AutoSAR Overview

FESA Workshop at KTH 2010‐04‐12

Prof. Jakob Axelsson
Volvo Cars and
Mälardalen University

This presentation is based on a tutorial prepared by the 

AutoSAR Consortium
 AUTOSAR – Members Status June 2007

10 Core Partners
10 Core Partners 

57 Associate Members
49 Premium Members

2
Exchangeability and Reuse of SW Components
OEM b

Exchangeability
between supplier
between supplier‘ss
OEM a solutions
Platform b.1 OEM c
Platform b.2
Platform b.n

Platform a.1
Platform a.2 Supplier A Supplier B
Platform c.1
Platform a.n ¾ Chassis
¾ Chassis Platform c.2
¾ Safety ¾ Safety Platform c.n

Exchangeability ¾ Body/Comfort ¾ Telematics

¾ Multimedia ¾ Multimedia OEM d

between 
manufacturer‘s Supplier C
applications ¾ Body/Comfort
¾ Powertrain
OEM f
OEM f ¾ Telematics
T l ti
¾ Multimedia Platform d.1
Platform d.2
OEM e Platform d.n

Platform f.1
Platform f.2 Exchangeability
Platform f.n
Platform e.1
between vehicle 
Platform e.2 platforms
Platform e.n 3
 Changing Automotive SW Development
Automotive SW Development
Conventional AUTOSAR

Application Software
Software
standardized
AUTOSAR
HW‐specific
Hardware
Hardware

• Hardware and software will be widely independent of each other.

p p
• Development processes will be simplified. 
p
This reduces development time and costs.
• Reuse of software increases at OEM as well as at suppliers. 
This enhances also quality and efficiency.

Automotive Software will become a product. 
 AUTOSAR Main Working Topics
AUTOSAR Main Working Topics
¾ Architecture:
Architecture
Software architecture including a complete basic or environmental 
g p
Application
software stack for ECUs – the so called AUTOSAR Basic Software – as 
Methodology
Interfaces
an integration platform for hardware independent software 
applications. 

¾ Methodology:
Architecture
Exchange formats or description templates to enable a seamless 
Application
Methodology
configuration process of the basic software stack and the 
Interfaces
i
integration of application software in ECUs and it includes even the 
i f li i f i di i l d h
methodology how to use this framework.

¾ Application Interfaces:
Architecture
Specification of interfaces of typical automotive applications from 
Application
all domains in terms of syntax and semantics, which should serve as 
Methodology
Interfaces
a standard for application software.
a standard for application software.

5
 Intra‐ and Inter‐ECU Communication
• Ports implement the interface according to 
the communication paradigm (here client‐
server based).
• Ports are the interaction  ECU I ECU II
points of a component. Appli‐ Appli‐ Appli‐
cation cation cation
Application
• The communication is  SW‐C SW‐C SW‐C
A B C
channeled via the RTE.
• The communication layer 
in the basic software is  Ports
encapsulated and not 
visible at the application  RTE VFB RTE

l
layer. AUTOSAR
Infrastructure
BSW BSW

Hardware
Sensor

Communication Bus
Communication Path

6
 AUTOSAR Methodology
AUTOSAR Methodology
VFB view
SW‐C SW‐C SW‐C SW‐C
Description Description Description Description
Standardized description templates for 
St d di d d i ti t l t f
AUTOSAR
AUTOSAR

AUTOSAR

AUTOSAR
application software components 
SW‐C
SW‐C

SW‐C

SW‐C
...
2
1

n
(interfaces and BSW requirements)

Virtual Functional Bus
Standardized exchange formats and 
ECU
methodology for component, ECU, 
System Constraint
Descriptions Description and system level
Tool supporting deployment
of SW components

Mapping Tools for 
‐ support of component mapping 
ECU I ECU II ECU m
‐ generation of RTE, i.e. inter‐ and 
AUTTOSAR
AUTOSAR

AUTOSAR

AUTOSAR

intra ECU communication

intra ECU communication
SSW‐C
SSW‐C

SSW‐C

SSW‐C

n
1

...
RTE RTE RTE Standardized Basic Software (BSW) 
Basic  Basic  Basic  architecture, detailed specifications 
Software Software Software
for implementation and configuration
for implementation and configuration 
of BSW
Gateway

7
 AutoSAR Descriptions
ECUs Software Components

SwitchEval

SW‐Component Description
ECU Resource  ECU Resource  ECU Resource 
Description Description Description
BlinkInputModule
SwitchEval
SW‐Component Description

BlinkInputModule
SSupported protocols:
t d t l
BlinkMaster
CAN, LIN, FlexRay
SMLS System  BlinkMaster
SW‐Component Description
Description
BC‐H LightActuatorsControl
BC‐V LightActuatorsControl

