The AUTOSAR Way of Model-Based Engineering of

Automotive Systems
Heiko Dörr
International Conference on Graph Transformation
Leicester, 12.09.2008

Purpose of the Presentation.

Future model-based
engineering of
automotive systems will
use AUTOSAR
Long history of
graph transformation
Explore
Explorepotentials
potentials
Sound body of theory of
ofthe
theapplication
application
of
ofgraph
graph
Several areas of application transformation
transformationin in
Tool-support available to handle larger models an
an AUTOSAR
AUTOSAR
development
development

Identification
Identificationof
of
research
researchand
and
- - Folie 2

development
developmenttopics
topics

1
 Content.

1 2 3 4
Automotive
AutomotiveSystem
System AUTOSAR
AUTOSAR Methodology
Methodologyof
of R&D
R&DTopics
Topics
Engineering
Engineering Standardization
Standardization System
SystemDevelopment
Development

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

Description Description Description Description

AUTOSAR

AUTOSAR

AUTOSAR

AUTOSAR
SW-C

SW-C

SW-C

SW-C
...

2
1

n
Architecture
Virtual Functional Bus

Tool supporting deployment

ECU
Methodology of SW components

System Constraint
Descriptions Description

Application
Methodology
Interfaces ECU I ECU II ECU m

AUTOSAR

AUTOSAR

AUTOSAR

AUTOSAR
SW-C

SW-C
SW-C

SW-C
...

n
RTE RTE RTE

Basic Software Basic Software Basic Software

Gateway
- - Folie 3

Automotive Systems and SW Engineering

2
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

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
Exchangeability Body/Comfort Telematics
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 platforms
Platform e.n

3
 Model-based Development.
General Task.
Driver

W*

Vehicle
Demand U
Measurement Actuators
R Control
Sensors
Y

Plant
(Electronic) Control Unit
Z

Environment
W
U
R

Control Unit
W WINT UINT U
Power /
Input Micro- Communi
Decoder controller cation
R RINT Control
- - Folie 7

MbE-Slides by M. Conrad, Abb: Schäuffele/Zurawka: Automotive Software Engineering; Foto: www.bba-reman.com/ images/ecu.jpg

Model-based Development.
Paradigm Shift.
Model based
Document based
development
development process
Idea process

Micro controller
WINT A/D WDIS Software
converter UDIS D/A UINT
converter
RINT A/D RDIS
converter

Software component
for computation of
- - Folie 8

control functions

MbE-Slides by M. Conrad

4
 Model-based Development.
Evolution of Models.
Idea

Requirements /
Behavioral model of system
t
Physical model

Implementation model

Autocode

*.c *.h
Micro controller
WINT A/D WDIS Software
converter UDIS D/A UINT
converter
RINT A/D RDIS
converter
- - Folie 9

MbE-Slides by M. Conrad

Use case ‘Front-Light Management’

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

ECU1
AUTOSAR RTE
Standardized Operating
Std. AUTOSAR System
Standardized AUTOSAR AUTOSAR
Interface Interface Interface Interface Interface
Communication Control ECU
Communi-
Services Abstraction
Memory Management
cation
Standardized

Std. Interface Std. Interface

Drivers Std. Interface
Interface

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

Microcontroller Abstraction

10

5
Use case ‘Front-Light Management’
Exchange of type of front-light
SwitchEvent LightRequest Front-Light Manager Xenonlight
Headlight
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

ECU2
AUTOSAR RTE
Standardized Operating
Std. AUTOSAR System
Standardized AUTOSAR AUTOSAR
Interface Interface Interface Interface Interface
Communication Control ECU
Communi-
Services cation Abstraction
Memory Management
Standardized

Std. Interface Std. Interface Std. Interface

Drivers
Interface

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

Microcontroller Abstraction

11

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

12

6
 Use case ‘Front-Light Management’ – Multiple ECUs
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

