Layered Software Architecture

- AUTOSAR Confidential -
 Document Title Layered Software Architecture

Document Owner AUTOSAR

Document Responsibility AUTOSAR

Document Identification No 053

Document Classification Auxiliary

Document Version 3.2.0

Document Status Final

Part of Release 4.0

Revision 3

- AUTOSAR Confidential -

2 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

 Document Change History
Date Version Changed by Change Description
06.10.2011 3.2.0 AUTOSAR  added a note for the R3-compatibility FlexRay Transport Layer FrArTp on slide "ki890".
Administration  added an overview chapter for energy management and partial networking
 corrected examples regarding DEM symbol generation
 fixed minor typography issues
 clarification of term AUTOSAR-ECU on slide "94jt1"
 corrected CDD access description for EcuM on slide "11123“
24.11.2010 3.1.0 AUTOSAR  added a note regarding support for System Basis Chips on slide "94juq“
Administration  clarification of DBG and DLT text on slide "3edfg"
 corrected DBG description on slide "11231"
30.11.2009 3.0.0 AUTOSAR  The document has been newly structured. There are now 3 main parts:
Administration  Architecture
 Configuration
 Integration and Runtime aspects
 The whole content has been updated to reflect the content of the R 4.0 specifications.
 Topics which have bee newly introduced or heavily extended in release 4.0 have been
added. E.g.,. Multi Core systems, Partitioning, Mode Management, Error Handling,
Reporting and Diagnostic, Debugging, Measurement and Calibration, Functional Safety etc
 Legal disclaimer revised
23.06.2008 2.2.1 AUTOSAR  Legal disclaimer revised
Administration

- AUTOSAR Confidential -

3 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

 Document Change History
Date Version Changed by Change Description
15.11.2007 2.2.0 AUTOSAR  Updates based on new wakeup/startup concepts
Administration  Detailed explanation for post-build time configuration
 "Slimming" of LIN stack description
 ICC2 figure
 Document meta information extended
 Small layout adaptations made
06.02.2007 2.1.0 AUTOSAR  ICC clustering added.
Administration  Document contents harmonized
 Legal disclaimer revised
 Release Notes added
 “Advice for users” revised
 “Revision Information” added
21.03.2006 2.0.0 AUTOSAR Rework Of:
Administration  Error Handling
 Scheduling Mechanisms
 More updates according to architectural decisions in R2.0
31.05.2005 1.0.1 AUTOSAR  Correct version released
Administration
09.05.2005 1.0.0 AUTOSAR  Initial release
Administration

- AUTOSAR Confidential -

4 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

 Disclaimer

Disclaimer
This specification and the material contained in it, as released by AUTOSAR, is for the purpose of information only. AUTOSAR and the
companies that have contributed to it shall not be liable for any use of the specification.
The material contained in this specification is protected by copyright and other types of Intellectual Property Rights. The commercial
exploitation of the material contained in this specification requires a license to such Intellectual Property Rights.
This specification may be utilized or reproduced without any modification, in any form or by any means, for informational purposes only.
For any other purpose, no part of the specification may be utilized or reproduced, in any form or by any means, without permission in
writing from the publisher.
The AUTOSAR specifications have been developed for automotive applications only. They have neither been developed, nor tested for
non-automotive applications.
The word AUTOSAR and the AUTOSAR logo are registered trademarks.

Advice for users

AUTOSAR specifications may contain exemplary items (exemplary reference models, "use cases", and/or references to exemplary
technical solutions, devices, processes or software).
Any such exemplary items are contained in the specifications for illustration purposes only, and they themselves are not part of the
AUTOSAR Standard. Neither their presence in such specifications, nor any later documentation of AUTOSAR conformance of products
actually implementing such exemplary items, imply that intellectual property rights covering such exemplary items are licensed under
the same rules as applicable to the AUTOSAR Standard.

- AUTOSAR Confidential -

5 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 94jt4

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

page id: 94jt2
Introduction
Purpose and Inputs

Purpose of this document

The Layered Software Architecture describes the software architecture of AUTOSAR:
 it describes in an top-down approach the hierarchical structure of AUTOSAR software and
 maps the Basic Software Modules to software layers and
 shows their relationship.

This document does not contain requirements and is informative only. The examples given are
not meant to be complete in all respects.

This document focuses on static views of a conceptual layered software architecture:

 it does not specify a structural software architecture (design) with detailed static and dynamic
interface descriptions,
 these information are included in the specifications of the basic software modules
themselves.

Inputs
This document is based on specification and requirement documents of AUTOSAR.

- AUTOSAR Confidential -

16 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 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

page id: 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

page id: 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

Complex
ECU Abstraction Layer Drivers

Microcontroller Abstraction Layer

Microcontroller

- AUTOSAR Confidential -

19 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 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 I/O Hardware Abstraction Complex
Drivers

Onboard Device Memory Hardware Communication

Abstraction Abstraction Hardware Abstraction

Microcontroller Drivers Memory Drivers Communication Drivers I/O Drivers

Microcontroller

- AUTOSAR Confidential -

20 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 94ju6
Architecture – Overview of Software Layers
Microcontroller Abstraction Layer

The Microcontroller Abstraction Layer is the

lowest software layer of the Basic Software. Application Layer

It contains internal drivers, which are software

RTE
modules with direct access to the µC and
internal peripherals. Co
mpl
ex
ECU Abstraction Layer Dri
Task ver
s
Make higher software layers independent of µC Microcontroller Abstraction Layer

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

- AUTOSAR Confidential -

21 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 94ju7
Architecture – Overview of Software Layers
ECU Abstraction Layer

The ECU Abstraction Layer interfaces the Application Layer

drivers of the Microcontroller Abstraction
Layer. It also contains drivers for external RTE
devices.
Co
It offers an API for access to peripherals and mpl
devices regardless of their location (µC ECU
ECU Abstraction
Abstraction Layer
Layer
ex
Dri
internal/external) and their connection to the ver
s
µC (port pins, type of interface) 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

page id: 94jwe
Architecture – Overview of Software Layers
Complex Drivers

The Complex Drivers Layer spans from the

Application Layer
hardware to the RTE.
RTE
Task
Services Layer
Provide the possibility to integrate special purpose

Complex
Drivers
functionality, e.g. drivers for devices: ECUECU Abstraction
Abstraction Layer
Layer
 which are not specified within AUTOSAR,
Microcontroller Abstraction Layer
 with very high timing constrains or
 for migration purposes etc. Microcontroller

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

page id: 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 Application Layer

the application software: while access to I/O

signals is covered by the ECU Abstraction Layer, RTE

the Services Layer offers:

Services Layer
 Operating system functionality

Complex
Drivers
 Vehicle network communication and management
ECUECU Abstraction
Abstraction Layer
Layer
services
 Memory services (NVRAM management) Microcontroller Abstraction Layer
 Diagnostic Services (including UDS communication, error
memory and fault treatment) Microcontroller
 ECU state management, mode management
 Logical and temporal program flow monitoring (Wdg
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

page id: 94ju9
Architecture – Overview of Software Layers
AUTOSAR Runtime Environment (RTE)

The RTE is a layer providing communication services

to the application software (AUTOSAR Software Application Layer
Components and/or AUTOSAR Sensor/Actuator
components). AUTOSAR Runtime Environment (RTE)

Services Layer
Above the RTE the software architecture style

Complex
Drivers
changes from “layered“ to “component style“.
ECUECU Abstraction
Abstraction Layer
Layer

The AUTOSAR Software Components communicate Microcontroller Abstraction Layer

with other components (inter and/or intra ECU)
Microcontroller
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

page id: 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

page id: 94jui
Architecture – Introduction to Basic Software Module Types
Driver (internal)

A driver contains the functionality to control and access an internal or an external device.

Internal devices are located inside the microcontroller. Examples for internal devices are:
 Internal EEPROM
 Internal CAN controller
 Internal ADC

A driver for an internal device is called internal driver and is located in the Microcontroller
Abstraction Layer.

- AUTOSAR Confidential -

27 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 94juq
Architecture – Introduction to Basic Software Module Types
Driver (external)

External devices are located on the ECU hardware outside the microcontroller. Examples for
external devices are:
 External EEPROM
 External watchdog
 External flash

A driver for an external device is called external driver and is located in the ECU Abstraction
Layer. It accesses the external device via drivers of the Microcontroller Abstraction Layer.
This way also components integrated in System Basis Chips (SBCs) like transceivers and
watchdogs are supported by AUTOSAR.

 Example: a driver for an external EEPROM with SPI interface accesses the external
EEPROM via the handler/driver for the SPI bus.

Exception:
The drivers for memory mapped external devices (e.g. external flash memory) may access the
microcontroller directly. Those external drivers are located in the Microcontroller Abstraction
Layer because they are microcontroller dependent.

- AUTOSAR Confidential -

28 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id:94jwx
Architecture – Introduction to Basic Software Module Types
Interface

An Interface (interface module) contains the functionality to abstract from modules which are
architecturally placed below them. E.g., an interface module which abstracts from the
hardware realization of a specific device. It provides a generic API to access a specific type of
device independent on the number of existing devices of that type and independent on the
hardware realization of the different devices.

The interface does not change the content of the data.

In general, interfaces are located in the ECU Abstraction Layer.

Example: an interface for a CAN communication system provides a generic API to access CAN
communication networks independent on the number of CAN Controllers within an ECU and
independent of the hardware realization (on chip, off chip).

- AUTOSAR Confidential -

29 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 94jww
Architecture – Introduction to Basic Software Module Types
Handler

A handler is a specific interface which controls the concurrent, multiple and asynchronous
access of one or multiple clients to one or more drivers. I.e. it performs buffering, queuing,
arbitration, multiplexing.

The handler does not change the content of the data.

Handler functionality is often incorporated in the driver or interface (e.g. SPIHandlerDriver, ADC
Driver).

- AUTOSAR Confidential -

30 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 94j22
Architecture – Introduction to Basic Software Module Types
Manager

A manager offers specific services for multiple clients. It is needed in all cases where pure
handler functionality is not enough to abstract from multiple clients.

Besides handler functionality, a manager can evaluate and change or adapt the content of the
data.

In general, managers are located in the Services Layer

Example: The NVRAM manager manages the concurrent access to internal and/or external
memory devices like flash and EEPROM memory. It also performs distributed and reliable
data storage, data checking, provision of default values etc.

- AUTOSAR Confidential -

31 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 99j22
Architecture – Overview of Software Layers
Introduction to Libraries

Libraries are a collection of functions for

related purposes Application Layer

AUTOSAR Libraries
Libraries: Runtime Environment (RTE)
 can be called by BSW modules (that Basic Software
including the RTE), SW-Cs, libraries
or integration code
 run in the context of the caller in the
same protection environment
 can only call libraries
 are re-entrant ECU Hardware

 do not have internal states

 do not require any initialization
 are synchronous, i.e. they do not have
wait points
The following libraries are
specified within AUTOSAR:
 Fixed point mathematical,  Interpolation for floating point data,  CRC calculation,
 Floating point mathematical,  Bit handling,  Extended functions (e.g. 64bits
 Interpolation for fixed point data,  E2E communication, calculation, filtering, etc.) and
 Crypto
- AUTOSAR Confidential -

32 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 95jt4

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

page id: oiu42
Architecture – Content of Software Layers Application Layer
Microcontroller Abstraction Layer RTE
Communi-
Memory
cation

Complex Drivers
System Services Services I/O HW
The µC Abstraction Layer consists of the following module groups: Services
Abstraction
Onboard Memory COM HW
Dev. Abstr. HW Abstr. Abstr.
 Communication Drivers Micro- Communi-
Drivers for ECU onboard (e.g. SPI) and vehicle communication (e.g. CAN). controller
Memory
cation
I/O
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)
Functions with direct µC access (e.g. Core test) Group of
Software
modules of
Microcontroller Drivers Memory Drivers Communication Drivers I/O Drivers
similar type

