Layered Software Architecture

- AUTOSAR Confidential -

Table of contents
1. Architecture
1. Overview of Software Layers
2. Content of Software Layers
3. Content of Software Layers in Multi Core systems
4. Overview of Modules
5. Interfaces
1. General
2. Interaction of Layers (Examples)

2. Configuration
3. Integration and Runtime aspects

- AUTOSAR Confidential 15

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

pageid: 94jt1

Introduction
Scope and Extensibility
Application scope of AUTOSAR
AUTOSAR is dedicated for Automotive ECUs. Such ECUs have the following properties:
strong interaction with hardware (sensors and actuators),
connection to vehicle networks like CAN, LIN, FlexRay or Ethernet,
microcontrollers (typically 16 or 32 bit) with limited resources of computing power and memory (compared
with enterprise solutions),
Real Time System and
program execution from internal or external flash memory.
NOTE: In the AUTOSAR sense an ECU means one microcontroller plus peripherals and the according
software/configuration. The mechanical design is not in the scope of AUTOSAR. This means that if more
than one microcontroller in arranged in a housing, then each microcontroller requires its own description of
an AUTOSAR-ECU instance.
AUTOSAR extensibility
The AUTOSAR Software Architecture is a generic approach:
standard modules can be extended in functionality, while still being compliant,
still, their configuration has to be considered in the automatic Basic SW configuration process!
non-standard modules can be integrated into AUTOSAR-based systems as Complex Drivers and
further layers cannot be added.
- AUTOSAR Confidential 17

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

pageid: 94qu9

Architecture Overview of Software Layers

Top view
The AUTOSAR Architecture distinguishes on the highest abstraction level between three
software layers: Application, Runtime Environment and Basic Software which run on a
Microcontroller.

Application Layer

Runtime Environment (RTE)

Basic Software (BSW)

Microcontroller
- AUTOSAR Confidential 18

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

pageid: 94ju3

Architecture Overview of Software Layers

Coarse view
The AUTOSAR Basic Software is further divided in the layers: Services, ECU Abstraction,
Microcontroller Abstraction and Complex Drivers.

Application Layer

Runtime Environment
Services Layer

ECU Abstraction Layer

Microcontroller Abstraction Layer

Microcontroller
- AUTOSAR Confidential 19

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

Complex
Drivers

pageid: 94ju4

Architecture Overview of Software Layers

Detailed view
The Basic Software Layers are further divided into functional groups. Examples of Services
are System, Memory and Communication Services.

Application Layer

Runtime Environment
System Services

Memory Services

Communication Services

Onboard Device
Abstraction

Memory Hardware
Abstraction

Communication
Hardware Abstraction

Microcontroller Drivers

Memory Drivers

Communication Drivers

Microcontroller
- AUTOSAR Confidential 20

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

I/O Hardware Abstraction

I/O Drivers

Complex
Drivers

pageid: 94ju6

Architecture Overview of Software Layers

Microcontroller Abstraction Layer
The Microcontroller Abstraction Layer is the
lowest software layer of the Basic Software.
It contains internal drivers, which are software
modules with direct access to the C and
internal peripherals.
Task
Make higher software layers independent of C

Application Layer
RTE

ECU Abstraction Layer

Microcontroller Abstraction Layer
Microcontroller

Properties
Implementation: C dependent
Upper Interface: standardized and C
independent

- AUTOSAR Confidential 21

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

Co
mpl
ex
Dri
ver
s

pageid: 94ju7

Architecture Overview of Software Layers

ECU Abstraction Layer
The ECU Abstraction Layer interfaces the
drivers of the Microcontroller Abstraction
Layer. It also contains drivers for external
devices.
It offers an API for access to peripherals and
devices regardless of their location (C
internal/external) and their connection to the
C (port pins, type of interface)

Application Layer
RTE

ECU
Abstraction
Layer
ECU
Abstraction
Layer
Microcontroller Abstraction Layer
Microcontroller

Task
Make higher software layers independent of
ECU hardware layout
Properties
Implementation: C independent, ECU hardware
dependent
Upper Interface: C and ECU hardware
independent

- AUTOSAR Confidential 22

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

Co
mpl
ex
Dri
ver
s

pageid: 94ju8

Architecture Overview of Software Layers

Services Layer
The Services Layer is the highest layer of the Basic
Software which also applies for its relevance for
the application software: while access to I/O
signals is covered by the ECU Abstraction Layer,
the Services Layer offers:

manager)
Task
Provide basic services for applications and basic
software modules.
Properties
Implementation: mostly C and ECU hardware
independent
Upper Interface: C and ECU hardware independent
- AUTOSAR Confidential 24

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

RTE
Services Layer
Abstraction
Layer
ECUECU
Abstraction
Layer
Microcontroller Abstraction Layer
Microcontroller

Complex
Drivers

Operating system functionality

