automotive software engineering - informatik.hu-berlin.dehs/lehre/2005-ws_swe2... · 06-02-16 - 5...

06-02-16 - 1

Automotive Software Engineering

Dr.-Ing. Mirko Conrad

DaimlerChrysler AG Research and TechnologyMirko.Conrad @ DaimlerChrysler.com

+49 30 39982-263

(C) 2005-2006 DaimlerChrysler (Conrad: Automotive Software Engineering - WS 2005/2006 - HU Berlin)


Teil II: Modell-basierte Softwareentwicklung

Teil I: Software-basierte eingebettete Systeme im Automobil

Gliederung

Teil III: Modell-basiertes Testen

06-02-16 - 2



Teil III: Modell-basiertes Testen


Testen Software-basierter eingebetteter Systeme im Automobil - MotivationDynamisches Testen

wichtigste und meistverbreitete Qualittssicherungsmanahme fr Software-basierte eingebettete Systeme im Automobil (Mittelpunkt der Verifikations- und Validations-

aktivitten)aber:

Tests stellen einen bedeutenden Zeit- und Kostenfaktor dar

Tests erfolgen (zu) hufig im Fahrzeug und nicht im Bro

Tests werden hufig ad-hoc und damit unsystematisch durchgefhrt

Wiederverwendung von Testszenarien erfolgt nur in Ausnahmefllen

Testqualitt wird nicht objektiv gemessen

Testauto-matisierungTestauto-

matisierunghohe Kosten

geringeFehlerauf-deckung

TestmethodikTestmethodik

06-02-16 - 3


Fehlerhafte Teile desEingabedatenraumes

Testen Software-basierter eingebetteter Systeme im Automobil - Ad-hoc Testing

i1

i2 Eingabedatenraum

Testszenarienfehleraufdeckend /nicht fehleraufdeckend

Test-redundanzen

i1

i2

o1

o2Testobjekt

Testlcher

Testverfahren / Testwerkzeuge fr den systematischen TestSoftware-basierter eingebetteterSysteme im Automobil


Modell-basierter TestNutzung der vorhandenenModelle als y Informationsquelle

fr den Test

Testen Software-basierter eingebetteter Systeme im Automobil - Grundidee

Lsungsansatz im Rahmen der Modell-basierten Entwicklung: Modell-basiertes Testen

Modell-basierte Entwicklungdurchgngiger Einsatz von Modellen fry Spezifikationy Designy Implementierung

Modell-basiertes Entwickeln ermglicht und erfordert neue Herangehensweisen an den Softwaretest

yfrhzeitiges Vorliegen ausfhrbarer ArtefakteyModelle als reichhaltige InformationsquelleyModellevolution

06-02-16 - 4


Modell-basiertes Testen Allgemeine Definitionen

y an approach that bases common testing tasks [...] on a model of the application under test

[EW01] I. K. El-Far, J. A. Whittaker: Model-based Software Testing. In: J.J. Marciniak (Ed.): Encyclopedia of Software Engineering, 2. edition, Wiley 2001

y a technique for checking the behavior of a system, based on the deployment of models, i.e. abstractions, of the system

[PP02] A. Pretschner, J. Philipps: Szenarien modellbasierten Testens. TB TUM-I0205, TU Mnchen, Inst. fr Informatik, Juli 2002


Modell-basiertes Testen Bereichsspezifische Definition (Automotive View)

y Notwendigkeit, die eingebettete Software und ihre Vorstufen (ausfhrbare Modelle) mit aufeinander abgestimmten Testverfahren zu prfen um Fehler aufzudecken und Vertrauen in die korrekte Funktionsweise zu gewinnen

y Modell-basierter TestEntwicklungsbegleitender Testprozess im Rahmen der Modell-basierten Entwicklung, der eine Kombination unterschiedlicher, sich gut ergnzender Testverfahren umfasst und dabei ausfhrbare Modelle als reichhaltige Informationsquelle fr den Test benutzt

/Con04/ M. Conrad: Modell-basierter Test eingebetteter Software im Automobil - Auswahl und Beschreibung von Testszenarien. Dt. Universittsverlag, Wiesbaden, 2004

prozessorientierte SichtweiseNutzung der im Entwicklungsprozess ohnehin vorhandenen ausfhrbarenModelle fr Testzwecke steht im Vordergrundallgemeiner als Definitionen, die die Existenz separater Modelle fr den Test ('Testmodelle') fordern

