Building a Generic (cross-domains) Basic Software on top of the XtratuM hypervisor

Transcription

1 Building a Generic (cross-domains) Basic Sofware on op of he Xrau hypervisor Jean-Jacques ETGE (1), Julien GALIZZI (1), Paul ARBERET (1), Bernard SANCHEZ (2), Jonahan PATY (2), Gilles SAINT-AUBIN (3), ikael DESCHAPS (3) (1) (2) (3) CNES - Cenre Spaial de Toulouse 18, avenue Edouard Belin TOULOUSE Cedex 9 - France Coninenal Engineering Services France - 1 avenue Paul Ourliac - BP Toulouse Cedex 1 - France Inerechnique / Zodiac Aerospace 61, rue Pierre Curie BP Plaisir Cedex - France Keywords : hypervisor, ime & space pariioning, middleware, service oriened archiecure (SOA), qualiy of service (QoS), basic sofware, monioring & conrol 1- INTRODUCTION Based on he lessons learn of he aeronauical domain inheried from he [ARINC653] sandard deploymen, he CNES is currenly working, since 2008, on he definiion and he developmen of a new ype of framework for embedded sofware developmen. This framework, which is known in he space domain as LVCUGEN, consiss in : - a se of generic sofware building blocks providing a se of sandard general purpose (middleware) services, compaible wih he monioring & conrol operaions expeced by he applicable sandard in space (refer o [PUS]) - an innovaive middleware echnology : o capable o ensure he qualiy of service expeced by he clien applicaions o highly aking benefi of ime & space pariioning propery, inheried from he [ARINC653] sandard, and ensured by he Xrau hypervisor o highly de-coupled from monioring & conrol services and proocols o highly de-coupled from hardware arges implemenaion An inernal evaluaion of he framework, performed in 2010, successfully demonsraed a TRL4/5 mauriy level on a single core LEON archiecure, fully compaible wih an operaional deploymen on a science payload for a fuure space observaion saellie. This evaluaion phase demonsraed also ha his framework mees he argeed end-users expecaions, in erms of increased independence beween he inernal funcions of any embedded sofware, and also beween sofware and hardware componens, wih very posiive impacs on developmen cycles and inegraion effors. Bu his evaluaion showed also ha he saellies marke will no probably be able o suppor alone he indusrialisaion coss of his framework, his siuaion being engraved by he emergence of muli-cores archiecures. In his difficul funding conex, he CNES decided in 2011 o impulse a long erms iniiaive wih several major french suppliers of space, aerospace and auomoive domains, wih he primary objecive o exend he business model of his framework, enabling he emergence of compeiive and perennial echnology providers. Direcly inspiring from he [AUTOSAR] business model, his iniiaive consiss in giving he opporuniy o hese new end-users o influence he curren definiion of he sofware building blocks consiuing he framework, while enabling an open compeiion beween providers of his new echnology. The roadmap currenly envisioned for he developmen of his cross-domains framework relies upon four seps : - assessmen of he LVCUGEN framework by suppliers from oher domains han space, in he conex of single core archiecures - pre-developmen of a generic (cross-domains) framework by hybridizaion of LVCUGEN framework wih inpus from oher domains han space, in he conex of single core archiecures - exension of he generic framework capabiliies o muli-cores archiecures - indusrialisaion of he generic (cross-domains) framework and pre-qualificaion vs a cross-domains qualificaion baseline, in he conex of single core and muli-cores archiecures The presen aricle aims a presening he preliminary resuls of feasibiliy sudies launched in 2011 by Inerechnique / Zodiac Aerospace (aeronauical use case) and Coninenal Engineering Services (auomoive use case). These aciviies, which conribue o he firs sep, have been covered by an inernal CNES budge dedicaed o LVCUGEN framework valorisaion.

