AUTOSAR –

An open standardized software architecture

for the automotive industry

Simon Fürst, BMW

1st AUTOSAR Open Conference &
8th AUTOSAR Premium Member Conference
October 23rd, 2008, Cobo Center, Detroit, MI, USA
Document Information and Change History

Document Owner Heiko Dörr

Document Responsibility SC

Document Version 1.5

Document filename AUTOSAR_Tutorial

Document Status <Draft | Ready for Approval | Final>

Document Change History

Date Version Changed by Change Description
30.05.2007 0.1 Heiko Dörr Initial creation and proposal for content
10.08.2007 0.2 Heiko Dörr Ready for approval
16.08.2007 0.3 Heiko Dörr Comments by Mr. Bunzel entered
17.08.2007 0.4 Heiko Dörr Section on Methodology updated after discussion with member of WPII-
1.2; Section on Exploitation removed; Ready for approval by SC
23.08.07 1.0 Heiko Dörr Tutorial approved by SC
31.08.07 1.1 Heiko Dörr PM memberships updated according to slide provided by admin
07.04.08 1.2 Heiko Dörr CP updated, readability improved
07.05.08 1.3 Heiko Dörr Bus state managers added to BSW modules slide
03.07.2008 1.4 Heiko Dörr Selected slides from ATI added (Animated use case for distributed
scenario, Validator 2), Schedule updated
01.10.2008 1.5 Heiko Dörr Selection of slides for presentation at 8th PM conference

2 Oct. 23rd 2008 AUTOSAR Tutorial

Document Information and Change History

Document Change History

Date Version Changed by Change Description
22.10.2008 1.51 Simon Fürst Review

3 Oct. 23rd 2008 AUTOSAR Tutorial

 Automotive Systems and SW Engineering

4 Oct. 23rd 2008 AUTOSAR Tutorial

Automotive Open System Architecture
Cooperate on standards – compete on implementation

Non functional
legal requirements

Vehicle family
management

Resource efficiency

Driver assistance

Driving dynamics

Safety functions
(active/passive)

Comfort functions

5 Oct. 23rd 2008 AUTOSAR Tutorial

AUTOSAR Managing Complexity
by Exchangeability and Reuse of Software Components
OEM b

Exchangeability
between
OEM a supplier‘s
Platform b.1 solutions 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 Platform c.n
¾ Safety
¾ Telematics
Exchangeability ¾ Body/Comfort
¾ Multimedia
between ¾ Multimedia OEM d
manufacturer‘s Supplier C
applications ¾ Body/Comfort
¾ Powertrain
OEM f ¾ Telematics
¾ 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
Platform e.n
platforms

6 Oct. 23rd 2008 AUTOSAR Tutorial

AUTOSAR
Project Objectives and Main Working Topics

¾ Implementation and ¾ Maintainability throughout the

standardization of basic whole “Product Life Cycle“
system functions as an OEM
wide “Standard Core“ solution
¾ Increased use of “Commercial
Architecture off the shelf hardware“
¾ Scalability to different vehicle
and platform variants
¾ Software updates
and upgrades over
¾ Transferability of vehicle lifetime
functions throughout
network Application ¾ Consideration of
Methodology availability and safety
¾ Integration of Interfaces requirements
functional modules
from ¾ Redundancy
multiple suppliers activation

7 Oct. 23rd 2008 AUTOSAR Tutorial

AUTOSAR
Main Working Topics

¾ Architecture:
Architecture
Software architecture including a complete basic or
Application
environmental software stack for ECUs – the so called
Methodology
Interfaces
AUTOSAR Basic Software – as an integration platform for
hardware independent software applications.

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

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

8 Oct. 23rd 2008 AUTOSAR Tutorial

Technical scope of AUTOSAR

Methodology

New Meta Model

Exchange
concepts Formats Configuration
Concept
Virtual Function
Bus (VFB)
Input Error
Templates Handling
RunTime
Environment

Memory Mode Network Comm.

Services Management Management Services

Diagnostics Gateway
Industry-wide OS Kernel
consolidation of ECU
Abstraction
Bus systems

µController
‚existing‘ basic Abstraction
Complex
Drivers
software designs Drivers

9 Oct. 23rd 2008 AUTOSAR Tutorial

Benefits from AUTOSAR

„ OEM overlapping reuse of software modules

„ Maintaining ability to compete on innovative functions,
OEM enlarged design flexibility
„ Simplification of the integration task
„ Reduction of total SW development costs

„ Reduction of version proliferation

„ Development partitioning among suppliers
Supplier
„ Increase of efficiency in functional development
„ New business models possible

„ Common interfaces with development

Tool provider
processes
„ Seamless, manageable, task optimized
(time dependent) tool landscape

„ Transparent and defined

New market
entrant interfaces enable new
business models

10 Oct. 23rd 2008 AUTOSAR Tutorial

 Project Setup Phase II

11 Oct. 23rd 2008 AUTOSAR Tutorial

AUTOSAR – Partnership Structure

