Avionic-X: A demonstrator for the Next Generation Launcher Avionics

3 Distributed Dependable Architectures for Safety-Critical Applications4 With the help of the Swedish company ÅAC Microtec.• SPA (Space Plug-and-Play Avionics),• SAVOIR,• DDASCA.SPA was developed in United States by the Air ForceResearch Laboratory (AFRL) 4 . The draft SPA standard hasalready been released through the American Institute ofAeronautics and Astronautics (AIAA). The SPA effort is aresponse to the need for reduced design, fabrication,integration, and test schedules (and therefore relatedengineering costs) for small spacecraft, thanks to selfconfigurationand self-organization.SAVOIR stands for Space Avionics Open InterfaceArchitecture. The space industry and Agencies have recognizedthis already for quite some time: The level of standardization inthe spacecraft avionics systems should be raised in order toFigure 1. Context of the Avionic-X projectincrease efficiency and reduce development cost and schedule.It has been proposed to federate several ongoing initiativesActually there are several other ESA technology programs under the common “Space Avionics Open Interfacebesides FLPP which include avionics aspects, for instance: Architecture” initiative. Within this initiative, the approach• Basic Technology Research Programs (TRP) for TRLbased on reference architectures and building blocks plays afrom 1 to 3. In particular ESA’s Deep Sub-Micronkey role. The SAVOIR Advisory Group (SAG) membersinitiative is working with industry to design a newregroups space agencies, large and small system integrators andgeneration of space-worthy microchips;equipment/software suppliers.Lastly, DDASCA is a newly born consortium dedicated to• General Support Technology Programs (GSTP) forTRL from 2 to 8.Distributed Dependable Architectures for Safety-CriticalApplications. It regroups universities and research centers,Besides, the Launch Vehicle (LV) avionics sector is toosmall a market to allow for self-standardization and to fundsystem integrators and equipment/software suppliers, withstandardization organisms.specific technologies development. The “Not Invented Here”syndrome is not an option. Therefore we have to seek ideas andIt aims at engineering and standardizing referencetechnologies in other innovative sectors, and establish a spinin,rather than recreate everything from scratch.architectures with generic building blocks, that will bemodular, provable, reusable and safe, to build hardware andsoftware platforms for safety-critical applications (DAL A –Several trends from outside the Launch Vehicle (LV) sectorseem promising:SIL 4).Within the Avionic-X project frame, we will strive to take• The “More Electric Aircraft” trend in aeronautics. Ona launcher, this could translate into electromechanicalactuators (EMA) for Thrust Vector Control, andelectrical valves in cryotechnic engines, thus givingbirth of a “More Electric Launcher”.in a wide range of promising concepts, emerging standards andinnovations (with a TRL above 2), and perform trade-offanalysis w.r.t. their interest in a launcher system context, andfinally prototype and test the most interesting candidates on theplatform.• Standardization is a trend in the satellite industry withthe Space Plug-and-Play Architecture (SPA), theIII. AVIONIC-X WORK LOGICSAVOIR 2 initiative, and more generally for embeddedsystems with the DDASCA 3 consortium. This couldA. Work Logic presentationalso encompass the IMA concepts (Integrated Modular Avionic-X project is more than a platform or a list ofAvionics), and the ARINC 653 Time and Space technologies. Its work logic is built on three axes:partitioning (TSP) standard [3]. Several projects arecurrently trying to spin-in from the aeronautical• #1 - Demonstrator activities (target IRL-3),domain the TSP/IMA technology for space • #2 - Technological activities (target TRL-6),applications.• #3 - Launcher avionics engineering.Three of the ongoing initiatives leading towards morestandardization in avionics, with reference architectures and As shown on the figure hereafter, these three branches ofbuilding blocks, are presented hereafter:Avionic-X interact all along the project in order to reach ourtargets in terms of TRL and IRL.2 Space AVionics Open Interface Architecture

