Hardware-independent

Software Development with AUTOSAR

Dr. Stefan Bunzel AUTOSAR Spokesperson (Continental)
8. Workshop Automotive Software Engineering
30 September, 2010, Leipzig

Overview

Introduction to AUTOSAR

Overview on AUTOSAR Architecture

AUTOSAR Development Methodology

30 September, 2010

Hardware-independent Software Development with AUTOSAR

AUTOSAR Vision
AUTOSAR aims to improve complexity management of integrated E/E architectures
through increased reuse and exchangeability of SW modules between OEMs and suppliers.
OEM b

OEM a

Platform a.1
Platform a.2
Platform a.n

Exchangeability
between
manufacturers
applications
OEM f

Exchangeability
between
OEM c
suppliers
solutions

Platform b.1
Platform b.2
Platform b.n

Supplier A

Chassis

Safety

Body/
Comfort

Platform c.1
Platform c.2
Platform c.n

Supplier B

Chassis

Safety

Telematics

OEM d

Supplier C

Body/Comfort

Powertrain

Telematics

Platform d.1
Platform d.2
Platform d.n

OEM e

Exchangeability
between vehicle
platforms

Platform f.1
Platform f.2
Platform f.n
Platform e.1
Platform e.2
Platform e.n
3

30 September, 2010

Hardware-independent Software Development with AUTOSAR

AUTOSAR Vision
AUTOSAR aims to standardize the software architecture of ECUs.
AUTOSAR paves the way for innovative electronic systems that further improve
performance, safety and environmental friendliness.

Yesterday

Customer needs

AUTOSAR
Application Software

Software

 Adaptive Cruise Control

 Lane Departure
Warning
 Advanced Front
Lighting System


standardized
Using standards
HW-specific

Hardware

Hardware






Communication Stack
OSEK
Diagnostics
CAN, FlexRay

Hardware and software will be widely independent of each other.

Development can be de-coupled by horizontal layers. This reduces development time
and costs.

The reuse of software increases at OEM as well as at suppliers. This enhances quality
and efficiency.
4

30 September, 2010

Hardware-independent Software Development with AUTOSAR

AUTOSAR Core Partners and Members

11 Development
Members

9 Core Partners

63 Associate Members
6 Attendees

47 Premium Members

General
OEM

Generic
Tier 1

Standard
Software

Tools and
Services

Status 22 September 2010. Up-to-date status see: http://www.autosar.org

5

30 September, 2010

Hardware-independent Software Development with AUTOSAR

Semiconductors

9 Project Objectives and 3 Main Working Topics

PO1:
Implementation and
standardization of basic system
functions as an OEM wide
Standard Core solution

PO5:
Maintainability throughout the
whole Product Life Cycle

Architecture

PO2:
Scalability to different vehicle
and platform variants
PO3:
Transferability of
functions throughout
network

Application
Interfaces

PO7:
Software updates and
upgrades over vehicle
lifetime

Methodology

PO4:
Integration of functional
modules from multiple
suppliers

30 September, 2010

PO6:
Increased use of Commercial
off the shelf hardware

PO8:
Consideration of
availability and safety
requirements
PO9:
Redundancy activation

Hardware-independent Software Development with AUTOSAR

AUTOSAR
Specifications vs. Products
Core Partners,
Premium, and
Development Members
Develop

AUTOSAR compliant products

SW modules
Tools

ECUs
Cars

Members

Partnership

Cooperate on standards,
compete on implementation.

Build

Apply

Core Partners,
Premium, Development,
and Associate Members
7

30 September, 2010

AUTOSAR Standard
Specifications
Architecture
Methodology
Appl. Interfaces
AUTOSAR Releases
R4.0, R3.2, R3.1,

Hardware-independent Software Development with AUTOSAR

Overview

Introduction to AUTOSAR

Overview on AUTOSAR Architecture

AUTOSAR Development Methodology

30 September, 2010

Hardware-independent Software Development with AUTOSAR

AUTOSAR Layered ECU Software Architecture

Application Layer

AUTOSAR Runtime Environment (RTE)