CorePartners
Core Partners PremiumMembers
Members
(OEM&&Tier
Tier11Supplier)
Supplier) Premium
(OEM „„Leadership
LeadershipofofWorking
WorkingGroups
Groups
„„Organizational
Organizationalcontrol
control
„„Involvement
InvolvementininWorking
WorkingGroups
Groups
„„Technical
Technicalcontributions
contributions
„„Technical
Technicalcontributions
contributions
„„Administrative
Administrativecontrol
control
„„Access
Accesstotocurrent
currentinformation
information
„„Definition
Definitionofofexternal
externalInformation
Information
(web-release,clearance,
(web-release, clearance,etc.)
etc.)
„„Leadership
LeadershipofofWorking
WorkingGroups
Groups
„„Involvement
InvolvementininWorking
WorkingGroups
Groups

Support Roles
„ Development
Members
AssociateMembers
Associate Members „ Attendees
„„Access
Accesstotofinalized
finalizeddocuments
documents
„„Utilization
UtilizationofofAUTOSAR
AUTOSARstandard
standard

12 Oct. 23rd 2008 AUTOSAR Tutorial

 AUTOSAR – Core Partners and Members
Status: 10th October 2008

9 Core Partner
6 Development Member

85 Associate Member
55 Premium Member

General Generic Standard Tools and Semi-

OEM Tier 1 Software Services conductors

Up-to-date status see: http://www.autosar.org

13 Oct. 23rd 2008 AUTOSAR Tutorial

AUTOSAR Phase II 2007 – 2009

¾ AUTOSAR Development Partnership continues

¾ Identical Core Partners
¾ Exploitation and maintenance
„ Already in 2008 the first cars on the road with AUTOSAR technology inside
„ All Core Partners have planned the introduction of AUTOSAR products until 2010
„ Establish conformance test specifications and process
¾ Further development and amendment of the standard, e.g.
„ Functional safety features
„ Support for multi core microcontrollers
„ Vehicle & application mode management
„ Debugging and error handling
„ Variant handling
„ Timing model
„ Standardization of application interfaces

14 Oct. 23rd 2008 AUTOSAR Tutorial

 Top Level Schedule for AUTOSAR in phase II

Phase II (2007 – 2009)

Basic Software & RTE

Specification R3.0 Finalizat. Maintain R3.0 Specifications

Specification R3.1 Finalizat. Maintain R3.1 Specifications

Concepts R4.0 Specification R4.0 Maint. R4.0

CT Pilot Conformance Test Preparation CT Spec 1st set CT Spec 2nd set CT 3rd set CT 4th set Maintain CTS

Validator 2 Validation R4.0 (BSW/RTE + Methodology)

Methodology and Templates

Methodology & Templates R3.0 Finalizat. Methodology & Templates R4.0 Maint. R4.0

Application Interfaces
Specification Appl. Interfaces R3.0Finalizat. Specification Application Interfaces R4.0 Maint. R4.0

28.09.07 21.12.07 30.05.08 27.06.08 12.12.08 24.07.09 27.11.09

Specification 3.0 Ready Release 3.0 Specification 3.1 Ready Release 3.1 Spec R4.0 MS3 Ready Validation & CT 4.0 Release 4.0

1H 2007 2H 2007 1H 2008 2H 2008 1H 2009 2H 2009

2007 2008 2009
15 Oct. 23rd 2008 AUTOSAR Tutorial
AUTOSAR Phase II
Work Package Breakdown Structure

Work Packages

II-1 II-2 II-3 II-4 II-5 II-10

Software and
System Enabling Maintenance of Application
Test Validation
Architecture Exploitation Releases Interfaces
Specification

II-1.1 II-2.1 WPII-3.1 WPII-4.2 WPII-5.1 WPII-10.0

Software Basic Software Communication Problem Coordination of
Architecture Basic Software Validation and Marketing Management Appl. Interfaces

WPII-1.1.1 WPII-1.1.2 WPII-2.1.1 WPII-3.2 WPII-4.3 WPII-5.2 WPII-10.1

Software Vehicle and Methodology Follow-up Change and Body and
Architecture Application COM Stack
Validation Organization Release Mgmt. Comfort
and OS Mode Mgmt.
WPII-2.1.2
WPII-1.1.3 WPII-1.1.4 WPII-5.3 WPII-10.2
FlexRay Maintenance of
Debugging Error Handling Specifications Powertrain
WPII-2.1.3
WPII-1.1.5 MCAL
WPII-10.3
VFB and RTE WPII-2.1.4 Chassis
Diagnostics Control
WPII-1.2 WPII-10.4
Methodology WPII-2.1.5
Occupants and
and Libraries Pedest. Safety
Configuration
WPII-2.2
WPII-1.3 WPII-10.5
Conformance
Functional Test MM / T / HMI
Safety Specification

16 Oct. 23rd 2008 AUTOSAR Tutorial

 Use Cases of AUTOSAR Results
¾ Exchange of SW-Components
¾ Re-use of SW components for different platforms

… shown by uses cases

pedal management
front light management

17 Oct. 23rd 2008 AUTOSAR Tutorial

Use Case ‘Pedal Management’ view for one ECU

¾ Implementation of functions independent on distribution on different ECU

as communication will be done via ECU-individual AUTOSAR-RTE exclusively

void distribute_v(void)
{
… distribute_v()
Rte_Write_p_v(rte_i, v)
…
}

void v_warn(void)
{
…
Rte_Read_p_v(rte_i, v)
…
}

18 Oct. 23rd 2008 AUTOSAR Tutorial

Use Case ‘Pedal Management’ view for two ECUs

distribute_v()

e.g. FlexRay, CAN, etc.

„ Reuse of Intellectual Property

„ Increase in design flexibility
Technical benefits „ Simplification of the integration task
„ Reduction of SW development costs

19 Oct. 23rd 2008 AUTOSAR Tutorial

Use case ‘Front-Light Management’ in AUTOSAR
SwitchEvent LightRequest Front-Light Manager Headlight
check_switch () switch_event(event) request_light(type, mode) set_light(type, mode)
get_keyposition()
switch_event request_light
set_light(type, mode) set_current (…)
(event) (type, mode)

AUTOSAR Int. AUTOSAR Interface AUTOSAR Interface AUTOSAR Interface

AUTOSAR RTE
Standardized Std. AUTOSAR Standardized AUTOSAR AUTOSAR
Interface Interface Interface Interface Interface
Communi- ECU
Services cation Abstraction
Standardized

Std. Interface Std. Interface Std. Interface

Interface

Complex
Operating Device
System Drivers
Standardized Interface
DIO PWM CAN Driver

Microcontroller Abstraction
ECU-Hardware

20 Oct. 23rd 2008 AUTOSAR Tutorial

Exchange of type of front-light
SwitchEvent LightRequest Front-Light Manager Headlight
Xenonlight
check_switch () switch_event(even request_light(type, mode) set_light(type, mode)
t) get_keyposition()
switch_event request_light
set_light(type, mode) set_current (…)
(event) (type, mode)

AUTOSAR Int. AUTOSAR Interface AUTOSAR Interface AUTOSAR Interface

AUTOSAR RTE
Standardized Std. AUTOSAR Standardized AUTOSAR AUTOSAR
Interface Interface Interface Interface Interface
Communi- ECU
Services cation Abstraction
Standardized

Std. Interface Std. Interface Std. Interface

Interface

Complex
Operating Device
System Drivers
Standardized Interface
DIO PWM
DIO CAN Driver

Microcontroller Abstraction
ECU-Hardware

21 Oct. 23rd 2008 AUTOSAR Tutorial

Distribution on ECUs
SwitchEvent LightRequest
LightRequest Front-Light Manager Xenonlight
check_switch () switch_event(even request_light(type, mode) set_light(type, mode)
t) get_keyposition()
switch_event request_light
set_light(type, mode) set_current (…)
(event) (type, mode)

AUTOSAR Int. AUTOSAR

AUTOSAR Interface
Interface AUTOSAR Interface AUTOSAR Interface

AUTOSAR RTE
Standardized Std. AUTOSAR Standardized AUTOSAR AUTOSAR
Interface Interface Interface Interface Interface
Communi- ECU
Services cation Abstraction
Standardized

Std. Interface Std. Interface Std. Interface

Interface

Complex
Operating Device
System Drivers
Standardized Interface
DIO PWM
DIO CAN Driver

Microcontroller Abstraction
ECU-Hardware

22 Oct. 23rd 2008 AUTOSAR Tutorial

 Use case ‘Front-Light Management’ in AUTOSAR
SwitchEvent LightRequest Front-Light Manager Xenonlight
check_switch () switch_event(event) request_light(type, mode) set_light(type, mode)
get_keyposition()
switch_event request_light
set_light(type, mode) set_current (…)
(event) (type, mode)

AUTOSAR Int. AUTOSAR Interface AUTOSAR Interface AUTOSAR Interface

AUTOSAR RTE AUTOSAR RTE AUTOSAR RTE

Std. AUTOSAR AUTOSAR Standardized Standardized Standardized AUTOSAR
Interface Interface Interface Interface Interface Interface
ECU Communi- Communi- Communi- ECU
Services Abstraction cation cation cation Abstraction
Std. Interface Std. Interface Std. Interface Std. Interface Std. Interface Std. Interface

Standardized Interface Standardized Interface Standardized Interface

DIO CAN Driver CAN Driver CAN Driver PWM

Microcontroller Abstraction Microcontroller Abstraction Microcontroller Abstraction

ECU-Hardware ECU-Hardware ECU-Hardware

CAN Bus

23 Oct. 23rd 2008 AUTOSAR Tutorial

AUTOSAR Key Topics

AUTOSAR provides three main areas of results:

¾ Architecture:
Software architecture including a complete basic (environmental) software stack for an
ECU as an integration platform for hardware independent SW applications

¾ Methodology:
Exchange formats (templates) to enable a seamless configuration process of the basic
software stack and the integration of application software in ECUs

¾ Application Interfaces:
Specification of application interfaces as a standard for application software modules

24 Oct. 23rd 2008 AUTOSAR Tutorial

 Main Concepts: Architecture
¾ Basic Software modules
¾ Run time environment and communication
¾ Results of sample implementation in „Validator 2“

25 Oct. 23rd 2008 AUTOSAR Tutorial

Standardized AUTOSAR interfaces will support HW independence
and enable the standardization of SW components.

Automotive Open System

SW-Component SW-Component SW-Component
1 2 n
Architecture (AUTOSAR):

AUTOSAR AUTOSAR
.................... AUTOSAR
„ Standardized, openly disclosed
Interface Interface Interface interfaces
„ HW independent SW layer
„ Transferability of functions
AUTOSAR RTE
„ Redundancy activation

AUTOSAR RTE:
Basic Software by specifying interfaces and their
„ Transfer layers for different communication technologies (e.g. CAN, LIN, …)
„ Network management
communication mechanisms, the
„ System services (diagnostic protocols, …) applications are decoupled from
„ NVRAM management
„ … the underlying HW and Basic SW,
enabling the realization of Stan-
dard Library Functions.
Microcontroller Abstraction

ECU Hardware

26 Oct. 23rd 2008 AUTOSAR Tutorial

AUTOSAR Basic Software

Application Layer

AUTOSAR Runtime Environment (RTE)

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

Onboard Device Memory Hardware Communication

Abstraction Abstraction Hardware Abstraction

Microcontroller Drivers Memory Drivers Communication I/O Drivers

Drivers

Microcontroller

27 Oct. 23rd 2008 AUTOSAR Tutorial

AUTOSAR Basic Software Modules
Application Layer

AUTOSAR Runtime Environment (RTE)

System Services Memory Communication Services I/O Hardware
Services Generic NM Abstraction
DCM CAN
ECU State Manager

Watchdog Manager
Interf.

Development Error
Function Inhibition
AUTOSAR Diagnostic SM

Diagnostic Event

Communication
Manager FIM

Manager DEM
COM Com.

Manager
I/O Hardware

Tracer
Manager
LIN

FlexRay NM
NVRAM Abstraction
Manager SM
PDU Router CAN NM
IPDU
Multi- FR
LIN CAN FlexRay
plexer SM
TP TP TP

Onboard Device Memory Hardware Abstraction Communication Hardware Abstraction

Abstraction LIN
Memory Abstraction Interface CAN Interface FR Interface
CRC Lib
AUTOSAR OS

Interface
Watchdog Interface
EEPROM Flash EEPROM

CAN transc
BSW Scheduler

FR transc
Ext. CAN
Abstraction Emulation

Ext. FR
Driver

Driver

Driver
Driver
External
Watchdog Ext.
Driver EEPROM Ext. Flash
Driver Driver

Microcontroller Drivers Memory Drivers Communication Drivers I/O Drivers

internal Flash Driver

LIN Communication
SPI Handler Driver
internal EEPROM
Watchdog Driver
Flash Check

PORT Driver
PWM Driver
MCU Driver

ADC Driver
GPT Driver

CAN Driver

DIO Driver
ICU Driver
RAM Test

LIN Driver

FR Driver
Driver

Stack
Clock Unit

EEPROM

e.g. CCU
e.g. PCP
e.g. TPU
Ext. BUS
Power &

FlexRay
FLASH

CCU

PWM
WDT
MCU

CAN

ADC
GPT

DIO
SCI
SPI

LIN

Microcontroller µC

28 Oct. 23rd 2008 AUTOSAR Tutorial

Example: “NVRAM Manager” ensures the storage and maintenance
of non-volatile data and is independent of the design of the ECU.
Example

Memory Services

NVRAM Manager

EepIf_Read()
EepIf_Write()
Memory Hardware Abstraction
Mem Abstraction Interface
Application Layer

EEPROM Abstraction
AUTOSAR Runtime Environment (RTE)
System Services Memory Services Communication I/O Hardware Complex
Services Abstraction Drivers

Ext. EEPROM Driver

Onboard Device Memory Hardware Communication Spi_Read()
Abstraction Abstraction Hardware Abstraction
Spi_Write()
Microcontroller Drivers Memory Drivers Communication I/O Drivers
Drivers
COM Drivers Memory Drivers
SPI Handler Int. EEPROM
Microcontroller
+ Driver Driver

SPI µC EEPROM

External EEPROM

29 Oct. 23rd 2008 AUTOSAR Tutorial

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-
cation
Appli-
cation
Appli-
cation
Application
¾ The communication is SW-C
A
SW-C
B
SW-C
C
channeled via the RTE.
¾ The communication layer
Ports
in the basic software is
encapsulated and not RTE VFB RTE
visible at the application AUTOSAR
layer. Infrastructure
BSW BSW

Hardware
Sensor

Communication Bus
Communication Path

30 Oct. 23rd 2008 AUTOSAR Tutorial

Validation of AUTOSAR Release 2.0

AUTOSAR AUTOSAR
Specifications Concepts &
Methodology

TriCore 1766 (32 Bit) Validator 2 Integration

Resource &
Hardware Platforms dealt with …
Consumption
HCS12X (16 Bit)
Measurement

Module Implementations
&
ECU Configuration Tools

31 Oct. 23rd 2008 AUTOSAR Tutorial

Used Release 2.0 AUTOSAR specifications

Application Actuator Sensor Application

Software
Component
Software
Component
Software
Component
AUTOSAR Software
Component SW-C Template
Software
AUTOSAR
Interface
AUTOSAR
Interface
AUTOSAR
Interface
..............
AUTOSAR
Interface Specification
AUTOSAR Runtime Environment (RTE)
All generic and
Standardized
module specific Standardized
Interface
AUTOSAR
Interface
Standardized
Interface
AUTOSAR
Interface
AUTOSAR
Interface

SW Specifications Services Communication

ECU
Abstraction

of all Standardized Standardized Standardized

Standardized
Inteface Interface Interface Interface

Software Layers Operating

System
Complex
Device
Drivers
of AUTOSAR Standardized
Interface
Basic Software
BSW & RTE Microcontroller
Abstraction

ECU-Hardware

.XML
System Configure
Configuration System
Input :
System
.XML AUTOSAR Methodology
System
Configuration
Extract
ECU- Specifications
Specific .XML
Description
:System Information
ECU Configure
regarding
Extract
of
ECU
.XML .exe
ECU Configuration
System
Configuration ECU Generate ECU
:System Configuration Executable Executable
Description

32 Oct. 23rd 2008 AUTOSAR Tutorial

Validation of Standardized SW Specifications: Functionality & Scalability

The specified application provides ‘realistic’ functionality:

„ Calculating of the vehicle speed based on several inputs
„ Displaying the calculated speed

ECU
ECU 11
Status
StatusControl
ControlInput I/O Status
Digital
Input I/O HWA
HWA Status
Status Status
DigitalSignal
Signal Digital Control Control
0000..1111
0000..1111 Digital Control Control
(see
(seedescription)
description) Input
Input Master
Master Slave
Slave

Short
Short
Counting
Counting

Formatting
Formatting I/O
I/O HWA
HWA Lamp
Lampor or
Engine
Engine Analog
Analog Analog
AnalogOut
Out Volt-
Volt-
Speed +Short meter
Revolution
Revolution
Analog
I/O
I/O HWA
HWA Revolution
Revolution Speed +Short Detection
Detection meter
AnalogSignal
Signal Analog Value
0..5V
0..5V->
-> Analog Value
0..6000U/min
0..6000U/min Input
Input Normalization
Normalization
Formatting
Formatting I/O
I/O HWA
HWA Lamp
Lamporor
Speed
Speedvalue
value PWM
PWM PWM
PWM Signal
Signal
calculation
calculation Analyzer
Analyzer
Speed
Speed Output
Output
Gear I/O
Gear
Digital
I/O HWA
HWA Gear
Gear
DigitalSignal
Signal Digital Signal
0..1
0..1->
-> Digital Signal
1st
1stand
and2nd
2ndGear
Gear Input
Input Normalization
Normalization Formatting
Formatting I/O
I/O HWA
HWA Dot
Dot Matrix
Matrix
Speed
Speed Digital
Digital Display
Display
Display
Display Output
Output

33 Oct. 23rd 2008 AUTOSAR Tutorial

System Test Approach: Functionality & Scalability

¾Scalability is divided into 3 aspects:

„ Distribution of the given application on several nodes.
„ Using the appropriate communication bus technology.
„ Using the appropriate platform for each node.

ECU
ECU33
Status Control Input Status Status
Status Control Input
LIN Signal Status Status Short
LIN Signal
0000..1111 Control Control Short
Control Control Counting
ECU
ECU33 (see 0000..1111
description)
(see description)
Master
Master
Slave
Slave
Counting
Status Control Input Status Status
Status
DigitalControl
SignalInput I/O HWA Status Status Short
Digital Signal
0000..1111 I/O HWA Control Control Short
Digital Input Control Control Counting Formatting I/O HWA Lamp or
(see0000..1111
description) Digital Input Master Slave Counting Formatting I/O HWA Lamp or
(see description) Master Slave Analog Analog Out Volt-
ECU
ECU11
Analog
Speed
Analog Out
+Short Detection
Volt-
meter
meter
ECU
ECU11 Status
Status
Speed +Short Detection
Status Control Input I/O HWA Status Status Formatting I/O HWA Lamp or Control
Status
DigitalControl
Signal Input I/O HWA Status Status Formatting I/O HWA Lamp or Control Formatting I/O HWA Lamp or
Digital Signal
0000..1111 Digital Control Control Analog Analog Out Volt- Slave Speed value Formatting I/O HWA Lamp or
(see 0000..1111
Digital
Input
Control
Master
Control
Slave Analog Analog Out Volt-
meter Slave Speed value PWM PWM Signal
description) Speed +Short Detection
(see description) Input Master Slave
ECU
ECU11 Speed +Short Detection meter
Engine
Engine
Revolution
calculation
calculation
PWM
Speed
Speed
PWM
Output
Output
Signal
Analyzer
Analyzer
Revolution Revolution
Analog Signal I/O HWA Revolution
Analog Signal
0..5V -> I/O HWA Value
Short
Short Status Formatting I/O HWA Lamp or 0..5V -> Analog Input Value Formatting I/O HWA
Counting Status Speed value Formatting I/O HWA Lamp or 0..6000U/min Analog Input Normalization Formatting I/O HWA Dot Matrix
Counting Control Speed value PWM PWM Signal 0..6000U/min Normalization Speed Digital Dot Matrix
Display
Control calculation PWM PWM Signal
Analyzer Speed Digital Display
Slave calculation Speed Output Analyzer Display Output
Formatting I/O HWA Slave Speed Output Output
Formatting
Analog
I/O HWA
Analog Out
Lamp or
Lamp
Volt- or ECU
ECU11 CAN
CANBus
Bus
Display
Engine
Engine
Revolution
Revolution
Analog Signal
I/O HWA
I/O HWA
Revolution
Revolution
Analog
Speed
Speed
Analog Out
+Short Detection
+Short Detection
Volt-
meter
meter Engine
Engine
ECU
ECU44
Analog
0..5V ->Signal Analog Value Revolution Revolution Formatting I/O HWA
0..5V -> Analog
Input
Value
Normalization
Revolution
Analog Signal I/O HWA Revolution Formatting I/O HWA Dot Matrix
0..6000U/min
Input Normalization Analog Signal I/O HWA Value Speed Digital Dot Matrix
Display Gateway
0..6000U/min Digital
Speed value
Formatting
Formatting
I/O HWA
I/O HWA
Lamp or
0..5V ->
0..5V ->
0..6000U/min
Analog Input
Analog Input
Value
Normalization CAN
CANBus
Bus
Speed
Display Output
Output
Display Gateway

Speed value PWM PWM Lamp or

Signal 0..6000U/min Normalization Display
calculation PWM PWM Signal
calculation Speed
Speed
Output
Output
Analyzer
Analyzer FlexRay
FlexRayBus
Bus
Gear I/O HWA Gear
DigitalGear
Signal I/O HWA Gear
Digital
0..1 ->Signal
1st and0..1
2nd->Gear
Digital
Digital
Input
Input
Signal
Signal
Normalization
Normalization Formatting I/O HWA Gear
ECU
ECU22 Gear I/O HWA Gear Status
ECU
ECU22
1st and 2nd Gear
Formatting I/O HWA I/O HWA Gear Status DigitalGear
Signal I/O HWA Gear Status
Speed Digital
Dot Matrix
DigitalGear
Signal I/O HWA Gear Status Digital Digital Input Signal Control
Dot Matrix
Display Digital Digital Input Signal Control 0..1 ->Signal Digital Input Signal Control
Speed
Display
Digital
Output Display 0..1 ->Signal Digital Input Signal Control 1st and0..1
2nd->Gear Short Detection Normalization Slave
Display Output 1st and0..1
2nd->Gear Short Detection Normalization Slave 1st and 2nd Gear Short Detection Normalization Slave
1st and 2nd Gear Short Detection Normalization Slave

3 ECU connected 4 ECU connected

One ECU
by CAN bus by CAN and FlexRay bus

34 Oct. 23rd 2008 AUTOSAR Tutorial

Experience with AUTOSAR concepts and methodology: RTE

RTE concept was validated in the system test where

a “dummy” real world application was created with a
couple of AUTOSAR SW-C’s and IO Hardware
Abstraction.

RTE overhead = low!

Lessons learned:

Î Configuration of RTE might be very complex as long the requirements of the RTE and the
OS are not optimized.
Î Close linkage of RTE & OS requires close cooperation between implementers

35 Oct. 23rd 2008 AUTOSAR Tutorial

Experience with AUTOSAR concepts and methodology:
IO Hardware Abstraction

The IO HW Abstraction is a special kind of

AUTOSAR SW-C.
It enables the integration of SW-C which use
IOs from the ECU (e.g. SW-C for sensors
and actors).

¾ The IO HW abstraction SWS implemented in validator 2 was handled as a SW-C

(AUTOSAR interface) and as a BSW module (interface to BSW Scheduler and IO
driver).
¾ It was needed to specify the AUTOSAR interface of the IO HW Abstraction at the
beginning of the project, since it is not defined in the SWS of the IO HW Abstraction.
¾ The definition of the AUTOSAR interface was done by defining ports for IO HW
Abstraction and SW-Cs.
Î Port interfaces instead of ports should be defined first.

36 Oct. 23rd 2008 AUTOSAR Tutorial

AUTOSAR Architecture – Conclusion

AUTOSAR harmonizes already existing basic software solutions and

1
closes gaps for a seamless basic software architecture.

AUTOSAR aims at finding the best solution for each requirement and
2 not finding the highest common multiple.

The decomposition of the AUTOSAR layered architecture into some

3 50 modules has proven to be functional and complete.

The AUTOSAR 2.0 specifications for the modules of the layered

4 architecture have been successfully implemented and integrated.

Conformance tests and processes are being prepared to ensure and

5 to maintain a stable standard.

37 Oct. 23rd 2008 AUTOSAR Tutorial

 Main Concepts: Methodology
¾ Overall methodology
¾ Structure of configuration information
¾ System Design – Implementation Process
¾ Meta-model structure

38 Oct. 23rd 2008 AUTOSAR Tutorial

Following the AUTOSAR Methodology, the E/E architecture is
derived from the formal description of software and hardware components.

¾ Functional software is described

SW-C SW-C SW-C SW-C
Description Description Description Description

formally in terms of “Software

AUTOSAR
AUTOSAR

AUTOSAR

AUTOSAR
SW-C
SW-C

SW-C
SW-C
... Components” (SW-C).
2
1

n
¾ Using “Software Component
Descriptions“ as input, the „Virtual
Virtual Functional Bus
Functional Bus“ validates the
interaction of all components and
interfaces before software
Tool supporting deployment implementation.
of SW components

ECU System Constraint ¾ Mapping of “Software Components” to

Descriptions Description
ECUs and configuration of basic
software.
ECU I ECU II ECU m
¾ The AUTOSAR Methodology supports
AUTOSAR

AUTOSAR

AUTOSAR

AUTOSAR

the generation of an E/E architecture.

SW-C

SW-C
SW-C

SW-C

...
1

RTE RTE RTE

Basic Software Basic Software Basic Software

Gateway

39 Oct. 23rd 2008 AUTOSAR Tutorial

AUTOSAR Methodology
Derive E/E architecture from formal descriptions of soft- and hardware components
VFB view
SW-C SW-C SW-C SW-C
DescriptionDescriptionDescription Description
Standardized description templates for
AUTOSAR
AUTOSAR

AUTOSAR

AUTOSAR
SW-C application software components
SW-C

SW-C

SW-C
...
2
1

n
(interfaces and BSW requirements)

Virtual Functional Bus

Standardized exchange formats
ECU
and methodology for component,
System Constraint
Descriptions Description ECU, 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
AUTOSAR
AUTOSAR

AUTOSAR
AUTOSAR

SW-C

intra ECU communication

SW-C

SW-C
SW-C

n
1

2
3

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

40 Oct. 23rd 2008 AUTOSAR Tutorial

To configure the system, input descriptions of all software
components, ECU resources and system constraints are necessary.
Example

ECUs Software Components

SwitchEval

SW-Component Description
ECU Resource ECU Resource ECU Resource
Description Description Description
BlinkInputModule
SwitchEval
SW-Component Description

BlinkInputModule
Supported protocols:
BlinkMaster
CAN, LIN, FlexRay
SMLS System BlinkMaster
SW-Component Description
Description
BC-H LightActuatorsControl
BC-V LightActuatorsControl
LightSourceSetting
SW-Component Description
CAN
LIN LightSourceSetting

LM-R SW-Component Description

LM-L

41 Oct. 23rd 2008 AUTOSAR Tutorial

The system configuration maps software components
to ECUs and links interface connections to bus signals.
Example

System Configuration
SWCMappingDefs DataMappingDefs

BlinkRequest

SwitchEval
Blink
Blink
Input
Master
Module
BlinkInputModule

BlinkMaster
Comm.Matrix for BodyCAN

LightActuatorsControl
FrameInstance
…BlinkRequest
LightSourceSetting SignalBS1
SignalBS2 SignalBS3

42 Oct. 23rd 2008 AUTOSAR Tutorial

AUTOSAR – System Design – Implementation Process
Input: Requirements & Vehicle Info

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

2
Configure System
& generate extracts
of ECU descriptions Iterative corrections
and(/or optimizations
(if required)
3
Configure
each ECU
SW Component
4
Generate SW
executables
for each ECU

SW executables
for each ECU

43 Oct. 23rd 2008 AUTOSAR Tutorial

AUTOSAR – The Virtual Functional Bus
Input to the System Design on an abstract level

Function Bus Integrator

SW-Component

„v_warn()“
Template

ponent m
SW Com-
ponent 3
„get_v()“

SW Com-
Description
Description

Description

Description
...
Example: speed
warning device Virtual Functional Bus

¾ SW-Component-Description „get_v()“ describes a function to acquire the current vehicle

speed and defines the necessary resources (such as memory, run-time and computing
power requirements, etc.)
¾ Function „v_warn()“ makes use of „get_v()“
¾ „Virtual Integration“ by check of
- completeness of SW-Component-Descriptions (entirety of interconnections)
- integrity/correctness of interfaces
¾ The Virtual Functional Bus is implemented by the AUTOSAR-Runtime-Environment
(RTE) and underlying Basic-SW
= tool based

44 Oct. 23rd 2008 AUTOSAR Tutorial

AUTOSAR – Input Descriptions (1 of 3)
Step 1a): Description of SW-Components independently of hardware

SW Component Description
ƒ General characteristics (name, manufacturer, etc.)
ƒ Communication properties:
- p_ports
- r_ports
Information for each SWC - interfaces
inner structure (composition)
e.g. “get_v()” - sub-components
- interfaces, behavior (repetition rate, ...) - connections
- direct hardware interfaces (I/O)
ƒ required HW resources:
- requirements on run-time performance - processing time
(memory, computing power, throughput, - scheduling
timing/latency, …) - memory (size, type, etc.)
- ...

„get_v()“
AUTOSAR-Description
Software Component
Editor
Description
= tool based

45 Oct. 23rd 2008 AUTOSAR Tutorial

AUTOSAR – Input Descriptions (2 of 3)
Step 1b): Description of hardware independently of application software
Information for each ECU
e.g. ECU1
- sensors and actuators
- hardware interfaces
- HW attributes (memory, processor,
computing power, …)
- connections and bandwidths, etc.
- ...
AUTOSAR-Description
Editor
= tool based
46 Oct. 23rd 2008
ECU Resource Description
ƒ General characteristics (name, manufacturer, etc.)
ƒ Temperature (own, environment, cooling/heating)
ƒ Available signal processing methods
ƒ Available programming capabilities
ƒ Available HW: - µC, architecture (e.g. multiprocessor)
- memory
- interfaces (CAN, LIN, MOST, FlexRay)
- periphery (sensor / actuator)
- connectors (i.e. number of pins)
ƒ SW below RTE for micro controller
ƒSignal path from Pin to ECU-abstraction
ECU 1
Resource
Description
AUTOSAR Tutorial
AUTOSAR – Input Descriptions (3 of 3)
Step 1c): Description of system

