Algoritmo para particionado autom atico de sistemas con … · 2014-09-11 · Algoritmo para particionado autom atico de sistemas con criticidad mixta Emilio Salazar1, Alejandro Alonso1

Actas de las XXXV Jornadas de Automática, 3-5 de septiembre de 2014, ValenciaISBN-13: 978-84-697-0589-6 © 2014 Comité Español de Automática de la IFAC (CEA-IFAC)

Algoritmo para particionado automatico de sistemas concriticidad mixta

Emilio Salazar1, Alejandro Alonso1 and Salvador Trujillo2

1Universidad Politecnica de Madrid{esalazar,aalonso}@dit.upm.es

[email protected]

Resumen

El desarrollo de sistemas particionados enplataformas multicore presenta nuevos desafıosque estan siendo objeto de muchas investigaciones.En esta clase de desarrollos existe un trabajo adi-cional: identificar las aplicaciones que deben serejecutadas en la misma particion. Para lograr esteobjetivo se deben tener en cuenta un numero im-portante de consideraciones, tales como el nivelde criticidad, requisitos temporales, requisitos deseguridad (safety y security), requisitos de hard-ware, etc.

Este artıculo describe en detalle el algoritmo degeneracion automatica de particiones desarrolladoen el marco del proyecto MultiPARTES [10].

Palabras clave: Real-time systems, PartitionedSystems, Mixed Criticality, Model Driven Engi-neering.

1 Introduccion

Los progresos tecnologicos en el campo de losprocesadores han incrementado notablemente supotencia de calculo. Los complejos sistemascrıticos empotrados que antano debıan ejecutarseen multiples equipos, ahora se pueden ejecutar sinproblemas en un unico computador con multiplesnucleos, con tiempo de computo disponible paraejecutar otras aplicaciones no crıticos.

No obstante, aunque la posibilidad de ejecutarmultiples sistemas en un unico computador tienemuchas ventajas, existe todavıa una dificultadmuy importante: garantizar espacial y temporal-mente la correcta ejecucion de todos los sistemas,incluso en caso de fallo de alguno de ellos.

Una aproximacion que cada vez cobra mas fuerzaes el uso de sistemas particionados. En un sistemaparticionado se anade un software de muy bajonivel entre el hardware y el resto aplicaciones de-nominado hipervisor. Los hipervisores como Xtra-tum [17] [9] permiten la creacion de particiones.Las particiones deben estar completamente ais-ladas unas de otras, para que el fallo de una noafecte al correcto funcionamiento de las demas.

Dentro de cada particion, se pueden ejecutar apli-caciones de diferente criticidad de forma segura,ya que Xtratum garantiza la separacion espacial ytemporal exigida en el estandar ARINC-653 [3].

Sin embargo, el soporte para el diseno y con-struccion de sistemas particionados multicore estodavıa escaso. El proyecto MultiPARTES [10]nace con el objetivo de mejorar ese soporte. Mul-tiPARTES busca crear un entorno de desarrollode sistemas crıticos particionados en platafor-mas multicore libre y abierto, con herramientasde apoyo de desarrollo basado en MDE (ModelDriven Engineering) [19].

En este artıculo se presenta parte de las her-ramientas que se estan desarrollando en elmarco del proyecto MultiPARTES cuyo principalproposito es facilitar el desarrollo de sistemas par-ticionados crıticos y de alta integridad en platafor-mas multicore [18] [2]. En particular, se muestrael algoritmo que permite la generacion automaticade las particiones a partir de los modelos de en-trada.

2 Arquitectura del sistema

En la figura 1 se muestra una descripcion de losprincipales componentes de la arquitectura del sis-tema, que se pueden resumir en:

Modelado del sistema: Se trata de la principal en-trada a la herramienta. Se compone, fundamen-talmente, de tres modelos:

• Modelo de plataforma. Contiene la infor-macion relacionada con la plataforma de eje-cucion: hardware subyacente, hipervisor ysistemas operativos disponibles.

• Modelo de aplicacion. Describe la aplicacion.Se han definido dos tipos principales de mod-elos de aplicacion:

– Modelo de aplicaciones modeladas conUML 2 [15] y el perfil MARTE [14].Gracias al detalle con el que se puedemodelar la aplicacion al emplear UML-MARTE, es posible realizar:

1


Neutral

NeutralTransformator

Artifacts

Source Code

Source Code Generator

Xtratum con�guration

XtratuMCon�guration

Xtratum make�les

XtratuMMake�les

Documenta-tion

Documenta-tion

Partitioning

PartitioningTool

Deployment

Validation

ValidationTransformation

Tool input model

