by Wolfgang Herzner, Martin Schlager, György Csertan, Bernhard Huber, Thierry Le-Sergent, Erwin Schoitsch and Rupert Schlick
The increasing complexity of distributed embedded systems, as found today in cars, aeroplanes and trains, is becoming a critical cost factor in their development. In the European 'Integrated Project' DECOS (Dependable Embedded Components and Systems), an integrated, model-driven tool-chain has been developed to accompany the system development process from design to deployment.
The development of embedded systems still follows a customized design approach, resulting in rather isolated applications, the reinvention of system design concepts, and little reuse of code across application domains. For example, in modern cars each new function implies a new subsystem. While the federated approach supports fault encapsulation, it implies increases in hardware cost, weight and power consumption, and severely hampers the sharing of resources such as sensors.
The European project DECOS has developed basic domain-independent technology for moving from federated to integrated distributed architectures. This will reduce the cost of development, validation and maintenance, and will increase dependability. An integrated architecture is characterized by the inte¬gration of multiple application subsystems (so-called DASs, a DAS may consist of severeal jobs, replicated or not, distributed over a cluster of nodes, forming a single distributed computer system). When integrating (critical) subsystems, it must be guaranteed that they do not dis¬turb each other, and faults must not propagate.
DECOS is based on a settled theory, the time-triggered paradigm. It assumes the existence of a core architecture providing the following core services:
- deterministic and timely message transport
- fault-tolerant clock synchronization
- strong fault isolation
- consistent diagnosis of failing nodes.
Any core architecture providing these services (eg TTP/C, FlexRay or Time-Triggered Ethernet) can form the basis for DECOS systems. On top of these core services, DECOS provides a middleware of high-level services:
- virtual networks (VN) and gateways
- encapsulated execution environment (EEE)
- fault tolerance layer
- diagnostics.
The DECOS system architecture is depicted in Figure 1. A job represents the smallest executable software fragment of a subsystem that can sensibly be distributed and replicated for reasons of hardware fault-tolerance.
DECOS Tool-Chain
For effective use and application, DECOS established a (prototype) tool-chain, which encompasses all phases from model to deployment. It consists of two vertical 'lanes' (Figure 2). On the left, the integrated system configuration is determined and middleware generated, while on the right, the application functionality is developed. A third lane not shown here contains the 'generic test bench'.
The DECOS tool-chain is completely model-based, ie it allows for any generated code to be finally deployed automatically from corresponding models. The specification starts with the platform-independent models (PIMs) of the application subsystems; defining their requirements with respect to performance, dependability and communication among the application tasks.
To ease the tedious task of capturing complex application PIMs, the project has developed PIM-DSE (domain-specific editor), which also exploits pre-defined PIM-patterns, and a visualization tool using GEF (Graphical Editing Framework) of Eclipse.
The purpose of the CRD (cluster resource description) is to capture characteristics of the platform for the software-hardware integration. A graphical, domain-specific modelling environment using the Generic Modelling Environment (GME) eases CRD creation.
The generation of the PSM (platform-specific model) encompasses a number of steps including PIM marking (ie adding information such as the resource requirements of jobs), feasibility checks, and the allocation process for jobs of different criticality to the (shared) hardware platform, subject to constraints of fault tolerance and real time. A PSM generation wizard supports PSM generation.
In the following steps, the middleware is generated. The platform interface layer (PIL) generated from the PSM represents the technology-neutral interface of the middleware to the application software.
The configuration data (eg for scheduling and fault tolerance) is generated by an adapted tool suite (TTplan, TTbuild) from TTTech (a DECOS partner developing time-triggered systems). This handles resource restrictions and EEE partitioning.
SCADE, a certified tool (IEC 61508, DO178B) from Esterel Technologies, is used for behaviour modelling. SCADE is based on a formally defined data flow notation. The PIMs are imported via the SCADE UML gateway, yielding empty job skeletons with correct interfaces. Simulink models are imported to SCADE via another gateway. SCADE is used for code generation; to link job codes with PIL, 'SCADE-wrappers' are generated.
Finally, in the deployment phase, all parts (application code, either generated from SCADE or written manually, generated middleware and configuration data) are put together into executables for the target platform. For the primary DECOS platform (encapsulated execution environment on TriCore TC1796), this is a single file per node that is loaded into the flash memory of the node. The makefile generator tool also takes care of (re)generating the code from the models, thus ensuring they are up to date.
A rather wide variety of tools comprise the DECOS tool-chain from model to deployment. A transformation tool VIATRA (VIsual Automated model TRAnsformations) from the Budapest University of Technology and Economics is used as the backbone for model transformations (PIM to PSM), PIL generation and domain-specific editors.
The tool chain was successfully validated by three application demonstrators from the automotive, aerospace and industrial control domains.
Links:
http://www.smart-systems.at
http://www.decos.at
http://portal.bme.hu
Please contact:
Erwin Schoitsch
Austrian Research Centers/AARIT
Tel: +43 50550 4117
E-mail: erwin.schoitsch
arcs.ac.at