System Description
ƒ Network topology
- bus systems: CAN, LIN, FlexRay
- connected ECUs, Gateways
- power supply, system activation
System Information
overall system ƒ Communication (for each channel)
- bus systems, protocols, - K-matrix
communication matrix and - gateway table
attributes (e.g. data rates, timing, …) ƒ Mapping / Clustering of SW
- function clustering components
- function deployment
(distribution to ECU)
- ...

System-
AUTOSAR-Description
Description
Editor

= tool based

47 Oct. 23rd 2008 AUTOSAR Tutorial

AUTOSAR – System Configuration
Step 2: Distribution of SW-Component-Descriptions to ECU

¾ Configuration on the basis of descriptions (not on the basis of implementations!) of SW-

Components, ECU-Resources and System-Description
¾ Consideration of ECU-Resources available and constraints given in the System-
Description

Description
„v_warn()“

Configuration-

SW Com-

SW Com-
„get_v()“

ponent n
ponent 3
Description

Description
Description

Description
Descript.
Configuration-
ECU1

System-
- Description
Descript.
Configuration-
1,
ECU2

... - Description
Descript.
- Description 2, 5,ECUm
- Description
- ... - Description 6, k,
- ... - Description n,
- Resources
- ...
- ... - Ressources
- ... - Ressources