2 2/10 2- THE LVCUGEN FRAEWORK (CNES) The LVCUGEN framework is he resul of he combined exploraion of several key echnologies described hereafer. a. Time & space pariioning (TSP) The TSP propery is ensured by a dedicaed sofware building block ensuring he fundamenal [ARINC653] principles : he Xrau hypervisor. The echnical descripion of he Xrau hypervisor, which can be found in [Xrau], is ou of he scope of he presen aricle, ha inends o focus more on he raionales ha lead CNES o push for he emergence of such an hypervisor echnology for embedded applicaions and also on he consequences of his echnology on any sofware archiecure, in which i is deployed. Taking profi of he lessons learn of aeronauical domain, he CNES decided, in 2008, o fund he developmen of a new hypervisor based echnology for single core LEON archiecures, because his echnology is well known as a very efficien soluion enabling o opimize he balance beween kernel adapabiliy o specific end-users needs (ie choice of he gues OS, possibiliy o add specific services, easy adapaion o hardware) and simpliciy of he kernel design. In his paricular conex, he sysemaic research of he mos simple design has been considered as an essenial objecive o be me by he Xrau hypervisor, his propery enabling in paricular o ease he kernel deerminism demonsraions, opimize memory and CPU fooprins of he kernel and reduce kernel qualificaion coss, which were considered very early as criical objecives of he LVCUGEN projec. Bu he side effecs of his echnological choice are, in comparison o a more radiional microkernel : - he very low level of services provided by he kernel - he rejecion of I/Os managemen ouside he kernel These wo side effecs implicily raise he quesion, a archiecure level, of implemening medium level services (ie middleware services), managing or no I/Os, inside pariions, wih a significan probabiliy ha several pariions need exacly he same se of hese medium level services. b. I/Os virualisaion The need for an I/Os virualisaion echnology is he firs direc consequence of he previous poin, in he sense ha, in an hypervisor based archiecure, mos of he hardware componens ouside he CPU core are considered as pure I/O devices, and mus be consequenly managed a pariion level. This applies for example o non volaile memory conrollers, I/O conrollers (eg SPW, 1553, ) and specialised hardware devices (eg emperaure & inrush curren monioring probes, ). In his conex, decision has been made in 2009 o define a sandard soluion for I/Os virualisaion inside pariions, which consised in defining a sandard SW/SW inerface (named SSIS in he following) beween I/Os drivers and medium level services ha are supposed o use hem. The second consequence of he previous poin is he fac ha, in a TSP based archiecure, several pariions mus be able o share he same I/Os wih a full guaranee of QoS. In he frame of he LVCUGEN projec, his raised he addiional need for a deerminisic soluion for QoS managemen of shared I/Os, since LVCUGEN projec hypohesis was ha he framework should be fully compaible wih I/O devices ha wouldn ensure inrinsically his QoS by hemselves. In his conex, he oher decision made in 2009 has been o develop a deerminisic I/O Scheduler, enabling o manage shared I/Os wih a guaraneed QoS. The main role of his I/O Scheduler is o manage, in a deerminisic way, a configurable se of RX and TX sequences, eiher in WAIT mode (for synchronous exchanges) or NO_WAIT mode (for asynchronous exchanges), and o ensure he rouing of frames beween he I/O devices and he local RX/TX buffers of an I/O Server pariion, inerface wih he I/O devices being, as explained above, ensured hrough I/O drivers compaible wih SSIS. In his conex, I/O daa managed by he I/O Server pariion can be accessed by any clien pariion hrough he iner-pariion communicaion service provided by he Xrau hypervisor. The scheduling plan execued by he I/O Scheduler has o be saically deermined by he plaform inegraor, generally wih he help of he Xoncree ool (see [Xoncree]), according o he need of he hosed applicaions in erms of I/O ypes, maximum frames sizes, maximum daaflow raes and maximum laencies. Deerminism of he I/Os scheduling plan, and consequenly QoS guaranee o all he clien pariions, is consequenly ensured by he fac ha he scheduling plan of he I/O Server pariion is perfecly known (propery ensured by Xrau) and he duraion of each sequence is se equal o is WCET (propery o be ensured by he plaform inegraor) and ha a sequence is no considered as finished unil is duraion has no elapsed (propery ensured by he I/O scheduler). c. General Purpose iddleware (Basic Sofware) The fac ha he LVCUGEN archiecure is based upon a compuing plaform hosing several pariions leads o he need o define a se of Common Services operaing a compuing plaform level : - shared I/Os managemen

