Image Processing Reference
In-Depth Information
A first step to define a standard for in-car embedded MW was started by the OSEK/VDX
consortium (http://www.osek-vdx.org) . In particular, two specifications are of particular interest
in the context of this chapter: the “OSEK/VDX Communication” layer [] and the “Fault-Tolerant
Communication (FTCom) layer” []. The first one specifies a communication layer [] that
defines common software interfaces and common behavior for internal and external communica-
tions between application components. How signals are packed into a frame is statically defined
off-line and the OSEK/VDX Communication layer automatically realizes the packing/unpacking at
run-time as well as the handling of queued or unqueued messages at the receiver side. OSEK/VDX
Communication runs on top of a transport layer (e.g., Ref. []) that takes care mainly of possible seg-
mentation of frames and it can operate on any OS compliant with “OSEK/VDX OS” services for tasks,
events, and interrupt management (see Ref. []). Some questions deserve to be raised. In particular,
communications between application processes that are internal to one ECU or located in two distant
ECUs do not obey exactly the same rules (see Ref. [] for more details); thus, the designer has to take
into account the distribution of the functions, which is a hindrance to portability. Finally, OSEK/VDX
Communication does not obey fully to a TT approach and is not intended to be used on top of a TT
network, as for example TTP/C or FlexRay. For this purpose, “OSEK/VDX FTCom” (see Ref. [])
is a proposal whose main functions is to manage the redundancy of data needed for achieving fault-
tolerance (i.e., the same information can be produced by a set of replicated nodes) by presenting
only one copy of data to the receiver application according to the agreement strategy specified by the
designer. Two other important services of the OSEK/VDX FTCom, already offered by OSEK/VDX
Communication, are () to manage the packing/unpacking of messages [], and () to provide mes-
sage filtering mechanisms for passing only “significant” data to the application. OSEK/VDX FTCom
wasdevelopedtorunontopofaTTOSsuchasOSEKTime[].
Between and , a European cooperative project aimed at the specification of an automo-
tive MW within the automotive industry (ITEA EAST-EEA project—see http://www.east-eea.net)
was undertaken. To the best of our knowledge, the ITEA EAST-EEA project was the first important
initiative targeting the specification of both the services to be ensured by the MW and the archi-
tecture of the MW itself in terms of components and architecture of components. Similar objectives
guide the work done in the AUTOSAR consortium, see http://www.autosar.org and [,], that gath-
ers most the key players in the automotive industry. he specifications produced by the consortium
become quickly de-facto standards for the cooperative development of in-vehicle embedded systems
(see, for instance, the migration to AUTOSAR at PSA Peugeot-Citröen []).
AUTOSARspeciiesthesotwarearchitectureembeddedinanECU.Moreprecisely,itprovidesa
reference model which is comprised of three main parts:
•
Application layer
•
Basic software (MW software components)
•
Run Time environment (RTE) that provides standardized software interfaces to the
application software
One of AUTOSAR's main objective is to improve the quality and the reliability of embedded
systems. By using a well-suited abstraction, the reference model supports the separation between
sotwareandhardware,iteasesthemasteringofthecomplexity,allowstheportabilityofapplication
software components and therefore the flexibility for product modification, upgrade and update, as
well as the scalability of solutions within and across product lines. he AUTOSAR reference architec-
ture is schematically illustrated in Figure .. An important issue is the automatic generation of an
AUTOSAR MW that has to be done from the basic software components, generally provided by sup-
pliers, and the specification of the application itself (description of applicative-level tasks, signals sent
or received, events, alarms, etc.). he challenge is to realize such a generation so that the deployment
of the MW layer can be optimized for each ECU.