...
AUTOSAR-System Definition (Distribution of SW-Compo- - ...
nent-Descriptions considering resources available)

SystemDescription
ECU-Resource

ECU-Resource
ECU-Resource

ECU-Resource
- e.g. mapping of signals
ECU m
-Description

-Description
-Description

-Description
ECU 2

ECU 3
ECU 1

...
to CAN matrices
- ...

= tool based an iterative process

48 Oct. 23rd 2008 AUTOSAR Tutorial

AUTOSAR – ECU-Configuration
Step 3: Generation of required configuration for AUTOSAR-Infrastructure per ECU

AUTOSAR-Configuration
ECU1

Configuration-
System Description configuration of
Descript. ECU1 the AUTOSAR-RTE
- Description 1, - e.g. mapping of signals
- Description 2, to CAN matrices
- ... configuration of
- ... AUTOSAR OS
- Resources
configuration
of MCAL
AUTOSAR - ECU Configuration Generator

Configuration
AUTOSAR-RTE-Config-Info of COM stack

- communication mechanisms
- transport protocols
etc
- ...

= tool based

49 Oct. 23rd 2008 AUTOSAR Tutorial

AUTOSAR – Generation of Software Executables
Step 4: Based on the configuration information for each ECU (example ECU1)

Application SW AUTOSAR-Library
Body of the - communication
SW components - transport protocols, ...
(code, macros, Objects, ...)

