New Solutions for In-Vehicle Embedded System Development

by Françoise Simonot-Lion and Yvon Trinquet

While automobile production is probably to increase slowly in the coming years, the part of embedded electronics and more precisely embedded software is growing. New solutions for the development of in-vehicle embedded systems was the purpose of the French 'Embedded Electronic Architecture' cooperative research and development program 'AEE'. The results are the identification of embedded component classes, the specification of a generic embedded architecture, as well as the definition of a declarative language.

Today, functions embedded in vehicles include braking assistance, active suspension, steering functionalities, etc. They are subject to stringent timing constraints and more generally to dependability constraints. In the close future, these constraints will be more critical with the generalisation of X-by-Wire technology. Therefore the development of such systems must define an eligible system, ie, satisfying these constraints, and must provide the best one according to cost criteria. Furthermore, the development process of an embedded system is shared between several actors: carmakers and suppliers; the development of reusable components is a main way for the reduction of costs.

In this context, the French 'AEE Project' (EEA in English: 'Embedded Electronic Architecture') specified new solutions for the development of in-vehicle embedded system. This program (September 1999 - December 2001) was granted by the French Under-Ministry for Industry and involved the French carmakers (PSA and Renault), OEM suppliers (SAGEM, SIEMENS, VALEO), the company EADS LV and the research centres INRIA, IRCCyN and LORIA. The European ITEA project (EAST-EEA) - currently in progress - extends and generalises these results.

Electronic Embedded Architecture and its Components
Most of the hard and software embedded in a car are specified and developed separately. Each one is dedicated to a particular feature and designed by a supplier with respect to carmaker requirements. On the one hand, this is a bar to the reusability of solutions in other projects and on the other hand, this leads to oversize the resources (hardware, buffers, etc). To solve this problem, the AEE project characterised formally the basic embedded components and defined the perimeter of the reusable ones. Furthermore it provided a generic architecture for an Electronic Control Unit (ECU), a station connected to one or several network(s) and supporting the embedded application (see Figure 1).

Figure 1: component classes and generic architecture.

Some components are independent of a particular ECU; this means that they can be implemented on any ECU in a distributed architecture:

• sensors and actuators (hardware components) and software components (Local Device Manager) realising the signal processing for these devices
• software components implementing the specific embedded application (Application Software Components).

On the contrary, the Input/Output drivers, the Software Components implementing the Operating System (OS) or the Communication Services are dependent of a specific ECU.

Finally, in order to ensure an entire independence of Application Software Components, a specific component, named Inter Component Exchange Manager was specified. It plays the role of a middleware, in particular by providing transparent communication services. This component is developed specifically for each ECU with a common Application Interface.

AIL_Transport: a Language for the Design of Embedded System
The project defined a specific development method for embedded systems to reduce costs and optimise the use of hardware elements. At the first step, functionalities are defined and validated independently of their implementation (Functional Architecture and Software Architecture). Then an allocation mechanism maps the specified functions onto the ECUs of the embedded architecture and subsequently, some exchange flows onto communication networks (Hardware Architecture). Finally, local task execution and frame transmissions are optimised (Operational Architecture). With this approach, capitalisation no longer focuses on ECUs, but on the implemented functions through validated hardware and software modules.

Strong co-operation between OEM suppliers and carmakers in the design process implies the development of a specific concurrent engineering approach. In order to specify this process, synchronisation points (rendezvous) across the co-operative development model have to be identified and information exchanged at these points must be characterised. Furthermore, a unique syntax of the exchanged information has to be defined. For this, the AEE project has specified a business model specifically adapted to the architecture development conjointly by carmaker(s) and OEM supplier(s).

Figure 2: AIL_Transport principles.

Performance of a vehicle embedded system may be evaluated from different points of view, according to the system analysis (wholly or partly) necessary at each development step. Usually carmakers attempt to optimise the number of ECUs, which are used to implement the vehicle functionalities. Furthermore, system designers attempt to optimise performances of communication networks. Finally, OEM suppliers have to demonstrate that their COTS are compliant with the carmaker requirements, etc. The AEE approach improves these different analyses and optimisations by enabling the use of various industrial and academic software tools. These tools are dedicated to analyse, test, simulate, validate, comment, and generate code of the electronic architecture. For that, each tool extract a specific and coherent model from the architecture description by means of a repository integrating all the pertinent data of the architecture modelling. This repository is the skeleton of the AEE development process, as shown in Figure 2. In order to build this repository, a language for the specification of any electronic architecture has been defined. It is called Architecture Implementation Language (AIL_Transport). The AIL_Transport language integrates the AEE design process, and thus is used by all designers as the backbone of the architecture development. Moreover, AIL_Transport is the source language to define the reusable architecture objects.

Associated to AIL_Transport, a development process has been specified for defining and harmonizing the exchanges of partial architectures between carmakers and OEM suppliers. The main benefit of this study is to allow the design of flexible architectures while reducing costs and increasing the quality of the development. At present, the results obtained in AEE project are one of the entry points for an ITEA European project (EAST - EEA), gathering the main actors of European automotive industry.

Please contact:
Françoise Simonot-Lion, LORIA
E-mail: Francoise.Simonot-Lion@loria.fr

Yves Sorel, INRIA
E-mail: Yves.Sorel@inria.fr

Jean-Pierre Elloy, Yvon Trinquet, Institut de Recherche en Communications
et Cybernétique de Nantes (IRCCyN), France
E-mail: Jean-Pierre.Elloy@irccyn.ec-nantes.fr, Yvon.Trinquet@irccyn.ec-nantes.fr