The needs for demonstrations arise equally from theoreticalstudies on various launcher avionics architectures (“SEL-X”activities) in a top-down approach, and from technologicalenablers studies in a bottom-up approach. The “technologicalbranch” also focuses on innovative methods with the same goalin mind: reducing the Total Cost of Ownership (TCO) of thelauncher system.The project Avionic-X is currently in phase A (systemconcepts feasibility). It is due to pursue its phase B(specification and preliminary design) from the beginning of2012, with an incremental development cycle, similar to the“spiral model” common in software engineering. This willoffer several windows of opportunity to introduce newtechnologies and new partners in the project.Figure 2. Work Logic of the Avionic-X projectB. Launcher avionics engineering (“SEL-X”)This activity branch of the project aims at identifying thekey drivers and requirements for a launcher avionics system,and following a top-down approach, taking into account thetechnological candidates, in order to propose several possibleavionics architectures (named “SEL-X”), and assess theirperformances and cost.But first, to prepare the future, we have to look back atthe past. So let’s take a look at the Ariane 5 launcher family.Ariane 5 avionics (see figure 3) follows three main drivers: Itis a duplex system, it is organized in several sub-systems(Flight Control, Telemetry, Electrical Power and FlightSafety Sub-Systems), and it is also strongly constrained bythe rule of “geographical return” (which may have led to apractical but non-optimal architecture).Ariane 5 avionics has evolved since the beginning ofAriane 5 program, in order to solve obsolescence problemsor to accommodate the various versions of the launcher, butits duplex architecture stays essentially the same. The duplexchoice was not derived from system requirements but wasseen as a way to increase robustness and ensure reliability.Figure 3. Overview of Ariane 5 upper composite avionics architectureAriane 5 avionics system breakdown in sub-systems willnot necessarily be retained, and for the moment,geographical return constraints should be put aside, in orderto look for “more” optimal solutions.The trade-offs performed on the SEL-X architectures ledus to consider several potential improvements: First, astronger integration (in order to reduce the number ofequipments, and the recurring costs), with standard modules

in a rack-based architecture (following the IMA trend) anduse of Time and Space Partitioning; second, a hotredundancy concept, and a communication based on a timetriggeredprotocol (see § III.C.1)).1) Toward a more integrated architecture (IMA)A “centralized” architecture is an architecture where themain tasks are executed on the same processing unit. In a“distributed” architecture, the tasks are distributed throughseveral equipments.The current Ariane 5 avionic architecture is mainlycentralized, as there is an On-Board Computer (OBC)centralizing all the sensor data to compute the GNC and thesequential algorithms for commanding the launcher.However it is also partially distributed as other equipmentsalso have “intelligent” functions to perform, before or afterthe OBC computations. The architecture is organized on a“master-slave” mode, meaning that the centralized OBCtakes all the decisions, based on the sensor inputs andmeasurements. This was a way to ensure the determinismrequired for a high level of reliability and availability.The choice of Ariane 5 was the result of a top-downallocation of the main avionics functions to differentequipments, with clear industrial perimeters andresponsibilities, accepting the fact that each industrial wouldprobably have to develop or to implement computing meansin an heterogeneous way and without any harmonization.In general this was not a problem as most of theequipments only needed very simple functions, easy toimplement within simple components such as DSP, ASIC orFPGA. But for complex equipments like the SRI (InertialMeasurement Unit), the computing unit could have beenharmonized or merged with the OBC itself.Today, the evolution of CPU capacity allows us toenvision a stronger centralization (or integration) of thearchitecture, for example by merging the SRI and OBCnumerical calculations on the same computing node, in orderto reduce the number of equipments and the associatedweight.We reach here the concept of Integrated ModularAvionics, which comes from Aircraft development. Themain idea is to reduce the amount of embedded avionichardware by sharing the same hardware and softwareresources between various sub-systems. In this concept, astandardized CPU modules would allow to reuse the samemodule for all the launchers functions requiring computingcapabilities.This standard Processing Module would be physicallyregrouped with other standardized or specific modules inracks, as it has been done in the satellite industry (forexample the Spacebus 4000 avionics concept described in[5]). Within Avionic-X we call this standard ProcessingModule “MDHB-X”, which stands for “Modular DataHandling Block” and is presented in § C.2).Modular Data Handling Block(MDHB-X)Power BoardEMPTYInertial BoardGNSS BoardFigure 4. Example of a rack-based architecture2) Redundancy conceptThe current Ariane 5 system is based on a duplexarchitecture composed of two onboard computers in hotredundancy. The nominal one is in charge of all operationson both avionics chains and the redundant one only spies asubset of the 1553 messages to maintain its own flightcontext. In case of auto-detected errors on the nominal OBC,an error signal is sent and a hand-over is done to theredundant OBC which takes the control of the 1553 busesand continues the mission. The redundant OBC becomes“the last survivor” and the nominal OBC cannot recover theflight control.The first redundancy concept which we aim at testing onAvionic-X is not dissimilar to Ariane 5’s one, but improvesthe transition phase and simplifies the design of the flightsoftware. As a matter of fact, in this concept both OBCsexecute the same software in parallel, and the selection of thecommand which shall be executed is performed by theactuator. The failure of one OBC is then almost transparent,hence a true “hot redundancy”. The reinsertion of the faultyOBC could also be envisioned, in case of a transient failurefollowed by a reset and successful auto-tests.This concept of “selection by the actuator” couldeventually be scalable to a triplex concept, for specificmissions where the exposition to natural radiativeenvironment could otherwise lead to unacceptableunreliability figures.C. Technological enablersThe second activity branch of the project aims atidentifying innovative technological candidates (hardware,software, methods), performing trade-offs and feasibilitystudies w.r.t. a launcher system, and elaborating roadmaps tomature the relevant technological enablers up to TRL 6.The technologies we are looking at in the frame of theAvionic-X shall cover the biggest part of a launcher avionics