SW-Components ECU1
AUTOSAR-Configuration (derived partially from the Virtual Function Bus)
ECU1 Tooling

AUTOSAR-
configuration of AUTOSAR-RTE
RTE
the AUTOSAR-RTE
Generator

configuration of OS
AUTOSAR OS Generator OS

configuration MCAL-
MCAL COM
of MCAL Generator

Basic system functions

Configuration COM core functions, drivers
of COM stack Generator
Hardware

50 Oct. 23rd 2008 AUTOSAR Tutorial

AUTOSAR Metamodel
Formal description of all methodology related information

¾ The metamodel is modeled in UML

¾ The structure of the information can be METAMODEL

clearly visualized
SW- Datatype
Component
¾ The consistency of the information is Interface
guaranteed

¾ Using XML, a data exchange format can be MODEL

generated automatically out of the
Mirror Mirror
metamodel Adjustment Actuator

51 Oct. 23rd 2008 AUTOSAR Tutorial

AUTOSAR Metamodel

¾ The AUTOSAR Metamodel

„ is the backbone of the AUTOSAR architecture definition
„ contains complete specification, how to model AUTOSAR systems

cd Package Overview
M3: Model of the Metamodel
GenericStructure
(Meta-Metamodel)
(Defines UML Modeling Elements)

