AUTOSAR Basic Training PDF

Alessandra Mitidieri C.
Roberto Sobrito
AUTOSAR training
Automotive Open System Architecture
Cooperate on standards, compete on implementation.
AUTOSAR basic training
2
Agenda
Whats AUTOSAR?
Partnership Structure and
Members
AUTOSAR Main Topics and
Benefits
AUTOSAR Architecture
SW layers
BSW modules
RTE
Application Layer
Conformance classes
AUTOSAR roadmap
FGA roadmap and strategies
AUTOSAR in FGA
3
About AUTOSAR
AUTOSAR (AUTomotive Open System ARchitecture) is an open and
standardized automotive software architecture, jointly developed by automobile
manufacturers, suppliers and tool developers.
4
Exchangeability and Reuse of Software Components
5
AUTOSAR History
July, 2003 - After an initial discussion on the common challenge and objectives (Aug. 2002) the
partnership between the Core Partners was formally signed off. The Core partners were initially BMW,
Bosch, Continental, DaimlerChrysler, Volkswagen and Siemens VDO then joined by Ford Motor
Company (Nov. 2003), P.S.A. and Toyota (Dec. 2003) and General Motors (Nov. 2004).
December, 2004 FGA became AUTOSAR Premium Member
6
AUTOSAR website
7
Partnership Structure
8
Core Partners and Members
9
AUTOSAR Benefits
OEM
Supplier
Tool
Provider
OEM overlapping reuse of software modules
Maintaining ability to compete on innovative
functions
Simplification of the integration task
Reduction of total SW development costs
Reduction of version proliferation
Development partitioning among suppliers
Increase of efficiency in functional development
New business models possible
Common interfaces with development processes
Seamless, manageable, task optimized (time
dependent)
tool landscape
10
Basic AUTOSAR Approach
Functional software is described formally in terms of
Software Components (SW-Cs).
Using Software Component Descriptionsas
input, the Virtual Functional Busvalidates the
interaction of all components and interfaces before
software implementation.
Mapping of Software Componentsto ECUs.
The AUTOSAR Methodology supports
the generation of an E/E architecture.
Following the AUTOSAR Methodology, the E/E architecture is derived from the
formal description of software and hardware components.
11
Intra- and Inter-ECU Communication
12
Layered Software Architecture
13
Layered Software Architecture : Introduction and Scope
The AUTOSAR consortium has, first of all, defined a
Software Architecture based on 3 main levels,
Application layer (SWC)
Presentation layer (RTE)
Basic Software Modules (BSW)
The Basic Software Module List and their relationship have
also been defined.
Microcontroller
Basic Software Layer (BSW)
Application Layer
AUTOSAR Runtime Environment (RTE)
14
Overview of Software Layers
15
Overviewof Software Layers - Component View
ECU-Hardware
Actuator
Software
Component
AUTOSAR
Interface
Application
Software
Component
Sensor
Software
Component
Application
Software
Component
..............
AUTOSAR
Software
Basic Software
Standardized
Interface
AUTOSAR
Interface
AUTOSAR
Interface
AUTOSAR
Interface
Microcontroller
Abstraction
Standardized
AUTOSAR
Interface
Services
Standardized
Interface
ECU
Abstraction
AUTOSAR
Interface
Standardized
Interface
Complex
Device
Drivers
AUTOSAR
Interface
Standardized
Interface
Communication
Standardized
Interface
Standardized
Interface
Operating
System
S
t
a
n
d
a
r
d
i
z
e
d
I
n
t
e
f
a
c
e
AUTOSAR
Software
Component
Interface
ECU
Firmware
Standard
Software
API 2
VFB & RTE
relevant
API 1
RTE
relevant
API 0
API 3 Private
Interfaces inside
Basic Software
possible
16
Classification of Interfaces
In AUTOSAR three different types of interfaces exist, "AUTOSAR
Interface", "Standardized AUTOSAR Interface" and "Standardized
Interface".
AUTOSAR Interface
An "AUTOSAR Interface" defines the information exchanged between
SW-Cs. This description is independent of a specific programming
language, ECU or network technology. AUTOSAR Interfaces are used in
defining the ports of SW-Cs. Through these ports SW-Cs can communicate
with each other (send or receive information or invoke services). So
"AUTOSAR Interfaces" are to be used when it should be possible to route
the information flowing through the interface through a network.
17
Classification of Interfaces
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 Basic Software to the 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
programming language (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.
18
Overviewof Software Layers - Layered View
Complex
Drivers
Microcontroller
Microcontroller Abstraction Layer
Services Layer
Application Layer
ECU Abstraction Layer
19
Overviewof SW Layers Introduction to Basic Software
Layers (1 / 3)
Properties:
Implementation: C
dependent
Upper Interface:
standardizable and C
independent
The Microcontroller Abstraction Layer is the lowest software layer
of the Basic Software. It contains drivers, which are software modules
with direct access to the C internal peripherals and memory mapped
C external devices.
Task:
Make higher
software layers
independent of C
Co
mp
lex
Dri
ver
s
Microcontroller
Application Layer
RTE
Services Layer
20
Overviewof SW Layers - Introduction to Basic Software
Layers (2 / 3)
The ECU Abstraction Layer interfaces the drivers of the Microcontroller Abstraction Layer.
It also contains drivers for external devices.
It offers an API for access to peripherals and devices regardless of their location (C internal/external)
and their connection to the C (port pins, type of interface).
Co
mp
lex
Dri
ver
s
Microcontroller
Application Layer
RTE
Services Layer
Task:
Make higher software
layers independent of
ECU hardware layout
Properties:
Implementation: C
independent, ECU hardware
dependent
Upper Interface: C and
ECU hardware independent,
dependent on signal type
21
Overviewof SW Layers - Introduction to Basic Software
Layers (3 / 3)
The Services Layer is the highest layer of the Basic Software which also applies for its
relevance to the application software.
Co
mp
lex
Dri
ver
s
Microcontroller
Application Layer
RTE
Services Layer
Task:
Make higher software
layers independent of
ECU hardware layout
Properties:
Implementation: C
independent, ECU hardware
dependent
Upper Interface: C and
ECU hardware independent,
dependent on signal type
Services Layer
The Services Layer offers
Operating system functionality
Vehicle network communication and management services
Memory services (NVRAM management)
Diagnostic Services (including UDS communication and error memory)
ECU state management.
22
Overviewof Software Layers
- Introduction to Run-Time Environment
The RTE is a middleware layer providing communication services for the application software
(AUTOSAR Software Components and/or AUTOSAR Sensor/Actuator components).
Above the RTE the software architecture style changes from layeredto component style.
The AUTOSAR Software Components communicate with other components (inter and/or
intra ECU) and/or services via the RTE.
Co
mp
lex
Dri
ver
s
Microcontroller
Application Layer
Services Layer
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
Co
mp
lex
Dri
ver
s
Microcontroller
Application Layer
Services Layer
23
Overviewof Software Layers
- Introduction to Application Layer
The Application Layer in Autosar Architecture is located above the Autosar RTE and
encloses the Application Software.
An application in AUTOSAR consists of interconnected "AUTOSAR Software Components".
Each AUTOSAR Software Component encapsulates part of the functionality of the
application.
An AUTOSAR SW-Ccannot directly access BSW all communication is via AUTOSAR
interfaces and therefore under the control of the RTE.
Co
mp
lex
Dri
ver
s
Microcontroller
Application Layer
Services Layer
Task:
Collect the Application,
Sensor and Actuators
Software Components.
Communication
between different
SWCs and with BSW
has to be done only
through RTE
Properties:
AUTOSAR Software
Components are
independent from the
mapping to a specific ECU
Application Layer
24
Overviewof Software Layers - Introduction to Basic
Software Layers
The Basic Software can be subdivided into the following types of services:
Input/Output (I/O)
Access to sensors, actuators and ECU onboard peripherals
Memory
Standardized access to internal/external memory (mainly non volatile
memory)
Communication
Standardized access to vehicle network systems and ECU onboard
communication systems and ECU internal SW.
System
Provision of standardizable (operating system, timers, error memory)
and ECU specific (ECU state management, watchdog manager)
services and library functions.
25
Overviewof SW Layers - Layered ViewDetailed
Complex
Drivers
Microcontroller
Microcontroller Drivers Memory Drivers I/O Drivers
I/O Hardware
Abstraction
Memory Hardware
Abstraction
Memory Services System Services
Onboard Device
Abstraction
Communication
Drivers
Communication
Hardware Abstraction
Communication
Services
Application Layer
26
Driver
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 software driver for an internal device is called internal driver and is located in the Microcontroller Abstraction Layer.
External devices are located on the ECU hardware outside the microcontroller. Examples for external devices are
external EEPROM
external watchdog
external Flash
A software 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.
Example: a driver for an external EEPROM with SPI interface accesses the external EEPROM via the SPIHandlerDriver.
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.
Software module types (1)
27
Interface
An Interface contains the functionality to abstract the hardware
realization of a specific device for upper layers. 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).
28
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.
In AUTOSAR the concept of pure handlers has been abandoned
because the growing capabilities of the microcontroller hardware are
incorporating handler functionality. It makes no sense to leave the
powerful hardware resources unused and implement them in software
instead.
This means: handler functionality is often incorporated in the driver
(e.g. SPIHandlerDriver, ADC Driver).
29
Manager
A manager offers specific services for multiple clients. It is needed in all cases
where pure handler functionality is not enough for accessing and using drivers.
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
management of RAM mirrors, redundant, distributed and reliable data storage, data
checking, provision of default values etc.
30
Contents of Software Layers
31
Microcontroller
A
D
C
D
I
O
C
C
U
I/O Drivers
P
O
R
T

D
r
i
v
e
r
A
D
C

D
r
i
v
e
r
D
I
O

D
r
i
v
e
r
P
W
M

D
r
i
v
e
r
I
C
U

D
r
i
v
e
r
P
W
M
Microcontroller Abstraction Layer (MCAL)
L
I
N

o
r
S
C
I
C
A
N
S
P
I
E
E
P
R
O
M
F
L
A
S
H
W
D
T
G
P
T
Microcontroller Drivers Communication Drivers Memory Drivers
R
A
M