ECU3 ECU4 ECU5
AUTOSAR RTE AUTOSAR RTE AUTOSAR RTE
Std. AUTOSAR AUTOSAR Standardized Standardized Standardized AUTOSAR
Interface
Operating System
Interface Interface
Operating System
Interface
Operating
Interface
System
Interface
Communication
ECU Control
Communi- Communication
Communi- Cont. Communication
Communi- Cont.
ECU
Services Abstraction cation cation cation Abstraction
Memory Management Memory Management Memory Management
Std. Interface Std. Interface Std. Interface Std. Interface Std. Interface Std. Interface
Drivers Drivers Drivers
Hardware Hardware Hardware
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

13

AUTOSAR Standardization

14

7
 AUTOSAR – Core Partners and Members
Status: 13th March 2008

9 Core Partner 6 Development

Member

67 Associate Member
52 Premium Member

General Generic Standard Tools and Semi-

OEM Tier 1 Software Services conductors
Up-to-date status see: http://www.autosar.org
15

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
Methodology Consideration of
Integration of Interfaces availability and safety
functional modules requirements
from
multiple suppliers

16

8
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:
Exchange formats or description templates to enable a
Architecture

Application
Methodology
seamless configuration process of the basic software stack
and the integration of application software in ECUs and it
Interfaces

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.

17

Main Concepts: Architecture

Basic Software modules
Run time environment and communication

18

9
AUTOSAR ECU Software Architecture

Application Software
(ASW)
Standardization of
interfaces

Not standardized in
AUTOSAR

Basic Software
(BSW) +RTE
Standardization of
interfaces and behavior

Objectives: Basic SW: Decoupling of Hardware and Application Software

Application SW: Relocation / Reuse of SW-Components between ECUs

19

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

Interf.
Watchdog Manager

Development Error
Function Inhibition

AUTOSAR Diagnostic SM
Diagnostic Event

Communication
Manager FIM

Manager DEM

COM Com.
I/O Hardware
Manager

Manager
Tracer

LIN Abstraction
FlexRay NM

NVRAM
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
Interface
CRC Lib
AUTOSAR OS

Watchdog Interface
EEPROM Flash EEPROM
BSW Scheduler

CAN transc

FR transc

Abstraction Emulation
Ext. CAN

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
LIN Driver
RAM Test

FR Driver
Driver

Stack
Clock Unit

EEPROM

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

FlexRay
FLASH

PWM
CCU
WDT
MCU

ADC
CAN
GPT

DIO
SCI
SPI

LIN

Microcontroller µC

20

10
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

21

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 40 modules has proven to be functional and complete.

22

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

23

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
Communi-Supporting
Services
ECUtransferability within the network
cation Abstraction
Standardized Standardized Standardized
Standardized

Interface Interface Interface

Interface

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

24

12
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
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
from other functions /
domains
Physical Offset 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)

25

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
Steering VehicleLongSpeed VehicleLongitudinalSpeed
SSM Min Bit; size; Res; phys low; phys up; Unit
Suspension ?? ?? ?? ?? ?? ??
EPB
… ?
VLC

26

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

27

Main Concepts: Methodology

Overall methodology
Structure of configuration information
System Design – Implementation Process

28

14
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
Descriptions
System Constraint Mapping of “Software Components” to
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

29

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

application software components

SW-C

SW-C

SW-C
SW-C

...
1

(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

intra ECU communication

SW-C
SW-C

SW-C

SW-C

n
1

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

30

15
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

31

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 SignalBS1SignalBS2 SignalBS3

32

16
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

33

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

34

17
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:
Information for each SWC - p_ports
e.g. “get_v()” - r_ports
- interfaces, behavior (repetition rate, ...) - interfaces
- direct hardware interfaces (I/O) inner structure (composition)
- requirements on run-time performance - sub-components
(memory, computing power, throughput, - connections
timing/latency, …) required HW resources:
- ... - processing time
- scheduling
- memory (size, type, etc.)

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

35

AUTOSAR – Input Descriptions (2 of 3)

Step 1b): Description of hardware independently of application software

ECU Resource Description

General characteristics (name, manufacturer, etc.)
Temperature (own, environment, cooling/heating)
Available signal processing methods
Available programming capabilities
Information for each ECU Available HW: - µC, architecture (e.g. multiprocessor)
e.g. ECU1 - memory
- sensors and actuators - interfaces (CAN, LIN, MOST, FlexRay)
- hardware interfaces - periphery (sensor / actuator)
- HW attributes (memory, processor, - connectors (i.e. number of pins)
computing power, …) SW below RTE for micro controller
- connections and bandwidths, etc. Signal path from Pin to ECU-abstraction
- ...