functional needs. At this stage of the project, all trade-offsare not completed yet, so we will detail only a few of themhereafter, focusing on ERTS² targets:1) Communication SystemThe Communication system, which is the “backbone” ofthe digital system, comes naturally first, as it will support theintegration of every other building blocks on thedemonstrator in the next increments.This work package has included several trade-offs, w.r.t.bus technology (optical, cable, wireless…), bus topology(star, ring…), communication protocols, field buses.Moreover, it appears interesting to follow the evolution incommunication systems from a message-centric model to adata-centric design. In a message-centric architecture, thecommunication system does not recognize the dataembedded in the messages it carries. In opposition, a datacentricdesign could be represented as a global virtualdatabase, with applications accessing it without worryingabout the distributed aspect of the system. The “smartTelemetry” concepts follow this data-centric design too. Forexample, a sensor may acquire data at 100Hz, but onlyupdating the virtualized data when the change is bigger thana predefined limit, thus avoiding bottleneck points in thecommunication system.The communication system has to answer to criteriadefined by the architecture of the new launcher. The firstSEL-X studies identified the following targets:• At least 50 or 100 times the Ariane 5 communicationsystem throughput in order to fit the necessaryincrease of command/control data flow due to the“hot” redundancy flight control concept suggested inSEL-X (see § B.2)), and moreover, to host thelauncher telemetry data flow which is managed untilnow on Ariane 5 by a dedicated bus.• A better exchanges determinism, ensured as must aspossible at standard level, firstly to avoid a costlydevelopment of a “tailor-made” deterministic layerand also to simplify the hot redundancy managementand synchronization between the communicationsystem nodes.• Reduce the communication system harness weight,• Reduce the electric consumption,• Increase Communication System flexibility.The current state of the preliminary design includes atleast three main communication systems on thedemonstrator:• One copper bus with a time-triggered Ethernetcommunication, for example TTEthernet. With athroughput of 100 Mbits/s (possible 1Gbits/s) basedon Ethernet (LAN compatible), TTEthernet managesdeterminism at standard level by offering TimeTriggered services based on PTP IEEE 1588protocol, the TT messages. This standard also takesinto account Rate-constrained (RC) messages likeARINC664 (AFDX) and is also compliant with basicEthernet messages, called Best Effort (BE) in thestandard. It benefits from the long Ethernetexperience, tools and has already been chosen inspace projects. Here is a purely theoretical viewillustrating the three kinds of messages managed bythe TTEthernet standard:Figure 5. Different kinds of TTEthernet traffic• One optical bus, for example FibreChannel. Themain benefits of using optical fiber at physical levelare an increased bandwidth and an immunity toElectromagnetic Interference (EMI). Thus, theharness weight could decrease due to wires shieldingreduction and the uselessness of EMC filters at boardlevel. Moreover, FibreChannel has been crafted toeasily map other protocols, so that existing softwarewritten for legacy protocols can be easily ported.Determinism and fault tolerance may be mapped toFibre Channel. It is compatible with 1553 (butwithout the limitations of the MIL-STD-1553standard in terms of throughput, message size,…)and it offers a low latency network.• One MIL-STD-1553 bus, which would ease theconnection of existing equipments on thedemonstrator. It offers industrial partners a wellknownspace bus to plug possible off-the-shelfdemonstrations using this standard.2) Modular Data Handling Block (MDHB-X)In this branch of the Avionic-X project, we will defineand demonstrate the MDHB-X solution for data processingand communication bus interface (such as identified in§ B.1)), while following several trends:• IMA and TSP for space applications;• Multi-core architectures.IMA changes drastically the usual industrial way ofworking: Sub-system suppliers are no longer the suppliers ofthe avionics part of their sub-system (that would be genericbricks), and could perhaps become only “applicationsoftware providers”.As for the multi-core aspects, we have to prepare the useof multi-core processors in space systems. Multi-corearchitecture is a solution to introduce additional processingpower, to improve the fault detection isolation and recovery(FDIR), and finally to implement more easily time and spacepartitioning.