System Services

Memory
Services

Onboard
Memory
Device
Hardware
Abstraction Abstraction
Microcontroller
Drivers

Memory
Drivers

Communication
Services

I/O
Complex
Hardware
Drivers
Abstraction

I/O Drivers

Microcontroller
10

30 September, 2010

Services

ECU
Abstraction
and Complex
Drivers

Comm.
Hardware
Abstraction
Communication
Drivers

BSW-Layers

Hardware-independent Software Development with AUTOSAR

Microcontroller
Abstraction

Abstraction inside the Infrastructure Architecture

Example: Memory stack
Equal mechanisms to access internal
(on-chip) and external (on-board)
memory devices and type of memory
hardware (EEPROM, Flash)

Abstracts from the location of

peripheral memory devices (on-chip
or on-board) and the ECU hardware
layout.
Memory Services

NVRAM Manager
Application Layer

AUTOSAR Runtime Environment (RTE)

System Services

Memory Services

Communication
Services

Memory Hardware Abstraction

I/O Hardware
Abstraction

Complex
Drivers

Memory Abstraction Interface

Onboard Device
Abstraction

Memory Hardware
Abstraction

Communication
Hardware Abstraction

Microcontroller Drivers

Memory Drivers

Communication
Drivers

Flash EEPROM
Emulation

EEPROM Abstraction
I/O Drivers

External
Flash Driver

External
EEPROM Driver

Microcontroller

COM Drivers

Memory Drivers

SPIHandler
Driver

SPI

11

30 September, 2010

Hardware-independent Software Development with AUTOSAR

EEPROM
Driver

EEPROM

Internal
Flash
Driver

Flash

Abstraction inside the Infrastructure Architecture

Example: CAN communication stack
CAN Communication Services
provide a uniform interface to the
CAN network. Hide protocol and
message properties from the
application.

Communication Services
Generic NM
Interface

Debugging

Diagnostic
Com.
Manager

AUTOSAR
COM

CAN
State
Manager

PDU Router
IPDU
Multiplexer

Application Layer

CAN NM

CAN Transport
Protocol
J1939 Transport
Protocol

AUTOSAR Runtime Environment (RTE)

System Services

Memory Services

Communication
Services

Onboard Device
Abstraction

Memory Hardware
Abstraction

Communication
Hardware Abstraction

Microcontroller Drivers

Memory Drivers

Communication
Drivers

Microcontroller

I/O Hardware
Abstraction

Complex
Drivers

Communication Hardware Abstraction

CAN Interface

I/O Drivers

CAN Transceiver
Driver

Driver for ext.

CAN ASIC

I/O Drivers
DIO Driver

Communication Drivers
SPIHandler
Driver

SPI

External
CAN Controller

12

30 September, 2010

Hardware-independent Software Development with AUTOSAR

CAN Driver

CAN

Overview

Introduction to AUTOSAR

Overview on AUTOSAR Architecture

AUTOSAR Development Methodology

13

30 September, 2010

Hardware-independent Software Development with AUTOSAR

AUTOSAR Architecture

Breakdown to /
Implementation on
ECU

Layered Software Architecture

Application Layer
AUTOSAR Runtime Environment (RTE)
Complex
Drivers

Services Layer
ECU Abstraction Layer

ECU Software Architecture

Microcontroller Abstraction Layer

Application
Software
Component

Actuator
Software
Component

Hardware

AUTOSAR
Interface

AUTOSAR
Interface

Sensor
Software
Componen
t
AUTOSAR
Interface

AUTOSAR
Software

..............

Application
Software
Componen
t
AUTOSAR
Interface

AUTOSAR Runtime Environment

Standardized
Interface

Standardized
Interface

Operating
System

Standardized
AUTOSAR
Interface

Standardized
Interface

Services

Communication

Standardized
Interface

Standardized
Interface

Basic Software

AUTOSAR
Interface
ECU
Abstraction
Standardized
Interface

Standardized
Interface
Microcontr.
Abstraction

ECU-Hardware

14

30 September, 2010

Hardware-independent Software Development with AUTOSAR

