Modelo y estrategias de partición de componentes hardware ...
Transcript of 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
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
b.2 Grafos de 100 nodos 154
b.3 Grafos de 150 nodos 155
b.4 Grafos de 200 nodos 156
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.
20 partición hardware/software de sistemas embebidos
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.
22 partición hardware/software de sistemas embebidos
• 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.
2.2 partición hardware/software . estado de la cuestión 23
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
24 partición hardware/software de sistemas embebidos
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
2.2 partición hardware/software . estado de la cuestión 25
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.
26 partición hardware/software de sistemas embebidos
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
2.2 partición hardware/software . estado de la cuestión 27
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 partición hardware/software . estado de la cuestión 29
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
30 partición hardware/software de sistemas embebidos
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
2.2 partición hardware/software . estado de la cuestión 31
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
32 partición hardware/software de sistemas embebidos
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
2.2 partición hardware/software . estado de la cuestión 33
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.
34 partición hardware/software de sistemas embebidos
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.
36 partición hardware/software de sistemas embebidos
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.
2.3 tendencias en la validación de las propuestas 37
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.
38 partición hardware/software de sistemas embebidos
[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.
2.3 tendencias en la validación de las propuestas 39
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-
40 partición hardware/software de sistemas embebidos
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í.
42 partición hardware/software de sistemas embebidos
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)
46 modelo de procesos para la partición hardware/software
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.
3.2 proceso para la partición hardware/software 47
<<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.
48 modelo de procesos para la partición hardware/software
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
3.2 proceso para la partición hardware/software 49
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).
50 modelo de procesos para la partición hardware/software
<<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:
3.2 proceso para la partición hardware/software 51
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.
52 modelo de procesos para la partición hardware/software
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.
3.2 proceso para la partición hardware/software 53
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.
54 modelo de procesos para la partición hardware/software
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
56 modelo de procesos para la partición hardware/software
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;
3.3 instancia del modelo 57
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
58 modelo de procesos para la partición hardware/software
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)
3.3 instancia del modelo 59
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
60 modelo de procesos para la partición hardware/software
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)
3.3 instancia del modelo 61
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)
62 modelo de procesos para la partición hardware/software
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.
3.3 instancia del modelo 63
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.
64 modelo de procesos para la partición hardware/software
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
3.3 instancia del modelo 65
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
66 modelo de procesos para la partición hardware/software
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.
68 modelo de procesos para la partición hardware/software
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
3.4 ejemplo de aplicación de la instancia 69
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)
70 modelo de procesos para la partición hardware/software
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.
72 modelo de procesos para la partición hardware/software
µ(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-
3.4 ejemplo de aplicación de la instancia 73
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.
74 modelo de procesos para la partición hardware/software
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:
76 modelo de procesos para la partición hardware/software
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.
82 experimentos y resultados
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
I4 50 50 Aleatorio 3-2
I5 99 98 out-tree 1-3
I6 103 107 serie-paralelo 3-2
I7 100 50 Aleatorio 3-2
I8 99 50 Aleatorio 3-2
I9 149 148 out-tree 1-3
I10 149 157 serie-paralelo 3-2
I11 149 150 Aleatorio 3-2
I12 150 150 Aleatorio 3-2
I13 199 198 out-tree 1-3
I14 200 219 serie-paralelo 3-2
I15 199 200 Aleatorio 3-2
I16 201 200 Aleatorio 3-2
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
4.1 organización de los experimentos 83
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
84 experimentos y resultados
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.
86 experimentos y resultados
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.
4.1 organización de los experimentos 87
• 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)
88 experimentos y resultados
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
4.1 organización de los experimentos 89
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
90 experimentos y resultados
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)
4.1 organización de los experimentos 91
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
92 experimentos y resultados
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.
4.1 organización de los experimentos 93
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
94 experimentos y resultados
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á.
96 experimentos y resultados
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 %.
4.2 configuración inicial del modelo 97
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).
98 experimentos y resultados
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.
4.2 configuración inicial del modelo 99
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.
100 experimentos y resultados
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
4.2 configuración inicial del modelo 101
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.
102 experimentos y resultados
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.
104 experimentos y resultados
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.
4.2 configuración inicial del modelo 105
Instancias Factores Interacciones
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.
4.2 configuración inicial del modelo 107
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 ).
108 experimentos y resultados
Instancias Factores Interacciones
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.
110 experimentos y resultados
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.
4.2 configuración inicial del modelo 111
Instancias Factores Interacciones
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.
114 experimentos y resultados
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.
4.3 análisis estadístico 115
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.
116 experimentos y resultados
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.
4.3 análisis estadístico 117
Algoritmo Clasificación de Friedman
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.
Friedman unadjusted Holm Finner
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.
118 experimentos y resultados
Algoritmo GA EE EC ECR
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.
4.3 análisis estadístico 119
Algoritmo Clasificación de Friedman
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.
Friedman unadjusted Holm Finner
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.
120 experimentos y resultados
Algoritmo GA EE EC ECR
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.
4.3 análisis estadístico 121
Algoritmo Clasificación de Friedman
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.
Algoritmo GA EE EC ECR
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-
122 experimentos y resultados
Algoritmo Clasificación de Friedman
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.
4.3 análisis estadístico 123
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).
124 experimentos y resultados
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.
4.3 análisis estadístico 125
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.
126 experimentos y resultados
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.
128 experimentos y resultados
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.
130 experimentos y resultados
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.
146 conclusiones y trabajo futuro
• 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.
148 conclusiones y trabajo futuro
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
b.2 grafos de 100 nodos
#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
#serie-paralelo.tgffopt
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
series_must_rejoin 0
B.3 grafos de 150 nodos 155
series_subgraph_fork_out .7
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
series_global_xover 50
tg_write # .tgff
eps_write # .eps
vcg_write # .vcg
b.3 grafos de 150 nodos
#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
#serie-paralelo.tgffopt
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
series_must_rejoin 0
156 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 150 1
task_degree 3 2
gen_series_parallel
series_len 0 0
series_wid 0 0
series_global_xover 150
tg_write # .tgff
eps_write # .eps
vcg_write # .vcg
b.4 grafos de 200 nodos
#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
#serie-paralelo.tgffopt
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
series_must_rejoin 0
B.4 grafos de 200 nodos 157
series_subgraph_fork_out .7
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
series_global_xover 200
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
Exp. αa βa αt βt αm βm αp βp restm restp pob_ini trunc pm pc
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
Exp. αa βa αt βt αm βm αp βp restm restp pob_ini trunc pm pc
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
Exp. αa βa αt βt αm βm αp βp restm restp pob_ini trunc pm pc
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
Exp. αa βa αt βt αm βm αp βp restm restp pob_ini trunc pm pc
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
Exp. αa βa αt βt αm βm αp βp restm restp pob_ini trunc pm pc
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
Exp. αa βa αt βt αm βm αp βp restm restp pob_ini trunc pm
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
Exp. αa βa αt βt αm βm αp βp restm restp pob_ini trunc pm
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
Exp. αa βa αt βt αm βm αp βp restm restp pob_ini trunc pm
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
Exp. αa βa αt βt αm βm αp βp restm restp pob_ini trunc pm
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
Exp. αa βa αt βt αm βm αp βp restm restp pob_ini trunc pm
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
Exp. αa βa αt βt αm βm αp βp restm restp count_it static_restart
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
Exp. αa βa αt βt αm βm αp βp restm restp count_it static_restart
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
Exp. αa βa αt βt αm βm αp βp restm restp count_it static_restart
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
Exp. αa βa αt βt αm βm αp βp restm restp count_it static_restart
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
Exp. αa βa αt βt αm βm αp βp restm restp count_it static_restart
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
Exp. αa βa αt βt αm βm αp βp restm restp
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
Exp. αa βa αt βt αm βm αp βp restm restp
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
Exp. αa βa αt βt αm βm αp βp restm restp
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
Exp. αa βa αt βt αm βm αp βp restm restp
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
Exp. αa βa αt βt αm βm αp βp restm restp
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
3 count_it =1500 static =
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
5 count_it =500 static =
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
7 count_it =1500 static =
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
9 count_it =500 static =
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
11 count_it =1500 static =
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
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-
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.
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.
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
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
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.
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.
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.
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.
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.
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.
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/