Validation Tool

Tool result model

Application PlatformPartitioning Restrictions

System model

Figura 1: Arquitectura general de las herramientas

∗ El perfil de MARTE provee deestereotipos donde se definen laspropiedades temporales de cada ob-jeto del sistema (p.e. periodos de tar-eas, tiempos de respuesta, etc.).

∗ Otra caracterıstica importante quepermite el modelo UML-MARTE esque proporciona la base para generaresqueletos de codigo Ada 2005 [7]acorde al perfil de Ravenscar [4], loque se requiere para sistemas crıticos.

– Modelo de aplicaciones pre-existentes.Para cumplir con este requisito, se haideado un modelo que permite definir lainformacion mınima necesaria de cadaaplicacion para poder realizar un parti-cionado valido.

• Modelo de restricciones al particionado. De-scribe explıcitamente restricciones que debecumplir el particionado resultante. Este mod-elo se explica con mayor detalle en la seccion3.

Herramienta de particionado del sistema: Generaautomaticamente las particiones del sistema, que

es el objeto de este artıculo y se explica detallada-mente en la seccion 3.

Validacion: Integrar en la herramienta todos losprocesos de validacion es muy complejo y ademasharıa muy complicado ampliar la herramienta conprocesos de validacion de nuevas propiedades nofuncionales. Por ello, se ha optado por ofrecerun modelo de interfaz (modelo de despliegue) conotras herramientas y dejar que estas se encarguende la validacion.

Generacion de artefactos: una vez que se ha com-probado que el particionado propuesto cumple conlos requisitos requeridos se generan una serie deartefactos cuya mision es ayudar al disenador aconstruir el sistema final:

• Ficheros de configuracion de Xtratum.

• Scripts de compilacion del sistema.

• Esqueletos de codigo (Ada 2005 con el perfilde Ravenscar).

Esta herramienta esta todavıa en desarrollo. Enel momento de escribir estas lıneas hay un pro-totipo de la herramienta capaz de trabajar con


modelos sencillos. No obstante, el objetivo esir anadiendo funcionalidades gradualmente hastaobtener una herramienta completamente fun-cional. La plataforma de desarrollo es EclipseModeling Tools y emplea Java como principallenguaje de programacion. Los metamodelos em-pleados son ECore o UML 2.4.

3 Particionado del sistema

En esta seccion de describe con detalle comofunciona el algoritmo de particionado de la her-ramienta. El problema a resolver es como agru-par las aplicaciones descritas en las entradas enel menor numero posible de particiones de modoque se cumplan todos los requisitos especificadospor el disenador, usando de la forma mas equili-brada posible todos los recursos hardware de laplataforma.

Debido a la magnitud del problema, se ha optadopor seguir la estrategia ”divide y venceras”. Estaestrategia consiste en dividir el problema originalen sub-problemas mas pequenos cuya resolucionsea mas asequible.

En el caso que nos ocupa se han identificado lossiguientes sub-problemas:

• Agrupar las aplicaciones en particionescumpliendo con los requisitos definidos en losmodelos de entrada. Se puede tratar como unproblema de asignacion de elementos a recur-sos.

• Asignar las particiones a los recursos deprocesamiento disponibles en la plataformade la forma mas equilibrada posible. Se puedetratar como un problema de equilibrado decargas de trabajo.

• Generacion de un plan de ejecucion de lasparticiones generadas que permita cumplirlos requisitos temporales de todas las aplica-ciones contenidas en las particiones.

Dada la complejidad de cada uno de los proble-mas, se ha decido abordarlos en secuencia. Estearticulo se centrara en el algoritmo empleado pararesolver el primero de los sub-problemas: la gen-eracion de las particiones.

3.1 Entradas

La informacion de entrada que requiere el algo-ritmo de generacion de particiones es:

3.1.1 Aplicaciones

Las aplicaciones que deben ser agrupadas en par-ticiones. Esta informacion se obtiene de los mod-elos de aplicacion definidos por el disenador en laentrada.

3.1.2 Restricciones

Una restriccion al particionado consiste en unaregla que indica al algoritmo de particionado loque debe (o no) hacer con una determinada apli-cacion. En el algoritmo actual existen las sigu-ientes reglas:

1. La aplicacion A no puede ir en la misma par-ticion que la lista de aplicaciones Va.

2. La aplicacion A debe ir en la misma particionque la lista de aplicaciones Va.

3. La aplicacion A debe ser alojada en la par-ticion P.

4. La aplicacion A no debe ser alojada en la par-ticion P.

5. La aplicacion A requiere acceso al hardwareH.

