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

More documents

Recommendations

Info

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.
Page 2 and 3: 3 Distributed Dependable Architectu
Page 4 and 5: in a rack-based architecture (follo
Page 6 and 7: Taking this into account, we will d
Page 10 and 11: Intra-model consistency will be ver
Page 12: AADLACGAFDXAFRLAVQ-XCNESDALDDASCAEG

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

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?