3 3/10 - power managemen - ON/OFF managemen - Reses managemen - odes managemen - HW & SW monioring managemen - Buil-in-ess managemen - Warning managemen - Failures & errors managemen - Non Volaile emory managemen - Sofware uploads managemen - Sofware configuraion conrol managemen - Insrumenaion service managemen In order o ensure porabiliy of he framework beween he projecs, decision has been made in 2009 o define a services oriened archiecure (SOA) enabling o implemen hese services independenly of he high level proocols and services ha enable he monioring & conrol of he compuing plaform. The raionale is ha, even if he space domain is permanenly willing o sandardise he monioring & conrol proocols applicable o saellies, a majoriy of saellies projecs sill coninues o define heir own insaniaion of he sandard, which has generally a direc impac on he on board sofware implemenaion. The second key design choice of hese services has been o cluser hem ino five specialized Generic Engines, implemened in such a manner ha hey could be developed and qualified independenly 2 by 2 inside separae pariions, wih very limied and simple inerfaces beween hem : - I/O Engine, for shared I/Os managemen - DL Engine, for : o o modes, ON/OFF, reses & modes managemen daaloading operaions (ie sofware uploads managemen, sofware configuraion conrol managemen, memory dumps & memory checks managemen) - HSE Engine, for HW & SW evens, buil-in-ess (including EDAC managemen), warning, failures & errors managemen - INSTR Engine, for insrumenaion service managemen - Engine, for he managemen of operaions in he Non Volaile emory Thanks o his implemenaion, he argeed goal was o provide capabiliy o implemen and qualify incremenally he whole se of Common Services, o have he possibiliy o fully characerize hem, in erms of QoS, and o parallelize heir developmens, wih he possibiliy o enable/disable a subse of hem or o add a new subse of services, depending upon he specific needs of he end-user projec, wih a minimum impac of he remaining subse of services. In his conex, remoe invokaion of he Common Services by exernal pariions imposed o define a sandard communicaion proocol, implemened on op of he inerpariions communicaion service provided by Xrau, he porabiliy of hese services on he hardware plaforms being ensured hrough basic drivers compaible wih he SSIS inerface. In erms of implemenaion, each Generic Engine is developed as a single hread code, based upon a dedicaed acions scheduler adaped o is exac funcional needs and QoS consrains : - deerminisic scheduler for he I/O Engine (see above). The raionale is ha a sric QoS mus be ensured by he I/O Engine o any clien pariion, whaever he saus of he oher pariions sharing he I/O device - basic evens handler mechanism provided by Xrau, for he DL Engine. The raionale is ha modes changes and memory operaions occur relaively rarely and ha he expeced QoS associaed o hese operaions is generally no oo sringen. - flexible scheduler for he HSE Engine, guaraneeing response imes for a se of pre-defined acions, while providing a dynamic CPU reallocaion capabiliy o a background acion (eg scrubbing) depending upon he effecive execuion imes of he pre-defined acions. The raionale is ha he duraion of he acions linked o he managemen of evens is highly dependan of he saus of he observaion poins ha are currenly moniored INSTR Engine and Engine are no implemened ye, bu, in a firs approach, i is probable ha hey could be respecively implemened wih he flexible scheduler of he HSE Engine and he deerminisic scheduler of he I/O Engine. The second imporan characerisics of each Generic Engine consis in heir high configurabiliy, ensured by dedicaed configuraion ables, populaed by he plaform inegraor, and implemened as pure binary code, generaed independenly of he binary code of he Generic Engine i is associaed o. A synheic overview of he General Purpose iddleware archiecure (Basic Sofware) is provided in he following figure :

