Civil Engineering Reference
In-Depth Information
configured to forward the PDU to the dedicated bus system—in this example, to a
dedicated CAN bus. An exception to this driver/interface relationship is the group
of the I/O driver. There exists no interface layer for the I/O drivers—instead there
is an “I/O hardware abstraction” module to implement the bridge between the low-
level hardware-dependent driver and the highest layer of the application abstraction
layer. The specification of this I/O hardware abstraction is more like a guideline for
the implementation than a real implementation with application program interface
(API) specification, etc. The reason is the various possibilities of connecting I/O to
a microcontroller; hence, the implementation of this I/O hardware abstraction is in
many cases project specific and peripheral specific. There could be, for example,
power switches which need already a combination of two I/O (ADC plus PWM)
or an algorithm implemented in this I/O hardware abstraction (e.g. debouncing of
digital input).
4.2.2.4
Service Layer
The service layer of an AUTOSAR-based software architecture provides many ser-
vices which can be accessed from the applications via the RTE. The modules of
this layer are complex state machines, e.g. the ECU state manager which controls
the state of the ECU like OFF, RUN and SLEEP. The module groups of the service
layer are as follows:
• State manager—it manages all the states of an ECU, communication and, e.g. of
the Watchdog.
• Memory manager—it controls the access to persistent memory. The non-vol-
atile RAM manager (NVRAM-Manager) is a core module of the memory ser-
vices. This module manages the non-volatile memory blocks of an EEPROM, a
FLASH-EEPROM emulation or other external memory devices. The tasks are,
for example, write, read access, initialization of memory-mapped blocks and
check if the cyclic redundancy check (CRC) is still valid.
• Vehicle communication services—services of this service module group enable
the communication across the border of the ECU. The lower layers support the
known protocols like CAN, LIN and FlexRay—in future also Ethernet. The jobs
of these services are the abstraction of the access via standardized interfaces and
data encapsulation via abstract PDUs instead of protocol-specific messages, con-
trol of the network by support of NMT services and access to diagnostic services.
• OS services—the OS provides several services. For example, the management
of the central processing unit (CPU) time for tasks and interrupt service routines.
There are event mechanisms and protection mechanisms for time and memory
access if provided by hardware. The memory protection is only possible if the
controller has a memory management unit (MMU) or memory protection unit
(MPU). The AUTOSAR OS also provides mechanism for time synchroniza-
tion—e.g. to synchronize the internal schedule with an external clock, provided
by FlexRay.