AUTOSAR
Interface

Complex
Device
Drivers

SWC
Description

SWC
Description

AUTOSAR
SWC
n

SWC
Description

AUTOSAR
SWC
2

AUTOSAR
SWC
1

SWC
Description

AUTOSAR
SWC
3

AUTOSAR
SWC
1

AUTOSAR Development Methodology

Virtual Functional Bus Concept

...

Virtual Functional Bus

15

30 September, 2010

Application software functionality implemented in

Software Components (SWC)

Handling of vehicle wide functions, independent
from ECUs or network

SWCs can communicate between each other and
access functions from the standardized set of
infrastructure functions

Communication needs of a SWC are formally
described in a standard template,
i.e. the SWC Description

Any SWC interaction runs via Ports, which
implement different communication paradigms,
e.g. sender-receiver or client-server

The VFB
 enables a virtual integration of SWCs and
 allows to formally verify structural and
dynamic compatibility of SWCs

Hardware-independent Software Development with AUTOSAR

AUTOSAR Development Methodology

Virtual Functional Bus Concept Ports and Interfaces

PPort, provides a Sender-Receiver Interface

SWC
Description

SWC
Description

SWC
Description

SWC
Description

RPort, requires a Sender-Receiver Interface

AUTOSAR SWC

...

AUTOSAR
SWC
n

AUTOSAR
SWC
3

AUTOSAR
SWC
2

AUTOSAR
SWC
1

PPort, provides a Client-Server Interface,

i.e. implements service
RPort, requires a Client-Server Interface,
i.e. client of a service
PPort, provides a Calibration Interface
RPort, requires a Calibration Interface
PPort, provides data to AUTOSAR Service
RPort, requires data from AUTOSAR Service
PPort, provides AUTOSAR Service
(in BSW only)

Virtual Functional Bus

16

30 September, 2010

Hardware-independent Software Development with AUTOSAR

RPort, requires AUTOSAR Service as client

AUTOSAR Development Methodology

Principle

...

SWC
Description

AUTOSAR description
templates:
 SWC description:
application software
 ECU description:
ECU characteristics and
configuration
 System description:
network and assignment of
SWCs to ECUs

Descriptions for
 SWCs
+
 ECUs
+
 system description


allow a tool-based
deployment of SWCs to ECUs

AUTOSAR
SWC
n

AUTOSAR
SWC
3

AUTOSAR
SWC
2

AUTOSAR
SWC
1

SWC
SWC
SWC
Description Description Description

Virtual Functional Bus

ECU I

ECU
Description

AUTOSAR
SWC
2

AUTOSAR
SWC
1

AUTOSAR
SWC
3

ECU II

ECU
Description

ECU m

...

AUTOSAR
SWC
n

ECU
Description

RTE

RTE

RTE

Basic
Software

Basic
Software

Basic
Software

Gateway

FlexRay

17

30 September, 2010

CAN

System
Description

Hardware-independent Software Development with AUTOSAR

AUTOSAR Development Methodology

Development steps

From functional level to the ECU binaries.
Functional
architecture
level

Component modeling
Data model development
VFB Timing
Develop
VFB System Description

Physical
architecture
level

Design
System

System topology
Network
Mapping of
components to ECUs

Internal behavior
Implementation
Component timing
Develop
Application Software
Component

BSW implementation
Configuration
Deliver
Basic Software

Generate
ECU Extract

Build
ECU Software

18

30 September, 2010

Hardware
dependent

Hardware
independent

Hardware-independent Software Development with AUTOSAR

AUTOSAR Methodology and Templates

Overview

The AUTOSAR Methodology provides all descriptions necessary to describe all components of a
system..
System Level
.XML

System
Constraints
Description

Work product, e.g. XML-, C-, or binary file

.XML

Configure
System

Activity, consuming or producing a work product

System
Configuration
Description

.XML

ECU
related
templates

Object flow, input to or produced by activities

Referencing, using, or reading work products
Extract
ECU-Specific
Information

ECU Level
.XML

ECU
Extract
of
System
Configuration