4 4/10 Applicaion #1 Applicaion #2 Applicaion #m Sandardised Communicaion Proocol A1#1 A2#1 Ai#1 A1#2 A2#2 Aj#2 A1#n A2#n Ak#n Sandardised SW/SW Inerface (SSIS) Scheduler #1 Scheduler #2 Scheduler #n HAL #1 HAL #2 HAL #n Hardware Legend : Cluser of Common Services #1 Cluser of Common Services #2 Cluser of Common services #n Pariions Scheduler Generic Engine Configuraion capabiliy Sandard Service Access Poin over iner-pariions communicaion service A# Acions HAL# Se of drivers Figure 1 : saic archiecure of Basic Sofware d. Qualificaion package Based on he lessons learn of he aeronauical domain derived from he [DO297] consideraions, he las main objecive argeed by he LVCUGEN projec was he possibiliy o apply an incremenal qualificaion process o he compuing plaform and o he hosed applicaions. This firsly lead o he definiion and developmen of a qualificaion ki applicable o each generic sofware componen of he compuing plaform (ie Xrau hypervisor and Generic Engines), enabling o demonsrae he funcional validiy of a componen and o measure he WCETs of he Common Services hey provide, on he final hardware arge. This qualificaion ki, which is par of he LVCUGEN framework, mus be execued each ime a generic sofware componen Engine is pored on a new hardware plaform. The need for incremenal qualificaion process capabiliy lead also o define a qualified oolchain (*) for : - auomaic validiy checking of Xrau configuraion parameers - auomaic generaion of configuraion ables of Xrau and Generic Engines - sysem binary images producion (*) In he LVCUGEN process, he managemen of he CPU allocaions beween he pariions, he managemen of he precedences, daaflows and emporal consrains managemen across pariions and he offline sysem schedulabiliy analyses, are direcly managed by he plaform inegraor hrough he suppor of he Xoncree ool, which will no be qualified. The descripion of he Xoncree ool is ou of he scope of he presen aricle and can be found in [Xoncree]. 3- AUTOOTIVE USE CASE (CONTINENTAL ENGINEERING SERVICES) a. Feasibiliy sudy for auomoive applicaion A feasibiliy sudy has been performed by Coninenal Engineering Services o evaluae he LVCUGEN framework in an auomoive conex. The firs arge of his sudy was an engine conrol applicaion (ECU), bu i quickly appeared ha he saic scheduling plan provided by Xraum could no fi o he dynamic behavior of an ECU sofware. A par of i is riggered asynchronously by engine evens (crank evens, ha appears wih a so-called period ha ranges from 4 ms o 60 ms), and he expeced acivaion ime is very shor (a few µs). This requiremen can be reached wih a saic emporal design. So he sudy urned oward a body conroller module (BC), which does no impose such dynamic consrain, as is funcions are only riggered periodically. b. Requiremens of BC sysem Coninenal provides o a French OE a hardware and sofware plaform for a BC applicaion. This sysem manages body funcionaliies (wipers, elecric windows, air condiioning ), cenralized diagnosis and is a gaeway beween all oher elecronic equipmen in he car. The hardware plaform is based on a 32 bis microconroller. I includes a byes flash memory, [CAN] cells neworks, LIN neworks and hundreds of elecric (discree, analogical or PW) inpus and oupus.

5 5/10 The sofware of his applicaion, based on [AUTOSAR] release sandard, is spli in wo pars : - BSW developed and configured by Coninenal, and provided o he cusomer (source code is delivered), - ASW developed and inegraed by he cusomer ino he BSW plaform. For his use case, he cusomer requires ha he whole funcionaliy of BSW is execued wihou consuming more han 40% of CPU load, and no ask loss is allowed as inpus and oupus are no buffered. oreover, I/O and LIN reamens have o be achieved wih as minimum jier as possible. The implemened funcionaliies are disribued ino sacks, specified by he [AUTOSAR] sandard: - I/O Hardware Absracion: wriing and reading on discree I/Os, ADC conversions and PW driving, - Communicaion Services: emission and recepion on [CAN] and [LIN] neworks, use of neworks as wake-up sources, on-board diagnosis hrough [CAN] nework, - emory Services: reading and wriing of configured daa blocks in EEPRO during sysem sae ransiions (wake-up, shudown) or on-he-fly, - Sysem Services: error managemen and funcions inhibiion, ECU sae managemen, wachdog managemen c. Use case feasibiliy sudy The LVCUGEN framework faces wih wo main differences oward he curren realizaion in he [AUTOSAR] sandard: - i enforces, by he usage of Xraum, a saic scheduling plan, whereas he acual OS has dynamic feaures such as preempion and managemen of asks prioriies, - i provides generic engines o manage shared hardware resources, while [AUTOSAR] defines sacks aimed for he same goals, bu wih specific auomoive funcionaliies. The sudy will inend o show how far can he LVCUGEN framework can be reused in he respec of he cusomer requiremens. A preliminary sudy has shown ha he LVCUGEN general purpose middleware could be parially reused o cover he [AUTOSAR] BSW requiremens. Depending on he engine, reuse could be easy, or would need some adapaions: - he I/O engine fis o he basic requiremens of he I/O [AUTOSAR] sack, bu does no offer exended funcionaliies, mosly required by he communicaion sack for [CAN] and [LIN] neworks managemen. The access o I/O resources can be managed by I/O engine, and specific pariions mus be developed o provide he specific [AUTOSAR] feaures, - by an exension of is configuraion capabiliy, he DL engine could be able o manage ECU saes as i is expeced in auomoive. The reprogramming funcions are currenly embedded in he boo sofware, bu he use of he daa loading capabiliy of he DL engine can be useful o allow fas reprogramming (in order o download one specific pariion for insance, which is no possible wih he [AUTOSAR] archiecure), - he error managemen funcionaliies brough by he HSE engine would no replace he DE and FI modules ha fi o applicaive auomoive needs. Bu he engine will be used o manage evens linked o he pariioned archiecure, - he INSTR engine provides measuremen capabiliy o he upper pariions. A deep sudy has o be done o deermine he adapaions needed on he XCP module, ha provide his feaure for auomoive needs, o fi o INSTR engine inerfaces, - he engine for non-volaile memory managemen is no ye developed. So, in order o migrae he BC sofware ino he LVCUGEN framework, he upper level of he [AUTOSAR] sacks will be reused in specific pariions, because hey embed enhanced auomoive funcionaliies, and some LVCUGEN engines will be used o cover he lower level requiremens: - he [AUTOSAR] OS will be removed, ask managemen being fully handle by he Xraum scheduler, - he microconrollers drivers have o be developed o fi boh o hardware inerfaces and o Xraum inerfaces, - each [AUTOSAR] sack is inegraed as a Xraum pariion. The lower level modules can be replaced by LVCUGEN engines, - a specific pariion has o be reserved for he cusomer s applicaion. The resuling physical design of he applicaion is described in he following figure :

