hardware-independent software development with autosar · 3 30 september, 2010 hardware-independent...

Hardware-independent Software Development with AUTOSAR

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

Hardware-independent Software Development with AUTOSAR30 September, 20102

Overview

� Introduction to AUTOSAR

� Overview on AUTOSAR Architecture

� AUTOSAR Development Methodology


OEM f

Exchangeabilitybetween suppliers’solutions

Exchangeabilitybetween vehicle platforms

Exchangeabilitybetween manufacturers’applications

Platform d.nPlatform d.2Platform d.1

Platform e.nPlatform e.2Platform e.1

Platform f.nPlatform f.2Platform f.1

Platform c.nPlatform c.2Platform c.1

Platform a.nPlatform a.2Platform a.1

OEM e

OEM a

Platform b.nPlatform b.2Platform b.1

OEM b

OEM d

OEM c

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.

Supplier A

�Chassis

�Safety

�Body/Comfort

Supplier B

�Chassis

�Safety

�Telematics

Supplier C

�Body/Comfort

�Powertrain

�Telematics


� 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.

Yesterday

Application Software

Hardware

standardized

HW-specific

AUTOSARCustomer needs� Adaptive Cruise Control� Lane Departure

Warning� Advanced Front

Lighting System� …

Using standards� Communication Stack� OSEK� Diagnostics� CAN, FlexRay

Hardware

Software

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.

AUTOSAR Vision


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

AUTOSAR – Core Partners and Members

63 Associate Members6 Attendees

9 Core Partners

GeneralOEM

StandardSoftware

Semi-conductors

Tools andServices

GenericTier 1

11 Development Members

47 Premium Members


9 Project Objectives and 3 Main Working Topics

ApplicationInterfaces

Methodology

Architecture

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

PO2: Scalability to different vehicle and platform variants

PO3:Transferability of functions throughout network

PO4:Integration of functional modules from multiple suppliers

PO5:Maintainability throughout the whole “Product Life Cycle“

PO6:Increased use of “Commercial off the shelf hardware“

PO7:Software updates and upgrades over vehicle lifetime

PO8:Consideration of availability and safety requirements

PO9:Redundancy activation


AUTOSAR

Specifications vs. Products

Core Partners, Premium, and Development Members

AUTOSAR StandardSpecifications• Architecture• Methodology• Appl. Interfaces�AUTOSAR Releases

R4.0, R3.2, R3.1, …

Develop

Core Partners, Premium, Development, and Associate Members

Apply

AUTOSAR compliant products • SW modules• Tools• …

Build

• ECUs• Cars• …

Members Partnership

Cooperate on standards, compete on implementation.


Overview





Microcontroller

AUTOSAR Runtime Environment (RTE)

Micro-

controller

Drivers

Memory

Drivers

I/O DriversCommuni-

cation

Drivers

Complex

Drivers

I/O

Hardware

Abstraction

Memory

Hardware

Abstraction

Onboard

Device

Abstraction

Comm.

Hardware

Abstraction

Memory

Services

System Services Communi-

cation

Services

Application Layer

AUTOSAR Layered ECU Software Architecture

Micro-controller

Abstraction

ECU Abstraction

and Complex Drivers

Services

BSW-Layers


Memory Services

NVRAM Manager

Abstraction inside the Infrastructure ArchitectureExample: Memory stack

Complex

Drivers

Microcontroller


Microcontroller Drivers Memory Drivers I/O Drivers

I/O Hardware

Abstraction

Memory Hardware

Abstraction

Memory ServicesSystem Services

Onboard Device

Abstraction

Communication

Drivers

Communication

Hardware Abstraction

Communication

Services

Application Layer

COM Drivers

Memory Hardware Abstraction

µC

Memory Drivers

EEPROM Driver

SPIHandlerDriver

SPI EEPROM Flash

Internal Flash Driver

Memory Abstraction Interface