M2: Model of the model

(Metamodel)
(Defines AUTOSAR Modeling Elements)
SWComponentTemplate ECUResourceTemplate

M1: Model of the system

(Defines a real system)

SystemTemplate

M0: Realized System in the car

(Implements a real system)

52 Oct. 23rd 2008 AUTOSAR Tutorial

AUTOSAR Metamodel and Methodology

ConnectorPrototype
AssemblyConnectorPrototype

.XML .XML
0..* 0..*
PortPrototype
Configure PortPrototype
+provider
RPortPrototype
PPortPrototype +requester
ECU Extract ECU ECU 1
1
of System Configuration
Configuration Description +pPort * +rPort *

:System
+requiredInterface 1
+providedInterface
ARElement
1

¾ Methodology
PortInterface

+ isService: Boolean

„ defines activities and work-products

„ is integrated in the metamodel

¾ Metamodel defines content of work-products

SenderReceiv erInterface

„ Formal description of all the information that

is produced or consumed in the AUTOSAR +interface 1

methodology +dataElements 1..*

„ Benefit of using the metamodel: DataPrototype

DataElementPrototype

ƒ No inconsistencies + infoType: Enumeration{data, event}

ƒ Easy maintenance
ƒ Consistent terminology

53 Oct. 23rd 2008 AUTOSAR Tutorial

