HiLeS-PL: Un Framework para la Construcci on de L neas ...

HiLeS-PL: Un Framework para la Construccion deLıneas Especializadas en el Diseno de Sistemas

Embebidos

Claudia Andrea Arcos Mosquera

Universidad de los Andes

Departamento de Ingenierıa de Sistemas y Computacion

Bogota, Colombia

2012

HiLeS-PL: Un Framework para la Construccion deLıneas Especializadas en el Diseno de Sistemas

Embebidos

Claudia Andrea Arcos Mosquera

Tesis presentada como requisito parcial para optar al tıtulo de:

Magister en Ingenierıa de Sistemas y Computacion

Directora:

Rubby Casallas. PhD.

Universidad de los Andes

Departamento de Ingenierıa de Sistemas y Computacion

Bogota, Colombia

2012

iii

Resumen

El diseno y desarrollo de sistemas embebidos es una tarea compleja debido a que los sistemas

actuales involucran varios dominios de ingenierıa. Generalmente, estos disenos se realizan di-

rectamente en lenguajes de descripcion de hardware, que son lenguajes de bajo nivel. Esto

ha hecho crecer el interes por introducir metodologıas de diseno donde se pueda subir el

nivel de abstraccion. HiLeS-PL es un framework construido en la Universidad de los Andes

para apoyar el diseno de sistemas embebidos a un alto nivel de abstraccion basado en una

metodologıa top-down. HiLeS-PL fue desarrollado siguiendo el enfoque Ingenierıa Dirigida

por Modelos (MDE) y de Lıneas de Producto de Software (SPL). Alrededor de este frame-

work se ha desarrollado mas trabajos, con el fin de apoyar otras partes de la metodologıa

pero ninguno de los trabajos desarrollados se encuentran integrados en una sola herramienta.

Esta tesis presenta el desarrollo de un ambiente integrado para el diseno de sistema embebi-

dos apoyado en los trabajos previos. Ademas, se muestra una propuesta para el manejo de

variabilidad a nivel del sistema.

Contenido

Resumen III

1. Introduccion 2

1.1. Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2. Motivacion y Planteamiento del Problema . . . . . . . . . . . . . . . . . . . 3

1.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4. Estructura de la Tesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2. HiLeS: Una Estrategia para el Diseno de Sistemas Embebidos 6

2.1. Diseno a nivel Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1. Modelo de la Estructura y Comportamiento en SysML . . . . . . . . 7

2.2. Diseno a nivel del Procesador . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.1. Formalismo de HiLeS . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3. Diseno a nivel RTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3.1. HDLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4. Validacion y Verificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.5. Trabajos Previos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.5.1. HiLeS Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.5.2. HiLeS-PL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.5.3. Herramientas de Soporte . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.6. Trabajos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3. Lıneas de Producto de Software Dirigidas por Modelos 14

3.1. Ingenierıa Dirigida por Modelos . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1.1. Modelos, Metamodelos y Transformaciones de Modelos . . . . . . . . 15

3.1.2. Acercamiento MDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2. Lıneas de Productos de Software . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2.1. Lıneas de Productos Dirigida por Modelos . . . . . . . . . . . . . . . 16

3.3. Lenguaje para el manejo de Modelos . . . . . . . . . . . . . . . . . . . . . . 17

3.3.1. Transformacion de modelos en Epsilon . . . . . . . . . . . . . . . . . 18

3.3.2. Validacion de Modelos en Epsilon . . . . . . . . . . . . . . . . . . . . 18

3.3.3. Comparacion de Modelos en Epsilon . . . . . . . . . . . . . . . . . . 18

3.3.4. Composicion de Modelos en Epsilon . . . . . . . . . . . . . . . . . . . 19

Contenido v

3.3.5. Generacion de Codigo en Epsilon . . . . . . . . . . . . . . . . . . . . 19

4. La Cadena de Transformacion de HileS 20

4.1. Sistema de Produccion de Cana de Azucar . . . . . . . . . . . . . . . . . . . 21

4.1.1. Requerimientos para el Controlador de Nivel . . . . . . . . . . . . . . 22

4.1.2. Modelo a Nivel del Sistema . . . . . . . . . . . . . . . . . . . . . . . 22

4.2. Metamodelos de los Dominios de HiLeS . . . . . . . . . . . . . . . . . . . . . 24

4.2.1. Dominio del Formalismo de HiLeS . . . . . . . . . . . . . . . . . . . . 24

4.2.2. Dominio HDLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2.3. Dominio Red de Petri . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.3. Transformaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.3.1. Transformacion SysML::HiLeS . . . . . . . . . . . . . . . . . . . . . . 30

4.3.2. Transformacion HiLeS::HDL . . . . . . . . . . . . . . . . . . . . . . . 36

4.3.3. Transformacion HDL::Code . . . . . . . . . . . . . . . . . . . . . . . 42

4.3.4. Transformacion HiLeS::PetriNet::Code . . . . . . . . . . . . . . . . . 42

5. Variabilidad y Configuracion del Producto en HiLeS 45

5.1. Definicion Formal de los Modelos de Variabilidad . . . . . . . . . . . . . . . 45

5.1.1. Los Modelos de Features y Restricciones . . . . . . . . . . . . . . . . 45

5.1.2. El Modelo de Decision . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.1.3. El Modelo de Configuracion . . . . . . . . . . . . . . . . . . . . . . . 51

5.2. SHRMS: Sistema para el Monitoreo de Salud Estructural . . . . . . . . . . . 52

5.2.1. Requerimientos para el sistema SHRMS . . . . . . . . . . . . . . . . 52

5.2.2. Modelo a Nivel del Sistema . . . . . . . . . . . . . . . . . . . . . . . 53

5.2.3. Rasgos Variables del Sistema y el Modelo de Features . . . . . . . . . 54

5.3. Extension del Perfil de SysML para el manejo de Variabilidad . . . . . . . . 54

5.3.1. Perfil de Variabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.3.2. Metamodelo Extendido de SysML . . . . . . . . . . . . . . . . . . . . 56

5.4. Derivacion del Producto Especıfico . . . . . . . . . . . . . . . . . . . . . . . 57

5.4.1. Fase de Comparacion . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.4.2. Fase Merge/Transformacion . . . . . . . . . . . . . . . . . . . . . . . 58

5.4.3. Modelo Decision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.5. Activos para el manejo de Variabilidad en HiLeS . . . . . . . . . . . . . . . . 60

5.5.1. Metamodelos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.5.2. Transformaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

6. RCP para el Diseno de Sistemas Embebidos desde la Metodologıa de HiLeS 64

6.1. HiLeS Workbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6.1.1. Arquitectura de Alto Nivel . . . . . . . . . . . . . . . . . . . . . . . . 65

6.2. HiLeS-PL Workbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6.2.1. Arquitectura de Alto Nivel . . . . . . . . . . . . . . . . . . . . . . . . 67

vi Contenido

6.3. Construccion de una Lınea Especializada para Sistemas SHRMS . . . . . . . 68

6.3.1. Creacion de la Lınea especializada . . . . . . . . . . . . . . . . . . . . 68

6.3.2. Derivacion de un Producto Especıfico . . . . . . . . . . . . . . . . . . 71

7. Conclusiones 73

7.1. Resultados y Aportes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

7.2. Ventajas y Limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

7.3. Trabajo Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Bibliografıa 76

Lista de Tablas

2-1. Perfiles UML para el modelamiento de sistemas y verificacion. . . . . . . . . 12

2-2. Iniciativas para el diseno de sistemas embebidos . . . . . . . . . . . . . . . . 13

4-1. Equivalencias entre los conceptos de SysML que modelan comportamiento y

el metamodelo de HiLeS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4-3. Equivalencias entre los elementos SysML y HiLeS para el comportamiento . 32

4-3. (continua). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4-3. (continua). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4-2. Equivalencias entre los conceptos del perfil SysML y el metamodelo de HiLeS 35

4-4. Equivalencias entre los elementos HiLeS y VHDL-AMS . . . . . . . . . . . . 37

4-4. (continua). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4-4. (continua). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4-5. Equivalencias entre los elementos HiLeS y Verilog-AMS . . . . . . . . . . . . 39

4-5. (continua). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4-5. (continua). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Lista de Figuras

2-1. Metodologıa para el diseno de Sistemas Embebidos en HiLeS . . . . . . . . . 7

4-1. Cadena de transformacion base en el Framework de HiLeS . . . . . . . . . . 20

4-2. Sistema de produccion de cana de azucar . . . . . . . . . . . . . . . . . . . . 21

4-3. Diagrama de definicion de bloques para el controlador de nivel. . . . . . . . . 23

4-4. Diagrama de actividad para el bloque TankLevelControl del controlador de

nivel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4-5. Diagrama de actividad para el bloque Action del controlador de nivel. . . . . 24

4-6. Metamodelo HiLeS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4-7. Descripcion de la estructura del componente TankLevelControl en HiLeS. . . 26

4-8. Parte de la secuencia de ejecucion del componente DisplayController en HiLeS 26

4-9. Metamodelo VHDL-AMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4-10.Metamodelo Verilog-AMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4-11.Metamodelo de la Red de Petri. . . . . . . . . . . . . . . . . . . . . . . . . . 30

4-12.Regla de transformacion SysML::Connector To HiLeS::Payload aplicada a los

conectores entre puertos en SysML. . . . . . . . . . . . . . . . . . . . . . . . 32

4-13.Regla de transformacion SysML::CallOperationActivity To HiLeS::Block!Functional,

To HiLeS::PetriNet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4-14.Modelo de HiLeS obtenido de la composicion de las modelos generados en las

transformaciones de estructura y comportamiento. . . . . . . . . . . . . . . 36

4-15.Modelos en VHDL-AMS y Verilog-AMS del componente Action . . . . . . . 41

4-16.Fraccion del codigo del prototipo virtual del componente Action . . . . . . . 42

4-17.Fraccion de codigo con ejemplo de instancias para el componente Action . . 43

4-18.Modelo de la red de petri generada a partir del modelo de HiLeS. . . . . . . 44

5-1. Modelo de Restricciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5-2. Modelo de Configuracion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5-3. Modelo de Features del componente Acceleration del sistema SHRMS. . . . . 53

5-4. Modelo de Features del componente Acceleration del sistema SHRMS. . . . . 54

5-5. Perfil de variabilidad para el sistema SHRMS. . . . . . . . . . . . . . . . . . 56

5-6. Perfil de variabilidad para el sistema SHRMS. . . . . . . . . . . . . . . . . . 56

5-7. Estrategia para la derivacion de productos especıficos. . . . . . . . . . . . . . 57

5-8. Regla ECL para el metaconcepto AccelerationCapture. . . . . . . . . . . . . 58

Lista de Figuras 1

5-9. Regla EML AccelerationCaptureToFunctional del metaconcepto Acceleration-

Capture y regla ETL CallOperationActionToFunctional del metaconcepto Ca-

llOperationAction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5-10.Modelo de Restricciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5-11.Representacion grafica del modelo de decision del sistema SHRMS . . . . . . 61

5-12.Metamodelo extendido para la lınea especializada de sistemas SHRMS. . . . 61

5-13.Metamodelo de decision ajustado . . . . . . . . . . . . . . . . . . . . . . . . 62

5-14.Regla ECL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5-15.Regla EML que define la ejecucion de las transformaciones para la lınea del

sistema SHRMS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

6-1. Arquitectura de alto nivel del ambiente de desarrollo de HiLeS Workbench. . 65

6-2. Arquitectura de alto nivel del ambiente de desarrollo de HiLeS-PL Workbench. 67

6-3. Creacion de un proyecto de HiLeS desde el IDE HiLeS Workbench. . . . . . 68

6-4. Generacion del modelo de HiLeS desde el IDE HiLeS Workbench. . . . . . . 69



6-7. Creacion de un perfil UML desde el IDE HiLeS Workbench. . . . . . . . . . 70

6-8. Modelos de variabilidad desde el IDE HiLeS Workbench. . . . . . . . . . . . 71

6-9. Modelos de variabilidad desde el IDE HiLeS Workbench. . . . . . . . . . . . 72

1 Introduccion

1.1. Contexto

Los sistemas embebidos son sistemas de hardware y software o unicamente de hardware que

pueden involucrar componentes de diferentes dominios de ingenierıa, como el electronico,

mecanico, matematico, entre otros. Debido a este multidominio el diseno de los sistemas

embebidos se hace mas complejo, ocasionando que los tiempos de entrega, el desarrollo de

funcionalidades no deseadas y los costos de diseno se incrementen. El uso de prototipo vir-

tuales (PV) ayuda a prevenir este tipo de inconvenientes, ya que es una estrategia de diseno

que permite validar el comportamiento ofrecido por los componentes del sistema antes de

construir fısicamente el producto, [1]. Tanto los prototipos virtuales (PVs) como el diseno de

los componentes del sistema para una implementacion real, son modelados con lenguajes de

descripcion de Hardware (HDLs) a partir de los cuales se describe su comportamiento. Estos

lenguajes son lenguajes de bajo nivel, lo cual los hace poco flexibles y propenso a errores.

Una solucion a las problematicas anteriores es subir el nivel de abstraccion en el diseno de

sistemas embebidos. HiLeS es una propuesta que nace para apoyar el diseno de estos siste-

mas, a partir de un formalismo basado en redes de petri y una metodologıa de diseno. El

formalismo denominado Formalismo de HiLeS, [2], es un lenguaje a traves del cual se descri-

be la arquitectura del sistema y la secuencia de ejecucion de sus componentes a un nivel de

abstraccion mas alto que el nivel de los HDLs, [3]. La metodologıa desarrollada fue basada

en el estandar EIA-632 y en el uso del perfil de SysML para el modelamiento del sistema,

[4]. Adicionalmente, esta propuesta fue apoyada con el desarrollo de una herramienta para

construir el diseno desde el formalismo de HiLeS y generar los componentes del sistema en

el lenguaje de VHDL-AMS. Esta primera propuesta y la herramienta desarrollada poseıan

tres limitantes. La primera, era que la solucion era bastante acoplada lo cual no permitıa

enriquecer y extender la solucion propuesta. La segunda, estaba relacionada con el nivel de

automatizacion durante el proceso de diseno, ya que el disenador debıa construir a mano el

diseno del sistema en HiLeS a partir del modelo creado en el perfil de SysML. Por ultimo, el

disenador tenıa que ser experto en el formalismo de HiLeS. A partir de estas limitantes se

crea HiLeS-PL 1.

1Proyecto que se desarrolla en manera conjunta con los grupos de investigacion de Construccion de Software

(Departamento de Sistemas) y GIAP (Departamento de Electronica)

1.2 Motivacion y Planteamiento del Problema 3

HiLeS-PL es un framework desarrollado siguiendo los enfoques de la Ingenierıa Dirigida por

Modelos (MDE) y de las Lıneas de Producto de Software Dirigidas por Modelos (MD-SPL).

A partir de los conceptos de modelos y transformaciones de modelos del enfoque MDE, [3], el

framework puede generar los prototipos virtuales del sistema. Esta generacion se basa en una

secuencia de transformaciones de modelos que inicia con el modelo del sistema en SysML. El

modelo del sistema es transformado a un modelo basado en el formalismo de HiLeS. Con el

modelo de HiLeS se genera el modelo del lenguaje VHDL-AMS, a partir del cual se obtiene

el codigo de los prototipos virtuales. Por otro lado, los conceptos del enfoque MD-SPL como

la reutilizacion de componentes y la derivacion de productos especıficos a partir de activos

comunes y variables de la lınea, son utilizados por HiLeS-PL para el manejo de variabilidad

de los componentes que hacen parte del sistema y la derivacion de familia de productos.

Este manejo se realiza desde el dominio de HiLeS y a partir de la estrategia desarrollada en

[5]. Esta estrategia plantea el usos de los modelos de features, restricciones, configuracion y

decision para el manejo de variabilidad.

Posterior al desarrollo realizado en HiLeS-PL, se ha realizado otros proyectos en los cuales se

ha buscado mejorar o extender las funcionalidades de este framework, como los proyectos de

TUCAN [6], para el analisis de requerimientos de tiempo, y el proyecto de IPSEARCH [7],

para la busqueda, analisis e incorporacion de propiedad intelectual (IPs) durante el proceso

de derivacion de productos.

1.2. Motivacion y Planteamiento del Problema

El framework de HiLeS-PL posee algunas desventajas. La primera, es que la solucion pro-

puesta para el manejo de variabilidad y la generacion de codigo a VHDL-AMS se realiza a

partir de workflows definidos con openArchitectureWare [8] los cuales no se encuentran ac-