internal EEPROM Driver

internal Flash Driver

SPI Handler Driver

Watchdog Driver

Ethernet Driver
FlexRay Driver

PORT Driver
PWM Driver
MCU Driver

ADC Driver
CAN Driver
GPT Driver

Flash Test

DIO Driver
ICU Driver
LIN Driver
RAM Test
Core Test

Software
module

internal
Clock Unit

EEPROM

peripheral
Power &

FLASH

LIN or

PWM
CCU
WDT

MCU

CAN

ADC
GPT

DIO
SCI
SPI

Microcontroller device

- AUTOSAR Confidential -

34 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: swr42
Architecture – Content of Software Layers Application Layer
Microcontroller Abstraction Layer: SPIHandlerDriver RTE
Communi-
Memory
cation

Complex Drivers
System Services Services
Services I/O HW
Abstraction
The SPIHandlerDriver allows concurrent Onboard Memory COM HW
Dev. Abstr. HW Abstr. Abstr.
access of several clients to one or more SPI Micro-
Memory
Communi-
I/O
controller cation
busses. Drivers
Drivers
Drivers
Drivers

Microcontroller (µC)

To abstract all features of a SPI microcontroller

pins dedicated to Chip Select, those shall
directly be handled by the SPIHandlerDriver.
That means those pins shall not be available
in DIO Driver.
Example:
Onboard Device Memory Hardware I/O Hardware Abstraction
Abstraction Abstraction

External
External Driver for ext. Driver for ext.
EEPROM
Watchdog Driver ADC ASIC I/O ASIC
Driver

Communication Drivers

SPIHandlerDriver

µC SPI

- AUTOSAR Confidential -

35 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 21112
Architecture – Content of Software Layers Application Layer
Complex Drivers RTE
Communi-
Memory
cation

Complex Drivers
System Services Services
Services I/O HW
A Complex Driver is a module which implements non- Onboard Memory COM HW
Abstraction

standardized functionality within the basic software Dev. Abstr. HW Abstr. Abstr.
Micro- Communi-
stack. controller
Memory
cation
I/O
Drivers Drivers
Drivers Drivers
Microcontroller (µC)
An example is to implement complex sensor
evaluation and actuator control with direct access
to the µC using specific interrupts and/or complex Example:
µC peripherals (like PCP, TPU), e.g.
Complex Drivers
 Injection control
 Electric valve control
 Incremental position detection

Incremental Position Detection

Complex Device Driver XY

Electric Valve Control

Injection Control
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)

e.g. CCU
e.g. PCP
e.g. TPU
Lower interface: restricted access to Standardized µC
Interfaces

- AUTOSAR Confidential -

36 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: ddeaq
Architecture – Content of Software Layers Application Layer
ECU Abstraction: I/O Hardware Abstraction RTE
Communi-
Memory
cation

Complex Drivers
System Services Services
Services I/O HW
The I/O Hardware Abstraction is a group of modules Onboard Memory COM HW
Abstraction

which abstracts from the location of peripheral I/O Dev. Abstr. HW Abstr. Abstr.
Micro- Communi-
devices (on-chip or on-board) and the ECU controller
Memory
cation
I/O
Drivers Drivers
hardware layout (e.g. µC pin connections and Drivers Drivers

signal level inversions). The I/O Hardware Microcontroller (µC)

Abstraction does not abstract from the
sensors/actuators!

The different I/O devices might be accessed via an I/O

signal interface. Example:
I/O Hardware Abstraction

Task: I/O Signal Interface

Represent I/O signals as they are connected to the

ECU hardware (e.g. current, voltage, frequency). Driver for ext.
ADC ASIC
Driver for ext.
I/O ASIC
Hide ECU hardware and layout properties from higher
software layers.
COM Drivers I/O Drivers

SPIHandler

ADC Driver
DIO Driver
Properties:

Driver
Implementation: µC independent, ECU hardware
dependent
Upper Interface: µC and ECU hardware independent,
dependent on signal type specified and

ADC
DIO
SPI
implemented according to AUTOSAR (AUTOSAR µC
interface)

- AUTOSAR Confidential -

37 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: zzttz
Architecture – Content of Software Layers Application Layer
ECU Abstraction: Communication Hardware Abstraction RTE
Communi-
Memory
cation

Complex Drivers
System Services Services
Services I/O HW
Abstraction
The Communication Hardware Abstraction is a Onboard Memory COM HW
Dev. Abstr. HW Abstr. Abstr.
group of modules which abstracts from the Micro- Communi-
Memory I/O
location of communication controllers and the ECU controller
Drivers
cation
Drivers
Drivers Drivers
hardware layout. For all communication systems a
Microcontroller (µC)
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 Example:
connected to the microcontroller via SPI. Communication Hardware Abstraction

The communication drivers are accessed via bus CAN Interface

specific interfaces (e.g. CAN Interface).
CAN
Trans- Driver for ext.
ceiver CAN ASIC
Task: Driver

Provide equal mechanisms to access a bus channel I/O Drivers Communication Drivers

regardless of it‘s location (on-chip / on-board)

SPIHandler

CAN Driver
DIO Driver

Driver
Properties:
Implementation: µC independent, ECU hardware
dependent and external device dependent

CAN
DIO

SPI
µC
Upper Interface: bus dependent, µC and ECU
hardware independent

- AUTOSAR Confidential -

38 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: wwwaa
Architecture – Content of Software Layers Application Layer
Scope: Memory Hardware Abstraction RTE
Communi-
Memory
cation

Complex Drivers
System Services Services
Services I/O HW
The Memory Hardware Abstraction is a group of Onboard Memory COM HW
Abstraction

modules which abstracts from the location of Dev. Abstr. HW Abstr. Abstr.
peripheral memory devices (on-chip or on-board) Micro-
Memory
Communi-
I/O
controller cation
and the ECU hardware layout. Drivers
Drivers
Drivers
Drivers

Example: on-chip EEPROM and external EEPROM Microcontroller (µC)

devices are accessible via the same
mechanism.

The memory drivers are accessed via memory specific Example:

abstraction/emulation modules (e.g. EEPROM Memory Hardware Abstraction
Abstraction).
Memory Abstraction Interface
By emulating an EEPROM abstraction on top of Flash
hardware units a common access via Memory Flash EEPROM
EEPROM Abstraction
Abstraction Interface to both types of hardware is Emulation
enabled.
External External
EEPROM Driver Flash Driver
Task:
Provide equal mechanisms to access internal (on-chip)
and external (on-board) COM Drivers Memory Drivers
memory devices and type of memory hardware

Flash Driver
SPIHandler

EEPROM
(EEPROM, Flash).

Internal
Driver
Driver
Properties:
Implementation: µC independent, external device
dependent

EEPROM

Flash
SPI
Upper Interface: µC, ECU hardware and memory µC
device independent

- AUTOSAR Confidential -

39 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: xxdxx
Architecture – Content of Software Layers Application Layer
Onboard Device Abstraction RTE
Communi-
Memory
cation

Complex Drivers
System Services Services
Services I/O HW
Abstraction
The Onboard Device Abstraction contains Onboard Memory COM HW
Dev. Abstr. HW Abstr. Abstr.
drivers for ECU onboard devices which Micro-
Memory
Communi-
I/O
controller cation
cannot be seen as sensors or actuators like Drivers
Drivers
Drivers
Drivers

internal or external watchdogs. Those Microcontroller (µC)

drivers access the ECU onboard devices via

the µC Abstraction Layer.

Example:
Task: Onboard Device Abstraction
Abstract from ECU specific onboard devices. Watchdog Interface

External
Watchdog Driver

Properties: COM Drivers Microcontroller

Drivers
Implementation: µC independent, external

SPIHandler

watchdog
Driver
device dependent

internal
driver
Upper Interface: µC independent, partly ECU
hardware dependent

Wdg
SPI
µC

- AUTOSAR Confidential -

40 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: yyxyy
Architecture – Content of Software Layers Application Layer
Communication Services – General RTE
Communi-
Memory
cation

Complex Drivers
System Services Services
Services I/O HW
The Communication Services are a group of Onboard Memory COM HW
Abstraction

modules for vehicle network communication (CAN, Dev. Abstr. HW Abstr. Abstr.
Micro- Communi-
LIN and FlexRay). They interface with the controller
Memory
cation
I/O
Drivers Drivers
communication drivers via the communication Drivers Drivers

hardware abstraction. Microcontroller (µC)

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 Example:
diagnostic communication Communication Services
Hide protocol and message properties from the Generic NM
application. DCM Interface
AUTOSAR Diagnostic
Debugging
COM Com.
Manager
Properties: <Bus
specific>
Implementation: µC and ECU HW independent, partly State <Bus
Manager
dependent on bus type PDU Router
specific>
NM
IPDU
Upper Interface: µC, ECU hardware and bus type Multiplexer
<Bus specific>
independent Transport Protocol

The communication services will be detailed for each

Bus specific modules
relevant vehicle network system on the following
pages.

- AUTOSAR Confidential -

41 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: ppopp
Architecture – Content of Software Layers Application Layer
Communication Stack – CAN RTE
Communi-
Memory
cation

Complex Drivers
System Services Services
Services I/O HW
Example: Abstraction
Onboard Memory COM HW
Communication Services Dev. Abstr. HW Abstr. Abstr.
Micro- Communi-
Memory I/O
Generic NM controller cation

Debugging
Diagnostic
Drivers Drivers
Manager
Com. Interface Drivers Drivers
AUTOSAR
COM Microcontroller (µC)

CAN
State
PDU Router Manager The CAN Communication Services are a group of modules
Multiplexer

CAN NM
for vehicle network communication with the communication
IPDU

CAN Transport
Protocol
J1939 Transport
system CAN.
Protocol
Task:
Communication Hardware Abstraction  Provide a uniform interface to the CAN network. Hide
protocol and message properties from the application.
CAN Interface

CAN Transceiver Driver for ext.

Driver CAN ASIC Please Note:
 There are two transport protocol modules in the CAN stack
I/O Drivers Communication Drivers
which can be used alternatively or in parallel: CanTp and
DIO Driver
SPIHandler
Driver
CAN Driver J1939Tp. They are used as follows:
 CanTp: ISO Diagnostics (DCM), large PDU transport
µC SPI CAN
on standard CAN bus
 - J1939Tp: J1939 Diagnostics, large PDU transport on
External J1939 driven CAN bus
CAN Controller

- AUTOSAR Confidential -

42 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: bbnnh
Architecture – Content of Software Layers Application Layer
Communication Stack – CAN RTE
Communi-
Memory
cation

Complex Drivers
System Services Services
Services I/O HW
Abstraction
Properties: Onboard
Dev. Abstr.
Memory
HW Abstr.
COM HW
Abstr.
 Implementation: µC and ECU HW independent, partly Micro-
Memory
Communi-
I/O
controller cation
dependent on CAN. Drivers
Drivers
Drivers
Drivers

 AUTOSAR COM, Generic NM (Network Management) Microcontroller (µC)

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

page id: qwwwe
Architecture – Content of Software Layers Application Layer
Communication Stack Extension – TTCAN RTE
Communi-
Memory
cation

Complex Drivers
System Services Services
Services I/O HW
Example: Abstraction
Onboard Memory COM HW
Communication Services Dev. Abstr. HW Abstr. Abstr.
Micro- Communi-
Memory I/O
Generic NM controller cation