Taking this into account, we will define and demonstratea generic processing and Input/Output module answeringdifferent needs for data handling in a launcher. This“Modular Data Handling Block for Avionic-X”, orMDHB-X, is presented on the figure below.Figure 6. Modular Data Handling Block for Avionic-X (MDHB-X)The Modular Data Handling Block (MDHB-X) aims atproviding a generic, versatile and configurable computingsystem solution. Each MDHB-X unit can be made of variouspredefined combinations of Processing Modules (PM) andI/O Modules (IOM). Through this mechanism, it is possibleto create a wide range of MDHB-X units thanks to PM andIOM generic building blocks.Here are shown some configurations of the MDHB-X:Centralised highprocessingneed:ProcessingModule #1ProcessingModule #2Non-intelligent Remote-Terminal Unit:BasicSensorsCondition.unitSmartSensorsNon-intelligentActuatorsSeveral candidates are foreseen to be assessed asprocessor, like the LEON4-based NGMP platform, or someARM implementation, both potentially in single or dual coreconfiguration. The IOM will lie on a custom FPGA solution.The different I/Os to handle include for instance thecommunication system and sensors (“intelligent” or not, andaccessed through conditioner unit or directly).Each Module of MDHB-X units will lie on a separateboard, and the integration could be done thanks to a rack,connecting them together through a backplane bus forexample.From a software point-of-view, the spaceflight field is onthe verge of an evolution from federated avionics and datahandling architectures to Integrated Modular Avionics (IMA)paradigm, as it happened a few years ago with airbornesystems. By allowing running several previously segregatedpieces of software on the same computing platform, IMA inspace applications is expected to have an impact on theoverall avionics’ mass, volume, power consumption andrecurrent cost.As the physical boundaries of federated subsystemsdisappear, IMA has to implement a new kind of separationbetween the different pieces of software involved, throughthe technique of partitioning.In the frame of Avionic-X demonstrator, the Middlewarelayer represents every piece of software between the barehardware and the applicative software, including thepartitioning layer (inside or outside the RTOS) and the OS.Here is a scheme of the Middleware in Avionic-X:I/OsVirtualizationCPU /FPUMMURedundancyServicesBasic APServicesRTOS#1Partition 1APIH/W OBTPowerI/O ModulePowerI/O ModuleH/WPartition 2Avionic Communication SystemPowerI/O ModuleI/Os I/FI/ODriversI/O FrameManagementServicesI/OVirtualizationServicesI/O ModuleNetworks gateway:H/WAutotestsMiddleWareI/O PartitionFigure 7. Various configurations of the MDHB-XFigure 8. Middleware in Avionic-X

