Under the Hood: Model-Based Development in the Automotive Industry by Darren Buttle, ETAS GmbH...

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

Consulting

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

http://www.etas.com/



An overview of the automotive industry Challenges for software

Model-Based development What’s next?

Overview



80,000,000 Annual worldwide car production

1,000,000,000 Shipments 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





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





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

7 F

4

7

F 4

F2

F1

F3

F4

F6

F5 F7

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)

...

SWC1

SWC2

SWC3

SWCn

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

http://ascet.ecn.etasgroup.com/index.php/Image:Veyron_16.4.png




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





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

Software

Transcript of Under the Hood: Model-Based Development in the Automotive Industry by Darren Buttle, ETAS GmbH...