by Wolfgang Herzner, Bernhard Huber, György Csertan and Andras Balogh
'Smart systems' applications like adaptive cruise control or brake-by-wire, rely on predictable and reliable embedded system platforms as infrastructure. For the development of such dependable applications, it is therefore of crucial interest to avoid faults during design and development. Besides intensive testing, an important way of minimising the risk of faults is by controlling the design and development process, as well as maximising the coherence of the resulting system with the initial requirements. The model-based tool-chain developed by the DECOS project is described.
Today, the development of embedded - and in particular safety-critical - systems in general follows a customized design approach, resulting in rather isolated applications and little reuse of components and code across different application domains. For instance, in modern cars sub-systems like power-train control, advanced driver assistance systems or the body electronic co-exist, each equipped with its own electronic hardware, communication cabling etc. This approach implies at least increased hardware costs, weight, and power consumption, last not least due to severely hampering the sharing of resources like sensors among the different sub-systems.
Therefore, the European project DECOS aims at developing basic enabling technology for moving from federated to integrated distributed architectures in order to reduce development, validation and maintenance costs, and increase the dependability of embedded applications in various application domains. 'Integrated' means, that several software 'IP'-blocks (Intellectual Property) of different criticality can be allocated to one node (ECU - Electronic Control Unit) without interfering with each other, ie, guaranteed encapsulation in space (memory) and time (each job has its reserved time slot).
DECOS presumes the existence of a core architecture providing the core services:
-
deterministic and timely message transport
-
fault tolerant clock synchronisation
-
strong fault isolation
-
consistent diagnosis of failing nodes.
Any core architecture providing these services (eg TTP/C, FlexRay, or Time-Triggered Ethernet) can be a basis for DECOS-based systems. On top of these core services, DECOS provides a set of architectural (or high-level) services:
-
virtual networks (VN) and gateways
-
an encapsulated execution environment (EEE)
-
diagnostics.
To minimize the dependency of application programming on a certain DECOS implementation, a Platform Interface layer (PIL) provides a techology invariant interface of the high level services for application tasks.
DECOS Tool-Chain
A constituent element of such an enabling technology is a tool-chain, currently being developed by DECOS, which encompasses all embedded software design and development aspects, including configuration and testing. As illustrated in the figure, the DECOS tool-chain essentially consists of two vertical 'lanes': on the left side, the integrated system configuration is determined and middleware is generated, and on the right side the application functionality is developed. A third lane, containing tools for testing and verifying the various (intermediate) results, is not shown.
The specification starts with the Platform Independent Models (PIMs) of the application sub-systems, defining their requirements with respect to communication (among the application tasks), performance, and dependability.
PIMs serve two purposes: firstly, together with the specification of the target cluster hardware and resources, the Cluster Resource Description (CRD), they are used to derive the Platform Specific Model (PSM), which contains allocation (of tasks to nodes) and other information relevant for the successive steps. From PSM, configuration files and schedules for both task execution and message transmission are generated, as well as middleware like the PIL.
Secondly, PIMs are used to guide the development of jobs (i.e. application tasks), by modelling their behaviour with SCADE (a tool set of Esterel Technologies). If feasible, predefined Simulink models or modules written in conventional languages like C or Ada can be imported. After application code is generated from these models, the results of both activities are integrated to achieve the target executables, which can then be downloaded to the application cluster.
The purpose of the CRD (Cluster Resource Description) is to capture the characteristics of the platform relevant for the software-hardware integration. This includes computational resources (CPU, memory), communication resources and dependability properties. A graphical domain-specific modeling environment is developed, based on GME (Generic Modeling Environment). The targeted modeling domain is described formally via the HSM (Hardware Specification Model), a meta model which facilitates the validation and reuse of resource models.
Before generating the PSM, it is possible to add information manually to the PIM (PIM marking), for example information on specific middleware requirements.
Jobs are assigned to nodes taking into account functional and non-functional constraints. In the first phase of assignment, constraints are dealt with one by one. Since allocation is an NP-hard problem, in a second phase a multi-variable optimisation approach is proposed.
Scheduling is the next step, where a tool suite (TTplan, TTbuild) of TTTech (a DECOS partner developing time-triggered systems) has been adapted to handle resource restrictions and EEE partitioning.
Then, PIL is generated, providing generic message transfer, global time service and membership service (necessary to distribute information on the state of nodes).
For behaviour modelling, SCADE (by Esterel Technologies) has been chosen as a primary tool for DECOS. SCADE is based on a formally-defined data flow notation. It offers strong typing, explicit initialisation, explicit time-management and simple expression of concurrency. The PIMs are imported via the SCADE UML gateway, yielding empty job skeletons with correct interfaces. Their behaviour is then directly modelled with SCADE, or Simulink models are imported to SCADE via another gateway. SCADE is used for code generation. For linking job code with PIL, so-called 'SCADE-wrappers' are also generated.
The DECOS tool-chain comprises a wide variety of tools from model to deployment. To ease handling, a transformation tool VIATRA, developed at Budapest University of Technology and Economics, is used as backbone for model transformations (from PIM to PSM), PIL generation and domain-specific editors. Four tools are used for the DECOS tool-chain: GME, VIATRA, SCADE and TTplan/build; additionally, commercial and target-platform specific tools are used for deployment (compilation, linking, download). This tool-chain is designed for efficient configuration, development and validation of critical 'smart' embedded applications.
Links:
http://www.smart-systems.at
http://www.decos.at
Please contact:
Wolfgang Herzner, ARC Seibersdorf research/AARIT, Austria
Tel: +43 50550 4132
E-mail: wolfgang.herzner
arcs.ac.at
Bernhard Huber, Vienna University of Technology, Austria,
E-mail: huberbvmars.tuwien.ac.at
György Csertan, Andras Balogh, Budapest University of Technology and Economics
E-mail: {csertan, abalogh}mit.bme.hu