tualizados con las versiones actuales y son ejecutados desde las herramientas brindadas por

el mismo ambiente de desarrollo. La segunda, esta relacionada con el manejo de variabilidad

la cual se realiza en el dominio de HiLeS y no a nivel del sistema, donde se inicia el diseno

y el usuario puede identificar los rasgos variables de los componentes que hacen parte del

sistema. La tercera, se relaciona con los proyectos posteriores a HiLeS-PL en los cuales se ha

buscado mejorar o extender las funcionalidades de este framework. Estos proyectos han sido

implementados como proyectos independientes y en tecnologıas diferentes lo cual dificulta su

integracion. Finalmente, se hace uso de herramientas externas para la validacion del diseno,

como TINA, las cuales son ejecutadas por los usuarios por fuera del framework durante la

secuencia de transformacion de HiLeS-PL.

De acuerdo a lo anterior, estas serıan las problematicas identificadas:

4 1 Introduccion

P1. Los componentes, estrategias y herramientas desarrolladas se encuentran en dife-

rentes tecnologıas y desacopladas entre si.

P2. El manejo de la variabilidad no se da en el dominio de SysML, dominio en el cual

el usuario inicia el diseno y modela el prototipo virtual del sistema.

P3. La ejecucion y generacion de la lınea se realiza directamente desde el IDE de

Eclipse, siendo esto poco amigable al usuario.

1.3. Objetivos

O1. Proveer una aplicacion integrada para la generacion de una Lınea de prototipos

virtuales en HiLeS basado en MD-SPL

Con este objetivo se busca brindar un espacio de trabajo integrado y de facil uso para apoyar

la creacion de lıneas especializadas en el de diseno de sistemas embebidos. Este espacio de

trabajo debe ser construido a partir de los resultados generados en los proyectos previos y

estar acorde a la metodologıa propuesta para el diseno en HiLeS.

La aplicacion debe proveer como mınimo lo siguientes requerimientos:

Ejecucion de la cadena de transformacion base en la lınea de sistemas embebidos.

Manejo de variabilidad para la derivacion de un producto especıfico.

O2. Proveer una solucion para el manejo de variabilidad desde el dominio de SysML

Otro de los objetivos principales durante el desarrollo de esta tesis es brindar una solucion

para el manejo de variabilidad desde SysML. Esta solucion debe estar apoyada por la es-

trategia e implementacion desarrollada en FieSta, [5], para el manejo de variabilidad por

modelos, y por la metodologıa desarrollada en HiLeS-PL para el diseno de sistema embebidos.

Esto debe incluir la reutilizacion, actualizacion y ajustes de las herramientas desarrolladas

en estos proyectos.

O3. Estabilizar las implementaciones que actualmente existen en torno al proyecto de

HiLeS.

De acuerdo a los objetivos anteriores y teniendo en cuenta la problematica en las diferencias

tecnologicas entre los trabajos desarrollados, se hace necesario revisar y estabilizar las im-

plementaciones existentes con el fin de centralizar las herramientas en una sola aplicacion.

1.4 Estructura de la Tesis 5

Con este objetivo se busca verificar los activos necesarios para la generacion de la cadena

de transformacion basica y para el manejo de variabilidad. En la cadena de transformacion

basica se busca reevaluar los modelos y las transformaciones planteadas en cada uno de

los dominios dentro de la metodologıa de HiLeS y extender la cadena de transformacion

para generar el modelo del sistema en VHDL-AMS. Para el manejo de variabilidad se busca

integrar los activos que se desarrollen o se ajusten de acuerdo a O2.

1.4. Estructura de la Tesis

Este documento se ha articulado en 7 capıtulos y una seccion bibliografica. A continuacion

se presenta la organizacion de los capıtulos de este documento:

Capitulo 1. Introduccion: Se hace una contextualizacion acerca de los temas estudia-

dos durante el desarrollo de la tesis, se plantea la problematica y se define los objetivos.

Capitulo 2. HiLeS: Se habla acerca de la metodologıa de HiLeS para el diseno de

sistemas embebidos y de los proyectos desarrollados.

Capitulo 3. MD-SPL: Se introduce los conceptos basicos de los acercamientos de la

Ingenierıa Dirigida por Modelos y de Lıneas de Producto.

Capitulo 4. La Cadena de Transformacion de HileS: Se presenta la metodologıa segui-

da en la cadena de transformacion de HiLeS y los activos construidos para su ejecucion.

Capitulo 5. Variabilidad y Configuracion del Producto en HiLeS: Se presenta una

definicion formal de la estrategia de FieSta y la propuesta para el manejo de variabilidad

en HiLeS a nivel del sistema, que incluye los activos desarrollados.

Capitulo 6. RCP para el Diseno de Sistemas Embebidos desde la metodologıa de

HiLeS: Se muestra los componentes desarrollados y los ambiente de HiLeS construido

para el desarrollo de Lıneas Especializadas en el Diseno de Sistemas Embebidos.

Capitulo 7. Conclusion y Trabajo Futuro: El ultimo capıtulo de este documento se

aborda los aportes realizados por la tesis y se propone trabajos futuros.

2 HiLeS: Una Estrategia para el Diseno

de Sistemas Embebidos

Un sistema embebido es un dispositivo electronico disenado para computar una funcionali-

dad determinada en otro sistema en el que se embebe. Estos sistemas pueden ser sistemas de

hardware y software o unicamente de hardware, como los sistemas on chip (SoC). El diseno

de estos sistemas puede ser construido en diferentes niveles de abstraccion y estar acom-

panados por metodologıas de diseno, [9]. Los niveles de abstraccion abarcan disenos que van

desde nivel del circuito hasta el nivel del sistema, y estos pueden ser abordados desde los

aspectos de comportamiento, estructura y fısico, [9].

HiLeS es una estrategia para el diseno de sistemas embebidos a un alto nivel basada en el

formalismo de HiLeS, [10]. El diseno alto nivel es soportado por el estandar EIA-632, que

define los procesos para crear los sistemas embebidos, y el uso del perfil de SysML, para el

modelamiento del sistema, [4]. El formalismo de HiLeS es una especificacion basada en redes

de petri a traves de la cual se define el comportamiento y estructura de los componentes

del sistema. A partir de la especificacion del diseno en HiLeS se construyen los prototipos

de los componentes en un lenguaje de descripcion de hardware, como VHDL-AMS. La es-

pecificacion del diseno en HiLeS y los prototipos virtuales puede ser validados y verificados

en herramientas externas, con el proposito de validar si cumplen con los requerimientos de

diseno. El uso de HiLeS se limita solo al diseno de sistemas embebidos de Hardware, en

concreto sistemas on Chip.

De acuerdo a lo anterior, la metodologıa de diseno en HiLeS es basada en una metodologıa

Top-Down. Esta metodologıa puede ser clasificada en cada uno de los niveles de abstrac-

cion y aspectos de diseno mencionados al inicio del capitulo. Por ejemplo, la construccion del

modelo en SysML puede ser ubicado en el nivel de abstraccion del Sistema. La Figura 2-1

muestra la clasificacion y la metodologıa seguida en HiLeS, basada en la grafica de Diseno

en ”Y” de Gajski, [9].

El uso de metodologıas de alto nivel de abstraccion en el diseno de sistemas embebidos,

aumenta la brecha de productividad en la construccion del producto esperado. Esta brecha

aumenta mas si los sistemas a disenar son mas complejos. Para reducir la brecha, Gaski

sugiere la automatizacion de tareas dentro de la metodologıa de diseno.

2.1 Diseno a nivel Sistema 7

Figura 2-1: Metodologıa para el diseno de Sistemas Embebidos en HiLeS

En torno a HiLeS se han desarrollado proyectos previos con el fin de construir herramientas

de apoyo y soporte en el proceso de diseno de los sistemas embebidos. Estas herramientas

lograron automatizar varias partes del proceso y apoyar las tareas de verificacion y validacion

de los disenos construidos.

El objetivo de este capitulo es explicar la metodologıa seguida en HiLeS para el diseno

de sistemas embebidos y contextualizar un poco los aspectos involucrados en la estrategia.

Adicionalmente, hablar acerca de los proyectos previos, construidos a partir de otros trabajos

de tesis o trabajos de investigacion desarrollados dentro del grupo de HiLeS.

2.1. Diseno a nivel Sistema

La metodologıa inicia con la descripcion del sistema. Segun este nivel es necesario el uso de

lenguajes de alto nivel que permitan construir los modelos. El perfil de SysML es el lenguaje

que brinda los elementos necesarios para el diseno de sistemas embebidos a un alto nivel de

abstraccion.

2.1.1. Modelo de la Estructura y Comportamiento en SysML

De acuerdo a la Figura 2-1, el diseno se inicia con la descripcion de la estructura del sistema.

Esta descripcion se construye identificando los componentes en los que el sistema puede ser

dividido, su jerarquıa y las conexiones entre estos y del sistema con el ambiente.

8 2 HiLeS: Una Estrategia para el Diseno de Sistemas Embebidos

El diagrama de definicion de bloques (bdd) permiten modelar los componentes iden-

tificados y establecer su jerarquıa. Cada componente se representa a traves de un Bloque

(Block) en SysML y la jerarquıa se establece con las relaciones de composicion de SysML.

El modelo estructural del sistema se debe completar con la informacion de las conexiones

entre los componentes y del sistema con el ambiente. Para esto se hace uso del diagrama

interno de bloques (ibd), en el cual se define los puertos y conexiones requeridas. Los ele-

mentos Port y Flow Port, son utilizados para representar los puertos de los componentes. El

elemento Connector es utilizado para representar las conexiones. Los diagramas ibd se define

por cada uno de los componentes del sistema que tenga asociaciones, es decir, componentes

con bloques hijos.

Una vez modelada la estructura del sistema se continua con la descripcion de su compor-

tamiento. La descripcion del comportamiento consiste en definir la dinamica de cada uno

de los componentes modelados en el bdd. Esta dinamica se representa con una actividad de

SysML y los detalles del comportamiento se describe en un diagrama de actividad.

Para la estrategia de HiLeS el control de la dinamica se limita solo al uso de los elementos

Control Flow del diagrama de actividad, mientras los elementos Object Flow representan las

conexiones entre los componentes . Para expresar la funcionalidad especıfica de un bloque se

usa las acciones Call Operation Action. Estas acciones pueden ser usadas para ejecutar una

operacion o funcionalidad. Para la estrategia de HiLeS estos elementos representan un com-

portamiento especıfico que pueden ser descrito en un HDL, usualmente en la forma de una IP.

2.2. Diseno a nivel del Procesador

Una vez construido el modelo del sistema en SysML se debe construir el modelo del proce-

sador, ver Figura 2-1. Este modelo se construye de acuerdo al formalismo de HiLeS, a partir

del cual se define la arquitectura del sistema y la secuencia de ejecucion de sus componentes.

2.2.1. Formalismo de HiLeS

HiLeS es un formalismo basado en redes de Petri, por medio del cual un disenador puede

describir la arquitectura de un sistema y la secuencia de ejecucion de los bloques que lo

componen [2]. Los elementos que hacen parte de este formalismo son los que se describen a

continuacion.

1. Bloques Estructurales: Los bloques estructurales permiten modelar la estructura y

jerarquıa de un sistema. Estos bloques pueden contener otros bloques estructurales,

2.3 Diseno a nivel RTL 9

bloques funcionales o redes de control. Pueden comunicarse con otros bloques por

medio de canales de informacion y puertos ,[2].

2. Bloques Funcionales: Permite la descripcion del comportamiento del sistema. Estos

bloques no tienen propiedades jerarquicas.

3. Red de Control: Es un modelo basado en redes de Petri ordinarias, que representa el

control en la ejecucion de los bloques del sistema.

4. Canales: Permiten modelar la comunicacion entre los bloques y la red de control. Los

canales transportan dos tipos de senales: senales continuas y de eventos discretos. Para

los arcos de la red de Petri se define un tipo de canal discreto especial [2], que indica

como el token fluye en la red de control.

5. Servicios y Puertos: Son los puntos de entrada o salida del ambiente y de una caja

negra sobre el ambiente, respectivamente [6]. Contienen tipos y naturaleza de acuerdo

a la sintaxis de VHDL-AMS [6].

2.3. Diseno a nivel RTL

Teniendo el modelo procesador se pasa al siguiente nivel de abstraccion para obtener el

modelo RTL del sistema. Este modelo se encuentra relacionado con la construccion de los

componentes del sistema a un nivel logico y/o a un nivel del circuito. El nivel RTL es el

nivel de mas baja abstraccion, en este nivel se construye los prototipos virtuales de los com-

ponentes en un lenguaje especıfico, como los lenguajes de descripcion de hardware (HDL).

2.3.1. HDLs

Los lenguajes de descripcion de Hardware son usados para modelar el comportamiento de

los componentes de hardware de un sistema. Estos lenguajes son utilizados principalmente

para simular o sintetizar los modelos resultantes del sistema. El objetivo de la simulacion es

validar el comportamiento del diseno antes de llevarlo a una implementacion real, mientras

el objetivo de la sıntesis es llevar el diseno de hardware a la implementacion [11, 12] .

Los HDLs mas usados para modelar sistemas embebidos son: VHDL, Verilog y SystemC.

Estos lenguajes han sido extendidos para soportar el diseno de sistemas de senal mixta

(AMS) [13]. Los lenguajes de senal mixta son los lenguajes de interes dentro de la estrategia

de HiLeS.


2.4. Validacion y Verificacion

Durante el desarrollo de la metodologıa se puede hacer uso de herramientas externas para

validaciones del diseno construido. Esto ocurre a nivel del modelo del procesador y a nivel

del modelo RTL.

A nivel del procesador se puede obtener la red de Petri (PN) del sistema a partir de la infor-

macion de la red de control de HiLes. La redes de Petri permite validar el diseno del sistema.

Esta validacion se realiza con el uso de herramientas de verificacion como TINA, [14]. En

esta herramientas se verifican propiedades de la red de petri como vivacidad o acotamiento.

Esta propiedades definen el comportamiento que va a tener la PN del sistema.

A nivel del modelo RTL, los componentes del sistema creados en un HDL especıfico pueden

ser validados en una herramienta de simulacion externa, como SystemVisio o Questa ADMS,

[11]. Los resultados de las simulaciones permite verificar si el comportamiento descrito en el

HDL cumple con las especificaciones del diseno.

2.5. Trabajos Previos

A continuacion se presentara los trabajos desarrollados en el proyecto de HiLeS.

2.5.1. HiLeS Designer

HiLeS Designer, [15], fue la primera aplicacion desarrollada para apoyar el proceso de diseno

de los sistemas embebidos desde el formalismo de HiLeS. Esta herramienta ofrece un editor

grafico el cual permite modelar el sistemas embebidos con los elementos del formalismo de

HiLeS. A partir de esta aplicacion se genera el codigo VHDL-AMS parcial del sistema y un

codigo de la red de petri, el cual es usado en TINA (TIme petri Net Analyzer) [14]. Esto

permite la simulacion de los prototipos virtuales del sistema y la validacion del comporta-

miento del sistema [16]. La aplicacion fue construida en VisualBasic.

2.5.2. HiLeS-PL

Framework inicial para la construccion de lıneas especializadas en el diseno de sistemas

embebidos basado en el enfoque MD-SPL, a partir del cual se generaba los prototipo vir-

tuales (PV) del sistema embebido, [16]. El framework emplea una metodologıa soportada

en el estandar EIA-632 y en la semantica del perfil SysML para el modelamiento del siste-

ma. El prototipo virtual de los componentes del sistema se obtienen en el lenguaje de VHDL.

2.6 Trabajos Relacionados 11

En este framework el modelamiento del comportamiento se realizaba a partir de los diagramas

de secuencia de SysML. La implementacion fue realizada en openArchitectureware [8].

2.5.3. Herramientas de Soporte

Otros proyectos realizados fueron los proyectos de TUCAN [6] e IPSEARCH [7]. TUCAN es

una herramienta de analisis de requerimientos de tiempo en diseno de sistemas embebidos.

La herramienta se basa en adicionar anotaciones de tiempo en el modelo del comportamien-

to del sistema. IPS SEARCH es una herramienta de soporte para la busqueda, analisis e

incorporacion de propiedad intelectual (IPs) durante el proceso de derivacion de productos

en el framework HiLeS-PL. Propuesta basada en ontologıas y en estandares para IPs.

2.6. Trabajos Relacionados

El objetivo de esta seccion es presentar los trabajos relacionados con el diseno de sistemas

