AUTOSAR

Introduction to AUTOSAR
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
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
In a single car* 1994 2008
Control Units 40 60
MIPS 45 1150
MHz 85 2000
MCU-Storage (Program + Data) 1,1 MB+160 kB 19 MB+1,25 MB
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
10
Layered Software Architecture
!"#$%$&'()*+,"%$'-%./0+$.+1%$
AUTOSAR Software Architecture 14
11
!"#$%$&'()*+,"%$'-%./0+$.+1%$
Microcontroller
nMicrocontrollerAbstraction
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
!"#$%$&'()*+,"%$'-%./0+$.+1%$
n ECU
ECUAbstraction
AbstractionLayer:
Layer:
nInterfaces
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
!"#$%$&'()*+,"%$'-%./0+$.+1%$
Service
nServiceLayer:
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
14
!"#$%$&'()*+,"%$'-%./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
15
!"#$%$&'()*+,"%$'-%./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
V2.2.1
R3.0 Rev 0001
Part 2 – Overview of Software Layers
Detailed view
ID: 02-03 Layered View: Detailed
Application Layer
AUTOSAR Runtime Environment (RTE)

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

Abstraction Abstraction Hardware Abstraction
Microcontroller Drivers Memory Drivers Communication Drivers I/O Drivers
Microcontroller
Page 14 - AUTOSAR Confidential -
17
Outline
n Introduction
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
ECU1 ECU1 ECU1

AUTOSAR
AUTOSAR
AUTOSAR
AUTOSAR
SW-C n
SW-C 1
SW-C 2
SW-C 3
RTE RTE RTE

Basic Software Basic Software Basic Software
Gateway
20
!
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
! !"#$%&' (%)*$"+)&' ,%-./!(,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<
SW-C SW-C SW-C SW-C

Description Description Description Description
AUTOSAR
AUTOSAR
AUTOSAR
AUTOSAR
SW-C n
SW-C 1
SW-C 2
SW-C 3
22
! !"#$%&'()*#$+,-*$
!"#$%&'()*#$+,-*$ ,*.'/(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
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
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
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 Setting of the seat temperature nv ecuMode
n Information from a central power Figure

management
3.1:
system
Example of the definition of the component-type
“SeatHeatingControl” with eight ports
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.
that can be invoked by a client and implemented by

The mode manager provides modes that
can be used by mode users to adjust the
a server behavior according to modes or
synchronize activities to mode switches.
n ExampleTable 3.1: The kinds of port-interfaces provided by AUTOSAR.

n The interface “HeatingElementControl” defines a single
A client-server interface defines a set of operations that can be invoked by a client
andoperation
implemented called “SetPower”
by a server. withana example
Figure 3.4 shows single ofingoing
the definition of a
argument
simple called
client-server “Power”.
interface. The operation
The interface can return
“HeatingElementControl” an a
defines
single operation called “SetPower” with a single ingoing argument called “Power”.
Theapplication error
operation can return an called “HardwareProblem”
application error called “HardwareProblem”.
<<ClientServerInterface>>
HeatingElementControl
ApplicationErrors:
HardwareProblem
Operations:
SetPower(
IN ARGUMENTint32 Power,
POSSIBLEERROR=HardwareProblem)
34
The operation can return an application error called “HardwareProblem”.
Sender-receiver
<<ClientServerInterface>>
ApplicationErrors:
HardwareProblem
n A sender-receiver interface defines a set of data-

Operations:
SetPower(
elements that are sent and received over the VFB

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
Figure 3.5: Example of a Sender-Receiver Interface “SeatSwitch” with a single

data-element
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
The component provides values for

the data-elements
RPort sender-receiver No
The component reads or consumes

values for the data-elements
PPort client-server No
The component provides

(=implements) the operations
defined in the interface
RPort client-server No

V2.1.0
R4.0 Rev 2
The component requires (=uses or
invokes) the operations defined in 37
the interfaces
V2.1.0
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)
The component requires parameter

data (either fixed, const or variable)
PPort sender-receiver Yes
The component provides data-

elements and mode-groups to an
AUTOSAR Service
RPort sender-receiver Yes
The component reads/consumes

data-elements and mode-groups
from an AUTOSAR Service
PPort client-server Yes 38
Port types The component reads/consumes

data-elements and mode-groups
PPort client-server Yes
The component provides