ExternalEEPROM Driver

EEPROM Abstraction

ExternalFlash Driver

Flash EEPROMEmulation

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.


Abstraction inside the Infrastructure ArchitectureExample: CAN communication stack

Complex

Drivers

Microcontroller


Microcontroller Drivers Memory Drivers I/O Drivers

I/O Hardware

Abstraction

Memory Hardware

Abstraction

Memory ServicesSystem Services

Onboard Device

Abstraction

Communication

Drivers

Communication

Hardware Abstraction

Communication

Services

Application Layer

I/O Drivers

Communication Services

Communication Drivers

Communication Hardware Abstraction

CAN Driver

Driver for ext.CAN ASIC

SPIHandlerDriver

Diagnostic C

om.

Manager

AUTOSAR COM

CAN NM

µC SPI CAN

External CAN Controller

CAN Transceiver Driver

DIO Driver

Generic NM Interface

CANState

ManagerPDU Router

CAN Interface

Debugging

IPD

U

Multiplexer J1939 Transport

Protocol

CAN Transport Protocol

CAN Communication Services

provide a uniform interface to the CAN network. Hide protocol and

message properties from the application.


Overview





ECU Software Architecture

AUTOSAR Architecture

Co

mp

lex

Driv

ers

Hardware

Microcontroller Abstraction Layer

Services Layer

Application Layer


ECU Abstraction Layer

Layered Software Architecture

ECU-Hardware

AUTOSAR Runtime Environment


Component

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

AUTOSAR

Software

Basic Software

AUTOSAR Interface

Complex Device Drivers

Standardized Interface

Operating System

Actuator Software

Component

AUTOSAR Interface

Sensor Software

ComponentAUTOSAR

Interface


Component

AUTOSAR Interface


Standardized AUTOSAR Interface

AUTOSAR Interface

AUTOSAR Interface

Services


Communication


ECUAbstraction


Microcontr. Abstraction


Sta

nd

ard

ize

d

Inte

rface

Breakdown to /Implementation on

ECU


AU

TO

SA

R

SW

C

1

Virtual Functional Bus

...

AU

TO

SA

RS

WC

n

AU

TO

SA

RS

WC

3

AU

TO

SA

RS

WC

2

AU

TO

SA

RS

WC

1

AUTOSAR Development Methodology

Virtual Functional Bus Concept

� 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

SWCDescription

SWCDescription

SWCDescription

SWCDescription


AU

TO

SA

R S

WC


...

PPort, provides a Sender-Receiver Interface

RPort, requires a Sender-Receiver Interface

PPort, provides a Client-Server Interface,

i.e. implements service

RPort, requires a Client-Server Interface,

i.e. client of a service

PPort, provides data to AUTOSAR Service

PPort, provides AUTOSAR Service

(in BSW only)A

UT

OS

AR

SW

Cn

SWCDescription

PPort, provides a Calibration Interface

RPort, requires a Calibration Interface

RPort, requires AUTOSAR Service as client

RPort, requires data from AUTOSAR Service

AU

TO

SA

RS

WC

3

SWCDescription

AU

TO

SA

RS

WC

2

SWCDescription

AU

TO

SA

RS

WC

1

SWCDescription


Virtual Functional Bus Concept – Ports and Interfaces



Principle

� 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


...

AU

TO

SA

RS

WC

n

AU

TO

SA

RS

WC

3

AU

TO

SA

RS

WC

2

AU

TO

SA

RS

WC

1

SWCDescription

SWCDescription

SWCDescription

SWCDescription

ECU m

...

ECU IIECU I

RTE

Basic Software

RTE

Basic

Software

RTE

Basic Software

AU

TO

SA

RS

WC

1

AU

TO

SA

RS

WC

3

AU

TO

SA

RS

WC

2

AU

TO

SA

RS

WC

n

ECUDescription

ECUDescription

ECUDescription

GatewaySystem