embebidos. Esto puede ser abordado desde dos puntos de vista. El primero, esta relacio-

nado con los perfiles UML usados como lenguajes de alto nivel para el modelamiento de

estos sistemas. El segundo punto de vista involucra otras estrategias o iniciativas, las cuales

proveen ambientes o frameworks que soportan metodologıas de diseno en sistemas embebidos.

La mayorıa de los perfiles UML creados para modelar sistemas embebidos, aplican para

sistemas de tiempo real (RTS). Estos perfiles ofrecen elementos mas especializados lo cual

puede limitar su uso para describir el comportamiento y estructura de otros tipos de sistema.

Para el caso de la estrategia de HiLeS, el perfil SysML es el perfil usado para el modelo a

nivel del sistema. Este perfil es usado para modelar sistemas en general que extiende el perfil

UML para incluir elementos que permitan describir los componentes del sistema, definir los

flujos entre los bloques, definir los requerimientos del sistema y crear relaciones entre reque-

rimientos y componentes, entre otros. Por otro lado, algunos de los perfiles son apoyados por

herramientas que proveen verificacion del sistema. En nuestra estrategia, esto es soportado

a nivel del procesador con el modelo de la red de petri del sistema que es obtenida desde el

diseno en el formalismo de HiLeS. Algunos de los perfiles mas relevantes y sus caracterısticas

principales se resumen el la Tabla 2-1, [6].

Respecto a las iniciativas, el framework de GASPARD es una iniciativa construida siguiendo

el enfoque de la Ingenierıa Dirigida por Modelos (MDE). Este framework se enfoca en un

tipo especifico de diseno de sistemas embebidos, [6], a partir del cual se provee un formalismo

para la descripcion del sistema a un alto nivel de abstraccion, una metodologıa durante el

proceso de diseno y un conjunto de herramientas que soportan el diseno del sistema [17].

GASPARD hace uso del perfil de MARTE para modelar el sistema y de cuatro secuencias

de transformaciones (cadenas de transformacion), a partir de las cuales lleva el modelo de


Tabla 2-1: Perfiles UML para el modelamiento de sistemas y verificacion.

Perfil Tipo Sistema Descripcion

UML-RTRTS dirigido por even-

tos

Capacidades limitadas para modelar arquitectu-

ra y comportamiento, el comportamiento se de-

fine solo a traves diagramas de estado.

TURTLESistemas crıticos dis-

tribuidos

Valida el diseno de sistemas en tiempo real a

traves de analisis formal con RT-Lotos.

OMEGA RTS

Define una metodologıa y usa tecnicas formales

para la verificacion de los modelos en diferentes

fases de diseno.

MARTE RTS

Adicional a la semantica para el diseno de siste-

ma, provee conceptos para expresar restricciones,

schedulability y desempeno.

SysML Sistemas en generalLenguaje de proposito general, lo que le permite

que sea usado en varios dominios de ingenierıa.

alto nivel a modelos de mas bajo nivel de acuerdo a diferentes propositos: simulacion en

System C, sıntesis de hardware en VHDL, validacion formal a traves de lenguajes sıncronos

y computacion de alto desempeno con OpenMP que guıa a la generacion de codigo C y en

OpenMP Fortran, [6]. Esta framework comparado con el nuestro se diferencia principalmen-

te en las cadenas de transformacion disponibles y particularmente como derivan a VHDL

directamente desde el modelo del sistema. Por otro lado, ambos frameworks hacen uso de

lenguajes de alto nivel de abstraccion para la descripcion del sistema y generan modelos para

simulacion del comportamiento del sistema.

Otras iniciativas que proveen ambientes para el diseno de sistemas embebidos son Complex

[18] y DERAF [19]. Complex se enfoca sobre decisiones acerca de los componentes de hardwa-

re y software que seran implementados, donde la validacion del sistema consiste en explorar

el espacio de diseno del sistema y encontrar la implementacion que este mas acorde a los

requerimientos [6]. Esta exploracion es realizada comparando los resultados de las simulacio-

nes de los prototipos virtuales (PVs) generados desde un modelo de alto nivel. Los PVs son

generados en SystemC a partir de un modelo del sistema descrito con el perfil de MARTE.

Por otro lado, DERAF es un framework que se enfoca en los requerimientos no funcionales

de sistemas embebidos distribuidos de tiempo real. Su estrategia consiste en introducir estos

requerimiento a nivel del diseno del sistema para que sean tomados en cuenta. Esto lo realiza

por medio de una metodologıa de diseno orientada en aspectos y el uso del perfil RT-UML,

[6]. La diferencia principal de estos frameworks con nuestro acercamiento esta en la forma

en que estos definen la metodologıa de diseno y como ellos soportan desarrollo de HW/SW.

La Tabla 2-2 se muestra las caracterısticas principales de las iniciativas descritas en los

2.6 Trabajos Relacionados 13

parrafos anteriores comparadas con las ofrecidas en nuestra propuesta.

Tabla 2-2: Iniciativas para el diseno de sistemas embebidos

Iniciativa Lenguaje

Mode-

lamien-

to

Metodologıa Verificacion

del sistema

Validacion

del sistema

Sıntesis en

HDL

GASPARD* MARTE Si Si No Si (Codigo

HDL generado

a nivel del

sistema)

Complex MARTE Si No Si (Simulacion

PVs)

No

DERAF UML-

RT

Si Aspectos de

tiempo

No No

HiLeS-

PL*

SysML Si (Basada en

EIA-632)

Si (Nivel del

procesador -

Redes de petri)

Si (Nivel RTL

- componentes

en HDL)

Si (Codigo

HDL generado

a nivel del

procesador)

* Frameworks basados completamente en el enfoque MDE.

3 Lıneas de Producto de Software

Dirigidas por Modelos

Como se menciono en el Capitulo 2, la brecha de productividad en la metodologıa top-down

para el diseno de sistemas embebidos es reducida si en el proceso de diseno se introduce la

automatizacion. Un mecanismo de automatizacion es el uso de los conceptos de la Ingenierıa

Dirigida por Modelos (MDE) dentro del proceso de diseno. MDE propone el uso de modelos

durante las etapas de desarrollo de sistemas, para incrementar la productividad y calidad

de los productos obtenidos. Este paradigma fue usado en la mayorıa de las propuestas y

herramientas implementadas en los proyectos anteriores.

La automatizacion no es suficiente dentro de la metodologıa de diseno. En ocasiones, se re-

quiere construir una familia de productos, a partir de un diseno base que pueda ser ajustado.

En el desarrollo de software, esto se trabaja con las Lıneas de Producto de Software (SPL).

Una SPL se basa en la derivacion de productos de software a partir de la reutilizacion de los

activos de la lınea. El desarrollo de una SPL puede involucrar el uso de modelos dentro de

sus activos y la transformacion de modelos durante el proceso de derivacion. se le denomina

Desarrollo de Lıneas de Producto de Software basadas en Modelos (MD-SPL).

El objetivo de HiLeS es el diseno de sistemas embebidos a un alto nivel con el uso de modelos

a partir del cual se desarrolla los componentes del sistema en un lenguaje de descripcion

de hardware, Capitulo 2. De acuerdo a esto, los enfoques de MDE y MD-SPL pueden ser

aplicados en la metodologıa de la siguiente manera:

Construccion del sistema base. Uso de modelos en cada nivel de abstraccion para

automatizar el proceso de diseno con la aplicacion de transformaciones de modelos

(Sistema a Procesador a RTL). El framework de HiLeS, [16], fue la primera version de

automatizacion de los procesos en la metodologıa de HiLeS.

Construccion de una lınea de productos. Derivacion productos especıficos a partir

de los activos base de la lınea de productos, el manejo de variabilidad a nivel del sistema

y reutilizacion de componentes de hardware ya construidos (IPs). Herramientas de

apoyo como IPSearch, [7], para la busqueda de IPs en la configuracion de un producto

especıfico.

3.1 Ingenierıa Dirigida por Modelos 15

Verificacion y validacion del diseno. Generacion de un modelo intermedio para la

verificacion en TINA y la generacion de codigo de los componentes para validaciones

en herramientas de simulacion aplicando la estrategia del proyecto de TUCAN, [6].

Los puntos anteriores son la base del desarrollo de esta tesis los cuales seran tratados en

los capıtulos posteriores. Este capitulo tiene como objetivo brindar los conceptos basicos

de la Ingenierıa Dirigida por Modelos y las Lıneas de Producto de Software. Al final se

introducira los lenguajes usados para el manejo de modelos, siendo Epsilon el lenguaje de

interes.

3.1. Ingenierıa Dirigida por Modelos

La Ingenierıa Dirigida por Modelos (MDE - Model Driven Engineering) es un paradigma

que promueve el uso de modelos y las transformaciones de modelos en diferentes niveles de

abstraccion durante el desarrollo de sistemas, [3]. Una aplicacion de MDE es la Arquitectura

Dirigida por Modelos (MDA-Model Driven Architecture) creada por la OMG.

3.1.1. Modelos, Metamodelos y Transformaciones de Modelos

Un modelo es una representacion conceptual del funcionamiento, estructura y comporta-

miento de un sistema real, los cuales pueden ser representados a traves de un lenguaje. Este

lenguaje debe ser una abstraccion del dominio bajo el cual se construye el modelo, a lo que se

denomina metamodelo. De este modo, un metamodelo define un vocabulario y restricciones

para construir modelos como una representacion particular al dominio. La relacion entre el

modelo y el metamodelo se llama relacion de conformidad.

La transformacion de modelos es una operacion que se lleva a cabo entre dos o mas mo-

delos. Esta operacion se basa en algoritmos que permiten llevar modelos conforme a los

metamodelos de entrada a modelos conforme a los metamodelos de salida o a codigo directa-

mente. Los metamodelos pueden pertenecer al mismo nivel de abstraccion (Mx) o a niveles

de abstraccion inmediatos (Mx,Mx−1).

3.1.2. Acercamiento MDA

La arquitectura dirigida por modelos es un acercamiento de la OMG para el desarrollo de

sistemas. MDA propone dividir la funcionalidad del sistema desde la plataforma donde el

sistema sera implementado. Lo cual ayuda a la portabilidad, interoperabilidad y reuso del

diseno del sistema. Dividiendo la funcionalidad y la plataforma, es posible refinar la funcio-

nalidad en diferentes niveles de abstraccion. Cada nivel es transformado usando reglas de

16 3 Lıneas de Producto de Software Dirigidas por Modelos

transformacion desde un nivel a otro.

Estos son los principales elementos en MDA son, [20]:

Modelo Independiente de Computacion (CIM): Este modelo es usado para describir el

dominio del sistema. Este modelo es util para entender los requerimientos del sistema.

Este modelo no da una solucion al sistema.

Modelo Independiente de la Plataforma (PIM): Este modelo describe el comportamien-

to del sistema el cual es independiente desde la plataforma donde el sera implementado.

Este modelo puede ser refinado en diferentes grados de detalle, es decir, diferentes ni-

veles de abstraccion de diseno.

Modelo Especıfico de la Plataforma (PSM): Es el modelo donde el PIM sera imple-

mentado sobre una plataforma.

3.2. Lıneas de Productos de Software

La Ingenierıa de Lıneas de Productos de Software (SPL) es un enfoque que se soporta en

principios de reutilizacion. Este enfoque se basa inicialmente en la captura explıcita de las

caracterısticas comunes y variables de un conjunto de productos haciendo uso de modelos

de variabilidad. A partir de esta clasificacion se define y construye una serie de elementos o

activos base que son reutilizados durante el proceso de derivacion de los productos miembros

de una SPL.

El desarrollo de una lınea de producto se basa en dos procesos: Ingenierıa del dominio e

Ingenierıa de la aplicacion. La ingenierıa del dominio define e implementa los activos base

de la lınea y la ingenierıa de la aplicacion deriva los productos a partir de la plataforma base

de la lınea y la reutilizacion de componentes.

3.2.1. Lıneas de Productos Dirigida por Modelos

FieSta: Una estrategia para el manejo de variabilidad

FieSta ([5]) es una estrategia basada en el desarrollo dirigido por modelos para la creacion

de lıneas de producto de software. Esta estrategia provee mecanismos para expresar la va-

riabilidad de lıneas de producto de software e integra un proceso de derivacion a traves del

uso de modelos de decision y programacion orientada por aspectos que facilitan el reuso,

adptacion y composicion de reglas de transformacion de modelos.

Los mecanismos para expresar variabilidad son soportados por dos modelos: el modelo de

features y el modelo de restricciones. El modelo de features es un modelo que permite definir

la posible variabilidad que pueda existir en una lınea de producto. El metamodelo de features

3.3 Lenguaje para el manejo de Modelos 17

creado se basa en la metodologıa expuesta por czarnekqui [10]. Esta metodologia propone el

uso de features para representar la variabilidad. Estos features pueden ser clasificados en tres

tipos: Feature Soltario, Feature de Grupo y Feature Agrupado. Un feature de grupo expresa

escogencia sobre un conjunto de features agrupados y su cardinalidad define una restriccion

sobre el numero de elecciones; un feature agrupado no tiene cardinalidad y un feture solitario

es un feature no agrupado, donde su cardinalidad define si es obligatorio ([1..1]) u opcional

(0..1]) . Por otro lado, el modelo de restricciones permite limitar el alcance de la lınea crean-

do restricciones a las posibles configuraciones que pueda realizar un disenador de dominio

especıfico cuando configura un producto. Estas restricciones de acuerdo al metamodelo pro-

puesto se expresa a traves de relaciones de features con metaconceptos del metamodelo del

dominio especıfico y a traves de una propiedad de cardinalidad la cual lımita la cantidad de

relaciones entre los features y los metaconceptos.

La cofiguracion de un producto especıfico es soportado en la estrategia de FieSta por un mo-

delo de configuracion. El modelo de configuracion permite que un disenador de un dominio

especıfico pueda seleccionar los features que desea en su producto y expresar asociaciones

entre los features y elementos del modelo. A la seleccion de features se le denomina confi-

guracion gruesa, mientras las relaciones entre elementos del modelo y features se denomina

configuracion fina. El metamodelo propuesto contiene los metaconceptos de descritos en el

modelo de features y el concepto Configuration que contiene elementos binding, donde este

ultimo expresa la relacion entre los features y elementos del modelo.

El proceso de derivacion se realiza a partir del modelo de configuracion. Este proceso ha-

ce uso de modelos de decision para determinar la secuencia de ejecucion de las reglas de

transformacion. El modelo de decision basa la logica de su ejecucion en el paradigma de

programacion orientado a aspectos. Donde a traves de los aspectos definen cuando una regla

base deben ser interceptada (jointpoint) y que regla especıfica (advices) es ejecutada. Las

reglas base se encargan de crear los rasgos comunes en la lınea de producto y las regla es-

pecıficas de crear los rasgos variables. El metamodelo propuesto por la estrategia de FieSta

permite capturar la secuencia de las reglas de transformacion base o comunes, los aspectos

que se ejecutan para adaptar las transformaciones dada una condicion y configuraciones que

expresan las condiciones.

3.3. Lenguaje para el manejo de Modelos

De acuerdo a la perspectiva de MDE, el manejo de modelos incluye tareas comunes como

transformacion, validacion, comparacion, composicion y generacion de codigo. Estas tareas

pueden ser soportadas por uno o mas lenguajes. Por ejemplo, ATL para la transformacion

de modelos [21], OCL para validacion de modelos [22], Acceleo para la generacion de codigo

[23] y Epsilon que soporta varias tareas [24]. Nosotros vamos a usar epsilon para el manejo

18 3 Lıneas de Producto de Software Dirigidas por Modelos

de los modelos dentro de la metodologıa de HiLeS.

Epsilon es una plataforma extensible que hace parte del proyecto Eclipse Modeling GMT.

Epsilon ofrece lenguajes y herramientas para el manejo de modelos que pueden proceder de

diferentes tecnologıas como MOF, EMF y XML. El componente principal de esta plataforma

es Epsilon Language Object (EOL) que es un lenguaje agnostico al metamodelo y se basa

en el Lenguaje de Restriccion de Objetos (OCL) [25]. Este lenguaje permite acceder a los

modelos, crear modelos, modificar modelos y consultar varios modelos de forma simultanea.

A partir de EOL se construye lenguajes especıficos para dar soporte a las siguientes tareas:

Epsilon Transformation Language (ETL)

Epsilon Validation Language (EVL)

Epsilon Comparison Language (ECL)

Epsilon Merging Language (EML)

Epsilon Generation Language (EGL)

3.3.1. Transformacion de modelos en Epsilon

