Professional Documents
Culture Documents
Massimo Violante
Politecnico di Torino
Dip. Automatica e Informatica
Torino, Italy
Outline
n Introduction
n ECU software architecture
n The AUTOSAR approach
n Software components
n AUTOSAR methodology
2
Outline
n Introduction
n ECU software architecture
n The AUTOSAR approach
n Software components
n AUTOSAR methodology
3
What is AUTOSAR?
n ww.autosar.org:
n “AUTOSAR (AUTomotive Open System ARchitecture) is
an open and standardized automotive software
architecture, jointly developed by automobile
manufacturers, suppliers and tool developers.“
n Consortium founded in 2003:
n BMW, DaimlerChrysler, Bosch, Continental, Volkswagen
and Siemens VDO
n Later Ford, General Motors, Toyota and PSA (Peugeot
Citroen) joined the consortium as core members
n The AUTOSAR standard will serve as a platform for
future vehicle applications
4
!"# $% &'()*&+,
What is AUTOSAR?
Introduction to AUTOSAR 5
5
!"# $%&'( )(($ *+,-.*/0
Why do we need AUTOSAR?
Increasing complexity of software in automotive
systems
n Increasing complexity of software in automotive
systems
There is no standardized software architecture
n There is no standardized software architecture
Control Units 40 60
MIPS 45 1150
MHz 85 2000
Transistors 21 m. 340 m.
(* without Infotainment)
Source: ElektronikNet.de http://www.elektroniknet.de/home/automotive/autosar/multiple-applikationen-in-steuergeraeten/
Introduction to AUTOSAR 6
6
Main drivers for AUTOSAR
n Management of E/E complexity associated with
growth in functional scope
n Flexibility for product modification, upgrade and
update
n Scalability of solutions within and across product
lines
n Improved quality and reliability of E/E systems
7
Main goals of AUTOSAR
n Fulfillment of future vehicle requirements:
n Availability and safety, SW upgrades/updates and
maintainability
n Increased scalability and flexibility to integrate and
transfer functions
n Higher penetration of "Commercial off the Shelf"
SW and HW components across product lines
n Improved containment of product and process
complexity and risk
n Cost optimization of scalable systems
8
AUTOSAR Software Components
n AUTOSAR is based on the concept of separation
between infrastructure and application
n Infrastructure: services providing an execution
environment to abstract hw details
n Application: vehicle functions of interest
n Application consists of interconnected software
components
n Atomic software component: a software component
can not be distributed over several ECUs
n AUTOSAR software component implementation is
independent from the infrastructure
9
Outline
n Introduction
n ECU software architecture
n The AUTOSAR approach
n Software components
n AUTOSAR methodology
10
Layered Software Architecture
!"#$%$&'()*+,"%$'-%./0+$.+1%$
11
Layered Software Architecture
!"#$%$&'()*+,"%$'-%./0+$.+1%$
Microcontroller
nMicrocontrollerAbstraction
AbstractionLayer:
Layer:
n lowest software
Lowest software layer
layer of
of the
the Basic
BasicSoftware
Software
Makes higher software independent of Microcontroller
n Makes higher software independent of Microcontroller
12
Layered Software Architecture
!"#$%$&'()*+,"%$'-%./0+$.+1%$
n ECU
ECUAbstraction
AbstractionLayer:
Layer:
nInterfaces
Interfaces the
the drivers
drivers of Microcontroller
MicrocontrollerAbstraction
Abstraction Layer
Layer
n Makes higher software layers independent of ECU
Makes higher software layers independent of ECU
hardware layout
hardware layout
n Offers access to I/O Signals
Offers access to I/O Signals
13
Layered Software Architecture
!"#$%$&'()*+,"%$'-%./0+$.+1%$
Service
nServiceLayer:
Layer:
n Highestlayer
Highest layerofofthe
theBasic
Basic Software
Software
Offers Memory Services, Diagnostic Services, ECU state
n Offers Memory Services, Diagnostic Services, ECU state
management
management
Provides basic services for application and basic
n Provides
softwarebasic services for application and basic software
modules
modules
AUTOSAR Software Architecture 17
14
Layered Software Architecture
!"#$%$&'()*+,"%$'-%./0+$.+1%$
RuntimeEnvironment:
Runtime
n Environment:
Middleware Layer
n Middleware Layer
Provides communication services for the application
n Provides
softwarecommunication services for the application
software
Makes AUTOSAR Software Components independent
n Makes AUTOSAR
from the mappingSoftware Components
to a specific ECU independent from
the mapping to a specific ECU
AUTOSAR Software Architecture 18
15
Layered Software Architecture
!"#$%$&'()*+,"%$'-%./0+$.+1%$
Application
n ApplicationLayer:
Layer:
n
“componentstyle”
“component
style”
Software components communicate with other
n Software components communicate with other
components and/or services via the RTE
components and/or services via the RTE
16
Layered Software Architecture
V2.2.1
R3.0 Rev 0001
Part 2 – Overview of Software Layers
Detailed view
ID: 02-03 Layered View: Detailed
Application Layer
Microcontroller
17
Outline
n Introduction
n ECU software architecture
n The AUTOSAR approach
n Software components
n AUTOSAR methodology
18
Standardization
n The software implementing the automotive
functionality is encapsulated in software
components
n Standardization of the interfaces is central to
support scalability and transferability of functions
n Any standard-conformant implementation of a
software component can be integrated with
substantially reduced effort in a system
19
AUTOSAR Architecture
SW-C
AUTOSAR architecture
SW-C SW-C SW-C
Description Description Description Description
AUTOSAR
AUTOSAR
AUTOSAR
AUTOSAR
SW-C n
SW-C 2
SW-C 1
SW-C 3
Virtual Functional Bus
System
ECU Deployment tools Constraint
Descriptions Description
AUTOSAR
AUTOSAR
AUTOSAR
SW-C n
SW-C 1
SW-C 2
SW-C 3
Gateway
20
AUTOSAR Architecture
!
AUTOSAR
!"#$%!&'%()
!"#$%!&'%()*
architecture
"#$% &'"()&*% )+,-./0$% 1+23+4$4-5 $46/3578/-$ /4
n Software component
/33896/-9+4 (SW-C)
.#96# 0745 +4% -#$% &'"()&*% 94,0/5-076-70$:% "#$%
n Encapsulate
&'"()&*%an);<1%
application
#/=$ that runs in the
.$88<>$,94$> AUTOSAR
94-$0,/6$5?% .#96# /0$%
infrastructure
>$5609@$> /4>%5-/4>/0>9A$>:%
! !"#
!"#$%&'()*+,-+./
$%&'()*+,-+./
n It has "#$
well-defined
%&'()*%'$+,-'. standard interfaces
,. /'00 ,. #%&'$ ,.1'-%. *''2'2 +#$ %&'()*%'3$,%)#* #+
n Interfaces and other aspects needed for integration,(.%,*2,$2(
%&'(4567849(8#+%/,$'(:#;1#*'*%.<(4567849(1$#=)2'. of
2'.-$)1%)#* +#$;,%(>8?@:(A'.-$)1%)#*BC
SW-C a standard description format is provided (SW-C
description) SW-C Description
AUTOSAR
SW-C 1
21
AUTOSAR Architecture
AUTOSAR architecture
! !"#$%&' (%)*$"+)&' ,%-./!(,0
"#$% &'(% )* +#$% *,-% ./ 011 2.--,3)20+).3 -$2#03)*-* 4035%
n Virtual Function Bus (VFB)
)3+$6/02$* +. +#$%70*)2 *./+806$9%:6.;)5$5 7< =>"?@=A%.3% 03
n Sum 4+$2#3.1.B<
07*+602+ of all communication mechanisms and
)35$:$35$3+9%1$;$1C%D#$3 interfaces to
+#$%2.33$2+).3*
/.6 the basic software
0% 2.326$+$% *<*+$-% provided by AUTOSAR
06$% 5$/)3$5E% on a technology
+#$% &'(% 011.8* 0% ;)6+,01
independent
)3+$B60+).3 level5$;$1.:-$3+ :#0*$C
)3%03 $061<
AUTOSAR
AUTOSAR
AUTOSAR
SW-C n
SW-C 1
SW-C 2
SW-C 3
22
AUTOSAR Architecture
AUTOSAR architecture
! !"#$%&'()*#$+,-*$
!"#$%&'()*#$+,-*$ ,*.'/(0'1%#2+-3$-)*#
,*.'/(0'1%#2+-3$-)*#
n System
"#$ %&'(& constraints
)% *#)(+&,)($and ECU description
-./01-2$ 1345%67%#(#)8 *#)% ,$
#()9%&:$ %; <5.8=$ -./01-2$ 7&%>*'(8 '(8?&*7)*%# ;%&6,)8 ;%&
n Description format for: system, ECU resources and
)@($8A8)(6$,8 9(BB ,8 ;%& )@($&(8%C&?(8 ,#'$)@($?%#;*+C&,)*%# %;
configuration
)@($<5.8D$
n Needed for deploying SW-C on a network of ECUs
System
ECU Deployment tools Constraint
Descriptions Description
23
AUTOSAR architecture
n Mapping on ECU
n Methodology
AUTOSAR and tool support
Architecture: for implementing
Mapping on ECUs SW-Cs
on ECUs, performing for each ECU configuration and
!"#$%!&'()*+,)- ./)'0)./1(12134 5,('.112 -67718. .1 96+2( 5'
generation of:-4-.)0' 1* ;<"-=' #/+- +,:26()- ./)' :1,*+3685.+1, 5,('
:1,:8).)'
3),)85.+1,' 1* ./)' &6,.+0) ;,>+81,0),. ?&#;@' ' 5,(' ./)' A5-+:
n Runtime Environment (RTE)
%1*.B58)'?&#$%@'1,')5:/ à it implements the VFB on
;<"= each
ECUC !"#$%&' (#)%*+#&'#$ ,!-(.
n Basic D810 ./)'>+)B71+,. 1* ./)'!"#$%!&'%1*.B58)'<1071,),.E'./)'
Software (RTOS
&#;'+072)0),.- services)
./)'FDA'*6,:.+1,52+.4 1,'5'-7):+*+: ;<"=
Deployment tools
ECU1
AUTOSAR
AUTOSAR
SW-C 2
SW-C 3
RTE
Basic Software
24
Outline
n Introduction
n ECU software architecture
n The AUTOSAR approach
n Software components
n AUTOSAR methodology
25
Software component
n It encapsulate part of the functionality of the
application
n AUTOSAR does not specify the granularity of SW-C
n It is an atomic software component à it is statically
assigned to one ECU
n AUTOSAR does not specify how the SW-C should be
implemented
n Handwritten/automatically generated from a model
26
SW-C description
n It contains:
n The operations and data elements that the software
component provides and requires à PortInterface
concept
n The resources needed by the software component
(memory, CPU-time, etc.),
n Information regarding the specific implementation of the
software component
27
SW-C implementation
n It is independent from:
n The type of microcontroller of the ECU and the type of
ECU on which the component is mapped
n The AUTOSAR infrastructure takes care of providing the software
component with a standardized view on the ECU hardware
n The location of the other components with which it
interacts. The component description defines the data or
services that it provides or requires. The component
doesn’t know if they are provided from components on
the same ECU or from components on a different ECU
n The number of times a software component is
instantiated in a system or within one ECU
28
SW-C description levels
n Virtual functional bus level
n RTE level
n Implementation level
29
SW-C description levels
n Virtual functional bus level
n Components are described with the means of
n Datatypes and interfaces
n Ports and connections between them
n Hierarchical components
n At this level, the fundamental communication properties
of components and their communication relationships
among each other are expressed
n AUTOSAR terms
n Port Interfaces and Ports
n Compositions
30
non-volatile memory (port “nv”).
SeatHeatingControl
Example SeatSwitch
n SeatHeatingControl HeatingElement
Setting
n Input: PowerManagement
Passenger is sitting
DialLED
n Calibration
n Output:
n DialLED associated to the seat temperature- AUTOSAR
dial Confidential -
11 of 78 Document ID 056:
n Heating element
n It can be calibrated, needs the status of the ECU on
which the component runs and requires access to local
non-volatile memory
31
Port Interface
n It defines the contract that must be fulfilled by the
port providing or requiring that interface
n Client-server: the server is provider of operations and
several clients can invoke those operations
n Sender-receiver: a sender distributes information to one
or several receivers, or one receiver gets information
(events) from several senders. A mode manager can
notify mode switches to one or several receivers
n Parameter Interface: it allows SW-C access to either
constant data, fixed data or calibration data
32
Port Interface
n Non volatile Data Interface: provide element level access
(read only or read/write) to non volatile data
n Trigger Interface: it allows software components to
trigger the execution of other software components
n Mode Switch Interface: the mode switch interface is used
to notify a software component of a mode. The mode
manager provides modes that can be used by mode
users to adjust the behavior according to modes or
synchronize activities to mode switches.
33
Client-server Virtual Functional Bus
V2.1.0
R4.0 Rev 2
Mode Switch The mode switch interface is used to Section 8
n A client-server interface defines a set of operations
Interface notify a software component of a mode.
<<ClientServerInterface>>
HeatingElementControl
ApplicationErrors:
HardwareProblem
Operations:
SetPower(
IN ARGUMENTint32 Power,
POSSIBLEERROR=HardwareProblem)
34
The operation can return an application error called “HardwareProblem”.
Sender-receiver
<<ClientServerInterface>>
HeatingElementControl
ApplicationErrors:
HardwareProblem
n Example
Figure 3.4: Example of a client-server interface “HeatingElementControl” with
a single operation
nSimple sender-receiver interface called “SeatSwitch”
containing a single data-element called
A sender-receiver interface defines a set of data-elements that are sent and received
“PassengerDetected”
over the VFB. Figure 3.5 shows the definition of a simple sender-receiver interface
called “SeatSwitch” containing a single data-element called “PassengerDetected”.
<<SenderReceiverInterface>>
SeatSwitch
DataElements:
boolean PassengerDetected
35
VFB004: At configuration time it is known whether the port-interface is a client-server
Ports
n The ports of a component are the interaction points
between components
n A port of a component is either a PPort or an Rport
n PPort provides the elements defined in a port-interface
n RPort requires the elements defined in a port-interface
n A port is thus typed by exactly one port-interface
36
Table 3.2 shows the port-icons for the various combinations and summarizes the
semantics of those ports.
Kind of Port
Port types
Kind of Interface Service
Port
Port-Icon and description
PPort sender-receiver No
Port types
R4.0 Rev 2
invokes) the operations defined in
the interfaces
PPort parameter (this No
includes
providing
calibration data)
The component provides parameter
data (either fixed, const or variable)
RPort parameter (this No
includes requiring
calibration data)
39
Port types
Virtual Functional Bus
V2.1.0
R4.0 Rev 2
Block Component
PPort Sender-receiver Yes
Port types
RPort Trigger No
Port types
Mode Switch user
PPort mode switch No
43
interface.
In the example of Figure 3.6, the component “SeatHeating” implements the operation
Example
“SetPower” and makes it available to other components through the port “Setting”.
The component “SeatHeatingControl” uses the operation “SetPower” and expects
such an operation to be available through the port “HeatingElement”.
SeatHeatingControl SeatHeating
Setting
SeatSwitch IO
HeatingElement
Setting
PowerManagement <<Interface>>
HeatingElementControl
DialLED Calibration ApplicationErrors:
HardwareProblem
nv ecuMode Operations:
SetPower(
IN ARGUMENTint32 Power,
POSSIBLEERROR=HardwareProblem)
45
Example Virtual Functional Bus
V2.1.0
R4.0 Rev 2
SeatHeatingControl
SeatSwitch
SeatSwitch
IO Switch
HeatingElement
Setting
<<Interface>> PowerManagement
SeatSwitch
DialLED Calibration
DataElements:
boolean PassengerDetected
nv ecuMode
46
Compositions
n Ports between components that need to
communicate with each other are hooked up using
assembly-connectors
n Such an assembly-connector connects one RPort
with one PPort
47
Example Virtual Functional Bus
V2.1.0
R4.0 Rev 2
SHCFrontLeft:
SeatHeatingControl
SeatSwitch
SHFrontLeft:
SHDialFrontLeft: SeatHeating
HeatingDial
HeatingElement
IO
Position Setting
PowerManagement
IO LED DialLED
Calibration
nv ecuMode PM:
PowerManagement
SeatHeating
SHCFrontRight:
SeatHeatingControl WindowDefrost
SeatSwitch
PowerStatus
SHDialFrontRight: PowerManagement
HeatingDial
Position Setting
Calibration SHFrontRight:
SeatHeating
IO LED DialLED HeatingElement IO
nv ecuMode
48
For the case of sender-receiver communication, the presence of an assembly-
connector represents the fact that the data generated by the PPort on the connector
Example Virtual Functional Bus
V2.1.0
R4.0 Rev 2
SHCFrontLeft:
SeatHeatingControl
SeatSwitch
SHFrontLeft:
SHDialFrontLeft: SeatHeating
HeatingDial
HeatingElement
IO
Position Setting
PowerManagement
IO LED DialLED
Calibration
nv ecuMode PM:
PowerManagement
SeatHeating
SHCFrontRight:
SeatHeatingControl WindowDefrost
SeatSwitch
PowerStatus
SHDialFrontRight: PowerManagement
HeatingDial
Position Setting
Calibration SHFrontRight:
SeatHeating
IO LED DialLED HeatingElement IO
nv ecuMode
The operation
Figure 3.8:
invoked ports ofover Position is
Example of the use of eight assembly-connectors to connect the
seven components
50
Runnables
n SW-C actual implementation consists of a set of
runnable entities (aka runnables”) Virtual Functional Bus
V2.1.0
R4.0 Rev 2
n A runnable
3.8.2 Theentity
“runnable”is a sequence of instructions
concept
SHCFrontLeft: SeatHeatingControl
Management
SeatSwitch
Calibration
ecuMode
Setting
Power
nv
RTE
Example
V2.1.0
R4.0 Rev 2
SHCFrontLeft: SeatHeatingControl
Implementation
MainCyclic Rte_Read_SeatSwitch_PassengerDetected()
Setting
Management
SeatSwitch
Calibration
ec uMode
Setting
Po wer
nv
RTE
52
Figure 3.15: Implementation-view on the interaction between an atomic software
component and the RTE on an ECU
Virtual Functional Bus
Example
V2.1.0
R4.0 Rev 2
SHCFrontLeft: SeatHeatingControl
MainCyclic Rte_Read_SeatSwitch_PassengerDetected()
Setting
Management
SeatSwitch
Calibration
ec uMode
Setting
Po wer
nv
RTE
53
Figure 3.15: Implementation-view on the interaction between an atomic software
component and the RTE on an ECU
Virtual Functional Bus
Example
V2.1.0
R4.0 Rev 2
SHCFrontLeft: SeatHeatingControl
Setting
Management
SeatSwitch
Calibration
ec uMode
Setting
Po wer
nv
RTE
54
Figure 3.15: Implementation-view on the interaction between an atomic software
component and the RTE on an ECU
Runnables
n A runnable entity runs as a task on the ECU
microprocessor
n The task provides the common resources to the
runnable entities such as a context and stack-space
n Typically the operating-system scheduler has the
responsibility to decide during run-time when which
task can run on the CPU (or multiple CPUs) of the
ECU
n There are many standard strategies that schedulers can
use (e.g. priority-based preemptive, round- robin, time-
triggered...).
55
RTEEvents
n Mechanisms through which the component’s
implementation (for example “C” functions) is
invoked:
n Fixed-time schedules (for example: many components
need to run “cyclically”)
n Events related to the communication mechanisms (for
example some components might want to be notified
upon the reception of data from other components)
n Events related to physical occurrences (i.e. a triggered
event)
56
SW-C description levels
n Implementation level
n For each runnable the corresponding behavior is defined
(as handwritten or automatically generated code)
n The requirements for the RTE are defined in terms of:
n Which runnables need to be called cyclically
n Which runnables need to be called in response to events related
to communication or other sources
n How the component would like to access the information in its
ports or invoke the operations that it requires from other
components
n Any other resources the component requires, such as AUTOSAR
services or local memory
57
VFB view
Virtual Functional Bus
V2.1.0
R4.0 Rev 2
VFB
SHCFrontLeft: SeatHeatingControl
Management
SHDialFrontL PM:
Calibration
eft: PowerManag
ecuMode
HeatingDial … ement
…
Power
…
IO 58
nv
…
…
ating ating
IO IO IO IO
… …
SHCFrontLeft: SeatHeatingControl
Management
SHDialFrontL PM:
Calibration
eft: PowerManag
ecuMode
HeatingDial … ement
…
Power
…
IO
nv
…
…
RTE1 RTE3
BSW1 BSW3
Figure 3.12 shows the standard component-view on the AUTOSAR layered software
architecture, which is the architecture of a single AUTOSAR ECU. The “AUTOSAR
Interface” of a component refers to the full set of ports of a component (as59defined
before, a port-interface characterizes a single port of a component). A “Standardized
Virtual Functional Bus
V2.1.0
R4.0 Rev 2
Implementation view
SHCFrontLeft: SeatHeatingControl
Management
SHDialFrontLeft:
Calibration
AUTOSAR
HeatingDial
ecuMode
Software
Power
nv
IO
RTE
IO
Standardized Standardized ECU Abstraction
ECU State
Manager
Communication
Standardized
Standardized
Interface
Interface
Operating
System
Standardized
Interface
Basic Software
Microcontroller
Abstraction
ECU-Hardware
60
Figure 3.13: Example showing the relationship between the components mapped
on an ECU and the ECU Software Architecture
Outline
n Introduction
n ECU software architecture
n The AUTOSAR approach
n Software components
n AUTOSAR methodology
61
AUTOSAR Methodology
AUTOSAR methodology
Design steps go from the system-level configuration to the
generation of an ECU executable.
n Design steps go from the system-level configuration
to the generation of an ECU executable
62
Methodology
n The System Configuration Input must to be defined
n The software components and the hardware are defined
and selected
n The overall system constraints are identified
n XML templates:
n Software Components: each SW-C requires a description
of the software API e.g. data types, ports, interfaces
n ECU Resources: specifications regarding the CPU,
memory, peripherals, sensors and actuators
n System Constraints: bus signals, topology and mapping
of SW-C
63
Methodology
AUTOSAR Methodology
n System Configuration Descriptions contains
Design steps go from the system-level configuration to
n The mapping of SW-C to of
generation ECU
an ECU executable.
n Bus topology
n Further steps have to be performed on each ECU
n Extract ECU-Specific Information extracts the
information from the system configuration
description for a specific ECU
64
Methodology
n Configure ECU configures:
n RTE
n Basic Software
n It generates:
n Task scheduling
n Required basic software modules
n Configuration of the basic software
n Assigment of runnables to tasks
n The ECU software can be built from this information
65
methodology
n The executable code for the ECU si generated:
n Code generation
n Code compilation
n Code linking
66
Parallel to these steps are several steps performed for every
Flow for each SW-C
application software component (to be integrated later into the
system), e.g. generating the components API, and implementing
the components functionality.
67
Parallel to these steps are several steps performed for every
Flow for each SW-C
application software component (to be integrated later into the
system), e.g. generating the components API, and implementing
the components functionality.
• List of runnables
• Definition of input-data/runnable
association
68
Parallel to these steps are several steps performed for every
Flow for each SW-C
application software component (to be integrated later into the
system), e.g. generating the components API, and implementing
the components functionality.
69
Parallel to these steps are several steps performed for every
Flow for each SW-C
application software component (to be integrated later into the
system), e.g. generating the components API, and implementing
theimplementation
Actual components functionality.
of the SW-C
resulting in:
• Component implementation (C code)
• Component Internal Behavioral
description (documentation)
• Component Implementation
Description (e.g. compiler settings,
optimizations, etc.).
70
Parallel to these steps are several steps performed for every
Flow for each SW-C
application software component (to be integrated later into the
system), e.g. generating the components API, and implementing
the components functionality.
71