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

More documents

Recommendations

Info

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.
Page 2 and 3: 3 Distributed Dependable Architectu
Page 6 and 7: Taking this into account, we will d
Page 8 and 9: The MDE covers the whole range from
Page 10 and 11: Intra-model consistency will be ver
Page 12: AADLACGAFDXAFRLAVQ-XCNESDALDDASCAEG

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

Create successful ePaper yourself

Delete template?

Save as template?