Mercedes-Daimler-Audi -- Autosar in practice

1. AUTOSAR
- arrived in practice -
Experiences at Audi and Mercedes
Jens Kötz Frank Cornelius
AUDI AG Mercedes-Benz Cars Development

2. 2
Why this joint presentation?
The main intention of a brand is to enthuse the customer by
differentiation in technology, feel, optical impression & design
The main intention of AUTOSAR is the introduction of a common
standard in – for the customer – non visible layer!
Expectations of the customer
Characteristic and features inspire...

3. 3
Audi and Daimler introduce AUTOSAR 3.2 in vehicle production in 2013
Introducing a standard is more than using the same specification
It is better to use the same AUTOSAR implementation in each company
and benefit from synergies
testing once multiple usage
Improve the quality
Why this joint presentation?
Here we will show our way to a common AUTOSAR stack

4. 4
Future of the Standard
Introduction of AUTOSAR at Audi and Mercedes
AUTOSAR in Practice at Audi / Daimler
Summary & Outlook
Outline

5. 5
Future of the Standard
Introduction of AUTOSAR at Audi and Mercedes
AUTOSAR in Practice at Audi / Daimler
Summary & Outlook
Outline

6. 6
Basic Software Customer-relevance
Bus System
ECU I/OBus interface
Industry Standard
for Tier 1 Software
Industry Standard
for Communications-
Software
AUTOSAR Interface for applications
Differentiation in the functionality
of the customer applications
visible, tangible, audible
customer relevant
Standards in the
Basic Software of the ECU
visible, tangible, audible
only if defect
not customer relevant

7. 7
Introduction of AUTOSAR –
Experiences at Audi and Daimler
Bus System
ECU I/OBus interface
Industry Standard
for Tier 1 Software
Industry Standard
for Communications-
Software
AUTOSAR Interface for applications
Second Step:
AUTOSAR 3.1.4 for
FlexRay/CAN/LIN
with RTE
and Software
Components
Second Step:
AUTOSAR 3.1.4 for
FlexRay/CAN/LIN
with RTE
and Software
Components
First Step:
Usage of
FlexRay Modules of
AUTOSAR 2.1
First Step:
Usage of
FlexRay Modules of
AUTOSAR 2.1

8. 8
Roadmap for the Introduction of AUTOSAR
2009 2014 / 2015………
AUTOSAR 2.1
FlexRay
2012
AUTOSAR 3.1
Rev. 4
FlexRay/CAN/LIN
AUTOSAR 3.2
FlexRay/CAN/LIN

9. 9
Harmonisation of OEM Stacks – how it worked
Actions
Reduction of parameter set
Harmonization of AUTOSAR extensions
Where there is a will there is a way
Open Topics
harmonisation of diagnostic modules
Result
Common AUTOSAR specification release for Audi and Daimler
Evidence: One common AUTOSAR stack

10. 10
Outline
Future of the Standard
Introduction of AUTOSAR at Audi and Mercedes
AUTOSAR in Practice at Audi / Daimler
Summary & Outlook

11. 1111
Initial situation:
No FlexRay Standard Software for production use available on the market
Unclear suitability of AUTOSAR approach
AUTOSAR V2.0 as development base not technically suitable
Changes and extensions required for in vehicle usage
Adaption and Integration of specific VW-Group Modules
(e.G. Bedien- & Anzeige Protokoll (BAP), Komponentenschutz (KS), …)
Compliance to the AUTOSAR- Architecture
(Module-Structures, APIs, Configuration)
Introduction of AUTOSAR 2.1 for FlexRay

12. 12
First using pure AUTOSAR …
Problems with resources at different applications (RAM, ROM, Runtime)
FIBEX (1st K-Matrix shows insurmountable Problems:
AUTOSAR – PDU approach was not illustratable)
… then focusing on the development of
the optimization of the Performance of the COM-Stack
the correction and solidification of the AUTOSAR 2.0 Specifications
while maintaining the compliance with the AUTOSAR interfaces
the Audi-Application Requirements
(e.G. FR-TP and PDU-R without using CAN and LIN)
the extension to FIBEX+ because of missing elements
Introduction of AUTOSAR 2.1 for FlexRay – Experiences
High effort required to introduce the new AUTOSAR specificationHigh effort required to introduce the new AUTOSAR specification

13. 13
2/3 of the amount of
Issues are in Tooling
and interchange format
Introduction of FlexRay – Issues during pre-development
Standard-Software
Standard Software Configuration tool
Schedule-Designtool
Signal database extension for FlexRay
Bussystem Monitor and Analysis
tool extension for FlexRay
Disturbance node FlexRay
Fibex-Viewer
Datalogger for FlexRay
Sum: about 1000
High effortHigh effort requiredrequired to introduce the new AUTOSAR specificationto introduce the new AUTOSAR specification
Corrected Issues

14. 14
Introduction of FlexRay - Results
FLEXRAY – 16 Modules
Signal based abstraction
of application interface
Application is only responsible
for function.
No additional responsibilities
CAN – 9 Modules
Direct interaction between
drivers and application
Additional responsibilities
in the application
(timeout detection, unpack signals etc.)
Resources consumption for FlexRay-SSW only 10%* higher
(incl. COM-Layer, without Config.)
* abgeändertes AUTOSAR 2.x
Applikationen
BAP schutz (UDS)
Bootloader
FlexRay Treiber (AUTOSAR *)
FlexRay Controller
COM
(AUTO
SAR *)
FlexRay Interface (AUTOSAR *)
AALB AALI
XCP
Application
BAP
Generic NM
(AUTOSAR *) Kompo-
nenten-
schutz
Diagnose-
services
Diag.-
protocoll
(UDS)
Bootloader
FlexRay Driver (AUTOSAR *)
FlexRay Controller
COM
(AUTO
SAR *)
PDU Router (AUTOSAR *)
FlexRay Interface (AUTOSAR *)
FlexRay NM
(AUTOSAR *)
AALB AALI
XCP-PL
XCP-TL
FR-TP (AUTOSAR)
CAN Driver
CAN TP (ISO TP)
UDS
CAN Controller
Application
Bootloader
K
SBAP
CWM
NM
High
SDS
DEH
* conditionally functional identical

15. 15
Effort for AUTOSAR Specification development
2005 2006 2007 2008 2011
Efforttoprovidethe
AUTOSARReleases
Count of AUTOSAR Users
1.0
2.0
2.1
3.0
3.1
3.2
Mismatch between the effort
required to provide the AUTOSAR
Specifications and the Number of the
OEMs that use the releases
Mismatch between the effort
required to provide the AUTOSAR
Specifications and the Number of the
OEMs that use the releases

16. 16
Increasing of the
cooperation between
Toolsuppliers necessary
Most of the problems
are in Tooling and
interchange formats
Do not ignore the
performance while
introducing a standard
Introduction of FlexRay
Lessons
Learned

17. 17
Outline
Future of the Standard
Introduction of AUTOSAR at Audi and Mercedes
AUTOSAR in Practice at Audi / Daimler
Summary & Outlook

18. 18
AUTOSAR covers more than just standard software
Before AUTOSAR
Additional documents for system
description (*.pdf, *.doc, *.ppt, etc.),
sometimes oral agreements
bus communication
Communication from ECU to ECU
AUTOSAR
Communication from function to function
Integrated system description for
documentation and configuration
bus communication

19. 19
Daimler‘s AUTOSAR System Structure Approach
AUTOSAR structures the application into
functional blocks by using SW Components (SWC)
definition of interface descriptions of SWC
definitions of exchange formats
tool-based process
Mapping Process …
Which ECU
contributes what
for which system
Next steps: further refinement within the SW components
This approach defines a consequent enhancement
of system design and responsibility
First step: component contribution == AUTOSAR SWC

