Timing-Aware Design of Automotive Software Methods and ...

Timing-Aware Design of Automotive Software

Methods and Tools for Timing-Aware Design of

Automotive Control Software Arne Hamann, Corporate Research, Robert Bosch GmbH

Joint work with: Matthias Wöhrle (Bosch), Dirk Ziegenbein (Bosch), Goran Frehse (Université Joseph Fourier Grenoble),

Arne Hamann | 08.09.2015 | AE2-2127 | © Robert Bosch 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.

Sophie Quinton (INRIA Grenoble), Steffen Lampke (Technical University of Braunschweig)

1


OutlineOutline Problem statement & goals

Control & Real-time Systems Co- Engineering

Approach 1: Closed-loop simulation-based approach Combining Matlab/Simulink with SymTA/S “Timing-augmented Functional Simulation” Car Road Damping (Active Suspension)

Approach 2: Formal analysis approach Hybrid automatons and reachability analysis Electro Mechanic Braking System (EMB)g y ( )

Conclusion

Arne Hamann | 08.09.2015 | AE2-2127 | © Robert Bosch 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.2



Approach 1: Closed-loop simulation-based approach Combining Matlab/Simulink with SymTA/S “Timing-augmented Functional Simulation”

Approach 2: Formal analysis approach Hybrid automatons and reachability analysisy y y Electro Mechanic Braking System (EMB)

Conclusion



Automotive System – Engine Control UnitAutomotive System Engine Control Unit

Function:• Controlling combustion process• Controlling combustion process• Computing computation of several

injections for up to 12 cylinders @ 8,000 RPM

Software:

@ 8,000 RPM• > 50 sensors & actuators• Onboard diagnosis• …

> 500,000 LoC> 1000 SW components> 10,000 variables

Hardware:• 1-8 MB Flash,

> 2000 variation points256-512kB RAM• Specific accelerators• Transition from single

l i ( 6)


to multi cores (up to 6)

4

Two Disciplines – Two WorldsTiming-Aware Design of Automotive Software

Two Disciplines Two Worlds

ControlEngineer

SoftwareEngineer



System as seen by the software engineerSystem as seen by the software engineer

Deadline = PeriodWCET, WCRT

ECU

Tasks

Task containing runnables

Scheduling

Cores, Memories

„Real-time performance“


„Real time performance

6


System as seen by the control engineerSystem as seen by the control engineer

SophisticatedControl uyk Control Algorithm

ukyk

Periodic Sampling, No Jitter

No Output Jitter,“Freshest” value always available

ukykWriteData

ReadData

No/Constant Control DelayCalculation takes 0/constant time

Plant

x = Ax + Bu. D/A

Converteru(t)A/D

Converter

y(t)Control x Ax + Bu

y = CTxConverterConverter „Control

performance“



ConsequencesConsequences “That guy has unclear, not implementable requirements

-> I’ll optimize resources” Guaranteed period, task-wide data consistency,

last-is-best (LIB) communication Load-dependent behavior & jitter

“My algorithm performs always better in simulation than in the y g p yprototype vehicle -> I’ll test my algorithm only in the vehicle and make it more robust” Long design iterations, late rework, …g g , ,

(adds burden to heavy calibration tasks) Wasted HW resources



Problem Statement - ShortcomingsProblem Statement Shortcomings

Theory:Ti i d l d i h

Theory:E idi li

Control engineering Real-time system engineering

Timing models and requirements that are motivated by the runtime system rather than functionality (e.g. deadline = period)

l

Equidistant sampling Zero input-output latencies

l Reality: Timing requirements do not exist per se

and must be derived from functional requirements

Reality: Varying execution and response

times due to preemption, blocking data dependencies requirementsblocking, data-dependencies, ...

Sampling interval jitter Non negligible response times

Result: Functional integration effects due to timing are unpredictable Severe migration problems in case of platform modifications


Severe migration problems in case of platform modifications

9


Goals Co-engineering between real-time and control engineering

No integrated solution wanted: separation of concerns must be d b th di i li t b bl t f th i ti !

Goals

conserved, both discipline must be able to focus on their expertise ! What is a practical (minimal) interaction model ?

i f f f f Front loading: Assessment of functional behavior under the influence of resource sharing during design time on PC

Systematically derive timing requirements that are necessary to fulfill functional requirements

Use these timing requirements for system synthesis using adequate platform mechanisms





Approach 2: Formal analysis approachpp y pp Hybrid automatons and reachability analysis Electro Mechanic Braking System (EMB)

Conclusion



Practical Solution: Early Simulation FeedbackPractical Solution: Early Simulation Feedback

runnables, periods, constraints

Control Engineer(Simulink)

Software Engineering(TraceAnalyzer, SymTA/S)

Initial Control DesignVirtual Integrationwith SW Platform

Schedule Definition& Timing Model

Timing AnalysisTiming Simulation

Annotation of timing to simulation model

If needed: iterate long before code is

actually implemented

Evaluation of Control under

actual resource constraints

Timing profile for runnables



Timing Profile – OSEK Systems Description of points in time where the plant is sampled,

