DOMAIN SPECIFIC LANGUAGES FOR EFFICIENTSATELLITE CONTROL SOFTWARE DEVELOPMENT

Andreas Wortmann, Martin Beet

OHB System AG, Universitätsallee 27-29, 28359 Bremen, Germany,Email: andreas.wortmann@ohb.de Tel.: +49 (0)421 2020-9815

ABSTRACT

We present the motivation and an approach for theefficient development of satellite control software(flight software, onboard software) based on domainspecific languages. Significant technological advancesin the field of language workbenches have enabled us todevelop extensions to the C programming languagespecific to the needs of satellite flight software. Theapproach is very promising as it combines the flexibilityand efficiency of the C language with high-levelabstractions known from modeling-tools and allows foradditional adaptation specific to the space domain.

1. INTRODUCTION

Inefficiencies identified in earlier projects give reasonsfor improvement in various fields, including everythingfrom tools and processes to code reuse. Stepping backand reassessing the actual needs while observing thecurrent developments of embedded software technologyand the scientific community has brought up the idea ofdeveloping a domain specific language (DSL) thatperfectly matches the demands of satellite controlsoftware.The intention behind DSLs is to concentrate on theessence of a domain and introduce first-classprogramming language constructs with semanticsclosely related to that specific domain. Separation ofconcerns is achieved by introduction of various(composable) DSLs, each focusing on independentconcerns. This is combined with the idea of modelbased development, where a model serves as (single)source of information for many derived artifactsincluding the executable, the documentation andanalyses etc. With the tools used the boundary betweenthe model and the implementation becomes increasinglyfuzzy. Analysis and visualization techniques that areusually applied to the model become applicable to theentire implementation. Additionally, implementation-level code refers directly to elements usually regardedas part of the model.Essentially, a single artifact (which is both, the modeland the implementation) is used to derive all requiredrepresentations, including C code, documentation, andconfiguration.The following steps are taken to achieve thisimprovement:• identify the key issues that result in inefficiency• identify the essential needs of the application domain• identify the technology for improvement• a prototypical implementation to prove the idea

They are described in the subsequent sections.

2. KEY ISSUES IDENTIFIED

The major fundamental issues identified in recentprojects are related to both, tooling and process. Someof these are closely related to the selected approach,leaving it impossible to mitigate within an ongoingproject.Although tooling and processes are interrelated to somedegree by nature, some specific examples are discussedin the following distinct subsections. 2.1. Tooling

Model-based design tools such as IBM Rhapsody,Enterprise Architect, Sirius and others define a modelby composition of UML elements, creating structureand behavior diagrams. These are enriched withmanually written implementation code in a “regular”programming language such as C or Ada. Structural andskeleton code is generated from the UML model andmanually written code is inlined. This duality of inlinecode and the model specifically makes theimplementation hard to maintain, debug, document,review and analyze as both parts are only looselycoupled. Specifically, they are maintained with twodistinct tools.Software unit tests are developed and executed usingrespective tools such as Cantata++ or IBM RTRT.These test supporting tools in general are not directlyinterfaced with the UML model, thus they can't drawany information from the model that would support testdefinition, quality, evaluation and reporting.Software validation tests, as well as satellite validation,AIT and operational procedures, are developedtechnically independent from the satellite controlsoftware. As a consequence test coverage is hard todetermine and changes of the software are not directlyvisible to the various stakeholders. Maintaining tests,AIT and Ops procedures requires elaborate changeprocesses including iteration cycles and manual review.

2.2. Processes

Information that is commonly used onboard as well ason-ground is maintained in a central data repository, theSatellite Database (SDB). This central repository is usedas an external model to the flight software. Code andconfiguration data is generated from the SDB and linkedwith the flight software in a later step. Consistency ofthe SDB content and the software technically can't beassured until the entire software is compiled, linked andvalidated. As this is rather late in the process, bugs aredetected late and fixes are costly.

_______________________________________ Proc. ‘DASIA 2016’, DAta Systems In Aerospace Tallinn, Estonia, 10-12 May 2016 (ESA SP-736, August 2016)

In order to be self contained and complete, the Satellite-to-Ground Interface Control Document (SG-ICD)contains – among other things – the definition of validcommands, parameters, arguments, attributes andpossible failure codes, all of which are relevant to thesoftware development. In order to ensure full validation,the SG-ICD commonly is made applicable as a sourceof requirements. Since large parts of the SG-ICDincluding the failure codes are driven byimplementation details this may result in a circulardependency, calling for requirement change requestsuntil very late in the process.