6 6/10 Cusomer Applicaion Vehicle funcions SYSTE Services Diag. Even ECU Sae Wdg EORY Services NV RA CO Services Com. Diagnosic Com. I/O Hardware Absracion Diag. Even CRC ECU Sae Wdg ode and DL Pariion Insrumenaion Pariion I/O Server Pariion HW and SW Even Pariion Pariion Xrau Core I/O Drivers (CAN, DIO, PW, ADC, EEPRO ) CPU Drivers Hardware LVCUGEN General Purpose iddleware AUTOSAR odules HW/SW Inerface Hardware specific code Pariion Figure 2 : saic archiecure of he BC sofware Sandardized SW/SW Inerface The use of LVCUGEN framework offers several benefis compared o he acual echnical soluion and process. Firs, he QoS of each pariion is guaraneed by he saic scheduling plan and he design of specific schedulers embedded in each pariion. Wih he curren way of working, i is only demonsraed experimenally, by running sofware for a long ime o ry o reach every criical sofware sepoin. I also improves he whole V-cycle: he specificaion and design duraion is increased (around +10% for specificaion phase and +20% for he design phase), bu he inegraion ess are less imporan (around - 30%), and he inegraion of buil and esed objec files brings profis in case of reuse of sofware. In a long erm view, and also in a reuse conex, some ime will be saved on he developmen of an applicaion. The quaniy of generic engines ha can be reused has o be specified wih a more deailed sudy, bu his firs sep has shown ha here will be a mix beween LVCUGEN BSW (use of generic engines for funcions close o hardware drivers) and AUTOSAR modules (inegraed ino specific pariions o provide auomoive requiremens) : - he I/O engine could be fully reused, and he dedicaed pariion would only conain enhanced funcionaliies, - he engine developmen could be based on he emory Services sack, - [CAN] and [LIN] drivers could also be inegraed ino he I/O engine. In his firs sudy, all he asks execuion ime were specified wih he measured WCET. As a resul, he CPU load consumpion would be close o 70%, whereas he cusomer allows only a 40% CPU load consumpion. This way of designing he scheduling plan is no a good approach. I would be necessary o creae a scheduling plan ha respecs he resources consumpion requiremens. Then, i will be necessary o specify a accurae QoS need, o idenify criical pariions ha canno afford o lose asks, and less criical pariions ha can suppor some jier. As a resul, he real QoS would be known, and he CPU load which is available for he cusomer applicaion would be also guaraneed. d. Conclusions and evaluaion coninuaion The sudy of his use case has shown ha echnically, i is feasible o migrae a BC applicaion ino he LVCUGEN framework. The par of he middleware ha can be reused has o be sudied accuraely, and some benefis can be expeced on he developmen process. The bigges effor will have o be done o specify a new dynamic archiecure, o propose a more deerminisic approach of he scheduling, and hen o guarany a beer QoS ha he acual one. The saic design will also have o be sudied deeper: a his ime, each AUTOSAR sack is mapped in a single pariion. Communicaion beween sacks has o be idenified: a beer mapping of he AUTOSAR module ino pariions could avoid some hypercalls and save execuion ime. 4- AERONAUTICAL USE CASE (INTERTECHNIQUE / ZODIAC AEROSPACE) a. Evaluaion conex The purpose of his evaluaion was o deermine he abiliy of he LVCUGEN framework o provide a consisen alernaive o exising COST or proprieary soluions in aerospace domain, from several viewpoins, among which echnical, safey/cerificaion and coss ones are he mos imporan.

