models for automotive embedded systems development

Models for Automotive Embedded Systems Development

Henrik Lönn, Technology Specialist, Embedded Software Development, AB Volvo.

TDA594 / DIT594 Software Engineering Principles for Complex Systems

Volvo Group Trucks Technology

Lönn: Models for Automotive Embedded Systems Development

Volvo Group Business Areas

V O LV O T R U C K S

U D T R U C K S & J V s

R E N AU LT T R U C K S

VOLVO AUTONOMOUS SOLUTIONS

AR Q U U S

V O LV O P E N TA

B U S E S C O N S T R U C T I O N E Q U I P M E N T

M AC KT R U C K S

V O LV O F I N AN C I AL S E R V I C E S



Our organization

BUSINESS

AREAS

TRUCK

DIVISIONS

GROUP

FUNCTIONS

Volvo Group CEO

& Group Executive Board

Mack

TrucksUD Trucks

Volvo

Trucks

Volvo

CE

Volvo

Buses

Volvo

Penta

Volvo

Financial

Services

ArquusRenault

Trucks

Group Trucks Technology

Group Trucks Operations

Group Trucks Purchasing

Volvo

Autonomous

Solutions

Group Functions

North America

17.845

Europe

49.694Asia

16.888

South America

5.228

Africa & Oceania

2.474



Innovative technology offerings

FOR OUR CUSTOMERS AND THE SOCIETY

A U T O M A T E D M A N U A L

T R A N S M I S S I O N

V O L V O D Y N A M I C

S T E E R I N G ( V D S )

R E N A U L T I N F O M A X W A V E P I S T O N F O R

B E T T E R E F F I C I E N C Y

M A C K ® G U A R D D O G ®

C O N N E C T

COLLIS ION WARNING WITH

EMERGENCY BRAKE

PREDICT IVE CRUISE

CONTROL ( I -SEE)

A U T O M A T I C T R A C T I O N

C O N T R O L

PEDESTRIAN AND CYCLIST

DETECTION SYSTEM

R E M O T E P R O G R A M M I N G

O V E R - T H E - A I R ( O T A )



Concepts and technologies for the future

ACCELERATING THE TRANSITION TO A SUSTAINABLE FUTURE

A U T O N O M O U S R E F U S E

T R U C K F O R U R B A N

E N V I R O N M E N T

V O L V O V E R AA U T O N O M O U S T R U C K

F O R M I N I N G

E L E C T R I C R O A D

S Y S T E M S

A N D M A N Y M O R EP L A T O O N I N GW I R E L E S S S E N S O R S T O

R E P L A C E C A B L E S

3 D P R I N T I N G F O R

L I G H T E R E N G I N E S

F U L L Y E L E C TR I C

C O N S TR U C TI O N E Q U I P M E N T

W I TH AU TO M ATI O N

V O L V O C O N C E P T

T R U C K



Take Home Messages:

• Appropriate Software Architecture is Instrumental

• Software Architecture Competence is

Critical for Swedish Industry

• Modeling is an Enabling Technology for

Continuous Integration of Complex Products



Reduced Lead Times

Continuous Deployment

Continuous Integration

Quality

Reuse

Multiple cycle times

Multiple Aspects

Multiple Domains

Multiple Teams

Automation

Connectivity

Electrification

Control Strategies

Architecture

(re)volution


Get Things Right - Continuously


FinalizationConception

$

Product Cost Flexibility


Design

Space

Size

Mechanical vs. Software

Design Flexibility


Cumulative Resources –

Continuous Deployment

Hours


Cumulative Resources

Hours


Example: Testing



Example: Road and Track Testing

When Simulation is too difficult

When Simulation is Impossible

Because it is “Free”



Example: Analysis and Simulation Based “Testing”

To exercise rare situations

To exercise dangerous situations

To accelerate time

To accelerate coverage

To be repeatable

To allow debugging

To cover large sets of configurations

To cover fictuous configurations



In General: Multi-Method

Multiple Engineering Activities

- Input must be semantically and syntactically valid

- Input must be consistent across methods



Consistency and Accuracy

Models are a representation of the real truck

Data from factory, track, field is required to secure validity

Models allow engineering rigor and engineering automation




Engineering Information and Activities

Models & Code

Binaries & Components

V model as reference

…not to prescribe timing and sequence…



V model vs. Continuous Integration and Delivery