SW‐Component Description
LightSourceSetting
CAN
LIN LightSourceSetting

SW‐Component Description
LM‐L LM‐R

8
AUTOSAR System Design Process
Input: Requirements & Vehicle Info
Input: Requirements & Vehicle Info

1a 1c 1b
System
SW Component
SW Component D
Description
i ti ECU Resource
ECU Resource
Description Description

2
Configure System 
& generate extracts
& generate extracts 
of ECU descriptions Iterative corrections
and/or optimizations
(if required)
3
Configure 
g
each ECU

SW Component
4
Generate SW 
executables 
t bl
for each ECU

SW executables 
SW executables
for each ECU

9
 AUTOSAR System Design Process
Input: Requirements & Vehicle Info

1a 1c 1b
System
SW Component Description ECU Resource
Description Description

2
Configure System 
& generate extracts 
of ECU descriptions Iterative corrections
SW Component Description and(/or optimizations
ƒ General characteristics (name, manufacturer, etc.)  (if required)
ƒ Communication properties:
3
‐ p_ports Configure 
‐ r_ports each ECU
‐ interfaces
SW Component
inner structure (composition)
‐ sub‐components 4
‐ connections
Generate SW 
executables 
ƒ required HW resources:
for each ECU
‐ processing time
‐ scheduling
‐ memory (size, type, etc.)
SW executables 
for each ECU
10
AUTOSAR System Design Process
Input: Requirements & Vehicle Info

1a 1c 1b
System
SW Component Description ECU Resource
Description Description

2
Configure System 
& generate extracts 
of ECU descriptionsECU Resource Description Iterative corrections
and(/or optimizations
ƒ General characteristics (name, manufacturer, etc.)(if required)
3
ƒ Temperature (own, environment, cooling/heating)
Configure 
ƒ Available signal processing methods
each ECU
ƒ Available programming capabilities
SW Component ƒ Available HW: ‐ µC, architecture (e.g. multiprocessor)
4 ‐ memory
Generate SW  ‐ interfaces (CAN, LIN, MOST, FlexRay)
executables  ‐ periphery (sensor / actuator)
for each ECU ‐ connectors (i.e. number of pins)
ƒ SW below RTE for micro controller 
ƒSignal path from Pin to ECU‐abstraction
SW executables 
for each ECU
11
AUTOSAR System Design Process
Input: Requirements & Vehicle Info

1a 1c 1b
System
SW Component Description ECU Resource
Description Description

2
Configure System 
& generate extracts 
System Description
of ECU descriptions Iterative corrections
ƒ Network topology  and(/or optimizations
‐ bus systems: CAN, LIN, FlexRay (if required)
3 ‐ connected ECUs, Gateways
‐ power supply, system activation
Configure 
each ECU
ƒ Communication (for each channel) 
‐ K‐matrix
SW Component ‐ gateway table
4
ƒ Mapping / Clustering of SW components
Generate SW 
executables 
for each ECU

SW executables 
for each ECU
12
 AUTOSAR Metamodel
• The metamodel is modeled  METAMODEL
in UML SW‐
SW
Datatype
Component
• The structure of the  Interface

information can be clearly 
visualized
MODEL
• The consistency of the 
information is guaranteed Mirror 
Adjustment
Mirror 
Actuator

• Using XML, a data exchange 
format can be generated 
automatically out of the
automatically out of the 
metamodel

13
 Application Interfaces to Ease Reuse
Data Type Name LongAccBase
…
Data Type Name YawRateBase
ESP-Sensors
ESP-Sensors
Description Yaw rate measured along vehicle z- axis
(i.e. compensated for orientation).
Base Sensor Signals
I1 Coordinate system according to ISO
Interface of ESP
8855
and VLC

Ínterface of ESP and

I4
Vehicle
Vehicle
Longitudinal
Data Type S16
external yaw rate Longitudinal
controller Controller
Controller
2nd
2nd Yaw
Yaw I6
ESP
ESP Integer Range -32768..+32767
Standard Signals
Rate
RateController
Controller SW-Component
SW-Component from ESP
I2 Physical Range -2,8595..+2,8594
Information signals
g
from other functions /
domains
Ph i l Offset
Physical Off t 0
System-level Brake
Actuator Interface I3
I7 Command signals to Unit rad/sec
other functions /
domains
I5 … ….
Remarks This data element can also be used to
Brake
Brake Actuator
Actuator instantiate a redundant sensor interface.
Range might have to be extended for
future applications (passive safety).
Standardized application interfaces on 
…
system level 
Data Type Name RollRateBase
(ESP‐system, chassis domain)

14