Debugging
Diagnostic
Drivers Drivers
Manager
Com. Interface Drivers Drivers
AUTOSAR
COM Microcontroller (µC)

CAN
State
Manager The TTCAN Communication Services are the optional
multiplexer

PDU Router CAN NM

IPDU

extensions of the plain CAN Interface and CAN Driver module

CAN Transport for vehicle
Protocol
network communication with the communication system
Communication Hardware Abstraction TTCAN.
CAN Interface
Task:
TTCAN
 Provide a uniform interface to the TTCAN network. Hide
CAN Transceiver Driver for ext.
Driver CAN ASIC protocol and message properties from the application.

I/O Drivers Communication Drivers

SPIHandler
Please Note:
DIO Driver CAN Driver TTCAN
Driver
 The CAN Interface with TTCAN can serve both a
µC SPI TTCAN
plain CAN Driver and a CAN Driver TTCAN.

External
TTCAN Controller

- AUTOSAR Confidential -

44 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: ggghh
Architecture – Content of Software Layers Application Layer
Communication Stack Extension – TTCAN RTE
Communi-
Memory
cation

Complex Drivers
System Services Services
Services I/O HW
Abstraction
Properties: Onboard
Dev. Abstr.
Memory
HW Abstr.
COM HW
Abstr.

 TTCAN is an absolute superset to CAN, i.e. a CAN stack Micro-

controller
Memory
Communi-
cation
I/O
Drivers Drivers
which supports TTCAN can serve both a CAN and a Drivers Drivers
Microcontroller (µC)
TTCAN bus.
 CanIf and CanDrv are the only modules which need
extensions to serve TTCAN communication.
 The properties of the communication stack CAN are also
true for CAN with TTCAN functionality.

- AUTOSAR Confidential -

45 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 87z66
Architecture – Content of Software Layers Application Layer
Communication Stack – LIN (LIN Master) RTE
Communi-
Memory
cation

Complex Drivers
System Services Services
Services I/O HW
Abstraction
Example: Onboard Memory COM HW
Dev. Abstr. HW Abstr. Abstr.
Micro- Communi-
Communication Services Memory I/O
controller cation
Drivers Drivers
Drivers Drivers
Generic
Diagnostic

Microcontroller (µC)
Manager

NM
Com.

AUTOSAR
Interface
COM
LIN State
The LIN Communication Services are a group of modules for vehicle
Manager network communication with the communication system LIN.
LIN NM
PDU Router Task:
Provide a uniform interface to the LIN network. Hide protocol and
message properties from the application.
Communication Hardware Abstraction

LIN Interface Properties:

LIN Transceiver Driver for ext.
Driver LIN ASIC The LIN Communication Services contain:
 A LIN 2.1 compliant communication stack with
Communication Drivers  Schedule table manager for transmitting LIN frames and to
handle requests to switch to other schedule tables.
LIN Driver
 Transport protocol, used for diagnostics
 A WakeUp and Sleep Interface
µC SCI  An underlying LIN Driver:
 implementing the LIN protocol and adaptation the specific
hardware
 Supporting both simple UART and complex frame based LIN
hardware

- AUTOSAR Confidential -

46 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 66766
Architecture – Content of Software Layers Application Layer
Communication Stack – LIN RTE
Communi-
Memory
cation

Complex Drivers
System Services Services
Services I/O HW
Abstraction
Note: Integration of LIN into AUTOSAR: Onboard
Dev. Abstr.
Memory
HW Abstr.
COM HW
Abstr.

 Lin Interface controls the WakeUp/Sleep API Micro-

controller
Memory
Communi-
cation
I/O
Drivers Drivers
and allows the slaves to keep the bus awake Drivers Drivers
Microcontroller (µC)
(decentralized approach).
 The communication system specific LIN State
Manager handles the communication
dependent Start-up and Shutdown features.
Furthermore it controls the communication
mode requests from the Communication
Manager. The LIN state manager also
controls the I-PDU groups by interfacing
COM.
 When sending a LIN frame, the LIN Interface
requests the data for the frame (I-PDU) from
the PDU Router at the point in time when it
requires the data (i.e. right before sending
the LIN frame).

- AUTOSAR Confidential -

47 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 1122d
Architecture – Content of Software Layers Application Layer
Communication Services – LIN Slave RTE
Communi-
Memory
cation

Complex Drivers
System Services Services
Services I/O HW
Abstraction
LIN Slaves usually are „intelligent“ actuators and Onboard Memory COM HW
Dev. Abstr. HW Abstr. Abstr.
slaves that are seen as black boxes. As they Micro- Communi-
Memory I/O
provide very little hardware capabilities and controller
Drivers
cation
Drivers
Drivers Drivers
resources, it is not intended to shift AUTOSAR SW-
Microcontroller (µC)
Components onto such systems. Therefore it is not
necessary to have an AUTOSAR system on LIN
Slaves.

LIN Slave ECUs can be integrated into the AUTOSAR

VFB using their Node Capability Descriptions. They Example:
are seen as non-AUTOSAR ECUs. Please refer to
the VFB specification. LIN Slave Application
That means: LIN Slaves can be connected as
complete ECUs. But they are not forced to use the
AUTOSAR SW Architecture. Perhaps they can use Communication Drivers
some standard AUTOSAR modules (like EEPROM,
LIN Communication
DIO). Stack

Reason: LIN slaves usually have very limited memory

resources or are ASICs with „hard-coded“ logic. µC SCI

Note: LIN slaves cannot fulfill the requirements to a

Debugging Host, since LIN is not a multi-master
bus.
- AUTOSAR Confidential -

48 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: ki890
Architecture – Content of Software Layers Application Layer
Communication Stack – FlexRay RTE
Communi-
Memory
cation

Complex Drivers
Example: System Services Services
Services I/O HW
Abstraction
Communication Services Onboard Memory COM HW
Dev. Abstr. HW Abstr. Abstr.
Generic Micro- Communi-

Debugging
Diagnostic
NM Memory I/O
Manager controller cation
Com.
AUTOSAR Interface Drivers Drivers
Drivers Drivers
COM
Microcontroller (µC)
FlexRay
State
Manager The FlexRay Communication Services are a group
PDU Router FlexRay
of modules for vehicle network communication with
multiplexer

NM
IPDU

the communication system FlexRay.

FlexRay Transport
Protocol

Task:
Communication Hardware Abstraction
 Provide a uniform interface to the FlexRay network.
FlexRay Interface
Hide protocol and message properties from the
application.
Driver for FlexRay Driver for external
Transceiver FlexRay Controller

I/O Drivers Communication Drivers

Please Note:
 There are two transport protocol modules in the
DIO Driver SPIHandlerDriver
Driver for internal
FlexRay Controller
FlexRay stack which can be used alternatively
 FrTp: FlexRay ISO Transport Layer
 FrArTp: FlexRay AUTOSAR Transport Layer,
Host µC Internal FlexRay Controller
provides bus compatibility to AUTOSAR R3.x
Data lines
External External
FlexRay Controller FlexRay Transceiver Control/status lines
(e.g. MFR 4200) (e.g. TJA 1080)

- AUTOSAR Confidential -

49 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 42432
Architecture – Content of Software Layers Application Layer
Communication Stack – FlexRay RTE
Communi-
Memory
cation

Complex Drivers
System Services Services
Services I/O HW
Abstraction
Properties: Onboard Memory COM HW
Dev. Abstr. HW Abstr. Abstr.
 Implementation: µC and ECU HW independent, Micro-
Memory
Communi-
I/O
controller cation
partly dependent on FlexRay. Drivers
Drivers
Drivers
Drivers

 AUTOSAR COM, Generic NM Interface and Microcontroller (µC)

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 is replaced by the NM
Coordinator which in addition provides the
functionality to synchronize multiple different
networks (of the same or different types) to
synchronously wake them up or shut them down.
 FlexRay NM is specific for FlexRay networks and is
instantiated per FlexRay vehicle network system.
 The communication system specific FlexRay 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 -

50 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 44566
Architecture – Content of Software Layers Application Layer
Communication Stack – TCP/IP RTE
Communi-
Memory
cation

Complex Drivers
Example: System Services Services
Services I/O HW
Abstraction
Onboard Memory COM HW
Communication Services Dev. Abstr. HW Abstr. Abstr.
Micro- Communi-
Memory I/O
Generic NM controller cation

Debugging
Diagnostic
Drivers Drivers
Manager Interface Drivers Drivers
Com.
AUTOSAR
COM Microcontroller (µC)

Ethernet
UDP NM
State The TCP/IP Communication Services are a
Manager
group of modules for vehicle network
multiplexer

PDU Router
IPDU

communication with the communication

DoIP Socket Adaptor system TCP/IP.

Communication Hardware Abstraction

Task:
Ethernet Interface
 Provide a uniform interface to the TCP/IP
Ethernet Transceiver Driver
network. Hide protocol and message
properties from the application.
I/O Drivers Communication Drivers

DIO Driver Handler / Driver Ethernet Driver

µC MII Ethernet

External
Ethernet Controller

- AUTOSAR Confidential -

51 10 November 2011 Layered

Document
Software
ID 053
Architecture
: AUTOSAR_EXP_LayeredSoftwareArchitecture
- Document ID 053 - V 2.3 - R 4.0 Rev 0001
page id: qqeet
Architecture – Content of Software Layers Application Layer
Communication Stack – TCP/IP – Socket Adaptor RTE
Communi-
Memory
cation

Complex Drivers
System Services Services
Services I/O HW
Abstraction
Properties: Onboard
Dev. Abstr.
Memory
HW Abstr.
COM HW
Abstr.

 The SoAd Module fully contains the DoIP Micro-

controller
Memory
Communi-
cation
I/O
Drivers Drivers
protocol handler. Drivers Drivers
Microcontroller (µC)
 The SoAd provides two APIs towards the
TCP/IP stack.
 The TCP/IP Stack may contain a multitude
of protocol handlers including, but not limited
to UDP, TCP, DHCP, ARP, ICMP, and
others.
 The TCP/IP stack is not intended as an
AUTOSAR Module, but is defined by the
interfaces only.

- AUTOSAR Confidential -

52 10 November 2011 Layered

Document
Software
ID 053
Architecture
: AUTOSAR_EXP_LayeredSoftwareArchitecture
- Document ID 053 - V 2.3 - R 4.0 Rev 0001
page id: bbnnq
Architecture – Content of Software Layers Application Layer
Communication Stack – General RTE
Communi-
Memory
cation

Complex Drivers
System Services Services
Services I/O HW
Abstraction
General communication stack properties: Onboard
Dev. Abstr.
Memory
HW Abstr.
COM HW
Abstr.
Micro- Communi-
Memory I/O
controller cation
Drivers Drivers
Drivers Drivers
 A signal gateway is part of AUTOSAR COM to route Microcontroller (µC)
signals.
 PDU based Gateway is part of PDU router.
 IPDU multiplexing provides the possibility to add
information to enable the multiplexing of I-PDUs (different
contents but same IDs on the bus).
 Upper Interface: µC, ECU hardware and network type
independent.
 For refinement of GW architecture please refer to
“Example Communication”

- AUTOSAR Confidential -

53 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 9ddff
Architecture – Content of Software Layers Application Layer
Services: Memory Services RTE
Communi-
Memory
cation

Complex Drivers
System Services Services
Services I/O HW
Abstraction
The Memory Services consist of one module, Onboard Memory COM HW
Dev. Abstr. HW Abstr. Abstr.
the NVRAM Manager. It is responsible for Micro-
Memory
Communi-
I/O
controller cation
the management of non volatile data Drivers
Drivers
Drivers
Drivers

(read/write from different memory drivers). Microcontroller (µC)

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 Example:
protection and verification, reliable storage Memory Services

