Under the Hood: Model-Based Development in the Automotive Industry by Darren Buttle, ETAS GmbH (ECMFA'14 Keynote)

1 Public | ETAS-PGA/PRM-E | July 2014 | © ETAS GmbH 2014. All rights reserved, also regarding any disposal, exploitation, reproduction,
editing, distribution, as well as in the event of applications for industrial property rights.
Under the hood
Model-Based software development in the automotive industry

ETAS
Who are we?
ETAS GmbH
Customers
Vehicle OEMs, ECU suppliers, …
Portfolio
Tools, Services, Consulting
Headquarters: Stuttgart, Germany
13 regional offices worldwide
Employees: 850
Revenue: €149 million
Ownership: 100% owned by Robert Bosch GmbH
Find out more
www.etas.com
Function & Software
Development
Operating Systems &
AUTOSAR RTE
ECU Access & ECU Hardware
Measurement
&
Calibration
Test
&
Validation
Prototyping
Test
&
Validation
LABCAR
Hardware-in-the-Loop
Simulatoren
ASCET
Model-based
Development
ETAS Lösungen
ETK/XETK
ECU Interfaces
Isolating Measurement
Probes
Consulti
ng
on
ETAS
Consulting
Prototyping
Embedded Security
RTPRO-PC
PC Software for
Real-time Prototyping
ES900 and ES 1000
Prototyping and
Interface Modules
INTECRIO
Integrated Prototyping
Environment
EHOOKS
Bypass Hook
Insertion Tool
RTA-OSEK, RTA-OS
Real-time
Operating System
INCA
Measurement &
Calibration Software
ES400 & ES600
Measurement
Modules
ES500
ECU and Bus
Interface Modules
ES700
Road Testing Modules

An overview of the automotive industry
Challenges for software
Model-Based development
What’s next?
Overview

80,000,000Annual worldwide car production
1,000,000,000Shipments of smartphones in 2013
A Big Number…
…and a bigger one

€42.8 billion
Annual vehicle export sales
17.1 million
Vehicles manufactured annually in Europe
12.9 million
People employed (directly or indirectly)
in Europe making them
Europe’s Largest Export Industry
2x

Car Makers (the OEMs)
Requirements provider
System integrator
Sometimes the ECU integrator
ECU Suppliers (Tier1s)
Design & implementation
Usually ECU integrator
Significant Interaction
OEM builds the “plant”
Tier1 builds the “controller”
Distributed functions
Sub-contracting to Tier2 suppliers
Automotive Development
Who does what?
… and many more

€ 3,000.00
€ 2,000.00
€ 6,000.00
€ 9,000.00
€ 15,000.00
Labour
Other
Raw Materials
Electronics
The Rest
Assume it costs €20,000 to make a car…
Automotive Development
Where is the money spent?
Sources
McKinley, 2010

The Modern Car
A box of electronics on wheels
Complex mechatronic system
Hard real-time constraints
Designed by OEM and several Tier1 suppliers

Engine
Management
Injection/Spark timing
Emissions control
Noise control
Transmission
Control
Gear selection
Terrain Adjustment
Vehicle Domains: Powertrain
(Or what does all that stuff do?)

Braking
Anti-Lock Braking (ABS) since 1978
Traction Control
Electronic Stability (ESP) since 1995
Vehicle Domains: Chassis
Source: Robert Bosch GmbH

Wiper control / rain sensing
Wing mirrors
Vehicle access
Window lift/anti-trap/pinch
Electronic seats
Heating/ventilation
Airbags
Mood Lighting
Stop/start
Vehicle Domains: Body

Head Unit
Radio/CD/MP3 integration
Navigation/Mapping
TV
Internet
Telephony
Basically a “PC in a car”
This area accounts for an
increasing part of the
“user experience”
Vehicle Domains: In-Vehicle Infotainment (IVI)

Adaptive Cruise Control
Park pilot
Lane departure warning
Blind spot warning
Collision mitigation
Active steering
Pedestrian protection
Vehicle Domains: Advanced Driver Assistance (ADAS)
Images: Robert Bosch GmbH

Up to 60kg in
weight
Over 5,000,000
combinations
More changes
requests than
software
The Vehicle Network
Joining things together
50x Faster 10x Faster
19.2 kbit/s Up to 1Mbit/s Up to 10Mbit/s Infotainment

What’s next?
Overview

Constantly changing application
requirements
Quicker time to market demands
Increased complexity and functionality
Limited engineering resources
The same as every other industry …
Software Development in the Automotive Industry
Challenges

Tight performance constraints
Must fit within very limited resources
enable minimal production costs
High reliability demands
In massive production volumes
In places where “patching the software” is difficult
… but with some additional and unique challenges
Software Development in the Automotive Industry
Challenges

Memory
8MB ROM/512kB RAM is “huge”
256kB ROM/32kB RAM is “typical”
Speed
280MHz is “fast”
40MHz is “typical”
Harsh environment
Challenge: Manufacturing Cost Pressure
Resource constrained devices
Trademarks property of respective owners

Challenge: Development Cost Pressure
ECU development costs
Software
50-70%
Hardware
50-30%

Challenge: Software Development Cost Pressure
Lots of code
≈20,000,000 SLOC
≈ 100,000 SLOC
≈ 6,500,000 SLOC
Sources
Pavey & Winsborrow, “Demonstrating Equivalence of Source Code and PROM
Contents”, Computer Journal Vol 36, No 7, 1993
Charette, “This car runs on code”, IEEE Spectrum, Feb 2009
= 500 copies of “The Complete Works of Shakespeare”

Challenge: Variation
Many models. Many configurations.
1974 2014
3000
Compile time options
35000
Calibration parameters
(for tuning performance)
Image sources: wikipedia.com / Daimler AG

10x more “flying hours” than the entire Boeing
737 fleet since it entered service in 1968
Challenge: Exceptional Reliability Demands
Big volumes. Long lifetime.
Cars
• 400,000 vehicles per year
Hours
• 7 hours driving per week
Years
• On road for 20 years
Use
• 2,912,000,000 hours

Challenge: Exceptional Reliability Demands (2)
Expensive to fix when it breaks.
22 million
Vehicles recalled in US in 2013
17 million sold
$1,000,000,00
Excluding cost of repair
1-6% of company revenue
$1200
Estimated cost per SLOC for Toyota
unintended acceleration problem
Sources: New York Times, Klokwork, Autocar AU, Daily Telegraph, EDNbvg

What’s next?
Overview

Model-Based Software Development
Automotive development jobs

Modelling
Continuous
control/signal
flow
Reactive/Event
triggered
Architecture
Three key areas
Where is “model-based software development” used?
Modelling = “Drawing Software” + “Code Generation”
Trademarks property of their respective ownersh

What does this enable?
F
F
OS
MDF
Stimuli
Plant
Model
4
7
4
7F
4
7
F4
F
2
F1
F
3
F4
F
6
F5
F
7
F ‘4
F ‘7
Simulation
Early design validation
through
experimentation
Virtual Prototyping
Add automotive infrastructure to
function model. Validate new
function in context of more
realistic environment.
Rapid Prototyping
Bypass technology allows users to
test new functionality in the
context of
an existing ECU
Shortened feedback loop = Quicker time to market

Think about V&V at the model level
What does this enable?
Model-Based Testing
Natural representation of test
Easy management of variants
Automatic generation of test campaigns

Code generation is
Fast, Systematic, Structured,
Reproducible, Portable, Globally
optimizable
~30% faster to model
and then auto-code
Compared to hand-written C
~50% lower residual
failure rate
Compared to the worlds best C
programmers
Automotive embedded software is mostly C
Code Generation for application software
16%
18%
66%
MbSW
Reuse (OS, drivers etc.)
Hand Written in C

Hard for OEMs and Tier1s to collaborate
No common architectural standard
Prohibitive effort for SW integration
Lots of “custom glue”
Lots of incompatible file formats/tooling
What problem is it trying to solve?
AUTOSAR
Hardware
Software
Hardware
Application Software
(ASW)
Basic Software (BSW)
Proprietary
Hardware
Application
Software
AUTOSAR RTE
ECU Abstraction
and Complex Drivers
ECU Abstraction
and Complex Drivers
ECU Abstraction
and Complex Drivers
Microcontroller Abstraction
Services

63 Associate Members
6 Attendees
9 Core Partners
General
OEM
Standard
Software
Semi-
conductors
Tools and
Services
Generic
Tier 1
11 Development
Members
47 Premium Members
AUTOSAR: A Pan-Industry Effort

0
2000
4000
6000
8000
10000
12000
14000
R1.0 R2.0 R2.1 R3.0 R3.1 R3.2 R4.0
Auxilliary
Standard
AUTOSAR: Size of releases (by pages of specification)

AUTOSAR: Basic principles
Virtual Function Bus (VFB)
...
SWC
1
SWC
2
SWC
3
SWC
n
AUTOSAR
Interface
AUTOSAR
Interface
AUTOSAR
Interface
AUTOSAR
Interface
Standardized Software Architecture
• Software Components (SWCs) as building
blocks
• Virtual Function Bus (VFB) defines
communication model
• Abstraction that makes software
components portable
• Users define “what” but not “how”
Bus
Standardized Basic Software
• Run-Time Environment (RTE) encapsulates
VFB
• Standardized OS, communication model,
memory model, device drivers, etc.
• All APIs are defined
• All functionality is specified
…

AUTOSAR: Freedom to be flexible

AUTOSAR: Software components
My Component
External
Behaviour
The ports
define the
external
view of the
SWC – what
other SWCs
see.
Runnables represent
programs inside the
software component.
They run when
something happens on
the interface.
Events link events on the
ports to runnables inside the
SWC.
Runnable
Runnable
Runnable
Internal Behaviour captures what happens inside a software
component
Variable
Inter-runnable variables
provide communication
between runnables in a
SWC
Per-instance
memory
provide
persistant
storage
between
runnable
invocations
PIM

1990: ASCET-RS
Simulation of continuous time systems
Smalltalk, 80286/DOS, Transputer
1995: ASCET-SD V1.0
Re-worked to model legacy C code
…and do code generation
1998: ASCET-SD V2.1
1st series production
Bosch, BMW and Siemens Gasoline ECUs
Today
Up to 100% of application SW in ASCET
ASCET: 15 years of series production
Function development the ETAS way

More than 450 million ECUs on the road
ASCET in action

Different techniques for different jobs
What? Signal Flow Block Diagrams
Where? Closed loop control e.g.
Engine Management. Continuous
values and time.
What? State Machines
Where? Discrete Event (Reactive)
Systems e.g. Gearbox, Moding.
Discrete value and time.
What? Textual Description
Why? Easier for programmers to
read. Widely used in chassis control
What? Conditional Tables
Why? Easier comprehension of
complex conditionals

Controls-driven
function
development
Not too high, not too low
Getting an appropriate level of abstraction
More abstract Less abstract
Software-
driven controls
development

− Object-based model
− Forcing structure
− Supporting systematic reuse
− Real-time aware
− Integrated threading model
− Thread-safe communication
using state-based messaging
− Capture implicit assumptions about
data values
− Elements have value ranges
− Used in code generation for
defensive code generation
− Domain-specific modelling elements
− Characteristics, maps, curves,
Encourage users to structure models
Borrow from “Good Old-Fashioned Software Engineering”
Class X
Class Y
Class Z
Module A
Module B
Process I
Process J
Process P
Process Q
Process R
Module C
Process F
Process G
Project “ECU1”
Task1ms
Task10ms
P I
Q J R
Project “ECU2”
Task5ms
Task100ms
I J
F G

Obligations
Natural “hand over” point between function and
software development
Start with the end in sight
Add low-level concerns without breaking the model
Abstract Model Representation Variants
+
Requirements
Fixed point quantization & storage allocation
are de-coupled from the model
Variant instances to support PLE

Data & Code Variation / Binding
ASCET
Other variations
Assembly
Generation
Pre-Processing
Compile
Link
Calibration
Static Run-Time
Pre-Compile
Link-Time
Post-Build
Data Variation
Definition different data sets
#if SYSTEMCONSTANT == 42
/* Something */
#else
/* Something else */
#endif
System Constant
Code Variation
Force pre-processing optimization
Choose code from mode or libraries
Replace intrinsic maths routines with
custom “service” routines
Binding Times
Control what lives in ECU
e.g. Ship one ECU to the
OEM and let them selection
options
OR Ship different ECUs
without modifying code base

− Defense against
− Numeric problems (re-quantizations, overflow)
− Temporal problems (race conditions)
− Protection against common numeric errors
− E.g. Division by zero
− Introduction of Limiters (Saturated arithmetic)
− Easy use of fixed-point arithmetic
− Automatic re-scaling for differing quantas
− Mutual exclusion over critical sections
− Detect when messages can be read before they are written
Systematic introduction of defensive code
ASCET
Code generation
Source: de.wikipedia.com
Source: esa.int
Source: netcarshow.com
Source: BMWblog.com

Encourages homogeneous thinking
Problems
for (i=0; i < InjCrv_numInj; i++)
{
if (qInj[i] > qInjMax[i])
{
qInj[max] += eta.calc(qInj[i]-qInjMax[i]);
qInj[i] = qInjMax[i];
}
if (qInj[i] < qInjMin[i])
{
qInj[max] += eta.calc(qInj[i]-qInjMin[i]);
qInj[i] = qInjMin[i];
}
}

− Graphical modeling = Drawing
− Not natural for all problems
− Layout is dominant effort sink
− Software engineers unimpressed when
shown graphical modeling
− Representation is not natural
− Need to visualize, but not draw
− The right abstraction level is important
− Graphical model: too hot
− C programming: too cold
− Maybe need a “Goldilocks” solution that
is just right?
− DSLs?
Appropriate notations
Problems
Source: en.wikipedia.com

Workflow interaction
Hard to use efficiently
Lot’s of clicking
Diff & merge is a complex job
Process integration
Cumbersome to automate
Barrier to continuous integration
Incorrectly assume central position in
workflow
“Industrial strength”
Models can be enormous
Good tooling matters
Problems
500KB C code
Data
Representation
Model
4GB Model

What’s next?
Overview

Future Concerns
Trends & Drivers
?
Earlier V&V
New
Hardware
New
Functionality

Limited functional model composition
Integration of C code is normal
Feature interaction bugs often discovered ad-hoc
Need different views during
development
Drawn from different model sources/DSLs
AUTOSAR XML, ML/SL, ASCET, MSR-SW, DBC, FIBEX, LDF, …
Tooling isn’t as mature as for code
Less “out-of-the-box” support for metrics, re-factoring, model
analysis (information flow, program slicing, reasoning, …)
Lots of models, with late system integration
Earlier V&V
Issues in MBSE

The hardware comes late
Earlier V&V
The wider vehicle development process
60%
Less than
of the engineers have the opportunity
of an evaluation experience in the
whole vehicle
10%
Approximately
of the development process
no real prototype is available

Earlier V&V
Virtualization
virtual driving
Component design
(SW, Mechanics,
Electrics, …)
Virtual
System
Enabling technologies:

Multi-core is everywhere
More computing power
Redundancy
Aggregation
Experience is disappointing
Communication delays
Algorithmic timing issues
OS overheads
Models aren’t designed for
parallel execution
Paradox of more CPU power…
…less performance
Industry is struggling to take legacy to multicore
New Hardware
Multicore CPUs

More interactions
“Internet” – navigation
Roadside telemetry
Look ahead data from other vehicles
OTA Updates
Secure software activation
Patches for bugs
New vulnerabilities
Identical risks to other connected systems
Connected vehicles
New Functionality
Bigger distributed systems
Source: Robert Bosch GmbH

You are the biggest problem
1.3 million deaths a year
~90% are driver error
Take the driver out of the loop
More system integration
Prevent conflicting decisions
Move to domain controller architectures
More focus on software safety
Already being driven by standards
Keeping you alive
New Functionality
More sophisticated driver assistance
Source:Google
Source:Boeing
1/hour

Complex, cyber-physical system…
…with stringent demands for safety, security,
reliability
We use model-based development to
understand the problem…
…and engineer solutions
…under massive cost pressure
What is a car then?
Summary

Under the hood
Model-Based software development in the automotive industry

Under the Hood: Model-Based Development in the Automotive Industry by Darren Buttle, ETAS GmbH (ECMFA'14 Keynote)

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Under the Hood: Model-Based Development in the Automotive Industry by Darren Buttle, ETAS GmbH (ECMFA'14 Keynote)

Similar to Under the Hood: Model-Based Development in the Automotive Industry by Darren Buttle, ETAS GmbH (ECMFA'14 Keynote) (20)

More from Jordi Cabot

More from Jordi Cabot (20)

Recently uploaded

Recently uploaded (20)

Under the Hood: Model-Based Development in the Automotive Industry by Darren Buttle, ETAS GmbH (ECMFA'14 Keynote)