6. La aplicacion A es una aplicacion que vieneya empaquetada en una particion y no debemodificarse.

Se han identificado dos clases de restricciones de-pendiendo de si estas pueden ser automaticamentededucidas o no:

• Restricciones implıcitas. Son aquellas restric-ciones que son necesarias para que se veri-fiquen restricciones intrınsicas de un sistemaparticionado con criticidades mixtas.

Por ejemplo, dos aplicaciones con diferentesistema operativo nunca podran ir en lamisma particion, pues cada particion albergaun unico sistema operativo. Otro ejemploes el hardware exigido por cada aplicacion:una aplicacion para procesadores Intel, nopuede ir en la misma particion que otra apli-cacion que esta compilada para procesadoresSPARC.

Del mismo modo, dos aplicaciones condiferente nivel de criticidad no pueden iren la misma particion, ya que cada par-ticion solo ejecuta aplicaciones que poseanel mismo nivel de criticidad. Una buenaparte de esta clase de restricciones son de-tectadas por la herramienta y generadas au-tomaticamente ahorrando al disenador indi-carlas explıcitamente.


• Restricciones explıcitas. Son restriccionesadicionales que se deben cumplir para que elparticionado sea valido y que el disenador in-dica de forma expresa. A diferencia de las an-teriores, esta clase de restricciones no puedenser deducidas automaticamente por la her-ramienta pues normalmente responden req-uisitos no modelados en MARTE o a necesi-dades particulares de un sistema concreto.

Una ventaja significativa de poder definir re-stricciones de particionado de forma explicitaes la posibilidad de integrar en el algoritmode particionado el conocimiento de otras her-ramientas especializadas en diferentes cam-pos. Ası por ejemplo, una herramienta deanalisis de criticidad puede generar la listade restricciones oportuna para que el sistemaparticionado cumpla con el estandar de cor-respondiente (p.e. el servidor de vıdeo y elservidor de juegos de un sistema de entreten-imiento de un avion no pueden ir en la mismaparticion).

3.2 Algoritmo

El objetivo del algoritmo es encontrar un conjuntomınimo de particiones que albergue a todas lasaplicaciones y cumpla con todas las restricciones.Como ya se dijo anteriormente, se trata de unproblema de asignacion de elementos a recursos.

Tras realizar un analisis de los posibles algoritmosa emplear, se decidio adaptar el algoritmo IteratedRegister Coalescing (IRC) [6].

3.2.1 Iterated Register Coalescing (IRC)

IRC es un algoritmo heurıstico que mantiene unacomplejidad de implementacion aceptable a la vezque proporciona unos resultados de buena calidad.IRC fue originalmente disenado para ser empleadoen el generador de codigo de los compiladores.Su objetivo era asignar las variables temporalesdel codigo intermedio a los registros hardware delprocesador. Se pueden observar muchas simili-tudes entre el problema de asignar variables a reg-istros y el de asignar aplicaciones a particiones:

• Asignar un conjunto de elementos a un con-junto mas pequeno de recursos. En IRCse asignan variables temporales a registrosmaquina. En nuestro caso, se asignan apli-caciones a particiones.

• Emplear el menor numero posible de recur-sos. Cuantos menos registros emplee el com-pilador, mejor ya que el numero de copiasde un registro a otro se reduce, y por tanto,se incrementa la velocidad de ejecucion. Del

mismo modo, cuantas menos particiones hayaen el sistema, menos cambios de contexto en-tre particiones, y por tanto, mayor sera la efi-ciencia del sistema.

• Elementos con recursos predeterminados.Por ejemplo, en la mayor parte de las arqui-tecturas hardware, las operaciones de comaflotante usan unos registros especialmente op-timizados para ellas. Por ello, el compiladordebe asignar las variables temporales impli-cadas en operaciones de coma flotante a di-chos registros. En el caso del particionado,una de las restricciones que se pueden dar esque una aplicacion debe ir en una particiondeterminada a priori.

• Elementos que comparten recursos. El codigointermedio se puede optimizar si se detectandos variables temporales que no estan activasal mismo tiempo. En estos casos, se puedeasignar a ambas variables el mismo registromaquina sin interferencias. La misma idea sepuede aplicar al tratar las restricciones quefuerzan al algoritmo a colocar un conjuntodado de aplicaciones en la misma particion.

No obstante, existen tambien algunas diferenciasque impiden la aplicacion inmediata del IRC alproblema del particionado:

• Conjunto de recursos finito. El numero deregistros disponibles en un procesador es limi-tado. El numero de particiones que se puedencrear es infinito, aunque se trata de manteneren todo momento el menor numero de parti-ciones posible.

