control de la ejecución en sistemas de criticidad mixta

ControldelaEjecuciónenSistemasdeCriticidad Mixta

A.Crespo,P.Balbastre,J.SimóUniversitatPolitècnicadeValència,(acrespo,patricia,jsimo)@ai2.upv.es

J.CoronelFentISS,([email protected])

Resumen

En sistemasdetiemporealy,engeneral,ensistemascríticos,hayunatendenciaenalzaenutilizar aplicacionescondiferentes niveles decriticidad.Lassolucionesbasadasenhipervisoressonuna formade implementarsistemasdecriticidadmixtayaqueproporcionanaislamientotemporalyespacial.Sinembargo,laejecuciónde una partición puede serafectadapor laejecuciónenotrosnúcleos,loqueseconocecomúnmentecomointerferencias,poniendoenpeligrolaejecucióneneltiempoespecificado.En esteartículoseintentacontribuirdandosolucionesrealistasaesteproblema.Seproponeunasolucióndecontroldelaplanificacióncondoscontroladoresalniveldelhipervisor.Unodeloscontroladoresestáorientadoalimitarelusoderecursoscompartidosatravésdelalimitaciónenelusodelosbusesenlosnúcleosnocríticos.Elotrocontroladormidelaactividaddelnúcleocríticoytomasdecisionessobrelaejecucióndelosnúcleosnocríticos.

Palabrasclave:Hipervisor,sistemasdecritici-dadmixta,controlretroalimentado.

1. Introducción

XXXVIII Jornadas de Automática

Ensistemasdetiemporealy,engeneral,ensis-temascríticos,hayunatendenciaenalzaenutili-zaraplicacionescondiferentesnivelesdecriticidaddondevarioscomponentescondiferentesrestric-cionestemporalesseintegranconjuntamenteenunamismaplataforma[7].Lasrazonesdetrásdeestatendenciasonprincipalmentenofuncionales:reducircostes,volumen,pesoypotenciaconsu-midaparadiferentessectorescomoeldelcontrolindustrial,aviónica,espacioyautomóvilporcitarsóloalgunos.Lascapacidadesdeprocesamientoquelossistemasmutiprocesadorempotradospue-denalcanzarpermiteunificarenlamismaplata-formahardwarecadavezmásfuncionalidadesyaplicaciones.Enamboscasos,hayunanecesidaddeintegracióndeaplicacionescríticasynocríti-cas.Estaintegraciónesconocidaactualmenteenlacomunidaddetiemporealcomosistemasdecri-

ticidadmixta[5].

Desdeelpuntodevistadelaarquitecturasoft-ware,hayunatendenciaenutilizartécnicasdevirtualizaciónparaproporcionaraislamientotem-poralyespacialalasarquitecturasparticionadas.Estatécnicaseutilizóporprimeravezenelsectordelaaviónica[17]yseextendióposteriormentealsectorespacial[18].Elsoportedevirtualizacióndelasparticionesesproporcionadaporelhipervisor.Loshipervisoressoncapasdesoftwarequeapro-vechanlasfuncionalidadesdelhardwareparaes-tablecerentornosdeejecuciónindependientes.Es-tatendenciasehaidoextendiendoyactualmentelamayoríadelosprocesadoresofrecensoportedevirtualizaciónañadiendounnivelmásalmododeoperacióndelprocesador.

Lassolucionesbasadasenhipervisoressonunafor-madeimplementarsistemasdecriticidadmixta,especialmenteensistemasmultinúcleo.Lasprin-cipalespropiedadesdelhipervisortienequeverconelaislamientotemporalyespacialdelasparti-cionessoftwarequeseejecutanporencimadelhi-pervisor.Unaparticiónsedefinecomounentornodeejecuciónquecontieneunaaplicaciónysupro-piosistemaoperativoejecutándoseensuespaciodememoriapropio.Losmecanismosdelhipervisorproporcionanserviciosparavirtualizarlosrecur-soshardwarealasparticiones.ElhipervisorXtra-tuM[9]esunhipervisorbare-metalparasistemasempotradosdesarrolladoenvariosproyectoseuro-peos[16][10]yseestáutilizandoactualmenteenvariosmisionesenelsectorespacial.