...

Every j:th iterationEvery i:th iteration Every k:th iteration

Daily/Weekly/...Hourly Weekly

......

Component

Z

Component

X

TestY


Collaborate Efficiently

Product complexity call for advanced models and tools

Modelling is a significant Effort

Vehicle Manufacturer must integrate models


Black/White/Grey-box

Clear Interfaces

Structure and Behavior


Control over Engineering Information

Engineering documentation is a core asset

Increased use of models represents risk

– Vendor Lock-in

– Complex Information

– Complex access to information

Vehicle Manufacturer must have control of their models



Vehicle Content

Solution independent description of vehicle

”Features” to decompose content


Climate Control

Speed Keeping

External Lights

Entertainment

Entertainment

Height Control

Steering


Application Software Architecture - Layering



Virtual Engineering

...to allow

Instant Deliveries

Maximize Verification Confidence

Exercise Dangerous and Rare Events



Virtual Integration and Simulation

Simulation requires models of all relevant functional aspects

– (Software)

– Software platform

– Electronics

– Mechatronics

– Physics

– Environment



An information model that captures engineering information in a standardized way

Architecture Description Language



Modelling & Simulation Technology


Models -MIL

Software - SIL

Hardware - HIL

Prototyping - RCP

Controller

(SW & Electronics)Devices Plant

(Mechanics, etc.) Environment


Modelling Pattern to Support Integration


Model-in-the-loop: Controller model interfaces to models of sensors and actuators

Software-in-the-loop: Software interfaces to models of electronics

Hardware-in-the-loop: ECU interfaces to models of sensors and actuators

Hardware+-in-the-loop: Sensor & actuator interfaces to models of plant

https://www.google.se/url?sa=i&rct=j&q=&esrc=s&source=images&cd=&cad=rja&uact=8&ved=0ahUKEwj60dPop7LQAhXGBiwKHbP8DF0QjRwIBw&url=https://th.wikipedia.org/wiki/%E0%B8%A3%E0%B8%B0%E0%B8%9A%E0%B8%9A%E0%B8%84%E0%B8%A7%E0%B8%9A%E0%B8%84%E0%B8%B8%E0%B8%A1%E0%B8%9E%E0%B8%B5%E0%B9%84%E0%B8%AD%E0%B8%94%E0%B8%B5&bvm=bv.139250283,d.bGg&psig=AFQjCNExnmnx8zyhXJgAEgYNYC63TOZv7Q&ust=1479558693448067


Model Structure


Electrical

(Logical)Engineering

Units

Electrical

(Physical)

Electrical

(Bit pattern)

En

viro

nm

ent

Pla

nt

Actu

ato

r

I/O

BS

W

Se

nso

r/act.

SW

C

Ap

plic

atio

n

La

ye

r I

Ap

plic

atio

n

La

ye

r II

Engineering

Units


Feature Models



Functional & Software Architecture



Simulation Content


Behavior/TimingFunction Mockup Units+Execution Definition

Source Code+Execution Definition

.c


Property Annotations


V&V

Requirement

60 ms

Test

Timing

Dependability

Error Propagation Model

$

Cost

Variability

§


Electronic Control Unit

AUTOSAR - Technical Goals

Increased Flexibility

– Modularity

– Scalability

– Transferability

– Re-usability

Standardized platform

– Off-the-shelf purchase & integration of comm, OS, diagnosis, drivers, etc.

– Off-the-shelf hardware

Standardized Interfaces

– Off-the-shelf purchase & integration of common vehicle functions


Electronic Control Unit

Software Platform

Application 2

Application 1

Application 2

Application 1

Software Platform

Software Platform


AUTOSAR - Consortium

Core Partners

General

OEM

Generic

Tier 1

Standard

Software

Tools and

Services

Semi-

conductors

AssociateMembers

Premium Members


http://www.vector-informatik.de/index.html

http://www.delphi.com/

http://www.dspace.de/ww/en/pub/home.htm

http://www.renault.com/gb/home/accueil.htm

http://www.volvo.com/

http://www.st.com/stonline/index.htm


AUTOSAR ECU SW Architecture



AUTOSAR - Elements

Modelling

– Capture SW Components SW Component Template

– Capture ECU resources: ECU Resource Description

– Capture allocation and communication: System Description

Methodology

– Autogenerate ECU configuration

– Autogenerate platform SW configuration

