Civil Engineering Reference
In-Depth Information
Fig. 5.2
Communication within and between ECUs according to the AUTomotive Open System
ARchitecture (AUTOSAR) Standard. (According to Simon Fürst, AUTOSAR Guided Tour 2010)
by the introduction of abstraction layers is also a prerequisite. Based on these char-
acteristics, AUTOSAR allows a transferability of software modules within or be-
tween ECUs. Moreover it can support, in the longer run, the exchange of software
modules between different original equipment manufacturers (OEMs) if they com-
ply with the AUTOSAR standard.
The system basic functions comprise, e.g., system services (operating system
(OS), memory, network, diagnostic and ECU management), the microcontroller
abstraction, device driver, driver for communication and communication services,
communication hardware abstraction, etc.
The application layer docks on the so-called
Run Time Environment
(RTE) by
means of standardized interfaces. The RTE is frequently called a
Virtual Function
Bus
, a middleware layer, which allows the communication of the software modules
within and between the ECUs (Fig.
5.2
).
Ports implement the interface according to the communication paradigm (here:
client-server-based).
They are the points of interaction of software components. The communication
works through the RTE. The communication layer of the system basis software is
encapsulated and not visible at the application layer.
To support the existing variety of bus technologies, one has to establish tailored
standard solutions for the system basis functions. These solutions are packed in so-
called stacks (e.g., CAN stack and FlexRay stack) and are offered by a number of
first and second tiers. Up to now, it was not possible to standardize the system basis
functions to such a level that one standard solution would meet the requirements of