AUTOSAR Methodology – Conclusion

The E/E system architecture can be described by means of

1
AUTOSAR.

The meta model approach and the tool support for specifying the
2 AUTOSAR information model allow working at the right level of
abstraction.

A methodology to integrate AUTOSAR software modules has been

3 designed.

AUTOSAR pushes the paradigm shift from an ECU based approach to

4 a function based approach in automotive software development.

54 Oct. 23rd 2008 AUTOSAR Tutorial

 Main Concepts: Application Interfaces
¾ Standardization approach
¾ Current stage of standardization

55 Oct. 23rd 2008 AUTOSAR Tutorial

AUTOSAR Application Interfaces

Application Actuator Sensor Application

Software
Component
Software
Component
Software
Component
AUTOSAR Software
Component
Application
AUTOSAR AUTOSAR AUTOSAR Software AUTOSAR
Layer
Interface Interface Interface
.............. Interface

AUTOSAR Runtime Environment (RTE)

Standardized
Standardized Syntax of
Standardized Interfaces:
AUTOSAR AUTOSAR
AUTOSAR
Interface
Interface ƒ Meta-model,
Interface InterfaceSoftware Component
Interface Template
Services
ƒ Supporting
Communi- ECUtransferability within the network
cation Abstraction
Standardized Standardized Standardized
Standardized

Interface Interface Interface

Interface

Complex
Operating
Device
System Semantics of Interfaces: Drivers
Standardized
ƒ Physical properties, units, etc.
Interface
Basic re-use
ƒ Supporting Software
across product
Micro- lines
controller
ƒ In scope of AUTOSAR workpackages
Abstraction specifying application
interfacesECU-Hardware

56 Oct. 23rd 2008 AUTOSAR Tutorial

OEM Use case

¾ SHORT TERM: OEM is applying AUTOSAR Naming Convention more than 10.000
interfaces and calibrations data for industrial purposes after two years of intensive work
on the specification of the naming convention
¾ Middle Term: Results are foreseen as an “AUTOSAR Application Interfaces Handbook”
to support internal design & development of vehicle functions as much as support for
exchange in project where suppliers are tied.
Application Actuator Sensor Application
Software Software Software Software
Component Component Component AUTOSAR Component

AUTOSAR AUTOSAR AUTOSAR

Software AUTOSAR

AUTOSAR software
Interface Interface Interface Interface

AUTOSAR Runtime Environment (RTE)

Standardized
layered architecture
Standardized
Interface
AUTOSAR
Interface
Standardized
Interface ..............
AUTOSAR
Interface
AUTOSAR
Interface

ECU
integrated by TIER- B
Application behaviour
Services Communication Abstraction

SW-C X.y Standardized

Interface
Standardized
Interface
Standardized
Interface

Standardized
Inteface
developed by TIER-B wrt OEM
Complex
Operating
Device
System
Drivers

Basic Software Standardized

Interface

interfaces
10.x interfaces functional specifications Microcontroller
Abstraction

ECU-Hardware
OEM Components
interfaces
specifications integrate Application
Software
Actuator
Software
Sensor
Software
Application
Software
AUTOSAR
several application
Component Component Component Component

Software

X.y
SW-C X.z
AUTOSAR
Interface
AUTOSAR
Interface
AUTOSAR
Interface
AUTOSAR
Interface
AUTOSAR software
interfaces AUTOSAR Runtime Environment (RTE)
layered architecture
Application behaviour Standardized
Standardized
AUTOSAR
Standardized
..............
AUTOSAR AUTOSAR

integrated by TIER-A
developed by TIER-A wrt OEM
Interface Interface Interface Interface
Interface

ECU
Services Communication Abstraction

10.x interfaces
interfaces functional specifications Standardized
Interface
Standardized
Interface
Standardized
Interface

Standardized
XML

Inteface
Complex
Operating
Device
System
Drivers

Basic Software Standardized

Interface

Microcontroller
Abstraction

ECU-Hardware

Use of standardized application interfaces increase quality on exchange with

suppliers and improve software integration from system standpoint.

57 Oct. 23rd 2008 AUTOSAR Tutorial

Supplier Use case

¾ Specification of application interfaces will support integration of SW-components.

OEM_N
OEM_2
Components
Components
interfaces
OEM_1 interfaces
specifications
Components specifications
integrate several
interfaces integrate several
application
specifications application
interfaces
integrate several interfaces
application XML
interfaces
XML
XML
k
h o u l d wor
S pt
t attem
Application Actuator Sensor Application
Software Software Software Software
Component Component Component AUTOSAR Component

a t f ir s AUTOSAR
Interface
AUTOSAR
Interface
AUTOSAR
Interface
Software AUTOSAR
Interface

SW-C X.y AUTOSAR Runtime Environment (RTE)

..............
Standardized
Standardized Standardized AUTOSAR AUTOSAR
AUTOSAR
Interface Interface Interface Interface
Interface

ECU
Services Communication Abstraction

Standardized Standardized Standardized

Interface Interface Interface

Standardized
Inteface
10.x interfaces
Complex
Operating
Device
System
Drivers

Basic Software Standardized

Supplier
Interface

Microcontroller
Abstraction

ECU-Hardware
SW-C Model and implement only
once
container

Use of 10.x application interfaces increase quality on integration, i.e. they

prevent from inconsistencies.

58 Oct. 23rd 2008 AUTOSAR Tutorial