DescriptionCANFlexRay


� From functional level to the ECU binaries.


Development steps

• Component modeling• Data model development• VFB Timing

• System topology• Network• Mapping of

components to ECUs

DevelopVFB System Description

DesignSystem

Build ECU Software

GenerateECU Extract

Develop Application Software

Component

Deliver Basic Software

• BSW implementation• Configuration

Functionalarchitecturelevel

Physicalarchitecturelevel

• Internal behavior• Implementation• Component timing

Hardwaredependent

Hardwareindependent


� The AUTOSAR Methodology provides all descriptions necessary to describe all components of a system..

AUTOSAR Methodology and Templates

Overview

ECU Level

Component Level

System Level

ConfigureSystem

.XML .XML

SystemConfigurationDescription

ExtractECU-SpecificInformation

.XML

ECUExtract

ofSystem

Configuration

ConfigureECU

.XML

ECUConfigurationDescription

GenerateExecutable

. exe

ECUExecutable

.XML

SoftwareComponentDescription

.XML

ECUrelated

templates

ImplementedComponent

ImplementComponent

Object flow, input to or produced by activities

Referencing, using, or reading work products

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

Activity, consuming or producing a work product

.XML

SystemConstraintsDescription


AUTOSAR Methodology and Templates

RTE Generation ProcessECU x

RTE

Basic Software

AU

TO

SA

R

SW

C1

AU

TO

SA

R

SW

C3


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

Application Layer

RTE

Microcontroller

Microcontroller Abstraction Layer


Services Layer


Co

mp

lex

Driv

ers

Application Layer

ActuatorSoftware

Component

SensorSoftware

Component

ApplicationSoftware

Component

AUTOSARInterface

AUTOSARInterface

AUTOSARInterface

ApplicationSoftware

Component

AUTOSARInterface

SensorSoftware

Component

AUTOSARInterface


AUTOSAR R4.0 Specification: Table of Application Interfaces


Standardized Application Interfaces

…Mirror Adjustment…

40 Compositions

…MirrorPositionMirrorMoveStatus…

2500 Ports

…MirrPosnSts1…

570 Interfaces

RecordsContinuous Values EnumerationsArrays

770 Data types

msecPercent…

26 Units

Mirror Adjustment

Mirror Adjustment

MirrPosnSts1

MirrAxisPosn1

Mirror type

Axis type

Position

Continuous Value: “perc7”Recommended type: UInt14 Unit: PercentRange: 0,1 .. 1001,0Resolution: 0,1

Enumeration0: no axis1: horizontal axis2: vertical axis

MirrorPositionMirrorMoveStatus

MirrPosnSts1


AUTOSAR Standardized Application Interfaces

Re-Use of SW-Components

ESP

SW-Component

ESP

SW-Component2nd Yaw

Rate Controller

2nd YawRate Controller

Brake ActuatorBrake Actuator

Information signalsfrom other functions / domains

ESP-SensorsESP-Sensors

Ínterface of ESP and external yaw rate controller

Standard Signals from ESP

VehicleLongitudinal

Controller

VehicleLongitudinal

Controller

Command signals to other functions / domains

Interface of ESP and VLC

Base Sensor Signals

System-level BrakeActuator Interface

I 1

I 2

I 6

I 7

I 3

I 5

I 4

ESP

SW-Component

ESP

SW-Component2nd Yaw

Rate Controller

2nd YawRate Controller

Brake ActuatorBrake Actuator

Information signalsfrom other functions / domains

ESP-SensorsESP-Sensors

Ínterface of ESP and external yaw rate controller

Standard Signals from ESP

VehicleLongitudinal

Controller

VehicleLongitudinal

Controller

Command signals to other functions / domains

Interface of ESP and VLC

Base Sensor Signals

System-level BrakeActuator Interface

I 1

I 2

I 6

I 7

I 3

I 5

I 4

Standardized application interfaces on system level (ESP-system, chassis domain)