and where the actuation takes place Assumption: functionality implemented by a single runnable

g y

p y p y g Example: Bosch Engine Management

Copy-in of required data at task release Copy-out of produced data at runnable completion

High R1 R2 R1 R2 R1 R2 R1 R2 R1 R2 R1 R2 R1 R2

Tasks are container for

Middle

Low

R3 P3 R3 R3 R3

R4 R5 R5R4 R5R4R6 R6 R6

runnable that contain the functional code

Low R4 R5 R5R4 R5R4

P5Timing Profile

R6 R6 R6

R Ti Jitt


: sample : actuateResponse Time JitterSampling Jitter

13


Simulink Timing Toolbox BlocksSimulink Timing Toolbox Blocks

R1

R2

R3

R2

Function:

Idea: Model runnable behavior(algorithm and communication)

R1 • Each blocks uses list oftimestamps

• Rd & Wr blocks simulate readand write operations for each

R3

R1

and write operations for eachvariable

• Tr blocks executeTriggeredSubsystems at ti t i t t

R2


timestamp instants

14


How to get the Timing Profile ?How to get the Timing Profile ?SymTA/S platform model

Simulation

G tt di f t k ti ECU


Gantt diagram of task execution on ECU

15


Assignment of Timing Traces to BlocksAssignment of Timing Traces to Blocks

Start Endtimestamps

• Runnable Start-event becomesread-command and End-event b it d

timestamps

Simulink Action Timing Trace

becomes write-command• Triggering may be anywhere

between Start and End

S u ct o(TrigSubSys3)

g ace Event timestamps

‚Rd‘s : Sample & Hold R3 Start event

‚Tr‘ : Execute (0 time) R3 End event

W ‘ S l & H ld R3 E d t(Wr block to make it generic)


‚Wr‘s : Sample & Hold R3 End event(Wr block to make it generic)

16


Assignment of Timing Traces for complexer platformsg g p p

Option (I): Model all relevant activities in Simulink• Copy runnables network

Not all timing activities are modeled in Simulink like copy runnables and network processes

• Copy runnables, networkcommunication, gate ways …

• Potentially extra blocks• Manual - not generic

Option (II): Use SymTA/S Paths• Paths model data flow in Simulink

b blCopy runnable

between runnables• Can contain several runnables or

network frame transports• Correspond to one or multiple

W > Rd ti

Copy runnable in between

Wr -> Rd connections• Rd blocks read data of green

paths when data produced• Simulink model independent of

platform


platform

17


Proof of Concept: Car Road Damping (Active Suspension)

Is tool and concept applicable for complex systems? Case study: Damp car body acceleration with body control

C l t 12 bl 7 l t 4 f t t Complex system: 12 runnables, 7 accelerometers, 4 force actuators Exercise basic workflow with tool Tested different platform timing configurations z

Published SAE 2015 World Congress

Road unevennessin m

Source of Model: S. Ikenaga, F. L. Lewis, J. Campos and L. Davis (2000). Active Suspension Control of Ground Vehicle based on a Full-Vehicle Model. In Proceedings of the American Control Conference (ACC) Chicago USA


Control Conference (ACC). Chicago, USA.

18


Simulink model structureSimulink model structure

Diff. Eq.: Moving Disturbance

(Street)

Differential Equations

q gparts of car +

actuators

(Street)

Set point generation Local

Controllers

Observation of system‘s quantitiesquantities


Sensors

19


z

Road unevennessin m

Results for one set of control parameters (Shown: z-Acceleration in m/s²):

Ideal timing Timing Single Core Timing Distributed ECUs

• Program is able to handle complex systemsResults are plausible and show expected differences in response


• Results are plausible and show expected differences in response

20




Approach 2: Formal analysis approachpp y pp Hybrid automatons and reachability analysis Electro Mechanic Braking System (EMB)

Conclusion



Electro Mechanic Braking SystemElectro Mechanic Braking System

Force

Position


Position

22


Electro Mechanic Braking SystemElectro Mechanic Braking System

1. Inactive 2. Positioning 3. Brake

Force

Position


Position

23


Simulink Plant ModelSimulink Plant ModelVoltage

DC Motor

Rotating mass ofrotor and spindle

Gearing between rotationaland translational mass

Translational mass of thecaliper including stiff spring for brake disk

Braking Force

Caliper Position



Functional Requirements “Ready-to-brake” position x0 = 5 mm

Preparation of braking system for applying b k f f l

q

brake force, no force closure

Req. 1: Short response timef Reactiveness of the system

Caliper must be at x0 after the braking request is issued within 20ms with a precision of 4%

x0

Req. 2: Small impulse before braking Driver feels an abrupt deceleration The caliper speed at contact must be below 2mm/s Might be acceptable for braking, but not in other scenarios , e.g.

disk wiping



Formal analysis using hybrid automatons Formal analysis using hybrid automatons and reachability analysis



Functional Verification with ZET* AssumptionFunctional Verification with ZET Assumption

Closed-loop propertiesproperties

Plant Hybrid

(discrete)