Epsilon Transformation Language (ETL), [25], es la especificacion de epsilon para permitir

las transformaciones de Modelo a Modelo, este es un lenguaje de transformacion hıbrido

como ATL.

En una regla etl se define el modelo de entrada y el modelo de salida. La regla genera varios

elementos de salida a partir de un elemento de entrada. Esta regla puede extender otras

reglas y realizar filtros sobre los elementos de entrada antes de ejecutar la transformacion

sobre este elemento.

3.3.2. Validacion de Modelos en Epsilon

Epsilon Validation Language (EVL) es el lenguaje para ejecutar tareas de validacion en los

modelos de manera similar a los lenguajes OCL de EMF y XCheck de OaW.

3.3.3. Comparacion de Modelos en Epsilon

Epsilon Compare Language es el lenguaje usado para expresar reglas de comparacion entre

dos modelos. Una regla ECL consiste de reglas “match” que se aplican a los elementos de los

modelos que se comparan, los cuales son los parametros de entrada de la regla. Como ETL,

3.3 Lenguaje para el manejo de Modelos 19

ECL puede incluir filtros y extender otras reglas ECL.

Los resultados de la comparacion son almacenados en un “trace”, que incluye referencias de

los objetos comparados y resultado de la comparacion. El “trace” pueda ser consultado por

los otros lenguajes de epsilon.

3.3.4. Composicion de Modelos en Epsilon

Epsilon Merging Language (EML) es el lenguaje implementado en epsilon para realizar

composicion de modelos.

3.3.5. Generacion de Codigo en Epsilon

Epsilon Generation Language (EGL) es el lenguaje especıfico para la generacion de codigo a

partir de la informacion suministrada por un modelo, es decir, soporta las transformaciones

de Modelo a Texto como sus contrapartes Acceleo ([23]) y Xpand ([26]).

4 La Cadena de Transformacion de HileS

Una cadena de trasformacion (MTC) es una secuencia de transformaciones que se ejecuta

de manera controlada y donde las transformaciones son aplicadas a modelos para generar

un nuevo modelo o un archivo de texto basado en una plantilla. La cadena de transforma-

cion de HiLeS que se muestra en la Figura 4-1, consisten en una secuencia basica de tres

transformaciones definidas de acuerdo a la metodologıa descrita en el Capitulo 2. La pri-

mera transformacion ocurre a nivel del sistema, donde el modelo construido en SysML se

transforma en un modelo conforme al dominio de HiLeS. Este modelo en HiLeS es usado

en la segunda transformacion a partir de la cual se obtienen los modelos en VHDL-AMS o

Verilog-AMS. La ultima transformacion, generan los componentes del sistema descritos en

vhdl-ams o en verilog-ams a partir del modelo obtenido en la segunda transformacion. Adi-

cionalmente, la MTC de HiLeS incluye una cuarta transformacion que genera el codigo de la

red de petri del sistema, codigo usado en la verificacion en TINA. Este codigo es generado a

partir de la informacion del modelo de HiLeS.

Figura 4-1: Cadena de transformacion base en el Framework de HiLeS

Las transformaciones, metamodelos y plantillas de la MTC de HiLeS son el resultado de

las mejoras realizadas, durante el desarrollo de este trabajo de grado 1, a los activos de la

primera version construida en el framework propuesto en [16]. Las mejoras realizadas fueron

con base a los siguientes puntos:

1Las mejoras realizadas fueron trabajadas en conjunto con los integrantes del grupo de HiLeS.

4.1 Sistema de Produccion de Cana de Azucar 21

Separacion de las reglas de transformacion de estructura y comportamiento del modelo

SysML.

Migracion de las reglas de transformacion a epsilon.

Migracion de las plantillas de codigo a epsilon.

Validacion del modelo construido en SysML.

Refinamiento de los metamodelos de HiLeS y VHDL-AMS.

Adicional a las mejoras anteriores, parte del trabajo desarrollado en esta tesis fue la extension

de la MTC de HiLeS. Esta extension permite la generacion de componentes en Verilog-AMS

a partir del modelo en HiLeS del sistema.

El objetivo de este capitulo es presentar los activos de la MTC de HiLeS. La presentacion se

realizara introduciendo un caso de estudio simple a partir del cual se mostrara los modelos

generados en cada uno de los dominios de la MTC de HiLeS.

4.1. Sistema de Produccion de Cana de Azucar

El caso de estudio a desarrollar en este capitulo es el diseno de un controlador de nivel para

un tanque de melado de un sistema de produccion de cana de azucar. El sistema de produc-

cion se muestra en la Figura 4-2.

Figura 4-2: Sistema de produccion de cana de azucar

El proceso se inicia cuando el jugo de la cana de azucar entra al Clarificador en donde es

filtrado para ser enviado al Evaporador. En el Evaporador se elimina el agua del jugo para

producir un melado. El melado es almacenado en el Tanque antes de ser enviado a las cubetas

de vacıo donde se realiza el proceso de cristalizacion. El proceso de clarificacion es continuo

y el de las cubetas de vacıo es por lotes, por lo cual el tanque funciona como un elemento

22 4 La Cadena de Transformacion de HileS

de almacenamiento temporal. La valvula on/off se encarga de controlar el flujo del tanque

hacia las cubetas de vacıo.

La funcion del controlador es evitar que el nivel del tanque supere el nivel maximo y se

desborde o que llegue a un nivel mınimo y quede vacıo. Este nivel se calcula a partir de los

flujos de entrada y salida en el tanque.

4.1.1. Requerimientos para el Controlador de Nivel

De acuerdo a la seccion anterior los requerimientos funcionales que debera cumplir el con-

trolador de nivel son los siguientes:

1. El controlador debera monitorear el nivel del tanque para permitir o no el paso del

jugo a el.

2. El controlador debera enviar una senal de control a la valvula on/off, cuando el nivel

del tanque alcance un valor mınimo.

3. El controlador debera enviar una senal al clarificador, cuando el nivel del tanque alcance

un valor maximo.

4. El controlador debera mostrar el nivel actual del tanque y alarmas en una pantalla

local.

El alcance de la solucion propuesta no tendra en cuenta las acciones a realizar cuando el

nivel del tanque se encuentre vacıo (0 %) o en sobreflujo (100 %).

4.1.2. Modelo a Nivel del Sistema

En esta seccion presentamos el modelo a nivel del sistema para el controlador de nivel. Este

modelo es construido siguiendo la metodologıa de HiLeS. A partir del modelo construido se

mostrara los activos requeridos para la ejecucion de la MTC.

Representacion de la Estructura en SysML

El controlador de nivel (TankLevelControl) consta de los componentes FlowProcessor y Dis-

playController. El FlowProcessor es responsable de procesar y controlar el flujo en el tanque

a traves de los componentes Level y Action. DisplayController, es el componente responsable

de mostrar los valores de nivel en una pantalla.

En la figura 4-3 se ilustra el diagrama de definicion de bloques (bdd) del sistema y el

diagrama interno de bloques (ibd) para el componente Flow Processor. En el diagrama

bdd se modelan los componentes del sistema, mientras el diagrama ibd del componente Flow

Processor modela las conexiones entre los bloques Level y Action.

4.1 Sistema de Produccion de Cana de Azucar 23

Figura 4-3: Diagrama de definicion de bloques para el controlador de nivel.

Representacion del Comportamiento en SysML

El diagrama de actividad construido para el sistema, TankLevelControl, se muestra en la

Figura 4-4. En el diagrama se hacen llamados a las actividades de los bloques FlowProcessor

y DisplayController. La ejecucion de la actividad finaliza si se envıa la senal de off.

Como se sabe, los bloques terminales en el bdd son los responsables de implementar la

Figura 4-4: Diagrama de actividad para el bloque TankLevelControl del controlador de

nivel.

funcionalidad especıfica del sistema. Un ejemplo de como especificar una funcionalidad en

el diagrama de actividad se muestra en la Figura 4-5. Este diagrama modela el compor-

tamiento del componente Action. El cual consiste en validar si el valor del nivel del agua se


encuentra entre los valores mınimo y maximo permitidos para el tanque, de acuerdo a esto

se ejecuta una de las dos operaciones de control de nivel o se finaliza la actividad.

Figura 4-5: Diagrama de actividad para el bloque Action del controlador de nivel.

4.2. Metamodelos de los Dominios de HiLeS

Los metamodelos construidos para soportar la MTC de HiLeS se lista a continuacion:

Metamodelo del Formalismo de HiLeS

Metamodelos de los HDLs de interes.

Metamodelo de la Red de Petri

4.2.1. Dominio del Formalismo de HiLeS

Un modelo descrito en el formalismo de HiLeS inicia con una arquitectura. Esta arquitectura

describe el comportamiento o la estructura interna del sistema a traves de bloques estruc-

turales, bloques funcionales y una red de control. Los bloques estructurales representan los

componentes jerarquicos del sistema, mientras los bloques funcionales representan los com-

ponentes funcionales del sistema. Los bloques estructurales pueden contener otros bloques

estructurales o funcionales, por lo tanto puede contener una o ninguna arquitectura. Final-

mente, la red de control define la ejecucion de los bloques basado en los componentes del

4.2 Metamodelos de los Dominios de HiLeS 25

formalismo de una red de petri.

Como se menciono en el Capitulo 2, estos bloques se comunican a traves de canales discretos

y continuos. Los puntos de interaccion de estos canales con los bloques son los servicios y

puertos, los cuales pueden ser de entrada o de salida.

De acuerdo a lo anterior, el metamodelo para el dominio de HiLes es el que se presenta a

continuacion, figura 4-6.

Figura 4-6: Metamodelo HiLeS.

Para el ejemplo del controlador de nivel, el componente TankLevelControl se representa

a traves de un bloque estructural, que contiene los bloques estructurales FlowProcessor y

DisplayController como se muestra en la figura 4-7. Por otro lado, en la figura 4-8 se ilustra

la secuencia de ejecucion descrita en HiLeS para una parte del modelo del comportamiento

en SysML del bloque DisplayController.

4.2.2. Dominio HDLs

En esta seccion se presentara los metamodelos para los lenguajes VHDL-AMS y Verilog-

AMS. Metamodelos a partir de los cuales se generan sus respectivos modelos desde un modelo

conforme a HiLeS.


Figura 4-7: Descripcion de la estructura del componente TankLevelControl en HiLeS.

Figura 4-8: Parte de la secuencia de ejecucion del componente DisplayController en HiLeS


VHDL-AMS

La figura 4-9 muestra el metamodelo para el lenguaje de VHDL-AMS. De acuerdo al meta-

modelo, un modelo en VHDL-AMS debe iniciar con un DesignUnit, este elemento contiene

una o mas entidades (Entity). En un Entity se declara las entradas y salidas del componente.

Estas entradas y salidas corresponde a los elementos PortList y GenericList. Un PortList

contienen elementos Port, que representan los puertos de un componentes, mientras un Ge-

nericList contiene elementos Generic, que representan los parametros de los componentes.

La estructura y comportamiento se define dentro de un arquitectura, Architecture. Un Ar-

chitecture esta compuesta principalmente por instancias a otras entidades, declaraciones de

senales, declaracion de datos, asignaciones de senales y procesos. La parte AMS se relaciona

con los elementos Terminal, Quantity, Branch y elementos semejantes.

Verilog-AMS

El metamodelo de Verilog-AMS se construyo con base a la especificacion formal de la sinta-

xis de Verilog, [27], y a la especificacion de la parte AMS, verilogams. En la Figura 4-10 se

muestra el metamodelo obtenido.

Un modelo en Verilog-AMS inicia con el elemento ArchitectureSystem, que puede contener

uno o mas elementos Module. Un elemento Module representa modulos, que como se sa-

ben, contiene elementos que describen la interfaz y el comportamiento de un componente.

Elementos como PortList, PortDirection, TypeDeclarations, modelan la interfaz de un com-

ponente. Estos elementos se encuentran asociados a elementos Port y Parameter, que de

acuerdo al lenguaje modelan la interaccion entre modulos. La definicion de los tipos de datos

dentro de un modulo se realiza a traves del elemento TypeDeclaration. Un TypeDeclara-

tion se debe asociar a un elemento Variable o a un elemento Port. El elemento Variable

define las conexiones internas y Port define las conexiones de los puertos de un PortList.

ModuleInstance representa la instancia de un modulo en otro principal. Un ModuleInstance

contiene un elemento Intance donde se asigna las conexiones entre los bloques y se modifica

los valores de los parametros del modulo instanciado. Los elementos BlokingStament y Con-

tinousAssignment, se relaciona con la parte del comportamiento, es decir, la definicion de la

funcionalidad para los modulos.

4.2.3. Dominio Red de Petri

El dominio de la PN se encuentra definido por el metamodelo que se muestra en la figura

4-11. Este metamodelo define los elementos base de este formalismo matematico.


Figura 4-9: Metamodelo VHDL-AMS


Figura 4-10: Metamodelo Verilog-AMS


Figura 4-11: Metamodelo de la Red de Petri.

4.3. Transformaciones

En la MTC de HiLeS, ver Figura 4-1, la secuencia de las transformaciones esta dada por las

siguientes transformaciones.

1. SysML::HiLeS

2. HiLeS::HDL

3. HDL::Code

. Las reglas de transformaciones fueron implementadas en el lenguaje Epsilon Transfor-

mation Language (ETL) introducido en el Capitulo 3. Estas reglas seran discutidas a

continuacion.

4.3.1. Transformacion SysML::HiLeS

La transformacion SysML::HiLeS transformar un modelo conforme a SysML a un modelo

conforme a HiLeS. Esta transformacion se encuentra subdividida en tres partes: Transforma-

cion de la Estructura, Transformacion del Comportamiento y Composicion de la Estructura-

Comportamiento. La separacion de la transformacion en estructura y comportamiento per-

mite simplificar las reglas de transformaciones y mantener un bajo acoplamiento entre estos

dos aspectos de diseno. La composicion permite obtener el modelo final de HiLeS, a partir

de los modelos parciales obtenidos en las transformaciones de estructura y comportamiento.

Las reglas de la parte de comportamiento fueron construidas nuevamente. Esto debido al

cambio realizado en la metodologıa de diseno a nivel del sistema con respecto al uso de los

diagramas de actividad en lugar de los diagramas de secuencia, ver Capitulo 2.

4.3 Transformaciones 31

Transformacion de la Estructura

La transformacion de la estructura consiste en crear los bloques estructurales y los canales de

comunicacion entre estos bloques a partir de la informacion suministrada por los diagramas

bdd (diagrama de bloques) e ibd (diagrama interno de bloques) de SysML. Por cada bloque

del bdd se crea un bloque estructural en HiLeS y la informacion jerarquica (arquitectura

y bloques hijos) del bloque estructural se obtiene de las relaciones de composicion que el

bloque en SysML posea. A partir de la informacion brindada por el ibd se puede crear los

puertos, servicios y canales requeridos para conectar los bloques de hiles. En la tabla 4-1

se presenta un resumen que muestra un mapeo entre los conceptos del perfil de SysML,

utilizados en esta estrategia, y los conceptos del metamodelo de HiLeS. Los elementos de

SysML son capturados del ejemplo del controlador de nivel.

Tabla 4-1: Equivalencias entre los conceptos de SysML que modelan comportamiento y el

metamodelo de HiLeS

SysML HiLeS Nota

SysML::Block To HiLeS::Block!Structural

Bloques que representan los

componentes del sistema

SysML::Block To HiLeS::Block!Structural

Cada uno de los bloques de

SysML se les crea una arquitec-

tura. Los bloques hijos se adi-

cionan a la arquitectura de los

bloques que tengan relaciones de

composicion.

SysML::FlowPort To HiLeS::Service,Port; SysML::Connector To HiLeS::Payload

Por cada puerto de sysml se gene-

ran los respectivos servicios y puer-

tos de los bloques estructurales.

Los conectores de SysML se con-

vierten en un payload de HiLeS.


En la Figura 4-12 se muestra un ejemplo de una de regla de transformacion en epsilon.

Esta regla transforma un connector de SysML a un elemento payload de HiLeS. Esta regla

se ejecuta si la conexion se realiza entre dos elementos flowport.

Figura 4-12: Regla de transformacion SysML::Connector To HiLeS::Payload aplicada a los

conectores entre puertos en SysML.

Transformacion del Comportamiento

La transformacion del comportamiento consiste en crear la red de control, servicios y puertos

de los elementos de HiLeS a partir de los diagramas de actividad en SysML. Por cada CallO-

peration de SysML se crea un bloque funcional, y los elementos CallBehavior se convierten