.XML

Configure
ECU

ECU
Configuration
Description

Component Level
.XML

Software
Component
Description

19

30 September, 2010

.XML

Implement
Component

Implemented
Component

Hardware-independent Software Development with AUTOSAR

. exe

Generate
Executable

ECU
Executable

AUTOSAR
SWC
3

ECU x
AUTOSAR
SWC
1

AUTOSAR Methodology and Templates

RTE Generation Process

RTE
Basic
Software

20

30 September, 2010

Hardware-independent Software Development with AUTOSAR

AUTOSAR Application Interfaces

Above the RTE the software architecture
style changes from layered to component
style.
Standardized, openly disclosed interfaces

HW independent SW layer

Transferability of functions

RTE

Services Layer
Complex
Drivers

Application Layer

ECUAbstraction
AbstractionLayer
Layer
ECU
Microcontroller Abstraction Layer
Microcontroller

21

Application
Software
Component

Actuator
Software
Component

Sensor
Software
Component

Sensor
Software
Component

AUTOSAR
Interface

AUTOSAR
Interface

AUTOSAR
Interface

AUTOSAR
Interface

30 September, 2010

Application Layer

Hardware-independent Software Development with AUTOSAR

Application
Software
Component
AUTOSAR
Interface

AUTOSAR Development Methodology

Standardized Application Interfaces

AUTOSAR R4.0 Specification: Table of Application Interfaces

Mirror
Mirror Adjustment
Adjustment

MirrorPosition
MirrorMoveStatus

40 Compositions

2500 Ports

MirrPosnSts1

570 Interfaces

Records
Continuous Values
Enumerations
Arrays

770 Data types

MirrPosnSts1

Mirror
Adjustment

MirrAxisPosn1
Mirror type
Axis type
Position

22

30 September, 2010

Hardware-independent Software Development with AUTOSAR

m
sec
Percent

26 Units

Enumeration
0: no axis
1: horizontal axis
2: vertical axis
Continuous Value: perc7
Recommended type: UInt14
Unit: Percent
Range: 0,1 .. 1001,0
Resolution: 0,1

AUTOSAR Standardized Application Interfaces

Re-Use of SW-Components
To ease the re-use of software components across several OEMs, AUTOSAR proceeds on the
standardization of application interfaces.
Port Name

Example

ESP-Sensors
ESP-Sensors
Base Sensor Signals

2nd
2nd Yaw
Yaw
Rate
Rate Controller
Controller

I6

Port Name

YawRateBase

Description

Yaw rate measured along vehicle z- axis

(i.e. compensated for orientation).
Coordinate sys. according to ISO 8855.

Appl. Interface

YawRate1

I1
Interface of ESP
and VLC

nterface of ESP and

external yaw rate
controller

I4

ESP
ESP
SW-Component
SW-Component

System-level Brake
Actuator Interface

Vehicle
Vehicle
Longitudinal
Longitudinal
Controller
Controller

Data element: YawRate

Data Type: AngleSpeed3
Minimal bits size: SInt16
Physical Range: -5,..+5,
Physical offset: 0
Unit: rad/sec

Standard Signals
from ESP

I2

I3

Information signals
from other functions /
domains

Command signals to
other functions /
domains

I7
I5

Remarks

This data element can also be used to

instantiate a redundant sensor interface.
Range might have to be extended for
future applications (passive safety).

Brake
Brake Actuator
Actuator

Standardized application interfaces on

system level
(ESP-system, chassis domain)

23

LongAccBase

30 September, 2010

Port Name

Hardware-independent Software Development with AUTOSAR

RollRateBase

Software Architecture AUTOSAR Defined Interfaces

Use Case Front Light Management mapped to AUTOSAR architecture
Integrator
SwitchEvent
check_switch ()

Supplier B

OEM

Supplier A

LightRequest

Front-Light Manager

Headlight

switch_event(event)

request_light(type, mode)

set_light(type, mode)

get_keyposition()
set_light(type, mode)
set_dboard(type, mode)

switch_event
(event)

request_light
(type, mode)

AUTOSAR Int.