7 7/10 This evaluaion was based on he furnished documenaion: user and reference manuals, inerfaces descripions, implemenaion examples of use cases exraced from he spaial domain and a rial version of he associaed scheduling configuraion and analysis ool (Xoncree). This evaluaion was performed considering he poring of a real use case on a subse of an Inegraed odular Avionics archiecure (fully disribued archiecure). The resuling hardware archiecure of he use case is depiced in he following figure : ARINC 664 Gaeway Field bus #1 Remoe Daa Concenraor Discree oupu Discree inpu CAN Field bus #2 (ARINC 429 replacemen) Figure 3 : example of IA archiecure sub-elemen b. Requiremens & consrains i. Cerificaion and safey consideraions Safey aspecs and heir corollary, cerificaion issues, are key poins in he aerospace world in general and in he Inegraed odular Avionics in paricular. These consideraions are susained by a few conceps: - Robus pariioning in space, ime and considering inpus/oupus (a fauly applicaion shall no disurb oher applicaions), - Proecion agains high-energy (mainly neurons) paricles, - An incremenal developmen and cerificaion process involving differen acors and requiring modulariy and configuraion parameers segregaion and he definiion of a usage domain. The pariioning opic is addressed by he [ARINC653] sandard, which provides as well an applicaion programming inerface. The cerificaion subjec is mainly covered, a sofware level, by he [DO178B] sandard. Alhough securiy of informaion is no ye a real concern, i may become an emerging need in a near fuure. ii. Funcionaliies and performances os of aerospace applicaions do no require high levels of iming performance (wih an excepion for braking and landing gear sysems): expressed laencies and responsiveness are no lower han a few ens of milliseconds. A he opposie, hey may require high compuing performances. Concerning he presened use case: - Hundred of messages are exchanges on he [CAN] busses, beween 6 o 40 label like messages are exchanges on field bus #2. os of he inpus and oupus require a refresh rae beween 500 msec and 1 sec, his can fall down o 50 msec concerning some few informaion on field bus #2. - Concerning [ARINC 664] messages, 96 messages disribued on 45 virual links are received (wih a wors case daa rae of 320 byes every 30 msec), 25 messages disribued on 16 virual links are ransmied (wih a wors case daa rae of 244 byes every 50 msec). - Expeced responsiveness (wors case) for a given funcion following a paricular even is around 2 sec. Concerning he funcionaliies, a few ones are commonly used and as a consequence are expeced: - faul managemen o deec and idenify problems during sysem iniializaion or a runime, o repor hese problems wih possible correlaion and ake acion a differen levels(plaform, pariion or service, ask), - an [ARINC 615A]/[ARINC 665] complian daa loading service including correcness verificaion and compaibiliy check feaures,