etc.
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

page id: qwehg
Architecture – Content of Software Layers Application Layer
Services: System Services RTE
Communi-
Memory
cation

Complex Drivers
System Services Services
Services I/O HW
Abstraction
The System Services are a group of modules Onboard Memory COM HW
Dev. Abstr. HW Abstr. Abstr.
and functions which can be used by modules Micro-
Memory
Communi-
I/O
controller cation
of all layers. Examples are Real Time Drivers
Drivers
Drivers
Drivers

Operating System (which includes timer Microcontroller (µC)

Example:
services) and Error Manager.
System Services
Some of these services are µC dependent (like

Basic Software Mode

Synchronized Time-
OS), partly ECU hardware and application

ECU State Manager

Watchdog Manager
Diagnostic Log and
Development Error
Function Inhibition
Manager (ComM)

Manager (BswM)
Diagnostic Event
Manager (Dem)
Communication

Manager (FIM)

base Manager
Tracer (Det)

Trace (Dlt)
dependent (like ECU State Manager) or

(WdgM)
(StbM)
(EcuM)
hardware and µC independent.

Task:

AUTOSAR OS
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

page id: 3edfg
Architecture – Content of Software Layers Application Layer
Error Handling, Reporting and Diagnostic RTE
Communi-
Memory
cation

Complex Drivers
System Services Services
Services I/O HW
Abstraction
Application Layer Onboard Memory COM HW
Dev. Abstr. HW Abstr. Abstr.
Micro- Communi-
Memory I/O
AUTOSAR Runtime Environment (RTE) controller
Drivers
Drivers
cation
Drivers
Drivers

Watchdog Manager
Communication Microcontroller (µC)
Services
System Services

Function Inhibition
Manager Diagnostic Communi-
Development Error cation Manager
Tracer There are dedicated modules for different aspects
Diagnostic Log Debugging
and Trace of error handling in AUTOSAR. E.g.:
Diagnostic Event XCP  The Debugging module supports debugging of
Manager
the AUTOSAR BSW. It interfaces to ECU
Onboard Device Communication internal modules and to an external host system
Abstraction Hardware
Abstraction via communication .
Watchdog Interface
 The Diagnostic Event Manager is responsible
Microcontroller Drivers Communication
for processing and storing diagnostic events
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.
- AUTOSAR Confidential -

56 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: xsji8
Architecture – Content of Software Layers Application Layer

Application Layer: Sensor/Actuator Software Components RTE

Communi-
Memory
cation

Complex Drivers
System Services Services
Services I/O HW
Abstraction
The Sensor/Actuator AUTOSAR Software Onboard Memory COM HW
Dev. Abstr. HW Abstr. Abstr.
Component is a specific type of AUTOSAR Micro- Communi-
Memory I/O
Software Component for sensor evaluation controller
Drivers
Drivers
cation
Drivers
Drivers
and actuator control. Though not belonging Microcontroller (µC)
to the AUTOSAR Basic Software, it is
described here due to its strong relationship
to local signals. It has been decided to locate
the Sensor/Actuator SW Components above Example:
the RTE for integration reasons
(standardized interface implementation and
Application Layer
interface description). Because of their
strong interaction with raw local signals, Actuator Sensor
relocatability is restricted. Software Software
Component Component

Task:
Provide an abstraction from the specific RTE
physical properties of hardware sensors and
actuators, which are connected to an ECU. Basic Software
Interfaces to (e.g.)
• I/O HW Abstraction (access to I/O signals)
Properties: • Memory Services (access to calibration data)
• System Services (access to Error Manager)
Implementation: µC and ECU HW independent,
sensor and actuator dependent
- AUTOSAR Confidential -

57 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 96jt4

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

 page id: 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 0: core 1:

Application Layer

RTE

Operating
System Services Communi- System
Memory
cation
Services
Services ECU State
I/O HW Manager
Abstraction

Complex Drivers

Complex Drivers
Onboard Dev. Memory HW COM HW
Abstraction Abstraction Abstraction

Micro-
Memory Communi- I/O
controller Core Test
Drivers cation Drivers Drivers
Drivers

Microcontroller (µC)

- AUTOSAR Confidential -

59 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: w111c
Architecture – Content of Software Layers Application Layer

Scope: Multi-Core System Services RTE

Communi-
Memory
cation

Complex Drivers
System Services Services
Services I/O HW

 The IOC, as shown in the figure, provides communication Onboard Memory COM HW
Abstraction

Dev. Abstr. HW Abstr. Abstr.

services which can be accessed by clients which need Micro-
Memory
Communi-
I/O
controller cation
to communicate across OS-Application boundaries on Drivers
Drivers
Drivers
Drivers

the same ECU. The IOC is part of the OS Microcontroller (µC)

 Every Core runs a kind of ECU state management

Example: an ECU with a two core microcontroller

Microcontroller
core 0: core 1:
System Services System Services

Basic Software Mode

management Core 1
ECU State Manager

Development Error
Function Inhibition

Diagnostic Event
Communication
Inter OsApplication

Inter OsApplication

ECU state
communication

communication
Manager
Manager

Manager

Manager
Core 0

Tracer
…
iOC

iOC
AUTOSAR OS
AUTOSAR OS

- AUTOSAR Confidential -

60 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 97jt4

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 -

61 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 9dfc8
Architecture
Overview of Modules – Implementation Conformance Class 3 - ICC3
This figure shows the mapping of basic software modules to AUTOSAR layers

Application Layer

AUTOSAR Runtime Environment (RTE)

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

Debug
Com

Dcm

ging
Nm
If
ComM

WdgM

BswM

NvM
StbM
Dem

Csm
FiM

Det

Dlt

I/O Signal Interface

IpduM
PduR

XCP
Nm
Tp
Driver for Driver for
Onboard Device Memory Hardware Communication ext. ext.
AUTOSAR OS

Abstraction Abstraction Hardware Abstraction ADC ASIC I/O ASIC

EcuM

WdgIf MemIf xxx Interface

Ea Fee
Trcv. ext. Drv

Microcontroller Drivers Memory Drivers Communication Drivers I/O Drivers

RamTst
CoreTst

FlsTst
MCU

Pwm
Wdg

Eep

Can

Port
Adc
Gpt

Dio
Fls

Spi

Eth

Icu
Lin

Fr
Microcontroller

Not all modules are shown here

- AUTOSAR Confidential -

62 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 92jc9
Architecture
Overview of Modules – Implementation Conformance Classes – ICC2
The clustering shown in this document is the one defined by the project so far. AUTOSAR is currently not restricting the clustering
on ICC2 level to dedicated clusters as many different constraint and optimization criteria might lead to different ICC2
clusterings. There might be different AUTOSAR ICC2 clusterings against which compliancy can be stated based on a to be
defined approach for ICC2 compliance.

Application Layer

AUTOSAR Runtime Environment

Com …
Services
*
COM

PDU Router

O CAN … …
S CAN St Mgr …

CAN CAN
..
TP NM

CAN Interface

CAN Driver

ECU Hardware

… ICC3 module ICC2 clusters

- AUTOSAR Confidential -

63 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 94t21
Architecture
Overview of Modules – Implementation Conformance Classes – ICC1
In a basic software which is compliant to ICC1 no modules or clusters are required.
The inner structure of this proprietary basic software is not specified.

Application Layer

AUTOSAR Runtime Environment

Proprietary software

ECU Hardware

- AUTOSAR Confidential -

64 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 94p21
Architecture
Overview of Modules – Implementation Conformance Classes – behavior to the outside
Basic software (including the RTE) which is AUTOSAR compliant (ICC1-3) has to behave to the outside as specified by ICC3.
For example the behavior towards:
 buses,
 boot loaders and
 applications.

Application Layer

AUTOSAR Runtime Environment

Basic Software

ECU Hardware

ICC 3 compliant
behavior
- AUTOSAR Confidential -

65 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 98jt4

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

page id: tz76a
Interfaces
Type of Interfaces in AUTOSAR

An "AUTOSAR Interface" defines the information exchanged between

software components and/or BSW modules. This description is
independent of a specific programming language, ECU or network
technology. AUTOSAR Interfaces are used in defining the ports of
AUTOSAR Interface software-components and/or BSW modules. Through these ports
software-components and/or BSW modules can communicate with each
other (send or receive information or invoke services). AUTOSAR makes
it possible to implement this communication between Software-
Components and/or BSW modules either locally or via a network.

A "Standardized AUTOSAR Interface" is an "AUTOSAR Interface" whose

syntax and semantics are standardized in AUTOSAR. The "Standardized
Standardized AUTOSAR
AUTOSAR Interfaces" are typically used to define AUTOSAR Services,
Interface which are standardized services provided by the AUTOSAR Basic
Software to the application Software-Components.

A "Standardized Interface" is an API which is standardized within

AUTOSAR without using the "AUTOSAR Interface" technique. These
"Standardized Interfaces" are typically defined for a specific programming
language (like "C"). Because of this, "standardized interfaces" are
Standardized Interface typically used between software-modules which are always on the same
ECU. When software modules communicate through a "standardized
interface", it is NOT possible any more to route the communication
between the software-modules through a network.

- AUTOSAR Confidential -

67 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 94ju5
Interfaces
Components and interfaces view (simplified)

Application Actuator Sensor Application

AUTOSAR Software
Component
Software
Component
Software
Component
AUTOSAR Software
Component
Software
Component
AUTOSAR AUTOSAR AUTOSAR
Software AUTOSAR

Interface
Interface Interface Interface
.............. Interface

AUTOSAR Runtime Environment (RTE)

Standard
Software
Standardized
Standardized Standardized AUTOSAR AUTOSAR
AUTOSAR
Interface Interface Interface Interface
Interfaces: Interface
ECU
VFB & RTE Services Communication
Abstraction
relevant
Standardized Standardized Standardized
Standardized

RTE Interface Interface Interface

Interface

relevant
Operating Complex
BSW System Drivers
relevant Standardized
Interface
Possible interfaces
inside Basic Software Microcontroller
Basic Software
(which are
Abstraction
not specified
within AUTOSAR)
ECU-Hardware
Note: This figure is incomplete with respect to the possible interactions between the layers.
- AUTOSAR Confidential -

68 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: a6ztr
Interfaces: General Rules
General Interfacing Rules
Horizontal Interfaces Vertical Interfaces

Services Layer: horizontal interfaces are allowed One Layer may access all interfaces of the SW layer
Example: Error Manager saves fault data using the below
NVRAM manager

ECU Abstraction Layer: horizontal interfaces are Bypassing of one software layer should be avoided
allowed

A complex driver may use selected other BSW Bypassing of two or more software layers is not
modules allowed

µC Abstraction Layer: horizontal interfaces are not

allowed. Exception: configurable notifications are Bypassing of the µC Abstraction Layer is not allowed
allowed due to performance reasons.
AUTOSAR AUTOSAR AUTOSAR AUTOSAR
SW Comp SW Comp SW Comp SW Comp A module may access a lower layer module of
1 3 4 5
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

page id: 1xdfr
Interfaces: General Rules
Layer Interaction Matrix

Communication Hardware Abstraction

This matrix shows the possible interactions between

Memory Hardware Abstraction

AUTOSAR Basic Software layers

Onboard Device Abstraction

I/O Hardware Abstraction
Communication Services

Communication Drivers
Microcontroller Drivers
 “is allowed to use”

Memory Services
System Services
 ”is not allowed to use”

Complex Drivers

Memory Drivers
 “restricted use uses

I/O Drivers
(callback only)”

The matrix is read row-