– Autogenerate glue code (RTE)

Application Interfaces

– Standard interface definitions for well-established functions

Architecture

– Standard platform SW

– Standard interfaces



AUTOSAR Software: Software Components

Hardware independent (CPU and peripherals of ECU)

Location independent (Communication technology, platform services)

Specified by

– Interface

– Resource Requirements

– Implementation constraints



AUTOSAR Software: Sensors and Actuators

SensorActuatorSoftwareComponent adapts device interface to application

functions

Software architecture

to separate ECU and

device specific parts

Support for re- allocation

of sensors and actuators



AUTOSAR Basic Software

Software platform for application SW components

Standardized Components

– System services (diagnostic protocols; NVRAM, flash and memory management)

– Communication (CAN/LIN/FlexRay... framework, I/O management, Network management)

– Operating System (OSEK based)

– Microcontroller Abstraction

ECU Specific Components

– ECU Abstraction

– Complex Device Driver



AUTOSAR Methodology

Covers process steps for

–ECU platform software generation and configuration

–Application software intregration



SystemModel

AnalysisLevel

DesignLevel

ImplementationLevel

Envi

ron

men

t M

od

el

FunctionalAnalysisArchitecture

FunctionalDesignArchitecture

AUTOSAR Application SW

VehicleLevel

AUTOSAR Basic SW

AUTOSAR HW

HardwareDesignArchitecture

Var

iab

ility

Req

uir

emen

ts

TechnicalFeatureModel

Dep

end

abili

ty

Tim

ing

Extensions …

Data exchange over ports Allocation

EAST-ADL Representation


Features

of the vehicleChassis

TechnicalFeatureModel

Steer Brake Cruise

<<AnalysisArchitecture>> DemonstratorAA

<<FunctionalDevice>>

BrakePedal


BrakeFrontLeft


WheelSensorFrontLeft

<<FunctionalAnalysisArchitecture>> DemoFAA

<<ADLFunction>>

BrakeAlgorithm

<<ADLFunction>>

AbstractABSFrontLeft

VehicleSpeed

<<SWC>>

BaseBrake

<<SensorSWC>>

BrakePedal

<<LocalDeviceManager>>

WheelSensorFL

<<ActuatorSWC>>

Brake

<<SWC>>

ABSFrontLeft

SWComposition

VehicleSpeed

Abstract

functions

Concrete functions,

Hardware topology,

allocation to nodes

Software Architecture

as represented

by AUTOSAR

<<HWFunction>>

BrakePedal

<<HWFunction>>

BrakeFrontLeft

<<HWFunction>>


FunctionalDesignArchitecture


BrakePedal

<<DesignFunction>>

BrakeController

<<DesignFunction>>

ABSFrontLeft<<LocalDeviceManager>>

BrakeActuatorFL

<<BSWFunction>>

BrakeIO

<<BSWFunction>>

PedalIO


WheelSensorFL<<BSWFunction>>

WSensIO

VehicleSpeed

HardwareDesignArchitecture<<ECUNode>>

PedalNode<<ECUNoder>>

WheelNode

<<Sensor>>

Pedal<<Actuator>>

Brake

<<Realize>>


EAST-ADL Model on Design Level

Functional Structure


Design Level

Application Functionality HW Functionality

<<FunctionalDesignArchitecture>> DemonstratorFDA

<<HWFunction>>

PedalSensor

<<HWFunction>>

BrakeActuatorFrontLeft

<<HWFunction>>


<A

na

lysis

Fu

nctio

n>

>

Bra

ke

Pla

ntM

od

el

BSW Functionality


BrakePedal

<<DesignFunction>>

BrakeController

<<DesignFunction>>


BrakeActuatorFL

<<BSWFunction>>

BrakeIO

<<BSWFunction>>

PedalIO



WSensIO

VehicleSpeed

Pe

da

lAn

gle

Bra

ke

Fo

rce

Wh

ee

lSp

ee

dF

L

<<

En

viro

nm

en

tMo

de

l>>

De

mo

nstr

ato

rEM



Functional Structure onto HW Architecture



<<HWFunction>>

PedalSensor

<<HWFunction>>


<<HWFunction>>


<A

na

lysis

Fu

nctio

n>

>

Bra

ke

Pla

ntM

od

el

BSW Functionality


BrakePedal

<<DesignFunction>>