T
e
s
t
C
A
N

D
r
i
v
e
r
i
n
t
e
r
n
a
l
E
E
P
R
O
M

D
r
i
v
e
r
i
n
t
e
r
n
a
l
F
l
a
s
h

D
r
i
v
e
r
W
a
t
c
h
d
o
g
D
r
i
v
e
r
L
I
N

D
r
i
v
e
r
M
C
U

D
r
i
v
e
r
F
l
e
x
R
a
y
D
r
i
v
e
r
C
o
r
e
T
e
s
t
G
P
T

D
r
i
v
e
r
S
P
I
H
a
n
d
l
e
r
D
r
i
v
e
r
e
x
t
e
r
n
a
l
F
l
a
s
h

D
r
i
v
e
r
E
x
t
.

B
U
S
The C Abstaction Layer consists of the following module groups:
Communication Drivers
Drivers for ECU onboard (e.g. SPI) and vehicle communication (e.g. CAN). OSI-Layer: Part of Data Link Layer
I/O Drivers
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)
Software
module
internal
peripheral
device
Group of
Software
modules
of similar
type
M
C
U

P
o
w
e
r

&

C
l
o
c
k
U
n
i
t
32
Contents of Software Layers - Complex Drivers
A Complex Driver implements complex sensor evaluation and actuator control with direct
access to the C using specific interrupts and/or complex C peripherals (like PCP, TPU),
e.g.
injection control
electric valve control
incremental position detection
Task:
Fulfill the special functional and timing requirements for handling complex
sensors and actuators
Properties:
Implementation: highly C, ECU and application dependent
Upper Interface: specified and implemented according to AUTOSAR (AUTOSAR interface)
Complex Drivers
E
l
e
c
t
r
i
c

V
a
l
v
e
C
o
n
t
r
o
l
I
n
j
e
c
t
i
o
n
C
o
n
t
r
o
l
I
n
c
r
e
m
e
n
t
a
l
P
o
s
i
t
i
o
n

D
e
t
e
c
t
i
o
n
C
o
m
p
l
e
x
D
e
v
i
c
e
D
r
i
v
e
r

X
Y
C
e
.
g
.

C
C
U
e
.
g
.

P
C
P
e
.
g
.

T
P
U
Example:
Microcontroller (C)
Micro-
controller
Drivers
Memory
Drivers
C
o
m
p
l
e
x
D
r
i
v
e
r
s
Communi-
cation Drivers
I/O
Drivers
Application Layer
33
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, MOST, FlexRay).
Example: An ECU has a microcontroller with 2 internal CAN channels and an additional on-board ASIC with 4 CAN
controllers. The CAN-ASIC is connected to the microcontroller via SPI.
The communication drivers are accessed via bus specific interfaces (e.g. CAN Interface).
Task:
Provide equal mechanisms to access a bus channel regardless of its location
(on-chip / on-board)
Properties:
Implementation: C independent, ECU hardware dependent and external device
dependent
Upper Interface: bus dependent, C and ECU hardware independent
CAN Interface
Driver for ext.
CAN ASIC
Example:
C
C
A
N
S
P
I
C
A
N

D
r
i
v
e
r
S
P
I
H
a
n
d
l
e
r
D
r
i
v
e
r
C
o
m
p
l
e
x
D
r
i
v
e
r
s
Microcontroller (C)
Micro-
controller
Drivers
Memory
Drivers
Communi-
cation Drivers
COM HW
Abstraction
I/O
Drivers
I/O HW
Abstraction
I/O Drivers
D
I
O

D
r
i
v
e
r
D
I
O
CAN
Trans-
ceiver
Driver
Application Layer
34
Contents of Software Layers - SPIHandlerDriver
In many ECUs, a lot of onboard hardware devices like external EEPROM,
external I/O ASICs, external watchdogs etc. are connected to the
microcontroller via SPI.
The SPIHandlerDriver allows concurrent access of several clients to one or
more SPI busses.
To abstract all features of a SPI microcontrollers pins dedicated to Chip
Select shall directly be handled by the SPIHandlerDriver. That means those
pins shall not be available in DIO Driver.
Memory Hardware
Abstraction
I/O Hardware Abstraction
C
SPI
SPIHandlerDriver
Driver for ext.
I/O ASIC
Driver for ext.
ADC ASIC
Onboard Device
Abstraction
External
Watchdog
Driver
External
EEPROM
Driver
Example:
35
Contents of Software Layers I/O Hardware Abstraction
The I/O Hardware Abstraction is a group of modules which abstracts from the location of peripheral I/O devices (on-
chip or on-board) and the ECU hardware layout (e.g. C pin connections and signal level inversions). The I/O Hardware
Abstraction does not abstract from the sensors/actuators!
The different I/O devices are accessed via an I/O signal interface.
Task:
Represent I/O signals as they are connected to the ECU hardware (e.g. current, voltage, frequency).
Hide ECU hardware and layout properties from higher software layers.
Properties:
Implementation: C independent, ECU hardware dependent
Upper Interface: C and ECU hardware independent, dependent on signal type
specified and implemented according to AUTOSAR
(AUTOSAR interface)
COM Drivers
I/O Signal Interface
Driver for
ext.
I/O ASIC
Example:
C
I/O Drivers
D
I
O

D
r
i
v
e
r
S
P
I
H
a
n
d
l
e
r
D
r
i
v
e
r
S
P
I
D
I
O
Driver for
ext.
ADC ASIC
A
D
C

D
r
i
v
e
r
A
D
C
C
o
m
p
l
e
x
D
r
i
v
e
r
s
Microcontroller (C)
Micro-
controller
Drivers
Memory
Drivers
Communi-
cation Drivers
I/O
Drivers
I/O HW
Abstraction
Application Layer
36
Memory Hardware Abstraction
The Memory Hardware Abstraction is a group of modules which abstracts from the location of peripheral memory
devices (on-chip or on-board) and the ECU hardware layout.
Example: on-chip EEPROM and external EEPROM devices should be accessible via an equal mechanism.
The memory drivers are accessed via memory specific abstraction/emulation modules (e.g. EEPROM Abstraction).
By emulating an EEPROM interface and Flash hardware units a common access via Memory Abstraction Interface to both
types of hardware is enabled.
Task:
Provide equal mechanisms to access internal (on-chip) and external (on-board)
memory devices and type of memory hardware (EEPROM, Flash).
Properties:
Implementation: C independent, external device dependent
Upper Interface: C, ECU hardware and memory device independent
COM Drivers
Memory Hardware Abstraction
Example:
C
Memory Drivers
E
E
P
R
O
M

D
r
i
v
e
r
S
P
I
H
a
n
d
l
e
r
D
r
i
v
e
r
S
P
I
E
E
P
R
O
M
C
o
m
p
l
e
x
D
r
i
v
e
r
s
Microcontroller (C)
Micro-
controller
Drivers
Memory
Drivers
Memory HW
Abstraction
Communi-
cation Drivers
COM HW
Abstraction
I/O
Drivers
I/O HW
Abstraction
Application Layer
F
l
a
s
h
I
n
t
e
r
n
a
l
F
l
a
s
h

D
r
i
v
e
r
E
x
t
e
r
n
a
l
F
l
a
s
h

D
r
i
v
e
r
Memory Abstraction Interface
External
EEPROM Driver
EEPROM Abstraction
Flash
EEPROM
Emulation
37
Contents of Software Layers Onboard Device Abstraction
The Onboard Device Abstraction contains drivers for ECU onboard devices which cannot be seen as
sensors or actuators like system basic chip, external watchdog etc. 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 ECU hardware dependent
COM Drivers
Onboard Device Abstraction
Example:
C
I/O Drivers
S
P
I
H
a
n
d
l
e
r
D
r
i
v
e
r
S
P
I
Driver for System
Basic Chip
D
I
O

D
r
i
v
e
r
D
I
O
External
Watchdog
Driver
C
o
m
p
l
e
x
D
r
i
v
e
r
s
Microcontroller (C)
Micro-
controller
Drivers
Memory
Drivers
Memory HW
Abstraction
Onboard Dev.
Abstraction
Communi-
cation Drivers
COM HW
Abstraction
I/O
Drivers
I/O HW
Abstraction
Application Layer
Watchdog
Interface
38
Contents of Software Layers - Scope: Communication
Services - General
The Communication Services are a group of modules for vehicle network communication (CAN, LIN and FlexRay). They
are interfacing with the communication drivers via the communication hardware abstraction.
Task:
Provide a uniform interface to the vehicle network for communication between different applications.
Provide uniform services for network management
Provide uniform interface to the vehicle network for diagnostic communication
Hide protocol and message properties from the application.
Properties:
Implementation: C and ECU HW independent, partly dependent on bus type
Upper Interface: C, ECU hardware and bus type independent
C
o
m
p
l
e
x
D
r
i
v
e
r
s
Microcontroller (C)
Micro-
controller
Drivers
Memory
Drivers
Memory HW
Abstraction
Onboard Dev.
Abstraction
Communi-
cation Drivers
Communi-
cation
Services
COM HW
Abstraction
I/O
Drivers
I/O HW
Abstraction
Application Layer
Communication Services
<
B
u
s

s
p
e
c
i
f
i
c
>
X
C
P

T
r
a
n
s
p
o
r
t

P
r
o
t
o
c
o
l
<Bus specific>
Transport Protocol
PDU Router
DCM
Diagnostic
Com.
Manager
AUTOSAR
COM
<Bus
specific>
NM
Generic
NM
IPDU
Multiplexer
Color code: Bus specific modules are marked gray.
Note: XCP is currently not discussed within AUTOSAR
39
The CAN Communication Services are a group of modules for
vehicle network communication with the communication system CAN.
Task:
Provide a uniform interface to the CAN network. Hide protocol and
message properties from the application.
Properties:
Implementation: C and ECU HW independent, partly dependent on
CAN
AUTOSAR COM and Diagnostic Communication Manager are the
same for all vehicle network systems and exist as one instance per
ECU. Generic NM is also the same for all vehicle network systems
but will be instantiated per vehicle network system. Generic NM
interface with CAN via underlying network dependent adapter (CAN
NM).
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).
Upper Interface: C, ECU hardware and network type independent
(goal)
Communication Stack CAN
X
C
P

