If you can't read please download the document
Upload
trinhkhue
View
220
Download
0
Embed Size (px)
Citation preview
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)
Automotive Software Engineering
Teil II: Modell-basierte Softwareentwicklung
Teil I: Software-basierte eingebettete Systeme im Automobil
Gliederung
Teil III: Modell-basiertes Testen
06-02-16 - 2
(C) 2005-2006 DaimlerChrysler (Conrad: Automotive Software Engineering - WS 2005/2006 - HU Berlin)
Automotive Software Engineering
Teil III: Modell-basiertes Testen
(C) 2005-2006 DaimlerChrysler (Conrad: Automotive Software Engineering - WS 2005/2006 - HU Berlin)
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
(C) 2005-2006 DaimlerChrysler (Conrad: Automotive Software Engineering - WS 2005/2006 - HU Berlin)
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
(C) 2005-2006 DaimlerChrysler (Conrad: Automotive Software Engineering - WS 2005/2006 - HU Berlin)
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
(C) 2005-2006 DaimlerChrysler (Conrad: Automotive Software Engineering - WS 2005/2006 - HU Berlin)
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
(C) 2005-2006 DaimlerChrysler (Conrad: Automotive Software Engineering - WS 2005/2006 - HU Berlin)
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
(C) 2005-2006 DaimlerChrysler (Conrad: Automotive Software Engineering - WS 2005/2006 - HU Berlin)
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
(C) 2005-2006 DaimlerChrysler (Conrad: Automotive Software Engineering - WS 2005/2006 - HU Berlin)
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
(C) 2005-2006 DaimlerChrysler (Conrad: Automotive Software Engineering - WS 2005/2006 - HU Berlin)
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
(C) 2005-2006 DaimlerChrysler (Conrad: Automotive Software Engineering - WS 2005/2006 - HU Berlin)
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
(C) 2005-2006 DaimlerChrysler (Conrad: Automotive Software Engineering - WS 2005/2006 - HU Berlin)
Modell-basierter Test
Testmglichkeiten (2): Testphasen
Modul-/Unittest
Systemtest
Testmglichkeiten (3): Funktions- vs. Strukturtests
(C) 2005-2006 DaimlerChrysler (Conrad: Automotive Software Engineering - WS 2005/2006 - HU Berlin)
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
(C) 2005-2006 DaimlerChrysler (Conrad: Automotive Software Engineering - WS 2005/2006 - HU Berlin)
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
(C) 2005-2006 DaimlerChrysler (Conrad: Automotive Software Engineering - WS 2005/2006 - HU Berlin)
Modell-basierter TestMglichkeitsraum -
Funktions-Test
Struktur-test
Systemverhaltens-modell
unit level
system levelunit level
system level
unit level
system levelunit 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
(C) 2005-2006 DaimlerChrysler (Conrad: Automotive Software Engineering - WS 2005/2006 - HU Berlin)
Modell-basierter TestMglichkeitsraum - Beispiele
Funktions-Test
Struktur-test
Systemverhaltens-modell
unit level
system levelunit level
system level
unit level
system levelunit 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
*.h*.c *.h*.c
Modellstrukturtestauf Modulebene
?=
Back-to-back Test Modell C-Code
(C) 2005-2006 DaimlerChrysler (Conrad: Automotive Software Engineering - WS 2005/2006 - HU Berlin)
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
(C) 2005-2006 DaimlerChrysler (Conrad: Automotive Software Engineering - WS 2005/2006 - HU Berlin)
Modell-basierter TestWiederverwendung von Testszenarien
SteuergertSteuergert FahrzeugFahrzeug
SystemreaktionSystemreaktion
TestszenarioTestszenario=
?
ModellModell C CodeC Code
*.h*.c
SystemreaktionSystemreaktion
TestszenarioTestszenario
SystemreaktionSystemreaktion
TestszenarioTestszenario
SystemreaktionSystemreaktion
TestszenarioTestszenario= =
? ?
systematisch
exemplarisch
(C) 2005-2006 DaimlerChrysler (Conrad: Automotive Software Engineering - WS 2005/2006 - HU Berlin)
Modell-basierter TestWiederverwendung von Testszenarien
Funktions-Test
Struktur-test
Systemverhaltens-modell
unit level
system levelunit level
system level
unit level
system levelunit 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
*.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
(C) 2005-2006 DaimlerChrysler (Conrad: Automotive Software Engineering - WS 2005/2006 - HU Berlin)
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
(C) 2005-2006 DaimlerChrysler (Conrad: Automotive Software Engineering - WS 2005/2006 - HU Berlin)
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
(C) 2005-2006 DaimlerChrysler (Conrad: Automotive Software Engineering - WS 2005/2006 - HU Berlin)
Modell-basiertes Testen Testverfahren fr Simulink/Stateflow-Modelle
Modellierungs-technik
SimulinkStateflown.a.
Testbasis
Bercksichtigungder internen
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
(C) 2005-2006 DaimlerChrysler (Conrad: Automotive Software Engineering - WS 2005/2006 - HU Berlin)
Modell-basiertes Testen Testverfahren fr Simulink/Stateflow-Modelle
Modellierungs-technik
SimulinkStateflown.a.
Testbasis
Bercksichtigungder internen
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
06-02-16 - 13
(C) 2005-2006 DaimlerChrysler (Conrad: Automotive Software Engineering - WS 2005/2006 - HU Berlin)
Fahrzeugsubsysteme/-domnen:
Antriebsstrang
Fahrwerk
Karosserie
Multi-Media
Verkehrsflussangepasste Geschwindigkeits-regelung (engl. Adaptive Cruise Control)
(C) 2005-2006 DaimlerChrysler (Conrad: Automotive Software Engineering - WS 2005/2006 - HU Berlin)
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
(C) 2005-2006 DaimlerChrysler (Conrad: Automotive Software Engineering - WS 2005/2006 - HU Berlin)
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)
(C) 2005-2006 DaimlerChrysler (Conrad: Automotive Software Engineering - WS 2005/2006 - HU Berlin)
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
(C) 2005-2006 DaimlerChrysler (Conrad: Automotive Software Engineering - WS 2005/2006 - HU Berlin)
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)
(C) 2005-2006 DaimlerChrysler (Conrad: Automotive Software Engineering - WS 2005/2006 - HU Berlin)
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
(C) 2005-2006 DaimlerChrysler (Conrad: Automotive Software Engineering - WS 2005/2006 - HU Berlin)
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
(C) 2005-2006 DaimlerChrysler (Conrad: Automotive Software Engineering - WS 2005/2006 - HU Berlin)
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
(C) 2005-2006 DaimlerChrysler (Conrad: Automotive Software Engineering - WS 2005/2006 - HU Berlin)
combination table time tagsabstract test
input description
Pedal Interpretation
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
(C) 2005-2006 DaimlerChrysler (Conrad: Automotive Software Engineering - WS 2005/2006 - HU Berlin)
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
(C) 2005-2006 DaimlerChrysler (Conrad: Automotive Software Engineering - WS 2005/2006 - HU Berlin)
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
Pedal Interpretation
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
(C) 2005-2006 DaimlerChrysler (Conrad: Automotive Software Engineering - WS 2005/2006 - HU Berlin)
test sequence 1:Recognition of pedal acti-vation by using special values which are held constant for a time t >> t.
Pedal Interpretation
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
(C) 2005-2006 DaimlerChrysler (Conrad: Automotive Software Engineering - WS 2005/2006 - HU Berlin)
Pedal Interpretation
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].
(C) 2005-2006 DaimlerChrysler (Conrad: Automotive Software Engineering - WS 2005/2006 - HU Berlin)
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
(C) 2005-2006 DaimlerChrysler (Conrad: Automotive Software Engineering - WS 2005/2006 - HU Berlin)
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
(C) 2005-2006 DaimlerChrysler (Conrad: Automotive Software Engineering - WS 2005/2006 - HU Berlin)
Modell-basiertes Testen Testverfahren fr Simulink/Stateflow-Modelle
Modellierungs-technik
SimulinkStateflown.a.
Testbasis
Bercksichtigungder internen
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.
(C) 2005-2006 DaimlerChrysler (Conrad: Automotive Software Engineering - WS 2005/2006 - HU Berlin)
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
(C) 2005-2006 DaimlerChrysler (Conrad: Automotive Software Engineering - WS 2005/2006 - HU Berlin)
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
(C) 2005-2006 DaimlerChrysler (Conrad: Automotive Software Engineering - WS 2005/2006 - HU Berlin)
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
(C) 2005-2006 DaimlerChrysler (Conrad: Automotive Software Engineering - WS 2005/2006 - HU Berlin)
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
(C) 2005-2006 DaimlerChrysler (Conrad: Automotive Software Engineering - WS 2005/2006 - HU Berlin)
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
(C) 2005-2006 DaimlerChrysler (Conrad: Automotive Software Engineering - WS 2005/2006 - HU Berlin)
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