Architectural Simulation of Distributed ECU Systems

Motivation Definition Abstraction Classification Sample Usage Summary

Architectural Simulation ofDistributed ECU Systems

Joachim Schlosser

16. Dezember 2005


Why Architectural Simulation?Context & Motivation

• Increasing complexity of automotive systems

• Highly interconnected controller and control loop systems

• Complicated integration of functions

⇒ Support the development of the technical architecture:

• Flexible validation

• earlier, well-founded assertions on temporal and functionalbehavior

• Recognize HW/SW integration issues earlier

Task of the thesis: define, classify, assess


Terms of Architectural Simulation

Architectural simulation:execute behavioral models +architecture effects

(Technical) architecture:hardware platform + system platform

Behavioral model:functional behavior of components

⇒ Architectural simulation is a test method.⇒ Architectural simulation serves validation.


Related Work

• Functional simulation, e. g. Matlab/Simulink, ASCET-SD

• Rapid prototyping, e. g. xPC, dSpace, ETAS

• Hardware simulation, e. g. VHDL, Verilog

• Static architecture analysis, e. g. function chains, WCETanalysis, scheduling analysis


PrinciplePrinciple of Architectural Simulation

Example: safety critical, redundant systemfA Signal1

fBSignal2

fC

VerhaltenArchitektur

Mem

OSEK

CPU

BusCtrl BusCtrl BusCtrl

ECU1

Mem

OSEK

CPU

BusCtrl BusCtrl BusCtrl

ECU2

BusA

BusB

BusC


Reflection of AbstractionWhy a Taxonomy?

• Discussions on abstraction dissatisfying

Solution: use abstraction taxonomy

⇒ Improve discussion

⇒ Ensure consistency of models

⇒ Detect model disharmony and put in metric

⇒ Benchmark modeling and simulation tools


VSI TaxonomyVirtual Socket Interface Alliance: System Level Model Taxonomy

Time 1

Gateaccurate

2

Cycleaccurate

3

Cycleapprox.

4

Instructioncycles

5

Datacycles

6

Systemevents

7

Partialorder

Data 1

Bit

2

Data type

3

Abstract type

4

Property

5

Token

Function 1

Digital logic

2

Implementation

3

Algorithm

4

Mathematical

Structure 1

Structure

2

Block diagram

3

Black box

Program 1

Object code

2

Mikro code

3

Assembler

4

High levellanguage

5

DSPprimitive

6

Statemachine


NotationSimplification

VSI Taxonomy, displayed as vector:

a =

(aZaDaFaSaP

)( TimeData

FunctionStructure

ProgrammingModel

)

• disuse of axis expressed by ⊥• abstraction ranges written as intervalls, e. g.

aV =

[4,7][2,4]

22⊥


Dependencies betweeen Abstraction AxesCorrelations

Abstraction axes are not orthogonal.

Time

Data Function

Structure

ProgrammingModel

Why important?

• Consistency of models ("‘model harmony"’)


Dependencies betweeen Abstraction AxesSample Relation, Sample Usage

Sample: RZP = Time× ProgrammingModel

Time 1 2 3 4 5 6 7Program 2 2 3 3 4 5 6

Sample usage:

• CPU modell for run time estimation

• Estimates generated C code (level P = [4, 6])

• To deliver instruction cycles (level Z = 4)

• Relation states: RZP(4) = 3

⇒ Model cannot meet requirements


Dependencies between Types of ModelsWhy?

• Harmony of interacting models

• Discrepancy of abstraction admissible according toindividual dependency

• Consistency of abstraction of whole system


Types of Models with Abstraction and Dependencies

KomponentenimplementierungKomponentenverhalten

Funktionsnetzstruktur

Betriebssystem

Middleware

Stimulation Simulation

Architektur

Prozessor

Abbildung

Verhalten

Nachricht

Speicher

Signal

Prozess Task

FeldbusAnalyse

Fehler

1

1..*

1

1..*

0..11..*

0..*

1..*

1..*

1

0..11..*

0..1

1..* 1 1

1

1

0..1

1..*

0..1

1..*

0..1

0..*

0..*

1

1

1..*

[2,5]

2[2,3]

3[1,4]

[4,6][2,4]

33

[1,5]

221∞2



KomponentenimplementierungKomponentenverhalten

Funktionsnetzstruktur

Betriebssystem

Middleware

Stimulation Simulation

Architektur

Prozessor

Abbildung

Verhalten

Nachricht