(=implements) operations for an
AUTOSAR Service
RPort client-server Yes
The component invokes operations

A component requires access to non

volatile data provided by an NV
17 of 78 Document ID 056: AUTOSAR_EXP_VFB
- AUTOSAR Confidential -
39
Port types
V2.1.0
R4.0 Rev 2
Block Component
PPort Sender-receiver Yes
The NV Block Component provides

access to non volatile data
PPort Trigger No
Application component with trigger

source
RPort Trigger No

sink
RPort Trigger Yes
Service with trigger sink 40

PPort Trigger Yes
source
Port types
RPort Trigger No

sink
RPort Trigger Yes
Service with trigger sink

PPort Trigger Yes
Service with trigger source

RPort mode switch No
Mode Switch user

PPort mode switch No
Mode Switch manager

RPort mode switch Yes 41
Service with trigger source
RPort mode switch No
Port types
Mode Switch user
PPort mode switch No
Mode Switch manager

RPort mode switch Yes

V2.1.0
Mode Switch userR4.0 Rev 2
PPort mode switch Yes
18 of 78 Document ID 056: AUTOSAR_EXP_VFB
- AUTOSAR Confidential -
Mode Switch manager
Table 3.2: Semantics of the port-icons
When a PPort of a component provides a client-server interface, the component to