06-02-16 - 5


Modell-basiertes Testen Modelle als Informationsquelle

y Mgliche Rollen ausfhrbarer Modelle im Testprozess:

y Besonderheit: grere Anzahl ausfhrbarer Artefakte zahlreiche Testmglichkeiten Teststrategie

Modell als Testobjekt ('Modelltest, Model-in-the-Loop Test, MIL)* Modell als Testbasis fr die Ermittlung der TestszenarienModell als TestorakelModell als Basis fr strukturorientierte berdeckung (model coverage)* MIL model test model-based test


Modell-basiertes Testen Begriffe: Testszenario, Testverfahren

Testszenario (engl. test scenario)Allgemeine Beschreibung eines Prffalles, die eine Menge von (konkreten) Testdatenoder Testdatenverlufen spezifiziert

Testverfahren (engl. test design technique)Standardisierte Vorgehensweise fr die Ermittlung von Testszenarien auf Basis bestimmter Informationsquellen (z.B. funktionale Spezifikation, ausfhrbares Modell, Programmcode).

06-02-16 - 6


Modell-basiertes Testen Testmglichkeiten

y Modell-basierte Entwicklung bietet zahlreiche 'Testmglichkeiten':

y nicht alle denkbaren Kombinationen knnen und sollen getestet werden

sorgfltige Auswahl im Rahmen einer Teststrategie

Systemverhaltens-modellPhysikalisches ModellImplementierungsmodellC-Code HostC-Code TargetSteuergertFahrzeug

ModultestSystemtest

+ Kombinatorik


Modell-basierter TestTestmglichkeiten (1): Testartefakte

Systemverhaltensmodell

Physikalisches Modell Model-in-the-Loop (MIL)

Implementierungsmodell

C-Code Host Software-in-the-Loop (SIL)

C-Code Target Processor-in-the-Loop (PIL)

Steuergert Hardware-in-the-Loop (HIL)

*.h*.c

*.h*.c

06-02-16 - 7


Modell-basierter Test

Testmglichkeiten (2): Testphasen

Modul-/Unittest

Systemtest

Testmglichkeiten (3): Funktions- vs. Strukturtests


Modell-basierter TestFunktions- vs. Strukturtests

Funktionstests (Black-box Tests)Nachweis, dass das Modell / die Softwaredie Anforderungen erflltTestbasis: AnforderungsspezifikationZiel der Testauswahl:

berdeckung aller Anforderungenrequirements coverageberdeckung der Wertebereiche von In und/oder Outputs (optional)range coverage

Strukturtests (White-box Tests)Nachweis, dass alle Teile des Modells / der Software ausgefhrt wurdenTestbasis: Modell / C CodeZiel der Testauswahl: berdeckung aller Modell- / Codeelemente model / code coverage'

path A

path B Switch

controlIn 1

In 2

06-02-16 - 8


Modell-basierter TestBack-to-Back Tests

Back-to-back TestsNachweis, dass sich zwei verschiedene Stadien der Modellevolution funktional gleichwertig verhalten(vergleichendes Testen zur Absicherung eines Entwicklungsschrittes) Stimulation zweier unterschiedler, ausfhrbarer Artefakte mit den selben Testszenarien und Vergleich der Systemreaktionen auf hinreichende hnlichkeit Wiederverwendung bereits existierender Testszenarien, unabhngig davon, ob diese aus Black- oderWhite-box-Tests stammen

?=

?=

*.h*.c


Modell-basierter TestMglichkeitsraum -

Funktions-Test

Struktur-test

Systemverhaltens-modell

unit level

system levelunit level

system level

unit level


system level

system level

unit level

system level

system level

unit level

system level

system level

system level

system level

system level

PhysikalischesModell

Implementierungs-modell

C-CodeHost

C-CodeTarget

Steuergert

unit level

unit level

y Nicht alle Testmglichkeiten knnen / sollen genutzt werden Teststrategie

*.h*.c *.h*.c

Testartefakt x Testphase x { | }

06-02-16 - 9


Modell-basierter TestMglichkeitsraum - Beispiele

Funktions-Test

Struktur-test


unit level


system level

unit level


system level

system level

unit level

system level

system level

unit level

system level

system level

system level

system level

system level



C-CodeHost

C-CodeTarget

Steuergert

unit level

unit level

*.h*.c *.h*.c

Modellstrukturtestauf Modulebene

?=

Back-to-back Test Modell C-Code


Modell-basierter TestWiederverwendung von Testszenarien

complete modelsubsystem 1subsystem 2subsystem 3subsystem 3.1

n.a. complete modelsubsystem 1subsystem 2subsystem 3

complete code

Modellevolution t

Systemverhaltensmodell Physikalisches Modell Implementierungsmodell C-Code Target

*.h*.c

06-02-16 - 10



SteuergertSteuergert FahrzeugFahrzeug

SystemreaktionSystemreaktion

TestszenarioTestszenario=

?

ModellModell C CodeC Code

*.h*.c


TestszenarioTestszenario


TestszenarioTestszenario


TestszenarioTestszenario= =

? ?

systematisch

exemplarisch



Funktions-Test

Struktur-test


unit level


system level

unit level


system level

system level

unit level

system level

system level

unit level

system level

system level

system level

system level

system level



C-CodeHost

C-CodeTarget

Steuergert

unit level

unit level

*.h*.c *.h*.cArten der Wiederverwendung

y logische (Testszenarien) / technische (Testdaten, Test-skripte) Wiederverwendung

y horizontale / vertikale Wieder-verwendung ber verschiedene Testebenen innerhalb einer Baureihe

y Wiederverwendung innerhalb einer Testebene ber unterschiedliche Baureihen (z.B. E-Klasse, S-Klasse)

y Wiederverwendung innerhalb einer Testebene zwischen Vorgnger-Baureihe und aktueller BR (z.B. E-Klasse aktuell vs. E-Klasse Nachfolger)

y Wiederverwendung von Testinputs vs. Wiederverwendung von Testoutputs/Sollwerteny

Welche Art der Wiederverwendung ist wann/wo sinnvoll und mglich?

06-02-16 - 11


Modell-basiertes Testen Klassifikation von Testanstzen (1/2)

Modellierungs-technik

SimulinkStateflown.a.

Testbasis

EvolutionsstufeSpezifikationsmodellDesignmodellImplementierungsmodell

Textuelle Spezifilation

Bercksichtigungder internen

Struktur

black-boxwhite-box

Testauswahl-kriterium

Requirements CoverageData CoverageTime CoverageProperty-basedFault-basedRandom / Stochastic

Automati-sierungsgrad

Testauswahl

manuellautomatisch

ad-hoc


Modell-basiertes Testen Klassifikation von Testanstzen (2/2)

Testobjekt(SUT)

Evolutionsstufe

SpezifikationsmodellDesignmodellImplementierungsmodellAutocode (Host)Autocode (Target)Eingebettetes System (ECU)Fahrzeug

Rckkopplungopen-loopclosed loop

Testreferenzfunktionale Spezifikationandere Evolutionsstufe (Back-to-back Test)andere Version (Regressionstest)

06-02-16 - 12


Modell-basiertes Testen Testverfahren fr Simulink/Stateflow-Modelle



Testbasis


Struktur

black-boxwhite-box

Testauswahl

Simulink

Sta

teflo

w

TPT(4)

Zufalls-tests

(1) Klassifikationsbaum-Methode frEingebettete Systeme (CTMEMB)

(2) Evolutionrer Sicherheitstest (EST)(3) Modell-basierter Black-box Test (MB3T)(4) Time Partition Testing (TPT)

EST(2)

CTMEMB(1)

Testgene-rierung durch

Model-checking

Constraint-basierte

Testdaten-analyse

Modell-basierteTestfall-

extraktion

Modell-struktur

tests

I/O-OrientiertesTest Design

MB3T(3) Prototyp-

bas. Test frhybride reak-

tive Syst.

Verfahrensbeschreibungen und untersttzendeWerkzeuge:

[CF05] M. Conrad, I. Fey: Modell-basierter Test von Simulink/Stateflow-Modellen.Proc. Kolloqium Testen im System- und Software-Life-Cycle,S.278-298, TAE Esslingen, Nov. 2005





Testbasis


Struktur

black-boxwhite-box

Testauswahl

Simulink

Sta

teflo

w

TPT(4)

Zufalls-tests



EST(2)

CTMEMB(1)


Model-checking

Constraint-basierte

Testdaten-analyse


extraktion

Modell-struktur

tests


MB3T(3) Prototyp-


tive Syst.

Verfahrensbeschreibungen und untersttzendeWerkzeuge:

[CF05] M. Conrad, I. Fey: Modell-basierter Test von Simulink/Stateflow-Modellen.Proc. Kolloqium Testen im System- und Software-Life-Cycle,S.278-298, TAE Esslingen, Nov. 2005

06-02-16 - 13


Fahrzeugsubsysteme/-domnen:

Antriebsstrang

Fahrwerk

Karosserie

Multi-Media

Verkehrsflussangepasste Geschwindigkeits-regelung (engl. Adaptive Cruise Control)


Test Design Techniques for Simulink / Stateflow ModelsThe Classification-Tree Method for Embedded Systems CTMEmb

systematic approach for the selection of test scenarios and a notation for their appropriate description

systematic design of time-variable test scenarios based on the data-oriented equivalence partitioning of the input domain

compact, problem-oriented representation, suitable for a human tester and containing a high potential for reusability

activities:test input partitioningtest scenario determinationtest data refinement

06-02-16 - 14


12Gang_i

11i_Ges10

n_Mot 9a_Fzg

8Tempomatmodus

7Fahrerwarnung

6d_rel

5d_soll

4v_Soll

3M_Mot_b

2M_Br_b

1v_Fzg

v_Ziel

v_Fzg

d_rel

v_rel

Ziel

Zielerkennung

FzgDaten

ZielDaten

WunschMomente

PedalFlags

BedienhebelStellung

AbstandsFaktor

TempomatFlag

v_Soll

FahrerWarnung

Stellgroessen

TempomatModus

d_soll

TmA

v_act

PedalPositions

DesiredTorques

PedalFlags

PedalInterpretation

Tempomat mit Abstandsregelung----------------------------------------------Last Change:MCONRAD 01-May-2003 21:36:32

DesiredTorques

FzgDatenStellgroessen

Handbetrieb

Fahrzeugmodell

Demux

5Abstandsfaktor

4v_Ziel

3 BedienhebelStellung

2BremspedalWinkel

1FahrpedalWinkel

phi_Brake

LeverPos

d_reld_rel

Ziel

DistFactor

v_Ziel

phi_Acc

v_rel

Adaptive Cruise ControlPhysical Model (Simulink/Stateflow)

Preprocessing componentPedal interpretation (short: PedInt)


Pedal Interpretation

T_des_Drive [Nm] (Wunschabtriebsmoment)T_Des_Brake [Nm] (Wunschbremsmoment)

2PedalFlags

1DesiredTorques

f(u)

selection

70

ped_min

T_70_Drive(v)

T_100_Drive(v)

>=

>

Mux

1/100T_max_Brake

1/30

1/70

(boolean)

(boolean)

2PedalPositions

1v_act

v_act

T_des_Drive

AccPedal

BrakePedal

AccPedal

BrakePedal

T_des_Brake

2PedalPositions

06-02-16 - 15


CTMEmb Test Input Partitioning

i2

i2.1

i2.2

i2.3

i2.4

i2.5

i1

i1.1 i1.2 i1.3 i1.4 i1.5

test object disjoint & complete partitioning into equivalence classes which are suitable abstractions of individual input values

equivalence classes shouldbehave homogeneously w.r.t.the detection of potential errors (= heuristic procedure)


Pedal Interpretation PedInt

phi_Acc

0]0, ped_min[

ped_min

100]ped_min, 100[

real[0,100]%phi_Brake

data typedomainunitvariable

Recognition of brake pedal activationIf the brake pedal is depressed more than athreshold value ped_min, the BrakePedal flag should be set to the value 1, otherwise to 0.

ID DescriptionPI-01.1

06-02-16 - 16


Pedal Interpretation PedInt

phi_Acc

0]0, ped_min[

ped_min

100]ped_min, 100[

phi_Brake

0]0, ped_min[

ped_min

100]ped_min, 100[

classification-tree

induced partitioning of input data space


CTMEmb - Test Scenario Determination

i2

i2.1

i2.2

i2.3

i2.4

i2.5

i1

i1.1 i1.2 i1.3 i1.4 i1.5

test object

test stepi1 i1.3 / i2 i2.1

abstract description of the course of inputs over time based on thetest input partitioning

test scenario:t = t0: i1 i1.3 / i2 i2.1t = t1: i1 i1.2 / i2 i2.2...

t = tend: i1 i1.1 / i2 i2.5

06-02-16 - 17


combination table time tagsabstract test

input description


Time [s]TScen 1

TStep 1.1 0 TStep 1.2 0.2

TStep 1.3 0.5

... ...

PedInt

phi_Acc phi_Brake

0]0, ped_min[

ped_min

100]ped_min, 100[:

0]0, ped_min[

ped_min]ped_min, 100[

100


CTMEmb - Test Data Refinement

i2

i2.1

i2.2

i2.3

i2.4

i2.5

i1

i1.1 i1.2 i1.3 i1.4 i1.5

test object refinement of abstracttest input descriptions into signal waveformsby selecting specific numbersfor each equivalence class

test scenario:t = t0: i1 i1.3 / i2 i2.1t = t1: i1 i1.2 / i2 i2.2...

t = tend: i1 i1.1 / i2 i2.5

test data:i1(t0) = 5 / i2(t0) = 0i1(t1) = 1 / i2 (t1) = 1....i1(t5) = 0 / i2 (t5) = 100

06-02-16 - 18


Time [s]TScen 1

TStep 1.1 0 TStep 1.2 0.2

TStep 1.3 0.5

... ...

PedInt

phi_Acc phi_Brake

0]0, ped_min[

ped_min

100]ped_min, 100[:

0]0, ped_min[

ped_min]ped_min, 100[

100

test data


0 0.1 0.2 0.3 0.4 0.5 0.6

100

50

phi_Acc [%]

Time [s]

step

0 0.1 0.2 0.3 0.4 0.5 0.6

100

50

phi_Brake [%]

Time [s]

sine

ramp


test sequence 1:Recognition of pedal acti-vation by using special values which are held constant for a time t >> t.


0 0.20.4

phi_Brakephi_Acc

v_act-1005

70100

time [s]

Test 1 / Test sequence 1

0]0,ped_min[

phi_Brake

ped_min

]ped_min,100[

PedalPositions

100

0

]0,ped_min[

PedalInterpretation

phi_Gas

ped_min

Inputs

]ped_min,100[

100

AuLa

Ti [ ]0.50.40.30.20.1

0Time [s]

06-02-16 - 19



test sequence 2:Testing the hysteretic properties of the test object.Therefore, the pedal positions are ramped up and down covering the entire domain.

01

2phi_Brakephi_Acc

v_act

0

50

100

time [s]

Test 1 / Test sequence 2

0]0,ped_min[

phi_Brake

ped_min

]ped_min,100[

PedalPositions

100

0

]0,ped_min[

PedalInterpretation

phi_Gas

ped_min

Inputs

]ped_min,100[

100

AL

210

Time [s].


Pedal InterpretationRequirements Traceability

ID Beschreibung

SR-PI-01 Erkennung der PedalbettigungWerden Fahr- oder Bremspedal ber einen bestimmten Schwellwerthinaus bettigt, ist dies durch ein pedalspezifisches Binrsignalanzuzeigen.

SR-PI-01.1 Erkennung der BremspedalbettigungWird das Bremspedal ber einen Schwellwert ped_min hinaus bettigt,ist das Binrsignal BrakePedal auf den Wert 1 zu setzen, andernfallsauf 0.

SR-PI-01.2 Hysterese BremspedalbettigungBei der Erkennung der Bremspedalbettigung ist keine Hysteresevorzusehen.

SR-PI-01.3 Erkennung der FahrpedalbettigungWird das Fahrpedal ber einen Schwellwert ped_min hinaus bettigt, istdas Binrsignal AccPedal auf den Wert 1 zu setzen, andernfalls auf 0.

SR-PI-01.4 Hysterese FahrpedalbettigungBei der Erkennung der Fahrpedalbettigung ist keine Hysteresevorzusehen.

SR-PI-02 Interpretation der PedalwegeDie normierten Pedalwege von Fahr- und Bremspedal sind als Wunsch-momente zu interpretieren. Dabei sind sowohl Komfort- als auchVerbrauchsaspekte zu bercksichtigen.

SR-PI-02.1 Interpretation des BremspedalwegesDer normierte Bremspedalweg ist als WunschbremsmomentT_des_Brake [Nm] zu interpretieren. Das Wunschbremsmoment ergibtsich, indem der aktuelle Pedalweg zum maximalen BremsmomentT_max_Brake ins Verhltnis gesetzt wird.

SR-PI-02.2 Interpretation des FahrpedalwegesDer normierte Fahrpedalweg ist als WunschabtriebsmomentT_des_Drive [Nm] zu interpretieren. Das Wunschabtriebsmoment istdabei im nichtnegativen Bereich geschwindigkeitsabhngig so zuskalieren, dass bei hheren Geschwindigkeiten derAbtriebsmomentenwunsch kleiner wird.*

0]0,ped_min[

phi_Brake

ped_min

]ped_min,100[

PedalPositions

100

0

]0,ped_min[

PedalInterpretation

phi_Gas

ped_min

Inputs

]ped_min,100[

100

Author Last Changed

MCONRAD11.05.2003 00:38

-10

]-10,0[

v_act

0]0,70[

70

10-delta_t 3.10: 8 3.9:

8-delta_t 3.8: 6 3.7:

6-delta_t 3.6: 4 3.5:

4-delta_t 3.4: 2 3.3:

2-delta_t 3.2: 0 3.1:

Time [s]3: Test der Fahrpedalinterpretation2 2.3: 1 2.2: 0 2.1:

Time [s]2: Erkennung der Pedalbettigung (2) - . ..0.5 1.6: 0.4 1.5: 0.3 1.4: 0.2 1.3: 0.1 1.2:

0 1.1: Time [s]1: Erkennung der Pedalbettigung (1) - . ..

?

isCheckedBy

SR-P

I-01

SR

-PI-0

1.1

SR

-PI-0

1.2

SR

-PI-0

1.3

SR

-PI-0

1.4

SR-P

I-02

SR

-PI-0

2.1

SR

-PI-0

2.2

Test 1 / Testseq. 1 ( )Test 1 / Testseq. 2 ( ) ( )Test 1 / Testseq. 3 ( )

Test 1 / Testseq. 1Test 1 / Testseq. 2Test 1 / Testseq. 3

Traceability Matrix

requirements test scenarios

06-02-16 - 20


0]0,ped_min[

phi_Brake

ped_min

]ped_min,100[

PedalPositions

100

0

]0,ped_min[

phi_Gas

ped_min

]ped_min,100[

100

-10

]