en bloques estructurales. Como se menciono en el Capitulo 2, una de las ventajas de usar

diagramas de actividad es que estos estan basados en redes de petri, facilitando la transfor-

macion de la mayorıa de los elementos de control. En la Tabla 4-2 se muestra equivalencias

entre los elementos de control de SysML con estructuras o propiedades de la red de petri.

La tabla 4-3 presenta de forma grafica las principales transformaciones para el comporta-

miento. Los elementos de SysML son tomados del ejemplo del controlador de nivel. En los

graficos, los puertos asociados a la red de control no seran visualizados y las regiones en gris

representaran elementos que ya existen o seran creados por otra transformacion.

Tabla 4-3: Equivalencias entre los elementos SysML y HiLeS para el comportamiento

SysML HiLeS Notes

SysML::ControlFlow To HiLeS::Transition


Tabla 4-3: (continua).

SysML::InitialNode To HiLeS::Place

SysML::CallBehaviorActivity To HiLeS::Block!Structural, To HiLeS::PetriNet

Process

Un Call Behavior es

una peticion para la

ejecucion de un bloque

estructural. Por lo tan-

to se crean los elemen-

tos de control y sus co-

nexiones con el bloque

estructural generado

SysML::CallOperationActivity To HiLeS::Block!Functional, HiLeS::PetriNet

StartConversion

Un Call Operation es

una peticion para la

ejecucion de un bloque

funcional. Por lo tan-

to se crean los elemen-

tos de control y sus co-

nexiones con el bloque

funcional generado

SysML::ForkNode To HiLeS::PetriNet

Un ForkNode a dos

CallOperationActi-

vities. Se crean los

elementos de control y

sus conexiones.

SysML::JoinNode To HiLeS::PetriNet



Un JoinNode desde

dos CallOperationActi-

vities. Se crean los ele-

mentos de control y sus

conexiones.

SysML::FinalNode To HiLeS::Place

SysML::MergeNode To HiLeS::Place

Un nodo de control

MergeNode con dos

flujos de control de

entrada.

SysML::DecisionNode To HiLeS::PetriNet

Un DecisionNode

que el evalua la senal

off, con dos posibles

flujos de control de

salida. Se crean los

elementos de control

y sus conexiones.

En la Figura 4-13 se muestra las reglas de transformacion construidas en epsilon para


Tabla 4-2: Equivalencias entre los conceptos del perfil SysML y el metamodelo de HiLeS

SysML: Elementos de Control [12] Red de Petri: Estructuras Especiales [28]

ForkNode: Cuando recibe un

token de control lo replica en ca-

da una de sus salidas.

Divergencia-AND: Cuando la

transicion se dispara coloca un to-

ken en cada salida. Genera tokens.

JoinNode: Coloca un token a

la salida si existe un token en

cada una de sus entradas.

Convergencia-AND: La transi-

cion se dispara si existe un token

en cada entrada. Absorbe tokens.

DecisionNode: Cuando recibe

el token de control lo replica solo

a una de las salidas de acuerdo

a una condicion.

Divergencia-OR: Se da cuando

existe dos o mas transiciones con

un unico lugar como entrada. Con-

flicto Estructural.

MergeNode: Coloca un token

a la salida si existe al menos una

entrada con un token de control.

Convergencia-OR: Se da cuan-

do dos o mas transiciones, cada

una con un lugar de entrada, tie-

nen el mismo lugar de salida.

generar los bloques funcionales y su red de control en HiLeS, a partir del elemento CallOpe-

rationAction de SysML.

Composicion de los modelos de Estructura y Comportamiento

El modelo de HiLeS obtenido en la transformacion SysML::HiLeS se genera a partir de

la composicion de los modelos parciales generados en las transformaciones de estructura y

comportamiento. Las reglas de composicion son realizadas en los lenguajes Epsilon Com-

paration Language (ECL) y Epsilon Merge Language (EML). ECL es usado para

construir reglas de comparacion, que permitan determinar que elementos de HiLeS se en-

cuentra en ambos modelos. Estos elementos, como los bloques estructurales, son fusionados

en un solo elemento a traves de una regla EML. Los elementos que no son capturados por

las reglas de comparacion, como los de la red de control de HiLeS, son adicionados al mo-

delo final de HiLeS. En la Figura 4-14 se muestra parte del modelo HiLeS generado para el

control de nivel junto con los modelos parciales de estructura y comportamiento. La parte

que se visualiza corresponde al componente ControlFlow. Por ejemplo, la informacion de

puertos y servicios de los bloques estructurales generados en la transformacion de estructura

se completa con los puertos y servicios correspondientes a los arcos de la red de control.


Figura 4-13: Regla de transformacion SysML::CallOperationActivity To Hi-

LeS::Block!Functional, To HiLeS::PetriNet.

Mientras la informacion de los elementos de la red de control de la parte de comportamiento

es adicionada al modelo final de HiLeS.

Figura 4-14: Modelo de HiLeS obtenido de la composicion de las modelos generados en las

transformaciones de estructura y comportamiento.

4.3.2. Transformacion HiLeS::HDL

La transformacion SysML::HDL transforma un modelo conforme con HiLeS a un modelo

conforme con un HDL especıfico. Los dos HDLs soportados por nuestra MTC son VHDL-

AMS y Verilog-AMS. En esta seccion se mostrara los mapeos entre los elementos de HiLeS y

los elementos de los metamodelos de los HDLs soportados,a partir de los cuales se especifica-


ran las reglas de transformacion en ETL. Al final, se mostrara un parte del modelo generado

en ambos lenguajes para el caso de estudio.

VHDL-AMS

La transformacion de un modelo en HiLeS a un modelo en VHDL-AMS, se basa principal-

mente en crear entidades, sus arquitecturas e instancias a otros componentes. Los elementos

Entity y ComponentInstance se crean desde los bloques estructurales y funcionales. Las

senales y asociaciones son generadas desde los elementos payload de HiLeS, es decir, de los

canales de comunicacion. Desde los elementos de la red de control (Place, Transition, Arc)

se generan senales, asociaciones e instancias a los componentes en VHDL-AMS de Place y

Transition. Finalmente, los puertos son obtenidos desde los servicios y puertos de HiLeS.

En la tabla 4-4 se muestra un mapeo de los elementos principales del dominio de VHDL-

AMS con el dominio de HiLeS. Los elementos de VHDL-AMS se visualiza como una porcion

de codigo basado en el caso de estudio.

Tabla 4-4: Equivalencias entre los elementos HiLeS y VHDL-AMS

HiLeS VHDL-AMS Notes

HiLeS::Block!Structural To vhdlAMS::Entity

Se crean un Entity

para el componen-

te que representa

el bloque.

HiLeS::Block!Functional To vhdlAMS::Entity

Se crean un Entity

para el componen-

te que representa

el bloque.

HiLeS::Architecture To vhdlAMS::Architecture

HiLeS::Service To vhdlAMS::Port



El puerto se adi-

cionan a la enti-

dad creada desde

el bloque estruc-

tural dueno del

servicio

HiLeS::Port To vhdlAMS::Port

El puerto se adi-

cionan a la enti-

dad creada desde

el bloque estruc-

tural funcional del

servicio

HiLeS::Payload, Arc To vhdlAMS::Signal, Terminal

El tipo de

senal creada

dependera de la

naturaleza del

elemento Payload.

Para cada uno de

los arcos de la red

de control se crea

un Signal.

HiLeS::Block To vhdlAMS::ComponentInstance

Se crea la ins-

tancia al elemento

Entity generado a

partir del mismo

bloque.

HiLeS:: Place, Transition To vhdlAMS::ComponentInstance



Se crean las

instancias a las

entidades Place

y Transition.

Estas entidades

se encuentran

previamente

construidas en

VHDL.

Verilog-AMS

La transformacion de un modelo en HiLeS a un modelo en Verilog-AMS, es similar a las

transformaciones en VHDL-AMS. En este caso, se inicia creando un SystemArchitecture a

partir del elemento HilesSystem. Luego se crean los modulos, las declaraciones de senales,

las instancias a otros modulos y los puertos. A continuacion, en la tabla 4-5 se resume el

mapeo de los elementos principales del dominio de Verilog-AMS con el dominio de HiLeS.

Los elementos de Verilog-AMS se visualiza a traves de un porcion de codigo basado en el

caso de estudio

Tabla 4-5: Equivalencias entre los elementos HiLeS y Verilog-AMS

HiLeS VHDL-AMS Notes

HiLeS::Block!Structural To vhdlAMS::Module

Se crean un Mo-

dule para el com-

ponente que re-

presenta el blo-

que.

HiLeS::Block!Functional To vhdlAMS::Module

Se crean un Mo-

dule para el com-

ponente que re-

presenta el blo-

que.

HiLeS::Service To vhdlAMS::Port



El puerto se adi-

cionan a la enti-

dad creada desde

el bloque estruc-

tural dueno del

servicio.

HiLeS::Port To vhdlAMS::Port

El puerto se adi-

cionan a la enti-

dad creada des-

de el bloque fun-

cional dueno del

servicio

HiLeS::Payload, Arc To verilogAMS::TypeDeclaration

El tipo de la

declaracion de

la senal de-

pendera de

la naturaleza

del PayLoad.

Los arcos de

la red control

se crean como

DiscreteNet.

HiLeS::Block To verilogAMS::ModuleInstance

Se crean la ins-

tancia al elemen-

to Module gene-

rado a partir del

mismo bloque.

HiLeS:: Place, Transition To verilogAMS::ModuleInstance



Se crean las

instancias a los

modulos Place

y Transition.

Estos modulos

se encuentran

previamente

construidos en

Verilog.

Modelos VHDL-AMS y Verilog-AMS

En la Figura 4-15 se ilustra una fraccion de los modelos generados a partir de las transfor-

maciones descritas en las secciones anteriores. La fraccion corresponde al componente Action

que hace parte del sistema de control de nivel. Los modelos son conformes a los metamodelos

de VHDL-AMS y Verilog-AMS descritos previamente, esto se presentan en el formato ecore

de eclipse.

Figura 4-15: Modelos en VHDL-AMS y Verilog-AMS del componente Action


4.3.3. Transformacion HDL::Code

A partir de la transformacion HDL::Code se genera el codigo de los componentes de los

modelos generados en HiLeS::HDL. Esta transformacion se realiza con el uso de plantillas

construidas de acuerdo a la sintaxis de los lenguajes HDLs soportados. La transformacion

hace uso de dos plantillas, una plantilla que genera el codigo de un componente de pruebas

y otra plantilla que genera el codigo de cada uno de los componentes del sistema. Estos

componentes son representados por el elemento Entity del modelo VHDL-AMS, y por el

elemento Module del modelo Verilog-AMS. Las plantillas fueron construidas con el lenguaje

Epsilon Generation Language(EGL).

Prototipos Virtuales

En la Figura 4-16 y la Figura 4-17 se muestra parte del codigo generado en vhdl-ams y

verilog-ams para el componente Action (ver Figura 4-14). La parte derecha de la figuras

muestra la declaracion de instancias que se realizan dentro del archivo de entity o module.

Figura 4-16: Fraccion del codigo del prototipo virtual del componente Action

4.3.4. Transformacion HiLeS::PetriNet::Code

La transformacion HiLeS::PetriNet::Code esta compuesta por dos transformaciones. La pri-

mera, es una transformacion de modelo a modelo donde los elementos de la red de control

del modelo de HiLeS son transformados a los elementos correspondientes del dominio de la

Red de Petri (PN), ver , esto genera el modelo de la Red de Petri del sistema. La segunda

transformacion consiste en generar el codigo de la PN a partir del modelo generado en la

primera. Este archivo es el que se usa para las validaciones en TINA dentro de la metodologıa

de HiLeS.


Figura 4-17: Fraccion de codigo con ejemplo de instancias para el componente Action

Para el caso de estudio, en la figura Figura 4-18 se muestra un ejemplo grafico del modelo de

la red de petri que se construye a partir de la informacion del modelo de HiLeS. El ejemplo

solo muestra parte de la red de control para el bloque estructural TankLevelControl con el

bloque estructural DisplayController. De acuerdo al ejemplo, la transformacion de modelo a

modelo consiste en eliminar la parte estructural y jerarquıa del modelo HiLeS. Los mapeos

entre los elementos de ambos dominios son directos.


Figura 4-18: Modelo de la red de petri generada a partir del modelo de HiLeS.

5 Variabilidad y Configuracion del

Producto en HiLeS

De acuerdo al capitulo Capitulo 3, el manejo de variabilidad a nivel del sistema dentro de

la MTC de HiLeS permite definir una linea de productos del sistema modelado en SysML.

Rasgos como estandares de comunicacion, algoritmos de encripcion, parametros funcionales

u otro tipo de caracterıstica, determinan los aspectos variables de los componentes.

El manejo de la variabilidad y la configuracion del producto especıfico desde el dominio de

SysML no puede ser manejado de forma directa como se realiza en la estrategia de FIESTA,

[5]. En este dominio solo un concepto es usado para representar los componentes del siste-

ma, de manera que el metamodelo de SysML debe ser extendido a partir de los componentes

variables del sistema base para soportar el manejo de variabilidad. Este manejo dentro de la

metodologıa de HiLeS se quiere realizar con los activos de la estrategia de FIESTA. Pero

estos activos se encuentran desarrollados en Open Architecture Ware, y no se encuentran

actualizados con las nuevas versiones. A raız de esto se decidio pasar epsilon, pero antes de

eso tambien se concluyo que para verificar que el planteamiento de FIESTA se mantuviera

era necesario formalizar la especificacion de los conceptos de modelo de variabilidad, restric-

ciones, decision y configuracion.

En la parte inicial del capitulo se presentara la definicion formal realizada a los modelos

utilizados en la estrategia de FIESTA. Luego se presentara un caso de estudio a partir del

cual se mostrara el desarrollo de la propuesta para el manejo de variabilidad desde el dominio

de SysML. Esto tambien incluye la estrategia desarrollada para la derivacion de un diseno

especıfico a partir de una configuracion.

5.1. Definicion Formal de los Modelos de Variabilidad

5.1.1. Los Modelos de Features y Restricciones

En la Figura 5-1 se muestra un ejemplo de como se construye un modelo de restricciones a

partir de un metamodelo MM y un modelo de features FM, de acuerdo con el enfoque de

FIESTA. Su representacion grafica se basa en la notacion de Czarneschi, [29]

46 5 Variabilidad y Configuracion del Producto en HiLeS

Figura 5-1: Modelo de Restricciones

Como se menciono en el Capitulo 2, el modelo de features permite describir las variaciones

de la lınea de producto, mientras el modelo de restricciones es usado para validar las confi-

guraciones que se crean al momento de derivar un producto especıficos. Por ejemplo, en la

Figura 5-1 las restricciones c1 y c3 establece que solo los elementos conforme a los metacon-

ceptos m3 y m4 pueden estar asociados con las opciones ofrecidas por los features f3 y f5,

respectivamente. Por otro lado, la restriccion c4, establece que la configuracion pueden tener

entre una (1) a tres (3) asociaciones que involucren el feature f7 con elementos conforme al

metaconcepto m4.

A partir de este ejemplo se introduce las definiciones formales de los modelos de features y

restricciones.

Definicion Formal del Modelo de Features

Un modelo de Features (FM) puede ser descrito formalmente como una tupla constituida

por un conjunto de features, un conjunto de cardinalidades y un conjunto de secuencias de

features (ver Ecuacion 5-1). El conjunto de features se puede organizar en subconjuntos de

secuencias de features que forman un arbol con una raız y n nodos, de las cuales m son

terminales.

FM = 〈F,G,X〉 (5-1)

Donde:

F = {f1, f2, ..., fn}, representa el conjunto de features

G = {g1, g2, ..., gl}, representa el conjunto de cardinalidades

g = {min,max} ,min,max ∈ N ∧min < max

5.1 Definicion Formal de los Modelos de Variabilidad 47

g define una cardinalidad X = {−→x 1,−→x 2, ...,

−→x n}, representa el conjunto de secuencias

−→x se define como una secuencia finita y ordenada de features (ver Ecuacion 5-2), por ejemplo,

la secuencia −→x1 = {f1, f2, xor − f2, f5, xor − f5, f7}, ver Figura 5-1.

Sea −→x : N → X : −→x = 〈f1, f2, ..., fm〉|(fi ∈ F ) ∧ (m < n), denotada por: −→x i | m,m ∈ N(5-2)

Un feature es terminal si existe una unica secuencia que lo contenga, (ver Ecuacion 5-3),

como por ejemplo: los features f7 y f8.