• Solucion unica. IRC esta disenado para ofre-cer una unica solucion. El algoritmo de par-ticionado debe ser capaz de generar multiplessoluciones factibles porque es posible que elparticionado propuesto en un primer mo-mento sea rechazado por algun analisis pos-terior.

• Soluciones ordenadas. Como se ha dicho enel punto anterior, es necesario poder generarmultiples esquemas de particionado. No ob-stante, se debe ofrecer en cada momento elmejor resultado posible de aquellos que se hanencontrado.

3.2.2 Representacion del problema:Grafos coloreados

La herramienta matematica en la que se basa IRCes la teorıa de grafos. Un grafo es un conjunto de


Application A

Application CApplication D

Application B

Application E

Application F

1

Application G

1

Application H

2

Application I

Application A

Application CApplication D

Application B

Application E

Application H

2

Application F+I+G

1

(A) (B)

Partition 4Partition 2 Partition 3Partition 1

Application A Application H Application E Application D Application B

Partition 5

Application F Application I Application G

(C)

Figura 2: (A) Grafo inicial. (B) Grafo con las restricciones implıcitas aplicadas (C) Esquema de parti-cionado propuesto

objetos llamados vertices o nodos unidos por en-laces llamados aristas o arcos, que permiten rep-resentar relaciones binarias entre elementos de unconjunto. En particular, IRC emplea un caso es-pecial de etiquetado de grafos, llamado coloracionde vertices, donde se asignan etiquetas (o colores)a los vertices del grafo. Dicha asignacion de col-ores ha de ser tal que ningun vertice adyacentecomparta el mismo color.

El numero mınimo de colores que se pueden em-plear para colorear los vertices de un grafo se de-nomina numero cromatico y es un conocido prob-lema NP-Completo [5], en otras palabras, hastael momento, no se conocen algoritmos que resuel-van este problema en su caso general en tiempopolinomico. La aproximacion que se suele llevar acabo en esta clase de problemas es la utilizacion dealgoritmos heurısticos (como IRC). Esta clase dealgoritmos no buscan la solucion optima, sino quese conforman con encontrar soluciones aceptables.

La representacion del problema de particionado enun grafo coloreado serıa la siguiente:

• Los vertices representan una o mas aplica-ciones.

• Los colores asignados a cada vertice represen-tan las particiones donde debe ser ejecutada

la aplicacion.

• Las aristas entre vertices representa restric-ciones de tipo 1. Es decir, unen aplicacionesque no pueden ser ejecutadas en la mismaparticion.

Con esta representacion, el numero cromatico delgrafo coincide con el mınimo numero de parti-ciones necesarias para albergar todas las aplica-ciones.

3.2.3 Grafo inicial

A continuacion se muestra como funciona el algo-ritmo de generacion de particiones con un ejemplo.Por claridad se ha simplificado las restriccionesimplıcitas y los datos que se tienen en cuenta paragenerarlas ası como la informacion asociada a cadavertice. En la figura 2A se muestra el grafo ini-cial donde se representa la informacion que se harecibido de las entradas:

• Un conjunto de aplicaciones. Cada aplicacionindica el sistema operativo donde debe ejecu-tar, representado en el dibujo por el color dela bandera.

• Un conjunto restricciones explicitas:


– Las lıneas continuas indican restriccionesde tipo 1, es decir, unen aquellas aplica-ciones que no deben nunca ejecutar en lamisma particion.

– Las lıneas discontinuas representan re-stricciones del tipo 2, es decir, unen apli-caciones que deben ejecutar siempre enla misma particion.

– Los numeros en negrita a la izquierda decada aplicacion indican que dicha apli-cacion debe ser alojada en la particionindicada.

3.2.4 Restricciones implıcitas

El primer paso del algoritmo es generar las re-stricciones implıcitas. Las restricciones implıcitasse generan automaticamente (como se explica enla seccion 3.1.2). Pueden ser de cualquier tipo,aunque las que afectan al algoritmo del coloracionde vertices son las de tipo 1 y 2.

En este ejemplo son las siguientes:

• Aplicaciones con diferente sistema operativodeben ejecutar en particiones diferentes. Portanto, todas las aplicaciones con diferente sis-tema operativo tienen que estar relacionadascon una restriccion de tipo 1.

• Las aplicaciones que tienen predefinida lamisma particion deben ir en la misma par-ticion. Por tanto, las aplicaciones F y Gdeben estar unidas por una restriccion de tipo2.

Una vez generadas las restricciones implıcitas, elgrafo de la figura 2A se convierte en el mostradoen la figura 2B.

