Marco Panunzio

Application of Model-Driven Engineering to the Development of On-board Software: Benefits and Challenges

Marco Panunzio and Tullio Vardanega

ESA Workshop on Avionics Data, Control and Software Systems (ADCSS 2008)

Presentation

Abstract

The validation-intensive nature of high-integrity real-time systems makes the adoption of Model-Driven Engineering (MDE) less obvious than in other industrial domains. In this presentation we discuss some of the obstacles to remove.

Dispelling MDE fads. For MDE to be intelligently used for high-integrity real-time systems, some essential characteristics must be actively sought: (i) separation of concerns, to help designers acquire intellectual control on the aspects of their specific pertinence without the need or the pretense to master all system and software aspects; and (ii) correctness-by-construction, to warrant proactively (as opposed to a posteriori) the consistency of all the models that compose the system and to ensure the preservation of properties throughout the development until run time. Models are the means to promote and attain focus of attention (hence simplification) and abstraction. The use of a graphical notation per se is neither sufficient nor desirable, unless it increases the expressive power availed to the designer. Creating models may otherwise become as complex and error prone as writing code in (unfamiliar) languages. The abstraction level availed to the designer may be raised by favoring the use of libraries of pre-built components (tantamount to the reuse of models) as well as of MDE-geared design patterns, which address and provably solve recurrent domain-specific problems in a fashion coherent with principles (i) and (ii) above.

Highlighting the added value of MDE. In an on-board system, parts of the code are inherently archetypal, thus rigidly defined and with little or no implementation freedom (e.g., concurrency-related code). Other parts leave more space to expert skills (e.g., control-related algorithmic code). An MDE incarnation suited for the space domain should have designers solely focus on the parts that benefit from their expert contribution; all other aspects should be left to proven automation. That decision should earn increased productivity and less defects.

Coping with heterogeneous models. The models used and produced by the various actors in the development team are likely to be heterogeneous in scope, content and formalism. Models may address different aspects (often called "views") of the system and also be the product of view-specific formalisms and technologies. A possible yet undesirable consequence of this situation is that models may be incompatible in either technology or (worse) semantics. The most feasible way to defeat this risk is to acknowledge heterogeneity and require that models be provably composable: this is easier to ensure if all metamodels that underpin the user models address non-overlapping aspects (and thus separate concerns).