AUTOSAR Interface

set_current ()

AUTOSAR Interface

AUTOSAR Interface

24

Standardized
Interface

Operating
System

Standardized
Interface

Silicon vendor A

Integrator

AUTOSAR RTE
Std. AUTOSAR
Interface

Standardized
Interface

AUTOSAR
Interface

Services

Communication

ECU
Abstraction

Std. Interface

Std. Interface

Std. Interface
Complex
Device
Drivers

Standardized Interface
DIO

PWM

CAN Driver

Microcontroller Abstraction

ECU-Hardware

30 September, 2010

AUTOSAR
Interface

Hardware-independent Software Development with AUTOSAR

Software Architecture AUTOSAR Defined Interfaces

Use Case Front Light Management: Exchange type of Front Light
Integrator
SwitchEvent
check_switch ()

Supplier B

OEM

Supplier C
A

LightRequest

Front-Light Manager

Xenonlight
Headlight

switch_event(event)

request_light(type, mode)

set_light(type,
set_light(type, mode)
mode)

get_keyposition()
set_light(type, mode)
set_dboard(type, mode)

switch_event
(event)

request_light
(type, mode)

AUTOSAR Int.

AUTOSAR Interface

set_current ()
()
set_current

AUTOSAR Interface

AUTOSAR Interface

25

Standardized
Interface

Operating
System

Standardized
Interface

Silicon vendor B
A

Integrator

AUTOSAR RTE
Std. AUTOSAR
Interface

Standardized
Interface

AUTOSAR
Interface

Services

Communication

ECU
Abstraction

Std. Interface

Std. Interface

Std. Interface
Complex
Device
Drivers

Standardized Interface
DIO

DIO
PWM

CAN Driver

Microcontroller Abstraction

ECU-Hardware

30 September, 2010

AUTOSAR
Interface

Hardware-independent Software Development with AUTOSAR

AUTOSAR Application Interfaces

Supplier Use Case

Specification of application interfaces will support integration of SW-components.
OEM_1
Components
interfaces
specifications
integrate
several
application
interfaces

.xml

OEM_2
Components
interfaces
specifications
integrate several
application
interfaces

.xml

OEM_N
Components
interfaces
specifications
integrate
several
application
interfaces

.xml
Application
Software
Component

Actuator
Software
Component

Sensor
Software
Component

AUTOSAR
Interface

AUTOSAR
Interface

AUTOSAR
Interface

AUTOSAR
Software

Application
Software
Component

AUTOSAR
Interface

AUTOSAR Runtime Environment (RTE)

SWC X.y

Standardized
Interface

Supplier
SWC
container

Interfaces

Standardized
Inteface

Operating
System

..............

Standardized
AUTOSAR
Interface

Standardized
Interface

Services

Communication

ECU
Abstraction

Standardized
Interface

Standardized
Interface

Standardized
Interface

Basic Software

AUTOSAR
Interface

AUTOSAR
Interface

Complex
Device
Drivers
Standardized
Interface

Microcontroller
Abstraction

Model and implement only once

ECU-Hardware

Use of AUTOSAR application interfaces increase quality on integration, i.e. they prevent from
inconsistencies.

26

30 September, 2010

Hardware-independent Software Development with AUTOSAR

Summary

AUTOSAR has become a global standard for embedded automotive software,
providing specifications for


Software architecture

Development methodology

Standardized application interfaces

...

AR
SWC
n

AR
SWC
3

AR
SWC
2

AR
SWC
1

Layered software
architecture

Hardware-independent
development of application functions

Early virtual integration of the

entire vehicles application functions

Virtual Functional Bus

AUTOSAR is a key enabler for managing the growing E/E complexity

First series cars with AUTOSAR technology are on the road
27

30 September, 2010

Hardware-independent Software Development with AUTOSAR

Thank you for your attention!

http://www.autosar.org

request@autosar.org

Become a member and get exploitation

rights for the
AUTOSAR standard.

Published Releases

For information only, see disclaimer.

28

30 September, 2010

Hardware-independent Software Development with AUTOSAR