Es importante resaltar que el algoritmo de col-oracion de grafos trabaja unicamente con las re-stricciones de tipo 1. Las restricciones de tipo 2que en la figura 2A se muestran como lıneas dis-continuas, en realidad no indican adyacencia entredos vertices, sino que se emplean para indicar al al-goritmo que vertices pueden simplificarse y cualesno (ver seccion 3.2.5).

3.2.5 Transitividad de restricciones detipo 2

El segundo paso del algoritmo es la union delos vertices unidos por restricciones de tipo 2aprovechando la transitividad de estas restric-ciones.

Los vertices que estan relacionados con una re-striccion de tipo 2 se deben colorear con los mis-mos colores. Por otra parte, la restriccion de tipo 2

implica heredar las restricciones de tipo 1 del otrovertice de la relacion. De modo que dos verticesunidos por restricciones de tipo 2 tienen prohibidoel conjunto de colores que estan en uso por partede aquellos vertices con los que cualquiera de losdos vertices este relacionados a traves de una re-striccion de tipo 1.

Teniendo todo lo anterior en cuenta, se puede con-cluir que dos vertices relacionados con una re-striccion de tipo 2 se comportan como si fueranun unico vertice:

• cuyas restricciones de tipo 1 son la union delas restricciones de los dos vertices originales

• cuyos colores pre-asignados son la union delos colores pre-asignados de los vertices orig-inales.

En el grafo de la figura 2 los vertices F e I estanrelacionados por una restriccion 2 explıcitamentedada por el disenador. Por otra parte, los verticesF y G estan relacionados con una restriccion 2automaticamente generada en el paso anterior.

Aplicando lo anteriormente dicho, se puede crearun unico vertice union que representa a los verticesF, G e I juntos y que hereda sus restricciones detipo 1 ası como los colores que estos tuvieran pre-asignados. A continuacion se pueden eliminar losvertices F, G e I del grafo.

En este paso se deben simplificar todas las restric-ciones de tipo 2, pues en los pasos posteriores solopueden existir restricciones de tipo 1. Tras aplicareste paso al grafo inicial, el resultado es el que semuestra en la figura 2B.

3.2.6 Reduccion del grafo

El tercer paso del algoritmo es la reduccion delgrafo de los vertices que no estan pre-asignadosa un color. Los vertices pre-asignados (verticesH y F+I+G en el ejemplo) permanceran todo elrato en el grafo. El proceso consiste en extraerdel grafo el vertice de menor grado (numero dearistas), apilarlo en una pila auxiliar y eliminarsus aristas del grafo. Repetir el proceso hasta queno queden mas vertices, o bien, todos los verticesque queden en el grafo esten pre-asignados.

3.2.7 Coloracion de los vertices

El cuarto paso es la coloracion de los vertices.Para ello, se extraen los vertices de la pila, deuno en uno, y en orden inverso a como fueroninsertados (LIFO). A cada vertice extraıdo se leasigna un color teniendo en cuenta que no puedecoincidir con ninguno de los colores que usen losvertices adyacentes ya extraıdos.


XtratuM

LEON3 AtomLEON3 Atom

SafetyProtection

MPTAL

HMI

Linux

ComServer

Linux

Diagnostic

MPTAL

Diagnostic

MPTAL

SafetyProtection

MPTAL

Supervision

PaRTiKLe

Supervision

PaRTiKLe

Partition 5Partition 6 Partition 4 Partition 3

HMI ComServer Diagnostic Diagnostic SafetyProtection SafetyProtection Supervision Supervision

Partition 2 Partition 1 Partition 0

(A)

(B)

Figura 3: (A) Arquitectura del sistema de control Galileo (B) Esquema de particionado propuesto por laherramienta

Tambien hay que tener en cuenta que es posibleque un vertice puede ser coloreado con mas de uncolor. Para estos casos, se ha definido una funcionde afinidad. La mision de esta funcion es ordenar,de mayor a menor, la afinidad del vertice por elcolor. Cuanto mayor sea la afinidad del color,antes sera empleado para colorear el vertice. Loscriterios de afinidad no estan todavıa completa-mente estudiados y probablemente cambien segunavance el desarrollo. De momento, se emplean lossiguientes criterios:

• Periodos similares. Se prefiere aquella par-ticion que contenga aplicaciones con periodosde un rango similar al de la nueva aplicacion.

• Tiempo de computo. Se prefiere aquella par-ticion que tenga un menor tiempo de computoglobal.

De modo que cuando se encuentra un vertice conmultiples colores candidatos, estos se ordenan enfuncion de su afinidad al vertice. A continuacionse guarda el estado del grafo, ya que sera a partirde este punto de donde comenzara la busqueda desoluciones alternativas (ver seccion 3.2.9). Final-mente se selecciona el color mas afın y se continuacon el proceso.