terminal : F → {true, false} ; terminal (fi) =

{true , Si ∃!−→x j|fi ∈ −→x j

false , de lo contrario(5-3)

Los features pueden ser clasificados como features de tipo solitario (fs), de grupo (fg) y

agrupado (gf ), [30]. Esta clasificacion define una propiedad de los features la cual puede ser

definida a traves de la funcion ftype, (ver Ecuacion 5-4). Los features xor − f2 y xor − f5,

que hacen parte de la secuencia −→x1, son features de grupo y sus hijos features agrupados

ftype : F → {fs, fg, gf}

ftype(fi) =

fs Si fi ∈ FS|FS ⊆ F , define un feature solitario

fg Si fi ∈ FG|FG ⊆ F , define un feature de grupo

gf Si fi ∈ GF |GF ⊆ F , define un feature agrupado

⇔ FS 6= FG 6= GF

(5-4)

Adicional a la clasificacion anterior, se deben cumplir ciertas restricciones entre los features

padres e hijos.

Supongamos dos secuencias: −→xn = {f1, ..., fn−1, fn} y −→xm = {f1, ..., fm−1, fm}, donde

fn−1 = fm−1 = fp ⇒ fp es un feature padre y {fn, fm} sus hijos, entonces:

1. Si ftype(fp) = fs||gf ⇒), ftype(fn) = fs||fg ∧ ftype(fm) = fs||fg.

2. Si ftype(fp) = fg ⇒), ftype(fn) = gf ∧ ftype(fm) = gf .

Los features de tipo solitario o de grupo se deben relacionar con las cardinalidades que hacen

parte del FM (ver Ecuacion 5-1). De modo que el par ordenado 〈f, g〉 define una relacion

fRg entre estos elementos (ver Ecuacion 5-5) .

fRg = 〈fi, gj〉 ⇔ fi ∈ F ∧ gj ∈ G ∧ (ftype(fi) = fs ∨ ftype(fi) = fg) (5-5)


Definicion Formal del Modelo de Restricciones

De acuerdo al estrategia de FIESTA, una restriccion (cj) se define como una tupla com-

puesta por un metaconcepto (mk), un feature (fl), una cardinalidad (A) y una propiedad de

dependencia estructural (D). Por lo tanto, el modelo de restricciones (CM ) puede ser defini-

do formalmente como una tupla formada por restricciones (C ), fetures (F ) y metaconceptos

(EC ) (ver Ecuacion 5-6). EC es el conjunto de todos los metaconceptos que hacen parte del

metamodelo del dominio del problema (MM ).

CM = 〈F,C,CM〉 , modelo de restricciones (5-6)

Donde,

C = {cf1, cf2, ..., cfn}cf = 〈m, f,A,D〉 | m ∈ EC ∧ f ∈ FA = {i, j} ⇒ min ≤ i ≤ j ≤ max ∧ ∃!fRg| min,max ∈ g,D = {ocl1, ocl2, ..., ocln} , define un conjunto de restricciones ocl

Las propiedades A y D, permite establecer las validaciones ha realizar en una configuracion

de un producto especıfico. Para el caso de la propiedad A, las validaciones dependen del

tipo de feature que hace parte de la restriccion. Sea ck = 〈mx, fc, {i, j} , D〉 una restriccion,

entonces:

Si ftype(fc) = fs||gf , se valida que el numero de asociaciones (bl) en una configuracion

que satisfaga la restriccion se encuentre entre los limites de la cardinalidad A.

∀bl ∈ B ⇒ i ≤ |B′| ≤ j | bl s−→ck ∧B′ ⊆ B (5-7)

Si ftype(fc) = fg, se valida que exista una asociacion bl = 〈ey, fm〉 en la configuracion

que satisfaga la restriccion y que el numero de asociaciones con el elemento ey y los

features hijos de fc se encuentre entre los limites de la cardinalidad A.

∃bl| bl s−→ck ⇒ i ≤ |B′| ≤ j | B′ ⊆ B ∧B′ = {〈ez, fn〉 : ez = ey ∧ fn ∈ fc} (5-8)

5.1.2. El Modelo de Decision

Un modelo de decision expresa las condiciones que validan cuando se debe ejecutar una regla

especıfica en lugar de la regla base, dada una configuracion. Estas condiciones contienen

variantes, las cuales son obtenidas a partir de la informacion de los modelos de features y

restricciones. En el modelo restricciones, cada ck y su propiedad de cardinalidad asociada

(A) establece las posibles opciones o combinaciones (nCr) que se pueden establecer en una

configuracion fina (ver Ecuacion 5-9). Por ejemplo, para la restriccion c3 (ver Figura 5-1) se


puede definir las siguientes combinaciones: 2c1,1 = 2C1 ∪ 2C1 = {f7, f8}. Los elementos que

hacen parte de la combinacion definen las variantes.

ncl,m =n Cl ∪ nCl+1 ∪ ... nCm (5-9)

Donde:

n, es la union de todos los elementos terminales del feature asociado a la restriccion

l,m =