Unosdelospuntoscrucialesenlossistemascríti-cosmulti-núcleoeselaislamientotemporal.Aesterespecto,elhipervisorpuedegarantizarrecursostemporalesexactosypredeciblesalasparticiones.Sinembargo,laejecucióndeunaparticiónpue-deserafectadaporlaejecuciónenotrosnúcleos,loqueseconocecomúnmentecomointerferencias.Esteproblema,debidoalusoderecursoscompar-tidos,puedeafectaralaejecucióndeunaparti-cióncríticaponiendoenpeligrolaejecucióneneltiempoespecificado.Portanto,estasinterferen-ciasintroducenunfactordeimpredecibilidadenlaejecucióndeunatareacríticaynopermitees-timarunlímitesuperioreneltiempodeejecución

906

https://doi.org/10.17979/spudc.9788497497749.0906

https://creativecommons.org/licenses/by-nc-sa/4.0/deed.es

de peor caso (WCET), introduciendo anomalíastemporales [14].

En este artículo, nos centraremos en el control dela ejecución de sistemas particionados de critici-dad mixta sobre un hipervisor. Se propone unasolución de control de la planificación con dos con-troladores al nivel del hipervisor. el resto del ar-tículo se organiza de la siguiente forma: el apar-tado 2 cuenta el estado del arte en este área. Elapartado 3 describe los contadores de prestacionesutilizados por el hipervisor para definir el control.En el apartado 5 se presentan los objetivos delcontrolador y los mecanismos utilizados. El apar-tado 6 describe el ámbito de ejecución de los con-troladores. El apartado 7 presenta los resultadosde los experimentos realizados sobre una platafor-ma multi núcleo. Finalmente, en el apartado 8 secomentan las conclusiones y el trabajo futuro.

2. Estado del arte

Hay muchos trabajos que han abordado el proble-ma de los recursos compartidos en sistemas multinúcleo. En [1], se analiza el impacto de los busescompartidos, caches y otros recursos y sobre pre-dicción de prestaciones.

En [6], se propone un protocolo de bus basado enTDMA junto con un segundo protocolo dinámicoque facilita la integración de sistemas de criticidadmixta libre de interferencias.

En [12] se presenta un controlador de acceso arecursos compartidos por las tareas en ejecución.En [20], se define un mecanismo de protección dememoria que regula los accesos a la misma. En[13], se propone un controlador distribuido que pa-ra las tareas de baja criticidad cada vez que de-tecta que su ejecución puede hacer perder plazosa tareas de alta criticidad. En [19] se propone unainfraestructura de planificación que utiliza conta-dores de prestaciones para calcular la latencia me-dia de acceso a memoria.

Por otro lado, las técnicas de control y planifica-ción controlan el uso de los recursos de una plata-forma computacional por medio de controladoresque actúan sobre las tareas en ejecución. Se handefinido muchas estrategias en este sentido, entreotras: optimización del periodo [2], memoria comorecurso compartido [15], ajuste de los periodos delas tareas para minimizar el hiperperiodo [3].

3. Contadores de monitorizaciónde prestaciones

Los procesadores actuales proporcionan mecanis-mos para monitorizar el funcionamiento del sis-

tema, ofreciendo contadores de eventos que pue-den ser leídos por las aplicaciones o los sistemasoperativos. El monitor de prestaciones (Perfor-mance Monitor, PM) es un dispositivo que pro-porciona este mecanismo en el procesador mul-ti núcleo PowerPC T2080 en la placa NXP Qo-rIQ T2080RDB [11]. El procesador T2080 incluyecuatro núcleos de 64 bits e6500. El núcleo e6500incluye un PM que proporciona un conjunto dePMCs (contadores de monitorización de prestacio-nes) para definir, habilitar y contar ciertas condi-ciones que pueden disparar la interrupción del mo-nitor de prestaciones. Cada core puede configurarhasta seis contadores de 32 bits para almacenareventos específicos.