To ease the re-use of software components across several OEMs, AUTOSAR proceeds on the
standardization of the application interfaces agreed among the partners.

Example
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).
Coordinate system according to ISO
Base Sensor Signals
I1

Interface of ESP
8855
and VLC

Ínterface of ESP and

I4
Vehicle
Vehicle Data Type S16
external yaw rate Longitudinal
Longitudinal
Controller
Controller
Integer Range
controller

2nd
2nd Yaw
Yaw I6
ESP
ESP -32768..+32767
Standard Signals
Rate
Rate Controller
Controller SW-Component
SW-Component
Physical Range -2,8595..+2,8594
from ESP
I2

Physical Offset 0
Information signals
from other functions /
System-level Brake domains
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)

59 Oct. 23rd 2008 AUTOSAR Tutorial

Glance on Application Interfaces – Body Domain

¾ CmdWashing is the interface defined by following information:

„ It is provided by the WiperWasherManager component through the
[Washer]Activation port
„ CmdWashing contains one data element command
„ Command is of type t_onoff
„ t_onoff is a RecordType, which describes a generic on/off information

60 Oct. 23rd 2008 AUTOSAR Tutorial

AUTOSAR Application Interfaces
Compositions under Consideration

„ Body Domain ƒ Exterior Lights

ƒ Central Locking ƒ Defrost Control
ƒ Interior Light ƒ Seat climatization
ƒ Mirror Adjustment ƒ Cabin climatization
ƒ Mirror Tinting ƒ Steering wheel climatization
ƒ Seat Adjustment ƒ Window Control
ƒ Wiper/Washer ƒ Sunroof/Convertible control
ƒ Anti Theft Warning System ƒ Steering column adjustment
ƒ Horn Control ƒ Roller blind control

„ Chassis Control Domain „ Powertrain Domain

ƒ Vehicle Longitudinal Control
ƒ Electronic Stability Program
ƒ Electronic Parking Brake
ƒ Adaptive Cruise Control
ƒ Roll Stability Control
ƒ Steering System
ƒ Suspension System
ƒ Stand Still Manager
ƒ High Level Steering
ƒ Vehicle Stability Steering
ƒ Driver Assistance Steering
ƒ All Wheel Drive/ Differential Lock
ƒ Powertrain Coordinator
ƒ Transmission System
ƒ Combustion Engine
ƒ Engine torque and mode management
ƒ Engine Speed And Position
ƒ Combustion Engine Misc.
ƒ Electric Machine
ƒ Vehicle Motion Powertrain
ƒ Driver Request
ƒ Accelerator Pedal Position
ƒ Safety Vehicle Speed Limitation

61 Oct. 23rd 2008 AUTOSAR Tutorial

Major task: Conflict Resolution - Example Vehicle Speed
DataElement
Body Domain Name DataType
VehicleSpeed value t_VehiculeSpeed
CentralLockingMaster ? Min Bit size; Res; phys low; phys up; Unit
Uint12 0.1 0.0 0.0 403.4 km/h
InteriorLight
DataElement
Name DataType OK
ActualVehicleSpeed VehicleSpeed
Powertrain Domain
Min Bit; size; Res; phys low; phys up; Unit
ActualVehicleSpeed Uint16 0.00781 0 0 511.992 km/h
DriverReq

OK
Chassis Domain
ActualVehicleSpeed
CentralLockingMaster
VehicleLongSpeed DataElement
Name DataType
ESP ACC VehicleLongSpeed VehicleLongitudinalSpeed
Steering
SSM Min Bit; size; Res; phys low; phys up; Unit
Suspension ?? ?? ?? ?? ?? ??
EPB
… ?
VLC

62 Oct. 23rd 2008 AUTOSAR Tutorial

AUTOSAR Application Interfaces – Conclusion

For several domains a subset of application interfaces has been

1
standardized to agreed levels.

It is a challenge to align standardization with the pace of application

2 development.

63 Oct. 23rd 2008 AUTOSAR Tutorial

 Wrap-up

64 Oct. 23rd 2008 AUTOSAR Tutorial

Distribution on ECUs
SwitchEvent LightRequest
LightRequest Front-Light Manager Xenonlight
check_switch () switch_event(even request_light(type, mode) set_light(type, mode)
t) get_keyposition()
switch_event request_light
set_light(type, mode) set_current (…)
(event) (type, mode)

AUTOSAR Int. AUTOSAR

AUTOSAR Interface
Interface AUTOSAR Interface AUTOSAR Interface

AUTOSAR RTE
Standardized Std. AUTOSAR Standardized AUTOSAR AUTOSAR
Interface Interface Interface Interface Interface
Communi- ECU
Services cation Abstraction
Standardized

Std. Interface Std. Interface Std. Interface

Interface

Complex
Operating Device
System Drivers
Standardized Interface
DIO PWM
DIO CAN Driver

Microcontroller Abstraction
ECU-Hardware

65 Oct. 23rd 2008 AUTOSAR Tutorial

 Use case ‘Front-Light Management’ in AUTOSAR
SwitchEvent LightRequest Front-Light Manager Xenonlight
check_switch () switch_event(event) request_light(type, mode) set_light(type, mode)
get_keyposition()
switch_event request_light
set_light(type, mode) set_current (…)
(event) (type, mode)

AUTOSAR Int. AUTOSAR Interface AUTOSAR Interface AUTOSAR Interface

AUTOSAR RTE AUTOSAR RTE AUTOSAR RTE

Std. AUTOSAR AUTOSAR Standardized Standardized Standardized AUTOSAR
Interface Interface Interface Interface Interface Interface
ECU Communi- Communi- Communi- ECU
Services Abstraction cation cation cation Abstraction
Std. Interface Std. Interface Std. Interface Std. Interface Std. Interface Std. Interface

Standardized Interface Standardized Interface Standardized Interface

DIO CAN Driver CAN Driver CAN Driver PWM

Microcontroller Abstraction Microcontroller Abstraction Microcontroller Abstraction

ECU-Hardware ECU-Hardware ECU-Hardware

CAN Bus

66 Oct. 23rd 2008 AUTOSAR Tutorial

Automotive Software Development will change.

Conventional, by now AUTOSAR

Application Software
Software
standardized
AUTOSAR
HW-specific
Hardware
Hardware

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

 Development processes will be simplified.
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.

67 Oct. 23rd 2008 AUTOSAR Tutorial

 AUTOSAR Outlook

¾ AUTOSAR is ready to be used automotive product development

¾ Exploitation has already started
¾ AUTOSAR welcomes new members

¾“Cooperate on standards, compete on implementation.”

68 Oct. 23rd 2008 AUTOSAR Tutorial

Thank you for your attention!

http://www.autosar.org

request@autosar.org

69 Oct. 23rd 2008 AUTOSAR Tutorial