Plant HybridAutomaton

(discrete)Software


*ZET = Zero Execution Time

27


Functional Verification considering TimingFunctional Verification considering Timing Model Timing in Hybrid Automaton

When is data written / readN d t i i ti d l

Closed-loop properties Non-deterministic model

Possible modelsLogical Execution Times

properties

Pl t Logical Execution Times Arrival Curves Typical Worst-Case Models

(di t )

Plant

…

Drivers for choosing a model Generality / analysis trade-off

(discrete)Software

read write Generality / analysis trade-off Decision to simplify design for

verifiabilityFunctional requirements

TimingProfile


Functional requirements

28


Which Timing Model to choose? LET ?

Trade Jitter against Latency DeterminismG t i lifi ti f ifi ti t k

Which Timing Model to choose?

Great simplification of verification task Ok for “robust” control tasks based on exact

models and little external disturbances

Arrival Curves? Precise model of possible system timing

behavior Large space of possible timings Closed-loop verification very difficult

Typical Worst-Case Model ! Allows for trade-off between both models



Typical Worst-Case Analysis Principle

Identify typical bounds for the behavior of a system and how often

Typical Worst Case Analysis

the system may leave these bounds

Output for each task a “safe” bound on its response times: SWCRT a typical bound: TWCRT a function err such that out of every k consecutive executions, at y

most err(k) response times may be larger than TWCRT

Advantagesg Approach is computationally very efficient m-out-of-k constraints are easy to understand No assumptions w.r.t. dependencies


No assumptions w.r.t. dependencies

30 30


Formal Analysis of Sporadic OverloadFormal Analysis of Sporadic Overload

T1 Scheduling policy: SPP(Static Priority Preemptive)

T2

(Static Priority Preemptive)T1 > T2

CPU1

T1

T2



Modeling Sporadic OverloadModeling Sporadic Overload

=Worst case

Typical case

+

yp

δ-over(3)

δ-over(2)Overload


over( )

32


Formal Analysis of Sporadic OverloadFormal Analysis of Sporadic Overload Input:

1. a worst-case model of the system2. a typical model ignoring the overload3. a model of the overload

Analysis (for each task):1. a busy window analysis of the worst-case model

Safe Worst-Case Response Time (SWCRT)p2. a busy window analysis of the typical-case model

Typical-Case Response Time (TWCRT)3. a computation of the error model based on the result of 1. and the p

overload model function err such that out of every k consecutive executions,

at most err(k) response times may be larger than TWCRT


at most err(k) response times may be larger than TWCRT

33


Using TWCRT Model for Closed-loop Functional Verification

Idea: Data is written to plant deterministically at TWCRT << WCRT (using LET)

T d ff b t d t i i & f ti l

Data for EMB example

Period = 1 ms Trade-off between determinism & functional

requirements TWCRT misses are bounded by error function

Period 1 msWCRT = 0.8 ms

TWCRT = 0.4 ms

Scalable “discrete” timing model

( bli h d RTSS 2014)


(published RTSS 2014)

34


Requirement 1: Response timeq p

< 20 ms

Arne Hamann | 06.03.2015 | © Robert Bosch 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.

< 20 ms



Requirement 2: Small impulseq p

< 1.25 A

• Current I proportional to the caliper velocity• Intersection reachable states with the plane of contact

B d [0 38 0 99] i fi h i 2

Arne Hamann | 06.03.2015 | © Robert Bosch 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.

• Bounds [0.38, 0.99] satisfies the requirement 2.



Comparison of different ApproachesComparison of different Approaches

ConstructionPrinciple Simulation Verification

LIB computationallyLIB

computationally

challenging

TWCRT + LET

LET trivial



Conclusion Both control and real-time engineers have idealized system models for

physical systems Functional integration effects are not considered by both disciplines

Conclusion

Functional integration effects are not considered by both disciplines Integration effects are anticipated with overdesign …but even then, functional correctness cannot be guaranteed

Simulation based approach for co-engineering between control and real-time Simulation based approach for co-engineering between control and real-time system engineering is feasible for complex systems Important requirement: separation of concerns

Reachability analysis for hybrid automatons is an adequate tool to verify Reachability analysis for hybrid automatons is an adequate tool to verify closed loop properties under timing influences for critical systems Recent advances allow analysis of industrial strength applications

Promising research area to close the gap between control and real-time Promising research area to close the gap between control and real time system engineering Verify correctness and performance of control software Derive timing requirements for system synthesis


Derive timing requirements for system synthesis

38


Q ti ???Questions ???

Methods and Tools for Timing-Aware Design of

Automotive Control Software Arne Hamann, Corporate Research, Robert Bosch GmbH

Joint work with: Matthias Wöhrle (Bosch), Dirk Ziegenbein (Bosch), Goran Frehse (Université Joseph Fourier Grenoble),


Sophie Quinton (INRIA Grenoble), Steffen Lampke (Technical University of Braunschweig)

39

Timing-Aware Design of Automotive Software Methods and ...

Documents

Transcript of Timing-Aware Design of Automotive Software Methods and ...