AUTOSAR-Description ECU 1
Editor Resource
Description
= tool based

36

18
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

37

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 2, 5,
- Description
Descript.
- ... - Description
- Resources
ECUm
- Description
6, k,
- ... - Description n,
- ... - 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 1

ECU 2

ECU 3

to CAN matrices
... - ...

= tool based an iterative process

38

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

AUTOSAR-Configuration
ECU1

Configuration-
Descript. ECU1 System Description configuration of
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

39

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

40

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

41

Use case ‘Front-Light Management’ applying 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 Abstraction
cation cation
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

42

21
 Topics for Research and Development
System configuration
Semi-automatic mapping of communication
- - Folie 43

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

2
Configure System
& generate extracts
of ECU descriptions

Step 2 “System Configuration” has high complexity

Contains mappings of
Data Signals Network Communication
Implementations SW-compositions ECU
Logical HW resources ECU
Under the existence of mappings constraints

System configuration is data structure covering the whole system description

- - Folie 44

22
 System Configuration.
Communication Mapping.

ECU I ECU II
Appli- Appli- Appli-
cation cation cation
SW-C SW-C SW-C
Application
A B C

Data Types

Ports
System Signals
RTE VFB RTE
AUTOSAR Interaction Protocol
Infrastructure Data Units
BSW BSW

Frames
Hardware
Sensor

Communication Bus
Communication Path
- - Folie 45

Communication Mapping.
Level 1: Primitive Data Types System Signals.

Communication between SW Components

mapped onto Run Time Environment

Mapping defined as set of associations

Similar, but more complex mappings for

Complex data types
Client-server communication between SW-
Components
Additionally, signal paths can be constraint
- - Folie 46

23
 Communication Mapping.
Level 2:
System Signals
Run Time Environment
Interaction Protocol Data Units.

Mapping of RTE signals to

Communication Manager

Interaction layer defines also timing and

triggering of ISignals
- - Folie 47

Communication Mapping.
Level 3: Interaction Protocol Data Units Frames.
Mapping of Communication
Manager to PDU Router

PDU Router deploys frames to

different communication
protocols

Frame definitions configure all

communication stacks of full
network
Different segments of system
configuration will be used to
configure each communication
stack at each ECU
- - Folie 48

24
 Communication Mapping.
Tooling.

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
- Description
Descript.
2, 5,
- ... - Description
- Resources
ECUm
- Description
6, k,
- ... - Description n,
- ... - Ressources
- ...
- ... - Ressources
AUTOSAR-System Configuration Generator
(Definition of mappings) ... - ...

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

Generation of mappings based on graph transformation rules

Challenges
Complexity and size of system configuration
- - Folie 49

Interaction with decisions by system designer

Conclusion

AUTOSAR
Leverages model-based engineering of automotive software to whole systems
Standardization itself is highly formalized and so supports formal system
development
Shifts implementation efforts to configuration

Graph Transformation
Is the technology for semi-automatic configuration
Can reduce the configuration complexity
Needs to build domain knowledge
- - Folie 50

25
 Further Information

http://www.autosar.org

Published version of
AUTOSAR Release 3.0

request@autosar.org
- - Folie 51

Backup
- - Folie 52

26
Challenges in Automotive E/E Development

Extend product offering and increase product differentiation

Stable or decreasing development costs
Strengthen brand image in the market
Propose specific features and functions across the product range
Ensure long term competitiveness, as well as presence in emerging markets, through
cost reduction
Increase quality and reduce “non quality” costs

Increasing share of electronics in vehicle value

Electronics share (in value): 2004: 20% 2015: 40%
(McKinsey, Automotive Electronics - Managing innovations on the road)
Software share (in value): 2000: 4,5% 2010: 13%
(Mercer Consulting, Automobile technologie 2010)

53

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

54

27
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

55

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

56

28
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

57

29