T
r
a
n
s
p
o
r
t

P
r
o
t
o
c
o
l
o
n

C
A
N
CAN Driver
Driver for ext.
CAN ASIC
SPIHandler
Driver
CAN Transport
Protocol
PDU Router
DCM
Diagnostic
Com.
Manager
AUTOSAR
COM
CAN NM
Generic
NM
C SPI CAN
External
CAN Controller
CAN Interface
IPDU
multiplexer
CAN Transceiver
Driver
DIO Driver
40
C
The LIN Communication Services contain:
A LIN 2.0 compliant communication stack (LIN Interface) with
Scheduler for transmitting LIN frames
Diagnostic transport protocol, which can also be used for non
diagnostic purposes.
Signal packing and unpacking with a signal based API
A WakeUp and Sleep Interface
An underlying LIN Driver
Note: Integration of LIN into AUTOSAR:
The Scheduler and its interfaces are still used to decide the point of time to send
a LIN header.
LIN has to be extended by a LIN NM which controls the WakeUp/Sleep API and
allows the slaves to keep the bus awake (decentralized approach).
The PDU router accesses the LIN Interface on PDU-Level, not on signal level. It
is expected that a LIN driver gets rid of the signal packing/unpacking code, if no
signalsare configured in the ldf (LIN Description File).
I-PDUs to be transmitted on LIN are requested by the Lin Interface at COM via
the PDU router at the point in time it requires the data.
The LIN 2.0 communication stack needs to be extended by a indication
mechanism for event driven notification of the PDU Router when a LIN frame
has been received. Otherwise, the PDU Router would need to poll the flag
interface of the LIN 2.0 communication stack.
LIN TP does not support non-diagnostic data transfer LIN will not support the
transmission of AUTOSAR signals >8 bytes.
IPDU multiplexing provides the possibility to add information to enable the
multiplexing of I-PDUs (different contents but same IDs).
SCI
LIN Driver
LIN Interface
(LIN Master Communication Stack)
Contents of Software Layers - Communication Stack LIN
PDU Router
DCM
Diagnostic
Com.
Manager
AUTOSAR
COM
LIN NM
Generic
NM
IPDU
multiplexer
LIN Transceiver
Driver
DIO Driver
41
System
Services
Communication Stack - FlexRay
FlexRay
NM
Generic
NM
FlexRay Transport
Protocol
PDU Router
The FlexRay Communication Services are a
group of modules for vehicle network communication
with the communication system FlexRay.
Task:
Provide a uniform interface to the FlexRay network.
Hide protocol and message properties from the
application.
Properties:
Implementation: C and ECU HW independent, partly
dependent on FlexRay
As seen before, AUTOSAR COM and Diagnostic
Communication Manager are the same for all vehicle
network systems and exist as one instance per ECU.
Generic NM is also the same for all vehicle network
systems but will be instantiated per vehicle network
system. The generic NM interfaces with FlexRay via
underlying network dependent adapter (FlexRay NM).
Upper Interface: C, ECU hardware and network type
independent (goal)
X
C
P

T
r
a
n
s
p
o
r
t

P
r
o
t
o
c
o
l
o
n

F
l
e
x
R
a
y
DCM
Diagnostic
Com.
Manager
AUTOSAR
COM
FlexRay Interface
IPDU
multi-
plexer
S
y
n
c
r
o
n
i
z
a
t
i
o
n
a
n
d

T
i
m
e

S
e
r
v
i
c
e
Host C
Internal FlexRay Controller
Data lines
Control/status lines
External
FlexRay Controller
(e.g. MFR 4200)
External
FlexRay Transceiver
(e.g. TJ A 1080)
Driver for internal
FlexRay Controller
Driver for
external FlexRay
Controller
Driver for FlexRay
Transceiver
FlexRay
Time
Service
SPIHandlerDriver DIO Driver
42
Communication Services LIN Slave
LIN Slaves usually are intelligent actuators and
slaves that are seen as black boxes. As they provide
very little hardware capabilities and resources it is not
intended to shift AUTOSAR SW Components 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.
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 memory
resources or are ASICs with hard-codedlogic.
LIN Slave Application
LIN Communication
Stack
C SCI
43
Contents of Software Layers - Memory Services
The Memory Services consist out of one module, the NVRAM Manager, responsbile for the management of non volatile
data (read/write fromdifferent memory drivers). It expects a RAM mirror as data interface to the application for fast read
access.
Task: Provide non volatile data to the application in a uniform way. Abstract frommemory locations and properties.
Provide mechanisms for non volatile data management like saving, loading, checksumprotection and verification, reliable
storage etc.
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:
Memory Services
NVRAM Manager
C
o
m
p
l
e
x
D
r
i
v
e
r
s
Microcontroller (C)
Micro-
controller
Drivers
Memory
Drivers
Memory HW
Abstraction
Onboard Dev.
Abstraction
Memory
Services
Communi-
cation Drivers
Communi-
cation
Services
COM HW
Abstraction
I/O
Drivers
I/O HW
Abstraction
Application Layer
44
Contents of Software Layers - System Services
The System Services are a group of modules and functions which can be used by modules of all layers. Examples
are Real Time Operating System, Error Manager and Library Functions (like CRC, interpolation etc.).
Some of these services are C dependent (like OS), 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
C
o
m
p
l
e
x
D
r
i
v
e
r
s
Microcontroller (C)
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
Application Layer
System Services
B
S
W

S
c
h
e
d
u
l
e
r
E
C
U

S
t
a
t
e

M
a
n
a
g
e
r
F
I
M
F
u
n
c
t
i
o
n
I
n
h
i
b
i
t
i
o
n

M
a
n
a
g
e
r
Example:
CRC Lib
Interpolation Lib
Crypto Lib
Bit Lib
Other Libs
Flash Check
W
a
t
c
h
d
o
g
M
a
n
a
g
e
r
D
e
v
e
l
o
p
m
e
n
t
E
r
r
o
r

T
r
a
c
e
r
D
E
M
D
i
a
g
n
o
s
t
i
c
E
v
e
n
t

M
a
n
a
g
e
r
C
o
m
m
u
n
i
c
a
t
i
o
n
M
a
n
a
g
e
r
Free Run. Timer
A
U
T
O
S
A
R

O
S
S
y
n
c
h
r
o
n
i
z
a
t
i
o
n
a
n
d

T
i
m
e

S
e
r
v
i
c
e
45
RTE - Run-Time Environment
RTE - Run-Time
Environment
46
The RTE, together with the OS, AUTOSAR COM and other Basic
Software Modules (BSW), is the implementation (for a particular
ECU) of the interfaces of the AUTOSAR Virtual Functional Bus
(VFB).
The RTE provides the infrastructure services that enable
communication to occur between AUTOSAR Software-
Components (SW-Cs) as well as acting as the means by which
AUTOSAR SW-Cs access BSW modules including the OS and
communication service.
47
The AUTOSAR RTE specification specifies the application
programming interface of the RTE and therefore the
mechanisms for accessing the RTE functionality.
The RTE is then responsible for ensuring that components
can communicate and that the system continues to function
as expected wherever the components are deployed.
48
RTE and AUTOSAR SW-Cs
An AUTOSAR SW-Ccannot directly access BSW all
communication is via AUTOSAR interfaces and therefore under the
control of the RTE.
The requirement to not have direct access applies to all BSW modules
including the operating system (OS) and the communication service.
The communication interface of an AUTOSAR SW-C consists of several
ports (which are characterized by port-interfaces).
An AUTOSAR SW-C can communicate through its interfaces with other
AUTOSAR SW-Cs (whether that component is located on the same
ECU or on a different ECU) or with BSW modules that have a port and
are located on the same ECU.
This communication can only occur via the components ports.
49
RTE and AUTOSAR SW-Cs
AUTOSAR SW-Cs have no direct access to the OS and hence there are no
tasksin an AUTOSAR application.
Concurrent activity within AUTOSAR is based around runnable entities
within components that are invoked by the RTE.
Runnable entities (RE) are the schedulable parts of SW-Cs.
A runnable entity is a sequence of instructions that can be started by the
Run-Time Environment.
The RTE shall trigger the execution of RE in accordance with the connected
RTEEvent.
The RTE supports both AUTOSAR SW-Cs where the source is available and
AUTOSAR SW-C where only the object code is available.
50
RTE and AUTOSAR Services
An AUTOSAR service is a logical entity of the BSW
offering general functionality to be used by various
AUTOSAR SW-Cs.
The functionality is accessed via standardized AUTOSAR
interfaces.
The RTE shall support the connection of AUTOSAR
services only to AUTOSAR SW-Cs located on the same
ECU.
The RTE supports neither connections to AUTOSAR
services located on remote ECUs nor connections between
AUTOSAR services.
51
RTE and OS
The interaction between the RTE and the AUTOSAR OS is
realized via the standardized interface of the OS - the
AUTOSAR OS API.
The RTE both uses OS objects already in existance (e.g.
tasks for which the RTE generator builds bodies) as well as
requires new objects (e.g. a schedule table or periodic alarms
for periodic runnable entities). The coordination of
configuration information between the OS and RTE is
therefore key since both the RTE and OS have to agree upon
the set of OS objects.
The RTE has to create the task bodies, which contain the
calls of the runnable entities.
52
RTE and OS
The RTE controls the task activation/resumption either
directly by calling OS services like SetEvent() or
ActivateTask() or indirectly by initializing OS alarms or
starting Schedule-Tables for time-based activation of
runnable entities.
If the task terminates, the generated taskbody also contains
the calls of TerminateTask() or ChainTask().
The RTE generator does not create tasks. The mapping of
runnable entities to tasks is the input to the RTE generator
and is therefore part of the RTE Configuration.
53
RTE and OS
The RTE may use OS Events for the implementation of
the abstract RTEEvents.
The RTE therefore may call the OS service functions
SetEvent(), WaitEvent(), GetEvent() and ClearEvent().
The used OS Events are part of the input information of
the RTE generator.
The RTE may use Alarms for timeout monitoring of
asynchronous client/server calls.
The RTE is responsible for Timeout handling.
The RTE may setup cyclic alarms for periodic triggering of
runnable entities (RE activation via RTEEvent TimingEvent).
The used Alarms are part of the input information of the RTE
generator.
54
RTE and OS
The RTE configurator has to allocate the necessary
alarms in the OS configuration.
The RTE may setup schedule tables for cyclic task
activation (runnable entity activation via RTEEvent
TimingEvent). The used schedule tables are part of the
input information of the RTE generator.
The RTE configurator has to allocate the necessary
schedule tables in the OS Configuration.
55
RTE and ECU Abstraction
The ECU Abstraction provides an interface to physical values for
AUTOSAR SW-Cs. It abstracts the physical origin of signals (their
pathes to the ECU hardware ports) and normalizes the signals with
respect to their physical appearance (like specific values of current
or voltage).
Froman architectural point of viewthe ECU Abstraction is part of
the BSW layer and offers AUTOSAR interfaces to AUTOSAR SW-
Cs. Seen fromthe perspective of an RTE, regular AUTOSAR ports
are connected.
However, ports of the ECU Abstraction shall always only be
connected to ports of specific AUTOSAR SW-Cs: sensor or actuator
SW-Cs.
56
RTE and ECU Abstraction
The RTE-Generator expects only one instance of the ECU
Abstraction.
The RTE-Generator shall generate a communication path
between connected ports of AUTOSAR sensor or actuator
SW-Cs and the ECU Abstraction in the exact same manner
like for connected ports of AUTOSAR SW-Cs.
The RTE-Generator shall reject configurations which require
a communication path froma AUTOSAR software component
to an ECU Abstraction located on a remote ECU.
57
RTE and Complex Device Drivers
A Complex Device Driver has an AUTOSAR Interface,
therefore the RTE can deal with the communication on
the Complex Device Drivers ports.
The Complex Device Driver is allowed to have code
entities that are not under control of the RTE but still may
use the RTE API (e.g. ISR2, BSW main functions).
58
RTE Generation Process
59
RTE generation
The RTE is generated by a generator tool.
The RTE generator is one of a set of tools that create the realization
of the AUTOSAR VFB for an ECU based on information in the ECU
Configuration Description.
The RTE Generator is responsible for creating the AUTOSAR SW-C
API functions that link AUTOSAR SW-Cs to the OS and manage
communication between AUTOSAR SW-Cs and between AUTOSAR
SW- C and BSW.
The RTE generation process consists of two distinct phases:
RTE Contract phase
RTE Generation phase
One RTE is generated for each ECU in the system.
60
RTE Generation Process Contract Phase
RTE Contract phase a limited set of information
about a component, principally the AUTOSAR
interface definitions, is used to create an application
header file for a component type. The application
header file defines the contractbetween component
and RTE.
61
RTE Generation Process Contract Phase
RTE Contract Phase
.h
.XML .XML
Component
Type
Description
Atomic Software
Component
Type
Component
Internal Behaviour
Description
[API Generation]
Internal
Behaviour
Generate
Component
API
Autosar
Component
API
Component
API
62
RTE Generation Process Legenda
Legenda
Work Product
is a piece of information or physical entity produced by or used by an activity.
e.g. XML-Document, c-Document, obj-Document, or h-Document.
Activity
describes a piece of work performed by one or a group of
persons
Guidance: represent additional information or tools that are to be
used to perform the activity.
Flow of Work Product: is used to identify
the input and output of an activity.
Dependency
indicates that one workproduct depends on another work product.
It is a unidirectional.
63
RTE Generation Process Generation Phase
RTE Generation Phase
.XML
Collection
of
Available
SWC
Implementation
Autosar
System
Configuration
Generator
.XML .XML .XML
.c
.h
Configure
System
Autosar
RTE
Generator
System
Configuration
Description:
System
Extract
ECU -
Specific
Information
ECU Extract
of
System
Configuration:
System
Configure
ECU
ECU
Configuration:
Description
Generate
RTE
RTE
header
RTE
Code
Autosar
ECU
Configuration
Editors
Edit
ECU
Configuration
64
RTE Generation Process Generation Phase
RTE Generation phase - all relevant information about
components, their deployment to ECUs and communication
connections is used to generate the RTE.
65
Application Layer - Agenda
Application Layer: structure overview
Software Component (SWC): overview, concept and types
SWC structure: Runnables Entities
SWC characterization: Ports, Interfaces, Data Element
Communication Models: sender receiver, client server
Application Layer
66
Application Layer Structure Overview
Microcontroller
Application Layer
AUTOSARRuntime Environment (RTE)
AUTOSAR
Interface
Sensor
Software
Component
Application
Software
Component
..............
AUTOSAR
Software
AUTOSAR
Interface
AUTOSAR
Interface
AUTOSAR
Interface
Application
Software
Component
Actuator
Software
Component
The Application Layer in Autosar Architecture is located above
the Autosar RTE and encloses the Application Software.
Inside Appplication Layer, we can observe that the software
architecture style changes from layered based(like for BSW)
to component style.
These components are called Software Component (SWC).
In particular we can find three different types of Software
component in Application Layer:
- Application Software Component
- Sensor Software Component
- Actuator Sofware Component
67
Software Component Concepts
An application in AUTOSAR consists of interconnected "Autosar Software Components".
Each AUTOSAR Software Component encapsulates part of the functionality of the application.
The AUTOSAR Software Component is a so-called "Atomic Software Component".
Atomic here means that the AUTOSAR Software Component cannot be distributed over several
AUTOSAR ECUs.
In AUTOSAR, applicationsoftware is conceptually located above the AUTOSAR RTE
Definition: AUTOSAR Software Componentis an atomic piece of software that
implements a complete or a part of an application, runs on the AUTOSAR
infrastructure, and can be mapped on an ECU.
An AUTOSAR software-component is defined by a type definition that defines the components
interfaces. A component type is instantiated when the component is deployed to an ECU. A
component type can be instantiated more than once on the same ECU in which case the
component type is said to be multiply instantiated.
68
Software Component Description and Implementation (1/3)
A development of an AUTOSAR Software Component therefore consists of :
a complete and formal Software Component Description which specifies howthe
infrastructure must be configured for the component
an implementation of the component, which could be provided as "object code" or
"source code".
AUTOSAR does not prescribe HOW an AUTOSAR Software Component should be implemented (for
example, whether the component is generated froma model or written "by hand").
Rather AUTOSAR prescribes everything that is needed to allowseveral AUTOSAR Software
Components to be integrated correctly in an infrastructure consisting of networked ECUs.
Describe and Implement an AUTOSAR Software Component
69
The AUTOSAR Software Component Description contains:
the operations and data elements that the software component provides and
requires (this is described using the AUTOSAR Port-Interface concept - described
in the following),
the requirements that software component has on the infrastructure (runnable
entities),
the resources needed by the software component (memory, CPU-time, timers
usage),
information regarding the specific implementation of the software component
(configuration parameters).
70
An implementation of an AUTOSAR Software Component fundamentally is
independent from:
the type of microcontroller of the ECU on which the AUTOSAR Software
Component is mapped,
the type of ECU on which the AUTOSAR Software Component is mapped (the
AUTOSAR infrastructure takes care of providing the software component with a
standardized viewon the ECU hardware such as the ECU input/output
periphery),
the location of the other AUTOSAR Software Components with which the
software component interacts (that is if these services or data elements are
provided fromcomponents on the same ECU or are coming fromcomponents that
run on a different ECU); the implementation of the software component therefore
also is network technology independent,
the number of times a software component is instantiated in a system or within
one ECU.
71
Software Component Types
Concept: Application Software consists of :
AUTOSAR application software-componentsthat are ECU and location
independent
AUTOSAR sensor-actuator componentsthat are dependent on ECU hardware
and thus not readily relocatable for reasons of performance/efficiency.
In general, the AUTOSAR infrastructure takes care of hiding the specifics of the microcontroller
(this is done in the MCAL, which is part of the AUTOSAR infrastructure running on the ECU) and the
ECU electronics (this is handled by the ECU-Abstraction which is also part of the AUTOSAR Basic
Software).
The AUTOSAR infrastructure does NOT hide the specifics of sensors and actuators.
The dependencies on a specific sensor and/or actuator are dealt with in
" Sensor/Actuator Software Component" , which is a special kind of "AUTOSAR
Software Component for sensor evaluation and actuator control.
72
Sensor/Actuator AUTOSAR SW Components
The Sensor/Actuator AUTOSAR Software Component is independent of the
ECU on which it is mapped but is dependent on a specific sensor and/or actuator for
which it is designed and therefore has strong relationship to local signals.
It has been decided to locate the Sensor/Actuator SW Components above the
RTE for integration reasons (standardized interface implementation and interface
description).
Because of their strong interaction with raw local signals they are not relocatable
in most cases. Thus, because of performance issues, such components will need to
run on the ECU to which the sensor/actuator is physically connected.
Tasks and interfaces are similar to that of a Complex Driver.
Conclusions for Sensor/Actuator AUTOSAR SW Components
73
Sensor/Actuator AUTOSAR SW Components - Example
Examples of tasks of a Sensor/Actuator Component are switch debouncing,
battery voltage monitoring, DC motor control, lamp control etc.
For example, a "Sensor Component" typically inputs a software representation
of the electrical signal present at an input-pin of the ECU (e.g. a current
produced by the sensor) and outputs the physical quantity measured by the
sensor (e.g. the current car speed).
The following slide shows the typical conversion process fromphysical
signal to software signal (e.g. car velocity) and back, fromsoftware
signal to physical signal (e.g. car light).
74
Sensor/Actuator AUTOSAR SW Components - Example
Sensor
ECU
Electronics
C
Peripherals
Example
Car Velocity
Phisycal Interface Electrical Interface:
I
sensor
[0..200]mA
Hardware
Sensor
Component
Actuator
Component
Actuator
ECU
Abstraction
MCAL
(HAL Driver)
Software
Hardware
ECU
Electronics
C
Peripherals
Electrical Interface:
U
ECU
[0..5]V
Application
SWC 1
Application
SWC 2
Example
Car Light
get_v() get_I_ECU(velocity sensor)
set_lamp() set_I_ECU(light_actuator)
DIO_get()
DIO_set()
I
ECU
[0..2]A U
C
[0..5]V
HW/phys. signal Require Port Provide Port API
75
Application Layer Structure
Runnable Entities
Definition2: Runnable Entities are the smallest code fragments that are
provided by AUTOSAR SWC (and those basic software modules that implement
AUTOSAR interfaces, that are Services, ECU Abstraction and Complex Device
Drivers) and are executed in the context of an OS task.
Remind: AUTOSAR SW-Cs have no direct access to the OS and hence there
are no tasksin an AUTOSAR application.
Concept: Instead, inside AUTOSAR SW-Cs, the related activity is based
around runnable entities that are invoked by the RTE.
Definition1: Runnable entities are the schedulable parts of SW-Cs.
They are mapped to tasks by the RTE (through the RTE Generation process)
and are activated/triggered by the RTE as a result of RTEEvents.
76
Application Layer Communication
Ports Interfaces Data Elements
A component has well-defined ports, through which the component can interact with
other components.
Port: is the interaction point between the component and other components.
Each SW-Component is providing and/or requiring ports to communicate with other
SW-Components.
This communication can only occur via the components ports.
To define the services or data that are provided on or required by a port of a
component, the AUTOSAR Interface concept is introduced.
Interface: a Port Interface characterizes the information provided or required by
a port of a component.
The Elements that contribute to create the Interface contents are called Data
Element
Data Element: Any interface can contain a certain number and type of data
77
Communication Models
Consequently each SWC Port can be categorized through its interface by these
two communication models:
sender-receiver interface that provides a signal passing facility
client-server interface provides function invocation.
Two communication patterns are supported by AUTOSAR:
Client-Server and Sender-Receiver.
The specification what information sender-receiver communication transports
and which services with which arguments can be called by client-server
communication is done by interfaces.
The detailed behavior of a basic communication pattern is specified by
attributes.
The RTE provides the implementation of these communication patterns.
Concepts for Communication Models:
78
Communication Models: Client-Server
In the client-server pattern the server is a provider of a service and the client is a user of a service.
The client initiates the communication, requesting that the server performs a service, transferring a
parameter set if necessary.
The server waits for incoming communication requests froma client, performs the requested
service and (if needed) dispatches a response to the clients request.
So, the direction of initiation is used to categorize whether an AUTOSAR Software Component is a
client or a server.
A single component can be both a client and a server depending on the software realization.
The client can be blocked
(synchronous
communication) respectively
non-blocked (asynchronous
communication) after the
service request is initiated
until the response of the
server is received.
AUTOSAR
SW-C
client1
AUTOSAR
SW-C
client2
AUTOSAR
SW-C
server
Service_requested
Service_provided
Service_requested
79
Communication Models: Sender-Receiver
The sender-receiver pattern gives solution to the asynchronous distribution of information where
a sender distributes information to one or several receivers.
The sender is not blocked (asynchronous communication) and neither expects nor gets a
response fromthe receivers (data or control flow), i.e. the sender just provides the information
and the receivers decides autonomously when and howto use this information. It is the
responsibility of the communication infrastructure to distribute the information.
The sender component does not knowthe identity or the number of receivers to support
transferability and exchange of AUTOSAR Software Components.
send_information
receive_information
AUTOSAR
SW-C
sender
AUTOSAR
SW-C
receiver1
AUTOSAR
SW-C
receiver2
receive_information
80
Communication Models: Sender-Receiver Classification
With Sender-Receiver Communication Model is possible the following
classification:
Implicit data access
Explicit data access
These are called Modes of communication
A further classification with other two principles can be done inside Explicit
data access Mode:
Data Distribution
Event Distribution.
Related to this classification is introduced the concept of queue
Note: Implicit Mode can be considered a Data Distribution
Sender-Receiver Classification:
81
Sender-Receiver Communication: Implicit Mode
Implicit data access reception and transmission means that a
runnable does not actively initiate the reception or transmission of data.
Instead, the required data is received automaticallywhen the
runnable starts (invoked by the RTE that automatically reads a
specified set of data elements) through the usage of a local copy
Local Copy remains constantduring all the execution of the runnable:
this makes Implicit Mode safer but, on the opposite, more expensive
fromthe point of viewof resources (RAM usage)
In a similar way data is made available for other runnables at the
earliest when the runnable terminates (again by the RTE that
automatically writes - a different - set of data elements)
82
Sender-Receiver API Call for Implicit Mode
Implicit DataReadAccess
API name prototype:
Rte_IRead_<Runnable>_<PortPrototype>_<DataElementPrototype>
For the implicit reading of data, called DataReadAccess, the data is made available when
the runnable starts using the semantics of a copy operation and the RTE ensures that the
copy will not be modified until after the runnable terminates.
Implicit DataWriteAccess
API name prototype:
Rte_IWrite_<Runnable>_<PortPrototype>_<DataElementPrototype>
Implicit sending, called DataWriteAccess, is the opposite concept. Data elements marked
as DataWriteAccess are sent by the RTE after the runnable terminates.
The sending is independent from the position in the execution flow in which the API call is
performed inside the Runnable. When performing several write accesses during runnable
execution to the same data element, only the last one will be recognized.
API calls for Sender Receiver Implicit Mode
83
Sender-Receiver Communication: Explicit Mode
Explicit data access reception and transmission means that a runnable
employs an explicit API call to send or receive certain data elements.
For reception the RTE generator creates an API call to enable the receiver to
poll (and read) data.
This send-receive mode is an explicitmode since an explicit API call is
invoked respectively by the sender-receiver.
84
Sender-Receiver Explicit: Data and Event Distribution
With Sender-Receiver Explicit communication there are two main principles:
Data Distribution and Event Distribution.
When data is distributed, the last received value is of interest (last-is-best
semantics).
When events are distributed the whole history of received events is of
interest, hence they must be queued on receiver side.
Therefore an is-Queued attribute of the data element is used to distinguish
between Data and Event Distribution.
If a data element has event semantics, the isQueued attribute is set to true, if
the data element has data semantics, the isQueued attribute is set to false.
85
Sender-Receiver Explicit: Data and Event Distribution
Last-is-Best-Semantics for data Reception
On the receiver side, the buffering of data (isQueued =false) shall be realized
by the RTE by a single data set for each data element instance.
The use of a single data set provides the required semantics of a single element
queue with overwrite semantics (new data replaces old).
When new data is received, the RTE shall silently discard the previous value of
the data, regardless of whether it was read or not.
Queueing for event Reception
The application of event semantics implies a state change.
Events usually have to be handled. Usually, a loss of events can not be
tolerated.
Hence the isQueued attribute is set to true to indicate that the received events
have to be buffered in a queue.
The events shall be written to the end of the queue and read (consuming) from
the front of the queue (i.e. the queue is first-in-first-out).
86
Sender-Receiver API Call for Explicit Mode
Explicit Sending APIs call
APIs name prototype:
Rte_Send_<PortPrototype>_<DataElementPrototype>
Rte_Write_<PortPrototype>_<DataElementPrototype>
These two API initiate an explicitsending transmission of data elements and the
transmission occurs at the point the API call is made.
The Rte_Write API call is used for datasemantics (isQueued =false) and the
Rte_Send API call used for eventssemantics (isQueued =true).
API call for Sender Receiver Explicit Mode
Explicit Receiving APIs call
APIs name prototype:
Rte_Read_<PortPrototype>_<DataElementPrototype>
Rte_Receive_<PortPrototype>_<DataElementPrototype>
These two API performs an explicitread on a sender-receiver communication.
The Rte_Read API call is used for data element with datasemantics (isQueued =
false) while the Rte_Receive API call is used for data element with event
semantics (isQueued =true).
87
API Call Return_type
Std_ReturnType
For every kind of communication model (and related APIs call) a
standard API return type (Std_ReturnType) is defined.
The Std_ReturnType defines the status and error values returned
by API functions.
It is defined as a uint8 type. The value 0(RTE_E_OK) is reserved for
No error occurred.
Other values can have different error meanings, depending on the
communication mode to which the API is related (ex. RTE_E_INVALID,
RTE_E_NO_DATA, RTE_E_MAX_AGE_EXCEEDED, )
Standard Return Type for Communication API call
88
AUTOSAR Implementation Conformant Classes (ICC)
AUTOSAR CONFORMANCE CLASSES
89
AUTOSAR Implementation Cluster Conformance Classes Definition
An Implementation cluster is a collection of BSW modules
that is handled as one unit. The implementation of this cluster is
AUTOSAR conformant providing the following criteria are
satisfied:
The interface provided by a cluster shall be a subset of the
superset of the included modules. The subset shall be limited
to what is used by modules external to the cluster.
This means that the externally visible behavior at the border
of an implementation cluster shall be the same as if the
modules were not clustered.
This means that the externally visible configurability at the
border of an implementation cluster shall be the same as if the
modules were not clustered.
It shall be possible to exchange a lower ICC by an higher ICC.
90
AUTOSAR Conformance Classes - definitions
Conformance class
A defined subset of properties from the
total possible set of properties.
The nature of conformance classes is such
that higher conformance classes are
supersets of the lower ones. Several
conformance class trees with different
properties are allowed.
The known definition of OSEK
conformance classes, which are feature
based, are extended for AUTOSAR in two
additional dimensions (configurability and
implementation clustering).
91
AUTOSAR Conformance Classes - Rationale
Conformance Classes shall add value to AUTOSAR by
Limiting the degrees of freedom, w.r.t. some system properties, (e.g.
tailored to different domains, products and HW platforms).
Limiting the complexity of the system, e.g. w. r. t. possible
combinations
Supporting efficient and standardized scalability of solutions.
A lower conformance class could be implemented more efficiently
than one aiming to cover more (e.g. memory, real time).
A lower conformance class can be implemented in a simpler way.
Support migration in a standardized way
Supports to define the scope of the conformance test cases (e.g.
integration test cases).
92
AUTOSAR Conformance Classes - Rationale
Without the Definition of Conformance Classes, AUTOSAR
might:
end up in a few proprietary/incompatible implementations
not be able to define the right scope for the conformance
test cases of sufficient test coverage
lack business opportunities for all partners
end up with different clustering between different parties,
which will lead to an evolution where we have nothing in
common
end up in non-standardized solutions to support migration
and business objectives
be useful only on micros with high performance.
93
AUTOSAR ICC Objectives
Primary objectives of ICCs
Ensure a standardized way of packaging modules, to
achieve optimization, business, migration, or reuse
objectives.
Ensure that the resulting interfaces of the cluster
implementations are common and standardized.
94
AUTOSAR Implementation-cluster Conformance
Classes (ICC)
3 ICCs proposed
ICC1 : RTE + BSW in one cluster
Can be used for migrating to AUTOSAR
Can be used to embed existing proprietary solutions
Offers the highest level of integration possibility
ICC2 : RTE + BSW bundled into about 10 separate clusters.
Maps existing solutions and clusters (e.g. CAN-Cluster
includes several modules)
Offers significant integration possibility
ICC3 : RTE + all BSW bundled modules in separate clusters
Maps full AUTOSAR module granularity, according to the
BSW module list .
95
Implementation Conformance Classes ICC3
Not all ICC3 modules are shown here
Complex
Drivers
Microcontroller
Microcontroller
Drivers
Memory Drivers I/O Drivers
I/O Hardware
Abstraction
Memory Hardware
Abstraction
Memory Services System Services
Onboard Device
Abstraction
Communication
Drivers
Communication
Hardware Abstraction
Communication
Services
Application Layer
P
o
r
t
A
d
c
D
i
o
P
w
m
I
c
u
R
a
m
T
s
t
C
a
n
F
l
s
W
d
g
L
i
n
M
C
U
F
r
C
o
r
e

T
e
s
t
G
p
t
S
p
i
MemIf
Driver
for ext.
I/O
ASIC
Driver
for ext.
ADC
ASIC
WdgIf
Tp
C
o
m
N
m
I
p
d
u
M
Nm
If
ext.
Drv
xxx Interface
Trcv.
NvM
F
iM
W
d
g
M
D
e
t
D
e
m
C
o
m
M
A
U
T
O
S
A
R

O
S
PduR
ICC3 module functional groups

I/O Signal Interface
E
a
F
e
e
D
lt
G
t
M
E
c
u
M
E
e
p
T
T
C
a
n
E
t
h
B
s
w
M
D
c
m
D
e
b
u
g
g
i
n
g
In a basic software which conforms to ICC3 all modules have to have the interfaces
and behavior as specified in the software specifications of the according modules
96
Com-
plex
Dri-
vers
ECU Hardware
Microcont
roller
Drivers
Memory
Drivers
I/O
Drivers
I/O HW
Abstract
.
Memory
HW
Abstract.
Memory
Services
System Services
Onboard
Device
Abstract.
COM
Drivers
COM HW
Abstract.
Communi
cation
Services
Application Layer
ICC 3: All modules as defined in the
BSW module list, together with the
RTE, must comply to the defined
interfaces.
This is the highest ICC of AUTOSAR.
ICC3 shall support the AUTOSAR
configuration methodology.
ICC3 is the superset of all features in
AUTOSAR.
The (bus-)communication of the ECU to the network shall be
conformant to the AUTOSAR specifications (e.g. Network
Management, Transport Layer, Communication Message
Format, Diagnostic).
97
MOST is currentl y not included
Complex
Drivers
*
Hardware
Abstractio
n
Application Layer
CAN
Com
Services
FlexRay LIN
O
S
IPDU
M
*
Watch-
dog
ECU Hardware
MemIf
EA Fee
P
O
R
T

D
r
i
v
e
r
A
D
C

D
r
i
v
e
r
D
I
O

D
r
i
v
e
r
P
W
M

D
r
i
v
e
r
I
C
U

D
r
i
v
e
r
R
A
M

T
e
s
t
CAN Driver
E
E
P
R
O
M

D
r
i
v
e
r
F
l
a
s
h

D
r
i
v
e
r
W
a
t
c
h
d
o
g

D
r
i
v
e
r
LIN Driver
M
C
U

D
r
i
v
e
r
FlexRay
Driver
C
o
r
e

T
e
s
t
G
P
T

D
r
i
v
e
r
S
P
I
H
a
n
d
l
e
r
D
r
i
v
e
r
COM
W
d
g
M
Me
mori
es
N
v
M
CAN
Interface
FR Interface
LIN
Interface
LIN
NM
F
R
T
P
FR
NM
CAN
TP
CAN
NM
Diagnosti
cs
Mode
Ecu
M
N
M

I
f
CAN St
Mgr
FR St
Mgr
LIN St
Mgr
IPD
UM
C
o
m
M
C
A
N

T
r
a
n
s
c
e
i
v
e
r
F
l
e
x
R
a
y
T
r
a
n
s
c
e
i
v
e
r
Debu
g
D
e
t
Wdg
If
F
I
M
D
E
M
D
C
M
PDU Router
ICC3 module ICC2 clusters
D
e
b
u
g
g
i
n
g
B
s
w
M
In ICC2 the modules can be clustered. The intention is optimization through reduction of interfaces between modules.
AUTOSAR is currently not restricting the clustering on ICC2 level to dedicated clusters as different constraint and
optimization criteria might lead to different ICC2 clustering. There might be different AUTOSAR ICC2 clustering
against which compliancy can be stated based on a to be defined approach for ICC2 conformance.
Example
98
AUTOSAR ICC 2
Complex
Drivers
ECU Hardware
Application Layer
CAN
Communicatio
n Services
FR LIN
DCM OS
PDU
Mult
ECU Firmware
D
E
T
D
E
M
E
c
u
M
F
I
M
C
o
m
M
W
d
g
M
.
M
e
m
S
e
r
v
.
G
e
n
N
M
99
Proprietary software
Application Layer
ECU Hardware
In a basic software which is conformant to ICC1 no modules or clusters are required.
The inner structure of this proprietary basic software is not specified.
100
AUTOSAR ICC 1
The (bus-)communication of the ECU to the network shall be
conformant to the AUTOSAR specifications.
ECU Hardware
AUTOSAR RTE to SW component
and proprietary API to BSW
Application Layer
Proprietary Basic Software components
Proprietary APIs
AUTOSAR interface
Rte_Call_<BSWID>_<Operation>();
e.g.
Rte_Call_Dcm_SetEventStatus();
The interface to the application and the interface to the network shall be AUTOSAR
conformant.
101
Implementation Conformance Classes behavior to the
outside
Basic Software
Application Layer
ECU Hardware
ICC 3
conformant
behavior
For example the behavior
towards:
buses,
boot loaders and
applications
Whichever the conformance class is , basic software and the RTE which are Autosar
conformant (ICC1 3) have to behave to the outside as specified by ICC3.
102
ROADMAP AUTOSAR
103
Next Steps: Time plan of AUTOSAR phase III
104
FGA in AUTOSAR Consortium
Work Packages
Functional Safety
WPII-1.3
Body and Comfort
WPII-10.1
Powertrain
WPII-10.2
Chassis Control
WPII-10.3
Occupants and
Pedest. Safety
WPII-10.4
Methodology and
Configuration
WPII-1.2
Conformance Test
Specification
WPII-2.2
Software
Architecture
II-1.1
Software
Architecture
and OS
WPII-1.1.1
Vehicle and
Application
Mode Mgmt.
WPII-1.1.2
Debugging
WPII-1.1.3
Error Handling
WPII-1.1.4
COM Stack
WPII-2.1.1
FlexRay
WPII-2.1.2
MCAL
WPII-2.1.3
Diagnostics
WPII-2.1.4
Basic Software
II-2.1
Basic Software
Validation
WPII-3.1
MM / T / HMI
WPII-10.5
II-1
System
Architecture
II-2
SW and Test
Specification
II-3
Validation
II-5
Maintenance
of Releases
Communication
and Marketing
WPII-4.2
Follow-up
Organization
WPII-4.3
II-4
Enabling
Exploitation
Coordination of
Appl. Interfaces
WPII-10.0
Problem
Management
WPII-5.1
Change and
Release Mgmt.
WPII-5.2
Maintenance of
Specifications
WPII-5.3
Methodology
Validation
WPII-3.2
II-10
Application
Interfaces
Libraries
WPII-2.1.5
VFB and RTE
WPII-1.1.5
FGA starts working in AUTOSAR consortium as Premium Member at the end of 2004 with 10 active and
passive members in some Work Packages.
Active Members
Passive Members
105
ROADMAP FGA
106
FGA AUTOSAR Strategy
+
30%
70%
SWCs in-housedevelopment in Body
Electronics, Infotainment, Climate Control
and Chassyenvironment.
SWCs reuse and standardization in many
car projects
Management of some BSW stacks:
Communication
Diagnosis
Centralized development of cited BSW stacks
Centralized distribution of cited BSW stacks
Optimization of validation phases
100% AUTOSAR compatibilityfor some ECU
Application Software
Basic Software
107
AUTOSAR ICC in FGA
108
AUTOSAR Implementation-cluster Conformance
Classes (ICC) in FGA
Fiat has defined 4 types of ECU for migration to AUTOSAR
Class A ECU: ICC3 AUTOSAR .
Class B ECU: NM e DIAG AUTOSAR, RTE.
Class C ECU: NM e DIAG AUTOSAR
Class D ECU: no AUTOSAR (ECU not on CAN bus, LIN Slave).
109
CAN-BUS
Motivation first step:
To bring an existing, non AUTOSAR- ECU to AUTOSAR conformant by using the AUTOSAR methodology with ICC1:
1st having an AUTOSAR conformant application (SW-C port interfaces) and 2nd having AUTOSAR conformant system-wide
network-communication
A migration path from NON-AUTOSAR conformant ECUs
to AUTOSAR-conformant ECUs. Small 2 architecture First step 2012
ECU Hardware
Application Layer
ProprietaryBasic Software components
ProprietaryAPIs
e.g.
C
o
m
-
pl
ex
Dr
i-
ve
rs
Microc
ontroll
er
Drivers
Memor
y
Drivers
I/O
Drive
rs
I/O
HW
Abstr
act.
Memory
HW
Abstract
.
Memor
y
Servic
es
System
Services
Onboard
Device
Abstract
.
Application Layer
Comm
unicati
on
Servic
es
ECU Hardware
COM HW
Abstract
.
COM
Drivers
C
o
m
p
l
e
x
D
ri
v
e
r
s
ECU Hardware
I/O Hardware
Abstraction
Application Layer
C
A
N
Com
muni
catio
n
Servi
ces
FR L
I
N
D
C
M
O
S
P
D
U
M
u
l
t
ECU Firmware
D
E
T
D
E
M
E
c
u
M
F
IM
C
o
m
M
W
d
g
M
.
M
e
m
S
e
r
v
.
G
e
n
N
M
CAN-BUS
110
CAN-BUS
A migration path from NON-AUTOSAR conformant ECUs
to AUTOSAR-conformant ECUs. Small 2 architecture Step after 2012
ECU Hardware
Application Layer
ProprietaryBasic Software components
ProprietaryAPIs
e.g.
C
o
m
-
pl
ex
Dr
i-
ve
rs
Microc
ontroll
er
Drivers
Memor
y
Drivers
I/O
Drive
rs
I/O
HW
Abstr
act.
Memory
HW
Abstract
.
Memor
y
Servic
es
System
Services
Onboard
Device
Abstract
.
Application Layer
Comm
unicati
on
Servic
es
ECU Hardware
COM HW
Abstract
.
COM
Drivers
Motivation next step:
Using existing BSW-solutions (e. g. clustered CAN-stack).
Adopt existing BSW-modules to ICC2 conformant interfaces of the AUTOSAR-layered architecture
again having AUTOSAR conformant SW_C and again AUTOSAR conformant system-wide network-communication
B-CAN
LIN
C-CAN
DLC gateway
BCM
TERM
Diagnostic Link Connector
Class A
Class D
Class C
Class B
111
AUTOSAR: Application SW development
Body Computer - FGA Software Modules
0
2
4
6
8
10
12
2007 2008 2009 2010
SOP
N

M
o
d
u
l
e
s
Small
Compact
Florence
AUTOSAR Body Computer Project
6 SW modules nowadays in production,
including Alfa D.N.A.and Stop&Start
11 SW modules in production fully
operational(2010)
14 SW modules involved on 3
architectures
81% of application software developed by
FGA fullyoperational
100% reuse of software deliberato
80% minimum reuse in different cars
Future developments on different systems/environments
3 modules in Chassis Control Systems environment
Instrument Panel Cluster: an enquiry is going on with Suppliers
Climate Control System: possible synergy with already developed SW modules by Interiors
112
Autosar Concepts Application:
Example of FGA Software Factory Activity
Application Layer: FGA Sw Factory Activity overview
Functionality SWC Decomposition: example
Software Component Configuration Document (SWCC):
contents analysis
Autosar API call: generated code fragment analysis
Autosar Concepts
Application
113
FGA SW Factory: AUTOSAR Body ComputerProject
Microcontroller
Application Layer
AUTOSARRuntime Environment (RTE)
AUTOSAR
Interface
Sensor
Software
Component
Application
Software
Component
..............
AUTOSAR
Software
AUTOSAR
Interface
AUTOSAR
Interface
AUTOSAR
Interface
With Model Based Design methodology (MBD), Application
modules related to BodyComputer functionalities are developed.
Each Application SW Component (SWC) realize a (part of)
fuctional algorithm.
Each AUTOSAR SWC communicates with other
functionalities/components and with Basic Layer (BSW) services
via RTE layer necessity of interfaces standardization
Application
Software
Component
Actuator
Software
Component
FGA Sw Factory develops Sw for Application SWCs
114
Application SW : FGA SW Factory Activity
Development Cycle and Traceability
Requirements
Requirements Analysis
Architecture
Functionality Sub-Systems Definition
Interface Specifications
Project Planning
Configuration Management Req.Tracking Defect Tracking
Model Based Design
Simulink/Stateflow Model Implementation
Auto Coding
C Code Automatic Generation
Code Validation
Software in the Loop (SIL) test (Automatic)
Model Validation
Model in the Loop (MIL) test (Manual/Automatic)
SwQuality Assurance
115
Autosar Architecture Use-Case: Exterior Light Management
LowBeamLight activation
ECU-Hardware (Microcontroller)
Microcontroller Abstraction (MCAL)
check_switch()
switch_event
(event)
Switch Event Light Actuator
............
Application
Software switch_event(event)
request_light
(type, mode)
request_light(type, mode)
get_keyposition()
set_light(type,mode)
set_dboard(type,mode)
set_light(type,mode)
set_current()
Light_Request MainLight Manager
Operating
System
S
t
a
n
d
a
r
d
i
z
e
d

i
n
t
e
r
f
a
c
e
Standardized Interface
DIO PWM
SPAL
ECU
Abstraction
set_current()
ECU
Abstraction
Standardized
Interface
COM
Driver
Autosar
Interface
Complex
Device
Driver
B
S
W
S
t
a
n
d
a
r
d
i
z
e
d
get_keyposition()
set_dboard(type,mode)
HW dependent services
Autosar
Interface
HW
dependent
services
Autosar
Interface
H
W
I
n
d
e
p
e
n
d
e
n
t
s
e
r
v
i
c
e
s
Autosar
SWC

116
Functional Requirements detailed analysis (database Doors ) possible
modification to make themstronger (RAR: Requirements Analysis Report)
Requirements Classification (RAC: Requirements Analysis Classification)
Architectural choice for application level: functionality Decomposition into one or
more SWCs corresponding simulation models
(ex. for ExteriorLight functionality we have 3 SWCs: MainLight, (ex. for ExteriorLight functionality we have 3 SWCs: MainLight, StopLight, BlinkLight) StopLight, BlinkLight)
Interface Definition between different SWCs and RTE level (included Timers
definition): fundamental document shared with ECU supplier (that is also Application
SW integrator) SW SW Component Component Configuration Configuration
Requirements Analysis and
functionality SWC decomposition
Functional
Requirements
Database
SWComponent SWComponent
Configuration Configuration
RTE
Application
Interface
Application
Software
Component
117
Official Autosar Decomposition-Chart Exterior Light (1)
Exterior Light
Manager
(LiMgr)
not not further further
broken broken
down down
L
i
g
h
t
S
e
n
s
o
r
HomeCmngAndHomeLvngReq1
HomeCmngAn
dHomeLvng
H
M
I
LiExtReq1
SwtLiAut
SwtLiAut
SwtLiPosn
LiExtReq1
SwtLiPosn
broken broken
down down
CHLH Adapter
(AdprHome
CmngAnd
HomeLvng)
SwtHomeCmngAndHomeLvng
DoorSts1
[DOOR]Sts
LockgFbReq1
LockgFb
CarFindrReq1
CarFindr
OutdBriSts1
OutdBri
PrkgLiSwt
PrkgLiExtReq1
PrkgLiSwt
SwtFlashBeam
LiExtReq1
SwtFlashBeam
SwtBeamLo LiExtReq1
SwtBeamLo
SwtBeamHi
LiExtReq1
SwtBeamHi
SwtFogLiFrnt
LiExtReq1
SwtFogLiFrnt
OperModSts1
C
l
a
m
p
C
o
n
t
r
o
l
GearAct
OperMod
LiExtReq1
SwtFogLiRe
SwtFogLiRe
HomeCmngAn
dHomeLvng
PrkgLiRiOut
PlateNrOut
BeamLoOut
LiExtCmd1
LiExtCmd1
LiExtCmd1
BeamHiOut
LiExtCmd1
RvsgOut
LiExtCmd1
SideMkrOut
LiExtCmd1
FogFrntOut
LiExtCmd1
PrkgLiIndcn
PrkgLiDispExt1
BeamLoIndcn
ExtrLiDisp1
FogReOut
LiExtCmd1
FlashBeamOut
LiExtCmd1
PuddleLiLeOut
LiExtCmd1
PuddleLiRiOut
LiExtCmd1
CornrMkrLeOut
LiExtCmd1
CornrMkrRiOut
LiExtCmd1
R
e
m
o
t
e
K
e
y
CarFindr
[DOOR]Sts
C
e
n
t
r
a
l
L
o
c
k
i
n
gLockgFb
FogIndcnRe
ExtrLiDisp1
FogIndcnFrnt
ExtrLiDisp1
LiDaytiRunngIndcn
ExtrLiDisp1
FlashBeamIndcn
ExtrLiDisp1
BeamHiIndcn
ExtrLiDisp1
LiOnWarn LiOnWarnReq1
SwtHomeCmngAndHomeLvng LiExtReq1
OutdBri
Autolight
Adapter
(LiAdprAut)
OutdBri
SwtLiAut
Cornering
Adapter
(AdprCornrg)
WiprSts1
WiprFrnt
W
i
p
e
r
WiprStsFrnt
LiAutReq
LiAutReq
Oper
Mod
LiExtReq1
OperMod
broken broken
down down
OperMod
Gear1
P
o
w
e
r
t
r
a
i
n
GearAct
non non- -atomic atomic
SW SW- -C C
broken broken
down down
IndcrTurnReq1
SwtIndcr
OperMod
SwtIndcr
C
h
a
s
s
i
sVehSpdLgt1
VehSpdLgt VehSpdLgt
SteerWhlAg1
SteerWhlAgBas
SteerW
hlAgBas
LiExtReq1
SwtLiDaytiRunng
SwtLiDaytiRunng
CornrMkrReq CornrMkrReq
CornrMkrReq1
LiDaytiRunngOut
LiExtCmd1
PrkgLiLeOut
LiExtCmd1
HomeCmngAndHomeLvngOut
LiExtCmd1
H
M
I
PrkgLiIndcn
BeamLoIndcn
FogIndcnRe
FogIndcnFrnt
LiDaytiRunngIndcn
FlashBeamIndcn
BeamHiIndcn
t
o

A
d
a
p
t
e
r

S
W
-
C
s
Chimer
LiDimGlb
LiDimGlbCmd1
I
n
t
e
r
i
o
r
L
i
g
h
t
LiDimGlb
OutdBri
AcvnOfWshrFrnt WshrFrnt
WshngCmd1
HomeCmngAn
dHomeLvng
EgyMngt
EgyMngtSts1
OutdBri
Port Name:
SwtBeamLo
LowBeamSwitch
Interface Name:
LiExtReq1
ExternalLightRequest
(data element: On-Off type)
Interface Name:
LiExtCmd1
ExternalLightCommand
(data element: On-Off type)
Port Name:
BeamLoOut
LowBeamOut
FGA Sw Factory
develops Sw inside this
non-Atomic SWC
focus on LowBeam activation
118
broken broken
down down
Flash
Manager
(FlashMgr)
H
M
I
IndcrTurnReq1
SwtIndcr SwtIndcr
SwtForHzrdWarn
LiExtReq1
SwtForHzrdWarn
Crash
OperMod
IndcrTurnCmd1
IndcrPat
IndcrPatCmd1
E
n
e
r
g
y
M
a
n
a
g
e
m
.
Crash
EgyMngtSts1
EgyMngt
EmgyBrk
TrlrIndcrDisp1
broken broken
down down
BrakeLight Manager
(BrkLiMgr)
BrkLiOnReqFromChassis
BrkPedlPsd
BrkLiInten
BrkLi
LiExtCmd1
BrkInten
LiExtReq1
BrkLiOnReq1
BrkPedlPsd1
BrkLiInten1
IndcrOut
C
h
a
s
s
i
s
non non- -atomic atomic
SW SW- -C C
EmgyBrk
C
l
a
m
p
C
o
n
t
r
o
l
OperMod
S
a
f
e
t
y
CrashSts1
BrkLiOnReqFromChassis
BrkLiInten
BrkPedlPsd
OperModSts1
OperMod
TrlrIndcrDisp
H
M
I
TelltaleActivation
TelltalePattern
t
o

A
d
a
p
t
e
r
S
W
-
C
s
VehSpdLgt
AbsCtlAcv1
VehSpdLgt
AbsCtlAcv AbsCtlAcv
VehSpdLgt1
EgyMngt
FltOf
[ExtrLiActr]
F
r
o
m
I
n
d
i
c
a
t
o
r
A
c
t
u
a
t
o
r
S
W
-
C
s
LiExtCmd1
LockgFbReq1
AlrmVisCmd1
C
e
n
t
r
a
l
L
o
c
k
i
n
g
LockgFb
LockgFb
A
n
t
i
T
h
e
f
t
W
a
r
n
i
n
g
S
y
s
t
e
m
AlrmVis
AlrmVis
TrlrSwt
TrlrSts1
AAct1
VlcAAct
AlrmSts1 AlrmSt
AlrmSt
LockSts1
[Door]LockSt
Door]LockSt
VlcAAct
TrailerIndicator
Display
TrlrSts
TrlrSts1
FGA Sw Factory
non-Atomic SWCs
- StopLights SWC
- BlinkManager SWC
119
LiFltSts1
ExtrLiBriCmd1
BatU1
Exterior
Light
Actuator
[ext_light]
actuator actuator SW SW- -C C
Acvn
Fault
U
ExteriorLight AdapterFront
broken broken
down down
ExteriorLight AdapterRear
broken broken
down down
ExteriorLight
AdapterTrailer
broken broken
down down
Light
Manager
BrakeLight
Manager
Flash
Manager
IndcrOut/ IndcrPat
BeamLo
BeamHi
SideMkr
FogFrnt
FlashBeam
LiDaytiRunng
PrkgLi
IndcrOut/ IndcrPat
LiDaytiRunng
PrkgLi
PlateNr
SideMkr
FogRe
Rvsg
CornrMkr
PuddleLi
HomeCmngAn
dHomeLvng
PuddleLi
HomeCmngAnd
HomeLvng
BrkLi
BrkInten
t
o

a
l
l
A
d
a
p
t
e
r
S
W
-
C
s
IndcrOut/ IndcrPat
LiDaytiRunng
PrkgLiRi
PlateNr
SideMkr
FogRe
Rvsg
BrkLi
BrkInten
AcvnOf
[ExtrLiActrFrntLe]
FltOf
[ExtrLiActr]
AcvnOf
[ExtrLiActrReRi]
FltOf
[ExtrLiActr]
AcvnOf
[ExtrLiActr]
FltOf
[ExtrLiActr]
U
Energy
Managem.
TrlrSts
C
h
a
s
s
i
s
TrlrSts
TrlrSts
HomeCmngAnd
HomeLvng
TrlrSts1
PrkgLiLe
FltOf[ExtrLiActr]
H
M
I
TrlrSwt
TrlrSwt
TrlrSts1
EgyMngt
EgyMngt
EgyMngt
EgyMngtSts1
PrkgLiRiOut
PlateNrOut
BeamLoOut
BeamHiOut
RvsgOut
SideMkrOut
FogFrntOut
FogReOut
FlashBeamOut
PuddleLiLeOut
PuddleLiRiOut
CornrMkrLeOut
CornrMkrRiOut
LiDaytiRunngOut
PrkgLiLeOut
HomeCmngAn
dHomeLvngOu
t
BrkLi
BrkInten
IndcrPat
IndcrOut
To be split up to FrntLe,
FrntRi, ReLe, ReRi, Trl
Note: ExteriorLightAdapters Front & Rear
each always with 2 instances Left & Right
Port Name:
BeamLoOut
LowBeamOut
FGA Sw Factory
non-Atomic SWC
120
In particular, focusing again the attention on LowBeamactivation, the
following contents are involved:
- Related RTETriggerEvents
- Related DataReceivePort
- Related DataSendPort
Inside the SW Component Configuration document SW Component Configuration document related to the Main Light
SWC, are collected all the information related to the implementation of this SWC,
like Runnable Entity definition, Interface definition, Timer Resources usage
Definition and Analysis of SWCC document main contents
SWComponent SWComponent
Configuration Configuration
Foglio di lavoro di
Microsoft Excel
121
In particular, focus on LowBeam activation involves the following code
lines in file elgmlm_re.c(file for MainLight Runnable entity)
/*Typedef definition*/
typedef struct t_ff_req_main_light_tag {
Boolean MainLightCmd_Fault;
UInt8 MainLightCmd;
}t_ff_req_main_light; /* Record Typedef */
/*Local variable definition*/

t_ff_req_main_light ff_req_main_light;
/*Example of SenderReceiver Explicit Read (Data distribution with Std Return Type usage)
/*call of function: asr_elgmlm_swc/elgmlm_re/ASR_MainLightCmd_ReturnType_BLOCK/Rte_Function1*/
Rte_Read_Status_a = Rte_Read_ff_req_main_light_ff_req_main_light(&(ff_req_main_light));
/* usage of signal content just read */
Aux_B_c =ff_req_main_light.MainLightCmd ==LowBeamSwitch;
/* usage of Std Return Type read */
Aux_B_i =Rte_Read_Status_a ==RTE_E_OK;
/*Example of SenderReceiver Explicit Write (data output) */
/* call of function: asr_elgmlm_swc/elgmlm_re/LowBeamOut_ON_DATA_CHANGE/Rte_Function1 */
Rte_Write_af_cmd_low_beam_af_cmd_low_beam(Celgmlm5_LowBeamOut);
Generated Code Fragment Analysis
Example of SenderReceiver Explicit Read (Data distribution with Std Return Type usage)
/*call of function: asr_elgmlm_swc/elgmlm_re/ASR_MainLightCmd_ReturnType_BLOCK/Rte_Function1*/
Rte_Read_Status_a = Rte_Read_ff_req_main_light_ff_req_main_light(&(ff_req_main_light));
Std_Return_Type
Rte_Read_<PortPrototype>_<DataElementPrototype>
Data_Contents
122
Other examples of communication in file elgmlm_re.c
(file for MainLight Runnable entity)
/*Example of SenderReceiver Explicit Read (Event distribution with Std Return Type usage)
/* call of function: asr_elgmlm_swc/elgmlm_re/ASR_HighBeamCmd_ReturnType_BLOCK/Rte_Function1 */
Rte_Receive_Status_a =Rte_Receive_ff_req_high_beam_ff_req_high_beam(&(ff_req_high_beam));
Aux_B =ff_req_high_beam ==HighBeamSwitch;
/* usage of Std Return Type read */
Aux_B_a =Rte_Receive_Status_a ==RTE_E_OK;
/* Example of SenderReceiver Implicit Read
/* call of function: asr_elgmlm_swc/elgmlm_re/Rte_Function1 */
af_req_indicator =Rte_IRead_elgmlm_re_af_req_indicator_af_req_indicator();
/* Example of Client Call for asking a set of a signal
/* call of function: asr_elgmlm_swc/elgmlm_re/ACTIVITY_FLAG_LOGIC/Set_Activity_Flag/CP_elgm
lm_re_activity_flag_set_activity_flag */
Rte_Call_CP_elgmlm_re_activity_flag_set_activity_flag();
/* Example of Client Call and usage of Proxy parameter
Rte_Call_elgmlm_RearFog_Config_get_Proxi_par(&(RearFog_Configuration));
Aux_B_l =RearFog_Configuration ==Left_Fog_Light;
Aux_B_m =RearFog_Configuration ==Right_Fog_Light;
Generated Code Fragment Analysis
Example of SenderReceiver Implicit Read
af_req_indicator =Rte_IRead_elgmlm_re_af_req_indicator_af_req_indicator();
Data_Contents
Rte_IRead_<Runnable>_<PortPrototype>_<DataElementPrototype>
123
Questions, doubts?
124
Thank you!
Alessandra Mitidieri Costanza
Roberto Sobrito
alessandra.mitidieri@fiat.com
roberto.sobrito@fiat.com
+0039 011 0035423
+0039 011 0030382

AUTOSAR Basic Training PDF

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

AUTOSAR Basic Training PDF

Uploaded by

Copyright:

Available Formats

Alessandra Mitidieri C.

ICC3 module functional groups

AUTOSAR basic training

/Local variable definition/

You might also like