El estado del grafo se almacena unicamente en el

primer caso de vertice con multiples colores can-didatos. El motivo es que todos los vertices conmultiples colores candidatos que se hallen a con-tinuacion pueden cambiar de candidatos o de dejarde ser vertices multicolor despues de modificar elcolor del primer vertice multicolor encontrado.

3.2.8 Generacion de soluciones

Teniendo en cuenta que los vertices representan auna o mas aplicaciones, y que los colores repre-sentan las particiones, el esquema de particionadocorresponderıa con el mostrado en la figura 2C.

3.2.9 Generacion de solucionesalternativas

Como ya se ha mencionado previamente, el es-quema de particionado propuesto puede ser rec-hazado en la etapa de validacion. Por este mo-tivo, es preciso que el algoritmo de particionadosea capaz de proporcionar mas de una solucionaceptable.

Para generar una solucion alternativa, se restaurael estado del grafo. Es decir, se vuelve a tenerel grafo y la pila auxiliar en el mismo estadoque se tenıa cuando se encontro el primer verticemulticolor. Por tanto, el primer vertice a ser col-oreado de nuevo es el primer vertice multicolor


que se encontro.

La diferencia en esta ocasion es que, en vez deseleccionar el color mas afın (el que se uso en lasolucion anterior), se emplea el segundo color masafin y se deshecha el primero. Si el vertice siguesiendo multicolor se guarda el estado del nuevografo. Si no, se elimina el estado guardado y seprocede a colorear el resto de vertices que quedenen la pila tal y como se describe en la seccion 3.2.7.

4 Caso de estudio: Galileo windturbine control

Galileo [20] el sistema de control distribuido em-pleado por Alstom Renewables en sus aerogener-adores. Se trata de un sistema de criticidadesmixtas, pues deben ejecutar componentes con req-uisitos de safety a la vez que otros componentesno-safety. Ademas, algunos de los componentestienen restricciones de tiempo real, mientras queotros no. Galileo, es por tanto, un claro de ejemplode un complejo sistema de control con elementosde diversa criticidad y requisitos.

En la figura 3 se muestra el particionado realizadoa mano por los ingenieros. El objetivo es mod-elar Galileo con la herramienta de particionadoautomatico de modo que el resultado coincida conel que los ingenieros han sugerido como idoneo.

4.1 Plataforma

En la figura 3 se muestra la arquitectura gen-eral de Galileo. La plataforma hardware es unentorno heterogeneo compuesto por procesadoresde arquitecturas Intel y SPARC. En particular,es un sistema multiprocesador multicore con 2procesadores de doble nucleo Intel Atom y dosprocesadores de tres nucleos LEON3 [1]. Laconexion logica entre los nucleos se realiza medi-ante TTNoC [13].

Las aplicaciones que deben ejecutar sobre estaplataforma hardware tienen diferentes diferentesniveles de criticidad, diferentes requisitos tempo-rales y diferentes sistemas operativos. Por ello,se ha optado por implementar un sistema parti-cionado empleando el hipervisor Xtratum. Lossistemas operativos que se emplean son: PaR-TIKLe (para Intel y SPARC), MPTAL (para Intely SPARC) y Linux (solo para Intel).

4.2 Aplicaciones

En este caso de estudio intervienen 5 aplicaciones,a saber:

• COM Server: Se encarga de interactuar con

sensores y actuadores conectados a una redEtherCAT y distribuir la informacion recolec-tada a HMI, Supervision y Safety Protection.Esta aplicacion, que no tiene requisitos espe-ciales de safety ni de tiempo real, debe eje-cutar bajo un sistema operativo Linux paraarquitectura Intel x86.

• HMI: Esta aplicacion se encarga de presentarinformacion al operador. Requiere ejecutarbajo Linux x86. No tiene requisitos especialesni de safety ni de tiempo real.

• Supervision: Contiene el algoritmo controly supervision en tiempo tiempo real de lasturbinas. No tiene requisitos de safety perosı de tiempo real. Ademas, hay una instanciade esta aplicacion para cada arquitectura, esdecir, debe ejecutar en un procesador LEONy en un procesador Atom. En ambos casosejecuta bajo PaRTIKLe.

• Safety Protection: Controla que losparametros de la turbina permanecenen niveles aceptables. Se trata de unaaplicacion con requisitos de safety. Por otraparte, al igual que Supervision, debe ejecutaruna instancia en LEON y otra en Atom. Enambos emplea MPTAL 1.