210

Time [s]

CTMEmb Summary

ID Description

SR-PI-01.2 Hysteretic behavior of brake pedal activationNo hysteresis is to be expected during brake pedal activation recognition.

v_Fzg Ziel

Zielerkennung

v_act

PedalPositions

DesiredTorques

PedalFlags

PedalInterpretation

ng

elBrake

06-02-16 - 21





Testbasis


Struktur

black-boxwhite-box

Testauswahl

Simulink

Sta

teflo

w

TPT(4)

Zufalls-tests



EST(2)

CTMEMB(1)


Model-checking

Constraint-basierte

Testdaten-analyse


extraktion

Modell-struktur

tests


MB3T(3) Prototyp-


tive Syst.


path B

path A

Test Design Techniques for Simulink / Stateflow ModelsStructural Model Testing

Pass through In1 whencontrol threshold;otherwise, pass throughIn2

test goal test input specification

Switch

control

In 1

In 2

M1 (path A) control threshold

M2 (path B) control < threshold

Model Coverage Metrics Decision Coverage on Model Level (M_D1) Pathways through a Switch Block and Test Goals

06-02-16 - 22


Test Design Techniques for Simulink / Stateflow ModelsStructural Model Testing

T_out_des_CC [Nm]

v_act [m/s]Manipulated

Variables

1

DesiredSpeed

BrakePedal

AccPedal

Lever

ControlState

InitDesiredSpeed

SetDesiredSpeed

IncreaseDesiredSpeed

DecreaseDesiredSpeed

TempomatContro

ReduceDesiredSpeed()

SetDesiredSpeed()

InitDesiredSpeed()

IncreaseDesiredSpeed()

v_Soll

v_Soll

ActualSpeed

PedalPositions

DesiredTorques_Drv

PedalFlags

PedalInterpretation

ActualSpeed

TargetData

DesiredTorque_DC

DistanceControl

Data Store

ActualSpeed

DesiredSpeed

DesiredTorque_CC

CruiseControlVehicleData

DesiredToruqe_CC

DesiredTorque_DC

TargetData

DesiredTorques_Drv

ControlState

ManipulatedVariables

Coordination

4

Pedal

Positions

3

TargetData

VehicleData

1

CruiseControl

Lever

v_des [ms]

v_act [m/s]

BrakePedal

AccPedal

T_out_des_DC [Nm]

Lever

v_des [m/s]

0% 100%

0% 100%

0% 100%

0% 100%

0% 100%

2

CruiseControl100,0%

DistanceControl92,4%

TempomatContro25,9%

PedalInterpretation52,1%

Coordination95,4%

Model Coverage Monitoring


Modellbasierter TestEffektive Teststrategie fr den Modell-basierten Test

Testbasis Testverfahren Testobjekt

Modell

C-Code

Steuergert

Anforderungen

?

SystemreaktionTestdaten

Modell

Systematischer Funktionstest auf Modellebene (Black-box Test)Monitoring der ModellberdeckungStrukturtest auf Modellebene (White-box Test)Back-to-back-Tests Modell Software ECU

/ * pi c t r l * /#def i ne " dst ypes . h#def i ne G1 ( I nt 32) 0x

voi d pi ct r l ( UI nt 16 r { I nt 16 e, S2, G_1, x1, UI nt 8 i ; e = ( I nt 16) ( r ef >> G_1 = ( I nt 16) ( ( ( a> x1 = ( e >> 4) +x1; G_2 = ( I nt 16) ( ( ( a> * u = G2 + G1;

Classification-Tree Method forEmbedded Systems CTMEmb

Model CoverageMonitoring

06-02-16 - 23


Effektive Teststrategie fr den Modell-basierten TestEmpfehlungen

y Frhzeitiger Beginn des Black-box-Tests (d.h. auf Modellebene) zur Absicherung der Funktionalitt

y Durchfhrung von Strukturtests als Ergnzung - nicht als Ersatz zur Absicherung der strukturellen Integritt

y Nutzung von vergleichenden Tests (Back-to-Back-Tests) zur Absicherung der Transformationsschritte(Systemverhaltensmodell Physikalisches Modell Implementierungs-modell C-Code Host C-Code Target Steuergert)

y Erhhung der Wiederverwendung von Modellkomponenten und damit derzugehrigen Tests


Automotive Software EngineeringTeil III: Modell-basiertes Testen

y Modell-basiertes Testen ist state-of-the-art bei der Qualittssicherung Modell-basiertentwickelter Fahrzeugsofware

y Testaktivitten werden in frhe Entwicklungsphasen vorverlagert, Lern- und Korrekturprozesse knnen frhzeitig beginnen

y entwicklungsbegleitender Testprozess in der Modell-basierten Entwicklung,zahlreiche Testmglichkeiten

y Nutzung von Simulink/Stateflow-Modellen als reichhaltige Informationsquelle fr den Test

y Kombination verschiedener, sich gegenseitig ergnzender Testverfahren:effektive Teststrategie fr den Modell-basierten Test

y Testverfahren fr Simulink/Stateflow-ModelleKlassifikationsbaum-Methode fr eingebettete Systeme CTMEMBModellstrukturtests

Zusammenfassung

06-02-16 - 24


Automotive Software EngineeringTeil III: Modell-basiertes Testen

M. Conrad: Modell-basierter Test eingebetteter Software im Automobil - Auswahl und Beschreibung von Testszenarien.Deutscher Universittsverlag, Wiesbaden, Okt. 2004

M. Conrad:A Systematic Approach to Testing Automotive Control Software.Proc. Convergence 2004, Detroit, Okt. 2004 (SAE technical paper #2004-21-0039)

K. Lamberg, M. Beine, M. Eschmann, R. Otterbach, M. Conrad, I. Fey:Model-based testing of embedded automotive software using MTest.Proc. SAE World Congress 2004, Detroit, Mrz 2004 (SAE technical paper #2004-01-1593)

M. Conrad, I. Fey, S. Sadeghipour: Systematic Model-Based Testing of Embedded Control Software: The MB3T Approach.Proc. ICSE 2004 Workshop on Software Engineering for Automotive Systems (SEAS04), Edinburgh, Mai 2004

www.immos-project.de > Papers

automotive software engineering - informatik.hu-berlin.dehs/lehre/2005-ws_swe2... · 06-02-16 - 5...

Documents