Modelo y estrategias de partición de componentes hardware ...

MODELO Y ESTRATEGIAS DE PARTICIÓN DE COMPONENTES

HARDWARE / SOFTWARE EN EL CO-DISEÑO DE SISTEMAS EMBEBIDOS

Humberto Díaz Pando

http://www.ua.es/

http://www.eltallerdigital.com/

humberto díaz pando

M O D E L O Y E S T R AT E G I A S D E PA RT I C I Ó N D EC O M P O N E N T E S H A R D WA R E / S O F T WA R E E N E L

C O - D I S E Ñ O D E S I S T E M A S E M B E B I D O S

Universidad de Alicante

memoria de tesis doctoral

M O D E L O Y E S T R AT E G I A S D E PA RT I C I Ó N D EC O M P O N E N T E S H A R D WA R E / S O F T WA R E E N

E L C O - D I S E Ñ O D E S I S T E M A S E M B E B I D O S

humberto díaz pando

DirectoresDr. Sergio Cuenca Asensi

Dr. Roberto Sepúlveda Lima

Departamento de Tecnología Informática y Computación(DTIC)

Escuela Politécnica Superior

Enero 2014

Humberto Díaz Pando: Modelo y estrategias de partición de componenteshardware/software en el co-diseño de sistemas embebidos, c© Enero 2014

A Mariela y Victor Manuel...

A mis padres, a mi familia...

...Día llegará en que pueda llevar consigo el hombre,como hoy el tiempo en un reloj,

la luz, el calor y la fuerzaen algún aparato diminuto...

—– José Martí

A G R A D E C I M I E N T O S

Intentaré, agradecer en este espacio a todos aquellos que de una for-ma u otra contribuyeron durante la realización de este trabajo. Digointentaré, pues puede que se me olvide mencionar a alguien, debidoa la gran cantidad de personas que han estado pendientes de misavances durante este período.

Primeramente agradecer a Sergio y Roberto, mis dos tutores. Gra-cias por introducirme y guiarme en el mundo de la investigación. Porponer a mi disposición todo su conocimiento y contribuir a mi forma-ción profesional y personal. Por su ejemplo diario, por creer en mi,por su confianza y por contribuir a hacerme una mejor persona. Porser, sobre todas las cosas, mis amigos.

Quisiera agradecer también a alguien que fue como otro tutor máspara mí. Por el apoyo y aliento, por su convicción en la pertinencia demi trabajo, en momentos que ni yo mismo lo creía, por ser un ejemploa seguir, muchas gracias Ale.

A la Universidad de Alicante y al Departamento de Tecnología In-formática y Computación (DTIC) por la oportunidad que nos handado a mis colegas y a mi de formar parte del programa de doctora-do. Además, por el empeño en concretar esta beca para culminar misestudios doctorales en tiempos tan difíciles.

A todas aquellas personas que forman parte del DTIC y que dealguna forma me ofrecieron su apoyo y amistad incondicional. Enespecial quiero agradecer a Francisco Macía, por ser una de las per-sonas que llevó a cabo este programa de doctorado que ha permitidomi formación y superación profesional. Principalmente, por habermebrindado su amistad de forma incondicional, lo cual valoro y aprecio.

vii

A todas aquellas personas de la Facultad de Ingeniería Informáticade la CUJAE y del Complejo de Investigaciones Tecnológicas Integra-das, que de una forma u otra han estado pendientes y que me hanapoyado durante la realización de este trabajo. Gracias, sin su apoyotodo hubiera sido más difícil.

Al grupo de investigación de Minería de datos y optimización de laFacultad de Ingeniería Informática de la CUJAE, por aceptarme entresus filas. Por las buenas y productivas discusiones científicas, graciaspor permitirme ser un “inteligente” como ustedes.

Al equipo de Seguridad Tecnológica, que comenzó siendo un pe-queño grupo y hoy es un gran equipo o más bien una gran familia.Por ser testigo de todo este proceso de formación. Por las discusiones,por lo debates, por los buenos y malos momentos que hemos pasadojuntos. Por todo, gracias.

A Angel Grediaga y Toñi, que me han acogido siempre como sifuera un miembro más de su familia. A mis hermanos Angel Llorety Danay por su infinito apoyo y por estar siempre dispuestos a ayu-darme. Más que agradecido, me siento feliz por la familia que heencontrado aquí en España.

A Mariela y Victor Manuel, las dos personas más importantes enmi vida. Por saber esperar, por ser pacientes, por estar siempre a milado en este camino que emprendí. Espero que con este trabajo veanrecompensados los momentos en que quizás no les presté toda laatención que merecían. Los quiero mucho.

A mis padres por ser siempre el ejemplo a seguir, por el consejooportuno, por mostrar el camino, por su ayuda y apoyo. Este mo-mento también es de ustedes, se que lo disfrutarán como yo. A misabuelos, mi hermano, tíos, en fin, a toda mi familia que me ha apoya-do y ha estado presente siempre que los he necesitado, para todos mimas profundo agradecimiento.

Alicante, 10 de enero de 2014.Humberto Díaz Pando.

viii

R E S U M E N

La tarea de partición Hardware/Software es clave dentro de la me-todología de co-diseño de sistemas embebidos. En ella se decide, te-niendo en cuenta las métricas de diseño, qué componentes se ejecu-tarán en un procesador de propósito general (software) y cuáles enun hardware específico. La solución de dicha tarea implica resolverun problema de optimización combinatoria que en la mayoría de loscasos está clasificado de complejidad NP-fuerte.

En los últimos años se han propuesto diversos modelos dirigidos aautomatizar dicha tarea. En la mayoría de los casos estos modelos es-tán guiados por la optimización de una determinada métrica y sujetoa restricciones en otras métricas. Mientras que para recorrer el espa-cio de soluciones es frecuente encontrar aproximaciones que utilizanalgoritmos metaheurísticos.

No obstante, a pesar de la gran diversidad de modelos y métricasutilizadas, existen varios problemas que todavía permanecen abier-tos. Uno de estos problemas lo constituye la carencia de un modelogenérico para la partición Hw/Sw de componentes de un sistema em-bebido que integre varias métricas para la búsqueda de la particiónóptima. Otro aspecto por resolver es la forma de elegir el algoritmode partición más apropiado en función del tipo de aplicación y losrequisitos del sistema. De hecho, la mayoría de comparativas repor-tadas utilizan distintas instancias del problema, distintos modelos desistema y/o los parámetros son escogidos de forma poco clara o arbi-traria.

En este contexto, el presente trabajo define un modelo genérico yformal para el proceso de partición. Además, se propone una instan-cia del modelo dirigida a optimizar dos de las métricas más habi-tuales en los sistemas embebidos: Tiempo y Área. A partir de estainstancia, se desarrolla un estudio comparativo entre varios algorit-mos metaheurísticos, cuyas conclusiones están respaldadas mediantepruebas estadísticas no paramétricas. Como caso de estudio, se utiliza

ix

el modelo en una aplicación real, codificador JPEG, que combina losdos tipos de computación más habituales en los sistemas embebidos.

Los resultados de la comparación muestran, en general, que losalgoritmos Escalador de colinas estocástico y Escalador de colinas es-tocástico con Reinicio se compartan de forma similar a los AlgoritmosGenéticos en la solución de este problema. Por otra parte, el análisisde las soluciones desde el punto de vista multi-objetivo concluyó quelos algoritmos tienden a dominar porciones bien definidas del frentede Pareto, es decir, soluciones dominadas por el Tiempo, por el Áreao que tienden a estar en el centro del frente. Estos resultados per-miten establecer como estrategia, la utilización de varios algoritmosmetaheurísticos para resolver una instancia particular del problema,aportándole al diseñador un mayor abanico de posibilidades para to-mar la decisión sobre la implementación a realizar.

Como resultado de aplicar la instancia del modelo y los algoritmosEscalador de Colinas Estocástico y Escalador de Colinas Estocásti-co con Reinicio sobre la implementación de un codificador JPEG, sepudo constatar que estos dos algoritmos lograron soluciones com-parables, en cuanto a calidad, con otros algoritmos utilizados pararesolver este mismo problema.

A partir de los resultados obtenidos es posible concluir, en primerlugar, que el empleo de lógica difusa en el modelo permite manipularlas restricciones de forma más intuitiva con respecto a las variantesanteriores. Además de aportarle al modelo cierto grado de flexibi-lidad, permitiendo tratar el problema de una forma más cercana acómo el diseñador lo hace en la práctica. En segundo lugar, se pudoapreciar que los algoritmos Escalador de Colinas Estocástico y Esca-lador de Colinas Estocástico con Reinicio ofrecen resultados significa-tivos si son aplicados en el contexto de este problema. A partir de laaplicación de estos algoritmos en el caso de estudio se pudo consta-tar que estos logran soluciones que mejoran a las generadas por otrosalgoritmos.

Por otra parte, tanto el análisis multi-objetivo de las soluciones co-mo el enfoque multi-algorítmico para resolver el problema, dotan almodelo de partición Hardware/Software de una mayor riqueza alconsiderar soluciones en un espectro que pudieran resultar de inte-rés al diseñador.

x

A B S T R A C T

Hardware/Software partitioning is a key task in the design processof the embedded systems. In this task the system is partitioned ontohardware and software components, taking into account the designmetrics. To accomplish this task is necessary to solve an optimizationproblem that in most of its formulations is NP-hard.

In recent years, several models have been proposed to solve thistask. In most cases, these models are directed to optimize a particulardesign metric restricting others. To deal with the the optimizationproblem the most of the proposals use metaheuristics optimizationalgorithms.

However, despite the diversity of models and metrics employed,several problems remain open. One of these problems is the lack of ageneric model for Hw/Sw partitioning of embedded systems that in-tegrates various design metrics to explore the search space. Moreover,the appropriate choice of the best suited algorithm, depending on thetype of application and system requirement, it remains an open prob-lem. In fact, different problem instances and systems models are usedby most of the comparison reported. Moreover, the selection of thealgorithms and model parameters are not clear and in most case isarbitrary.

A generic and formal model for Hardware/Software Partitioningproblem based on soft computing methods is presented. Besides, amodel instance directed to optimize two of the most used metrics(Hardware area and the Execution time) is proposed. Whit this in-stance, a comparative study among several metaheuristics algorithmsis conducted. The data were compared using non-parametric statisti-cal tests. Finally, a study on the application of the model instance tothe JPEG codification system is presented.

The results show, in general, that the Stochastic Hill Climbing andRestart Stochastic Hill Climbing algorithms behave in a similar way tothe Genetics Algorithms to solve the hardware/software partitioningproblem. The analysis of the solutions form the multi-objective point

xi

of view state that the algorithms tend to dominate well defined re-gions of the Pareto front. In others word the algorithms tend to reachsolutions dominated by time or by area or tend to be at the center ofthe front. These results allow as effective strategy the use of multiplealgorithm to solve the hardware/software partitioning over a particu-lar instance. This strategy enable the designer to utilise a wide rangeof possibilities to take the decision of the best suited implementation.

As a result of applying the model instance with the Stochastic HillClimbing and Restart Stochastic Hill Climbing algorithms over thethe JPEG codification system implementation, it was confirmed thatthese two algorithms reach solution quality comparable to with theother algorithm used.

On the basis of the results obtained, it is possible to conclude thatthe use of fuzzy logic based models enables to handle the restrictionsin a more intuitively way with respect to other models. Moreover,it provides a certain degree of flexibility to addressed the problemin a similar way that the designers act in practice. Moreover, theStochastic Hill Climbing and Restart Stochastic Hill Climbing algo-rithms shows a significant results if they are used for hardware/soft-ware partitioning. These algorithms reach a good quality solutionson the JPEG study over other algorithms used.

Beside, the multi-problem and multi-algorithm strategy, give to themodel a broad spectrum of solutions, to to improve decision-making.

xii

Í N D I C E G E N E R A L

1 introducción 1

1.1 Preámbulo 1

1.2 Motivación 2

1.3 Antecedentes 8

1.4 Problema y Objetivos 10

1.5 Estructura de la tesis 12

i caracterización del problema de la partición hard-ware/software 15

2 partición hardware/software de sistemas embe-bidos 17

2.1 Marco teórico 17

2.2 Soluciones al problema de la Partición Hardware/Soft-ware. Estado de la cuestión 21

2.2.1 Métricas de diseño empleadas en los modelosde Partición Hardware/Software 23

2.2.2 Estrategias de búsqueda aplicadas en la solu-ción del problema 29

2.3 Tendencias en la validación de las propuestas 34

2.3.1 Aplicaciones empleadas para validar las pro-puestas 36

2.3.2 Estrategias para la validación de las propues-tas 38

2.4 Conclusiones 40

3 modelo de procesos para la partición hardwa-re/software 43

3.1 Caracterización del modelo de Partición Hardware/-Software 44

3.2 Proceso para la Partición Hardware/Software 45

3.2.1 Componente de inicialización 48

3.2.2 Componente de búsqueda 50

3.3 Instancia del modelo de partición para el índice de ren-dimiento 54

xiii

xiv índice general

3.3.1 Componente de inicialización 57

3.3.2 Componente de búsqueda 59

3.4 Un ejemplo de aplicación de la instancia del modelo departición 66

3.5 Conclusiones 74

ii validación del modelo de partición hardware/-software 77

4 experimentos y resultados 79

4.1 Organización de los experimentos 80

4.1.1 Guía de experimentación 80

4.1.2 Bancos de prueba 81

4.1.3 Algoritmos metaheurísticos 86

4.1.4 Métricas para evaluar el comportamiento de losalgoritmos 87

4.1.5 Análisis estadístico 92

4.2 Configuración inicial del modelo de Partición Hardwa-re/Software 95

4.2.1 Planificación 96

4.2.2 Diseño 97

4.2.3 Análisis de los resultados 100

4.3 Análisis estadístico 113

4.3.1 Calidad de la solución 113

4.3.2 Tasa de error 115

4.3.3 Distancia generacional 117

4.3.4 Dispersión 119

4.3.5 Tamaño del espacio cubierto 120

4.3.6 Cobertura 122

4.4 Contribución al frente de Pareto unificado 126

4.5 Conclusiones 128

5 caso de estudio 131

5.1 Descripción del caso de estudio 132

5.2 Instancia del modelo de Partición Hardware/Softwa-re 135

5.3 Descripción de los experimentos 136

5.4 Análisis de los resultados 137

5.5 Conclusiones 141

índice general xv

6 conclusiones y trabajo futuro 143

6.1 Conclusiones generales 143

6.2 Principales aportaciones 145

6.3 Trabajo futuro 146

6.4 Publicaciones 148

iii apéndices 149

a notación 151

b configuración de la herramienta tgff 153

b.1 Grafos de 50 nodos 153




c configuración de los experimentos 159

d configuración de los experimentos para el caso

de estudio 185

bibliografía 191

Í N D I C E D E F I G U R A S

Figura 1 Ejemplo de competencia entre las métricas dediseño. 3

Figura 2 Flujo básico del proceso de co-diseño. 5

Figura 3 Vista general del proceso de Partición Hard-ware/Software. 19

Figura 4 Clasificación de las propuestas de partición decomponentes de Hardware/Software. 23

Figura 5 Estrategias empleadas en la solución del pro-blema de Partición Hardware/Software. 30

Figura 6 Componentes presentes en la validación de pro-puestas de Partición Hardware/Software. 35

Figura 7 Vista global del proceso de Partición Hardwa-re/Software propuesto. 47

Figura 8 Vista de las actividades del subproceso de Ini-cialización. 49

Figura 9 Definición de las variables involucradas en elmodelo. 50

Figura 10 Vista de las actividades del subproceso de bús-queda. 53

Figura 11 Funciones de pertenencia Gamma. 63

Figura 12 Frente de Pareto. 65

Figura 13 Aplicación hipotética para el ejemplo. 67

Figura 14 Resultados obtenidos por el proceso de Inicia-lización para el ejemplo. 69

Figura 15 Tendencia de la función objetivo para el ejem-plo. 74

Figura 16 Frente de Pareto para el ejemplo. 75

Figura 17 Frente optimal de Pareto unificado para las pri-meras cuatro instancias estudiadas. 127

Figura 18 Frente optimal de Pareto unificado de otrasinstancias. 128

xvi

Figura 19 Grafo de flujo de control-datos para el siste-ma de codificación JPEG. Tomado de Lee et al.[2007a]. 133

Figura 20 Frente optimal de Pareto unificado para el casode estudio JPEG. 141

Í N D I C E D E TA B L A S

Tabla 1 Resumen de las métricas utilizadas en los mo-delos de Partición Hardware/Software. 28

Tabla 2 Universo del discurso para cada una de las va-riables lingüísticas. 62

Tabla 3 Posibles combinaciones que generan las carac-terísticas dinámicas del procesador. 68

Tabla 4 Codificación de las soluciones generadas a par-tir de los datos del ejemplo. 71

Tabla 5 Evaluación de las soluciones generadas a par-tir de los datos del ejemplo. 72

Tabla 6 Universo del discurso para cada métrica delejemplo. 73

Tabla 7 Características de las instancias generadas. 82

Tabla 8 Universo del discurso para cada instancia ge-nerada. 85

Tabla 9 Factores controlables asociados a la lógica di-fusa que influyen en el rendimiento del mode-lo. 98

Tabla 10 Factores controlables asociados a los algorit-mos que influyen en el rendimiento del mo-delo. 99

Tabla 11 Factores e interacciones influyentes para el Al-goritmo Genético. 102

Tabla 12 Niveles de los factores para minimizar el ren-dimiento en el algoritmo Genético. 103

xvii

xviii Índice de tablas

Tabla 13 Factores e interacciones influyentes para el al-goritmo Estrategia Evolutiva. 105

Tabla 14 Niveles de los factores para minimizar el ren-dimiento en el algoritmo Estrategia Evolutiva. 106

Tabla 15 Factores e interacciones influyentes para el al-goritmo Escalador de Colinas con Reinicio. 108

Tabla 16 Niveles de los factores para minimizar el ren-dimiento en el algoritmo Escalador de Colinascon Reinicio. 109

Tabla 17 Factores e interacciones influyentes para el al-goritmo Escalador de Colinas. 111

Tabla 18 Niveles de los factores para minimizar el ren-dimiento en el algoritmo Escalador de Coli-nas. 112

Tabla 19 Promedio de calidad de la solución en las 16

instancias. 114

Tabla 20 Clasificaciones obtenidas por la prueba de Fried-man. Métrica: calidad de la solución. 115

Tabla 21 Valores p ajustados para la prueba de Fried-man, con Escalador de Colinas como métodode control. Métrica: calidad de la solución. 115

Tabla 22 Tasa de error del frente de Pareto de cada algo-ritmo con respecto al frente unificado. 116

Tabla 23 Clasificaciones obtenidas por la prueba de Fried-man. Métrica: tasa de error. 117

Tabla 24 Valores p ajustados para la prueba de Fried-man, con Algoritmo Genético como método decontrol. Métrica: tasa de error. 117

Tabla 25 Distancia generacional del frente de Pareto decada algoritmo con respecto al frente de ParetoUnificado. 118

Tabla 26 Clasificaciones obtenidas por la prueba de Fried-man. Métrica: distancia generacional. 119

Tabla 27 Valores p ajustados para la prueba de Fried-man, con Algoritmo Genético como método decontrol. Métrica: tasa de error. 119

Tabla 28 Valores de dispersión de cada uno de los fren-tes de Pareto de cada algoritmo. 120

Tabla 29 Clasificaciones obtenidas por la prueba de Fried-man. Métrica: dispersión. 121

Tabla 30 Área cubierta por los frentes de Pareto de cadaalgoritmo en cada instancia. 121

Tabla 31 Clasificaciones obtenidas por la prueba de Fried-man. Métrica: tamaño del espacio cubierto. 122

Tabla 32 Cobertura alcanzada por cada uno de los fren-tes de Pareto de cada algoritmo en cada ins-tancia (I). 123

Tabla 33 Cobertura alcanzada por cada uno de los fren-tes de Pareto de cada algoritmo en cada ins-tancia (II). 124

Tabla 34 Resultados de la prueba de Wilcoxon. Métrica:Cobertura. 124

Tabla 35 Resultados globales de las clasificaciones delos algoritmos por cada métrica. 125

Tabla 36 Clasificaciones obtenidas para los resultadosglobales. 125

Tabla 37 Estimaciones obtenidas para el caso de estu-dio. Tomado de Lee et al. [2007a]. 134

Tabla 38 Comparación de los resultados de los algorit-mos Escalador de Colinas y Escalador de Co-linas con Reinicio con el estado del arte en elcaso de estudio. 139

Tabla 39 Configuración del experimento para el Algo-ritmo Genético 165

Tabla 40 Configuración del experimento para el algorit-mo Estrategia Evolutiva. 171

Tabla 41 Configuración del experimento para el algorit-mo Escalador de Colinas con Reinicio. 177

Tabla 42 Configuración del experimento para el algorit-mo Escalador de Colinas. 183

xix

xx lista de acrónimos

Tabla 43 Configuración de los experimentos para los al-goritmos Escalador de Colinas con Reinicio,Algoritmo Genético y Estrategia Evolutiva. 189

L I S TA D E A C R Ó N I M O S

SE Sistema embebido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

BA Algoritmo Búsqueda Aleatoria . . . . . . . . . . . . . . . . . . . . . . 31

BT Algoritmo Búsqueda Tabú . . . . . . . . . . . . . . . . . . . . . . . . . . 31

RS Algoritmo Recocido Simulado . . . . . . . . . . . . . . . . . . . . . . 31

EC Algoritmo Escalador de Colinas mejor ascenso . . . . 132

ECR Algoritmo Escalador de Colinas con Reinicio . . . . . . 132

AG Algoritmos Genéticos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

EE Algoritmo Estrategia Evolutiva . . . . . . . . . . . . . . . . . . . . 132

PSO De sus siglas en inglés Particle Swarm Optimization,Optimización basada en Enjambre de Partículas . . . 132

ACO De sus siglas en inglés Ant Colony Optimization,Optimización basada en Colonia de Hormigas . . . . . . 31

AJ Algoritmo Agrupamiento Jerárquico . . . . . . . . . . . . . . . . 31

MG Algoritmo Migración de Grupos . . . . . . . . . . . . . . . . . . . . 31

KL Algoritmo Kernighan/Lin . . . . . . . . . . . . . . . . . . . . . . . . . . 32

ENSA De sus siglas en inglés Evolutionary NegativeSelection Algorithm, Algoritmo Evolutivo de SelecciónNegativa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

AIS De sus siglas en inglés Artificial Inmune System,Sistema Inmune Artificial. . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

HSP De sus siglas en inglés, Hardware-SoftwarePartitioning, Partición Hardware/Software. . . . . . . . . 131

lista de acrónimos xxi

UML De sus siglas en inglés Unified Modeling Language,Lenguaje Unificado de Modelado. . . . . . . . . . . . . . . . . . . 19

VHSIC De sus siglas en inglés Very High Speed IntegratedCircuit, Circuito Integrado de Muy Alta Velocidad.

VHDL De sus siglas en inglés VHSIC Hardware DescriptionLenguaje, Lenguaje de Descripción de Hardware paraCircuitos Integrados de Muy Alta Velocidad. . . . . . . . . .6

FFT De sus siglas en inglés, Fast Fourier Transform,Transformada Rápida de Fourier. Este algoritmopermite resolver la Transformada Discreta de Fourier.37

DCT De sus siglas en inglés, De sus siglas en inglés,Discrete Cosine Transform, Transformada Discreta delCoseno. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

TGFF De sus siglas en inglés, Task Graph For Free. . . . . . . 153

JPEG De sus siglas en inglés, Joint Photographic ExpertsGroup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131

CDFG De sus siglas en inglés, Control-Data Flow Graph,Grafo de flujo de control-datos. . . . . . . . . . . . . . . . . . . . . 132

FPGA De sus siglas en inglés, Field Programmable GateArray. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

ASIC De sus siglas en inglés, Application-Specific IntegratedCircuit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

NSGA De sus siglas en inglés, Non-dominated SortingGenetic Algorithm, Algoritmo Genético deOrdenamiento No dominado. . . . . . . . . . . . . . . . . . . . . . . . 32

WSGA De sus siglas en inglés, Weighted Sum GeneticAlgorithm, Algoritmo Genético basado en SumaPonderada. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

MOPSO-CD De sus siglas en inglés, Multi-Objective Particle SwarmOptimization using Crowding Distance, Optimizaciónbasada en Enjambre de Partículas Multi-Objetivousando la Distancia de Hacinamiento. . . . . . . . . . . . . . . 32

xxii lista de acrónimos

NP De sus siglas en inglés, Nondeterministic PolynomialTime, Tiempo Polinomial No Determinista. . . . . . . . . . . 2

BFM De sus siglas en inglés, Bus Functional Model. . . . . . . . 6

RTL De sus siglas en inglés, Register Transfer Level. . . . . . . 6

CFG De sus siglas en inglés, Control Flow Graph, Grafo deControl de Flujo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

DFG De sus siglas en inglés, Data Flow Graph, Grafo deFlujo de Datos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21

CG De sus siglas en inglés, Call Graph, Grafo deLlamadas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

1I N T R O D U C C I Ó N

Este capítulo presenta los principales aspectos relacionados con elcampo de acción en el cual se enmarca la presente investigación doc-toral. En la sección 1.1 se plantea a grandes rasgos el contexto en quese desarrolló el trabajo de investigación. Seguidamente, la sección 1.2describe los aspectos que motivaron el trabajo y la sección 1.3 lasprincipales contribuciones realizadas en el ámbito del problema departición Hw/Sw. En la sección 1.4, se plantean los problemas identi-ficados y los objetivos que permitirán darle solución. Finalmente, enla sección 1.5 se muestra la estructura general de la memoria.

1.1 preámbulo

La memoria que se presenta a continuación es el resultado del traba-jo de tesis doctoral desarrollado en el programa de doctorado Tecno-logías de la sociedad de la información. Este programa está a cargo delDepartamento de Tecnología Informática y Computación DTIC, de la Uni-versidad de Alicante (España) y en él participan varias universidadescubanas, entre ellas, el Instituto Superior Politécnico José Antonio Eche-verría, CUJAE.

Este trabajo se enmarca en el contexto del diseño de sistemas embe-bidos. En particular aborda el problema que consiste en particionarlos componentes del sistema en dos conjuntos, hardware y software,de forma tal que se cumplan los requisitos y restricciones impuestas.En general, la decisión de adoptar una partición determinada implica

1

2 introducción

dar solución a un problema de optimización combinatoria que en lamayoría de los casos es de tipo NP1.

En la mayoría de los casos la partición se realiza de forma manual,a partir de la experiencia del diseñador. Teniendo en cuenta que lossistemas a diseñar cada vez son más complejos, el enfoque manualno garantiza, en general, la solución óptima o al menos una cercanaa esta. Es por ello, que en la última década se han propuesto un con-junto de soluciones que que permiten explorar de forma automáticael espacio de diseño. El principal inconveniente de estas propuestases que están dirigidas a resolver una instancia concreta del problemade optimización y además están altamente condicionadas por las mé-tricas que se definan para evaluar la calidad de los resultados y guiarla exploración de soluciones.

Se trata por tanto, de un problema de investigación abierto, comoevidencia el hecho de que las herramientas comerciales de diseño ra-ramente incluyen la partición automática de los sistemas. Por otrolado no existe una aproximación genérica al problema de la particiónhw/sw que tenga en cuenta un conjunto de características generalesy que trace las pautas para las instancias de acuerdo con los requeri-mientos a resolver.

La tesis se ha desarrollado en el marco del Proyecto de Seguridad Tec-nológica, llevado a cabo por el Complejo de Investigaciones TecnológicasIntegradas - CITI en colaboración con la Facultad de Ingeniería Informá-tica perteneciente a la CUJAE. Dicho proyecto tiene como objetivodesarrollar componentes y soluciones de software y hardware quegaranticen la seguridad de los sistemas informáticos en los que semanejan arquitectura híbridas.

1.2 motivación

En la actualidad, muchos son los escenarios donde se pueden encon-trar dispositivos que incluyen SE2 para controlar su funcionamiento;tales son los casos de la industria automovilística, la domótica, ins-trumentación médica, control de tráfico en carreteras o aplicaciones

1 De sus siglas en inglés, Nondeterministic Polynomial Time, Tiempo Polinomial NoDeterminista.

2 Sistema embebido

1.2 motivación 3

Consumo

de potencia

Tiempo Tamaño de

Hw

Tamaño de

Sw

Figura 1 Ejemplo de competencia entre las métricas de diseño.

de seguridad entre otras. Según Vahid and Givargis [2002], estos sis-temas tienen tres características fundamentales: (1) ofrecen una únicafuncionalidad, (2) están ligados a fuertes restricciones y (3) deben serreactivos y/o responder en tiempo real.

Esta caracterización supone que para diseñar un SE es necesariocumplir diferentes objetivos que son definidos por el diseñador encorrespondencia con los requerimientos del sistema. La presencia dedistintos objetivos, generalmente contrapuestos, trae consigo la nece-sidad de lograr un balance adecuado entre estos, implicando que eldiseño sea un proceso complejo en sí mismo. Para evaluar el grado decumplimiento de estos objetivos se suelen utilizar diferentes métricas,siendo las más habituales: Área de hardware, Área de software, Ren-dimiento, Coste por unidad, Flexibilidad, Potencia consumida, entreotras. La optimización de una de estas métricas, con el fin de cumplircon algún objetivo de diseño, puede provocar que otras empeoren. Va-rios autores consideran esta situación análoga a una rueda con variosclavos, donde al presionar uno hacia dentro el resto sale hacia fuera.En la figura 1 se puede apreciar gráficamente este efecto, donde al in-tentar disminuir los recursos de hardware del sistema, el rendimientodisminuye y los costes asociados al software aumentan.

En la mayoría de los casos para garantizar el adecuado balancede las métricas o simplemente para cumplir con los requisitos im-puestos al sistema, es necesario codificar parte del sistema en softwa-re (Sw) para ser ejecutado sobre un microprocesador e implementar

4 introducción

otras partes sobre hardware diseñado a medida (Hw). Esto suponeun complejo proceso de diseño sustentado en tres tecnologías claves[Vahid and Givargis, 2002]: tecnologías de circuitos integrados, tecno-logías de los procesadores y tecnologías de diseño. Estas tecnologíasestablecen la posibilidad de utilizar distintos tipos de arquitecturase implementarlas con diferentes procesos de fabricación. Además po-nen a disposición del diseñador un conjunto de herramientas y pro-cedimientos para guiar el proceso de diseño, permitiéndole cumplircon las métricas de diseño. En los últimos años estas herramientashan ido perfeccionándose, haciendo posible que el diseño sea un pro-ceso más ágil; permitiendo así el desarrollo de sistemas embebidosen menos tiempo.

Las metodologías tradicionales de diseño consideran la especifica-ción y codificación del hardware y del software por separado, lleván-dose a cabo esta separación durante las primeras etapas del desarro-llo. Esta forma de trabajar no asegura el cumplimiento de los obje-tivos, además de requerir costosas iteraciones para el refinamientodel diseño. Para resolver estos inconvenientes la tendencia actual, de-nominada co-diseño (Wolf [2003], Shaout et al. [2009], Schaumont[2010]), consiste en realizar una descripción unificada del sistemacompleto, tanto Hw como Sw, con el fin de garantizar las funciona-lidades y restricciones en su conjunto. Esta metodología permite: (1)obtener estimaciones precisas de los parámetros de diseño (Área, Ren-dimiento, Potencia, etc.) en las fases más tempranas, sin necesidad depasar por la costosa fase de implementación y que la exploración delespacio de diseño sea más ágil y (2) facilitar la descripción y la interac-ción entre el hardware y el software, por ejemplo mediante lenguajesunificados de descripción que sirvan tanto para el hardware comopara el software (por ejemplo SystemC [Swan, 2001] o SpecC [Fujitaand Nakamura, 2001], [Gajski et al., 2000]).

En los trabajos de Adhipathi [2004] y Shaout et al. [2009] es posibleapreciar que el proceso de co-diseño está compuesto de varias etapas,aunque cabe señalar que estas pueden variar según el enfoque quepretendan brindar los autores. No obstante a partir de estos traba-jos se puede identificar un flujo básico formado por: Especificacióny Modelado, Partición Hw/Sw, Síntesis, Integración y Simulación yVerificación. En la figura 2 se muestra este flujo básico de actividades.

1.2 motivación 5

Especificación

Partición Hw/Sw

Síntesis

Hardware

Síntesis

Interfaces

Síntesis

Software

Descripción

Hardware

Descripción

Software

Integración e

Implementación

Validación

Figura 2 Flujo básico del proceso de co-diseño.

Como puede observarse, el punto de inicio del proceso es la especi-ficación del sistema, en la cual el diseñador captura los requerimien-tos haciendo abstracción de las cuestiones de implementación. Estosrequerimientos normalmente se especifican en un lenguaje no formal,aunque existen trabajos como los de López-Vallejo and López [2003]y Shaout et al. [2009] que intentan formalizarlo para ayudar en laautomatización de las actividades posteriores.

Seguidamente se realiza la etapa de partición Hw/Sw que tienepor misión realizar la exploración de distintas posibilidades con elobjetivo de decidir qué elementos del sistema se ejecutarán en un pro-cesador de propósito general (Sw) y cuales se implementarán sobreco-procesadores a medida (Hw) (De Micheli and Gupta [1997], Aratóet al. [2003], Wolf [2003]). El resultado de esta fase es un modelo de

6 introducción

comportamiento para cada parte del sistema (por ejemplo: VHDL3

para el hardware y C para el software). Para realizar la exploracióndel espacio de diseño Hw/Sw, en primer lugar, es necesario traducirla especificación inicial en un modelo computacional; en el cual sedefine la forma en que será representado el sistema antes y duranteel proceso [Cortés et al., 1999]. Además cada elemento de este mode-lo es anotado con los valores estimados de cada una de las variablesque se desea medir en el sistema final.

El próximo paso es el encargado de traducir este modelo de com-portamiento en un modelo físico, dicha traducción se realiza utilizan-do una herramienta de síntesis, obteniéndose un modelo ejecutabledel software, un modelo RTL4 para del hardware y un modelo fun-cional para los elementos de comunicación (por ejemplo un modeloBFM5). A este nivel se puede realizar una simulación conjunta o co-simulación con el fin de verificar la funcionalidad de todo el sistemay estimar las métricas asociadas. Así mismo, como resultado de la sín-tesis se pueden obtener estimaciones de las restricciones que se captu-raron en el inicio del diseño. Finalmente, se realiza la implementacióndel Hw y la compilación del Sw, integrándose conjuntamente con lasinfraestructuras de comunicaciones. En este momento es posible me-dir el nivel de cumplimiento de los objetivos planteados (Rendimien-to, Área, Potencia, etc.) y validar el diseño o en caso contrario volvera repetir el proceso hasta conseguir los objetivos (López-Vallejo andLópez [2003], Adhipathi [2004], Shaout et al. [2009]).

En la metodología del co-diseño, una de las etapas clave es la parti-ción Hw/Sw (HSP6), ya que en ella se definirá cual será la configura-ción final que adoptará el sistema (módulos de Hw y Sw). A pesar dejugar un rol importante dentro del proceso, en la mayoría de los ca-sos, esta etapa se ejecuta teniendo en cuenta únicamente la experien-cia del diseñador y/o realizando una somera exploración del espaciode diseño. Este procedimiento, además de no ajustarse a ninguna me-todología, no asegura un resultado óptimo, ya que para obtener la

3 De sus siglas en inglés VHSIC Hardware Description Lenguaje, Lenguaje de Des-cripción de Hardware para Circuitos Integrados de Muy Alta Velocidad.

4 De sus siglas en inglés, Register Transfer Level.5 De sus siglas en inglés, Bus Functional Model.6 De sus siglas en inglés, Hardware-Software Partitioning, Partición Hardware/Soft-

ware.

1.2 motivación 7

mejor configuración es necesario resolver un problema de optimiza-ción que en la mayoría de sus formulaciones es NP-fuerte, tal y comodemuestra Arató et al. [2005]. Además la mayoría de las herramientascomerciales para el desarrollo de sistemas embebidos, no incluyen so-porte para la ejecución automática o semiautomática de esta tarea, locual trae como consecuencia que el diseñador tenga que completar elcostoso ciclo partición/síntesis/implementación repetidas veces has-ta alcanzar los objetivos. Bajo las condiciones descritas anteriormenteel proceso de diseño se hace tedioso, ya que para sistemas grandeslas etapas de síntesis e implementación pueden tardar del orden dehoras hasta varios días.

En los últimos años han sido publicados varios trabajos, entre losque se pueden citar los de [López-Vallejo and López, 2003, Mann,2004, Jigang and Srikanthan, 2006b, Amin et al., 2007, Jigang et al.,2008a,b, Bhattacharya et al., 2008], los cuales buscan la sustitución deestos métodos “ad-hoc” por determinada automatización en la parti-ción de los componentes entre las plataformas de hardware y softwa-re. Estos trabajos se centran en proponer modelos HSP que permitenllegar a una solución de una instancia del problema HSP, que si bienen algunos casos pudiera ser un óptimo local, es aceptada como sufi-cientemente buena. Generalmente estos modelos están guiados por laoptimización de una sola métrica de diseño (Área de hardware utili-zada, Tiempo de ejecución o Potencia consumida) restringiendo otrassegún el modelo definido y de acuerdo con los intereses del sistemaen cuestión.

En la mayoría de las propuestas los autores utilizan algoritmos me-taheurísticos (Recocido Simulado, Búsqueda Tabú, Algoritmos Gené-ticos, entre otros) para resolver el problema de optimización, permi-tiendo explorar de forma más exhaustiva el espacio de diseño en bus-ca de la solución adecuada, en un tiempo considerable. En muchasde las propuestas la selección del algoritmo utilizado, no está funda-mentada sobre ningún criterio, mientras que en otras se analizan unnúmero arbitrario de criterios con el fin de escoger el mejor algorit-mo. La gran diversidad de algoritmos utilizados para guiar el procesode partición, unido a la carencia de bancos de prueba (benchmarks)impide una comparativa fiable entre las distintas propuestas y la se-

8 introducción

lección acertada de una estrategia particular que se adapte mejor acada problema HSP.

1.3 antecedentes

A la hora de abordar la problemática de la partición Hw/Sw es nece-sario considerar en primer lugar, aquellos trabajos que están dirigidosa utilizar nuevas métricas o a combinar de forma diferente las que yahan sido utilizadas en modelos previos. En segundo lugar, se consi-deran los trabajos que emplean nuevas estrategias para resolver elproblema HSP, así como los que comparan estrategias ya utilizadassobre un mismo modelo de optimización. Por último se tiene en cuen-ta la forma en que estas propuestas validan los modelos y algoritmosque proponen.

Los modelos propuestos hasta el momento de manera general sedefinen mediante una función de coste y varias restricciones, en estosdos aspectos están involucradas las métricas que se obtendrán a par-tir de los requerimientos que se deseen del sistema embebido. Existendiferentes métricas a considerar en el diseño de un sistema embebi-do, entre las más utilizadas se encuentran: el tiempo de ejecución, elconsumo de potencia, área de hardware ocupada.

En el trabajo de Mann [2004], se hace una abstracción de estas mé-tricas considerando solamente tres grandes grupos: (1) métricas decoste de hardware, (2) coste de software y (3) coste de comunicaciónentre los bloques Hw y Sw. En [Gupta and De Micheli, 1993] los auto-res proponen como función objetivo minimizar la utilización del bus ydel procesador y el tamaño del hardware, mientras que las restriccio-nes están basadas en métricas de tiempo relacionadas con la ejecuciónde las operaciones. En el sistema Cosyma [Ernst et al., 1993], se opti-miza el tiempo de ejecución bajo restricciones de tiempo y cantidadde ejecuciones de bloques básicos. En el sistema LYCOS propuestopor Madsen et al. [1997], así como en [Jigang and Srikanthan, 2006b],los autores buscan maximizar la aceleración que se produce al mo-ver un nodo de software a hardware, teniendo en cuenta el área totalocupada por el diseño. En [Jigang and Srikanthan, 2006a], los autoresplantean minimizar el área de hardware ocupada teniendo en cuentael consumo de potencia y el tiempo de ejecución del sistema. El mis-

1.3 antecedentes 9

mo autor propone en trabajos más recientes, [Jigang et al., 2008a,b],la minimización del tiempo de ejecución, en el cual se incluyen loscostos de comunicación entre nodos adyacentes, utilizando como res-tricción el área ocupada por el sistema. Por su parte, Göhringer et al.[2010], utilizan el tiempo de ejecución de las funciones, el costo decomunicación entre las funciones y la proximidad de las funcionespara determinar qué tareas pueden ejecutarse en un procesador.

En cuanto a las propuestas relacionadas con los aspectos algorít-micos existen tres grupos de ellas, diferenciadas por el tipo de al-goritmo o estrategias utilizadas para resolver el problema HSP: (1)algoritmos exactos, (2) algoritmos heurísticos y (3) técnicas de SoftComputing. En el primer grupo está la propuesta de Jigang and Sri-kanthan [2006a], la cual utiliza algoritmos basados en programacióndinámica. Mientras que en las de Madsen et al. [1997], Srinivasanet al. [1998], Jigang and Srikanthan [2006b], Jigang et al. [2008b], seemplean programación lineal. En el tercer grupo se encuentra la pro-puesta de Huang and Kim [2007] los autores combinan lógica difusay redes neuronales. Finalmente, en Zhang et al. [2007] es utilizado elalgoritmo ENSA7, el cual está inspirado en AIS8.

La mayoría de las propuestas están agrupadas en la segunda cate-goría, es decir, emplean algoritmos heurísticos (de propósito generalo de propósito específico) para resolver el problema HSP. En el casode las heurísticas generales, Adhipathi [2004] y Vahid [1997] propo-nen aproximaciones basadas en el algoritmo de la Estrategia Voraz.También se han realizado diversas propuestas basadas en los algorit-mos de Búsqueda Tabú y Aleatoria, tales son los casos de los trabajosde: Eles et al. [1997], Vahid [1997], Wiangtong et al. [2002], Jiganget al. [2008a]. Otras propuestas plantean soluciones basadas en Re-cocido Simulado como es el caso de las de Vahid [1997], Eles et al.[1997], Ernst et al. [1993], Wiangtong et al. [2002], López-Vallejo andLópez [2003], Algoritmos Genéticos son utilizados por Purnaprajnaet al. [2007], Wiangtong et al. [2002], Jigang et al. [2008a] y Enjam-bre de Partículas por Amin et al. [2007], Bhattacharya et al. [2008],Abdelhalim and Habib [2011].

7 De sus siglas en inglés Evolutionary Negative Selection Algorithm, Algoritmo Evo-lutivo de Selección Negativa.

8 De sus siglas en inglés Artificial Inmune System, Sistema Inmune Artificial.

10 introducción

Existen varios autores [Vahid, 1997, López-Vallejo and López, 2003,Göhringer et al., 2010] que utilizan el algoritmo de AgrupamientoJerárquico y Gupta and De Micheli [1993] utilizan la Migración deGrupos.

También existen trabajos que emplean heurísticas de propósito es-pecífico tal es el caso de la propuesta de Jigang and Srikanthan [2006a],Jigang et al. [2008a]. Vahid [1997], la cual utiliza el algoritmo de Ker-nighan/Lin.

Por otra parte existen trabajos donde los autores comparan sus pro-puestas con otros algoritmos, tal es el caso del trabajo de Vahid [1997],en el cual se compara una extensión al algoritmo Min-Cut o heurísticoKernighan/Lin, con Búsqueda Aleatoria, Recocido Simulado, varian-te de Voraz, Agrupamiento Jerárquico y Agrupamiento seguido poruna mejora voraz; obteniéndose buenos resultados con el primero deestos. También en López-Vallejo and López [2003], los autores compa-ran el algoritmo de Kernighan/Lin con Recocido Simulado, Agrupa-miento Jerárquico y un Sistema Experto.

Jigang and Srikanthan [2006b] y Jigang et al. [2008b] modifican elalgoritmo propuesto por Madsen et al. [1997] el cual está basado enprogramación lineal, para luego comparar los resultados de ambosalgoritmos. En Jigang et al. [2008a], se compara un algoritmo heurís-tico de propósito específico con Recocido Simulado, Búsqueda Tabúy Algoritmo Genético. Por último, en el trabajo de Wiangtong et al.[2002], los autores obtienen buenos resultados con la Búsqueda Tabúsobre el Algoritmo Genético y Recocido Simulado.

1.4 problema y objetivos

Una vez identificados los elementos motivacionales y analizados losantecedentes, se identifican como problemas:

• Carencia de un modelo genérico para la partición Hw/Sw decomponentes de un sistema embebido que integre varias métri-cas para la búsqueda de la partición óptima.

• Carencia de un estudio comparativo homogéneo y estadística-mente fundamentado con algoritmos metaheurísticos que per-

1.4 problema y objetivos 11

mita determinar la pertinencia de una estrategia concreta paraun modelo HSP dado.

Para solucionar estos problemas se plantea como Objetivo generalproponer un modelo matemático para la partición Hw/Sw de siste-mas embebidos que garantice:

• Un balance entre varias métricas de diseño

• Múltiples soluciones factibles para una misma instancia del pro-blema

Este objetivo general es posible descomponerlo en los siguientesObjetivos específicos y estos a su vez en Tareas:

1. Realizar un estudio del estado del arte de las propuestas vincu-ladas con la partición de componentes Hw/Sw en el co-diseñode sistemas embebidos

a) Definir el marco teórico asociado a la problemática aborda-da en este trabajo.

b) Estudiar las métricas empleadas en los modelos HSP.

c) Estudiar el estado actual de las investigaciones relaciona-das con los algoritmos metaheurísticos aplicados a la solu-ción del problema HSP.

2. Definir un modelo matemático genérico para el HSP de SE.

a) Seleccionar las métricas a utilizar en el modelo.

b) Definir un enfoque de integración de un conjunto de mé-tricas previamente seleccionadas.

3. Caracterizar el empleo de algoritmos metaheurísticos que so-porten de manera consistente el modelo propuesto.

a) Implementar una instancia del modelo propuesto utilizan-do un lenguaje de programación.

b) Ejecutar la instancia sobre problemas simulados utilizandodiferentes algoritmos metaheurísticos.

c) Definir las medidas que permitan evaluar la calidad de lassoluciones brindadas por los algoritmos.

12 introducción

d) Validar la pertinencia del modelo y el desempeño de losalgoritmos en cuanto a las métricas definidas.

4. Validar mediante un caso de estudio el modelo propuesto.

a) Analizar un caso de estudio significativo para el problemaHSP.

b) Adecuar el modelo propuesto, de forma tal que sea posiblesu aplicación al caso de estudio.

c) Definir los experimentos sobre el caso de prueba.

d) Analizar los resultados de los experimentos para evaluarla propuesta de algoritmos y métricas en la instancia.

e) Comparar los resultados alcanzados con los reportados enla literatura.

1.5 estructura de la tesis

El presente documento de tesis está estructurada en seis capítulos. Acontinuación se brinda un resumen del contenido abordado en cadauno de estos:

• Capítulo 1 Introducción: este primer capítulo contiene los aspec-tos metodológicos de la presente investigación doctoral.

• Capítulo 2 Partición Hardware/Software de Sistemas Embebi-dos: se abordan los principales elementos conceptuales que per-mitirán comprender las bases teóricas en las que se sustentael problema HSP. Además, se presenta la revisión del estadoactual de las propuestas para solucionar dicho problema, asícomo de las estrategias para validar estas propuestas.

• Capítulo 3 Modelo de procesos para la Partición Hardware/-Software: se propone un modelo HSP genérico, que estableceaspectos claves a tener en cuenta para resolver el problema HSP.Además, se propone una instancia de este modelo, la cual em-plea la métrica Índice de rendimiento para evaluar las solucio-nes.

1.5 estructura de la tesis 13

• Capítulo 4 Experimentos y resultados: contiene los elementosnecesarios para realizar una evaluación experimental del mode-lo propuesto.

• Capítulo 5 Caso de estudio: presenta la aplicación de la instan-cia del modelo propuesta sobre la implementación del codifica-dor JPEG9 y se comparan los resultados con los reportados enlas fuentes.

• Capítulo 6 Conclusiones y trabajos futuros: se exponen las con-clusiones generales que se obtuvieron como resultado de la in-vestigación, se detallan las principales aportaciones y por últi-mo se exponen las líneas futuras de investigación a seguir.

Además, la memoria cuenta con Referencias Bibliográficas y Anexos.

9 De sus siglas en inglés, Joint Photographic Experts Group.

Parte I

C A R A C T E R I Z A C I Ó N D E L P R O B L E M A D E L APA RT I C I Ó N H A R D WA R E / S O F T WA R E

En el capítulo 2 se presentará una taxonomía que agru-pa las principales contribuciones del estado del arte dela temática que se aborda en el trabajo de tesis. Ademásse establecen las bases conceptuales, que permitirán com-prender mejor las propuestas analizadas.

Seguidamente, en el capítulo 3, se presentará el modelogenérico para la partición HSP, el cual permitirá la inte-gración de varias métricas primitivas y compuestas paralograr configuraciones con altos niveles de calidad y deacuerdo con la forma en que se realizan las tareas para eldiseño de sistemas embebidos. Para finalizar, en este capí-tulo se detalla una instancia de este modelo, así como unejemplo de aplicación de esta instancia, a fin de lograr lacomprensión de la propuesta.

2PA RT I C I Ó N H A R D WA R E / S O F T WA R E D E S I S T E M A SE M B E B I D O S

En este capítulo se presentan las bases conceptuales vinculadas alobjeto de estudio de este trabajo, las cuales permitirán identificar lasfortalezas y debilidades para, a partir de estas, diseñar una propuestade modelo HSP de sistemas embebidos.

La sección 2.1 presenta los principales conceptos que permitiráncomprender las bases teóricas en las que se sustenta el problemaHSP. Seguidamente, en la sección 2.2 se expone el estado del artede las propuestas dedicadas a la solución del problema HSP. Para ha-cer más efectivo el análisis, en la sección 2.2.1 se detallan las métricasutilizadas para caracterizar el diseño; mientras que en la sección 2.2.2se analizan los algoritmos y estrategias más utilizadas para resolver elproblema HSP. Por último, se exploran las principales tendencias uti-lizadas en la validación de las propuestas de modelos HSP, (sección2.3)

2.1 marco teórico

Como se ha comentado en el capítulo anterior el proceso de co-diseñoestá formado por un conjunto de etapas en las cuales sobresale porsu importancia la partición del sistema en componentes de hardwarey de software. En el Capítulo 1 se definió esta como la etapa donde sedecide la configuración que debe ser implementada para que se cum-plan los valores establecidos para las métricas. Antes de continuar esimportante aclarar que el término partición se deriva de la traducciónal castellano del término en inglés partitioning, el cual proviene de la

17

18 partición hardware/software de sistemas embebidos

palabra Partition: Divide into parts. Dismember and distribute. Separateby a partition.

Existen tres conceptos más vinculados a esta área del conocimiento,los cuales son utilizados indistintamente en los trabajos relacionados,creando cierta confusión. Con el objetivo de establecer una base con-ceptual sobre los términos empleados en el contexto de este trabajo,a continuación se definirán los términos: Problema, Instancia del pro-blema y Modelo HSP; para esto se tendrá en cuenta los diferentessignificados dados en el resto de los trabajos.

El Problema HSP se define como el problema de optimización com-binatoria que resulta de encontrar la configuración (componentes deHw y Sw) óptima o cercana a esta que garantice los parámetros de ca-lidad y tenga en cuenta las restricciones impuestas en el diseño1. Porsu parte, una Instancia del problema HSP obedece a un caso particu-lar del problema, el cual está en función del sistema a implementar,de los parámetros de calidad y de las restricciones. Por último, elModelo HSP es un esquema o representación de una Instancia delproblema HSP en concreto, el cual permitirá obtener las solucionesque se correspondan con los parámetros de calidad definidos paraesa instancia.

Vinculada a la tarea de partición de sistemas embebidos, se definetambién la exploración de las distintas alternativas de implementa-ción de los módulos hardware. Esta tarea se suele denominar Explo-ración del Espacio de Diseño y consiste en explorar los grados delibertad del diseño en busca la mejor forma de implementar el siste-ma. Es necesario apuntar que los grados de libertad no son más quelas diferentes configuraciones que puede adoptar la arquitectura encada experimento para llegar a la solución con mejor calidad. En al-gunos trabajos la Exploración del Espacio de Diseño se incluye en elproceso de partición [Srinivasan et al., 1998]. En el presente trabajo,y siguiendo el planteamiento de la mayoría de las aproximaciones,consideraremos el problema HSP de forma independiente, pudién-dose complementar posteriormente con la tarea de Exploración pararefinar los resultados obtenidos.

1 Los parámetros de calidad, al igual que las restricciones, serán definidos por el di-señador y pueden variar de una instancia a otra del problema y en correspondenciacon los requerimientos del usuario

2.1 marco teórico 19

Analizando la definición que se ha dado a la etapa de particiónHw/Sw, es posible identificar la presencia de actividades relaciona-das entre sí, las cuales utilizan recursos, para obtener la configuraciónadecuada del sistema. Teniendo en cuenta la observación anterior enesta sección será explicado el HSP siguiendo un enfoque orientadoa proceso. Lo anterior permitirá identificar cada una de las activida-des que lo conforman y los recursos asociados a cada una de ellas,ayudando a decidir qué actividades pueden ser objeto de mejora. Elmodelo de proceso HSP que se presentará en esta sección sigue lanotación propuesta por Eriksson and Penker [2000] como extensiónUML2 para describir procesos de negocio.

<<physical>>

Especificación

del sistema

<<abstract>>

Arquitectura

<<abstract>>

Restricciones

Búsqueda de la

solución Inicialización

<<abstract>>

Variables

<<Objetivo>>

Obtener una configuración del sistema en cuanto a

componentes de software y hardware que cumpla con los

requerimientos y restricciones.<<abstract>>

Componentes

de Sw

<<abstract>>

Componentes

de Hw

<<information>>

Estimaciones de

Hw y Sw

<<supply>> <<supply>><<supply>>

<<achieve>>

Figura 3 Vista general del proceso de Partición Hardware/Software.

En las últimas décadas, varios han sido los trabajos donde se hanpropuesto soluciones al problema HSP. La mayoría de las propuestasanalizadas coinciden en la presencia de dos subprocesos básicos: Ini-cialización y Búsqueda de la solución, (figura 3). Es necesario destacarque esta definición obedece a una representación de un modelo HSPgenérico, el cual permitirá exponer los principales conceptos presen-tes en el marco teórico de este trabajo.

Como puede apreciarse, la entrada del proceso es la Especificacióndel sistema, en la que se define la granularidad y la implementacióninicial del mismo (Wolf [2003], López-Vallejo and López [2003]). Lagranularidad, según Henkel and Ernst [2001], es el tamaño que será

2 De sus siglas en inglés Unified Modeling Language, Lenguaje Unificado de Modela-do.


considerado para un bloque funcional del sistema (instrucciones, blo-ques básicos, bloques de control, funciones o procedimientos). Ade-más, el sistema puede ser implementado inicialmente en softwareo hardware. Si se implementa en software (o hardware) la estrate-gia durante la partición es migrar los bloques funcionales hacia elhardware (o software) hasta que se logre encontrar la solución quecumpla con las métricas de diseño impuestas. La descripción de laimplementación inicial puede hacerse utilizando diversos lenguajes,preferiblemente uno de alto nivel, con los que el diseñador especificalas funcionalidades que tendrá el sistema; los más utilizados suelenser C, SystemC y VHDL/Verilog. Por otra parte, el resultado de esteproceso es un modelo de comportamiento, en lenguaje C por ejemplo,para los componentes que serán implementados sobre un procesadorde propósito general (Sw) y en VHDL para los que serán implemen-tados sobre coprocesadores (Hw).

A partir de la Especificación del sistema y de la Arquitectura, elsubproceso de Inicialización debe producir estimaciones de los costesde implementación de cada bloque funcional en Hw y Sw y ademásde los costes por concepto de comunicación entre los componentesimplementados en Hw y en Sw3. Por ejemplo, pudiera definirse paraun sistema, que el coste de hardware de un bloque funcional esta-rá representado por el Área que ocupa y el Tiempo de ejecución; elcoste software por el Tiempo de ejecución y la Memoria consumida,y el coste de comunicación por el tiempo que demora la transferen-cia de datos de un bloque a otro y la cantidad de recursos de Hwnecesarios para implementar el bus de comunicación. Es importanteseñalar que estas variables son definidas por el diseñador según losrequisitos impuestos. Para realizar estas estimaciones es necesario te-ner en cuenta la arquitectura donde será desplegado el sistema. Estesubproceso tiene una alta implicación en la calidad de las solucionesque se obtengan, ya que mientras más precisas sean las estimacionesrealizadas mejor se podrá explorar el espacio y evaluar las solucionesgeneradas.

Al mismo tiempo este subproceso debe hacer una representaciónde la Especificación del sistema sobre un modelo computacional [Cor-

3 Al igual que en el trabajo de Arató et al. [2005], en este trabajo se considerarán estoscostes como medidas genéricas, los cuales pueden tener asociado a su vez diferentesvariables en dependencia de los requerimientos del sistema.

2.2 partición hardware/software . estado de la cuestión 21

tés et al., 1999]. Entre los modelos más utilizados están los grafos decontrol de flujo (CFG4), grafos de flujo de datos (DFG5) y los grafosde llamadas (CG6). Muchos de estos modelos computacionales estáncondicionados por la granularidad escogida. Por ejemplo, si se selec-ciona una granularidad a nivel de funciones o procedimientos el mo-delo pudiera ser un grafo de llamada en el cual los nodos representanlas funciones del sistema y los arcos representan las llamadas entrefunciones. Es necesario resaltar la conclusión a la que llegan los auto-res en [Cortés et al., 1999], siendo esta que la selección de un modelocomputacional está condicionada por el tipo de sistema. Finalmente,el proceso de Inicialización retorna el modelo anterior anotado conlos valores estimados de cada una de las variables (area de hardware,tiempo de ejecución en Sw y en Hw, etc.).

A partir de las estimaciones obtenidas, el subproceso de Búsquedade la solución es el encargado de encontrar configuración de compo-nentes de Hw y Sw de acuerdo a los parámetros de calidad y quesatisfaga las restricciones impuestas por el diseñador. Las actividadesinternas que se ejecutarán en este proceso están en dependencia dela forma en que será implementado, ya sea utilizando programacióndinámica, algoritmos metaheurísticos, sistemas expertos o cualquierotro algoritmo o estrategia.

2.2 soluciones al problema de la partición hardware/-software . estado de la cuestión

Existen diversas propuestas para abordar el problema HSP, las cualessegún la clasificación dada por Niemann [1998], se pueden caracteri-zar por diversos criterios tales como:

• Complejidad del problema HSP tratado, por ejemplo, si la ar-quitectura de destino está predefinida o se optimiza durante elproceso.

4 De sus siglas en inglés, Control Flow Graph, Grafo de Control de Flujo.5 De sus siglas en inglés, Data Flow Graph, Grafo de Flujo de Datos.6 De sus siglas en inglés, Call Graph, Grafo de Llamadas.


• La arquitectura de destino que es soportada, por ejemplo, unúnico procesador o múltiples procesadores, dispositivo de hard-ware basado en FPGA7 o en ASIC8.

• Dominio de la aplicación que será particionada, por ejemplo,sistemas donde el flujo de datos sea significativo o donde pre-dominen los ciclos de control.

• La función objetivo utilizada, por ejemplo minimizar el área dehardware ocupada por el diseño bajo restricciones de tiempo deejecución, maximizar el rendimiento con restricciones sobre elárea de hardware ocupada por el diseño, etc.

• La estrategia de búsqueda, la cual puede ser heurística, proba-bilística o exacta, comparadas a partir del tiempo de ejecucióny la calidad de los resultados.

• Aspectos a tener en cuenta durante la optimización, por ejemplosi se tienen en cuenta los costes de comunicación, los recursoscompartidos entre los coprocesadores de hardware.

• La granularidad utilizada en el sistema inicial para estimar loscostes, por ejemplo funciones, bloques básicos o sentencias.

• Los métodos de estimación, es decir si se calculan con herra-mientas especiales o si se analizan los resultados de herramien-tas de compilación o síntesis.

A partir de esta clasificación y de acuerdo con los problemas identi-ficados en el capítulo anterior, las propuestas de solución al problemaHSP, presentadas en esta sección, se clasificarán según dos criterios(figura 4): el tipo de métricas utilizadas y el tipo de estrategia emplea-da para resolver el problema.

Las métricas permitirán evaluar la calidad de una configuracióndeterminada y por consiguiente compararla con otras configuracio-nes, mientras que los algoritmos permitirán explorar el espacio desoluciones para buscar las configuraciones que cumpla con los pa-rámetros establecidos por el diseñador. La correcta combinación de

7 De sus siglas en inglés, Field Programmable Gate Array.8 De sus siglas en inglés, Application-Specific Integrated Circuit.


ambos componentes permitirá encontrar la configuración que mejorevaluación obtenga para dar solución a una instancia del problemaHSP en particular. En las secciones siguientes se describen las princi-pales propuestas agrupadas según la clasificación anterior.

Partición Hardware/Software

Métricas Estrategias

Primitivas Compuestas Exactas Aproximadas

Figura 4 Clasificación de las propuestas de partición de componentes deHardware/Software.

2.2.1 Métricas de diseño empleadas en los modelos de Partición Hardwa-re/Software

Un elemento importante dentro del proceso de búsqueda es la deci-sión de qué características se van a medir para evaluar el diseño y/opara acotar la solución a un entorno de despliegue determinado. Lasdiferentes propuestas de modelos HSP se diferencian en las métri-cas que tienen en cuenta y en la forma en que estas se combinan eintegran en el modelo.

Diferentes trabajos, [Arató et al., 2005], [Amin et al., 2007], clasifi-can las métricas en tres grupos: Costes de Hardware (CHW), Costesde Software (CSW) y Costes de comunicación (CCM) planteando queesta clasificación no impone restricciones semánticas a los términos,es decir, estos pueden ser asociados a cualquier métrica según losintereses del diseñador. En estos trabajos se realiza un estudio formu-lando el problema de diferentes formas, empleando diferentes métri-cas y combinando otras mediante una suma ponderada. El problemade esta clasificación radica en que no da un soporte semántico paraotras formas de combinar las métricas, por ejemplo la multiplicacióndel tiempo de ejecución con el área de hardware ocupada. En este


caso, el tiempo de ejecución es complicado ubicarlo en una catego-ría ya que existen componentes del sistema ejecutándose en ambasplataformas, además si se deseara considerar el tiempo dedicado ala comunicación entre ambas plataformas como parte del tiempo decomunicación también sería complejo de categorizar. Por su parte,el área de hardware ocupada evidentemente pertenece al Costo dehardware, aunque esta tiene también una representación como costode comunicación ya que las interfaces de comunicación ocupan es-pacio de hardware en el diseño. Este ejemplo pone de manifiesto lascarencias semánticas de la taxonomía propuesta.

Teniendo en cuenta lo anterior, en el presente trabajo se propone laclasificación de las métricas entre Primitivas y Compuestas (figura 4).Al considerar estos dos grupos (primitivas y compuestas) no solo esposible clasificar las propuestas existentes, sino que permite conside-rar las métricas surgidas de la combinación de primitivas mediantecualquier operador matemático.

Métricas primitivas son aquellas métricas básicas que se definen a simismas, es decir no se combinan con otras métricas de forma directapara poder definirse. En este grupo se encuentran las métricas más co-munes que refiere la literatura, [Vahid and Givargis, 2002], tales como:Tamaño, Rendimiento, Potencia, Flexibilidad, etc. En esta categoríase encuentran los trabajos de Schwiegershausen et al. [1996], Vahid[1997], Wiangtong et al. [2002], Adhipathi [2004], Jigang and Srikant-han [2006b,a], Galanis et al. [2006], Kim and Kim [2006], Zhang et al.[2007], Göhringer et al. [2010], Beux et al. [2010], Abdelhalim andHabib [2011], Han et al. [2013], Nath and Datta [2014].

Además, existen trabajos que tienen en cuenta, para calcular elTiempo de ejecución, el Tiempo de comunicación entre los nodos delsistema, ya sea entre nodos implementados en plataformas diferentes(Hw/Sw) o entre nodos implementados sobre la misma plataforma(Hw/Hw o Sw/Sw). En este caso se encuentran los trabajos de Ernstet al. [1993], Eles et al. [1997], Madsen et al. [1997], Kalavade and Lee[1997], Jigang et al. [2008b,a], Beux et al. [2010], Han et al. [2013].

Es posible encontrar también propuestas que utilizan variacionesde las métricas anteriores, por ejemplo en [Madsen et al., 1997], [Hen-kel and Ernst, 2001], los autores emplean la Aceleración (variante deltiempo de ejecución) que se produce en el sistema por mover un nodo


hacia el Hw. En la propuesta de Gupta and De Micheli [1993] se tieneen cuenta la utilización del bus y del procesador (tiempo de comu-nicación y ejecución), garantizando que la solución cumpla con unvalor de tiempo establecido. Mientras que la propuesta de Beux et al.[2010], utiliza el rendimiento medido como la cantidad de ejecucionesque puede se pueden realizar en un tiempo dado.

Métricas compuestas son aquellas que surgen por la combinación dedos o más métricas primitivas o compuestas, lo cual en muchos ca-sos permite tratar el problema HSP como un problema multiobjetivo,aunque no sea multiobjetivo puro. Esto significa que existen más deun objetivo a optimizar y que incluso pueden ser contrapuestos. Elaporte de tratar el problema de esta forma es que la solución encon-trada tendrá implícita un balance entre las métricas que se combinan.Nath and Datta [2014] realizan un estudio para determinar de lasmétricas que utiliza cuáles representan términos contrapuestos. Losresultados de este estudio muestran que para el modelo que utiliza,el Área de hardware se contrapone al Tiempo de ejecución y a lamemoria consumida; mientras que la Potencia se contrapone con laMemoria y con el Tiempo de ejecución.

Entre las propuestas que utilizan este enfoque se encuentra la dePurnaprajna et al. [2007], donde emplean las métricas de Tiempo deejecución y Potencia combinadas mediante la operación de multiplica-ción9; además también se tienen en cuenta las demoras por conceptode comunicación y el Área de Hw ocupada. Bhattacharya et al. [2008]combina el Área de Hw ocupada y el Tiempo de ejecución por cadatarea10, mediante la operación de multiplicación. Por su parte, Srini-vasan et al. [1998] combinan en la función objetivo las métricas deÁrea de Hw y Tiempo de ejecución mediante la operación de suma,considerando además el coste de tiempo por concepto de comuni-cación. La combinación mediante esta operación permite además de

9 El consumo de potencia es máximo cuando todas las tareas son implementadas enHw, lo cual entraría en contradicción pues en este mismo caso el tiempo de ejecuciónsería mínimo.

10 La contraposición de estos dos objetivos se debe a que para garantizar un pococonsumo de Área de Hw es necesario implementar la mayor parte del sistema enprocesadores de propósito general, lo cual implicaría un aumento en el Tiempo deejecución.


forma más sencilla ponderar cada término según los propósitos deldiseñador.

En los trabajos de Lee et al. [2007c], Abdelhalim and Habib [2011],Nath and Datta [2014], los autores utilizan como función objetivo lasuma ponderada del Área de Hw, tiempo de ejecución, Memoria yPotencia consumida. Además estos autores utilizan penalizacionessobre estos elementos si incumplen con un determinado valor de res-tricción.

Los trabajos de López et al. [1998] y López Vallejo et al. [1999],además de utilizar métricas primitivas y de considerar el tiempo decomunicación, tienen la particularidad de modelar las métricas comomagnitudes difusas; esto se debe a que en muchos casos estos valoresson dependientes del criterio del diseñador y por tanto muchas vecesson imprecisos.

Es importante señalar que la inclusión de más de dos métricas enel proceso de búsqueda eleva la complejidad del mismo tal y comose explicó en la introducción de este trabajo; pero a su vez permiteobtener soluciones con mejor calidad y más cercanas a la plataformadonde será desplegado.

En la tabla 1 se muestra un resumen de las métricas empleadasen las propuestas descritas anteriormente. Para facilitar el análisis, sehizo una generalización de aquellos modelos que emplean las mismasmétricas. Las métricas incluidas en la tabla son: A (Área de hardware),T (Tiempo de ejecución), Tc (Tiempo de comunicación), P (Potencia),M (Memoria), S (Aceleración), R (Rendimiento), Ub (Utilización delbus) y Up (Utilización del procesador) y F (Flexibilidad).

Como puede observarse existen métricas primitivas que están pre-sentes en más de un modelo, tales son los casos del Área de Hw,Tiempo de ejecución y Tiempo de comunicación; mientras que existeuna determinada tendencia a utilizar variaciones de estas aunque enmenor medida. Es posible apreciar también, que existen propuestasque emplean métricas compuestas en las cuales se combinan primiti-vas contrapuestas, lo cual permite evaluar las soluciones teniendo encuenta objetivos contrapuestos.

Finalmente se hace necesario destacar que en todos los modelosse integran, al menos dos o más métricas primitivas o compuestas.Considerar la integración de las métricas en un mismo modelo es un


aspecto vital, ya que de esta forma es posible contar con una caracte-rización más completa del sistema que se está diseñando.

28

pa

rt

ic

ió

nh

ar

dw

ar

e/s

of

tw

ar

ed

es

is

te

ma

se

mb

eb

id

os

ModelosMétricas primitivas Métricas compuestas

A T Tc M P S R F Ub Up T ∗ P A ∗ T A+ T A+ T + P+M

1 X X

2 X X X

3 X X X

4 X X X X

5 X X X

6 X X X

7 X X X X

8 X X

9 X X X

10 X X X

11 X

12 X X

13 X

Tabla 1 Resumen de las métricas utilizadas en los modelos de Partición Hardware/Software.


2.2.2 Estrategias de búsqueda aplicadas en la solución del problema

Una vez definidas las métricas y el modelo que guiarán el procesode búsqueda es necesario definir la estrategia o el algoritmo que seencargará de recorrer el espacio de búsqueda para encontrar la me-jor solución para la instancia del problema HSP. En esta sección sedescribirán las propuestas desde el punto de vista algorítmico.

Al ser el problema HSP un problema de optimización, la taxonomíapresentada en esta sección está basada en la presentada por Talbi[2009] para la clasificación de algoritmos de optimización. La figura5 presenta una vista más detallada, de la clasificación esbozada en lafigura 4, en cuanto al componente algorítmico. Las diferencias con lataxonomía de Talbi, radican en que el objetivo de la presentada aquíno es clasificar los algoritmos de optimización, sino crear un espacioen que sea posible catalogar los trabajos existentes, a fin de establecerlos aspectos relevantes y las carencias de las propuestas.

Como puede apreciarse existen dos tipos de estrategias, las basadasen algoritmos exactos y las basadas en aproximaciones. La primerade estas, como su nombre indica, incluye algoritmos que brindarán lasolución óptima al problema HSP. Entre las propuestas que utilizanalgoritmos exactos se encuentra aquellas que utilizan algoritmos deprogramación dinámica o alguna variación de estos, tales son los ca-sos de Madsen et al. [1997], Jigang and Srikanthan [2006a,b], Jiganget al. [2008b].

Existen otras propuestas que emplean programación lineal [Aratóet al., 2003], [Bhattacharya et al., 2008]; mientras que en el trabajo deSchwiegershausen et al. [1996] emplean Programación Lineal EnteraMezclada (MILP11), junto con una estrategia de branch-and-bound pa-ra obtener la solución. Por último en Arató et al. [2005], los autoresemplean un algoritmo exacto basado en el algoritmo de corte míni-mo.

El principal inconveniente que presentan estas estrategias es que eltiempo de ejecución crece exponencialmente según el tamaño de lainstancia del problema que se esté resolviendo.

Producto de este inconveniente, se desarrolla la segunda estrategia,basada en algoritmos aproximados. Esta estrategia está fundamenta-

11 de sus siglas en inglés Mixer Integer Linear Programming


Basadas en

Programación

dinámica

Basadas en

Programación

lineal

Basadas en

Heurísticas

específicas

Basadas en

Metaheurísticas

Basadas en

Soft

computing

Partición Hardware/Software

Métricas

EstrategiasPrimitivas Compuestas

Exactas Aproximadas

Figura 5 Estrategias empleadas en la solución del problema de ParticiónHardware/Software.

da en las ideas planteadas por Zadeh [1994], de que la satisfacciónes mejor que la optimización, o sea si no es posible dar la soluciónóptima a un problema, es mejor brindar una solución que al menossatisfaga al usuario de alguna manera. Además, trata de emular dealguna manera el comportamiento típico del diseñador de sistemasembebidos. De esta forma, se pretende que la herramienta sea capazde identificar y usar de forma implícita el conocimiento del diseñador.Es importante destacar que esta clasificación no se limita solamentea las estrategias presentadas, ya que es posible la inclusion de otrasque permitan resolver el problema HSP.

Dentro de esta categoría se identifican tres tipos principales: losbasados en algoritmos metaheurísticos, en heurísticas específicas yen métodos de soft computing.

Los algoritmos metaheurísticos son algoritmos de propósito gene-ral, es decir no tienen conocimiento a priori del problema a tratar.En el caso de las estrategias basadas en algoritmos metaheurísticos,existen autores que utilizan algoritmos mono-objetivos y otros queutilizan algoritmos multi-objetivos. La diferencia fundamental radicaque los primero evalúan la solución teniendo en cuenta una función


objetivo, mientras que los segundos tienen en cuenta más de una fun-ción objetivo para guiar la búsqueda.

Entre las propuestas que emplean los primeros de estos algoritmosse encuentran:

• Estrategia voraz o variaciones de esta, [Vahid and Le, 1997], [Ad-hipathi, 2004].

• BT12, [Eles et al., 1997], [Wiangtong et al., 2002].

• BA13, [Vahid and Le, 1997].

• RS14, [Ernst et al., 1993], [Eles et al., 1997], [Vahid and Le, 1997],[Srinivasan et al., 1998], [Henkel and Ernst, 2001], [Wiangtonget al., 2002], [López-Vallejo and López, 2003].

• AG15, [Srinivasan et al., 1998], [Wiangtong et al., 2002], [Aratóet al., 2003], [Arató et al., 2005], [Purnaprajna et al., 2007], [Aminet al., 2007], [Bhattacharya et al., 2008].

• PSO16, [Amin et al., 2007], [Bhattacharya et al., 2008], [Tonget al., 2008], [Abdelhalim and Habib, 2011].

• ACO17, [Bhattacharya et al., 2008].

• EE18, [Zhang et al., 2007].

• AJ19, [Vahid, 1997], [López-Vallejo and López, 2003], [Göhringeret al., 2010].

• MG20, [Gupta and De Micheli, 1993].

12 Algoritmo Búsqueda Tabú13 Algoritmo Búsqueda Aleatoria14 Algoritmo Recocido Simulado15 Algoritmos Genéticos16 De sus siglas en inglés Particle Swarm Optimization, Optimización basada en En-

jambre de Partículas17 De sus siglas en inglés Ant Colony Optimization, Optimización basada en Colonia

de Hormigas18 Algoritmo Estrategia Evolutiva19 Algoritmo Agrupamiento Jerárquico20 Algoritmo Migración de Grupos


Por otra parte, entre las propuestas que utilizan estrategias multi-objetivos se encuentran:

• NSGA21, una de las variantes del Algoritmo Genético para pro-blemas multi-objetivo [Lu et al., 2009, Beux et al., 2010, Jaga-deeswari and Bhuvaneswari, 2011].

• Algoritmo Inmune basado en el frente de Pareto, [Liu and Li,2009].

• WSGA22, variante el AG clásico que permite tratar con proble-mas de optimización multi-objetivo considerando los objetivoscomo una suma ponderada. Este algoritmo es utilizado por [Ja-gadeeswari and Bhuvaneswari, 2011].

• Algoritmo Genético Multi-Objetivo codificado binario, utilizadoen [Nath and Datta, 2014].

• MOPSO-CD23, variante de algoritmo de enjambre de partículas,[Jagadeeswari and Bhuvaneswari, 2011].

Por su parte las basadas en algoritmos heurísticos de propósitoespecífico están diseñados para resolver un problema o instancia es-pecífica. La principal ventaja de estos algoritmos radica precisamenteen el conocimiento que tienen del problema, lo cual puede conducir aencontrar mejores soluciones en un menor tiempo, que si fuera utili-zado un metaheurístico. Entre las propuestas que utilizan este tipo dealgoritmos se encuentran las de Arató et al. [2005], Jigang and Srikant-han [2006a] y Jigang et al. [2008a] y Han et al. [2013]. Además Eleset al. [1997], López-Vallejo and López [2003] y Arató et al. [2005] em-plean el algoritmo heurístico KL24(min-cut) o en Kim and Kim [2006]

21 De sus siglas en inglés, Non-dominated Sorting Genetic Algorithm, Algoritmo Ge-nético de Ordenamiento No dominado.

22 De sus siglas en inglés, Weighted Sum Genetic Algorithm, Algoritmo Genético basa-do en Suma Ponderada.

23 De sus siglas en inglés, Multi-Objective Particle Swarm Optimization using Crow-ding Distance, Optimización basada en Enjambre de Partículas Multi-Objetivo usan-do la Distancia de Hacinamiento.

24 Algoritmo Kernighan/Lin


y Vahid [1997] y Vahid and Le [1997] extensiones o variaciones de es-te. Kalavade and Lee [1997] utilizan un algoritmo heurístico llamadoGCLP 25 y a partir de este proponen uno llamado MIBS.

Por último, las basadas en métodos de soft computing, tiene susfundamentos en el concepto de Soft computing. Soft computing, segúnVerdegay et al. [2008], no es más que la unión de varios métodos quetienen como principal objetivo tratar con la imprecisión e incertidum-bre de problemas reales, de forma tal que se garanticen soluciones debajo coste. Los elementos que la componen son: los modelos probabi-lísticos, lógica difusa, redes neuronales y algoritmos metaheurísticos.

En este caso se encuentra la propuesta de Huang and Kim [2007],donde los autores utilizan un sistema que combina la lógica difusacon las redes neuronales. Por último en Zhang et al. [2007] utilizanun Algoritmo Evolutivo de Selección Negativa (ENSA); el cual estáinspirado en los Sistemas Inmunes Artificiales (AIS).

Teniendo en cuenta el teorema planteado por Wolpert and Ma-cready [1996] el cual se conoce como No Free Lunch (NFL)26, no existeun algoritmo que sea mejor que otro para todos los problemas. Lasconsecuencias de este teorema son que para decir que un algoritmo esmejor que otro para un problema, se debe haber experimentado convarios algoritmos a fin de fundamentar un criterio de preferencia.

Si bien los algoritmos exactos llegan a obtener la solución óptima,puede observarse que existe una tendencia a la utilización de algo-ritmos aproximados. Un elemento importante a tener en cuenta, esque para instancias de problemas grandes los algoritmos exactos al-canzan un tiempo de respuesta muy alto en comparación con los heu-rísticos, lo cual constituye una desventaja. Es decir, en determinadassituaciones los algoritmos exactos pueden no ser idóneos en la prácti-ca. Mientras que los algoritmos aproximados ofrecen soluciones muycercanas a la óptima, con un tiempo de ejecución menor para ins-tancias de problemas de gran tamaño. No obstante, los exactos sonutilizados, en la mayoría de los casos, como referentes para compararlas soluciones obtenidas por los algoritmos aproximados.

De acuerdo con lo anterior los algoritmos más utilizados son losaproximados, empleando con mayor frecuencia los metaheurísticos y

25 De sus siglas en inglés Global Criticaly/Local Phase26 La traducción al castellano parece carecer de lógica en el contexto de este trabajo por

lo que se asume el significado explicado arriba.


dentro de estos el Recocido simulado y Algoritmos Genéticos. Ade-más se aprecia en alguna medida la disposición a definir o adaptarheurísticas específicas para tratar el problema. Este algoritmo ademásde ser utilizado como único algoritmo para generar las soluciones, enmuchas de las propuestas se sigue como estrategia su empleo pa-ra generar la solución inicial a partir de la cual los metaheurísticoscomenzarán la búsqueda. Esta estrategia permite reducir de ciertamanera el espacio de soluciones y dirigir la búsqueda del metaheu-rístico hacia una parte del espacio donde se encuentran las mejoressoluciones.

A pesar de las observaciones anteriores sobre los algoritmos uti-lizados, determinar cuál de ellos es mejor es una decisión complejade tomar, pues los resultados no se obtuvieron sobre el mismo ban-co de pruebas ni sobre la misma instancia del problema HSP. En lassecciones siguientes se darán algunos aspectos que complementaránesta afirmación, a fin de brindar una mejor idea de la complejidadpresente en esta decisión.

2.3 tendencias en la validación de las propuestas

Independientemente de las métricas utilizadas o la estrategia seleccio-nada, es necesario someter las propuestas a un proceso de validaciónpara determinar si cumplen con los requisitos para los cuales fue dise-ñada. A partir de estas necesidades se han desarrollado un conjuntode estrategias mediante las cuales es posible decidir si una determi-nada propuesta es viable o no. En aras de establecer una clasificacióncon la cual sea posible agrupar los trabajos relacionados e identificarfortalezas y debilidades, en la figura 6 se presenta un diagrama dedominio utilizando UML, en el cual es posible apreciar no solo lostipos de validaciones que se pueden realizar, sino su relación con lasaplicaciones empleadas con más frecuencia para tales propósitos.

2.3 tendencias en la validación de las propuestas 35

Validación

Pruebas Comparaciones

Aplicación

Simulada Real

Propuesta

Métricas Estrategiassometidas a

utiliza

mediante

Experimento

Umbrales

Parámetros

ejecuta

Iteraciones

Ejecucionesestablece

Figura 6 Componentes presentes en la validación de propuestas de Parti-ción Hardware/Software.

Para llevar a cabo la validación es necesario ejecutar un conjuntode experimentos en los cuales se establecen diferentes característicasque se desean medir o controlar; tales son los casos de los parámetrosde los algoritmos, la cantidad de soluciones que generará (definiendola cantidad de ejecuciones e iteraciones) y los valores aceptados paracada una de las métricas.

El objetivo principal de la validación es determinar, a partir de losexperimentos ya definidos y de un conjunto de aplicaciones, el rendi-miento y la efectividad de la propuesta; ya sea evaluando empírica-mente la calidad de las soluciones generadas a partir de un conjuntode pruebas o comparando varios algoritmos para un mismo modelo.El rendimiento está dado por el tiempo necesario para producir unarespuesta efectiva; por su parte la efectividad está dada por la calidadde las soluciones generadas, de forma tal que estas cumplan con losrequisitos establecidos.


A continuación, en las secciones siguientes, se presentarán las apli-caciones empleadas en la validación (sección 2.3.1), así como las es-trategias empleadas para validar las propuestas (sección 2.3.2).

2.3.1 Aplicaciones empleadas para validar las propuestas

Para ejecutar los experimentos es necesario decidir qué tipo de apli-cación utilizar de acuerdo con los propósitos de la validación. Comose aprecia en la figura 6 existen dos variantes, utilizar aplicacionessimuladas o aplicaciones reales.

La primera de estas variantes consiste en generar grafos de controlde flujo o grafos de llamadas (según la granularidad definida), loscuales representan la estructura de una aplicación hipotética. Para ca-da uno de los nodos de estos grafos se generan de forma aleatoriavalores que representan cada uno de los costes definidos. En este ca-so se encuentran las propuestas de: Eles et al. [1997], Vahid and Le[1997], Kalavade and Lee [1997], López Vallejo et al. [1999], Srinivasanet al. [1998], Wiangtong et al. [2002], Arató et al. [2003], Arató et al.[2005], Jigang et al. [2008b,a], Kim and Kim [2006], Jigang and Sri-kanthan [2006a], Purnaprajna et al. [2007], Zhang et al. [2007], Aminet al. [2007].

Estas propuestas, necesitan una herramienta computacional paragenerar el grafo y simular los valores de los costes. Una de las herra-mientas más utilizadas es la propuesta por Dick et al. [1998], llamadaTGFF27, la cual permite generar grafos con diferentes estructuras, can-tidad de nodos, arcos y valores para cada uno de los costes utilizados.

En la variante de aplicaciones reales, son utilizadas aplicacionesque con frecuencia son implementadas en sistemas embebidos, porejemplo: procesamiento digital de señales, criptografía, comunicacio-nes, entre otras. Para esta variante es imprescindible utilizar herra-mientas que implementen el Proceso de inicialización descrito en lasección 2.1, figura 3. Con estas herramientas se estimarán los costesasociados al Hw, Sw y comunicaciones de las variables involucradas.

Entre las propuestas que utilizan aplicaciones vinculadas con las co-municaciones, cabe destacar el caso de Gupta and De Micheli [1993],Eles et al. [1997], Vahid and Le [1997] que implementan un coproce-

27 De sus siglas en inglés, Task Graph For Free.


sador Ethernet. Además Vahid and Le [1997] emplean una aplicaciónpara contestadora telefónica. Por su parte Kalavade and Lee [1997]implementan un modem y un simulador de canales de teléfono y Ad-hipathi [2004] desarrolla sus experimentos con una aplicación GSM28.Por último en el trabajo de Arató et al. [2005] se implementan los al-goritmos patricia y dijkstra los cuales se encuentran dentro del bancode prueba MiBench [Guthaus et al., 2001].

Otro grupo de propuestas por su parte emplean algoritmos y apli-caciones del campo del procesamiento digital de señales, [Henkeland Ernst, 2001]. También Ernst et al. [1993], Srinivasan et al. [1998],Wiangtong et al. [2002], López-Vallejo and López [2003] emplean losalgoritmos DCT29, DCT16 y FFT30; mientras que Arató et al. [2005]implementa el algoritmo clustering presente en MiBench.

Las aplicaciones de procesamiento de video digital también sonutilizadas con propósitos de validación, en este caso se encuentrala propuesta de Schwiegershausen et al. [1996] que realiza las prue-bas sobre un esquema de codificación de video híbrido denominadoH.261. Kim and Kim [2006] utilizan un video teléfono y un repro-ductor de video y Vahid and Le [1997] un procesador de televisióninteractiva. Además en [Ernst et al., 1993], los autores utilizan bancosde prueba con aplicaciones para el filtrado de imágenes, Smooth ypara el procesamiento de video 3d.

En el caso del trabajo de Lee et al. [2007a], los autores utilizan unsistema de codificación de imágenes JPEG. La principal ventaja deeste trabajo radica en que los autores proveen todas las estimacionesde los costes empleados por el proceso de búsqueda para evaluarlas soluciones. Esta aplicación ha sido posteriormente utilizada enlos trabajos de Lee et al. [2007d,b,c], Abdelhalim and Habib [2011],Nath and Datta [2014], para evaluar sus propuestas y sobre todo pararealizar comparaciones entre las propuestas.

Existen propuestas, en menor medida, que basan su estrategia devalidación en algoritmos criptográficos, tal es el caso de Arató et al.

28 De sus siglas en inglés, Global System for Mobile Communications, Sistema Globalpara Comunicaciones Móviles

29 De sus siglas en inglés, De sus siglas en inglés, Discrete Cosine Transform, Transfor-mada Discreta del Coseno.

30 De sus siglas en inglés, Fast Fourier Transform, Transformada Rápida de Fourier.Este algoritmo permite resolver la Transformada Discreta de Fourier.


[2003], Bhattacharya et al. [2008] que utilizan el IDEA, RC6 y MARS.En [Arató et al., 2005] los autores utilizan, además del RC6, el algorit-mo CRC32; ambos contenidos dentro del banco de prueba MiBench.

Existen otras propuestas, como las de Srinivasan et al. [1998], Wiang-tong et al. [2002], López-Vallejo and López [2003], que utilizan las apli-caciones LU, Laplace, Mean, Reg. Por su parte, Vahid and Le [1997]utilizan para validar su propuesta una aplicación de un instrumen-to médico de medición. Además en [Eles et al., 1997], los autoreshacen una partición de las funciones de operación y mantenimientocorrespondientes a la capa de protocolo ATM. Finalmente, Ernst et al.[1993] utilizan para probar el comportamiento del algoritmo bancosde prueba con aplicaciones reales (Simp, Fft, Diesel).

De acuerdo con lo comentado hasta ahora, a modo de resumen esposible decir que existen propuestas que emplean solo aplicacionesreales y otras solo simuladas; mientras que en otras se mezclan ambosenfoques. En esta última variante las simulaciones son utilizadas paraafinar o ajustar los parámetros de los algoritmos y validar el modelopropuesto y las aplicaciones se emplean como casos de estudios.

Con respecto a la utilización de aplicaciones reales cabe decir que,según se plantea en Vahid [1997], los procesos de estimación son com-plejos de resolver ya que se requiere, entre otras cosas, de la unión devarias herramientas tales como: profilers, sintetizadores y estimadores;dentro de un entorno de desarrollo de sistemas embebidos. Es válidoaclarar que las dos primeras de estas sí están incluidas en los entor-nos de desarrollo y presentan un determinado nivel de desarrollo,pero las de estimación no están lo suficientemente difundidas. Otroaspecto importante que hace de la estimación un proceso complejo esque varía según la plataforma de hardware que se utilice y según lasvariables que se midan en cada modelo.

2.3.2 Estrategias para la validación de las propuestas

A partir de los experimentos definidos y de la selección de las aplica-ciones a emplear, es necesario definir de qué forma será validado elmodelo HSP propuesto. En este sentido existen dos tipos, tal y comose aprecia en la figura 6, el desarrollo de pruebas, la comparación oambas.


El término Prueba se refiere al tipo de validación a la que se someteuna propuesta que tiene como objetivo introducir un nuevo modeloo algoritmo para resolver el problema HSP. Estas pruebas están guia-das por el diseño de un conjunto de experimentos. En el diseño deestos experimentos se busca establecer diferentes valores en sus ca-racterísticas (ver figura 6), para de esta forma buscar los valores delos parámetros del algoritmo que permitan obtener soluciones conbuena calidad. Además a partir de estos experimentos se busca en-contrar los umbrales de los valores de las métricas definidas. Sobreesta idea están las propuestas de: Ernst et al. [1993], Gupta and De Mi-cheli [1993], Henkel and Ernst [2001], Adhipathi [2004], Kim and Kim[2006], Purnaprajna et al. [2007].

El propósito de la comparación, como su nombre lo sugiere, esestablecer referentes comparativos según las medidas que se deseen.Para realizar una comparativa válida, es necesario utilizar siempre elmismo modelo sobre el mismo banco de pruebas y en caso necesariocontar con la información que permita reproducir los experimentosdescritos en otras propuestas.

Entre las comparaciones reportadas, destaca la realizada por Sch-wiegershausen et al. [1996], donde se compara la solución obtenida(Hw/Sw) con una solución puramente Sw. Es conocido que la solu-ción puramente en Sw tiene un mínimo de área de Hw ocupada perosu tiempo de respuesta no es el mejor, de esta manera al compararuna solución híbrida es posible determinar en qué medida se muevenlas métricas.

También es posible encontrar propuestas que plantean una compa-ración con propuestas de otros autores o propias, pero siempre te-niendo en cuenta las condiciones enunciadas anteriormente. En estecaso se encuentra el trabajo de Jigang and Srikanthan [2006b], dondese realiza una modificación al algoritmo propuesto por Madsen et al.[1997], además en [Jigang et al., 2008b] extienden el modelo propues-to en [Jigang and Srikanthan, 2006b]. Por último, en [Jigang et al.,2008a] comparan el algoritmo propuesto con los algoritmos utiliza-dos por Wiangtong et al. [2002], empleando los mismos valores deparámetros.

No obstante, las propuestas más comunes, plantean una compara-ción de varios algoritmos con los mismos experimentos y aplicacio-


nes, tales son los casos de: Vahid and Le [1997], Eles et al. [1997],López-Vallejo and López [2003], Srinivasan et al. [1998], Wiangtonget al. [2002], Arató et al. [2005], Zhang et al. [2007], Amin et al. [2007].Además en las propuestas de Kalavade and Lee [1997], Arató et al.[2003], Bhattacharya et al. [2008], Jigang and Srikanthan [2006a] seutilizan algoritmos exactos como referentes comparativos para losheurísticos; de esta forma es posible evaluar cuan cercas o alejadasse encuentran del óptimo las soluciones generadas por el heurístico.

Tal y como se adelantaba en el final de la sección 2.2.2, la decisiónsobre qué algoritmo es mejor, es una decisión compleja. Esto se debea que en las comparaciones son utilizados los algoritmos más popu-lares, por decirlo de alguna manera, mientras que existen algoritmosque no son empleados y que han obtenido buenos resultados en otrosproblemas, tal y como se expone en [Rosete-Suárez et al., 1999a,b].Por otra parte si se quisiera tomar la decisión a partir de unir todoslos trabajos y sacar el mejor algoritmo, se estaría cometiendo un errorpues no todas las propuestas utilizan el mismo modelo y el mismojuego de datos.

Por último resaltar que estos dos tipos de validaciones tambiénpueden complementarse, es decir es posible utilizar las Pruebas paraafinar una determinada propuesta y luego comparar sus resultadoscon otras propuestas. De esta forma se estarían aprovechando las bon-dades de los dos tipos de validación.

2.4 conclusiones

Al término de este capítulo se puede concluir de manera general que:

1. Modelar la partición de componentes Hw/Sw de Sistemas Em-bebidos con un enfoque procedural permite identificar de formaclara las tareas y recursos implicados en la solución al problemaHSP.

2. El proceso de inicialización es clave dentro del HSP pues influyeen la exactitud del proceso de búsqueda. Este proceso según sepudo apreciar es complejo de resolver ya que en primer lugar serequiere de la combinación de varias herramientas en un mismo

2.4 conclusiones 41

entorno de desarrollo y en segundo lugar porque este procesodepende de las arquitectura de Hw que se utilicen.

En cuanto a la utilización de las métricas en los modelos HSP, sepuede concluir que:

1. Las métricas más empleadas en los modelos HSP son: Área deHw, Sw, Costo de comunicación, Tiempo de ejecución, Consu-mo de potencia.

2. La combinación de más de una métrica permite optimizar mé-tricas contrapuestas garantizando un equilibrio adecuado.

3. La integración de varias métricas de diseño en un mismo mode-lo HSP permite resolver el problema de forma más cercana a larealidad.

En cuanto a los algoritmos utilizados en los modelos HSP, se puedeconcluir que:

1. Los algoritmos heurísticos alcanzan soluciones muy cercanasa las obtenidas por los algoritmos exactos, pero en un menortiempo de ejecución.

2. Los algoritmos metaheurísticos RS y AG, son los que con másfrecuencia se emplean para resolver el problema HSP.

3. Decidir qué algoritmo es mejor que otro es una tarea compleja,por lo que es necesario comparar varios algoritmos sobre unamisma instancia del problema HSP para determinar cuál es elque obtiene mejores soluciones en casos particulares.

En cuanto a las estrategias de validación:

1. En la mayoría de los casos la validación consiste en determi-nar cuál es el rendimiento del algoritmo y la efectividad de lasolución propuesta.

2. La estrategia de validación más común consiste en combinarlas pruebas sobre cada uno de los algoritmos para afinar losparámetros con la comparación de estos algoritmos entre sí.


3. El uso de grafos simulados permite validar las propuestas sinnecesidad de contar con herramientas de estimación.

4. Para comparar los algoritmos utilizados en diferentes propues-tas, es deseables que estas coincidan en el modelo utilizado yen los benchmarks, a fin de que la comparación tenga utilidad.

3M O D E L O D E P R O C E S O S PA R A L A PA RT I C I Ó NH A R D WA R E / S O F T WA R E

Según lo planteado en el capítulo anterior, un modelo HSP debe in-tegrar y combinar varias métricas de diseño con el fin de caracterizarde forma más precisa el sistema que se implementará. Además, debetener en cuenta el carácter impreciso implícito en la medición de es-tas métricas. Estas características permitirán automatizar el procesode una forma más cercana a como el diseñador concibe y ejecuta, enla práctica, el diseño de un sistema embebido.

En este capítulo se define un modelo HSP genérico que tiene encuenta estas consideraciones. En primer lugar propone optimizar lacombinación de cualquier métrica utilizando cualquier operador. Ensegundo lugar, permite la integración de varias métricas bajo el mis-mo modelo de optimización. Mientras que la imprecision en la es-timación de las métricas se tiene en cuenta al considerar cada unade ellas como conjuntos difusos, lo cual además brinda cierto gradode flexibilidad al modelo a la hora de decidir qué solución aceptary cuáles no; de acuerdo con los requisitos del sistema que se estédiseñando.

El modelo presentado en este capítulo es definido de la mismaforma en que fue explicado el proceso genérico en la sección 2.1. Deacuerdo con la clasificación dada en la sección 2.2, el modelo propues-to está basado en la integración de métricas primitivas y compuestas.Además emplea una estrategia basada en Soft computing, al combinarlógica difusa en el modelado de las variables y algoritmos metaheu-rísticos para buscar la solución al problema HSP. El modelo llevaimplícito la definición de: la granularidad de la especificación inicial,el modelo computacional utilizado, las variables asociadas a cada ele-

43

44 modelo de procesos para la partición hardware/software

mento de este, codificación de la solución, dominio de las variables yla función de coste.

La primera secció de este capítulo están dirigidas a caracterizar elmodelo que se presentará (sección 3.1). En la sección 3.2 se presentael modelo HSP genérico, donde en las secciones 3.2.1 y 3.2.2, se deta-llan los dos subprocesos que lo conforman (Inicialización y Búsquedarespectivamente). La sección 3.3 presenta una instancia de este mode-lo a fin de ilustrar la forma en que se materializan las definicionesgenéricas del modelo.

3.1 caracterización del modelo de partición hardwa-re/software

El modelo de procesos que se presenta en este capítulo cumple conun conjunto de características generales. Estas características se en-cuentran agrupadas en dos vistas fundamentales: descriptivas y pres-criptivas. La primera de estas vistas muestra las propiedades que pre-senta el modelo, mientras que la otra expresa el comportamiento delmodelo. Estas características se expresan a continuación:

• Vista descriptiva

1. Integración de métricas: se refiere a la integración de variasmétricas en el modelo con el fin de garantizar una caracte-rización más precisa del sistema que se implementará.

2. Composición de métricas: describe la combinación de doso más métricas, dando lugar a una nueva métrica, lo cualpermite medir el sistema teniendo en cuenta otros puntosde vistas.

3. Flexibilidad: permite acercar el modelo HSP a una formamás natural de expresar los objetivos del diseñador. Permi-tirá considerar como bueno o malo los valores obtenidospor las métricas en una solución, en función de los requisi-tos y de la arquitectura de la plataforma de hardware conque disponga.

4. Satisfacción sobre optimización: se contempla la posibili-dad de obtener soluciones de compromiso que satisfagan

3.2 proceso para la partición hardware/software 45

al usuario en el caso de que no se encuentre la soluciónóptima al problema.

5. Múltiples soluciones: como su nombre lo indica, esta ca-racterística le permitirá al diseñador contar con un conjun-to de soluciones que son clasificadas como buenas, con locual la toma de decisiones se enriquecerá.

• Vista prescriptiva

1. Integración de métricas: se logra a partir de incluir las mé-tricas en la función objetivo o como restricciones del mode-lo.

2. Composición de métricas: esta característica se logra me-diante cualquier operación matemática que vincule dos omás métricas primitivas.

3. Flexibilidad: se garantiza en el modelo mediante la utiliza-ción de lógica difusa, para lo cual las métricas serán consi-deradas como variables lingüísticas.

4. Satisfacción sobre optimización: empleo de algoritmos me-taheurísticos para buscar la solución el problema HSP.

5. Múltiples soluciones: el conjunto de las mejores solucionesse obtiene a partir de sobre todas las soluciones genera-das y teniendo en cuenta algún criterio para seleccionar lasmejores. Por ejemplo, utilizar las conceptos de dominanciateniendo en cuenta dos o más métricas.

3.2 proceso para la partición hardware/software

De manera general el proceso HSP que se modelará se define por latupla:

HSP ≡ (F,CompIni,CompBusq,∆,S) (1)

F = {f1, f2, . . . , fn} (2)

∆ = {δ1, δ2, . . . , δk} (3)

S = {s1, s2, . . . , sm} (4)


Donde F representa a las funciones o métodos (fi) que conformanel sistema o programa que se desea particionar, el cual constituye laentrada al proceso HSP. Mientras que a la salida de este se obtiene elconjunto S, el cual representa a las m mejores soluciones encontradasdurante el proceso de búsqueda.

Se denota como ∆ al conjunto de elementos presente en la arquitec-tura del dispositivo de hardware en el que se realizará la implemen-tación final del sistema.

Por último, el elemento CompIni representa al elemento encarga-do de establecer los valores iniciales de los costes. Mientras que elelemento CompBusq será el encargado de obtener el conjunto S conlas mejores soluciones. Ambos elementos serán descritos con mayornivel de detalles en las secciones siguientes.

Es necesario señalar que la especificación del sistema se realiza con-siderando una granularidad gruesa, la cual es aceptada comúnmentepor encima de la granularidad fina para el diseño de sistemas embe-bidos. La principal razón es que la granularidad fina pudiera generarun número superior de transacciones entre el hardware y el software,dando lugar a peores resultados en el diseño.

Por otra parte, en los artículos revisados es común observar que ala salida de este proceso solo se brinda la mejor solución encontrada,esto es la que mejor valor obtiene de la función objetivo, lo que nosiempre garantiza el mejor balance entre las métricas. Este enfoquerestringe la capacidad para tomar decisiones por parte del diseñador,ya que pudiera ser que existan otras soluciones que se adapten mejora sus especificaciones. Es por eso que en el modelo presentado enesta sección se emplea un enfoque basado en múltiples soluciones.


<<physical>>

Especificación

del sistema (F)

<<abstract>>

Arquitectura (Δ)

Búsqueda Inicialización

<<goal>>

Obtener las mejores configuraciones de componentes de

software y hardware que cumplan con los requerimientos

y restricciones.

<<supply>>

<<achieve>>

<<abstract>>

Configuraciones

(S)

<<information>>

Estimaciones

(Gc’)

Figura 7 Vista global del proceso de Partición Hardware/Software propues-to.

En la figura 7, es posible apreciar una vista dinámica del mode-lo descrito previamente. Teniendo en cuenta la arquitectura de hard-ware (∆), el proceso comienza estimando los valores iniciales de loscostes para cada uno de los elementos de F.

A partir de estos costes, y teniendo en cuenta nuevamente la arqui-tectura, el CompBusq se encarga de recorrer el espacio de diseño yrecuperar las m mejores particiones del sistema.

Es importante señalar que la arquitectura del hardware se defineen el proceso como como un recurso abstracto, debido a que depen-de de las características físicas de los dispositivos con que cuenteel diseñador para realizar la implementación final. De esta forma,pudieran constituir componentes de la arquitectura, por ejemplo, elprocesador de propósito general o la cantidad de coprocesadores dehardware que sea posible implementar.

Además, como se observa en la figura 7, este recurso es utilizadodurante todo el proceso; en otras palabras, la plataforma donde sedesplegará el sistema final va a condicionar el proceso de particióny el proceso de co-diseño de manera general. Esto se debe a que elCompIni debe tener en cuenta la arquitectura subyacente para produ-cir estimaciones más precisas de los costes que se vayan a utilizar enel CompBusq. Mientras que, durante la búsqueda de la solución, lascaracterísticas de la arquitectura permitirán definir, entre otras cosas,la cantidad de coprocesadores de hardware que se podrán utilizarpara implementar las funcionalidades del sistema.


3.2.1 Componente de inicialización

El CompIni es el encargado de generar las estimaciones para cadauna de las variables que se desean medir. Dicho componente se definemediante la tupla:

CompIni ≡ (F,Va,Es,∆,C,GC′) (5)

F = {f1, f2, . . . , fn} (6)

Va = {va1, va2, . . . , vap} (7)

C = {c1, c2, . . . , cr} (8)

Es = {es1, es2, . . . , esp}; (9)

∀esi, ∃(vai,∆) | esi : vi→ ci (10)

G ′C = {V ′,E′}; ∀vi′,∃ci | vi ∈ V , ci ∈ C (11)

∀eij′,∃cj | eij ∈ E, cj ∈ C (12)

Donde Va representa a cada una de las variables que deberán serinicializadas por el componente. Estas variables pudieran estar aso-ciadas a cada una de las funciones del sistema o a cada enlace entrelas funciones. Es necesario señalar, que estas variables las define eldiseñador en dependencia de los requisitos impuestos al desarrollo.

Los costes, representados por el conjunto C, no son más que el valorestimado de cada una de las variables para cada una de las funcionesy enlaces presentes en la especificación del sistema (F), de acuerdocon la arquitectura (∆).

El elemento fundamental de este componente lo constituye el con-junto de estimadores Es. Cada uno de los estimadores se define comouna función inyectiva y son los encargados de producir las estimacio-nes de cada uno de los costes a partir de las variables definidas enel conjunto Va. Cada estimador esi, tiene asociado una variable vaide la que estimará su coste (ci). Como puede apreciarse, el estimadortiene en cuenta la arquitectura de hardware subyacente con el fin deproducir estimaciones más precisas.

Finalmente, el grafo de llamadas anotado GC′ representa el siste-ma o aplicación sobre la que se va a realizar la partición. En estegrafo, cada vértice vi del conjunto V = {v1, v2, . . . , vn} se hace corres-ponder con un elemento del conjunto F. Mientras que el conjunto


Obtener modelo computacional

Especificación del sistema (F)

Anotar modelo

Estimar costes

Grafo de llamadas (Gc)

Arquitectura (Δ)

Estimaciones(Gc')

Costes (C)

Variables (Va)

Figura 8 Vista de las actividades del subproceso de Inicialización.

E = {e11, e12, . . . , enn} representa las dependencias entre los vértices.Cada nodo y arco de este grafo tiene asociado los costes que se gene-raron.

La figura 8, muestra las actividades que deberá ejecutar el CompInipara generar los costes de cada una de las variables definidas. Comose observa, el subproceso recibe como recurso la especificación de laarquitectura (∆) y la definición de las variables que serán utilizadas(Va).

Las variables vinculadas a este subproceso se definen como un re-curso abstracto, ya que sus instancias dependerán de las variables quedesee medir el diseñador, a partir de los requisitos impuestos por elcliente (figura 9). A su vez este recurso se define por las variables queestán asociadas con las funciones del programa a particionar (VF) y es-tas a su vez están vinculadas con la implementación de las funcionesen cada una de las plataformas, Variables de Software y de Hardware(VSW ,VHW). Además, el recurso variable, se define por aquellas queestán vinculadas a la comunicación que se produce entre dos fun-ciones implementadas en plataformas diferentes, como Variables deComunicación (VCM).


<<abstract>>

Variables

<<abstract>>Variables de

Comunicación (VCM)

<<abstract>>Variables de

Funciones (VF)

Figura 9 Definición de las variables involucradas en el modelo.

La actividad Estimar costes, es la encargada de generar las esti-maciones en correspondencia con las variables y la arquitectura de-finidas. Estos costes, al igual que las variables (V), se asocian a lasimplementaciones de las funciones del programa en cada una de lasplataformas. De esta manera, se consideran Costes de funciones (CF)),ya sea si estas son implementadas en Hw y Sw (CHW y CSW). Ade-más, se tienen en cuenta los Costes de Comunicación (CCM) paracada uno de los enlaces entre los métodos.

Por su parte, la actividad Obtener modelo computacional realizauna representación del sistema de entrada a partir de un modelocomputacional conocido. En el caso del modelo HSP propuesto esutilizada la representación en grafo, en particular un grafo de llama-das.

Finalmente, la actividad Anotar modelo es la encargada de caracte-rizar cada nodo y arco del grafo, a partir de asociar a cada uno de loselementos del grafo los valores de los costes que fueron estimados.

3.2.2 Componente de búsqueda

El CompBusq es el responsable de buscar una combinación de com-ponentes de hardware y software que cumpla con los requisitos delsistema. Este componente se define como:


CompBusq ≡ (∆,C,EM,M, FP,µ(M),R, fo,S) (13)

EM = {em1, em2, . . . , ems};

∀emi,∃(c ′,mi) | emi : c ′ → mi, c ′ ⊂ C (14)

M = {m1,m2, . . . ,ms}; s > 2 (15)

FP = {fp1, fp2, . . . , fps}; fpi ≡< tfi,pi >;

fpi : mi → µ(mi) (16)

TF = {tf1, tf2, . . . , tft} (17)

P = {p1,p2, . . . ,ps} (18)

U = {u1,u2, . . . ,us} (19)

µ(M) = {µ(m1),µ(m2), . . . ,µ(ms)} (20)

R = {r1, r2, . . . , rk} (21)

fo : (µ(M),Op,R)→ vfo (22)

Los evaluadores de métricas (EM) son los responsables de obtenerel valor de cada una de las métricas definidas según la solución gene-rada. Estos evaluadores se definen como una función sobreyectiva, esdecir para cada elemento del conjunto de las métricas existe al menosun coste que le da origen. Como puede apreciarse la cardinalidad delconjunto de las métricas está condicionada, para una cantidad mayoro igual que dos; en otras palabras, esto garantiza la integración devarias métricas en el modelo.

Para garantizar la característica de flexibilidad, todas las métricasse considerarán como conjuntos difusos, utilizando el nombre de lamétrica como variable lingüística. Teniendo en cuenta esto, el con-junto FP define a las funciones de pertenencia que serán aplicadassobre cada conjunto difuso. Estas funciones serán las encargadas deasociar a cada elemento de un conjunto difuso (mi) el grado con quepertenece a la etiqueta asociada (µ(mi)).

En dependencia de las necesidades del diseñador, es posible selec-cionar para cada métrica uno de los tipos de funciones de pertenen-cia definidos (TF). Además cada función de pertenencia especifica unjuego de parámetros, que responde también a las necesidades del di-señador. Estos parámetros a su vez se definen según el universo deldiscurso de cada una de las variables lingüísticas.


La función objetivo (fo) es la encargada de guiar la búsqueda delalgoritmo metaheurístico. Ella es la encargada de garantizar la carac-terística de composición de métricas, fundamentalmente a partir dela aplicación de cualquiera de las operaciones lógicas (Op) sobre losvalores de pertenencia de las métricas (µ(mi)). Es necesario destacarque esta operación pudiera ser cualquiera de las funciones definidaspor las operaciones T-Norma, S-Norma o cualquier otra según lasnecesidades del diseñador.

A partir de la operación definida (Op), de las restricciones (R) y delos valores de pertenencia de las métricas (µ(M)), la función objetivo(fo) evalúa las soluciones generadas. El valor obtenido (vfo) será utili-zado como referencia para determinar si la solución generada puedeser incluida dentro del conjunto de soluciones válidas (S).

La figura 10 muestra las actividades que ejecuta el CompBusq paragenerar las soluciones al problema HSP. A partir de las estimacionesrealizadas (GC′), el subproceso de Búsqueda será el encargado de ge-nerar las combinaciones de componentes de Hw y Sw que garanticensoluciones efectivas (S) al problema HSP en un tiempo adecuado.

Para determinar la efectividad de las soluciones es necesario definirla forma en que será medida la calidad de las mismas, lo cual está enfunción de los requerimientos planteados por el usuario final. Esteproceso en general, estará condicionado por la arquitectura (∆) y lasrestricciones (R) impuestas por el diseñador que deben cumplir lassoluciones que se generen.

Como se hace alusión en la sección 3.1, el modelo de procesos de-be ser flexible y garantizar la satisfacción del diseñador a partir degenerar soluciones efectivas en un tiempo considerable. Estas dos ca-racterísticas se logran considerando el modelo bajo un enfoque de Softcomputing, combinando algoritmos metaheurísticos con lógica difusa.En la figura, las actividades resaltadas en color azul se correspondencon los algoritmos metaheurísticos, mientras que las de color amarilloestán vinculadas con los elementos de lógica difusa empleados.

Para cumplir con tales propósitos, el subproceso de búsqueda debeejecutar las siguientes tareas:

1. Calcular el universo del discurso: a partir de las estimaciones(GC′), esta actividad calcula el rango de valores posibles quepuede tomar cada una de las variables lingüísticas.


Seleccionar mejores configuraciones

Fuzzificar métricas

Valores de pertenencia (µ(M))

Calcular universodel discurso

Calcular métricas

Generar solución

Configuraciones(S)

Evaluar solución

Función de pertenencia (Fp)

Restricciones(R)

Estimaciones(Gc')

Universo deldiscurso (U)

Almacenarsolución

Operación lógica (Op)

Solución(S')

Métricas(M)

[No]

[No][Mejora o iguala]

[Iteraciónfinal]

Figura 10 Vista de las actividades del subproceso de búsqueda.


2. Generar solución: es la encargada de generar una solución s′, lacual más adelante en el proceso será evaluada. Esta actividad es-tá condicionada por: la codificación utilizada y el operador quese esté aplicando en el problema (por ejemplo: el operador demutación) y por la forma en que los algoritmos metaheurísticosconstruyen la solución.

3. Calcular métricas: este subproceso, a partir de la solución gene-rada (s′), es el encargado de evaluar cada una de las métricasprimitivas empleadas en el proceso. Para realizar la evaluaciónes necesario contar con los costes estimados (C), obteniendo ala salida el conjunto M, compuesto por los valores de cada unade las métricas.

4. Fuzzificar métricas: permite asociar a cada valor mi ∈M el gra-do con que pertenece a la etiqueta asociada (µ(mi) ∈ µ(M)). Lafunción de pertenencia y sus parámetros, debe estar en corres-pondencia con el comportamiento de los conjuntos difusos quese desee modelar.

5. Evaluar solución: permite obtener un valor (vfo) que caracterizaa la solución generada, para lo cual tiene en cuenta los valoresde pertenencia (µ(M)), las restricciones (R) y la operación (Op)definida.

6. Almacenar solución: permite almacenar la solución evaluadapara su posterior análisis, si y solo si la solución evaluada esigual o mejor que las anteriores.

7. Obtener mejores soluciones: permite obtener un conjunto conlas m mejores soluciones generadas. Estas soluciones se clasifi-can de esta manera a partir del criterio que desee establecer eldiseñador.

3.3 instancia del modelo de partición para el índice de

rendimiento

El modelo presentado en la sección anterior constituye un nuevo en-foque a la solución del problema HSP. Este modelo fue presentado

3.3 instancia del modelo 55

siguiendo un enfoque abstracto en cuanto a la arquitectura, variables,métricas y demás elementos para indicar que pueden existir diversasinstancias, según los requerimientos y propósitos de los usuarios ydiseñadores.

No obstante para validar las características que se defienden en él,es necesario establecer una instancia del mismo que permita realizarlos experimentos necesarios. En esta sección, se presenta una instan-cia del modelo teniendo en cuenta como métrica fundamental paraguiar la búsqueda, el Índice de rendimiento [Mourelle and Nedjah,2004]. Además se consideran como elementos arquitectónicos las ca-racterísticas del procesador empotrado y los buses. La instancia delmodelo define también variables, métricas y funciones para evaluarestas, así como, un criterio para la selección de las mejores soluciones.

La instancia del modelo se define de manera general de forma si-milar a la ecuación 1, manteniendo la misma definición también parala estructura del sistema a particionar y las soluciones finales. La úni-ca variación radica en la especificación del recurso arquitectura dehardware, la cual se define de la siguiente forma:

∆ = {Pg,Co,B,Me} (23)

Pg = {ce, cd1, cd2, . . . , cdu};

ce =< ceah >, cdi =< cdahi >

Co = {co1, co2, ..., con};

B = {b1,b2, ...,br};

br =< btcr ,bapr >

Me = RM

Donde Pg representa al procesador de propósito general empotra-do que será usado en el sistema para ejecutar los componentes desoftware. Este procesador está compuesto por Características Estáti-cas (ce) y Dinámicas (cd). Las primeras representan las característicasbásicas de cualquier procesador de propósito general empotrado, porejemplo: el camino de datos y la unidad de control.

Por su parte, el segundo grupo representa aquellas característi-cas que pudieran ser configuradas por el diseñador para mejorar sudesempeño en determinados casos; por ejemplo en el procesador Mi-croblaze [Xil, 2008], es posible configurar el uso de instrucciones de


multiplicación y desplazamiento de bits para que sean implementa-das por hardware, la utilización de memoria cache y su tamaño, etc.La presencia de estas características en un diseño cualquiera implicaconsiderar unos costes, que para la instancia que se presenta en estasección serán considerados aquellos por concepto de área de hardwa-re (ceah y cdahi ) que se ocupa por la inclusión en el diseño de cadauna de las características.

El conjunto Co define los coprocesadores que pueden ser imple-mentados en el sistema. La cardinalidad de este conjunto puede irdesde cero hasta la cantidad elementos del conjunto F. Es decir, pue-de ser que no se usen coprocesadores lo cual significa que todos losmétodos del sistema fueron implementados sobre el procesador em-potrado o que todo el sistema sea implementado como coprocesadorde hardware. Si bien estos casos extremos no son los ideales, es nece-sario tenerlos en cuenta en el diseño, puesto que representan configu-raciones posibles para cualquier sistema.

También se tiene en cuenta para definir la arquitectura, los busesdisponibles en la plataforma (B), mediante los cuales es posible conec-tar los coprocesadores implementados en hardware con los módulosimplementados en el procesador de propósito general. Al igual quelos elementos anteriores cada uno de los buses presentes en la ar-quitectura se definen por el coste de hardware que en este caso secontempla el área de hardware (bahr ) que ocupa su implementaciónen el sistema y por el coste de comunicación el cual está asociadoal ancho de palabra que es capaz de transferir el bus por cada ciclo(bapr ) y por el tiempo que demora cada ciclo de bus (btcr ).

Finalmente, el elemento Me representa la cantidad de memoriadisponible en la arquitectura y que será utilizada para almacenar elcódigo de programa de las funciones que serán ejecutadas sobre elprocesador empotrado (Pg). Este valor de memoria será empleadocomo restricción (RM) para evaluar la calidad de las soluciones gene-radas por el CompBusq.

Es necesario resaltar que al considerar los buses y las característicasdel procesador en el modelo, será posible realizar una exploracióndel espacio de diseño, de conjunto con la partición del sistema encomponentes el hardware y el software. Esto se debe a que se podrácontemplar, para una misma partición, varias alternativas de diseño;


evaluando qué bus y qué características brindarían a la solución lacalidad adecuada.

3.3.1 Componente de inicialización

La vista del proceso de inicialización para esta instancia es similar ala presentada en la figura 8. La principal diferencia radica en que laactividad Estimar costes se convierte en tres actividades: estimar loscostes de hardware, estimar costes de software y estimar costes decomunicación. Estas tres actividades reciben como entrada la especi-ficación del sistema, la arquitectura y las correspondientes variablesque se desean estimar. A la salida de estas tres actividades se contarácon una estimación de los costes a partir de las funciones de estima-ción definidas.

Las variables de Software que se desean estimar se definen como:VSW = {ts,as,ps, ci}, donde ts es el tiempo de ejecución de las fun-ciones del sistema sobre el procesador de propósito general, as es lacantidad de memoria que ocupa cada función en el sistema y ps es lapotencia que disipa el procesador por ejecutar cada función.

Por su parte las Variables de Hardware se definen como: VHW =

{th,ah,ph, ci}, cada una de estas variables son los equivalentes de lasanteriores pero para el caso en que la función se implemente forman-do parte de un coprocesador hardware. En ambos conjuntos se puedeapreciar la presencia de una misma variable, siendo esta la cantidadde veces que la función es invocada (ci).

Finalmente las Variables de Comunicación se definen como el con-junto VCM que contiene la cantidad de bits que se transfieren por elbus, es decir VCM = {bt}.

Las funciones de estimación se definen como: Es = {es1, es2, es3},donde es1 representa la función de estimación de los costes de hard-ware (CHW), es2 la función de los costes de software (CSW) y es3 laencargada de realizar las estimaciones de los costes asociados con lacomunicación (CCM). Cada una de estas funciones se correspondencon las actividades antes mencionadas.

Para este modelo, la función de estimación de los costes de hardwa-re generará los costes: CHW = {chw1 , chw2 , . . . , chwn }, donde cada chwirepresenta los costes de hardware de cada una de las funciones del


sistema. En el contexto de este modelo cada chwi está constituido por:chwi = {ahi, thi,phi}, donde ahi representa el coste por concepto deárea de hardware ocupada por el coprocesador, phi es el consumode potencia de ese coprocesador y thi es el tiempo que demora laejecución de esa función.

De forma análoga los costes de software generados se definen co-mo: CSW = {csw1 , csw2 , . . . , cswn }, donde cada cswi se define como: cswi =

{mei, tsi,psi}. Es necesario señalar que los Costes de software estánen función de las características dinámicas (cd) que se le configurenal procesador de propósito general, o sea que el proceso de estima-ción deberá tener en cuenta este aspecto para producir las los valoresde los Costes. Por ejemplo, si se considera el procesador empotradoMicroblaze y a este se le configura el multiplicador como característi-ca adicional, entonces las funciones que hagan uso de esta operaciónse ejecutarán más rápido que si no estuviera; de la misma forma elconsumo de potencia y la memoria ocupada se verá afectada.

El conjunto CCM = {ccm11 , ccm12 , . . . , ccmnn } define los costes de comu-nicación, donde cada ccmij representa los costes de cada uno de los ar-cos, definiéndose en el contexto de esta instancia como: ccmij = {btij}

donde btij es la cantidad de bits transferidos entre dos funcionesimplementadas en plataformas diferentes por un bus en particular.

Por último, la actividad Anotar modelo, será la responsable de aso-ciar los costes generados al grafo de llamadas (GC). Para esto, a cadanodo vi y a cada vértice eij del grafo se le asocian los costos corres-pondientes en los conjuntos CSW ,CHW y CCM, según corresponda.

Para el caso de los costes de comunicación, estos serán represen-tados mediante una matriz de adyacencia (AG) del grafo, la cual esde orden n y representa la conexión que existe entre dos nodos delgrafo. Sea la función booleana Conexión(vi, vj), definida como truesi existe un elemento de E que sirva de enlace entre los vértices vi yvj y false en caso contrario. Se define la matriz de adyacencia (AG)como:

AG =

{1 Conexión(vi, vj) = true

0 Conexión(vi, vj) = false(24)


Sea btij la cantidad de bits transferidos de la función i a la funciónj y ciij la cantidad de veces que la función i invoca a la función j. Lamatriz de adyacencia definida en la ecuación 24, se redefine como:

AG =

{btij ∗ ciij Conexión(vi, vj) = true

0 Conexión(vi, vj) = false(25)

Por ejemplo, si Conexión(1, 2) = true, bt12 = 32 y ci12 = 3 enton-ces el valor de la matriz en esa posición será AG[1, 2] = 96.

El resultado de este subproceso es la caracterización de cada vérticey arco a partir de los costes estimados como:

G ′C = {V ′,E ′} (26)

v ′i =< ahi,asi, thi, tsi,phi,psi,> (27)

e ′ij =< btij > (28)

3.3.2 Componente de búsqueda

Las actividades del proceso de búsqueda son las mismas que las delproceso genérico presentado previamente, en la figura 10. La diferen-cia fundamental está dada en los valores que tomarán los recursos,los cuales están en función de las métricas que se proponen en estainstancia del modelo.

Las soluciones generadas por la actividad Generar solución, se re-presentan a partir de los conjuntos X, Y y Z. El primero de estos esun conjunto de elementos binarios X = {x1, x2, . . . , xn} donde el valorde cada elemento i representa el tipo de implementación asignada ala función representada por el vértice vi; si xi = 1 indica implementa-ción Hw e implementación Sw en caso contrario.

Por su parte el conjunto Y se define como: Y = {y11,y12, . . . ,ynn},donde 1 6 yij 6 r, representando al tipo de Bus que será utilizadopara implementar el enlace entre dos funciones (eij). Es necesariorecordar que los Buses (B) se encuentran definidos en la Arquitectura(∆) que dispone el diseñador para realizar la implementación final.

El conjunto Z representa las características dinámicas (cdi) que seimplementarán en el procesador de propósito general y que fueron


definidas en la arquitectura. Este será un conjunto de dígitos de unbit Z = {z1, z2, . . . , zu}, donde cada elemento se define como:

zi =

{1 si cdi es implementada

0 en caso contrario(29)

Sea A el área de hardware ocupada por la solución, T el tiempode ejecución, Me la memoria de programa ocupada, CC el coste decomunicación y P el consumo de potencia, el conjunto de métricas,en esta instancia del modelo se define como: M = A, T ,CC,Me,P.

A partir de la definición de las métricas, el subproceso Evaluarmétricas se define a través del conjunto de evaluadores como: EM =

{EA,ET ,ECC,EM,EP}.Sea APg el Área de hardware ocupada por el procesador general

dentro del sistema, la cual está en función del área que ocupan lasCaracterísticas estáticas (ce) y las dinámicas (cd). El término w tomavalor 0 cuando todas las funciones son implementadas en hardwa-re, mientras que un valor de 1 representa que al menos una de lasfunciones se implementarán en software.ACo es el área que ocupa la implementación de las funciones como

coprocesadores de hardware, según la solución analizada en ese mo-mento. El evaluador del área de hardware (EA) se define mediante lafunción que calcula esta métrica como:

A = w ∗APg +ACo (30)

APg = ceah +

u∑i=1

zi ∗ cdahi

ACo =

n∑i=1

(xi ∗ ahi)

Seamei el consumo de memoria de cada función implementada ensoftware, la memoria consumida por las funciones que se ejecutaránen el procesador de propósito general, se evalua mediante la función:

Me =

n∑i=1

(1− xi)mei (31)


Sea Tf el tiempo de ejecución de las funciones del sistema, el cualestá en dependencia de la plataforma donde haya sido implementada(Hw o Sw). Sea cii la cantidad de veces que es invocada esta funcióni. Es necesario resaltar que el tiempo de ejecución de las funcionesimplementadas en software está en función de las características di-námicas (cd) que han sido implementadas en el procesador.

Sea TC, el tiempo dedicado a la transferencia de datos entre fun-ciones implementadas en plataformas diferentes ((xi ⊕ xj) = 1). Seaci,j el coste en que se incurre por la transferencia de datos entre lafunción i y la función j, a través de uno de los buses (B) definidosen la arquitectura (∆). El tiempo de ejecución del sistema se calculacomo:

T = Tf + TC (32)

Tf =

n∑i=1

[((1− xi)tsi + xithi) ∗ cii]

TC =

n∑i=1

n∑j=1

(xi ⊕ xj

)∗ ci,j

ci,j =

(AG[i, j] ∗ btc[yi,j]

bap[yi,j]

)Sea PPg la potencia que consume el procesador para ejecutar ca-

da una de las funciones, de acuerdo con las características estáticasy cada una de las dinámicas. Al igual que en la ecuación 30, el tér-mino w toma valor 0 cuando todas las funciones son implementadasen hardware y 1 cuando al menos una se ejecuta sobre el procesadorempotrado. PCo el consumo de potencia que se generan en los co-procesadores de hardware. La función de evaluación del consumo depotencia, se define como:

P = w ∗ PPg + PCo (33)

PPg =

n∑i=1

[(1− xi)psi ∗ cii]

PCo =

n∑i=1

(xiphi ∗ cii)


Variablelingüística

Valor mínimo Valor máximo

Área Implementaciónsoftware

A′ = max A

Tiempo Implementaciónhardware

T ′ = max T

Memoria Implementaciónhardware

Implementaciónsoftware

Potencia Implementaciónhardware

P′ = max P

Tabla 2 Universo del discurso para cada una de las variables lingüísticas.

Para tener en cuenta la precisión limitada de los valores estima-dos, las métricas anteriores serán consideradas como conjuntos di-fusos, donde el nombre de la métrica se asociará a la variable lin-güística. Para esto, la actividad Fuzzyficar métricas asociará a cadavalor de las métricas el grado con que pertenece a la etiqueta asocia-da (µ(M) = {µ(A),µ(T),µ(Me),µ(P)}). La etiqueta utilizada en estainstancia del modelo será {mucho/a} según corresponda, o sea seráncaracterizados los elementos más grandes de los conjuntos.

Además es necesario definir, para cada uno de los conjuntos difu-sos, el universo del discurso (U), el cual es utilizado también por laactividad anterior. El universo del discurso de estas variables defineun valor mínimo y uno máximo, los cuales estarán en dependenciade las características del sistema a particionar.

En la tabla 2 se muestran los valores extremos de los universosde cada una de las variables. Es posible apreciar en esta tabla quelos valores mínimos del universo están siempre claros cuales debende ser; en cambio los valores máximos, exceptuando la memoria, de-penderán de la implementación que se realice. Por ejemplo, para lavariable lingüística Área, el valor mínimo posible estará asociado conel área ocupada por una implementación totalmente sobre un proce-sador general; mientras que el valor máximo estará asociado con laforma en que se combinen los componentes. De forma similar sucedeen el resto de los casos.


0

0.2

0.4

0.6

0.8

1

αA βA

µ(A)

A

mucha

(a) Métrica Área

0

0.2

0.4

0.6

0.8

1

αT βT

µ(T)

T

mucho

(b) Métrica Tiempo

Figura 11 Funciones de pertenencia Gamma.

Para calcular los extremos que no estén previamente definidos se-rán utilizados algoritmos metaheurísticos también. En este caso lafunción objetivo estaría orientada a maximizar cada una de las varia-bles lingüísticas y se calcularía según las ecuaciones anteriores (30,33, 32). La actividad para generar el universo del discurso como de-pende únicamente de los datos estimados, se ejecutará al inicio delsubproceso.

Sea α = k1 ∗ Vm y β = k2 ∗ Vm, los límites inferior y superior res-pectivamente. Donde Vm es el valor máximo del universo del discur-so para esa métrica, mientras que k1 y k2 se ajustan de acuerdo a losrequerimientos del usuario. De acuerdo con las etiquetas definidaspara cada una de las variables lingüísticas, la función de pertenen-cia que se utilizará en el modelo será la función Gamma y se definecomo:

µ(x) =

0 si x 6 α

(x−α)/(β−α) si α 6 x 6 β

1 si x > β

(34)

La figura 11 muestra, a modo de ejemplo, las funciones de perte-nencia para las variables Área y Tiempo; siendo similar para el restode las variables. Es necesario destacar que el límite inferior repre-senta hasta qué valor, a partir del mínimo, el diseñador considerarácomo poco; mientras que el superior representa a partir de qué valorse considerará el valor como mucho/a.


Sea R = {RP,RMe} el conjunto de las restricciones impuestas al di-seño, donde RP representa el valor máximo de potencia permisiblepor la solución y RMe es la cantidad de memoria máxima disponibleen la plataforma para el código que se ejecuta en el procesador depropósito general. Estas restricciones serán tenidas en cuenta comopenalizaciones con el fin de incluir en el espacio de búsqueda solucio-nes que, si bien no forman parte de éste, puedan ayudar a llegar a lasolución deseada. Sean PP y PM las penalizaciones que se aplicaránal modelo por violar las restricciones definidas, las cuales se definencomo:

PP =

{µ(P)−RPRP

µ(P) > RP

0 µ(P) 6 RP(35)

PM =

{µ(Me)−RMe

RMeµ(Me) > RMe

0 µ(Me) 6 RMe(36)

Sea Ir el índice de rendimiento, según Mourelle and Nedjah [2004],una métrica compuesta calculada a partir de la combinación de lasmétricas Área y Tiempo mediante la operación de multiplicación(Ir = A ∗ T ). El objetivo de emplearla es garantizar que en el procesose obtenga una solución que tenga en cuenta a ambas, de forma talque se asemeje a la forma en que en la práctica el diseñador abordaun problema de este tipo.

Como en este trabajo las métricas A y T se modelarán como varia-bles lingüísticas, Ir se calculará a partir de los valores de pertenenciay como operación lógica (Op) será utilizada la función x ∗y de la ope-ración T-Norma, es decir Ir = µ(a) ∗ µ(t). Para evaluar la solución sedefine la función objetivo como:

FO = mı́n Ir + PP + PM (37)

Es necesario resaltar que el empleo de lógica difusa aporta al mode-lo flexibilidad en el espacio de soluciones que será explorado. Lo ante-rior se debe a que al variar los límites inferiores y superiores (siempre


1000120014001600180020002200240026002800

0 1000 2000 3000 4000 5000

Tiem

po

Área

Figura 12 Frente de Pareto.

de acuerdo a los requerimientos del sistema), es posible aceptar so-luciones que se consideren suficientemente buenas o rechazar otrasque no lo parezcan. De esta forma el modelo propuesto logra mayornivel de flexibilidad con respecto a la mayoría de las propuestas an-teriores, donde el límite inferior es igual al superior; aceptando solosoluciones “buenas”.

Como se pudo apreciar, la función objetivo propuesta en esta ins-tancia, tiene en cuenta la coexistencia de dos métricas contrapuestas,área y tiempo. De acuerdo con esto, la actividad Obtener mejores solu-ciones es la encargada de realizar un análisis de las soluciones desdeun punto de vista multiobjetivo. Este análisis consiste en determinarel Frente optimal de Pareto [Coello et al., 2007], el cual está formadopor las soluciones no dominadas, teniendo en cuenta que una solu-ción domina a otra si es mejor en al menos una de las funcionesobjetivo y no es peor en ninguna de las restantes.

Para ilustrar mejor el concepto anterior, la figura 12 muestra unfrente de Pareto hipotético. Los puntos marcados de color verde re-presentan las soluciones no dominadas. Como puede apreciarse endicha figura, forman parte de este frente aquellas soluciones dondeel tiempo es máximo y el área mínima o viceversa, es decir las solucio-nes que se encuentran en los extremos de la gráfica. Estas solucionesde los extremos en la mayoría de los casos están asociadas con imple-mentaciones puras sobre coprocesadores de hardware o implemen-taciones puras sobre procesadores generales. Si bien estas soluciones


no son, en la mayoría de los casos las deseables, se muestran en el grá-fico para brindarle al diseñador una referencia con respecto al restode las soluciones.

Las soluciones dominadas están representadas en color rojo, comopuede apreciarse están en esta categoría pues existe al menos unasolución que la mejora en una de las funciones y no es peor en la otra.Estas soluciones no se muestran al finalizar el proceso, solo se hancolocado en este gráfico para ilustrar el concepto.

3.4 un ejemplo de aplicación de la instancia del mode-lo de partición

A partir de la instancia del modelo definida previamente, en esta sec-ción se describirá un escenario de aplicación, para el cual se utilizaráun sistema hipotético. Para describir el ejemplo se seguirá la mismaestructura utilizada para definir la instancia del modelo.

Se supone, a los efectos del ejemplo, la aplicación que se muestraen la figura 13a, la cual se representa, a partir de las funciones quela conforman, por el conjunto P = {p1,p2,p3,p4,p5} y por el grafode llamadas mostrado en la figura 13b. El modelo HSP deberá darcomo resultado las mejores soluciones que garanticen los valores es-tablecidos previamente para las métricas. Cada solución describiráuna combinación de componentes de hardware y software de cadauna de las cinco funciones antes mencionadas, de forma tal que sesatisfagan los requerimientos planteados.

La arquitectura disponible para este ejemplo establece un proce-sador general el cual está compuesto, además de las característicasestáticas (ce), por dos características dinámicas (cd1 y cd2), cada unade estas con sus respectivos costes. La presencia de estas dos caracte-rísticas implica que en el momento de estimar los Costes de softwaresea necesario considerar las cuatro combinaciones que resultan decontemplar esta opción. Es decir que para cada una de las funcio-nes hay que tener en cuenta su implementación sin las características,con ambas características o con una de ellas. La definición de los Co-procesadores (Co) establece que será posible implementar las cincofunciones como coprocesadores de hardware. Además la arquitectu-ra contará con 2 buses y un límite de memoria de 30 unidades. De

3.4 ejemplo de aplicación de la instancia 67

char f3(int a){

f4(a);

char c = f5();

return c;

}

void f1(){

int a = f2();

char t = f3(a);

}

(a) Código.

f1

f2 f3

f4 f5

e12

e21 e13

e31

e34 e35

e53

(b) Grafo de llamadas.

Figura 13 Aplicación hipotética para el ejemplo.

acuerdo a lo anterior la ecuación 38, resume las características de laarquitectura disponible en el ejemplo, esta definición está basada enla ecuación 23. Los valores que aparecen en esta definición fuerongenerados aleatoriamente para este ejemplo.

∆ = Pg∪Co∪B (38)

Pg = ce∪ cd1 ∪ cd2; ce =< ceah = 20 >

cd1 =< cdah1 = 10 >

cd2 =< cdah2 = 8 >

Co = {co1, co2, co3, co4, co5};

B = {b1,b2};b1 =< btc1 = 50,bap1 = 16 >

b2 =< btc2 = 40,bap2 = 16 >

Me = 30

Las dos características dinámicas establecidas en el procesador ge-neran cuatro configuraciones diferentes, las cuales tendrán implica-ciones sobre la estimación de los Costes de software. La tabla mues-tra las posibles configuraciones a partir de la presencia o no de estascaracterísticas.


cd1 cd2 Configuración

0 0 C0

0 1 C1

1 0 C2

1 1 C3

Tabla 3 Posibles combinaciones que generan las características dinámicasdel procesador.

A partir de las variables definidas previamente en la instancia yteniendo en cuenta las definiciones anteriores, se producirán las es-timaciones de cada uno de los costes definidos por el modelo paracada una de las funciones del sistema,

CHW = {ahi, thi,phi}

CSW = {asi, tsi,psi}

CCM = {btij}

Para representar la aplicación durante el proceso de partición, seráutilizado como modelo computacional un grafo de llamadas: G =

{V ,E}. Este grafo (figura 13b), está formado por:

• El conjunto V = {v1, v2, v3, v4, v5}, representando los vértices.

• El conjunto E = {e12, e21, e13, e31, e34, e35, e53}, representandolos arcos.

De acuerdo con el modelo, el resultado final del subproceso de ini-cialización será el grafo anotado y la matriz de adyacencia. El primerode estos resultados incluye los valores estimados para cada una de lasfunciones del sistema, tal y como puede apreciarse en las figuras 14ay 14b. La figura 14a muestra además, los Costes de Sw (CSW) que sehan producido para cada una de las funciones, teniendo en cuentalas configuraciones que genera el establecimiento o no de las caracte-rísticas dinámicas (cd1 y cd2) en el procesador de propósito generalempotrado (Pg). La figura 14c muestra la matriz de adyacencia (AG),la cual permitirá, en el subproceso de Búsqueda, determinar los enla-ces existentes entre funciones en el sistema. Por último se determina


la cantidad de veces que es invocada cada función del sistema, tabla14d.

C0 C1 C2 C3 C0 C1 C2 C3 C0 C1 C2 C3f1 2 17 2 3 26 27 23 15 28 12 6 14f2 20 15 16 3 23 26 12 13 27 6 1 1f3 14 16 7 18 15 14 30 6 14 5 13 12f4 3 17 2 16 10 9 30 10 22 28 14 4f5 10 6 10 18 24 15 8 1 6 18 2 5

ts as ps

(a) Costes de software.

th ah phf1 1 30 3f2 7 25 12f3 5 31 2f4 1 8 11f5 5 23 3

(b) Costes dehardware.

f1 f2 f3 f4 f5f1 0 16 32 0 0f2 64 0 0 0 0f3 8 0 0 16 32f4 0 0 0 0 0f5 0 0 16 0 0

(c) Matriz de adyacen-cia.

f1 f2 f3 f4 f5ci 1 2 2 1 1

(d) Cantidad de invoca-ciones.

Figura 14 Resultados obtenidos por el proceso de Inicialización para el ejem-plo.

A partir de estos valores estimados se comienza el proceso de bús-queda para encontrar las mejores configuraciones del sistema, tenien-do en cuenta los siguientes valores de Restricciones (R), para la res-tricción de consumo de potencia se considerará RP = 70 y para elconsumo de memoria RM = 30. esta última de acuerdo con la arqui-tectura definida en 38.

Cada solución generada en este proceso tendrá en cuenta la imple-mentación, Hw o Sw, de cada nodo (X), qué tipo de buses se utilizaránpara conectar los nodos implementados en plataformas diferentes (Y)


y qué características dinámicas estarán incluidas en el procesador depropósito general (Z). Las tablas 4 muestran la codificación de lassoluciones generadas en el ejemplo, mientras que la 5, muestra losvalores de pertenencia de cada métrica para cada solución. Ademásse muestra el valor de la función objetivo y el cumplimiento de lasrestricciones.

3.4

eje

mp

lo

de

ap

lic

ac

ió

nd

el

ain

st

an

cia

71

X Y Z

x1 x2 x3 x4 x5 y12 y21 y13 y31 y34 y35 y53 cd1 cd2

S1 1 1 0 0 1 2 1 1 1 2 1 2 1 1

S2 1 0 1 0 1 2 2 1 1 2 2 1 1 0

S3 1 1 1 0 0 1 1 1 1 1 1 1 1 0

S4 1 1 1 0 0 1 1 1 1 2 2 2 1 0

S5 1 1 1 0 0 1 1 1 1 1 1 1 0 0

S6 1 1 1 0 0 1 1 1 1 2 2 2 0 0

S7 1 0 1 1 0 2 1 1 2 1 2 2 0 0

S8 0 0 1 1 1 1 1 1 1 1 2 1 1 0

S9 0 1 0 1 1 1 2 1 1 2 2 2 0 1

S10 0 0 0 0 1 1 1 2 2 1 1 1 0 0

Tabla 4 Codificación de las soluciones generadas a partir de los datos del ejemplo.


µ(A) µ(T) µ(M) µ(P) Ir = µ(A)∗µ(T) µ(υ) µ(θ)

S1 0.886 1 0.018 0.266 0.886 S S

S2 0.829 1 0.491 0 0.829 S S

S3 0.886 0.925 0.345 0.933 0.820 S S

S4 0.886 0.695 0.418 0.133 0.616 S S

S5 0.600 0.931 0.345 0.933 0.559 S S

S6 0.600 0.701 0.345 0.933 0.421 S S

S7 0.114 1 0.582 1 0.114 N S

S8 0.200 0.540 0.364 0.108 0.108 S S

S9 0 1 0.473 1 0 S S

S10 0 0.874 1 1 0 N S

Tabla 5 Evaluación de las soluciones generadas a partir de los datos delejemplo.

Como puede apreciarse, uno de los elementos que conforma unasolución es la configuración que adoptarán las funciones teniendo encuenta el tipo de implementación (X); por ejemplo la configuración:X = {1, 1, 0, 0, 1}, indica que las funciones 1, 2 y 5 del sistema se imple-mentarán en hardware y el resto en el procesador general. De igualmanera se genera para cada enlace el tipo de bus que lo implementa-rá: Y = {2, 1, 1, 1, 2, 1, 2}, por ejemplo para esta solución el enlace e12se implementará usando el bus b2 y el enlace e13 mediante el busb1 y así para el resto. Además se genera cuáles de las característicasdinámicas del procesador de propósito general serán implementadasen la solución: Z = {1, 1}, indicando que se implementarán las doscaracterísticas presentes en el procesador (cd1 y cd2). Las solucionesS7 y S10 (señaladas en rojo) a pesar de lograr valores mínimos dela función objetivo, no son consideradas como válidas pues violan larestricción de consumo de memoria.

Cada vez que se genera una solución, se calculan los valores de lasmétricas asociados a ella según las ecuaciones de: Área 30, Tiempo32, Memoria 31 y Potencia 33; para luego calcular sus valores de per-tenencia. Para calcular estos valores es necesario aplicar la funciónde pertenencia definida anteriormente 34, para lo cual se deben es-


tablecer los límites inferior y superior de dicha función, teniendo encuenta el universo del discurso de cada métrica. Además es necesariocalcular el valor de pertenencia para ambas restricciones, para lo cualse utilizarán las mismas funciones de pertenencia que se utilizaronpara las métricas correspondientes. En la tabla 6 se puede apreciar elvalor mínimo y máximo de cada métrica, de acuerdo con los datosgenerados para el ejemplo. A partir de estos valores, se han estable-cido valores para los límites de la función de pertenencia (α y β), loscuales se muestran en dicha tabla. Es necesario resaltar que estos lími-tes pueden ser movidos en dependencia de los requerimientos parabuscar soluciones con una mejor calidad.

Variablelingüística

Valormínimo

Límiteinferior (α)

Límitesuperior (β)

Valormáximo

Área 20 85 120 A′

Tiempo 19 76 250 T ′

Memoria 0 15 70 91

Potencia 31 45 60 P′

Tabla 6 Universo del discurso para cada métrica del ejemplo.

Cuando el proceso alcanza el máximo de iteraciones establecidasse cuenta con la solución de mejor calidad, es decir la que menor va-lor de Ir alcanzó (en este caso la solución S10). La figura 15 muestra,para el ejemplo, la tendencia del proceso para converger hacia el me-nor valor de la función objetivo. Bajo este tipo de análisis se tomaríacomo válida la última solución generada (de acuerdo a lo estableci-do en el proceso hasta este punto), no obstante pudieran existir otrassoluciones con igual valor de calidad y que cumplan con las restriccio-nes, por lo que el diseñador pudieran considerarlas para una posibleimplementación.

Finalmente, en la última actividad estas soluciones son analizadasdesde el punto de vista multiobjetivo para determinar las solucionesno dominadas. Para el caso del ejemplo que se analiza, las solucio-nes no dominadas son la: S8 y S9, ya que es la de mejor tiempo yárea presentan del resto de las soluciones y ambas son no dominadaspues entre ellas no existe una que mejore o iguale las dos funciones.


0.000

0.100

0.200

0.300

0.400

0.500

0.600

0.700

0.800

0.900

1.000

1 2 3 4 5 6 7 8

Función ob

jetivo

Soluciones

Figura 15 Tendencia de la función objetivo para el ejemplo.

La figura 16 muestra el frente de Pareto para las soluciones genera-das en el ejemplo, es necesario resaltar que de acuerdo a lo que seplanteaba anteriormente, el frente de Pareto lo forman las solucionesrepresentadas en color verde; el resto de las soluciones en color rojose muestran para ilustrar este concepto.

Obsérvese que las dos soluciones tienen valores de calidad simila-res pero cada una con sus características que la hacen adecuada paraser implementada. Una de las soluciones es mejor en el tiempo de eje-cución y la otra es mejor en el área ocupada por el diseño. A partir deeste resultado el diseñador cuenta con dos variantes para tomar la de-cisión sobre qué solución implementar, incluso pudiera implementarambas y ver en la práctica cuál le ofrece mejores resultados.

3.5 conclusiones

Al término de este capítulo y de acuerdo con los aspectos analizadosdurante la formalización del modelo genérico, se concluye que:

1. Este modelo permite la incorporación de cualquier métrica, asícomo de cualquier estrategia de búsqueda siempre y cuandocumpla con el enfoque de Soft computing.

3.5 conclusiones 75

0.000

0.200

0.400

0.600

0.800

1.000

0.000 0.200 0.400 0.600 0.800 1.000

Tie

mp

o

Área

Figura 16 Frente de Pareto para el ejemplo.

2. Propicia la integración y combinación de métricas, dos aspec-tos que le introducen nuevos enfoques a fin de caracterizar deforma más precisa las soluciones generadas.

3. Permite la inclusión de elementos de la arquitectura subyacente,lo cual le aporta al proceso en general que las soluciones genera-das se correspondan con la arquitectura donde será desplegado.

4. La definición de elementos arquitectónicos permite además ex-plorar el espacio de diseño teniendo en cuenta el impacto de laarquitectura en la configuración del sistema.

5. El subproceso de Inicialización requiere de herramientas quepermitan estimar los costes de Software, Hardware y Comuni-cación; las cuales no se encuentran muy generalizadas y depen-den de la arquitectura para la que se esté diseñando.

6. El subproceso de Búsqueda emplea un enfoque de Soft compu-ting, al combinar las bondades de la lógica difusa con los algo-ritmos metaheurísticos.

7. El empleo de la lógica difusa le aporta al modelo flexibilidad,ya que al mover los límites de la función de pertenencia se pu-dieran estar considerando mayor cantidad de soluciones.

De acuerdo con la instancia estudiada, se concluye que:


8. La instancia presentada integra las métricas primitivas: área,tiempo, tiempo de comunicación, potencia y memoria; de formatal que sea posible caracterizar las soluciones desde un puntode vista más integral.

9. La definición de elementos arquitectónicos como el procesadorgeneral empotrado y los buses disponibles, permite realizar unaexploración del espacio de diseño analizando el aporte de estoselementos al sistema en general.

10. El empleo de la métrica compuesta: Índice de rendimiento, lacual combina el área ocupada y el tiempo de ejecución por la so-lución; permitirá obtener soluciones que equilibren ambas mé-tricas.

11. Bajo estas características, se presume que el análisis multiobjeti-vo de las soluciones generadas aportaría un mecanismo viablepara garantizar la característica de múltiples soluciones. Estacondición le brinda al diseñador una mayor cantidad de ele-mentos para tomar la decisión sobre cuál solución es mejor im-plementar.

Parte II

VA L I D A C I Ó N D E L M O D E L O D E PA RT I C I Ó NH A R D WA R E / S O F T WA R E

Esta sección del documento está dedicada a describir lavalidación realizada al modelo de procesos presentado an-teriormente. Para lo cual, se realizarán experimentos diri-gidos a afinar los parámetros de cada uno de los algorit-mos empleados en el proceso de búsqueda (Capítulo 4),estos experimentos se realizarán utilizando aplicacionessimuladas. Mientras que, en el Capítulo 5, se presenta laaplicación del modelo sobre una aplicación real. Ademásse comparan los resultados obtenidos con los reportadosen la bibliografía.

4E X P E R I M E N T O S Y R E S U LTA D O S

El objetivo principal de este capítulo está en realizar una comparativahomogénea entre diferentes algoritmos utilizados habitualmente enel problema HSP. A la comparativa se han añadido los algoritmosEC1 y ECR2 que no han sido utilizados hasta el momento. Además seutilizarán AG y EE.

Con el fin de establecer una comparación lo más fiel posible, sedeterminará para cada uno de los algoritmos la mejor configuraciónen sus parámetros. Además se estudiará la configuración de los pará-metros vinculados con el modelo HSP. Es importante destacar que lavalidación se realizará utilizando la instancia del modelo presentadaen la sección 3.3.

Para evaluar el comportamiento de los algoritmos se tendrán encuenta seis métricas: calidad de la solución, tasa de error, distanciageneracional, distribución, cobertura y tamaño del espacio cubierto.La primera de estas tiene en cuenta el valor de la función objetivo,mientras que el resto son métricas que permiten analizar los resul-tados desde un punto de vista multiobjetivo. En todos los casos, lasconclusiones sobre el algoritmo que mejor valor de estas métricas al-canza se plantean sobre la base de un análisis estadístico, empleandoestadística no paramétrica.

El resto del capítulo está organizado de la siguiente forma, en lasección siguiente se muestran las actividades realizadas para llevara cabo los experimentos. Además se describen los bancos de prue-ba y los algoritmos utilizados, así como las métricas utilizadas paraevaluar el comportamiento de los algoritmos. Se describe también,

1 Algoritmo Escalador de Colinas mejor ascenso2 Algoritmo Escalador de Colinas con Reinicio

79

80 experimentos y resultados

las pautas del análisis estadístico que se lleva a cabo para tomar ladecisión sobre cuál algoritmo es el que mejores resultados ofrece.

Seguidamente, en la sección 4.2 se detalla la forma en que es selec-cionada la configuración de parámetros para cada algoritmo y paralos parámetros del modelo que permitirán obtener los mejores re-sultados. En la sección 4.3 se muestra el análisis realizado sobre losresultados de los experimentos, a partir de las métricas utilizadas.Por último en la sección 4.4 se expone el análisis de los resultados encuanto a la contribución de cada algoritmo al frente de Pareto unifica-do. Este análisis constituye un aporte novedoso de esta investigación,al tener en cuenta las características de las soluciones generadas porcada algoritmo en función del tipo de soluciones que desee lograr eldiseñador.

4.1 organización de los experimentos

En esta sección se presentan los aspectos necesarios a tener en cuen-ta para ejecutar los experimentos y analizar los resultados obtenidos.Con el fin de permitir que los experimentos puedan ser reproducidospor cualquier otro investigador, a continuación se presenta la secuen-cia de pasos que se ejecutaron para obtener los datos necesarios. Losexperimentos se llevaron a cabo utilizando aplicaciones simuladas,las cuales se presentan en la sección 4.1.2. Los algoritmos metaheu-rísticos utilizados en la comparación se presentan en la sección 4.1.3,mientras que las métricas utilizadas para evaluar su desempeño sonpresentadas en la sección 4.1.4. Por ultimo la sección 4.1.5 muestra lasbases del análisis estadístico que respalda las conclusiones brindadasen el capítulo.

4.1.1 Guía de experimentación

Para llevar a cabo la validación del modelo propuesto es necesarioejecutar una secuencia de actividades, las cuales se presentan a conti-nuación:

1. Determinar la mejor combinación de parámetros para cada al-goritmo.

4.1 organización de los experimentos 81

2. Ejecutar los algoritmos sobre los bancos de prueba simulados ycon los parámetros definidos.

3. Realizar un análisis estadístico para obtener el algoritmo quemejor rendimiento obtuvo en las métricas seleccionadas.

4. Realizar un análisis de las soluciones desde el punto de vistamultiobjetivo para determinar la contribución de cada algorit-mo al frente de Pareto Unificado y la distribución de las soluci-nes sobre este último.

Para determinar la mejor combinación, los algoritmos son analiza-dos teniendo en cuenta la métrica de calidad de la solución, la cualexpresa la relación entre el área de hardware ocupada y el tiempo deejecución del sistema. Este estudio es llevado a cabo mediante unaestrategia de experimento factorial, la cual fue propuesta por Mont-gomery [2009], Antony [2003]. Los resultados de estos experimentosse describen en la sección 4.2.

Una vez obtenidos los resultados de la ejecución de los algoritmossobre los bancos de prueba, el paso 3 permitirá decidir cuál algoritmoes mejor sobre el resto; para lo cual se emplean diferentes métricas pa-ra medirlos. Para dar esta respuesta se emplea un análisis basado enestadística no paramétrica. Los resultados de este análisis se reportanen la sección 4.3.

El último paso se corresponde con el análisis de las soluciones nodominadas generadas por cada algoritmo y su participación en unfrente de Pareto que tiene en cuenta las soluciones de todos los algo-ritmos (frente unificado), los resultados de este análisis son descritosen la sección 4.4.

4.1.2 Bancos de prueba

Como se pudo observar en el capítulo 2 una forma de llevar a cabo lavalidación es sobre bancos de prueba simulados. Uno de los motivoses que mediante el uso de las simulaciones no es necesario utilizarherramientas de estimación para obtener los costes de las variablesutilizadas en el modelo, lo que hace posible obtener a priori el com-portamiento de los algoritmos utilizados.


A partir de lo anterior, en esta investigación, se adoptó una estra-tegia basada en la simulación de las aplicaciones a particionar y detoda la información asociada a esta. Esta estrategia de simulación hasido utilizada previamente en esta área según se pudo apreciar en lasección 2.3.1.

En las simulaciones fueron empleados dieciséis (16) grafos de lla-madas. Estos 16 grafos se generaron teniendo en cuenta la cantidadde nodos y arcos, así como su estructura. La tabla 7 muestra las prin-cipales características de las instancias generadas.

Instancia Nodos Arcos Tipo de grafo Grado portarea (entrada-

salida)

I1 49 48 out-tree 1-3

I2 49 55 serie-paralelo 3-2

I3 49 50 Aleatorio 3-2


I5 99 98 out-tree 1-3




I9 149 148 out-tree 1-3




I13 199 198 out-tree 1-3




Tabla 7 Características de las instancias generadas.

Para generar los grafos de prueba fue utilizada la herramientaTGFF, en su versión 3.1 para el sistema operativo Windows, la cual


fue propuesta propuesta por Dick et al. [1998]. Esta herramienta per-mite generar grafos de llamadas de forma controlada por el usuario,es decir, el usuario puede decidir el tipo de grafo, la cantidad de no-dos, grado de entrada-salida de cada nodo, entre otras características.En el anexo B se presenta la configuración de los parámetros usadospor esta herramienta para generar los grafos de llamadas.

Como puede observarse en la tabla 7, se utilizaron por cada tamaño(de forma aproximada los tamaño son: 50, 100, 150 y 200 nodos) 3

tipos de grafos. El tipo de grafo out-tree, según Harary [1969], no esmás que un di-grafo que cumple con las siguientes características:(1) no contiene semi-ciclos y (2) contiene una raíz que representa elpunto de partida del resto de los nodos. Por otra parte, el tipo degrafo serie-paralelo, Dick et al. [1998] plantean que es un grafo quepresenta un nodo raíz del cual derivan un conjunto de cadenas denodos. Esta cadena de nodos está compuesta por uno o más nodosconectados en serie.

Para cada uno de los nodos y arcos de estos grafos se generaron losvalores de los costes de funciones y comunicación de forma aleatoria.Además, fueron generados también de forma aleatoria los valoresde los parámetros asociados a la arquitectura (∆) propuesta en laecuación 23.

Para estos experimentos se consideró una misma arquitectura paratodas las instancias. Además, el procesador general tendrá posibili-dades de contar con 2 características dinámicas. El coste de área ocu-pada por las características básicas se generó en un rango de [1..10].Para las características dinámicas se asumió que estas ocupan menosespacio que las características básicas, esta conjetura se realizó sobrela base que las características básicas obedecen a la estructura generaldel procesador (camino de datos y unidad de control), mientras quelas dinámicas son pequeños componentes. Teniendo en cuenta estoel área de hardware ocupada por las dos características dinámicas segeneró en el rango [1..12 ∗ cb

ah].La arquitectura contará además con tres tipos de buses. El ancho

de palabra de cada uno de ellos será tomado de forma aleatoria en-tre los anchos predefinidos {8, 16, 32, 64, 128, 256, 512}. Mientras queel tiempo de ciclo será generado en el rango [20..80]. Por último, seconsideró que la cantidad de coprocesadores permitidos podrá ser


igual que la cantidad de funciones presentes en el grafo de entraday la memoria disponible será considerada a partir de varios valores,según se muestra en la sección 4.2.

La arquitectura utilizada por cada uno de los cuatro tamaños esdiferente, mientras que para un mismo tamaño se utilizó la mismaarquitectura.

Los costes de funciones de las variables de software (CSW) fuerongenerados de la siguiente forma: el tiempo de ejecución de cada fun-ción (tsi) se generó en un rango de [1..30], la memoria ocupada (mei)entre [1..50] y la potencia consumida (psi) entre [1..20]. Asumiendoque cada uno de estos valores está en función de las característicasdinámicas que estén implementadas en el procesador, se generaronvalores de estos costes para cada una de las cuatro posibles combina-ciones (sin características, con cd1, con cd2 y con ambas) que generanlas dos características.

De forma similar se generaron los costes de hardware (CHW). Elárea de hardware ocupada por cada función (ahi) implementada enhardware se generó en el rango [1..100]. En el caso del tiempo de eje-cución (thi) y la potencia consumida (phi) se asume que estas songeneralmente más pequeñas que sus homólogas en software, por loque son generadas en el rango [1..12 ∗hti] y [1..12 ∗hpi] respectivamen-te.

A partir de los valores estimados se calculó el universo del discursopara cada una de las métricas en cada una de las instancias. La tabla8 muestra para cada una de las instancias el universo del discurso.Los valores máximos para el área, tiempo y potencia fueron genera-dos utilizando el algoritmo Escalador de colinas, con el objetivo demaximizar cada una de estas métricas; las cuales se evaluaron segúnlas ecuaciones 30,32 y 33.

4.1

or

ga

niz

ac

ió

nd

el

os

ex

pe

rim

en

to

s85

InstanciaÁrea Tiempo Memoria Potencia

Mínimo Máximo Mínimo Máximo Mínimo Máximo Mínimo Máximo

I1 30.0 2589.0 750.26 73235.37 0.0 1380.0 197.0 1170.0

I2 30.0 2474.0 996.03 81994.62 0.0 1236.0 161.0 1358.0

I3 30.0 2720.0 1428.40 75889.75 0.0 1188.0 191.0 1241.0

I4 30.0 2394.0 608.46 74430.0 0.0 1346.0 168.0 1104.0

I5 30.0 4777.0 1848.31 128402.37 0.0 2429.0 400.0 2844.0

I6 30.0 5253.0 3289.40 157253.0 0.0 2717.0 422.0 2713.0

I7 30.0 4841.0 997.68 80908.73 0.0 2736.0 257.0 1904.0

I8 30.0 4837.0 755.93 77001.87 0.0 2718.0 268.0 2016.0

I9 30.0 7447.0 5185.62 212832.5 0.0 3985.0 552.0 3731.0

I10 30.0 7625.0 6172.01 235526.39 0.0 4044.0 538.0 3898.0

I11 30.0 7476.0 5712.07 228826.25 0.0 3972.0 442.0 2982.0

I12 30.0 7156.0 3811.64 191960.51 0.0 3911.0 507.0 3413.0

I13 30.0 10535.0 8355.67 299166.51 0.0 5120.0 706.0 5142.0

I14 30.0 10087.0 6547.34 306897.75 0.0 5238.0 849.0 5232.0

I15 30.0 10136.0 7109.53 271318.43 0.0 5406.0 626.0 4240.0

I16 30.0 9924.0 6219.29 293883.62 0.0 5308.0 659.0 4520.0

Tabla 8 Universo del discurso para cada instancia generada.


4.1.3 Algoritmos metaheurísticos

Según el modelo definido en el capítulo 3, el CompBusq para buscarlas soluciones al problema HSP emplea algoritmos metaheurísticos.Para el caso de la instancia del modelo definida (sección 3.3), es nece-sario realizar una comparación entre varios algoritmos para determi-nar cuál se ajusta mejor al modelo. En esta comparación fueron utili-zados cuatro algoritmos. La decisión se fundamenta en los resultadosobtenidos en experimentos realizados previamente y publicados enDíaz-Pando et al. [2013a,b], donde se muestra que los algoritmos Bús-queda Aleatoria, Búsqueda Tabú y Recocido Simulado no ofrecieronbuenos resultados para las instancias del modelo. A continuación semuestran las principales características de los algoritmos utilizados.

• EC: Escalador de colinas mejor ascenso o primer ascenso [Jones,1995], este algoritmo permite mejorar una solución explorandosu vencindad de forma aleatoria y se acepta la mejor soluciónvecina si ésta no es peor que la anterior. El principal problemade este algoritmo radica en que puede quedarse estancado enun óptimo local sin posibilidades de salir de este.

• ECR: Escalador de colinas con reinicio [Rosete-Suárez, 2000],es una variante del anterior cuya principal ventaja es que esposible salir de los óptimos locales a partir de comenzar nue-vamente la búsqueda. Este algoritmo tiene dos parámetros, elprimero indica la forma en que será reiniciada la búsqueda(static_restar) y el segundo, en función del primero, estable-ce si el reinicio será por una cantidad fija de iteraciones o si esdespués de varias iteraciones con la misma solución (count_it).

• EE: Estrategia Evolutiva [Gottlieb and Raidl, 2006], este algorit-mo está basado en mutaciones. Emplea estrategias de seleccióny mutación al igual que ocurre en la reproducción asexual. Estealgoritmo mantiene un conjunto de individuos a y en cada itera-ción se obtienen nuevas soluciones aplicando mutaciones sobrela población. Luego se escogen las mejores soluciones, las cualesformarán la nueva población. De acuerdo con [Méndez and Mo-rales, 2008], el método de selección utilizado es el de selecciónpor truncamiento y el operador de mutación es el uniforme.


• AG: Algoritmo Genético [Goldberg, 1989], basado en el cru-zamiento. Emplea estrategias de selección, cruzamiento y mu-tación de forma similar a como ocurre en la reproducción se-xual. Este algoritmo tiene cuatro parámetros: población inicial(pob_ini), factor de truncamiento (trunc), probabilidad de cru-zamiento (pc) y probabilidad de mutación (pm). A partir de lapoblación inicial, se seleccionan un grupo de estas que seránlas utilizadas para generar las nuevas soluciones. De estas so-luciones se seleccionan aleatoriamente dos, las cuales se cruzande acuerdo con una probabilidad. Como resultado del cruza-miento se obtiene una posible solución la cual muta, tambiénde acuerdo con una determinada probabilidad, generando lanueva solución a evaluar. El método de selección utilizado es elde selección por truncamiento, el operador de cruzamiento y demutación es el uniforme.

A partir de encontrar la configuración de parámetros que garan-tizan obtener el mejor rendimiento (sección 4.2), cada uno de estosalgoritmos será ejecutado treinta veces por cada instancia. Cada unade estas ejecuciones termina luego de alcanzar una cantidad máximade evaluaciones (50000). Los resultados de estas ejecuciones serán uti-lizados para determinar el algoritmo que mejor se ajusta al modelo.

4.1.4 Métricas para evaluar el comportamiento de los algoritmos

Una vez ejecutados los algoritmos sobre los bancos de pruebas defi-nidos, es necesario establecer medidas que permitan evaluar el rendi-miento de los algoritmos, para así determinar qué algoritmo es mejorpara este problema. Para tales propósitos son utilizadas seis métricasfundamentales.

La primera de estas es la Calidad de la solución, a partir de la cuales posible determinar el menor valor como promedio obtenido porla función objetivo. Con esta métrica es posible evaluar el comporta-miento del algoritmo en la búsqueda de la mejor solución y se definecomo:

Cs =

∑ni=1 Irin

(39)


Donde n representa la cantidad de ejecuciones del algoritmo queserán realizadas, mientras que Iri representa el mejor valor de la fun-ción objetivo en cada ejecución. Como puede apreciarse, la métricaCalidad de la solución no es más que el promedio de los resultadosobtenidos en la evaluación de la función objetivo en cada una de lasejecuciones.

Métricas multi-objetivo para evaluar el comportamiento de los algoritmos

Debido a que el Índice de rendimiento se genera mediante la combi-nación de las métricas área y tiempo mediante la operación de multi-plicación (según la ecuación Ir = A ∗ T ), es posible realizar un análisisde las soluciones desde le punto de vista multiobjetivo.

Según Zitzler et al. [2000], definir una métrica que evalúe algorit-mos de optimización multi-objetivo, es más complejo que para el casode los mono-objetivo. Esto se debe en gran medida a que la evalua-ción en sí misma se corresponde con un problema multi-objetivo. Pa-ra lo cual se deben tener en cuenta tres objetivos fundamentales:

1. Minimizar la distancia entre PFknow y PFtrue. Asumiendo quese conoce este último.

2. Maximizar la dispersión de las soluciones encontradas para lo-grar una distribución suave y uniforme.

3. Maximizar la cantidad de elementos en PFknow.

De acuerdo con los comentarios anteriores y con los realizadospor Sarker and Coello Coello [2002], producir una única métrica escomplejo, por tanto es más apropiado usar diferentes métricas paraevaluar diferentes aspectos. En la actualidad son varios los trabajosque abordan el tema de las métricas para evaluar algoritmos multi-objetivos, ya sea para proponer nuevas métricas o para usar las exis-tentes en la evaluacion de los algoritmos. En estos casos se encuentranlos trabajos de Nath and Datta [2014], Arias-Montano et al. [2012],Datta and Figueira [2012], Schutze et al. [2012], Mateo and Alberto[2012], Alberto and Mateo [2011], Zitzler et al. [2003], van Veldhuizenand Lamont [2000], entre otros. A partir del estudio de estos, en estetrabajo se tendrán en cuenta aquellas métricas que han sido utilizadas


con más frecuencia, así como métricas menos frecuentemente usadaspero que forman parte de la base de los trabajos actuales.

Las métricas utilizadas en este análisis son: Tasa de error (Er) [vanVeldhuizen and Lamont, 1999], Distancia generacional (G) [van Veld-huizen and Lamont, 1998], Espaciado (ESS) [Schott, 1995], Tamañodel espacio cubierto (SSC) [Zitzler et al., 2000] y Cobertura [Zitzleret al., 2000].

Antes de continuar es necesario dejar claro los términos que seránutilizados para definir las ecuaciones siguientes. Sea X el espacio desoluciones a explorar y a ∈ X y b ∈ X dos soluciones factibles, se diceque a domina a b (a ≺ b), en un problema de minimización, si y solosi:

∀i ∈ {1, . . . ,n}|fi(a) 6 fi(b) ∧ (40)

∃j ∈ {1, . . . ,n}|fj(a) < fj(b)

En otras palabras la solución a domina a b si y solo si a es mejorque b en al menos un objetivo y mejor o igual en el resto.

De forma adicional se dice que a cubre a b (a � b) si y solo si a ≺ bo f(a) = f(b).

Basado en las definiciones anteriores, es posible definir las solucio-nes no dominadas y los óptimo de Pareto, como:

1. La solución a es no dominada con respecto a un conjunto X′ ⊆X si y solo si, no existe una solución en X′ que domine a a.Formalmente se define como: 6 ∃a′ ∈ X′|a′ ≺ a.

2. La solución a es un óptimo de Pareto si y solo si es no dominadacon respecto a X.

El conjunto de todas las soluciones óptimos de Pareto generadapor un algoritmo se denomina conjunto optimal de Pareto o frentede Pareto correspondiente a ese algoritmo. En la definición de lasecuaciones siguientes este conjunto se representará como FPk, es decirel frente de Pareto conocido y que está formado por las soluciones nodominadas generadas por un algoritmo determinado.

En varias de las ecuaciones que se definen a continuación es necesa-rio el conocimiento del frente optimal de Pareto global, o sea el frente


de Pareto del espacio de soluciones completo. En muchos casos y enparticular en el que se aborda en esta investigación, este frente no esconocido.

De acuerdo con esto y para poder utilizar las métricas, se conside-rará como frente global (FPtrue) al frente unificado formado por elconjunto de todas las soluciones no dominadas generadas por todoslos algoritmos. El frente de Pareto unificado (FPU) se define como:

1. Sea: A = {A1, . . . ,Ak},k > 1, el conjunto de todos los algoritmosmetaheurísticos aplicados al problema.

2. Sea FP = {FP1, . . . , FPk} el conjunto de todos los frentes de Pa-reto formados por las soluciones no dominadas de los k algorit-mos.

3. La solución a ∈ FP es del frente unificado si y solo si:

6 ∃a′ ∈ FP|a′ ≺ a (41)

La métrica Tasa de error, definida por van Veldhuizen and Lamont[1999], expresa la cantidad de soluciones no dominadas generadaspor un algoritmo que son parte del frente verdadero (FPtrue). Esamétrica se calcula como:

Er =

∑ni=1 ein

(42)

Donde, n es la cantidad de soluciones del frente de Pareto del al-goritmo k (FPk). Si la solución i es parte de FPtrue entonces ei = 0 yvale 1 en el caso contrario. El valor ideal para esta métrica es 0 o unocercano a este, lo cual significa que todas o la mayoría de las solucio-nes de FPk se encuentran en el frente verdadero FPtrue. Esta métricaestá dirigida a medir el objetivo 3 planteado anteriormente.

La Distancia generacional la cual se define por van Veldhuizen andLamont [1998], representa la distancia que existe entre el frente delalgoritmo y el frente verdadero y se calcula como:

G =

√∑ni=1 d

2i

n(43)


El término n, en la ecuación anterior representa la cantidad de so-luciones en el frente generado por el algoritmo k (FPk) y cada diequivale a la menor distancia entre la solución i de FPk y una solu-ción de FPtrue. Un valor de 0 para esta métrica indica que todas lassoluciones en FPk son parte de FPtrue. Esta métrica permitirá evaluarel aspecto 1.

La forma en que se distribuyen las soluciones sobre el frente dePareto (FPk) es determinada por la métrica Efficient Set Spacing (ESS)propuesta por Schott [1995]. Mediante esta métrica es posible evaluarel espaciado que existe entre las soluciones del frente del algoritmo.El espaciado se calcula como:

S =

√√√√ 1

n− 1

n∑i=1

(d− di)2 (44)

El término di = minj(|fi1 − f

j1|+ |fi2 − f

j2|), i, j = 1, . . . ,n, mientras

que d es la media de todos los di y n es la cantidad de solucionesen FPk. Un valor de 0 para esta métrica significa que todas las solu-ciones sobre el FPk están espaciadas de forma equidistantes. Comoes posible apreciar, esta métrica permitirá tener una medida sobre ladispersión de las soluciones encontradas (aspecto 2).

Zitzler and Thiele [1999], proponen una métrica que se denominaSize of the Space Covered (SSC). Esta métrica permite estimar el tamañoque cubre el conjunto de soluciones no dominadas encontradas den-tro del espacio de búsqueda. En otras palabras, se basa en calcularel área de la función objetivo que es cubierta por las soluciones nodominadas generadas por cada uno de los algoritmos.

En un problema con dos funciones objetivos, cada solución se defi-ne por los puntos (0, 0) y (f1(a), f2(a)), donde a ∈ PFk y (f1(a), f2(a))es el valor que corresponde con la evaluación de esta solución enlas dos funciones objetivo. Por tanto esta métrica se calcula comola unión de las áreas de todos los rectángulos formados por las so-luciones no dominadas generadas. Según Sarker and Coello Coello[2002], esta métrica intenta combinar en un único valor los tres aspec-tos anunciados previamente.

Por último, Zitzler and Thiele [1999], también proponen una mé-trica para comparar el rendimiento de dos algoritmos a partir de las


soluciones no dominadas generadas. En este caso las soluciones soncomparadas a partir de calcular la fracción de cada uno que es cubier-ta (o dominada) por el otro.

Sea FP1, FP2 ⊆ PF las soluciones no dominadas generadas por losalgoritmos A1 y A2. La función C asigna al par ordenado (FP1, FP2)un valor en el intervalo [0, 1]:

C(FP1, FP2) =| {a′′ ∈ FP2;∃a′ ∈ FP1|a′ � a′′} |

|FP2|(45)

Si C(FP1, FP2) = 1 significa que todos las soluciones en el frente dePareto FP2 están dominadas por o son iguales a las soluciones de FP1.Por otra parte, si C(FP1, FP2) = 0 significa que ninguna solución deFP2 está cubierto por FP1. Para determinar si un algoritmo es mejorque el otro con respecto a esta métrica es necesario probar las dosvariantes. De acuerdo con los resultados obtenidos, FP1 será mejorque FP2 si C(FP1, FP2) es notablemente mayor que C(FP2, FP1).

De acuerdo con las métricas empleadas, las conclusiones que seobtendrán serán conclusiones generales. Tal y como plantea Zitzleret al. [2003] estas conclusiones se expresan de la forma: “el conjuntode soluciones del algoritmo A domina estrictamente/domina/es me-jor que/domina débilmente al conjunto de soluciones del algoritmoB”. Es importante señalar que las conclusiones dadas a partir del aná-lisis de estas métricas no están enfocadas a determinar en qué medidael algoritmo A es mejor que el algoritmo B.

4.1.5 Análisis estadístico

El análisis estadístico utilizado en este trabajo permitirá decidir conun determinado nivel de certeza cuál es el algoritmo que mejor resul-tados ofrece en cada una de las métricas anteriores. Este análisis sebasa en las consideraciones planteadas por Derrac et al. [2011] y secaracteriza por:

1. Análisis multi-problema.

2. Pruebas de hipótesis.

3. Pruebas estadísticas no paramétricas.


El primer elemento indica que cada resultado obtenido en los ex-perimentos es considerado como un par algoritmo/problema.

Para sacar conclusiones sobre cuál es el mejor algoritmo, se utiliza-rán pruebas de hipótesis. En primer lugar se formula una prueba dehipótesis dirigida a determinar si existen diferencias entre el compor-tamiento de los algoritmos en general:

H0 : No existen diferencias significativas entre los algorit-mos.

Ha : Existen diferencias significativas entre los algoritmos.

En segundo lugar, para concluir sobre cuál es el mejor algoritmo sedefinen las siguientes hipótesis:

H0 : Los resultados del algoritmo X y el algoritmo Y soniguales para todos los problemas.

Ha : Los resultados de los algoritmos no son iguales paratodos los problemas.

Todas las pruebas de hipótesis se realizan con un nivel de signifi-cancia de α = 0 ,05.

La utilización de estadística no paramétrica está fundamentada enque no es posible asumir que los datos obtenidos en los experimen-tos siguen una distribución de probabilidades conocida. Estas prue-bas permitirán realizar un análisis de comparaciones múltiples conun método de control, al comparar todos los algoritmos en todas lasinstancias de problemas, obteniéndose el algoritmo que mejor desem-peño logró.

Para probar las hipótesis sobre el comportamiento general de losalgoritmos se utilizará la prueba de Friedman [Friedman, 1937, 1940].Esta prueba permite identificar, en el conjunto de los resultados de losalgoritmos para una métrica, si existen diferencias en el desempeñode al menos dos algoritmos.

Los resultados de esta prueba permitirán concluir sobre la existen-cia o no de diferencias significativas entre los algoritmos, identifican-do el que mejor rendimiento alcanzó (método de control). Para esto


el método asigna una clasificación a cada algoritmo en cada una delas instancias, teniendo en cuenta el valor de la métrica alcanzadopor ese algoritmo en la instancia. A partir de estas clasificaciones secalcula el estadístico de Friedman como:

Ff =12n

k(k+ 1)

∑j

R2j −k(k+ 1)2

4

(46)

donde k es la cantidad de algoritmos involucrados en la compara-ción, n es la cantidad de problemas y Rj es el promedio de todas lasclasificaciones obtenidas por el algoritmo j en todos los problemas.

A partir del cálculo de este estadístico, se obtiene un valor de pro-babilidad (valor p) a partir del cual, y teniendo en cuenta el nivelde significancia (α) fijado, se podrá concluir si existen o no diferen-cias significativas en la muestra. Si el valorp < α entonces es posibleconcluir que existen diferencias entre al menos dos de los cuatro al-goritmos estudiados.

Es necesario señalar que el resultado del estadístico de Friedmanno permitirá conocer cuál algoritmo es mejor. Para tales propósitos seaplicarán procedimientos posteriores (post-hoc) que permitirán identi-ficar si las diferencias en las clasificaciones entre el método de controly el resto de los algoritmos, son significativas para el nivel de signifi-cancia fijado para la prueba. Los métodos posteriores utilizados son:el método de Holm [1979] y el de Finner [1993].

Además, de acuerdo con las características de los resultados quese obtendrán al evaluar la métrica de cobertura, la prueba estadísti-ca utilizada será la de Wilcoxon [Derrac et al., 2011]. La prueba deWilcoxon se define como: sea di la diferencia entre el rendimiento dedos algoritmos en el i-ésimo de n problemas. Estas diferencias sonclasificadas de acuerdo con su valor absoluto, en caso de empates esposible aplicar cualquiera de los métodos disponibles en la literatura,según se explica en Derrac et al. [2011].

Sea R+ la suma de las clasificaciones para los problemas en que elprimer algoritmo mejora al segundo y R− el caso opuesto:

4.2 configuración inicial del modelo 95

R+ =∑di>0

rank(di) +1

2

∑di=0

rank(di)

R− =∑di<0

rank(di) +1

2

∑di=0

rank(di) (47)

Sea T la suma más pequeña, T = min(R+,R−), si T es menor oigual que el valor de la distribución de Wilcoxon para n grados delibertad, la hipótesis nula de igualdad de las medias se rechaza, locual significa que un algoritmo mejora al otro.

De acuerdo con la definición de la métrica presentada en la sec-ción 4.1.4, un algoritmo supera al otro si C(FP1, FP2) es notablemen-te mayor que C(FP2, FP1). Teniendo en cuenta esto, en la prueba deWilcoxon se asumirá como el rendimiento de un algoritmo al valorC(FP1, FP2) de ese algoritmo en cada uno de los problemas y como elrendimiento del otro algoritmo a C(FP2, FP1).

4.2 configuración inicial del modelo de partición hard-ware/software

La introducción de lógica difusa dota al modelo HSP presentado decierto nivel de flexibilidad, modelando las métricas que intervienencomo medidas difusas. De esta forma el diseñador es capaz de intro-ducir criterios que no son exactos y dependen de su nivel de experti-cia, durante la concepción y diseño del sistema.

Bajo el modelo presentado, se considera una buena solución aque-lla que garantice el menor Índice de rendimiento, lo cual implica lo-grar el menor valor en el compromiso entre el área consumida y eltiempo de ejecución del sistema. Estos niveles de rendimiento son po-sibles alcanzarlos estableciendo una configuración adecuada en losrangos de las variables difusas y los valores de restricciones estable-cidos en el modelo. Debido a la diversidad de variables presentes enel modelo y rangos de estas, encontrar la mejor configuración consti-tuye una tarea compleja, es por esto que se hace necesario analizar elcomportamiento del modelo según la configuración establecida y deacuerdo con el algoritmo de búsqueda utilizado y las característicasde la instancia del problema que se resolverá.


Para analizar el comportamiento del modelo, se diseñarán y ejecu-tarán una serie de experimentos, los cuales persiguen los siguientesobjetivos:

1. Identificar los factores más influyentes y sus interacciones quegaranticen el menor valor en el Índice de rendimiento.

2. Determinar la mejor configuración en cuanto a factores y nivelesque permitan lograr la calidad requerida en las soluciones.

Para dar cumplimiento a estos objetivos, se utilizará una estrategiade experimento factorial, la cual fue propuesta por Antony y Mont-gomery [Antony, 2003, Montgomery, 2009]. A continuación se expon-drán los elementos que se tuvieron en cuenta en el diseño y desa-rrollo del experimento, considerando en primer lugar la planificacióndel mismo. Finalmente, serán analizados los resultados para determi-nar la mejor configuración del modelo HSP según el algoritmo y lainstancia del problema.

4.2.1 Planificación

De acuerdo con la descripción del problema brindada con anterio-ridad, se considerará como variable de salida en el experimento lacalidad de la solución 39. Esta variable, expresada por la métrica Ín-dice de rendimiento en el modelo HSP, permite garantizar un equili-brio entre el área ocupada por el diseño y el tiempo de ejecución delmismo.

Teniendo en cuenta la variable de salida se han identificado diez(10) factores controlables que pudieran influir sobre el comportamien-to de la misma. Como puede observarse en 9, la mayoría de los facto-res se corresponden con los límites inferior y superior de la funciónde pertenencia seleccionada para cada una de las variables lingüísti-cas, así como con las restricciones que presenta el modelo. De acuerdocon Montgomery [2009], para determinar los factores e interaccionesinfluyentes, es suficiente con solo establecer dos niveles por cada fac-tor. El nivel bajo se estableció sobre el 25 % del valor máximo delrango de valores posibles, mientras que el nivel alto se estableció enel 75 %.


Como puede apreciarse, los niveles están expresados en función deun valor máximo. Este valor máximo (Vmax) está en correspondenciacon el valor máximo del universo del discurso para cada una de lasvariables lingüísticas (tabla 8). En general, los límites inferiores detodas las variables se considerarán en el rango [0..max/2], mientrasque para los superiores se considerará el rango (max/2..max].

Además el uso de los algoritmos ECR, AG y EE introduce paráme-tros asociados a estos que pudieran influir en el rendimiento de lavariable de salida. Teniendo en cuenta lo anterior, la tabla 10 presentalos niveles utilizados para estos factores.

Los dos primeros factores están relacionados con el algoritmo ECR,mientras que el resto están asociados al AG. Por otra parte, el algo-ritmo EE tiene asociados los factores: pob_ini, trunc y prob_mut.Existen factores para los cuales se desconocen sus valores mínimos ymáximos, esto está dado porque abarcan el espectro de los númerosenteros. En estos casos los valores de los niveles se corresponden conlos utilizados comúnmente en la bibliografía consultada.

4.2.2 Diseño

Debido al número de factores que se tendrán en cuenta, el experimen-to será dividido en dos etapas. En una primera etapa se procederá arealizar un escrutinio para determinar cuáles son los factores e inter-acciones que más influyen en el rendimiento del modelo. Mientrasque la segunda etapa consistió en determinar qué niveles deben fijar-se a cada factor para obtener el menor valor de la variable de salidaCs.

Para el experimento, se aplicó un diseño factorial fraccionado de2k−p aleatorizado, con k = 14 y p = 9, lo cual garantiza un total de 32

corridas. Además se realizaron por cada tratamiento un total de tresréplicas, lo que provocó que se generaran un total de 96 tratamientos.El anexo C presenta los tratamientos aplicados sobre cada uno de loscuatro algoritmos utilizados.

Los tratamientos fueron aplicados sobre el banco de prueba descri-to en la sección 4.1.2 y sobre los cuatro algoritmos empleados (sección4.1.3).


Factor Nombre Nivel bajo(L−)

Nivel alto(L+)

Límiteinferior área

αa 0,25 ∗ Vmax 0,75 ∗ Vmax

Límitesuperior

área

βa 0,25 ∗ Vmax 0,75 ∗ Vmax

Límiteinferiortiempo

αt 0,25 ∗ Vmax 0,75 ∗ Vmax

Límitesuperiortiempo

βt 0,25 ∗ Vmax 0,75 ∗ Vmax

Límiteinferior

memoria

αm 0,25 ∗ Vmax 0,75 ∗ Vmax

Límitesuperiormemoria

βm 0,25 ∗ Vmax 0,75 ∗ Vmax

Límiteinferior

potencia

αp 0,25 ∗ Vmax 0,75 ∗ Vmax

Límitesuperiorpotencia

βp 0,25 ∗ Vmax 0,75 ∗ Vmax

Restricciónmemoria

restm 0,25 ∗ Vmax 0,75 ∗ Vmax

Restricciónpotencia

restp 0,25 ∗ Vmax 0,75 ∗ Vmax

Tabla 9 Factores controlables asociados a la lógica difusa que influyen en elrendimiento del modelo.


Factor Nombre Nivel bajo(L−)

Nivel alto(L+)

Cantidad deiteraciones

count_it 500 1500

Reinicioestático

static_restart false true

Poblacióninicial

pob_ini 150 300

Factor detruncamien-

to

trunc 30 75

Probabilidadde mutación

pm 0.25 0.75

Probabilidadde

cruzamiento

pc 0.25 0.75

Tabla 10 Factores controlables asociados a los algoritmos que influyen en elrendimiento del modelo.


La configuración del experimento para cada algoritmo se muestraen el apéndice C, en las tablas 39, 40, 41, 42. Los parámetros de losalgoritmos fueron establecidos a partir de la configuración de cadatratamiento, realizando 50,000 evaluaciones en la función objetivo porcada tratamiento.

4.2.3 Análisis de los resultados

En esta sección serán analizados los resultados según las dos etapasdel experimento: escrutinio y configuración. En las secciones siguien-tes se analizan los factores y las interacciones de hasta orden II3 queinfluyen en el rendimiento del modelo, obtenido mediante el escru-tinio de todos los factores. La tabla donde se presentarán estos re-sultados contendrá los factores e interacciones influyentes ordenadossegún el nivel de influencia.

Además se obtendrá la configuración de factores y niveles que ga-rantice alcanzar el mejor valor de rendimiento por parte del modelo.Para mostrar estos resultados, los niveles que le corresponden a losfactores influyentes serán presentados con letra en negritas. Si bienel resto de los factores pudiera fijarse a cualquier nivel, puesto quesu influencia sobre el rendimiento del modelo no es significativo, enesta tabla se muestra un nivel que es el que será utilizado en los ex-perimentos siguientes.

Para realizar el análisis de los resultados de la ejecución de los expe-rimentos se utilizó el software estadístico Minitab4. Para obtener losfactores e interacciones influyentes en el rendimiento del algoritmo,fueron contrastadas las gráficas normal de efectos estandarizados conla gráfica de Pareto de efectos estandarizados, empleando un nivel designificancia α = 0,05. Mientras que para obtener la mejor configura-ción fueron utilizadas las gráficas de efectos principales, interaccióny cubos.

Análisis para el Algoritmo Genético

La tabla 11 muestra los factores e interacciones (hasta interacciones desegundo orden) que son significativas para algoritmo AG. Es posible

3 Están asociadas con las interacciones que se generan entre cada uno de los factores.4 www.minitab.com


apreciar en esta tabla, que para todas las instancias los factores másinfluyentes están relacionados con los parámetros de la función depertenencia utilizados, incluso por encima de los factores que estánvinculados con los algoritmos. En particular, destacar que el límiteinferior de la variable lingüística tiempo (αt) es el factor que se repitepara todas las instancias y el de mayor influencia en todas. Además,en la mayoría de las instancias aparece también el límite inferior delárea (αa), aunque en interacción con otro factor.

Los resultados anteriores pudieran tener sentido ya que los pará-metros asociados a la lógica difusa definen en qué medida los valoresde las métricas cumplen con las etiquetas definidas por la función depertenencia, quedaría solo determinar con qué nivel estos parámetrosgarantizan el mejor resultado.

La tabla 12 muestra la configuración en cada una de las instanciaspara obtener el mejor valor de la función objetivo. Los campos resal-tados representan aquellos factores que son influyentes, ya sean deforma independiente como en interacción con otro factor. Sobre estaconfiguración se debe destacar, como en todas las instancias en queson influyentes los factores αt y αa deberán estar en su valor bajopara garantizar el mejor valor en el rendimiento del modelo.

Es necesario resaltar, además el predominio, en general, del nivelalto en los factores influyentes, lo cual de acuerdo con la función depertenencia utilizada equivale a considerar pocas métricas con valo-res altos de pertenencia. En otras palabras el establecer estos umbra-les en su nivel alto está aceptando en la generalidad buenos valoresen las métricas.


Instancias Factores Interacciones

I1 αt, βp αa-pmI2 αt, αp, αaI3 αt

I4 αt αt-pob_ini

I5 αt, pc, restm, βm αa-pcI6 αt, αm, pc αa-αpI7 αt

I8 αt

I9 αt, αa, αm αa-βp, αa-pcI10 αt, αm, restp αa-pobiI11 αt, pc αa-restp, αa-αp,

αa-trunc, αa-αmI12 αt, αm, restm, trunc αa-pc, αa-αtI13 αt, αm, restm, trunc αa-βp, αa-pobi, αa-βaI14 αt, trunc αa-βaI15 αt, αm, pcI16 αt, restp, αm αa-pobi

Tabla 11 Factores e interacciones influyentes para el Algoritmo Genético.

4.2

co

nf

ig

ur

ac

ió

nin

ic

ia

ld

el

mo

de

lo

103

InstanciaFactores

αa βa αt βt αm βm αp βp restm restp pobi trunc pm pc

I1 b a b a a a b a b a b a b a

I2 b b b a a b a b a a b a a a

I3 b a b a a a b b b a a a a b

I4 a a b a a a a b b b a b a b

I5 a a b a a b a b a a b a a a

I6 b a b a a a a a a a a b a a

I7 b a b b a a b b a a b b a a

I8 b b b a a b a a a a a b a b

I9 b a b a a b a a b a b a b b

I10 b a b b a b a a a a b a a a

I11 a a b a a a a b b a b a b a

I12 b a b a a b b a b a a b b b

I13 a a b a a b a a a a a a b a

I14 a a b b a b b b b a b a a a

I15 a a b b a a a a a b b b a a

I16 b a b b a b a b a a b a b a

Tabla 12 Niveles de los factores para minimizar el rendimiento en el algoritmo Genético.


Análisis para el algoritmo Estrategia Evolutiva

Las tablas 13 y 14 muestran los factores e interacciones (hasta inter-acciones de segundo orden) que son significativas y los niveles paracada uno de estos para algoritmo EE. Al igual que el AG en este al-goritmo los factores αt y alphaa son influyentes en más de la mitadde las instancias analizadas, en el caso particular de este algoritmo seadiciona el factor restp.

Para el caso del factor αt siempre se fija en el nivel bajo, mientrasque en la mayoría de los casos en que el factor restp es influyente sefija en el nivel alto. Por último el factor αa en la mitad de las vecesen que es considerado como influyente se fija en su nivel bajo.



I1 αt, trunc αa-βtI2 αt, restp αa-βt, βa-βtI3 αt, βm, αa, βa, restp, αp βa-pm, βa-trunc, αa-βm,

αa-αm, αa-pmI4 αt, restmI5 αt, trunc αa-βtI6 αt, restp αa-βt, βa-βtI7 αt, βm, αa, βa, restp, αp βa-pm, βa-trunc, αa-βm,

αa-αm, αa-pmI8 αt, restmI9 αt, restp, restm, αmI10 αt, restp αa-βtI11 αt, restpI12 αt, pm, αa, restp αa-restm, αa-αt,

αa-trunc

I13 αt, restp, restm αa-βpI14 αt, restp, βp, αp, αm αa-βaI15 αt, restp βa-pm, αa-βtI16 αt, restp, βp, restm βa-trunc, αa-βa

Tabla 13 Factores e interacciones influyentes para el algoritmo EstrategiaEvolutiva.

106

ex

pe

rim

en

to

sy

re

su

lt

ad

os

InstanciaFactores

αa βa αt βt αm βm αp βp restm restp pobi trunc pm

I1 a b b a a a b a a a a a a

I2 a b b b a a a a b a b b a

I3 b b b b b a b b a a a b b

I4 b b b b a a b b a a a a b

I5 b b b b a a a a a a a a b

I6 a a b b a a a a a a a b b

I7 a b b b a a a a a b a b a

I8 a a b b a b a a a a a a b

I9 a a b a a b a b b a b a b

I10 b b b a a a b a a a b a b

I11 a b b a a a b a a a b b a

I12 a b b b a a a a a a b a b

I13 a a b b a a a b a a b a b

I14 b b b b a a a b a a b a a

I15 b a b a a a a a a a a b b

I16 b a b a a a a a a a a b b

Tabla 14 Niveles de los factores para minimizar el rendimiento en el algoritmo Estrategia Evolutiva.


Análisis para el algoritmo Escalador de Colinas con Reinicio

La tabla 15 muestra los factores e interacciones (hasta interaccionesde segundo orden) que son significativas para algoritmo ECR. Deacuerdo con esta tabla, el factor que mayor porcentaje de influenciapresenta es el αt, el cual influye en todas las instancias. Mientras quelos factores αa y restm tienen una influencia significativa en más dela mitad de las instancias.

Por otra parte la tabla 16 muestra los niveles que se fijarán en cadafactor para cada una de las instancias. Se debe destacar en esta tablaque el factor αt, en todas las instancias donde es influyente se fijaen su nivel bajo. Mientras que en el 85 y 100 por ciento de las vecesdonde αa y restm respectivamente son influyentes se fijan en su nivelalto.

A partir de los resultados anteriores es necesario hacer notar quede acuerdo con la configuración de los parámetros αt y βt estos pu-dieran estar actuando como restricciones a la métrica tiempo, ya quepuestos los dos en su nivel bajo, poca soluciones tendrán un tiempoconsiderado como bajo. De forma similar ocurre con el parámetroαa el cual al estar fijado en la mayoría de los casos a su valor altoes posible predecir que el algoritmo se está moviendo en un espaciode búsqueda donde las soluciones están dominadas por la métricatiempo (T ).



I1 αt, βm, αp αa-αm, αa-βt, αa-βaI2 αt αa-βpI3 αt, βa, staticrest, βm,

countit

βa-αt, αa-staticrestart,βa-staticrestart,αa-restp, αa-βm

I4 αt, restm αa-countit, αa-βpI5 αt, βmI6 αt, restm, βm, αm αa-staticrest

I7 αt, restp αa-βt, αa-βaI8 αt, restp, αp, βa, αm αa-βtI9 αt, restp, restm αa-βtI10 αt, restm, βm, αa, restp αa-βt, αa-count_it,

αa-βmI11 αt, βm, restm αa-βaI12 αt, restm, αa αa-βt, αa-αmI13 αt, restm, restp αa-restm, αa-βtI14 αt, βm, restm αa-βt, αa-αmI15 αt, restm, αa, βm αa-αp, αa-restm,

αa-static_rest

I16 αt, restp, restm

Tabla 15 Factores e interacciones influyentes para el algoritmo Escalador deColinas con Reinicio.

4.2

co

nf

ig

ur

ac

ió

nin

ic

ia

ld

el

mo

de

lo

109

InstanciaFactores

αa βa αt βt αm βm αp βp restm restp count_it static_rest

I1 a a b b a b a b a a b b

I2 a a b a a a a a a a b a

I3 b b b a b b b b a a b b

I4 a a b a a a b a a a b b

I5 a a b b b a a a a a b b

I6 a b b b b a a a a b b a

I7 a b b b b a b b a b a a

I8 a b b a a a a b a a b b

I9 a a b b b a b a a a b b

I10 a a b b a a b a a a b b

I11 a b b b a a b b a a a a

I12 b b b a a a a a a a b a

I13 a a b b a a a b a a b b

I14 a a b b a a b b a a b a

I15 a a b a a a a a a a b b

I16 b a b b a a a a a a b b

Tabla 16 Niveles de los factores para minimizar el rendimiento en el algoritmo Escalador de Colinas con Reinicio.


Análisis para el algoritmo Escalador de Colinas

La tabla 17 muestra los factores e interacciones (hasta interacciones desegundo orden) que son significativas para algoritmo EC. De acuerdocon esta tabla, el factor que mayor porcentaje de influencia presenta esel αt, el cual influye en todas las instancias. Mientras que los factoresαp y αa tienen una influencia significativa en más de la mitad de lasinstancias.

Por otra parte, la tabla 18 muestra los niveles que se fijarán en cadafactor para cada una de las instancias. En esta tabla, al igual que parael resto de los algoritmos, el factor αt, en todas las instancias dondees influyente se fija en su nivel bajo. Mientras que en el 91.6 y 72.7 porciento de las veces donde αp y αa respectivamente son influyentes sefijan en su nivel alto y bajo respectivamente.

A partir de los resultados anteriores es necesario hacer notar que deacuerdo con la configuración de los parámetros αt y βt, αa y βa estospudieran estar actuando como restricciones a la métrica tiempo y árearespectivamente. Esto está dado porque los cuatro factores se ponenla mayor parte de las veces en su nivel bajo. Esto pudiera provocarque existirán muy pocas soluciones con un tiempo y área consideradocomo bajo. En este caso sería posible predecir que el algoritmo semueve en un espacio donde existe cierto equilibrio entre estas dosmétricas.



I1 αt βa-βm, αa-βpI2 αt βa-αm, αa-αp, αa-βp,

αt-αpI3 αt αa-βt, βa-βm, αt-αpI4 αt,αm,βt αa-βm, αa-βtI5 αt, restm, αp βa-αtI6 αt, αa, restm αa-αt, αa-βp, αa-restp,

αt-αpI7 αt βa-αt, αt-αpI8 αt,restp,βa αt-αm, αt-βmI9 αt, αa βa-βp, αa-βt, αa-βp,

αt-αp, βa-βm, αa-αt,βa-αm

I10 αt, restm, restp, αp αa-βpI11 αt, restm, restp αt-αpI12 αt αt-αpI13 αt, restm, restp, αm βa-βm, αa-βt, αt-αp,

αa-βp, αa-restmI14 αt, restm αt-αp, αa-βt, βa-βm,

αa-βp, βa-αm, αt-αm,αa-αp

I15 αt, restm, restp, αm αa-βp, αt-αp, αa-restpI16 αt, restp αt-αp, αa-βp

Tabla 17 Factores e interacciones influyentes para el algoritmo Escalador deColinas.

112

ex

pe

rim

en

to

sy

re

su

lt

ad

os

InstanciaFactores

αa βa αt βt αm βm αp βp restm restp

I1 b b b a a b b a a a

I2 b b b a b b a a a b

I3 b b b b a a a b a a

I4 b a b b b a a a a a

I5 a b b a a a a a a a

I6 a a b a a a a b a a

I7 a a b a a b a a a b

I8 b b b a b a a a a a

I9 b b b b b a a a b a

I10 a b b a a a a b a a

I11 a b b a a b a a a a

I12 a b b a a a a a a a

I13 b b b b b a a a a a

I14 b b b a a b b a a a

I15 b b b b b a a a a a

I16 a b b b a a a b a a

Tabla 18 Niveles de los factores para minimizar el rendimiento en el algoritmo Escalador de Colinas.

4.3 análisis estadístico 113

4.3 análisis estadístico

A continuación en esta sección se presentarán los resultados obteni-dos en el análisis estadístico de cada una de las métricas. En cadasección se presentará en primer lugar los resultados de cada métrica,luego se presentarán los resultados obtenidos al aplicar la prueba deFriedman y finalmente los resultados de los procedimientos posterio-res. Al finalizar cada sección se plantearán conclusiones parciales.

4.3.1 Calidad de la solución

La tabla 19 muestra los resultados de los algoritmos en cuanto alpromedio de la calidad de la solución, obtenido luego de ejecutar loscuatro algoritmos sobre las 16 instancias de problemas del banco deprueba.


Instancia GA EE EC ECR

1 1,22 · 107 1,69 · 107 1,04 · 107 1,21 · 107

2 1,32 · 107 1,48 · 107 1,32 · 107 1,57 · 107

3 1,32 · 107 1,35 · 107 1,22 · 107 1,30 · 107

4 1,17 · 107 1,23 · 107 9,13 · 106 1,23 · 107

5 4,54 · 107 3,61 · 107 4,31 · 107 4,40 · 107

6 4,11 · 107 6,81 · 107 5,18 · 107 5,11 · 107

7 2,50 · 107 2,49 · 107 2,40 · 107 2,93 · 107

8 2,12 · 107 2,57 · 107 1,91 · 107 2,55 · 107

9 1,08 · 108 1,03 · 108 1,29 · 108 1,00 · 108

10 9,76 · 107 1,02 · 108 1,09 · 108 1,16 · 108

11 1,10 · 108 1,53 · 108 9,97 · 107 1,05 · 108

12 9,89 · 107 1,31 · 108 9,43 · 107 7,35 · 107

13 2,70 · 108 2,08 · 108 1,75 · 108 1,91 · 108

14 2,30 · 108 2,01 · 108 1,76 · 108 2,13 · 108

15 1,83 · 108 1,59 · 108 1,44 · 108 2,00 · 108

16 1,87 · 108 1,75 · 108 1,74 · 108 1,61 · 108

Tabla 19 Promedio de calidad de la solución en las 16 instancias.

Para determinar si existen diferencias significativas entre las me-dias de las muestras obtenidas se aplica la prueba de Friedman. En latabla 20 se presentan los resultados obtenidos por cada una de estaspruebas.

Como puede observarse, el valor p es menor que el nivel de signi-ficancia fijado para la prueba (α = 0,05), lo cual indica que la pruebaes significativa, pudiendo concluir que al menos uno de los algorit-mos tiene un rendimiento diferente al resto. El algoritmo EC es elque alcanza una mejor clasificación, como promedio, por lo que seráutilizado como método de control para el análisis en los post-hoc.

A partir de estos resultados y con el objetivo de determinar si elEC es mejor que el resto de los algoritmos, fueron aplicados los pro-cedimientos post-hoc descritos en la sección 4.1.5.


Algoritmo Clasificación de Friedman

GA 2.81

EE 2.94

EC 1.63

ECR 2.63

valor p 0.016368

Tabla 20 Clasificaciones obtenidas por la prueba de Friedman. Métrica: cali-dad de la solución.

Friedman unadjusted Holm Finner

EE 0.0040 0.0121 0.0121

GA 0.0093 0.0186 0.0139

ECR 0.0285 0.0285 0.0285

Tabla 21 Valores p ajustados para la prueba de Friedman, con Escalador deColinas como método de control. Métrica: calidad de la solución.

Como puede apreciarse en la tabla 24, los valores p obtenidos alaplicar los métodos de Holm y Finner son menores que el nivel designificancia. De acuerdo con este resultado, es posible concluir quelas diferencias en las clasificaciones obtenidas por Friedman son sig-nificativas entre el método de control EC y el resto de los algoritmos.En otras palabras, el EC, en general, logra mejores valores de calidadde la solución en todos los problemas, en comparación con el restode los algoritmos.

4.3.2 Tasa de error

La tabla 22 muestra la tasa de error obtenida a partir de la ecuación42, para los cuatro algoritmos en cada una de las instancias.


Algoritmo GA EE EC ECR

1 0.38 0.50 0.87 1.00

2 0.46 1.00 0.98 0.12

3 0.48 1.00 0.71 0.53

4 0.31 1.00 0.41 0.59

5 0.21 1.00 0.92 1.00

6 0.00 1.00 1.00 1.00

7 0.42 1.00 0.81 0.54

8 0.33 1.00 0.48 0.88

9 0.46 1.00 1.00 0.00

10 0.00 1.00 1.00 1.00

11 0.00 1.00 1.00 1.00

12 0.67 1.00 0.98 0.07

13 0.00 1.00 0.79 0.70

14 0.56 1.00 0.17 0.51

15 0.25 1.00 0.77 1.00

16 0.45 1.00 1.00 0.04

Tabla 22 Tasa de error del frente de Pareto de cada algoritmo con respectoal frente unificado.

La tabla 23, nuestra los resultados de la prueba de Friedman. Esposible concluir que existen diferencias significativas entre las clasifi-caciones de al menos dos algoritmos. El algoritmo AG es el que mejorpromedio de clasificaciones alcanza entre los cuatro analizados.

Al aplicar los procedimientos posteriores es posible destacar queel algoritmo AG, como método de control, mejora considerablementeel rendimiento del resto de los algoritmos para el caso de la métricatasa de error. Este resultado expresa que en general el AG, generasoluciones que luego estarán en el frente de Pareto unificado, es decir,genera mayor cantidad de soluciones no dominadas.



GA 1.375

EE 3.5625

EC 2.6875

ECR 2.375

valor p 0.000032

Tabla 23 Clasificaciones obtenidas por la prueba de Friedman. Métrica: tasade error.


EE 0.000002 0.000005 0.000005

EC 0.004033 0.008067 0.006044

ECR 0.02846 0.02846 0.02846

Tabla 24 Valores p ajustados para la prueba de Friedman, con AlgoritmoGenético como método de control. Métrica: tasa de error.

4.3.3 Distancia generacional

Los valores obtenidos de la distancia de los frentes de Pareto de cadauno de los algoritmos por cada una de las instancias se muestran enla tabla 25.



1 5.44 7.07 7.60 7.45

2 5.96 6.90 4.66 2.63

3 4.22 6.20 4.78 3.83

4 3.44 7.91 4.21 4.04

5 3.91 7.07 4.98 5.77

6 0.00 7.91 6.45 5.98

7 4.17 6.09 5.04 3.72

8 5.27 6.74 3.95 5.93

9 4.21 7.25 5.20 0.00

10 0.00 6.45 4.94 6.59

11 0.00 7.25 4.34 4.15

12 5.63 15.81 4.61 1.66

13 0.00 5.98 4.51 4.83

14 3.93 6.74 3.04 3.30

15 3.23 11.95 5.44 5.13

16 6.43 10.00 4.43 1.17

Tabla 25 Distancia generacional del frente de Pareto de cada algoritmo conrespecto al frente de Pareto Unificado.

Al aplicar la prueba de Friedman esta demuestra con una proba-bilidad relativamente alta (valorp � α) que existen diferencias encuanto a la distancia a la que se encuentra el frente de cada unode los algoritmos del frente unificado. Como puede observarse (ta-bla 26), el algoritmo con mejor promedio en las clasificaciones es elAG, el cual será tenido en cuenta en los métodos posteriores paradeterminar entre que algoritmos la diferencia de las clasificaciones essignificativa.

Al aplicar los procedimientos posteriores (tabla 27), es posible cons-tatar que existen diferencias significativas con el algoritmo EE. Estosignifica que las soluciones no dominadas generadas por el AG seencuentran más cerca del frente unificado que las del algoritmo EE.



GA 1.75

EE 3.8125

EC 2.4375

ECR 2

valor p 0.000021

Tabla 26 Clasificaciones obtenidas por la prueba de Friedman. Métrica: dis-tancia generacional.


EE 0.000006 0.000019 0.000019

EC 0.132006 0.264013 0.191323

ECR 0.583882 0.583882 0.583882

Tabla 27 Valores p ajustados para la prueba de Friedman, con AlgoritmoGenético como método de control. Métrica: tasa de error.

Por otra parte, no existe una diferencia significativa entre el AG y ECy ECR, representando que el AG no mejora a estos dos algoritmos.

4.3.4 Dispersión

La tabla 28 presenta los resultados alcanzados por cada uno de losalgoritmos en cuanto a la forma en que distribuyen sus solucionessobre el frente de Pareto.



1 187.07 250.97 431.07 397.88

2 280.08 294.12 229.42 2176.29

3 1504.10 230.91 284.87 96.14

4 479.34 449.66 317.89 787.89

5 703.79 713.75 267.35 759.72

6 458.27 706.43 404.95 795.61

7 440.75 321.62 756.73 334.77

8 716.08 351.28 230.57 148.48

9 2361.98 3891.11 413.22 627.64

10 1192.94 513.79 635.27 649.63

11 897.85 961.53 461.16 223.60

12 1374.67 1829.98 469.62 1991.26

13 2424.57 477.34 347.06 710.07

14 1161.89 2817.03 431.42 1773.61

15 2171.01 714.94 748.70 1006.21

16 1203.25 7079.03 820.74 662.00

Tabla 28 Valores de dispersión de cada uno de los frentes de Pareto de cadaalgoritmo.

La prueba de Friedman realizada sobre estos datos, arrojó que noexisten diferencias significativas en las clasificaciones de los algorit-mos para todas las instancias (valorp > 0,05), aunque el EC es el quemejor clasificación obtiene como promedio. Esto quiere decir que loscuatro algoritmos distribuyen de forma similar sus soluciones sobresu frente de Pareto.

4.3.5 Tamaño del espacio cubierto

La tabla 30 presenta el área cubierta por cada uno de los algoritmos.



GA 2.875

EE 2.625

EC 1.8125

ECR 2.6875

valor p 0.094725

Tabla 29 Clasificaciones obtenidas por la prueba de Friedman. Métrica: dis-persión.


1 8,32 · 106 5,89 · 106 8,89 · 106 7,96 · 106

2 8,90 · 106 1,48 · 107 2,21 · 107 1,09 · 107

3 2,11 · 107 1,66 · 107 8,84 · 106 8,42 · 106

4 7,44 · 106 1,11 · 107 7,72 · 106 1,08 · 107

5 3,35 · 107 6,47 · 107 4,11 · 107 4,61 · 107

6 1,81 · 107 5,56 · 107 7,29 · 107 6,33 · 107

7 2,89 · 107 3,53 · 107 4,26 · 107 3,32 · 107

8 1,66 · 107 2,83 · 107 1,77 · 107 1,85 · 107

9 1,77 · 108 1,92 · 108 2,13 · 108 1,20 · 108

10 7,77 · 107 1,25 · 108 1,72 · 108 1,35 · 108

11 1,11 · 108 1,36 · 108 1,49 · 108 1,69 · 108

12 1,58 · 108 1,30 · 108 1,20 · 108 8,49 · 107

13 1,94 · 108 2,82 · 108 2,15 · 108 2,86 · 108

14 4,21 · 108 3,89 · 108 2,11 · 108 3,23 · 108

15 2,11 · 108 3,07 · 108 1,57 · 108 2,62 · 108

16 1,92 · 108 2,52 · 108 3,71 · 108 1,85 · 108

Tabla 30 Área cubierta por los frentes de Pareto de cada algoritmo en cadainstancia.

Al igual que en el caso anterior, en este, la prueba de Friedmanrealizada sobre los datos, arrojó que no existen diferencias significa-



GA 1.875

EE 2.9375

EC 2.8125

ECR 2.375

valor p 0.083011

Tabla 31 Clasificaciones obtenidas por la prueba de Friedman. Métrica: ta-maño del espacio cubierto.

tivas en las clasificaciones de los algoritmos para todas las instancias(valorp > 0,05). En el contexto de este trabajo representa que los fren-tes de Pareto de todos los algoritmos abarcan un área similar. La tabla31 presenta los resultados luego de aplicar dicha prueba.

4.3.6 Cobertura

Los resultados de la cobertura para cada par de algoritmos, se mues-tran en las tablas 32 y 33.

La tabla 34muestra el valor p calculado en cada comparación po-sible. Al analizar los resultados de la prueba de Wilcoxon es posibleconcluir que el algoritmo AG mejora significativamente el rendimien-to del resto de los algoritmos. Mientras que EE mejora a ECR pero notiene diferencias significativas con EC, al igualqeu ocurre entre EC yECR.

Estos resultados implican que las soluciones del AG, en general,cubren a las soluciones del resto de los algoritmos; por lo cual esposible concluir que para esta métrica AG es mejor que el resto.

A partir de el análisis de las métricas y en aras de establecer si exis-te un algoritmo que mejore al resto en todas las métricas, se muestrala tabla 36. En esta tabla se muestra a modo de resumen las clasifi-caciones obtenidas por cada algoritmo en cada una de las métricas,independientemente de si las diferencias entre las clasificaciones ob-tenidas en una métrica fueron significativas. el objetivo principal deesta tabla resumen es determinar si existe un algoritmo que mejore alresto en todos o en la mayoría de los casos.


Algoritmo GA-EE EE-GA GA-EC EC-GA GA-ECR ECR-GA

1 0.40 0.23 0.80 0.15 1.00 0.00

2 1.00 0.00 0.98 0.00 0.12 0.46

3 0.33 0.11 0.62 0.19 0.06 0.44

4 1.00 0.00 0.98 0.00 0.53 0.04

5 1.00 0.00 0.92 0.21 1.00 0.00

6 1.00 0.00 1.00 0.00 0.97 0.00

7 0.85 0.00 0.49 0.13 0.30 0.17

8 1.00 0.00 0.84 0.00 0.77 0.00

9 0.32 0.12 1.00 0.00 0.00 0.46

10 1.00 0.00 1.00 0.00 1.00 0.00

11 1.00 0.00 1.00 0.00 1.00 0.00

12 0.89 0.00 1.00 0.00 0.03 0.38

13 0.64 0.00 0.44 0.00 0.64 0.00

14 0.18 0.31 0.17 0.56 0.15 0.53

15 1.00 0.00 1.00 0.00 1.00 0.00

16 1.00 0.00 1.00 0.00 0.57 0.00

Tabla 32 Cobertura alcanzada por cada uno de los frentes de Pareto de cadaalgoritmo en cada instancia (I).


Algoritmo EE-EC EC-EE EE-ECR ECR-EE EC-ECR ECR-EC

1 0.47 0.40 0.83 0.20 0.89 0.13

2 0.16 0.48 0.00 1.00 0.00 0.80

3 0.09 0.92 0.00 1.00 0.29 0.29

4 0.18 0.88 0.00 1.00 0.94 0.00

5 0.00 1.00 0.00 1.00 0.33 0.62

6 0.00 1.00 0.00 1.00 0.00 1.00

7 0.41 0.33 0.13 0.33 0.53 0.13

8 0.51 0.18 0.40 0.27 0.93 0.00

9 0.59 0.21 0.00 1.00 0.00 0.86

10 0.35 0.04 0.00 1.00 0.00 1.00

11 0.35 0.00 0.00 1.00 0.00 1.00

12 0.30 0.25 0.16 0.50 0.84 0.11

13 0.00 1.00 0.02 0.93 0.83 0.00

14 0.00 1.00 0.00 1.00 0.47 0.11

15 0.78 0.57 0.49 0.43 0.83 0.00

16 0.78 0.10 0.38 0.20 0.40 0.31

Tabla 33 Cobertura alcanzada por cada uno de los frentes de Pareto de cadaalgoritmo en cada instancia (II).

Comparación valor p

AG-EE 0.001

AG-EC 0.001

AG-ECR 0.014

EE-EC 0.339

EE-ECR 0.004

EC-ECR 0.979

Tabla 34 Resultados de la prueba de Wilcoxon. Métrica: Cobertura.


Métrica GA EE EC ECR

Calidad 3 4 1 2

Error 1 4 3 2

Distancia 1 4 3 2

Dispersión 4 2 1 3

Tamaño 1 4 3 2

Cobertura 1 4 3 2

Tabla 35 Resultados globales de las clasificaciones de los algoritmos por ca-da métrica.

Algoritmo Clasificación

GA 1.8333

EE 3.6667

EC 2.3333

ECR 2.1667

valor p 0.071898

Tabla 36 Clasificaciones obtenidas para los resultados globales.

Al igual que con el resto de las métricas, al comportamiento glo-bal de los algoritmos se le realizó la prueba de Friedman para de-terminar si existen diferencias significativas entre las clasificacionesalcanzadas por cada algoritmo. La tabla 36 muestra los resultados ob-tenidos por la prueba de Friedman, donde es posible apreciar que noexisten evidencia para rechazar la hipótesis nula de igualdad entrelos algoritmos.

A partir de los resultados es posible concluir que no existe un al-goritmo que sea significativamente mejor que el resto en todas lasmétricas. Por lo cual es posible plantear que los dos nuevos algorit-mos propuestos (EC y ECR) son igual de válidos que el AG pararesolver el problema HSP.


4.4 contribución al frente de pareto unificado

A partir de resultados obtenidos en experimentos previos, cuyos re-sultados fueron publicados en Díaz-Pando et al. [2013a] y Díaz-Pandoet al. [2013b], en esta sección se presenta un enfoque novedoso paraanalizar las contribuciones de cada algoritmo al frente unificado dePareto. En estos artículos es posible apreciar que los algoritmos de-terminan el tipo de solución en el frente unificado. Esto está dadoporque existen algoritmos que sus soluciones están dominadas por lamétrica tiempo (alcanzan soluciones con un menor valor de tiempo)y otros por el área (alcanzan soluciones con un menor valor de área).

De acuerdo con esos resultados, este análisis será incluido en estainvestigación a fin de determinar si bajo la instancia del modelo pro-puesta el comportamiento es similar a los resultados anteriores. Lasfiguras 17 y 18, muestran el frente unificado de algunas de las ins-tancias estudiadas. Para el resto de las instancias, el comportamientoes similar, aunque se muestran solo estas para hacer el análisis mássimple.

Como puede observarse en las gráficas, el comportamiento de losalgoritmos es similar, es decir, es posible distinguir de forma claracómo existe una tendencia a cubrir determinadas regiones del frenteunificado. Las soluciones del algoritmo ECR están dominadas por elárea, el algoritmo AG aporta soluciones dominadas por el tiempo yel EC que la mayor parte de sus soluciones se encuentran en el centrodel frente.

4.4 contribución al frente de pareto unificado 127

Tiempo

Área

AGEEEC

(a) Instancia 1

Tiempo

Área

AGEC

ECR

(b) Instancia 2

Tiempo

Área

AGEC

ECR

(c) Instancia 3

Tiempo

Área

AGEC

ECR

(d) Instancia 4

Figura 17 Frente optimal de Pareto unificado para las primeras cuatro ins-tancias estudiadas.


Tiempo

Área

AGEC

ECR

(a) Instancia 7

Tiempo

Área

AGEC

ECR

(b) Instancia 12

Tiempo

Área

AGEC

ECR

(c) Instancia 14

Figura 18 Frente optimal de Pareto unificado de otras instancias.

Este comportamiento aporta a la solución del problema HSP unnuevo enfoque, siendo este el de utilizar varios algoritmos de acuerdoal tipo de solución que desee lograr el diseñador. Este enfoque demulti-algoritmo resulta novedoso y no había sido reportado en laliteratura previamente.

4.5 conclusiones

Al término de este capítulo se concluye que:

1. A partir del análisis estadístico realizado, en cada una de lasmétricas, es posible plantear que los algoritmos EC y ECR, en

4.5 conclusiones 129

general, se compartan de forma similar al AG para solucionarel problema HSP.

2. En el caso de la métrica calidad de la solución, los resultados delas pruebas estadísticas mostraron que el algoritmo EC presentauna diferencia significativa con respecto al resto, lo cual indicaque este algoritmo es mejor que el resto de los estudiados.

3. El AG es el mejor en cuanto a la cantidad de soluciones no do-minadas aportadas al frente de Pareto unificado (tasa de error).

4. Los valores de distancia generacional alcanzados por el AG entodas las instancias son mejores que los del algoritmo EE, mien-tras que son similares con respecto a los algoritmos EC y ECR.

5. Todos los algoritmos estudiados alcanzan valores similares paralas métricas: Dispersión, Tamaño del espacio cubierto y Cober-tura.

6. En el análisis del frente de Pareto unificado se pudo constatarque los algoritmos tienden a dominar porciones bien definidasde este (soluciones dominadas por el tiempo, por el área y en elcentro).

7. En general, si se desean obtener soluciones donde el Tiempode ejecución sea el menor el AG es el más indicado, mientrasque si se necesitan soluciones con bajo consumo de Área de Hwel ECR es el que aporta mayor cantidad de soluciones en esaregión; el EC tiende a alcanzar soluciones hacia el centro delfrente unificado.

8. La utilización de varios algoritmos metaheurísticos para resol-ver el problema HSP le aporta al diseñador un mayor abanico deposibilidades para tomar la decisión sobre la implementación arealizar.

9. El diseño estadístico de experimentos aporta argumentos paradeterminar la mejor configuración de los parámetros en los al-goritmos metaheurísticos.


10. La utilización de estadística no paramétrica permite discriminarla pertinencia (o preferencia) de un algoritmo sobre otro para unproblema particular.

5C A S O D E E S T U D I O

El objetivo de este capítulo radica en evaluar la propuesta de instan-cia de modelo y los nuevos algoritmos introducidos utilizando unaaplicación real, en lugar de las simuladas utilizadas en el capítuloanterior. De forma adicional se pretende comparar la propuesta deeste trabajo con otras propuestas que utilizan otros algoritmos y otraforma de modelar el problema HSP1.

La aplicación a utilizar será la que implementa la codificación JPEG2.Esta aplicación se ha escogido porque es una aplicación típica pa-ra sistemas embebidos que combina a partes iguales los dos tiposde computación más utilizados: la computación dominada por datos(data-flow) y la computación dominada por control (control-flow). Ade-más existen un conjunto de artículos que utilizan este algoritmo paraevaluar sus propuestas lo que permitirá establecer comparaciones connuestra aproximación.

El resto del capítulo está ordenado de la siguiente forma: en la sec-ción 5.1 se ofrece una descripción del caso de estudio detallando laestructura del sistema y las estimaciones. En la sección 5.2 se mues-tran las modificaciones necesarias a realizar en la instancia del mode-lo presentada previamente. Además se presentan los experimentos arealizar 5.3 y el análisis de los resultados (sección 5.4). Por último seplantean las conclusiones relacionadas con el caso de estudio.

1 De sus siglas en inglés, Hardware-Software Partitioning, Partición Hardware/Soft-ware.

2 De sus siglas en inglés, Joint Photographic Experts Group.

131

132 caso de estudio

5.1 descripción del caso de estudio

Como ya se adelantaba en la introducción del capítulo, la aplicacióna utilizar será el sistema de codificación de imágenes JPEG. Básica-mente este algoritmo está formado por cinco pasos: conversión delcolor, sub-muestreo, transformada discreta del coseno, cuantificacióny codificación por entropía 3.

En la figura 19 se muestra el CDFG4 de este codificador, el cual estátomado de Lee et al. [2007a]. Estos autores asumen que el convertidorRGB a YUV es implementado en software, por lo que no estará invo-lucrado en el proceso de partición. Además, los procesos agrupadosen un mismo nivel pueden ser ejecutados de forma concurrente yaque no existe dependencia entre ellos.

Para poder utilizar el caso de estudio, es necesario disponer de de-talles de las estimaciones de las variables utilizadas, la función de cos-te y los resultados de la partición, todos estos detalles se encuentranen el trabajo de Lee et al. [2007a]. Además en este trabajo sus autorescomparan su propuesta con otras sobre el mismo caso de estudio.

Por otra parte Abdelhalim and Habib [2011] utilizan este caso, pa-ra realizar un estudio sobre el algoritmo PSO5 en el problema de lapartición Hw/Sw. Este escenario constituye una buena referencia pa-ra comparar los algoritmos propuestos en esta investigación (EC6 yECR7). Además para evaluar si la nueva estrategia multi-algoritmoque incluye también a los algoritmos (AG8 y EE9), se comporta deforma similar a los experimentos anteriores, generando soluciones deacuerdo a una región concreta del frente de Pareto.

3 Para mayor detalles del sistema JPEG, es posible consultar a Wallace [1992].4 De sus siglas en inglés, Control-Data Flow Graph, Grafo de flujo de control-datos.5 De sus siglas en inglés Particle Swarm Optimization, Optimización basada en En-

jambre de Partículas6 Algoritmo Escalador de Colinas mejor ascenso7 Algoritmo Escalador de Colinas con Reinicio8 Algoritmos Genéticos9 Algoritmo Estrategia Evolutiva

5.1 descripción del caso de estudio 133

Read .Bmp FileRead .Bmp FileYUV

SW only

Level Offset

(FEa)

DCT (FEb) DCT (FEc) DCT (FEd)

Quant. (FEe) Quant. (FEf) Quant. (FEg)

Level 1

Level 2

Level 3

Control

Step 1

Control

Step 2

Control

Step 3

DPCM (FEh) ZigZag (FEi)

DPCM (FEj) ZigZag (FEk)

DPCM (FEl) ZigZag (FEm)

Control

Step 4Level 4

Control

Step 5Level 5

VLC (FEn) RLE (FEo)

VLC (FEp) RLE (FEq)

VLC (FEr) RLE (FEs)

Control

Step 6Level 6

VLC (FEt) VLC (FEu) VLC (FEv)

Control

Step 6

Level 6

Bit-Stream

Figura 19 Grafo de flujo de control-datos para el sistema de codificaciónJPEG. Tomado de Lee et al. [2007a].

Las estimaciones se muestran en la tabla 37, la cual está tomadade Lee et al. [2007a]. Los componentes fueron implementados en unatarjeta ML310 usando la plataforma de diseño Xilinx ISE 7.1i, paraobtener las estimaciones de los costes en hardware. Las estimacionesde los costes en software se obtuvieron con Xilinx Embedded De-sign Kit (EDK 7.1i). La tarjeta ML310 contiene una FPGA Virtex2-ProXC2vP30FF896, la cual a su vez contiene 13696 slices y 2448 Kbytes dememoria y dos procesadores IBM Power PC embebidos.

En esta tabla, la primera columna representa el nombre y el identifi-cador de cada componente. La segunda y tercera columna representael tiempo de ejecución de cada uno de los componentes en las dosimplementaciones. Las columnas cuatro y cinco representan el por-centaje del área total que ocupa cada uno de los componentes. Estos

134 caso de estudio

ComponenteTiempo Área (10−3) Potencia (mw)

HW(ns) SW (µs) HW SW HW SW

a(LevelOffset)

0.16 9.38 7.31 0.58 4 0.096

b(DCT) 1.84 20000.00 378 2.88 274 45

c(DCT) 1.84 20000.00 378 2.88 274 45

d(DCT) 1.84 20000.00 378 2.88 274 45

e(Quant.) 3.51 34.70 11 1.93 3 0.26

f(Quant.) 3.51 33.44 9.64 1.93 3 0.27

g(Quant.) 3.51 33.44 9.64 1.93 3 0.27

h(DPCM) 0.01 0.94 2.191 0.677 15 0.957

i(ZigZag) 0.40 13.12 35 0.911 61 0.069

j(DPCM) 0.01 0.94 2.191 0.677 15 0.957

k(ZigZag) 0.40 13.12 35 0.911 61 0.069

l(DPCM) 0.01 0.94 2.191 0.677 15 0.957

m(ZigZag) 0.40 13.12 35 0.911 61 0.069

n(VLC) 2.05 2.80 7.74 14.4 5 0.321

o(RLE) 1.15 43.12 2.56 6.034 3 0.021

p(VLC) 2.20 2.80 8.62 14.4 5 0.321

q(RLE) 1.15 43.12 2.56 6.034 3 0.021

r(VLC) 2.20 2.80 8.62 14.4 5 0.321

s(RLE) 1.15 43.12 2.56 6.034 3 0.021

t(VLC) 2.67 51.26 19.21 16.7 6 0.018

u(VLC) 2.67 50.00 1.91 16.7 6 0.018

v(VLC) 2.67 50.00 1.91 16.7 6 0.018

Tabla 37 Estimaciones obtenidas para el caso de estudio. Tomado de Leeet al. [2007a].

5.2 instancia del modelo de partición hardware/software 135

porcentajes están referidos a los recursos disponibles en la tarjeta uti-lizada. Las dos últimas columnas muestran el consumo de potenciade cada componente según el tipo de implementación.

5.2 instancia del modelo de partición hardware/soft-ware

En aras de hacer la comparación lo más fiel posible se hace necesariomodificar la instancia del modelo propuesta en 3.3. La modificaciónconsta de tres elementos principales:

• Considerar los dos procesadores disponibles en la plataforma.

• Considerar la ejecución simultánea de los dos componentes quese ejecuten en los procesadores.

• Modificar el cálculo del área de hardware ocupada por la solu-ción.

En el primer caso, la instancia propuesta solo consideraba un pro-cesador por lo que no era posible ejecutar de forma simultánea doscomponentes. En la instancia propuesta se asumía que podían exis-tir más de un componente implementado en software, pero estos seejecutaban de forma secuencial. En este nuevo caso, al tener la pla-taforma dos procesadores, es posible ejecutar de forma concurrentecomo máximo dos componentes en cada uno de los niveles (ver figura19). Para permitir esta característica se le agregó a la función objetivouna restricción que controla por cada solución generada que existansolo dos componentes, como máximo, implementados en software.

La segunda modificación es necesaria ya que al permitir la ejecu-ción simultánea de varios componentes, no es posible calcular el tiem-po de forma aditiva. Al igual que en el trabajo de Nath and Datta[2014], la solución es considerar el tiempo de ejecución de la solucióncomo el tiempo que toma ejecutar el camino crítico, es decir, la sumade los tiempos máximos en cada nivel del sistema .

Sea L la cantidad de niveles en el sistema y li es la cantidad detareas en el i-ésimo nivel. El tiempo de ejecución para la j-ésima tareaen el i-ésimo nivel en hardware y software se define como thij ytsij respectivamente. Xij es una variable binaria que indica el tipo de

136 caso de estudio

implementación de la función i-ésima en el nivel j-ésimo, un valor de1 indica implementación en hardware y 0 en software. De acuerdocon esto, el tiempo total del sistema se calcula como:

T =

L∑i=1

max{thijXij, tsij(1−Xij); j = 1, . . . , li} (48)

Por último, es necesario modificar la forma en que se calcula el áreade hardware del sistema. Esto se debe a que en el caso de estudio nose toman en cuenta los costes de hardware de la arquitectura de hard-ware subyacente. Por tanto el área de hardware se define solamentea partir del área de hardware ocupada por cada componente (ahi)implementado en esta plataforma (xi = 1) y se calcula como:

A =

n∑i=1

(xi ∗ ahi) (49)

El resto de las métricas se calcula de la misma forma que las defini-das en las ecuaciones 31 y 33. Además, la función objetivo se calcularámediante la ecuación 37.

5.3 descripción de los experimentos

El objetivo principal de estos experimentos es demostrar la validez dela hipótesis de que el comportamiento de los algoritmos EC y ECRempleando un modelo HSP basado en lógica difusa, en un escenarioreal, es similar o mejor al alcanzado por otros algoritmos y modelosmás utilizados. Además, se comprobará si el comportamiento de laestrategia multi-algoritmo es similar a los resultados alcanzados enlos resultados experimentales, generando cada algoritmo solucionesen una región específica del frente unificado.

Para lograr estos objetivos se propone la realización de un conjun-to de experimentos, los cuales tienen en común la aplicación de lainstancia difusa del modelo al juego de datos referido anteriormente.En cada uno de los experimentos se modificarán los parámetros delmodelo o los parámetros del algoritmos, para evaluar el impacto deestos en la solución obtenida.

5.4 análisis de los resultados 137

La tabla 43 del Anexo D, muestra la configuración de los paráme-tros del modelo y de los algoritmos ECR, AG y EE. Para el caso delalgoritmo EC, como este no tiene parámetros solo se ejecutaron lostres experimentos que se corresponden con la configuración de losparámetros del modelo.

Al igual que en los experimentos anteriores, en este, los algorit-mos fueron ejecutados 30 veces y en cada ejecución fueron realizadas50000 evaluaciones de la función objetivo. El resultado de estas ejecu-ciones es la mejor solución por cada una de las ejecuciones en cuantoa calidad de la solución. Además, se obtiene como resultado todaslas soluciones generadas en cada una de las ejecuciones, para podercalcular el frente de Pareto unificado.

Para evaluar los resultados y el comportamiento de los algoritmosy del modelo, se seleccionaron las mejores soluciones en cuanto a ca-lidad de la solución. Estas se compararon con las mejores solucionesobtenidas del estado del arte, utilizando las siguientes métricas: por-centaje del Área de hardware ocupada, Tiempo de ejecución, Potenciay Memoria consumida.

Mientras que para evaluar el comportamiento de la estrategia multi-algorítmica, se generó el frente de Pareto unificado a partir de ana-lizar las soluciones no dominadas de los algoritmos: EC, ECR, AG,EE.

5.4 análisis de los resultados

Una vez ejecutados los experimentos, se presentarán en esta secciónlos resultados y el análisis de estos. En la tabla 38, se presentan losresultados obtenidos junto con los resultados de las propuestas revi-sadas en el estado del arte: FBP [Lee et al., 2007d], GHO [Lee et al.,2007c], GA [Lin et al., 2006], HOP [Lee et al., 2007b], PSO-Norm [Ab-delhalim and Habib, 2011].

Con vistas a realizar una comparación lo más justa posible y ganaren claridad a la hora de presentar los datos, de esta tabla fueronretiradas variantes de solución propuestas por Abdelhalim and Habib[2011] las cuales están dirigidas a minimizar solo un objetivo (Área oTiempo o Memoria o Potencia). Además se retiró la variante donde

138 caso de estudio

no se asume la restricción de la cantidad de componentes de softwarepor nivel.

Como es posible observar, en la tabla 38 no se encuentran todoslos resultados obtenidos con ambos algoritmos, sino que se muestrantodas aquellas soluciones que son de interés en la comparación, esdecir aquellas que mejoran al menos una de las métricas con respectoa las propuestas anteriores. A fin de ilustrar el comportamiento deestos dos algoritmos con respecto a los reportados en la bibliografía,se realizará un análisis de las soluciones teniendo en cuenta cada unade las métricas.

Con respecto a la métrica tiempo, es posible apreciar que ningunade las soluciones obtenidas por el EC y el ECR logra alcanzar el me-nor tiempo. No obstante, el incremento es despreciable, mientras quela mejora en el resto de métricas es bastante significativo. Por ejem-plo, en la variante ECR-3, que arroja el peor tiempo, solo excede enun 0,6426% a la variante GHO, la cual es la que mejor tiempo alcanza.No obstante, esa misma variante (ECR-3) mejora en un 20,26% y enun 18,12% el Área de hardware y la Potencia consumida por GHO.Por otro lado la variante ECR-11, que presenta el mejor de los tiem-pos, solo excede a GHO en 0,002197% y al mismo tiempo mejora elÁrea y la Potencia en 3% y 4% respectivamente.

Con respecto al consumo de memoria, la soluciones generadas porestos dos algoritmos no logran buenos resultados, llegando a ser lapeor solución (EC-3) 11 veces superior a la mejor solución del estadodel arte (GHO). No obstante, es posible apreciar también que estassoluciones que presentan un consumo de memoria elevado, tiendena mejorar en varios órdenes el área de hardware ocupada, el consu-mo de potencia y el tiempo de ejecución. Por ejemplo, la soluciónalcanzada por EC-3 alcanza el valor mínimo de Área y Potencia entretodas las soluciones.

En cualquier caso, se puede decir como caso general que en los sis-temas embebidos modernos la métrica menos restrictiva suele ser elconsumo de Memoria, debido al bajo precio de las nuevas tecnologíasde memoria (DDR, DDR2, etc.).

5.4

an

ál

is

is

de

lo

sr

es

ul

ta

do

s139

Propuesta Solución Tiempo(µs)

Memoria(KB)

Área( %)

Potencia(mw)

FBP 1/001/111/101111/111101/111 20022.26 51.58 53.9 581.39

GHO 1/010/111/111110/111111/111 20021.66 16.507 54.7 586.069

GA 0/010/010/101110/110111/010 20111.26 146.509 47.1 499.121

HOP 0/100/010/101110/110111/010 20066.64 129.68 56.6 599.67

PSO-Norm 0/010/111/101110/111111/111 20030.9 19.98 50.6 521.234

ECR-3 0/100/100/101011/011011/010 20150.32 161.215 45.5 496.15

ECR-11 0/100/111/110011/110111/111 20022.10 54.659 53.0 563.44

ECR-5 1/010/110/111110/101111/111 20092.50 35.826 53.6 580.36

EC-3 0/001/010/101110/011101/001 20101.88 181.695 44.7 494.44

EC-2 1/001/110/101011/011111/111 20052.18 58.537 49.5 517.73

EC-1 1/010/001/101011/111111/111 20052.84 28.010 49.2 519.67

Tabla 38 Comparación de los resultados de los algoritmos Escalador de Colinas y Escalador de Colinas con Reinicio conel estado del arte en el caso de estudio.

140 caso de estudio

De acuerdo a los resultados mostrados, es posible constatar que lassoluciones aportadas por EC y ECR son las que mejores valores deárea de hardware ocupada y consumo de potencia. Muchas de estassoluciones alcanzan el menor valor de estas métricas entre todas laspropuestas, por ejemplo la solución EC-3 logra un 5,27% y 0,95% demejora con respecto a la mejor solución del estado del arte.

A la luz de los resultados y de acuerdo con el propósito de estosexperimentos, es posible concluir que no existe un algoritmo que seamejor que el resto, en este caso de estudio. Para el caso de la métricaÁrea y Potencia los algoritmos EC y ECR alcanzan los mejores valo-res, mientras que para la métrica Tiempo alcanzan valores similares almejor valor; no obstante las soluciones de estos dos algoritmos alcan-zan un consumo de Memoria superior en comparación con el estadodel arte. De acuerdo con este planteamiento se considera errado elofrecer como resultado del proceso HSP una única solución, cuandose trata de optimizar varias métricas de forma simultánea.

Con relación a las soluciones de los algoritmos EC y ECR, es po-sible plantear que están dominadas por la métrica Área, es decir al-canzan soluciones con muy bajo porcentaje de utilización de recursosde hardware. Estos resultados se corresponden con los alcanzados enlos experimentos del capítulo 4, donde era posible apreciar que estosalgoritmos además de establecerse en un sector del frente, tendíanhacia aquellas soluciones dominadas por el área.

De acuerdo con los resultados obtenidos en los experimentos, va-riando los parámetros difusos del modelo, es posible plantear que lalógica difusa además de brindar flexibilidad al modelo permite pe-nalizar de cierta forma las métricas involucradas en el modelo. Estaforma de penalizar las soluciones es más intuitiva para un diseñador,en lugar de establecer pesos por cada una de las métricas. Además,permiten dirigir la búsqueda hacia determinados espacios según lasnecesidades del diseñador en cuanto al tipo de solución que se deseelograr. Esto se debe a que moviendo los límites de la función de per-tenencia es posible lograr valores en las métricas más altos o másbajos.

Finalmente, para evaluar el comportamiento de la estrategia multi-algorítmica se hizo un análisis desde el punto de vista multi-objetivopara determinar las soluciones no dominadas de cada algoritmo (EC,

5.5 conclusiones 141

Tiempo

Área

AGECR

Figura 20 Frente optimal de Pareto unificado para el caso de estudio JPEG.

ECR, EE y AG) y con estas crear un frente de Parteo unificado. La fi-gura 20, muestra el frente de Pareto unificado para el caso de estudiodel codificador JPEG.

Como puede apreciarse en la figura 20, el frente unificado está for-mado solamente por soluciones de los algoritmos ECR y AG. Inclusolas soluciones de ambos algoritmos son iguales, excepto por dos solu-ciones de más que aporta el ECR. Este resultado permite comprobarque el ECR aporta al frente unificado de igual manera que el AG, locual reafirma la utilización de este algoritmo en el problema HSP.

5.5 conclusiones

Al término de este capítulo se concluye que:

1. Los algoritmos ECR y EC, lograron soluciones comparables conotros algoritmos utilizados con más frecuencia.

2. El algoritmo EC alcanzó la mejor solución en cuanto a Áreade Hw y Potencia consumida logrando una mejora del 5,27%

142 caso de estudio

y 0,95% respectivamente con relación a la mejor solución delestado del arte.

3. El algoritmo ECR alcanzó una solución con un Tiempo de eje-cución que solo excede en 0,6426% a la mejor solución del es-tado del arte (GHO), presentando una mejora significativa enun 20,26% y en un 18,12% el Área de hardware y la Potenciaconsumida por GHO, aunque la solución del ECR consume másmemoria que GHO.

4. En problemas donde se optimicen varios objetivos de forma si-multánea, es erróneo plantear una única solución como la co-rrecta, ya que existen soluciones buenas en un objetivo y malasen otros.

5. En esta aplicación concreta, el algoritmo ECR aporta más so-luciones al frente de Pareto Unificado que el AG, aunque lamayoría de estas soluciones son las mismas.

6. El enfoque difuso es mejor con respecto a las propuestas delestado del arte que utilizan pesos en la función objetivo, estose debe a que permite tratar la importancia de las métricas deforma más intuitiva moviendo los límites en la función de per-tenencia.

7. Los parámetros del modelo asociados con la lógica difusa mejo-ran las soluciones al ser utilizados como penalizaciones.

8. Los parámetros del modelo permiten dirigir la búsqueda en fun-ción del espacio de soluciones que se desee explorar.

6C O N C L U S I O N E S Y T R A B A J O F U T U R O

6.1 conclusiones generales

La partición de componentes de hardware y software de un sistemaembebido es una tarea clave dentro del proceso de co-diseño. En ellase decide la configuración final del sistema que permita cumplir conlos requerimientos del usuario y el diseñador.

Para encontrar la configuración que satisfaga los requerimientos esnecesario resolver un problema de optimización combinatoria, llama-do problema HSP. En la mayoría de las formulaciones está demostra-do que es un problema de optimización combinatoria NP.

En la práctica, es muy frecuente que los diseñadores no cuenten conuna herramienta que permita resolver este problema de forma auto-mática, por lo que exploran un pequeño número de combinacionespara buscar la mejor solución. No obstante, contar con una solucióngenérica es complejo ya que las soluciones están ligadas fuertemen-te a las características de la instancia del problema HSP que se estéresolviendo.

Existen diferentes propuestas dirigidas a resolver de forma con-creta una instancia particular del problema HSP. Estas propuestasgeneralmente están destinadas a evaluar un determinado algoritmoo estrategia de búsqueda empleando un conjunto de métricas paraevaluar las soluciones. Mientras que las métricas más utilizadas son:Área de Hw, Sw, Costo de comunicación, Tiempo de ejecución y Con-sumo de potencia.

Entre las estrategias de búsquedas más utilizadas se encuentran losalgoritmos metaheurísticos, ya que garantizan soluciones cercanas alóptimo en un tiempo de búsqueda relativamente pequeño en compa-

143

144 conclusiones y trabajo futuro

ración con las estrategias exactas. Dentro de estos algoritmos los másutilizados son el algoritmo de Recocido Simulado y el Algoritmo Ge-nético. Sin embargo, de acuerdo con las fuentes consultadas existenotros algoritmos como el Escalador de Colinas Estocástico y el Esca-lador de Colinas Estocástico con Reinicio que no han sido utilizadosaún en el marco de este problema.

La validación de estas propuestas se realiza mediante aplicacionessimuladas o mediante aplicaciones reales. En muchos casos la valida-ción se realiza utilizando bancos de prueba compuestos por aplicacio-nes simuladas, ya que la utilización de aplicaciones reales requiere deherramientas para la estimación de los costes o de la especificaciónde estos a partir de estudios previos, lo cual no es muy frecuente.

El modelo genérico presentado en esta investigación considera losprincipales aspectos a tener en cuenta a la hora de diseñar un modelopara resolver una instancia concreta del problema HSP. En primerlugar permite la incorporación de cualquier métrica al modelo, asícomo la combinación de estas; permitiendo evaluar las solucionesdesde varios puntos de vista y aportándole al proceso mayor nivel dedetalle.

La utilización de estrategias basadas en Soft computing, ha dotadoal modelo de cierto grado de flexibilidad, permitiendo tratar el pro-blema HSP de una forma más cercana a cómo el diseñador lo hace enla práctica. Es importante considerar el estudio de varios algoritmosmetaheurísticos sobre un mismo modelo para de esta forma buscarel/los algoritmos que mejor desempeños alcanzan.

Al integrar elementos de la arquitectura es posible realizar unaexploración del espacio de diseño teniendo en cuenta el efecto quetienen estos elementos en el rendimiento del sistema en general. Ade-más la búsqueda de la solución se realiza bajo condiciones similaresa las que existirá en el despliegue.

La representación del modelo abstracto utilizando la notación Erik-sson-Penker para describir procesos de negocio ha permitido identifi-car todas las actividades involucradas en la tarea de partición Hw/Sw.De esta forma, ha sido posible definir y formalizar cada actividad afin de refinar o mejorar las soluciones al problema HSP, al identificarfortalezas y debilidades en desarrollos posteriores.

6.2 principales aportaciones 145

De acuerdo con los resultados experimentales obtenidos, es posibleconcluir que los algoritmos Escalador de Colinas Estocástico y el Es-calador de Colinas Estocástico con Reinicio son comparables e inclusomejores que otros algoritmos utilizados con más frecuencia.

Por otra parte, se pudo apreciar que los algoritmos Escalador deColinas Estocástico y el Escalador de Colinas Estocástico con Reinicio,lograron soluciones comparables con otros algoritmos utilizados conmás frecuencia, sobre el caso de estudio del codificador JPEG. Estosalgoritmos alcanzaron resultados en las métricas analizadas, mejoresque el resto de los algoritmos presentes en el estado del arte. Mientrasque en las métricas que no superaron al resto, la diferencia con losmejores no fue significativa.

El análisis multi-objetivo de las soluciones generadas brinda la posi-bilidad de contar con un conjunto de soluciones que son consideradascomo válidas para la instancia del problema que se esté resolviendo.Esta condición le brinda al diseñador una mayor cantidad de elemen-tos para tomar la decisión sobre cuál solución es mejor implementar.

A partir del análisis de la contribución de los algoritmos al frentede Pareto, es posible concluir que un enfoque multi-algorítmico pararesolver el problema HSP, enriquece el enfoque de múltiples solucio-nes. De esta forma es posible utilizar a determinados algoritmos paraque generen soluciones en determinadas regiones del espacio.

Las pruebas estadísticas no paramétricas han permitido realizar in-ferencias sobre el comportamiento de los algoritmos en cada una delas métricas. Por otro lado, la utilización de la metodología de DiseñoEstadístico de Experimentos ha permitido explorar de forma ordena-da el espacio de combinaciones, obteniéndose la mejor configuraciónde los algoritmos metaheurísticos.

6.2 principales aportaciones

El presente trabajo de tesis incluye como contribuciones a la solucióndel problema HSP los siguientes aspectos:

1. Se ha propuesto un modelo HSP genérico que garantiza aspec-tos claves a tener en cuenta en cualquier instancia.


• Integración y Composición de métricas, permitiendo carac-terizar las soluciones desde otros puntos de vista y de for-ma más integral.

• Basado en Soft computing, al emplear un enfoque difusopara evaluar la solución y algoritmos metaheurísticos parabuscar la solución, lo cual dota al modelo de un notablenivel de flexibilidad.

• Múltiples soluciones, permitiendo contar con un conjuntode soluciones clasificadas como buenas, con lo cual la tomade decisiones se enriquecerá.

2. Se ha realizado un estudio comparativo homogéneo, respalda-do por pruebas estadísticas no paramétricas, entre varios de losalgoritmos de búsqueda más utilizados, en el contexto de unainstancia concreta del problema HSP.

3. Se ha propuesto una nueva estrategia para resolver el problemaHSP basada en la combinación de varios algoritmos de búsque-da y en función del tipo de soluciones a explorar. La propuestapresenta como características novedosas:

• La utilización de los algoritmos EC y ECR (no reportadoshasta el momento para el problema HSP). Estos algorit-mos presentan un comportamiento igual o superior a lasúltimas propuestas.

• Un enfoque multi-objetivo que proporciona al diseñador,no solo la mejor solución desde el punto de vista de la fun-ción de coste, sino también un amplio abanico de solucio-nes intermedias que permiten abordar el problema desdeuna óptica más integral y flexible.

6.3 trabajo futuro

De acuerdo con los resultados obtenidos al término de esta investi-gación y los aspectos abordados en la misma, es posible plantear unconjunto de líneas futuras de trabajo, desde el punto de vista teóricocomo práctico.

6.3 trabajo futuro 147

espacio teórico

• Proponer un modelo flexible que permita la estimación de loscostes de hardware asociados a los componentes del sistema.La flexibilidad del modelo deberá estar dada principalmentepor incorporar distintas plataformas de hardware y así produ-cir estimaciones más precisas. Además de considerar distintasformas de implementación para una función particular.

• Proponer un modelo flexible que permita la estimación de loscostes de software asociados a los componentes del sistema. Es-te modelo deberá tener en cuenta distintas arquitecturas de pro-cesadores empotrados de forma tal que el resultado final de lapartición esté relacionado con la arquitectura donde será des-plegado.

espacio práctico

• Integrar los modelos de estimación y búsqueda en una una he-rramienta de partición Hw/Sw, que permita satisfacer las nece-sidades de los diseñadores.

• Integrar esta herramienta en los entornos de diseño de siste-mas embebidos, principalmente en los nuevos entornos HLS(High Level Synthesis) basados en lenguajes de alto nivel. Estosentornos permiten una descripción unificada del sistema, unaexploración semiautomática del espacio de diseño de los com-ponentes Hw y una precisa estimación de los costes. Toda estainformación puede ser suministrada automáticamente a la he-rramienta de partición para generar soluciones realistas y deforma interactiva.

• Incluir otros algoritmos metaheurísticos al estudio para evaluarsu comportamiento en las instancia de los modelos HSP, porejemplo el algoritmo de Estimación de Distribuciones.


6.4 publicaciones

Los conceptos, enfoques y resultados parciales de esta investigaciónhan sido publicados en los escenarios que a continuación se presen-tan:

Revistas científicas:

Humberto Díaz Pando, Sergio Cuenca Asensi, Roberto SepúlvedaLima, Jenny Fajardo Calderín, and Alejandro Rosete Suárez. Anapplication of fuzzy logic for hardware/software partitioning onembedded systems. Computación y Sistemas, 17(1):30−40,marzo 2013.

Humberto Díaz Pando, Sergio Cuenca Asensi, Roberto SepúlvedaLima, Alejandro Rosete Suárez, and Jenny Fajardo Calderín.Algoritmos metaheurísticos en el problema del particionadohardware/software de sistemas embebidos. Inteligencia Artificial,16(51):1−14, 2013.

Conferencias científicas:

Humberto Díaz Pando, Yulier Nuñez Musa, Roberto SepúlvedaLima, and Sergio Cuenca Asensi. Tendencias actuales en laconcepción de subsistemas hardware para la protección deaplicaciones. En IX Seminario Iberoamericano de Seguridaden las Tecnologías de la Información, La Habana, Cuba, 2009.

Humberto Díaz Pando, Sergio Cuenca Asensi, Roberto SepúlvedaLima, and Alejandro Rosete Suárez. Particionado hardware/software de sistemas embebidos usando lógica difusa. En XVIConvención Científica de Ingeniería y Arquitectura, La Habana, Cuba,2012.

Parte III

A P É N D I C E S

AN O TA C I Ó N

A continuación se muestra un listado de la notación utilizada en ladefinición del modelo de procesos HSP, presentado en el capítulo 3.

F : Conjunto de todas las funciones que conforman el sistema queserá particionado.

GC : Grafo de llamadas, modelo computacional que representa al sis-tema que será particionado. Este es un grafo dirigido y acíclico,donde cada nodo o vértice se asocia a una función y los arcoses la comunicación entre dos funciones.

V : Conjunto de nodos o vértices del grafo de llamadas.

E : Conjunto de arcos o enlaces del grafo de llamadas.

∆ : Conjunto que representa los elementos arquitectónicos de la pla-taforma de hardware que será utilizada para implementar elsistema que será particionado.

S : Representa el conjunto de soluciones válidas que se obtiene comoresultado del proceso.

Va : Conjunto que detona a todas las variables que serán medidaspor el CompIni para producir los costes.

Es : Denota al conjunto de funciones de estimación, estas funcionesserán las encargadas de producir, a partir de las variables defi-nidas, las estimaciones de los costes correspondientes.

C : Denota al conjunto de los costes que se generaron mediante lasfunciones de estimación y que serán utilizados por CompBusq

151

152 notación

para calcular los valores de las métricas asociadas a cada solu-ción.

GC ′ : Representa al grafo de llamadas en el cual sus nodos y arcostienen asociados los valores de los costes que le pertenecen.

EM : Denota al conjunto de funciones de evaluación de métricas, es-tas funciones tienen en cuenta los costes para generar un valora cada métrica definida.

M : Denota al conjunto de todas las métricas primitivas calculadas yque serán utilizadas para evaluar la solución generada.

U : Denota al conjunto de universos del discurso de cada una de lasmétricas utilizadas.

FP : Denota al conjunto de las funciones de pertenencia aplicadassobre cada una de las métricas calculadas.

P : Denota al conjunto de parámetros de las funciones de pertenenciay que se generan de acuerdo al universo del discurso de cadamétrica.

R : Denota al conjunto de restricciones de diseño impuestas al iniciodel proceso y que deben cumplir las soluciones generadas.

fo : Representa la función objetivo que permitirá evaluar las solucio-nes generadas teniendo en cuenta las restricciones y los valoresde las métricas primitivas.

BC O N F I G U R A C I Ó N D E L A H E R R A M I E N TA T G F F

A continuación se muestran los parámetros utilizados para configu-rar la herramienta TGFF1 para generar los grafos de llamadas utili-zados en los experimentos. Por cada uno de los cuatro tamaños degrafos utilizados se generaron cuatro grafos: un grafo out-tree, unserie-paralelo y dos grafos aleatorios.

b.1 grafos de 50 nodos

#out-tree.tgffopt

period_mul 1

tg_cnt 1

task_cnt 50 1

task_degree 1 3

tg_write # .tgff

eps_write # .eps

vcg_write # .vcg

#serie-paralelo.tgffopt

period_mul 1

tg_cnt 1

task_cnt 50 1

gen_series_parallel

task_degree 3 2

series_wid 4 2

series_len 5 3

series_must_rejoin 0

1 De sus siglas en inglés, Task Graph For Free.

153

154 configuración de la herramienta tgff

series_subgraph_fork_out .7

tg_write # .tgff

eps_write # .eps

vcg_write # .vcg

#aleatorio.tgffopt

period_mul 1

tg_cnt 2

task_cnt 50 1

task_degree 3 2

gen_series_parallel

series_len 0 0

series_wid 0 0

series_global_xover 50

tg_write # .tgff

eps_write # .eps

vcg_write # .vcg


#out-tree.tgffopt

period_mul 1

tg_cnt 1

task_cnt 100 1

task_degree 1 3

tg_write # .tgff

eps_write # .eps

vcg_write # .vcg


period_mul 1

tg_cnt 1

task_cnt 100 1

gen_series_parallel

task_degree 3 2

series_wid 3 2

series_len 5 3


B.3 grafos de 150 nodos 155


tg_write # .tgff

eps_write # .eps

vcg_write # .vcg

#aleatorio.tgffopt

period_mul 1

tg_cnt 2

task_cnt 100 1

task_degree 3 2

gen_series_parallel

series_len 0 0

series_wid 0 0


tg_write # .tgff

eps_write # .eps

vcg_write # .vcg


#out-tree.tgffopt

period_mul 1

tg_cnt 1

task_cnt 150 1

task_degree 1 3

tg_write # .tgff

eps_write # .eps

vcg_write # .vcg


period_mul 1

tg_cnt 1

task_cnt 150 1

gen_series_parallel

task_degree 3 2

series_wid 3 2

series_len 4 2


156 configuración de la herramienta tgff


tg_write # .tgff

eps_write # .eps

vcg_write # .vcg

#aleatorio.tgffopt

period_mul 1

tg_cnt 2

task_cnt 150 1

task_degree 3 2

gen_series_parallel

series_len 0 0

series_wid 0 0


tg_write # .tgff

eps_write # .eps

vcg_write # .vcg


#out-tree.tgffopt

period_mul 1

tg_cnt 1

task_cnt 200 1

task_degree 1 3

tg_write # .tgff

eps_write # .eps

vcg_write # .vcg


period_mul 1

tg_cnt 1

task_cnt 200 1

gen_series_parallel

task_degree 3 2

series_wid 3 2

series_len 3 2


B.4 grafos de 200 nodos 157


tg_write # .tgff

eps_write # .eps

vcg_write # .vcg

#aleatorio.tgffopt

period_mul 1

tg_cnt 2

task_cnt 200 1

task_degree 3 2

gen_series_parallel

series_len 0 0

series_wid 0 0


tg_write # .tgff

eps_write # .eps

vcg_write # .vcg

CC O N F I G U R A C I Ó N D E L O S E X P E R I M E N T O S

159

160

co

nf

ig

ur

ac

ió

nd

el

os

ex

pe

rim

en

to

s

Exp. αa βa αt βt αm βm αp βp restm restp pob_ini trunc pm pc

1 37,5 87,5 12,5 87,5 12,5 62,5 37,5 62,5 0,25 0,75 150 30 0,75 0,25

2 12,5 62,5 12,5 62,5 12,5 62,5 12,5 62,5 0,25 0,25 150 30 0,25 0,25

3 12,5 87,5 12,5 62,5 12,5 87,5 37,5 87,5 0,25 0,25 150 75 0,75 0,75

4 12,5 62,5 12,5 62,5 37,5 62,5 12,5 87,5 0,25 0,75 300 30 0,75 0,75

5 12,5 87,5 37,5 87,5 12,5 62,5 12,5 87,5 0,25 0,75 300 75 0,25 0,25

6 37,5 87,5 12,5 87,5 37,5 62,5 37,5 87,5 0,25 0,25 300 30 0,25 0,75

7 37,5 62,5 12,5 62,5 37,5 87,5 37,5 62,5 0,75 0,25 150 30 0,75 0,75

8 12,5 87,5 12,5 62,5 37,5 87,5 37,5 62,5 0,25 0,75 300 75 0,25 0,25

9 12,5 62,5 12,5 87,5 37,5 62,5 37,5 87,5 0,75 0,75 150 75 0,75 0,25

10 12,5 62,5 37,5 87,5 12,5 87,5 37,5 62,5 0,25 0,75 300 30 0,75 0,75

11 12,5 62,5 37,5 87,5 12,5 87,5 37,5 62,5 0,25 0,75 300 30 0,75 0,75

12 12,5 87,5 37,5 87,5 12,5 62,5 12,5 87,5 0,25 0,75 300 75 0,25 0,25

13 37,5 87,5 12,5 62,5 12,5 62,5 12,5 62,5 0,75 0,75 300 75 0,75 0,75

14 37,5 62,5 37,5 62,5 37,5 62,5 37,5 62,5 0,25 0,75 150 75 0,25 0,75

15 37,5 62,5 37,5 62,5 37,5 62,5 37,5 62,5 0,25 0,75 150 75 0,25 0,75

16 37,5 87,5 12,5 62,5 37,5 62,5 12,5 87,5 0,75 0,25 150 75 0,25 0,25

17 12,5 62,5 37,5 87,5 37,5 87,5 37,5 87,5 0,25 0,25 150 30 0,25 0,25

co

nf

ig

ur

ac

ió

nd

el

os

ex

pe

rim

en

to

s161


18 12,5 87,5 12,5 87,5 37,5 87,5 12,5 62,5 0,75 0,75 150 30 0,25 0,75

19 12,5 62,5 12,5 87,5 37,5 62,5 37,5 87,5 0,75 0,75 150 75 0,75 0,25

20 12,5 87,5 12,5 87,5 37,5 87,5 12,5 62,5 0,75 0,75 150 30 0,25 0,75

21 37,5 87,5 37,5 62,5 37,5 87,5 12,5 87,5 0,25 0,75 150 30 0,75 0,25

22 12,5 62,5 12,5 87,5 37,5 62,5 37,5 87,5 0,75 0,75 150 75 0,75 0,25

23 37,5 62,5 12,5 87,5 37,5 87,5 12,5 62,5 0,25 0,25 300 75 0,75 0,25

24 37,5 62,5 12,5 62,5 12,5 87,5 37,5 87,5 0,75 0,75 300 30 0,25 0,25

25 12,5 87,5 37,5 87,5 37,5 62,5 12,5 62,5 0,25 0,25 150 75 0,75 0,75

26 12,5 62,5 12,5 87,5 12,5 62,5 37,5 62,5 0,75 0,25 300 75 0,25 0,75

27 12,5 87,5 37,5 62,5 37,5 62,5 37,5 62,5 0,75 0,25 300 30 0,75 0,25

28 37,5 87,5 12,5 87,5 12,5 62,5 37,5 62,5 0,25 0,75 150 30 0,75 0,25

29 37,5 62,5 37,5 62,5 12,5 62,5 37,5 87,5 0,25 0,25 300 75 0,75 0,25

30 12,5 62,5 37,5 62,5 37,5 87,5 12,5 87,5 0,75 0,25 300 75 0,25 0,75

31 37,5 87,5 37,5 87,5 12,5 87,5 37,5 62,5 0,75 0,25 150 75 0,25 0,25

32 37,5 62,5 37,5 62,5 12,5 62,5 37,5 87,5 0,25 0,25 300 75 0,75 0,25

33 37,5 87,5 37,5 62,5 12,5 87,5 12,5 62,5 0,25 0,25 300 30 0,25 0,75

34 12,5 87,5 37,5 62,5 37,5 62,5 37,5 62,5 0,75 0,25 300 30 0,75 0,25

162

co

nf

ig

ur

ac

ió

nd

el

os

ex

pe

rim

en

to

s


35 12,5 62,5 12,5 62,5 12,5 62,5 12,5 62,5 0,25 0,25 150 30 0,25 0,25

36 12,5 87,5 12,5 87,5 12,5 87,5 12,5 87,5 0,75 0,25 300 30 0,75 0,25

37 12,5 87,5 37,5 62,5 12,5 62,5 37,5 87,5 0,75 0,75 150 30 0,25 0,75

38 12,5 87,5 12,5 62,5 12,5 87,5 37,5 87,5 0,25 0,25 150 75 0,75 0,75

39 37,5 62,5 12,5 62,5 12,5 87,5 37,5 87,5 0,75 0,75 300 30 0,25 0,25

40 12,5 62,5 37,5 62,5 37,5 87,5 12,5 87,5 0,75 0,25 300 75 0,25 0,75

41 12,5 62,5 12,5 62,5 37,5 62,5 12,5 87,5 0,25 0,75 300 30 0,75 0,75

42 37,5 87,5 12,5 87,5 37,5 62,5 37,5 87,5 0,25 0,25 300 30 0,25 0,75

43 37,5 62,5 37,5 62,5 12,5 62,5 37,5 87,5 0,25 0,25 300 75 0,75 0,25

44 12,5 87,5 12,5 62,5 37,5 87,5 37,5 62,5 0,25 0,75 300 75 0,25 0,25

45 37,5 62,5 37,5 87,5 37,5 62,5 12,5 62,5 0,75 0,75 300 30 0,25 0,25

46 12,5 62,5 12,5 87,5 12,5 62,5 37,5 62,5 0,75 0,25 300 75 0,25 0,75

47 12,5 87,5 12,5 87,5 37,5 87,5 12,5 62,5 0,75 0,75 150 30 0,25 0,75

48 12,5 62,5 37,5 87,5 12,5 87,5 37,5 62,5 0,25 0,75 300 30 0,75 0,75

49 37,5 87,5 12,5 62,5 37,5 62,5 12,5 87,5 0,75 0,25 150 75 0,25 0,25

50 37,5 87,5 37,5 62,5 12,5 87,5 12,5 62,5 0,25 0,25 300 30 0,25 0,75

51 12,5 87,5 37,5 62,5 12,5 62,5 37,5 87,5 0,75 0,75 150 30 0,25 0,75

co

nf

ig

ur

ac

ió

nd

el

os

ex

pe

rim

en

to

s163


52 37,5 87,5 12,5 87,5 12,5 62,5 37,5 62,5 0,25 0,75 150 30 0,75 0,25

53 37,5 62,5 12,5 87,5 37,5 87,5 12,5 62,5 0,25 0,25 300 75 0,75 0,25

54 12,5 87,5 37,5 62,5 12,5 62,5 37,5 87,5 0,75 0,75 150 30 0,25 0,75

55 37,5 62,5 37,5 87,5 12,5 62,5 12,5 87,5 0,75 0,25 150 30 0,75 0,75

56 12,5 87,5 12,5 62,5 37,5 87,5 37,5 62,5 0,25 0,75 300 75 0,25 0,25

57 37,5 62,5 37,5 87,5 37,5 62,5 12,5 62,5 0,75 0,75 300 30 0,25 0,25

58 12,5 62,5 37,5 87,5 37,5 87,5 37,5 87,5 0,25 0,25 150 30 0,25 0,25

59 12,5 62,5 37,5 87,5 37,5 87,5 37,5 87,5 0,25 0,25 150 30 0,25 0,25

60 12,5 62,5 37,5 62,5 12,5 87,5 12,5 62,5 0,75 0,75 150 75 0,75 0,25

61 37,5 62,5 37,5 87,5 37,5 62,5 12,5 62,5 0,75 0,75 300 30 0,25 0,25

62 12,5 87,5 12,5 87,5 12,5 87,5 12,5 87,5 0,75 0,25 300 30 0,75 0,25

63 12,5 62,5 37,5 62,5 12,5 87,5 12,5 62,5 0,75 0,75 150 75 0,75 0,25

64 37,5 62,5 12,5 87,5 37,5 87,5 12,5 62,5 0,25 0,25 300 75 0,75 0,25

65 37,5 62,5 12,5 62,5 12,5 87,5 37,5 87,5 0,75 0,75 300 30 0,25 0,25

66 37,5 62,5 37,5 87,5 12,5 62,5 12,5 87,5 0,75 0,25 150 30 0,75 0,75

67 37,5 62,5 12,5 62,5 37,5 87,5 37,5 62,5 0,75 0,25 150 30 0,75 0,75

68 12,5 87,5 37,5 87,5 37,5 62,5 12,5 62,5 0,25 0,25 150 75 0,75 0,75

164

co

nf

ig

ur

ac

ió

nd

el

os

ex

pe

rim

en

to

s


69 37,5 62,5 12,5 87,5 12,5 87,5 12,5 87,5 0,25 0,75 150 75 0,25 0,75

70 12,5 87,5 37,5 87,5 37,5 62,5 12,5 62,5 0,25 0,25 150 75 0,75 0,75

71 12,5 87,5 12,5 62,5 12,5 87,5 37,5 87,5 0,25 0,25 150 75 0,75 0,75

72 12,5 87,5 37,5 62,5 37,5 62,5 37,5 62,5 0,75 0,25 300 30 0,75 0,25

73 12,5 87,5 12,5 87,5 12,5 87,5 12,5 87,5 0,75 0,25 300 30 0,75 0,25

74 37,5 87,5 37,5 87,5 37,5 87,5 37,5 87,5 0,75 0,75 300 75 0,75 0,75

75 12,5 62,5 37,5 62,5 12,5 87,5 12,5 62,5 0,75 0,75 150 75 0,75 0,25

76 12,5 62,5 12,5 87,5 12,5 62,5 37,5 62,5 0,75 0,25 300 75 0,25 0,75

77 37,5 87,5 12,5 87,5 37,5 62,5 37,5 87,5 0,25 0,25 300 30 0,25 0,75

78 37,5 62,5 37,5 62,5 37,5 62,5 37,5 62,5 0,25 0,75 150 75 0,25 0,75

79 12,5 62,5 12,5 62,5 37,5 62,5 12,5 87,5 0,25 0,75 300 30 0,75 0,75

80 37,5 87,5 37,5 62,5 37,5 87,5 12,5 87,5 0,25 0,75 150 30 0,75 0,25

81 37,5 62,5 12,5 62,5 37,5 87,5 37,5 62,5 0,75 0,25 150 30 0,75 0,75

82 37,5 62,5 12,5 87,5 12,5 87,5 12,5 87,5 0,25 0,75 150 75 0,25 0,75

83 37,5 62,5 12,5 87,5 12,5 87,5 12,5 87,5 0,25 0,75 150 75 0,25 0,75

84 37,5 87,5 37,5 87,5 37,5 87,5 37,5 87,5 0,75 0,75 300 75 0,75 0,75

85 37,5 87,5 12,5 62,5 12,5 62,5 12,5 62,5 0,75 0,75 300 75 0,75 0,75

co

nf

ig

ur

ac

ió

nd

el

os

ex

pe

rim

en

to

s165


86 12,5 62,5 37,5 62,5 37,5 87,5 12,5 87,5 0,75 0,25 300 75 0,25 0,75

87 37,5 87,5 37,5 87,5 12,5 87,5 37,5 62,5 0,75 0,25 150 75 0,25 0,25

88 12,5 87,5 37,5 87,5 12,5 62,5 12,5 87,5 0,25 0,75 300 75 0,25 0,25

89 37,5 87,5 37,5 62,5 12,5 87,5 12,5 62,5 0,25 0,25 300 30 0,25 0,75

90 37,5 87,5 37,5 87,5 37,5 87,5 37,5 87,5 0,75 0,75 300 75 0,75 0,75

91 37,5 87,5 37,5 62,5 37,5 87,5 12,5 87,5 0,25 0,75 150 30 0,75 0,25

92 37,5 87,5 37,5 87,5 12,5 87,5 37,5 62,5 0,75 0,25 150 75 0,25 0,25

93 37,5 87,5 12,5 62,5 37,5 62,5 12,5 87,5 0,75 0,25 150 75 0,25 0,25

94 37,5 62,5 37,5 87,5 12,5 62,5 12,5 87,5 0,75 0,25 150 30 0,75 0,75

95 12,5 62,5 12,5 62,5 12,5 62,5 12,5 62,5 0,25 0,25 150 30 0,25 0,25

96 37,5 87,5 12,5 62,5 12,5 62,5 12,5 62,5 0,75 0,75 300 75 0,75 0,75

Tabla 39 Configuración del experimento para el Algoritmo Genético

166

co

nf

ig

ur

ac

ió

nd

el

os

ex

pe

rim

en

to

s

Exp. αa βa αt βt αm βm αp βp restm restp pob_ini trunc pm

1 37,5 87,5 12,5 87,5 37,5 62,5 12,5 62,5 0,25 0,25 300 30 0,75

2 12,5 62,5 37,5 62,5 12,5 87,5 37,5 87,5 0,75 0,75 150 75 0,25

3 37,5 62,5 37,5 62,5 12,5 62,5 37,5 62,5 0,75 0,25 300 30 0,75

4 37,5 87,5 12,5 87,5 37,5 62,5 12,5 62,5 0,25 0,25 300 30 0,75

5 37,5 62,5 37,5 62,5 37,5 87,5 12,5 62,5 0,25 0,75 150 30 0,25

6 37,5 87,5 12,5 62,5 12,5 87,5 37,5 62,5 0,25 0,25 150 75 0,75

7 12,5 87,5 37,5 87,5 37,5 62,5 37,5 62,5 0,75 0,25 150 30 0,25

8 12,5 62,5 12,5 87,5 37,5 87,5 37,5 62,5 0,25 0,25 300 75 0,25

9 37,5 87,5 37,5 62,5 37,5 87,5 37,5 87,5 0,25 0,25 300 30 0,25

10 37,5 87,5 12,5 62,5 12,5 87,5 37,5 62,5 0,25 0,25 150 75 0,75

11 37,5 62,5 12,5 62,5 37,5 62,5 37,5 87,5 0,75 0,25 150 75 0,25

12 37,5 87,5 12,5 87,5 37,5 62,5 12,5 62,5 0,25 0,25 300 30 0,75

13 37,5 87,5 37,5 87,5 37,5 87,5 37,5 87,5 0,75 0,75 300 75 0,75

14 12,5 62,5 37,5 87,5 12,5 87,5 37,5 87,5 0,25 0,25 150 30 0,75

15 37,5 87,5 37,5 87,5 37,5 87,5 37,5 87,5 0,75 0,75 300 75 0,75

16 12,5 87,5 37,5 87,5 12,5 87,5 12,5 62,5 0,25 0,75 300 30 0,75

17 37,5 87,5 12,5 87,5 12,5 87,5 37,5 62,5 0,75 0,75 150 30 0,25

18 37,5 87,5 37,5 62,5 12,5 62,5 12,5 87,5 0,75 0,75 150 30 0,75

co

nf

ig

ur

ac

ió

nd

el

os

ex

pe

rim

en

to

s167


19 12,5 87,5 12,5 87,5 12,5 62,5 37,5 87,5 0,75 0,25 300 75 0,75

20 12,5 87,5 12,5 62,5 37,5 87,5 12,5 87,5 0,75 0,25 150 30 0,75

21 12,5 87,5 12,5 87,5 12,5 62,5 37,5 87,5 0,75 0,25 300 75 0,75

22 37,5 87,5 12,5 87,5 12,5 87,5 37,5 62,5 0,75 0,75 150 30 0,25

23 12,5 87,5 37,5 87,5 12,5 87,5 12,5 62,5 0,25 0,75 300 30 0,75

24 37,5 87,5 37,5 62,5 37,5 87,5 37,5 87,5 0,25 0,25 300 30 0,25

25 37,5 62,5 37,5 87,5 37,5 87,5 12,5 62,5 0,75 0,25 150 75 0,75

26 37,5 87,5 37,5 87,5 37,5 87,5 37,5 87,5 0,75 0,75 300 75 0,75

27 37,5 62,5 12,5 87,5 12,5 87,5 12,5 87,5 0,75 0,25 300 30 0,25

28 12,5 87,5 12,5 62,5 12,5 62,5 37,5 87,5 0,25 0,75 300 30 0,25

29 12,5 62,5 37,5 87,5 12,5 87,5 37,5 87,5 0,25 0,25 150 30 0,75

30 12,5 87,5 37,5 62,5 12,5 87,5 12,5 62,5 0,75 0,25 300 75 0,25

31 37,5 62,5 12,5 87,5 12,5 87,5 12,5 87,5 0,75 0,25 300 30 0,25

32 37,5 87,5 12,5 62,5 12,5 87,5 37,5 62,5 0,25 0,25 150 75 0,75

33 37,5 87,5 37,5 87,5 12,5 62,5 12,5 87,5 0,25 0,25 150 75 0,25

34 12,5 62,5 37,5 62,5 37,5 62,5 12,5 87,5 0,25 0,25 300 75 0,75

35 12,5 87,5 12,5 62,5 12,5 62,5 37,5 87,5 0,25 0,75 300 30 0,25

168

co

nf

ig

ur

ac

ió

nd

el

os

ex

pe

rim

en

to

s


36 37,5 62,5 12,5 62,5 12,5 87,5 12,5 87,5 0,25 0,75 300 75 0,75

37 37,5 87,5 12,5 62,5 37,5 62,5 12,5 62,5 0,75 0,75 300 75 0,25

38 37,5 87,5 37,5 62,5 12,5 62,5 12,5 87,5 0,75 0,75 150 30 0,75

39 12,5 62,5 12,5 62,5 37,5 87,5 37,5 62,5 0,75 0,75 300 30 0,75

40 12,5 62,5 37,5 62,5 37,5 62,5 12,5 87,5 0,25 0,25 300 75 0,75

41 37,5 62,5 37,5 62,5 12,5 62,5 37,5 62,5 0,75 0,25 300 30 0,75

42 12,5 62,5 12,5 87,5 37,5 87,5 37,5 62,5 0,25 0,25 300 75 0,25

43 12,5 87,5 37,5 87,5 37,5 62,5 37,5 62,5 0,75 0,25 150 30 0,25

44 37,5 62,5 37,5 87,5 37,5 87,5 12,5 62,5 0,75 0,25 150 75 0,75

45 12,5 62,5 12,5 62,5 37,5 87,5 37,5 62,5 0,75 0,75 300 30 0,75

46 12,5 62,5 12,5 62,5 12,5 62,5 12,5 62,5 0,25 0,25 150 30 0,25

47 37,5 62,5 37,5 62,5 37,5 87,5 12,5 62,5 0,25 0,75 150 30 0,25

48 37,5 62,5 12,5 87,5 37,5 62,5 37,5 87,5 0,25 0,75 150 30 0,75

49 37,5 62,5 37,5 87,5 37,5 87,5 12,5 62,5 0,75 0,25 150 75 0,75

50 12,5 87,5 12,5 87,5 37,5 87,5 12,5 87,5 0,25 0,75 150 75 0,25

51 37,5 62,5 37,5 62,5 12,5 62,5 37,5 62,5 0,75 0,25 300 30 0,75

52 12,5 62,5 12,5 62,5 12,5 62,5 12,5 62,5 0,25 0,25 150 30 0,25

co

nf

ig

ur

ac

ió

nd

el

os

ex

pe

rim

en

to

s169


53 12,5 62,5 12,5 87,5 37,5 87,5 37,5 62,5 0,25 0,25 300 75 0,25

54 37,5 62,5 12,5 62,5 37,5 62,5 37,5 87,5 0,75 0,25 150 75 0,25

55 37,5 87,5 12,5 62,5 37,5 62,5 12,5 62,5 0,75 0,75 300 75 0,25

56 12,5 62,5 37,5 62,5 12,5 87,5 37,5 87,5 0,75 0,75 150 75 0,25

57 37,5 87,5 37,5 87,5 12,5 62,5 12,5 87,5 0,25 0,25 150 75 0,25

58 12,5 87,5 12,5 87,5 12,5 62,5 37,5 87,5 0,75 0,25 300 75 0,75

59 12,5 62,5 12,5 87,5 12,5 62,5 12,5 62,5 0,75 0,75 150 75 0,75

60 12,5 62,5 37,5 87,5 12,5 87,5 37,5 87,5 0,25 0,25 150 30 0,75

61 12,5 87,5 37,5 62,5 37,5 62,5 37,5 62,5 0,25 0,75 150 75 0,75

62 12,5 87,5 12,5 62,5 37,5 87,5 12,5 87,5 0,75 0,25 150 30 0,75

63 12,5 87,5 12,5 62,5 12,5 62,5 37,5 87,5 0,25 0,75 300 30 0,25

64 12,5 62,5 12,5 87,5 12,5 62,5 12,5 62,5 0,75 0,75 150 75 0,75

65 37,5 87,5 12,5 62,5 37,5 62,5 12,5 62,5 0,75 0,75 300 75 0,25

66 12,5 62,5 12,5 62,5 37,5 87,5 37,5 62,5 0,75 0,75 300 30 0,75

67 12,5 62,5 37,5 87,5 37,5 62,5 12,5 87,5 0,75 0,75 300 30 0,25

68 12,5 87,5 12,5 87,5 37,5 87,5 12,5 87,5 0,25 0,75 150 75 0,25

69 37,5 62,5 12,5 62,5 12,5 87,5 12,5 87,5 0,25 0,75 300 75 0,75

170

co

nf

ig

ur

ac

ió

nd

el

os

ex

pe

rim

en

to

s


70 12,5 87,5 37,5 62,5 12,5 87,5 12,5 62,5 0,75 0,25 300 75 0,25

71 37,5 62,5 12,5 87,5 37,5 62,5 37,5 87,5 0,25 0,75 150 30 0,75

72 37,5 62,5 12,5 87,5 37,5 62,5 37,5 87,5 0,25 0,75 150 30 0,75

73 12,5 87,5 37,5 87,5 12,5 87,5 12,5 62,5 0,25 0,75 300 30 0,75

74 12,5 62,5 37,5 62,5 37,5 62,5 12,5 87,5 0,25 0,25 300 75 0,75

75 37,5 62,5 37,5 87,5 12,5 62,5 37,5 62,5 0,25 0,75 300 75 0,25

76 12,5 62,5 12,5 87,5 12,5 62,5 12,5 62,5 0,75 0,75 150 75 0,75

77 12,5 62,5 12,5 62,5 12,5 62,5 12,5 62,5 0,25 0,25 150 30 0,25

78 37,5 87,5 37,5 62,5 12,5 62,5 12,5 87,5 0,75 0,75 150 30 0,75

79 37,5 62,5 37,5 87,5 12,5 62,5 37,5 62,5 0,25 0,75 300 75 0,25

80 12,5 87,5 12,5 87,5 37,5 87,5 12,5 87,5 0,25 0,75 150 75 0,25

81 12,5 87,5 37,5 87,5 37,5 62,5 37,5 62,5 0,75 0,25 150 30 0,25

82 37,5 62,5 37,5 62,5 37,5 87,5 12,5 62,5 0,25 0,75 150 30 0,25

83 37,5 62,5 37,5 87,5 12,5 62,5 37,5 62,5 0,25 0,75 300 75 0,25

84 37,5 87,5 37,5 87,5 12,5 62,5 12,5 87,5 0,25 0,25 150 75 0,25

85 12,5 87,5 37,5 62,5 37,5 62,5 37,5 62,5 0,25 0,75 150 75 0,75

86 12,5 87,5 37,5 62,5 12,5 87,5 12,5 62,5 0,75 0,25 300 75 0,25

co

nf

ig

ur

ac

ió

nd

el

os

ex

pe

rim

en

to

s171


87 37,5 62,5 12,5 62,5 12,5 87,5 12,5 87,5 0,25 0,75 300 75 0,75

88 12,5 62,5 37,5 87,5 37,5 62,5 12,5 87,5 0,75 0,75 300 30 0,25

89 12,5 87,5 12,5 62,5 37,5 87,5 12,5 87,5 0,75 0,25 150 30 0,75

90 12,5 62,5 37,5 62,5 12,5 87,5 37,5 87,5 0,75 0,75 150 75 0,25

91 12,5 62,5 37,5 87,5 37,5 62,5 12,5 87,5 0,75 0,75 300 30 0,25

92 37,5 87,5 37,5 62,5 37,5 87,5 37,5 87,5 0,25 0,25 300 30 0,25

93 12,5 87,5 37,5 62,5 37,5 62,5 37,5 62,5 0,25 0,75 150 75 0,75

94 37,5 87,5 12,5 87,5 12,5 87,5 37,5 62,5 0,75 0,75 150 30 0,25

95 37,5 62,5 12,5 62,5 37,5 62,5 37,5 87,5 0,75 0,25 150 75 0,25

96 37,5 62,5 12,5 87,5 12,5 87,5 12,5 87,5 0,75 0,25 300 30 0,25

Tabla 40 Configuración del experimento para el algoritmo Estrategia Evolutiva.

172

co

nf

ig

ur

ac

ió

nd

el

os

ex

pe

rim

en

to

s

Exp. αa βa αt βt αm βm αp βp restm restp count_it static_restart

1 37,5 87,5 12,5 87,5 12,5 87,5 12,5 87,5 0,25 0,75 1500 false

2 37,5 62,5 37,5 62,5 12,5 62,5 12,5 87,5 0,75 0,75 500 true

3 37,5 87,5 37,5 87,5 12,5 62,5 37,5 87,5 0,25 0,25 500 false

4 37,5 62,5 37,5 87,5 37,5 87,5 37,5 62,5 0,25 0,75 500 true

5 12,5 87,5 12,5 87,5 12,5 62,5 37,5 62,5 0,75 0,75 500 true

6 12,5 62,5 37,5 62,5 12,5 87,5 37,5 62,5 0,25 0,75 1500 false

7 37,5 87,5 37,5 62,5 12,5 62,5 12,5 62,5 0,25 0,75 1500 true

8 37,5 62,5 37,5 62,5 37,5 87,5 12,5 87,5 0,25 0,25 1500 false

9 37,5 62,5 37,5 87,5 12,5 62,5 37,5 62,5 0,75 0,25 1500 false

10 12,5 62,5 37,5 87,5 12,5 87,5 12,5 87,5 0,25 0,25 500 true

11 37,5 62,5 12,5 87,5 37,5 62,5 12,5 62,5 0,25 0,25 1500 true

12 12,5 87,5 12,5 87,5 37,5 87,5 37,5 62,5 0,25 0,25 1500 false

13 12,5 62,5 12,5 87,5 37,5 87,5 37,5 87,5 0,75 0,25 500 false

14 12,5 87,5 12,5 87,5 37,5 87,5 37,5 62,5 0,25 0,25 1500 false

15 37,5 87,5 12,5 62,5 12,5 87,5 37,5 62,5 0,25 0,25 500 true

16 12,5 87,5 12,5 62,5 12,5 62,5 12,5 87,5 0,75 0,25 1500 false

17 12,5 62,5 37,5 87,5 37,5 62,5 12,5 87,5 0,75 0,75 1500 false

co

nf

ig

ur

ac

ió

nd

el

os

ex

pe

rim

en

to

s173


18 37,5 62,5 37,5 62,5 37,5 87,5 12,5 87,5 0,25 0,25 1500 false

19 37,5 62,5 12,5 87,5 37,5 62,5 12,5 62,5 0,25 0,25 1500 true

20 12,5 87,5 37,5 62,5 37,5 62,5 37,5 87,5 0,25 0,25 1500 true

21 12,5 62,5 37,5 87,5 12,5 87,5 12,5 87,5 0,25 0,25 500 true

22 37,5 62,5 37,5 87,5 12,5 62,5 37,5 62,5 0,75 0,25 1500 false

23 37,5 87,5 12,5 62,5 37,5 62,5 37,5 62,5 0,75 0,75 1500 false

24 12,5 62,5 12,5 62,5 12,5 62,5 12,5 62,5 0,25 0,25 500 false

25 37,5 62,5 12,5 62,5 12,5 87,5 37,5 87,5 0,75 0,25 1500 true

26 37,5 62,5 12,5 62,5 37,5 62,5 37,5 87,5 0,25 0,75 500 false

27 12,5 87,5 37,5 62,5 37,5 62,5 37,5 87,5 0,25 0,25 1500 true

28 37,5 87,5 12,5 87,5 37,5 62,5 12,5 87,5 0,75 0,25 500 true

29 37,5 62,5 12,5 87,5 12,5 87,5 12,5 62,5 0,75 0,75 500 false

30 37,5 87,5 37,5 62,5 12,5 62,5 12,5 62,5 0,25 0,75 1500 true

31 12,5 87,5 12,5 62,5 12,5 62,5 12,5 87,5 0,75 0,25 1500 false

32 12,5 62,5 37,5 62,5 37,5 62,5 37,5 62,5 0,75 0,25 500 true

33 12,5 62,5 12,5 62,5 37,5 87,5 12,5 62,5 0,75 0,75 1500 true

34 37,5 62,5 12,5 62,5 37,5 62,5 37,5 87,5 0,25 0,75 500 false

174

co

nf

ig

ur

ac

ió

nd

el

os

ex

pe

rim

en

to

s


35 12,5 62,5 37,5 62,5 37,5 62,5 37,5 62,5 0,75 0,25 500 true

36 12,5 87,5 37,5 62,5 12,5 87,5 37,5 87,5 0,75 0,75 500 false

37 12,5 87,5 12,5 62,5 37,5 87,5 12,5 87,5 0,25 0,75 500 true

38 37,5 62,5 12,5 87,5 12,5 87,5 12,5 62,5 0,75 0,75 500 false

39 37,5 87,5 37,5 62,5 37,5 87,5 12,5 62,5 0,75 0,25 500 false

40 37,5 87,5 37,5 87,5 12,5 62,5 37,5 87,5 0,25 0,25 500 false

41 12,5 87,5 37,5 87,5 12,5 87,5 12,5 62,5 0,75 0,25 1500 true

42 37,5 87,5 37,5 87,5 37,5 87,5 37,5 87,5 0,75 0,75 1500 true

43 12,5 87,5 37,5 87,5 37,5 62,5 12,5 62,5 0,25 0,75 500 false

44 37,5 62,5 37,5 62,5 12,5 62,5 12,5 87,5 0,75 0,75 500 true

45 12,5 87,5 12,5 62,5 37,5 87,5 12,5 87,5 0,25 0,75 500 true

46 12,5 87,5 12,5 62,5 37,5 87,5 12,5 87,5 0,25 0,75 500 true

47 37,5 62,5 12,5 87,5 37,5 62,5 12,5 62,5 0,25 0,25 1500 true

48 37,5 62,5 37,5 87,5 37,5 87,5 37,5 62,5 0,25 0,75 500 true

49 12,5 62,5 12,5 62,5 12,5 62,5 12,5 62,5 0,25 0,25 500 false

50 12,5 62,5 37,5 62,5 12,5 87,5 37,5 62,5 0,25 0,75 1500 false

51 12,5 62,5 12,5 87,5 37,5 87,5 37,5 87,5 0,75 0,25 500 false

co

nf

ig

ur

ac

ió

nd

el

os

ex

pe

rim

en

to

s175


52 12,5 62,5 12,5 87,5 37,5 87,5 37,5 87,5 0,75 0,25 500 false

53 12,5 87,5 12,5 87,5 12,5 62,5 37,5 62,5 0,75 0,75 500 true

54 12,5 87,5 37,5 87,5 37,5 62,5 12,5 62,5 0,25 0,75 500 false

55 37,5 87,5 12,5 87,5 37,5 62,5 12,5 87,5 0,75 0,25 500 true

56 37,5 62,5 37,5 87,5 12,5 62,5 37,5 62,5 0,75 0,25 1500 false

57 12,5 87,5 37,5 87,5 12,5 87,5 12,5 62,5 0,75 0,25 1500 true

58 37,5 62,5 12,5 62,5 37,5 62,5 37,5 87,5 0,25 0,75 500 false

59 37,5 87,5 37,5 87,5 37,5 87,5 37,5 87,5 0,75 0,75 1500 true

60 12,5 62,5 12,5 87,5 12,5 62,5 37,5 87,5 0,25 0,75 1500 true

61 12,5 62,5 37,5 87,5 12,5 87,5 12,5 87,5 0,25 0,25 500 true

62 37,5 87,5 37,5 62,5 37,5 87,5 12,5 62,5 0,75 0,25 500 false

63 37,5 87,5 37,5 87,5 37,5 87,5 37,5 87,5 0,75 0,75 1500 true

64 37,5 87,5 12,5 62,5 12,5 87,5 37,5 62,5 0,25 0,25 500 true

65 37,5 87,5 12,5 87,5 37,5 62,5 12,5 87,5 0,75 0,25 500 true

66 37,5 62,5 37,5 87,5 37,5 87,5 37,5 62,5 0,25 0,75 500 true

67 37,5 87,5 12,5 62,5 37,5 62,5 37,5 62,5 0,75 0,75 1500 false

68 37,5 87,5 12,5 87,5 12,5 87,5 12,5 87,5 0,25 0,75 1500 false

176

co

nf

ig

ur

ac

ió

nd

el

os

ex

pe

rim

en

to

s


69 12,5 87,5 37,5 87,5 12,5 87,5 12,5 62,5 0,75 0,25 1500 true

70 37,5 62,5 12,5 62,5 12,5 87,5 37,5 87,5 0,75 0,25 1500 true

71 12,5 62,5 12,5 62,5 12,5 62,5 12,5 62,5 0,25 0,25 500 false

72 12,5 87,5 12,5 87,5 12,5 62,5 37,5 62,5 0,75 0,75 500 true

73 12,5 62,5 12,5 62,5 37,5 87,5 12,5 62,5 0,75 0,75 1500 true

74 12,5 87,5 12,5 62,5 12,5 62,5 12,5 87,5 0,75 0,25 1500 false

75 37,5 87,5 37,5 62,5 12,5 62,5 12,5 62,5 0,25 0,75 1500 true

76 12,5 62,5 12,5 87,5 12,5 62,5 37,5 87,5 0,25 0,75 1500 true

77 37,5 87,5 37,5 62,5 37,5 87,5 12,5 62,5 0,75 0,25 500 false

78 12,5 62,5 37,5 87,5 37,5 62,5 12,5 87,5 0,75 0,75 1500 false

79 12,5 62,5 37,5 62,5 12,5 87,5 37,5 62,5 0,25 0,75 1500 false

80 12,5 87,5 37,5 62,5 37,5 62,5 37,5 87,5 0,25 0,25 1500 true

81 37,5 62,5 12,5 87,5 12,5 87,5 12,5 62,5 0,75 0,75 500 false

82 37,5 62,5 12,5 62,5 12,5 87,5 37,5 87,5 0,75 0,25 1500 true

83 12,5 87,5 37,5 62,5 12,5 87,5 37,5 87,5 0,75 0,75 500 false

84 12,5 62,5 37,5 87,5 37,5 62,5 12,5 87,5 0,75 0,75 1500 false

85 12,5 62,5 12,5 62,5 37,5 87,5 12,5 62,5 0,75 0,75 1500 true

co

nf

ig

ur

ac

ió

nd

el

os

ex

pe

rim

en

to

s177


86 12,5 62,5 12,5 87,5 12,5 62,5 37,5 87,5 0,25 0,75 1500 true

87 12,5 87,5 12,5 87,5 37,5 87,5 37,5 62,5 0,25 0,25 1500 false

88 37,5 87,5 12,5 62,5 12,5 87,5 37,5 62,5 0,25 0,25 500 true

89 12,5 62,5 37,5 62,5 37,5 62,5 37,5 62,5 0,75 0,25 500 true

90 12,5 87,5 37,5 62,5 12,5 87,5 37,5 87,5 0,75 0,75 500 false

91 37,5 62,5 37,5 62,5 37,5 87,5 12,5 87,5 0,25 0,25 1500 false

92 37,5 62,5 37,5 62,5 12,5 62,5 12,5 87,5 0,75 0,75 500 true

93 37,5 87,5 12,5 62,5 37,5 62,5 37,5 62,5 0,75 0,75 1500 false

94 37,5 87,5 12,5 87,5 12,5 87,5 12,5 87,5 0,25 0,75 1500 false

95 12,5 87,5 37,5 87,5 37,5 62,5 12,5 62,5 0,25 0,75 500 false

96 37,5 87,5 37,5 87,5 12,5 62,5 37,5 87,5 0,25 0,25 500 false

Tabla 41 Configuración del experimento para el algoritmo Escalador de Colinas con Reinicio.

178

co

nf

ig

ur

ac

ió

nd

el

os

ex

pe

rim

en

to

s

Exp. αa βa αt βt αm βm αp βp restm restp

1 12,5 87,5 12,5 62,5 12,5 62,5 12,5 62,5 0,75 0,25

2 12,5 87,5 12,5 87,5 12,5 87,5 12,5 87,5 0,25 0,75

3 37,5 62,5 37,5 62,5 37,5 87,5 12,5 87,5 0,25 0,75

4 37,5 87,5 37,5 62,5 12,5 62,5 12,5 87,5 0,75 0,75

5 12,5 87,5 37,5 62,5 37,5 87,5 12,5 87,5 0,75 0,25

6 12,5 62,5 12,5 62,5 37,5 87,5 12,5 62,5 0,25 0,25

7 12,5 87,5 37,5 87,5 12,5 62,5 37,5 87,5 0,75 0,25

8 37,5 62,5 37,5 62,5 12,5 87,5 37,5 62,5 0,75 0,25

9 12,5 62,5 37,5 87,5 12,5 87,5 12,5 62,5 0,75 0,75

10 37,5 87,5 12,5 62,5 12,5 87,5 37,5 87,5 0,25 0,25

11 37,5 62,5 12,5 62,5 37,5 62,5 37,5 87,5 0,75 0,25

12 37,5 62,5 12,5 62,5 12,5 62,5 12,5 62,5 0,25 0,75

13 12,5 87,5 12,5 87,5 37,5 87,5 37,5 62,5 0,75 0,25

14 37,5 87,5 37,5 87,5 37,5 87,5 37,5 87,5 0,75 0,75

15 37,5 62,5 37,5 87,5 12,5 62,5 37,5 87,5 0,25 0,75

16 37,5 62,5 37,5 87,5 12,5 62,5 37,5 87,5 0,25 0,75

17 12,5 62,5 37,5 87,5 12,5 87,5 12,5 62,5 0,75 0,75

co

nf

ig

ur

ac

ió

nd

el

os

ex

pe

rim

en

to

s179


18 37,5 87,5 12,5 87,5 37,5 62,5 12,5 87,5 0,25 0,25

19 37,5 62,5 12,5 87,5 37,5 87,5 37,5 62,5 0,25 0,75

20 12,5 62,5 37,5 87,5 37,5 87,5 37,5 87,5 0,25 0,25

21 12,5 62,5 37,5 62,5 37,5 62,5 37,5 62,5 0,75 0,75

22 12,5 87,5 37,5 62,5 12,5 87,5 37,5 62,5 0,25 0,75

23 37,5 87,5 12,5 87,5 12,5 62,5 37,5 62,5 0,75 0,75

24 12,5 62,5 12,5 87,5 37,5 62,5 12,5 87,5 0,75 0,75

25 37,5 62,5 37,5 62,5 37,5 87,5 12,5 87,5 0,25 0,75

26 37,5 87,5 37,5 62,5 37,5 62,5 37,5 62,5 0,25 0,25

27 37,5 87,5 12,5 87,5 12,5 62,5 37,5 62,5 0,75 0,75

28 37,5 62,5 12,5 87,5 37,5 87,5 37,5 62,5 0,25 0,75

29 37,5 62,5 12,5 87,5 12,5 87,5 12,5 87,5 0,75 0,25

30 37,5 62,5 12,5 62,5 12,5 62,5 12,5 62,5 0,25 0,75

31 12,5 62,5 37,5 62,5 37,5 62,5 37,5 62,5 0,75 0,75

32 12,5 62,5 37,5 87,5 12,5 87,5 12,5 62,5 0,75 0,75

33 37,5 62,5 37,5 87,5 37,5 62,5 12,5 62,5 0,75 0,25

34 37,5 62,5 37,5 87,5 37,5 62,5 12,5 62,5 0,75 0,25

180

co

nf

ig

ur

ac

ió

nd

el

os

ex

pe

rim

en

to

s


35 37,5 62,5 12,5 62,5 37,5 62,5 37,5 87,5 0,75 0,25

36 37,5 62,5 37,5 62,5 12,5 87,5 37,5 62,5 0,75 0,25

37 12,5 62,5 12,5 87,5 37,5 62,5 12,5 87,5 0,75 0,75

38 37,5 62,5 12,5 87,5 12,5 87,5 12,5 87,5 0,75 0,25

39 12,5 62,5 12,5 87,5 12,5 62,5 37,5 62,5 0,25 0,25

40 12,5 87,5 37,5 62,5 12,5 87,5 37,5 62,5 0,25 0,75

41 12,5 62,5 12,5 62,5 37,5 87,5 12,5 62,5 0,25 0,25

42 12,5 87,5 37,5 87,5 12,5 62,5 37,5 87,5 0,75 0,25

43 12,5 62,5 12,5 62,5 12,5 87,5 37,5 87,5 0,75 0,75

44 12,5 87,5 12,5 62,5 12,5 62,5 12,5 62,5 0,75 0,25

45 12,5 87,5 12,5 87,5 37,5 87,5 37,5 62,5 0,75 0,25

46 12,5 62,5 12,5 62,5 12,5 87,5 37,5 87,5 0,75 0,75

47 12,5 87,5 12,5 87,5 37,5 87,5 37,5 62,5 0,75 0,25

48 37,5 87,5 37,5 87,5 12,5 87,5 12,5 62,5 0,25 0,25

49 37,5 62,5 12,5 87,5 37,5 87,5 37,5 62,5 0,25 0,75

50 12,5 62,5 12,5 87,5 12,5 62,5 37,5 62,5 0,25 0,25

51 12,5 62,5 37,5 62,5 12,5 62,5 12,5 87,5 0,25 0,25

co

nf

ig

ur

ac

ió

nd

el

os

ex

pe

rim

en

to

s181


52 12,5 87,5 37,5 62,5 12,5 87,5 37,5 62,5 0,25 0,75

53 37,5 62,5 12,5 87,5 12,5 87,5 12,5 87,5 0,75 0,25

54 37,5 62,5 12,5 62,5 37,5 62,5 37,5 87,5 0,75 0,25

55 37,5 87,5 37,5 87,5 37,5 87,5 37,5 87,5 0,75 0,75

56 37,5 87,5 37,5 87,5 12,5 87,5 12,5 62,5 0,25 0,25

57 37,5 87,5 37,5 62,5 37,5 62,5 37,5 62,5 0,25 0,25

58 12,5 87,5 12,5 87,5 12,5 87,5 12,5 87,5 0,25 0,75

59 37,5 62,5 37,5 87,5 12,5 62,5 37,5 87,5 0,25 0,75

60 37,5 87,5 12,5 62,5 37,5 87,5 12,5 62,5 0,75 0,75

61 12,5 62,5 37,5 87,5 37,5 87,5 37,5 87,5 0,25 0,25

62 12,5 87,5 12,5 62,5 37,5 62,5 37,5 87,5 0,25 0,75

63 12,5 62,5 12,5 62,5 12,5 87,5 37,5 87,5 0,75 0,75

64 37,5 62,5 12,5 62,5 12,5 62,5 12,5 62,5 0,25 0,75

65 37,5 62,5 37,5 62,5 12,5 87,5 37,5 62,5 0,75 0,25

66 12,5 87,5 12,5 87,5 12,5 87,5 12,5 87,5 0,25 0,75

67 37,5 87,5 12,5 62,5 37,5 87,5 12,5 62,5 0,75 0,75

68 12,5 87,5 12,5 62,5 37,5 62,5 37,5 87,5 0,25 0,75

182

co

nf

ig

ur

ac

ió

nd

el

os

ex

pe

rim

en

to

s


69 12,5 87,5 12,5 62,5 37,5 62,5 37,5 87,5 0,25 0,75

70 12,5 87,5 37,5 87,5 12,5 62,5 37,5 87,5 0,75 0,25

71 37,5 87,5 12,5 87,5 37,5 62,5 12,5 87,5 0,25 0,25

72 12,5 62,5 37,5 87,5 37,5 87,5 37,5 87,5 0,25 0,25

73 37,5 87,5 12,5 87,5 12,5 62,5 37,5 62,5 0,75 0,75

74 37,5 87,5 37,5 87,5 12,5 87,5 12,5 62,5 0,25 0,25

75 12,5 62,5 37,5 62,5 12,5 62,5 12,5 87,5 0,25 0,25

76 12,5 62,5 12,5 62,5 37,5 87,5 12,5 62,5 0,25 0,25

77 12,5 87,5 37,5 87,5 37,5 62,5 12,5 62,5 0,25 0,75

78 12,5 62,5 12,5 87,5 12,5 62,5 37,5 62,5 0,25 0,25

79 12,5 62,5 37,5 62,5 37,5 62,5 37,5 62,5 0,75 0,75

80 37,5 87,5 37,5 62,5 12,5 62,5 12,5 87,5 0,75 0,75

81 12,5 87,5 12,5 62,5 12,5 62,5 12,5 62,5 0,75 0,25

82 12,5 87,5 37,5 62,5 37,5 87,5 12,5 87,5 0,75 0,25

83 12,5 87,5 37,5 62,5 37,5 87,5 12,5 87,5 0,75 0,25

84 37,5 87,5 37,5 87,5 37,5 87,5 37,5 87,5 0,75 0,75

85 37,5 62,5 37,5 87,5 37,5 62,5 12,5 62,5 0,75 0,25

co

nf

ig

ur

ac

ió

nd

el

os

ex

pe

rim

en

to

s183


86 37,5 87,5 12,5 87,5 37,5 62,5 12,5 87,5 0,25 0,25

87 12,5 62,5 37,5 62,5 12,5 62,5 12,5 87,5 0,25 0,25

88 37,5 87,5 37,5 62,5 12,5 62,5 12,5 87,5 0,75 0,75

89 12,5 87,5 37,5 87,5 37,5 62,5 12,5 62,5 0,25 0,75

90 37,5 87,5 37,5 62,5 37,5 62,5 37,5 62,5 0,25 0,25

91 12,5 87,5 37,5 87,5 37,5 62,5 12,5 62,5 0,25 0,75

92 37,5 87,5 12,5 62,5 12,5 87,5 37,5 87,5 0,25 0,25

93 37,5 87,5 12,5 62,5 37,5 87,5 12,5 62,5 0,75 0,75

94 12,5 62,5 12,5 87,5 37,5 62,5 12,5 87,5 0,75 0,75

95 37,5 87,5 12,5 62,5 12,5 87,5 37,5 87,5 0,25 0,25

96 37,5 62,5 37,5 62,5 37,5 87,5 12,5 87,5 0,25 0,75

Tabla 42 Configuración del experimento para el algoritmo Escalador de Colinas.

DC O N F I G U R A C I Ó N D E L O S E X P E R I M E N T O S PA R AE L C A S O D E E S T U D I O

185

186

co

nf

ig

ur

ac

ió

nd

el

os

ex

pe

rim

en

to

sp

ar

ae

lc

as

od

ee

st

ud

io

Exp. ParámetrosECR

ParámetrosAG

ParámetrosEE

Parámetros modelo

1 count_it =500 static =

false

pob_it =150

trunc = 75

pm = 0,25pc = 0,75

pob_it =300

trunc = 30

pm = 0,25

αa = 37,5 βa = 87,5αt = 12,5 βt = 87,5αm = 37,5 βm = 62,5αp = 37,5 βp = 87,5

2 count_it =500

static = true

pob_it =150

trunc = 75

pm = 0,75pc = 0,75

pob_it =300

trunc = 75

pm = 0,25


false

pob_it =150

trunc = 75

pm = 0,25pc = 0,25

pob_it =300

trunc = 30

pm = 0,75

4 count_it =1500

static = true

pob_it =150

trunc = 75

pm = 0,75pc = 0,25

pob_it =300

trunc = 75

pm = 0,75

co

nf

ig

ur

ac

ió

nd

el

os

ex

pe

rim

en

to

sp

ar

ae

lc

as

od

ee

st

ud

io

187

Exp. ParámetrosECR

ParámetrosAG

ParámetrosEE

Parámetros modelo


false

pob_it =150

trunc = 75

pm = 0,25pc = 0,75

pob_it =300

trunc = 30

pm = 0,25

αa = 10 βa = 35

αt = 10 βt = 30

αm = 5 βm = 25

αp = 5 βp = 25

6 count_it =500

static = true

pob_it =150

trunc = 75

pm = 0,75pc = 0,75

pob_it =300

trunc = 75

pm = 0,25


false

pob_it =150

trunc = 75

pm = 0,25pc = 0,25

pob_it =300

trunc = 30

pm = 0,75

8 count_it =1500

static = true

pob_it =150

trunc = 75

pm = 0,75pc = 0,25

pob_it =300

trunc = 75

pm = 0,75

188

co

nf

ig

ur

ac

ió

nd

el

os

ex

pe

rim

en

to

sp

ar

ae

lc

as

od

ee

st

ud

io

Exp. ParámetrosECR

ParámetrosAG

ParámetrosEE

Parámetros modelo


false

pob_it =150

trunc = 75

pm = 0,25pc = 0,75

pob_it =300

trunc = 30

pm = 0,25

αa = 31 βa = 42

αt = 33 βt = 34

αm = 5 βm = 25

αp = 5 βp = 25

10 count_it =500

static = true

pob_it =150

trunc = 75

pm = 0,75pc = 0,75

pob_it =300

trunc = 75

pm = 0,25


false

pob_it =150

trunc = 75

pm = 0,25pc = 0,25

pob_it =300

trunc = 30

pm = 0,75

12 count_it =1500

static = true

pob_it =150

trunc = 75

pm = 0,75pc = 0,25

pob_it =300

trunc = 75

pm = 0,75

co

nf

ig

ur

ac

ió

nd

el

os

ex

pe

rim

en

to

sp

ar

ae

lc

as

od

ee

st

ud

io

189

Exp. ParámetrosECR

ParámetrosAG

ParámetrosEE

Parámetros modelo

Tabla 43 Configuración de los experimentos para los algoritmos Escalador de Colinas con Reinicio, Algoritmo Genético yEstrategia Evolutiva.

B I B L I O G R A F Í A

M.B. Abdelhalim and S.E.-D. Habib. An integrated high-levelhardware/software partitioning methodology. Design Automationfor Embedded Systems, 15(1):19–50, 2011. ISSN 0929-5585. doi:10.1007/s10617-010-9068-9. URL http://dx.doi.org/10.1007/

s10617-010-9068-9.

Pradeep Adhipathi. Model based approach to hardware/softwarepartitioning of soc designs. Master’s thesis, Faculty of the Virgi-nia Polytechnic Institute and State University, 2004. URL http://

citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.58.3531.

I. Alberto and P.M. Mateo. A crossover operator that uses paretooptimality in its definition. TOP, 19(1):67–92, 2011. ISSN 1134-5764. doi: 10.1007/s11750-009-0082-7. URL http://dx.doi.org/

10.1007/s11750-009-0082-7.

F.-F. Amin, K. Mehdi, F. Sied Mehdi, and S. Saeed. Hw/sw parti-tioning using discrete particle swarm. In 17th ACM Great Lakessymposium on VLSI, Stresa-Lago Maggiore, Italy., 2007. ACM.

Jiju Antony. Design of Experiments for Engineers and Scientists. Elsevier,2003.

P. Arató, S. Zuhász, Z. A. Mann, A. Orbán, and D. Papp. Hardware/-software partitioning in embedded system design. In IEEE Interna-tional Symposium on Intelligent Signal Processing, 2003.

Péter Arató, Zoltán Ádám Mann, and András Orbán. Algorithmicaspects of hardware/software partitioning. ACM Trans. Des. Au-tom. Electron. Syst., 10(1):136–156, January 2005. ISSN 1084-4309.doi: 10.1145/1044111.1044119. URL http://doi.acm.org/10.1145/

1044111.1044119.

A. Arias-Montano, Carlos A. Coello Coello, and E. Mezura-Montes.Multiobjective evolutionary algorithms in aeronautical and aeros-pace engineering. Evolutionary Computation, IEEE Transactions on,

191

http://dx.doi.org/10.1007/s10617-010-9068-9

http://dx.doi.org/10.1007/s10617-010-9068-9

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.58.3531

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.58.3531

http://dx.doi.org/10.1007/s11750-009-0082-7

http://dx.doi.org/10.1007/s11750-009-0082-7

http://doi.acm.org/10.1145/1044111.1044119

http://doi.acm.org/10.1145/1044111.1044119

192 bibliografía

16(5):662–694, 2012. ISSN 1089-778X. doi: 10.1109/TEVC.2011.2169968.

Sébastien Le Beux, Guy Bois, Gabriela Nicolescu, Youcef Bouche-baba, Michel Langevin, and Pierre Paulin. Combining map-ping and partitioning exploration for noc-based embedded sys-tems. Journal of Systems Architecture, 56(7):223 – 232, 2010.ISSN 1383-7621. doi: http://dx.doi.org/10.1016/j.sysarc.2010.03.005. URL http://www.sciencedirect.com/science/article/pii/

S1383762110000172. <ce:title>Special Issue on HW/SW Co-Design:Systems and Networks on Chip</ce:title>.

A. Bhattacharya, A. Konar, S. Das, C. Grosan, and A. Abraham. Hard-ware software partitioning problem in embedded system designusing particle swarm optimization algorithm. In International Con-ference on Complex, Intelligent and Software Intensive Systems, pages171–176, 2008.

C.A. Coello Coello, G.L. Lamont, and D.A. van Veldhuizen. Evolu-tionary Algorithms for Solving Multi-Objective Problems. Genetic andEvolutionary Computation. Springer, Berlin, Heidelberg, 2nd edi-tion, 2007. doi: 10.1007/978-0-387-36797-2. URL http://books.

google.com/books?id=rXIuAMw3lGAC.

L. A. Cortés, P. Eles, and Z. Peng. A survey on hardware/soft-ware codesign representation models. Save project report, Dept.of Computer and Information Science, Linköping University, Lin-köping, Sweden, 1999. URL http://ftp.ida.liu.se/labs/eslab/

publications/pap/db/SAVE99.pdf. http://ftp.ida.liu.se/labs/eslab/publications/pap/db/SAVE99.pdf.

Dilip Datta and José Rui Figueira. Some convergence-based m-arycardinal metrics for comparing performances of multi-objectiveoptimizers. Computers & Operations Research, 39(7):1754 – 1762,2012. ISSN 0305-0548. doi: http://dx.doi.org/10.1016/j.cor.2011.10.013. URL http://www.sciencedirect.com/science/article/pii/

S0305054811003017.

Humberto Díaz-Pando, Sergio Cuenca Asensi, Roberto Sepúlveda Li-ma, Jenny Fajardo Calderín, and Alejandro Rosete Suárez. An ap-

http://www.sciencedirect.com/science/article/pii/S1383762110000172


http://books.google.com/books?id=rXIuAMw3lGAC

http://books.google.com/books?id=rXIuAMw3lGAC

http://ftp.ida.liu.se/labs/eslab/publications/pap/db/SAVE99.pdf






bibliografía 193

plication of fuzzy logic for hardware/software partitioning on em-bedded systems. Computación y Sistemas, 17(1):30–40, marzo 2013a.

Humberto Díaz-Pando, Sergio Cuenca Asensi, Roberto Sepúlveda Li-ma, Alejandro Rosete Suárez, and Jenny Fajardo Calderín. Algorit-mos metaheurísticos en el problema del particionado hardware/-software de sistemas embebidos. Inteligencia Artificial, 16(51):1–14,2013b.

Giovanni De Micheli and Rajesh K. Gupta. Hardware/software co-design. Proceedings of the IEEE, 85(3):349–365, 1997.

Joaquín Derrac, Salvador García, Daniel Molina, and Francisco He-rrera. A practical tutorial on the use of nonparametric statisticaltests as a methodology for comparing evolutionary and swarmintelligence algorithms. Swarm and Evolutionary Computation, 1(1):3–18, 2011. URL http://dblp.uni-trier.de/db/journals/swevo/

swevo1.html#DerracGMH11.

Robert P. Dick, David L. Rhodes, and Wayne Wolf. Tgff: Task graphsfor free. In Proceedings of the 6th International Workshop on Hardware/-Software Codesign, CODES/CASHE ’98, pages 97–101, Washington,DC, USA, 1998. IEEE Computer Society. ISBN 0-8186-8442-9. URLhttp://dl.acm.org/citation.cfm?id=278241.278309.

P. Eles, Z. Peng, K. Kuchcinski, and A. Doboli. System level hardwa-re/software partitioning based on simulated annealing and tabusearch. Des Autom Embed Syst, 2(1):5–32, 1997.

Hans-Erik Eriksson and Magnus Penker. Business Modeling WithUML: Business Patterns at Work. Wiley, 1 edition, 2000. ISBN0471295515. URL http://www.amazon.com/gp/redirect.html%

3FASIN=0471295515%26tag=ws%26lcode=xm2%26cID=2025%26ccmID=

165953%26location=/o/ASIN/0471295515%253FSubscriptionId=

13CT5CVB80YFWJEPWS02.

Rolf Ernst, Jorg Henkel, and Thomas Benner. Hardware-softwarecosynthesis for microcontrollers. IEEE Des. Test, 10(4):64–75, Oc-tober 1993. ISSN 0740-7475. doi: 10.1109/54.245964. URL http:

//dx.doi.org/10.1109/54.245964.

http://dblp.uni-trier.de/db/journals/swevo/swevo1.html#DerracGMH11

http://dblp.uni-trier.de/db/journals/swevo/swevo1.html#DerracGMH11

http://dl.acm.org/citation.cfm?id=278241.278309

http://www.amazon.com/gp/redirect.html%3FASIN=0471295515%26tag=ws%26lcode=xm2%26cID=2025%26ccmID=165953%26location=/o/ASIN/0471295515%253FSubscriptionId=13CT5CVB80YFWJEPWS02




http://dx.doi.org/10.1109/54.245964

http://dx.doi.org/10.1109/54.245964

194 bibliografía

H. Finner. On a monotonicity problem in step-down multiple test pro-cedures. Journal of the American Statistical Association, 88(423):920–923, 1993. ISSN 01621459. URL http://www.jstor.org/stable/

2290782.

Milton Friedman. The use of ranks to avoid the assumption of norma-lity implicit in the analysis of variance. Journal of the American Sta-tistical Association, 32(200):pp. 675–701, 1937. ISSN 01621459. URLhttp://www.jstor.org/stable/2279372.

Milton Friedman. A comparison of alternative tests of significancefor the problem of m rankings. The Annals of Mathematical Statistics,11(1):pp. 86–92, 1940. ISSN 00034851. URL http://www.jstor.org/

stable/2235971.

Masahiro Fujita and Hiroshi Nakamura. The standard specc lan-guage. In Proceedings of the 14th International Symposium on Sys-tems Synthesis, ISSS ’01, pages 81–86, New York, NY, USA, 2001.ACM. ISBN 1-58113-418-5. doi: 10.1145/500001.500019. URLhttp://doi.acm.org/10.1145/500001.500019.

Daniel D. Gajski, Jianwen Zhu, Rainer Dömer, Andreas Gerstlauer,and Shuqing Zhao. SPECC: Specification Language and Methodology.Kluwer Academic Publishers, Norwell, MA, USA, 2000.

Michalis D. Galanis, Athanasios Milidonis, George Theodoridis, Di-mitrios Soudris, and Costas E. Goutis. A method for partitioningapplications in hybrid reconfigurable architectures. Des Autom Em-bed Syst, 10:27–47, 2006.

Diana Göhringer, Michael Hübner, Michael Benz, and Jürgen Becker.A design methodology for application partitioning and architectu-re development of reconfigurable multiprocessor systems-on-chip.In 18th IEEE Annual International Symposium on Field-ProgrammableCustom Computing Machines, 2010. doi: 10.1109/FCCM.2010.47.

David E. Goldberg. Genetic Algorithms in Search, Optimization and Ma-chine Learning. Addison-Wesley Longman Publishing Co., Inc., Bos-ton, MA, USA, 1st edition, 1989. ISBN 0201157675.

http://www.jstor.org/stable/2290782





http://doi.acm.org/10.1145/500001.500019

bibliografía 195

Jens Gottlieb and Günther R. Raidl, editors. Evolutionary Compu-tation in Combinatorial Optimization, 6th European Conference, Evo-COP 2006, Budapest, Hungary, April 10-12, 2006, Proceedings, vo-lume 3906 of Lecture Notes in Computer Science, 2006. Springer.ISBN 3-540-33178-6. URL http://dblp.uni-trier.de/db/conf/

evoW/evocop2006.html.

Rajesh K. Gupta and Giovanni De Micheli. Hardware-softwarecosynthesis for digital systems. IEEE Design & Test of Computers,10(3):29–41, July 1993. ISSN 0740-7475. doi: 10.1109/54.232470.

M. R. Guthaus, J. S. Ringenberg, D. Ernst, T. M. Austin, T. Mud-ge, and R. B. Brown. Mibench: A free, commercially represen-tative embedded benchmark suite. In Proceedings of the WorkloadCharacterization, 2001. WWC-4. 2001 IEEE International Workshop,WWC ’01, pages 3–14, Washington, DC, USA, 2001. IEEE Compu-ter Society. ISBN 0-7803-7315-4. doi: 10.1109/WWC.2001.15. URLhttp://dx.doi.org/10.1109/WWC.2001.15.

Honglei Han, Wenju Liu, Jigang Wu, and Guiyuan Jiang. Ef-ficient algorithm for hardware/software partitioning andscheduling on mpsoc. Journal of Computers, 8(1), 2013. URLhttp://ojs.academypublisher.com/index.php/jcp/article/

view/jcp08016168.

F. Harary. Graph Theory. Addison-Wesley, Reading, MA, 1969.

Jörg Henkel and Rolf Ernst. An approach to automated hardwa-re/software partitioning using a flexible granularity that is dri-ven by high-level estimation techniques. IEEE Trans. Very LargeScale Integr. Syst., 9(2):273–290, April 2001. ISSN 1063-8210. doi:10.1109/92.924041.

Sture Holm. A simple sequentially rejective multiple test procedure.Scandinavian Journal of Statistics, 6(2):65–70, 1979. ISSN 03036898.URL http://www.jstor.org/stable/4615733.

Yue Huang and Yong-Soo Kim. Boltzmann machine incorporatedhybrid neural fuzzy system for hardware/software partitioning inembedded system design. In Proceedings of the 4th international confe-rence on Modeling Decisions for Artificial Intelligence, MDAI ’07, pages

http://dblp.uni-trier.de/db/conf/evoW/evocop2006.html

http://dblp.uni-trier.de/db/conf/evoW/evocop2006.html

http://dx.doi.org/10.1109/WWC.2001.15

http://ojs.academypublisher.com/index.php/jcp/article/view/jcp08016168

http://ojs.academypublisher.com/index.php/jcp/article/view/jcp08016168


196 bibliografía

307–317, Berlin, Heidelberg, 2007. Springer-Verlag. ISBN 978-3-540-73728-5. doi: 10.1007/978-3-540-73729-2\_29.

M. Jagadeeswari and M. C. Bhuvaneswari. Estimation of hw/sw costparameters in altera fpga design environment. WSEAS Transactionson Information Science and Applications, 8(11):430–439, 2011. URLwww.scopus.com.

Wu Jigang and Thambipillai Srikanthan. Algorithmic aspects ofarea-efficient hardware/software partitioning. Journal of Super-computing, 38(3):223–235, December 2006a. ISSN 0920-8542. doi:10.1007/s11227-006-8045-3.

Wu Jigang and Thambipillai Srikanthan. Low-complex dynamic pro-gramming algorithm for hardware/software partitioning. Informa-tion Processing Letters, 98(2):41–46, April 2006b. ISSN 0020-0190. doi:10.1016/j.ipl.2005.12.008.

Wu Jigang, Thambipillai Srikanthan, and Tao Jiao. Algorithmic as-pects for functional partitioning and scheduling in hardware/soft-ware co-design. Des Autom Embed Syst, 12(4):345–375, 2008a. ISSN0929-5585. doi: 10.1007/s10617-008-9032-0.

Wu Jigang, Thambipillai Srikanthan, and Guang-Wei Zou. New mo-del and algorithm for hardware/software partitioning. Journal ofComputer Science and Technology, 23(4):644–651, July 2008b. ISSN1000-9000. doi: 10.1007/s11390-008-9160-9.

Terry Jones. Evolutionary Algorithms, Fitness Landscapes and Search.PhD thesis, University of New Mexico, 1995.

A. Kalavade and E. A. Lee. The extended partitioning problem: Hard-ware/software mapping, scheduling and implementation-bin selec-tion. Des Autom Embed Syst, 2(2):125–164, 1997.

Young-Jun Kim and Taewhan Kim. A hw/sw partitioner for multi-mode multi-task embedded applications. Journal of VLSI Signal Pro-cessing, 44:269–283, 2006.

Trong-Yen Lee, Yang-Hsin Fan, Yu-Min Cheng, Chia-Chun Tsai, andRong-Shue Hsiao. Enhancement of hardware-software partition for

www.scopus.com

bibliografía 197

embedded multiprocessor fpga systems. In Intelligent InformationHiding and Multimedia Signal Processing, 2007. IIHMSP 2007. ThirdInternational Conference on, volume 1, pages 19–22, 2007a. doi: 10.1109/IIHMSP.2007.4457483.

Trong-Yen Lee, Yang-Hsin Fan, Yu-Min Cheng, Chia-Chun Tsai, andRong-Shue Hsiao. Hardware-oriented partition for embedded mul-tiprocessor fpga systems. In Innovative Computing, Information andControl, 2007. ICICIC ’07. Second International Conference on, pages65–65, 2007b. doi: 10.1109/ICICIC.2007.332.

Trong-Yen Lee, Yang-Hsin Fan, Yu-Min Cheng, Chia-Chun Tsai, andRong-Shue Hsiao. An efficiently hardware-software partitioningfor embedded multiprocessor fpga system. In International multi-conference of engineers and computer scientists, pages 346–351, HongKong, 2007c.

Trong-Yen Lee, Yang-Hsin Fan, Yu-Min Cheng, Chia-Chun Tsai,and Rong-Shue Hsiao. Enhancement of hardware-software par-tition for embedded multiprocessor fpga systems. In Bin-YihLiao, Jeng-Shyang Pan, Lakhmi C. Jain, Mark Liao, Hideki No-da, and Anthony T. S. Ho, editors, IIH-MSP, pages 19–22. IEEE,2007d. ISBN 978-0-7695-2994-3. URL http://dblp.uni-trier.de/

db/conf/iih-msp/iih-msp2007.html#LeeFCTH07.

Tzong-Yen Lin, Yu-Ting Hung, and Rong-Guey Chang. Efficient hard-ware/software partitioning approach for embedded multiproces-sor systems. In VLSI Design, Automation and Test, 2006 InternationalSymposium on, pages 1–4, 2006. doi: 10.1109/VDAT.2006.258167.

Yang Liu and Qing Cheng Li. Hardware software partitioning usingimmune algorithm based on pareto. In Artificial Intelligence andComputational Intelligence, 2009. AICI ’09. International Conference on,volume 2, pages 176–180, 2009. doi: 10.1109/AICI.2009.39.

Marisa López-Vallejo and Juan Carlos López. On the hardware-software partitioning problem: System modeling and partitioningtechniques. ACM Trans. Des. Autom. Electron. Syst. (TODAES), 8(3):269–297, July 2003. ISSN 1084-4309. doi: 10.1145/785411.785412.

http://dblp.uni-trier.de/db/conf/iih-msp/iih-msp2007.html#LeeFCTH07

http://dblp.uni-trier.de/db/conf/iih-msp/iih-msp2007.html#LeeFCTH07

198 bibliografía

M. L. López, C. A. Iglesias, and J. C. López. A knowledge-based sys-tem for hardware-software partitioning. In Proceedings of the confe-rence on Design, automation and test in Europe, DATE ’98, pages 914–915, Washington, DC, USA, 1998. IEEE Computer Society. ISBN0-8186-8359-7. URL http://dl.acm.org/citation.cfm?id=368058.

368458.

M. López Vallejo, J.C. López, and C Iglesias. Hardware-software par-titioning at the knowledge level. J. Applied Intell., 10:173–184, 1999.

Xiao-zhang Lu, Wei Liu, and Yao-dong Tao. Method of hw/sw parti-tioning based on nsga-ii. J. Comput. Appl., 29(1):238–241, 2009. doi:10.3724/SP.J.1087.2009.238.

J. Madsen, J. Grode, P.V. Knudsen, M.E. Petersen, and A. Haxthausen.Lycos: the lyngby co-synthesis system. Des Autom Embed Syst, 2(2):195–235, 1997. ISSN 0929-5585. doi: 10.1023/A:1008884219274.

Zoltán Ádám Mann. Partitioning algorithms for hardware/software co-design. PhD thesis, Budapest Univerity of Technology and Econo-mics, Department of Control Engineering and Information Techno-logy, 2004.

P.M. Mateo and I. Alberto. A mutation operator based on a pa-reto ranking for multi-objective evolutionary algorithms. Jour-nal of Heuristics, 18(1):53–89, 2012. ISSN 1381-1231. doi:10.1007/s10732-011-9156-4. URL http://dx.doi.org/10.1007/

s10732-011-9156-4.

José Tomás Palma Méndez and Roque Marín Morales. InteligenciaArtificial: métodos, técnicas y aplicaciones. McGraw-Hill, 2008.

Douglas C. Montgomery. Design and Analysis of Experiments. Wiley, 7

edition, 2009.

Luiza de M. Mourelle and Nadia Nedjah. Efficient cryptographichardware using the co-design methodology. In Proceedings of theInternational Conference on Information Technology: Coding and Compu-ting (ITCC’04) Volume 2 - Volume 2, ITCC ’04, pages 508–, Washing-ton, DC, USA, 2004. IEEE Computer Society. ISBN 0-7695-2108-8.URL http://dl.acm.org/citation.cfm?id=977403.978515.



http://dx.doi.org/10.1007/s10732-011-9156-4

http://dx.doi.org/10.1007/s10732-011-9156-4


bibliografía 199

Pankaj Kumar Nath and Dilip Datta. Multi-objective hardware-software partitioning of embedded systems: A case study of{JPEG} encoder. Applied Soft Computing, 15(0):30 – 41, 2014.ISSN 1568-4946. doi: http://dx.doi.org/10.1016/j.asoc.2013.10.032. URL http://www.sciencedirect.com/science/article/pii/

S1568494613003669.

Ralf Niemann. Hardware/Software co-design for data flow dominated em-bedded systems. Kluwer Academic Publishers, Boston, 1998.

M. Purnaprajna, M. Reformata, and W. Pedrycza. Genetic algorithmsfor hardware-software partitioning and optimal resource allocation.Journal of Systems Architecture, 53(7):339–354, 2007.

Alejandro Rosete-Suárez. Una solución flexible y eficiente para el trazadode grafos basada en el Escalador de Colinas Estocástico. PhD thesis,Facultad de Ingeniería Industrial, CUJAE, La Habana, 2000.

Alejandro Rosete-Suárez, Alberto Nogueira-Keeling, Alberto Ochoa-Rodríguez, and Michèle Sebag. Hacia un enfoque general del tra-zado de grafos. Revista Iberoamericana de Inteligencia Artificial., 3

(8):18–26, 1999a. URL http://polar.lsi.uned.es/revista/index.

php/ia/article/view/258/0.

Alejandro Rosete-Suárez, Alberto Ochoa-Rodríguez, and Michele Se-bag. Automatic graph drawing and stochastic hill climbing. InWolfgang Banzhaf, Jason Daida, Agoston E. Eiben, Max H. Garzon,Vasant Honavar, Mark Jakiela, and Robert E. Smith, editors, Pro-ceedings of the Genetic and Evolutionary Computation Conference, vo-lume 2, pages 1699–1706, Orlando, Florida, USA, 13-17 July 1999b.Morgan Kaufmann. ISBN 1-55860-611-4. URL http://www.cs.bham.

ac.uk/~wbl/biblio/gecco1999/RW-726f.PS.

Ruhul Sarker and CarlosA. Coello Coello. Assessment methodolo-gies for multiobjective evolutionary algorithms. In Evolutionary Op-timization, volume 48 of International Series in Operations Research &Management Science, pages 177–195. Springer US, 2002. ISBN 978-0-7923-7654-5. doi: 10.1007/0-306-48041-7_7. URL http://dx.doi.

org/10.1007/0-306-48041-7_7.



http://polar.lsi.uned.es/revista/index.php/ia/article/view/258/0

http://polar.lsi.uned.es/revista/index.php/ia/article/view/258/0

http://www.cs.bham.ac.uk/~wbl/biblio/gecco1999/RW-726f.PS

http://www.cs.bham.ac.uk/~wbl/biblio/gecco1999/RW-726f.PS

http://dx.doi.org/10.1007/0-306-48041-7_7

http://dx.doi.org/10.1007/0-306-48041-7_7

200 bibliografía

Patrick Schaumont. A Practical Introduction to Hardware/Software Code-sign. Springer, 2010. ISBN 978-1-4419-5999-7. doi: http://dx.doi.org/10.1007/978-1-4419-6000-9.

Jason R. Schott. Fault tolerant design using single and multicriteriagenetic algorithm optimization. Master’s thesis, Massachusetts Ins-titute of Technology, May 1995.

O. Schutze, X. Esquivel, A. Lara, and Carlos A. Coello Coello. Usingthe averaged hausdorff distance as a performance measure in evo-lutionary multiobjective optimization. Evolutionary Computation,IEEE Transactions on, 16(4):504–522, 2012. ISSN 1089-778X. doi:10.1109/TEVC.2011.2161872.

M. Schwiegershausen, H. Kropp, and P. Pirsch. A system level hw/swpartitioning and optimization tool. In Proceedings of the conference onEuropean design automation, EURO-DAC ’96/EURO-VHDL ’96, pa-ges 120–125, Los Alamitos, CA, USA, 1996. IEEE Computer SocietyPress. ISBN 0-8186-7573-X. URL http://dl.acm.org/citation.

cfm?id=252471.252497.

A. Shaout, A. H. El-Mousa, and K. Mattar. Specification and mode-ling of hw/sw co-design for heterogeneous embedded systems. InWorld Congress on Engineering, WCE, 2009.

V. Srinivasan, S. Radhakrishnan, and R. Vemuri. Hardware softwarepartitioning with integrated hardware design space exploration. InDATE, pages 28–35, Paris, France, 1998.

Stuart Swan. An introduction to system level modeling in systemc2.0. Technical report, 2001. URL http://www.systemc.org.

El-Ghazali Talbi. Metaheuristics: from design to implementation. JohnWiley & Sons, Inc., Hoboken, New Jersey, 2009.

Qiaoling Tong, Xuecheng Zou, Qiao Zhang, Fei Gao, and HengqingTong. The hardware/software partitioning in embedded system byimproved particle swarm optimization algorithm. In Embedded Com-puting, 2008. SEC ’08. Fifth IEEE International Symposium on, pages43–46, 2008. doi: 10.1109/SEC.2008.23.



http://www.systemc.org

bibliografía 201

F. Vahid and T. D. Le. Extending the kenighan/lin heuristic for hard-ware and software functional partitioning. Des Autom Embed Syst,2:237–261, 1997.

Frank Vahid. Modifying min-cut for hardware and software functio-nal partitioning. In Proceedings of the 5th International Workshop onHardware/Software Co-Design, CODES ’97, pages 43–48, Washington,DC, USA, 1997. IEEE Computer Society. ISBN 0-8186-7895-X. URLhttp://dl.acm.org/citation.cfm?id=792768.793517.

Frank Vahid and Tony Givargis. Embedded System Design: A UnifiedHardware/Software Introduction. J. Wiley and Sons, 2002.

David A. van Veldhuizen and Gary B. Lamont. Evolutionary compu-tation and convergence to a pareto front. In John R. Koza, edi-tor, Late Breaking Papers at the Genetic Programming 1998 Conferen-ce, University of Wisconsin, Madison, Wisconsin, USA, 22–25 July1998. Stanford University Bookstore. URL http://www.lania.mx/

~ccoello/EMOO/vanvel2.ps.gz.

David A. van Veldhuizen and Gary B. Lamont. Multiobjective evolu-tionary algorithm test suites. In SAC, pages 351–357, 1999. URLhttp://dblp.uni-trier.de/db/conf/sac/sac99.html.

David A. van Veldhuizen and Gary B. Lamont. On measuring multi-objective evolutionary algorithm performance. In 2000 Congress onEvolutionary Computation, volume 1, pages 204–211, 2000.

José L. Verdegay, Ronald R. Yager, and Piero P. Bonissone. On heuris-tics as a fundamental constituent of soft computing. Fuzzy Sets Syst.,159(7):846–855, April 2008. ISSN 0165-0114. doi: 10.1016/j.fss.2007.08.014. URL http://dx.doi.org/10.1016/j.fss.2007.08.014.

G.K. Wallace. The jpeg still picture compression standard. ConsumerElectronics, IEEE Transactions on, 38(1):xviii–xxxiv, 1992. ISSN 0098-3063. doi: 10.1109/30.125072.

Theerayod Wiangtong, Peter Y. K. Cheung, and Wayne Luk. Compa-ring three heuristic search methods for functional partitioning inhardware/software codesign. Des Autom Embed Syst, 6(4):425–449,2002. ISSN 0929-5585. doi: 10.1023/A:1016567828852.


http://www.lania.mx/~ccoello/EMOO/vanvel2.ps.gz

http://www.lania.mx/~ccoello/EMOO/vanvel2.ps.gz

http://dblp.uni-trier.de/db/conf/sac/sac99.html

http://dx.doi.org/10.1016/j.fss.2007.08.014

202 bibliografía

Wayne Wolf. A decade of hardware/software codesign. Computer,36(4):38–43, April 2003. ISSN 0018-9162. doi: 10.1109/MC.2003.1193227.

D. H. Wolpert and W. G. Macready. No free lunch theorems for opti-mization. IEEE Transactions on Evolutionary Computation, 1(1):67–82,1996.

MicroBlaze Processor Reference Guide. Xilinx, January 2008.

Lotfi A. Zadeh. Soft computing and fuzzy logic. IEEE-SOFTWARE, 11

(6):48–56, nov 1994. ISSN 0740-7459 (print), 0740-7459 (electronic).

Yiguo Zhang, Wenjian Luo, Zeming Zhang, Bin Li, and Xufa Wang.A hardware/software partitioning algorithm based on artificial im-mune principles. Applied Soft Computing, 23(32):383–391, 2007.

E. Zitzler and L. Thiele. Multiobjective evolutionary algorithms: acomparative case study and the strength pareto approach. Evolu-tionary Computation, IEEE Transactions on, 3(4):257–271, 1999. ISSN1089-778X. doi: 10.1109/4235.797969.

E. Zitzler, L. Thiele, M. Laumanns, C.M. Fonseca, and V.G. da Fonseca.Performance assessment of multiobjective optimizers: an analysisand review. Evolutionary Computation, IEEE Transactions on, 7(2):117–132, 2003. ISSN 1089-778X. doi: 10.1109/TEVC.2003.810758.

Eckart Zitzler, Kalyanmoy Deb, and Lothar Thiele. Compa-rison of multiobjective evolutionary algorithms: Empirical re-sults. Evol. Comput., 8(2):173–195, June 2000. ISSN 1063-6560.doi: 10.1162/106365600568202. URL http://dx.doi.org/10.1162/

106365600568202.

http://dx.doi.org/10.1162/106365600568202

http://dx.doi.org/10.1162/106365600568202

colofón

This document was typeset using the typographical look-and-feelclassicthesis developed by André Miede. The style was inspiredby Robert Bringhurst’s seminal book on typography “The Elements ofTypographic Style”. classicthesis is available for both LATEX and LYX:

http://code.google.com/p/classicthesis/

http://code.google.com/p/classicthesis/

Modelo y estrategias de partición de componentes hardware ...

Documents

Transcript of Modelo y estrategias de partición de componentes hardware ...