Vehicle network communication and management
services
Memory services (NVRAM management)
Diagnostic Services (including UDS communication, error
memory and fault treatment)
ECU state management, mode management
Logical and temporal program flow monitoring (Wdg

Application Layer

Architecture Overview of Software Layers

Complex Drivers
The Complex Drivers Layer spans from the
hardware to the RTE.

Application Layer
RTE

Task
Provide the possibility to integrate special purpose
functionality, e.g. drivers for devices:
which are not specified within AUTOSAR,
with very high timing constrains or
for migration purposes etc.
Properties
Implementation: might be application, C and ECU
hardware dependent
Upper Interface: might be application, C and ECU
hardware dependent

- AUTOSAR Confidential 23

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

Services Layer
Abstraction
Layer
ECUECU
Abstraction
Layer
Microcontroller Abstraction Layer
Microcontroller

pageid: 94ju9

Architecture Overview of Software Layers

AUTOSAR Runtime Environment (RTE)
The RTE is a layer providing communication services
to the application software (AUTOSAR Software
Components and/or AUTOSAR Sensor/Actuator
components).

Application Layer

AUTOSAR Runtime Environment (RTE)

The AUTOSAR Software Components communicate

with other components (inter and/or intra ECU)
and/or services via the RTE.
Task
Make AUTOSAR Software Components independent
from the mapping to a specific ECU.
Properties
Implementation: ECU and application specific
(generated individually for each ECU)
Upper Interface: completely ECU independent

- AUTOSAR Confidential 25

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

Services Layer
Abstraction
Layer
ECUECU
Abstraction
Layer
Microcontroller Abstraction Layer
Microcontroller

Complex
Drivers

Above the RTE the software architecture style

changes from layered to component style.

pageid: 94j33

Architecture Overview of Software Layers

Introduction to types of services
The Basic Software can be subdivided into the following types of services:
Input/Output (I/O)
Standardized access to sensors, actuators and ECU onboard peripherals
Memory
Standardized access to internal/external memory (non volatile memory)
Communication
Standardized access to: vehicle network systems, ECU onboard communication systems and
ECU internal SW
System
Provision of standardizeable (operating system, timers, error memory) and ECU specific
(ECU state management, watchdog manager) services and library functions

- AUTOSAR Confidential 26

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

Table of contents
1. Architecture
1. Overview of Software Layers
2. Content of Software Layers
3. Content of Software Layers in Multi Core systems
4. Overview of Modules
5. Interfaces
1. General
2. Interaction of Layers (Examples)

2. Configuration
3. Integration and Runtime aspects

- AUTOSAR Confidential 33

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

Architecture Content of Software Layers

Microcontroller Abstraction Layer

Application Layer
RTE

The C Abstraction Layer consists of the following module groups:

System Services
Onboard
Dev. Abstr.

Memory
Services

Communication
Services

Memory
HW Abstr.

COM HW
Abstr.

I/O HW
Abstraction

Communication Drivers
MicroCommuniMemory
I/O
Drivers for ECU onboard (e.g. SPI) and vehicle communication (e.g. CAN).
controller
cation
Drivers
Drivers
OSI-Layer: Part of Data Link Layer
Drivers
Drivers
I/O Drivers
Microcontroller (C)
Drivers for analog and digital I/O (e.g. ADC, PWM, DIO)
Memory Drivers
Drivers for on-chip memory devices (e.g. internal Flash, internal EEPROM) and memory mapped external memory devices
(e.g. external Flash)
Microcontroller Drivers
Drivers for internal peripherals (e.g. Watchdog, General Purpose Timer)
Group of
Functions with direct C access (e.g. Core test)
Microcontroller Drivers

Memory Drivers

Communication Drivers

I/O Drivers

Software
modules of
similar type

Software
module

internal
peripheral
device

Microcontroller

- AUTOSAR Confidential 34

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

Architecture Content of Software Layers

Onboard Device Abstraction

Application Layer
RTE
Memory
Services

Communication
Services

Onboard
Dev. Abstr.

Memory
HW Abstr.

COM HW
Abstr.

Microcontroller
Drivers

Memory
Drivers

Communication
Drivers

System Services

The Onboard Device Abstraction contains

drivers for ECU onboard devices which
cannot be seen as sensors or actuators like
internal or external watchdogs. Those
drivers access the ECU onboard devices via
the C Abstraction Layer.
Task:
Abstract from ECU specific onboard devices.

I/O HW
Abstraction

I/O
Drivers

Microcontroller (C)

Example:
Onboard Device Abstraction
Watchdog Interface

External
Watchdog Driver

Properties:
Implementation: C independent, external
device dependent
Upper Interface: C independent, partly ECU
hardware dependent

COM Drivers

Microcontroller
Drivers

- AUTOSAR Confidential 40

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

Architecture Content of Software Layers

Scope: Memory Hardware Abstraction

Application Layer
RTE
Memory
Services

Communication
Services

Onboard
Dev. Abstr.

Memory
HW Abstr.

COM HW
Abstr.

Microcontroller
Drivers

Memory
Drivers

Communication
Drivers

System Services

The Memory Hardware Abstraction is a group of

modules which abstracts from the location of
peripheral memory devices (on-chip or on-board)
and the ECU hardware layout.
Example: on-chip EEPROM and external EEPROM
devices are accessible via the same
mechanism.
The memory drivers are accessed via memory specific
abstraction/emulation modules (e.g. EEPROM
Abstraction).
By emulating an EEPROM abstraction on top of Flash
hardware units a common access via Memory
Abstraction Interface to both types of hardware is
enabled.
Task:
Provide equal mechanisms to access internal (on-chip)
and external (on-board)
memory devices and type of memory hardware
(EEPROM, Flash).
Properties:
Implementation: C independent, external device
dependent
Upper Interface: C, ECU hardware and memory
device independent
- AUTOSAR Confidential 39

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

I/O HW
Abstraction

I/O
Drivers

Microcontroller (C)

Example:
Memory Hardware Abstraction
Memory Abstraction Interface

EEPROM Abstraction

External
EEPROM Driver

Flash EEPROM
Emulation

External
Flash Driver

COM Drivers

Memory Drivers

Architecture Content of Software Layers

ECU Abstraction: Communication Hardware Abstraction

Application Layer
RTE
Memory
Services

Communication
Services

Onboard
Dev. Abstr.

Memory
HW Abstr.

COM HW
Abstr.

Microcontroller
Drivers

Memory
Drivers

Communication
Drivers

System Services

The Communication Hardware Abstraction is a

group of modules which abstracts from the
location of communication controllers and the ECU
hardware layout. For all communication systems a
specific Communication Hardware Abstraction is
required (e.g. for LIN, CAN, FlexRay).
Example: An ECU has a microcontroller with 2 internal
CAN channels and an additional on-board ASIC
with 4 CAN controllers. The CAN-ASIC is
connected to the microcontroller via SPI.
The communication drivers are accessed via bus
specific interfaces (e.g. CAN Interface).
Task:
Provide equal mechanisms to access a bus channel
regardless of its location (on-chip / on-board)
Properties:
Implementation: C independent, ECU hardware
dependent and external device dependent
Upper Interface: bus dependent, C and ECU
hardware independent
- AUTOSAR Confidential 38

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

I/O HW
Abstraction

I/O
Drivers

Microcontroller (C)

Example:
Communication Hardware Abstraction
CAN Interface
CAN
Transceiver
Driver

Driver for ext.

CAN ASIC

I/O Drivers

Communication Drivers

Architecture Content of Software Layers

ECU Abstraction: I/O Hardware Abstraction

Application Layer
RTE
Memory
Services

Communication
Services

Onboard
Dev. Abstr.

Memory
HW Abstr.

COM HW
Abstr.

Microcontroller
Drivers

Memory
Drivers

Communication
Drivers

System Services

The I/O Hardware Abstraction is a group of modules

which abstracts from the location of peripheral I/O
devices (on-chip or on-board) and the ECU
hardware layout (e.g. C pin connections and
signal level inversions). The I/O Hardware
Abstraction does not abstract from the
sensors/actuators!
The different I/O devices might be accessed via an I/O
signal interface.

I/O HW
Abstraction

I/O
Drivers

Microcontroller (C)

Example:
I/O Hardware Abstraction

Task:
Represent I/O signals as they are connected to the
ECU hardware (e.g. current, voltage, frequency).
Hide ECU hardware and layout properties from higher
software layers.

I/O Signal Interface

Driver for ext.

ADC ASIC

Driver for ext.

I/O ASIC

COM Drivers

Properties:
Implementation: C independent, ECU hardware
dependent
Upper Interface: C and ECU hardware independent,
dependent on signal type specified and
implemented according to AUTOSAR (AUTOSAR
interface)
- AUTOSAR Confidential 37

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

I/O Drivers

Architecture Content of Software Layers

Complex Drivers

Application Layer
RTE
Memory
Services

Communication
Services

Onboard
Dev. Abstr.

Memory
HW Abstr.

COM HW
Abstr.

Microcontroller
Drivers

Memory
Drivers

Communication
Drivers

System Services

A Complex Driver is a module which implements nonstandardized functionality within the basic software
stack.
An example is to implement complex sensor
evaluation and actuator control with direct access
to the C using specific interrupts and/or complex
C peripherals (like PCP, TPU), e.g.
Injection control
Electric valve control
Incremental position detection

Microcontroller (C)

Example:
Complex Drivers

Task:
Fulfill the special functional and timing requirements
for handling complex sensors and actuators
Properties:
Implementation: highly C, ECU and application
dependent
Upper Interface to SW-Cs: specified and implemented
according to AUTOSAR (AUTOSAR interface)
Lower interface: restricted access to Standardized
Interfaces
- AUTOSAR Confidential 36

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

I/O HW
Abstraction

I/O
Drivers

Architecture Content of Software Layers

Communication Services General

Application Layer
RTE
Memory
Services

Communication
Services

Onboard
Dev. Abstr.

Memory
HW Abstr.

COM HW
Abstr.

Microcontroller
Drivers

Memory
Drivers

Communication
Drivers

System Services

The Communication Services are a group of

modules for vehicle network communication (CAN,
LIN and FlexRay). They interface with the
communication drivers via the communication
hardware abstraction.
Task:
Provide a uniform interface to the vehicle network for
communication.
Provide uniform services for network management
Provide uniform interface to the vehicle network for
diagnostic communication
Hide protocol and message properties from the
application.

Example:
Communication Services

IPDU
Multiplexer

DCM
Diagnostic
Com.
Manager

Generic NM
Interface
Debugging

PDU Router

The communication services will be detailed for each

relevant vehicle network system on the following
pages.
- AUTOSAR Confidential 41

I/O
Drivers

Microcontroller (C)

AUTOSAR
COM

Properties:
Implementation: C and ECU HW independent, partly
dependent on bus type
Upper Interface: C, ECU hardware and bus type
independent

I/O HW
Abstraction

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

<Bus
specific>
State
Manager

<Bus
specific>
NM

<Bus specific>
Transport Protocol

Bus specific modules

Architecture Content of Software Layers

Communication Stack CAN

Application Layer
RTE
Memory
Services

Communication
Services

Onboard
Dev. Abstr.

Memory
HW Abstr.

COM HW
Abstr.

Microcontroller
Drivers

Memory
Drivers

Communication
Drivers

System Services

Example:
Communication Services
Generic NM
Interface

AUTOSAR
COM

I/O HW
Abstraction

I/O
Drivers

Microcontroller (C)
CAN
State
Manager

PDU Router

CAN NM

CAN Transport
Protocol
J1939 Transport
Protocol

Communication Hardware Abstraction

The CAN Communication Services are a group of modules

for vehicle network communication with the communication
system CAN.
Task:
Provide a uniform interface to the CAN network. Hide
protocol and message properties from the application.

CAN Interface
CAN Transceiver
Driver

Driver for ext.

CAN ASIC

I/O Drivers
DIO Driver

Communication Drivers
SPIHandler
Driver

SPI

External
CAN Controller

CAN Driver

CAN

Please Note:
There are two transport protocol modules in the CAN stack
which can be used alternatively or in parallel: CanTp and
J1939Tp. They are used as follows:
CanTp: ISO Diagnostics (DCM), large PDU transport
on standard CAN bus
- J1939Tp: J1939 Diagnostics, large PDU transport on
J1939 driven CAN bus

- AUTOSAR Confidential 42

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

Architecture Content of Software Layers

Communication Stack CAN

Application Layer
RTE
Memory
Services

Communication
Services

Onboard
Dev. Abstr.

Memory
HW Abstr.

COM HW
Abstr.

Microcontroller
Drivers

Memory
Drivers

Communication
Drivers

System Services

Properties:
Implementation: C and ECU HW independent, partly
dependent on CAN.
AUTOSAR COM, Generic NM (Network Management)
Interface and Diagnostic Communication Manager are the
same for all vehicle network systems and exist as one
instance per ECU.
Generic NM Interface contains only a dispatcher. No
further functionality is included. In case of gateway ECUs it
can also include the NM coordinator functionality which
allows to synchronize multiple different networks (of the
same or different types) to synchronously wake them up or
shut them down.
CAN Generic NM is specific for CAN networks and will be
instantiated per CAN vehicle network system. CAN
Generic NM interfaces with CAN via underlying network
adapter (CAN NM).
The communication system specific Can State Manager
handles the communication system dependent Start-up
and Shutdown features. Furthermore it controls the
different options of COM to send PDUs and to monitor
signal timeouts.
- AUTOSAR Confidential 43

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

Microcontroller (C)

I/O HW
Abstraction

I/O
Drivers

Architecture Content of Software Layers

Services: Memory Services

Application Layer
RTE
Memory
Services

Communication
Services

Onboard
Dev. Abstr.

Memory
HW Abstr.

COM HW
Abstr.

Microcontroller
Drivers

Memory
Drivers

Communication
Drivers

System Services

The Memory Services consist of one module,

the NVRAM Manager. It is responsible for
the management of non volatile data
(read/write from different memory drivers).
Task: Provide non volatile data to the
application in a uniform way. Abstract from
memory locations and properties. Provide
mechanisms for non volatile data
management like saving, loading, checksum
protection and verification, reliable storage
etc.

Microcontroller (C)

Example:
Memory Services

NVRAM Manager

Properties:
Implementation: C and ECU hardware
independent, highly configurable
Upper Interface: C and ECU hardware
independent specified and implemented
according to AUTOSAR
(AUTOSAR interface)
- AUTOSAR Confidential 54

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

I/O HW
Abstraction

I/O
Drivers

Architecture Content of Software Layers

Services: System Services

Application Layer
RTE
Memory
Services

Communication
Services

Onboard
Dev. Abstr.

Memory
HW Abstr.

COM HW
Abstr.

Microcontroller
Drivers

Memory
Drivers

Communication
Drivers

System Services

The System Services are a group of modules

and functions which can be used by modules
of all layers. Examples are Real Time
Operating System (which includes timer
services) and Error Manager.
Some of these services are C dependent (like
OS), partly ECU hardware and application
dependent (like ECU State Manager) or
hardware and C independent.

Microcontroller (C)

Example:

Task:
Provide basic services for application and
basic software modules.
Properties:
Implementation: partly C, ECU hardware and
application specific
Upper Interface: C and ECU hardware
independent
- AUTOSAR Confidential 55

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

System Services

I/O HW
Abstraction

I/O
Drivers

Architecture Content of Software Layers

Error Handling, Reporting and Diagnostic

Application Layer
RTE
Memory
Services

Communication
Services

Onboard
Dev. Abstr.

Memory
HW Abstr.

COM HW
Abstr.

Microcontroller
Drivers

Memory
Drivers

Communication
Drivers

System Services

Application Layer
AUTOSAR Runtime Environment (RTE)
Watchdog Manager
Function Inhibition
Manager
Development Error
Tracer

Communication
Services
Diagnostic Communication Manager

I/O HW
Abstraction

I/O
Drivers

Microcontroller (C)

There are dedicated modules for different aspects

Diagnostic Log
of error handling in AUTOSAR. E.g.:
and Trace
XCP
Diagnostic Event
The Debugging module supports debugging of
Manager
the AUTOSAR BSW. It interfaces to ECU
Communication
Onboard Device
internal modules and to an external host system
Hardware
Abstraction
via communication .
Abstraction
Watchdog Interface
The Diagnostic Event Manager is responsible
for processing and storing diagnostic events
Microcontroller Drivers
Communication
Drivers
(errors) and associated FreezeFrame data.
Watchdog Driver
The module Diagnostic Log and Trace
supports logging and tracing of applications. It
Microcontroller
collects user defined log messages and converts
them into a standardized format.
All detected development errors in the Basic Software are reported to Development Error Tracer.
The Diagnostic Communication Manager provides a common API for diagnostic services
etc.
Debugging

- AUTOSAR Confidential 56

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

Table of contents
1. Architecture
1. Overview of Software Layers
2. Content of Software Layers
3. Content of Software Layers in Multi Core systems
4. Overview of Modules
5. Interfaces
1. General
2. Interaction of Layers (Examples)

2. Configuration
3. Integration and Runtime aspects

- AUTOSAR Confidential 58

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

pageid: w111b

Architecture Content of Software Layers

Example of a Layered Software Architecture for Multi-Core Microcontroller

Example: an ECU with a two core microcontroller

ECU
core 1:

core 0:

Application Layer
RTE

System Services

Memory
Services

Operating
System

Communication
Services

Memory HW
Abstraction

COM HW
Abstraction

Microcontroller
Drivers

Memory
Drivers

Communication Drivers

I/O
Drivers

Complex Drivers

Onboard Dev.
Abstraction

Complex Drivers

I/O HW
Abstraction

ECU State
Manager

Core Test

Microcontroller (C)

- AUTOSAR Confidential 59

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

Architecture Content of Software Layers

Scope: Multi-Core System Services

Application Layer
RTE
Memory
Services

Communication
Services

Onboard
Dev. Abstr.

Memory
HW Abstr.

COM HW
Abstr.

Microcontroller
Drivers

Memory
Drivers

Communication
Drivers

System Services

The IOC, as shown in the figure, provides communication

services which can be accessed by clients which need
to communicate across OS-Application boundaries on
the same ECU. The IOC is part of the OS
Every Core runs a kind of ECU state management

Microcontroller (C)

Microcontroller
core 0:

core 1:
System Services

System Services

- AUTOSAR Confidential 60

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

I/O HW
Abstraction

I/O
Drivers

Table of contents
1. Architecture
1. Overview of Software Layers
2. Content of Software Layers
3. Content of Software Layers in Multi Core systems
4. Overview of Modules
5. Interfaces
1. General
2. Interaction of Layers (Examples)

2. Configuration
3. Integration and Runtime aspects

- AUTOSAR Confidential 66

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

pageid: a6ztr

Interfaces: General Rules

General Interfacing Rules
Horizontal Interfaces

Vertical Interfaces

Services Layer: horizontal interfaces are allowed

Example: Error Manager saves fault data using the
NVRAM manager

One Layer may access all interfaces of the SW layer

below

ECU Abstraction Layer: horizontal interfaces are

allowed

Bypassing of one software layer should be avoided

A complex driver may use selected other BSW

modules

Bypassing of two or more software layers is not

allowed

C Abstraction Layer: horizontal interfaces are not

allowed. Exception: configurable notifications are
allowed due to performance reasons.

Bypassing of the C Abstraction Layer is not allowed

AUTOSAR

AUTOSAR

AUTOSAR

AUTOSAR

SW Comp
1

SW Comp
3

SW Comp
4

SW Comp
5

A module may access a lower layer module of

another layer group (e.g. SPI for external hardware)

All layers may interact with system services.

Microcontroller (C)

- AUTOSAR Confidential 69

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

pageid: 1xdfr

Interfaces: General Rules

Layer Interaction Matrix

This matrix shows the possible interactions between

AUTOSAR Basic Software layers
is allowed to use
is not allowed to use
restricted use
(callback only)
The matrix is read rowwise:
Example: I/O Drivers
are allowed
to use System Services
and
Hardware, but no other
layers.
(gray background indicates nonBasic Software layers)

uses

AUTOSAR SW Components / RTE

System Services
Memory Services
Communication Services
Complex Drivers
I/O Hardware Abstraction
Onboard Device Abstraction
Memory Hardware Abstraction
Communication Hardware Abstraction

restricted access -> see the following two slides

Microcontroller Drivers
Memory Drivers
Communication Drivers
I/O Drivers
- AUTOSAR Confidential 70

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

Interfaces
Interfacing with Complex Drivers (1)

Application Layer
RTE
Memory
Services

Communication
Services

Onboard
Dev. Abstr.

Memory
HW Abstr.

COM HW
Abstr.

Microcontroller
Drivers

Memory
Drivers

Communication
Drivers

System Services

Complex Drivers may need to interface to other modules

in the layered software architecture, or modules in
the layered software architecture may need to interface
to a Complex Driver. If this is the case,
the following rules apply:

I/O HW
Abstraction

I/O
Drivers

Microcontroller (C)

1. Interfacing from modules of the layered software architecture to Complex Drivers

This is only allowed if the Complex Driver offers an interface which can be generically configured by the accessing
AUTOSAR module.
A typical example is the PDU Router: a Complex Driver may implement the interface module of a new bus system.
This is already taken care of within the configuration of the PDU Router.
2. Interfacing from a Complex Driver to modules of the layered software architecture
Again, this is only allowed if the respective modules of the layered software architecture offer the interfaces, and are
prepared to be accessed by a Complex Driver. Usually this means that
The respective interfaces are defined to be re-entrant.
If call back routines are used, the names are configurable
No upper module exists which does a management of states of the module (parallel access would change states
without being noticed by the upper module)
- AUTOSAR Confidential 71

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

Interfaces
Interfacing with Complex Drivers (2)

Application Layer
RTE
System Services

Memory
Services

Communication
Services

I/O HW
Abstraction

In general, it is possible to access the following modules:

Onboard
Memory
COM HW
Dev. Abstr.
HW Abstr.
Abstr.
The SPI driver
MicroCommuniMemory
I/O
controller
cation
The GPT driver
Drivers
Drivers
Drivers
Drivers
The I/O drivers with the restriction that re-entrancy often only exists for
Microcontroller (C)
separate groups/channels/etc. Parallel access to the same
group/channel/etc. is mostly not allowed. This has to be taken care of during configuration.
The NVRAM Manager as exclusive access point to the memory stack
The Watchdog Manager as exclusive access point to the watchdog stack
The PDU Router as exclusive bus and protocol independent access point to the communication stack
The bus specific interface modules as exclusive bus specific access point to the communication stack
The NM Interface Module as exclusive access point to the network management stack
The Communication Manager (only from upper layer) and the Basic Software Mode Manager
as exclusive access points to state management
Det, Dem and Dlt
The OS as long as the used OS objects are not used by a module of the layered software architecture
Still, for each module it is necessary to check if the respective function is marked as being re-entrant. For example,
init functions are usually not re-entrant and should only be called by the ECU State Manager.

- AUTOSAR Confidential 72

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

Interfaces
Interfacing with Complex Drivers (3)

Application Layer
RTE
System Services

Memory
Services

Communication
Services

I/O HW
Abstraction

In case of multi core architectures, there are additional rules:

Onboard
Memory
COM HW
Dev. Abstr.
HW Abstr.
Abstr.
In AUTOSAR release 4.0, the BSW resides on the master core.
MicroCommuniMemory
I/O
controller
cation
Consequently, if the CDD needs to access standardized interfaces
Drivers
Drivers
Drivers
Drivers
of the BSW, it needs to reside on the same core.
Microcontroller (C)
In case a CDD resides on a different core, it can use the normal
port mechanism to access AUTOSAR interfaces and standardized AUTOSAR interfaces. This invokes the RTE,
which uses the IOC mechanism of the operating system to transfer requests to the master core.
However, if the CDD needs to access standardized interfaces of the BSW and does not reside on the master
core, a stub part of the CDD needs to be implemented on the master core, and communication needs to be
organized CDD-local using the IOC mechanism of the operating system similar to what the RTE does.
Additionally, in this case the initialization part of the CDD also needs to reside in the stub part on the master core.

- AUTOSAR Confidential 73

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

Table of contents
1. Architecture
1. Overview of Software Layers
2. Content of Software Layers
3. Content of Software Layers in Multi Core systems
4. Overview of Modules
5. Interfaces
1. General
2. Interaction of Layers (Examples)

2. Configuration
3. Integration and Runtime aspects

- AUTOSAR Confidential 74

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 2wfr5

Interfaces: Interaction of Layers Example Memory

Introduction
The following pages explain using the example memory:
How do the software layers interact?
How do the software interfaces look like?
What is inside the ECU Abstraction Layer?
How can abstraction layers be implemented efficiently?

- AUTOSAR Confidential 75

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 99876

Interfaces: Interaction of Layers Example Memory

Example and First Look
This example shows how the NVRAM Manager and the
Watchdog Manager interact with drivers on an assumed
hardware configuration:
The ECU hardware includes an external EEPROM and an
external watchdog connected to the microcontroller via the
same SPI.
The SPIHandlerDriver controls the concurrent access to the
SPI hardware and has to give the watchdog access a
higher priority than the EEPROM access.

System Services

Memory Services

Watchdog
Manager

NVRAM
Manager

Onboard Device
Abstraction

Memory Hardware Abstraction

Memory Abstraction Interface

Watchdog Interface

Wdg_Trigger()

The microcontroller includes also an internal flash which is

used in parallel to the external EEPROM. The EEPROM
Abstraction and the Flash EEPROM Emulation have an
API that is semantically identical.

Fls_Read()
Fls_Write()

COM Drivers

Memory Drivers

SPIHandlerDriver

Internal
Flash Driver

SPI

Flash

External
Watchdog

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

Flash EEPROM
Emulation

Spi_ReadIB()
Spi_WriteIB()

CS

- AUTOSAR Confidential -

Fee_Read()
Fee_Write()

EEPROM
Abstraction

External
EEPROM Driver

External
Watchdog Driver

The Memory Abstraction Interface can be realized in the

following ways:
routing during runtime based on device index (int/ext)
routing during runtime based on the block index (e.g. >
0x01FF = external EEPROM)
routing during configuration time via ROM tables with
function pointers inside the NVRAM Manager (in this case
the Memory Abstraction Interface only exists virtually)

76

MemIf_Read()
MemIf_Write()

WdgIf_Trigger()

SPI

CS
External
EEPROM

SPI

page id: 1ase4

Interfaces: Interaction of Layers Example Memory

Closer Look at Memory Hardware Abstraction
Architecture Description
The NVRAM Manager accesses drivers via the
Memory Abstraction Interface. It addresses
different memory devices using a device index.

Nvm_Write(BlockIndex)
Memory Services

Interface Description
The Memory Abstraction Interface could have the
following interface (e.g. for the write function):

NVRAM
Manager

MemIf_Write(
DeviceIndex,
BlockNumber,
DataBufferPtr)

Std_ReturnType MemIf_Write
(
uint8
DeviceIndex,
uint16
BlockNumber,
uint8
*DataBufferPtr
)

Memory Hardware Abstraction

Memory Abstraction Interface

Ea_Write(
BlockNumber,
DataBufferPtr)

The EEPROM Abstraction as well as the Flash

EEPROM Emulation could have the following
interface (e.g. for the write function):

EEPROM Abstaction

Std_ReturnType Ea_Write
(
uint16
BlockNumber,
uint8
*DataBufferPtr
)

- AUTOSAR Confidential 77

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

Fee_Write(
BlockNumber,
DataBufferPtr)

Flash
EEPROM Emulation

page id: wfgz7

Interfaces: Interaction of Layers Example Memory

Implementation of Memory Abstraction Interface
Situation 1: only one NV device type used
This is the usual use case. In this situation, the Memory Abstraction can, in case of source code availability, be
implemented as a simple macro which neglects the DeviceIndex parameter. The following example shows
the write function only:
File MemIf.h:
#include Ea.h
/* for providing access to the EEPROM Abstraction */
...
#define MemIf_Write(DeviceIndex, BlockNumber, DataBufferPtr) \
Ea_Write(BlockNumber, DataBufferPtr)

File MemIf.c:
Does not exist

Result:
No additional code at runtime, the NVRAM Manager virtually accesses the EEPROM Abstraction or the Flash
Emulation directly.
- AUTOSAR Confidential 78

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 12345

Interfaces: Interaction of Layers Example Memory

Implementation of Memory Abstraction Interface
Situation 2: two or more different types of NV devices used
In this case the DeviceIndex has to be used for selecting the correct NV device. The implementation can also
be very efficient by using an array of pointers to function. The following example shows the write function
only:
File MemIf.h:
extern const WriteFctPtrType WriteFctPtr[2];
#define MemIf_Write(DeviceIndex, BlockNumber, DataBufferPtr) \
WriteFctPtr[DeviceIndex](BlockNumber, DataBufferPtr)

File MemIf.c:
#include Ea.h
#include Fee.h
#include MemIf.h

/* for getting the API function addresses */

/* for getting the API function addresses */
/* for getting the WriteFctPtrType
*/

const WriteFctPtrType WriteFctPtr[2] = {Ea_Write, Fee_Write};

Result:
The same code and runtime is needed as if the function pointer tables would be inside the NVRAM Manager.
The Memory Abstraction Interface causes no overhead.
- AUTOSAR Confidential 79

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: wwwee

Interfaces: Interaction of Layers Example Memory

Conclusion
Conclusions:
Abstraction Layers can be implemented very efficiently
Abstraction Layers can be scaled
The Memory Abstraction Interface eases the access of the NVRAM Manager to one or more
EEPROM and Flash devices

- AUTOSAR Confidential 80

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

Table of contents
1. Architecture
1. Overview of Software Layers
2. Content of Software Layers
3. Content of Software Layers in Multi Core systems
4. Overview of Modules
5. Interfaces
1. General
2. Interaction of Layers (Examples)

2. Configuration
3. Integration and Runtime aspects

- AUTOSAR Confidential 86

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

Configuration
Overview
The AUTOSAR Basic Software supports the following configuration classes:
1. Pre-compile time
Preprocessor instructions
Code generation (selection or synthetization)
2. Link time
Constant data outside the module; the data can be configured after the module has been
compiled
3. Post-build time
Loadable constant data outside the module. Very similar to [2], but the data is located in
a specific memory segment that allows reloading (e.g. reflashing in ECU production line)
Single or multiple configuration sets can be provided. In case that multiple configuration
sets are provided, the actually used configuration set is to be specified at runtime.
In many cases, the configuration parameters of one module will be of different configuration
classes.
Example: a module providing Post-build time configuration parameters will still have some
parameters that are Pre-compile time configurable.
- AUTOSAR Confidential 87

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

Configuration
Pre-compile time (1)
Use cases
Pre-compile time configuration would be chosen for
Enabling/disabling optional functionality
This allows to exclude parts of the source code that are not needed
Optimization of performance and code size
Using #defines results in most cases in more efficient code than
access to constants or even access to constants via pointers.
Generated code avoids code and runtime overhead.
Restrictions
The module must be available as source code
The configuration is static. To change the configuration, the module
has to be recompiled
Required implementation
Pre-compile time configuration shall be done via the modules two
configuration files (*_Cfg.h, *_Cfg.c) and/or by code generation:
*_Cfg.h stores e.g. macros and/or #defines
*_Cfg.c stores e.g. constants
- AUTOSAR Confidential 88

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

Nm_Cfg.c

Nm_Cfg.h

uses
(optional)

includes
Nm.c

Configuration
Link time (1)
Use cases
Link time configuration would be chosen for
Configuration of modules that are only available as object code
(e.g. IP protection or warranty reasons)
Selection of configuration set after compilation but before linking.

Required implementation
1. One configuration set, no runtime selection
Configuration data shall be captured in external constants. These external constants are
located in a separate file. The module has direct access to these external constants.

- AUTOSAR Confidential 91

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

Configuration
Post-build time (1)
Use cases
Post-build time configuration would be chosen for
Configuration of data where only the structure is defined but the contents not known during ECU-build time
Configuration of data that is likely to change or has to be adapted after ECU-build time
(e.g. end of line, during test & calibration)
Reusability of ECUs across different product lines (same code, different configuration data)
Restrictions
Implementation requires dereferencing which has impact on performance, code and data size
Required implementation
1. One configuration set, no runtime selection (loadable)
Configuration data shall be captured in external constant structs. These external structs are located in a separate memory
segment that can be individually reloaded.

2. 1..n configuration sets, runtime selection possible (selectable)

Configuration data shall be captured within external constant structs. These configuration structures are located in one
separate file. The module gets a pointer to one of those structs at initialization time. The struct can be selected at each
initialization.

- AUTOSAR Confidential 94

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

Table of contents
1. Architecture
2. Configuration
3. Integration and Runtime aspects
1. Mapping of Runnables
2. Partitioning
3. Scheduling
4. Mode Management
5. Error Handling, Reporting and Diagnostic
6. Debugging
7. Measurement and Calibration
8. Functional Safety
9. Energy Management

- AUTOSAR Confidential 100

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

Integration and Runtime aspects

Mapping of Runnables
Runnables are the
active parts of
Software Components
They can be executed
concurrently, by
mapping them to
different Tasks.
The figure shows
further entities like OSapplications, Partitions,
C-Cores and BSWResources which have
to be considered for
this mapping.

SW-C

Runnable
0..*

0..*
1

Task
0..*
1

Partition

OS-Application
0..*

1
0..*
BSW-Ressource
(E.g., NV-block)

- AUTOSAR Confidential 101

0..*

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

1
C-Core

Table of contents
1. Architecture
2. Configuration
3. Integration and Runtime aspects
1. Mapping of Runnables
2. Partitioning
3. Scheduling
4. Mode Management
5. Error Handling, Reporting and Diagnostic
6. Debugging
7. Measurement and Calibration
8. Functional Safety
9. Energy Management

- AUTOSAR Confidential 102

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: wweev

Integration and Runtime aspects - Partitioning

Introduction
Partitions are used as error containment regions:
Permit logical grouping of SW-Cs and resources
Recovery policies defined individually for each partition
Partition consistency is ensured by the system/platform, for instance for:
Memory access violation
Time budget violation
Partitions can be terminated or restarted during run-time as a result of a detected error:
Further actions required: see example on following slides
The BSW is placed in a privileged partition
This partition should not be restarted or terminated
Partitions are configured in the ECU-C:
A partition is implemented by an OS-Application within the OS
SW-Cs are mapped to partitions (Consequence: restricts runnable to task mapping)
A partition can be configured as restartable or not
Communication across partitions is realized by the IOC
- AUTOSAR Confidential 103

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

Table of contents
1. Architecture
2. Configuration
3. Integration and Runtime aspects
1. Mapping of Runnables
2. Partitioning
3. Scheduling
4. Mode Management
5. Error Handling, Reporting and Diagnostic
6. Debugging
7. Measurement and Calibration
8. Functional Safety
9. Energy Management

- AUTOSAR Confidential 108

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: y331a

Integration and Runtime aspects - Scheduling

General Architectural Aspects
Basic Software Scheduler and the RTE are generated together.
This enables
that the same OS Task schedules BSW Main Functions and Runnable Entities of
Software Components
to optimize the resource consumption
to configure interlaced execution sequences of Runnable Entities and BSW Main functions.

a coordinated switching of a Mode affecting BSW Modules and Application Software

Components
the synchronized triggering of both, Runnable Entities and BSW Main Functions by the
same External Trigger Occurred Event.

- AUTOSAR Confidential 109

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: y331d

Integration and Runtime aspects - Scheduling

Transformation Process

Logical Architecture (Model)

Technical Architecture (Implementation)

Ideal concurrency
Unrestricted resources
Only real data dependencies

Restricted concurrency
Restricted resources
Real data dependencies
Dependencies given by restrictions

Scheduling objects
Trigger
BSW Events
Sequences of scheduling objects
Scheduling Conditions
...

OS objects
Tasks
ISRs
Alarms
Resources
OS services
Sequences of scheduling objects within tasks
Sequences of tasks
...
Transformation
Mapping of scheduling objects to OS Tasks
Specification of sequences of scheduling objects within tasks
Specification of task sequences
Specification of a scheduling strategy
...
- AUTOSAR Confidential -

112

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: yqqq1

Integration and Runtime aspects - Scheduling

Transformation Process Example 1

Logical Architecture (Model)

Technical Architecture (Schedule Module)

Task1 {
Zzz_MainFunction_Bbb();
Zzz_MainFunction_Bbb();

Yyy_MainFunction_Aaa();

Yyy_MainFunction_Aaa();

glue code

Xxx_MainFunction_Aaa();

Xxx_MainFunction_Aaa();
glue code
...
}

Transformation
Mapping of scheduling objects to OS Tasks
Specification of sequences of scheduling objects within tasks

- AUTOSAR Confidential 113

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: yqqq2

Integration and Runtime aspects - Scheduling

Transformation Process Example 2

Logical Architecture (Model)

Technical Architecture (Schedule Module)

Task2 {
...
Xxx_MainFunction_Bbb();
...

Xxx_MainFunction_Bbb();

Yyy_MainFunction_Bbb();

Task3 {
...
Yyy_MainFunction_Bbb();
...
}

Transformation
Mapping of scheduling objects to OS Tasks

- AUTOSAR Confidential 114

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: yqqq3

Integration and Runtime aspects - Scheduling

Data Consistency Motivation

Logical Architecture (Model)

Technical Architecture (Schedule Module)

Access to resources by different and concurrent entities of the implemented technical architecture
(e.g., main functions and/or other functions of the same module out of different task contexts)
Xxx_Module
Xxx_MainFunction();

Yyy_ AccessResource();

XYZ resource
Yyy_MainFunction();
Yyy_Module
Transformation
Data consistency strategy to be used:
Sequence, Interrupt blocking, Cooperative Behavior,
Semaphores (OSEK Resources), Copies of ...

- AUTOSAR Confidential 115

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: yqqq4

Integration and Runtime aspects - Scheduling

Data Consistency Example 1 Critical Sections Approach

Logical Architecture (Model)/

Technical Architecture (Schedule Module)
Task1

Xxx_Module

Xxx_MainFunction();

Yyy_ AccessResource();

Implementation of Schedule Module

#define SchM_Enter_<mod>_<name> \
DisableAllInterrupts
#define SchM_Exit_<mod>_<name>
\
EnableAllInterrupts
Yyy_AccessResource() {
...
SchM_Enter_Xxx_XYZ();
<access_to_shared_resource>
SchM_Exit_Xxx_XYZ();
...
}
Yyy_MainFunction() {
...
SchM_Enter_Yyy_XYZ();
<access_to_shared_resource>
SchM_Exit_Yyy_XYZ();
...
}

XYZ resource
Yyy_MainFunction();
Task2
Transformation

Data consistency is ensured by:

Interrupt blocking

- AUTOSAR Confidential 116

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: yqqq5

Integration and Runtime aspects - Scheduling

Data Consistency Example 1 Critical Sections Approach

Logical Architecture (Model)/

Technical Architecture (Schedule Module)
Task1

Xxx_Module

Xxx_MainFunction();

Yyy_ AccessResource();

Implementation of Schedule Module

#define SchM_Enter_<mod>_<name> \
/* nothing required */
#define SchM_Exit_<mod>_<name> \
/* nothing required */
Yyy_AccessResource() {
...
SchM_Enter_Xxx_XYZ();
<access_to_shared_resource>
SchM_Exit_Xxx_XYZ();
...
}
Yyy_MainFunction() {
...
SchM_Enter_Yyy_XYZ();
<access_to_shared_resource>
SchM_Exit_Yyy_XYZ();
...
}

XYZ resource
Yyy_MainFunction();
Task2
Transformation

Data consistency is ensured by:

Sequence

- AUTOSAR Confidential 117

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

Table of contents
1. Architecture
2. Configuration
3. Integration and Runtime aspects
1. Mapping of Runnables
2. Partitioning
3. Scheduling
4. Mode Management
5. Error Handling, Reporting and Diagnostic
6. Debugging
7. Measurement and Calibration
8. Functional Safety
9. Energy Management

- AUTOSAR Confidential 119

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: q222b

Integration and Runtime aspects

Vehicle and application mode management (1)
Relation of Modes:
Every system contains Modes at
different levels of granularity. As shown
in the figure, there are vehicle modes
and several applications with modes and
ECUs with local BSW modes.
Modes at all this levels influence each
other.

1
3

Influence each other

Application
Modes

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

Influence each other

- AUTOSAR Confidential -

2
1
3
3

Influence each other

BSW
Modes

1
3

Therefore:
Depending on vehicle modes, applications may be active or inactive and thus be in different
application modes.
Vice versa, the operational state of certain applications may cause vehicle mode changes.
Depending on vehicle and application modes, the BSW modes may change, e.g. the
communication needs of an application may cause a change in the BSW mode of a
communication network.
Vice versa, BSW modes may influence the modes of applications and even the whole
vehicle, e.g. when a communication network is unavailable, applications that depend on it
may change into a limp-home mode.

120

Vehicle
Modes

2
1

3
3

page id: q222e

Integration and Runtime aspects

Vehicle and application mode management (2)
Processing of Mode Requests
The basic idea of vehicle mode management is to distribute and arbitrate mode requests and to
control the BSW locally based on the results.
This implies that on each ECU, there has to be a mode manager that switches the modes for its local
mode users and controls the BSW. Of course there can also be multiple mode managers that
switch different Modes.
The mode request is a normal sender/receiver communication (system wide) while the mode
switch always a local service.
Mode
Requester

Mode
Request

Mode
Manager

Mode
Manager

- AUTOSAR Confidential 121

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

Mode
Switch

Mode
Switch

Mode
User

Mode
User

Integration and Runtime aspects

Vehicle and application mode management (3)

Application Layer
RTE
Memory
Services

Communication
Services

Onboard
Dev. Abstr.

Memory
HW Abstr.

COM HW
Abstr.

Microcontroller
Drivers

Memory
Drivers

Communication
Drivers

System Services

Layer
App

Functionality per module

Mode Arbitration SW-C

I/O HW
Abstraction

I/O
Drivers

Microcontroller (C)

RTE

Mode Request Distribution + Mode Handling

BswM

BSW

Mode Arbitration

Mode Control

The major part of the needed functionality is

placed in a new BSW module which we call
the Basic Software Mode Manager (BswM for
short). Since the BswM is located in the BSW,
it is present on every ECU and local to the
mode users as well as the controlled BSW
modules.

The distribution of mode requests is performed by the RTE and the RTE also implements
the handling of mode switches.
E.g. for vehicle modes, a mode request originates from one central mode requestor SW-C
and has to be received by the BswMs in many ECUs. This is an exception of the rule that
SW-Cs may only communicate to local BSW.
- AUTOSAR Confidential 122

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

Table of contents
1. Architecture
2. Configuration
3. Integration and Runtime aspects
1. Mapping of Runnables
2. Partitioning
3. Scheduling
4. Mode Management
5. Error Handling, Reporting and Diagnostic
6. Debugging
7. Measurement and Calibration
8. Functional Safety
9. Energy Management

- AUTOSAR Confidential 124

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 09op0

Integration and Runtime aspects - Error Handling, Reporting and Diagnostic

Error Classification (1)
Types of errors
Hardware errors / failures
Root cause: Damage, failure or value out of range, detected by software
Example 1: EEPROM cell is not writable any more
Example 2: Output voltage of sensor out of specified range
Software errors
Root cause: Wrong software or system design, because software itself can never fail.
Example 1: wrong API parameter (EEPROM target address out of range)
Example 2: Using not initialized data
System errors
Example 1: CAN receive buffer overflow
Example 2: time-out for receive messages

- AUTOSAR Confidential 125

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: nji98

Integration and Runtime aspects - Error Handling, Reporting and Diagnostic

Error Classification (2)
Time of error occurrence according to product life cycle
Development
Those errors shall be detected and fixed during development phase. In most cases, those errors are
software errors. The detection of errors that shall only occur during development can be switched off
for production code (by static configuration namely preprocessor switches).
Production / series
Those errors are hardware errors and software exceptions that cannot be avoided and are also expected
to occur in production code.

Influence of error on system

Severity of error (impact on the system)
No influence
Functional degradation
Loss of functionality
Failure mode in terms of time
Permanent errors
Transient / sporadic errors
- AUTOSAR Confidential 126

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: g7zre

Integration and Runtime aspects - Error Handling, Reporting and Diagnostic

Error Reporting Alternatives
Each basic software module distinguishes between two types of errors:
1. Development Errors
The detection and reporting can be statically switched on/off
2. Production relevant errors and exceptions
This detection is hard coded and always active.
There are several alternatives to report an error (detailed on the following slides):
Via API
Inform the caller about success/failure of an operation.
Via statically definable callback function (notification)
Inform the caller about failure of an operation
Via central Error Hook (Development Error Tracer)
For logging and tracing errors during product development. Can be switched off for production code.
Via central Error Function (AUTOSAR Diagnostic Event Manager)
For error reaction and logging in series (production code)
Each application software component (SW-C) can report errors to the Dlt.

- AUTOSAR Confidential 127

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

Integration and Runtime aspects - Error Handling, Reporting and Diagnostic

Mechanism in relation to AUTOSAR layers and system life time
Development Error
Tracer
(Det)
Diagnostic
Log
and Trace
(Dlt)

End to End
Communication
(E2E)

Application Layer
AUTOSAR Runtime Environment (RTE)
Basic Software

Diagnostic Event
Manger (Dem)
and Function
Inhibition
Manager (Fim)

Debugging
(Dbg)

ECU Hardware

Watchdog
(Wdg)

Life cycle:

development

production
- AUTOSAR Confidential -

128

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

After production

page id: oiuzt

Integration and Runtime aspects - Error Handling, Reporting and Diagnostic

Error Reporting Introduction
Error reporting via Diagnostic Event Manager (Dem)
For reporting production / series errors.
Those errors have a defined reaction depending on the configuration of this ECU, e.g.:
Writing to error memory
Disabling of ECU functions (e.g. via Function Inhibition Manager)
Notification of SW-Cs
The Diagnostic Event Manager is a standard AUTOSAR module which is always available in production code
and whose functionality is specified within AUTOSAR.
Error reporting via Development Error Tracer (Det)
For reporting development errors.
The Development Error Tracer is mainly intended for tracing and logging errors during development. Within the
Development Error Tracer many mechanisms are possible, e.g.:
Count errors
Write error information to ring buffer in RAM
Send error information via serial interface to external logger
Infinite Loop, Breakpoint
The Development Error Tracer is just a help for SW development and integration and is not necessarily
contained in the production code. The API is specified within AUTOSAR, but the functionality can be
chosen/implemented by the developer according to his specific needs.
The detection and reporting of development errors to the Development Error Tracer can be statically switched
on/off per module (preprocessor switch or two different object code builds of the module).
- AUTOSAR Confidential 130

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: fghjk

Integration and Runtime aspects - Error Handling, Reporting and Diagnostic

Error Reporting Diagnostic Event Manager
API
The Diagnostic Event Manager has semantically the following API:
Dem_ReportErrorStatus(EventId, EventStatus)

Problem: the error IDs passed with this API have to be ECU wide defined, have to be statically defined and have to occupy a
compact range of values for efficiency reasons. Reason: The Diagnostic Event Manager uses this ID as index for accessing
ROM arrays.
Error numbering concept: XML based error number generation
Properties:
Source and object code compatible
Single name space for all production relevant errors
Tool support required
Consecutive error numbers
Error manager can easily access ROM arrays where handling and reaction of errors is
defined
Process:
Each BSW Module declares all production code relevant error variables it needs as extern
Each BSW Module stores all error variables that it needs in the ECU configuration description (e.g. CANSM_E_BUS_OFF)
The configuration tool of the Diagnostic Event Manager parses the ECU configuration description and generates a single
file with global constant variables that are expected by the SW modules (e.g.
const Dem_EventIdType DemConf_DemEventParameter_CANSM_E_BUS_OFF=7U; or
#define DemConf_DemEventParameter_CANSM_E_BUS_OFF ((Dem_EventIdType)7))
The reaction to the errors is also defined in the Error Manager configuration tool. This configuration is project specific.

- AUTOSAR Confidential 131

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: ki87z

Integration and Runtime aspects - Error Handling, Reporting and Diagnostic

Error Reporting Development Error Tracer
API
The Development Error Tracer has syntactically the following API:
Det_ReportError(uint16 ModuleId, uint8 InstanceId, uint8 ApiId, uint8 ErrorId)
Error numbering concept
ModuleId (uint16)
The Module ID contains the AUTOSAR module ID from the Basic Software Module List.
As the range is 16 Bit, future extensions for development error reporting of application SW-C are possible. The Basic SW
uses only the range from 0..255.
InstanceId (uint8)
The Instance ID represents the identifier of an indexed based module starting from 0. If the module is a single instance
module it shall pass 0 as an instance ID.
ApiId (uint8)
The API-IDs are specified within the software specifications of the BSW modules. They can be #defines or constants
defined in the module starting with 0.
ErrorId (uint8)
The Error IDs are specified within the software specifications of the BSW modules. They can be #defines defined in the
modules header file.
If there are more errors detected by a particular software module which are not specified within the AUTOSAR module
software specification, they have to be documented in the module documentation.
All Error-IDs have to be specified in the BSW description.

- AUTOSAR Confidential 132

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: yecvb

Integration and Runtime aspects - Error Handling, Reporting and Diagnostic

Error Reporting Diagnostic Log and Trace (1)
The module Diagnostic Log and Trace (Dlt) collects log messages and converts them into a
standardized format. The Dlt forwards the data to the Dcm or a CDD which uses a serial
interface for example.
Therefore the Dlt provides the following functionalities:
Logging
logging of errors, warnings and info messages from AUTOSAR SW-Cs, providing a
standardized AUTOSAR interface,
gathering all log and trace messages from all AUTOSAR SW-Cs in a centralized
AUTOSAR service component (Dlt) in the BSW,
logging of messages from Det and
logging of messages from Dem.
Tracing
of RTE activities
Control
individual log and trace messages can be enabled/disabled and
Log levels can be controlled individually by back channel.
Generic
Dlt is available during development and production phase,
access over standard diagnosis or platform specific test interface is possible and
security mechanisms to prevent misuse in production phase are provided.
- AUTOSAR Confidential 133

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

Table of contents
1. Architecture
2. Configuration
3. Integration and Runtime aspects
1. Mapping of Runnables
2. Partitioning
3. Scheduling
4. Mode Management
5. Error Handling, Reporting and Diagnostic
6. Debugging
7. Measurement and Calibration
8. Functional Safety
9. Energy Management

- AUTOSAR Confidential 136

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

pageid: 11231

Integration and Runtime aspects - Debugging

Debugging Module - functional overview
The goal of the Debugging Module is to support a user (system integrator or BSW developer)
during development, in case the basic software does not behave as expected. To do so, it
collects as much information as possible about the runtime behavior of the systems without
halting the processor. This data is transmitted to an external host system via communication,
to enable the user to identify the source of a problem. An internal buffer is provided to
decouple data collection from data transmission.
Main tasks of the Debugging Module are to
Collect and store data for tracing purposes
Collect and immediately transmit data to host
Modify data in target memory on host request
Transmit stored data to host
Accept commands to change the behavior of the Debugging Module

- AUTOSAR Confidential 137

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

Table of contents
1. Architecture
2. Configuration
3. Integration and Runtime aspects
1. Mapping of Runnables
2. Partitioning
3. Scheduling
4. Mode Management
5. Error Handling, Reporting and Diagnostic
6. Debugging
7. Measurement and Calibration
8. Functional Safety
9. Energy Management

- AUTOSAR Confidential 146

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture