Automotive Software Engineering

Transkript

1 Automotive Software Engineering Dr.-Ing. Mirko Conrad DaimlerChrsler AG Research and Technolog DaimlerChrsler.com Gliederung Automotive Software Engineering Teil I: Teil II: Software-basierte eingebettete Ssteme im Automobil Modell-basierte Softwareentwicklung Teil III: Modell-basiertes Testen

2 Automotive Software Engineering Teil III: Modell-basiertes Testen Testen Software-basierter eingebetteter Ssteme im Automobil - Motivation hohe Kosten Dnamisches Testen wichtigste und meistverbreitete Qualitätssicherungsmaßnahme für Software-basierte eingebettete Ssteme im Automobil (Mittelpunkt der Verifikations- und Validationsaktivitäten) aber: Tests stellen einen bedeutenden Zeit- und Kostenfaktor dar Tests erfolgen (zu) häufig im Fahrzeug und nicht im Büro Tests werden häufig ad-hoc und damit unsstematisch durchgeführt Wiederverwendung von Testszenarien erfolgt nur in Ausnahmefällen Testqualität wird nicht objektiv gemessen Testautomatisierung Testautomatisierung Testmethodik Testmethodik geringe Fehleraufdeckung

3 Testen Software-basierter eingebetteter Ssteme im Automobil - Ad-hoc Testing i o 1 1 i 2 Testobjekt o 2 i 2 Eingabedatenraum Testlöcher Testredundanzen i 1 Fehlerhafte Teile des Eingabedatenraumes Testszenarien fehleraufdeckend / nicht fehleraufdeckend Testverfahren / Testwerkzeuge für den sstematischen Test Software-basierter eingebetteter Ssteme im Automobil Testen Software-basierter eingebetteter Ssteme im Automobil - Grundidee Lösungsansatz im Rahmen der Modell-basierten Entwicklung: Modell-basiertes Testen Modell-basiertes Entwickeln ermöglicht und erfordert neue Herangehensweisen an den Softwaretest frühzeitiges Vorliegen ausführbarer Artefakte Modelle als reichhaltige Informationsquelle Modellevolution Modell-basierte Entwicklung durchgängiger Einsatz von Modellen für Spezifikation Design Implementierung Modell-basierter Test Nutzung der vorhandenen Modelle als Informationsquelle für den Test

4 Modell-basiertes Testen Allgemeine Definitionen an approach that bases common testing tasks [...] on a model of the application under test [EW1] I. K. El-Far, J. A. Whittaker: Model-based Software Testing. In: J.J. Marciniak (Ed.): Encclopedia of Software Engineering, 2. edition, Wile 21 a technique for checking the behavior of a sstem, based on the deploment of models, i.e. abstractions, of the sstem [PP2] A. Pretschner, J. Philipps: Szenarien modellbasierten Testens. TB TUM-I25, TU München, Inst. für Informatik, Juli 22 Modell-basiertes Testen Bereichsspezifische Definition (Automotive View) Notwendigkeit, die eingebettete Software und ihre Vorstufen (ausführbare Modelle) mit aufeinander abgestimmten Testverfahren zu prüfen um Fehler aufzudecken und Vertrauen in die korrekte Funktionsweise zu gewinnen Modell-basierter Test Entwicklungsbegleitender Testprozess im Rahmen der Modell-basierten Entwicklung, der eine Kombination unterschiedlicher, sich gut ergänzender Testverfahren umfasst und dabei ausführbare Modelle als reichhaltige Informationsquelle für den Test benutzt /Con4/ M. Conrad: Modell-basierter Test eingebetteter Software im Automobil - Auswahl und Beschreibung von Testszenarien. Dt. Universitätsverlag, Wiesbaden, 24 prozessorientierte Sichtweise Nutzung der im Entwicklungsprozess ohnehin vorhandenen ausführbaren Modelle für Testzwecke steht im Vordergrund allgemeiner als Definitionen, die die Existenz separater Modelle für den Test ('Testmodelle') fordern

5 Modell-basiertes Testen Modelle als Informationsquelle Mögliche Rollen ausführbarer Modelle im Testprozess: Modell als Testobjekt ('Modelltest, Model-in-the-Loop Test, MIL )* Modell als Testbasis für die Ermittlung der Testszenarien Modell als Testorakel Modell als Basis für strukturorientierte Überdeckung ( model coverage ) * MIL model test model-based test Besonderheit: größere Anzahl ausführbarer Artefakte zahlreiche Testmöglichkeiten Teststrategie Modell-basiertes Testen Begriffe: Testszenario, Testverfahren Testszenario (engl. test scenario) Allgemeine Beschreibung eines Prüffalles, die eine Menge von (konkreten) Testdaten oder Testdatenverläufen spezifiziert Testverfahren (engl. test design technique) Standardisierte Vorgehensweise für die Ermittlung von Testszenarien auf Basis bestimmter Informationsquellen (z.b. funktionale Spezifikation, ausführbares Modell, Programmcode)

6 Modell-basiertes Testen Testmöglichkeiten Modell-basierte Entwicklung bietet zahlreiche 'Testmöglichkeiten': Sstemverhaltensmodell Phsikalisches Modell Implementierungsmodell C-Code Host C-Code Target Steuergerät Fahrzeug Modultest Sstemtest + Kombinatorik nicht alle denkbaren Kombinationen können und sollen getestet werden sorgfältige Auswahl im Rahmen einer Teststrategie Modell-basierter Test Testmöglichkeiten (1): Testartefakte Sstemverhaltensmodell Phsikalisches Modell Model-in-the-Loop (MIL) Implementierungsmodell *.c *.h C-Code Host Software-in-the-Loop (SIL) *.c *.h C-Code Target Processor-in-the-Loop (PIL) Steuergerät Hardware-in-the-Loop (HIL)

7 Modell-basierter Test Testmöglichkeiten (2): Testphasen Modul-/Unittest Sstemtest Testmöglichkeiten (3): Funktions- vs. Strukturtests Modell-basierter Test Funktions- vs. Strukturtests Funktionstests (Black-box Tests) Nachweis, dass das Modell / die Software die Anforderungen erfüllt Testbasis: Anforderungsspezifikation Ziel der Testauswahl: Überdeckung aller Anforderungen requirements coverage Überdeckung der Wertebereiche von In und/oder Outputs (optional) range coverage Strukturtests (White-box Tests) Nachweis, dass alle Teile des Modells / der Software ausgeführt wurden Testbasis: Modell / C Code Ziel der Testauswahl: Überdeckung aller Modell- / Codeelemente model / code coverage' path A In 1 control In 2 path B Switch

8 Modell-basierter Test Back-to-Back Tests Back-to-back Tests Nachweis, dass sich zwei verschiedene Stadien der Modellevolution funktional gleichwertig verhalten (vergleichendes Testen zur Absicherung eines Entwicklungsschrittes) Stimulation zweier unterschiedler, ausführbarer Artefakte mit den selben Testszenarien und Vergleich der Sstemreaktionen auf hinreichende Ähnlichkeit Wiederverwendung bereits existierender Testszenarien, unabhängig davon, ob diese aus Black- oder White-box-Tests stammen *.c? =? = *.h Modell-basierter Test Möglichkeitsraum - Testartefakt x Testphase x { } *.c *.h *.c *.h Sstemverhaltensmodell Phsikalisches Implementierungsmodell Modell C-Code Host C-Code Target Steuergerät Funktions- Test Strukturtest Nicht alle Testmöglichkeiten können / sollen genutzt werden Teststrategie

9 Modell-basierter Test Möglichkeitsraum - Beispiele *.c *.h *.c *.h Sstemverhaltensmodell Phsikalisches Implementierungsmodell Modell C-Code Host C-Code Target Steuergerät Funktions- Test? = Strukturtest Modellstrukturtest auf Modulebene Back-to-back Test Modell C-Code Modell-basierter Test Wiederverwendung von Testszenarien *.c *.h Sstemverhaltensmodell Phsikalisches Modell Implementierungsmodell C-Code Target n.a. complete model subsstem 1 subsstem 2 subsstem 3 subsstem 3.1 complete model subsstem 1 subsstem 2 subsstem 3 complete code Modellevolution t

10 Modell-basierter Test Wiederverwendung von Testszenarien sstematisch exemplarisch Testszenario Testszenario = Testszenario Testszenario Testszenario Testszenario = = Testszenario Testszenario Modell Modell C Code Code Steuergerät Steuergerät Fahrzeug Fahrzeug *.c *.h Sstemreaktion Sstemreaktion? Sstemreaktion Sstemreaktion Sstemreaktion Sstemreaktion?? Sstemreaktion Sstemreaktion Modell-basierter Test Wiederverwendung von Testszenarien Arten der Wiederverwendung *.c *.h *.c *.h logische (Testszenarien) / technische (Testdaten, Testskripte) Wiederverwendung horizontale / vertikale Wiederverwendung über verschiedene Testebenen innerhalb einer Baureihe Funktions- Test Strukturtest Sstemverhaltensmodell Phsikalisches Implementierungsmodell C-Code Modell Host C-Code Target Wiederverwendung innerhalb einer Testebene über unterschiedliche Baureihen (z.b. E-Klasse, S-Klasse) Wiederverwendung innerhalb einer Testebene zwischen Vorgänger-Baureihe und aktueller BR (z.b. E-Klasse aktuell vs. E-Klasse Nachfolger) Wiederverwendung von Testinputs vs. Wiederverwendung von Testoutputs/Sollwerten Steuergerät Welche Art der Wiederverwendung ist wann/wo sinnvoll und möglich?

11 Modell-basiertes Testen Klassifikation von Testansätzen (1/2) Testbasis Evolutionsstufe Modellierungstechnik Textuelle Spezifilation Spezifikationsmodell Designmodell Implementierungsmodell Simulink Stateflow n.a. Berücksichtigung der internen Struktur black-box white-box Testauswahl Testauswahlkriterium Requirements Coverage Data Coverage Time Coverage Propert-based Fault-based Random / Stochastic ad-hoc Automatisierungsgrad manuell automatisch Modell-basiertes Testen Klassifikation von Testansätzen (2/2) Spezifikationsmodell Designmodell Testobjekt (SUT) Evolutionsstufe Implementierungsmodell Autocode (Host) Autocode (Target) Eingebettetes Sstem (ECU) Fahrzeug Testreferenz funktionale Spezifikation andere Evolutionsstufe (Back-to-back Test) andere Version (Regressionstest) Rückkopplung open-loop closed loop

12 Modell-basiertes Testen Testverfahren für Simulink/Stateflow-Modelle CTM EMB (1) I/O- Orientiertes Test Design MB 3 T (3) Prototpbas. Test für hbride reaktive Sst. Simulink Testbasis Testauswahl Modellierungstechnik Berücksichtigung der internen Struktur Simulink Stateflow n.a. black-box white-box Stateflow EST (2) TPT (4) Zufallstests Testgenerierung durch Modelchecking Constraintbasierte Testdatenanalse Modellbasierte Testfallextraktion Modellstruktur tests (1) Klassifikationsbaum-Methode für Eingebettete Ssteme (CTM EMB ) (2) Evolutionärer Sicherheitstest (EST) (3) Modell-basierter Black-box Test (MB 3 T) (4) Time Partition Testing (TPT) Verfahrensbeschreibungen und unterstützende Werkzeuge: [CF5] M. Conrad, I. Fe: Modell-basierter Test von Simulink/Stateflow-Modellen. Proc. Kolloqium Testen im Sstem- und Software-Life-Ccle, S , TAE Esslingen, Nov. 25 Modell-basiertes Testen Testverfahren für Simulink/Stateflow-Modelle CTM EMB (1) I/O- Orientiertes Test Design MB 3 T (3) Prototpbas. Test für hbride reaktive Sst. Simulink Testbasis Testauswahl Modellierungstechnik Berücksichtigung der internen Struktur Simulink Stateflow n.a. black-box white-box Stateflow EST (2) TPT (4) Zufallstests Testgenerierung durch Modelchecking Constraintbasierte Testdatenanalse Modellbasierte Testfallextraktion Modellstruktur tests (1) Klassifikationsbaum-Methode für Eingebettete Ssteme (CTM EMB ) (2) Evolutionärer Sicherheitstest (EST) (3) Modell-basierter Black-box Test (MB 3 T) (4) Time Partition Testing (TPT) Verfahrensbeschreibungen und unterstützende Werkzeuge: [CF5] M. Conrad, I. Fe: Modell-basierter Test von Simulink/Stateflow-Modellen. Proc. Kolloqium Testen im Sstem- und Software-Life-Ccle, S , TAE Esslingen, Nov

13 Verkehrsflussangepasste Geschwindigkeitsregelung (engl. Adaptive Cruise Control) Fahrzeugsubssteme/-domänen: Antriebsstrang Fahrwerk Karosserie Multi-Media Test Design Techniques for Simulink / Stateflow Models The Classification-Tree Method for Embedded Sstems CTM Emb sstematic approach for the selection of test scenarios and a notation for their appropriate description sstematic 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 reusabilit activities: test input partitioning test scenario determination test data refinement

14 Adaptive Cruise Control Phsical Model (Simulink/Stateflow) Tempomat mit Abstandsregelung Last Change: MCONRAD 1-Ma-23 21:36:32 6 d_rel d_rel v_ziel d_rel 4 v_ziel d_rel v_ziel v_rel v_rel <d_rel, v_rel, Ziel> v_fzg <v_fzg> Ziel Ziel Zielerkennung v_act DesiredTorques <T_des_Drive, T_des_Brake> 1 phi_acc FahrpedalWinkel PedalPositions PedalFlags <AccPedal, BrakePedal> 2 BremspedalWinkel PedalInterpretation DesiredTorques Stellgroessen FzgDaten Handbetrieb Preprocessing component FzgDaten TempomatFlag <TempomatFlag> Pedal interpretation (short: PedInt) ZielDaten v_soll 4 <u_soll> v_soll WunschMomente FahrerWarnung 7 <FaherWarnung> Fahrerwarnung PedalFlags Stellgroessen 3 LeverPos BedienhebelStellung BedienhebelStellung TempomatModus 8 <TempomatModus> Tempomatmodus 5 DistFactor Abstandsfaktor AbstandsFaktor d_soll <d_soll> 5 d_soll <T_Engine, T_Brake> TmA <i_ges, n_mot, a_fzg, v_fzg, Gang_i> 11 1 i_ges 2 n_mot M_Br_b 9 Demux 3 1 a_fzg M_Mot_b v_fzg 12 Fahrzeugmodell Gang_i Pedal Interpretation 1 v_act v_act <phi_acc> <phi_acc> <> 2 <phi_acc, > PedalPositions <phi_acc> 2 PedalPositions <ph <> T_1_Drive(v) T_7_Drive(v) > >= 7 AccPedal BrakePedal <phi_acc> The PedInt subsstem interprets the current, normalized positions of accelerator and brake pedal (phi_acc, ) [ ] 1/3 Furthermore, two flags (AccPedal, BrakePedal) are calculated which indicate whether or not the pedals are considered to be depressed. 1/7 T_max_Brake (boolean) (boolean) AccPedal BrakePedal 1/1 Mux f(u) T_des_Drive selection T_des_Brake <AccPedal, BrakePedal> T_des_Drive [Nm] (Wunschabtriebsmoment) T_Des_Brake [Nm] (Wunschbremsmoment) 1 <T_des_Drive, T_des_Brake> DesiredTorques 2 PedalFlags phi_acc PedInt AccPedal BrakePedal variable phi_acc AccPedal BrakePedal unit domain % [,1] % [,1] {,1} {,1} data tpe real real bool bool

15 CTM Emb Test Input Partitioning test object i 1 i 1.1 i 1.2 i 1.3 i 1.4 i 1.5 disjoint & complete partitioning into equivalence classes which are suitable abstractions of individual input values i 2 i 2.1 i 2.2 i 2.3 i 2.4 equivalence classes should behave homogeneousl w.r.t. the detection of potential errors (= heuristic procedure) i 2.5 Pedal Interpretation PedInt phi_acc ], [ ], 1[ 1 ID PI-1.1 Description Recognition of brake pedal activation If the brake pedal is depressed more than a threshold value, the BrakePedal flag should be set to the value 1, otherwise to. variable unit domain data tpe % [,1] real

16 Pedal Interpretation phi_acc ], [ ], 1[ 1 PedInt ], [ ], 1[ 1 classification-tree induced partitioning of input data space CTM Emb - Test Scenario Determination test object i 1 i 1.1 i 1.2 i 1.3 i 1.4 i 1.5 abstract description of the course of inputs over time based on the test input partitioning i 2 i 2.1 i 2.2 i 2.3 i 2.4 i 2.5 test step scenario: t = t : i 1 i 1.3 / i 2 i 2.1 t = t 1 : i 1 i 1.2 / i 2 i t = t end :i 1 i 1.1 / i 2 i

17 Pedal Interpretation phi_acc PedInt TScen 1 ], [ ],: 1[ 1 TStep 1.1 abstract test input description ], [ ], 1[ 1 combination table Time [s] TStep TStep time tags CTM Emb - Test Data Refinement test object i 2.1 i 1 i 1.1 i 1.2 i 1.3 i 1.4 i 1.5 refinement of abstract test input descriptions into signal waveforms b selecting specific numbers for each equivalence class i 2 i 2.2 i 2.3 i 2.4 i 2.5 test scenario: data: t i 1 = (t t) : = 5 i 1 / i 2 (t i 1.3 )=/ i 2 i 2.1 it 1 = (t 1 t) 1 : = 1 i 1 / i 2 i 1.2 (t 1 )= / i 2 1 i t i 1 = (t 5 t) end = :i 1 / i 2 i(t )=/ i1 2 i

18 Pedal Interpretation PedInt phi_acc TScen 1 ], [ ],: 1[ 1 ], [ ], 1[ 1 Time [s] TStep 1.1 ramp step TStep TStep 1.3 sine [%] 1 phi_acc [%] test data 5 Time [s] Time [s] Pedal Interpretation PedalPositions PedalInterpretation Inputs phi_gas Au La test sequence 1: Recognition of pedal activation b using special values which are held constant for a time t >> t. ],[ ],1[ 1 ],[ ],1[ 1 Time [s] Ti [ ] Test 1 / Test sequence v_act phi_acc.2.4 time [s]

19 1: Erkennung der Pedalbetätigung (1) -... Time [s] 1.1: 1.2:.1 1.3:.2 1.4:.3 1.5:.4 1.6:.5 2: Erkennung der Pedalbetätigung (2) -... Time [s] 2.1: 2.2: 1 2.3: 2 3: Test der Fahrpedalinterpretation Time [s] 3.1: 3.2: 2-delta_t 3.3: 2 3.4: 4-delta_t 3.5: 4 3.6: 6-delta_t 3.7: 6 3.8: 8-delta_t 3.9: 8 3.1: 1-delta_t ],[ ],1[ 1 PedalPositions PedalInterpretation Inputs phi_gas ],[ ],1[ 1 Author MCONRAD Last Changed :38 v_act -1 ]-1,[ ],7 [ 7 Pedal Interpretation PedalPositions ],[ ],1[ 1 PedalInterpretation Inputs phi_gas ],[ ],1[ 1 A L test sequence 2: Testing the hsteretic properties of the test object. Therefore, the pedal positions are ramped up and down covering the entire domain. 1 5 Test 1 / Test sequence 2. Time [s] 1 2 v_act phi_acc 1 time [s] 2 Pedal Interpretation Requirements Traceabilit requirements ID Beschreibung SR-PI-1 Erkennung der Pedalbetätigung Werden Fahr- oder Bremspedal über einen bestimmten Schwellwert hinaus betätigt, ist dies durch ein pedalspezifisches Binärsignal anzuzeigen. SR-PI-1.1 Erkennung der Bremspedalbetätigung Wird das Bremspedal über einen Schwellwert hinaus betätigt, ist das Binärsignal BrakePedal auf den Wert 1 zu setzen, andernfalls auf. SR-PI-1.2 Hsterese Bremspedalbetätigung Bei der Erkennung der Bremspedalbetätigung ist keine Hsterese vorzusehen. SR-PI-1.3 Erkennung der Fahrpedalbetätigung Wird das Fahrpedal über einen Schwellwert hinaus betätigt, ist das Binärsignal AccPedal auf den Wert 1 zu setzen, andernfalls auf. SR-PI-1.4 Hsterese Fahrpedalbetätigung Bei der Erkennung der Fahrpedalbetätigung ist keine Hsterese vorzusehen. ischeckedb? test scenarios SR-PI-2 Interpretation der Pedalwege Die normierten Pedalwege von Fahr- und Bremspedal sind als Wunschmomente zu interpretieren. Dabei sind sowohl Komfort- als auch Verbrauchsaspekte zu berücksichtigen. SR-PI-2.1 Interpretation des Bremspedalweges Der normierte Bremspedalweg ist als Wunschbremsmoment T_des_Brake [Nm] zu interpretieren. Das Wunschbremsmoment ergibt sich, indem der aktuelle Pedalweg zum maximalen Bremsmoment T_max_Brake ins Verhältnis gesetzt wird. SR-PI-2.2 Interpretation des Fahrpedalweges Der normierte Fahrpedalweg ist als Wunschabtriebsmoment T_des_Drive [Nm] zu interpretieren. Das Wunschabtriebsmoment ist dabei im nichtnegativen Bereich geschwindigkeitsabhängig so zu skalieren, dass bei höheren Geschwindigkeiten der Abtriebsmomentenwunsch kleiner wird.* SR-PI-1 SR-PI-1.1 SR-PI-1.2 SR-PI-1.3 SR-PI-1.4 SR-PI-2 SR-PI-2.1 SR-PI-2.2 Traceabilit Matrix Test 1 / Testseq. 1 () Test 1 / Testseq. 2 () () Test 1 / Testseq. 3 () Test 1 / Testseq. 1 Test 1 / Testseq. 2 Test 1 / Testseq

20 CTM Emb Summar test basis test design technique(s) test notation functional model _Fzg> v_fzg v_act Zielerkennung Ziel DesiredTorques Ziel <T_des_Dr data range oriented equivalence partitioning boundar value analsis testing special values test scenarios Acc PedalPositions PedalFlags <AccPedal, PedalPositions Brake el PedalInterpretation phi_gas ID erpos ng requirements Description requirements testing classification tree coverage state / transition testing control sstem testing error guessing Time [s] 1 2 ],[ ],1[ 1 ],[ ],1[ classification-tree 1 test sequences -1 ] SR-PI-1.2 Hsteretic behavior of brake pedal activation No hsteresis is to be expected during brake pedal activation recognition. Tool Support: MTest & CTE/ES MTest: dspace GmbH CTE/ES: Razorcat GmbH

21 Modell-basiertes Testen Testverfahren für Simulink/Stateflow-Modelle CTM EMB (1) I/O- Orientiertes Test Design MB 3 T (3) Prototpbas. Test für hbride reaktive Sst. Simulink Testbasis Testauswahl Modellierungstechnik Berücksichtigung der internen Struktur Simulink Stateflow n.a. black-box white-box Stateflow EST (2) TPT (4) Zufallstests Testgenerierung durch Modelchecking Constraintbasierte Testdatenanalse Modellbasierte Testfallextraktion Modellstruktur tests (1) Klassifikationsbaum-Methode für Eingebettete Ssteme (CTM EMB ) (2) Evolutionärer Sicherheitstest (EST) (3) Modell-basierter Black-box Test (MB 3 T) (4) Time Partition Testing (TPT) Test Design Techniques for Simulink / Stateflow Models Structural Model Testing Model Coverage Metrics Decision Coverage on Model Level (M_D1) Pathwas through a Switch Block and Test Goals path A In 1 test goal test input specification control In 2 M1 (path A) M2 (path B) control threshold control < threshold path B Switch Pass through In1 when control threshold; otherwise, pass through In

22 /* pictrl */ #def i ne " dst pes. h #def i ne G1 ( I nt 32) x void pictrl(uint16 r { Int16 e,s2,g_1,x1, UI nt 8 i ; e = (Int16)(ref >> G_1 = ( I nt 16) ( ( ( a> x1 = (e >> 4)+x1; G_2 = ( I nt 16) ( ( ( a> * u = G2 + G1; Test Design Techniques for Simulink / Stateflow Models Structural Model Testing PedalInterpretation 52,1% Coordination 95,4% CruiseControl 1,% VehicleData DistanceControl 92,4% TempomatContro 25,9% v_act [m/s] CruiseControl ActualSpeed Model Coverage Monitoring v_soll VehicleData v_des [m/s] Coordination 1 DesiredSpeed DesiredTorque_CC DesiredToruqe_CC v_soll v_des [ms] DesiredSpeed T_out_des_CC [Nm] v_act [m/s] % 1% DistanceControl ActualSpeed T_out_des_DC [Nm] DesiredTorque_DC ManipulatedVariables TargetData 2 Manipulated DesiredTorque_DC Variables 3 TargetData DesiredTorques_Drv TargetData % 1% ControlState PedalInterpretation ActualSpeed DesiredTorques_Drv BrakePedal TempomatContro ControlState BrakePedal % 1% 4 PedalPositions PedalFlags InitDesiredSpeed Pedal AccPedal AccPedal SetDesiredSpeed Positions 1 % 1% Lever Lever IncreaseDesiredSpeed DecreaseDesiredSpeed SetDesiredSpeed() InitDesiredSpeed() CruiseControl Lever % 1% ReduceDesiredSpeed() IncreaseDesiredSpeed() Data Store Modellbasierter Test Effektive Teststrategie für den Modell-basierten Test Testbasis Testverfahren Testdaten Testobjekt Classification-Tree Method for Embedded Sstems CTM Emb Anforderungen Model Coverage Monitoring Sstemreaktion Modell Sstematischer Funktionstest auf Modellebene (Black-box Test) Monitoring der Modellüberdeckung Strukturtest auf Modellebene (White-box Test) Back-to-back-Tests Modell Software ECU Modell C-Code Steuergerät?

23 Effektive Teststrategie für den Modell-basierten Test Empfehlungen Frühzeitiger Beginn des Black-box-Tests (d.h. auf Modellebene) zur Absicherung der Funktionalität Durchführung von Strukturtests als Ergänzung - nicht als Ersatz zur Absicherung der strukturellen Integrität Nutzung von vergleichenden Tests (Back-to-Back-Tests) zur Absicherung der Transformationsschritte (Sstemverhaltensmodell Phsikalisches Modell Implementierungsmodell C-Code Host C-Code Target Steuergerät) Erhöhung der Wiederverwendung von Modellkomponenten und damit der zugehörigen Tests Zusammenfassung Automotive Software Engineering Teil III: Modell-basiertes Testen Modell-basiertes Testen ist state-of-the-art bei der Qualitätssicherung Modell-basiert entwickelter Fahrzeugsofware Testaktivitäten werden in frühe Entwicklungsphasen vorverlagert, Lern- und Korrekturprozesse können frühzeitig beginnen entwicklungsbegleitender Testprozess in der Modell-basierten Entwicklung, zahlreiche Testmöglichkeiten Nutzung von Simulink/Stateflow-Modellen als reichhaltige Informationsquelle für den Test Kombination verschiedener, sich gegenseitig ergänzender Testverfahren: effektive Teststrategie für den Modell-basierten Test Testverfahren für Simulink/Stateflow-Modelle Klassifikationsbaum-Methode für eingebettete Ssteme CTM EMB Modellstrukturtests

24 Automotive Software Engineering Teil III: Modell-basiertes Testen M. Conrad: Modell-basierter Test eingebetteter Software im Automobil - Auswahl und Beschreibung von Testszenarien. Deutscher Universitätsverlag, Wiesbaden, Okt. 24 M. Conrad: A Sstematic Approach to Testing Automotive Control Software. Proc. Convergence 24, Detroit, Okt. 24 (SAE technical paper # ) K. Lamberg, M. Beine, M. Eschmann, R. Otterbach, M. Conrad, I. Fe: Model-based testing of embedded automotive software using MTest. Proc. SAE World Congress 24, Detroit, März 24 (SAE technical paper # ) M. Conrad, I. Fe, S. Sadeghipour: Sstematic Model-Based Testing of Embedded Control Software: The MB 3 T Approach. Proc. ICSE 24 Workshop on Software Engineering for Automotive Sstems (SEAS4), Edinburgh, Mai 24 > Papers