BrakeController

<<DesignFunction>>


BrakeActuatorFL

<<BSWFunction>>

BrakeIO

<<BSWFunction>>

PedalIO



WSensIO

VehicleSpeed

Pe

da

lAn

gle

Bra

ke

Fo

rce

Wh

ee

lSp

ee

dF

L

<<

En

viro

nm

en

tMo

de

l>>

De

mo

nstr

ato

rEM

<<HardwareDesignArchitecture>>

Validator1HDA

<<Sensor>>


<<Sensor>>

WheelSensorFrontRight

<<Sensor>>

WheelSensorRearLeft

<<Sensor>>

WheelSensorRearRight

<<ECUNode>>

Brake

<<Sensor>>

BrakePedal

<<Sensor>>

BrakeFrontLeft

<<Actuator>>

BrakeFrontRight

<<Actuator>>

BrakeRearLeft

<<Actuator>>

BrakeRearRight

<<ECUNode>>

ABS_FR

<<ECUNode>>

ABS_RL

<<ECUNode>>

ABS_RR

<<ECUNode>>

ABS_FL




Timing/Triggering

<<FunctionTrigger>>

ABSTrigger

<<Mode>>

InMotion

<<PeriodicEventConstraint>>

ABSPeriodConstraint



<<HWFunction>>

PedalSensor

<<HWFunction>>


<<HWFunction>>


<A

na

lysis

Fu

nctio

n>

>

Bra

ke

Pla

ntM

od

el

BSW Functionality


BrakePedal

<<DesignFunction>>

BrakeController

<<DesignFunction>>


BrakeActuatorFL

<<BSWFunction>>

BrakeIO

<<BSWFunction>>

PedalIO



WSensIO

VehicleSpeed

Pe

da

lAn

gle

Bra

ke

Fo

rce

Wh

ee

lSp

ee

dF

L

<<

En

viro

nm

en

tMo

de

l>>

De

mo

nstr

ato

rEM




<<FunctionBehavior>>

ABS_Behavior

Simulink model



<<HWFunction>>

PedalSensor

<<HWFunction>>


<<HWFunction>>


<A

na

lysis

Fu

nctio

n>

>

Bra

ke

Pla

ntM

od

el

BSW Functionality


BrakePedal

<<DesignFunction>>

BrakeController

<<DesignFunction>>


BrakeActuatorFL

<<BSWFunction>>

BrakeIO

<<BSWFunction>>

PedalIO



WSensIO

VehicleSpeed

Pe

da

lAn

gle

Bra

ke

Fo

rce

Wh

ee

lSp

ee

dF

L

<<

En

viro

nm

en

tMo

de

l>>

De

mo

nstr

ato

rEM

Transfer Function – ”Black-box” behavior




<<FunctionBehavior>>

ABS_Behavior

Simulink model

My_ABS.mdl



<<HWFunction>>

PedalSensor

<<HWFunction>>


<<HWFunction>>


<A

na

lysis

Fu

nctio

n>

>

Bra

ke

Pla

ntM

od

el

BSW Functionality


BrakePedal

<<DesignFunction>>

BrakeController

<<DesignFunction>>


BrakeActuatorFL

<<BSWFunction>>

BrakeIO

<<BSWFunction>>

PedalIO



WSensIO

VehicleSpeed

Pe

da

lAn

gle

Bra

ke

Fo

rce

Wh

ee

lSp

ee

dF

L

<<

En

viro

nm

en

tMo

de

l>>

De

mo

nstr

ato

rEM

Transfer Function – ”Black-box” behavior





<<HWFunction>>

PedalSensor

<<HWFunction>>


<<HWFunction>>


<A

na

lysis

Fu

nctio

n>

>

Bra

ke

Pla

ntM

od

el

BSW Functionality


BrakePedal

<<DesignFunction>>

BrakeController

<<DesignFunction>>


BrakeActuatorFL

<<BSWFunction>>

BrakeIO

<<BSWFunction>>

PedalIO



WSensIO

VehicleSpeed

Pe

da

lAn

gle

Bra

ke

Fo

rce

Wh

ee

lSp

ee

dF

L

<<

En

viro

nm

en

tMo

de

l>>

De

mo

nstr

ato

rEM


Behavior of environment (Plant)

<<AnalysisFunction>> BrakePlantModel

<<AnalysisFunction>>

Env1


Env2