In partitioning-based software, like in ARINC-653systems for instance, isolation, protection and determinismlie on the concept of Time and Space Partitioning (TSP). Itallows a strong segregation of pieces of software of mixedcriticalities and/or mixed suppliers by implementing a staticallocation of fixed amounts of memory for each partition,and a fixed amount of CPU time allocation of each partitionaccording to a cyclic preemptive execution scheme. In thislight, the MDHB-X represents the physical implementationof IMA.Actually, the market offers a wide panel of partitioningsolutions, from bare metal hypervisors (or Virtual MachineMonitors) to userspace RTOSes over partitioningmicrokernels, and care must be taken when choosing asuitable option depending on the project. XtratuM hypervisoris currently foreseen, as well as in CNES and ESA studies.Another form of abstraction mechanism used in IMAsystem is the concept of Input/Output virtualization.This consists in presenting to every software instance thesame abstracted and generic interface to manage I/Os byisolating high-level software and the communication system,having available each piece of data at each node of thesystem, solving equipment synchronization problematic,supplying data consistent with the equipment need (not onlythe last update), reading an entire engineering data like aquaternion (without update during acquisition) and ensuringdata consistency.The resulting generic layer will be usable on every pieceof equipment (i.e. MDHB-X).3) Other technological enablersThe other work packages and technologies we arelooking at in the frame of the Avionic-X project are not fullydetailed in this paper, but they encompass:• Flight Control:Within Avionic-X we will explore different inertialnavigation sensors (e.g. hemispherical resonator gyro orfiber-optics gyro), which would be less expensive than thegyrolaser technology used on Ariane 5. GNSS hybridizationwill also be considered, in order to improve the navigationprecision or to compensate for less precise gyros, and toprovide real-time localization for safeguard purposes.MEMS gyrometers distributed along the launcher will beconsidered in order to improve the robustness of ThrustVector Control. As a matter of fact, vibrating structuregyroscopes manufactured with MEMS technology havebecome quite inexpensive and widely available.• Pyrotechnics:Both opto-pyrotechnics and advanced electropyrotechnicswill be assessed during the Avionic-X project.• RF communications:In order to improve the RF links between the launcherand the ground means (higher bit rate with less energyconsumption), we will test and mature directive antennas,either phased array antennas or active antennas on innovativematerials.• Power Generation and Distribution (Digital PowerControl);• Data acquisition and sensors;• Ground System – Onboard Interfaces (electrical andradiofrequency parts of the Ground to LaunchVehicle Interface);• EGSE and Simulators;• Harness and connectors, taking into account that thecommunication and power supply harness of atypical Launch Vehicle electrical system representmore than 10 kilometers of cable of various types !D. Methods: A focus on Model-Driven Engineering1) The MDE approachThe MDE approach is meant to increase productivity bymaximizing compatibility between systems (via reuse ofstandardized models), simplifying the process of design (viamodels of recurring design patterns in the applicationdomain), and promoting communication between individualsand teams working on the system (via a standardization ofthe terminology and the best practices used in the applicationdomain).MDE reduces costs, in particular hidden costs or costoverruns, not foreseen at the beginning of a software project.The famous “Chaos Report” (an industry study by theStandish Group) [1] is nowadays contested, however it foundthat for IT (information technology) projects, the averagecost overrun was 43 percent, and 71 percent of projects wereover budget.Moreover, according to [4], available statistics on bugs inembedded systems show that approximately 75% of them arecaused by ambiguities or misunderstandings between systemrequirements and software requirements. Moreover, sucherrors are generally found late in the project life, thus areparticularly expensive to correct 5 .In the frame of the European Project ASSERT (see [2]),it has been estimated that a gain of 10% is achievable interms of productivity during software engineering, due to:• the use of formal modeling, proof and verification atsystem level,• data modeling and code generation techniques.5 Original citation in French: « Les statistiques disponibles […] sur lacause des bugs dans les systèmes embarqués montrent qu’environ 75% deceux-ci sont lies à des ambigüités ou des divergences de compréhensionentre spécifications systèmes et spécifications logicielles. Ce type de bugs apour circonstance aggravante d’être généralement trouvé très tard dans lesprojets et donc d’être particulièrement coûteux à corriger ».