• Diagnostic. Es una aplicacion con requisitosde safety que se encarga, entre otras cosas,de controlar dos temporizadores de guarda.Debe existir una instancia de esta aplicacionen un procesador LEON y otra en uno In-tel. Se trata de una aplicacion que ejecutaen maquina desnuda con MPTAL en ambasarquitecturas.

Aquellas aplicaciones que deben estar en dos ar-quitecturas diferentes se consideran aplicacionesdiferentes. Ası por ejemplo, la aplicacion Safe-tyProtection se modela como las aplicaciones Safe-tyProtection (Intel) y SafetyProtection (SPARC).

4.3 Restricciones

Se debe indicar a la herramienta aquellos casosen los que una aplicacion requiere un familia deprocesadores en particular. De modo que las re-stricciones que habrıa que anadir son las sigu-ientes:

1MPTAL (MultiPARTES Abstraction Layer)ofrece servicios ARINC 653 P4 a traves de una APIcuyo objetivo es estandarizar el uso de sistemasparticionados en el proyecto MultiPARTES. Puedeejecutar en maquina desnuda o con la ayuda de unsistema operativo.


Supervision

Diagnostic

Diagnostic

SafetyProtection

SafetyProtection

HMI

ComServer

Supervision

Figura 4: Grafo inicial con las restricciones implıcitas generadas para el ejemplo de Galileo

• Aplicaciones que requieren ejecutar en proce-sadores de la familia Intel: Supervision (In-tel), Diagnostic (Intel), SafetyProtection (In-tel), HMI y ComServer.

• Aplicaciones que requieren ejecutar en proce-sadores de la familia SPARC: Supervision(SPARC), Diagnostic (SPARC), SafetyPro-tection (SPARC).

4.4 Grafo inicial y restricciones implıcitas

Una vez definidas las entradas, se ejecuta el al-goritmo mostrado en el apartado 3. La figura4 muestra como serıa el grafo despues de habergenerado el grafo inicial (seccion 3.2.3) y haberanadido las restricciones implıcitas (seccion 3.2.4).

Las lıneas discontinuas muestran las restriccionesde tipo 1 insertadas automaticamente debido ala familia de procesadores. Aquellas aplicacionesque deben ejecutar en LEON3 no pueden ser alo-jadas en particiones que contienen aplicacionespara Atom y viceversa.

Las lıneas continuas muestran las restricciones detipo 1 insertadas automaticamente debido la crit-icidad. Dos aplicaciones con diferente nivel decriticidad no pueden ser alojadas en la misma par-ticion. En la figura 3 se muestra un icono de excla-macion en aquellas aplicaciones que tienen difer-entes niveles de criticidad. Se puede observar quecada una de estas aplicaciones tienen prohibido irjunto a cualquier otra aplicacion.

Hay que tener en cuenta que, por ejemplo, Di-agnotic (para Intel) y SafetyProtection (paraSPARC) no pueden ejecutarse en la misma par-

ticion por dos motivos: diferente arquitecturay diferente nivel de criticidad. No obstante, siaparece una restriccion que une dos aplicacionesque ya estaban previamente unidas por una re-striccion del mismo tipo, esta no se repite.

4.5 Generacion del particionado deseado

Una vez que se acaba de ejecutar todo el algoritmomostrado en la apartado 3, el resultado es el sigu-iente el indicado en la figura 3. Como se puedecomprobar, la unica diferencia con el propuestoinicialmente por los ingenieros es que las aplica-ciones HMI y ComServer se han colocado en lamisma particion.

El motivo de esta diferencia es que no hay ningundato en los modelos de entrada que permita de-ducir que estas aplicaciones deben ir separadas.Por tanto, el algoritmo busca la solucion con elmenor numero posible de particiones.

No obstante, en caso de que se requiera que estasdos aplicaciones ejecuten en particiones separadas,basta con anadir una restriccion de tipo 1 relacio-nando ambas. Una vez hecho esto, si se vuelvea ejecutar el algoritmo, el particionado propuestosera identico al mostrado en la figura 3.

5 Conclusiones

En este artıculo se ha descrito el algoritmo em-pleado en la generacion automatica de esque-mas de particionado con restricciones implıcitasy explıcitas a partir de la informacion propor-cionada por los diferentes modelos de entrada. Ac-


tualmente, este algoritmo se esta probando y val-idando en tres casos de uso diferentes: sistema decontrol de turbinas eolicas, sistema de control deabordo del satelite UPMSAT2 y en sistemas devıdeo-vigilancia.

