Download - AUTOSAR EXP LayeredSoftwareArchitecture
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
1/143
- AUTOSAR Confidential -
Layered Software Architecture
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
2/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture2
Document Title Layered Software Architecture
Document Owner AUTOSAR
Document Responsibility AUTOSAR
Document Identif ication No 053
Document Classification Auxiliary
Document Version 3.2.0
Document Status Final
Part of Release 4.0
Revision 3
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
3/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture3
Document Change History
Date Version Changed by Change Description
06.10.2011 3.2.0 AUTOSAR Administration
added a note for the R3-compatibility FlexRay Transport Layer FrArTp on slide "ki890".
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 Administration
added a note regarding support for System Basis Chips on slide "94juq“
clarification of DBG and DLT text on slide "3edfg"
corrected DBG description on slide "11231"
30.11.2009 3.0.0 AUTOSAR
Administration
The document has been newly structured. There are now 3 main parts:
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 beenadded. E.g.,. Multi Core systems, Partitioning, Mode Management, Error Handling,Reporting and Diagnostic, Debugging, Measurement and Calibration, Functional Safety etc
Legal disclaimer revised23.06.2008 2.2.1 AUTOSAR
Administration
Legal disclaimer revised
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
4/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture4
Document Change History
Date Version Changed by Change Description
15.11.2007 2.2.0 AUTOSAR Administration
Updates based on new wakeup/startup concepts
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 Administration
ICC clustering added.
Document contents harmonized
Legal disclaimer revised
Release Notes added
“Advice for users” revised
“Revision Information” added
21.03.2006 2.0.0 AUTOSAR Administration
Rework Of:
Error Handling
Scheduling Mechanisms
More updates according to architectural decisions in R2.0
31.05.2005 1.0.1 AUTOSAR
Administration
Correct version released
09.05.2005 1.0.0 AUTOSAR Administration
Initial release
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
5/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture5
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 productsactually 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.
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
6/143
- AUTOSAR Confidential -
Table of contents
1. Architecture1. Overview of Software Layers
2. Content of Software Layers
3. Content of Software Layers in Multi Core systems
4. Overview of Modules5. Interfaces
1. General
2. Interaction of Layers (Examples)
2. Configuration
3. Integration and Runtime aspects
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture15
p a g e i d : 9 4 j t 4
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
7/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture16
Introduction
Purpose and Inputs
Purpose of this documentThe 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.
p a g e i d : 9 4 j t 2
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
8/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture17
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 morethan 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.
p a g e i d : 9 4 j t 1
9
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
9/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture18
Architecture – Overview of Software Layers
Top view
Microcontroller
Application Layer
Runtime Environment (RTE)
p a g e i d : 9 4 q u 9
Basic Software (BSW)
The AUTOSAR Architecture distinguishes on the highest abstraction level between threesoftware layers: Application, Runtime Environment and Basic Software which run on a
Microcontroller.
3
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
10/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture19
Architecture – Overview of Software Layers
Coarse view
Complex
Drivers
Microcontroller
Microcontroller Abstraction Layer
Services Layer
Application Layer
Runtime Environment
ECU Abstraction Layer
p a g e i d : 9 4 j u 3
The AUTOSAR Basic Software is further divided in the layers: Services, ECU Abstraction,Microcontroller Abstraction and Complex Drivers.
4
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
11/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture20
Architecture – Overview of Software Layers
Detailed view
Complex
Drivers
Microcontroller
Runtime Environment
Microcontroller Drivers Memory Drivers I/O Drivers
I/O Hardware Abstraction
Memory Hardware
Abstraction
Memory ServicesSystem Services
Onboard Device
Abstraction
Communication Drivers
Communication
Hardware Abstraction
Communication Services
Application Layer
p a g e i d : 9 4 j u 4
The Basic Software Layers are further div ided into functional groups. Examples of Servicesare System, Memory and Communication Services.
u 6
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
12/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture21
Architecture – Overview of Software Layers
Microcontroller Abstraction Layer
The Microcontroller Abstraction Layer is thelowest software layer of the Basic Software.
It contains internal drivers, which are software
modules with direct access to the µC and
internal peripherals.
Task
Make higher software layers independent of µC
PropertiesImplementation: µC dependent
Upper Interface: standardized and µC
independent
Co
mplex
Dri
ver
s
Microcontroller
Microcontroller Abstraction Layer
Appl ication Layer
RTE
ECU Abstraction Layer
p a g e i d : 9 4 j u
u 7
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
13/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture22
Architecture – Overview of Software Layers
ECU Abstraction Layer
The ECU Abstraction Layer interfaces thedrivers of the Microcontroller Abstraction
Layer. It also contains drivers for external
devices.
It offers an API for access to peripherals and
devices regardless of their location (µCinternal/external) and their connection to the
µC (port pins, type of interface)
Task
Make higher software layers independent of
ECU hardware layout
Properties
Implementation: µC independent, ECU hardware
dependent
Upper Interface: µC and ECU hardware
independent
Co
mpl
exDri
ver
s
Microcontroller
Microcontroller Abstraction Layer
Appl ication Layer
RTE
ECU Abstraction Layer ECU Abstraction Layer
p a g e i d : 9 4 j u
w e
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
14/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture23
Architecture – Overview of Software Layers
Complex Drivers
The Complex Drivers Layer spans from thehardware to the RTE.
Task
Provide the possibility to integrate special purpose
functionality, e.g. drivers for devices:
which are not specified within AUTOSAR,
with very high timing constrains or
for migration purposes etc.
Properties
Implementation: might be application, µC and ECU
hardware dependent
Upper Interface: might be application, µC and ECUhardware dependent
Microcontroller
Microcontroller Abstraction Layer
Appl ication Layer
RTE
ECU Abstraction Layer
Services Layer
ECU Abstraction Layer
p a g e i d : 9 4 j w
C
om pl ex
Dr i v er s
A hit t O i f S ft L
j u 8
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
15/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture24
Architecture – Overview of Software Layers
Services Layer
The Services Layer is the highest layer of the BasicSoftware which also applies for its relevance forthe application software: while access to I/Osignals is covered by the ECU Abstraction Layer,the Services Layer offers:
Operating system functionality
Vehicle network communication and managementservices
Memory services (NVRAM management)
Diagnostic Services (including UDS communication, errormemory and fault treatment)
ECU state management, mode management
Logical and temporal program flow monitoring (Wdgmanager)
Task
Provide basic services for applications and basic
software modules.Properties
Implementation: mostly µC and ECU hardwareindependent
Upper Interface: µC and ECU hardware independent
C
om pl ex
Dr i v er s
Microcontroller
Microcontroller Abstraction Layer
Appl ication Layer
RTE
ECU Abstraction Layer
Services Layer
ECU Abstraction Layer
p a g e i d : 9 4 j
A hit t O i f S ft L
4 j u 9
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
16/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture25
Architecture – Overview of Software Layers
AUTOSAR Runtime Environment (RTE)
The RTE is a layer providing communication services
to the application software (AUTOSAR Software
Components and/or AUTOSAR Sensor/Actuator
components).
Above the RTE the software architecture style
changes from “layered“ to “component style“.
The AUTOSAR Software Components communicate
with other components (inter and/or intra ECU)
and/or services via the RTE.
Task
Make AUTOSAR Software Components independent
from the mapping to a specific ECU.
Properties
Implementation: ECU and application specific
(generated individually for each ECU)
Upper Interface: completely ECU independent
Microcontroller
Microcontroller Abstraction Layer
Appl ication Layer
AUTOSAR Runtime Environment (RTE)
ECU Abstraction Layer
Services Layer
ECU Abstraction Layer
p a g e i d : 9 4j
C
om pl ex
Dr i v er s
Architecture Overview of Software Layers4 j 3 3
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
17/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture26
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 andECU internal SW
System
Provision of standardizeable (operating system, timers, error memory) and ECU specific
(ECU state management, watchdog manager) services and library functions
p a g e i d : 9 4
Architecture Introduction to Basic Software Module Types 4 j u i
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
18/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture27
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.
p a g e i d : 9
Architecture Introduction to Basic Software Module Types
4 j u q
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
19/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture28
Architecture – Introduction to Basic Software Module Types
Driver (external)
External devices are located on the ECU hardware outside the microcontroller. Examples forexternal 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.
p a g e i d : 9
Architecture – Introduction to Basic Software Module Types
4 j w x
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
20/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture29
Architecture – Introduction to Basic Software Module Types
Interface
An Interface (interface module) contains the functionality to abstract from modules which arearchitecturally 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).
p a g e i d : 9 4
Architecture – Introduction to Basic Software Module Types9 4 j w w
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
21/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture30
Architecture Introduction to Basic Software Module Types
Handler
A handler is a specific interface which controls the concurrent, multiple and asynchronousaccess 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).
p a g e i d : 9
Architecture – Introduction to Basic Software Module Types
9 4 j 2 2
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
22/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture31
Architecture Introduction to Basic Software Module Types
Manager
A manager offers specific services for multiple clients. It is needed in all cases where purehandler 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 reliabledata storage, data checking, provision of default values etc.
p a g e i d :
Architecture – Overview of Software Layers 9 9 j 2 2
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
23/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture32
y
Introduction to Libraries
Libraries are a collection of functions forrelated purposes
Libraries:
can be called by BSW modules (that
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
do not have internal states
do not require any initialization
are synchronous, i.e. they do not have
wait points
p a g e i d :
A U T O S A R
L i b r a r i e s
Basic Software
Runtime Environment (RTE)
Application Layer
ECU Hardware
The fol lowing l ibraries are
specified within AUTOSAR:
Fixed point mathematical,
Floating point mathematical,
Interpolation for fixed point data,
Interpolation for floating point data,
Bit handling,
E2E communication,
CRC calculation,
Extended functions (e.g. 64bits
calculation, filtering, etc.) and
Crypto
: 9 5 j t 4
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
24/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture33
Table of contents
1. Architecture1. 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
p a g e i d :
Architecture – Content of Software Layers Application Layer : o i u 4 2
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
25/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture34
y
Microcontroller Abstraction Layer
The µC Abstraction Layer consists of the following module groups:
Communication DriversDrivers for ECU onboard (e.g. SPI) and vehicle communication (e.g. CAN).OSI-Layer: Part of Data Link Layer
I/O DriversDrivers for analog and digital I/O (e.g. ADC, PWM, DIO)
Memory DriversDrivers for on-chip memory devices (e.g. internal Flash, internal EEPROM) and memory mapped external memory devices
(e.g. external Flash)
Microcontroller DriversDrivers for internal peripherals (e.g. Watchdog, General Purpose Timer)Functions with direct µC access (e.g. Core test)
Microcontroller
A D C
C C U
I/O Drivers
A D C Dr i v er
DI ODr i v er
P WMDr i v er
I C UDr i v er
P WM
L I N or
S C I
C A N
S P I
E E P R OM
F L A S H
WDT
GP T
Microcontroller Drivers Communication DriversMemory Drivers
RA MT e s t
i n t er n al E E P R OMD
r i v er
i n t er n al F l a s h Dr i v er
W a t c h d o gDr i v e
r
M C UDr i v er
C or eT e s t
GP T Dr i v er
Software
module
internal
peripheral
device
Group of
Software
modules of
similar type
M C U
P ow er &
C l o c k Un
i t
C o m p l e x D r i v e r s
Microcont roller (µC)
Micro-
controller
Drivers
Memory
Drivers
Memory
HW Abstr.
RTE
Onboard
Dev. Abstr.
Memory
ServicesSystem Services
Communi-
cation
Drivers
Communi-
cation
Services
COM HW
Abstr.
I/O
Drivers
I/O HW
Abstraction
pp y
p a g e i d :
C A NDr i v er
L I NDr i v er
F l ex R a y Dr i v er
S P I H an d l er Dr i v
er
E t h er n e t Dr i v er
F l a s h T e s t
P ORT Dr i v er
DI O
Architecture – Content of Software Layers Application Layer
: s w r 4 2
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
26/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture35
Microcontroller Abstraction Layer: SPIHandlerDriver
The SPIHandlerDriver allows concurrent
access of several clients to one or more SPI
busses.
To abstract all features of a SPI microcontroller
pins dedicated to Chip Select, those shalldirectly be handled by the SPIHandlerDriver.
That means those pins shall not be available
in DIO Driver.Example:
C o m p l e x D r i v e r s
Microcont roller (µC)
Micro-
controller
Drivers
Memory
Drivers
Memory
HW Abstr.
RTE
Onboard
Dev. Abstr.
Memory
ServicesSystem Services
Communi-
cation
Drivers
Communi-
cation
Services
COM HW
Abstr.
I/O
Drivers
I/O HW
Abstraction
Memory Hardware Abstraction
I/O Hardware Abstraction
µC SPI
Communication Drivers
SPIHandlerDriver
Driver for ext.
I/O ASIC
Driver for ext.
ADC ASIC
Onboard Device Abstraction
External
Watchdog Driver
External
EEPROM
Driver
p a g e i d
Architecture – Content of Software Layers Application Layer d : 2 1 1 1 2
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
27/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture36
Complex Drivers
A Complex Driver is a module which implements non-
standardized functionality within the basic softwarestack.
An example is to implement complex sensorevaluation and actuator control with direct accessto the µC using specific interrupts and/or complexµC peripherals (like PCP, TPU), e.g.
Injection control
Electric valve control
Incremental position detection
Task:Fulfill the special functional and timing requirements
for handling complex sensors and actuators
Properties:
Implementation: highly µC, ECU and applicationdependent
Upper Interface to SW-Cs: specified and implementedaccording to AUTOSAR (AUTOSAR interface)
Lower interface: restricted access to StandardizedInterfaces
Complex Drivers
E
l e c t r i c V al v e C on t r ol
I n j e c t i on C on t r ol
I n c r em en t al P o s i t i onD e t e c t i on
C om pl ex D ev i c eDr i v er X
Y
µC
e. g. C C
U
e. g.P C
P
e. g.T P U
Example:
C o m p l e x D r i v e r s
Microcont roller (µC)
Micro-
controller
Drivers
Memory
Drivers
Memory
HW Abstr.
RTE
Onboard
Dev. Abstr.
Memory
ServicesSystem Services
Communi-
cation
Drivers
Communi-
cation
Services
COM HW
Abstr.
I/O
Drivers
I/O HW
Abstraction
p a g e i d
Architecture – Content of Software Layers Application Layer d : d d e a q
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
28/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture37
ECU Abstraction : I/O Hardware Abstraction
The I/O Hardware Abstraction is a group of modules
which abstracts from the location of peripheral I/Odevices (on-chip or on-board) and the ECUhardware layout (e.g. µC pin connections andsignal level inversions). The I/O Hardware
Abstraction does not abstract from thesensors/actuators!
The different I/O devices might be accessed via an I/Osignal interface.
Task:
Represent I/O signals as they are connected to theECU hardware (e.g. current, voltage, frequency).
Hide ECU hardware and layout properties from highersoftware layers.
Properties:
Implementation: µC independent, ECU hardwaredependent
Upper Interface: µC and ECU hardware independent,dependent on signal type specified andimplemented according to AUTOSAR (AUTOSARinterface)
Example:
C o m p l e x D r i v e r s
Microcont roller (µC)
Micro-
controller
Drivers
Memory
Drivers
Memory
HW Abstr.
RTE
Onboard
Dev. Abstr.
Memory
ServicesSystem Services
Communi-
cation
Drivers
Communi-
cation
Services
COM HW
Abstr.
I/O
Drivers
I/O HW
Abstraction
COM Drivers
I/O Hardware Abstraction
I/O Signal Interface
Driver for ext.
I/O ASIC
µC
I/O Drivers
DI O
Dr i v er
S P I H an d l er
D
r i v er
S P I
DI O
Driver for ext.
ADC ASIC
A D C Dr i v er
A D C
p a g e i d
Architecture – Content of Software Layers
ECU Ab t ti C i ti H d Ab t ti
Application Layer i d : z z t t z
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
29/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture38
ECU Abstraction : Communication Hardware Abstraction
The Communication Hardware Abstraction is a
group of modules which abstracts from the
location of communication controllers and the ECU
hardware layout. For all communication systems a
specific Communication Hardware Abstraction is
required (e.g. for LIN, CAN, FlexRay).
Example: An ECU has a microcontroller with 2 internalCAN channels and an additional on-board ASIC
with 4 CAN controllers. The CAN-ASIC is
connected to the microcontroller via SPI.
The communication drivers are accessed via bus
specific interfaces (e.g. CAN Interface).
Task:
Provide equal mechanisms to access a bus channel
regardless of it‘s location (on-chip / on-board)
Properties:
Implementation: µC independent, ECU hardware
dependent and external device dependent
Upper Interface: bus dependent, µC and ECU
hardware independent
Example:
C o m p l e
x D r i v e r s
Microcont roller (µC)
Micro-
controller
Drivers
Memory
Drivers
Memory
HW Abstr.
RTE
Onboard
Dev. Abstr.
Memory
ServicesSystem Services
Communi-
cation
Drivers
Communi-
cation
Services
COM HW
Abstr.
I/O
Drivers
I/O HW
Abstraction
Communication Hardware Abstraction
Driver for ext.
CAN ASIC
µC
C A N
S P I
Communication Drivers
C A NDr i v er
S P I H a
n d l er
Dr i v er
I/O Drivers
DI OD
r i v er
DI O
CANTrans-
ceiver
Driver
p a g e
CAN Interface
Architecture – Content of Software Layers
S M H d Ab t ti
Application Layer d : w w w a a
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
30/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture39
Scope: Memory Hardware Abstraction
The Memory Hardware Abstraction is a group of
modules which abstracts from the location ofperipheral memory devices (on-chip or on-board)and the ECU hardware layout.
Example: on-chip EEPROM and external EEPROMdevices are accessible via the samemechanism.
The memory drivers are accessed via memory specificabstraction/emulation modules (e.g. EEPROM
Abstraction).
By emulating an EEPROM abstraction on top of Flashhardware units a common access via Memory
Abstraction Interface to both types of hardware is
enabled.
Task:
Provide equal mechanisms to access internal (on-chip)and external (on-board)memory devices and type of memory hardware
(EEPROM, Flash).
Properties:
Implementation: µC independent, external devicedependent
Upper Interface: µC, ECU hardware and memory
device independent
Example:
C o m p l e
x D r i v e r s
Microcont roller (µC)
Micro-
controller
Drivers
Memory
Drivers
Memory
HW Abstr.
RTE
Onboard
Dev. Abstr.
Memory
ServicesSystem Services
Communi-
cation
Drivers
Communi-
cation
Services
COM HW
Abstr.
I/O
Drivers
I/O HW
Abstraction
COM Drivers
Memory Hardware Abstraction
µC
Memory Drivers
E E P R OM
Dr i v er
S
P I H an d l er
Dr i v er
S P I
E E P R OM
F l a s h
I n t er n al
F l a s h Dr i v er
Memory Abstraction Interface
External
EEPROM Driver
p a g e i d
EEPROM Abstraction
External
Flash Driver
Flash EEPROM
Emulation
Architecture – Content of Software Layers
Onboard Device Abstraction Application Layer
i d : x x d x x
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
31/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture40
Onboard Device Abstraction
The Onboard Device Abstraction contains
drivers for ECU onboard devices which
cannot be seen as sensors or actuators like
internal or external watchdogs. Those
drivers access the ECU onboard devices via
the µC Abstraction Layer.
Task:
Abstract from ECU specific onboard devices.
Properties :
Implementation: µC independent, external
device dependent
Upper Interface: µC independent, partly ECUhardware dependent
Example:
C o m p l e
x D r i v e r s
Microcont roller (µC)
Micro-
controller
Drivers
Memory
Drivers
Memory
HW Abstr.
RTE
Onboard
Dev. Abstr.
Memory
ServicesSystem Services
Communi-
cation
Drivers
Communi-
cation
Services
COM HW
Abstr.
I/O
Drivers
I/O HW
Abstraction
COM Drivers
Onboard Device Abstraction
µC
Microcontroller
Drivers S P I H an d l er
Dr i v e
r
S P I
i n t er n al
w a t c h
d o g
d r i v
er
W d g
External
Watchdog Driver
Watchdog Interface
p a g e
Architecture – Content of Software Layers
Communication Services General Application Layer
i d : y y x y y
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
32/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture41
Communication Services – General
The Communication Services are a group of
modules for vehicle network communication (CAN,LIN and FlexRay). They interface with thecommunication drivers via the communicationhardware abstraction.
Task:
Provide a uniform interface to the vehicle network forcommunication.
Provide uniform services for network management
Provide uniform interface to the vehicle network fordiagnostic communication
Hide protocol and message properties from theapplication.
Properties:
Implementation: µC and ECU HW independent, partlydependent on bus type
Upper Interface: µC, ECU hardware and bus typeindependent
The communication services will be detailed for eachrelevant vehicle network system on the following
pages.
Example:
C o m p l e
x D r i v e r s
Microcont roller (µC)
Micro-
controller
Drivers
Memory
Drivers
Memory
HW Abstr.
RTE
Onboard
Dev. Abstr.
Memory
ServicesSystem Services
Communi-
cation
Drivers
Communi-
cation
Services
COM HW
Abstr.
I/O
Drivers
I/O HW
Abstraction
Communication Services
Transport Protocol
DCM
Diagnostic
Com.
Manager
AUTOSAR
COM
NMIPDUMultiplexer
Generic NM
Interface
State
Manager
p a g e
PDU Router
Debugging
Bus specific modules
Architecture – Content of Software Layers
Communication Stack CAN RTE
Application Layer
e i d : p p o p p
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
33/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture42
Communication Stack – CAN
The CAN Communication Services are a group of modulesfor vehicle network communication with the communication
system CAN.
Task:
Provide a uniform interface to the CAN network. Hide
protocol and message properties from the application.
Please Note:
There are two transport protocol modules in the CAN stack
which can be used alternatively or in parallel: CanTp and
J1939Tp. They are used as follows:
CanTp: ISO Diagnostics (DCM), large PDU transport
on standard CAN bus
- J1939Tp: J1939 Diagnostics, large PDU transport on
J1939 driven CAN bus
Example:
C o m p l e
x D r i v e r s
Microcont roller (µC)
Micro-
controller
Drivers
Memory
Drivers
Memory
HW Abstr.
RTE
Onboard
Dev. Abstr.
Memory
ServicesSystem Services
Communi-
cation
Drivers
Communi-
cation
Services
COM HW
Abstr.
I/O
Drivers
I/O HW
Abstraction
I/O Drivers
Communication Services
Communication Drivers
Communication Hardware Abstraction
CAN Driver
Driver for ext.
CAN ASIC
SPIHandler
Driver
Di a gn o s t i c
C om.
M an a g er
AUTOSAR
COM
CAN NM
µC SPI CAN
External
CAN Controller
CAN Transceiver
Driver
DIO Driver
Generic NM
Interface
CAN
State
Manager
p a g e
PDU Router
CAN Interface
D e b u g gi n g
I P D U
M ul t i pl ex er J1939 Transport
Protocol
CAN Transport
Protocol
Architecture – Content of Software Layers
Communication Stack – CAN RTE
Application Layer
e i d : b b n n h
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
34/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture43
Communication Stack – CAN
Properties:
Implementation: µC and ECU HW independent, partlydependent on CAN.
AUTOSAR COM, Generic NM (Network Management)Interface and Diagnostic Communication Manager are thesame for all vehicle network systems and exist as oneinstance per ECU.
Generic NM Interface contains only a dispatcher. Nofurther functionality is included. In case of gateway ECUs itcan also include the NM coordinator functionality whichallows to synchronize multiple different networks (of the
same or different types) to synchronously wake them up orshut them down.
CAN Generic NM is specific for CAN networks and will beinstantiated per CAN vehicle network system. CANGeneric NM interfaces with CAN via underlying network
adapter (CAN NM).
The communication system specific Can State Managerhandles the communication system dependent Start-upand Shutdown features. Furthermore it controls thedifferent options of COM to send PDUs and to monitor
signal timeouts.
C o m p l e
x D r i v e r s
Microcont roller (µC)
Micro-
controller
Drivers
Memory
Drivers
Memory
HW Abstr.
RTE
Onboard
Dev. Abstr.
Memory
ServicesSystem Services
Communi-
cation
Drivers
Communi-
cation
Services
COM HW
Abstr.
I/O
Drivers
I/O HW
Abstraction
p a g e
Architecture – Content of Software Layers
Communication Stack Extension – TTCAN RTE
Application Layer
e i d : q w w w e
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
35/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture44
Communication Stack Extension TTCAN
The TTCAN Communication Services are the optionalextensions of the plain CAN Interface and CAN Driver module
for vehicle
network communication with the communication system
TTCAN.
Task:
Provide a uniform interface to the TTCAN network. Hide
protocol and message properties from the application.
Please Note:
The CAN Interface with TTCAN can serve both aplain CAN Driver and a CAN Driver TTCAN.
Example:
C o m p l e
x D r i v e r s
Microcont roller (µC)
Micro-
controller
Drivers
Memory
Drivers
Memory
HW Abstr.
RTE
Onboard
Dev. Abstr.
Memory
ServicesSystem Services
Communi-
cation
Drivers
Communi-
cation
Services
COM HW
Abstr.
I/O
Drivers
I/O HW
Abstraction
I/O Drivers
Communication Services
Communication Drivers
Communication Hardware Abstraction
CAN Driver
Driver for ext.
CAN ASIC
SPIHandler
Driver
CAN Transport
Protocol
CAN NM
µC SPI TTCAN
External
TTCAN Controller
CAN Transceiver
Driver
DIO Driver
Generic NM
Interface
CAN
State
Manager
p a g e
CAN Interface
Di a gn o s t i c
C om.
M an a g er
AUTOSAR
COM
PDU Router
D e b u g gi n g
I P D U
m ul t i pl ex er
TTCAN
TTCAN
Architecture – Content of Software Layers
Communication Stack Extension – TTCAN RTE
Application Layer
e i d : g g g h h
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
36/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture45
Communication Stack Extension TTCAN
Properties:
TTCAN is an absolute superset to CAN, i.e. a CAN stack
which supports TTCAN can serve both a CAN and a
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.
C o m p l e
x D r i v e r s
Microcont roller (µC)
Micro-
controller
Drivers
Memory
Drivers
Memory
HW Abstr.
RTE
Onboard
Dev. Abstr.
Memory
ServicesSystem Services
Communi-
cation
Drivers
Communi-
cation
Services
COM HW
Abstr.
I/O
Drivers
I/O HW
Abstraction
p a g
Architecture – Content of Software Layers
Communication Stack – LIN (LIN Master) RTE
Application Layer
g e i d : 8 7 z 6 6
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
37/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture46
( )
The LIN Communication Services are a group of modules for vehiclenetwork communication with the communication system LIN.
Task:
Provide a uniform interface to the LIN network. Hide protocol andmessage properties from the application.
Properties:
The LIN Communication Services contain:
A LIN 2.1 compliant communication stack with
Schedule table manager for transmitting LIN frames and tohandle requests to switch to other schedule tables.
Transport protocol, used for diagnostics
A WakeUp and Sleep Interface
An underlying LIN Driver:
implementing the LIN protocol and adaptation the specifichardware
Supporting both simple UART and complex frame based LINhardware
Example:
C o m p l e
x D r i v e r s
Microcont roller (µC)
Micro-
controller
Drivers
Memory
Drivers
Memory
HW Abstr.
RTE
Onboard
Dev. Abstr.
Memory
ServicesSystem Services
Communi-
cation
Drivers
Communi-
cation
Services
COM HW
Abstr.
I/O
Drivers
I/O HW
Abstraction
Communication Hardware Abstraction
Communication Drivers
µC SCI
LIN Driver
Communication Services
PDU Router
AUTOSAR
COM
LIN State
Manager
p a g
Di a gn o s t i c
C om.
M an a g er
Driver for ext.
LIN ASIC
LIN Transceiver
Driver
LIN Interface
LIN NM
Generic
NM
Interface
Architecture – Content of Software Layers
Communication Stack – LIN RTE
Application Layer
g e i d : 6 6 7 6 6
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
38/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture47
Note: Integration of LIN into AUTOSAR:
Lin Interface controls the WakeUp/Sleep API
and allows the slaves to keep the bus awake
(decentralized approach).
The communication system specific LIN State
Manager handles the communicationdependent 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 interfacingCOM.
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).
C o m p l e
x D r i v e r s
Microcont roller (µC)
Micro-
controller
Drivers
Memory
Drivers
Memory
HW Abstr.
RTE
Onboard
Dev. Abstr.
Memory
ServicesSystem Services
Communi-
cation
Drivers
Communi-
cation
Services
COM HW
Abstr.
I/O
Drivers
I/O HW
Abstraction
p a g
Architecture – Content of Software Layers
Communication Services – LIN Slave RTE
Application Layer
g e i d : 1 1 2 2 d
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
39/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture48
LIN Slaves usually are „intelligent“ actuators and
slaves that are seen as black boxes. As theyprovide very little hardware capabilities and
resources, it is not intended to shift AUTOSAR SW-
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
are seen as non-AUTOSAR ECUs. Please refer to
the VFB specification.
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
some standard AUTOSAR modules (like EEPROM,
DIO).
Reason: LIN slaves usually have very limited memoryresources or are ASICs with „hard-coded“ logic.
Note: LIN slaves cannot fulfill the requirements to a
Debugging Host, since LIN is not a multi-master
bus.
Example:
C o m p l e
x D r i v e r s
Microcont roller (µC)
Micro-
controller
Drivers
Memory
Drivers
Memory
HW Abstr.
Onboard
Dev. Abstr.
Memory
ServicesSystem Services
Communi-
cation
Drivers
Communi-
cation
Services
COM HW
Abstr.
I/O
Drivers
I/O HW
Abstraction
LIN Slave Application
Communication Drivers
LIN Communication
Stack
µC SCI
p a g
Architecture – Content of Software Layers
Communication Stack – FlexRay RTE
Application Layer
a g e i d : k i 8 9 0
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
40/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture49
The FlexRay Communication Services are a group
of modules for vehicle network communication withthe communication system FlexRay.
Task:
Provide a uniform interface to the FlexRay network.
Hide protocol and message properties from theapplication.
Please Note:
There are two transport protocol modules in the
FlexRay stack which can be used alternatively
FrTp: FlexRay ISO Transport Layer
FrArTp: FlexRay AUTOSAR Transport Layer,
provides bus compatibility to AUTOSAR R3.x
Example:
C o m p l e
x D r i v e r s
Microcont roller (µC)
Micro-
controller
Drivers
Memory
Drivers
Memory
HW Abstr.
Onboard
Dev. Abstr.
Memory
ServicesSystem Services
Communi-
cation
Drivers
Communi-
cation
Services
COM HW
Abstr.
I/O
Drivers
I/O HW
Abstraction
I/O Drivers
Communication Services
Communication Hardware Abstraction
Communication Drivers
FlexRay
NM
FlexRay Transport
Protocol
Host µC Internal FlexRay Controller
Data linesExternal
FlexRay Controller (e.g. MFR 4200)
External
FlexRay Transceiver (e.g. TJA 1080)
Driver for internal
FlexRay Controller
Driver for external
FlexRay Controller
Driver for FlexRay
Transceiver
SPIHandlerDriver DIO Driver
Generic
NM
Interface
FlexRay
State
Manager
p a
FlexRay Interface
Control/status lines
Di a gn o s t i c
C om.
M an a g er
AUTOSAR
COM
PDU Router
D e b u g gi n g
I P D U
m
ul t i pl ex er
Architecture – Content of Software Layers
Communication Stack – FlexRay RTE
Application Layer
a g e i d : 4 2 4 3 2
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
41/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture50
Properties:
Implementation: µC and ECU HW independent,
partly dependent on FlexRay.
AUTOSAR COM, Generic NM 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 is replaced by the NM
Coordinator which in addition provides the
functionality to synchronize multiple differentnetworks (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.
C o m p l e x D r i v e r s
Microcont roller (µC)
Micro-
controller
Drivers
Memory
Drivers
Memory
HW Abstr.
Onboard
Dev. Abstr.
Memory
ServicesSystem Services
Communi-
cation
Drivers
Communi-
cation
Services
COM HW
Abstr.
I/O
Drivers
I/O HW
Abstraction
p a
Architecture – Content of Software Layers
Communication Stack – TCP/IP RTE
Application Layer
a g e i d : 4 4 5 6 6
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
42/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture51 Layered Software Architecture - Document ID 053 - V 2.3 - R 4.0 Rev 000110 November 201151
The TCP/IP Communication Services are a
group of modules for vehicle networkcommunication with the communication
system TCP/IP.
Task:
Provide a uniform interface to the TCP/IP
network. Hide protocol and message
properties from the application.
C o m p l e x D r i v e r s
Microcont roller (µC)
Micro-
controller
Drivers
Memory
Drivers
Memory
HW Abstr.
Onboard
Dev. Abstr.
Memory
ServicesSystem Services
Communi-
cation
Drivers
Communi-
cation
Services
COM HW
Abstr.
I/O
Drivers
I/O HW
Abstraction
p a
Example:
I/O Drivers
Communication Services
Communication Drivers
Communication Hardware Abstraction
Ethernet Driver Handler / Driver
Socket Adaptor
UDP NM
µC MII Ethernet
External
Ethernet Controller
Ethernet Transceiver Driver
DIO Driver
Generic NM
Interface
Ethernet
State
Manager
Ethernet Interface
Di a gn o s t i c
C om.
M an a g er
AUTOSAR
COM
PDU Router
D e b u g gi n g
I P D U
m ul t i pl ex er DoIP
Architecture – Content of Software Layers
Communication Stack – TCP/IP – Socket Adaptor RTE
Application Layer
p a g e i d : q q e e t
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
43/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture52 Layered Software Architecture - Document ID 053 - V 2.3 - R 4.0 Rev 000110 November 201152
Properties:
The SoAd Module fully contains the DoIP
protocol handler.
The SoAd provides two APIs towards the
TCP/IP stack.
The TCP/IP Stack may contain a multitudeof 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.
C o m p l e x D r i v e r s
Microcont roller (µC)
Micro-
controller
Drivers
Memory
Drivers
Memory
HW Abstr.
Onboard
Dev. Abstr.
Memory
ServicesSystem Services
Communi-
cation
Drivers
Communi-
cation
Services
COM HW
Abstr.
I/O
Drivers
I/O HW
Abstraction
p
Architecture – Content of Software Layers
Communication Stack – General RTEC i
Application Layer
p a g e i d : b b n n q
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
44/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture53
General communication stack properties:
A signal gateway is part of AUTOSAR COM to route
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”
C o m p l e x D r i v e r s
Microcont roller (µC)
Micro-
controller
Drivers
Memory
Drivers
Memory
HW Abstr.
Onboard
Dev. Abstr.
Memory
ServicesSystem Services
Communi-
cation
Drivers
Communi-
cation
Services
COM HW
Abstr.
I/O
Drivers
I/O HW
Abstraction
p
Architecture – Content of Software Layers
Services: Memory Services RTEC i
Application Layer
p a g e i d : 9 d d f f
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
45/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture54
The Memory Services consist of one module,
the NVRAM Manager. It is responsible forthe management of non volatile data
(read/write from different memory drivers).
Task: Provide non volatile data to theapplication in a uniform way. Abstract from
memory locations and properties. Provide
mechanisms for non volatile data
management like saving, loading, checksum
protection and verification, reliable storageetc.
Properties :
Implementation: µC and ECU hardware
independent, highly configurable
Upper Interface: µC and ECU hardware
independent specified and implemented
according to AUTOSAR
(AUTOSAR interface)
Example:
C o m p l e x D r i v e r s
Microcont roller (µC)
Micro-
controller
Drivers
Memory
Drivers
Memory
HW Abstr.
Onboard
Dev. Abstr.
Memory
ServicesSystem Services
Communi-
cation
Drivers
Communi-
cation
Services
COM HW
Abstr.
I/O
Drivers
I/O HW
Abstraction
Memory Services
NVRAM Manager
Architecture – Content of Software Layers
Services: System Services RTECommuni
Application Layer
p a g e i d : q w e h g
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
46/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture55
The System Services are a group of modules
and functions which can be used by modulesof all layers. Examples are Real Time
Operating System (which includes timer
services) and Error Manager.
Some of these services are µC dependent (likeOS), partly ECU hardware and application
dependent (like ECU State Manager) or
hardware and µC independent.
Task:Provide basic services for application and
basic software modules.
Properties:Implementation: partly µC, ECU hardware and
application specific
Upper Interface: µC and ECU hardware
independent
Example:
C o m p l e x D r i v e r s
Microcont roller (µC)
Micro-
controller
Drivers
Memory
Drivers
Memory
HW Abstr.
Onboard
Dev. Abstr.
Memory
ServicesSystem Services
Communi-
cation
Drivers
Communi-
cation
Services
COM HW
Abstr.
I/O
Drivers
I/O HW
Abstraction
System Services
F un c t i onI nh i b i t i on
M an a g er ( F I M )
W a t c h d o gM an a g er
( W d gM )
D ev el o pm en t E r r or
T r a c er ( D e t )
Di a gn o s t i c E v en t
M an a g er ( D em )
C omm uni c a t i on
M an a g er ( C omM )
A UT O S A R O S
B a s i c S of t w ar eM o d e
M an a g er ( B s wM )
E C U S t a t eM an a g er
( E c uM )
p
S y n c h r oni z e d T i m e-
b a s eM an a g er
( S t b M )
Di a gn o s t i c L o g an d
T r a c e ( Dl t )
Architecture – Content of Software Layers
Error Handling, Report ing and Diagnostic p a g e i d : 3 e d f g
RTE
Communi-
Application Layer
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
47/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture56
There are dedicated modules for different aspectsof error handling in AUTOSAR. E.g.:
The Debugging module supports debugging of
the AUTOSAR BSW. It interfaces to ECU
internal modules and to an external host system
via communication .
The Diagnostic Event Manager is responsible
for processing and storing diagnostic events
(errors) and associated FreezeFrame data.
The module Diagnostic Log and Trace
supports logging and tracing of applications. Itcollects user defined log messages and converts
them into a standardized format.
C o m p l e x D r i v e r s
Microcont roller (µC)
Micro-
controller
Drivers
Memory
Drivers
Memory
HW Abstr.
Onboard
Dev. Abstr.
Memory
ServicesSystem Services
Communi-
cation
Drivers
Communi
cation
Services
COM HW
Abstr.
I/O
Drivers
I/O HW
Abstraction
S y s t em
S er v i c e s
Microcontroller
AUTOSAR Runtime Environment (RTE)
Microcontroller Drivers
Onboard Device
Abst raction
Communication
Drivers
Communication
Hardware
Abst raction
Communication
Services
Application Layer
Function Inhibition
Manager
Watchdog Manager
Development Error
Tracer
Diagnostic Event
Manager
Watchdog Interface
Watchdog Driver
Diagnostic Communi-
cation Manager
DebuggingDiagnostic Log
and Trace
XCP
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.
Architecture – Content of Software Layers
Application Layer: Sensor/Actuator Software Components
RTE
MCommuni-
Application Layer
p a g e i d : x s j i 8
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
48/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture57
The Sensor/Actuator AUTOSAR Software
Component is a specific type of AUTOSARSoftware Component for sensor evaluationand actuator control. Though not belongingto the AUTOSAR Basic Software, it isdescribed here due to its strong relationship
to local signals. It has been decided to locatethe Sensor/Actuator SW Components abovethe RTE for integration reasons(standardized interface implementation andinterface description). Because of theirstrong interaction with raw local signals,
relocatability is restricted.
Task:
Provide an abstraction from the specificphysical properties of hardware sensors andactuators, which are connected to an ECU.
Properties :
Implementation: µC and ECU HW independent,
sensor and actuator dependent
Example:
C o m p l e x D r i v e r s
Microcont roller (µC)
Micro-
controller
Drivers
Memory
Drivers
Memory
HW Abstr.
Onboard
Dev. Abstr.
Memory
ServicesSystem Services
Communi-
cation
Drivers
Communi
cation
Services
COM HW
Abstr.
I/O
Drivers
I/O HW
Abstraction
Appl ication Layer
Actuator SoftwareComponent
Sensor SoftwareComponent
RTE
Basic Software
Interfaces to (e.g.)
• I/O HW Abstraction (access to I/O signals)
• Memory Services (access to calibration data)
• System Services (access to Error Manager)
Table of contents
p a g e i d : 9 6 j t 4
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
49/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture58
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
Architecture – Content of Software Layers
Example of a Layered Software Architecture for Multi-Core Microcontroller p a g e i d : w 1 1 1 b
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
50/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture59
ECU
core 1:core 0:
C om pl ex Dr i v er s
Micro-controller
Drivers
Memory
Drivers
Memory HW
Abstraction
Onboard Dev.
Abstraction
Memory
Services
System Services
Communi-
cation Drivers
Communi-
cation
Services
COM HW
Abstraction
I/O
Drivers
I/O HW
Abstraction C om pl ex Dr i v er s
Microcont roller (µC)
Core Test
Application Layer
RTE
E x am pl e: anE C U
wi t
h a t w o c or emi c
r o c on t r ol l er
Operating
System
ECU State
Manager
Architecture – Content of Software Layers
Scope: Multi-Core System Services
r s
RTE
Memory
S iSystem Services
Communi-
cation
Application Layer
p a g e i d : w 1 1 1 c
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
51/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture60
Microcontroller core 0:
C o m
p l e x D r i v e r
Microcont roller (µC)
Micro-controller
Drivers
Memory
Drivers
Memory
HW Abstr.
Onboard
Dev. Abstr.
ServicesSystem Services
Communi-cation
Drivers
cation
Services
COM HW
Abstr.
I/O
Drivers
I/O HW
Abstraction
System Services
F
un c t i onI nh i b i t i on
M an a g er
…
D
ev el o pm en t E r r or
T r a c er
Di a gn o s t i c E v en t
M an a g er
C omm uni c a t i on
M an a g er
E C
U S t a t eM an a g er
C or e 0
core 1:
System Services
A UT O S A R O S
E C U s t a t e
m an a g em en t C or e1
A UT O S A R O S
i O C
I n t er O s A p pl i c a t i on
c omm uni c a t i on
i O C
I n t er O s A p pl i c a t i on
c omm uni c a t i on
The IOC, as shown in the figure, provides communication
services which can be accessed by clients which needto communicate across OS-Application boundaries on
the same ECU. The IOC is part of the OS
Every Core runs a kind of ECU state management
B a
s i c S of t w ar eM o d e
M an a g er
E x am pl e: anE
C U
wi t h a t w o c or emi c r o c on t r ol l er
Table of contents p a g e i d : 9 7 j t 4
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
52/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture61
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
Architecture
Overview of Modules – Implementation Conformance Class 3 - ICC3 p a g e i d : 9 d f c 8
This figure shows the mapping of basic software modules to AUTOSAR layers
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
53/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture62
Not all modules are shown here
Complex
Drivers
Microcontroller
AUTOSAR Runtime Environment (RTE)
Microcontroller Drivers Memory Drivers I/O Drivers
I/O Hardware Abstraction
Memory Hardware
Abstraction
Memory ServicesSystem Services
Onboard Device
Abstraction
Communication Drivers
Communication
Hardware Abstraction
Communication Services
Application Layer
P or t
A d c
Di o
P wm
I c u
R amT s t
C an
F l s
W d g
L i n
M C U
F r
G p t
S pi
MemIf
Driver forext.
I/O ASIC
Driver forext.
ADC ASIC
WdgIf
Tp
C om
Nm
I p d uM
Nm
If
ext. DrvTrcv.
NvMF i MW d gM
D e t
D em
C omM
A UT O S A R O S
PduR
This figure shows the mapping of basic software modules to AUTOSAR layers
I/O Signal Interface
Ea Fee
Dl t
S t b M
E c uM
E e p
E t h
B s wM
D c m
D e b u g
gi n g
X C P
xxx Interface
C s m
F l s T s t
C or eT s t
Architecture
Overview of Modules – Implementation Conformance Classes – ICC2 p a g e i d : 9 2 j c 9
The clustering shown in this document is the one defined by the project so far. AUTOSAR is currently not restricting the clustering
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
54/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture63
AUTOSAR Runtime Environment
Applicat ion Layer
CAN
Com
Services
… …O
S
*
ECU Hardware
CAN Driver
COM
CAN Interface
..CAN
TP
CAN
NM
…
CAN St Mgr …
PDU Router
… ICC3 module ICC2 clusters
The clustering shown in this document is the one defined by the project so far. AUTOSAR is currently not restricting the clusteringon ICC2 level to dedicated clusters as many different constraint and optimization criteria might lead to different ICC2clusterings. There might be different AUTOSAR ICC2 clusterings against which compliancy can be stated based on a to be
defined approach for ICC2 compliance.
Architecture
Overview of Modules – Implementation Conformance Classes – ICC1 p a g e i d : 9 4 t 2 1
In a basic software which is compliant to ICC1 no modules or clusters are required.
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
55/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture64
Proprietary software
AUTOSAR Runtime Environment
Applicat ion Layer
ECU Hardware
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.
Architecture
Overview of Modules – Implementation Conformance Classes – behavior to the outside p a g e i d : 9 4 p 2 1
Basic software (including the RTE) which is AUTOSAR compliant (ICC1-3) has to behave to the outside as specified by ICC3.
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
56/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture65
Basic Software
AUTOSAR Runtime Environment
Application Layer
ECU Hardware
( g ) p ( ) p y
For example the behavior towards:
buses,
boot loaders and
applications.
ICC 3 compliantbehavior
Table of contents p a g e i d : 9 8 j t 4
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
57/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture66
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. Interfaces1. General
2. Interaction of Layers (Examples)
2. Configuration
3. Integration and Runtime aspects
Interfaces
Type of Interfaces in AUTOSAR p a g e i d : t z 7 6 a
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
58/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture67
AUTOSAR Interface
An "AUTOSAR Interface" defines the information exchanged between
software components and/or BSW modules. This description isindependent of a specific programming language, ECU or network
technology. AUTOSAR Interfaces are used in defining the ports of
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.
Standardized AUTOSAR
Interface
A "Standardized AUTOSAR Interface" is an "AUTOSAR Interface" whose
syntax and semantics are standardized in AUTOSAR. The "Standardized
AUTOSAR Interfaces" are typically used to define AUTOSAR Services,
which are standardized services provided by the AUTOSAR BasicSoftware to the application Software-Components.
Standardized Interface
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 programminglanguage (like "C"). Because of this, "standardized interfaces" are
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.
Interfaces
Components and interfaces view (simpli fied) p a g e i d : 9 4 j u 5
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
59/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture68
ECU-Hardware
AUTOSAR Runtime Environment (RTE)
Actuator
SoftwareComponent
AUTOSARInterface
Applicat ionSoftware
Component
Sensor
SoftwareComponent
Applicat ionSoftware
Component
..............
AUTOSARSoftware
Basic Software
StandardizedInterface
AUTOSARInterface
AUTOSARInterface
AUTOSARInterface
Microcontroller Abstraction
AUTOSARSoftware
Component
StandardSoftware
Standardized AUTOSAR
Interface
Services
StandardizedInterface
ECU
Abstraction
AUTOSARInterface
StandardizedInterface
ComplexDrivers
AUTOSARInterface
VFB & RTErelevant
StandardizedInterface
Communication
StandardizedInterface
StandardizedInterface
OperatingSystem
RTErelevant
BSWrelevant
S t an d ar d i z
e d
I n t er f a c e
Possible interfacesinside
Basic Software(which are
not specifiedwith in AUTOSAR)
Note: This figure is incomplete with respect to the possible interactions between the layers.
Interfaces:
Interface
Interfaces: General Rules
General Interfacing Rules
Horizontal Interfaces Vertical Interfaces
p a g e i d : a 6 z t
r
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
60/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture69
Services Layer: horizontal interfaces are allowedExample: Error Manager saves fault data using the
NVRAM manager
ECU Abstraction Layer: horizontal interfaces are
allowed
A complex driver may use selected other BSWmodules
µC Abstraction Layer: horizontal interfaces are not
allowed. Exception: configurable notifications are
allowed due to performance reasons.
Microcontroller (µC)
Vertical Interfaces
One Layer may access all interfaces of the SW layerbelow
Bypassing of one software layer should be avoided
Bypassing of two or more software layers is notallowed
Bypassing of the µC Abstraction Layer is not allowed
A module may access a lower layer module of
another layer group (e.g. SPI for external hardware)
All layers may interact with system services.
AUTOSARSW Comp
1
AUTOSARSW Comp
3
AUTOSARSW Comp
4
AUTOSARSW Comp
5
o n
Interfaces: General Rules
Layer Interaction Matrix p a g e i d : 1 x d f r
-
8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture
61/143
- AUTOSAR Confidential -
Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture70
S y s t e m
S e r v i c e s
M e m o r y S e r v
i c e s
C o m m u n i c a t i o n S e r v i c e s
C o m p l e x D r i v
e r s
I / O
H a r d w a r e
A b s t r a c t i o n
O n b o a r d D e v i c e A b s t r a c t i o n
M e m o r y H a r d
w a