Port Name LongAccBase

…

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

Data element: YawRateData Type: AngleSpeed3

Minimal bits size: SInt16Physical Range: -5,..+5,Physical offset: 0Unit: rad/sec

… ….

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).

…

Port Name RollRateBase

Example

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


ECU-Hardware

AUTOSAR RTE

AUTOSAR Int.

SwitchEvent


Microcontroller Abstraction

Std. AUTOSARInterface

Services

Std. Interface

ECUAbstraction

AUTOSARInterface

Std. Interface

ComplexDeviceDrivers

AUTOSARInterface

StandardizedInterface

Communi-cation

Std. Interface


OperatingSystem

DIO

check_switch ()

AUTOSAR Interface

LightRequest

AUTOSAR Interface

Front-Light Manager

get_keyposition()

AUTOSAR Interface

Headlight

set_current (…)

CAN Driver

switch_event(event)

switch_event

(event)

request_light

(type, mode)

request_light(type, mode)

set_light(type, mode)


PWM

Sta

nd

ard

ize

dIn

terfa

ce

set_dboard(type, mode)

Software Architecture – AUTOSAR Defined Interfaces

Use Case ‘Front Light Management’ mapped to AUTOSAR architecture

Integrator Supplier B OEM Supplier AS

ilic

on

ve

nd

or

AIn

teg

rato

r


ECU-Hardware

AUTOSAR RTE

AUTOSAR Int.

SwitchEvent


Microcontroller Abstraction

Std. AUTOSARInterface

Services

Std. Interface

ECUAbstraction

AUTOSARInterface

Std. Interface


AUTOSARInterface


Communi-cation

Std. Interface


OperatingSystem

DIO

check_switch ()

AUTOSAR Interface

LightRequest

AUTOSAR Interface

Front-Light Manager

get_keyposition()

AUTOSAR Interface

Headlight

set_current (…)

CAN Driver

switch_event(event)

switch_event

(event)

request_light

(type, mode)

request_light(type, mode)



PWM

Sta

nd

ard

ize

dIn

terfa

ce

set_dboard(type, mode)

Software Architecture – AUTOSAR Defined Interfaces

Use Case ‘Front Light Management’: Exchange type of Front Light

DIO

AUTOSAR Interface

Xenonlight


set_current (…)

Integrator Supplier B OEM Supplier AS

ilic

on

ve

nd

or

AIn

teg

rato

rS

ilic

on

ve

nd

or

BSupplier C


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

ECU-Hardware


ActuatorSoftware

Component

AUTOSARInterface

ApplicationSoftware

Component

SensorSoftware

Component

ApplicationSoftware

Component

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

AUTOSARSoftware

Basic Software StandardizedInterface

AUTOSARInterface

AUTOSARInterface

AUTOSARInterface

MicrocontrollerAbstraction

StandardizedAUTOSARInterface

Services


ECUAbstraction

AUTOSARInterface



AUTOSARInterface


Communication



OperatingSystem

Sta

nd

ard

ized

Inte

face

AUTOSAR Application Interfaces

Supplier Use Case

Model and implement only once

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

SWC X.y

Interfaces

SupplierSWC

container

OEM_1

Components interfaces

specifications integrate several

application interfaces

.xml .xml

OEM_2




.xml

OEM_N





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

� Software architecture

� Development methodology

� Standardized application interfaces

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

� First series cars with AUTOSAR technology are on the road

Summary

... AR

SW

CnAR

SW

C3AR

SW

C2AR

SW

C1


Early virtual integration of the entire vehicles application functions

Hardware-independent development of application functions

Layered softwarearchitecture


Thank you for your attention!

[email protected] a member and get exploitation rights for the AUTOSAR standard.

Published ReleasesFor information only, see disclaimer.

http://www.autosar.org

hardware-independent software development with autosar · 3 30 september, 2010 hardware-independent...

Documents