Como se dijo en la seccion 3, la generacion de es-quemas de particionado es solo uno de los tres sub-problemas principales a ser resueltos. Como tra-bajo futuro se incluye profundizar y mejorar losalgoritmos de planificacion y balanceo de carga deproceso del prototipo actual.

Agradecimientos

Este trabajo esta financiado parcialmente porfondos del proyecto FP7 STREP MultiPARTES,no. 287702 (www.multipartes.eu). Los autoresagradecen al consorcio de MultiPARTES su ayuday colaboracion. Este trabajo ha sido tambien par-cialmente financiado por el Ministerio de Edu-cacion, Cultura y Deporte a traves del proyectoHI-PARTES (High Integrity Partitioned embed-ded systems), TIN2011- 28567-C03-01 del PlanNacional de I+D+i.

Referencias

[1] Aeroflex Gaisler. LEON3-FT SPARC V8 Pro-cessor Datasheet and User’s Manual, AeroflexGaisler Technical Report, 2013.

[2] Alonso, A., Salazar, E., de Miguel, M.A.,A Toolset for the Development of Mixed-Criticality Partitioned Systems, in 2nd Work-shop on High-performance and Real-time Em-bedded Systems, 2014, Vienna, Austria

[3] ARINC: Avionics Application Software Stan-dard Interface ARINC Specification 653-1 (Oc-tober 2003)

[4] Burns A., Dobbing B. and Vardanega T.:Guide for the use of the Ada Ravenscar profilein high integrity systems. Ada Letters XXIV,1–74 (June 2004)

[5] Garey and Johnson, Computers and In-tractability: A Guide to the Theory of NP-Completeness. 1979. ISBN: 0-7167-1044-7.

[6] George L., Appel A.W.: Iterated register coa-lescing. TOPLAS 18(3), 300–324 (1996).

[7] ISO/IEC: ISO/IEC 8652:1995(E) /TC1(2000)/AMD1(2007): InformationTechnology - Programming Languages - Ada(2007)

[8] Gonzalez Harbour M., Gutierrez J.J., Palen-cia J.C., Drake, J.M.: ”MAST modeling and

analysis suite for real time applications”. In:Proceedings of 13th Euromicro Conference onReal-Time Systems,(June 2001).

[9] Masmano M., Ripoll I., Crespo A., Peiro S.:XtratuM for LEON3: an OpenSource Hy-pervisor for High-Integrity Systems. Embed-ded Real Time Software and Systems (ERTS22010), May 2010.

[10] MultiPARTES: Multi-cores Partitioningfor Trusted Embedded Systems, Available:www.multipartes.eu

[11] MultiPARTES project, ”Requirements Plat-form and Methodology Viewpoint”, Deliver-able D2.2, http://www.multipartes.eu.

[12] MultiPARTES project, ”Specification andModels of Platform”, Deliverable D5.1,http://www.multipartes.eu.

[13] Obermaisser, R.: Time-triggered commu-nication. CRC Press, Inc., 2011 ISBN9781439846612.

[14] OMG: Modeling and Analysis ofReal-Time Embedded Systems (2011),http://www.omg.org/spec/MARTE/, ver-sion 1.1

[15] OMG: Unified ModelingLanguage (UML) (2011),http://www.omg.org/spec/UML/2.4.1/,version 2.4.1

[16] Panunzio, Marco, and Tullio Vardanega.”Ada Ravenscar code archetypes forcomponent-based development.” ReliableSoftware Technologies–Ada-Europe 2012.Springer Berlin Heidelberg, 2012. 1-17.

[17] Peiro S., Masmano M., Ripoll I. and CrespoA. ”PaRTiKle OS, a replacement of the coreof RTLinux”, in Proc. of the Real-Time LinuxWorkshop, 2007.

[18] Salazar E., Alonso A., de Miguel M.A., de laPuente, J.A. ”A Model-Based Framework forDeveloping Real-Time Safety Ada Systems”.In H.B. Keller, et al (eds.), Reliable SoftwareTechnologies — Ada-Europe, LNCS 7896, pp.126–141. Springer-Verlag, 2013.

[19] Schmidt, Douglas C. ”Guest editor’s intro-duction: Model-driven engineering.” Com-puter 39.2 (2006): 0025-31.

[20] Trujillo, Salvador, Alfons Crespo, and Ale-jandro Alonso. ”MultiPARTES: Multicorevirtualization for Mixed-criticality Systems.”Digital System Design (DSD), 2013 Euromi-cro Conference on. IEEE, 2013.

Documents

Algoritmo para particionado autom atico de sistemas con … · 2014-09-11 · Algoritmo para particionado autom atico de sistemas con criticidad mixta Emilio Salazar1, Alejandro Alonso1