3. ESSENTIAL NEEDS OF THE DOMAIN

The high-level essential needs that a satellite controlsoftware development and maintenance process has tofulfill are the “usual suspects” of optimizing codequality, development time, cost-efficiency and V&Veffort while allowing late requirement changes and earlyprototyping (Faster, Later, Softer). When focusing onthe technical details of how to achieve these goals, thearguments discussed in the following are split into twogroups: design and development considerations andgeneric building blocks of the software, called softwareelements.

3.1. Design and Development Considerations

As a developer you are generally driven by scheduleand cost and at some point in the project you just haveto “get it done”. As a consequence, a preferred way is tobase a software design on experience and heritage fromearlier systems and consolidate these with the customerneeds. On the other side you have to develop accordingto (external) guidelines, nomenclature and processes,as for example MISRA [11], OSRA [7], SOIS [12],PUS [8] as well as company coding guidelines.Introducing new rules and standards naturally requiressome (learning) effort and may lead to hesitance oropposition. To successfully introduce and apply suchstandards, as much of the theoretical backgroundimposed as possible needs to be made transparent to theuser. Furthermore, user-optimized IDE support withrespect to the applicable standards is appreciated.The implementation must comply with quality criteria,such as those imposed by the ECSS. This generallyincludes software unit testing, validation tests,conformance to code metrics and a schedulabilityanalysis. The software architecture and implementationshould be designed with respect to test and analysis.This facilitates achieving the required quality standardsand reduces the effort needed to obtain the expectedlevel of quality.A precise and detailed design documentation, a usermanual, a satellite-to-ground ICD and other documentsneed to be provided and maintained. It is crucial thatthese documents are always consistent with the actualimplementation. Well-considered structuring andwriting and a large share of auto-generation is needed inorder to obtain high-quality documents. Maintainingsignificant parts of the documentation as close to theactual implementation as possible and generating

figures and tables directly from the implementationcode supports this process.

3.2. Software Elements

A number of software building blocks, elements andpatterns are very common to any satellite controlsoftware. What follows is a non-comprehensive list ofsuch elements.Component-based software design is state-of-the-artand eases the test, validation and reuse of the softwarebecause components are self contained with well-defined interfaces. Recent initiatives including theOSRA and SOIS are all based on components.Components comprise attributes and define functionalbehavior that may be exposed and provided to othercomponents and/or ground.Functionality commonly is described as a sequence ofactions. Such sequences can be invoked internally fromthe software as well as via telecommand from ground.In general, sequences depend on functionality spread allover the software and multiple independent or inter-related sequences may be executed concurrently.Actions (especially when accessing hardware) may besubject to hard real-time constraints or may requiresynchronization with external stimuli.Periodic (e.g. autonomous functions and checks) andaperiodic functionality (e.g. telecommands and otherexternal stimuli) needs to be executed. Typically thesoftware comprises a base frequency and a number ofderived frequencies for execution of distinct and real-time sensitive repetitive functionality. Additionally,non-timing critical and sporadic functionality isexecuted concurrently. The task design and thescheduling scheme and algorithm is strictly designedaccording to the requirements of the timing criticalactions and functions.Commandability and observability of the satellite isachieved through a satellite-to-ground interface fortelecommanding and telemetry. It is typically based onthe PUS [8] but proprietary protocols or (in the future)CCSDS MO [9] are alternative options. Muchinformation, such as the types and numbers of thearguments, describing telemetry and telecommanding isrequired onboard as well as on-ground.It has been shown to be advantageous to define modesof operation for the entire satellite control software aswell as for its constituent components. A mode in thissense is a special component attribute used to affect thecomponents behavior in a consistent and common way.For example telecommands may only be executed incertain modes or periodic activities are always activatedin selected modes.Last but not least a well elaborated failure detection,isolation and recovery (FDIR) concept must be realizedsupporting redundancy schemes as required to achievethe needed overall reliability. Incorporating such aconcept right from the beginning, when thinking aboutthe software architecture, is necessary but rarely done.

4. DOMAIN SPECIFIC LANGUAGES

The emerging technology of Domain SpecificLanguages (DSL) and their development environments,so called language workbenches, has great potential tomitigate many of the listed inefficiencies and effectivelyfulfill the essential needs outlined above. The essentialidea is to concentrate on the specific needs of aparticular domain and provide efficient means forexpressing the solution of a problem in a language (ormore generally: by some distinct notation) known to thedomains professionals. Aspects of the implementationthat are self-evident or repetitive (in that specificdomain) are abstracted away. In practice the user (e.g.the implementer) does not need to keep them in mindand is able to focus on the essential objectives. Thehigh-level and domain specific abstract description ofthe software objectives is automatically transformedinto various concrete representations includingimplementation code, documentation or input foranalyses tools. Essentially the implementation is amodel comprising everything.The idea behind this approach is fully in line withstatements by F.P. Brooks in his paper "No Silver Bullet– Essence and Accidents of Software Engineering" [5].The idea of introducing a compiler for writing computerprograms in a human-readable language rather than in aseries of '0's and '1's is merely taken to a level whereeven more accidental complexity is removed from themanual work share. This is achieved by shifting moreknowledge about the applications domain (which is howto operate a satellite) into the language semantics.Also the idea addresses the findings and proposals ofthe NASA Study on Flight Software Complexity [10].Once a DSL has been developed for the specific domainof satellite control software, the gap betweenspecification and implementation in our projects isnarrowed significantly. Fig. 1 illustrates the greatadvantages of this increase in abstraction.Basically, the software implementation focuses on theessential functionality rather than on the details ofrealization. A well-designed DSL allows describingwhat the software shall do without the possibility to

introduce ambiguities. A subsequent transformationprocess generates C code (in the case of satellite controlsoftware) that is compiled to the executable using theestablished tool-chain.

5. MPS AND MBEDDR

Jetbrains' Meta Programming System (MPS) [1] is alanguage workbench [13] (DSL DevelopmentEnvironment) that is open source and freely available. Itapplies projectional editing. This overcomes the limitsof language parsers and allows editors to include tables,mathematical symbols and graphical diagrams. The userdirectly modifies the abstract syntax tree (AST),respectively the implementation model, which isprojected onto the screen, see Fig. 2.

Different visualizations can be selected, depending onthe current needs, all representing (parts of) the samemodel. Since a parser is not engaged, languages arecomposable by construction and can be arbitrarilymixed in an implementation.

Figure 1: Pyramid of Abstraction

Figure 2: Projectional Editor

Languages in MPS consist of an abstract syntax (thestructure), a type system, a set of constraint rules,(multiple) editors and model-to-model as well as model-to-text transformations, compare Fig.3. As the MPSframework is open for extension, it can be easilyaugmented to interface with various external tools. Forexample, analysis tools are directly integrated and theirresults are reported in the editor. The AST is theimplementation model which is transformed via anumber of (model-to-model) transformation steps into atextual representation. In the case of satellite controlsoftware this could be C code for further processing bythe compiler. During the transformation processavailable MPS languages can be used and the entiremodel is available for queries for efficienttransformation results.The mbeddr project [2] is based on MPS. It provides alanguage in MPS that looks exactly like the C language,has the same semantics and transforms into C code forthe compiler to process. The advantage of having the Clanguage available as an MPS language (calledmbeddrC) is that it is now possible to extend thelanguage with domain-specific abstractions, while at thesame time being able to write low-level C code whennecessary. A number of such extensions including finitestate machines, documentation, requirements tracing,model-checking, visualizations etc. have beendeveloped as part of the mbeddr project. The mbeddrstack of extensions is shown in Fig. 7. mbeddr is

available as open source software, professionallymaintained by Itemis AG [6] and has been successfullyapplied within commercial projects as reported in [4].

6. A PROTOTYPICAL IMPLEMENTATION

Based on the technology provided by MPS and mbeddr,a set of DSLs is currently being developed by OHB inthe scope of R&D activities. The DSLs capture andefficiently implement the crucial elements of satellitecontrol software. Redundant and repeatedly appliedaspects are captured in higher level abstractions (first-class DSL constructs). The DSLs are modular in termsof the addressed concerns. This, together with a fullyintegrated development environment providing state-of-the-art user guidance and team development support,results in a highly efficient approach to softwaredevelopment.The DSL design is mainly influenced by heritage fromearlier projects carried out at OHB (Small Geo Platformand Galileo), the ESA SAVOIR initiative OSRA [7] andthe ECSS Packet Utilization Standard (PUS) [8].Programs written in the DSLs are compliant to theECSS standards and quality requirements.According to the list of software elements as presentedin section 3.2 the mbeddrC language is extended withhigher level concepts. Appropriate structure, editorrules, type system and constraints are defined. Finally,transformation rules are defined for generating C codeand documentation.

Figure 3: Language Definition

Figure 4: mbeddr Stack of Extensions

Figure 6: Thermal Control Component

Figure 5: Temperature Acquisition Component

1

3

2

4

5

7

9

10

11

12

14

15

6

8

14

13

13

15

17

18

19

16

Components as basic structural element and theirinstances are first-order constructs. Besides otherelements the components contain attributes, mode-charts and activities. Fig.5 and 6 show screenshots of animplementation based on DSLs extending the Clanguage. Everything that does not look like C belongsto a language extension. The used elements are brieflydescribed in the following. Fig.5 depicted the implementation of componentTemperatureAcquisition and two instancesof this component . The component is assigned amnemonic (TACQ) that is reused and augmented with amnemonic tail (A and B) by the instances. The resultingcomponent instances' mnemonics (TACQA and TACQB)are derived and projected into the editor. For addressingpurposes unique numeric Ids (350 and 351) areprovided with the instances. The componentimplementation comprises mandatory (short andregular) description fields which are required for thegenerated documents. The component is assigned to theEPL.PDF (Platform Devices) layer which isone of several predefined layers and has the same intentas that defined in the OSRA . The layer technically(enforced by the editor) restricts access to other layers'component instances.Furthermore the component defines three attributes ,by convention (and technically enforced by the editor)they are all capital letters. They act as variables local tothe component instance which may be configured to beaccessible by ground via a dedicated Service. For thispurpose, attributes are marked either 'hidden', 'readonly'or 'readwrite' and – if not hidden – are assigned anumerical Id for identification via the space-to-groundprotocol. Note that the entire data pool maintaining theattribute values and their access by other componentsand via telecommands from ground (PUS 3 and PUS 20services) is not mentioned here. It is abstracted from theDSL-level implementation and generated during model-to-model transformations. Thus, the implementationonly focuses on the essential concern, which is theprovision of an attribute. Like a regular C variabledeclaration an attribute is assigned a data type and maybe initialized. The editor requires the implementer toadd documentation. An attribute can be initializeddifferently for each component instance. In the examplethe attribute SENSOR (which is of enum typetempSensor) is initialized differently for bothinstances. Together with the instance's mnemonic theattributes are uniquely addressed in a hierarchical wayusing a dot expression syntax . In the example theattribute AVTEMP from instance PUS150 is accessed(see Fig. 6 for its definition).The yellow annotation /rawTemp/ to the datatypeof the array is part of a language extension that allowsassociating a physical unit to the values carried in thisvariable. Here the value represents a raw value readfrom the thermal sensor. In Fig. 6 attributes areassociated with centigrade . The ModeChart statement implements a simplekind of state-chart efficiently capturing the idea thatevery component may reside in an operational mode.This mode is changed by dedicated statements invoked

in the activities . The ModeChart in Fig.5 defines twomodes (OFF and ON) and a trigger. Mode OFF does notdefine any behavior, but mode ON has an entry actionand an action that is associated with the triggertcsAcquisition. When entering this mode the(hidden) attribute ACQCNT is initialized. When thetrigger is invoked (by a periodical task/thread not shownhere) a temperature value is read from the sensor and anaverage of the last 10 measurements is calculated.While invoking a function for reading the temperaturevalue, calculating the index and accessing the array forstoring 10 values is regular C code the calculation of theaverage temperature uses an extension that providesmathematical symbols . This extension allows

to be an expression that is transformed into a respectiveloop for doing the calculation. Projectional editingallows the mathematical symbol to be made visible inthe editor. The mathematical formula is wrapped with aconvert[ … → °C] statement. This is part of thelanguage extension that provides physical units as usedat . It converts the value from rawTemp to °C asdefined for example in the following sketchedconversion rule:

If expressions are assigned to variables with a non-matching physical unit the typing rules of the languageextension report the error in the editor directly atimplementation time. Functionality is implemented by ActivityS inside acomponent. The activities shown in Fig.5 are rathersimple and their representation in the editor is folded forbrevity . Fig.5 shows a simplified component for acquisition oftemperature values and calculating an average. Twoinstances of this component are realized. Thecomponent shown in Fig. 6 uses these instances, itrealizes a very simple thermal control system that isable to use either one of the component instances foracquisition.The component ThermalControlSystem as shownin Fig. 6 implements a service according to the PUSstandard. The component statement is markedaccordingly and is provided with a PUS type (150). Inorder to make this more visible in the editor, thebackground is colored yellow. Services are onlyinstantiated once and their mnemonic is PUSxxxwhere xxx is the assigned PUS type . Thecomponent is assigned to the AL (ApplicationLayer) and as such is allowed to access theTemperatureAcquisition instances assigned tothe Platform Devices Layer .The ThermalControlSystem component defines aModeChart. It is visualized in Fig. 7. The visualizationis generated directly from the implementation by

1

2

1

3

4

5

7

7

6

6

8

9

10

316

invoking an external tool from within the IDE. It – bynature – is always consistent with the implementation,such that code review actually can be carried out usingthe printed documentation.

Figure 7: ModeChart

In mode OFF the control is inactive. In mode ON itreacts on the trigger tcsControl, which isperiodically invoked in the context of a periodictask/thread. In this trigger action the commanding forthe heater lines is determined by comparison of theaverage temperature PUS150.AVTEMP with thethresholds PUS150.LOTH and PUS150.UPTH. Thecomparison and the resulting heater command isrealized using a language extension that provides adecision table . Depending on the booleanexpressions on the rows and columns a value is selectedand returned. The shown example is a very smalldecision table. The mentioned component attributes are associated with the physical unit °C ensuring thatthe check is carried out on comparable values.The ThermalControlSystem service defines twoactivities that define functionality . Each activity isassigned a numerical id, name and description fields. Asthere is only a single instance of this component(service) its activities can be marked a telecommand.The telecommands PUS compliant type identifier isderived from the services numerical id by definition andthe subtype identifier is the activitiesnumeric id .An activity may be constrained by a set ofboolean expressions , only if all of themevaluate to true when invoked, the activityis actually executed. If an invoked activitydoes not fulfill a constraint a failure codeis returned instead. The failure code isunique and derived from the numerical idsassigned to the component instance andthe activity according to the structure ofthe software. In the example the mode ofthe ModeChart TCSCONTR is required tobe OFF or ON, respectively. An activitycan define input and output parameters ,telecommands are restricted to input

parameter due to limitations of the PUS. Such parameterare typed and mandate a description field. In-parametersmay define a constraint, for validity checking. The in-parameter constraint is a boolean expression and actssimilarly to the activities' constraint. In the exampleactivity shown, TC(150,1)enableTcs is onlyexecuted with the components mode being OFF and thepassed in-parameter upperThreshold is larger thanthe passed in-parameter lowerThreshold.

The invocation of activities is according to the MOMAL interaction pattern [9]. Based on an executionframework middleware, the activities are invokedasynchronously. The adaptation to the middleware isgenerated as part of the transformation process.Depending on the middleware the software is expectedto be operated with, different sets of transformationrules may be applied. The implementation itself isdesigned independently of the middleware. In Fig. 6 theactivity enableTcs uses the REQUEST pattern toinvoke the startAcquisition activity of theaddressed TemperatureAcquisition componentinstance . The REQUEST pattern allows in- and out-parameters to be transmitted and the respectivestatement may specify a block of code that is to beexecuted if a failure indication is returned. The controlflow requires the invoked activity to complete executionprior to the invoking activity to continue. In contrast,the SEND pattern asynchronously invokes an activityand does not wait for any acknowledge. Fig. 8 shows asequence diagram visualizing the telecommandsimplementation. Again, this picture is generated fromthe implementation using an external tool from withinthe IDE.The telecommand (TC) Dispatcher is not shown in thecode. It is aware of all telecommands defined in thesoftware by querying the implementation. Via modeltransformation the needed telecommand dispatchingharness is generated, enabling invocation of the activityvia TC packets received.The activity delays enabling of the thermal control by10 seconds using the DELAY statement , whichtransforms into respective delay functionality providedby the framework. The last statement of thetelecommand shown in Fig. 6 is the TELEMETRYstatement . It defines a telemetry packet (again,

11

12

14

13

15

15

17

18

19

Figure 8: Sequence Diagram

according to PUS) by specifying a mandatorydescription, a subtype (the type is inherited from theembracing service) and a list of typed parameters. Onlythis statement defines the telemetry packet, otheroccurrences merely refer to it. During code generationthis statement is transformed into an activity invocationaccording to the SEND pattern. The activity responsiblefor preparing and transmitting a telemetry packet isinvoked as shown in the sequence diagram in Fig. 8.The corresponding arrow in the figure is annotated with“queue=10”. This indicates that the activity provides aqueue, allowing different parts of the software to invokethe activity and respective invocations being queued.Again, the concrete realization of the queue is not partof the implementation, it is part of the transformationrules defined in the DSL statement with respect to aselected middleware.From the implementation not only executable code isgenerated. As briefly summarized in Fig. 9, otheraspects are covered also. A dedicated DSL allowsefficient requirement tracing, state-of-the-art softwarerevisioning enables efficient team collaboration andissue tracking. The implementation serves as source fordocumentation generation and the configuration of the(ground-) operator software system. Dedicated DSLsare developed for the inclusion of unit tests andanalyses. While mbeddr already provides means toshow formal properties of certain state machines anddecision tables, we are currently working on a DSLlinking the implementation with static worst caseexecution time (WCET) and schedulability analysis.

Figure 9: Linked and Generated Aspects

As the implementation contains the entire designinformation and arbitrary queries can be executed, it isfeasible to simplify the data dependencies and as aconsequence the overall workflow. Circular and overlycomplex process-related dependencies with respect tothe Satellite-to-Ground ICD and the Satellite Databaseas described in section 2.2 are simplified.

7. SUMMARY AND OUTLOOK

A significant increase in development efficiency andquality is achievable when the focus of workconcentrates on essential aspects and recurring effortsare abstracted.In recent years the technology of domain specificlanguages and language workbenches has reached alevel of maturity that allows its application in the fieldof embedded, real-time, mission-critical flight software

of spacecraft. In addition to what is accomplished bylibraries, language extensions provide custom syntaxand type systems as well as the possibility to introducestatic error checking. Context sensitive model-to-codetransformation allows for optimized code generationresulting in run-time and memory efficient code.Compared to other concepts the approach is non-disruptive as it builds upon the C language andexperienced developers feel comfortable. Establishedtools and analyses can be introduced smoothly. Theprojectional editing and introduction of higher levelabstractions cause the concepts of modeling andimplementing to become somewhat blurred, takingadvantages from both.The work carried out and prototype developed hasshown that the approach and the tooling is verypromising. It bears great potential for improving currentworkflows. Up to the present and while significantelements and aspects of satellite control software havenot been tackled, the full advantage has not been drawnfrom the approach. Nevertheless, the DSL basedapproach of embedded software development has beenreported very successful in a commercial environment[4]. It is expected to achieve improvement results ofsimilar magnitude and quality.The next step in evaluation is to cover the entire life-cycle (requirements engineering, architecture design,implementation, validation and operation) and all majorfunctional aspects of in an exemplary satellite controlsoftware implementation.

ACKNOWLEDGMENTS

This work is based on the technology provided byJetbrains MPS [1] and the mbeddr project [2]. It hasbeen carried out in the scope of the ARTES 11Subelement 3 project under ESA contract number20619/2007/F/W.

REFERENCES[1] Jetbrains MPS, www.jetbrains.com/MPS[2] The mbeddr project, www. mbeddr . com [3] M. Völter, DSL Engineering, www. dslbook.or g ,

2013.[4] M. Völter et.al., Using C Language Extensions for Developing Embedded Software: A Case Study, OOPSA2015[5] F.P.Brooks, No Silver Bullet – Essence and Accidents of Software Engineering, Proceedings of the IFIP Tenth World Computing Conference, 1986[6] Itemis AG, www.itemis.de[7] SAVOIR-FAIR–OSRA, Onboard Software Reference Architecture, TEC- SWE/09-289/AJ [8] ECSS-E-70-41C, Packet Utilization Standard, 2014[9] CCSDS 521.0-B-2, Mission Operations– MAL, 2015[10] D.L.Dvorak et al., NASA Study on Flight Software Complexity, Final Report, March 2009[11] MISRA, www.misra-c.com[12] CCSDS 850.0-G-2, Spacecraft Onboard Interface Services, December 2013 [13] Language Workbench Challenge, www.languageworkbenches.net