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.
Long history of
graph transformation
Sound body of theory
Several areas of application
- - Folie 2
Tool-support available to handle larger models
Future model-based
engineering of
automotive systems will
use AUTOSAR
Explore
Explorepotentials
potentials
of
ofthe
theapplication
application
of
ofgraph
graph
transformation
transformationin
in
an
an AUTOSAR
AUTOSAR
development
development
Identification
Identificationof
of
research
researchand
and
development
developmenttopics
topics
1
Content.
1
2
Automotive
AutomotiveSystem
System
Engineering
Engineering
3
AUTOSAR
AUTOSAR
Standardization
Standardization
4
Methodology
Methodologyof
of
System
SystemDevelopment
Development
SW-C
Description
SW-C
Description
R&D
R&DTopics
Topics
SW-C
Description
SW-C
Description
AUTOSAR
SW-C
n
AUTOSAR
SW-C
3
AUTOSAR
SW-C
2
AUTOSAR
SW-C
1
...
Architecture
Virtual Functional Bus
Tool supporting deployment
of SW components
Methodology
ECU
Descriptions
Application
Interfaces
Methodology
ECU I
ECU II
System Constraint
Description
ECU m
AUTOSAR
SW-C
n
AUTOSAR
SW-C
2
AUTOSAR
SW-C
3
AUTOSAR
SW-C
1
...
RTE
RTE
RTE
Basic Software
Basic Software
Basic Software
- - Folie 3
Gateway
Automotive Systems and SW Engineering
4
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
5
AUTOSAR Managing Complexity
by Exchangeability and Reuse of Software Components
OEM b
Exchangeability
between
supplier‘s
solutions
OEM a
Platform b.1
Platform b.2
Platform b.n
Platform a.1
Platform a.2
Platform a.n
Exchangeability
between
manufacturer‘s
applications
Supplier A
Chassis
Safety
Body/Comfort
Multimedia
Supplier C
Body/Comfort
Powertrain
Telematics
Multimedia
OEM f
OEM e
Platform f.1
Platform f.2
Platform f.n
Supplier B
Chassis
Safety
Telematics
Multimedia
OEM c
Platform c.1
Platform c.2
Platform c.n
OEM d
Platform d.1
Platform d.2
Platform d.n
Exchangeability
Platform e.1
Platform e.2
Platform e.n
between vehicle
platforms
6
3
Model-based Development.
General Task.
Driver
W*
W
R
Measurement
Control
Sensors
U
Actuators
Vehicle
Demand
Y
X
(Electronic) Control Unit
Plant
Z
Environment
W
U
R
Control Unit
WINT
W
RINT
UINT
Microcontroller
- - Folie 7
R
Input
Decoder
Power /
Communi
cation
Control
U
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.
Document based
development process
Model based
development
process
Idea
- - Folie 8
Micro controller
WINT
WDIS
A/D
converter
RINT
RDIS
A/D
converter
Software
UDIS
D/A
converter
UINT
Software component
for computation of
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
Micro controller
WINT
WDIS
A/D
converter
RINT
RDIS
- - Folie 9
A/D
converter
*.h
Software
UDIS
UINT
D/A
converter
MbE-Slides by M. Conrad
Use case ‘Front-Light Management’
LightRequest
Front-Light Manager
check_switch ()
switch_event(event)
switch_event
(event)
request_light
(type, mode)
request_light(type, mode)
get_keyposition()
set_light(type, mode)
SwitchEvent
AUTOSAR Int.
AUTOSAR Interface
AUTOSAR Interface
Headlight
set_light(type, mode)
set_current (…)
AUTOSAR Interface
ECU1
AUTOSAR RTE
Standardized
Interface
Operating
System
Standardized
Std. AUTOSAR
Interface
Interface
AUTOSAR
Interface
Communication Control
Communi-
Services
AUTOSAR
Interface
ECU
Abstraction
cation
Memory Management
Standardized
Interface
Operating
System
Std. Interface
Std. Interface
Drivers
Std. Interface
Complex
Device
Drivers
Hardware
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
check_switch ()
switch_event
(event)
switch_event(even
t)
request_light
(type, mode)
request_light(type, mode)
get_keyposition()
set_light(type, mode)
AUTOSAR Int.
AUTOSAR Interface
AUTOSAR Interface
Xenonlight
Headlight
set_light(type, mode)
set_current (…)
AUTOSAR Interface
ECU2
AUTOSAR RTE
Operating
System
Standardized
Std. AUTOSAR
Interface
Interface
Standardized
Interface
AUTOSAR
Interface
Communication Control
Communi-
Services
AUTOSAR
Interface
ECU
Abstraction
cation
Memory Management
Standardized
Interface
Operating
System
Std. Interface
Std. Interface
Std. Interface
Drivers
Complex
Device
Drivers
Hardware
Standardized Interface
PWM
DIO
DIO
CAN Driver
Microcontroller Abstraction
11
Distribution on ECUs
SwitchEvent
LightRequest
LightRequest
Front-Light Manager
check_switch ()
switch_event
(event)
switch_event(even
t)
request_light
(type, mode)
request_light(type, mode)
get_keyposition()
set_light(type, mode)
AUTOSAR Int.
AUTOSAR
AUTOSAR Interface
Interface
AUTOSAR Interface
Xenonlight
set_light(type, mode)
set_current (…)
AUTOSAR Interface
AUTOSAR RTE
Standardized
Interface
Standardized
Interface
Operating
System
Std. AUTOSAR
Interface
Standardized
Interface
AUTOSAR
Interface
Services
Communication
ECU
Abstraction
Std. Interface
Std. Interface
Std. Interface
AUTOSAR
Interface
Complex
Device
Drivers
Standardized Interface
DIO
PWM
DIO
CAN Driver
Microcontroller Abstraction
ECU-Hardware
12
6
Use case ‘Front-Light Management’ – Multiple ECUs
LightRequest
Front-Light Manager
check_switch ()
switch_event(event)
switch_event
(event)
request_light
(type, mode)
request_light(type, mode)
get_keyposition()
set_light(type, mode)
SwitchEvent
AUTOSAR Int.
AUTOSAR Interface
ECU3
AUTOSAR RTE
AUTOSAR
Standardized
Std. AUTOSAR
Operating
System
Interface
Interface
Interface
ECU
Communication
Control
CommuniServices
Abstraction
cation
Memory Management
Std. Interface
Std. Interface
Std. Interface
Drivers
Hardware
Standardized Interface
DIO
CAN Driver
Microcontroller Abstraction
ECU-Hardware
Xenonlight
set_light(type, mode)
set_current (…)
AUTOSAR Interface
ECU4
AUTOSAR RTE
AUTOSAR Interface
ECU5
AUTOSAR RTE
Standardized
Operating
System
Interface
Communication
Communi- Cont.
cation
Memory Management
Standardized
Operating
Interface
Communication
Cont.
ECU
Communi-
Drivers
Hardware
Standardized Interface
Standardized Interface
ECU-Hardware
Abstraction
Std. Interface
Drivers
Hardware
Microcontroller Abstraction
cation
Std. Interface
Memory Management
Std. Interface
CAN Driver
AUTOSAR
System
Interface
CAN Driver
PWM
Microcontroller Abstraction
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
OEM
Generic
Tier 1
Standard
Software
Tools and
Services
Semiconductors
Up-to-date status see: http://www.autosar.org
15
AUTOSAR
Project Objectives and Main Working Topics
Implementation and
standardization of basic
system functions as an OEM
wide “Standard Core“ solution
Scalability to different vehicle
and platform variants
Transferability of
functions throughout
network
Integration of
functional modules
from
multiple suppliers
Maintainability throughout the
whole “Product Life Cycle“
Architecture
Increased use of “Commercial
off the shelf hardware“
Software updates
and upgrades over
vehicle lifetime
Application
Methodology
Interfaces
Consideration of
availability and safety
requirements
16
8
AUTOSAR
Main Working Topics
Architecture
Application
Methodology
Interfaces
Architecture
Application
Methodology
Interfaces
Architecture
Application
Methodology
Interfaces
Architecture:
Software architecture including a complete basic or
environmental software stack for ECUs – the so called
AUTOSAR Basic Software – as an integration platform for
hardware independent software applications.
Methodology:
Exchange formats or description templates to enable a
seamless configuration process of the basic software stack
and the integration of application software in ECUs and it
includes even the methodology how to use this framework.
Application Interfaces:
Specification of interfaces of typical automotive applications
from all domains in terms of syntax and semantics, which
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
PDU Router
IPDU
Multiplexer
LIN
TP
Ext. FR
Driver
Memory Drivers
FR Interface
FR transc
Driver
Ext. Flash
Driver
Ext. CAN
Driver
Microcontroller Drivers
CAN Interface
Flash EEPROM
Emulation
CAN transc
Driver
BSW Scheduler
CRC Lib
AUTOSAR OS
Ext.
EEPROM
Driver
CAN NM
FR
SM
FlexRay
TP
I/O Hardware
Abstraction
Communication Hardware Abstraction
Watchdog Interface
External
Watchdog
Driver
CAN
TP
LIN
Interface
Memory Abstraction Interface
EEPROM
Abstraction
LIN
SM
FlexRay NM
Development Error
Tracer
Communication
Manager
Watchdog Manager
Diagnostic Event
Manager DEM
Function Inhibition
Manager FIM
ECU State Manager
NVRAM
Manager
I/O Hardware
Abstraction
Generic NM
Interf.
CAN
SM
DCM
Diagnostic
Com.
Manager
AUTOSAR
COM
Memory Hardware Abstraction
Onboard Device
Abstraction
Communication Drivers
I/O Drivers
DIO Driver
e.g. PCP
e.g. CCU
e.g. TPU
DIO
ADC
CCU
PWM
FlexRay
CAN
LIN
µC
PORT Driver
ADC Driver
PWM Driver
ICU Driver
FR Driver
CAN Driver
LIN Driver
LIN Communication
Stack
SPI Handler Driver
SPI
SCI
FLASH
internal Flash Driver
internal EEPROM
Driver
EEPROM
Ext. BUS
WDT
MCU
Power &
Clock Unit
GPT
RAM Test
Watchdog Driver
MCU Driver
GPT Driver
Flash Check
Microcontroller
Communication Services
Memory
Services
20
10
Intra- and Inter-ECU Communication
Ports implement the interface according
to the communication paradigm (here
client-server based).
ECU I
Ports are the interaction
Applipoints of a component.
cation
SW-C
The communication is
A
channeled via the RTE.
The communication layer
in the basic software is
encapsulated and not
RTE
visible at the application
layer.
BSW
ECU II
Application
SW-C
B
Application
SW-C
C
Application
Ports
VFB
RTE
AUTOSAR
Infrastructure
BSW
Sensor
Hardware
Communication Bus
Communication Path
21
AUTOSAR Architecture – Conclusion
1
AUTOSAR harmonizes already existing basic software solutions and
closes gaps for a seamless basic software architecture.
2
AUTOSAR aims at finding the best solution for each requirement and
not finding the highest common multiple.
3
The decomposition of the AUTOSAR layered architecture into some
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
Software
Component
Actuator
Software
Component
Sensor
Software
Component
AUTOSAR
Interface
AUTOSAR
Interface
AUTOSAR
Interface
AUTOSAR
Software
..............
Application
Software
Component
AUTOSAR
Interface
Application
Layer
AUTOSAR Runtime Environment (RTE)
Standardized
Interface
Standardized
AUTOSAR
Interface
Syntax of
Interfaces:
AUTOSAR
AUTOSAR
Standardized
InterfaceSoftware
Interface
Interface
Meta-model,
Component
Template
CommuniECUtransferability within the network
Supporting
cation
Abstraction
Standardized Standardized
Standardized
Interface
Interface
Interface
Complex
Operating
Device
System Semantics of Interfaces:
Drivers
Standardized
Physical properties, units, etc.
Interface
Micro- lines
Supporting re-use across product
controller
In scope of AUTOSAR workAbstraction
packages specifying application
Services
Standardized
Interface
Basic Software
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
…
ESP-Sensors
ESP-Sensors
Base Sensor Signals
2nd
2nd Yaw
Yaw
Rate
RateController
Controller
I6
YawRateBase
Description
Yaw rate measured along vehicle z- axis
(i.e. compensated for orientation).
Coordinate system according to ISO
8855
Data Type
S16
Integer Range
-32768..+32767
Physical Range
-2,8595..+2,8594
Physical Offset
0
Unit
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).
I1
Interface of ESP
and VLC
Ínterface of ESP and
external yaw rate
controller
Data Type Name
I4
ESP
ESP
SW-Component
SW-Component
System-level Brake
Actuator Interface
Vehicle
Vehicle
Longitudinal
Longitudinal
Controller
Controller
Standard Signals
from ESP
I2
I3
Information signals
from other functions /
domains
Command signals to
other functions /
domains
I7
I5
Brake
Brake Actuator
Actuator
Standardized application interfaces on
system level
(ESP-system, chassis domain)
…
Data Type Name
RollRateBase
25
Major task: Conflict Resolution – Example Vehicle Speed
Body Domain
CentralLockingMaster
VehicleSpeed
?
DataElement
Name
value
DataType
t_VehiculeSpeed
Min Bit size; Res; phys low; phys up; Unit
Uint12
0.1 0.0 0.0 403.4
km/h
InteriorLight
Powertrain Domain
DriverReq
DataElement
Name
DataType
ActualVehicleSpeed VehicleSpeed
OK
Min Bit; size; Res; phys low; phys up; Unit
Uint16 0.00781 0 0
511.992 km/h
ActualVehicleSpeed
OK
Chassis Domain
CentralLockingMaster
ActualVehicleSpeed
VehicleLongSpeed
ESP
ACC
SSM
EPB
VLC
Steering
Suspension
…
DataElement
Name
DataType
VehicleLongSpeed VehicleLongitudinalSpeed
Min Bit; size; Res; phys low; phys up; Unit
??
?? ??
??
??
??
?
26
13
AUTOSAR Application Interfaces – Conclusion
1
For several domains a subset of application interfaces has been
standardized to agreed levels.
2
It is a challenge to align standardization with the pace of application
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.
SW-C
Description
SW-C
Description
SW-C
Description
SW-C
Description
AUTOSAR
SW-C
n
AUTOSAR
SW-C
3
AUTOSAR
SW-C
2
AUTOSAR
SW-C
1
...
Virtual Functional Bus
Tool supporting deployment
of SW components
ECU
Descriptions
System Constraint
Description
ECU I
ECU II
ECU m
AUTOSAR
SW-C
n
AUTOSAR
SW-C
2
AUTOSAR
SW-C
3
AUTOSAR
SW-C
1
...
RTE
RTE
RTE
Basic Software
Basic Software
Basic Software
Functional software is described
formally in terms of “Software
Components” (SW-C).
Using “Software Component
Descriptions“ as input, the „Virtual
Functional Bus“ validates the
interaction of all components and
interfaces before software
implementation.
Mapping of “Software Components” to
ECUs and configuration of basic
software.
The AUTOSAR Methodology supports
the generation of an E/E architecture.
Gateway
29
AUTOSAR Methodology
Derive E/E architecture from formal descriptions of soft- and hardware
components
VFB view
SW-C
Description
SW-C
SW-C
SW-C
DescriptionDescriptionDescription
Standardized description templates for
application software components
(interfaces and BSW requirements)
AUTOSAR
SW-C
n
AUTOSAR
SW-C
3
AUTOSAR
SW-C
2
AUTOSAR
SW-C
1
...
Virtual Functional Bus
ECU
Descriptions
System Constraint
Description
Standardized exchange formats
and methodology for component,
ECU, and system level
Tool supporting deployment
of SW components
Mapping
ECU I
ECU II
ECU m
AUTOSAR
SW-C
n
AUTOSAR
SW-C
2
AUTOSAR
SW-C
3
AUTOSAR
SW-C
1
...
RTE
RTE
RTE
Basic
Software
Basic
Software
Basic
Software
Tools for
- support of component mapping
- generation of RTE, i.e. inter- and
intra ECU communication
Standardized Basic Software
(BSW) architecture, detailed
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
Description
ECU Resource
Description
ECU Resource
Description
BlinkInputModule
SwitchEval
SW-Component Description
BlinkInputModule
Supported protocols:
CAN, LIN, FlexRay
BlinkMaster
SMLS
System
Description
BC-H
BC-V
SW-Component Description
BlinkMaster
LightActuatorsControl
LightActuatorsControl
SW-Component Description
CAN
LIN
LightSourceSetting
LightSourceSetting
LM-L
SW-Component Description
LM-R
31
The system configuration maps software components
to ECUs and links interface connections to bus signals.
Example
System Configuration
SWCMappingDefs
DataMappingDefs
BlinkRequest
SwitchEval
BlinkInputModule
BlinkMaster
Blink
Input
Module
Blink
Master
Comm.Matrix for BodyCAN
LightActuatorsControl
LightSourceSetting
FrameInstance
…BlinkRequest
SignalBS3
SignalBS1SignalBS2
32
16
AUTOSAR – System Design – Implementation Process
Input: Requirements & Vehicle Info
1a
1c
1b
System
Description
SW Component
Description
ECU Resource
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
Example: speed
warning device
...
Description
SW Component m
Description
SW Component 3
Description
„v_warn()“
Description
„get_v()“
SW-Component
Template
Function Bus Integrator
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:
- p_ports
- r_ports
- interfaces
inner structure (composition)
- sub-components
- connections
Information for each SWC
e.g. “get_v()”
- interfaces, behavior (repetition rate, ...)
- direct hardware interfaces (I/O)
- requirements on run-time performance
(memory, computing power, throughput,
timing/latency, …)
- ...
AUTOSAR-Description
Editor
required HW resources:
- processing time
- scheduling
- memory (size, type, etc.)
„get_v()“
Software Component
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
e.g. ECU1
- sensors and actuators
- hardware interfaces
- HW attributes (memory, processor,
computing power, …)
- connections and bandwidths, etc.
- ...
AUTOSAR-Description
Editor
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
= 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)
- K-matrix
- gateway table
- bus systems, protocols,
communication matrix and
attributes (e.g. data rates, timing, …)
- function clustering
- function deployment
(distribution to ECU)
- ...
Mapping / Clustering of SW
components
SystemDescription
AUTOSAR-Description
Editor
= tool based
37
AUTOSAR – System Configuration
Step 2: Distribution of SW-Component-Descriptions to ECU
SystemDescription
SW Component n
...
Description
SW Component 3
Description
„v_warn()“
Description
„get_v()“
Description
Configuration on the basis of descriptions (not on the basis of implementations!) of SWComponents, ECU-Resources and System-Description
Consideration of ECU-Resources available and constraints given in the SystemDescription
= tool based
...
ECU-Resource
-Description
ECU m
ECU-Resource
-Description
ECU 3
ECU-Resource
-Description
ECU 2
ECU-Resource
-Description
ECU 1
AUTOSAR-System Definition (Distribution of SW-Component-Descriptions considering resources available)
ConfigurationDescript.
ConfigurationECU1
- Description
Descript.
Configuration1,
ECU2
- Description
2, 5,
- Description
Descript.
ECUm
- ... - Description
- Description
6, k,
- Resources
- ... - Description n,
- ... - Ressources
- ...
- ... - Ressources
- ...
...
SystemDescription
- e.g. mapping of signals
to CAN matrices
- ...
an iterative process
38
19
AUTOSAR – ECU-Configuration
Step 3: Generation of required configuration for AUTOSAR-Infrastructure
per ECU
AUTOSAR-Configuration
ECU1
ConfigurationDescript. ECU1
- Description 1,
- Description 2,
- ...
- Resources
System Description
- e.g. mapping of signals
to CAN matrices
- ...
configuration of
the AUTOSAR-RTE
configuration of
AUTOSAR OS
configuration
of MCAL
AUTOSAR - ECU Configuration Generator
Configuration
of COM stack
AUTOSAR-RTE-Config-Info
- 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
Body of the
SW components
AUTOSAR-Library
- communication
- transport protocols, ...
(code, macros, Objects, ...)
AUTOSAR-Configuration
ECU1
configuration of
the AUTOSAR-RTE
SW-Components ECU1
Tooling
(derived partially from the Virtual Function Bus)
AUTOSARRTE
Generator
configuration of
AUTOSAR OS
OS
Generator
configuration
of MCAL
MCALGenerator
Configuration
of COM stack
COM
Generator
AUTOSAR-RTE
OS
MCAL
COM
Basic system functions
core functions, drivers
Hardware
40
20
AUTOSAR Methodology – Conclusion
1
The E/E system architecture can be described by means of
AUTOSAR.
2
The meta model approach and the tool support for specifying the
AUTOSAR information model allow working at the right level of
abstraction.
3
A methodology to integrate AUTOSAR software modules has been
designed.
4
AUTOSAR pushes the paradigm shift from an ECU based approach to
a function based approach in automotive software development.
41
Use case ‘Front-Light Management’ applying AUTOSAR
LightRequest
Front-Light Manager
check_switch ()
switch_event(event)
switch_event
(event)
request_light
(type, mode)
request_light(type, mode)
get_keyposition()
set_light(type, mode)
SwitchEvent
Xenonlight
set_light(type, mode)
set_current (…)
AUTOSAR Interface
AUTOSAR Interface
AUTOSAR RTE
AUTOSAR RTE
AUTOSAR RTE
Std. AUTOSAR
Interface
AUTOSAR
Interface
Standardized
Interface
Standardized
Interface
Standardized
Interface
AUTOSAR
Interface
Services
ECU
Abstraction
Communication
Communication
Communication
ECU
Abstraction
Std. Interface
Std. Interface
Std. Interface
Std. Interface
Std. Interface
Std. Interface
AUTOSAR Int.
AUTOSAR Interface
Standardized Interface
DIO
CAN Driver
Microcontroller Abstraction
ECU-Hardware
Standardized Interface
CAN Driver
Microcontroller Abstraction
ECU-Hardware
Standardized Interface
CAN Driver
PWM
Microcontroller Abstraction
ECU-Hardware
CAN Bus
42
21
Topics for Research and Development
- - Folie 43
System configuration
Semi-automatic mapping of communication
System Configuration.
1a
1c
SW Component
Description
System
Description
1b
ECU Resource
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
- - Folie 44
System configuration is data structure covering the whole system description
22
System Configuration.
Communication Mapping.
ECU I
ECU II
Application
SW-C
A
Application
SW-C
B
Application
SW-C
C
Application
Data Types
Ports
RTE
VFB
RTE
AUTOSAR
Infrastructure
BSW
System Signals
Interaction Protocol
Data Units
BSW
Frames
Sensor
Hardware
Communication Bus
- - Folie 45
Communication Path
Communication Mapping.
Level 1: Primitive Data Types
System Signals.
Communication between SW Components
mapped onto Run Time Environment
Mapping defined as set of associations
- - Folie 46
Similar, but more complex mappings for
Complex data types
Client-server communication between SWComponents
Additionally, signal paths can be constraint
23
Communication Mapping.
Level 2:
System Signals
Run Time Environment
Interaction Protocol Data Units.
Mapping of RTE signals to
Communication Manager
- - Folie 47
Interaction layer defines also timing and
triggering of ISignals
Communication Mapping.
Level 3: Interaction Protocol Data Units
Frames.
Mapping of Communication
Manager to PDU Router
PDU Router deploys frames to
different communication
protocols
- - Folie 48
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
24
SystemDescription
SW Component n
...
Description
SW Component 3
Description
„v_warn()“
Description
„get_v()“
Description
Communication Mapping.
Tooling.
...
ECU-Resource
-Description
ECU m
ECU-Resource
-Description
ECU 3
ECU-Resource
-Description
ECU 2
ECU-Resource
-Description
ECU 1
AUTOSAR-System Configuration Generator
(Definition of mappings)
ConfigurationDescript.
ConfigurationECU1
- Description
Descript.
Configuration1,
ECU2
- Description
- Description
Descript.
2, 5,
ECUm
- ... - Description
- Description
6, k,
- Resources
- ... - Description n,
- ... - Ressources
- ...
- ... - Ressources
- ...
...
SystemDescription
- e.g. mapping of signals
to CAN matrices
- ...
- - Folie 49
Generation of mappings based on graph transformation rules
Challenges
Complexity and size of system configuration
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
- - Folie 50
Graph Transformation
Is the technology for semi-automatic configuration
Can reduce the configuration complexity
Needs to build domain knowledge
25
Further Information
http://www.autosar.org
Published version of
AUTOSAR Release 3.0
- - Folie 51
[email protected]
- - Folie 52
Backup
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
Services
Onboard Device
Abstraction
Memory Hardware
Abstraction
Communication
Hardware Abstraction
Microcontroller Drivers
Memory Drivers
Communication
Drivers
I/O Hardware
Abstraction
Complex
Drivers
I/O 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
Services
Onboard Device
Abstraction
Memory Hardware
Abstraction
Communication
Hardware Abstraction
Microcontroller Drivers
Memory Drivers
Communication
Drivers
I/O Hardware
Abstraction
Complex
Drivers
I/O Drivers
Microcontroller
Ext. EEPROM Driver
Spi_Read()
Spi_Write()
COM Drivers
Memory Drivers
SPI Handler
+ Driver
Int. EEPROM
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
clearly visualized
The consistency of the information is
guaranteed
Using XML, a data exchange format can be
generated automatically out of the
metamodel
METAMODEL
Datatype
SWComponent
Interface
MODEL
Mirror
Adjustment
Mirror
Actuator
57
29