wise: AUTOSAR SW Components / RTE            
Example: “I/O Drivers System Services            
are allowed Memory Services            
to use System Services Communication Services            
and Complex Drivers restricted access -> see the following two slides
Hardware, but no other I/O Hardware Abstraction            
layers”. Onboard Device Abstraction            
(gray background indicates “non- Memory Hardware Abstraction            
Basic Software” layers) Communication Hardware Abstraction            
Microcontroller Drivers            
Memory Drivers            
Communication Drivers            
I/O Drivers            
- AUTOSAR Confidential -

70 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 11122
Interfaces Application Layer
Interfacing with Complex Drivers (1) RTE
Communi-
Memory
cation

Complex Drivers
System Services Services
Services I/O HW
Abstraction
Complex Drivers may need to interface to other modules Onboard Memory COM HW
Dev. Abstr. HW Abstr. Abstr.
in the layered software architecture, or modules in Micro- Communi-
Memory I/O
the layered software architecture may need to interface controller
Drivers
cation
Drivers
Drivers Drivers
to a Complex Driver. If this is the case,
Microcontroller (µC)
the following rules apply:

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

page id: 11123
Interfaces Application Layer
Interfacing with Complex Drivers (2) RTE
Communi-
Memory
cation

Complex Drivers
System Services Services
Services I/O HW
In general, it is possible to access the following modules: Onboard Memory COM HW
Abstraction

 The SPI driver Dev. Abstr.

Micro-
HW Abstr. Abstr.
Communi-
Memory I/O
 The GPT driver controller
Drivers
Drivers
cation
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

page id: q1123
Interfaces Application Layer
Interfacing with Complex Drivers (3) RTE
Communi-
Memory
cation

Complex Drivers
System Services Services
Services I/O HW
In case of multi core architectures, there are additional rules: Onboard Memory COM HW
Abstraction

 In AUTOSAR release 4.0, the BSW resides on the master core. Dev. Abstr.
Micro-
HW Abstr. Abstr.
Communi-
Memory I/O
 Consequently, if the CDD needs to access standardized interfaces controller
Drivers
Drivers
cation
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

page id: 99jt4

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

System Services Memory Services

This example shows how the NVRAM Manager and the
Watchdog Manager interact with drivers on an assumed Watchdog NVRAM
hardware configuration: Manager Manager

The ECU hardware includes an external EEPROM and an MemIf_Read()

external watchdog connected to the microcontroller via the WdgIf_Trigger() MemIf_Write()
same SPI. Onboard Device Memory Hardware Abstraction
Abstraction
Memory Abstraction Interface
The SPIHandlerDriver controls the concurrent access to the
SPI hardware and has to give the watchdog access a Watchdog Interface Fee_Read()
higher priority than the EEPROM access. EEPROM Fee_Write()
Wdg_Trigger() Abstraction
Flash EEPROM
The microcontroller includes also an internal flash which is Emulation
External External
used in parallel to the external EEPROM. The EEPROM Watchdog Driver EEPROM Driver
Abstraction and the Flash EEPROM Emulation have an
API that is semantically identical. Spi_ReadIB() Fls_Read()
Spi_WriteIB() Fls_Write()
The Memory Abstraction Interface can be realized in the COM Drivers Memory Drivers
following ways:
Internal
 routing during runtime based on device index (int/ext) SPIHandlerDriver
Flash Driver
 routing during runtime based on the block index (e.g. >
0x01FF = external EEPROM)
µC SPI Flash
 routing during configuration time via ROM tables with
function pointers inside the NVRAM Manager (in this case
the Memory Abstraction Interface only exists „virtually“)
CS SPI CS SPI

External External
Watchdog EEPROM

- AUTOSAR Confidential -

76 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

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 Nvm_Write(BlockIndex)
different memory devices using a device index.
Memory Services

Interface Description NVRAM

The Memory Abstraction Interface could have the Manager

following interface (e.g. for the write function):

MemIf_Write(
Std_ReturnType MemIf_Write DeviceIndex,
( BlockNumber,
uint8 DeviceIndex, DataBufferPtr)
uint16 BlockNumber, Memory Hardware Abstraction
uint8 *DataBufferPtr
) Memory Abstraction Interface

Ea_Write(
BlockNumber, Fee_Write(
The EEPROM Abstraction as well as the Flash BlockNumber,
DataBufferPtr)
EEPROM Emulation could have the following DataBufferPtr)
interface (e.g. for the write function):
EEPROM Abstaction Flash
EEPROM Emulation
Std_ReturnType Ea_Write
(
uint16 BlockNumber,
uint8 *DataBufferPtr
)

- AUTOSAR Confidential -

77 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

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“ /* for getting the API function addresses */
#include “Fee.h“ /* for getting the API function addresses */
#include “MemIf.h“ /* 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

page id: 10zow
Interfaces: Interaction of Layers – Example “Communication”
PDU Flow through the Layered Architecture
Layer N+1
 Explanation of terms: data structure PDU

 SDU LayerN_Tx(*PDU);

SDU is the abbreviation of “Service Data Unit”. It

void LayerN_Tx(*SDU);
is the data passed by an upper layer, with the
request to transmit the data. It is as well the data Layer N
PCI data structure SDU
which is extracted after reception by the lower
layer and passed to the upper layer.
PCI data structure PDU
A SDU is part of a PDU.
LayerN+1_Tx(*PDU);

 PCI
void LayerN+1_Tx(*SDU);
PCI is the abbreviation of “Protocol Control Layer N-1
Information”. This Information is needed to pass a
SDU from one instance of a specific protocol layer PCI data structure SDU
to another instance. E.g. it contains source and
target information.
The PCI is added by a protocol layer on the
transmission side and is removed again on the
receiving side. TP
PCI data structure SDU
 PDU
PDU is the abbreviation of “Protocol Data Unit”. PCI data structure PDU
The PDU contains SDU and PCI.
On the transmission side the PDU is passed from
the upper layer to the lower layer, which interprets CAN IF
this PDU as its SDU.
PCI data structure

- AUTOSAR Confidential -

81 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 94j42
Interfaces: Interaction of Layers Application Layer
Example “Communication” (1) RTE
Communi-
Memory
cation

Complex Drivers
System Services Services
Services I/O HW
SDU and PDU Naming Conventions Onboard Memory COM HW
Abstraction

Dev. Abstr. HW Abstr. Abstr.

The naming of PDUs and SDUs respects the following rules: Micro- Communi-
Memory I/O
controller cation
For PDU: <bus prefix> <layer prefix> - PDU Drivers
Drivers
Drivers
Drivers

For SDU: <bus prefix> <layer prefix> - SDU Microcontroller (µC)

The bus prefix and layer prefix are described in the following table:

ISO Layer Layer AUTOSAR PDU Name CAN / LIN prefix FlexRay
Prefix Modules TTCAN prefix
prefix
Layer 6: I COM, DCM I-PDU N/A
Presentation
I PDU router, PDU I-PDU N/A
(Interaction)
multiplexer SF:
Single Frame
Layer 3: N TP Layer N-PDU CAN SF LIN SF FR SF FF:
Network Layer CAN FF LIN FF FR FF First Frame
CAN CF LIN CF FR CF CF:
Consecutive
CAN FC LIN FC FR FC
Frame
Layer 2: L Driver, Interface L-PDU CAN LIN FR FC:
Data Link Layer Flow Control

Examples:
I-PDU or I-SDU For details on the frame types, please refer to the
AUTOSAR Transport Protocol specifications for CAN,TTCAN, LIN and FlexRay.
CAN FF N-PDU or FR CF N-SDU
LIN L-PDU or FR L-SDU
- AUTOSAR Confidential -

82 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 5udw1
Interfaces: Interaction of Layers
Example “Communication” (2)

Components
 PDU Router:
 Provides routing of PDUs between different abstract communication controllers and upper layers
 Scale of the Router is ECU specific (down to no size if e.g. only one communication controller exists)
 Provides TP routing on-the-fly. Transfer of TP data is started before full TP data is buffered
 COM:
 Provides routing of individual signals or groups of signals between different I-PDUs

 NM Coordinator:
 Synchronization of Network States of different communication channels connected to an ECU via the
network managements handled by the NM Coordinator
 Communication State Managers:
 Start and Shutdown the hardware units of the communication systems via the interfaces
 Control PDU groups

- AUTOSAR Confidential -

83 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 3hd8w
Interfaces: Interaction of Layers
Example “Communication” (3)

RTE

Communication
Signals
Manager

FlexRay TTCAN
Diagnostic Eth State CAN State LIN State Generic
IPDU State State
AUTOSAR Communi- Manager Manager Manager NM interface
multi- Debugging Manager Manager
plexer COM cation
Manager
NM
Coordinator
I-PDU I-PDU I-PDU I-PDU
XCP

PDU Router

Internet Protocol
I-PDU1 I-PDU1 NM
I-PDU I-PDU1 I-PDU I-PDU NM
Module
NM
will be described on Module
NM
CAN Tp Module
the next slide Module
FlexRay Tp J1939Tp

N-PDU N-PDU N-PDU

Communication
HW
LIN Interface
Eth Interface FlexRay Interface CAN Interface2 Abstraction
(incl. LIN TP)

L-PDU L-PDU L-PDU L-PDU

Communication Drivers

Eth Driver FlexRay Driver CAN Driver2 LIN Low Level Driver

1 The Interface between PduR and Tp differs significantly compared to the interface between PduR and the Ifs.
In case of TP involvement a handshake mechanism is implemented allowing the transmission of I-Pdus > Frame size.
2 CanIf with TTCAN serves both CanDrv with or without TTCAN. CanIf without TTCAN cannot serve CanDrv with TTCAN.

- AUTOSAR Confidential -

84 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: eed8w
Interfaces: Interaction of Layers
Example “Communication” (4) - Internet Protocol

 This figure shows the interaction of and PDU Router

inside the internet protocol stack.
I-PDUs

DoIP UDP NM
Socket Adaptor

Messages Streams

UDP TCP

Protocol Stack
Internet
Packet Segment
DHCP
IP
ARP ICMP
Datagram

Communication HW
Eth Interface Abstraction
Eth. Frame

Communication Drivers
Eth Driver

- AUTOSAR Confidential -

85 10 November 2011 Layered

Document
Software
ID 053
Architecture
: AUTOSAR_EXP_LayeredSoftwareArchitecture
- Document ID 053 - V 2.3 - R 4.0 Rev 0001
page id: 94kt4

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

page id: 9000a
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

page id: 9000b
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

Nm_Cfg.c Nm_Cfg.h
Required implementation
Pre-compile time configuration shall be done via the module‘s two
uses includes
configuration files (*_Cfg.h, *_Cfg.c) and/or by code generation: (optional)
 *_Cfg.h stores e.g. macros and/or #defines
Nm.c
 *_Cfg.c stores e.g. constants
- AUTOSAR Confidential -

88 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 9000c
Configuration
Pre-compile time (2)

Example 1: Enabling/disabling functionality

File Spi_Cfg.h:
#define SPI_DEV_ERROR_DETECT ON

File Spi_Cfg.c:
const uint8 myconstant = 1U;

File Spi.c (available as source code):

#include "Spi_Cfg.h" /* for importing the configuration parameters */

extern const uint8 myconstant;

#if (SPI_DEV_ERROR_DETECT == ON)

Det_ReportError(Spi_ModuleId, 0U, 3U, SPI_E_PARAM_LENGTH); /* only one instance available */
#endif

Note: The Compiler Abstraction and Memory Abstraction (as specified by AUTOSAR) are not used to keep the example simple.

- AUTOSAR Confidential -

89 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 9000d
Configuration
Pre-compile time (3)

Example 2: Event IDs reported to the Dem

XML configuration file of the NVRAM Manager:
Specifies that it needs the event symbol NVM_E_REQ_FAILED for production error reporting.