Adicionalmente, el T2080 proporciona extensionesde hardware para virtualización y define un modohipervisor que permite la ejecución del hipervisor.XatratuM ha sido portado a este procesador y pro-porciona virtualización completa, manejando losPMCs para almacenar eventos concretos durantela ejecución. Utilizando el PM, XtratuM propor-ciona la habilidad de contar eventos predefinidospor núcleo asociados con operaciones específicos,como ciclos de procesador, instrucciones ejecuta-das, pérdidas de chace L1 y L2, accesos a bus dedatos e instrucciones, etc.

Para cada contador se puede definir un umbralpara disparar los eventos cuando un cierto valor esalcanzado. Los contadores pueden ser habilitadoso deshabilitados según la necesidad del hipervisoro de las aplicaciones.

4. Planificación de hipervisor

XtratuM es un hipervisor bare-metal específi-camente diseñado para sistemas empotrados detiempo real, ofreciendo para-virtualización o vir-tualización completa dependiendo del soporte delhardware.

Xtratum define el concepto de CPU (núcleo) vir-tual (vCPU), las cuales son abstracciones que mo-delan el comportamiento de la CPU y pueden serasignadas a las CPUs reales. XtratuM abstrae tan-tas vCPUS como núcleos físicos existan. Las par-ticiones pueden ser mono núcleo o multi núcleo(utiiizan una o varias vCPUs). La asignación devCPUS a CPUs se especifica en el fichero de con-figuración donde se define el sistema completo:hardware, dispositivos, planificación temporal, ca-nales de comunicación, etc.

Una partición puede ser una aplicación compila-da para ejecutarse sobre máquina desnuda, unaaplicación de tiempo real con su propio sistemaoperativo de tiempo real o una aplicación ejecu-tándose sobre un sistema operativo de propósito


907

general.Lasaplicaciones multinúcleorequierenunsistemaoperativoSMPyasignarvariasCPUsalapartición.

Laarquitecturasoftwaredeunsistemaparticio-nadomultinúcleosemuestraenlaFigura1.Enlafigurasemuestraunsistemaintegradopor5particionesmononúcleoyunaparticiónmultinú-cleo.Tambiénsemuestralaasignacióndenúcleosvirtualesanúcleosreales.P0yP1seasignanalaCPU0,P3yP4alaCPU1,P5alaCPU2ylasdosvCPUsdeP6alasCPU2yCPU3respectivamen-te.TodaslastareasdeunaparticiónseejecutanensuCPUasignada.LaparticiónSMPplanificainternamentequétareasseasignanacadavCPUy,enconsecuencia,enquéCPUrealseejecutan.

Figura1:Arquitecturaparticionadaenplataformamultinúcleo

Lageneracióndelplancíclicodebeconsiderarelimpactodelosrecursoscompartidos(accesosabus,cachesL2,memoria,etc)enlaejecucióndelastareas.EnlaherramientaXoncrete[4]seim-plementanestastécnicasdeplanificación.En[8],sedefineunametodologíaparagenerarplanescí-clicosensistemasmultinúcleodecriticidadmixta.

Elnúmerodenúcleossedeterminacalculandolautilizacióndecadaparticiónyasignandolaspar-ticionesalosnúcleos mediantetécnicasdebin-packing.

Elplangeneradosecaraterizapor:

TodaslasparticionescríticasseasignanaunsubconjuntodenúcleosllamadosCC.

LasparticionesnocríticasseasignanaotrosubconjuntollamadoNCC.

Cadatareaenunaparticióntieneasignadosupropioslotenunnúcleo.

Seconsideraeltiempodeejecucióndepeorcasoincrementadoporunfactorquetieneencuentalainterferenciaentrenúcleos.

Enesteartículoseasumequelasparticionescríti-casestánalojadasenunsolonúcleomientrasquelasnocríticaspuedenestarenvariosnúcleos.Sinembargo,elesquemadecontrolpropuestoescom-patibleconlaejecucióndeparticionesnocríticasenelnúcleocríticoCC.ComotrabajofuturoseconsideraránmásdeunCC.

5. Controladoresdeejecución

Elobjetivodeloscontroladoreseslimitarlain-terferenciaproducidaporlasaplicacionesdelosnúcleosnocríticos(NCP)sobreelcrítico(CP).

Lasaplicacionescríticasejecutándoseenlosnú-cleoscríticostienenqueasegurarelcumplimientodelasrestriccionestemporalesy,enconsecuencia,loscontroladoresnopuedenactuardirectamentesobresuejecución.Sinembargo,losnúcleosnocríticospuedensuspendersuejecucióndurantelosintervalosenquesuejecuciónconprometalasapli-cacionescríticas.

Lafigura 2muestraelesquemadecontrolpro-puesto.

Figura2:Esquemadecontrol

Inicialmente,seconsideraran2núcleos.ElC_0ejecutapartitionescríticasyelC_1


lasaplicacio-nesnocríticas.Elnúcleonocrítico(NCC)leelaspeticionesdebusylascomparaconunareferenciadeterminada.Cuandolalecturaexcedelareferen-cia,setomalaacciónsobreelNCC.Encambio,elnúcleocríticoleeloscicloseinstruccionesdelaunidaddeprestacionesycalculalarelacióndeci-closporinstruccion(CPI)ysiexcedelareferencia,setomaunaacciónsobreelnúcleonocrítico.

Amboscontroladoressonbasadoseneventosconelfindelimitarlasejecucionesdelhipervisoryporlotantoreducirlasobrecargadelsistema.Es-tosepuedeconseguirdebidoaqueloscontadoresdeprestacionessepuedenconfigurarparagenerarunainterrupciónsobreelnúcleocorrespondientecuandosealcanzaunvalorlimitequeeslarefe-rencia.

908

6. Ámbitodeactuacióndeloscontroladores

Seasume,porsimplicidad,quesedisponede2núcleosy4particiones.P0yP1seconsiderancrí-ticasyP2yP3nocríticas.

Laimplementacióndeloscontroladoresserealizaaniveldehipervisor.Paradefinirsucomporta-mientosedefinenunconjuntoderequisitos.

Req1 :Siunnúcleocríticoestáinactivo,sucon-troladorestadeshabilitado.

Req2 :Alempezarlaejecucióndeunaranuradetiempodeunaparticióncrítica,seactivanamboscontroladores

Req3 :Cuandoelcontroladordelnúcleocríticotomalaaccióndesuspenderlaactividaddelnocrítico,laejecucióndelaparticiónactualyfuturassesuspenden.

Req4 :Cuandoelcontroladordelnúcleonocríti-cotomalaaccióndesuspenderse,laejecucióndelaparticiónactualsesuspendehastaquesereanudeexternamente.

Req5 :Cuandounaparticióncríticafinalizasuejecución,loscontroladoressedeshabilitanysereanudalaactividadsuspendidaenlosnú-cleosnocríticos.

Req6 :Lascomnicacionesentrenúcleosserea-lizanmedianteinterrrupcionesentrenúcleos(IPIs).

Req7 :Lasdecisionesyaccionesatomarhandesersimplesconelfindereducirlasobrecargadelhipervisor.

Req8 :Loscontroladoresestaránbasadoseneventosconelfindeacotarelnúmerodein-terrupciones.

Enconclusión,elámbitodeloscontroladoresdenúcleocríticoserálaranuradetiempodesueje-cución.Loscontroladoresdelosnúcleonocríticosseráelmismoqueeldelanterior.

Lafigura3muestraunposibleescenariodeejecu-ciónyactivacióndeloscontroladores.Laevolu-cióndeloscontadoresdeprestacionessemuestracomoejemploenlafigura.