8 - Insrumenaion services for debug and inegraion purpose. Finally, Freescale processors, being commonly used in he aerospace domain, are preferred. 8/10 iii. Coss Recurring and non-recurring coss represen, as in many domains, a key poin. I is no possible o give accurae figures; i is easier o idenify common expensive iems. In relaionship wih he above consideraions, hese iems are: - A cerificaion ki o suppor he corresponding aciviies ; such a ki can include pariioning demonsraion, wors case execuion ime analysis, es procedures and scrips, ec - Supplemenal developmens (poring, cusomizaion, addiional drivers developmens, ec ). Long-erm consideraions o assess a cos are re-usabiliy, adapabiliy, scalabiliy of he considered componens, oolse o suppor applicaions developmen and cerificaion aciviies, ec Ease of insallaion and hos plaform requiremens, documenaion qualiy and echnical suppor, should no be le apar. c. Synhesis i. Possible implemenaion using he LVCUGEN framework Saic archiecure depiced below represen a possible echnical implemenaion ono wo differen kinds of avionics equipmens. I shows ha he LVCUGEN framework, including sysem pariion enhancemens (o suppor avionics sandard), and provided a buffered inpus and oupus managemen, is well suied o avionics applicaion. The gaeway (gaeway beween he [ARINC 664] Aircraf Daa Communicaion Nework and he Remoe Daa Conroller) shall hos user pariions (idenified PAx ) in charge of implemening he funcional requiremens, and sysem pariions (idenified SYSx ) ha have o perform generic/common asks: [ARINC 615A] complian daaloading, Buil-In Tes and monioring, insrumenaion. For his purpose, he available generic engines have o be compleed o comply wih avionics sandards or direcive: he HSE may be a basis for a conrol & monioring pariion, he DL for an [ARINC615A] pariion. A nework managemen pariion should be developed from scrach. Several asks are commonly managed wihin a user pariion, hus requiring he use of a gues OS. oreover, an [ARINC 653] API is required. Regarding he iming requiremens, he definiion of four 15 msec Inor Frames (IF) wihin a Ajor Frame (AF) is enough. The wake-up of he I/O server pariion before and afer every pariion scheduling should ensure he required informaion freshness and laencies requiremens, and is suppored by he processor considering is compuing capabiliies. XAL PA1 A653 Gues OS PA2 A653 Gues OS Xraum core PA3 A653 Gues OS PA4 A653 Gues OS I / O S e r v e r H S E A664 driver C T R L & O N D L A A D L Field bus driver I n s r u m e n. N e w o r k g Oher drivers XAL + I/O enry poins Xraum HAL Hardware board I/Os Generic BSW componen Hardware arge Generic inerface Figure 4 :saic archiecure of he Gaeway sofware The Remoe Daa Concenraor (or RDC, which purpose is o concenrae I/O daa owards he gaeway) will no hos user pariions, bu configuraion ables. Feaures equivalen o he gaeway s sysem pariion are required, excep he nework managemen one, hus requiring he here above described

9 9/10 enhancemens concerning DL and HSE. There is no need for an [ARINC653] layer, and monohreaded pariions could be convenien. Access o he field bus or o he I/Os is exclusive o he concerned pariion, an I/O server is herefore no mandaory, bu i may consiue a basis for he developmen of he I/O and field bus managemen pariions (see figure below). The main funcionaliy of a RDC being he compuaion and rouing of daa flows, a scheduling plan wih a AF consiued of wo 70 msec IFs, fulfils he iming requiremens. XAL Xraum core Compuai on & Rouing I/O g. I/O drivers Field bus g Field bus driver H S E C T R L & O N Oher drivers D L D a a l o a d i n g I n s r u m e n. XAL + I/O enry poins Xraum HAL Hardware board I/Os Generic BSW componen Generic inerface Hardware arge Figure 5 :saic archiecure of he Remoe Daa Concenraor sofware ii. Srong poins The evaluaion performed by Inerechnique / Zodiac Aerospace shows ha he LVCUGEN frameworks provides : Srong spaial, ime and inpu/oupu scheduling. Time pariioning demonsraed a configuraion level via Xoncree. And ha: Developmen effor reducion using he generic componens o answer o avionics sandards requiremens. iii. Weak poins and improvemen opporuniies A he opposie, he following improvemens should be considered in order o ease he LVCUGEN framework diffusion in he aerospace world : Economical and/or licensing model o be clarified, A asks/hreads managemen capabiliy a pariion level, Availabiliy of an [ARINC653] layer. Finally, concerns remains on unbuffered inpu/oupu low laencies requiremens leading o an overscheduling wih loss of efficiency and even unschedulabiliy. 5- CONCLUSION The preliminary assessmens performed by Coninenal Engineering Services and Inerechnique / Zodiac Aerospace concluded ha he LVCUGEN framework, in is curren definiion : - is well suied o Gaeway and Remoe Daa Concenraor applicaions of Inerechnique / Zodiac Aerospace (aeronauical domain) and o Gaeway applicaion of Coninenal Engineering Services (auomoive domain) - is no adaped o applicaions requiring exreme reaciviy o evens (ypical max laency of several µs). ore globally speaking, hese resuls provide an encouraging rend ha confirms he cross-domains poenialiy of he LVCUGEN framework for aeronauical and auomoive domains, in he class of applicaions from low o high reaciviy, which generally consiue a very big proporion of embedded sysems (probably around 70%). This rend is fully in line wih he conclusions of he experimenaion already performed by he CNES in he space domain on he perimeer of saellies payloads. On he basis of hese very encouraging resuls, i is now necessary o consolidae he cross-domains