{l = i,m = j , ftype(fh) = fg ∧ i, j ∈ A ∧ A, fh ∈ ckl = {0, 1} ,m = 1 , ftype(fh) = fs ∧ fh ∈ ck

La ecuacion anterior solo es valida si cada metaconcepto se relaciona solo con un feature. Si

un metaconcepto (mx) debe ser asociado a mas de un feature (fh),(ver Figura 5-1), entonces,

las variantes se obtienen a partir de los elementos que forman parte de las combinaciones

resultantes desde las restricciones asociadas al mismo metaconcepto. Por ejemplo, para las

restricciones c2 y c3 asociadas con el metaconcepto m4, una posible configuracion para un

elemento del modelo ey conforme a este metaconcepto es: f7,f9 y f11. Por lo tanto, las com-

binaciones son todas la n-tuplas ordenadas que se pueden obtener del producto entre cada

uno de los elementos de las opciones de cada restriccion, (ver Ecuacion 5-10).

nFCm|c| =n cm1 × ncm2 × ... ncm|c| (5-10)

Donde: |c| es el numero total de restricciones asociadas al metaconcepto mx.

Para el caso de configuracion gruesa, las variantes se definen a partir de la combinacion de

uno o mas features terminales, los cuales pueden ser seleccionados o no seleccionados durante

la configuracion. Por lo tanto, las variantes estan dadas por los elementos de combinaciones

genericas nCCr, donde los valores de n y r dependen de los requerimientos de la lınea 1.

A partir de la informacion anterior, se pueden establecer las condiciones en el modelo de

decision. Esta son usadas para validar cada elemento ey del modelo de entrada (Ms) dada

una configuracion. La validacion se cumple cuando el elemento se encuentre asociado a uno

o mas fetures en la configuracion, y si las asociaciones cumplen con las variantes de la condi-

cion. En el momento que la condicion sea valida se busca la regla especıfica (rei) asignada a

la condicion, la cual se ejecuta para transformar el elemento ey a un elemento e′y del modelo

de salida (Mt), de lo contrario, se ejecuta su regla base (rbj).

Teniendo en cuenta lo anterior, la logica de ejecucion de un modelo de decision puede ser

expresada formalmente de la siguiente manera:

1Para este caso, el conjunto de las combinaciones esta sujeto a las decisiones de los ingenieros de la Lınea

de Producto, dado que en este caso las reglas especıficas son aplicadas a todos los elementos que sean

conformes a un metaconcepto que requiera el manejo de variabilidad


pd = φ

∀ey ∈Ms

if ∃ condition(ey, B)

pd = execute(rei, ey, pd)

else

pd = execute(rbj, ey, pd)

(5-11)

Donde:

pd ⊆Mt, Mt es el modelo de salida conforme a MMt

Ms es el modelo de entrada

B = {b1, b2, ..., bn}, es un conjunto de asociaciones

execute, es una funcion que define la ejecucion de las reglas

La funcion condition se define como:

condition =

{true, if ∃ bi | ey = ei ∧ ei ∈ bi ∧ cdl e←→B

′

false, de lo contrario(5-12)

Donde:

cdl ∈ nCm|c| ∨ cdl ∈ nCCr, define una condicion como:

cdl = F × V = {〈ft1, v1〉 , ..., 〈ftm, vm〉} | ∀fz ∈ F ⇒ terminal(fz) = true

V, es el conjunto de variantes para una combinacion particular.

B′ ⊆ B, es un subconjunto de todas las asociaciones del elemento ey con a uno o mas fetures

en la configuracion

cdl e←→B′, valida que todas las asociaciones cumplan con las variantes de la condicion. La va-

riante depende de si se trata de asociaciones (configuracion fina) o de features seleccionados

(configuracion gruesa).

De acuerdo a las definiciones anteriores, un modelo de decision se puede definir como una

tupla compuesta por condiciones, por un conjunto de reglas base, por un conjunto de reglas

especıficas y por un conjunto de intercepciones que relaciona cada condicion con una regla

especıfica y con una regla base.

MD = 〈CD,Q,Q′, I〉 (5-13)

Donde,

CD = {cd1, cd2, ..., cdn}Q = {q1, q2, ..., qn}Q′ = {q′1, q′2, ..., q′n}I = {i1, i2, ..., in}i = 〈q, q′, cd〉


5.1.3. El Modelo de Configuracion

En la Figura 5-2 se muestra un ejemplo de un modelo para configuracion fina construido de

acuerdo a la estrategia de FIESTA.

Figura 5-2: Modelo de Configuracion

De acuerdo a la figura, una configuracion fina se define a traves de asociaciones (bindings) que

relaciona elementos del modelo con features de tipo terminal. Cada asociacion generada es

un par ordenado de un elemento del modelo M con un feature del modelo FM, [5]. Esto defi-

ne un conjunto de asociaciones (bindings) (ver Ecuacion 5-14)) en el modelo de configuracion.

B = {b1, b2, ..., bn} (5-14)

Donde,

b = 〈e, f〉 , e ∈M ∧ f ∈ F ∧ terminal(f) = true

Un binding bi = 〈ei, fk〉 puede ser creado si satisface una de las restricciones creadas en el

modelo de restricciones, es decir, bi s−→ cj.

Sea la restriccion cj = 〈mj, fj, A,D〉 la relacion bi s−→ cj se cumple si:

fj = fk y si el elemento ei es conforme a mj.

Por otro lado, la configuracion gruesa se define a partir de los features que fueron seleccio-

nados o no seleccionados durante una configuracion (ver Ecuacion 5-15).

FS = {fs1, fs2, ..., fsn〉 (5-15)

Donde,

fs = 〈f, s〉 , f ∈ F ∧ s ∈ S


S = {selected, notSelected}

De acuerdo a lo anterior, un modelo de configuracion MB puede ser definido como una estruc-

tura formada por un conjunto de bindings y un conjunto de features FS (ver Ecuacion 5-16).

MB = 〈FS,B〉 (5-16)

5.2. SHRMS: Sistema para el Monitoreo de Salud

Estructural

Los sistemas de monitoreo remoto para salud estructural (SHRMS) permiten monitorear

estructuras como puentes, edificios aviones, entregando informacion fiable que permite dar

alerta temprana sobre posibles danos en una estructura. Un esquema central de un SHRMS

consiste de un sistema local (estacion de monitoreo), y un sistema remoto (transmisor)

localizado en la estructura a monitorear. El sistema local obtiene la informacion de la unidad

remota para ser presentada a un usuario. El sistema remoto debe encargarse de las siguientes

funciones:

Capturar las diferentes condiciones de la estructura, particularmente la medidas de

vibraciones, a traves de sensores.

Gestionar y procesar los datos entregados por los diferentes sensores.

Mostrar los datos capturados.

Enviar los datos que han sido procesados al sistema local de forma encriptada.

Para simplificar el ejemplo solo se va a mostrar el diseno de la unidad remota del sistema

SHRMS.

5.2.1. Requerimientos para el sistema SHRMS

De acuerdo a la seccion anterior los requerimientos funcionales que debera cumplir la unidad

remota son los siguientes:

1. La unidad debera capturar datos de aceleracion en al menos un eje.

2. Cada medida de aceleracion debera ir con una etiqueta de tiempo.

3. Cada dato capturado debera ser transmitido al sistema local.

4. La unidad debera mostrar los datos de aceleracion capturados en el lugar de monitoreo.

5.2 SHRMS: Sistema para el Monitoreo de Salud Estructural 53

5.2.2. Modelo a Nivel del Sistema

En esta seccion presentamos el modelo a nivel del sistema para la unidad de monitoreo

remoto del sistema SHRMS. Este modelo es construido siguiendo la metodologıa de HiLeS.

A partir del modelo construido se mostrara la propuesta para el manejo de variabilidad en

HiLeS y sus activos.

Representacion del Sistema en SysML

La unidad de monitoreo remoto consta principalmente de los componente de Capture, Ac-

quisition, Encode, Visualize y Communication. El componente Capture es responsable de

capturar la informacion desde los sensores, mientras el componente Acquisition procesa la

informacion capturada la cual es enviada a unidad local a traves del componente Commu-

nication. Antes de enviar la informacion a la unidad local esta es encriptada por Encode. El

componente Visualize es el responsable de mostrar la informacion capturada. En la Figu-

ra 5-3 se presenta parte del modelo de la estructura y el comportamiento disenada para la

unidad de monitoreo remoto.

Figura 5-3: Modelo de Features del componente Acceleration del sistema SHRMS.


5.2.3. Rasgos Variables del Sistema y el Modelo de Features

Los sensores de aceleracion pueden variar caracterısticas relacionadas a su interfaz y desem-

peno. Por ejemplo, las interfaces pueden ser analogas y digitales o la resolucion de bits de

la informacion manejada puede estar entre valores de 10, 11 y 12 bits. Por otro lado, la

encripcion de los datos depende de caracterısticas como algoritmos de encripcion, modo de

operacion o tamano de llave. Por lo tanto, los componentes AccelerationCapture y Encode

son los componentes variables del sistema SHRMS.

La Figura 5-4 muestra parte del modelo de features construido de acuerdo con el enfoque

de FIESTA, [5]. La parte que se visualiza corresponde a los rasgos variables del compo-

nente AccelerationCapture y su representacion grafica se basa en la notacion de Czarneschi,

[29]. De acuerdo a la figura, el sensor de aceleracion puede manejar senales analogas tipo

DCM y Voltaje, o senales digitales tipo SPI (Serial protocol Interchange). El numero de

ejes que puede medir puede ser un eje, dos ejes o tres ejes. Mientras la resolucion en bits

de la senal digital de salida puede ser uno de los valores del modelo o la combinacion de estos.

Figura 5-4: Modelo de Features del componente Acceleration del sistema SHRMS.

5.3. Extension del Perfil de SysML para el manejo de

Variabilidad

SysML es un lenguaje de proposito general, por lo tanto, las caracterısticas estructurales

y de comportamiento de los componentes del sistema que se esta disenando se definen en

base al mismo metaconcepto del metamodelo de SysML. En este caso, todos los arboles de

variabilidad para todos los componentes estarıan asociados a un solo metaconcepto y eso lo

hace inviable de manejar directamente, ya sea aplicando l modelo de features de Czarnecki,

5.3 Extension del Perfil de SysML para el manejo de Variabilidad 55

[30] o la estrategia de FIESTA.

Teniendo en cuenta lo anterior, nuestra propuesta para el manejo de la variabilidad en la

metodologıa de HiLeS es hacer uso de un perfil en UML, a traves del cual se extienda el

metamodelo de SysML para que incluya la informacion de los componentes variables. La

propuesta consiste en lo siguientes pasos:

1. Construir un perfil en UML a traves del cual se pueda identificar los componentes

variables en el modelo de SysML.

2. Extender el metamodelo de SysML a partir de los elementos anotados con el perfil de

UML.

3. Generar un nuevo modelo del sistema conforme al metamodelo extendido de SysML.

A partir del metamodelo extendido de SysML y el nuevo modelo del sistema se realizara el

manejo de la variabilidad aplicando la estrategia de FIESTA. Se debe aclarar, que este nuevo

activo solo sera usado para definir los modelos de variabilidad y que el diseno del sistema es

el modelo construido desde el metamodelo original de SysML.

5.3.1. Perfil de Variabilidad

La variabilidad en la estrategia de HiLeS se da a nivel de los componentes funcionales del

sistema, ya que sobre estos se define el comportamiento especıfico del sistema. Este com-

portamiento especıfico usualmente es provisto a partir de una propiedad intelectual (IP).

Una IP es componente previamente construido, que puede ser configurable externamente a

traves de parametros, como por ejemplo: la resolucion en bits para la captura de una medida.

Por otro lado, las IPs puede proveer diferentes interfaces dependiendo de las funcionalidades

ofrecidas, las cuales pueden ser analogas o digitales.

Las variaciones generadas por el uso de IPs afecta a los componentes funcionales en dos as-

pectos. El primero, esta relacionado con la informacion adicional que debe ser suministrada

para configurar los parametros de las IPs, la cual debe suministrada por el bloque funcional

que instancia una IP particular. El otro aspecto, involucra los puertos de conexion de estos

componentes funcionales los cuales deben ser adaptados dependiendo de la naturaleza de la

senal, donde esta informacion es suministrada por el tipo de interfaz de la IP.

Los elementos de SysML relacionados con los dos aspectos mencionados son: CallOperatio-

nAction, ObjectFlow y Connector. A partir del elemento CallOperationAction se genera los

bloques funcionales de los componentes. Los elementos ObjectFlow y Connector generan las

senales que fluyen a traves estos componentes.


De acuerdo a lo anterior, el perfil UML para expresar variabilidad se debe construir a partir

de las metaclases CallOperationAction, ObjectFlow y Connector de UML. Los estereotipos

que extiende las metaclases, dependen de los rasgos de los bloques con variabilidad del

sistema embebido, en otras palabras son construidos a partir de la informacion del modelo

de features. La Figura 5-5 muestra un perfil creado de acuerdo a los rasgos variables del

componente AccelerationCapture del sistema SHRMS (ver Figura 5-4).

Figura 5-5: Perfil de variabilidad para el sistema SHRMS.

5.3.2. Metamodelo Extendido de SysML

El metamodelo extendido de SysML es construido a partir del perfil de UML creado para ex-

presar variabilidad. Cada estereotipo del perfil deben extender los metaconceptos de SysML

que representan los elementos anotados con el perfil. Para el caso de estudio, se crean los me-

taconceptos Encode, AccelerationCapture, AccelerationConnector y AccelerationObjectFlow.

Encode y AccelerationCapture deben extender del metaconcepto CallOperationAction de

SysML. AccelerationConnector y AccelerationObjectFlow deben extender de los metacon-

ceptos Connector y ObjectFlow de SysML, respectivamente. La Figura 5-6 muestra la parte

que fue extendida para el metamodelo de SysML. A partir de este metamodelo extendido se

crea el modelo del sistema conforme a este metamodelo.

Figura 5-6: Perfil de variabilidad para el sistema SHRMS.

5.4 Derivacion del Producto Especıfico 57

Figura 5-7: Estrategia para la derivacion de productos especıficos.

5.4. Derivacion del Producto Especıfico

En la seccion 5.1.2 se realizo una definicion formal de la logica de ejecucion de los modelos

de decision para la derivacion de productos especıficos en una lınea de productos (ver Ecua-

cion 5-11). De acuerdo a esta ecuacion, la ejecucion de una regla especıfica o base esta sujeta

al resultado de la funcion condition(ey,B’), la cual valida que exista al menos un binding

asociado al elemento ey y que los bindings de la configuracion B’ cumplan con las variantes

asociadas a una condicion del modelo de decision. Para el caso de una configuracion gruesa,

la funcion condition es evaluada con respecto a los features seleccionados o no seleccionados

dentro de la configuracion y las variantes de la condicion.

Nuestra propuesta para la derivacion del producto especıfico esta basada en los lenguajes

ECL y EVL de epsilon. Como se discutio en el Capitulo 3, EML permite la composicion

de modelos a partir de comparaciones con reglas ECL. Por cada uno de los elementos del

modelo que cumpla la comparacion debe existir una regla EML la cual sera ejecutada. Para

los elementos que no cumpla la comparacion, se debera ejecutar la regla ETL correspondiente

al elemento. Esto se ilustra en la Figura 5-7.

Retomando la definicion de logica de ejecucion de los modelos de decision (ver Ecuacion 5-

11), tenemos que:

La evaluacion de la condicion es dada por las reglas ECL (Fase de Comparacion).

La funcion execute es realizada por el motor de epsilon, quien se encarga de ejecutar

las reglas EML o ECL de acuerdo la condicion (Fase Merge/Transformacion).

Adicional a la solucion propuesta para implementar la logica de ejecucion de los modelos de

decision en epsilon, se debe construir una regla EML principal. En esta regla se importan

todos las reglas EML y las reglas bases de la transformacion de SysML a HiLeS construidas

en la MTC. Esta regla es construida a partir del modelo de decision.


Figura 5-8: Regla ECL para el metaconcepto AccelerationCapture.

5.4.1. Fase de Comparacion

La fase de comparacion se realiza sobre el modelo del Sistema, en este caso el modelo de

SysML extendido sysmlExt, el modelo de decision (decision) y el modelo de configuracion

(configuration). Los modelos sysmlExt y decision definen los parametros left y right de la

regla ECL, respectivamente. El modelo configuration se usa para consultas dentro de la parte

de comparacion (compare) y filtro (guard)de la regla ECL.

El algoritmo de comparacion de la regla ECL se construye a partir de la semantica de la

funcion condition (ver Ecuacion 5-12), es decir, se establece todas las validaciones existentes

de la relacion cdl e←→B′. En la Figura 5-8 se presenta un ejemplo de la regla ECL construida

para el metaconcepto AccelerationCapture.

5.4.2. Fase Merge/Transformacion

En esta fase se define la ejecucion de las reglas especıficas o de las reglas base, de acuer-

do a la informacion del archivo de trazas generado en la fase de comparacion. Las reglas

especıficas son definidas por reglas EML, mientras las reglas base son las reglas ETL que

fueron definidas en la MTC de HiLeS, ver Capitulo 4. Las reglas especıficas son aplicadas a

los modelos: SysML extendido (sysmlExt),decision (decision) y HiLeS (hiles). Los modelos

sysmlExt, (decision) y hiles definen los parametros de merge, with e into de la regla EML,

respectivamente. La transformaciones definidas en las reglas especıficas son ejecutadas para

los elementos del modelo sysmlExt que esten asociados a un elemento del modelo de (decision

en el archivo de trazas.

5.4 Derivacion del Producto Especıfico 59

Figura 5-9: Regla EML AccelerationCaptureToFunctional del metaconcepto Acceleration-

Capture y regla ETL CallOperationActionToFunctional del metaconcepto

CallOperationAction.

La Figura 5-9 muestra un ejemplo de la regla EML AccelerationCaptureToFunctional y la

regla ETL CallOperationActionToFunctional para el sistema SHRMS. En la regla Accelera-

tionCaptureToFunctional se especıfica la informacion adicional para el bloque funcional.

5.4.3. Modelo Decision

Para construir el modelo de decision se requiere construir primero el modelo de restriccio-

nes. Este modelo es construido a partir del metamodelo extendido de SysML y el modelo

de Features del sistema. En la Figura 5-10, se muestra un ejemplo de la construccion del

modelo de restricciones del sistema SHRMS a partir de su modelo de features. En el modelo

se ilustra parte de los features de los componentes Acceleration y Encode.

A partir de este modelo se obtiene la informacion de las condiciones y sus variantes para la

ejecucion de las transformaciones. Por ejemplo, para el componente AccelerationCapture del

sistema SHRMS se pueden establecer las siguientes condiciones :

cd1 = {〈1G,AccelerationCapture〉 , 〈10bits, AccelerationCapture〉}cd2 = {〈10bits, AccelerationCapture〉 , 〈12bits, AccelerationCapture〉}cd3 = {〈V oltage, AccelerationConnector〉}

A partir de las condiciones se construyen las reglas especıficas en EML. Una vez construidas

las reglas, se realiza el modelo de decision. En la Figura 5-11 se muestra la representacion

grafica de una parte del modelo de decision del sistema SHRMS. El modelo es construido


Figura 5-10: Modelo de Restricciones

con base al metamodelo de decision de la estrategia de FIESTA. La parte que representa el

modelo son las condiciones 1 y 3 del componente AccelerationCapture.

El modelo de decision obtenido se usa para la generacion de las reglas ECL de la fase de

comparacion y la regla EML principal, para la ejecucion desde la MTC de HiLeS. Las reglas

de transformaciones construidas para la generacion de estos archivos seran discutidas en la

siguiente seccion.

5.5. Activos para el manejo de Variabilidad en HiLeS

5.5.1. Metamodelos

Los metamodelos utilizados para soportar el manejo de variabilidad dentro de la MTC de

HiLeS se lista a continuacion:

Metamodelo extendido de SysML

Metamodelos para el manejo de variabilidad

El metamodelo extendido de SysML es un metamodelo que se crea cada vez que se construya

la lınea para sistemas embebidos. Como se menciono en , este metamodelo dependera de la

informacion del perfilUML. Por ejemplo, en la Figura 5-12 se muestra el metamodelo del

caso de estudio de la SHRMS.

Los modelos de features, restricciones y configuracion son creados a partir de los metamo-

delos construidos en la estrategia de FieSta, [5]. En cuanto el metamodelo de decision fue

5.5 Activos para el manejo de Variabilidad en HiLeS 61

Figura 5-11: Representacion grafica del modelo de decision del sistema SHRMS

Figura 5-12: Metamodelo extendido para la lınea especializada de sistemas SHRMS.


ajustado para incluir la logica de ejecucion planteada en 5.4. En la Figura 5-13 se muestra el

metamodelo de decision ajustado. Los ajustes realizados se enumeran a continuacion. Prime-

ro, se agrego los metaconceptos DecisionLogic y Condition. Segundo, el metaconcepto Aspect

se modifico para que extendiera desde DecisionLogic. Finalmente, se agrego mas informacion

al metaconcepto Metamodel. A partir de Condition se modela las condiciones obtenidas del

modelo de configuracion.

Figura 5-13: Metamodelo de decision ajustado

5.5.2. Transformaciones

Transformacion Decision::Code

A partir de la transformacion Decision::Code se genera el codigo de las reglas ECL y la

reglas EMLExecute desde el modelo de decision. Esta transformacion se realiza con el uso de

plantillas construidas de acuerdo a la sintaxis de los lenguajes de epsilon. La transformacion

hace uso de dos plantillas, una plantilla que genera el codigo de cada una de las reglas de

comparacion y otra plantilla que genera el codigo de la regla EML. Las plantillas fueron

construidas con el lenguaje Epsilon Generation Language(EGL).

La reglas ECL son construidas a partir de los elementos Condition del modelo de decision.

Estos elementos tienen una relacion al elemento Configuration a partir de la cual se pueden

obtener las variantes de la condicion. A partir de la informacion de las variantes se obtiene

las condiciones de la variable validate que se define en la parte compare de la regla ECL,

5.5 Activos para el manejo de Variabilidad en HiLeS 63

como se muestra en la Figura 5-14.

Figura 5-14: Regla ECL

La regla EML se crea a partir de la informacion suministrada en las relaciones specificRule y

baseRule que tienen los elementos Condition. las relaciones specificRule y baseRule relaciona

las reglas especifica y la regla base de la condicion. En la

Figura 5-15: Regla EML que define la ejecucion de las transformaciones para la lınea del

sistema SHRMS.

6 RCP para el Diseno de Sistemas

Embebidos desde la Metodologıa de

HiLeS

Uno de los objetivos de esta tesis es proveer ambientes de desarrollo integrado para construir

lineas especializadas en el diseno de sistemas embebidos desde la metodologıa de HiLeS. Un

ambiente para construir el producto base y otro ambiente para derivar productos especıfi-

cos. Estos ambientes de desarrollo o aplicaciones deben estar constituidos por los activos

desarrollados en la cadena de transformacion (MTC) de HiLeS, Capitulo 4, y el manejo de

variabilidad, Capitulo 5. Ademas, deben ser aplicaciones facilmente extensibles que permitan

integrar, en su medida, las herramientas de soporte desarrolladas dentro del grupo de HiLeS

(IPSEARCH, TUCAN) y herramientas externas, como TINA.

Eclipse provee una plataforma que permite crear aplicaciones flexibles y extensibles mediante

el uso de una arquitectura de componentes basada en plugins. Esta plataforma se basa en la

plataforma tecnologica RCP (Rich Client Plattform), la cual permite construir aplicaciones

de cliente enriquecidas. El desarrollo de aplicaciones RCP en eclipse permite heredar las fun-

cionalidades base de este IDE (vistas, menu, integracion, workbenchs, etc) permitiendonos

solamente preocuparnos por las funcionalidades especıficas de la aplicacion.

En el trabajo de [31] se construyo una primera version de una aplicacion de la MTC de

HiLeS, basado en los activos del framework inicial y en la plataforma de RCP de Eclipse.

Basados en este trabajo previo y en los nuevos activos de la MTC de HiLeS y en los activos de

variabilidad se desarrollo las aplicaciones: HiLeS Workbench y HiLeS-PL Workbench.

Estas aplicaciones deben apoyar los procesos para la construccion de lıneas especializadas

de sistemas embebidos. El objetivo de este capitulo es presentar los componentes desarro-

llados para estos ambientes y su funcionalidad. Adicionalmente, se mostrara la creacion de

una lınea de producto del caso de estudio presentado en el Capitulo 5 desde el ambiente de

HiLeS Workbench.

6.1 HiLeS Workbench 65

6.1. HiLeS Workbench

HiLeS Workbench es un ambiente de desarrollo para construir lıneas de producto especia-

lizadas en el diseno de sistemas embebidos en HiLeS, que de acuerdo a la metodologıa de

HiLeS, debe proveer las siguientes funcionalidades:

Creacion y edicion del modelo del sistema en SysML.

Ejecucion de la MTC de HiLeS.

Validacion del modelo del sistema en TINA.

Construccion de los modelos base para el manejo de Variabilidad

6.1.1. Arquitectura de Alto Nivel

La arquitectura de HiLeS Workbench se encuentra formada principalmente por los compo-

nentes que se muestran en la Figura 6.1.1. Los componentes que se visualizan en el diagrama

son los componentes funcionales de la aplicacion, los cuales seran explicados a continuacion.

Figura 6-1: Arquitectura de alto nivel del ambiente de desarrollo de HiLeS Workbench.

HiLeSMTC

SysMLEditor

Este componente provee los editores para la creacion y edicion de los diagramas en SysML.

Estos editores son provistos por los plugins org.eclipse.papyrus.syml y org.topcasd.modeler.syml

desarrollados en los proyectos de Papyrus [32] y Topcased [33], respectivamente 1.

1El editor inicial del Framework de HiLeS fue soportado por el plugin de Topcased.

66 6 RCP para el Diseno de Sistemas Embebidos desde la Metodologıa de HiLeS

HiLeSTransformation

Componente responsable de la ejecucion de las transformaciones de la MTC de HiLeS. Esta

ejecucion es implementada con base a los activos de las transformaciones de modelo a modelo

y transformaciones de modelo a codigo desarrolladas en la MTC de HiLeS.

HiLeSModelEditor Este componente contiene los plugins que fueron desarrollados para

los dominios de HiLeS, VHDLAMS, VerilogAMS y PetriNet. El componente brinda funcio-

nalidades para validacion del modelo en SysML y editores EMF para los modelos de estos

dominios.

VariabilityManagement

FiestaModels

Componente que contiene los plugins desarrollados en la estrategias de Fiesta para la cons-

truccion de los modelos de Features y Restricciones para el manejo de variabilidad. Tambien,

contiene un editor emf para la creacion del modelo de decision.

Generator

Es un plugin desarrollado para la generacion de los modelos de variabilidad en epsilon.

Herramientas de Soporte

ExtendSysML

Plugin que permite generar el modelo extendido de SysML del diseno del sistema, a partir

del perfil del sistema en SysML. Este perfil se crea desde el editor de Papyrus.

TINASupport

Este plugin permite ejecutar los comandos de validacion de la herramienta de TINA desde

el IDE de HiLeS Workbench. Plugin desarrollado en el grupo de HiLeS.

TicswModelsTools

Componente que ofrece funcionalidades comunes dentro del funcionamiento de la RCP.

6.2. HiLeS-PL Workbench

HiLeS-PL Workbench es un ambiente de desarrollo para la configuracion y derivacion de un

producto especıfico dentro de la lınea especializada de HiLeS. Por lo tanto, este ambiente

debe ser construido con base a los modelos del sistema y variabilidad que fueron previamente

6.2 HiLeS-PL Workbench 67

creados en HiLeS Workbench. Siguiendo la metodologıa de HiLeS, el ambiente de desarrollo

debe proveer las siguientes funcionalidades:

Configuracion del producto especıfico.

Ejecucion de la MTC de HiLeS.

Validacion del sistema en TINA.

6.2.1. Arquitectura de Alto Nivel

La arquitectura de HiLeS-PL Workbench se encuentra formada principalmente por los com-

ponentes que se muestran en la Figura 6.2.1. En el diagrama solo se visualiza los componentes

funcionales de la aplicacion, los cuales seran explicados a continuacion.

Figura 6-2: Arquitectura de alto nivel del ambiente de desarrollo de HiLeS-PL Workbench.

De acuerdo al diagrama, los componentes modificados o adicionales respecto a la arquitec-

tura de HiLeS Workbench son:

SpecializedHiLeSTransformation

Componente modificado para ejecutar la transformacion de SysML a HiLeS de acuerdo a la

configuracion que se realice para un producto especıfico. En este componente se adiciona la

informacion del modelo base del diseno en SysML, los modelos de variabilidad, el metamodelo

extendido de SysML y el modelo extendido del sistema. La ejecucion de las trasformaciones

de HiLeS a HDL, a la red de petri y a codigo son basadas en la mismas funcionalidades del

componente HiLeSTransformation.

FiestaConfigurationModel

Plugin provisto por la estrategia de FIESTA para la construccion del modelo de configura-

cion.


6.3. Construccion de una Lınea Especializada para

Sistemas SHRMS

Basado en el caso de estudio presentado en el Capitulo 5, se muestra la creacion de la lınea

especializada para Sistemas de Monitoreo Remoto de Salud Estructural (SHRMS) desde los

ambientes desarrollados. La creacion de una lınea especializada desde la estrategia de HiLeS

teniendo en cuenta los procesos de lıneas de producto de software, debe ser realizada por

ingenieros con los siguientes perfiles: arquitecto de la lınea de producto, experto del dominio

y disenador del producto especıfico. El arquitecto de la lınea de producto y el experto del

dominio son los usuarios responsables de crear el diseno base de la lınea especializada. La

derivacion del producto es responsabilidad del disenador del producto especıfico.

6.3.1. Creacion de la Lınea especializada

Diseno y modelamiento del sistema base

El experto del dominio inicia creando un proyecto HiLeS desde las opciones del menu de

HiLeS Workbench, como se presenta en la Figura 6-3. El workbench crea una estructura

de carpetas donde se almacena los modelos y archivos de codigo, de acuerdo a como sean

creados. En la carpeta model, el experto del dominio adiciona el modelo SysML del sistema

SHRMS, el cual se crea desde el editor de Papyrus. Este modelo se crea siguiendo la meto-

dologıa de HiLeS descrita en el Capitulo 2.

Figura 6-3: Creacion de un proyecto de HiLeS desde el IDE HiLeS Workbench.

Validacion del diseno del modelo base

Para validar el modelo base el experto del dominio debe generar el modelo de HiLeS desde

6.3 Construccion de una Lınea Especializada para Sistemas SHRMS 69

el modelo SysML del sistema. El modelo generado es adicionado por el workbench en la

carpeta src-gen, como se presenta en la Figura 6-4.

Figura 6-4: Generacion del modelo de HiLeS desde el IDE HiLeS Workbench.

A partir de este modelo, el experto del dominio obtiene la red de petri del sistema, como se

muestra en la Figura 6-5.


Teniendo la red de petri del sistema, el experto del dominio puede ejecutar los comandos de

validacion de la herramienta TINA desde el ambiente de desarrollo de HiLeS Workbench.

Estos comandos son provistos desde las opciones del menu del workbench, a partir de los

cuales se solicita los datos para la simulacion de la red de petri en TINA, como se muestra

en la Figura 6-6.



Construccion de los modelos de variabilidad

Validado el modelo base de la lınea, el experto del dominio inicia la creacion de los modelos

para el manejo de variabilidad. Antes de crear los modelos de variabilidad el experto del

dominio debe crear un perfil UML para expresar la variabilidad en el modelo SysML del sis-

tema. Este perfil se adiciona en la carpeta model y se construye desde el editor de papyrus,

como se muestra en la Figura 6-7. Los bloques del sistema con variabilidad son anotados

con los estereotipos creados en el perfil. A partir de este perfil y del metamodelo extendido

de SysML, el experto del dominio crea el modelo extendido del sistema.

Figura 6-7: Creacion de un perfil UML desde el IDE HiLeS Workbench.

Con el modelo extendido del sistema, el experto de dominio puede crear los modelos de fea-

tures, restricciones y decision. El modelo de restricciones se crea a partir de un editor grafico,

mientras el modelo de features y el modelo de decision se crean desde un editor EMF, como

se presenta en la Figura 6-8.

6.3 Construccion de una Lınea Especializada para Sistemas SHRMS 71

Figura 6-8: Modelos de variabilidad desde el IDE HiLeS Workbench.

Generacion de las Reglas de Comparacion y Creacion de Reglas Especıficas

Teniendo los modelos para el manejo de variabilidad, el experto del dominio ejecuta la opcion

Generate WorkFlow que permite obtener los archivos de las reglas ECL (Eclipe Compare

Language), donde se valida las condiciones del modelo de decision, y la regla EML(Epsilon

Merge Language), que define el flujo de ejecucion. Este flujo de ejecucion se encarga de eje-

cutar la transformacion de SysML a HiLeS.

El arquitecto de la lınea de producto debe crear las reglas especificas en EML teniendo en

cuenta el modelo de configuracion del sistema.

6.3.2. Derivacion de un Producto Especıfico

El disenador del producto especıfico se encarga de crear el modelo de configuracion desde

un editor grafico, en el cual se cargan los modelos de variabilidad y el modelo extendido del

sistema. Una vez creado este modelo, el disenador ejecuta la opcion Generate HiLeS model

para obtener el modelo de HiLeS del sistema.

A partir del modelo de HiLeS el disenador obtiene los archivos de codigo de los componentes

del sistema, como se muestra en la Figura 6-9.


Figura 6-9: Modelos de variabilidad desde el IDE HiLeS Workbench.

7 Conclusiones

El principal objetivo para el desarrollo de esta tesis es proveer ambientes de desarrollo in-

tegrado para apoyar la construccion de lıneas de producto especializadas en el diseno de

sistemas embebidos basados en la metodologıa de HiLeS. HiLeS Workbench es un ambien-

te desarrollado para apoyar la creacion del producto base y el manejo de variabilidad. De

forma paralela, HiLeSPL Workbench es un ambiente desarrollado para apoyar el proceso de

derivacion del producto especıfico. En este capitulo se presentara los aportes realizados en

esta tesis durante el desarrollo de estos ambientes y trabajos futuros.

7.1. Resultados y Aportes

Los resultados y aportes logrados durante el desarrollo de esta tesis en los ambientes cons-

truidos se enumera a continuacion.

Participacion en la estabilizacion de los activos base de la cadena de transformacion

de HiLeS e implementacion de los plugins que fueron integrados en los ambientes

desarrollados.

Extension de la cadena de transformacion de HiLeS para soportar la generacion de

componentes en Verilog-AMS.

Formalizacion de los modelos de variabilidad provistos en la estrategia de FieSta.

Planteamiento de la estrategia para el manejo de variabilidad a nivel del sistema basado

en la estrategia de FieSta e integracion de los plugins en los ambientes desarrollados.

Solucion e implementacion de la logica para la derivacion de productos especıficos a

partir del modelo de decision.

7.2. Ventajas y Limitaciones

Los ambientes de desarrollo ofrecen principalmente dos ventajas a la metodologıa de HiLeS.

La primera se relaciona con la integracion en un ambiente simple de las funcionalidades para

la ejecucion de la cadena de transformacion de HiLeS y el manejo de variabilidad del siste-

ma. La otra, es que se pueden extender las funcionalidades e integrar herramientas externas

74 7 Conclusiones

a estos ambientes, gracias a las ventajas que ofrecen las aplicaciones construidas bajo una

plataforma RCP. En cuanto a la propuesta para el manejo de variabilidad, el uso del perfil

UML para expresar variabilidad desde SysML permite que se pueda seguir usando el editor

de Papyrus o Topcased desde ambos ambientes sin necesidad de generar nuevos editores cada

vez que se cree una lınea especializada para el diseno de sistemas embebidos.

Por otro lado, se han identificado algunas limitaciones tanto en los ambientes desarrollados

como en la propuesta de variabilidad. La primera, es que parte de las funcionalidades ofre-

cidas por HiLeS workbench es crear el modelo de features y el modelo de decision desde

editores EMF, esto puede volverse una tarea compleja dependiendo del tamano del arbol

de variabilidad del sistema. Esto tambien ocurre en el dominio de HiLeS, donde se usa un

editor EMF para ver el modelo, en algunos casos especiales el sistema deberıa poder ser

modelado desde este dominio. Respecto al manejo de variabilidad se puede enumerar las

siguientes desventajas. La primera, es que las reglas especıficas son creada manualmente lo

cual puede ser una tarea dispendiosa dependiendo de la cantidad de posibles configuraciones

que se pueda tener en la lınea, por otro lado el manejo de variabilidad solo esta a nivel de

los requerimientos funcionales.

Respecto a la metodologıa de HiLeS una de las limitantes es que los resultados de las valida-

ciones o verificaciones realizadas al diseno del sistema no son integradas de manera automati-

ca sino que la identificacion de los componentes que tienen falla se debe realizar de forma

manual. Esto se debe a que las validaciones son realizadas desde herramientas externas, por

lo tanto quedan por fuera de la cadena de transformacion de HiLeS (MTC) y los resultados

arrojados por estas no pueden ser incorporados de forma directa a los modelos de la MTC.

7.3. Trabajo Futuro

Teniendo en cuenta las limitaciones planteadas en la seccion anterior, a continuacion se

propone algunas mejoras para los ambientes desarrollados y las estrategias para el manejo

de variabilidad desde la metodologıa de HiLeS.

Construir editores graficos para permitir el diseno del sistema desde el dominio de

HiLeS y para crear los modelos de features y decision para el manejo de variabilidad.

Evaluar la posibilidad de generar reglas especıficas desde el modelo de restricciones

para la configuracion fina.

Identificar y evaluar el manejo de variabilidad desde el punto de vista de los requeri-

mientos no funcionales. Los requerimientos no funcionales a nivel de diseno de sistemas

embebidos son generalmente restricciones sobre el diseno como el tamano de la tarjeta

donde iran los componentes, o tambien respecto a desempeno de los componentes.

7.3 Trabajo Futuro 75

Manejar trazabilidad en las transformaciones de los modelos que forman parte de la

cadena de transformacion de HiLeS. Esto con el fin de indicar de una forma automatica

al disenador del producto especıfico los componentes desde la parte estructural que

generan la falla o los elementos de los diagramas de actividad que no ofrecen el control

esperado desde el lado del comportamiento.

Por otro lado, en el desarrollo de esta tesis no se alcanzo a estabilizar e integrar las herra-

mienta de apoyo IPSearch y Tucan dentro del ambiente de HiLeSPL workbench.

Bibliografıa

[1] F. Jimenez H. Hoyos, R. Casallas and D. Correal. Hiles2: model driven embedded

system virtual prototype generation. In Proceedings of the 2011 Symposium on Theory

of Modeling & Simulation: DEVS Integrative M&S Symposium, TMS-DEVS ’11, pages

75–82, San Diego, CA, USA, 2011. Society for Computer Simulation International.

[2] D. Esteve J. Verries F. Jimenez, R. Duarte and C. Gutierrez. A platform for high level

systems design based on the hiles formalism.

[3] F. Fondement and R. Silaghi. Defining model driven engineering processes. In 3rd

Workshop in Software Model Engineering Satellite workshop at the 7th International

Conference on the UML, 2004.

[4] C. Gomez. Modeling complex systems using sysml. Master’s thesis, Universidad de los

Andes.

[5] H. Arboleda. FieSta: An approach for Fine-Grained Scope Definition, Configuration

and Derivation of Model-Driven Software Product Lines. PhD thesis, Universidad de

los Andes/Universite de Nantes, 2009.

[6] F. Jimenez R. Casallas H. Hoyos, G. Grandas and D. Correal. Tucan: Time constraints

analysis of real-time embedded systems.

[7] J. Tovar. Ontology based intellectual properties(ip) search indexing and evaluation.

Master’s thesis, Universidad de Los Andes, 2011.

[8] Openarchitectureware framework. Website. http://www.openarchitectureware.org/.

[9] D. Gajski. Embedded system design: modeling, synthesis and verification. Springer,

2009. ISBN 9781441905048. LCCN 2009931042.

[10] F. Jimenez C. Gomez, J. Pascal and P. Esteban. Heterogeneous systems verification

on hiles designer tool. In 36th Annual Conference of the IEEE Industrial Electronics

Society (IECON-2010)., 2010.

[11] K. Kundert and O. Zinke. The Designer’s Guide To Verilog-AMS. Kluwer Academic

Publishers, Boston, 2004.

Bibliografıa 77

[12] A. Moore S. Friedenthal and R. Steiner. A Practical Guide to SysML: The Systems

Modeling Language. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, 2008.

ISBN 0123743796, 9780123743794.

[13] C. Lallement F. Pecheux and A. Vachoux. Vhdl-ams and verilog-ams as alternative

hardware description languages for efficient modeling of multidiscipline systems. IEEE

Trans. on CAD of Integrated Circuits and Systems, 24(2):204–225, 2005.

[14] Time petri net analyzer, laascnrs. Website. http://www.laas.fr/tina/.

[15] C. Villarraga F. Jimenez and L. Plata. Sintesis de sistemas digitales modelado con redes

de petri a traves del formalismo hiles designer. In XV Workshop IBERCHIP, volume 1

y 2, 2009.

[16] G. Grandas. Framework para el desarrollo de lineas de producto de sistemas electronicos,

basado en redes de petri, mde y hiles-designer. Master’s thesis, Universidad de los Andes,

2010.

[17] E. Piel R. Ben Atitallah A. Etien P. Marquet A. Gamatie, S. Le Beux and J. Dekeyser. A

model-driven design framework for massively parallel embedded systems. ACM Trans.

Embed. Comput. Syst., 10:39:1–39:36, November 2011.

[18] S. Rosinger K. Gruttner, K. Hylla and W. Nebel. Towards an esl framework for ti-

ming and power aware rapid prototyping of hw/sw systems. In Specification Design

Languages, 2010. IC 2010. Forum on, pages 1 –6, sept. 2010.

[19] E. Silva F. Carvalho C. Pereira E. De Freitas, M. Wehrmeister and F. Wagner. Deraf:

a high-level aspects framework for distributed embedded real-time systems design. In

Proceedings of the 10th international conference on Early aspects: current challenges

and future directions, pages 55–74, Berlin, Heidelberg, 2007. Springer-Verlag.

[20] R. France and B. Rumpe. Model-driven development of complex software: A research

roadmap. In 2007 Future of Software Engineering, FOSE ’07, pages 37–54, Washington,

DC, USA, 2007. IEEE Computer Society. ISBN 0-7695-2829-5.

[21] Atl transformation language. Website. http://eclipse.org/atl/.

[22] Object constraint language (ocl). Website. http://www.eclipse.org/modeling/mdt/

?project=ocl.

[23] Acceleo project. Website. http://www.acceleo.org/pages/home/en.

[24] Epsilon project. Website. http://eclipse.org/gmt/epsilon/.

[25] R. Paige D. Kolovos, L. Rose. The Epsilon Book.

78 Bibliografıa

[26] Xpand, a language specialized on code generation based on emf models. Website. http:

//www.eclipse.org/modeling/m2t/?project=xpand.

[27] Verilog formal syntax specification. Website. http://www.verilog.com/VerilogBNF.

html.

[28] D. Ren and A. Hassane. Discrete, Continuous, and Hybrid Petri Nets. Springer Publis-

hing Company, Incorporated, 2nd edition, 2010. ISBN 3642106684, 9783642106682.

[29] K. Czarnecki and et al. Cardinality-based feature modeling and constraints: A progress

report, 2005.

[30] S. Helsen K. Czarnecki and U. Eisenecker. Staged configuration using feature models.

In Software Product Lines: Third International Conference, SPLC 2004, pages 266–283.

Springer-Verlag, 2004.

[31] L. Lara. Estudio de la plataforma rcp y su aplicacion en un caso de estudio. Technical

report, Universidad de los Andes, 2010.

[32] Papyrus project. Website. http://www.papyrusuml.org.

[33] Topcased project. Website. http://www.topcased.org/.

HiLeS-PL: Un Framework para la Construcci on de L neas ...

Documents

Transcript of HiLeS-PL: Un Framework para la Construcci on de L neas ...