File Dem_Cfg.h (generated by Dem configuration tool):

typedef uint8 Dem_EventIdType; /* total number of events = 46 => uint8 sufficient */

#define DemConf_DemEventParameter_FLS_E_ERASE_FAILED_0 1U
#define DemConf_DemEventParameter_FLS_E_ERASE_FAILED_1 2U Example for a multiple
#define DemConf_DemEventParameter_FLS_E_WRITE_FAILED_0 3U instance driver (e.g. internal
#define DemConf_DemEventParameter_FLS_E_WRITE_FAILED_1 4U and external flash module)
#define DemConf_DemEventParameter_NVM_E_REQ_FAILED 5U
#define DemConf_DemEventParameter_CANSM_E_BUS_OFF 6U
...

File Dem.h:
#include "Dem_Cfg.h" /* for providing access to event symbols */

File NvM.c (available as source code):

#include "Dem.h" /* for reporting production errors */

Dem_ReportErrorStatus(DemConf_DemEventParameter_NVM_E_REQ_FAILED, DEM_EVENT_STATUS_PASSED);

- AUTOSAR Confidential -

90 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 9000e
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

page id: 9000f
Configuration
Link time (2)

Example 1: Event IDs reported to the Dem by a multiple instantiated module (Flash Driver) only available as object code
XML configuration file of the Flash Driver:
Specifies that it needs the event symbol FLS_E_WRITE_FAILED for production error reporting.

File Dem_Cfg.h (generated by Dem configuration tool):

typedef uint16 Dem_EventIdType; /* total number of events = 380 => uint16 required */

#define DemConf_DemEventParameter_FLS_E_ERASE_FAILED_0 1U
#define DemConf_DemEventParameter_FLS_E_ERASE_FAILED_1 2U
#define DemConf_DemEventParameter_FLS_E_WRITE_FAILED_0 3U
#define DemConf_DemEventParameter_FLS_E_WRITE_FAILED_1 4U
#define DemConf_DemEventParameter_NVM_E_REQ_FAILED 5U
#define DemConf_DemEventParameter_CANSM_E_BUS_OFF 6U
...

File Fls_Lcfg.c:
#include "Dem_Cfg.h" /* for providing access to event symbols */

const Dem_EventIdType Fls_WriteFailed[2] = {DemConf_DemEventParameter_FLS_E_WRITE_FAILED_1,

DemConf_DemEventParameter_FLS_E_WRITE_FAILED_2};

File Fls.c (available as object code):

#include "Dem.h" /* for reporting production errors */
extern const Dem_EventIdType Fls_WriteFailed[];

Dem_ReportErrorStatus(Fls_WriteFailed[instance], DEM_EVENT_STATUS_FAILED);

Note: the complete include file structure with all forward declarations is not shown here to keep the example simple.

- AUTOSAR Confidential -

92 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: y000g
Configuration
Link time (3)

Example 2: Event IDs reported to the Dem by a module (Flash Driver) that is available as object code only

Problem
Dem_EventIdType is also generated depending of the total number of event IDs on this ECU. In this example it is represented
as uint16. The Flash Driver uses this type, but is only available as object code.

Solution
In the contract phase of the ECU development, a bunch of variable types (including Dem_EventIdType) have to be fixed and
distributed for each ECU. The object code suppliers have to use those types for their compilation and deliver the object code
using the correct types.

- AUTOSAR Confidential -

93 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: y000h
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

page id: y000i
Configuration
Post-build time (2)

Example 1 (Post-build time loadable)

If the configuration data is fix in memory size and position, the module has direct access to these external structs.

PduR.c Compiler Linker PduR.o

Direct access
(via reference as given by
Linker control file the pointer parameter of
PduR’s initialization function)

PduR_PBcfg.c Compiler Linker PduR_PBcfg.o

- AUTOSAR Confidential -

95 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: y000k
Configuration
Post-build time (3)

Required implementation 2: Configuration of CAN Driver that is available as object code only; multiple configuration
sets can be selected during initialization time.

File Can_PBcfg.c:
#include “Can.h” /* for getting Can_ConfigType */
const Can_ConfigType MySimpleCanConfig [2] =
{
{
Can_BitTiming = 0xDF,
Can_AcceptanceMask1 = 0xFFFFFFFF,
Can_AcceptanceMask2 = 0xFFFFFFFF,
Can_AcceptanceMask3 = 0x00034DFF, Compiler
Can_AcceptanceMask4 = 0x00FF0000
},
{ … }
};

File EcuM.c:
#include “Can.h“ /* for initializing the CAN Driver */
Can_Init(&MySimpleCanConfig[0]); Linker

File Can.c (available as object code):

#include “Can.h“ /* for getting Can_ConfigType */

void Can_Init(Can_ConfigType* Config)

{
/* write the init data to the CAN HW */ Binary file
};

- AUTOSAR Confidential -

96 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: y000m
Configuration
Variants

Different use cases require different kinds of configurability. Therefore the following configuration variants are
provided:
 VARIANT-PRE-COMPILE
Only parameters with "Pre-compile time" configuration are allowed in this variant.
 VARIANT-LINK-TIME
Only parameters with "Pre-compile time" and "Link time" are allowed in this variant.
 VARIANT-POST-BUILD
Parameters with "Pre-compile time", "Link time" and "Post-build time" are allowed in this variant.

Example use cases:

 Reprogrammable PDU routing tables in gateway (Post-build time configurable PDU Router required)
 Statically configured PDU routing with no overhead (Pre-compile time configuration of PDU Router
required)

To allow the implementation of such different use cases in each BSW module, up to 3 variants can be
specified:
 A variant is a dedicated assignment of the configuration parameters of a module to configuration
classes
 Within a variant a configuration parameter can be assigned to only ONE configuration class
 Within a variant a configuration class for different configuration parameters can be different (e.g. Pre-
Compile for development error detection and post-build for reprogrammable PDU routing tables
 It is possible and intended that specific configuration parameters are assigned to the same
configuration class for all variants (e.g. development error detection is in general Pre-compile time
configurable). - AUTOSAR Confidential -

97 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: y000n
Configuration
Memory Layout Example: Postbuild Loadable (PBL)

EcuM defines the index: Description where to find what is an overall agreement:
1. EcuM needs to know all addresses including index
0x8000 &index (=0x8000)
2. The modules (xx, yy, zz) need to know their own
0x8000 &xx_configuration = 0x4710
start address: in this case: 0x4710, 0x4720 …
0x8002 &yy_configuration = 0x4720
3. The start addresses might be dynamic i.e. changes
0x8004 &zz_configuration = 0x4730
with new configuration
…
4. When initializing a module (e.g. xx, yy, zz), EcuM
passes the base address of the configuration data (e.g.
Xx defines the modules configuration data: 0x4710, 0x4720, 0x4730) to the module to allow for
0x4710 &the_real_xx_configuration variable sizes of the configuration data.
0x4710 lower = 2
0x4712 upper =7 The module data is agreed locally (in the module) only
0x4714 more_data 1. The module (xx, yy) knows its own start address
… (to enable the implementer to allocate data section)
2. Only the module (xx, yy) knows the internals of
Yy defines the modules configuration data:
its own configuration
0x4720 &the_real_yy_configuration

ation” in
0x4720 Xx_data1=0815
p le ment
0x4722 Yy_data2=4711
er “ Po s t build im ules.pdf”
pt entation
R
0x4724 more_data
e t ails , see Cha Im p le m
For d C
… U T O S AR_TR_
“ A

- AUTOSAR Confidential -

98 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: axcvb
Configuration
Memory Layout Example: Postbuild Multiple Selectable (PBM)

0x8000 &index[] (=0x8000) As before, the description where to find what is an

FL 0x8000 &xx_configuration = 0x4710 overall agreement
0x8002 &yy_configuration = 0x4720 1. The index contains more than one description (FL,
FR,..) in an array
0x8004 &zz_configuration = 0x4730
(here the size of an array element is agreed to be
… 8)
0x8008 &xx_configuration = 0x5000 2. There is an agreed variable containing the position
FR
0x800a &yy_configuration = 0x5400 of one description
selector = CheckPinCombination()
0x800c &zz_configuration = 0x5200
3. Instead of passing the pointer directly there is one
…
indirection:
0x8010 &xx_configuration = … (struct EcuM_ConfigType *) &index[selector];
RL 0x8012 &yy_configuration = … 4. Everything else works as in PBL
0x8014 &zz_configuration = …
…

le m en tation” in
imp
ter “ Post build R u les.pdf”
C hap nta t ion
ils, see mpleme
For deta AR_ T R_ C I
“AUTOS

- AUTOSAR Confidential -

99 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 94mt4

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

page id: 11eer
Integration and Runtime aspects
Mapping of Runnables

 Runnables are the 1 0..*

VFB-
view
active parts of SW-C Runnable
Software Components
 They can be executed 0..* 0..*
concurrently, by

Implementation/ECU-view
1
mapping them to
different Tasks. Task
 The figure shows
further entities like OS- 0..*
applications, Partitions, 1 1
µC-Cores and BSW-
Resources which have 1 1
Partition OS-Application
to be considered for
this mapping. 0..*
1
0..* 1

BSW-Ressource µC-Core
(E.g., NV-block)

- AUTOSAR Confidential -

101 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 94lt4

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

page id: wweeu
Integration and Runtime aspects - Partitioning
Example of restarting partition

A violation (error) has occurred in the system (e.g., memory or

SW-C SW-C SW-C
timing violation)
SW-C SW-C SW-C SW-C SW-C SW-C
Decision (by integrator code) to restart the partition

RTE Other partitions remain unaffected

The partition is terminated by the OS, cleanup possible

SW-C SW-C SW-C

Communication to the partition is stopped

SW-C SW-C SW-C SW-C SW-C SW-C

Communication from the partition is stopped (e.g., default values

for ports used)
RTE

The partition is restarting (integrator code), initial environment for

SW-C SW-C SW-C
partition setup (init runnables, port values etc)

SW-C SW-C SW-C SW-C SW-C SW-C

Communication to the partition is stopped

Communication from the partition is stopped

RTE

SW-C SW-C SW-C The partition is restarted and up and running

SW-C SW-C SW-C SW-C SW-C SW-C

Communication is restored

Partition internally handles state consistency

RTE - AUTOSAR Confidential -

104 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: wweet
Integration and Runtime aspects - Partitioning
Involved components

 Protection Hook
 Executed on protection violation (memory or timing)
 Decides what the action is (Terminate, Restart, Shutdown, Nothing)
 Provided by integrator
 OS acts on decision by inspecting return value
 OsRestartTask
 Started by OS in case Protection Hook returns Restart
 Provided by integrator
 Runs in the partition’s context and initiates necessary cleanup and restart activities, such as:
 Stopping communication (ComM)
 Updating NvM
 Informing Watchdog, CDDs etc.
 RTE
Functions for performing cleanup and restart of RTE in partition

 Triggers init runnables for restarted partition
 Handles communication consistency for restarting/terminated partitions
 Operating System
 OS acts on OS-Applications, which are containers for partitions
 OS-Applications have states (APPLICATION_ACCESSIBLE, APPLICATION_RESTART,
APPLICATION_TERMINATED)
 OS provides API to terminate other OS-Applications (for other errors than memory/timing)
- AUTOSAR Confidential -

105 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: wwees
Integration and Runtime aspects - Partitioning
restart example

sd TerminateRestartPartition

Os-Application
state for the OS ProtectionHook OSRestartTask RTE BSW modules
considered
Partition.

APPLICATION_ACTIVE
ProtectionHook
inform the RTE

APPLICATION_RESTARTING ActivateTask

Trigger cleanup in the BSW partition

Polling end of asynchronous cleanups

request a restart of the partition to the RTE

AllowAccess

APPLICATION_ACTIVE

TerminateTask

- AUTOSAR Confidential -

106 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: wweer
Integration and Runtime aspects - Partitioning
Other examples

 Termination
 A partition can be terminated directly
 Also for termination, some cleanup may be needed, and this shall be performed in the
same way as when restarting a partition
 No restart is possible without a complete ECU restart

 Error detection in applications

 Application-level SW-Cs may detect errors (i.e., not memory/timing)
 A termination/restart can be triggered from a SW-C using the OS service
TerminateApplication()
 Example: a distributed application requires restart on multiple ECUs

- AUTOSAR Confidential -

107 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 94nt4

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: y331b
Integration and Runtime aspects - Scheduling
Basic Scheduling Concepts of the BSW

BSW Scheduling shall

 Assure correct timing behavior of the BSW, i.e., correct interaction of all BSW modules with respect to time

Data consistency mechanisms

 Applied data consistency mechanisms shall be configured by the ECU/BSW integrator dependent from the configured
scheduling.

Single BSW modules do not know about

 ECU wide timing dependencies
 Scheduling implications
 Most efficient way to implement data consistency

Centralize the BSW schedule in the BSW Scheduler configured by the ECU/BSW integrator and generated by the RTE
generator together with the RTE
 Eases the integration task
 Enables applying different scheduling strategies to schedulable objects
 Preemptive, non-preemptive, ...
 Enables applying different data consistency mechanisms
 Enables reducing resources (e.g., minimize the number of tasks)
 Enables interlaced execution sequences of Runnable Entities and BSW Main functions

Restrict the usage of OS functionality

 Only the BSW Scheduler and the RTE shall use OS objects or OS services
(exceptions: EcuM, Complex Drivers and services: GetCounterValue and GetElapsedCounterValue of OS; MCAL
modules may enable/disable interrupts )
 Rationale:
 Scheduling of the BSW shall be transparent to the system (integrator)
 Enables reducing the usage of OS resources (Tasks, Resources,...)
 Enables re-using modules in different environments

- AUTOSAR Confidential -

110 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: y331c
Integration and Runtime aspects - Scheduling
Scheduling Objects, Triggers and Mode Disabling Dependencies

BSW Scheduling objects

RTE
 Main functions
 n per module
 located in all layers

Zzz_MainFunction_Aaa
BSW Events
 BswTimingEvent
 BswBackgroundEvent
 BswModeSwitchEvent
 BswModeSwitchedAckEvent
 BswInternalTriggerOccuredEvent
Yyy_MainFunction_Aaa
 BswExternalTriggerOccuredEvent

Triggers
 Main functions can be triggered in all layers by
the listed BSW Events
Xxx_Isr_Yyy

Mode Disabling Dependencies

 The scheduling of Main functions can be
disabled in particular modes. Microcontroller

- AUTOSAR Confidential -

111 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: y331d
Integration and Runtime aspects - Scheduling
Transformation Process
Logical Architecture (Model) Technical Architecture (Implementation)
 Ideal concurrency  Restricted concurrency
 Unrestricted resources  Restricted resources
 Only real data dependencies  Real data dependencies
 Dependencies given by restrictions

 Scheduling objects  OS objects

 Trigger  Tasks
 BSW Events  ISRs
 Sequences of scheduling objects  Alarms
 Scheduling Conditions  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)/ Implementation of Schedule Module