which the port belongs provides an implementation of the operations defined in the
interface.
In the example of Figure 3.6, the component “SeatHeating” implements the operation
42
“SetPower” and makes it available to other components through the port “Setting”.
Client-server
n When a PPort of a component provides a client-
server interface, the component provides an
implementation of the operations defined in the
interface
n Example:
n “SeatHeating” implements the operation “SetPower” and
makes it available to other components through the port
“Setting”
n The component “SeatHeatingControl” uses the operation
“SetPower” and expects such an operation to be available
through the port “HeatingElement”
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>>
DialLED Calibration ApplicationErrors:
HardwareProblem
nv ecuMode Operations:
SetPower(
Figure 3.6: Example showing the use of the Client-Server Interface

“HeatingElementControl” to type the Port ”HeatingElement” of the component
“SeatHeatingControl” and the port “Setting” of the component “SeatHeating”
44
Sender-receiver
n A component providing a sender-receiver interface
generates values for the data elements defined in
the interface
n Example:
n The component “SeatSwitch” generates values for the
Boolean value “PassengerDetected” through its port
“Switch”
n Similarly, the component “SeatHeatingControl” can read
the data-element “PassengerDetected” through its port
“SeatSwitch”
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
Figure 3.7: Example showing the use of the Sender-Receiver Interface

“SeatSwitch” to type the Port “SeatSwitch” of the components
“SeatHeatingControl” and the port “Switch” of the component “SeatSwitch”
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
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
DialLED is sent toExample

Figure 3.8:
LEDofports
the use of eight assembly-connectors to connect the
of seven components
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
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
requested to the server over the Setting port 49

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
n RTE level
n Component behavior is described in terms of:
n RTE events
n Schedulable units
n For instance, for an operation defined in an interface on
the VFB, the behavior specifies which of those units is
activated as a consequence of the invocation of that
operation
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
(provided bycannotthebe divided

component)
in smaller componentsthat
and must can
therefore be
The “atomicity” of an atomic software-component refers to the fact that the
component started by
be mapped
the Run-Time Environment

onto a single ECU.
For example, Figure 3.14 shows a logical component view of the mapped
application-software component “SHCFrontLeft” on a specific ECU. Through its ports,
the component expresses which information it requires from and provides to other
components.
SHCFrontLeft: SeatHeatingControl
Management
SeatSwitch
Calibration
ecuMode
Setting
Power
nv
RTE
Figure 3.14: Component-view on the interaction between an atomic software

component and the RTE on an ECU
51
However, the actual implementation of a component consists of a set of “runnable
8
Example
V2.1.0
R4.0 Rev 2
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
Example
V2.1.0
R4.0 Rev 2
Runnable invoked cyclically

Implementation
by the RTE
Setting
Management
SeatSwitch
Calibration
ec uMode
Setting
Po wer
nv
RTE
53
Example
V2.1.0
R4.0 Rev 2
Invoked when other SW-C

Implementation
requires “Setting” P-Port. It
will requires the RTE to
provide the data over Rport
“SeatSwitch”
Setting
Management
SeatSwitch
Calibration
ec uMode
Setting
Po wer
nv
RTE
54
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
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
V2.1.0
R4.0 Rev 2
SHDialFrontL SHCFrontLeft: HFront SHDialFront SHCFrontRight: HFront PM:

eft: SeatHeatingControl Left: Right: SeatHeatingControl Right: PowerManag
HeatingDial SeatHe HeatingDial SeatHe ement
ating ating
IO IO IO IO
… …
VFB
ECU1 ECU2 ECU3
Management
SHDialFrontL PM:
Calibration
eft: PowerManag
ecuMode
HeatingDial … ement
…
Power
…
IO 58
nv
…
…
ating ating
IO IO IO IO
… …
RTE view VFB
ECU1 ECU2 ECU3
Management
SHDialFrontL PM:
Calibration
eft: PowerManag
ecuMode
HeatingDial … ement
…
Power
…
IO
nv
…
…
RTE1 RTE3
BSW1 BSW3
Figure 3.11: Example illustrating the mapping of a composition of components on

three ECUs.
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
V2.1.0
R4.0 Rev 2
Implementation view
Management
SHDialFrontLeft:
Calibration
AUTOSAR
HeatingDial
ecuMode
Software
Power
nv
IO
RTE
IO
Standardized Standardized ECU Abstraction
ECU State
Manager
Interface Interface Component

Service
NvRam
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
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
Flow for each SW-C
• List of runnables
• Definition of input-data/runnable
association
68
Flow for each SW-C
The AUTOSAR Component API Generator reads the

Component Internal Behavior Description of the
appropriate software component and generates
the Component API accordingly. The Component
API contains all header declarations for the RTE
communication.
69
Flow for each SW-C
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
Flow for each SW-C
Compilation of SW-C in object code

• Compiled Component
• Component Implementation Description
(e.g. linker settings, entry point).
71

AUTOSAR

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

AUTOSAR

Enviado por

Direitos autorais:

Formatos disponíveis

Introduction to AUTOSAR

In a single car* 1994 2008

MCU-Storage (Program + Data) 1,1 MB+160 kB 19 MB+1,25 MB

AUTOSAR Software Architecture 14

AUTOSAR Software Architecture 15

AUTOSAR Software Architecture 16

AUTOSAR Software Architecture 19

AUTOSAR Runtime Environment (RTE)

Onboard Device Memory Hardware Communication

Microcontroller Drivers Memory Drivers Communication Drivers I/O Drivers

Page 14 - AUTOSAR Confidential -

ECU1 ECU1 ECU1

RTE RTE RTE

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

Virtual Functional Bus

n Setting of the seat temperature nv ecuMode

n Information from a central power Figure

that can be invoked by a client and implemented by

n ExampleTable 3.1: The kinds of port-interfaces provided by AUTOSAR.

n A sender-receiver interface defines a set of data-

elements that are sent and received over the VFB

Figure 3.5: Example of a Sender-Receiver Interface “SeatSwitch” with a single

The component provides values for

The component reads or consumes

The component provides

Virtual Functional Bus

The component requires parameter

The component provides data-

The component reads/consumes

Port types The component reads/consumes

The component provides

The component invokes operations

A component requires access to non

The NV Block Component provides

Application component with trigger

Application component with trigger

Service with trigger sink 40

Application component with trigger

Service with trigger sink

Service with trigger source

Mode Switch user

Mode Switch manager

Mode Switch manager

Virtual Functional Bus

Mode Switch manager

Table 3.2: Semantics of the port-icons

When a PPort of a component provides a client-server interface, the component to

Figure 3.6: Example showing the use of the Client-Server Interface

Figure 3.7: Example showing the use of the Sender-Receiver Interface

DialLED is sent toExample

requested to the server over the Setting port 49

(provided bycannotthebe divided

the Run-Time Environment

Figure 3.14: Component-view on the interaction between an atomic software

Runnable invoked cyclically

Invoked when other SW-C

SHDialFrontL SHCFrontLeft: HFront SHDialFront SHCFrontRight: HFront PM:

ECU1 ECU2 ECU3

RTE view VFB

ECU1 ECU2 ECU3

Figure 3.11: Example illustrating the mapping of a composition of components on

Interface Interface Component

The AUTOSAR Component API Generator reads the

Compilation of SW-C in object code