The MDE covers the whole range from softwareintensivesystems to on-board code, and relies on the use ofvarious modeling languages, which are presented in § D.2).The following figure shows a typical development cyclefor a space transportation system, using a MDE approach:Figure 9. Model-Driven Engineering process for a space transportation system2) Software intensive system EngineeringIn launchers systems, the role of the software is more andmore important in functional chains. Furthermore, on onehand the embedded software becomes more complex andharder to master. On the other hand, the introduction of IMA(Integrated Modular Avionic) principles in avionicsarchitecture implies new software rules: use of TSP (Timeand Space Partitioning), distributed software architecture...It is essential to ensure the consistency of the softwareengineering all over the system development. Another veryimportant aspect is to limit the risk and anticipate thepotential problems which could be faced during thedevelopment: early validation shall also be an objective. Tofulfill these objectives, it has been decided, in the context ofthe Avionic-X project, to define a Model Driven Engineering(MDE) process to support the embedded softwaredevelopment.The advantages of using models can be presented asbelow:• Consistency improvement:oModels are more formal than hand writtendocument (misunderstanding limitation),ooModels can be analysed to check developmentrules, to verify properties (softwareverification process improvement)...Model transformation using tools instead ofmanual transformation from documents.• Early validation:ooModels can be executed to verify behaviour ofthe system,Models can be used to ease the build ofvalidation tests.As shown in the ECSS-E-40 [6] following overview (seefigure 10), the planned MDE process will cover all thesoftware development activities from the “software relatedsystem requirements process” to the “validation w.r.tTechnical Specification activity”. In addition to the followingfigure, another activity is essential: the “System datarequirement” which consists in the management (all over ofthe system development) of all data exchanged between thedifferent parts of the software intensive system.

Figure 10. Software engineering process overviewFor each activity, the following models are foreseen:• System data requirements:System related data model that will represent allthe data and interfaces types in a common language(currently an extension of ASN1.0 is envisaged).This model is refined by all teams involved fromtheir unit/dimension until their software interfaceimplementation (taking into account the differentlevel of implementation: equipment software,communication protocol, low level software,applicative software).• Software related system requirementsSoftware-intensive system SysML model whichdescribes the static architecture: definition offunctional blocks, interfaces (data flow and controlflow), mission data and the non algorithmicbehaviour: mode automata, time line, activationcondition, activation frequencies and acyclicactions… this model is independent of the chosensystem architecture (redundancy policy, processingunits …). It corresponds to the System SoftwareSpecification (SSS) in the ECSS wording.Interface requirement Document isautomatically generated from a refinement of theSystem related data model.Software-intensive system design model whichdescribes the processing units, the avioniccommunication means, the physical equipments, thesoftware partitions, redundant equipments, dataflows and their associated latencies, the allocation offunctional blocks to partition, the partition allocationto processing units (AADL 6 is currently envisagedto describe this model). This model corresponds to apart of SRS in the ECSS-E-40 wording.6 AADL stands for “Architecture Analysis & Design Language”, but it isinteresting to remind that at the beginning, AADL stood for AvionicsArchitecture Description Language.• Software requirements & architectureSoftware static architecture model whichdescribes the static decomposition (in terms ofsoftware components/objects) of the software. Thismodel will use UML for manual code and Scade forcode that will be automatically generated. Interfacesbetween the two formalisms will be ensured using theASN1.0 language (and automatically generatedwrappers).Software-intensive system detailed design modelwhich is a refinement of the previous system designmodel. It contains the thread definition, subprograms(interfaces), data flow timing constraints, worst casetiming (bus and subprogram estimations).Interface Control Document is automaticallygenerated from a refinement of the System relateddata model.• Software design & implementationThe implementation will be made usingAutomatic Code Generation (ACG) for interfaces(code skeleton) from UML model, and Scade modelsare refined until containing all the functional aspects(to be able to generate a final flight code).• Validation & Verification related to implementationand modelsOne of the goals of all these modelling activitiesis also to provide early validation and/or automaticreplay/generation of (early) validations activities.The following list is far from exhaustive:ooSoftware-intensive system SysML model: use ofsimulation with a system granularity.Automatic generation of validation tests fromsequence diagrams.Software intensive system detailed designmodel: automatic generation of on-boardsoftware scheduler (or configuration) and fornumerical validation software, TSPconfiguration, verification of all the worst casetiming information (data flow latencies, worstcase execution times …)o Software architecture models: automaticgeneration of integration tests.oSoftware design and implementation: unit test& coverage performed at model level for Scademodels. Use of formal proof (ADA 2012) toreplace some unit test for (suited) manual code.• Models consistencyThe Avionic-X models shall ensure someconsistency between their different views. Part of thework is made by the refinement of the data interfacesdefined in the system related data model. But it is farfrom sufficient.