20. 20
AUTOSAR
One exchange format for LIN-Master, CAN and
FlexRay ECU‘s
One XML File for each ECU
Exchange format contains network and
SW-C information
Before AUTOSAR
Exchange formats only contain network
information
For each network a LDF, DBC, Fibex File
necessary for each ECU
The AUTOSAR System Description is an integral part of the
- standard software configuration
- RTE generation
- AUTOSAR tooling
AUTOSAR Introduces New Exchange Formats
LIN Network: LDF-File
CAN Network: DBC-File
FlexRay Network: Fibex-File
System Description
(xml-File)
ECU Extract of
System Description
(xml-File)

21. 21
Thus we need:
an interoperable AUTOSAR tool chain
tools with a secure and simple Update for System Descriptions
continuous Tool-Chain across the whole development process
converter tools from XML to dbc, Fibex, ldf and vice versa
tooling for XML modifications (XML – Writer”)
Challenge “AUTOSAR Tools”
We see the major challenges primarily in the AUTOSAR tooling than in
the AUTOSAR standard software modules itself
Providing a professional AUTOSAR tool framework will playProviding a professional AUTOSAR tool framework will play
a key role for market success of AUTOSAR Software suppliersa key role for market success of AUTOSAR Software suppliers

22. 22
Tighter coupling of
configuration, schemata
scheme and SW stack
higher test effort
compatibility issues
Change management
process of SWC at OEM
and Tier 1 side is still a
learning field
Increasing of the
cooperation between
Toolsuppliers necessary
Most of the problems
are in Tooling and
interchange formats
AUTOSAR templates
still offer a wide scope
for interpretation
Do not ignore the
performance while
introducing a standard
Experiences with the AUTOSAR system approach
Lessons
Learned

23. 23
Outline
Future of the Standard
Introduction of AUTOSAR at Audi and Mercedes
AUTOSAR in Practice at Audi / Daimler
Summary & Outlook

24. 24
Rollout AUTOSAR
2008 2009 2010 2011 2012 2013 2014 2015
AUTOSAR ModuleAUTOSAR Module
AUTOSAR
Module
AUTOSAR
Module
AUTOSAR ModuleAUTOSAR Module
Einheitliche AUTOSAR
Lösung
Proprietär Erste AUTOSAR Module
integriert
Migrationsphase zur AUTOSAR
Companion Guideline
AUTOSAR ModuleAUTOSAR Module
AUTOSAR R2.1
AUTOSAR R2.1
AUTOSAR
R3.0
AUTOSAR
R2.1
AUTOSAR R3.2
AUTOSAR R3.2
AUTOSAR R3.2
R3.1
CGAUTOSAR R3.2
AUTOSAR R3.0/1
AUTOSAR R3.2/R4.0
AUTOSAR R3.2 Rev 1 is the first usable Standard for all big German OEMs
The 5 big German OEMs committed to the usage & rollout of ASR 3.2

25. 25
Rollout AUTOSAR
Our Roadmap:
Mercedes and Audi have invested large amount of effort in making AUTOSAR 3.2 ready for
use
specification, implementation & tooling
Now AUTOSAR 3.2 will be rolled out
in various product lines at Audi and Mercedes (B / C / D / Crossover)
high volumes from 2013 onwards

26. 26
Outline
Future of the Standard
Introduction of AUTOSAR at Audi and Mercedes
AUTOSAR in Practice at Audi / Daimler
Summary & Outlook

27. 27
Audi and Daimler will use the AUTOSAR 3.2 Standard long term
Steadiness of the Standard
What is a standard?
„A technical standard is an established norm or requirement about technical
systems…“
„A de facto standard is a custom, convention, product, or system that has achieved a
dominant position by public acceptance or market forces …“
WIKIPEDIA:
CopyrightByWikimedia

28. 28
Summary & Outlook
AUTOSAR development process causes early definitions
-- Frontloading –
For a stable development process the maturity and usability of tools is essential
-- Focus on Tools –
To introduce a standard requires the will to arrange a common optimum
-- Audi and Daimler showed that this is possible –
Standard means: stability, maturity, quality, continuity; therefore
-- Audi and Daimler use R 3.1 / R 3.2 –
A standard shall be open - therefore
-- Audi and Daimler will be open for further implementations based on the
AUTOSAR 3.2 Standard if the four points above are fulfilled--