10 10/10 poenialiy of he LVCUGEN framework by a real implemenaion on represenaive hardware arges, in conexs represenaive of operaional R&T projecs. The new AVIONIQUE-X French projec for he space domain (space vehicles) and he fuure ASHLEY European projec for he aeronauical domain (SCARLETT coninuaion) could consiue very good opporuniies o perform hese experimenaions, hrough he developmen of compuer prooypes, based upon he LVCUGEN framework. No paricular auomoive R&T projec could be idenified up o now, probably due o he fac ha he whole auomoive domain is currenly invesing a lo in he [AUTOSAR] implemenaion and ha he new paradigm induced by he LVCUGEN framework would consiue an addiional sep, ha probably comes oo early. However, he curren rend of he auomoive domain, consising in higher inegraion and bigger compued assisance ino criical funcions will probably lead, on longer erms, o he emergence of fuure R&T projecs, where he LVCUGEN framework could ake is place. Anoher opion could be o ry o se up from scrach a new cross-domains R&T projec, aiming a defining a common sandard o hese hree domains, and defining a new generic (cross-domains) framework, inheried from he LVCUGEN one, bu he effors done in 2011 o raise such a projec showed such an objecive necessiaes a emporal convergence beween he echnological roadmaps of all he involved domains, which does no appear o be realisic. So his soluion may no be he preferred opion. Whaever he conex ha will be found for hese fuure experimenaions, he disribuion, licensing and governance schemes of he LVCUGEN framework already appeared o be crucial quesions, in he sense ha hese hree opics are compleely linked wih he business model ha can be effecively reached by his framework. The addiional quesion behind hese consideraions is he capabiliy o creae he economical condiions ha would enable he emergence of a cross-domains supplier (echno-provider of he generic framework), ha will be ready o inves on his echnology. These crucial quesions apply also o he Xrau framework (ie hypervisor and associaed ools), whose fuure seems o be ighly linked wih he fuure of he LVCUGEN framework. In his complex conex, he curren prioriy for he CNES, which is a naional agency dedicaed o space, is o deermine he way he LVCUGEN framework could be made open o experimenaions by endusers, in paricular hose of oher domains han space, while being able o provide he necessary echnical suppor for hese experimenaions. Probably he new IRT AESE (Insiue of Research and Technology for Aeronauical, Space and Embedded Sysems), currenly creaed in Toulouse in he frame of a French public loan ( Grand Emprun ), could emporally consiue he bes relay for his aciviy, unil a cross-domains echno-provider of he LVCUGEN framework can be formally idenified. 6- REFERENCES a. Sandards [ARINC615A] Sofware Daa Loader using Eherne Inerface Ref ARINC 615-A [ARINC653] Avionics Applicaion Sofware Sandard Inerface - Ref ARINC 653 [ARINC664] Aircraf Daa Nework Ref ARINC 664 [ARINC665] Loadable Sofware Sandards Ref ARINC 665 [AUTOSAR] AUTomoive Open Sysem Archiecure (AUTOSAR) - hp:// [CAN] Conroller Area Nework Ref ISO [DO178B] Sofware Consideraions in Airborne Sysems and Equipmen Cerificaion Ref RTCA DO178B/EUROCAE ED-12B [DO297] Inegraed odular Avionics (IA) Design Guidance and Cerificaion Consideraions Ref RTCA DO-297/EUROCAE ED-124 [LIN] Local Inerconnec Nework - hp:// [PUS] Ground sysems and operaions Telemery and elecommand packe uilizaion Ref ECSS-E-70-41A b. Publicaions [Xoncree] V. Brocal,. asmano, I. Ripoll, A. Crespo, P. Balbasre and J-J ege. Xoncree : a scheduling ool for pariioned real ime sysems In ERTS² Embedded Real Time Sofware and Sysems. ay. Toulouse 2010 [Xrau]. asmano, I. Ripoll, A. Crespo, J-J ege and P. Arbere. Xrau : an open source hypervisor for TSP embedded sysems in aerospace. In DASIA Daa Sysems In Aerospace. ay. Isanbul 2009