Speicher

Signal

Prozess Task

FeldbusAnalyse

Fehler

1

1..*

1

1..*

0..11..*

0..*

1..*

1..*

1

0..11..*

0..1

1..* 1 1

1

1

0..1

1..*

0..1

1..*

0..1

0..*

0..*

1

1

1..*

[2,5]

2[2,3]

3[1,4]

[4,6][2,4]

33

[1,5]

221∞2



Postulation:[4,6][2,4]

33

[1,5]

≤( 2

21∞2

)+

[2,5]2

[2,3]3

[1,4]


Architectural Simulation in the Development Process(extremely simplified, no iterations)


Example of Usage Brake-by-Wire

• Simulation and architecture modeling withCadence VCC/SysDesign

• Function modeling with ETAS ASCET-SD

Sensor vRR

Sensor vRL

Sensor vFR

Sensor vFL

Bremsaktor RR

Bremsaktor RL

Bremsaktor FR

Bremsaktor FLBremspedal

Sensor

FeststellbremseSchalter


Simulation ResultsScheduling 1

0

0,02

0,04

0,06

0,08

0,10

3,500 3,505 3,510 3,515 3,520 3,525 3,530 3,535 3,540 3,545

q q q q q q

q q q q q q q q q

+ + +

+ +

r r r r r r r

r r r r r r r r

r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r

r r r r r r r r r r r r r r r r r r r r r r r

u u u u u u u u

u u u u u u u

Task 3.50 3.51 3.52 3.53 3.54

Arch/MCU1Arch/MCU2Arch/MCU3Arch/WCU_FLArch/WCU_FRArch/WCU_RLArch/WCU_RR

MCU1 OSEK::Archi...Behav/Fehlerbeh.Behav/Kraft_rlBehav/Kraft_frBehav/ÜberwachungBehav/SensorsignalBehav/Kraft_rrBehav/Signalverarb.Behav/Kraft_flBehav/Längskraft

0 1 2 3 4 5 6 7

20 ms 10,6 ms

Gesamtlatenz 43,5 ms

busallocation

{

prozessorutilization

{

(a) q Pedalpos. Sens. MCU2

(b) r Pedalpos. Sens. MCU2 auf MCU2

(c) + Pedalpos. Sens. MCU2 auf MCU1

(d) u normalisierte Klemmenkraft fl lokal

(e) r normalisierte Klemmenkraft fl MCU2 auf WCU fl


Simulation ResultsScheduling 2

0

0,02

0,04

0,06

0,08

0,10

3,500 3,505 3,510 3,515 3,520 3,525 3,530 3,535 3,540 3,545

q q q q q q

q q q q q q q q q

+

+ + +

r r r r r r

r r r r r r r r r

r r r r r r r r r r r r r r r r r r r r r r r r r r r r

r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r

u u u u u u

u u u u u u u u u

Task 3.50 3.51 3.52 3.53 3.54

Arch/MCU1Arch/MCU2Arch/MCU3Arch/WCU_FLArch/WCU_FRArch/WCU_RLArch/WCU_RR

MCU1 OSEK::Arch...Behav/Fehlerbeh.Behav/Kraft_rlBehav/Kraft_frBehav/ÜberwachungBehav/SensorsignalBehav/Kraft_rrBehav/Signalverarb.Behav/Kraft_flBehav/Längskraft

0.0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 2.0 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 3.0 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 4.0 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8

4,5 ms 4,3 ms

Gesamtlatenz 21,0 ms


Advantages of Architectural SimulationComparison to other test methods

• Better test depthsome properties hard or impossible to reproduce with realhardware

• Better test coverageautomated tests, simulation computers easier scale betterthan HiL/RP systems


Disadvantages

• Problem of test coverage

• In early phases no detailed models⇒ limited simulation accuracy

• Limited accuracy of software run time estimation

• Effort for assembly, analysis, model adation

• Complexity of tool chain and models


Summary and PerspectiveArchitectural Simulation

• Architectural simulation defined, classified, benchmarked

• Metrics for abstraction review

⇒ Earlier disclosure of inconsistencies in design andimplementation

⇒ Project dependent balancing of effort to expected benefit

⇒ Architectural simulation as project stopped

⇒ Use of static architecture analysis instead of/ ahead ofarchitectural simulation

Date post:	05-Jul-2015
Category:	Science
Upload:	joachim-schlosser
View:	148 times
Download:	2 times

Architectural Simulation of Distributed ECU Systems

Science