Durantelainicializacióndelhipervisor,seiden-tificanlosnúcleosdisponiblesysecreaunhilodeejecucióninternoparacadanúcleo(HT0andHT1).Ent0,HTOdetectaeliniciodeP0eidenti-fica(definidoenlaconfiguración)queescríticayhabilitaloscontroladoresdefiniendolosvaloresdereferenciadeestos.Almismotiempo,ent0,HT1

Figura3:Controllerscope

empiezalaejecucióndeP2recibiendounaIPIdeC_0queindicaquelohabilita.Enelintervalo[t0,t

i1],HT0recibevariasinterrupcionesdelcon-

tadordeinstruccionesycalculaelvalordelCPI.Cuandoestevalorseasuperioralareferenciasus-penderálaactividaddelC_1(ti1).

Ent1,P0terminayenvíaunaIPIaC_1paraquereanudesuejecución.Enti2,comoconsecuenciadelainterrupciónydelcálculodelPCI,sesuspendeelC_1.

Ent2,HT0terminayenvíalaIPIparaqueC_1reanudelaejecución.HT0leelasiguienteranu-radetiempoydetectaqueenelinstantet3seiniciará.Delamismamanera,laacciónenti3essuspender,mientrasqueenti4,C_1seautosus-pende.

Elescenarioanteriorsepuedeextenderamultiplesnúcleosnocríticos.Cadaunodeéstostienesupropiocontroladorlocal.Laaccióntomadaporelcríticodesuspenderlaactividadafectaatodoslosnocríticos.Asimismo,laaccióndereanudarlaejecuciónesparatodosellos.

Lafigura4muestraelesquemadecontroladoresparamúltiplesnúcleosnocríticos.


Figura4:Esquemacontroladoresparamúltiplesnúcleosnocríticos

909

7. Experimentación

En esta sección se detallan los escenarios eva-luados y la influencia de los controladores. Des-pués de un detallado análisis de los contado-res de prestaciones, se han seleccionado 3 even-tos para la implementación. Estos eventos son:PME_PROCESSOR_CYCLES que cuenta el nú-mero de ciclos, PME_INSTR_COMPLETEDque cuenta el número de instrucciones ejecutadasy BIU_MASTER_REQUESTS que indica el nú-mero de peticiones de acceso a bus. Los eventospueden contar cuando el procesador está en modousuario, núcleo o hipervisor.

Estos escenarios se han ejecutado en la plataformaT2080 con una partición crítica (CPart) y de 0 a3 particiones no críticas en los otros núcleos. Lasparticiones no críticas se consideran que van a in-terferir en la crítica y se identifican como dummys.El solapamiento entre la crítica y las no críticas va-ría en los experimentos con el fin de mostrar dis-tintas situaciones y las acciones tomadas. El obje-tivo es medir el tiempo de respuesta de la particióncrítica comparando su ejecución de forma aisladacon su ejecución cuando hay otros núcleos en eje-cución. Se han definido cuatro escenarios: SC1 loscontroladores no están activos, SC2 utiliza contro-ladores locales, SC3 usa el controlador del núcleocrítico y SC4 utiliza ambos tipos. En las gráficasse identifican las gráficas mediante el número departiciones (dummy) no criticas en ejeución (n-D)y el intervalo de tiempo en el que se ejecutan.

7.1. Evaluación de escenarios

La figura 5 muestra la ejecución de CPart en to-das las situaciones. El eje X representa el time-po en milisegundos (aunque se leen los ciclos delprocesador) mientras que el eje Y presenta las ins-trucciones ejecutadas.

En esta situación, CPart termina su ejecucióndespues de 278ms si no hay interferencia. Cuandose ejecuta con 1,2 y 3 particioens en otros núcleos,su tiempo de ejecución es 409, 591 y 802 milise-gundos, respectivamente.

La figura 6 muestra lo mismo que lo anterior perocon los controladores locales de los núcleos no crí-ticos activados. La referencia puesta al C_1 cuan-do se ejecuta 1 partición no crítica no es alcanzadapor lo que se ejecuta sin suspensión. Cuando se eje-cutan 2 particiones, C1 y C2 se suspenden en losinstantes 426 y 477 ms, respectivamente. Cuandoson 3 no críticas, las suspensiones se producen enlos instantes 413, 426 and 478 ms, respectivamen-te.