Env4


Env3

Typically in plant model:

•Non-causal: ”Power Ports” – {Torque,Speed}, {Pressure, Flow}, etc.

•Continuous Time: No triggers



Variability - Background

On average, less than 2 vehicles of the same configuration is built: Huge configuration space

All engineering information is governed by configuration and variant

– Requirements

– Components

– Tests

– Annotations

– ...

Co-variation SW and mechanics/plant

– SW configuration must be consistent with mechatronics and mechanics of truck

Customer variability vs technical variability

– Some variability is invisible to the user: Internal technical solutions

Detaled variability vs. Exposed variability

– Some details are only relevant for the component developer



Variability Mechanism 1: Include/exclude


Feature model for configuration

Artefacts subject to configuration


Variability Mechanism 2: Parameterize


Parameter

”FunctionAvailable”

Feature model for configuration

Artefacts subject to configuration

• Include/exclude

• Variant-specific calibration

True

False

Parameter

”MaxRideHeight”12

8


Public Feature Model

Compositional Variability


wi:WiperIntegrator

rsThr:Threshold

wiperBtnSig

rainSensorSig

thresholdValuerainSensor

Request

driver

Request

WiperController

WiperControlthresholdValue :=

front ? 140 : rear ? 80 : undef

Variant 1

Variant 2

Front Rear


Compositional Variability


: ThrottleCalculator

rsThr:Threshold

…

from Radar

isTooNear

currSpeed

…

to throttle

CruiseControl

thresholdValue:Float

BodyElectronicsSystem

CC

minDistance:Int

Adaptive

ComfortCC

ShortLong

Other:Int

Car

Model

A-ClassC-Class

E-Class

Market

US EMEA

Comfort

from vehicle

speed sensor

…

Reductio

n o

f Com

ple

xity

Gra

dual S

hift o

f Vie

wpoin

t

Encapsula

tion

Reuse


Engineering Workflow

Represent

– Models and Code

Resolve

– Configure and Resolve variability

Generate

– Automatic preparation for each tool

Simulate/Analyze/Verify

– Software centric simulations

– Physics centric simulations

– Arithmetic analysis

– Formal verification

– ...


Simulate

Resolve

Adapt System

ADAPT Virtual System Bus

RepresentFunctional Block

Software Component

Plant Element

Electrical Device

Environment Element

Analyse

UPPAAL

Verify

UPPAAL

GenerateModule

SWC

Module

FMU

GenerateModule

SWC

Module

FMU



Configuration

Application SW

Integration

Platform SW

Integration

ECU, I/O,

Sensors & Actuators

Plant

Integration

Environment

Integration


Software:

AUTOSAR SWC Selection

AUTOSAR SWC Parameterization

Configuration ports

Initialization valuesNon-Software

Logical Component Selection

Function Mockup Unit Parameterization

Configuration Ports

Initialization values


Configuration

Environment:

Traffic Scenario:

OpenScenario Selection & Parameterization

Roads:

OpenRoad Selection and Parameterization



Generation

Application SW

Integration

Platform SW

Integration

ECU, I/O,

Sensors & Actuators

Plant

Integration

Environment

Integration



Simulation

Adapt Simulation Platform

Simulated MechatronicsApplication Software

Platform Software Simulated Physics Environment

MyRoads.odr

MyScenario.osc

Test F

ram

ew

ork


.eaxml

.arxml

.fmu

.c

.h


Engineering Automation

gitLocal Unit Test

Test

Cases

Local PC or Cloud

Publish.xml

.dllArtifactory

TestSimulation Build

Make

Changes

Automatic

Resolution

and

Build

Automatic

InvocationAutomatic Test


Conclusion

AUTOSAR software platform is automotive de-facto standard

EAST-ADL supports automotive embedded systems modelling

“starting” with needs and requirements and

“ending” with an AUTOSAR SW architecture

An agreed modelling language makes it possible

– to understand engineering information from other departments/disciplines/companies

– to exchange engineering models between different organizations and tools

– to progress jointly on tools and methodology for modelling, analysis and synthesis




Summary

New Vehicle Functionality

Development Efficiency

Short Lead Time

Iterative & Incremental

Development

Engineering Automation

Automatic Configurability

Automatic Evaluation

Variability Modelling

System &Plant Modelling

ConfigureModel Simulate

models for automotive embedded systems development

Documents