Intra-model consistency will be verified usingOCL rules for AADL, UML, SysML models. Scademodels will be verified using in-house TCL scripts.Inter-model consistencies have many differentmeans to be verified. Most of them will be assured byusing scripts which will import a version of theinterface and data types. For instance, an Acceleoscript can be written in order to translate an ASN1.0data type in a UML/SysML/AADL data type.Then we have been fine-tuning the requirements andobjectives during the feasibility phase, and a first set of“platform means” has been written down, as shown on figure12, which gives an overview of the global concept ofAvionic-X demonstrator.• Others ModelsIn parallel to these models dedicated to on-boardsoftware development, the MDE activity in Avionic-X willalso cover following modelling: Data handling system withSystemC (data handling system specification: used forspecification verification and simulator generation (forapplicative software development support)); EquipmentSimulator Software Architecture using UML and ASN1.0interfaces (for functional closed loop validation of the onboardsoftware); Algorithm Prototyping Models using inhousecommon formalism (for a faster and safer translationof prototype to on-board software).Figure 12. Overview of the Avionic-X demonstratorIV.AVIONIC-X DEMONSTRATION PLATFORMThe last activity branch of the project shall cover allplatform needs in order to be ready for the first test phase atthe end of the first increment, and shall manage the variousdemonstrator configurations, deriving from the other twoactivity branches (SEL-X and technological enablers, seepart III).The key properties of this demonstrator are modularity,openness and connectivity. It will keep evolving, and will beable to host different demonstrations (unitary or integrated).The “virtual layer” (shown at the bottom of figure 11) andthe simulators will allow several testing configuration, fromSWIL to HWIL.In the Statement of Work, the overview of the platformwas drafted as follows:ELECTRICAL GROUND SUPPORT EQUIPMENT (EGSE)The EGSE is mainly composed of the following subsystems:• The test supervisor based on the AITS (AdvancedIntegration and Tests Services) product which offersthe user interface to control the tests andcommanding activities;• The front-ends equipments which interface with theproduct under test (Time server, Telemetry, Powersupply, Avionic buses I/F…).• The matrix connections whose objective is todispatch the signals between the front ends and theproduct under test taking into account the SEL-Xconfiguration;• The avionic simulators interface with the testsupervisor;I/F I/F I/F• and specific check-out equipments if necessary.SIMULATORS :- FLIGHTSIMULATOR- ACTUATORSIMULATORSAVIONICSDEMONSTRATOR#1AVIONICSDEMONSTRATOR#2AVIONICSDEMONSTRATOR#NOBSERVATIONANDEXPLOITATIONMEANSThe following figure shows how the three activitybranches of the Avionic-X project interact continuously inorder to reach our objectives of TRL and IRL, and buildperformance files for various launcher avionics architectures,based on test results and benchmarks.SIMULATORS FOR AVIONICS FUNCTIONSVIRTUAL LAYER AVQ-X« Avionics » part of the démonstratorAVIONIC-X DEMONSTRATORFigure 11. First draft of an overview of the Avionic-X demonstrator