#define SchM_Enter_<mod>_<name> \
Technical Architecture (Schedule Module) DisableAllInterrupts
#define SchM_Exit_<mod>_<name> \
EnableAllInterrupts
Task1 Xxx_Module
Yyy_AccessResource() {
Xxx_MainFunction(); ...
SchM_Enter_Xxx_XYZ();
<access_to_shared_resource>
SchM_Exit_Xxx_XYZ();
Yyy_ AccessResource(); ...
}
Yyy_MainFunction() {
XYZ resource ...
SchM_Enter_Yyy_XYZ();
<access_to_shared_resource>
Yyy_MainFunction(); SchM_Exit_Yyy_XYZ();
...
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)/ Implementation of Schedule Module

#define SchM_Enter_<mod>_<name> \
Technical Architecture (Schedule Module) /* nothing required */
#define SchM_Exit_<mod>_<name> \
/* nothing required */
Task1 Xxx_Module
Yyy_AccessResource() {
Xxx_MainFunction(); ...
SchM_Enter_Xxx_XYZ();
<access_to_shared_resource>
SchM_Exit_Xxx_XYZ();
Yyy_ AccessResource(); ...
}
Yyy_MainFunction() {
XYZ resource ...
SchM_Enter_Yyy_XYZ();
<access_to_shared_resource>
Yyy_MainFunction(); SchM_Exit_Yyy_XYZ();
...
Task2 }

Transformation

Data consistency is ensured by:

 Sequence

- AUTOSAR Confidential -

117 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: y331e
Integration and Runtime aspects
Mode Communication / Mode Dependent Scheduling

 The mode dependent scheduling of BSW Modules is identical to the mode dependent
scheduling of runnables of software components.
 A mode manager defines a Provide ModeDeclarationGroupPrototype in its Basic
Software Module Description, and the BSW Scheduler provides an API to communicate mode
switch requests to the BSW Scheduler
 A mode user defines a Required ModeDeclarationGroupPrototype in its Basic Software
Module Description. On demand the BSW Scheduler provides an API to read the current
active mode
 If the Basic Software Module Description defines Mode Disabling Dependencies, the BSW
Scheduler suppresses the scheduling of BSW Main functions in particular modes.

- AUTOSAR Confidential -

118 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 94ot4

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: Vehicle

1

3
2

Modes
 Every system contains Modes at
Influence each other
different levels of granularity. As shown
in the figure, there are vehicle modes Application
1
1
2
2
3 1 2

and several applications with modes and Modes 3

3

ECUs with local BSW modes. Influence each other

Influence each other

 Modes at all this levels influence each 1

1
2
2
BSW
other. Modes
3
3
1 2

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.

- AUTOSAR Confidential -

120 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

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 Mode
Mode Mode Mode
Request Switch
Requester Manager User

Mode
Mode Mode
Switch
Manager User

- AUTOSAR Confidential -

121 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: q222c
Integration and Runtime aspects Application Layer
Vehicle and application mode management (3) RTE
Communi-
Memory
cation

Complex Drivers
System Services Services
Services I/O HW
Layer Functionality per module Onboard Memory COM HW
Abstraction

Dev. Abstr. HW Abstr. Abstr.

Micro- Communi-
Memory I/O
controller cation
App Mode Arbitration SW-C Drivers
Drivers
Drivers
Drivers

Microcontroller (µC)

RTE Mode Request Distribution + Mode Handling

 The major part of the needed functionality is