La figura 7 muestra la ejecución del escenario SC3

0

5000

10000

15000

20000

25000

0 100 200 300 400 500 600 700 800

Num

ber o

f Ins

tructi

ons (

103 )

Time (ms)

Scenario 1

Inst-0DInst-1DInst-2DInst-3D

Figura 5: Todos los controladores están desactiva-dos.

0

5000

10000

15000

20000

25000

0 100 200 300 400 500 600

Num

ber o

f Ins

tructi

ons (

103 )

Time (ms)

Scenario 2


Figura 6: Los controladores locales están activados

con el controlador del núcleo crítico activado. Eneste caso, en el instante 205 ms suspende la activi-dad de C1 cuando sólo hay otro núcleo activo, en245 ms cuando hay dos y en 252 ms cuando haytres. En este caso, la suspensión es de todos losnúcleos no críticos.

0

5000

10000

15000

20000

25000

0 50 100 150 200 250 300 350 400 450

Num

ber o

f Ins

tructi

ons (

103 )

Time (ms)

Scenario 3


Figura 7: El Controlador crítico está activado

La figura 8 corresponde con el escenario SC4. Eneste caso, también es el controlador del núcleo crí-tico el que toma la decisión antes de los locales.En 206, 130 y 122 ms, se suspenden cuando hay1, 2 o 3 núcleos no activos.


910

0

5000

10000

15000

20000

25000

0 50 100 150 200 250 300 350 400 450

Num

ber o

f Ins

tructi

ons (

103 )

Time (ms)

Scenario 4


Figura 8: El controlador crítico y los locales acti-vados

La conclusión de esta experimentación es que esposible controlar la ejecución de las actividadescríticas en un sistema multi-núcleo. No obstante,es necesaria una identificación de estas activida-des que permita determinar los parámetros apro-piados de referencia para los controladores.

8. Conclusiones

En este artículo se ha propuesto un controladorimplementado a nivel del hipervisor para contro-lar la ejecución de aplicaciones críticas en una pla-taforma multi núcleo. Se ha definido también elámbito y el esquema del controlador, siendo esteefectivo sólo cuando se están ejecutando las apli-caciones críticas. Las acciones de control sobre lasaplicaciones críticas son simples: suspender la eje-cución de los núcleos dedicados a las aplicacionesno críticas. Esto es debido a que las acciones a to-mar por el hipervisor deben ser extremadamentesencillas de cara a facilitar una futura certifica-ción y a evitar decisiones complejas que puedanincrementar la sobrecarga de tiempo de ejecución.

El trabajo futuro se centra en el ajuste del contro-lador y en cómo los parámetros de las particionespueden tenerse en cuenta en el fichero de confi-guración del sistema para permitir al hipervisordefinir las referencias más adecuadas para los con-troladores.

Agradecimientos

Este trabajo ha sido desarrollado en el marco delos proyectos de investigación M2C2 (TIN2014-56158-C4-01/02) y PROMETEOII/2014/031 (Ge-neralitat Valenciana).

Referencias

[1] A. Abel and et al. Impact of resource sharingon performance and performance prediction:A survey. In Proc. 24th Int. Conf CONCUR

2013, Buenos Aires, Argentina, Aug. 27-30.,pages 25–43, 2013.

[2] E. Bini and M. D. Natale. Optimal taskrate selection in fixed priority systems. InProceedings of the 26th IEEE Real-TimeSystems Symposium (RTSS 2005), 6-8 Dec.2005, Miami, FL, USA, pages 399–409, 2005.

[3] V. Brocal, P. Balbastre, R. Ballester,and I. Ripoll. Task period selection tominimize hyperperiod. In IEEE 16thConference on Emerging Technologies &Factory Automation, ETFA 2011, Toulouse,France, Sept. 5-9, 2011, pages 1–4, 2011.

[4] V. Brocal, R. Masmano, I. Ripoll, A. Cres-po, and P. Balbastre. Xoncrete: a schedu-ling tool for partitioned real-time systems. InEmbedded Real-Time Software and Systems,2010.

[5] A. Burns and R. I. Davis. Mixed criticalitysystems - a review, Ed. 2017. Univ. York.Internal Report.

[6] B. Cilku, A. Crespo, P. Puschner, J. Co-ronel, and S. Peiro. A tdma-based ar-bitration scheme for mixed-criticality mul-ticore platforms. In Int. Conf. onEvent-based Control, Communication andSignal Processing (EBCCSP), pp: 17-19,2015. Krakow. Poland, 2015.

[7] E. Commision. Workshop on MixedCriticality Systems, 2012. Brussels. cor-dis.europa.eu/fp7/ict/computing/homeen.html.

[8] A. Crespo, P. Balbastre, J. Simo, and P. Al-bertos. Static scheduling generation for mul-ticore partitioned systems. In Lecture Notesin Electrical Engineering. Vol. 376., pages511–522, 2016. Int. Conf. on InformationScience and Applications, ICISA 2016, HoChi Min, Vietnam, Feb 2016.

[9] A. Crespo, I. Ripoll, S. Peiró, and R. Mas-mano. Partitioned embedded architecture ba-sed on hypervisor: Then XtratuM approach.In EDCC, pages 67–72, 2010.

[10] DREAMS. Distributed real-time architecturefor mixed criticality systems, 2013. EU FP7-ICT-610640 2013-17.

[11] I. Freescale Semiconductors. E6500rm, e6500core reference manual - reference manual,Mon Jun 9 19:06:06 2014.

[12] S. Girbal, X. Jean, J. L. Rhun, D. Gracia Pé-rez, and M. Gatti. Deterministic platform


911

software for hard real-time systems usingmulti-core cots. In 34th Digital AvionicsSystems Conference (DASC’2015), Prague,Czech Republic, 2015. Thales Research &Technology.

[13] A. Kritikakou, C. Rochange, M. Faugère,C. Pagetti, M. Roy, S. Girbal, and D. Gra-cia Pérez. Distributed run-time WCETcontroller for concurrent critical tasks inmixed-critical systems. In 22nd InternationalConference on Real-Time Networks andSystems, RTNS 2014, Versaille, France,October 8-10, 2014, page 139, 2014.

[14] T. Lundqvist and P. Stenström. Timinganomalies in dynamically scheduled micro-processors. In IEEE Real-Time SystemsSymposium, pages 12–21, 1999.

[15] A. Marchand, P. Balbastre, I. Ripoll, R. Mas-mano, and A. Crespo. Memory resour-ce management for real-time systems. In19th Euromicro Conf. on Real-Time Systems,ECRTS’07, 4-6 July 2007, Pisa, Italy, pages201–210, 2007.

[16] MultiPARTES. Multi-cores partitioning fortrusted embedded systems, 2011. EU FP7-ICT-287702 2011-14.

[17] J. Rushby. Partitioning in avionics architec-tures: Requirements, mechanisms, and assu-rance, 1999.

[18] J. Windsor and K. Hjortnaes. Time andspace partitioning in spacecraft avionics.Space Mission Challenges for InformationTechnology, 0:13–20, 2009.

[19] Y. Ye, R. West, J. Zhang, and Z. Cheng. MA-RACAS: A real-time multicore VCPU sche-duling framework. In 2016 IEEE Real-TimeSystems Symposium, RTSS 2016, Porto,Portugal, November 29 - December 2, 2016,pages 179–190, 2016.

[20] H. Yun, G. Yao, R. Pellizzoni, M. Caccamo,and L. Sha. Memguard: Memory bandwidthreservation system for efficient performanceisolation in multi-core platforms. In 19thIEEE Real-Time and Embedded Technologyand Applications Symposium, RTAS 2013,Philadelphia, PA, USA, April 9-11, 2013, pa-ges 55–64, 2013.


912

control de la ejecución en sistemas de criticidad mixta

Documents