#3 - Avionics Engineering activities (SEL-X) #1 - Demonstrator Platform activities#1 - Test configurations architectureASTRI UM -STAp pl icatio n SW(inc reme nt 1)UploadEGSE Fr ont EndAvio nics BusesEGSEAvionicssimulator sSensorSensorRT Simulator(PC)SwitchT T TechSwitchPART NER #1MT TT ech#2 - Building Blocks activities (technological enablers )- Modular Data Handling Block (MDHB-X)- Communication system- Model Driven Engineering (MDE)- Navigation- Thrust Vector Control- Sensors and data acquisition- Antennas ...RT Simulator(PC)Log PCEther net1000BASE- TCompa ct PCIBo x (8U)Ap plic atio n SW( increment 1)FCPMPT LIOMAlime ntations22 0VacEGSE F ront EndPower supp liesPo wer switchin gCompactPCIBox (8U)I/F cPCIdataPLC Boxd ata +powerPLC B oxASTRI UM-ST PAR TN ER #2IOMIOMpowerActuatorFigure 13. Links between the three activity branches of Avionic-XV. CONCLUSIONThe Avionic-X project covers a wide range oftechnologies and avionics functions. It will provide a testbench to integrate innovative technologies. Itscomplementarities with other existing programs like FLPPwill allow to contribute effectively to future launcherdevelopments. It was initiated in the frame of the FrenchPIA, but it remains open to the European partners involved inAvionics systems.The development plan is foreseen to adopt iterativecycles in order to integrate new technology demonstrationswhich are not necessarily identified yet. This flexibility willallow, up to 2013, to associate new partners who wouldpropose innovative solutions for launcher avionics.VI.REFERENCES[1] Standish Group (2004) CHAOS Report. West Yarmouth,Massachusetts: Standish Group. (Report).[2] The assert-project, 2008, European Space Agency. http://www.assertproject.net.[3] Avionics Application Software Standard Interface (ARINC-653),AEEC (Airlines Electronic Engineering Committee).[4] Rapport de D. Potier sur les Briques Génériques du LogicielEmbarqué, 7 octobre 2010[5] SPACEBUS 4000 Avionics : key features and first flight return. J-M.Pasquet, 24th AIAA International Communications Satellite SystemsConference (ICSSC) - June 2006[6] Space Engineering – Software, ECSS Standard n°ECSS-E-40(European Cooperation for Space Standardization)

AADLACGAFDXAFRLAVQ-XCNESDALDDASCAEGSEEMCEMIESAFDIRFLPPGNCGNSSGSTPHWILIMAIMUIOMIRLVII. GLOSSARYArchitecture Analysis & Design LanguageAutomatic Code GenerationAvionics Full DupleX switched ethernetUS Air Force Research LaboratoryAvionic-XCentre National d’Etudes SpatialesDesign Assurance Level (according toEUROCAE ED-12B / DO-178-Bstandards)Distributed Dependable Architectures forSafety-Critical ApplicationsElectrical Ground Support EquipmentElectroMagnetic CompatibilityElectroMagnetic InterferenceEuropean Space AgencyFailure Detection Isolation and RecoveryFuture Launchers Preparatory ProgramGuidance, Navigation & ControlGlobal Navigation Satellite SystemsGeneral Support Technology ProgramHardware-In-the-LoopIntegrated Modular AvionicsInertial Measurement UnitInput-Output ModuleIntegration Readiness LevelLVMDEMDHB-XMEMSNGLNGMPOBCPIAPMPOAR&TRTOSUMLLaunch VehicleModel-Driven EngineeringModular Data Handling BlockMicroElectroMechanical SystemsNext Generation LauncherNext Generation Multi-PurposeMicroprocessorOn-Board ComputerPlan d’Investissement pour l’AvenirProcessing ModulePower Optimized AircraftResearch and TechnologyReal-Time Operating SystemUnified Modeling LanguageSAVOIR Space AVionics Open InterfaceArchitectureSAGSAVOIR Advisory GroupSIL Safety Integrity Level (IEC/EN 61508)SPASWILSysMLTCOTRLTRPTSPSpace Plug-and-Play ArchitectureSoftware-In-The-LoopSystems Modeling LanguageTotal Cost of OwnershipTechnology Readiness LevelTechnology Research ProgramTime and Space Partitioning