BswM placed in a new BSW module which we call
the Basic Software Mode Manager (BswM for
BSW Mode Arbitration Mode Control
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

page id: q222d
Integration and Runtime aspects
Vehicle and application mode management (4)

Applications
Mode Processing Cycle
Mode requesting Mode using
 The mode requester SW-C requests
SW-C SW-C
mode A through its sender port. The RTE
distributes the request and the BswM 3: switch
receives it through its receiver port. 1: request mode A´
mode A
 The BswM evaluates its rules and if a
rule triggers, it executes the
corresponding action list. RTE
 When executing the action list, the BswM Mode request Local mode
may issue a (configurable optional) RTE distribution handling
call to the mode switch API as a last
action to inform the mode users about the
arbitration result, e.g. the resulting mode BswM
A’. Mode Mode
Control
 Any SW-C, especially the mode Arbitration
requester can register to receive the Action list
mode switch indication. 2: execute
associated Mode arbitration Action 1
 The mode requests can originate from action list overrides the Action 2
local and remote ECUs.
request for mode …
 Note that the mode requestor can only A with mode A´.
receive the mode switch indications from RteSwitch(mode A´)
the local BswM, even if the requests are
sent out to multiple ECUs.
- AUTOSAR Confidential -

123 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 94pt4

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

page id: tegz7
Integration and Runtime aspects - Error Handling, Reporting and Diagnostic
Mechanism in relation to AUTOSAR layers and system life time
Develop-
ment Error
Tracer
(Det)

Diagnostic
Log End to End
and Trace Communication
(Dlt) Application Layer (E2E)

AUTOSAR Runtime Environment (RTE)

Basic Software

Diagnostic Event
Manger (Dem)
Debug-
and Function
ging
Inhibition
(Dbg)
Manager (Fim)

Watchdog ECU Hardware

(Wdg)

Life cycle: development production After production

- AUTOSAR Confidential -

128 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: yaq12
Integration and Runtime aspects - Error Handling, Reporting and Diagnostic
Error Reporting via API

Error reporting via API

Informs the caller about failure of an operation by returning an error status.

Basic return type

Success: E_OK (value: 0)
Failure: E_NOT_OK (value: 1)

Specific return type

If different errors have to be distinguished for production code, own return types have to be
defined. Different errors shall only be used if the caller can really handle these. Specific
development errors shall not be returned via the API. They can be reported to the
Development Error Tracer (see 04-014).

Example: services of EEPROM driver

Success: EEP_E_OK
General failure (service not accepted): EEP_E_NOT_OK
Write Operation to EEPROM was not successful: EEP_E_WRITE_FAILED

- AUTOSAR Confidential -

129 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

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
module‘s 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

page id:dxcvb
Integration and Runtime aspects - Error Handling, Reporting and Diagnostic
Error Reporting – Diagnostic Log and Trace (2)

The Dlt communication module is SW-C sends a log message via

SW-C Dlt_SendLogMessage()
enabled by an external client.
The external client has to set up a 1
diagnostic session in a defined Rte
security level and sending control Dcnm Call
message to Dlt for enabling the Dlt Dlt_WriteData() Dlt collects
communication module. messages

A SW-C is generating a log message. 2 2

Dcm Dlt
The log message is sent to Dlt by
calling the API provided by Dlt. Dlt comunication
module
Dlt sends the log message Over UDS an External Client
enables the Dlt Log message is
to the implemented Dlt communication module send over network
communication module (WriteDataByIdendifer)
3
interface. CAN / Flexray /
1 Ethernt / Serial
At the end, the log message
is stored on an external
external client
client and can be collects stores log
analyzed later on. messages
4

- AUTOSAR Confidential -

134 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: k387z
Integration and Runtime aspects - Error Handling, Reporting and Diagnostic
Error Reporting – Diagnostic Log and Trace (3)

API
The Diagnostic Log and Trace has syntactically the following API:
Dlt_SendLogMessage(Dlt_SessionIDType session_id, Dlt_MessageLogInfoType log_info, uint8
*log_data,
uint16 log_data_length)

Log message identification :

session_id
Session ID is the identification number of a log or trace session. A session is the logical entity of the source of log or
trace messages. If a SW-C is instantiated several times or opens several ports to Dlt, a new session with a new Session
ID for every instance is used. A SW-C additionally can have several log or trace sessions if it has several ports opened
to Dlt.

log_info contains:
Application ID / Context ID
Application ID is a short name of the SW-C. It identifies the SW-C in the log and trace message. Context ID is a user
defined ID to group log and trace messages produced by a SW-C to distinguish functionality. Each Application ID can
own several Context IDs. Context ID’s are grouped by Application ID’s. Both are composed by four 8 bit ASCII
characters.
Message ID
Messaged ID is the ID to characterize the information, which is transported by the message itself. It can be used for
identifying the source (in source code) of a message and shall be used for characterizing the payload of a message. A
message ID is statically fixed at development or configuration time.
log_data
Contain the log or trace data it self. The content and the structure of this provided buffer is specified by the Dlt
transmission protocol.

Description File
Normally the log_data contains only contents of not fixed variables or information (e.g. no static strings are transmitted).
Additionally a description file shall be provided. Within this file the same information for a log messages associated with the
Message ID are posted. These are information how to interpret the log_data buffer and what fixed entries belonging to a log
message.

- AUTOSAR Confidential -

135 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 94qt4

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

page id: 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

page id: 1123a
Integration and Runtime aspects - Debugging
Debugging Module - architectural overview

The Debugging Module can:

 interface to ECU internal modules and to an external host system via communication.

With respect to the host system:

 the Debugging Module is also described as being ‘target’.

Internally, the Debugging Module consists of:

 a core part, which handles data sampling, and
 a communication part, which is responsible for transmission and reception of data.

The Debugging Module is designed to be:

 hardware independent and
 interfaces to the PDU router.

It can be used by:

 the BSW and
 RTE.

There is no interface to software components.

- AUTOSAR Confidential -

138 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 1123b
Integration and Runtime aspects - Debugging
External architectural view - Data flow host  target

Example:

Host Debugging Com Module Debugging Core Module BSW

host command

call debug core command

confirmation

collection of data

processing of host
commands

- AUTOSAR Confidential -

139 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 1123c
Integration and Runtime aspects - Debugging
External architectural view - Data flow target  host

Example:

Host Debugging Com Module Debugging Core Module BSW

TX request

message fragment 1

message fragment 2

collection of data

message fragment n

debugging communication
module contains
implementation of simplified
TP

- AUTOSAR Confidential -

140 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 94rt4

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 -

141 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: y0099
Integration and Runtime aspects - Measurement and Calibration
XCP

XCP is an ASAM standard for calibration purpose of an ECU.

RTE
XCP within AUTOSAR provides
the following basic features:
Signals

 Synchronous data acquisition

 Synchronous data stimulation IPDU
AUTOSAR
Diagnostic
Communi-
multi- Debugging
COM
 Online memory calibration (read / write plexer cation
Manager

access) XCP Protocol I-PDU I-PDU I-PDU I-PDU

 Calibration data page initialization and XCPonFr /

PDU Router
XCPonCAN /
switching XCPonTCP/IP / NM
Interfaces Module
 Flash Programming for ECU I-PDU1

I-PDU
development purposes AUTOSAR Tp

N-PDU N-PDU

Communication HW Abstraction
Bus Interface(s)
(or Socket Adaptor on ethernet)

L-PDU

Communication Drivers

Bus Driver(s)

- AUTOSAR Confidential -

142 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 94st4

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 -

143 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: yxcvb
Integration and Runtime aspects – Safety End to End (E2E) Communication Protection
Overview

Typical sources of interferences,

causing errors detected by E2E
Libraries OS-Application 2 OS-Application 1
protection:
Receiver 1 Sender
SW-related sources:
S1. Error in mostly generated RTE,
S2. Error in partially generated and
partially hand-coded COM
E2E protection E2E protection S3. Error in network stack
wrapper wrapper S4. Error in generated IOC or OS
Direct function call Direct function call S1
H3 HW-related sources:
RTE H1. Microcontroller error during
E2E
Lib

core/partition switch
H2. Failure of HW network
System Services Memory Services Communication I/O Hardware CDD H2. Network EMI
Services Abstraction H3. Microcontroller failure during
S4 S2 context switch (partition) or on the
communication between cores
IOC

Direct function call

Onboard Device Memory Hardware Communication RTE int. wrapper
Abstraction Abstraction Hardware Abstraction
S3 Receiver
2

Microcontroller Memory Drivers Communication I/O Drivers

Drivers Drivers

H3 H4

Microcontroller 2
Microcontroller 1 / ECU 1
/ ECU 2

- AUTOSAR Confidential -

144 10 November 2011 Layered

Document
Software
ID 053
Architecture
: AUTOSAR_EXP_LayeredSoftwareArchitecture
- Document ID 053 - V 2.3 - R 4.0 Rev 0001
page id: yx3vb
Integration and Runtime aspects – Safety End to End (E2E) Communication Protection
Logic

Libraries OS-Application 2 OS-Application 1

Receiver 1 Sender 1
Application logic Application logic
9. Consume safe data elements 1. Produce safe data elements

6. Invoke safe read do get the 2. Invoke safe transmission

E2E protection data element - E2E protection request -
wrapper E2EWRP_Read_<p>_<o>() wrapper E2EWRP_Write_<p>_<o>()

8. Call E2E check on array

- E2E_P0xCheck()
3. Call E2E protect on array – E2E_P0x_Protect()

7. Invoke RTE read - RTE_Read_<p>_<o>() to get 4. Invoke RTE - RTE_Write_<p>_<o>() to

the data element transmit the data element
E2E
Lib

AUTOSAR Runtime Environment (RTE)

5. RTE communication (intra or inter ECU), either through COM, IOC,

or local in RTE

Notes:
 For each RTE Write or Read function that transmits safety-related data (like Rte_Write_<p>_<o>()), there is the
corresponding E2E protection wrapper function.
 The wrapper function invokes AUTOSAR E2E Library.
 The wrapper function is a part of Software Component and is preferably generated.
 The wrapper function has the same signature as the corresponding RTE function, just instead of Rte_ there is E2EPW_.
 The E2EPW_ function is called by Application logic of SW-Cs, and the wrapper does the protection/checks and calls
internally the RTE function.
 For inter-ECU communication, the data elements sent through E2E Protection wrapper are be byte arrays. The byte
arrays are put without any alterations in COM I-PDUs.
- AUTOSAR Confidential -

145 10 November 2011 Layered

Document
Software
ID 053
Architecture
: AUTOSAR_EXP_LayeredSoftwareArchitecture
- Document ID 053 - V 2.3 - R 4.0 Rev 0001
page id: 94tt4

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

page id: eep2q
Energy Management
Introduction

The goal of efficient energy management in AUTOSAR is to provide mechanisms for power
saving, especially while bus communication is active (e.g. charging or clamp 15 active).
AUTOSAR R3.2 and R4.0.3 support only Partial Networking.

Partial Networking
 Allows for turning off network communication across multiple ECUs in case their provided
functions are not required under certain conditions. Other ECUs can continue to
communicate on the same bus channel.
 Uses NM messages to communicate the request/release information of a partial network
cluster between the participating ECUs.

- AUTOSAR Confidential -

147 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: eep3e
Energy Management – Partial Networking
Example scenario of a partial network going to sleep

Initial situation:
1
ECUs “A” and “B” are members of Partial Network Cluster (PNC) 1.
ECU
ECU AA ECUs “B”, “C” and “D” are members of PNC 2.
All functions of the ECUs are organized either in PNC 1 or PNC 2.
1 Both PNCs are active.
ECU
ECU B
B PNC 2 is only requested by ECU “C”.
2
The function requiring PNC 2 on ECU “C” is terminated, therefore
ECU “C” can release PNC 2.
This is what happens:
ECU
ECU C
C
2 ECU “C” stops requesting PNC 2 to be active.
ECUs “C” and “D” are no longer participating in any PNC and can be
shutdown.
2
ECU
ECU D
D ECU “B” ceases transmission and reception of all signals associated
with PNC 2.
ECU “B” still participates in PNC 1. That means it remains awake
Physical CAN Bus
and continues to transmit and receive all signals associated with PNC
Partial Network Cluster 1 1.
Partial Network Cluster 2 ECU “A” is not affected at all.

- AUTOSAR Confidential -

148 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: eep3c
Energy Management – Partial Networking
Conceptual terms

 A significant part of energy management is about mode handling. For the terms
 Vehicle Mode,
 Application Mode and
 Basic Software Mode
see chapter 3.4 of this document.

 Virtual Function Cluster (VFC): groups the communication on port level between SW-
components that are required to realize one or more vehicle functions.
This is the logical view and allows for a reusable bus/ECU independent design.

 VFC-Controller: Special SW-component that decides if the functions of a VFC are required at
a given time and requests or releases communication accordingly.

 Partial Network Cluster (PNC): is a group of system signals necessary to support one or
more vehicle functions that are distributed across multiple ECUs in the vehicle network.
This represents the system view of mapping a group of buses to one ore more VFCs.

- AUTOSAR Confidential -

149 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: eep3r
Energy Management – Partial Networking
Restrictions

 Partial Networking is currently supported on CAN and FlexRay buses.

 In order to wake-up a Partial Networking ECU a special transceiver hardware is required as
specified in ISO 11898-5.
 The concept of Partial Networking does not consider a VFC located on only one ECU because
there is no bus communication and no physical PNC.

 Restrictions for CAN

 J1939 and Partial Networking exclude each other, due to the address claiming and start-
up behaviour of J1939.
 J1939 need to register first their address in the network before they are allowed to start
communication after a wake-up.

 Restrictions on FlexRay
 FlexRay is only supported for requesting and releasing PNCs.
 FlexRay nodes cannot be shut down since there is no hardware available which supports
partial networking.

- AUTOSAR Confidential -

150 Document ID 053 :

page id: eep3m
Energy Management – Partial Networking
Mapping of Virtual Function Cluster to Partial Network Cluster

SW-C
SW-C
SW-C SW-C
SW-C SW-Component of VFC1
SW-C 44 66
22
SW-C
SW-C
SW-Component of VFC2
11 SW-C
SW-C
55
SW-C
SW-C SW-C
SW-C SW-Component of VFC3
33 77
CompositionType Communication Port

VFC1
VFC1 VFC2
VFC2 VFC3
VFC3
Mapping of
VFC on PNC
PNC1
PNC1 PNC2
PNC2

ECU A ECU B ECU C

• Here both Partial Networks
map to one CAN bus.
SW-C
SW-C SW-C
SW-C SW-C
SW-C SW-C
SW-C SW-C
SW-C SW-C
SW-C SW-C
SW-C
11 22 33 44 55 66 77 • One Partial Network can also
span more than one bus.
RTE RTE RTE

Basic Software Basic Software Basic Software PNC1

PNC1 PNC2
PNC2

ECU Hardware ECU Hardware ECU Hardware CAN

CAN
PNC1 CAN Bus PNC2

- AUTOSAR Confidential -

151 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: eep3b
Energy Management – Partial Networking
Involved modules – Solution for CAN

Application Layer SW-C SW-C

•• VFC
VFC to
to PNC
PNC toto channel
channel
translation
translation
•• Coordination
Coordination of of I-PDU
I-PDU •• PNC
ComM_User PNC management
management (request
(request //
group
group switching
switching Mode release
RTE
•• Start or release of
of PNCs)
PNCs)
Start // stop
stop I-PDU-
I-PDU- request Request •• Indication
Indication of
of PN
PN states
states
groups
groups

System Services
Communication Services ComM_UserRequest
BswM ComM
PNC states
Network
I-PDU GroupSwitch
PNC request/release Request Request
information ComMode
•• Exchange
Exchange PNCPNC request
request // release
release COM NmIf
information
information between NM
between NM andand
ComM
ComM via
via NMNM user
user data
data
•• Enable
Enable // disable
disable I-PDU-groups
I-PDU-groups
Trigger Transmit
PduR CanNm CanSm

Communication Hardware Abstraction

•• Filter
Filter incoming
incoming NMNM messages
messages CanIf
•• Collect
Collect internal
internal and
and external
external PNC
PNC requests
requests
•• Send
Send outout PNC
PNC request
request infocmation
infocmation in
in NM
NM user
user
data
data
•• Spontaneous
Spontaneous sending
sending ofof NM
NM messages
messages on on PNC
PNC
startup
startup CanTrcv

- AUTOSAR Confidential -

152 Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture