The 19th IEEE/IFIP International Symposium on Rapid System Prototyping
Using MDE for the Rapid Prototyping of Space Critical Systems Jérôme H UGUES, GET-Télécom Paris LTCI-UMR 5141 CNRS 46, rue Barrault, F-75013 Paris, France
[email protected]
Maxime P ERROTIN European Space Agency, Keplerlaan 1 - 2201 AZ Noordwijk, The Netherlands
[email protected]
Thanassis T SIODRAS Semantix Information Technologies, K. Tsaldari 62, 11476, Athens, Greece
[email protected]
Abstract
Separate tools exist to address specific aspects of these subsystems: synchronous languages, data flow modeling, automata-based models, etc. To build the complete system, one has to integrate the code derived from this model (written either manually, or produced by a code generator) with a real-time kernel on the hardware platform. Tests ensure that all timing and resources constraints are fulfilled prior to delivery. Yet, this later part can be highly time consuming. Detecting resource mismatch at this stage also implies going back to the early stage of the process to correct some models, increasing mission cost and delay. From this consideration, the European Space Agency, along with partners from both the academic and industry domains joined together to form the ASSERT project, in which partners aimed at reducing inherent complexity in the process by taking full advantage of Model-Driven Engineering practice. In this paper, we provide a pragmatic report on the use of MDE for the construction of space-critical systems. We first recall the key steps of the process defined by the ASSERT project. We then list selected technology to support it. Finally, we detail its implementation and assess it on a complete case study.
The reliability requirements for space-critical system call for specific tools and models. Space systems have been a long time user of models (synchronous or asynchronous building blocks), from which code generators could derive analyzable code, while also providing additional benefits like simulation, model checking, etc. However, the integration of multiple models to form one complete system was done manually, in an ad hoc and time consuming way. In this paper, we show how a MDE process built around ASN.1, SDL, SCADE and AADL allows for more rigor by separating concerns to defining data models, functional blocks, interfaces and then behavior of a complete system; and then weave them to build the final systems. By automating the full process, we show the benefits from the system designer perspective: reduced implied complexity, quicker access to evaluation prototype of the end system.
1
Introduction
The construction of space systems revolves around the use of many techniques. Aside typical requirements from embedded systems, one has to come with sub-systems performing intensive computations for navigation maneuver, or control/command logic to handle orders from ground station or to react to on-board sensors. To support the requirements for safety and reliability, different modeling notations exist to first model the system, then evaluate it through simple animated simulation to complete model checking, down to code generation.
978-0-7695-3180-9/08 $25.00 © 2008 IEEE DOI 10.1109/RSP.2008.19
2
The ASSERT process for building systems
ASSERT initially aimed at modifying the way space systems were built, moving from an ad hoc process to a more reliable and rigorous one. Teams might be scattered across Europe, increasing project management issues. The typical pitfalls of that process were:
10
P1 lack of a common repository for storing system’s definition and reasoning about it. This could lead to versionning errors as the project evolves, and difficulties to synchronize teams; but also late discovery of nonfeasibility of some requirements.
C1 The first step of the process implies defining models that represent the system. The choice of a modeling notation is a hard point: many formalisms exist, each of which with its pros and cons. C2 Second challenge is to select the elements to model. Let us recall these elements should complement themselves to allow for both consistency checks, and enable separation of concerns.
P2 tedious and error-prone process to manually integrate multiple source code, either manually or automatically generated. A slight modification in the system usually imply performing this step again, at the expense of the project being late.
C3 Furthermore, to avoid constraining the process, it was decided to first define a generic process, and then “instantiate” it with selected notations. We first review constraints put on the models to be defined.
MDE was selected as way to support the different steps, from the definition of models to model transformations to code generation. The figure 1 recaps the main logic of the ASSERT process. This process is divided up into three phases:
To address these challenges, the ASSERT process defined three complementary views. The objective is to capture and structure “implementation-neutral” information about the system as possible, without constraining the user to select one particular development environment for describing the behavior of his system.
1. A modeling phase, where the developer captures the functional and non functional properties of his system, 2. A model transformation and verification phase, which automatically verifies the feasibility of the system,
• The Interface view helps the user capture his system structure, identify functional blocks, and set nonfunctional attributes to interfaces.
3. An automatic code generation phase which produces a distributed real-time software system that is ready for download on hardware target.
Interface,
func
