Hybrides Testverfahren für Simulink/TargetLink-Modelle · deren Test, ist eine größtmögliche...

Hybrides Testverfahren fürSimulink/TargetLink-Modelle

vorgelegt vonDipl.-Inf.

Benjamin Wilmesaus Berlin

von der Fakultät IV – Elektrotechnik und Informatikder Technischen Universität Berlin

zur Erlangung des akademischen Grades

Doktor der Ingenieurwissenschaften— Dr.-Ing. —

genehmigte Dissertation

Promotionsausschuss

Prof. Dr. Uwe Nestmann (Vorsitzender)Prof. Dr. Stefan Jähnichen (Berichter)Prof. Dr. Andreas Spillner (Berichter)

Prof. Dr. Steffen Helke (Berichter)

Tag der wissenschaftlichen Aussprache:

19.11.2014

Berlin 2015

D 83

Technische Universität BerlinFakultät IV – Elektrotechnik und InformatikInstitut für Softwaretechnik und Theoretische InformatikFachgebiet SoftwaretechnikErnst-Reuter-Platz 7

D-10587 Berlin

Hochschule BremenFakultät Elektrotechnik und InformatikZentrum für Informatik und MedientechnologienFlughafenallee 10

D-28199 Bremen

Brandenburgische Technische Universität Cottbus-SenftenbergJuniorprofessur Sichere SoftwaresystemePostfach 10 13 44

D-03013 Cottbus

Benjamin Wilmes: Hybrides Testverfahren für Simulink/TargetLink-Modelle© März 2015

V E R Ö F F E N T L I C H U N G E N

Die in dieser Dissertation vorgestellte Arbeit entstand von 2010 bis 2014an der Technischen Universität Berlin (Daimler Center for AutomotiveInformation Technology Innovations). Ein Teil der Ideen und Darstel-lungen dieser Arbeit sind bereits in den im Folgenden aufgelistetenVeröffentlichungen erschienen:

konferenzbeiträge

• B.Wilmes: Automated Structural Testing of Simulink/TargetLink Mo-dels via Search-Based Testing assisted by Prior-Search Static Analysis,4th International Conference on Advances in System Testing andValidation Lifecycle (VALID), November 2012, Lissabon, Portugal,ISBN 978-1-61208-233-2

• B.Wilmes: Toward a Tool for Search-Based Testing of Simulink/Target-Link Models, 4th Symposium on Search Based Software Engineering(SSBSE), Fast Abstracts, Fondazione Bruno Kessler, September 2012,Riva del Garda, Italien, ISBN 978-88-905389-9-5

• B.Wilmes, F. Lindlar, A. Windisch: Suchbasierter Test für den indus-triellen Einsatz, 4. Symposium Testen im System- und SoftwareLife-Cycle, Technische Akademie Esslingen, November 2011, Ost-fildern, Deutschland, ISBN 3-92-4813-92-2

journalbeiträge

• B. Wilmes: Static Preprocessing for Automated Structural Testing ofSimulink Models, International Journal On Advances in Systemsand Measurements, IARIA, Ausgabe 6, Nummer 3&4 2013, Seiten310-323, Dezember 2013, ISSN 1942-261x

iii

K U R Z FA S S U N G

Die modellbasierte Entwicklung der Software eingebetteter Systeme hatsich in vielen Industriezweigen durchgesetzt, allen voran in der Auto-mobilindustrie. Die Programmierung von Softwarecode erfolgt hierbeiauf grafischem Wege, meist durch spezielle Datenflussmodelle, wie siedas weit verbreitete Werkzeug Matlab/Simulink bereitstellt. Der Codewird aus diesen Modellen in der Regel automatisiert abgeleitet, häufigunter Nutzung der Simulink-Erweiterung TargetLink. Derlei Modelle be-sitzen als maschinell ausführbarer Ursprung der Softwarefunktionalitäteine hohe Relevanz für die ohnehin im Automobilbereich sehr bedeut-same Qualitätssicherung. In Anbetracht des zunehmenden Anteils vonSoftware in Fahrzeugen, einhergehend mit steigenden Aufwänden fürderen Test, ist eine größtmögliche Testautomatisierung wünschenswert.Der suchbasierte Test hat sich als ein geeignetes, bezüglich seiner Effizi-enz allerdings noch verbesserungswürdiges Automatisierungsverfahrenerwiesen. Er eignet sich unter anderem, um Eingaben (Testdaten) zurstrukturellen Überdeckung eines Modells, welches unter Verwendungvon Matlab/Simulink und TargetLink entwickelt wurde, zu finden.

Diese Arbeit verfolgt das Ziel, die Effizienz des suchbasierten Tests inAnwendung für solche Modelle zu steigern. Hierzu kombiniert sie densuchbasierten Test mit unterstützenden Techniken. Das entstehende hy-bride Testverfahren enthält zum einen drei speziell entwickelte statischeAnalysetechniken, welche der Vorbereitung eines suchbasierten Testsdienen. So wird ermittelt, ob das Finden gewünschter Testdaten über-haupt möglich ist, ob es Testdaten gibt, die vorab von einer Betrachtungausgeschlossen werden können, und in welcher Reihenfolge für die ein-zelnen (strukturorientierten) Ziele geeignete Testdaten zu suchen sind.Zum anderen wird der suchbasierte Test um eine in geeigneten Fällenstattfindende Testdatengenerierung mittels symbolischer Ausführungund SMT-Solving ergänzt. Darüber hinaus wird ein alternativer Suchal-gorithmus vorgestellt, welcher den Raum aller möglichen Testdaten imVergleich zum sonst verwendeten genetischen Algorithmus nicht global,sondern lokal untersucht.

Fallstudien untersuchen die Auswirkungen dieser Beiträge anhand zwei-er realer Modelle aus der Automobilindustrie. Die Ergebnisse dieserStudien zeigen, dass die realisierte Hybridisierung des suchbasiertenTests im betrachteten Kontext zu einer deutlichen Effizienzsteigerungführt – die Laufzeiten der Testdatengenerierungsvorgänge fielen um über90% geringer aus, ohne dass bezüglich der Qualität der Ergebnisse, wiedem Überdeckungsgrad, Einbußen hingenommen werden mussten.

iv

A B S T R A C T

Model-based development of embedded systems software has become awell-established practice in many industry branches, especially the auto-motive industry. Such an approach involves programming via graphicalmeans, most often through the use of specialized data-flow models, suchas those provided by the widely-used tool Matlab/Simulink. Normally,the software code is automatically generated from these models, oftenthrough the use of the Simulink extension TargetLink. Simulink modelsare usually the first executable artifacts in the development process. Tes-ting these models is therefore particularly relevant to the aspect of theautomotive industry dealing with quality assurance. Considering theever-expanding role of software in modern automobiles, going hand inhand with the rising testing costs, the automation of testing activities ishighly desirable. One promising technique which has shown its capa-bilities in automating software testing is search-based testing. Amongother applications, it can be utilized to generate input data (test data) forstructural coverage of a Simulink model.

The aim of this work is to raise the efficiency of search-based test data ge-neration when applied to such models. To achieve this goal, search-basedtesting is combined with supportive techniques. The resulting hybrid testprocedure contains three specially designed static analysis techniqueswhich enhance the setup of search-based testing. These techniques deter-mine (1) whether it is even possible to find desired test data, (2) if there istest data present that can be exempted from the search in advance, and (3)in what order the individual (structure-oriented) goals should be aimedat by the search. In addition, for certain goals, the hybrid test procedureis generating test data by symbolic execution and SMT-Solving, in placeof a search. Furthermore, an alternative search algorithm is presented,which, unlike the elsewise used genetic algorithm, explores the test dataspace locally, rather than globally.

Case studies investigate the effect of these additional techniques on thebasis of two real models from the automotive industry. The results ofthese studies show, that the provided and implemented hybridization ofsearch-based testing results in a clear rise in efficiency. The run times oftest data generation operations is over 90% shorter, yet the quality of theresults, such as the structural coverage, are not compromised.

v

DA N K S A G U N G

Als Autor der vorliegenden Arbeit möchte ich mich an dieser Stellebei den Personen bedanken, die mich bei der Erarbeitung dieser Arbeitunterstützt und zu ihrem Gelingen beigetragen haben.

Mein ausdrücklicher Dank gilt der Daimler AG und Prof. Dr. Stefan Jähni-chen von der Technischen Universität Berlin, ohne die eine Durchführungdieser Arbeit nicht möglich gewesen wäre. Insbesondere möchte ich DirkJohanson, Christian Scheidler und Michael Weber von der Daimler AGfür die jahrelange Unterstützung meines Vorhabens danken. Herzlichdanke ich auch Prof. Dr. Andreas Spillner und Prof. Dr. Steffen Helkefür die Begutachtung dieser Arbeit. Darüber hinaus gilt mein Dank Dr.Andreas Windisch, dessen Dissertation den Ausgangspunkt dieser Arbeitdarstellte.

Mein freundschaftlicher Dank gilt den Kollegen meiner Zeit am DCAITI,namentlich Thomas Noack, Dr. Felix Lindlar, Quang Minh Tran, KerstinHartig und Dr. Thomas Karbe. Die vielen interessanten und kreativenDiskussionen, die ich mit Euch hatte, wie auch Hilfestellungen undHinweise von Euch, haben maßgeblich zum Fortschreiten und Erfolgdieser Arbeit beigetragen. Dr. Thomas Karbe gebührt hierbei für seineausgiebige Durchsicht der schriftlichen Ausarbeitung mein besondererDank. Auch den weiteren Mitarbeitern des Fachgebiets Softwaretechnikvon Prof. Jähnichen bin ich für den gemeinsamen Austausch und diehilfreichen Anmerkungen bei gemeinsamen Klausurtagungen dankbar.

Von ganzem Herzen danke ich, nicht zuletzt, meiner Frau Tanya Wilmes,die mich stets unterstützt und mir den nötigen Rückhalt gegeben hat.Unseren beiden kleinen Söhnen Oscar und Elias, die das Laufen lernten,indem sie sich an dem Bürostuhl hochzogen, wenn ihr Vater auch an denWochenenden an dieser Arbeit schrieb, sei gesagt: Papa hat nun endlichwieder etwas mehr Zeit.

Benjamin WilmesBerlin, März 2015

vi

INHALTSVERZE ICHN IS

i grundlagen 11 einführung 32 hintergrund 11

2.1 Modelltest . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.1.1 Modellbasierte Entwicklung . . . . . . . . . . . . 122.1.2 Simulink und TargetLink . . . . . . . . . . . . . . 142.1.3 Testgrundlagen . . . . . . . . . . . . . . . . . . . . 28

2.2 Szenarien automatisierter Testdatengenerierung . . . . . 302.2.1 Strukturtest . . . . . . . . . . . . . . . . . . . . . . 312.2.2 Funktionstest . . . . . . . . . . . . . . . . . . . . . 372.2.3 Entwicklungsbegleitender Test . . . . . . . . . . . 392.2.4 Back-to-Back-Test . . . . . . . . . . . . . . . . . . . 39

2.3 Automatisierungsansätze . . . . . . . . . . . . . . . . . . . 402.3.1 Statische Testdatengenerierung . . . . . . . . . . . 402.3.2 Dynamische Testdatengenerierung . . . . . . . . . 452.3.3 Hybride Testdatengenerierung . . . . . . . . . . . 482.3.4 Kommerzielle Werkzeuge . . . . . . . . . . . . . . 51

2.4 Suchbasierter Ansatz . . . . . . . . . . . . . . . . . . . . . 522.4.1 Lokale und globale Suche . . . . . . . . . . . . . . 522.4.2 Anwendung für Simulink/TargetLink-Modelle . 56

2.5 Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . 62

ii hybrides verfahren zur testdatengenerierung 673 statische voranalysen 69

3.1 Überdeckungsziel-Erreichbarkeitsprüfung . . . . . . . . . 693.1.1 Ziel . . . . . . . . . . . . . . . . . . . . . . . . . . . 703.1.2 Abstrakte Intervall-Interpretation . . . . . . . . . 713.1.3 Modelltransformationen . . . . . . . . . . . . . . . 863.1.4 Erreichbarkeitsanalyse . . . . . . . . . . . . . . . . 883.1.5 Verwandte Arbeiten . . . . . . . . . . . . . . . . . 93

3.2 Modelleingang-Abhängigkeitsermittlung . . . . . . . . . . 963.2.1 Ziel . . . . . . . . . . . . . . . . . . . . . . . . . . . 963.2.2 Technik . . . . . . . . . . . . . . . . . . . . . . . . . 973.2.3 Verwandte Arbeiten . . . . . . . . . . . . . . . . . 105

3.3 Suchzielpriorisierung . . . . . . . . . . . . . . . . . . . . . 1073.3.1 Ziel . . . . . . . . . . . . . . . . . . . . . . . . . . . 1073.3.2 Überdeckungszielanalyse . . . . . . . . . . . . . . 1103.3.3 Abarbeitungsreihenfolgenbildung . . . . . . . . . 1293.3.4 Verwandte Arbeiten . . . . . . . . . . . . . . . . . 136

3.4 Kombination der Techniken . . . . . . . . . . . . . . . . . 138

vii

viii inhaltsverzeichnis

4 generierungsverfahren 1414.1 Generierung mittels lokaler Suche . . . . . . . . . . . . . . 141

4.1.1 Ziel . . . . . . . . . . . . . . . . . . . . . . . . . . . 1424.1.2 Nachbarschaftsdefinition für Signale . . . . . . . 1434.1.3 Alternierende Signalparameteroptimierung . . . 1524.1.4 Verwandte Arbeiten . . . . . . . . . . . . . . . . . 159

4.2 Generierung mittels SMT-Solving . . . . . . . . . . . . . . 1614.2.1 Ziel . . . . . . . . . . . . . . . . . . . . . . . . . . . 1614.2.2 Satisfiability Modulo Theories . . . . . . . . . . . 1624.2.3 Einsatzkriterien . . . . . . . . . . . . . . . . . . . . 1644.2.4 Definition des Testdatengenerierungsproblems . 1664.2.5 Signalgenerierung . . . . . . . . . . . . . . . . . . 1714.2.6 Kombination von Suche und SMT-Solving . . . . 1734.2.7 Verwandte Arbeiten . . . . . . . . . . . . . . . . . 176

iii realisierung und evaluierung 1775 testwerkzeug-prototyp 179

5.1 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . 1795.2 Nutzersicht und Funktionsweise . . . . . . . . . . . . . . . 1835.3 Technische und praktische Herausforderungen . . . . . . 188

6 fallstudien 1896.1 Versuchsaufbau . . . . . . . . . . . . . . . . . . . . . . . . 189

6.1.1 Testobjekte/Modelle . . . . . . . . . . . . . . . . . 1896.1.2 Thesen . . . . . . . . . . . . . . . . . . . . . . . . . 1916.1.3 Konfigurationen . . . . . . . . . . . . . . . . . . . 1936.1.4 Kriterien . . . . . . . . . . . . . . . . . . . . . . . . 1946.1.5 Einstellungen und Randbedingungen . . . . . . . 197

6.2 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . 1996.2.1 Messdaten . . . . . . . . . . . . . . . . . . . . . . . 1996.2.2 Analyse der statischen Voranalysen . . . . . . . . 2096.2.3 Analyse des SMT-Solver-Einsatzes . . . . . . . . . 2156.2.4 Analyse des lokalen Suchverfahrens . . . . . . . . 216

6.3 Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . 2177 zusammenfassung und ausblick 221

7.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . 2217.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

literaturverzeichnis 229abbildungsverzeichnis 244tabellenverzeichnis 245abkürzungsverzeichnis 246

Teil I

G R U N D L A G E N

1 E I N F Ü H R U N G

Die Begriffe Optimierung, Automatisierung und Effizienz haben denmenschlichen Fortschritt seit seinen Anfängen bis zum heutigen Tagedominiert und geprägt. Angefangen mit einfachen Werkzeugen, überProduktionssysteme, bis hin zu Prozessgestaltungen und wirtschaftlichenBestrebungen: Aus dem Leben einer fortschrittlichen Gesellschaft undaus der industriellen, betrieblichen Welt sind diese drei Begriffe nichtmehr wegzudenken. Dies gilt gleichermaßen für Wissenschaft sowieForschung und erst recht für Informatik und Softwaretechnik.

Es lassen sich eine Vielzahl an Definitionen und Bedeutungen für die-se Begriffe finden. Etliche Bereiche und Disziplinen, wie im Falle derOptimierung beispielsweise die Mathematik oder im Falle der Effizienzder Wirtschaftsbereich, haben sie für sich vereinnahmt. Und doch bleibtunabhängig von ihrer Verwendung stets festzustellen: Optimierung, Au-tomatisierung und Effizienz stehen einander sehr nahe und bedingeneinander häufig. Beispielsweise sorgt eine Automatisierung im Idealfallfür erhöhte Effizienz. Andererseits sollte eine Automatisierung selbstausreichend effizient sein, um ihren Einsatz zu rechtfertigen. Eine Auto-matisierung kann im eingesetzten Kontext eine Optimierung darstellen.Optimierungen können aber auch Teil einer Automatisierung sein.

Die vorliegende Arbeit hat sich diesen drei Begriffen ganz besondersverschrieben. Sie behandelt eine Automatisierung im Bereich des Softwa-retests: ein automatisches Finden geeigneter Testfälle. Die Automatisie-rung entsteht dabei durch Techniken zur Optimierung: Testfälle werdenhinsichtlich ihrer Eignung optimiert. Und das Hauptziel der vorliegen-den Arbeit ist die Steigerung der Effizienz dieser Automatisierung. Diefolgenden Seiten werden Klarheit in diese abstrakte Umschreibung brin-gen. Hierbei spielt auch der Begriff der Hybridisierung eine zentraleRolle. Auch für diesen Begriff lassen sich eine Vielzahl an Definitionenfinden, beispielsweise in der Kraftfahrzeugtechnik. Dort bezeichnet derBegriff das Zusammenspiel verschiedenartiger Antriebseinheiten, wieVerbrennungsmotor oder Elektromotor, und Energiespeichersysteme –mit dem Ziel, die Effizienz hinsichtlich Kraftstoffverbrauch und Leistungzu optimieren.

3

4 einführung

qualität der software eingebetteter systeme

Nun ist diese Arbeit zwar auch im automobilen Umfeld entstanden, aller-dings adressiert sie ein anderes Themengebiet. Dieses ist aus Kundensichtzwar weniger greifbar, aber für die Automobilindustrie von hoher Re-levanz. Es geht um die Qualität von Software, welche für eingebetteteSysteme entwickelt wird, und deren Absicherung. Eingebettete Systemesind speziell auf ihren Anwendungsfall zugeschnittene Computer, wel-che üblicherweise zur Erfüllung ihrer Funktion eine Software betreiben.Derartige Systeme steuern heutzutage vielfältige Geräte, Maschinen undAnlagen [110]. Seit vielen Jahren sind eingebettete Systeme, in Form vonsogenannten Steuergeräten, auch ein integraler Bestandteil modernerFahrzeuge – sei es zu Zwecken einer effizienten Motorsteuerung, demAuf- und Zuschließen des Fahrzeugs per Knopfdruck, dem Auslöseneines Airbags oder, betrachtet man aktuelle Entwicklungen, selbststän-dig (autonom) fahrenden Fahrzeugen. Die Anforderungen an Sicherheit,Zuverlässigkeit und Haltbarkeit sind in diesem Bereich in der Regel sehrhoch [106], denn Nachlässigkeiten in der Entwicklung haben mitunterdrastische Folgen. Der Automobilhersteller Toyota sah sich zum Beispieljüngst mit den Konsequenzen eines fehlerhaften Motorsteuergeräts kon-frontiert. Eine Person starb, weil das Fahrzeug unkontrolliert beschleu-nigte. Eine Reihe von Untersuchungen machte Unzulänglichkeiten in derSoftware der Motorsteuerung sowie Verstöße gegen branchenübliche Ent-wicklungsrichtlinien aus [12]. Die Qualitätssicherung erfährt also, auchangesichts der steigenden Zahl softwarebasierter Fahrzeugfunktionen,einen erhöhten Stellenwert.

modellbasierte entwicklung und test

Der Test ist dabei die in der Praxis am intensivsten genutzte Maßnahmezur Qualitätssicherung. Das Vorgehen bei der Entwicklung orientiertsich üblicherweise am V-Modell. Dieses zeichnet sich unter anderemdadurch aus, dass das Produkt in seiner Planung graduell in kleinereEinheiten zerlegt wird, diese Einheiten entwickelt und anschließendintegriert werden, um so das finale Produkt zu bilden. Wird beispiels-weise ein System für ein Fahrzeug entwickelt, so wird dieses eventuellauf mehrere Steuergeräte verteilt. Die Software wiederum wird übli-cherweise in mehrere Bausteine (Module) aufgeteilt, wie Klassen oderFunktionen. Die Testaktivitäten orientieren sich an den bei den jeweiligenEntwicklungs- und Integrationsstufen entstehenden System- und Softwa-reartefakten. Wird modellbasiert entwickelt, so bedeutet dies, dass vorallem die Funktionsmodelle, der hieraus automatisch generierte Software-code, der integrierte Softwarecode, das Steuergerät mit der eingebettetenSoftware, die integrierten Steuergeräte sowie das Gesamtsystem zu Test-zwecken herangezogen werden. Mithilfe systematischer Testverfahrenwerden derlei Testobjekte überprüft und abgesichert. Die Entwicklung

einführung 5

der Funktionsmodelle, welche wie auch der resultierende Code Software-Module repräsentieren, erfolgt in der Automobilindustrie in der Regelmit dem Editor Simulink (SL) [114], der Teil des Werkzeugs Matlab (ML)[113] von The Mathworks ist. Zur Codegenerierung wird häufig dasauf SL aufsetzende TargetLink (TL) [36] von dSpace eingesetzt. TL stelltgewisse Anforderungen an ein SL-Modell. Ist im Folgenden also vonSL/TL-Modellen, oder manchmal auch einfach nur von Modellen, dieRede, so sind damit TL-konforme SL-Funktionsmodelle gemeint. Einemodellbasierte Entwicklung mit SL findet nicht nur in der Automobilin-dustrie, sondern auch in anderen Industriezweigen statt, beispielsweisebei der Entwicklung von Satelliten [112].

Erfolgt die Entwicklung wie zuvor beschrieben, so sind SL/TL-Modellein der Regel die ersten entstandenen Entwicklungsartefakte, welche ma-schinell ausführbar oder simulierbar sind. Daher kommt ihnen bei derAbsicherung in der Theorie zwar ein hoher Stellenwert zu – allerdingswird dieser Tatsache in der Testpraxis erfahrungsgemäß leider nichtimmer Rechnung getragen. In einer historisch stark vom Maschinen-bau dominierten Domäne liegt der Fokus auch heute noch oftmals zusehr auf dem Test von Entwicklungsartefakten mit einem höheren Ab-straktionsgrad. Dies bedeutet, der Test der Gesamt-Software oder desresultierenden Systems, insbesondere der Steuergeräte, erfolgt häufiggründlicher als der Test der SL/TL-Modelle (Modelltest). Ein hoher Zeit-oder Innovationsdruck in der Entwicklung verstärkt diese Priorisierung.Eine Vernachlässigung solcher Tests birgt jedoch das Risiko, dass be-stimmte Fehler erst spät im Entwicklungsprozess gefunden werden undin Folge mit höherem Aufwand und Kosten behoben werden müssen.Zudem könnten manche Fehler auf späteren Integrationsstufen schwererauffindbar sein.

automatisierte testdatengenerierung

Grundsätzlich ist man in der Entwicklung automobiler Softwaresystemeum eine Automatisierung der auszuführenden Testaktivitäten bemüht.Dies gilt insbesondere für die für gewöhnlich aufwändigste Testaktivität:die Wahl geeigneter Testfälle, beziehungsweise der Testobjekt-Eingaben(Testdaten). Nun ist eine Automatisierung dieser Aktivität beim Modell-test einerseits sehr attraktiv, da das Modell – wie erwähnt – das ersteausführbare Entwicklungsartefakt ist und viele Fehler bereits direkt anihrer Quelle beseitigt werden können – und andererseits, weil beim Mo-delltest ein Blick in das Innere des Testobjekts möglich ist. Dies ist beimTest eines Steuergeräts beispielsweise nicht der Fall.

Automatisierte Testdatengenerierung ist ein Forschungsthema, welcheseine Vielzahl an Ansätzen und Techniken hervorgebracht hat. Mit dersymbolischen Ausführung [72], dem Zufallstest [99], dem suchbasierten Test[83], dem Concolic Testing [49, 109] und Model-Checking-Techniken [41]

6 einführung

seien an dieser Stelle nur die Grundtechniken der Arbeiten genannt. Vor-nehmlich wurden die Ansätze allerdings für den Test von Programmcodeentwickelt. Wie sich in dieser Arbeit zeigen wird, bringt die Testdaten-generierung für SL/TL-Modelle aus dem Automobilbereich zusätzlicheHerausforderungen mit sich. Der suchbasierte Test, welcher metaheuris-tische Such- und Optimierungsalgorithmen zur Testdatenfindung instru-mentiert, hat sich in vorherigen Arbeiten als ein geeignetes Verfahrenzur Testdatengenerierung für SL/TL-Modelle erwiesen. Die vorliegendeArbeit baut daher auf entsprechenden Vorarbeiten auf, insbesondere aufder Dissertation von Windisch [132].

Der suchbasierte Test eignet sich unter anderem, um Testdaten zur Über-deckung der inneren Struktur eines Testobjekts zu finden. Der BegriffÜberdeckung bezeichnet hierbei das Erreichen bestimmter Zuständeinnerhalb des Testobjekts, beziehungsweise von strukturellen Elemen-ten wie Programmanweisungen oder -verzweigungen, während dessenAusführung. Diese Art von Tests wird auch als White-Box-Test oderStrukturtest bezeichnet. Eine weitere Anwendungsmöglichkeit liegt imBereich des Funktionstests, bei welchem die Einhaltung der Spezifikation,auf deren Grundlage die Entwicklung erfolgt ist, durch das Testobjektgeprüft wird. Erste Arbeiten zum suchbasierten Test wurden bereits inden 1970er Jahren veröffentlicht. Obwohl der Ansatz seit Beginn der1990er Jahre mit steigenden Veröffentlichungszahlen einen enormen Auf-schwung erlebt hat, führt er sein Dasein nach wie vor hauptsächlich inder Forschungswelt. Dafür gibt es folgende Gründe: Erprobungen mitindustriellen Fallbeispielen bestätigten zwar häufig die Fähigkeit dessuchbasierten Tests, ein äußerst generisch einsetzbares Automatisierungs-verfahren zu sein. Allerdings stehen den guten Ergebnissen teils hoheLaufzeiten in der Durchführung gegenüber. Diese Schwäche stellt, so lässtsich zumindest im Falle des suchbasierten Tests von SL/TL-Modellenurteilen, das wichtigste Hindernis für den Einsatz des Verfahrens in derPraxiswelt dar. Die vorliegende Arbeit hat sich zum Ziel gesetzt, diesesHindernis zu überwinden.

fokus

Aufgrund der Relevanz von SL/TL-Modellen in der Automobilindustriefokussiert sich die Arbeit in der Anwendung der Automatisierungs-methoden auf diese. Es ist allerdings zu betonen, dass SL/TL-Modelleletzten Endes nur als Vertreter einer ganzen Klasse von Modelltypen her-angezogen werden: Datenflussdiagramme, welche dynamische Systemebeschreiben. Dynamische Systeme berücksichtigen in ihrer Funktion denFaktor Zeit. Auch wenn die vorgestellten Lösungen im Detail an Spezifikavon SL/TL angepasst sind, so sind das grundlegende Konzept und dieentstandenen Techniken auf verwandte Modelltypen übertragbar.

einführung 7

Wie zuvor angedeutet, gibt es mehrere Arten von Tests. Der Strukturtestist dabei nur eine Testart, bei der sich eine automatisierte Testdatengene-rierung anbietet oder diese vorstellbar ist. Eine Betrachtung der in Fragekommenden Testarten, beziehungsweise der Szenarien einer automatisier-ter Testdatengenerierung – namentlich der Strukturtest, der Funktionstest,der Back-to-Back-Test und der entwicklungsbegleitende Test – ist Teildieser Arbeit. Diese Betrachtung kommt zu dem Schluss, dass die Ge-staltung eines Verfahrens zur automatisierten Testdatengenerierung, imFalle eines Funktionstests allerdings nur zum Teil, unabhängig von derbetrachteten Testart ist. In jedem der betrachteten Anwendungsszenariengilt es, Testdaten zu finden, welche bei Ausführung des Modells dasErreichen bestimmter Zustände im Modell bewirken. Die Arbeit setztdaher den Fokus auf den Strukturtest und betrachtet ihn als Repräsentantfür die anderen möglichen Testarten.

herausforderung

Eine effiziente Testdatengenerierung für SL/TL-Modelle ist aus mehrerenGründen besonders herausfordernd. Der Umstand, dass solche Modelledynamische Systeme beschreiben, erhöht ihren Zustandsraum ungemein.Um alle Zustände erreichen zu können, müssen Testdaten aus Signalen,also Sequenzen von Werten, bestehen. Dies führt zu einer sehr großenMenge möglicher Testdaten, aus der es die Richtigen auszuwählen gilt.Automatisch generierte Testdaten müssen zudem plausibel sein, dasheißt bezüglich der Funktionalität des Testobjekts realitätsnahe Szenarienbeschreiben. Entsprechende Randbedingungen gilt es zu berücksichtigen.Hinzu kommt, dass SL/TL-Modelle aus der industriellen Praxis häufigsehr umfangreich sind. Um Testdaten ermitteln zu können, muss alsoeine entsprechend mächtige Funktionalität untersucht werden.

idee

Zur Steigerung der Effizienz einer automatisierten Testdatengenerie-rung setzt diese Arbeit auf eine Hybridisierung verschiedener Techniken.Insbesondere geht es um die Kombination statischer und dynamischerTechniken. Im Bereich der Programmanalyse und des Softwaretests wirdeine Technik als dynamisch bezeichnet, wenn das Programm oder dasTestobjekt durch sie zur Ausführung kommt [38]. Andernfalls ist voneiner statischen Technik die Rede. Hierzu jeweils ein Beispiel: Der such-basierte Test ist in der in dieser Arbeit betrachteten Anwendung einedynamische Technik, da das Modell mit den generierten Testdaten aus-geführt wird. Bei einer symbolischen Ausführung oder einer statischenAnalyse hingegen handelt es sich, wie die Namen der Techniken bereitspreisgeben, um statische Techniken.

8 einführung

Die Idee besteht nun darin, statische und dynamische Techniken gegen-seitig von den Stärken des Anderen profitieren zu lassen und hierdurchindividuelle Schwächen oder Restriktionen auszumerzen. So müssenstatische Verfahren oftmals Abstriche in der Genauigkeit ihrer Ergebnissemachen, da Abstraktionstechniken notwendig sind, um überhaupt mitumfangreichen Problemstellungen umgehen zu können. DynamischeVerfahren hingegen arbeiten in der Regel zwar präzise, liefern aber kei-ne verallgemeinernden Ergebnisse. Ein für die Effizienz einer Lösungwichtiges Kriterium besteht zudem in der Geschwindigkeit, mit der sta-tische und dynamische Techniken ihre Aufgaben erledigen. Statischeund dynamische Techniken unterscheiden sich diesbezüglich häufig inAbhängigkeit von der Komplexität des zu lösenden Problems. Währendstatische Techniken kleine, wenig komplizierte Problemstellungen meistschneller bearbeiten, lohnt sich der Einsatz dynamischer Techniken oft-mals genau dann, wenn statische Techniken an Komplexitätsgrenzenstoßen.

arbeitsthese und beiträge

Aus dieser Motivation heraus stellt sich diese Arbeit folgender These:

These. Die Effizienz des Ansatzes von Windisch zur suchbasierten Testdatenge-nerierung für SL-Modelle lässt sich durch eine Hybridisierung derselben mitgeeigneten statischen oder dynamischen Techniken deutlich erhöhen.

Um diese These zu belegen, identifiziert die Arbeit technische Problemedieses suchbasierten Ansatzes, deren Lösung oder Abschwächung einPotenzial zur Effizienzsteigerung bergen. So hängt der notwendige Auf-wand für eine automatische Testdatensuche beispielsweise maßgeblichvon der Größe des Raums aller theoretisch möglichen Testdaten, genanntSuchraum, ab. Ließe sich dieser einschränken, so könnte dies dem such-basierten Test zu einer Effizienzsteigerung verhelfen. Auf derlei Aspektewird die Arbeit im Detail eingehen. Die ermittelten Probleme adressiertdie Arbeit auf zwei Wegen:

1. Statische Analysetechniken wurden geschaffen, um die Testdaten-generierung besser auf die sich ihr stellenden Probleme einzustel-len und auszurichten. Da diese Techniken vor der eigentlichenTestdatengenerierung Anwendung finden, werden sie als statischeVoranalysen bezeichnet. Es wurden drei derartige Techniken entwi-ckelt, namentlich die Überdeckungsziel-Erreichbarkeitsprüfung (SIA),die Modelleingang-Abhängigkeitsermittlung (SDA) und die Suchziel-priorisierung (CGSeq).

2. Im Weiteren widmet sich die Arbeit alternativen Techniken zur Testda-tengenerierung. In der zugrunde liegenden Vorarbeit von Windisch

einführung 9

Abbildung 1: Übersichtsbild des entwickelten hybriden Testdatengenerie-rungsverfahrens für Simulink/TargetLink-Modelle

wurde zur automatisierten Testdatengenerierung ein globales Such-verfahren verwendet. Daneben existiert die Klasse lokaler Suchver-fahren. Auf die Bedeutung dieser Unterscheidung wird an spätererStelle eingegangen. Mit der Absicht, effizienter Testdaten zu ge-nerieren, wurde in dieser Arbeit ein auf die Bedürfnisse des Testsvon SL/TL-Modellen zugeschnittenes lokales Suchverfahren entwi-ckelt. Ein weiterer Beitrag besteht in der Testdatengenerierungdurch eine Art symbolische Ausführung unter Anwendung vonSMT-Solving, in hybridisierter Form mit einem Suchverfahren.

Die entwickelten Techniken wurden in einem prototypisches Werkzeugumgesetzt. Dieses demonstriert einerseits die Praxistauglichkeit des ent-standenen Ansatzes und dient andererseits der Evaluierung der Beiträgedieser Arbeit. Zwei reale Modelle der Firma Daimler dienen hierbei alsFallbeispiele. Die Ergebnisse der Fallstudien zeigen, dass die hergestell-te Hybridisierung einer suchbasierten Testdatengenerierung zu einerdeutlichen Effizienzsteigerung führt.

Die einleitenden Ausführungen dieses Abschnitts bezüglich des Kontex-tes und der Beiträge dieser Arbeit sind in Abbildung 1 veranschaulicht.Dargestellt ist zum einen der Typ betrachteter Testobjekte, TL-konformeSL-Modelle, sowie die Wahl der Testart, zu deren Zweck eine automa-tisierte Erzeugung von Testdaten erfolgt. Von diesen Testarten rücktder Strukturtest in den Fokus dieser Arbeit. Zum anderen sind in derAbbildung die einzelnen Techniken des hybriden Testdatengenerierungs-verfahrens aufgeführt. Zudem ist eine grobe Abfolge zu erkennen.

10 einführung

aufbau der arbeit

Die Dissertation hat die im Folgenden geschilderte Struktur.

Kapitel 2 behandelt das Hintergrundwissen und die Motivation, welcheden vorgestellten Ideen und Lösungen zu Grunde liegen. Einerseits wirdder klassische, in der Automobilindustrie angewandte modellbasierteEntwicklungsprozess zur Erstellung von Software eingebetteter Systemeeingeführt. In diesem Zusammenhang erfolgt auch eine Einführung inSL und TL, um die in dieser Arbeit betrachteten Modelle zu definie-ren. Andererseits beschäftigt sich das Kapitel mit den Grundlagen desSoftwaretests, dem Test von Modellen im Speziellen und den möglichenAnwendungsszenarien einer automatisierten Testdatengenerierung beimModelltest. Anschließend werden existierende Automatisierungsansätzezur Testdatengenerierung beleuchtet, wobei der suchbasierte Testansatzeine intensivere Betrachtung erfährt. Das Kapitel endet mit einer Analyseder Problemstellungen, welche bei der Anwendung des suchbasiertenTests für SL/TL-Modelle existieren.

In Kapitel 3 werden die drei entwickelten Verfahren zur statischen Vor-analyse vorgestellt. Für die Techniken SIA, SDA und CGSeq werdenjeweils ihre Zielsetzung, ihre Funktionsweise sowie verwandte Arbeitenund Ansätze betrachtet. Die Integration dieser Techniken miteinanderund die ihre Anbindung an die Testdatensuche, im Sinne eines hybridenTestdatengenerierungsverfahrens, erfolgt im Anschluss.

Kapitel 4 befasst sich mit zwei alternativen Testdatengenerierungstechni-ken. Ein lokales Suchverfahren und ein Vorgehen zur Verwendung vonSMT-Solving zu Zwecken der Testdatengenerierung für SL/TL-Modellewerden vorgestellt. Möglichkeiten zur Hybridisierung der Generierungs-techniken sind ebenfalls Thema dieses Abschnitts.

Kapitel 5 stellt den im Rahmen dieser Arbeit entstandenen Testwerkzeug-Prototypen vor.

Die mit diesem Werkzeug durchgeführten Fallstudien zur Evaluierungder entwickelten Ansätze und Techniken finden sich in Kapitel 6 wieder.Eine Bewertung des Entstandenen erfolgt ebenfalls an dieser Stelle.

Kapitel 7 fasst die in dieser Arbeit gemachten Ergebnisse und Erfahrungenzusammen und gibt einen Überblick über offene Themen und Fragestel-lungen im behandelten Gebiet, sowohl aus wissenschaftlicher als auchaus technischer Sicht.

Verwendete Kurzschreibweisen können übrigens im Abkürzungsverzeich-nis nachgeschlagen werden. Dieses folgt, gemeinsam mit Abbildungs- undTabellenverzeichnis, dem Literaturverzeichnis am Ende dieser Arbeit.

2 H INTERGRUND

Das Fundament, auf welches die Beiträge dieser Arbeit aufbauen, istGegenstand dieses Kapitels. Das Themenfeld, in welchem die Arbeit sichbewegt, als auch die Problemstellung, derer sich die Arbeit angenommenhat, werden hier eingehend behandelt. Das Grundlagenwissen und dieAnforderungen an das Arbeitsthema entstammen dabei sowohl wissen-schaftlichen Quellen und der Fachliteratur als auch Erfahrungen undKenntnissen aus der Automobilindustrie.

2.1 modelltest

Ein modellbasiertes Vorgehen bei der Softwareentwicklung führt zwangs-läufig zu der Frage nach der Korrektheit der entwickelten Modelle. DieseAnforderung kommt umso stärker zum Tragen, wenn Modelle nichtnur der Unterstützung einer manuellen Implementierung dienen, wiees beispielsweise in der klassischen Softwareentwicklung häufig der Fallist, sondern der Programmcode gänzlich automatisiert aus Modellengeneriert wird. In der Automobilindustrie wird dies bei der modellba-sierten Entwicklung mittels SL/TL so gehandhabt. Der Test ist in diesemBereich neben Techniken wie Reviews oder statischen Analysen einemögliche Maßnahme zur qualitativen Absicherung eines Modells. Indiesem Abschnitt werden daher neben der modellbasierten Softwareent-wicklung im Automobilbereich und der betrachteten Art von Modellenauch das Wichtigste aus Theorie und Praxis des Softwaretests einführendvorgestellt.

Der Modelltest sollte im Übrigen nicht mit dem modellbasierten Test ver-wechselt oder gleichgesetzt werden. Während es beim Modelltest um dieÜberprüfung eines Modells an sich geht, geht es beim modellbasiertenTest um die Überprüfung eines Testobjekts mithilfe eines Modells. Einsolches Modell bildet üblicherweise Anforderungen (Soll-Verhalten) andas Testobjekt ab und dient der Ableitung von Testfällen, welche dieEinhaltung der Anforderungen durch das Testobjekt untersuchen. DasTestobjekt kann dabei von beliebiger Natur sein, das heißt es könnte sichzum Beispiel um ein Steuergerät oder eben auch um ein SL/TL-Modell

11

12 hintergrund

handeln [22]. Der Begriff Modelltest hingegen setzt voraus, dass das Test-objekt ein Modell ist – stellt aber keinerlei Bedingungen an die Herkunftoder Herleitung der Testfälle/Testdaten.

2.1.1 modellbasierte entwicklung

Modellbasiert Software zu entwickeln, bedeutet, die Implementierungeiner Software durch grafische Notationen geeignet zu unterstützen. Klas-sischerweise finden Modellierungsaktivitäten dabei zeitlich vor anderenAktivitäten zur Realisierung, wie der Programmierung, statt.

Das Bestreben einer modellbasierten Entwicklung gibt es im Bereich dereingebetteten Systeme wie auch bei klassischen Softwaresystemen. AlsHauptgründe für ein modellbasiertes Vorgehen werden typischerweise ei-ne Senkung der Komplexität innerhalb der Entwicklung, eine Steigerungder Qualität, sowie eine positive Auswirkung auf Entwicklungszeitenund -kosten genannt [17]. Kirstan belegt diese Aussage in einer Studie[75] sogar durch Zahlen: Ein modellbasiertes Vorgehen bei der Entwick-lung von eingebetteter Software im Automobilbereich führt zu Kosten-und Zeiteinsparungen von im Schnitt 27 bzw. 36 Prozent. Folgt manden weiteren Ausführungen dieser Studie, so liefert die Validierung aufModellebene darüber hinaus im Schnitt bis zu 60 Prozent mehr gefun-dene Fehler im Software-Design im Vergleich mit der Validierung aufnachfolgenden Ebenen, wenn nicht modellbasiert implementiert wird.

In der klassischen Softwareentwicklung, insbesondere im Bereich derobjektorientierten Programmiersprachen, zählen UML-Modelle [103] zuden prominentesten Notationen im Rahmen einer modellbasierten Ent-wicklung. Allerdings hat die Verwendung derartiger Modelle in der klas-sischen Softwareentwicklung meist nur einen unterstützenden Charakter.Dies bedeutet, dass die Modelle dem Entwickler zwar dabei helfen, seineSoftware sinnvoll zu strukturieren und deren Funktionsweise sauber zuspezifizieren – der Programmcode aber meist unter Zuhilfenahme derentstandenen Modelle manuell geschrieben wird. Im Bereich eingebette-ter Software, insbesondere im Automobilbereich, erfolgt die Erstellungdes Programmcodes (häufig in der Sprache C) heutzutage hingegen größ-tenteils automatisiert. Daher ist bei den der Codegenerierung zugrundeliegenden Modellen auch häufig von Implementierungsmodellen dieRede.

Der hohe Automatisierungsgrad bei der Entwicklung eingebetteter Soft-ware lässt sich vor allem durch die folgenden Feststellungen begründen.Die verwendeten Modellierungsnotationen liegen dem daraus abgeleite-ten Code zum einen sehr nah. So nah, dass mancher die Modellierungauch als grafische Programmierung bezeichnet. Zum anderen sind die

2.1 modelltest 13

Modellierungsnotationen meist sehr speziell. Das bedeutet, sie orien-tieren sich stark an den jeweiligen Besonderheiten eines eingebettetenSystems. Ein Beispiel: Bei eingebetteten Systemen, welche Steuerungs-und Regelungsaufgaben in einem Automobil übernehmen, handelt essich meist um dynamische Systeme. Derartige Systeme berücksichtigenden Faktor Zeit. Im Fall einer Blinkersteuerung gilt es zum Beispiel, dieRichtungsblinker eines Fahrzeugs in einem zeitlichen Takt synchron zu-einander aufleuchten zu lassen. Die zu verarbeitenden und berechnetenWerte und Variablen besitzen also eine zeitliche Dimension. Der dahernotwendigen Signalverarbeitung bei der Softwareentwicklung wird ineiner Modellierungsnotation wie SL Rechnung getragen.

Eine Modellbildung mitsamt Codegenerierung hat weitere Vorteile. Ge-nerierter Code hat eine einheitliche Form und moderne Codegeneratorengarantieren die Einhaltung von Code-Richtlinien, welche in der betref-fenden Domäne gängig oder sogar verpflichtend sind. Ein Modell kannzudem als Formalisierung der Spezifikation gesehen werden und bil-det somit eine Brücke zwischen textueller Spezifikation und Code [106].Hinzu kommt, dass ein Modell verständlicher und einfacher lesbar alsCode ist. Dies gilt nicht nur für den Entwickler selbst, sondern auch fürden Austausch mit anderen Entwicklern und mit weiteren an der Ent-wicklung beteiligten Personen. Eine erhöhte Lesbarkeit erleichtert auchdie Wiederverwendbarkeit und Wartbarkeit entwickelter Software. DieModelle sind zudem ausführbar und ermöglichen somit Simulationenund Tests.

Ein modellbasiertes Vorgehen ist aus der automobilen Softwareentwick-lung mittlerweile nicht mehr wegzudenken. Da die entwickelten Systemeallerdings, wie erwähnt, hohen Ansprüchen zu genügen haben, und dieEntwicklung in der Regel unter Zulieferer-Beteiligung erfolgt, sind mitder Zeit eine Reihe von Firmen- oder sogar Industrie-übergreifendenStandards und Richtlinien entstanden. So haben beispielsweise die NormISO 26262 [39] und die AUTOSAR-Initiative [71] wesentlich zur Gestal-tung der heutigen Entwicklungsprozesse und der Nutzung einheitlicherSoftware-Architekturen beigetragen. Die modellbasierte Entwicklung,insbesondere die Wahl der Modellierungsnotationen und der Werkzeu-ge, erfolgt daher in der Automobilindustrie herstellerübergreifend sehrähnlich.

Als Beispiele bekannter Modellierungsnotationen oder -werkzeuge füreingebettete Systeme und deren Software sind neben SL auch LabView[69], SCADE [111] und Modelica [7] zu nennen. In der Automobilindustrieist SL allerdings die am häufigsten eingesetzte Notation, beziehungsweiseML/SL das am häufigsten eingesetzte Werkzeug. Wird SL verwendet, sokommt häufig der Codegenerator TL zum Einsatz.

14 hintergrund

2.1.2 simulink und targetlink

In den vorherigen Abschnitten wurde bereits erklärt, dass SL eine Er-weiterung des Werkzeugs ML ist und zur Modellierung von Regelungs-und Steuerungssoftware eingebetteter Systeme eingesetzt werden kann.Ebenso wurde der Codegenerator TL erwähnt. In diesem Abschnitt wer-den SL und TL nun im Detail vorgestellt. Teilweise werden die hinter SLstehenden Konzepte sehr detailliert eingeführt – dies ist allerdings füreine präzise Vorstellung der Beiträge dieser Arbeit notwendig.

simulink

Die Grundzüge der SL-Notation lassen sich sehr kurz beschreiben. Bei SL-Modellen handelt es sich um Datenflussdiagramme. Dies sind gerichteteGraphen, bei denen die Knoten Funktionen und die Kanten jeweils Quelleund Ziel eines Datenflusses darstellen. Die Knoten werden in SL alsBlöcke bezeichnet und die Kanten als Signale. Die Daten, welche von Blockzu Block gereicht werden, sind Zahlenwerte. Beispielsweise enthält dieBlock-Bibliothek von SL einen Block mit der Summenfunktion, welcherdie Werte der zu dem Block führenden Signale addiert und das Ergebnismit einem ausgehenden Signal ausgibt. SL ergänzt diese Grundzüge umeine Reihe von Eigenschaften und Techniken. Die Wichtigsten sind imFolgenden aufgeführt.

Ports. Blöcke besitzen Ports. Inports (Eingangsports) und Outports (Aus-gangsports) bilden dabei die externen Schnittstellen eines Blocks, bezie-hungsweise die Ein- und Ausgaben, über die der Block seine Funktiona-lität beschreibt. Einem Port gehört stets genau ein Signal an – vorausge-setzt, das Modell ist vollständig modelliert und somit auch ausführbar.Die In- und Outports eines Blocks sind jeweils durchnummeriert undhaben bezüglich ihrer Darstellung eine entsprechend feste Position amBlock.

Hierarchie. Um auch große Modelle mit einer Vielzahl an Blöcken an-schaulich darstellen zu können, ermöglicht SL die Gruppierung vonBlöcken zu Teilsystemen, sogenannte Subsysteme. Subsysteme verlagerndie gruppierten Blöcke und deren Signalverbindungen auf eine tiefereHierarchie-Ebene. Auf der darüber liegenden Hierarchie-Ebene stellt sichdas Subsystem selbst wiederum als ein Block dar.

Schnittstellen. Auch ein SL-Modell als Ganzes ist im Grunde nichts an-deres als ein Subsystem. Modell und Subsysteme enthalten beide Blöckeund besitzen im Normalfall Ein- und Ausgänge, welche die internenSchnittstellen dieser funktionalen Einheit bilden. Für diesen Zweck existie-ren spezielle Inport- und Outport-Blöcke. Innerhalb eines Subsystems sinddie Inport- und Outport-Blöcke durchnummeriert – entsprechend der

2.1 modelltest 15

Position des dazugehörigen In- oder Outports in der externen Schnittstel-le des Subsystem-Blocks. Der Datenfluss ist in diesem Zusammenhangalso nicht explizit im Modell dargestellt, sondern ergibt sich aus derZuordnung zwischen interner und externer Block-Schnittstelle.

Zeit. SL-Modelle sind dynamische Systeme. Dies bedeutet, sie model-lieren zeitabhängige Prozesse. Hierbei kann es sich sowohl um zeit-kontinuierliche als auch um zeitdiskrete Prozesse handeln. In dieserArbeit werden, wie auch in der Entwicklungspraxis bei Verwendungvon TL, ausschließlich zeitdiskrete Modelle betrachtet. Die zeitliche Dy-namik spiegelt sich in SL-Modellen in dem Umstand wieder, dass dieKanten Signale sind. Signale sind nichts Anderes als Sequenzen vonZahlenwerten, wobei jeder Wert einem Zeitpunkt zugeordnet ist. EinModell besitzt eine global definierte Abtastrate und jeder Block, fallsangegeben, eine individuelle Abtastrate. Die Abtastrate bestimmt beider Ausführung eines Modells, in welchen zeitlichen Zyklen ein jederBlock ausgeführt wird. Der daraus resultierende Ausführungszeitpunktwird im Folgenden auch als Zeitschritt bezeichnet. Damit jeder Blockbei seiner Ausführung auch auf die von ihm benötigten Werte seinerEingangssignale zurückgreifen kann, berechnet SL für die Blöcke einesjeden Subsystems vor der Ausführung des Modells eine – für die Laufzeitstatische – Ausführungsreihenfolge.

Signaleigenschaften. Ein jeder Outport eines jeden Blocks definiert je-weils eine Reihe von Eigenschaften, welche für das von ihm ausgehendeSignal gelten. So wird an dieser Stelle der Datentyp des Signals spe-zifiziert. Des Weiteren ermöglicht SL es, Signale zu bündeln. Hierbeibietet SL zwei unterschiedliche Konzepte an. Zum einen können SignaleVektoren sein und somit mehrere Werte zu einem Zeitschritt bereitstel-len. Dabei bezeichnet die Dimension eines Vektorsignals die Anzahl derWerte, die es enthält. Zum anderen kann ein Signal einen Container fürbeliebig viele andere Signale bilden. In diesem Fall ist von sogenann-ten Bus-Systemen, Bus-Signalen oder einfach nur Bussen die Rede. EinBus-Signal definiert eine Baumstruktur, in der andere Signale angeordnetsind. Die enthaltenen Signale können selbst wiederum Bus-Signale oderVektorsignale sein.

Atomarität und bedingte Ausführung. Ein Subsystem kann als atomareEinheit deklariert werden. Dies wirkt sich auf die von SL berechneteAusführungsreihenfolge aus. Und zwar kann die Ausführung der Blöckeeines atomaren Subsystems nicht durch die Ausführung eines Blockes,der außerhalb dieses Subsystems liegt, unterbrochen werden. SL stellt dar-über hinaus eine Reihe von atomaren Subsystem-Typen zur Verfügung,deren enthaltene Blöcke nur zu den Zeitschritten ausgeführt werden, beidenen eine bestimmte Bedingung gilt. So besitzt das Enabled Subsystemeinen zusätzlichen Eingang mit einem sogenannten Kontrollsignal. DieBlöcke eines Enabled Subsystems werden nur dann ausgeführt, wenn

16 hintergrund

dieses Kontrollsignal einen positiven Wert enthält. Für die Ausgängeeines solchen Subsystems kann festgelegt werden, ob es im Falle derInaktivität den letztmalig berechneten oder einen spezifizierten Wertausgeben soll. Ein Subsystem, welches nicht atomar ist, wird auch alsvirtuelles Subsystem bezeichnet.

Stateflow (SF). Dies ist eine Statechart-ähnliche Notation für Zustands-automaten und Flussdiagramme. Mithilfe von SF können insbesondereereignisgesteuerte Funktionalitäten effizienter modelliert werden als mitSL-Mitteln. In SL können SF-Automaten innerhalb eines SF-Blocks model-liert werden. Die Ein- und Ausgänge eines SF-Blocks lassen sich beliebiggestalten, je nachdem welche Signale in dem Automaten benötigt werdenoder berechnet werden sollen.

targetlink

Der Codegenerator TL integriert sich direkt in die Entwicklungsumge-bung von SL. TL stellt zum einen zusätzliche Anforderungen an einSL-Modell. So schränkt TL die Menge der erlaubten Blöcke unter ande-rem dahingehend ein, dass es in dem Modell keine zeitkontinuierlichen,sondern ausschließlich zeitdiskrete Blöcke geben darf. Das Modell mussso gestaltet sein, dass die Modellsimulation mit einem Solver erfolgenkann, der eine feste (statische) Abtastrate voraussetzt. Diesbezüglichgeht TL konform mit dem Industriestandard ISO 26262 [39]1, welchereine variable Abtastrate bei der Fahrzeug- und Umgebungsmodellierungals relevant erachtet, für die eingebettete Software aus Gründen einereffizienten Codegenerierung allerdings eine feste Abtastrate empfiehlt.

Darüber hinaus ergänzt TL die Block-Bibliothek von SL. Die Block-Bibliothek von TL umfasst sowohl Blocktypen, welche äquivalente, inSL vorhandene Blocktypen ersetzen, als auch Blocktypen, die in SL stan-dardmäßig nicht enthalten sind. Der Grund, wieso TL eigene Blöckeanbietet, ist zweifältig. Einerseits haben TL-eigene Blöcke zusätzlicheParameter, welche für die Codegenerierung von Bedeutung sind. Ande-rerseits existiert das Problem, dass es für die Blocktypen in SL keine freiverfügbare formale Semantik gibt. Um aber eine einwandfreie Codege-nerierung zu garantierten, bringt TL eine eigene Block-Palette mit. Eineformale Semantik ist allerdings auch für den TL-Sprachumfang nichtveröffentlicht.

definition eines sl/tl-modells

Die Semantik der Blöcke ist auch für die in dieser Arbeit entwickeltenTechniken von Relevanz. Verschiedene Arbeiten haben sich in der Vergan-genheit mit der Definition einer Semantik für SL beschäftigt – allerdings

1 ISO/DIS 26262-6, Kapitel 6, Anhang B, Model Based Development

2.1 modelltest 17

vornehmlich mit der SF-Notation. So stellte Hamon zum einen einedenotationelle Semantik für SF vor [53] und zum anderen, gemeinsammit Rushby, eine operationale Semantik [55], ebenfalls beschränkt aufSF. Eine eigene Definition der Blocksemantik, zumindest für SL, ist alsovonnöten. Diese findet nicht nur bei der Vorstellung der Beiträge dieserArbeit, sondern auch in den weiteren Ausführungen dieses KapitelsVerwendung.

Neben der Semantik ist auch ein exaktes Verständnis der Syntax einesSL/TL-Modells wichtig. In diesem Zusammenhang haben mehrere Ar-beiten Meta-Modelle für SL entwickelt. So benötigte Scheible [107] einsolches Meta-Modell zur Messung von Modellqualitätsmetriken. Ebensowurde ein Meta-Modell im Rahmen des MATE-Ansatzes zur automati-sierten Prüfung von Modellqualitätsrichtlinien und der Behebung vonentsprechenden Verletzungen definiert [80]. Mit dem Ziel, SL-Modellezu refaktorisieren und zu transformieren, stellten Tran et al. [119] einMeta-Modell für SL auf. Die Meta-Modelle dieser Arbeiten sind jedochentweder auf ihren eigenen Anwendungszweck zugeschnitten oder un-zureichend für den Anwendungszweck dieser Arbeit. So benötigen diein dieser Arbeit vorgestellten Techniken beispielsweise keine Layout-Informationen. Inhalte aus dem ML-Workspace hingegen sind beispiels-weise von Interesse.

In dieser Arbeit wird daher eine eigene Definition eines SL/TL-Modellsaufgestellt. Die Definition ist dabei aus den Schilderungen der Doku-mentationen von SL (Version R2009b) und TL (Version 3.1), sowie derBeobachtung des Simulationsverhaltens der Blöcke, abgeleitet. Sie hatkeinen Anspruch auf Vollständigkeit, sondern bildet nur die Bestandteilevon SL und TL ab, die in dieser Arbeit relevant sind. Im Folgenden wirdbei Bedarf auf verwendete Hilfsfunktionen und -mengen verwiesen, wel-che in Tabelle 1 aufgeführt sind. Eine Erläuterung dieser erfolgt jeweilsentweder an passender Stelle auf den folgenden Seiten oder bei spätererVerwendung.

Modell. Ein SL/TL-Modell sei durch folgendes Tupel aus der Mengealler möglichen Modelle M gegeben:

M = { (B,P,S,W, DD,C) | B⊆((BSLS⊂BSL)∪BTL) } (1)

Hierbei ist B die Menge aller im Modell enthaltenen Blöcke. BSLS isthierbei die Untermenge der von TL unterstützten SL-Blöcke BSL, ergänztum die TL-eigenen Blöcke BTL. P ist die Menge aller Ports, S die Mengealler Signale. Die im ML-Workspace abgelegten Variablen und deren Bele-gung, auf welche ein Modell bei seiner Ausführung zurückgreifen kann,sind in der Menge W enthalten. Das zu TL gehörende Data Dictionary, indem ebenfalls Variablenbelegungen sowie weitere Informationen abge-legt sein können, sei an dieser Stelle abstrakt als Menge DD bezeichnet.

18 hintergrund

(a) Eingangs-/Ausgangssignale eines Blocks:

ISb = {s |s=(sp,DP)∈S∧∃p∈ IPb:p∈DP}OSb = {s |s=(sp,DP)∈S∧∃p∈OPb:p= sp}

(b) Signal eines Ports:

sig :P→Ssig(p)=pspsigin, sigout :B×N+→Ssigin(b, pos)= sig(ip(b, pos))sigout(b, pos)= sig(op(b, pos))

(c) In-/Outport eines Blocks über Portposition:

ip , op :B×N+→Pip(b, pos) = p′ mit p′=(pos, ps,d)∈ IPb

op(b, pos) = p′′ mit p′′=(pos, ps,d)∈OPb

(d) Quellport undZielports eines Si-gnals:

src :S→Psrc(s)= spsdest :S→P(P)dest(s)=DPs

(e) Signal-/In-port-Dimension:

d :S→N+

d(s)=dsrc(s)

d :P→N+

d(p)=dp

d :B×N+→N+

d(b, pos)=dip(b, pos)

(f) Block eines Ports:

b :P→B

b(p)=b′

mit b′∈B∧(p∈ IPb′ ∨p∈OPb′)

(g) Wert an Block-Inportfür Zeitschritt:

invb, pos :N→R

invb, pos(ts)=outvb(p′), pos(p′)(ts)

mit p′= src(sig(ip(b, pos)))

(h) Maximale Dimension aller Blockeingänge:

maxdin :B→N+

maxdin(b)=x′ mit (∃p1∈ IPb:x′=dp1

)

∧(∀p2∈ IPb:dp2�x′)

(i) Portposition:

pos :P→N+

pos(p)=posp

(j) Übergeordnete Subsysteme eines Blocks(direktes/alle) und Hierarchietiefe:

psysdir :B→Bpsysdir(b)=x′ mit b∈BCx′psysall :B→P(B)

psysall(b)={{x}∪ psysall(x) , ∃x∈B∧b∈BCx

∅ , sonstdep :B→N

dep(b)={1+dep(x) , ∃x∈B∧b∈BCx

0 , sonst

(k) Vektorindex-Korrekturfür Port oder Signal:

vc :N+×P→N+

vc(v,p)=min(v,dp)vc :N+×S→N+

vc(v,s)=min(v, src(s))

(l) Wahrheitswert einesSignalwerts:

T , F :R→B

T(x)={1 , wenn x�=00 , sonst

F(x)=¬T(x)

Tabelle 1: Hilfsfunktionen und -definitionen für Simulink/TargetLink-Modelle, welche in diesem Dokument zu weiteren Beschrei-bungen und Definitionen Anwendung finden

2.1 modelltest 19

Die Menge C bildet die Ausführungskonfiguration des Modells – diesebeinhaltet unter anderem die globale Abtastrate.

Block. Ein Block sei durch folgendes Tupel aus der Menge aller Blöcke B

eines Modells gegeben:

B = { (bt, IP,OP, BC, PV) | bt∈BT∧ IP⊆P∧ OP⊆P∧ BC⊂B } (2)

Der Parameter bt bezeichnet den Blocktypen. Dieser wird nachfolgenddefiniert. IP ist die Menge der Eingangsports, OP die Menge der Aus-gangsports. Handelt es sich bei einem Block um ein Subsystem, so bildendie enthaltenen Blöcke die Menge BC. Fast alle Blocktypen besitzen Para-meter, deren Belegung für eine Blockinstanz in der Menge PV enthaltenist.

Blocktyp. Jeder Block im Modell ist eine Instanz eines Blocktypen. EinBlocktyp sei als Element aller Blocktypen BT durch folgendes Tupeldefiniert:

BT = { (PM, outvb,pos, stvb, actb, rsb) } (3)

PM ist die Menge der Blocktyp-spezifischen Parameter (z.B. eine individu-elle Abtastrate) mit ihren Bezeichnern und gegebenenfalls dazugehörigenBelegungsmöglichkeiten. Die Abbildung

outvb,pos : N→R (4)

beschreibt die Blockfunktionalität über den berechneten Ausgabewertzu einem bestimmten Zeitschritt und dient als Vorlage für eine Blockin-stanz b. Der Parameter pos bezeichnet die Position eines der Ausgangs-ports und v einen der Vektorindizes des von diesem Port abgehendenSignals.

Manche Blöcke verwalten darüber hinaus einen Zustand

stvb : N→R (5)

Dieser gilt ebenfalls für einen bestimmten Zeitschritt und kann die Formeines Vektors (Index-Angabe v) haben.

Die Entscheidung über die Aktivität einer Blockinstanz zu einem Zeit-schritt ist durch

actb : N→B (6)

gegeben. Falls ein Blocktyp diese Abbildung nicht spezifisch definiert, giltallgemein, dass ein Block aktiv ist, wenn kein übergeordnetes Subsysteminaktiv ist:

actb(ts) = ¬∃x∈psysall(b): ¬ actx(ts) (7)

20 hintergrund

Die Funktion psysall (siehe Tabelle 1, Abschnitt j) bestimmt hierbei alleSubsystem-Blöcke, die einem Block in der Modellhierarchie übergeordnetsind.

Im Zuge der (Re-)Aktivierung eines Blocks besteht, je nach Parameter-Konfiguration, die Möglichkeit des Zurücksetzens des internen Zustands.Ob ein Zurücksetzen zu einem Zeitschritt erfolgt, gibt die Funktion

rsb : N→B (8)

an. Falls für einen Blocktyp nicht anders definiert, gilt, dass eine Reakti-vierung nur dann erfolgt, wenn das in der Subsystem-Hierarchie nachoben hin nächstfolgende bedingt ausgeführte Subsystem ein Zurückset-zen verlangt:

rsb(ts) =

⎧⎪⎨⎪⎩1 , ∃x∈psysall(b):

(rsx(ts)∧∀y∈psysall(b): dep(x)�dep(y))

0 , sonst

(9)

Die Funktion dep (siehe Tabelle 1, Abschnitt j) bezeichnet hierbei dieHierarchietiefe eines Blocks, das heißt die Anzahl aller Subsystem-Blöcke,die dem Block in der Modellhierarchie übergeordnet sind.

Port. Ein Port als Element aller Ports P sei definiert als Tupel seinerPosition pos, dem angehörigen Signal ps, sowie der Dimension d unddem Datentyp dt des von diesem Port ausgehenden Signals:

P = { (pos, ps,d, dt) | pos∈N+∧ ps∈S∧d∈N+ } (10)

Eine Funktion, welche den zu einem Port gehörenden Block liefert, istfür eine spätere Verwendung in Tabelle 1 (Abschnitt f) angegeben. DiePosition eines Ports ist in der Tabelle zudem auch über eine Funktiondefiniert (Abschnitt i).

Signal. Ein Signal aus der Menge aller Modellsignale S sei durch seinenUrsprung (Outport sp) und seine Ziele (Inport-Menge DP) definiert:

S = { (sp,DP, BS) | sp∈P∧DP⊆P } (11)

Handelt es sich um ein Bus-Signal, so bildet die Menge BS die Bus-Struktur ab. Diesem Fall wird an dieser Stelle nicht weiter Rechnunggetragen, da Bus-Signale im Rahmen des entwickelten Verfahrens zuBeginn aufgelöst werden und anschließend keine Rolle mehr spielen.

In Tabelle 1 (Abschnitt a) sind im Übrigen für eine spätere Verwendungin dieser Arbeit die Mengen ISb und OSb definiert. Sie enthalten jeweilsalle ein-/ausgehenden Signale eines Blocks. Zudem sind in dieser Tabellein Abschnitt b Funktionen definiert, mit welchen einerseits das Signaleines Ports und andererseits ein ein- oder ausgehendes Signal eines

2.1 modelltest 21

Blocks durch Angabe der Portposition abgefragt werden können. Letzterenutzen die Funktionen ip und op (siehe Tabelle 1, Abschnitt c), welcheden Ein-/Ausgangsport eines Blocks mit einer bestimmten Portpositionliefern. Den Ursprungsport und die Zielports eines Signals geben dieFunktionen src und dest an (siehe Tabelle 1, Abschnitt d). Die Dimensioneines Signals kann durch die in der Tabelle in Abschnitt e definiertenFunktionen abgefragt werden. Die Funktionen ermitteln die Dimensionhierbei wahlweise über Angabe des Signals, des zugehörigen Ports oderdes zu diesem Port gehörenden Blocks mitsamt Angabe der Portposition.Zudem existiert die Funktion maxdin, welche die maximale Dimensionaller in einen Block eingehenden Signale angibt (Abschnitt h).

Simulation. Die Simulation/Ausführung eines Modells wird in dieserArbeit als eine Art Black-Box betrachtet. Das bedeutet, die Behandlungund Funktionsweise einer Simulation in SL ist irrelevant. Relevant sindnur die der Simulation zu Grunde liegenden Daten und die Ergebnisseder Simulation. Entsprechend fällt die Definition aus:

SIM = { (MI,CS,MO) } (12)

MI ist die Menge der in das Modell eingehenden Signale. Für jeden Mo-delleingang i enthält MI eine Funktion mii :N→R über die Zeitschritteder Simulation. MO ist entsprechend die Menge der ausgehenden Signaleeines Modells (bestehend aus moj :N→R je Modellausgang j). CS ist eineoptionale Konfiguration der Simulation, welche die Konfiguration Cm

eines Modells m∈M überschreibt, je nach Vorhandensein der einzelnenmöglichen Parameterangaben in CS.

Blocksemantik. Die Definition der Funktionalität einiger ausgewähl-ter Blöcke, welche in SL/TL-Modellen häufig verwendet werden, ist inTabelle 2 durch Angabe der spezifischen Ausgabefunktionen outvb,posaufgeführt. Genau genommen sind dort exakt die Blocktypen gelistet,welche in Beispielen oder weiteren Betrachtungen dieser Arbeit vorkom-men. Eine vollständige Auflistung für alle SL/TL-konformen Blocktypenwürde den Rahmen dieser Arbeit sprengen. Wenige spezielle, in dembetrachteten Praxisumfeld selten vorkommende Sonderfälle sind in denDefinitionen zudem außen vor gelassen, um die Darstellung anschaulichzu halten oder den Aufwand der Umsetzung der entwickelten Technikenkontrollierbar zu halten. Zum Beispiel entfällt die Behandlung dynami-scher Signaldimensionen, das heißt sich während der Laufzeit änderndeVektorbreiten. Bei den Definitionen der Blockfunktionalitäten in der Ta-belle ist des Weiteren zu beachten: Ein Signal wird standardmäßig alsVektor-Signal verstanden. Ein Nicht-Vektor-Signal ist schlichtweg eineindimensionales Vektor-Signal. Im Folgenden werden die Darstellungender Tabelle je enthaltenem Blocktyp kurz in Worte gefasst.

Inport. Ein Inport-Block besitzt als einzigen Blockparameter eine Port-nummer. Die Ausgabe eines Inport-Blocks ist abhängig davon, ob sich der

22 hintergrund

Block in einem Subsystem oder auf der höchsten Hierarchie-Ebene desModells befindet. Ist er in einem Subsystem, so wird der Eingangswertdes dem Inport-Block zugeordneten Subsystem-Inports ausgegeben. Han-delt es sich um einen Modell-Eingang, so gibt der Block den durch dieSimulation festgelegten Eingangswert aus. Die in der Tabelle verwendeteAbbildung invb, pos gibt den Wert des Eingangssignals des Blocks b mitder Portposition pos und dem Vektorindex v zu einem Zeitschritt wieder.Die Definition hierzu enthält Tabelle 1 (Abschnitt g).

Outport und Subsystem. Ein Outport-Block hat selbst keinen Ausgang. Die-ser befindet sich, sofern es sich nicht um einen Modellausgang handelt,an dem Subsystem, in dem sich der Outport-Block befindet. Handeltes sich um ein virtuelles Subsystem, so gibt dieses den Wert, der inden Outport-Block eingeht, direkt aus. Ein Outport-Block hat allerdingsneben einer Portnummer zwei weitere Parameter: einen Initialwert sowiedie Einstellmöglichkeit des Ausgabeverhaltens des übergeordneten Sub-systems bei Inaktivität. Diese zwei Parameter sind für die Funktionalitäteines bedingt ausgeführten Subsystems von Interesse.

Constant. Der Block besitzt als Parameter eine Konstante. Diese kannauch ein Vektor sein. Der Block gibt diese Konstante unabhängig vombetrachteten Zeitschritt aus. Die Möglichkeit, dass der Konstantenpa-rameter stattdessen eine Referenz auf eine im Workspace befindlicheVariable enthält, ist der Übersichtlichkeit halber in dieser Definition nichtenthalten. Dies gilt ebenfalls für alle anderen in der Tabelle dargestelltenBlocktypen und ihre Parameter.

Logical Operator. Dieser Block realisiert eine aussagenlogische Verknüp-fung seiner Eingangswerte. Der Block-Parameter Operator gibt den Typder Verknüpfung an: AND (∧), OR (∨), NAND (↑), NOR (↓), XOR (⊕)oder NOT (¬). Ein weiterer Parameter legt die Anzahl der Eingänge fest.Handelt es sich nun um den Operator ¬, so gibt der Block den Wert 1 aus,wenn der Wert am einzigen Blockeingang mit dem gleichen Vektorindexgleich 0 ist – andernfalls gibt er den Wert 0 aus. Hat der Block einender anderen Operatoren, so gibt es zwei Fälle. Hat der Block nur einenEingang, so definiert sich die aussagenlogische Operation über alle Vek-torelemente dieses Eingangs und gibt entsprechend der Funktionalitätdes Operators den Wert 0 oder 1 aus. Hat der Block mehrere Eingänge,so bezieht sich der Operator auf die Werte aller Eingänge mit dem glei-chen Vektorindex. Die Dimension des Ausgangssignals entspricht dabeider größten Dimension einer der Eingangssignale. Bei unterschiedlichenDimensionen wird ein Eingangsvektor gegebenenfalls durch sein letztesVektorelement erweitert. In der Definition der Funktionsweise diesesBlocks in Tabelle 2 geben die Funktionen T und F (siehe Tabelle 1, Ab-schnitt l) die Wahrheitswerte wahr und falsch eines reellen (Signal-)Wertsan. Die Funktion vc (siehe Tabelle 1, Abschnitt k) korrigiert des Weiterendie Angabe eines Vektorindex für ein Signal, wenn diese Angabe die

2.1 modelltest 23

Dimension des Signals überschreitet. Die Funktion vc existiert in zweiVarianten: für ein Signal und für den Ursprungsport eines Signals.

Relational Operator. Der Block besitzt zwei Eingänge. Je nach verwende-tem Vergleichsoperator, der als Parameter festgelegt ist, vergleicht derBlock zwei Eingangswerte und gibt je nach Zutreffen der Operatorbe-dingung eine 0 oder 1 aus. Die Operation erfolgt je Vektorindex, wobeiEingangsvektoren bei ungleicher Dimensionalität erweitert werden.

Switch. Ein solcher Block hat zwei Daten-Eingänge (oben und unten) undeinen Kontroll-Eingang (in der Mitte). Je nach Wert am Kontroll-Eingangleitet der Block einen der beiden Daten-Eingänge zum Ausgang durch.Die zwei Parameter Kriterium und Schwellwert bestimmen dabei dieBedingung, die für das Durchleiten des oberen Daten-Eingangs geltenmuss. In der Definition wird zwischen dem Fall, dass Kontroll-Eingangoder Schwellwert mehrdimensional sind, und dem Fall eines eindimen-sionalen Kontroll-Eingangs und Schwellwerts unterschieden. In letzteremFall wird auch berücksichtigt, dass die Daten-Eingänge möglicherweiseunterschiedliche Dimensionen haben.

Unit Delay. Dieser Block gibt seinen Eingangswert um einen Zeitschrittverzögert aus. Hierzu greift er auf einen internen Zustand zurück. Exis-tiert kein vorheriger Zeitschritt, so gibt der Block einen Initialwert aus.Befindet sich der Block in einem bedingt ausgeführten Subsystem undkommt es zu einem Zurücksetzen der Zustände innerhalb dieses Subsys-tems, so setzt der Block seinen Zustand auf den Initialwert zurück.

Product, Sum und Min/Max. Die Blöcke Product und Sum können zurMultiplikation oder Division, beziehungsweise zur Addition oder Sub-traktion ihrer Eingangswerte verwendet werden. Hierbei kann über einenParameter jedem Eingang ein individueller Operator zugewiesen werden.Die Operation erfolgt im Falle von nur einem Eingang über die Vektorele-mente desselben oder, bei mehreren Eingängen, über alle Eingangswertemit gleichem Vektorindex. Dies gilt auch für den Min/Max-Block, der jenach Parameterwahl den kleinsten oder größten Eingangswert ausgibt.

Abs und Gain. Ein Abs-Block berechnet den Absolutwert seines Eingangs-werts und ein Gain-Block multipliziert seinen Eingangswert mit einemFaktor, der als Parameter vorliegt. Beide Blocktypen berechnen ihr Ergeb-nis dabei je Vektor-Element.

Enabled Subsystem und Enable. Die Funktionsweise des Enabled-Subsystem-Blocks ist im Vergleich zu den vorigen Blöcken ein wenig komplizierter.Ein solcher Block enthält stets einen Enable-Block. Dieser kann, soferngewünscht, den Wert des Subsystem-Kontrolleingangs ausgeben. In derDefinition hierzu in Tabelle 2 bezeichnet die Funktion psysdir (sieheTabelle 1, Abschnitt j) das diesem Block in der Modellhierarchie direktübergeordnete Enabled Subsystem. Darüber hinaus besitzt ein Enable-Block einen Parameter, über den sich einstellen lässt, ob die im Subsystem

24 hintergrund

enthaltenen Blöcke ihre Zustände bei einer (Re-)Aktivierung zurückset-zen. Ein Enabled Subsystem besitzt eine individuelle Aktivitäts- undZurücksetzungsfunktion. Erstere sagt aus, dass das Subsystem aktivist, wenn mindestens ein Vektor-Element des Kontrolleingangs einenpositiven Wert enthält. Darauf basierend bestimmen die im Subsystementhaltenen Blöcke ihre Aktivität über die in Definition 7 dargestellte all-gemeine Aktivitätsfunktion. Die Zurücksetzungsfunktion zeigt für die imSubsystem enthaltenen Blöcke an (siehe Definition 9), dass sie ihren Zu-stand zurückzusetzen haben, wenn (a) der Parameter des Enable-Blocksentsprechend eingestellt ist und (b) das Subsystem zum vorherigen Zeit-schritt inaktiv war und nun aktiv geworden ist. Das Ausführungsverhal-ten bedingt ausgeführter Subsysteme stellt im Übrigen eine Besonderheitdar. Normalerweise berechnen Blöcke ihre Ausgabe(n) nicht bei Inakti-vität – ein bedingt ausgeführtes Subsystem allerdings schon. Die dabeiausgegebenen Werte hängen in erster Linie von der (In-)Aktivität ab.Ist das Subsystem aktiv, so werden je Ausgangsport die Eingangswertedes dazugehörigen Outport-Blocks ausgegeben. Bei Inaktivität gibt einParameter des jeweiligen Outport-Blocks an, ob ein Initialwert oder derzuletzt ausgegebene Wert erneut ausgegeben werden soll.

Mit den Ausführungen dieses Abschnitts sind die Grundlagen gelegt,um sich im Folgenden mit dem Test von SL/TL-Modellen und derTestdatengenerierung für sie auseinanderzusetzen.

Inport

PM Portnummer: n∈N+

out

Fall 1: ∃sb∈B: b∈BCsb

∀v∈N[1,d(sb,n)]: outvb,1(ts)= invsb,n(ts)

Fall 2: ∀sb∈B: b�∈BCsb

out1b,1(ts)=x mit x=min(ts)∈MIsim∧sim∈SIM

OutportPM

Portnummer: m∈N+

Initialwert: iv∈Rq (q∈N+)

Subsystem-Ausgabeverhalten bei Inaktivität:

io∈B (Halten: io, Zurücksetzen auf iv: ¬ io)

Subsystemout

∀pos∈N[1,|OPb |]: ∀v∈N[1,d(op(b, pos))]:

outvb,pos(ts) = invb2,1(ts)

mit b2∈BCb ∧btb2=Outport∧(„m“,pos)∈PVb2

Constant

PM Konstante: ck∈RN[1,n]

out ∀v∈N[1,n]: outvb,1(ts) = cv

Tabelle 2: Blocktypen TL-konformer SL-Modelle (Auszug)

2.1 modelltest 25

LogicalOperator

PMOperator: •∈{∧,∨, ↑, ↓,⊕,¬}Eingang-Anzahl: n∈N+

out

Fall 1: •=¬

∀v∈N[1,d(b,1)]: outvb,1(ts) = ¬(invb,1(ts))

Fall 2: •�=¬

Fall 2.1: n>1

∀v∈N[1,maxdin(b)]:

outvb,1(ts) = ◦({invc(v,p)

b,pos(p)(ts) |p∈IPb})

Fall 2.2: n=1

out1b,1(ts) = ◦({invb,1(ts) |v∈N[1,d(b,1)]})

Es sei ◦ : P(R)→R mit

◦(X)=

⎧⎪⎪⎪⎪⎪⎪⎪⎪⎪⎨⎪⎪⎪⎪⎪⎪⎪⎪⎪⎩

1 , ((•=∧)∧∀x∈X:T(x))∨((•=∨)∧∃x∈X:T(x))∨

((•= ↑)∧∃x∈X:F(x))∨((•= ↓)∧∀x∈X:F(x))∨

((•=⊕)∧((∑x∈X,T(x)

1)%2)>0)

0 , sonst

RelationalOperator

PM Operator: •∈{=, �=,>,<,�,�}

out


outvb,1(ts)=

⎧⎨⎩1, in

vc(v,ip(b,1))b,1 (ts)• invc(v,ip(b,2))b,2 (ts)

0, sonst

Switch

PMKriterium: •∈{>,�, �=}Schwellwert: tk∈R

N[1,n] (•=„�=“ ⇒ tk=0)

out

Fall 1: max(n, d(b,2))>1

∀v∈N[1,max(n,d(b,2))]:

outvb,1(ts)=

⎧⎪⎪⎪⎨⎪⎪⎪⎩invc(v, ip(b,1))b,1 (ts) , invc(v, ip(b,2))b,2 (ts)

•tmin(v,n)

invc(v, ip(b,3))b,3 (ts) , sonst

Fall 2: n=d(b,2)=1

Fall 2.1: in1b,2(ts)•t1∀v∈N[1,d(b,1)]: outv

b,1(ts) = invb,1(ts)

Fall 2.2: ¬(in1b,2(ts)•t1)∀v∈N[1,d(b,3)]: outv

b,1(ts) = invb,3(ts)


26 hintergrund

Unit Delay

PM Initiale Ausgabe: ak∈RN[1,n]

st ∀v∈N[1,d(b,1)]: stvb(ts)=

⎧⎨⎩amin(v,n) , rsb(ts)

invb,1(ts−1) , sonst

out ∀v∈N[1,d(b,1)]: outvb,1(ts)=

⎧⎪⎨⎪⎩stvb(ts) , ts>0

amin(v,n) , sonst

Product

PMOperator je Eingang: •:N[1,n]→{×,÷} oder

Eingang-Anz.: n∈N+ (∀i∈N[1,n]: •(i)=×)

out

Fall 1: n>1

∀v∈N[1,maxdin(b)]: outvb,1(ts)=

1 •(1)

invc(v,p1)b,1 (ts)...•(i)

invc(v,pi)b,i (ts)... •(n)

invc(v,pn)b,n (ts)

mit i∈N[1,n]∧pi∈IPb∧i=pos(pi)

Fall 2: n=1

out1b,1(ts)=1 •

(1)in1b,1(ts)... •

(1)injb,1(ts)... •

(1)inmb,1(ts)

mit m=d(b,1)∧j∈N[1,m]

Sum

PMOperator je Eingang: •:N[1,n]→{+,−} oder

Eingang-Anz.: n∈N+ (∀i∈N[1,n]: •(i)=+)

out

Fall 1: n>1

∀v∈N[1,maxdin(b)]: outvb,1(ts)=

0 •(1)

invc(v,p1)b,1 (ts)...•(i)

invc(v,pi)b,i (ts)... •(n)

invc(v,pn)b,n (ts)

mit i∈N[1,n]∧pi∈IPb∧i=pos(pi)

Fall 2: n=1

out1b,1(ts)=0 •

(1)in1b,1(ts)... •

(1)injb,1(ts)... •

(1)inmb,1(ts)

mit m=d(b,1)∧j∈N[1,m]

Abs

out ∀v∈N[1,d(b,1)]: outvb,1(ts) = | invb,1(ts)|

Gain

PM Faktor: gfk ∈RN[1,n]

out∀v∈N[1,max(n,d(b,1))]:

outvb,1(ts) = gfmin(v,n) · invc(v, ip(b,1))b,1 (ts)


2.1 modelltest 27

Min/Max

PMFunktion: •∈{min,max} , • : P(R)→R

Eingang-Anzahl: n∈N+

out

Fall 1: n>1


outvb,1(ts)= •({invc(v,p)

b, pos(p)(ts) |p∈ IPb})

Fall 2: n=1

out1b,1(ts)= •({invb,1(ts) |v∈N[1,d(b,1)]})

Enable

PM

Zustände der Subsystem-Blöcke

bei (Re-)Aktivierung: az∈B

(Halten: az, Zurücksetzen: ¬ az)Aktivierung des Ausgangs: a∈B

outVoraussetzung: a∀v∈N[1,d(pb ,| IPpb|)]: outv

b,1(ts)= invpb,| IPpb|(ts)wobei pb=psysdir(b)

EnabledSubsystem

actactb(ts)=

{1 , ∃v∈N[1,dc]: in

vb,| IPb|(ts)>0

0 , sonstwobei dc=d(b,| IPb|)

rsrsb(ts)=

{1 , ts>0∧¬ az∧¬ actb(ts−1)∧ actb(ts)0 , sonst

wobei eb∈BCb ∧ bteb =Enable∧(„az“, az)∈PVeb

out

∀pos∈N[1,|OPb|]:

Fall 1: actb(ts)∀v∈N[1, d(obpos ,1)]: outv

b,pos(ts)= invobpos ,1(ts)Fall 2: ¬ actb(ts)∧ iopos

Fall 2.1: ts>0

∀v∈N[1, d(obpos ,1)]: outvb,pos(ts)= outvb, pos(ts−1)

Fall 2.2: ts=0

∀v∈N[1,qpos]: outvb,pos(ts)= ivvpos

Fall 3: ¬ actb(ts)∧¬ iopos∀v∈N[1,qpos]: outv

b,pos(ts)= ivvposmit

obpos∈BCb ∧ btobpos=Outport∧(„m“,pos)∈PVobpos ∧

iopos ∈B∧(„io“,iopos)∈PVobpos ∧

ivxpos ∈R∧(„iv“,ivxpos)∈PVobpos∧x∈N[1, qpos]∧

qpos ∈N+∧(„q“,qpos)∈PVobpos


28 hintergrund

2.1.3 testgrundlagen

In diesem Abschnitt wird der Test von eingebetteten Systemen undderen Software grundlegend behandelt. Zudem werden wichtige Begriffeeingeführt. Der Modelltest nimmt dabei eine zentrale Rolle ein.

Testen bedeutet in der industriellen Praxis in erster Linie, für die in derSpezifikation eines Systems niedergeschriebenen funktionalen Anforde-rungen die Einhaltung durch das System zu prüfen. Das zu prüfendeSystem wird als Testobjekt bezeichnet, um von seiner Natur (wie bei-spielsweise Steuergerät, Modell oder Code) zu abstrahieren. Diese Artdes Testens wird üblicherweise als Funktionstest oder als Anforderungs-test bezeichnet. Aus den Anforderungen werden dabei Testfälle abgeleitet.Ein Testfall definiert ein Szenario, welchem sich das Testobjekt stellenmuss, und legt das erwartete Testobjekt-Verhalten fest. Das Szenariobesteht hierbei aus der Umgebung, welche für die Durchführung desTests herzustellen ist, sowie aus Testschritten. Die Testschritte beinhaltenentweder Testdaten oder diese lassen sich aus ihnen ableiten. Testdatensind die rohen Eingabedaten (Stimuli) für die Ausführung des Testob-jekts. Findet eine automatisierte Testausführung statt, so wird ein Testfallin eine Testimplementierung überführt. Dies kann modellbasiert oderdurch ein Skript erfolgen. Bei der Testausführung wird das Verhalten desTestobjekts überwacht und protokolliert. Anschließend gilt es, die Konfor-mität der Ergebnisse mit dem erwarteten Testobjekt-Verhalten zu prüfen.Wurde das erwartete Verhalten zuvor in ein Testorakel überführt, bei-spielsweise in Form eines Prüfskripts, so kann die Konformitätsprüfungautomatisiert erfolgen.

Die Entwicklung eingebetteter Systeme orientiert sich in der Automo-bilindustrie im Normalfall an dem Vorgehensmodell V-Modell XT [66].Eine auf den Automobilbereich gemünzte Abwandlung hiervon ist inAbbildung 2 dargestellt. Der linke Ast im V-Modell beschreibt die Prozess-schritte zur Planung und Spezifikation des Produkts. Die Realisierungder einzelnen Bausteine des Produkts finden im V-Modell im unterenAbschnitt statt. Der rechte Ast stellt die Teststufen dar, welche sich ausder phasenweisen Integration der Bausteine zum Gesamtprodukt erge-ben. Klassischerweise dienen die Spezifikationsdokumente im linken Astjeweils dem Funktionstest des Testobjekts auf gleicher Ebene im rechtenAst. Die Entwicklungspraxis weicht von dieser Grundidee aber meistab: Spezifikationsdokumente werden beispielsweise gebündelt, das heißt,nicht für jede Test- oder Integrationsstufe existiert überhaupt eine 1:1zuordenbare Spezifikation. Daher müssen aus den Anforderungen abge-leitete Testfälle den Teststufen erst zugeordnet werden. Derlei Aspektewerden in dieser Arbeit allerdings nicht vertieft.

Es existieren vielerlei Testmethoden und -techniken, um bei einem Funk-tionstest systematisch und lückenlos vorzugehen. Hierbei steht die Ab-

2.1 modelltest 29

Abbildung 2: Entwicklungs- und Testprozess eingebetteter Systemeim Automobilbereich gemäß V-Modell

leitung der Testfälle im Vordergrund. Als Beispiel sei die Klassifika-tionsbaum-Methode von Grimm [51] genannt. Diese setzt auf eine syste-matische Analyse und Kategorisierung des zu testenden Aspekts. Conradentwickelte die Methode für den Test von eingebetteten System im Auto-mobilbereich weiter [28]. Trotz verschiedenster Vorgehensweisen bleibtdie Ableitung geeigneter Testfälle, beziehungsweise der Testdaten, meisteine manuell durchzuführende Aufgabe. Der Strukturtest, welcher imAnschluss an diesen Abschnitt ausführlich behandelt wird, spielt imVergleich zum Funktionstest in der Praxis eine untergeordnete Rolle.Dies liegt unter anderem daran, da er sich überhaupt nur in der unterenEbene des V-Modells anbietet (Modell oder Code). Das manuelle Ablei-ten der Testdaten ist beim Strukturtest allerdings ungemein schwerer alsbeim Funktionstest. Um nämlich in den Tiefen eines Programms oderModells einen bestimmten Zustand zu erreichen, gilt es, ausgehend vonden Eingängen vielfältige Abhängigkeiten, Strukturen und Berechnungs-schritte zu berücksichtigen. Daher ist insbesondere bei dieser Aktivitäteine Automatisierung besonders wertvoll.

Im Bemühen um eine Automatisierung setzt diese Arbeit ihren Fokus aufden Modelltest und nicht etwa, wie viele Arbeiten zuvor, auf den Testvon Code. Diese Fokussierung ist allerdings nicht mit dem Anspruchverbunden, der Modelltest könne den Test des Codes – selbst wenn die-ser automatisch generiert ist – in Gänze ablösen. Die Motivation bestehtvielmehr darin, Fehler in der Software eines eingebetteten Systems sonah wie möglich an ihrem Entstehungspunkt zu lokalisieren. Um Ab-weichungen zwischen Modell- und Codeverhalten festzustellen und umFehlverhalten zu erkennen, dass durch den konfigurierbaren Prozess derCodegenerierung entsteht, sind Tests des Codes weiterhin notwendig.Der bereits mehrfach erwähnte Industriestandard ISO 26262 verlangt eine

30 hintergrund

Betrachtung der Überdeckung bei Entwicklung und Test von Software-Modulen und weist explizit auf die Möglichkeit hin, diese Betrachtungbereits auf Modellebene führen zu können. Baresel et al. schlagen inihrer Studie zur Untersuchung von Zusammenhängen zwischen Code-und Modellüberdeckung [10] folgende Gestaltung des Testprozesses imunteren Teil des V-Modells vor:

1. Durchführung von Funktionstests auf Modellebene, um die kor-rekte Umsetzung der Anforderungen zu prüfen

2. Messung der erreichten Modellüberdeckung

3. Ableitung zusätzlicher Testfälle, um nicht-überdeckte Modellele-mente zu überdecken (Strukturtest), und Durchführung/Auswer-tung dieser zusätzlichen Tests

4. Ausführung der Testfälle aus Schritt 1 auf dem generierten Code,um auch hier die Konformität mit den Anforderungen zu prüfen

5. Messung der erreichten Codeüberdeckung (nur, falls eine hoheAbdeckung sowohl des Modells als auch des Codes gefragt ist)

6. Ableitung zusätzlicher Testfälle, um nicht-überdeckte Code-Ele-mente zu überdecken, und Durchführung/Auswertung dieser zu-sätzlichen Tests (ebenfalls nur, falls eine hohe Abdeckung sowohldes Modells als auch des Codes verlangt wird)

Diese Arbeit widmet sich insbesondere der Automatisierung des drittenSchritts. Wie im nächsten Abschnitt zu erfahren ist, können die Ansätzedieser Arbeit auch beim ersten Schritt unterstützen. Der entwickelteTool-Prototyp deckt darüber hinaus auch den zweiten Schritt ab. Für eineumfassende Auflistung anders gelagerter Forschungsarbeiten, welchesich mit der Qualitätssicherung von SL-Modellen beschäftigen, sei aufElberzhager et al. [37] verwiesen.

2.2 szenarien automatisiertertestdatengenerierung

Für den Modelltest gibt es verschiedene Szenarien, in denen eine auto-matisierte Generierung von Testdaten denkbar ist. Sadeghipour und Limhaben die möglichen Anwendungsfelder in einer Publikation [104] sehrtreffend herausgearbeitet:

• Strukturtests: Überdeckung von bei Funktionstests nicht überdeck-ten Modellelementen

2.2 szenarien automatisierter testdatengenerierung 31

• Funktionstests: (Teil-)Automatisierung bei der Ableitung von Test-fällen aus der Spezifikation, sofern ein Testorakel über das erwar-tete Modellverhalten existiert

• Entwicklungsbegleitende Tests: Erzeugung von Testdaten zur Über-prüfung eines ausgewählten Modellbestandteils während dessenEntwicklung

• Back-to-Back-Tests: Erzeugung von Testdaten für die Überprüfungder Äquivalenz von Modell und generiertem Code

Diese vier Bereiche werden in den nachfolgenden Abschnitten etwas nä-her beleuchtet. Der Strukturtest wird dabei bewusst intensiver behandelt,da er den Fokus dieser Arbeit darstellt. Allerdings wird auch gezeigt,dass die Problemstellung der strukturorientierten Testdatengenerierungdurchaus auf die Problemstellungen der drei anderen Bereiche über-tragbar ist – und der Strukturtest somit im Kontext dieser Arbeit alsrepräsentativer Anwendungsfall angesehen werden kann.

2.2.1 strukturtest

Der Strukturtest orientiert sich zur Herleitung von Testdaten an derinneren Struktur eines Testobjekts. Hintergrundgedanke ist, dass einTestobjekt nur dann als vollständig getestet gelten kann, wenn auch alleKommandos oder Verzweigungen im Inneren des Testobjekts durch Testsausgeführt oder beschritten wurden. Aus den Anforderungen abgeleiteteTestfälle erfüllen diese Maßgabe nicht zwingend. Nicht nur Baresel et al.[10] empfehlen daher, wie zuvor beschrieben, eine ergänzende Durchfüh-rung von Strukturtests. Auch Grimm [51] bezeichnet die Kombinationvon Funktionstest und Strukturtest als eine effektive Teststrategie.

Die Zielsetzung eines Strukturtests ist bestimmt durch die Wahl des ge-wünschten Überdeckungskriteriums. Der Strukturtest ist ein Verfahren,welches traditionell dem Test von Programmcode dient. In diesem Bereichwerden primär kontrollflussorientierte Überdeckungskriterien verwen-det – in wissenschaftlichen Arbeiten wie in der Praxis. Derlei Kriteriennutzen dabei folgende, vom Programmcode abstrahierende Strukturen:den Kontrollflussgraph (KFG) , wie er unter anderem von Liggesmeyer[82] behandelt wurde, oder den Programmablaufplan (PAP) , welcher auchFlowchart genannt wird und der in den Normen DIN 66001 und ISO 5807definiert ist. Ein wesentlicher Unterschied zwischen diesen beiden Dar-stellungsformen ist, dass Kontrollflussbedingungen in einem PAP explizitdargestellt sind. Während für Kriterien wie der Pfadüberdeckung, Anwei-sungsüberdeckung oder der Zweig- bzw. Entscheidungsüberdeckung (DC)die Betrachtung des KFG genügt, sind für die Bedingungsüberdeckung (CC)oder das Kriterium der Modified Condition/Decision Coverage (MC/DC, zu

32 hintergrund

Programmcode

1: if (a > b)2: x = 0;3: else4: x = 1;5: c = x+ 2;6: if (a==c || b>c)7: x = x− 1;8: return x;

Abbildung 3: Darstellung des Kontrollflusses eines Programmcode-Beispiels (links) als Kontrollflussgraph (mitte) und als Pro-grammablaufplan (rechts)

Deutsch: Modifizierte Bedingungs-/Entscheidungsüberdeckung) auchdie Kontrollflussbedingungen von Relevanz. Beide Formen der Darstel-lung werden in der Literatur im Kontext des Strukturtests dennochgrößtenteils synonym verwendet.

Abbildung 3 dient als Beispiel zum Verständnis des Strukturtests undseinen Überdeckungskriterien. Zu sehen sind ein Code-Fragment sowiedessen Kontrollfluss-Strukturen. Der PAP enthält sowohl die Bedingun-gen der Verzweigungen als auch die Anweisungen aus dem Code. ImKFG sind Bedingungen und Anweisungen hinter den entsprechendenCode-Zeilennummern verborgen. Wird nun die DC als Kriterium heran-gezogen, so gilt es, im KFG beispielsweise sowohl einmal von Knoten 1zu 4 (Entscheidung nein im PAP) als auch einmal von 1 zu 2 (Entschei-dung ja im PAP) überzugehen. Gesucht wären hierzu die Testdaten, alsoBelegungen für die Variablen a und b, welche diese Wege in KFG oderPAP beschreiten. Ein weiteres Beispiel: Um die CC für das gegebeneProgramm zu erfüllen, müssen alle Teilbedingungen der Bedingungen inVerzweigungen und Schleifen jeweils einmal mit wahr und einmal mitfalsch ausgewertet werden. Für Knoten 6 betrifft dies die Teilbedingungena==c und b>c, für Knoten 1 hingegen nur a>b. Insgesamt leiten sichfür die CC also sechs Ziele ab.

Wie im Beispiel ersichtlich, sind zur Erfüllung eines Überdeckungskrite-riums üblicherweise mehrere Strukturelemente oder Testobjekt-Zuständezu erreichen. Eine einzelne solche Zieldefinition wird in dieser Arbeit imAllgemeinen als Überdeckungsziel (CG, Plural: CGs) bezeichnet, wobeidie Abkürzung dem englischen Begriff Coverage Goal entstammt. Einekonkrete Belegung der Testobjekt-Eingänge wird als Testdatum bezeich-


net. Die bei einem Strukturtest entstehende Menge von Testdaten, welchegemeinsam möglichst viele CGs erreichen, wird in dieser Arbeit Test-suite genannt. Die Qualität einer Testsuite hinsichtlich der Erfüllungeines Überdeckungskriteriums wird durch den Überdeckungsgrad be-messen. Diese Arbeit folgt der Definition des Überdeckungsgrads vonBaluda et al. [9], da diese die potentielle Unerreichbarkeit einzelner CGsberücksichtigt:

Überdeckungsgrad =| Erreichte CGs |

| Gesamte CGs |− | Unerreichbare CGs |(13)

Die vollständige Erfüllung eines Überdeckungskriteriums ist dement-sprechend dem Erreichen des maximalen Überdeckungsgrads von 100%gleichzusetzen.

Die für die Code-Welt existierenden Strukturtest-Konzepte lassen sich aufdie Modell-Welt übertragen. Mögliche Überdeckungskriterien für SL/TL-Modelle [97, 114, 132] sind in Tabelle 3 aufgeführt. Für SF-Automatenexistieren zwei Automaten-typische Kriterien, die Transitions- und dieZustandsüberdeckung. Sowohl für SF als auch für den Blockdiagramm-Anteil eines SL/TL-Modells lassen sich die aus der Code-Welt bekann-ten Kriterien DC und CC sowie MC/DC anwenden. Für zwei spezi-elle Klassen von Blocktypen existieren darüber hinaus eigene Krite-rien. Für bedingte Subsysteme beispielsweise gibt es die Subsystem-Bedingungsüberdeckung (CSC) , welche die Aktivität eines jeden bedingten

Modellbestandteil Überdeckungskriterium Abkürzung

SL/TL

Entscheidungsüberdeckung DC

Bedingungsüberdeckung CC

Modifizierte Bedingungs-/Entscheidungsüberdeckung MC/DC

Lookup-Tabellen-Überdeckung LTC

Subsystem-Bedingungsüberdeckung

CSC

SF

Zustandsüberdeckung SC

Transitionsüberdeckung TC

Entscheidungsüberdeckung DC

Bedingungsüberdeckung CC

Tabelle 3: Modellüberdeckungskriterien für SL/TL-Block-diagramme sowie SF-Zustandsdiagramme

34 hintergrund

Subsystems im Modell, jeweils zu mindestens einem beliebigen Zeit-schritt, verlangt.

Während die zuvor genannten Code-Überdeckungskriterien stark stan-dardisiert sind, ist die Verwendung und Interpretation der gelistetenModell-Überdeckungskriterien noch stark werkzeugabhängig [29]. EinBeispiel: Gemäß der Dokumentation von SL ist ein Relational-Operator-Block nicht relevant für die DC. In dieser Arbeit wird dieser Blocktypallerdings bei der DC berücksichtigt, da er nach Ansicht des Autors eineEntscheidung impliziert. Darüber hinaus ist anzumerken: Die vorliegendeArbeit behandelt nur eine Auswahl der verfügbaren Überdeckungskri-terien. Diese sind in der Tabelle durch Fettdruck hervorgehoben. Dieentwickelten Techniken sind allerdings ebenso für die nicht behandeltenKriterien anwendbar. Einzig für die SF-spezifischen Kriterien ist eineErweiterung der Techniken vonnöten.

In der Anwendung des Strukturtests für SL/TL-Modelle besteht ein CGaus einem Ausdruck cg, der das zu erfüllende Ziel beschreibt. Ein solcherAusdruck stellt eine Bedingung an ein oder mehrere Modellsignal/-e. DieMenge E sei die Menge aller möglichen, für ein Modell definierbaren CGs.Der Bezeichner E steht hierbei für den englischen Begriff Expression (zuDeutsch: Ausdruck). Die folgenden Vorschriften definieren den Aufbaueines CG cg∈E:E =Elog ∪ Erel (14)

Die Menge Erel enthält vergleichende Ausdrücke zwischen Signalenund/oder Konstanten über relationale Operatoren. In Elog sind hingegenlogische Ausdrücke (Negation, Konjunktion, Disjunktion) über relationa-le Ausdrücke oder andere logische Ausdrücke enthalten.

Elog =

{n∧

i=1

ϕi,n∨

i=1

ϕi, ¬ϕ

}(15)

Erel = {ξ1=ξ2, ξ1 =ξ2, ξ1>ξ2, ξ1<ξ2, ξ1�ξ2, ξ1�ξ2}

Hierbei gilt n∈N�2 und ϕ,ϕi∈E. Mit ξ1 und ξ2 ist jeweils entweder einSignal (mit Vektorindex-Angabe) oder eine Konstante bezeichnet, dasheißt es gilt ξ1,ξ2∈L mit:

L = {sv | s∈S∧v∈N[1, d(s)]}∪ {c | c∈R} (16)

Für eine Erweiterung dieser Definition zur Berücksichtigung SF-relevanterÜberdeckungskriterien müssten unter anderem mathematische Operato-ren miteinbezogen werden.

In Tabelle 4 ist die Überdeckungsziel-Menge CG(b,k), die sich je nachÜberdeckungskriterium k für einen Modellblock b ableitet, für eineAuswahl der in SL/TL-Modellen verfügbaren Blocktypen gegeben. So


ist der Logical-Operator-Block sowohl für DC als auch CC relevant. FürDC ist erforderlich, dass jedes Vektorelement des ausgehenden Signalsjeweils einmal gleich 0 und einmal gleich 1 ist. Im Sinne der CC ist esnotwendig, dass jedes Vektorelement eines jeden Blockeingangs jeweilseinmal 0 und einmal ungleich 0 ist. Die Bedingung eines Relational-Operator-Blocks muss zur Erfüllung der DC ebenfalls einmal zutreffenund einmal nicht. Auch hier ist die Bedingung pro Vektorelement zuverstehen. Dies gilt ebenso für Switch- und Abs-Blöcke. Für den Switch-Block verlangt DC, dass die beiden Dateneingänge jeweils einmal zumBlockausgang geleitet werden. Ebenfalls für DC muss am Eingang einesAbs-Blocks einmal ein negativer und einmal ein nicht-negativer Wertvorliegen. Der Min/Max-Block muss zur Erfüllung der DC an jedemseiner Eingänge mindestens einmal den Minimal-/Maximalwert, den derBlock ausgibt, anliegen haben. Ein Enabled-Subsystem-Block muss inseinem Kontrollsignal einmal mindestens einen positiven Wert enthaltenund einmal muss das Gegenteil der Fall sein, um DC zu erfüllen. Für CSCgenügt das einmalige Vorliegen eines positiven Werts im Kontrollsignal.CC verlangt, dass jedes Vektorelement des Kontrollsignals jeweils einmalpositiv und einmal nicht-positiv ist.

BlocktypBT

Krit.k

ÜberdeckungszieleCG(b,k)

LogicalOperator

DC {〈sv=0〉, 〈sv=1〉 | s∈OSb ∧v∈N[1,d(s)]}

CC {〈sv �=0〉, 〈sv=0〉 | s∈ ISb ∧v∈N[1,d(s)]}

RelationalOperator

DC

⎧⎪⎪⎪⎪⎪⎪⎪⎨⎪⎪⎪⎪⎪⎪⎪⎩

˝svc(v,s1)1 •svc(v,s2)2

˛,˝

svc(v,s1)1 ◦svc(v,s2)2

˛| s1= sigin(b,1)

∧s2= sigin(b,2)

∧v∈N[1,maxdin(b)]

⎫⎪⎪⎪⎪⎪⎪⎪⎬⎪⎪⎪⎪⎪⎪⎪⎭

wobei ◦:=

⎧⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎨⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎩

�= ,•=„=“

= ,•=„�=“

� ,•=„>“

� ,•=„<“

< ,•=„�“

> ,•=„�“

Switch

DC

⎧⎪⎪⎪⎪⎨⎪⎪⎪⎪⎩

〈svc(v,s)•tmin(v,n)〉,〈svc(v,s)◦tmin(v,n)〉| s= sigin(b,2)

∧v∈N[1,max(n, d(s))]

⎫⎪⎪⎪⎪⎬⎪⎪⎪⎪⎭

wobei ◦:=

⎧⎪⎪⎪⎨⎪⎪⎪⎩� ,•=„>“

< ,•=„�“

= ,•=„�=“

Abs

DC {〈sv<0〉, 〈sv�0〉 | s∈ ISb ∧v∈N[1,d(s)]}

Tabelle 4: Überdeckungskriterien-relevante SL/TL-Blocktypen und diesich ableitenden Überdeckungsziele (Auszug)

36 hintergrund

BlocktypBT

Krit.k

ÜberdeckungszieleCG(b,k)

EnabledSubsystem

CSC

{ � ∨

v∈N[1, d(s)]

sv>0�| s= sigin(b,|IPb|)

}

DC

⎧⎪⎨⎪⎩

� ∨

v∈N[1, d(s)]

sv>0�,

� ∨

v∈N[1, d(s)]

sv�0�

| s= sigin(b,|IPb|)

⎫⎪⎬⎪⎭

CC

Voraussetzung: d(s)>1 für s= sigin(b,|IPb|){〈sv>0 〉, 〈sv�0 〉 | v∈N[1, d(s)]

}

Min/MaxDC

Fall 1: n>1:⎧⎪⎪⎪⎪⎪⎪⎪⎪⎨⎪⎪⎪⎪⎪⎪⎪⎪⎩

" ∧j∈N[1,i−1] ,s2= sigin(b,j)

svc(v,s)◦svc(v,s2)2

∧∧

k∈N[i+1,n] ,s3= sigin(b,k)

svc(v,s)�svc(v,s3)3

#| i∈N[1,n]∧s= sigin(b,i)∧v∈N[1,maxdin(b)]

⎫⎪⎪⎪⎪⎪⎪⎪⎪⎬⎪⎪⎪⎪⎪⎪⎪⎪⎭

Fall 2: n=1:⎧⎪⎪⎪⎪⎪⎨⎪⎪⎪⎪⎪⎩

� ∧v2∈N[1,v−1]

sv◦sv2

∧∧

v3∈N[v+1, d(s)]

sv�sv3

�| s= sigin(b,1)∧v∈N[1, d(s)]

⎫⎪⎪⎪⎪⎪⎬⎪⎪⎪⎪⎪⎭

wobei ◦ :=„<“, �:=„�“ für •=min

und ◦ :=„>“, �:=„�“ für •=max

Tabelle 4: Überdeckungskriterien-relevante SL/TL-Blocktypen und diesich ableitenden Überdeckungsziele (Auszug)

Die in der Tabelle enthaltenen Definitionen der Block-CGs vernachläs-sigen der Übersichtlichkeit halber ein Detail. Und zwar werden dieCG-Ausdrücke jeweils mit einem weiteren Ausdruck verundet, wenn sichder zugrunde liegende Block in der Modellhierarchie unterhalb bedingtausgeführter Subsysteme befindet. Ein CG-Ausdruck wird in diesemFall mit der oder den relevanten Aktivierungsbedingung/-en verknüpft.Denn ein CG kann selbstverständlich nur dann erfüllt sein, wenn diean ihm beteiligten Signale zum betrachteten Zeitschritt auch einen Wertenthalten. Hierzu ein Beispiel: Ein AND-Block mit dem Ausgangssignals1 befindet sich in einem Enabled Subsystem, welches das Signal s2an seinem für die Aktivierung und Deaktivierung relevanten Eingangbesitzt. Bezüglich des Kriteriums der Entscheidungsüberdeckung leitet


sich unter anderem das CG s1=1 ab. Dieses kann jedoch bei einer Mo-dellausführung nur dann erfüllt sein, wenn das Enabled Subsystem aktivist. Dies ist der Fall, wenn s2>0 eintritt. Daher wird das CG s1=1 umdiese Bedingung erweitert, das heißt das CG lautet s2>0∧s1=1.

In Ergänzung zu diesen Strukturtest-Grundlagen soll das Thema derVergleichbarkeit von Code- und Modell-Überdeckungskriterien an die-ser Stelle nicht unerwähnt bleiben. Baresel et al. [10] untersuchten denZusammenhang zwischen Code- und Modell-Überdeckungskriterien an-hand von SL-Modellen und dem aus diesen mit TL generierten Code. Be-trachtet wurden Bedingungs- und Entscheidungsüberdeckung. Die Auto-ren kamen zu dem Schluss, dass eine deutlich stärkere Wechselbeziehungbesteht als zuvor angenommen, wenn Modell und Code mit denselbenTestdaten ausgeführt werden. Auf Grundlage ihrer Ergebnisse wagten dieAutoren sogar die Schlussfolgerung, dass die Betrachtung von Modell-Überdeckungskriterien diejenige von Code-Überdeckungskriterien inZukunft möglicherweise sogar ablösen könnte. Diese Aussage ist aller-dings strikt auf den betrachteten Kontext der Verwendung von SL unddem Einsatz eines Codegenerators zu beziehen. Des Weiteren gebensowohl Baresel et al. als auch Kirner [74] zu bedenken, dass die Nähezwischen Modellüberdeckung und Codeüberdeckung letzten Endes starkvom betrachteten Codegenerator abhängt.

2.2.2 funktionstest

Der Funktionstest wurde in Abschnitt 2.1.3 bereits grundlegend einge-führt. Eine automatisierte Testdatengenerierung zum Zwecke funktio-naler Tests bedeutet in der Regel, automatisiert Testfälle oder Testdatenaus der dem Testobjekt zugrunde liegenden Spezifikation abzuleiten. BeiVerwendung natürlichsprachlicher Spezifikationsdokumente, wie es inder Automobilindustrie weitestgehend gang und gäbe ist, gestaltet sichdies sehr schwierig. Wird dennoch eine automatisierte Testdatengenerie-rung angestrebt, so greift man meist auf formalere Spezifikationsformenzurück. Die Verwendung von Zustandsautomaten (Testfallautomaten)ist hierbei eine weit verbreitete Form. Derlei sogenannte Testmodellebilden die Umgebung des Testobjekts hinsichtlich einer oder mehrererAnforderungen aus der Spezifikation ab. Oftmals spezifizieren sie aucherwartetes Testobjektverhalten. Aufgabe einer automatisierten Testdaten-generierung ist es in diesem Kontext, Testdaten aus einem Testmodellabzuleiten. Auch hierbei spielen Überdeckungskriterien eine Rolle. Sowäre es beispielsweise sinnvoll, sicherzustellen, dass alle Zustände oderTransitionen eines Testfallautomaten erreicht werden. Dieses Testvorge-hen fand bereits in Abschnitt 2.1 unter dem Begriff modellbasierter TestErwähnung.

38 hintergrund

Das in dieser Arbeit vorgestellte Automatisierungsverfahren ist aller-dings zu einer, zumindest in der Zielsetzung, anders gelagerten Art vonFunktionstests anwendbar. Hierbei geht es um die Frage, ob das Test-objekt, in diesem Fall ein SL/TL-Modell, möglicherweise Eigenschaftenverletzt, deren Einhaltung durch die Spezifikation verlangt wird oder diesich aus dieser ableiten lassen. Es gilt, Testdaten zu generieren, die beiAusführung des Testobjekts einen spezifizierten Fehlerfall provozieren.Derartige Testdaten lassen sich manuell meist nur mit hohem Aufwandfinden – insbesondere, weil ein solcher Negativtest vom Entwickler oderTester eine pessimistische Grundhaltung bezüglich der Korrektheit desTestobjekts verlangt. Bei diesem Anwendungsfall einer automatisiertenTestdatengenerierung stellt sich die Frage, wie der betrachtete Fehlerfalloder die zu verletzende Eigenschaft spezifiziert werden können odersollten. Eine Antwort auf diese Frage richtet sich vor allem nach demeingesetzten Automatisierungsverfahren. So ist es beispielsweise mög-lich, einen Fehlerfall durch eine Zielfunktion zu beschreiben, wie es beiVerwendung des in Abschnitt 2.4 vorgestellten suchbasierten Ansatzes inder Vergangenheit häufig gemacht wurde.

Eine andere Möglichkeit ist in Abbildung 4 beispielhaft veranschaulicht.Hierbei wird die zu verletzende Testobjekt-Eigenschaft modellbasiertformuliert. Denkbar ist, die Sprachmittel von SL und TL zur Definitioneiner Eigenschaft einzusetzen. Die Eingänge der Eigenschaftsdefinition

Abbildung 4: Automatisierte Testdatengenerierung mit dem Ziel der Pro-vokation der Verletzung einer aus der Spezifikation abge-leiteten, modellbasiert definierten Eigenschaft


enthalten dabei Referenzen auf interne Signale des zu testenden SL/TL-Modells. Sollen nun Testdaten generiert werden, welche zu einer Verlet-zung der in der Abbildung dargestellten Eigenschaft führen, so muss esdas Ziel sein, am Ausgang der modellbasierten Eigenschaftsdefinitionden Wert 0 (falsch) zu erreichen. Nun entspricht eine solche Zieldefinitionaus formaler Sicht der Definition eines Überdeckungsziels bei der struk-turorientierten Testdatengenerierung. Daher behandelt die vorliegendeArbeit den Strukturtest als stellvertretenden Anwendungsfall für dasentwickelte Automatisierungsverfahren. Dennoch empfehlen sich für dieZukunft Studien zur Einsetzbarkeit des Verfahrens zu Funktionstests.

2.2.3 entwicklungsbegleitender test

Der Test eines SL/TL-Modells, sei es in funktionaler oder in strukturorien-tierter Ausrichtung, ist zwar eine wichtige qualitätssichernde Maßnahme– allerdings ist es nicht die einzig Verfügbare. Neben der Durchführungvon statischen Analysen oder der Anwendung von Review-Technikensind es vor allem entwicklungsbegleitende Tests, welche für eine kor-rekte Funktionalität eines Modells sorgen. Arbeitet ein Entwickler aneinem Modell, so prüft er üblicherweise wichtige veränderte oder neuhinzugekommene Bestandteile direkt durch Simulationen des Modells indem SL-Werkzeug. Die hierzu verwendeten Eingangsdaten lassen sichdirekt im Modell durch verschiedene Blocktypen definieren, zum Beispielunter Verwendung des Signal-Builder-Blocks oder des Constant-Blocks.Handelt es sich allerdings um die Implementierung einer Teilfunktionali-tät innerhalb eines großen Modells, so ist es auch für einen Entwicklermanchmal nicht offensichtlich, wie die Eingangsdaten für das Modellauszusehen haben, damit das Modell einen gewünschten Zustand ein-nimmt. In diesem Fall stellt die automatisierte Testdatengenerierung einesinnvolle Hilfestellung dar. Das Testdatengenerierungsproblem, also dieArt der Zielstellung, ist dabei aus Sicht eines Automatisierungsverfahrensäquivalent zu dem des Funktionstests (siehe voriger Abschnitt).

2.2.4 back-to-back-test

In einem Back-to-Back-Test werden klassischerweise zwei Versionen ei-ner Programmierung gegeneinander getestet [124]. Im Rahmen einermodellbasierten Entwicklung werden Back-to-Back-Tests eingesetzt, umdie funktionale Äquivalenz von Modell und Programmcode zu überprü-fen. Diese Überprüfung erfolgt in der Regel durch einen Vergleich dervon beiden Testobjekten bei ihrer Ausführung mit denselben Testdatenausgegebenen Werten oder Signalen [104].

40 hintergrund

Wird eine Testsuite benötigt, welche zur Ausführung von Modell undCode verwendet wird, so bietet sich eine automatisierte Testdatengenerie-rung an. Beispielsweise könnte eine strukturorientiert generierte Testsuite,das heißt eine Menge von Testdaten mit hoher Modellüberdeckung, füreinen Back-to-Back-Test herangezogen werden. So gesehen stellt dieseArt des Testens keine zusätzliche Anforderung an das in dieser Arbeitbehandelte Testverfahren – es handelt sich lediglich um einen weite-ren Anwendungsfall für die durch einen automatisierten Strukturtesterzeugten Testdaten.

2.3 automatisierungsansätze

Die vorigen Abschnitte dieses Kapitels behandelten zum einen Software-test- sowie Praxis-Grundlagen und steckten zum anderen den in dieserArbeit betrachteten Anwendungsfall ab: Es geht um die Generierung vonTestdaten für ein SL/TL-Modell, wobei das Hauptaugenmerk dabei demModell-Strukturtest gilt. Die verbleibenden Abschnitte dieses Kapitelswidmen sich nun den für eine Testdatengenerierung existierenden Ansät-zen und Techniken. Auch hierbei erfolgt eine Fokussierung – und zwarauf den suchbasierten Ansatz. Dieser wird daher im Anschluss an denfolgenden Abschnitt ausführlich behandelt.

Die verschiedenen in der Literatur auffindbaren Techniken zur Testda-tengenerierung lassen sich grundsätzlich in drei Kategorien einteilen:statische, dynamische und hybride Techniken. Wie im einführendenKapitel beschrieben, führen dynamische Techniken das Testobjekt aus,wohingegen statische Techniken das Testobjekt entweder nur analysierenoder zumindest nur symbolisch ausführen. Hybride Techniken führendas Testobjekt unter Umständen ebenfalls aus, beinhalten allerdings auchstatisch arbeitende Komponenten. Im Folgenden werden Ansätze aus al-len drei Kategorien vorgestellt. Dabei handelt es sich primär um Ansätzein Anwendung für SL-Modelle, allerdings zum Teil auch um Arbeiten,welche die Testdatengenerierung für Programmcode behandeln. Einenim Vergleich hierzu deutlich allgemeineren Einblick in die verschiede-nen Methodiken zur Testdatengenerierung stellen Anand et al. [3] zurVerfügung.

2.3.1 statische testdatengenerierung

Im Bereich der statischen Testdatengenerierungsverfahren haben sich, so-wohl in der Anwendung für Programmcode als auch für SL/TL-Modelle,

2.3 automatisierungsansätze 41

zwei grundlegende Techniken hervorgetan: die symbolische Ausführungund das Model Checking.

symbolische ausführung

Anders als der Name der symbolischen Ausführung [72] suggeriert,wird ein Testobjekt durch das Verfahren nicht im eigentlichen Sinneausgeführt. Allerdings erfolgt eine statische Analyse des Testobjekts,welche einer abstrakten Ausführung gleichkommt. Diese Ausführungwird als symbolisch bezeichnet, weil die Eingangswerte und internenWerte des Testobjekts durch symbolische Werte repräsentiert werden. ImFalle der Anwendung für Programmcode wird durch die symbolischeAusführung eine Baumstruktur aufgebaut, welche die Ausführungslogikdes Programms abbildet. Verzweigungen im Code führen dabei zu Ver-zweigungen im Ausführungsbaum. Jeder Knoten im Baum referenzierteine Zeile im Code und enthält den Zustand der Programm-Variablenals symbolischen Ausdruck. Ein solcher Ausdruck bildet beispielsweisedie Berechnungsschritte innerhalb eines Programms ab. Des Weiterenbeinhaltet jeder Knoten eine sogenannte Pfadbedingung (englisch: pathconstraint) – eine aussagenlogische Formel – welche alle Bedingungen andie Eingänge des Programms beschreibt, die durch Testdaten erfüllt seinmüssen, um zu dieser Stelle im Code zu gelangen. Ist die Formel einerPfadbedingung unerfüllbar, das heißt existiert keine Variablenbelegung,welche die Formel wahr macht, so ist die referenzierte Zeile im Codenicht erreichbar. Die Prüfung der Unerfüllbarkeit und die Lösung derPfadbedingungen, also das Finden von erfüllenden Testdaten, erfolgt inder Regel mithilfe von Constraint Solvern oder verwandten Technikenund Werkzeugen.

Ein Großteil der Arbeiten zur symbolischen Ausführung beschäftigt sichmit der Anwendung der symbolischen Ausführung zur strukturorien-tierten Testdatengenerierung für verschiedenste Programmiersprachen.Anand et al. [3] bieten hierzu eine umfangreiche Übersicht an. Dabeistellen Anand et al. allerdings auch fest, dass die bisherigen Arbeiten diedrei großen Probleme der symbolischen Ausführung nur zum Teil lösenoder adressieren. Ein Problem besteht in der sogenannten Pfadexplosi-on (englisch: path explosion). Mit diesem Begriff wird eine ausuferndeAnzahl möglicher Programmpfade bezeichnet. Sowohl eine symbolischeAusführung als auch die Lösung von Pfadbedingungen gestaltet sichhierdurch sehr schwierig. Dies hat zur Folge, dass eine Testdatengenerie-rung mittels symbolischer Ausführung für viele reale, in der Praxisweltvorkommende Programme nicht in angemessener Zeit bewerkstelligtwerden kann. Ein weiteres Problem besteht in der Divergenz innerhalbvieler Programme. Oftmals sind Teile des Codes in anderen Sprachenimplementiert, ausgelagert oder stehen nur in binärer Form zur Verfü-gung. Dies erschwert oder verhindert eine vollständige Ableitung der

42 hintergrund

Pfadbedingungen. Problematisch sind zudem Pfadbedingungen, in de-nen nicht-lineare Operationen, wie Division und Multiplikation, oderandere mathematische Funktionen, beispielsweise die Sinus-Funktion,enthalten sind.

model checking

Während die symbolische Ausführung ein Verfahren ist, welches primärzum Zwecke der Testdatengenerierung geschaffen wurde, hat das ModelChecking einen anders gelagerten Hintergrund. Model Checking wirdnormalerweise dazu verwendet, um zu verifizieren, dass ein Modelloder Programm seine (formale) Spezifikation einhält. EntsprechendeWerkzeuge werden als Model Checker bezeichnet. Deren grundlegendeFunktionsweise haben Fraser und Wotawa [41] gut zusammengefasst:Ein Model Checker arbeitet üblicherweise mit einem Zustandsautomaten,welcher das Programm abbildet, und hat die Aufgabe, die Einhaltungoder Nicht-Einhaltung einer durch temporale Logiken spezifizierten Ei-genschaft durch den Automaten zu prüfen. Hierzu untersucht der ModelChecker den gesamten Zustandsraum des Automaten. Falls er eine Verlet-zung der Eigenschaft ausfindig machen kann, liefert er ein Gegenbeispiel.Dieses besteht bei den meisten aktuellen Model Checkern aus einer li-nearen Sequenz von Zuständen, die der Automat nacheinander auf demWeg zur Eigenschaftsverletzung einnehmen würde.

Wie aber lässt sich dieses Verfahren zur Testdatengenerierung einsetzen?Um dies zu erreichen, wird die Fähigkeit eines Model Checkers zurErzeugung von Gegenbeispielen ausgenutzt und zur Erzeugung vonTestdaten uminterpretiert [41]. Bezogen auf einen Strukturtest werdenim Testobjekt-Automaten sogenannte Trap-Variablen eingebaut, welchejeweils die Erfüllung eines Überdeckungsziels durch Einnahme eines be-stimmten Zustands oder durch Begehen einer bestimmten Transition imAutomaten anzeigen. Entsprechend ihrer deutschen Übersetzung bildendiese Trap-Variablen somit Fallen, in die der Model Checker tappen soll.Die durch den Model Checker je Überdeckungsziel zu prüfende Eigen-schaft verkörpert nämlich die Behauptung, dass das Überdeckungszielnicht erreichbar sei. Ist es doch erreichbar, so liefert der Model Checkerein Gegenbeispiel, aus dem sich die gesuchten Testdaten ableiten lassen.Fraser und Wotawa [41] haben sich in einer Publikation intensiv mit derAnwendung von Model Checkern zum Zwecke der Testdatengenerierungauseinandergesetzt. Hierbei führen sie eine ganze Reihe von Defizitenauf, welche dieser Ansatz mit sich bringt – insbesondere im Vergleichmit Verfahren, welche gezielt für den Zweck der Testdatengenerierungentwickelt wurden. Hierbei kommt vor allem das Problem der sogenann-ten Zustandsexplosion zur Sprache. Ähnlich der Pfadexplosion bei dersymbolischen Ausführung bezeichnet diese eine ausufernde Größe desZustandsraums, den ein Model Checker erschöpfend untersucht. Eine


Abstraktion innerhalb des Zustandsautomaten ist ein Weg, um diesesProblem zu lindern. Allerdings, so stellen Fraser und Wotawa fest, eig-nen sich die existierenden Abstrahierungskonzepte nicht, wenn ModelChecking zur Testdatengenerierung verwendet wird.

anwendung für simulink-modelle

Sowohl die symbolische Ausführung als das Model Checking wurden zurTestdatengenerierung für SL-Modelle oder SF-Automaten angewandt.

Hamon et al. [54, 56] setzen auf den zuvor beschriebenen Model-Checking-Ansatz, um neben der Durchführung eines klassischen Model Checkingsauch strukturorientiert Testdaten für SL-Modelle und SF-Automaten ge-nerieren zu können. Hierbei erfolgt eine Übersetzung der Modelle ineine für den verwendeten Model Checker verständliche Sprache (SAL).Die Autoren merken an, dass ihr Ansatz Einschränkungen bezüglich derUnterstützung von verschiedenen SL-Blocktypen macht. Beispielsweisewerden Blöcke mit nicht-linearen Operationen oder trigonometrischenFunktionen nicht unterstützt. Der Ansatz wurde in der Anwendungzur Testdatengenerierung für SF-Automaten mit Erfolg evaluiert, SL-Blockdiagramme wurden in den vorgestellten Fallbeispielen allerdingsnicht betrachtet.

Gadkari et al. verfolgen gemeinsam mit Mohalik et al. einen sehr ähn-lichen Ansatz [43, 44, 90]. Ihr mit AutoMOTGen bezeichneter Ansatzsetzt ebenfalls sowohl auf Model-Checking-Techniken als auch auf eineTransformation des Modells in die Sprache SAL. Die Autoren berücksich-tigen allerdings nur eine stark eingegrenzte Untermenge der verfügbarenSL-Blocktypen in ihrer Umsetzung. Zwei SL-Modelle aus dem Automo-bilbereich wurden in Fallstudien zur Evaluierung herangezogen unddie Ergebnisse mit denen eines kommerziellen Werkzeugs, welches aufeine zufallsbasierte Testdatengenerierung setzt, verglichen. Der Model-Checking-Ansatz führte zwar zu vielversprechenden Ergebnissen, dasheißt einer ähnlich hohen Modellüberdeckung wie das kommerzielleTool, allerdings sahen sich die Autoren auch mit den technischen Grenzenihres Ansatzes konfrontiert – vor allem bezüglich der Skalierbarkeit.

Weitere Arbeiten, in denen Model Checking zur Testdatengenerierungfür SL-Modelle zur Anwendung kommt, stammen von He et al. [64]und von Brillout et al. [21]. Diese beschäftigen sich allerdings mit derGenerierung von Tests im Rahmen von sogenannten Mutationstests undseien daher an dieser Stelle nur der Vollständigkeit halber genannt.

Die symbolische Ausführung wird in Arbeiten von Roy und Shankar[101, 102] sowie Pasareanu et al. [96] im Kontext von SL betrachtet. Royund Shankar verwenden SMT-Solving, um Testdaten für SL-Modelle zuerzeugen. Da ein Teil der vorliegenden Arbeit einen ähnlichen Ansatz

44 hintergrund

verfolgt, sei hier darauf verwiesen, dass das Thema SMT-Solving anspäterer Stelle eingehend behandelt wird. Die Arbeit von Roy und Shan-kar unterscheidet sich allerdings grundlegend bezüglich dreier Aspekte:Erstens liegt das Hauptaugenmerk der Autoren nicht in der struktu-rorientierten Testdatengenerierung, sondern in der Generierung vonTestdaten, die sogenannte Contracts, welche unter Berücksichtigung derSignaldatentypen zu gelten haben, verletzen. Mit dem Begriff Contractsbezeichnen die Autoren Aussagen über Beziehungen zwischen Signalen.Zweitens erörtert die Arbeit von Roy und Shankar nicht die Grenzen unddie Skalierbarkeit des vorgestellten Ansatzes. Drittens verwenden dieAutoren ausschließlich SMT-Solving zur Testdatengenerierung. In dervorliegenden Arbeit ist eine ähnliche Technik aber Teil eines hybridenAnsatzes.

Pasareanu et al. generieren Testdaten für SL ebenfalls mittels symboli-scher Ausführung. Allerdings übersetzen sie ein Modell zuerst in einemit der Programmiersprache Java beschriebenen Repräsentation undnutzen dann ihr Werkzeug Symbolic PathFinder zur Testdatengenerierung.Dieses Werkzeug führt die symbolische Ausführung auf Java-Byte-Code-Ebene durch und verwendet Constraint Solver, um Testdaten aus denPfadbedingungen abzuleiten. Unklar ist, in welchem Zusammenhangdie hierdurch erzielte Codeüberdeckung mit der in der vorliegendenArbeit betrachteten Modellüberdeckung steht. Die Autoren berichten desWeiteren von Skalierungsproblemen ihres Ansatzes.

Zusammenfassend bleibt festzustellen, dass die Unterstützung aller inSL/TL-Modellen relevanten Funktionalitäten und die Skalierbarkeit mitsteigender Modellgröße entscheidende Hürden für eine rein statischeTestdatengenerierung darstellen. Hinzu kommt, wie Kanade et al. [70]treffend feststellen, dass das Fehlen einer klar spezifizierten Semantikfür SL (siehe Abschnitt 2.1.2) die Konstruktion formaler Werkzeuge er-schwert. In der vorliegenden Arbeit werden dennoch statische Technikenbehandelt und eingesetzt. Grund hierfür ist, dass statische Technikenauch ihre Vorteile haben. So können sie allgemeingültige Aussagen tref-fen und arbeiten oftmals schneller als entsprechende dynamische Tech-niken. Allerdings sind die statischen Techniken dieser Arbeit stets alsErgänzung einer dynamischen Testdatengenerierung anzusehen. Dasdynamische Verfahren funktioniert auch dann, wenn eine der statischenTechniken an ihre Grenzen stößt. Ergänzend ist zu erwähnen, dass keineder aufgeführten Arbeiten die Plausibilität der generierten Testdatenberücksichtigt. Dies bedeutet, dass nicht sichergestellt wird, dass diegenerierten Testdaten – welches im Falle von SL/TL-Modellen Signalesein sollten – gewisse Anforderungen an ihre Form (wie beispielsweisedie Signalcharakteristik) erfüllen. In der Praxis könnten derlei Testdatenunbrauchbar sein, weil sie keine realistischen Szenarien abbilden.


2.3.2 dynamische testdatengenerierung

In der Kategorie dynamische Testdatengenerierung sind im Wesentlichender Zufallstest und der suchbasierte Test zu nennen. Diese beiden Ansät-ze werden im Folgenden behandelt, insbesondere in ihrer Anwendungfür SL/TL-Modelle.

zufallstest

Die Testdatengenerierung durch verschiedenste Formen einer zufälligenBestimmung oder Auswahl von Testdaten ist seit den frühen 1960er Jah-ren [99] und auch in aktuellen Arbeiten ein Thema in der Forschung. Inseiner Reinform werden bei einem Zufallstest so lange zufällig Testdatengeneriert und das Testobjekt mit diesen ausgeführt, bis die gewünschtenTestdaten, beispielsweise zum Erreichen aller Überdeckungsziele einesStrukturtests, gefunden wurden – oder die zufällige Generierung an-derweitig abgebrochen wird. Die Testdaten werden dabei üblicherweisemit einer einheitlichen Wahrscheinlichkeit p aus dem EingabedatenraumD des Testobjekts zufällig gewählt, das heißt für jedes Testdatum gilt:p = 1/|D| [4].

Selbst kommerzielle Werkzeuge zur Testdatengenerierung setzen, wie inAbschnitt 2.3.4 ersichtlich wird, auf diesen simplen Ansatz. Die Gründehierfür sind naheliegend, wie Chen et al. [24] feststellen: Der Zufallstestist leicht zu verstehen, kann in der Regel einfach implementiert werden,hat in vielen Arbeiten unter Beweis gestellt, dass er Fehler aufdeckenkann, und ist möglicherweise gerade deswegen so beliebt, weil er dasTestobjekt auch mit eher ungewöhnlichen Szenarien konfrontiert – aufdie ein Tester gar nicht erst kommen würde. Arcuri et al. stellen fest,dass der Zufallstest in vielen Anwendungsfällen ein brauchbares Mittelzur Testdatengenerierung darstellt [6]. Insbesondere dann, wenn ande-re Testdatengenerierungstechniken nicht ausreichend gut skalieren, hatder Zufallstest Vorteile [5]. Daher wird der Zufallstest auch gerne inhybriden Ansätzen zur Testdatengenerierung verwendet, wie der fol-gende Abschnitt 2.3.3 zeigt. Es zeigt sich allerdings häufig, dass einreiner Zufallstest ineffizient ist, da keinerlei Versuch unternommen wird,die Generierung der Testdaten in irgendeiner Art und Weise mithilfevon Informationen über das Testobjekt zu steuern [24]. Daher wird derZufallstest auch gerne zum Vergleich herangezogen, wenn es gilt, einanderes Testdatengenerierungsverfahren zu untersuchen.

In den letzten Jahren hat sich eine Reihe von Arbeiten mit einer Variationdes Zufallstests beschäftigt: dem sogenannten adaptiven Zufallstest (ART,englisch: adaptive random testing) [24]. Die grundlegende Idee des ARTbesteht darin, eine stärkere Verteilung der generierten Testdaten imEingabedatenraum anzustreben. Befinden sich generierte Testdaten in

46 hintergrund

ähnlichen Regionen des Eingabedatenraums und sind diese Testdatennicht die Gesuchten, so wird bei der Erzeugung weiterer Testdatendarauf geachtet, dass diese im Eingabedatenraum weit von dieser Regionentfernt sind. Wie weit, hängt von dem betrachteten Anwendungsfallund dem Testobjekt ab [4]. In einer groß angelegten Studie [4] stellenArcuri und Briand allerdings fest, dass ART nur geringfügig effizienterund effektiver als ein klassischer Zufallstest ist. Die Autoren zeigen sichangesichts der hohen Anzahl an Arbeiten bezüglich ART sehr überraschtob der ernüchternden Ergebnisse.

suchbasierter test

Die Anfänge des suchbasierten Tests reichen bis in die 1970er Jahre zu-rück. Im Jahre 1976 hatten Miller und Spooner [89] die Idee, Testdaten zugenerieren, die einen bestimmten Programmpfad zur Ausführung brin-gen, indem erzeugte Testdaten innerhalb eines simplen Optimierungspro-zesses mithilfe einer Kostenfunktion bewertet werden. Testdaten, welcheder Ausführung des gewünschten Pfades näher kamen, bekamen durchdie Kostenfunktion (im Folgenden als Fitnessfunktion bezeichnet) einenniedrigen Wert zugewiesen und dienten der Optimierung zur Erzeugungweiterer Testdaten. Testdaten mit hohen „Kosten“ wurden hingegen ver-worfen. Erst Anfang der 1990er Jahre wurde dieser Ansatz von Korel [76]wieder aufgegriffen und erfährt seit Mitte der 1990er Jahre eine steigendeBeachtung in der Forschung [83].

Heute wie damals ist der suchbasierte Test durch den Einsatz von meta-heuristischen Algorithmen gekennzeichnet [59, 83]. Dies sind Optimie-rungsalgorithmen, welche aus abstrakten Schritten bestehen und somitgrundsätzlich für jedes beliebige Optimierungsproblem anwendbar sind.Kern der meisten metaheuristischen Algorithmen ist die Bewertung ge-nerierter Lösungsvorschläge durch eine Fitnessfunktion. Diese hat dieAufgabe, gute Lösungsvorschläge von schlechten Lösungsvorschlägenzahlenmäßig zu unterscheiden und leitet die Suche somit im Idealfallzum gewünschten Ziel. Die verschiedenen existierenden Algorithmen,wie beispielsweise der Bergsteigeralgorithmus oder der genetische Algo-rithmus, unterscheiden sich imWesentlichen in der Art undWeise, wie sievon bereits generierten Lösungsvorschlägen zu neuen Lösungsvorschlä-gen gelangen. Im Kontext des Tests stellen die Lösungsvorschläge dieTestdaten dar. Als Strukturtest interpretiert, sucht ein metaheuristischerAlgorithmus nach Testdaten, die eines oder mehrere Überdeckungszieleerfüllen [120–122, 126, 127]. Die jeweilige Fitnessfunktion lässt sich dabeiautomatisch aus der inneren Struktur des Testobjekts ableiten [126].



Die Zahl der Arbeiten, die sich mit einer Anwendung des Zufallstestsoder des suchbasierten Tests für SL-Modelle beschäftigen, ist noch relativüberschaubar. Die existierenden Arbeiten zum suchbasierten Test behan-delt dennoch nicht nur den Strukturtest, sondern auch den Funktionstestund sogar den Mutationstest. Der Zufallstest wurde, zumindest in derForschung, zwar des Öfteren für den Modelltest angewandt, allerdingsprimär zu Vergleichszwecken. Das Konzept des adaptiven Zufallstests istnoch nicht in der SL-Welt angewandt worden.

Im Bereich des Funktionstests verwenden Boström und Björkqvist [20]sowie Vos et al. [123] einen suchbasierten Ansatz, um Spezifikationsver-letzungen innerhalb von SL-Modellen ausfindig zu machen. WährendBoström und Björkqvist die durch das Modell einzuhaltenden Anfor-derungen mittels sogenannter Assertions ausdrücken und aus diesenjeweils automatisch die benötigte Fitnessfunktion ableiten, setzen Voset al. auf eine direkte Definition der Fitnessfunktion. Der Ansatz vonBoström und Björkqvist ist im Übrigen eng verwandt mit der Interpretati-on des Funktionstests in der vorliegenden Arbeit. Im Unterschied zu demAnsatz der Beiden schlägt diese Arbeit allerdings, wie in Abschnitt 2.2.2beschrieben, eine Formulierung von Assertions mit den Sprachmittelnvon SL/TL vor.

Windisch [132] sowie Zhan und Clark [135, 137] wenden den suchbasier-ten Test zur strukturorientierten Testdatengenerierung für SL-Modelle an.Während Zhan und Clark hierbei lediglich die grundsätzliche Anwend-barkeit behandeln und sich ansonsten auf den Einsatz zu Mutationstestskonzentrieren, widmet sich die Arbeit von Windisch primär der Anwend-barkeit in der Praxis. Hierzu entwickelte er gemeinsam mit Al Moubayedeine Abstraktionstechnik, welche die Generierung plausibler Signaleermöglicht [133]. Ebenfalls im Sinne einer Plausibilität der erzeugtenTestdaten ist eine ergänzende Arbeit von Wilmes und Windisch zu sehen[130]. Diese behandelt die Berücksichtigung zusätzlicher Bedingungeninnerhalb der Testdatensuche. Dabei handelt es sich um temporal-logischspezifizierte Bedingungen, welche für die zu generierenden Signale zugelten haben. Des Weiteren berücksichtigt der Ansatz von Windisch auchdie strukturorientierte Testdatengenerierung für SF-Automaten [131]. Indiesem Zusammenhang stellen Oh et al. im Übrigen einen speziellengenetischen Algorithmus vor, der die Transitionsüberdeckung von SF-Automaten adressiert [94]. Zu guter Letzt seien Ghani und Clark genannt,welche die Arbeit von Zhan und Clark zum suchbasierten Mutations-test um dynamische Fitnessfunktionen ergänzen [47]. Hierbei wird dieZieldefinition einer Suche bewusst manipuliert, um der Suche die An-näherung an das eigentliche Suchziel zu erleichtern. Zhan und Clarkerweitern ihren Ansatz des Weiteren selbst um eine statische Analysedes betrachteten SL-Modells zur Bestimmung einer geeigneten Länge der

48 hintergrund

Signale, welche die Testdaten darstellen und die es demnach zu erzeugengilt [136].

Sowohl Windisch als auch Zhan und Clark vergleichen ihre Ansätze mitdem Zufallstest [132, 135, 137]. Hierbei liefert der suchbasierte Ansatzdurchweg bessere Ergebnisse. Besser bedeutet in diesem Zusammen-hang, dass der suchbasierte Strukturtest in Anwendung für SL-Modelleeine höhere Modellüberdeckung mit geringerem Aufwand erzielt. DerAufwand bemisst sich dabei in der Anzahl generierter Testdaten undModellausführungen. Diese Beobachtungen bestätigen Ergebnisse, dieim Bereich des suchbasierten Strukturtests von Programmcode erzieltwurden – beispielsweise durch Wegener et al. [127].

Windisch evaluierte seinen Ansatz anhand von realen Modellen ausder automobilen Entwicklung. Stellt man den suchbasierten Test in die-sem Zusammenhang den statischen Ansätzen gegenüber, so ist unab-hängig von der Anwendbarkeit rein statisch operierender Testdatenge-nerierungsverfahren festzustellen, dass der suchbasierte Ansatz zwarkeinerlei Einschränkungen hinsichtlich Blockunterstützung oder Modell-größe hinnehmen muss – allerdings ist die Effizienz des Verfahrens nochverbesserungswürdig.

2.3.3 hybride testdatengenerierung

Die Beiträge der vorliegenden Arbeit sind nicht die Ersten, welche derGrundidee der Kombination verschiedener Techniken folgen. So existierteine Vielzahl an Arbeiten, die sich mit einer Verzahnung von symbo-lischer Ausführung und Zufallstest auseinandersetzen. Zudem gibt eserste Impulse, die sich um eine Nutzung suchbasierter Techniken in-nerhalb dieser Kombination bemühen. Derlei Arbeiten und in diesemBereich unternommene Anwendungsversuche zur Testdatengenerierungfür SL werden in diesem Abschnitt behandelt.

hybride ansätze

Die erwähnte Kombination von symbolischer Ausführung und Zufalls-test zum Zwecke einer strukturorientierten Testdatengenerierung hat ihreUrsprünge in zwei parallel zueinander entstandenen Arbeiten. WährendGodefroid et al. [49] die Technik als dynamische symbolische Ausführungund ihr dazu entstandenes Werkzeug mit dem Namen DART bezeichnen,nennen Sen et al. [109] die Technik Concolic Testing und ihr WerkzeugCUTE. Der Begriff Concolic beschreibt hierbei, dass es in dem Verfahrensowohl zu einer konkreten (englisch: concrete) als auch zu einer symbo-lischen (englisch: symbolic) Ausführung des Testobjekts kommt. Beide


Begriffe haben sich in der Literatur gehalten, in den folgenden Ausfüh-rungen verwendet diese Arbeit jedoch den Begriff Concolic Testing.

Die grundlegende Idee beider Ansätze besteht in der tatsächlichen Aus-führung eines Testobjekts (in diesem Fall C-Code), falls eine Testdatenge-nerierung durch Constraint Solving bei der symbolischen Ausführungnicht möglich ist. In Abschnitt 2.3.1 wurde erklärt, dass die Bildungvon Pfadbedingungen oder das Ableiten von Testdaten aus diesen inverschiedenen Situationen entweder nicht möglich oder nur schwer zubewerkstelligen ist. Dies ist beispielsweise der Fall, wenn der zur Ablei-tung der Testdaten verwendete Constraint Solver mit einem Ausdruck inder Pfadbedingung nicht umgehen kann. In einem solchen Fall wird dasTestobjekt beim Concolic Testing mit zufällig generierten Testdaten aus-geführt. Anschließend werden Variablen des problematischen Ausdrucksin der Pfadbedingung zum Teil mit Werten ersetzt, die bei der realenAusführung entstanden sind. Handelt es sich zum Beispiel um die Multi-plikation zweier Variablen, so würde ein Multiplikand durch einen Wertersetzt werden. Der verwendete Constraint Solver wäre nun in der Lage,auch mit diesem Ausdruck umzugehen. Da die symbolische Ausführungdurch das Einsetzen konkreter Werte in die Pfadbedingungen allerdingspunktuell ihren verallgemeinernden Charakter verliert, beinhaltet dasConcolic Testing die Möglichkeit eines Backtrackings. Für eine detaillierteEinführung dieser Technik sei auf die Arbeiten von Godefroid et al. [49]und Sen et al. [109] verwiesen.

Lakhotia et al. vergleicht in einer umfangreichen Fallstudie den suchba-sierten Test und das Concolic Testing [77, 78]. Hierbei betrachtet er diestrukturorientierte Testdatengenerierung für C-Code mit dem WerkzeugCUTE und einem eigenen suchbasierten Testwerkzeug namens AUSTIN.Zusammenfassend betrachtet bringt die Studie keinen eindeutigen Sie-ger hervor. Beide Verfahren oder Werkzeuge hatten zum Zeitpunkt derDurchführung der Studie mit technischen Problemen im Umgang mitden verwendeten Testobjekten zu kämpfen. Im Schnitt arbeitete CUTEzwar etwas effizienter als AUSTIN, bezüglich des erreichten Überde-ckungsgrads gab es jedoch gleichermaßen Fälle, in denen das ConcolicTesting oder der suchbasierte Test bessere Ergebnisse erzielten.

In einer weiteren Arbeit ergänzen Lakhotia et al. das Testwerkzeug Pex[100] von Microsoft um eine suchbasierte Testdatengenerierung [79].Pex ist eine Erweiterung der Entwicklungsumgebung Visual Studio undkann zur strukturorientierten Testdatengenerierung für .NET-Programmeeingesetzt werden. Pex verwendet hierzu das Concolic Testing. Lakhotiaet al. betrachten das Problem von Fließkommazahl-Berechnungen in einerPfadbedingung. Diese sind für den in Pex verwendeten Constraint Solverproblematisch. Kommt in diesem Spezialfall statt Constraint Solvingeine metaheuristische Suche zum Einsatz, so kann die Effektivität derTestdatengenerierung deutlich gesteigert werden, wie die Ergebnisse

50 hintergrund

einer dazugehörigen Fallstudie zeigen. Diesem Vorteil stehen allerdingsdeutlich längere Laufzeiten gegenüber.

Inkumsah und Xie befassen sich ebenfalls mit einer Kombination dessuchbasierten Tests und des Concolic Testing [68]. Ihr Framework EVA-CON dient dabei der strukturorientierten Testdatengenerierung für mitJava geschriebenen objektorientierten Code. EVACON greift auf zweiandere Werkzeuge zurück: das suchbasierte Testwerkzeug eToc [118] undjCUTE [108], eine Implementierung von CUTE für Java-Code. WährendEVACON das suchbasierte Werkzeug einsetzt, um Sequenzen von Me-thodenaufrufen zu generieren, wird jCUTE genutzt, um in Ergänzunghierzu Werte für die Methodenparameter zu ermitteln.


Zwei Ansätze einer hybriden Testdatengenerierung für SL-Modelle lassensich in der Literatur aktuell finden.

Satpathy et al. übertragen die Idee des Concolic Testing auf die Modelle-bene [105]. Ihr Verfahren namens REDIRECT nutzt hierbei einen SMT-Solver zur Lösung der Pfadbedingungen. Zusätzlich wendet REDIRECTeine Reihe von Heuristiken an, um mit nicht-linearen Blöcken umgehenzu können. Allerdings fokussieren sich die Autoren in ihrer Veröffent-lichung auf SF-Automaten und betrachten den Blockdiagramm-Anteileines SL-Modells nur am Rande. In Fallbeispielen generiert REDIRECTTestdaten mit einer höheren Transitions- und Zustandsüberdeckung alsein kommerzielles Werkzeug. Bei den Anwendungsbeispielen handelt essich jedoch um relativ kleine SF-Automaten. Darüber hinaus beinhaltetder Ansatz keinerlei Konzepte zur Gewährleistung einer Plausibilität dergenerierten Testdaten.

Peranandam et al. [95] stellen einen Ansatz vor, der ähnlich wie ein Bei-trag der vorliegenden Arbeit ausgerichtet ist. In ihrem mit dem NamenSmartTestGen bezeichneten Verfahren kommen sowohl Zufallstest alsauch symbolische Ausführung, Model Checking und eigene Heuristikenzur Testdatengenerierung zum Einsatz. Die verschiedenen Technikenoperieren dabei nicht ineinander verzahnt, sondern es erfolgt je Überde-ckungsziel eine statische Auswahl der mutmaßlich erfolgversprechends-ten Technik. Über die Auswahlkriterien oder -regeln verraten die Autorenallerdings nicht viel, es ist von Regeln die Rede, die auf Erfahrungswertenbasieren. Fallstudien belegen, dass der SmartTestGen-Ansatz im Schnitteine höhere Modellüberdeckung als ein kommerzielles Werkzeug erzielt.Die Autoren schließen daraus, dass der Fall-spezifische Einsatz verschie-dener Testdatengenerierungsverfahren ein geeigneter Ansatz ist, um derVielfältigkeit und Komplexität in industriellen SL-Modellen zu begegnen.Die Plausibilität der Testdaten ist in ihrer Arbeit ebenfalls kein Thema.


Wie zu sehen ist, setzen existierende hybride Ansätze vornehmlich aufden Zufallstest als dynamische Komponente, um Limitierungen verwen-deter statischer Techniken zu überwinden. Die vorliegende Arbeit vertrittin diesem Zusammenhang eine umgekehrte Sichtweise: Sie verwendetstatische Techniken in erster Linie, um Schwächen der dynamischenKomponente zu kompensieren. Vergleicht man des Weiteren die Funk-tionsweise eines Zufallstest mit der eines suchbasierten Tests, so istfestzustellen, dass der suchbasierte Ansatz eine verbesserte Form des Zu-fallstests darstellt. Auch beim suchbasierten Test spielt der Zufall in derErzeugung der Testdaten eine entscheidende Rolle. Die Erzeugung erfolgtjedoch nicht vollständig zufällig, sondern erfährt durch die Bewertungder Testdaten eine Führung zum betrachteten Ziel. Dies ist ein Grund,wieso die vorliegende Arbeit im Bemühen um eine Hybridisierung densuchbasierten Ansatz aufgreift. Hinzu kommt, dass dieser Ansatz bereitssehr stark an die Bedürfnisse der industriellen Praxis angepasst ist –unter anderem durch die Arbeiten von Windisch [130–133].

2.3.4 kommerzielle werkzeuge

Neben den in der Literatur dokumentierten Arbeiten darf nicht verges-sen werden, dass es auch kommerzielle Werkzeuge gibt, die sich zurstrukturorientierten Testdatengenerierung für SL/TL-Modelle einsetzenlassen. Die Mehrheit dieser Werkzeuge generiert allerdings Testdatenzur strukturellen Überdeckung des aus dem Modell generierten Codes.Modellüberdeckungskriterien, wie in Abschnitt 2.2.1 vorgestellt, betrach-tet neben dem Werkzeug Reactis [97] der Firma Reactive Systems auchder Simulink Design Verifier [116] von ML/SL-Hersteller The MathWorks.Reactis wurde unter anderem von Windisch in Fallstudien zum Vergleichdes eigenen Testdatengenerierungsansatzes herangezogen. Hierbei konn-te der suchbasierte Ansatz von Windisch, wie zuvor bereits geschildert,einen höheren Modellüberdeckungsgrad erzielen [132].

Über die Techniken, welche Reactis und der Simulink Design Verifier zurTestdatengenerierung einsetzen, ist öffentlich nicht allzu viel bekannt.Während Reactis grundlegend auf den Zufallstest setzt und diesen umsogenannte „gesteuerte Simulationen“ ergänzt, verwendet der SimulinkDesign Verifier sowohl Model-Checking- als auch Constraint-Solving-Techniken.

52 hintergrund

2.4 suchbasierter ansatz

Aufbauend auf der Einführung des suchbasierten Tests in Abschnitt 2.3.2vertieft dieser Abschnitt das dort geschilderte Grundprinzip. Darüber hin-aus wird der Ansatz zum suchbasierten Strukturtest für SL von Windischetwas detaillierter als zuvor vorgestellt, da die Beiträge der vorliegendenArbeit hierauf aufsetzen.

2.4.1 lokale, globale und hybride suche

Zur Durchführung eines suchbasierten Tests kann grundsätzlich ein belie-biger metaheuristischer Optimierungsalgorithmus zum Einsatz kommen.Im Folgenden werden solche Algorithmen auch als Suchverfahren oderschlicht als Suche bezeichnet. Die vielfältige Welt der Suchverfahren lässtsich in drei Kategorien unterteilen: lokale, globale und hybride Such-verfahren. Um diese Unterscheidung erklären zu können, empfiehlt essich, zuerst einen Blick auf die Relevanz der Fitnessfunktion zu werfen.Eine Fitnessfunktion bewertet die von einem Suchverfahren generiertenLösungsvorschläge und hilft hierdurch wiederum dem Suchverfahren,denn das Suchverfahren kann nun ermitteln, in welche Regionen desSuchraums es als Nächstes steuert. Bildlich betrachtet spannt die Fitness-funktion über dem Suchraum, also dem Raum aller möglichen Lösungs-vorschläge, eine sogenannte Fitnesslandschaft auf. Die Fitnesslandschaftkann lokale und globale Optima enthalten. Betrachtet man dies wieder-um bildlich, so stellen lokale Optima Hügel beliebiger Größe dar. EinOptimum wird dann als global angesehen, wenn es den höchsten Hügelin der gesamten Fitnesslandschaft darstellt. Vor diesem Hintergrund de-finieren Harman und McMinn [59] die Klassifikation der Suchverfahrenwie folgt: Eine globale Suche (GS) ist darauf spezialisiert, trotz möglicherAnkunft in lokalen Optima dennoch das globale Optimum im Suchraumzu finden. Eine lokale Suche (LS) hingegen nimmt in Kauf, in lokalen Opti-ma zu verharren und somit nicht das globale Optimum zu finden. Eine LSnavigiert zu jedem Zeitpunkt des Suchvorgangs im Suchraum üblicher-weise nur von einem Punkt (Lösungsvorschlag) aus. Eine GS hingegenbetrachtet zu jedem Zeitpunkt des Suchvorgangs klassischerweise eineVielzahl an Lösungsvorschlägen [83]. Daher gelten lokale Suchverfahrenim Allgemeinen als effizienter, sofern sich ein Suchproblem mit ihnenlösen lässt. Eine GS findet allerdings häufiger Anwendung, da sie imAllgemeinen besser mit verschiedenartigen Fitnesslandschaften umgehenkann und somit Problem-unabhängiger ist [59]. Hybride Suchverfahrenkombinieren LS und GS.

Abbildung 5 stellt die grundlegende Funktionsweise eines suchbasier-ten Tests dar. Die Darstellung ist einerseits unabhängig vom tatsächlich

2.4 suchbasierter ansatz 53

Abbildung 5: Ablauf eines suchbasierten Tests im Allgemeinen mit demEinsatz eines genetischen Algorithmus zu Optimierungs-zwecken als Beispiel für eine mögliche Ausprägung (inAnlehnung an Windisch [132])

verwendeten Suchverfahren gehalten, enthält andererseits aber auch alsBeispiel die speziellen Schritte eines genetischen Algorithmus als Beispieleines Suchverfahrens. Ein genetischer Algorithmus realisiert eine GS.Die Anwendung eines Suchverfahrens zu Zwecken einer Testdatengene-rierung macht es häufig notwendig, die Testdaten innerhalb der Opti-mierung (unterer Kreislauf in der Abbildung) in einer kodierten Formzu betrachten. Enthält ein Testdatum beispielsweise eine Zeichenkette,so müsste das Suchverfahren in der Lage sein, einerseits Zeichenkettenzu generieren und diese andererseits gemäß seiner spezifischen Ände-rungsoperatoren zu variieren. Ist ein Suchverfahren allerdings nur aufden Umgang mit Zahlenwerten ausgerichtet, so bietet es sich an, eineentsprechende Kodierung für Zeichenketten zu verwenden. Natürlichist es auch möglich, die Operatoren des Suchverfahrens für den direk-ten Umgang mit Zeichenketten anzupassen. Unabhängig hiervon gilt

54 hintergrund

es, eine Repräsentation eines Testdatums zu definieren, welche mit denOperatoren des Suchverfahrens kompatibel ist.

Zurück zu der Darstellung: Ein suchbasierter Test beginnt mit der, in derRegel zufälligen, Erzeugung eines initialen Testdatums oder einer Mengeinitialer Testdaten – je nachdem, ob eine LS oder GS verwendet wird.Anschließend erfolgt eine Bewertung der Testdaten. Bevor allerdings dieFitnessfunktion die Nähe der Testdaten zum betrachteten Ziel bemessenkann, wird das Testobjekt in der Regel mit den Testdaten ausgeführt.Vor einer jeden Ausführung werden die kodierten Testdaten dekodiert.Während oder nach einer Ausführung werden Daten, die Grundlageder Bewertung durch die Fitnessfunktion darstellen, gesammelt – wiebeispielsweise die Ausgaben des Testobjekts. Liegen letzten Endes dieBewertungen vor, werden Abbruchkriterien geprüft. Diese sind von An-wendungsfall zu Anwendungsfall verschieden. So kann das Ziel derSuche darin bestehen, dass ein bestimmter Fitness-Schwellwert über-oder unterschritten wird. Des Weiteren ist häufig eine Obergrenze anOptimierungsiterationen definiert, damit eine Suche auch bei Misserfolgendet. Trifft keines der geprüften Abbruchkriterien zu, so verwendendie spezifischen Operatoren des Suchverfahrens die Fitnesswerte derTestdaten, um für die nächste Iteration der Suche neue Testdaten zu er-zeugen. Ein genetischer Algorithmus wendet hierbei Prinzipien der Evo-lutionstheorie an: Erst werden Testdaten mit einer guten Fitness selektiert(Selektion), dann Bestandteile dieser Testdaten miteinander getauscht(Rekombination) und zusätzlich einzelne Bestandteile variiert (Mutation).Lösungsvorschläge werden im Kontext eines genetischen Algorithmusauch als Individuen bezeichnet und die Menge aller Lösungsvorschlägeeiner Optimierungsiteration auch Population genannt. In den Operatoreneines genetischen Algorithmus werden Entscheidungen getroffen, beidenen meist der Zufall miteinbezogen wird. Von der Gestaltung der Ope-ratoren hängt auch wesentlich ab, ob das Suchverfahren in der Lage ist,lokale Optima in der Fitnesslandschaft zu überwinden und das globaleOptimum – sofern es denn gesucht ist – zu finden. Die Gestaltung derFitnessfunktion kann auf der anderen Seite darauf Einfluss nehmen, wieeinfach oder schwer das Ziel einer Suche gefunden werden kann.

In der Kategorie der globalen Suchverfahren ist der genetische Algorith-mus das mit Abstand am häufigsten verwendete Verfahren [59]. Einegute Übersicht über existierende Suchverfahren bietet Weicker [128]. Beiden lokalen Suchverfahren wird als Beispiel gerne der sogenannte Berg-steigeralgorithmus (englisch: Hill Climbing, HC ) angeführt. Die in denpublizierten Arbeiten am häufigsten behandelte LS ist hingegen die Alter-nating Variable Method (AVM) von Korel [76]. Die AVM ist eine Variationdes HC. Das Vorgehen des HC gestaltet sich sehr simpel: Gestartet wirdmit einem Lösungsvorschlag. Für im Suchraum benachbarte Lösungsvor-schläge wird anschließend geprüft, ob einer der Nachbarn eine bessereFitness aufweist. Ist dies der Fall, so rückt dieser Lösungsvorschlag in


den Fokus und seine Nachbarschaft im Suchraum wird wiederum un-tersucht. Gibt es keinen Nachbarn mit besserer Fitness, so endet derAlgorithmus. Die Nachbarschaft eines Lösungsvorschlags gilt es vorabgemäß dessen Repräsentation zu definieren [57]. Eine Nachbarschaftbesteht typischerweise aus allen Lösungsvorschlägen, die von einemLösungsvorschlag aus betrachtet mit einem möglichst kleinen Schrittim Suchraum, unter Anwendung eines Bewegungsoperators, erreichbarsind [57, 93]. Bei Anwendungsfällen mit einem vieldimensionalen Such-raum, also bei einer hohen Anzahl zu optimierender Parameter, ist dieNachbarschaft entsprechend groß. Die Nachbarschaftsdefinition gestaltetsich dann schwierig, da ansonsten das Durchsuchen einer Nachbarschaftnicht effizient geleistet werden kann [1].

Die AVM adressiert dieses Problem. Die Parameter eines Lösungsvor-schlags werden bei der AVM nacheinander einzeln betrachtet. Bei einemsuchbasierten Test könnten dies beispielsweise die einzelnen Eingabendes Testobjekts sein. Die Nachbarschaftsbetrachtung bezieht sich somitstets nur auf die Veränderung eines einzelnen Parameters. AVM gehtdabei je Parameter wie folgt vor: Zu Beginn wird geprüft, ob sich in derdurch Veränderung dieses Parameters aufgespannten Nachbarschaft einLösungsvorschlag mit besserer Fitness befindet. Dieser Schritt wird alsErkundungssuche bezeichnet. Gibt es einen solchen Lösungsvorschlag,so wird eine Richtungssuche durchgeführt. Hierbei erfolgen fortlaufendweitere Änderungen des betrachteten Parameters in die gleiche Rich-tung. Handelt es sich beispielsweise um eine ganze Zahl und führte eineInkrementierung bei der Erkundungssuche zu einem besseren Lösungs-vorschlag, so wird bei der Richtungssuche weiter inkrementiert. SowohlErkundungs- als auch Richtungssuche enden, sofern kein besserer Lö-sungsvorschlag entsteht. In diesem Fall wird zum nächsten Parameterübergegangen. Auf den letzten Parameter folgt erneut der erste Parame-ter. Die Suche endet insgesamt, sofern deren Ziel erreicht ist oder dieErkundungssuche aller Parameter in Folge zu keinem besseren Lösungs-vorschlag führt.

Auch im Bereich der Suchverfahren existieren Ansätze einer Hybridisie-rung, in erster Linie um die Effizienz einer Suche zu steigern. Sogenanntememetische Algorithmen bilden hierbei den bekanntesten Ansatz [93].Ihr Name leitet sich von dem Begriff der Memetik ab. Dieser stammtaus der Biologie und setzt sich aus dem englischen Wort Memory (zuDeutsch: Gedächtnis oder Speicher) und Genetik zusammen. MemetischeAlgorithmen führen grundsätzlich eine GS durch, zeichnen sich aber da-durch aus, dass sie ihre GS unterbrechen, um für ausgewählte oder alleaktuell betrachteten Lösungsvorschläge jeweils eine LS durchzuführen.Dieser Verfahrensweise liegt folgender Hintergrundgedanke zu Grunde:Befindet sich die GS innerhalb des Suchraums bereits in der Nähe desgesuchten Optimums, so ist eine LS in dieser Region des Suchraumszum einen erfolgsversprechend, da durch die Nachbarschaftsbetrachtung

56 hintergrund

der LS eine äußerst systematische Untersuchung dieser Suchraumregi-on stattfindet und zum anderen ist es nicht unwahrscheinlich, dass dieLS diese Untersuchung effizienter als eine direkte Fortführung der GSdurchführt. In der Literatur lassen sich sowohl Anwendungsbeispielefinden, in denen eine memetische Suche effizienter und effektiver als einerein lokale oder globale Suche ist, als auch Fälle, in denen Gegenteiligesfestgestellt wird [42, 59].

2.4.2 anwendung für simulink/targetlink-modelle

Das im vorigen Abschnitt vertiefte Prinzip des suchbasierten Tests wen-det Windisch unter Nutzung eines genetischen Algorithmus für denStrukturtest von SL-Modellen an [132]. Die in diesem Zusammenhangvon ihm entwickelten Konzepte sind eins zu eins auf den Strukturtestvon TL-konformen SL-Modellen übertragbar.

Abbildung 6 veranschaulicht den Ablauf der Testdatensuche im betrach-teten Kontext. Gemäß der Ausführungen in Abschnitt 2.2.1 leitet sichvon einem Modell entsprechend der durch den Anwender gewähltenÜberdeckungskriterien eine Menge von Überdeckungszielen (CGs) ab.Die CGs werden nacheinander mit Suchvorgängen abgearbeitet – in einerbeliebigen Reihenfolge. Aus dem Ausdruck eines jeden CGs lässt sichdabei automatisch eine Fitnessfunktion ableiten. Windisch ermöglichteine Spezifikation der durch die Suche zu generierenden Modellein-gangssignale durch den Nutzer. Wie im Folgenden detailliert erläutert,schlägt Windisch auch eine spezielle Kodierung für Signale vor. Die ko-dierte Form eines Signals bezeichnet er dabei als Optimierungssequenz.Wird ein Testdatum bewertet, so werden Optimierungssequenzen de-kodiert, das heißt in sogenannte Simulationssequenzen umgewandelt.Diesen Vorgang bezeichnet Windisch als Signalgenerierung. Mit den Si-mulationssequenzen kann das Modell ausgeführt werden. Während derAusführung findet eine Protokollierung der resultierenden Signalverläufeinnerhalb des Modells statt. Diese werden anschließend von der Fitness-funktion des anvisierten CG zur Distanzberechnung verwendet. Darüberhinaus werden auch die Fitnessfunktionen aller noch nicht erreichtenCGs ausgeführt, um zu prüfen, ob eines der CGs eventuell zufälligerwei-se mit-erreicht wurde. In diesem Fall ist von einer Kollateralüberdeckung(englisch: collateral coverage) die Rede. Sobald ein CG erstmalig erreichtwurde, wird das dafür verantwortliche Testdatum in die resultierendeTestsuite aufgenommen.

Die angesprochene Kodierung der Testdaten ist in Abbildung 7a veran-schaulicht. Da Windisch einen speziell angepassten genetischen Algo-rithmus zur Testdatensuche nutzt und dieser eine GS darstellt, wird je


Abbildung 6: Strukturorientierte Testdatensuche für SL/TL-Modelle

Optimierungsiteration eine Menge von Testdaten betrachtet. Diese Mengesei im Folgenden Population genannt. Ein Testdatum wird auch als Indi-viduum bezeichnet. Ein Individuum ist Träger einer geordneten Mengevon Optimierungssequenzen. Die Menge beinhaltet dabei exakt so vieleElemente wie das Modell Eingänge hat. In diesem Zusammenhang seidie Menge der Modelleingänge MB, bestehend aus den Inport-Blöckender obersten Hierarchie-Ebene im Modell, gegeben durch:

MB = {ib | ib∈B∧ btib=Inport∧∀sb∈B: ib ∈BCsb} (17)

Um nun die Motivation hinter der Einführung einer Signalkodierungund einer Trennung zwischen Optimierungs- und Simulationssequenz zuverstehen, ist zu bedenken, was ein Signal eigentlich strukturell darstelltund welche Auswirkung dies auf die Anwendung eines Suchverfahrenshat. Ein (diskretes) Signal ist eine Sequenz von Werten. Für ein SL/TL-Modell gilt es, ausreichend lange Eingangssignale zu generieren, da einModell in der Regel zeitbehaftete Funktionalitäten enthält. Dieses Pro-blem erkannten auch McMinn und Holcombe [85], verallgemeinerndfür zustandsbehaftete Systeme. Im Falle von SL machen zu kurze Ein-gangssignale und eine entsprechend kurze Simulationsdauer es unterUmständen unmöglich, einzelne CGs zu erreichen. Werden allerdings

58 hintergrund

(a) Struktur der Testdatenrepräsentation

(b) Aufbau einer Optimierungssequenz im Allgemeinen

(c) Optimierungssequenz mit dazugehöriger Simulationssequenz (Beispiel)

Abbildung 7: Aufbau der Testdaten- und Signalkodierung im Detail undFunktionsweise der Signalgenerierung anhand eines Bei-spiels (in Anlehnung an Windisch [132])


Signale mit sehr vielen Werten generiert und wird jeder Signalwert da-bei als zu optimierender Parameter aufgefasst, so führt dies zum einenaufgrund der hohen Parameterzahl zu einer ineffizienten Suche. Zumanderen würden dabei sehr sprunghafte Signalverläufe entstehen, die inder Praxis selten gewollt sind.

Baresel et al. schlagen daher einen Ansatz zur Signalkodierung vor [11].Dieser sieht vor, ein Signal als eine Sequenz von Signalsegmenten auf-zufassen. Windisch und Al Moubayed [133] greifen diese Idee auf undbauen den Ansatz wie im Folgenden beschrieben aus. Jedes Segmenteiner Optimierungssequenz besitzt drei Parameter: Einen Signalwert, denes am Ende des Segments einnimmt (Amplitude), eine relativ zu den rest-lichen Segmenten zu betrachtende Breite und einen Transitionstyp, derdie Art des Signalverlaufs zwischen Beginn und Ende des Segments be-schreibt. Auf diese Art und Weise reduziert sich die Parameterzahl einesSignals drastisch. Zusätzlich ergeben sich Möglichkeiten, das Aussehenund die Charakteristik der zu generierenden Signale zu kontrollieren.

So kann der Anwender vor Durchführung einer Testdatensuche dieMenge der möglichen Amplitudenwerte je Modelleingang einschrän-ken. Auch kann je Modelleingang bei Bedarf ein Startamplitudenwertfür den ersten Zeitschritt angegeben werden. Diese zwei Angaben derModelleingangsspezifikation seien wie folgt definiert:

∀ ib∈MB :

specdom(ib) = [a;b]q (a,b,q∈R∧a�b∧((b−a) mod q)=0) (18)

specinit(ib) = x∈ specdom(ib)

Im Falle der Wertebereich-Angabe bezeichnet q die Quantisierung einesSignals. Dies ist der Abstand zwischen den einzelnen aufeinanderfolgen-den Werten zwischen a und b. So entspricht [1;10]3 beispielsweise derMenge {1, 4, 7, 10}.

Neben Wertebereich und Startamplitude kann je Modelleingang eineMindest- und Höchstzahl an Segmenten spezifiziert werden. Hierüberlässt sich unter anderem steuern, wie sprunghaft ein Signalverlauf seindarf. Auch kann der Anwender die Menge der für einen Modelleingangmöglichen Transitionstypen einschränken. Zur Auswahl stehen hierbeigrundsätzlich folgende Typen: ein linearer Übergang, ein Sinus-förmigerVerlauf, eine Spline-Kurve, ein Sprung und ein Impuls. Hierzu empfiehltsich ein Blick auf Abbildung 7b, welche den Aufbau einer Optimie-rungssequenz veranschaulicht. Windisch betrachtet eine Reihe weitererAngaben, die in der sogenannten Modelleingangsspezifikation gemachtwerden können – an dieser Stelle seien aber nur diejenigen Angabendefiniert, welche in den Beiträgen dieser Arbeit eine Rolle spielen. Hier-zu gehören neben den oben angegebenen Modelleingangs-spezifischen

60 hintergrund

Angaben auch zwei Parameter, die für die Signalgenerierung aller Ein-gangssignale gelten:

speclen ∈ R>0 (19)

specres ∈ {x | x∈R>0∧ specres� speclen ∧(speclenmod specres)= 0}

Der Parameter speclen definiert die Länge der zu generierenden Signale inSekunden. Die Abtastrate, in dieser Arbeit auch als Auflösung bezeichnet,wird durch specres, ebenfalls in Sekunden, festgelegt. speclen hat dabeiein Vielfaches von specres zu sein. Aus Länge und Auflösung leitet sichdie Anzahl der Datenpunkte eines Signals ab:

specsteps = speclen÷ specres (20)

All diese Angaben werden bei der Erzeugung von Optimierungssequen-zen und deren Überführung zu Simulationssequenzen berücksichtigt.Der letztgenannte Schritt, die Signalgenerierung, ist beispielhaft in Ab-bildung 7c dargestellt. Zu sehen ist eine Optimierungssequenz mit vierSegmenten. Da in diesem Beispiel kein Startamplitudenwert spezifiziertist, wird stattdessen der Amplitudenwert des ersten Segments als Start-wert genutzt. Wie in der entstehenden Simulationssequenz zu erkennenist, verwendet jedes der folgenden Segmente den Amplitudenwert desVorgängersegments als Startwert. Der Amplitudenwert eines Segmentsbildet hingegen den Wert am Segmentende. Da die Segmentbreiten rela-tive Angaben sind, erfolgt entsprechend der spezifizierten Signallängeund Auflösung eine Berechnung der Datenpunkt-Anzahl, welche jedesSegment in der Simulationssequenz einnimmt. Ist die Anzahl der Da-tenpunkte für ein Segment bekannt, so kommt die Transitionsfunktiondes betreffenden Transitionstyps zum Einsatz, um den Signalwert einesjeden Datenpunkts zu bestimmen.

Da die Operatoren des eingesetzten Suchverfahrens für die Variation vonTestdaten zuständig sind, müssen auch diese mit der Signalkodierungumgehen können. Windisch setzt primär auf einen genetischen Algorith-mus mit angepasstem Rekombinations- und Mutationsoperator. DieseOperatoren tauschen oder verändern hierbei nicht nur die verschieden-artigen Segmentparameter. Sie sind auch dazu in der Lage, Segmentezu einer Optimierungssequenz hinzuzufügen oder zu entfernen. Daherwird dieses globale Suchverfahren im Folgenden als längenvariabler gene-tischer Algorithmus (LGA) bezeichnet. Für die verschiedenen Operatorendes LGA existieren eine Reihe von Parametern, welche unter anderemdie Wahrscheinlichkeiten der einzelnen Operatoraktionen festlegen. Füreine detaillierte Betrachtung des LGA sei auf die Arbeit von Windischverwiesen [132].

Zur Durchführung einer suchbasierten Testdatengenerierung wird desWeiteren je CG eine Fitnessfunktion benötigt. Diese lässt sich, wie bereits


angedeutet, automatisch aus einem CG-Ausdruck (siehe Definition 14)ableiten. Die vorliegende Arbeit folgt hierbei dem Vorgehen von Win-disch [132]. Zunächst wird für das betrachtete Überdeckungsziel cg∈Eje diskretem Zeitschritt ts der zuvor erfolgten Modellausführung einFitnesswert berechnet. Grundlage der Fitnessberechnung sind die beider Modellausführung protokollierten Signalverläufe genau der Signale,welche Teil des CG-Ausdrucks sind. Die Fitnessberechnung erfolgt jeZeitschritt über die in Tabelle 5 definierte Distanzfunktion δi:E×N→R,wobei i∈{T , F} angibt, ob das Ziel die Erfüllung oder die Nicht-Erfüllungdes betrachteten CG oder eines CG-Teilausdrucks ist. κ bezeichnet ei-ne möglichst kleine positive reelle Zahl. Da jedes ξ1, ξ2∈L eines CG-Ausdrucks jeweils entweder ein Signal oder eine Konstante bezeichnet,gibt die Funktion r:L×N→R dementsprechend entweder den bei derModellausführung protokollierten Wert eines Signals zu einem Zeitschrittoder den Wert der Konstanten an:

r(ξ, ts) =

⎧⎨⎩outvb(src(s)), pos(src(s))(ts) , ξ=sv

c , ξ=c

(21)

Auf diesem Wege wird eine Sequenz von Fitnesswerten berechnet:

fs(cg) = (δT (cg ,0), . . . , δT (cg , specsteps−1)) (22)

Diese wird anschließend in einen einzelnen Fitnesswert überführt:

f(cg) =

⎧⎨⎩0 ,min(fs(cg))�0

fs(cg) +min(fs(cg)) , sonst(23)

ϕ Distanz zur Erfüllung (i=T ) Distanz zur Nicht-Erfüllung (i=F)

ξ1<ξ2 r(ξ1, ts)− r(ξ2, ts)+κ δT (ξ1�ξ2, ts)

ξ1>ξ2 r(ξ2, ts)− r(ξ1, ts)+κ δT (ξ1�ξ2, ts)

ξ1�ξ2 r(ξ1, ts)− r(ξ2, ts) δT (ξ1>ξ2, ts)

ξ1�ξ2 r(ξ2, ts)− r(ξ1, ts) δT (ξ1<ξ2, ts)

ξ1=ξ2 |r(ξ1, ts)− r(ξ2, ts)| δT (ξ1 �=ξ2, ts)

ξ1 �=ξ2 1 δT (ξ1=ξ2, ts)

ϕ1∧ϕ2 δT (ϕ1, ts)+ δT (ϕ2, ts)δF(ϕ1 , ts) ·δF(ϕ2 , ts)δF(ϕ1 , ts)+δF(ϕ2 , ts)

ϕ1∨ϕ2δT (ϕ1 , ts) ·δT (ϕ2 , ts)δT (ϕ1 , ts)+δT (ϕ2 , ts) δF(ϕ1, ts)+ δF(ϕ2, ts)

¬ϕ1 δF(ϕ1, ts) δT (ϕ1, ts)

Tabelle 5: Distanz δi(ϕ, ts) zur (Nicht-)Erfüllung eines CG-Ausdrucks ϕzum Zeitschritt ts (in Anlehnung an Windisch [132])

62 hintergrund

Hierbei bezeichnet fs(cg) das arithmetische Mittel aller Werte aus derFitness-Sequenz und min(fs(cg)) den kleinsten Wert dieser Sequenz.

Der so entstehende Fitnesswert bewertet das Testdatum, das bei derModellausführung zum Einsatz kam, und wird von den Operatoren desSuchverfahrens zu Optimierungszwecken genutzt. Das betrachtete CGgilt als erreicht, wenn ein Testdatum den Fitnesswert 0 besitzt. Nebendiesem Abbruchkriterium für die Suche begrenzt Windisch in seinemAnsatz die Anzahl der Optimierungsiterationen.

2.5 problemstellung

Der suchbasierte Ansatz hat sich in den Arbeiten von sowohl Windisch[131–133] als auch Zhan [135, 136] als geeignet für eine Testdatengenerie-rung aus SL-Modellen erwiesen. Während Windisch, wie beschrieben,eine GS verwendet, setzt Zhan eine LS ein. Windisch und Zhan verglei-chen ihre Verfahren beide mit einem Zufallstest und dem kommerziellenWerkzeug Reactis. Diese werden hinsichtlich des erzielten Überdeckungs-grads vom suchbasierten Ansatz in beiden Fällen übertrumpft. Windischnutzte in seinen Fallstudien allerdings deutlich größere Modelle.

Auch wenn diese Ergebnisse als sehr positiv zu werten sind, so existie-ren dennoch Hürden, die einer Anwendung in der industriellen Praxisim Wege stehen. Aus Nutzersicht spiegelt sich dies vor allem in denteils sehr hohen Laufzeiten einer suchbasierten Testdatengenerierungwider. Wie die Fallstudien der vorliegenden Arbeiten zeigen werden,kann es bei der Betrachtung von Modellen aus der industriellen Entwick-lungspraxis durchaus zu Laufzeiten im zweistelligen Stundenbereichkommen. Ohne Anwendung des zusätzlichen Abbruchkriteriums einerFitness-Stagnation werden aus diesen Stunden schätzungsweise sogarTage. Ähnliche Erfahrungen machte Vos et al. bei der strukturorientiertenTestdatensuche für C-Code [121].

Aus dieser Betrachtung leitet sich die Zielsetzung dieser Arbeit ab: dieSteigerung der Effizienz der suchbasierten Testdatengenerierung in An-wendung für SL/TL-Modelle. Zusätzlich muss es das Ziel sein, dieEffizienzsteigerung ohne Einbußen bei den Überdeckungsgraden zu er-reichen. Um dies beides erreichen zu können, sind folgende zwei Fragenzu beantworten:

1. Gibt es Potenzial zur Verbesserung der Effizienz einer suchbasier-ten Testdatengenerierung für SL/TL-Modelle?

2. Lassen sich Änderungen am suchbasierten Verfahren oder erwei-ternde Techniken formen, welche dieses Potenzial ausschöpfen?

2.5 problemstellung 63

Die erste Frage wird in den folgenden Zeilen dieses Abschnitts adressiert.Auf die drei zuletzt genannten der sechs hierbei aufgeführten Problem-stellungen weist auch Windisch im Ausblick seiner Arbeit hin [132]. Diezweite Frage wird in den folgenden Kapiteln dieser Arbeit beantwortet.

Unerreichbarkeit. Die erste Problemstellung besteht in der Unerreichbar-keit mancher CGs. Auch wenn ein Modell seine beabsichtigte Funktiona-lität vollständig korrekt implementiert, gibt es in der Regel Modellzustän-de, deren Eintreten durch keinerlei Testdaten bewirkt werden kann. Derin der Code-Welt bekannte „tote“ Code existiert auch in der SL-Welt. Inder Entwicklungspraxis werden beispielsweise vordefinierte Bibliotheks-blöcke in Modellen verwendet. Solche Blöcke realisieren häufig benötigteund wiederkehrende Funktionalitäten. De facto handelt es sich bei diesenBlöcken um referenzierte Subsysteme, mit Ein- und Ausgängen. Nunwerden allerdings oftmals nicht alle Parameter der auf diesem Wegeabgebildeten Bibliotheksfunktionen benötigt und einzelne Blockeingängedaher mit einem Konstantenblock verbunden. Dies führt innerhalb einesBibliotheksblocks dann dazu, dass bestimmte CGs nicht erreichbar sind.Für eine suchbasierte Testdatengenerierung ist dieser Umstand höchstproblematisch, da das Suchverfahren unerbittlich und ohne Aussichtauf Erfolg bis zum Eintreten eines anderweitigen Abbruchkriteriumsnach nicht existierenden Testdaten fahndet. Dieser Aspekt stand nichtim Fokus der Arbeit von Windisch [132]. Allerdings betrachtete er die-se Problematik in seinen Fallstudien. Die dort verwendeten Modellewurden vor Durchführung einer Testdatensuche manuell analysiert undunerreichbare CGs vorab herausgefiltert. Die vorliegende Arbeit schlägteine Technik (SIA) vor, welche diese Aufgabe automatisiert.

Suchraumgröße. Die Größe des Raumes aller, für die Eingänge einesModells generierbaren Signale kann ein entscheidender Faktor sein, wennes darum geht, wie einfach oder schwer eine Testdatensuche für einbestimmtes CG erledigt werden kann. Je enger der Suchraum auf dasgesuchte Optimum eingegrenzt werden kann, desto einfacher hat es dieSuche in der Regel. Auf ein SL/TL-Modell bezogen wächst die Größedes Suchraums allen voran mit der Anzahl der Modelleingänge. Nun istes allerdings so, dass das Erreichen vieler Zustände und CGs nicht vonder Stimulation aller Modelleingänge abhängig ist – sondern häufig nurvon einer Teilmenge der Eingänge. An genau dieser Stelle setzt ein indieser Arbeit vorgestelltes Verfahren (SDA) an.

Überdeckungsziel-Abhängigkeiten. Wie in Abschnitt 2.2.1 geschildert,bedingt ein Strukturtest in der Regel das Erreichen einer Vielzahl vonCGs. Zwischen den CGs existieren jedoch unzweifelhaft Abhängigkei-ten: Das Erreichen eines CG hat unter Umständen das Erreichen einesanderen CG zur Folge (Kollateralüberdeckung). Je höher die Kollate-ralüberdeckung bei einer strukturorientierten Testdatensuche ausfällt,desto weniger Suchvorgänge müssen insgesamt unternommen werden.

64 hintergrund

Der Ansatz von Windisch berücksichtigt diesen Aspekt nicht [132]. Dievorliegende Arbeit ergänzt den Ansatz daher um eine Technik (CGSeq),die den beschriebenen Sachverhalt ausnutzt, um die Kollateralüberde-ckung und somit auch die Effizienz eines automatisierten Strukturtestszu steigern.

Blindheit der Fitnessfunktion. Eine der Stärken des suchbasierten An-satzes ist gleichzeitig eine seiner Schwächen. Zur Erfüllung eines CGbetrachtet er nämlich den Teil des Modells zwischen Modelleingängenund den an dem CG beteiligten Signalen als eine Art Black-Box. Diesbedeutet, das Modell wird an den Eingängen mit Testdaten stimuliert, diein den relevanten Signalen entstandenen Werte werden ausgelesen undanschließend zur Fitnessberechnung verwendet. Jegliche Berechnungs-schritte dazwischen werden nicht berücksichtigt. Diese Eigenschaft machtden suchbasierten Ansatz auf der einen Seite hoch-skalierbar – vor allemim Vergleich mit statischen Verfahren wie der symbolischen Ausführung.Auf der anderen Seite können in diesem als Black-Box bezeichneten Teileines Modells jedoch Bedingungen oder Berechnungen enthalten sein,von deren Berücksichtigung oder Erfüllung das Erreichen des verfolgtenCG entscheidend abhängt. Dieses Problem erkannten bereits McMinnet al. [84, 86], wenn auch nicht auf den Modelltest bezogen. Die CGSeq-Technik der vorliegenden Arbeit adressiert auch dieses Problem, löst esallerdings nur für einen Teil der möglichen Problemfälle.

Boolesche Signale. Je nach Anwendungsbereich bilden SL/TL-Modelleteils mehr, teils weniger berechnende oder aussagenlogische Funktiona-litäten ab. Ist ein Modell entsprechend Logik-lastig, so enthält es vieleSignale mit Booleschem Wertebereich. Existieren CGs, welche Bedin-gungen über solche Booleschen Signale definieren, gestaltet sich eineBewertung der Testdaten schwierig. Gemäß der in Abschnitt 2.4.2 be-schriebenen Vorgehensweise zur Distanzberechnung ergibt sich für einTestdatum, welches ein solches CG nicht erfüllt, die Distanz 1. Die Fit-nessfunktion bietet dem Suchverfahren demnach keinerlei Unterstützungbei der Unterscheidung von Testdaten. Die CGSeq-Technik der vorliegen-den Arbeit und eine Testdatengenerierung via SMT-Solving, wie in dervorliegenden Arbeit behandelt, adressieren dieses Problem zum Teil.

Anzahl aufgesuchter Testdaten. Die Effizienz einer automatischen Test-datensuche hängt maßgeblich von der Anzahl an Testdaten ab, welcheim Zuge der Suche erzeugt, bewertet und möglicherweise verworfenwerden. Denn je betrachtetem Testdatum erfolgt eine Ausführung desSL/TL-Modells. Je nach Größe und Gestaltung des Modells variiert dieDauer einer Modellausführung. Eine Ausführungsdauer von zehn Se-kunden oder sogar mehr ist bei Modellen aus der industriellen Praxisnicht unüblich. Aus diesem Grund wirkt sich die Vorgehensweise einesSuchverfahrens direkt auf die Laufzeit der gesamten Testdatengenerie-rung aus. Globale Suchverfahren wie der LGA sind bekannt dafür, eine

2.5 problemstellung 65

hohe Anzahl an Testdaten im Zuge ihrer Suchiterationen zu betrachten.Eine LS kann effizienter sein, sofern sie es schafft, das Ziel der Suche zufinden. Die Arbeit untersucht daher, ob sich im betrachteten Kontext eineLS anwenden lässt und wie effizient, beziehungsweise erfolgreich, eineLS Testdaten für ein SL/TL-Modell generieren kann. Darüber hinauswird die Möglichkeit einer Testdatengenerierung mittels SMT-Solvinguntersucht.

Die aufgeführten Potenziale, welche der suchbasierte Ansatz von Win-disch aufweist, bilden die Grundlage der in den nachfolgenden Kapitelnvorgestellten Lösungen. Der suchbasierte Ansatz von Windisch wirddabei um eine Reihe von Techniken ergänzt. Die Einführung zusätzlicherTechniken ist hierbei um eine wichtige, zusätzliche Anforderung begleitet:Erweiternde Techniken dürfen keinerlei Einschränkungen bezüglich derBeschaffenheit verwendbarer SL/TL-Modelle machen. Die nachfolgendvorgestellten Techniken zur statischen Voranalyse eines SL/TL-Modellserfüllen diese Anforderung, da sie auch mit unbekannten oder durch sienicht explizit unterstützten Blocktypen umgehen können.

Teil II

H Y B R I D E S V E R FA H R E N Z U RT E S T DAT E N G E N E R I E R U N G

3 STAT ISCHE VORANALYSEN

Eine Hybridisierung des suchbasierten Ansatzes mit ergänzenden sta-tischen oder dynamischen Techniken ist auf drei Ebenen möglich. Un-terstützende Techniken können vor Durchführung einer Testdatensuche,während (oder zum Teil anstelle) dieser oder danach aktiv sein. In diesemKapitel werden drei Techniken vorgestellt, die einer Testdatensuche fürSL/TL-Modelle vorausgehen. Die drei Techniken operieren statisch, siesind vollständig automatisierbar und sie haben die Aufgabe, die Suchebesser auf die sich ihr stellenden Probleme einzustellen und hierdurchdie Effizienz der Testdatengenerierung zu steigern.

Allen drei als statische Voranalysen bezeichneten Techniken gehen grund-legende Modelltransformationen voraus. In diesem Zusammenhang istanzumerken, dass die Voranalysen mit einer Repräsentation des betrach-teten SL/TL-Modells arbeiten. Das originale Modell bleibt von etwaigenTransformationen unberührt. Bei den vorausgehenden Transformationenhandelt es sich einerseits um die Auflösung von Bus-Systemen, das heißtderen Zerlegung in ihre enthaltenen Signale. Andererseits geht es umdas Entfernen von Modellbestandteilen, die für die Analysen irrelevantsind. Dies betrifft Blöcke und Signale, die sich zwischen den Ausgängendes Modells und Signalen oder Blöcken, welche in Zusammenhang mitÜberdeckungszielen stehen, befinden. Derlei Blöcke und Signale sind amDatenfluss zwischen Modelleingängen und Überdeckungszielen nichtbeteiligt und können daher aus der Modellrepräsentation entfernt wer-den. Die vorausgehenden Transformationen erleichtern die Abläufe derstatischen Voranalysen und reduzieren ihren Aufwand.

3.1 überdeckungsziel-erreichbarkeitsprüfung

Der folgende Abschnitt behandelt Sinn und Zweck der ersten statischenVoranalyse, der sogenannten Überdeckungsziel-Erreichbarkeitsprüfung(SIA). Die Bedeutung der Abkürzung SIA wird ebenfalls im folgendenAbschnitt erklärt. Danach wird SIA im Detail vorgestellt und verwandteArbeiten aus dem Teilbereich, in dem SIA sich bewegt, beleuchtet.

69

70 statische voranalysen

3.1.1 ziel

Bei einem Strukturtest eines SL/TL-Modells besteht die Möglichkeit, dassein CG unerreichbar ist. Dies bedeutet, dass keinerlei Testdaten existieren,die zu einer Erfüllung führen. Dieser Umstand bedeutet allerdings nichtzwangsläufig, dass das Modell seine Spezifikation nicht korrekt umsetztoder dass es dem Modell an Qualität mangelt. In Abschnitt 2.5 wurde be-reits eine mögliche Ursache für die Unerreichbarkeit von CGs aufgeführt:die unvollständige Verwendung von Bibliotheksblöcken. Eine weitereUrsache besteht in der Auflösung von Variabilität zum Zeitpunkt derModellausführung. Systeme und Funktionen, die mit SL/TL-Modellenbeschrieben werden, sind häufig konfigurierbar gestaltet. Ein Modellkann zum Beispiel verschiedene Softwarevarianten gleichzeitig abbilden.Die Variabilität entsteht dabei in der Regel durch die Verwendung vonVariablen in Blockparametern, beispielsweise bei einem Constant-Block.Die Konfigurierung, das heißt die Festlegung auf eine Variante, erfolgtdann für gewöhnlich über eine Variablenbelegung im ML-Workspace.Abhängig hiervon können Teile des Modells bei dessen Ausführunginaktiv oder bestimmte Zustände nicht erreichbar sein.

Der suchbasierte Ansatz erkennt die eventuelle Unerreichbarkeit einesCG nicht. In Folge dessen wird, ohne Aussicht auf Erfolg, eine Test-datensuche durchgeführt. Je nachdem, welche Abbruchkriterien zumEinsatz kommen, wirkt sich das Vorhandensein eines unerreichbarenCG oder mehrerer unerreichbarer CGs entsprechend negativ auf dieLaufzeit der gesamten Strukturtestautomatisierung aus. Erfahrungen mitModellen aus der industriellen Praxis zeigen, dass oftmals nicht wenigeunerreichbare CGs in Modellen existieren [132]. Daher ist eine automati-sierte Erkennung dieser für eine automatisierte Testdatengenerierung vongroßem Nutzen. Dies gilt nicht nur, weil die Testdatengenerierung hier-durch effizienter erfolgen kann. Auch ermöglicht eine solche Erkennungeine präzisere Bestimmung des Überdeckungsgrads beim Strukturtest.Des Weiteren kann die Tatsache, dass ein CG unerreichbar ist, für denEntwickler eines Modells möglicherweise doch ein Hinweis auf einefehlerhafte oder nicht ideale Modellierung sein.

Im Allgemeinen ist es nicht mit vertretbarem Aufwand möglich, miteiner statischen Analyse jede mögliche Kombination von Zuständeninnerhalb eines beliebig großen Modells zu betrachten. Grund hierfürist die explodierende, oftmals sogar unendliche Anzahl möglicher Zu-standskombinationen [50, 78, 134]. Statische Analysetechniken nutzendaher meist Abstraktionstechniken, um nicht an Komplexitätsgrenzenzu stoßen. Eine Abstraktion führt dabei in der Regel zu einem Verlustan Detailinformationen, die Korrektheit der produzierten Ergebnisse istjedoch gewährleistet [38]. Für das Vorhaben, die unerreichbaren CGseines SL/TL-Modells zu identifizieren, bedeutet dies, dass eine auf Ab-straktionsprinzipien beruhende statische Analyse nicht garantieren kann,

3.1 überdeckungsziel-erreichbarkeitsprüfung 71

alle unerreichbaren CGs auch tatsächlich zu finden. Dies gilt auch fürdie im folgenden vorgestellte SIA-Technik.

SIA greift das Konzept der abstrakten Interpretation auf. Der Kerngedan-ke dieses von dem Ehepaar Cousot begründeten Konzepts für statischeProgrammanalysen besteht in der Interpretation eines Programms mittelseiner abstrakten Semantik anstatt seiner konkreten Semantik [31]. Alseine Form der Abstrahierung von den bei der Ausführung eines Pro-gramms entstehenden konkreten Werten schlagen Cousot und Cousot dieVerwendung von Intervallen vor [30]. Dieser Ansatz bildet die Grundlagevon SIA. Innerhalb der Modellanalyse, die SIA durchführt, kommt stattder Semantik eines jeden Modellblocks eine sogenannte Intervallseman-tik zum Einsatz. Unter Einbeziehung der Modelleingangsspezifikation(siehe Abschnitt 2.4.2) wird so der Wertebereich eines jeden Modellsi-gnals bestimmt. Eine im Anschluss durchgeführte Erreichbarkeitsanalyseist in der Lage, für die betrachteten CGs anhand der Signalwertebereicheabzuleiten, ob ein CG unerreichbar ist. Wird dies festgestellt, so ist dasbetreffende CG tatsächlich unerreichbar. Im Umkehrschluss bedeutetdies allerdings nicht, dass ein CG, für welches die Unerreichbarkeit aufdiesem Wege nicht festgestellt wird, zwingend erreichbar ist.

Die für diese statische Voranalyse verwendete Abkürzung orientiert sichübrigens an dem ihr zugrunde liegenden Prinzip, gemünzt auf denbetrachteten Kontext: SIA steht für den Begriff Signalintervallanalyse.

3.1.2 abstrakte intervall-interpretation

Das in Abbildung 8 dargestellte Beispiel soll als Einstieg für die nach-folgenden Ausführungen dienen. Zu sehen ist ein kleines Modell mitdrei Eingängen (Inport-Blöcke) und zwei Ausgängen (Outport-Blöcke).Das Modell ist umgeben von einer Modelleingangsspezifikation, wiesie im Rahmen des suchbasierten Ansatzes zur Testdatengenerierungvon Windisch zum Einsatz kommt. Jedem Eingang ist hierbei ein Wer-tebereich per Intervallangabe, gegebenenfalls inklusive Quantisierung,zugewiesen. Darüber hinaus ist über die spezifizierte Signallänge undAbtastrate die Gesamtanzahl der Zeitschritte einer Modellausführung,im Falle des Beispiels 300, bekannt.

Gemäß der Ausführungsreihenfolge der Modellblöcke kommt es nun zueiner abstrakten Ausführung des Modells. Hierbei berechnet jeder Blockauf Grundlage der Wertebereiche seiner eingehenden Signale die Werte-bereiche für seine Ausgangssignale (Intervallpropagierung). Jedem Signalist dabei nicht nur ein einziges Intervall zugeordnet, sondern eine Mengevon Intervallmengen. Jede Intervallmenge ist einer Zeitphase zugeord-net. Diese Zusammenhänge werden im Folgenden noch exakt definiertund erläutert. An dieser Stelle soll lediglich das Grundprinzip vermittelt


Abbildung 8: Funktionsweise der Überdeckungsziel-Erreichbarkeits-prüfung anhand eines Beispiels

werden. Hierzu seien die Modelleingänge zwei und drei im Beispielbetrachtet. Ihre Ausgangssignale besitzen zu jedem möglichen Zeitschritteiner Modellausführung, das heißt im Zeitintervall [0,299], den in derModelleingangsspezifikation entsprechend angegebenen Wertebereich.Beide Signale gehen im Modell in einen Product-Block ein. Unter Berück-sichtigung der eingehenden Wertebereiche und der Intervallsemantikdieses Blocks ergibt sich der Wertebereich seines Ausgangssignals.

Diese wesentliche Verfahrensweise findet auch vom ersten Modelleingangaus betrachtet Anwendung. Allerdings kann der im Modell enthalteneSum-Block den Wertebereich seines Ausgangssignals nicht ohne Weiteresbestimmen, da er Teil einer sogenannten Rückkopplung im Modell ist.Eine solche Rückkopplung wird in dieser Arbeit als Schleife bezeichnet.Im Falle des Beispiels wird die Schleife über einen Unit-Delay-Block gebil-det. Dieser bewirkt eine zeitliche Verzögerung seiner Ausgabe um einenZeitschritt. SIA enthält eine Schleifenanalyse, welche sich die spezifizierteDauer einer Modellausführung zu Nutze macht, um die Wertebereicheder an der Schleife beteiligten Signale schrittweise zu bestimmen. Fürdas betrachtete Beispiel kommt SIA zu dem Schluss, dass das Ausgangs-signal des Relational-Operator-Blocks zu jedem Zeitschritt den Wert 0einnimmt. Das dargestellte CG ist demzufolge unerfüllbar.


Die Intervallsemantik der verschiedenen Blocktypen wird im folgendenAbschnitt behandelt. Die Vorgehensweisen der Intervallpropagierungund der Schleifenanalyse werden anschließend betrachtet.

3.1.2.1 Intervallsemantik

Zur Bildung einer Intervallsemantik für die in SL/TL verfügbaren Block-typen wird in dieser Arbeit die Intervall-Arithmetik von Moore [91]genutzt. Die Arithmetik von Moore definiert unter anderem die ma-thematischen Operatoren für die Addition, Subtraktion, Division undMultiplikation in Anwendung für Intervalle. So gilt für zwei beliebigeabgeschlossene, reelle Intervalle:

[a,b]+[c,d] = [a+c,b+d]

[a,b]−[c,d] = [a−d,b−c] (24)

[a,b]·[c,d] = [min(a·c,a·d,b·c,b·d),max(a·c,a·d,b·c,b·d)][a,b]÷[c,d] = [min(a÷c,a÷d,b÷c,b÷d),max(a÷c,a÷d,b÷c,b÷d)]

(nur definiert für 0∈[c,d])Wang et al. verwenden dieses Grundkonzept ebenfalls, allerdings fürdie statische Analyse von Java-Programmen [125]. Um die Genauigkeitihrer Analysen zu erhöhen, weisen sie den Programmvariablen Intervall-mengen anstatt einzelner Intervalle zu. Hierzu ein Beispiel: Nimmt eineVariable Werte zwischen 10 und 20 sowie 30 und 40 an, so ist die Angabeeiner Intervallmenge {[10, 20],[30, 40]} zweifelsfrei exakter und verlustfrei-er als die Angabe des Intervalls [10, 40]. Auch SIA verwendet Intervall-mengen je Modellsignal. Um die Intervallmengen allerdings so kompaktwie möglich zu halten, enthält SIA ein Vorgehen zur Vereinigung vonIntervallen – ohne hierbei allerdings an Genauigkeit einzubüßen.

Alle Intervalle haben die folgend dargestellte Form. IV bildet hierbei dieMenge aller möglichen Intervalle.

IV = {[a;b] |a,b∈R∧a�b} ∪{[a;b]q |a,b,q∈R∧a�b∧((b−a) mod q)=0)} ∪ (25)

{[a] |a∈R}

Wie in dieser Definition zu sehen ist, existieren drei verschiedene Vari-anten. Zum einen kann ein Intervall optionalerweise mit einer Quanti-sierung q versehen sein. Zum anderen wird für einelementige Intervalleeine verkürzende Schreibweise verwendet. Als Trennzeichen innerhalbeines Intervalls wird ein Semikolon verwendet, da es sich bei den Inter-vallgrenzen um reelle Zahlen handelt.


Im Zusammenhang mit dem einführenden Beispiel wurde bereits er-wähnt, dass je Signal eine Aufteilung seiner Intervallmenge in zeitlichePhasen möglich ist. Auch dieser Schritt dient einer größtmöglichen Ge-nauigkeit der Analyse. Ist SIA mit seiner Analyse fertig, so decken diezeitlichen Phasen eines jeden Signals die Gesamtzahl der für die Signal-generierung spezifizierten Zeitschritte ab. Die Zeitphasen überlappensich dabei nicht. Eine Zeitphase wird ebenfalls in Form eines Intervalls,mit Anfangs- und Endzeitschritt, angegeben:

TI = {[t1,t2]T | t1,t2∈N∧0�t1�t2� specsteps −1} (26)

Im Folgenden werden Zeitphasen auch als Zeitintervalle bezeichnet. Umzwischen Werte- und Zeitintervallen unterscheiden zu können, wird einZeitintervall mit einem hochgestellten „T“ markiert.

Für die Zuordnung von Intervallmengen zu Signalen über Zeitintervalleseien folgende zwei Abbildungen eingeführt, welche im Folgenden zurDefinition der Intervallsemantik wahlweise Anwendung finden:

IS : (S× N+ × TI) → P(IV) (27)

IA : (S× N+) → P(TI×P(IV))

Während die Abbildung IS für ein konkretes Zeitintervall eines Signalsdie dazugehörige Intervallmenge liefert, gibt IA sämtliche durch SIAgebildete Zuordnungen von Zeitintervallen zu Intervallmengen für einSignal an. Beide Abbildungen erhalten als zweiten Parameter die Angabeeines Vektor-Index für das betreffende Signal.

Die Gestaltung der Intervallmenge eines Signals hängt im Allgemei-nen sowohl von der konkreten Semantik des Modellblocks ab, aus wel-chem das Signal hervorgeht, als auch von den Intervallmengen derEingangssignale dieses Blocks. Die Art und Weise, wie ein Blocktyp dieIntervallmenge seiner Ausgangssignale berechnet oder ableitet, sei alsIntervallsemantik bezeichnet. Bei der folgenden Beschreibung dieser fürverschiedene Blocktypen kommen folgende Abbildungen zum Einsatz,um die Definitionen kompakt zu gestalten.

Die Abbildung T gibt für das v-te Vektorelement eines Signals s dieMenge der dazugehörigen, durch SIA gebildeten Zeitintervalle an:

T : S× N+ → P(TI) (28)

T(s,v) = {ti | (ti ,Z)∈IA(s,v)}

Die Definition der Intervallsemantik greift darüber hinaus auf die Ab-bildungen IP und IV zurück. Diese liefern jeweils die Intervallmengender Eingangssignale eines Blocks – unterscheiden dabei aber zwischenBlöcken, welche mehrere Eingänge besitzen sowie ihre Funktionalität jeVektorelement anwenden (zum Beispiel ein AND-Block), und Blöcken,


welche nur einen Eingang besitzen und die ihre Funktionalität über alleVektorelemente dieses Eingangs anwenden (zum Beispiel ein Sum-Blockmit einem Eingang). Die Abbildung IP beschreibt also für die v-tenVektorelemente aller Eingangssignale eines Blocks b die Menge der dortanliegenden Intervalle, welche in ein Zeitintervall [t1,t2]T fallen. Die Aus-gabe der Intervallmengen erfolgt dabei zugeordnet zu den Eingängendes Blocks (über die Portnummer):

IP : (B× TI×N+) → (N+ ×P(IV)) (29)

IP(b, ti ,v) ={(i,X)

∣∣∣∣ i∈N[1,| IPb |]∧X=⋃

Z∈OIti,s,wZ}

Hierbei bezeichnet s= sigin(b,i) das Eingangssignal des Inports mit derPortnummer i und w=vc(v, ip(b,i)) einen, je nach Signaldimensionalitätgegebenenfalls nach unten korrigierten Vektorindex. OIti ist eine Mengeall derer Intervallmengen, welche Zeitintervallen zugeordnet sind, die mitdem betrachteten Zeitintervall ti mindestens einen Zeitschritt teilen:

OIti,s,u = { F | (ti’ ,F)∈IA(s,u)∧ overlap(ti, ti’) } (30)

Die Funktion overlap :TI×TI→B gibt an, ob ein Zeitintervall mindestenseinen Zeitschritt mit einem anderen Zeitintervall teilt:

overlap([t1,t2]T , [t ′1,t′2]

T ) = t ′2�t1∧t′1�t2 (31)

Die Abbildung IV funktioniert im Vergleich hierzu ähnlich, dient aberder Intervallsemantik-Definition von Blöcken, die nur einen Eingangbesitzen und die ihre Funktionalität über alle Vektorelemente des einenEingangssignals definieren. Dementsprechend bildet IV die Intervall-mengen des Eingangssignals, welche im Zeitintervall [t1,t2]T gelten, inZuordnung mit dem jeweiligen Vektorindex ab:

IV : (B× TI) → (N+ ×P(IV)) (32)

IV (b, ti) ={(i,X)

∣∣∣∣ i∈N[1, d(b,1)]∧X=⋃

Z∈OIti,s,iZ}

Hierbei bezeichnet s= sigin(b,1) das einzige Eingangssignal.

Die Funktionen min und max werden des Weiteren verwendet, um dieminimale untere Grenze oder die maximale obere Grenze einer Intervall-menge, das heißt aller ihrer enthaltenen Intervalle, zu bestimmen:

min,max : P(IV) → R (33)

min(X) = a mit ([a;b]∈X∨[a;b]q∈X∨[a]∈X)∧(∀ [c;d],[c;d]r,[c]∈X: a�c)

max(X) = b mit ([a;b]∈X∨[a;b]q∈X∨[b]∈X)∧(∀ [c;d],[c;d]r,[d]∈X: b�d)


Die untere und obere Grenze sowie Quantisierung eines einzelnen Inter-valls seien durch die Funktionen lb, ub und q gegeben:

lb, ub, q : IV → R

lb(iv) = a mit iv=[a;b]∨ iv=[a;b]q∨ iv=[a] (34)

ub(iv) = b mit iv=[a;b]∨ iv=[a;b]q∨ iv=[b]

q(iv) ={q , iv=[a;b]q0 , sonst

Eine Definition der Intervallsemantik einiger wichtiger Blocktypen ist inTabelle 6 angegeben. Die folgenden Absätze erläutern diese.

Constant, Inport und Subsystem. Wie aus der Definition für den Cons-tant-Block hervorgeht, gibt dieser unabhängig von dem betrachtetenZeitintervall stets ein einelementiges Intervall mit seinem Konstanten-wert aus. Im Falle des Inport-Blocks gilt es zu unterscheiden, ob sichdieser in einem Subsystem befindet oder ob es sich um einen Model-leingang handelt. In ersterem Fall gibt der Block die Intervallmengeaus, welche dem dazugehörigen Eingang des übergeordneten Subsys-tems für das betrachtete Zeitintervall zugewiesen ist. Handelt es sichum einen Modelleingang, so leitet sich das ausgehende Intervall vonder Wertebereichsangabe in der Modelleingangsspezifikation ab. Für dieAusgänge eines virtuellen Subsystems wird die Intervallmenge jeweilsohne Änderung von dem Eingang des dazugehörigen Outport-Blocks imSubsystem übernommen.

Logical und Relational Operator. Der Logical-Operator-Block prüft zurBestimmung seiner auszugebenden Intervallmenge in Abhängigkeit deslogischen Operators, ob die in den Block eingehenden Intervallmengenfür das betrachtete Zeitintervall zu einer Auswertung der Operatorbedin-gung mit ausschließlich falsch (oder wahr) führen. Für den And-Operatorwird beispielsweise geprüft, ob in den Intervallmengen aller Eingängeder Wert 0 nicht enthalten ist. Ist dies der Fall, besteht die auszuge-bende Intervallmenge ausschließlich aus dem Intervall [1]. Enthält dieIntervallmenge mindestens eines Eingangs des And-Blocks hingegenausschließlich das Intervall [0], so lautet das Ausgabe-Intervall [0]. Trifftkeiner dieser beiden Fälle zu, wird das Intervall [0;1]1 ausgegeben. DerRelational-Operator-Block verfährt in seiner Intervallsemantik sehr ähn-lich. Es wird ebenfalls geprüft, ob das Zutreffen oder Nicht-Zutreffenseiner Operatorbedingung mit den gegebenen Intervallmengen der Block-eingänge überhaupt möglich ist. Entsprechend gibt der Block anstatt desBooleschen Intervalls [0;1]1 gegebenenfalls [0] oder [1] aus.

Sum. Der Sum-Block berechnet seine auszugebende Intervallmenge paar-weise über die eingehenden Intervallmengen. Hat der Block nur einenEingang, so sind dies die Intervallmengen der einzelnen Vektorelementedes Eingangssignals. Hat der Block mehrere Eingänge, so sind dies die


Intervallmengen der unterschiedlichen Eingangssignale mit gleichemVektorindex. Das weitere Vorgehen ist in beiden Fällen identisch, dahersei an dieser Stelle der Einfachheit halber der Fall mit mehreren Block-eingängen betrachtet. Die Intervallberechnung erfolgt dann im erstenSchritt für die Intervallmenge des ersten Blockeingangs und der hin-sichtlich einer Addition/Subtraktion neutralen Intervallmenge {[0]}. Imzweiten Schritt erfolgt die Intervallberechnung mit der aus dem ers-ten Schritt resultierenden Intervallmenge und der Intervallmenge deszweiten Blockeingangs. Dieser Schritt wiederholt sich entsprechend derAnzahl an Blockeingängen. Die aus dem allerletzten Schritt resultierendeIntervallmenge ist die gesuchte Intervallmenge. Die Intervallberechnungerfolgt paarweise, da jeder Blockeingang einer unterschiedlichen Ope-ration, das heißt Addition oder Subtraktion, unterliegen kann. Im Kernwendet die Intervallsemantik des Sum-Blocks die grundlegenden Re-chenregeln für Intervalle an. Ergänzend hierzu wird allerdings auch dieQuantisierung von Intervallen berücksichtigt. Besitzen zwei zu addieren-de oder subtrahierende Intervalle jeweils eine Quantisierung, so bildetder größte gemeinsame Teiler dieser Quantisierungen die Quantisierungdes resultierenden Intervalls.

Switch. Bei einem Switch-Block gilt es, zwei Fälle zu unterscheiden. Sokönnen der Kontrolleingang oder der Schwellwert-Parameter des Blocksmehrdimensional sein - oder eben nicht. Unabhängig von dieser Unter-scheidung lässt sich die Intervallsemantik eines Switch-Blocks folgender-maßen zusammenfassen: Es wird geprüft, ob die am Kontrolleinganganliegende(n) Intervallmenge(n) des betrachteten Zeitintervalls zu einerausschließlichen Weiterleitung des ersten oder dritten Blockeingangszum Blockausgang führen. Diese Prüfung erfolgt durch die Funktionenrt1 und rt3. Ist rt1 wahr, so entspricht die Intervallmenge am Ausgangdes Blocks der Intervallmenge am ersten Blockeingang. Entsprechendesgilt für rt3 und den dritten Blockeingang. Tritt keiner dieser beiden Fälleein, so wird die auszugebende Intervallmenge aus den Intervallmengenvon sowohl dem ersten als auch dem dritten Blockeingang gebildet.

Unit Delay. Der Unit-Delay-Block gibt für ein Zeitintervall [t1,t2]T anseinem Ausgang die Intervallmenge seines Eingangs für das Zeitintervall[t1−1,t2−1]T , das heißt um einen Zeitschritt versetzt, aus. Ist allerdingsder erste Zeitschritt einer Modellausführung im betrachteten Zeitintervallenthalten, so fließt auch der Initialwert des Unit-Delay-Blocks in dieauszugebende Intervallmenge ein.

Unbekannter Block. In Abschnitt 2.5 wurde an Techniken wie SIA dieAnforderung gestellt, dass sie mit unbekannten oder nicht-unterstütztenBlocktypen umgehen können müssen. Aus diesem Grund wird eineIntervallsemantik für unbekannte Blöcke definiert. Ein Signal, welchesaus einem als unbekannt betrachteten Block ausgeht, erhält dabei denWertebereich seines Datentyps zugewiesen. Dieses Vorgehen führt zwar


dazu, dass die Unerreichbarkeit mancher CGs unter Umständen nichterkannt wird - es ist aber alternativlos, es sei denn der Wertebereich einessolchen Signals wird vorab durch eine manuelle Angabe spezifiziert.

Um in den Darstellungen der Intervallsemantik-Definitionen die Über-sichtlichkeit zu wahren, wurden zwei Aspekte bewusst weggelassen. Fürdie berechneten Intervalle findet im Anschluss noch eine Prüfung derKonformität mit dem Datentyp des betreffenden Signals statt. Gegebe-nenfalls wird ein Intervall korrigiert, das heißt Intervallgrenzen oderQuantisierung angepasst. Zudem enthalten die dargestellten Definitio-nen keine Behandlung der möglichen Inaktivität eines Blocks sowie dermöglichen Zurücksetzung eines Blockzustands. Befindet sich ein Blockbeispielsweise in einem bedingt ausgeführten Subsystem, so berücksich-tigt seine Intervallsemantik auch die Intervallmengen der Kontrollsignaledieses Subsystems.

Blocktyp Intervallmenge der ausgehenden Signale

Constant

∀v∈N[1,n]: IS(s,v, ti) = {[cv]} mit s= sigout(b,1)

RelationalOperator


IS(s,v, ti) =

⎧⎨⎩{[1]} ,�T (X,Z)

{[0]} ,�F(X,Z)

{[0;1]1} , sonst

mit s= sigout(b,1)∧(1,X),(2,Z)∈IP(b, ti ,v) und

�T , �F :P(IV)×P(IV)→B

�T (X,Z)=

⎧⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎨⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎩

1 , (((•=„>“)∨(•=„�“))∧(min(X)•max(Z)))∨

(((•=„<“)∨(•=„�“))∧(max(X)•min(Z)))∨

((•=„=“)∧(∃[c]∈X∪Z:

c=min(X∪Z)=max(X∪Z)))∨

((•=„�=“)∧(∀ iv1∈X:∀ iv2∈Z: iv1∩ iv2=∅))0 , sonst

�F(X,Z)=

⎧⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎨⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎩

1 , (((•=„>“)∨(•=„�“))∧(max(X)◦min(Z)))∨

(((•=„<“)∨(•=„�“))∧(min(X)◦max(Z)))∨

((•=„=“)∧(∀ iv1∈X:∀ iv2∈Z: iv1∩ iv2=∅))((•=„�=“)∧(∃[c]∈X∪Z:

c=min(X∪Z)=max(X∪Z)))

0 , sonst

Tabelle 6: Intervallsemantik TL-konformer Blocktypen (Auszug)



LogicalOperator

Fall 1: n>1∨ •=¬


IS(s,v, ti) =

⎧⎨⎩{[1]} , �T (IP(b, ti ,v)){[0]} , �F(IP(b, ti ,v)){[0;1]1} , sonst

Fall 2: n=1∧ • �=¬

IS(s,1, ti) =

⎧⎨⎩{[1]} , �T (IV(b, ti)){[0]} , �F(IV(b, ti)){[0;1]1} , sonst

mit s= sigout(b,1) und �T , �F :P(N+×P(IV))→B

�T (X)=

⎧⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎨⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎩

1 , ((•=∧)∧(∀(i,Z)∈X:∀ iv∈Z:0�∈ iv))∨

((•=∨)∧(∃(i,Z)∈X:∀ iv∈Z:0�∈ iv))∨

((•= ↑)∧(∃(i,Z)∈X:∀ iv∈Z: iv=[0]))∨

(((•= ↓)∨(•=¬))∧(∀(i,Z)∈X:∀ iv∈Z: iv=[0]))∨

((•=⊕)∧(|{i | (i,Z)∈X∧∀ iv∈Z:0�∈ iv}| mod 2=1)∧

(∀(i,Z)∈X:∀ iv∈Z:0∈ iv⇒ iv=[0]))

0 , sonst

�F(X)=

⎧⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎨⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎩

1 , ((•=∧)∧(∃(i,Z)∈X:∀ iv∈Z: iv=[0]))∨

((•=∨)∧(∀(i,Z)∈X:∀ iv∈Z: iv=[0]))∨

(((•= ↑)∨(•=¬))∧(∀(i,Z)∈X:∀ iv∈Z:0�∈ iv))∨

((•= ↓)∧(∃(i,Z)∈X:∀ iv∈Z:0�∈ iv))∨

((•=⊕)∧(|{i | (i,Z)∈X∧∀ iv∈Z:0�∈ iv}| mod 2=0)∧

(∀(i,Z)∈X:∀ iv∈Z:0∈ iv⇒ iv=[0]))

0 , sonst

Sum

Fall 1: n>1


IS(s,v, ti) = � (n,Y,... �(2,Y, �(1,Y,{[0]})) ...)wobei Y=IP(b, ti ,v)

Fall 2: n=1

IS(s,1, ti) = �(d(b,1),Y,... �(2,Y, �(1,Y,{[0]}))...)wobei Y=IV(b, ti)

In beiden Fällen gilt: s= sigout(b,1)und �:N+×(N+×P(IV))×P(IV)→P(IV)

�(i,Y,X)=⋃

iv1∈X

⋃(i,Z)∈Y

⋃iv2∈Z

{◦(iv1, iv2,i)}

und ◦: IV× IV×N+→ IV

◦([a;b],[c;d],i)={[a+c;b+d] ,•(i)=„+“[a−d;b−c] ,•(i)=„−“

◦([a;b]q,[c;d]r,i)= ◦([a;b],[c;d],i)ggT(q,r)




Inport


∀v∈N[1,d(sb ,n)]: IS(s1,v, ti) = IS(s2,v, ti)mit s1= sigout(b,1)∧s2= sigin(sb,n)


IS(s,1, ti) = {specdom(b)} mit s= sigout(b,1)

Subsystem

∀pos∈N[1,|OPb |]: ∀v∈N[1,d(op(b, pos))]:

IS(s1,v, ti) = IS(s2,v, ti)mit s1= sigout(b, pos)∧s2= sigin(ob,1)∧ ob∈BCb

∧ btob=Outport∧(„m“, pos)∈PVob

Switch

Fall 1: max(n, d(b,2))>1

∀v∈N[1,max(n,d(b,2))]:

IS(s0,v, ti)=

⎧⎨⎩RI(1, ti ,v) , rt1(v)RI(3, ti ,v) , rt3(v)RI(1, ti ,v)∪RI(3, ti ,v) , sonst

Fall 2: n=d(b,2)=1

Fall 2.1: rt1(1)∀v∈N[1,d(b,1)]: IS(s,v, ti)=RI(1, ti ,v)

Fall 2.2: rt3(1)∀v∈N[1,d(b,3)]: IS(s,v, ti)=RI(3, ti ,v)

Fall 2.3: ¬ rt1(1)∧¬ rt3(1)∀v∈N[1,max(d(b,1),d(b,3))]:

IS(s,v, ti)=RI(1, ti ,v)∪RI(3, ti ,v)

mit s= sigout(b,1)

und RI :N+×TI×N+→P(IV)RI(i, ti ,v)=X | (i,X)∈IP(b, ti ,v)

und rt1 , rt3 :N+×TI→B

rt1(v, ti)=

⎧⎨⎩1 , (•∈{>,�}∧ min(CI)•tmin(n,v))

∨(•=„�=“∧∀ iv∈CI :0�∈ iv)0 , sonst

rt3(v, ti)=

⎧⎨⎩1 , (•∈{>,�}∧ max(CI)◦tmin(n,v))

∨(•=„�=“∧ min(CI)=max(CI)=0)

0 , sonst

mit CI :=RI(2, ti ,v)

Unbekannt

∀pos∈N[1,|OPb |]: ∀v∈N[1,d(s)]:

IS(s,v, ti) = {range(dtop(b, pos))}mit s= sigout(b, pos)




Unit Delay

∀v∈N[1,d(b,1)]:

IS(s1,v,[t1,t2]T) =

⎧⎪⎪⎪⎪⎪⎨⎪⎪⎪⎪⎪⎩

IS(s2,v,[t1−1,t2−1]T) , t1>0

{[amin(v,n)]} , t1=0

∪IS(s2,v,[0,t2−1]T) ∧t2>0

{[amin(v,n)]} , sonst

mit s1= sigout(b,1)∧s2= sigin(b,1)


3.1.2.2 Intervallpropagierung und Schleifenanalyse

Die aufgestellte Intervallsemantik findet bei SIA innerhalb einer Inter-vallpropagierung Anwendung. Ergebnis dieser Propagierung ist, dassjedes Signal des betrachteten Modells für die gesamte Länge einer Model-lausführung über Wertebereichsinformationen verfügt. Die Länge einerModellausführung ist hierbei durch die aus der Modelleingangsspezifi-kation ableitbare Anzahl der Zeitschritte specsteps gegeben.

SIA erstellt und nutzt für eine Intervallpropagierung die Ausführungs-reihenfolge der Blöcke eines Modells, wie sie auch für die konkreteAusführung eines Modells verwendet wird. Im Vergleich hierzu wirddie Ausführungsreihenfolge aber nicht wiederholend Zeitschritt für Zeit-schritt angewandt. Die Ausführungsreihenfolge wird zwar auch iterativangewandt, das heißt sie wird gegebenenfalls mehrfach durchlaufen -allerdings berechnet ein jeder Block hierbei seine Ausgabe für so vieleZeitschritte wie möglich, also nicht zwangsläufig für nur einen Zeitschritt.Hat ein Block seinen Ausgangssignalen Intervallangaben für sämtlicheZeitschritte zugewiesen, so wird dieser Block aus der Ausführungsreihen-folge entfernt und in den folgenden Iterationen nicht weiter betrachtet.

Dieses Vorgehen impliziert die Durchführung einer Schleifenanalyse.Hierzu sei erneut das Beispiel aus Abbildung 8 betrachtet. Der in demBeispielmodell enthaltene Unit-Delay-Block befindet sich in der Aus-führungsreihenfolge vor dem Sum-Block. Wird der Unit-Delay-Blockerstmals abstrakt ausgeführt, so bestimmt er seine auszugebende Inter-vallmenge lediglich für den ersten Zeitschritt, das heißt für das Zeitinter-vall [0,0]T . Der in der Ausführungsreihenfolge nachfolgende Sum-Blockist nun in der Lage, seine Intervallberechnung ebenfalls für das Zeitin-tervall [0,0]T durchzuführen. Der Unit-Delay-Block betrachtet dann beiseiner nächsten abstrakten Ausführung das Zeitintervall [1,1]T . DieserZyklus innerhalb des Modells wird so lange abgearbeitet, bis für alle 300Zeitschritte im Falle des Beispiels Intervallangaben gemacht sind.


Bei jeder seiner abstrakten Ausführungen wird für einen Block also zuerstbestimmt, für welche Zeitintervalle er seine Intervallsemantik überhauptanwendet. Der Unit-Delay-Block bildet hierbei eine Ausnahme. Denn wiezuvor gesehen, wird für die Intervallbestimmung dieses Blocks ein Zeit-intervall gewählt, welches einen Zeitschritt über die an seinem Eingangverfügbaren Zeitintervalle hinausgeht. Für alle gewöhnlichen Blöcke hin-gegen reichen die am Ausgang betrachteten Zeitintervalle nicht überdie an den Blockeingängen vorliegenden Zeitintervalle hinaus. DieserUmstand ist in Abbildung 9 veranschaulicht. Je abstrakter Ausführungeines Blocks erfolgt die Intervallbestimmung mitunter für mehrere Zeit-intervalle. Der Grund: Hat ein Block mehr als einen Eingang, so kann esvorkommen, dass an seinen Eingängen unterschiedliche Zeitintervallevorliegen. Diese überlappen sich eventuell. Um nicht an Genauigkeitbei der zeitlichen Zuordnung von Wertebereichsangaben einzubüßen,werden daher alle unteren und oberen Grenzen der an den Eingängenanliegenden Zeitintervalle bei der Bildung der Zeitintervalle für den oderdie Ausgänge des Blocks berücksichtigt (siehe Abbildung 9).

3.1.2.3 Intervallvereinigung

Nachdem ein Block seine Wertebereichsbestimmung für eine oder meh-rere Zeitintervalle vorgenommen hat, erfolgt eine sogenannte Intervall-vereinigung. Hierbei wird einerseits versucht, die enstandenen Inter-vallmengen jeweils, ohne Verlust in ihrer Aussagekraft, zu reduzieren.Andererseits werden aufeinanderfolgende Zeitintervalle mit identischen

Abbildung 9: Ableitung der Zeitintervalle für das Ausgangssignal einesBlockes von den Zeitintervallen der für den Ausgang rele-vanten Eingangssignale


Intervallmengen zusammengeführt. Beide Varianten einer Intervallverei-nigung sind für die Durchführbarkeit von SIA nicht zwingend notwendig.Sie vereinfachen jedoch die Intervallpropagierung, die einzelnen Inter-vallbestimmungen und die anschließende Erreichbarkeitsanalyse.

Betrachtet man beispielsweise die Intervallsemantik eines Sum-Blocks(siehe Tabelle 6), in der je Blockeingang eine paarweise Intervallbestim-mung erfolgt und hierbei zudem alle möglichen Intervallpaare aus denzwei betrachteten Intervallmengen miteinander verrechnet werden, sollteersichtlich sein, dass es durchaus zu großen resultierenden Intervallmen-gen kommen kann. Darüber hinaus sind die Intervallmengen oftmalsnicht redundanzfrei, das heißt sie enthalten Intervalle, die – zumindestteilweise – identische Werte(-bereiche) abdecken.

Die daher durchgeführte Intervallvereinigung verfährt wie folgt: Zu-nächst wird für jedes neu hinzugekommene Zeitintervall eine Redu-zierung der zugeordneten Intervallmenge A⊆P(IV) angestrebt. Hierbeiwird zwischen der Behandlung einelementiger und mehrelementigerIntervalle unterschieden. Im Anschluss daran werden die Intervallmen-gen aufeinanderfolgender Zeitintervalle auf Gleichheit überprüft und dieZeitintervalle gegebenenfalls zusammengelegt.

vereinigung einelementiger intervalle

Gegebenenfalls lassen sich einelementige Intervalle zu mehrelementigenIntervallen zusammenfassen. Die Intervallmenge {[0], [1], [2], [3]} könntebeispielsweise in {[0;3]1} überführt werden. Hierzu wird folgendes Vor-gehen vorgeschlagen. Abbildung 10 dient dabei zur Veranschaulichung.Aus den Werten der in A enthaltenen einelementigen Intervalle wird ineinem ersten Schritt ein Distanznetz aufgebaut. Dieses beschreibt den zah-lenmäßigen Abstand zwischen jedem Wertepaar. In Abbildung 10 ist einsolches für die Intervallmenge A = {[1], [3], [5], [9], [12], [25]} gegeben.

Im zweiten Schritt werden aus diesem Netz Gruppen von Werten abge-leitet. Eine Gruppe besteht hierbei aus Werten, die im Netz über Kantenmit identischen Distanzen verbunden sind. So ergibt sich für das Beispielunter anderem die Gruppe {1, 3, 5}2, wobei 2 die Distanz bezeichnet. DieGruppen werden in einem dritten Schritt gemäß folgender Kriteriensortiert: nach Gruppengröße (größere Anzahl enthaltener Werte) und,bei identischer Größe, nach Distanz (kleiner vor größer). Die Auflistungder Gruppen für das Beispiel in Abbildung 10 ist bereits nach diesenVorgaben sortiert.

Im vierten Schritt erfolgt eine Auswahl der Gruppen. Die sortierte Grup-penliste wird hierzu durchgegangen und eine Gruppe selektiert, wennkeiner ihrer enthaltenen Werte Teil einer anderen bereits selektiertenGruppe ist. Für das betrachtete Beispiel werden daher die Gruppen


Abbildung 10: Systematische Vereinigung von einelementigen Interval-len (Konstanten) durch Bildung eines Distanznetzes undAbleitung von Konstanten-Gruppen (Beispiel)

{1, 3, 5}2 und {9, 12}3 ausgewählt. Zum Schluss werden aus den selek-tierten Gruppen Intervalle gebildet und die darin enthaltenen Werte inder ursprünglichen Intervallmenge ersetzt. Dies bedeutet im Falle desBeispiels: A ′ = (A \ {[1], [3], [5], [9], [12]})∪ {[1;5]2, [9;12]3}

behandlung mehrelementiger intervalle

Es erfolgt ein paarweiser Vergleich aller Intervalle [a;b]∈A und [a;b]q∈Auntereinander, wobei nach fünf verschiedenen Fällen Ausschau gehaltenwird. Der Vergleich sei dabei verallgemeinernd wie folgt definiert.

∀ iv1∈A: ∀ iv2∈A: iv1 = iv2∧x ⇒ A ′=Y (35)

Die jeweilige Fallbedingung ist hierbei für x einzusetzen. Die in demjeweiligen Fall resultierende Intervallmenge entspricht Y.

fall 1 (gleichheit):

Grundvoraussetzung sind identische Intervallgrenzen:

lb(iv1)= lb(iv2)∧ ub(iv1)=ub(iv2)

Wenn zudem teilbare Intervall-Quantisierungen angegeben sind:

q(iv1)>0∧q(iv2)>0

∧(max(q(iv1), q(iv2)) mod min(q(iv1), q(iv2)))=0

Dann gilt für die resultierende Intervallmenge:

(A \ {iv1, iv2})∪ {[ lb(iv1); ub(iv1) ]min(q(iv1), q(iv2))}

fall 2 (teilmenge):

Grundvoraussetzung ist, dass sich das Intervall iv2 innerhalb derGrenzen von iv1 befindet: lb(iv1)� lb(iv2)∧ ub(iv1)�ub(iv2)


fall 2.1:

Wenn die Werte aus iv2 unter Beachtung der Quantisierungenbeider Intervalle tatsächlich in iv1 enthalten sind:

q(iv2)�q(iv1)>0∧(q(iv2) mod q(iv1))=0∧ lb(iv2)∈ iv1Dann gilt für die resultierende Intervallmenge: A \ {iv2}

fall 2.2:

Wenn für iv1 keine Quantisierung angegeben ist: q(iv1)=0

Dann gilt für die resultierende Intervallmenge: A \ {iv2}

fall 3 (überlappung oder direkter anschluss):

Grundvoraussetzung ist, dass die Intervalle mit Blick auf ihreGrenzen potenziell mindestens einen Wert miteinander teilen:

lb(iv1)� lb(iv2)∧ ub(iv1)� lb(iv2)

fall 3.1:

Wenn Quantisierungen vorliegen, müssen diese identisch seinund es ist sicherzustellen, dass die Intervalle tatsächlich mindes-tens einen Wert miteinander teilen:

q(iv1)=q(iv2)>0∧(ub(iv1) mod q(iv1))=(lb(iv2) mod q(iv1))


(A \ {iv1, iv2})∪ {[ lb(iv1); ub(iv2) ]q(iv1)}

fall 3.2:

Wenn keine Quantisierungen angegeben sind: q(iv1)=q(iv2)=0


(A \ {iv1, iv2})∪ {[ lb(iv1); ub(iv2) ]}

fall 4 (indirekter anschluss):

Wenn zwei Intervalle eine identische Quantisierung besitzen undwenn durch einen Schritt mit dieser Quantisierung über die obereGrenze des einen Intervalls hinaus die untere Grenze des anderenIntervalls erreicht wird:

q(iv1)=q(iv2)>0∧ ub(iv1)+q(iv1)= lb(iv2)


(A \ {iv1, iv2})∪ {[ lb(iv1); ub(iv2) ]q(iv1)}

Für jeden Vergleich zweier Intervalle aus einer Intervallmenge A gilt:Sobald einer der aufgeführten Fälle eintritt und eine modifizierte Inter-vallmenge A ′ entsteht, wird der Vereinigungsvorgang (siehe Definiti-on 35) abgebrochen und für A ′ erneut gestartet. Auf diese Weise werdenauch transitive Vereinigungsmöglichkeiten identifiziert. Dieses Proze-dere endet, sobald in einer Intervallmenge keiner der gelisteten Fälleauftritt.


vereinigung von zeitintervallen

Die für Zeitintervalle eines Signals berechneten Intervallmengen werdenzuerst nach dem zuvor beschriebenen Schema minimiert. Anschließendwird geprüft, ob die Intervallmengen A1 und A2 zweier aufeinander-folgender Zeitintervalle [t1, t2]T und [t2+1, t3]T identisch sind. ZweiIntervallmengen werden hierbei genau dann als identisch angesehen,wenn sie die gleiche Anzahl an Intervallen beinhalten und jedes Intervallaus der einen Menge auch in der anderen Menge enthalten ist. Ist diesder Fall, so werden die zwei Zeitintervalle durch ein neues Zeitintervall[t1, t3]T ersetzt und diesem die Intervallmenge A1 zugeordnet.

SIA beschränkt sich an dieser Stelle auf identische Intervallmengen undvernachlässigt gleiche Intervallmengen. Zwei Intervallmengen sind ge-nau dann gleich, wohlgemerkt aber nicht identisch, wenn alle in denIntervallen einer der Intervallmengen enthaltenen Werte jeweils auch inmindestens einem Intervall der anderen Intervallmenge enthalten sind.Die Intervallmengen {[1,2]1, [4,5]1} und {[1,4]3, [2,5]3} sind beispielsweisegleich. Ein Vorgehen zur Erkennung der Gleichheit vorausgesetzt, könn-ten auch die Zeitintervalle gleicher Intervallmengen vereinigt werden.

3.1.3 modelltransformationen

Die durch die abstrakte Intervall-Interpretation ermittelten Signalwer-tebereiche machen es in bestimmten Fällen möglich, die durch SIA be-trachtete Repräsentation eines SL/TL-Modells zu vereinfachen. Diese(gegebenenfalls vereinfachte) Modellrepräsentation wird nicht nur durchSIA, sondern auch durch die anderen in dieser Arbeit vorgestellten stati-schen Voranalysen sowie durch den SMT-Testdatengenerierungsansatzverwendet. Wie in den Abschnitten zu diesen Techniken ersichtlich wird,können sich Vereinfachungen der Modellrepräsentation im Rahmen vonSIA vorteilhaft auf die Effizienz und die erzielten Ergebnisse der anderenTechniken auswirken. Da die Modelltransformationen im Rahmen vonSIA und auch in ihrer Auswirkung auf die anderen Techniken dennocheine untergeordnete Rolle einnehmen, wird in den folgenden Zeilenauf eine formale und umfassende Betrachtung der Transformationenverzichtet.

Die zur Vereinfachung der Modellrepräsentation durchgeführten Modell-transformationen erfolgen bei SIA während der Intervallpropagierung.Wird ein Block abstrakt ausgeführt, so wird zunächst geprüft, ob dieZeitintervalle aller seiner Eingänge bereits vollständig sind. Vollständigbedeutet, dass die Zeitintervalle sämtliche betrachtete Zeitschritte abde-cken. Ist dies der Fall, so erfolgt vor der Intervallberechnung eine Prüfungvon Transformationsbedingungen. Diese Transformationsbedingungen


sind Block-spezifisch und betrachten die an den Eingängen anliegen-den Intervallmengen. Trifft eine Transformationsbedingung zu, so wirddie Modellrepräsentation durch Anwendung von Transformationsope-rationen transformiert. Die nachfolgende Intervallbestimmung für dieBlockausgänge wird, je nach der Art der Transformationsoperationen,anschließend durchgeführt oder auch nicht. Wird sie durchgeführt, sowerden auch nach ihr noch weitere Transformationsbedingungen ge-prüft und gegebenenfalls Transformationsoperationen angewandt. DieTransformationsbedingungen betrachten hierbei allerdings die Intervall-mengen der Blockausgänge. Zudem sind diese nicht Block-spezifisch.In jedem Fall gilt aber auch hier die Vorbedingung der Zeitintervall-Vollständigkeit.

transformationsoperationen

Folgende drei Arten von Transformationsoperationen werden angewandt:

1. Ersetzung des betrachteten Blocks durch einen anderen Block odermehrere andere Blöcke

2. Entfernung des betrachteten Blocks und Vereinigung seiner Ein-und Ausgangssignale

3. Entfernung ausgewählter Eingangsports des betrachteten Blocks

In allen drei Fällen kann es sein, dass ein im Modell rückwärtsgerichteterEntfernungsprozess angestoßen wird. Dieser entfernt Signale und Blöcke,die zu keinem anderen Block mehr führen und die in keinem Zusam-menhang mit einem CG stehen. Der Entfernungsprozess geht sogar soweit, dass beispielsweise Signale ohne Zielport oder Ausgangsports ohneSignale existieren können. Die Umsetzungen von SIA und den anderen indieser Arbeit vorgestellten Techniken können mit derart unvollständigenModellrepräsentationen allerdings umgehen.

Mit dem Entfernen und Hinzufügen von Blöcken gilt es selbstverständ-lich auch, die Ausführungsreihenfolge der laufenden Intervallpropagie-rung zu aktualisieren.

transformationsbedingungen

Die Transformationsbedingungen, welche die Intervallmengen der Block-eingänge betrachten, können vielfältiger Natur sein. Für fast jeden fürSL/TL-Modelle verfügbaren Blocktypen lassen sich Überlegungen anstel-len, wie sich die Gestaltung der Wertebereiche an den Blockeingängenauf die Blockfunktionalität auswirkt und ob sich hieraus Vereinfachungenim Modell ableiten lassen. Folgend seien drei Beispiele aufgeführt:


• Logical Operator: Setzt ein solcher Block beispielsweise den AND-Operator ein und gibt es einen Eingang, dessen Intervallmen-gen aller vorhandener Zeitintervalle durchgängig ausschließlichdas Intervall [1] beinhalten, so kann dieser Eingang entfernt wer-den. Bleibt hierdurch nur ein Eingang übrig, so bietet es sich an,den Block durch einen Relational-Operator-Block (mit Ungleich-Operator) zu ersetzen. In diesen Block geht dann zum einen dasverbliebene Eingangssignal des AND-Blocks ein. Zum anderenwird ein Constant-Block mit der Konstanten 0 hinzugefügt undmit dem Relational-Operator-Block verbunden.

• Abs: Ist der Wertebereich des Blockeingangs durchgehend nicht-negativ, so kann der Block entfernt werden. Das Ein- und Aus-gangssignal werden vereinigt.

• Switch: Falls sich der Wertebereich des zweiten Eingangs derartgestaltet, dass für alle Zeitintervalle eine ausschließliche Weiterlei-tung des ersten oder dritten Eingangs zum Ausgang erfolgt, kannder Block ebenfalls entfernt werden. Das Signal des ersten oderdritten Eingangs wird dann mit dem Ausgangssignal vereinigt.

Für die Intervallmengen der Ausgänge eines Blocks berücksichtigt SIAeine Transformationsbedingung, die für alle Blocktypen gültig ist. ZurErfüllung dieser Bedingung muss für jeden Blockausgang Folgendesgelten: die Intervallmengen aller Zeitintervalle enthalten ausschließlichein einelementiges Intervall mit dem gleichen Wert. Handelt es sichum ein Vektorsignal, so muss diese Eigenschaft je Vektorelement gelten.Ist die Bedingung erfüllt, so wird der betrachtete Block durch einenConstant-Block oder mehrere Constant-Blöcke ersetzt - je nachdem wieviele Ausgänge der betrachtete Block hat.

3.1.4 erreichbarkeitsanalyse

Ist die Intervallpropagierung beendet, so liegen die Wertebereichsanga-ben für alle Modellsignale vor. SIA überprüft dann die Erreichbarkeit derCGs. Die diesem Zweck dienende Erreichbarkeitsanalyse erfolgt in dreiSchritten:

1. Ersetzung von Signalen in CG-Ausdrücken durch Konstanten

2. Normierung der CG-Ausdrücke

3. Prüfung der CG-Erreichbarkeit

Der erste Schritt betrifft lediglich die Signale, welche durch die Inter-vallbestimmung als konstant identifiziert wurden. Ein Signal wird imKontext von SIA als konstant bezeichnet, wenn die Intervallmengenaller Zeitintervalle ausschließlich ein einelementiges Intervall mit dem


gleichen Wert beinhalten. Ist ein Signal konstant, so werden alle Vor-kommnisse dieses Signals in CG-Ausdrücken durch den entsprechendenkonstanten Wert ersetzt. Im zweiten Schritt erfolgt eine Sortierung inner-halb der CG-Ausdrücke, um die anschließende Erreichbarkeitsprüfungzu erleichtern. Hierbei werden insbesondere Vergleiche von Signalenmit Konstanten in eine einheitliche Ordnung gebracht. Aus dem Aus-druck 5>s wird beispielsweise s<5. Die im dritten Schritt durchgeführteErreichbarkeitsprüfung wird im Folgenden detailliert vorgestellt.

Jedes CG ist durch seinen Ausdruck gegeben. Wie in Definition 14 ange-geben, kann ein CG aus Teilausdrücken bestehen. Sowohl CG-Ausdrückeals auch darin enthaltene Teilausdrücke seien in den folgenden Aus-führungen verallgemeinernd als ϕ∈E bezeichnet. Jedes ϕ besitzt einenZustand, der angibt, ob ϕ unerreichbar ist (Zustand UNSAT), ob ϕ un-abhängig von den bei einer Modellausführung verwendeten Testdatenstets erreicht ist (Zustand SAT) oder ob ϕ nur bei Verwendung passenderTestdaten erreicht werden kann (Zustand OPEN). Den Zustand gibt dieAbbildung st wieder:

st : E → {UNSAT, SAT,OPEN} (36)

Wie in den folgenden Definitionen ersichtlich wird, ist es für ein ϕ

mitunter relevant, zu welchen Zeitschritten einer potentiellen Modellaus-führung der Zustand SAT oder UNSAT eintritt. Die Abbildung S@(ϕ)gibt daher die Menge der Zeitschritte an, welche für den Zustand SATursächlich sind. Analog hierzu ist U@(ϕ) für UNSAT zu sehen.

S@ ,U@ : E → P(N) (37)

Voraussetzung zur Anwendung von S@(ϕ) ist allerdings, dass st(ϕ)= SATgilt. Denn nur dann ist S@(ϕ)=∅. Für U@(ϕ) gilt eine solche Einschrän-kung nicht, da es auch Zeitschritte enthalten kann, bei denen ϕ unerfüll-bar ist, ohne dass jedoch ϕ dadurch insgesamt unerfüllbar wird. Hierzumüsste ϕ nämlich zu jedem betrachteten Zeitschritt unerfüllbar sein.

Zudem sei AT die Menge aller Zeitschritte einer Modellausführung:

AT = N[0, specsteps −1] (38)

Der Zustand von ϕ ergibt sich unter Verwendung der Signalwerteberei-che wie im Folgenden dargestellt. Es wird hierbei zwischen den verschie-denen Formen, die ϕ haben kann, unterschieden.

relationaler ausdruck mit zwei konstanten

Kommt es im ersten Schritt der Erreichbarkeitsanalyse zur Ersetzung vonSignalen mit Konstanten in CG-Ausdrücken, so können sich Ausdrückeder Form ϕ = c1•c2 mit •∈{>,�,<,�,=,�=} und c1,c2∈R ergeben. Der


Zustand von ϕ sowie die Mengen der Zeitschritte, zu denen ϕ stetserfüllt und nicht erfüllbar ist, werden folgendermaßen definiert. Da keineSignale in den Ausdruck involviert sind, spielen Signalwertebereiche andieser Stelle keine Rolle.

st(c1•c2) ={SAT , c1•c2UNSAT , sonst

S@(c1•c2) ={AT , st(c1•c2)= SAT∅ , sonst (39)

U@(c1•c2) ={AT , st(c1•c2)=UNSAT∅ , sonst

Der Zustand ergibt sich einzig aus dem Zutreffen des relationalen Aus-drucks. Je nach Auswertung zu wahr oder falsch enthalten S@(ϕ) oderU@(ϕ) alle betrachteten Zeitschritte.

relationaler ausdruck mit signal und konstante

Für die Verknüpfung eines Signals s∈S (Vektorindex v∈N[1, d(s)]) miteiner Konstanten c∈R über einen relationalen Operator •∈{>,�,<,�,=,�=}greift die Zustandsdefinition auf den Wertebereich des Signals zurück:

st(sv•c) ={SAT , ∃ ti∈T(s,v): ◦(IS(s,v, ti),c)UNSAT , ∀ ti∈T(s,v): �(IS(s,v, ti),c)OPEN , sonst

S@(sv•c) =⋃

[t1,t2]T∈T(s,v):◦(IS(s,v,[t1,t2]T ),c)

N[t1,t2] (40)

U@(sv•c) =⋃

[t1,t2]T∈T(s,v):�(IS(s,v,[t1,t2]T ),c)

N[t1,t2]

Die Funktionen �,◦ : P(IV)× R → B prüfen für die Intervallmenge einesZeitintervalls ti und die in ϕ enthaltene Konstante c, ob die Intervalle die-ser Intervallmenge dazu führen, dass ϕ in ti unerfüllbar oder stets erfülltist. S@(ϕ) und U@(ϕ) sammeln jeweils die Zeitschritte der Zeitintervalle,in denen einer dieser beiden Fälle gilt.

◦ (X,c)=

⎧⎪⎨⎪⎩min(X) • c , •∈{>,�}max(X) • c , •∈{<,�}min(X)=max(X)=c , •=„=“∀ iv∈X: c∈ iv , •=„�=“

(41)


� (X,c)=

⎧⎪⎪⎪⎪⎨⎪⎪⎪⎪⎩

c�max(X) , •=„>“c>max(X) , •=„�“c�min(X) , •=„<“c<min(X) , •=„�“∀ iv∈X: c∈ iv , •=„=“min(X)=max(X)=c , •=„�=“

Ginge es beispielsweise um den Ausdruck s>5, so ist dieser unerfüllbar,wenn der größtmögliche Wert aus dem Wertebereich von s in jedemZeitintervall nicht größer als die Konstante 5 ist.

relationaler ausdruck mit zwei signalen

Für die Verknüpfung zweier Signale s1,s2∈S (Vektorindizes v∈N[1, d(s1)]

und w∈N[1, d(s2)]) über einen relationalen Operator •∈{>,�,<,�,=,�=}leitet sich der Zustand aus den Wertebereichen beider Signale ab:

st(sv•sw) =

⎧⎪⎪⎪⎪⎨⎪⎪⎪⎪⎩

SAT ,∃[t1,t2]T∈T(s1,v): ∃[t3,t4]T∈T(s2,w):(t1�t4∧t3�t2)⇒◦(G,H)

UNSAT ,∀[t1,t2]T∈T(s1,v): ∀[t3,t4]T∈T(s2,w):(t1�t4∧t3�t2)⇒ �(G,H)

OPEN , sonst

S@(sv•sw) =⋃

[t1,t2]T∈T(s1,v)

⋃

[t3,t4]T∈T(s2,w):t1�t4∧t3�t2

∧◦(G,H)

N[max(t1,t3),min(t2,t4)] (42)

U@(sv•sw) =⋃

[t1,t2]T∈T(s1,v)

⋃

[t3,t4]T∈T(s2,w):t1�t4∧t3�t2

∧�(G,H)

N[max(t1,t3),min(t2,t4)]

Hierbei bezeichnen G=IS(s1,v,[t1,t2]T) und H=IS(s2,w,[t3,t4]T) die Inter-vallmengen eines Zeitintervalls der beiden Signale. Die Hilfsfunktionen�,◦ : P(IV)× P(IV) → B geben für zwei Intervallmengen an, ob diesezu einer Unerfüllbarkeit oder garantierten Erfüllung des relationalenAusdrucks führen. S@(ϕ) und U@(ϕ) sammeln auch hier jeweils dieZeitschritte, in denen einer dieser beiden Fälle eintritt.

◦ (X,Y)=

⎧⎪⎨⎪⎩min(X)•max(Y) , •∈{>,�}max(X)•min(Y) , •∈{<,�}min(X)=min(Y)=max(X)=max(Y) , •=„=“∀ iv1 ∈X: ∀ iv2 ∈Y: iv1 ∩ iv2=∅ , •=„ �=“

(43)


� (X,Y)=

⎧⎪⎪⎪⎪⎨⎪⎪⎪⎪⎩

min(Y)�max(X) , •=„>“min(Y)>max(X) , •=„�“max(Y)�min(X) , •=„<“max(Y)<min(X) , •=„�“∀ iv1 ∈X: ∀ iv2 ∈Y: iv1 ∩ iv2=∅ , •=„=“min(X)=min(Y)=max(X)=max(Y) , •=„�=“

Auch hierzu ein Beispiel: Der Ausdruck s1=s2 ist unerfüllbar, wenn dieSchnittmenge der Signalwertebereiche von s1 und s2 leer ist, das heißtdie Wertebereiche keinen Wert gemeinsam haben.

logischer ausdruck

Besteht ϕ aus einer logischen Verundung von n�2 Teilausdrücken ϕi

(mit i∈N[1,n]), so gilt für den Zustand:

st(n∧

i=1

ϕi) =

⎧⎪⎪⎨⎪⎪⎩UNSAT , ∃j∈N[1,n]: st(ϕj)=UNSAT

SAT , (∀j∈N[1,n]: st(ϕj)= SAT)∧n⋂

k=1

S@(ϕk)=∅OPEN , sonst

S@(n∧

i=1

ϕi) =

n⋂

j=1

S@(ϕj) (44)

U@(n∧

i=1

ϕi) =

n⋃

j=1,st(ϕj)=UNSAT

U@(ϕj)

Existiert also ein unerfüllbarer Teilausdruck, so ist die Verundung allerTeilausdrücke ebenfalls unerfüllbar. Der Gesamtausdruck ist hingegenstets erfüllt, wenn alle seine Teilausdrücke stets erfüllt sind.

Im Falle einer logischen Veroderung von n�2 Teilausdrücken ϕi (miti∈N[1,n]) gilt für den Zustand:

st(n∨

i=1

ϕi) =

⎧⎨⎩UNSAT , ∀j∈N[1,n]: st(ϕj)=UNSATSAT , ∃j∈N[1,n]: st(ϕj)= SATOPEN , sonst

S@(n∨

i=1

ϕi) =

n⋃

j=1,st(ϕj)= SAT

S@(ϕj) (45)

U@(n∨

i=1

ϕi) =

n⋂

j=1

U@(ϕj)


Anders als bei der Verundung müssen alle Teilausdrücke unerfüllbar sein,damit der Gesamtausdruck unerfüllbar ist. Existiert hingegen mindestensein stets erfüllter Teilausdruck, so ist der Gesamtausdruck automatischauch stets erfüllt.

Der Zustand einer logischen Negation ϕ = ¬ϕ ′ sei wie folgt definiert:

st(¬ϕ ′) =

⎧⎨⎩UNSAT , st(ϕ ′)= SAT∧| S@(ϕ ′)|= specstepsSAT ,U@(ϕ ′)=∅OPEN , sonst

S@(¬ϕ ′) = U@(ϕ ′) (46)

U@(¬ϕ ′) = S@(ϕ ′)

Der Ausdruck ϕ ist unerfüllbar, wenn ϕ ′ zu allen betrachteten Zeitschrit-ten stets erfüllt ist. Existiert hingegen mindestens ein Zeitschritt, zu demϕ ′ unerfüllbar ist, so ist ϕ als stets erfüllt anzusehen.

Mit dieser Betrachtung ist die Erreichbarkeitsanalyse von SIA vollum-fänglich beschrieben. Zusammenfassend ist zu betonen, dass SIA durchseine abstrakte Intervall-Analyse eines SL/TL-Modells, gepaart mit derin diesem Abschnitt vorgestellten Erreichbarkeitsanalyse, dazu in derLage ist, eine Teilmenge unerreichbarer CGs zu identifizieren. Darüberhinaus erkennt SIA auch CGs, welche unabhängig von der Testdatenwahlerfüllt sind. Beide Kategorien von CGs können bei einer Testdatenge-nerierung, ganz gleich ob ein suchbasiertes Verfahren oder ein andererAnsatz zum Einsatz kommen, ausgeschlossen werden. Der in dieserArbeit verwendete suchbasierte Ansatz sollte seine Effizienz durch einevorherige Anwendung von SIA steigern können – vorausgesetzt, für dasbetrachtete Modell existieren unerreichbare CGs und der Aufwand vonSIA selbst hält sich, wie aufgrund der Vorgehensweise dieser Technikzu vermuten ist, in einem überschaubaren Rahmen. Die in Kapitel 6vorgestellten Fallstudien untersuchen neben der Auswirkung von SIAauf die Testdatengenerierung auch diesen Aspekt.

3.1.5 verwandte arbeiten

Die Durchführung einer Intervallanalyse, das heißt die Betrachtung derWertebereiche von Programmvariablen, stellt seit den Anfängen der ab-strakten Interpretation [30] eine algorithmische Herausforderung dar[45]. Die statische Interpretation eines Programms ist aus Komplexitäts-gründen meist an Abstraktionstechniken oder Abschätzungen gebunden.Genauigkeit und Optimalität derartiger Analysen stehen im Allgemei-nen im Konflikt mit der Durchführbarkeit derselben. Eine Vielzahl anArbeiten beschäftigt sich daher mit Intervallanalysen. Insbesondere im


Bereich des Compilerbaus, der sich dem Entwurf von Übersetzern (eng-lisch: Compiler) für die Wandlung von Programmcode in ausführbarenMaschinencode widmet, finden Intervallanalysen Anwendung. Wertebe-reichsinformationen werden dabei vielfältig genutzt, beispielsweise zurErkennung von totem, also nicht-erreichbarem Code [23, 35].

Intervalle als Teil einer abstrakten Interpretation nutzt beispielsweise dasWerkzeug ASTRÉE [32]. Dieses dient der Ermittlung von Laufzeitfehlernin C-Programmen. Geht es um den Anwendungsfall der vorliegenden Ar-beit, die Erkennung unerreichbarer Zustände, so existieren wohlgemerktauch Ansätze, die nicht auf eine abstrakte Interpretation bauen. Goldberget al. prüfen die Erreichbarkeit von Programmpfaden zum Beispiel mit-hilfe von Constraint-Solving-Techniken und durch Theorembeweis [50].Im betrachteten Kontext, der Anwendung für SL/TL-Modelle, ist dieSkalierbarkeit eines solchen Ansatzes allerdings als kritisch zu erachten(siehe Abschnitt 2.3.1).

Der Codegenerator TL sowie aktuelle Versionen des SL-Werkzeugs be-trachten ebenfalls die Wertebereiche der Signale innerhalb eines SL- oderSL/TL-Modells. Die Analysen dienen hierbei der Optimierung des ge-nerierten Codes und der Ermittlung geeigneter Signal-Datentypen und-Skalierungen für die Codegenerierung. Die verwendete Technik ist inbeiden Fällen allerdings nicht veröffentlicht. Es ist allerdings zu erken-nen, dass die Fähigkeiten der Werkzeuge zur Wertebereichserkennungbegrenzt sind. Im Falle von Schleifen beispielsweise kann der NutzerAngaben zu den Wertebereichen machen. Dies spricht dafür, dass keineSchleifenanalyse, wie sie SIA enthält, erfolgt. Neben diesen Funktionalitä-ten in SL und TL existiert des Weiteren das Werkzeug Polyspace [115] zurstatischen Analyse von C-Code. Polyspace ist in der Lage, Wertebereichs-angaben für Programmvariablen zu machen. Selbstverständlich lässt sichdas Werkzeug auch für den aus einem SL/TL-Modell generierten C-Codeeinsetzen. Seine statischen Analysen führt Polyspace allerdings nicht imModell durch.

Die am nächsten mit SIA verwandte Arbeit stammt von Wang et al. [125].Obwohl sie sich mit der Anwendung für Java-Programme und nicht etwafür SL/TL-Modelle oder andere verwandte Modellsprachen beschäftigt,so steht ihr Ansatz der SIA-Technik bezüglich Vorgehen und Ausrich-tung doch sehr nahe. Wang et al. verwenden eine abstrakte Interpretationmittels Intervallen, um unerreichbare Pfade in Java-Programmen zu er-mitteln. Hierbei setzen sie Intervallmengen je Programmvariable ein.Zudem definieren sie Mengenoperationen und die grundlegenden ma-thematischen Operationen für den Umgang mit Intervallmengen. SIAbaut auf diesen Grundlagen auf und zeichnet sich durch folgende Eigen-schaften und Beiträge aus:


1. Verwendung einer Spezifikation der Eingänge (Modelleingangs-spezifikation), um präzisere Wertebereichsangaben (mit engerenGrenzen) zu erhalten

2. Definition einer Intervallsemantik für SL/TL-Blöcke

3. Erweiterung des Intervallmengen-Konzepts von Wang et al. umzeitliche Dynamik (Zuordnung über Zeitintervalle)

4. Intervallpropagierung mit Schleifenanalyse unter Berücksichtigungder Ausführungssemantik eines SL-Modells

5. Modelltransformationen innerhalb der Intervallpropagierung

Zum letzten Punkt ist zu ergänzen, dass es Arbeiten gibt, die sich explizitmit der Transformation von SL-Modellen auseinandersetzen – beispiels-weise von Tran et al. [119]. Der Sinn und Zweck von Transformationenliegt bei SIA allerdings nicht in der Unterstützung und Teilautomatisie-rung der Modellbildung. Modelltransformationen werden in SIA durchEigenheiten der ermittelten Wertebereiche getriggert und dienen derVereinfachung einer Modellrepräsentation für an SIA anschließende Ana-lysen. Das zugrunde liegende SL/TL-Modell wird von SIA dabei zudemnicht abgeändert.


3.2 modelleingang-abhängigkeits-ermittlung

Die zweite der drei in dieser Arbeiten vorgestellten statischen Voranaly-sen wird mit dem Kürzel SDA bezeichnet. SDA steht für die englischeBezeichnung Signal Dependency Analysis (zu Deutsch: Signalabhängig-keitsanalyse). In diesem Abschnitt werden die Zielsetzung und das Vor-gehen von SDA beschrieben. Eine Einordnung der Technik im Vergleichmit verwandten Arbeiten erfolgt im Anschluss.

3.2.1 ziel

Das Problem der Größe des bei einem suchbasierten Test abzusuchen-den Suchraums wurde bereits in Abschnitt 2.5 erörtert. Die Anzahl derDimensionen des Suchraums wächst im betrachteten Anwendungsbe-reich maßgeblich mit der Anzahl der Modelleingänge, in zweiter Instanzallerdings auch mit den in der Modelleingangsspezifikation gemachtenAngaben. Hierbei kommen insbesondere die spezifizierte zeitliche Längeder Signale sowie Parameter, welche sich auf die Anzahl der Signalseg-mente auswirken, zum Tragen. Die Modelleingangsspezifikation stellt sogesehen bereits ein Instrument dar, mit dem manuell, durch Experten-wissen über das Testobjekt, Einschränkungen des Suchraums getroffenwerden können.

Einen Umstand adressiert die Modelleingangsspezifikation allerdingsnicht: Die Erfüllung der meisten CGs hängt zwar von einer geeignetenTestdatenwahl ab, allerdings gibt es im Falle vieler CGs Modelleingänge,deren Belegung mit wie auch immer gearteten Signalen keinerlei Ein-fluss auf die Erfüllung des CG nimmt. Derartige Modelleingänge sindirrelevant für die Testdatensuche eines bestimmten CG. Das eingesetz-te Suchverfahren besitzt allerdings keinerlei Kenntnis von solch einerTatsache. Es erzeugt nicht nur einmalig Signale für unter Umständenirrelevante Modelleingänge, sondern die Operatoren des Suchverfah-rens konzentrieren sich zum Zwecke der Suche auch auf Änderungendieser Signale. Dieses Vorgehen ist der Effizienz einer suchbasiertenTestdatengenerierung nicht zuträglich.

Die SDA-Technik ist in der Lage, festzustellen, welche Modelleingängefür die Erfüllung eines CG irrelevant sind. Wie der Name der Technikverrät, analysiert sie hierzu Abhängigkeiten zwischen den Signalen einesSL/TL-Modells. Das Vorgehen dieser Analyse und die Miteinbeziehungder Analyseergebnisse in die Testdatensuche werden im Folgenden be-handelt.

3.2 modelleingang-abhängigkeitsermittlung 97

3.2.2 technik

Ein motivierendes Beispiel soll als Einstieg in die folgenden Erläuterun-gen dienen. Abbildung 11 zeigt ein kleines Modell mit fünf Modellein-gängen. Wird bei einem Strukturtest beispielsweise eine Bedingungs-überdeckung angestrebt, so gilt es unter anderem, an den Eingängendes im Modell enthaltenen AND-Blocks ein wahr und falsch zu erreichen.Ein wahr bedeutet in diesem Zusammenhang, dass jedes in den Blockeingehende Signal mindestens einmal einen Wert enthält, der ungleich0 ist. Ein solches CG ist in der Abbildung dargestellt: s4 = 0. Um nunfestzustellen, welche Modelleingänge für das Erreichen dieses CG rele-vant oder irrelevant sind, verfolgt SDA die Einwirkungen auf die an demCG beteiligten Signale bis hin zu den Modelleingängen zurück. Das andem Beispiel-CG beteiligte Signal s4 entsteht in seiner Wertebelegungdurch die Anwendung des NOT-Blocks für Signal s3. Dies bedeutet, s4hängt von s3 ab – wie in dem Abhängigkeitsgraphen im unteren Teilder Abbildung dargestellt. Signal s3 wiederum hängt von den Signalens2 und s1 ab. Signal s2 entstammt einem Constant-Block, daher endet

(a) Beispielmodell mit ausgewähltem Überdeckungsziel

(b) Ausschnitt aus dem Signalabhängigkeitsgraphen für das Modell in (a)

Abbildung 11: Einführendes Beispiel zur Modelleingang-Abhängig-keitsermittlung


die Zurückverfolgung an dieser Stelle. Signal s1 hingegen stammt auseinem Modelleingang. Dieser stellt somit den einzigen für das betrach-tete CG relevanten Modelleingang dar. Dieses Beispiel demonstriert dieGrundzüge der SDA-Technik. Während der Zusammenhang zwischenCG und Modelleingängen in einem solch kleinen Modell wohlgemerktoffensichtlich ist, ist dieser in größeren Modellen im Allgemeinen wederderart einfach ablesbar, noch derart trivial ableitbar.

signalabhängigkeitsgraph

Wie im Beispiel angedeutet, sammelt SDA die zwischen Modellsigna-len existierenden Abhängigkeiten in einem Abhängigkeitsgraphen. Diesist ein gerichteter Graph, in dem die Knoten Signale, beziehungsweiseSignal-Vektorelemente im Falle vektorisierter Signale, darstellen. EineKante bezeichnet die Abhängigkeit eines Signals von einem Anderen. DieAbhängigkeitsbeziehung trifft dabei keine Aussage darüber, wie sich dieBeschaffenheit eines Signals auf die Beschaffenheit eines anderen Signalsauswirkt, sondern gibt lediglich an, dass die Wertebelegung des einen Si-gnals Einfluss auf die Wertebelegung des Anderen nimmt. Horwitz et al.unterscheiden bei einer hierzu verwandten Analyse für Programmcodezwischen Datenabhängigkeit und Kontrollabhängigkeit [67]. Bezugneh-mend auf diese Unterscheidung ist festzustellen, dass es sich bei demGroßteil der Signalabhängigkeiten innerhalb eines SL/TL-Modell fürgewöhnlich um Datenabhängigkeiten handelt. In wenigen Ausnahmengilt es allerdings auch Kontrollabhängigkeiten zu berücksichtigen, bei-spielsweise im Falle bedingt ausgeführter Subsysteme. Diese spiegelnsich in dem Abhängigkeitsgraph, den SDA aufbaut, jedoch letzten Endesauch als Datenabhängigkeiten wieder. Es wird nämlich nicht erfasst, un-ter welcher Bedingung beispielsweise ein solches Subsystem ausgeführtwird, sondern lediglich die Tatsache, dass das Kontrollsignal des bedingtausgeführten Subsystems an der Wertebelegung eines Signals innerhalbdieses Subsystems beteiligt ist.

Ein Signal kann im Allgemeinen nicht nur von einem, sondern von meh-reren anderen Signalen abhängig sein. Dies berücksichtigend beschreibtdie folgende Abbildung eine Abhängigkeitsbeziehung zwischen einem Si-gnal (mit Vektorindex-Angabe) und einer Menge von Signalen (ebenfallsjeweils mit Vektorindex-Angabe):

dep−−−→ : SN+ ×P(SN+

) (47)

Im Folgenden wird diese Abbildung in Infixnotation verwendet. Hängtein Signal s1 beispielsweise von den Signalen s2 und s3 ab, so wird dies

durch s1dep−−−→ {s2, s3} ausgedrückt. Vektoren-Indizes werden auch hier

weggelassen, sofern Signale eindimensional sind.


Grundsätzlich gilt, dass die aus einem Block ausgehenden Signale vonden in den Block eingehenden Signalen abhängen – und die Analyse derAbhängigkeiten somit basierend auf der Modellsyntax erfolgt. Genau ge-nommen sind die Signalabhängigkeiten jedoch Block-spezifisch. So kannes zum einen sein, dass bei einem Block mit mehreren Ausgangssignalenein Ausgangssignal nur von einem Teil der Eingangssignale abhängt.Zum anderen verarbeiten Blöcke gegebenenfalls Vektorsignale. Hierbeihängt ein Vektorelement des Ausgangssignals eines Blocks häufig nurvon bestimmten Vektorelementen der Blockeingangssignale ab. Andersausgedrückt lässt sich auch sagen: Rein Syntax-basiert ermittelte Ab-hängigkeiten können durch Berücksichtigung der Blockfunktionalitätenzum Teil wieder aus dem Abhängigkeitsgraph entfernt werden. Der soentstehende Abhängigkeitsgraph ist somit präziser als ein rein Syntax-basierter Abhängigkeitsgraph. Diese Sichtweise dient allerdings lediglichder Verdeutlichung, warum die Signalabhängigkeiten als Block-spezifischaufgefasst werden. SDA sammelt keine Abhängigkeitsbeziehungen, dieanschließend wieder gestrichen werden – sondern, soweit möglich, nurtatsächlich existierende Abhängigkeiten zwischen Signalen.

Für eine Reihe repräsentativer Blocktypen führt Tabelle 7 eine Definition

der Abhängigkeitsbeziehungdep−−−→ auf. Diese wird im Folgenden erläu-

tert. Für die sonstigen SL/TL-Blocktypen gestaltet sich die Definitionähnlich. Daher wird auf eine vollständige Auflistung verzichtet.

Logical Operator. Für einen Logical-Operator-Block ist hierbei zu un-terscheiden, ob dieser mehrere Eingänge oder nur einen Eingang hat– beziehungsweise ob er den NOT-Operator oder einen der anderenlogischen Operatoren verwendet. Dies ist deshalb notwendig, da derBlock seine Funktionalität dementsprechend entweder je Vektorelementder/des Eingänge/Eingangs oder für alle Vektorelemente seines einenEingangs anwendet. In ersterem Fall hängt jedes Vektorelement des ausdem Block ausgehenden Signals jeweils von den Vektorelementen derEingangssignale mit identischem Index ab. In zweiterem Fall hängt dasAusgangssignal, welches eindimensional ist, von allen Vektorelementendes einzigen Eingangssignals ab.

Inport. Ein Inport-Block befindet sich entweder in einem Subsystemoder auf der höchsten Hierarchie-Ebene – und stellt in diesem Fall einenModelleingang dar. Ist er in einem Subsystem, so hängt jedes v-te Vek-torelement seines Ausgangssignals von dem v-ten Vektorelement desSignals ab, welches in den entsprechenden Inport des Subsystems ein-geht. Handelt es sich um einen Modelleingang, so besteht keine weitereAbhängigkeit des Blockausgangssignals (oder dessen Vektorelemente)von anderen Signalen.

Subsystem. Die Ausgangssignale eines Subsystem-Blocks hängen jeweilsvon dem Eingangssignal des entsprechenden Outport-Blocks, der sich


Blocktyp Signal-Abhängigkeit

LogicalOperator

Fall 1: n>1∨ •=¬


(sigout(b,1))v dep−−→ ⋃

p∈ IPb{(sig(p))vc(v,p)}

Fall 2: n=1∧ • �=¬

(sigout(b,1))1 dep−−→

d(b,1)⋃v=1

{(sigin(b,1))v}

Inport


∀v∈N[1,d(sb ,n)]:

(sigout(b,1))v dep−−→ {(sigin(sb ,n))

v}


(sigout(b,1))1 dep−−→ ∅

Subsystem

∀pos∈N[1,|OPb|]: ∀v∈N[1,d(op(b, pos))]:

(sigout(b, pos))v dep−−→ {(sigin(ob ,1))

v} mit

ob∈BCb ∧ btob=Outport∧(„m“, pos)∈PVob

Unbekannt

∀pos∈N[1,|OPb|]: ∀v∈N[1,d(op(b, pos))]:

(sigout(b, pos))v dep−−→ ⋃

p∈ IPb

d(p)⋃i=1

{(sig(p))i}

Tabelle 7: Abhängigkeit der Ausgangssignale eines SL/TL-Blocks von dessen Eingangssignalen (Auszug)

im Subsystem befindet, ab. Handelt es sich um vektorisierte Signale, sobezieht sich die Abhängigkeit jeweils auf die Vektorelemente der Signalemit identischem Index.

Unbekannter Block. Auch die SDA-Technik soll, gemäß der in Ab-schnitt 2.5 gemachten Vorgabe, Modelle mit teils unbekannten odernicht-berücksichtigten Blocktypen unterstützen können. Aus diesemGrund enthält SDA eine Definition der Abhängigkeitsbeziehung für un-bekannte Blöcke. Diese Definition sagt aus, dass jedes Vektorelementeines Ausgangssignals eines unbekannten Blocks von allen Vektorele-menten aller Eingangssignale des Blocks abhängt. Diese Annahme stellt,entsprechende Kenntnis über die Funktionalität des Blocks vorausgesetzt,zweifelsfrei eine Über-Approximation der tatsächlichen Signalabhängig-keiten dar. Dies kann dazu führen, dass ein Modelleingang letzten Endes


als relevant für ein CG erachtet wird, obwohl er eigentlich irrelevant ist.Dieser Umstand ist allerdings hinnehmbar, da eine Testdatensuche ohneVerwendung der SDA-Technik ohnehin jeden Modelleingang als relevantbetrachten würde. Viel wichtiger ist: Eine solche Über-Approximationführt unter keinen Umständen dazu, dass relevante Modelleingange alsirrelevant erachtet werden.

In Ergänzung zu den Definitionen der Abhängigkeitsbeziehungen in derTabelle ist zu berücksichtigen, dass je Block gegebenenfalls weitere Signal-abhängigkeiten hinzukommen. Befindet sich ein Block, wie zuvor bereitsangedeutet, in einem bedingt ausgeführten Subsystem, beziehungswei-se ist er in der Modellhierarchie unterhalb eines bedingt ausgeführtenSubsystems angesiedelt, so hängen seine Ausgangssignale zusätzlichvon dem Kontrollsignal des in der Hierarchie nach oben hin nächstenbedingt ausgeführten Subsystems ab. Wird dieses Subsystem nämlichzu einem Zeitschritt einer beliebigen Modellausführung nicht aktiviert,so sind dessen enthaltene Blöcke nicht aktiv und die Ausgangssignaledieser Blöcke enthalten keinen Wert. Daher hängt ein jedes solches Signalzusätzlich von etwaigen Kontrollsignalen ab.

Wird dies für jeden Modellblock ergänzend berücksichtigt, so gilt: Durch

Anwendung der Abbildungdep−−−→ für die Ausgangssignale eines jeden

Blocks eines SL/TL-Modells entsteht der gewünschte Abhängigkeits-graph. Die Reihenfolge, in der die Blöcke betrachtet werden, ist hierbeinicht von Bedeutung. Da jeder Block auch nur einmal betrachtet werdenmuss, steigt und fällt der Aufwand des Aufbaus eines Signalabhängig-keitsgraphen mit der Anzahl der Blöcke eines Modells.

nutzen der sia-modelltransformationen für sda

In Abschnitt 3.1.3 wurde im Zuge der Vorstellung der statischen Voranaly-se SIA erklärt, dass innerhalb dieser Analyse gegebenenfalls Transforma-tionen der betrachteten Modellrepräsentation durchgeführt werden. DieSDA-Technik verwendet für den Aufbau eines Signalabhängigkeitsgra-phen die gleiche Modellrepräsentation wie SIA. Anhand eines Beispielssoll an dieser Stelle aufgezeigt werden, dass die Transformationen vonSIA für die SDA-Technik von Vorteil sein können.

Ausgangspunkt des Beispiels ist das in Abbildung 12a dargestellte SL/TL-Modell. Der dazugehörige Signalabhängigkeitsgraph, wie ihn SDA ablei-ten würde, ist in Abbildung 12b zu sehen. Für das Beispiel wird nun fol-gende Annahme getroffen: SIA stellt fest, dass der Wertebereich des zwei-ten Modelleingangs für alle betrachteten Zeitschritte ausschließlich denWert 0 enthält. Da dies im betrachteten Beispiel dazu führen würde, dassder Switch-Block stets den an seinem dritten Eingang anliegenden Wertausgibt, führt SIA eine Transformation durch. Der Switch-Block wird ent-fernt und das ursprünglich dritte Eingangssignal des Switch-Blocks mit


]0[∈

(a) Modellrepräsentation ohne Durchführung von Transformationen beiSIA

(b) Signalabhängigkeitsgraph für die Modellrepräsentation in (a)

(c) Modellrepräsentation mit Durchführung von Transformationen bei SIA

(d) Signalabhängigkeitsgraph für die Modellrepräsentation in (b)

Abbildung 12: Ausnutzung der Modelltransformationen von SIA bei SDAanhand eines Beispiels


dessen ursprünglichem Ausgangssignal vereinigt. Nicht mehr benötigteModellbestandteile werden gemäß der Erläuterungen in Abschnitt 3.1.3entfernt. Das transformierte Beispiel-Modell ist in Abbildung 12c zusehen. Interessant wird es nun bei einem Blick auf den Signalabhängig-keitsgraphen, den SDA für das transformierte Modell ableitet. Dieserenthält, wie in Abbildung 12d dargestellt, weniger Abhängigkeitsbezie-hungen als sein Gegenstück in Abbildung 12b. Die Signalabhängigkeitenkonnten durch die Transformationen von SIA präzisiert werden. Für einCG, welches sich von dem NOT-Block des Beispiel-Modells ableitet, wirdzum Beispiel nun erkannt, dass Modelleingang eins und zwei für dieErfüllung des CG irrelevant sind. Ohne Durchführung dieser Transforma-tion bei SIA hätte sich eine Testdatensuche auf alle drei Modelleingängekonzentriert.

modelleingangsabhängigkeit

Den für ein SL/TL-Modell erstellten Signalabhängigkeitsgraphen ver-wendet SDA, um für jedes der betrachteten CGs zu prüfen, von welchenModelleingängen dieses abhängt. Die Abhängigkeit eines CG von einemModelleingang hat zur Folge, dass dieser Eingang gezielt mit passen-den Testdaten stimuliert werden muss, um das Erreichen des CG zugewährleisten.

Zur Ermittlung der Menge relevanter Modelleingänge sei zuerst die Ab-bildung esig : E → P(SN+

) definiert. Diese gibt für einen CG-Ausdruckoder -Teilausdruck an, welche Signale (jeweils inklusive Vektorindex-Angabe) in ihm vorkommen.

esig(ξ1•ξ2) =

⎧⎪⎪⎪⎨⎪⎪⎪⎩{ξ1,ξ2} , ξ1∈SN+

∧ξ2∈SN+

{ξ1} , ξ1∈SN+

∧ξ2 ∈SN+

{ξ2} , ξ1 ∈SN+

∧ξ2∈SN+

∅ , sonst

esig(◦ϕi) =

n⋃

i=1

esig(ϕi) (48)

esig(¬ϕ) = esig(ϕ)

Hierbei gilt: •∈{>,�,<,�,=, �=} und ◦∈{n∧

i=1

,n∨

i=1

}.

Die Abhängigkeit eines CG ϕ von einer Menge von Modelleingängen sei

dann durch die Abbildung in−−→: E×P(MB) gegeben. Wie in der folgen-den Definition ersichtlich, wird die Abbildung ebenfalls in Infixnotationverwendet.


ϕin−−→

⋃

sv∈ esig(ϕ)

vis(sv,∅) (49)

Die Abbildung vis : SN+ × P(SN+) → P(MB) wird hierbei für jedes in

dem CG-Ausdruck vorkommende Signal angewandt. Ausgehend vondem betreffenden Signal traversiert sie den Abhängigkeitsgraphen durchAbgehen der Abhängigkeitsbeziehungen bis hin zu den auf diesemWege erreichbaren Modelleingängen. Diese werden der gesuchten Men-ge hinzugefügt. Mithilfe des zweiten Parameters der Abbildung, eineSignalmenge, wird festgehalten, welche Signale bei der Traversierungbereits besucht wurden. Dies ist notwendig, damit etwaige Zyklen imAbhängigkeitsgraphen nur einmalig beschritten werden.

vis(sv,H) =

⎧⎪⎪⎪⎪⎪⎪⎪⎪⎨⎪⎪⎪⎪⎪⎪⎪⎪⎩

∅ , sv∈Hib , sv

dep−−→ ∅∧ ib= b(src(s))∈MB

⋃xw∈X

(svdep−−→X)

vis(xw,H∪{sv}) , sonst(50)

Die Menge der für ein CG ϕ irrelevanten Modelleingänge ist demnach

MB \X, wobei ϕ in−−→ X gilt. Diese irrelevanten Modelleingänge werdenbei einer Modellausführung im Rahmen einer Testdatensuche für ϕ mitzufällig generierten Signalen belegt. Für jedes Testdatum wird hierzupro irrelevantem Modelleingang eine Optimierungssequenz erzeugt, de-ren Parameter unter Berücksichtigung der Modelleingangsspezifikationzufällig gewählt sind. Diese Optimierungssequenzen werden von denOperatoren des verwendeten Suchverfahrens nicht angefasst. Dies be-deutet, dass bei der Erzeugung neuer oder veränderter Testdaten keinegezielte Modifikation dieser Optimierungssequenzen erfolgt.

Dennoch bleiben diese für das betrachtete CG irrelevanten Optimierungs-sequenzen von Testdatum zu Testdatum nicht unverändert. Für jedesTestdatum erfolgt eine erneute zufällige Erzeugung. Hierdurch wird beider Suche die Wahrscheinlichkeit erhöht, dass andere, bislang unerreichteCGs, also Andere als das anvisierte CG ϕ, zufälligerweise auch erreichtwerden (Kollateralüberdeckung). Ohne diesen Hintergedanken könnteman irrelevante Eingänge auch schlichtweg mit Signalen belegen, welchedurchgängig den gleichen Wert haben. Versuche haben allerdings gezeigt,dass dies das Ausmaß der Kollateralüberdeckung, wie sie eine Suchenormalerweise hat, verringern würde. Eine zufällige Generierung derSignale für irrelevante Modelleingänge individuell für jedes erzeugteTestdatum beseitigt diesen Nachteil, den der Einsatz der SDA-Technikansonsten mit sich bringen würde.



Bei der Anwendung des suchbasierten Ansatzes zur Testdatengenerie-rung für Programmcode beschäftigte sich Korel bereits zu Beginn der1990er Jahre mit dem Einfluss der Eingangsvariablen eines Programmsauf das Erreichen eines Strukturelements im Programmcode [76]. In die-sem Zusammenhang schlägt er eine Datenflussabhängigkeitsanalyse vor.Diese Analyse ist jedoch dynamisch gestaltet, das heißt Abhängigkeitenwerden während der Programmausführungen im Rahmen einer Testda-tensuche gesammelt. Korel regt in seiner Arbeit an, dass das durch ihnbetrachtete Vorhaben durch statische Analysen möglicherweise effizienterzu realisieren wäre. Harman et al. [61] und McMinn et al. [87] griffendiesen Vorschlag auf und ergänzten den suchbasierten Strukturtest fürCode um eine entsprechende statische Analyse. Um irrelevante Eingangs-variablen von einer der Suche dienenden Optimierung auszuschließen,verwenden die Autoren beider Arbeiten eine vor der Suche stattfindendeVariablen-Abhängigkeitsanalyse. Die Arbeit von McMinn et al. ist, bezüg-lich der Zielsetzung und des grundlegenden Vorgehens, die am nächstenmit der SDA-Technik verwandte Arbeit. SDA überträgt die Konzepte vonHarman, McMinn et al. von der Code- auf die Modell-Welt.

Harman et al. [61] untersuchten des Weiteren in einer Studie die Aus-wirkungen des Einsatzes eines solchen Eingangsvariablen-Ausschlussesauf eine Testdatengenerierung. Als Testdatengenerierungsverfahren ver-wenden sie sowohl einen Zufallstest als auch zwei suchbasierte Ansätze.Ihre Experimente mit Open-Source-Code und Code aus der Serienent-wicklung von Daimler bestätigen die Vermutung, dass eine ergänzendeDurchführung einer Variablen-Abhängigkeitsanalyse für die rein zu-fällige Testdatengenerierung keinerlei Vorteile mit sich bringt. Dies istwenig überraschend, da in diesem Fall relevante und irrelevante Ein-gangsvariablen bei Programmausführungen ohnehin gleichermaßen mitZufallswerten belegt werden. Für „intelligentere“ Testdatengenerierungs-verfahren, wie lokale und globale Suchverfahren, stellen Harman et al.allerdings fest, dass der Ausschluss von irrelevanten Eingangsvariablendazu im Stande ist, die Effizienz einer Suche zu steigern – in den betrach-teten Fällen allerdings ohne dabei einen höheren Überdeckungsgrad zuerreichen. Als Suchverfahren kamen in dieser Studie das Hill Climbingund ein Genetischer Algorithmus zum Einsatz.

Abgesehen von dem betrachteten Kontext der Testdatengenerierung istfestzustellen, dass der SDA-Ansatz ein Problem behandelt, welches inseinem Kern der Variablenabhängigkeit in Programmcode [60] gleich-kommt. So gesehen ist SDA auch eng verwandt mit Slicing-Techniken[117, 129]. Slicing (zu Deutsch: schneiden oder abschneiden) bezeichnetdie Vereinfachung von Programmen durch eine Fokussierung auf aus-gewählte Aspekte der Programmsemantik, wie Harman und Hierons


[58] definieren. Slicing entfernt Programmbestandteile, für welche er-mittelt werden kann, dass sie keine Auswirkung auf den betrachtetenAspekt haben. Slicing-Techniken finden in den Bereichen Testen, Debug-ging, Re-Engineering und Programmanalyse sowie bei der Ableitungvon Software-Metriken Anwendung [58].

Bei SDA handelt es sich zwar nicht um eine Slicing-Technik, allerdingshat SDA die Ermittlung von Abhängigkeiten innerhalb eines Program-mablaufs mit Slicing-Techniken gemein. Der Unterschied besteht grund-sätzlich in der Verwendung der ermittelten Abhängigkeiten. So dienendiese bei SDA der Erkennung der Relevanz von Programmeingaben(Modelleingänge) hinsichtlich ihres Einflusses auf Programmvariablen(Signale). Slicing-Techniken hingegen nutzen die ermittelten Abhängig-keiten, um einen Ausschnitt des betrachteten Programms zu extrahierenoder Programmteile zu entfernen.

Aus technischer Sicht kann die SDA-Technik daher als verwandt miteiner Arbeit von Reicherdt und Glesner [98], die zeitlich parallel zu dervorliegenden Arbeit entstanden ist, angesehen werden. Reicherdt undGlesner schlagen einen Ansatz zum Slicing von SL-Modellen vor. Beiden Abhängigkeiten, welche dabei gesammelt werden, handelt es sichebenfalls um sowohl Daten- als auch Kontrollabhängigkeiten. Im Unter-schied zur SDA-Technik betrachtet der Slicing-Ansatz für SL-Modelleallerdings Abhängigkeiten zwischen Modellblöcken. SDA hingegen ana-lysiert die Abhängigkeiten zwischen den Signalen eines Modells. Ausrein syntaktischer Sicht auf ein Modell ist dieser Unterschied unerheblich.Für das durch die SDA-Technik verfolgte Ziel ist die Ermittlung derSignalabhängigkeit dennoch das präzisere Mittel. Enthält ein Modellnämlich beispielsweise vektorisierte Signale, so stellt die Erfassung vonBlockabhängigkeiten statt Signalabhängigkeiten eine Abstraktion dar,welche zu einem Verlust an Detailinformationen führt.

Die Beiträge der SDA-Technik im wissenschaftlichen Diskurs lassen sichfolgendermaßen zusammenfassen:

1. Transfer der Idee des Eingangsvariablen-Ausschlusses bei einerTestdatengenerierung für Programmcode auf den Kontext derTestdatengenerierung für SL/TL-Modelle

2. Analyse der Signalabhängigkeiten eines SL/TL-Modells unter Be-rücksichtigung von Abhängigkeiten, die sich nicht direkt aus derModellsyntax ergeben

3.3 suchzielpriorisierung 107

3.3 suchzielpriorisierung

Analog zu den zuvor vorgestellten statischen Voranalysen wird in diesemAbschnitt eine dritte statische Voranalyse in ihrer Zielsetzung, Funkti-onsweise und ihrem Verhältnis zu verwandten Arbeiten behandelt. Beider dritten statischen Voranalyse handelt es sich um die mit dem KürzelCGSeq (in Englisch: Coverage Goal Sequencing) bezeichnete Suchzielpriori-sierung.

3.3.1 ziel

Die CGSeq-Technik adressiert drei der in Abschnitt 2.5 identifiziertenProbleme einer suchbasierten Testdatengenerierung für SL/TL-Modelle.Zum einen berücksichtigt die Technik Abhängigkeiten zwischen CGs, mitdem Ziel, die bei einer Testdatensuche erzielte Kollateralüberdeckung zuerhöhen. Hierdurch kann sich die Anzahl der insgesamt notwendigenSuchvorgänge verringern. Entsprechend steigt die Effizienz der gesamtenAutomatisierung. Zum anderen kann CGSeq in vielen Fällen, wo die Pro-blematik einer „blinden“ oder einer Booleschen Fitnessfunktion auftritt,helfen. Die zwischen CGs ermittelten Abhängigkeiten werden nämlichauch genutzt, um anstatt eines problematischen CG gegebenenfalls einanderes CG, dessen Erfüllung die Erfüllung des problematischen CG zurFolge hat, mit einer Testdatensuche anzuvisieren.

Ein einführendes Beispiel soll diese Überlegungen verdeutlichen. Ab-bildung 13 zeigt ein kleines Modell und zusätzlich eine Reihe hierausabgeleiteter CGs. So existieren beispielsweise die CG-Ausdrücke s1�90,s1�70 und s1�50. Ohne gesonderte Berücksichtigung der Zusammen-hänge zwischen diesen CGs könnte es dazu kommen, dass das CG mitdem Ausdruck s1�50 als erstes durch einen Suchvorgang anvisiert wird.Angenommen, die Suche findet Testdaten, die zu einem Wert von 55

für das Signal s1 führen, so gilt das CG als erfüllt. Die CG-Ausdrückes1�90 und s1�70 werden hierdurch allerdings nicht erfüllt. Würde manhingegen zuerst das CG mit dem Ausdruck s1�90 betrachten, so sindbei Erfolg der Testdatensuche all diese drei CGs auf einmal erfüllt.

Neben dem Aspekt der Kollateralüberdeckung sei anhand des Beispielsauch der Nutzen von CGSeq im Zusammenhang mit der Problema-tik Boolescher Fitnessfunktionen aufgezeigt. Die Fitnessfunktionen derCGs, die sich in dem Beispiel-Modell von dem NOT-Block sowie demSwitch-Block ableiten, unterliegen beispielsweise dieser Problematik. DieSignale, auf welche sich die CGs jeweils beziehen, haben einen Boole-schen Wertebereich. Dies lässt sich durch die SIA-Technik feststellen.Die Fitnessfunktion eines CGs besitzt in diesen Fällen ebenfalls einennur zweielementigen Wertebereich. Eine derartige Fitnessfunktion ist


∈

∈

∈

Abbildung 13: Motivierendes Beispiel zur Suchzielpriorisierung

für das verwendete Suchverfahren unvorteilhaft, da sie keine qualitati-ve Unterscheidung von Testdaten liefert, die das betrachtete CG nichterfüllen. CGSeq hilft in diesem Fall, da die Technik erkennen würde,dass beispielsweise aus der Erfüllung des CG-Ausdrucks s1<50 auchdie Erfüllung der Ausdrücke s2=0, s3=1 und s3>0 folgt. Das CG mitdem Ausdruck s1<50 wird in diesem Fall priorisiert durch eine Testda-tensuche anvisiert und das Problem Boolescher Fitnessfunktionen somitumgangen.

Der Einsatz der CGSeq-Technik eignet sich insbesondere bei Testdatenge-nerierungen im Rahmen eines Strukturtests, darüber hinaus aber auch inden anderen möglichen Anwendungsszenarien (siehe Abschnitt 2.2). DerAnsatz geht allerdings in jedem Fall davon aus, dass initial alle CGs allerstrukturorientierten Überdeckungskriterien (siehe Abschnitt 2.2.1) ausdem betrachteten SL/TL-Modell abgeleitet werden. Eine Nutzerwahl desgewünschten Überdeckungskriteriums, einzelner CGs oder anderweitigerCG-ähnlicher Zieldefinitionen, wie bei einem suchbasierten Funktionstest(siehe Abschnitt 2.2.2), wird bei Verwendung der CGSeq-Technik erstinnerhalb derselben berücksichtigt.

CGSeq versucht also, aus den Zusammenhängen zwischen möglichstvielen markanten Zustandszielen, welche durch CGs gegeben sind, einenNutzen für die Effizienz der Testdatengenerierung zu ziehen. Hierzuwerden, unter Berücksichtigung der zuvor angesprochenen Nutzerwahl,aus den CG-Zusammenhängen sogenannte Suchziele (SGs, Singular: SG)abgeleitet. Die Abkürzung leitet sich vom englischen Begriff Search Goalab. Ein SG kann ein CG oder mehrere CGs enthalten. Die abgeleiteten SGswerden anschließend für die nachfolgende Bearbeitung durch Suchvor-


gänge sortiert. Die Sortierung erfolgt durch die Verwendung von eigenshierfür definierten Priorisierungsmetriken. Diese berücksichtigen unteranderem, wie hoch die Kollateralüberdeckung eines CG ist und, soferndie SIA-Technik zuvor eingesetzt wurde, ob ein CG ein Boolesches Signaladressiert. Die Berechnungsgrundlage der Metriken sind hauptsächlichdie ermittelten CG-Zusammenhänge.

Zwei Teilvorgänge bilden zusammen die CGSeq-Technik: die Überde-ckungszielanalyse und die Abarbeitungsreihenfolgenbildung. Die folgendenbeiden Abschnitte stellen beide Vorgänge ausführlich vor. Hierzu beglei-tend fasst Abbildung 14 die Funktionsweise der beiden Vorgänge undvon CGSeq insgesamt zusammen.

Abbildung 14: Funktionsweise der Suchzielpriorisierung


3.3.2 überdeckungszielanalyse

Die Überdeckungszielanalyse ermittelt für die Gesamtmenge der CGs, obzwischen den enthaltenen CGs prädikatenlogische Zusammenhänge exis-tieren. In einem vorbereitenden Schritt werden die Ausdrücke der CGs inein einheitliches Muster gebracht, um die Fallunterscheidungen der dar-auffolgenden Schritte schlanker gestalten zu können (Abschnitt 3.3.2.1).Die erfassten CG-Zusammenhänge formen einen speziellen Abhängig-keitsgraphen. Die Syntax eines solchen Graphen wird in Abschnitt 3.3.2.2vorgestellt. Die Ermittlung der Abhängigkeiten zwischen CGs erfolgt inzwei Schritten. Zuerst werden logische Abhängigkeiten (Abschnitt 3.3.2.3)und anschließend semantische Abhängigkeiten (Abschnitt 3.3.2.4) erfasst.Erstere ergeben sich einzig und allein aus den CG-Ausdrücken, Letz-tere durch Berücksichtigung der Modellsemantik. Als Nebenproduktder CGSeq-Technik können durch die ermittelten Abhängigkeiten unterUmständen weitere unerreichbare CGs identifiziert werden. Die hierzuexistierende Erreichbarkeitsprüfung, welche die Erreichbarkeitsprüfungvon SIA ergänzt, wird in Abschnitt 3.3.2.5 behandelt.

3.3.2.1 Harmonisierung und Vereinfachung

Die bei der CG-Abhängigkeitsanalyse durchgeführten Vergleiche ein-zelner CGs gestalten sich einfacher, wenn die CG-Ausdrücke zuvor inein einheitliches Format gebracht werden. Die hierzu durchgeführteHarmonisierung und Vereinfachung erfolgt in drei Schritten:

1. Anpassung von CG-Ausdrücken über die für deren beteiligte Si-gnale ermittelten Wertebereiche (falls SIA verwendet wird)

2. Sortierung der Parameter innerhalb von CG-Ausdrücken

3. Anwendung von Vereinfachungsregeln für CG-Ausdrücke

Für jeden dieser Schritte sei ein Beispiel betrachtet. Eine vollständigeAuflistung aller Fälle oder eine Formalisierung der angewendeten Regelnund Umformungen würde den Rahmen an dieser Stelle sprengen – insbe-sondere, da eine Harmonisierung und Vereinfachung der CG-Ausdrückefür CGSeq nicht zwingend erforderlich ist, sondern für die folgendenAnalysen lediglich eine einfachere Gestaltung zulassen.

Schritt 1. Angenommen, ein CG besitzt den Ausdruck s>0 und für dasSignal s wurde durch SIA der Wertebereich s∈[0;1]1 identifiziert. DieserWertebereich verfügt über eine Quantisierung, ist also diskretisiert. Erenthält ausschließlich die Werte 0 und 1. Da es nur einen Wert gibt,der größer als 0 ist, würde CGSeq den relationalen Operator des CG-Ausdrucks in diesem Fall austauschen: Aus s>0 wird s=1.


Schritt 2. Die relationalen Teilausdrücke innerhalb eines CG-Ausdruckswerden geordnet. Dies bedeutet, dass bei einem Vergleich eines Signalsmit einer Konstanten das Signal zuerst aufgeführt wird. Der Ausdruck0>s würde demnach in s<0 geändert werden. Für den relationalenVergleich zweier Signale ist zu berücksichtigen: In der Umsetzung derAnsätze dieser Arbeit wird einem Signal eines SL/TL-Modells eine ein-deutige Identifikationsnummer (ID) zugewiesen. Eine solche Signal-IDwird innerhalb dieses Dokuments, sofern eine Angabe notwendig ist,im Index einer Signalvariablen notiert (Beispiel: s5 hat die Signal-ID 5).In Schritt 2 gilt hierauf basierend: Werden in einem relationalen CG-Teilausdruck zwei Signale miteinander verglichen, so wird das Signal mitder kleineren Signal-ID zuerst aufgeführt. Aus s3<s1 wird beispielsweises1>s3.

Schritt 3. In diesem Schritt werden unter anderem Negationen in denCG-Ausdrücken eliminiert. Hierzu werden zuerst die De MorganschenGesetze angewandt, so dass Negationen nur noch direkt vor relationalenTeilausdrücken vorkommen. Eine Negation kann dann entfernt werden,indem der relationale Operator einer Teilaussage umgekehrt wird. Ausdem Ausdruck ¬(s=0) wird beispielsweise s=0. Neben der Beseitigungvon Negationen ist es auch sinnvoll, Redundanzen, wie im Falle desAusdrucks s>4∧s>10, aufzulösen.

3.3.2.2 Überdeckungsziel-Abhängigkeitsgraph

Bevor es um die Ermittlung von CG-Abhängigkeiten gehen soll, sei dieStruktur des dabei entstehenden Abhängigkeitsgraphen vorgestellt. Beieinem CG-Abhängigkeitsgraphen handelt es sich um einen zum Teilgerichteten, zum Teil aber auch ungerichteten Graphen, in dem die Kno-ten Gruppen äquivalenter CGs und die gerichteten Kanten zwischenderartigen Knoten Implikationsbeziehungen repräsentieren. Ein Graphkann allerdings eine Reihe weiterer logischer Beziehungen enthalten.Diese sind in einem Graphen als ungerichtete Kanten dargestellt. Zu-dem gibt es zwei Arten von Junktoren als weitere Knotentypen, überwelche sich zusammengesetzte Implikationsbeziehungen zwischen CGs,beziehungsweise CG-Gruppen, ausdrücken lassen.

Ein CG-Abhängigkeitsgraph sei gegeben als

CGDG = (VCG,VK,VD,E→,E↑,E⊕,E��) (51)

wobei VCG⊆P(E) die Menge derer Knoten ist, welche gruppierte, alsoäquivalente CGs beinhalten, und VK die Knotenmenge für Konjunk-toren sowie VD die Knotenmenge für Disjunktoren sind. Die MengeE→ ⊆ (VCG∪VK∪VD)×(VCG∪VK∪VD) enthält gerichtete Graphkantenzur Beschreibung der Implikationsbeziehung zwischen CG-Gruppen,


Disjunktoren und Konjunktoren. Die Mengen E↑,E⊕ ⊆ VCG×VCG bein-halten ungerichtete Kanten, welche der Beschreibung von NAND- undXOR-Beziehungen zwischen CG-Gruppen dienen. Die KantenmengeE�� ⊆ VCG×VCG enthält rückwärtsgerichtete Implikationsbeziehungen.Die verschiedenen Beziehungstypen sind in Tabelle 8 veranschaulichtund werden nachfolgend erläutert.

Die Erkennung äquivalenter CGs dient einer direkten Reduktion derAnzahl an CGs, die es durch separate Suchvorgänge zu bearbeiten gilt.Für eine Gruppe äquivalenter CGs gilt: Ist eines der CG einer Gruppeerfüllt, so sind alle anderen CGs der Gruppe ebenfalls erfüllt. Gleichesgilt für die Nicht-Erreichbarkeit. Ein Hinweis zur Schreibweise: EineGruppe äquivalenter CGs wird als Menge CGNa,...,n ∈VCG geschrieben.Die Indizes a, ...,n geben hierbei an, welche CGs in der Gruppe ent-halten sind: CGNa,...,n = {cga, ..., cgn}. In den folgenden Darstellungenwerden die Mengenklammern einer CG-Gruppe in der Regel weggelas-sen, wenn diese nur ein CG enthält. Des Weiteren wird die Abbildungcgn :E→VCG verwendet, um für ein CG den dazugehörigen Knoten imAbhängigkeitsgraphen zu erhalten:

cgn(cgi) = CGNa,...,n (i∈{a, ...,n}) (52)

Die Implikationsbeziehung sagt aus, dass aus der Erfüllung eines CG dieErfüllung eines anderen CG folgt. Das Erfassen derartiger Beziehungenist wesentliche Grundlage für CGSeq, um die Kollateralüberdeckungeiner Testdatensuche zu erhöhen. Neben der normalen Implikations-beziehung existiert der Beziehungstyp rückwärtsgerichteter Implika-tionen. In ihrer Bedeutung unterscheiden sich beide Beziehungstypennicht. Rückwärtsgerichtete Implikationen bilden allerdings ausschließlichsemantische Abhängigkeiten ab. Diese ergeben sich unter Berücksich-tigung der Semantik eines Modellblocks gegebenenfalls für die CGs,die mit dessen Ein- und Ausgangssignalen in Verbindung stehen. Wäh-rend Abhängigkeiten der CGs der Blockausgangssignale von CGs derBlockeingangssignale durch normale Implikationsbeziehungen abgebil-det werden, werden rückwärtsgerichtete Implikationen ausschließlich fürAbhängigkeiten der CGs der Blockeingangssignale von CGs der Block-ausgangssignale verwendet. Rückwärtsgerichtete Implikationen werdeneinzig und allein bei der ergänzenden Erreichbarkeitsprüfung genutzt.

Die NAND- und XOR-Beziehung ermöglichen es, auszudrücken, dasszwei CGs (oder Gruppen von CGs) nicht gleichzeitig erfüllt sein können.Gleichzeitig bedeutet hierbei: zu dem gleichen Zeitschritt einer Modell-ausführung. Der Unterschied zwischen NAND- und XOR-Beziehung be-steht darin, dass die NAND-Beziehung eine gleichzeitige Nicht-Erfüllungder beteiligten CGs erlaubt. Die XOR-Beziehung hingegen gibt an, dasszu jedem Zeitschritt einer Modellausführung stets eines der beiden in


Grafische Darstellung Beschreibung Formale Schreibweise

Knoten(äquivalenterÜberdeckungs-ziele)

CGNa,...,n ={cga, ..., cgn

}

Implikation CGNa →CGNb

VerneinteKonjunktion(NAND)

CGNa ↑CGNb

Kontravalenz(XOR) CGNa ⊕CGNb

Rückwärts-gerichteteImplikation

CGNa ��CGNb

KonjunktiveImplikation

(CGNa ∧...∧CGNn)

→(CGNm ∧...∧CGNz)

DisjunktiveImplikation

(CGNa ∨...∨CGNn)

→(CGNm ∧...∧CGNz)

Es gilt: cga , cgb , cgn , cgm , cgz ∈E (a,b,n,m,z ∈ N+)

Tabelle 8: Syntax eines Überdeckungsziel-Abhängigkeitsgraphen

Beziehung gesetzten CGs erfüllt ist. Die XOR-Beziehung ist also einestriktere Variante der NAND-Beziehung, das heißt es gilt:

(n1,n2)∈E⊕ ⇒ (n1,n2)∈E↑ (53)

Die Erfassung dieser beiden Beziehungstypen dient in erster Linie derErkennung weiterer unerreichbarer sowie stets erreichter CGs – in Er-gänzung zu denen, die bereits durch die SIA-Technik erkannt werden.Bei den nachfolgenden Betrachtungen der logischen und semantischenAbhängigkeiten ist die Kommutativität dieser beiden Ausschlussbezie-hungen zu berücksichtigen:

(n1,n2)∈E⊕ ⇔ (n2,n1)∈E⊕ und (n1,n2)∈E↑ ⇔ (n2,n1)∈E↑ (54)


Mithilfe des Junktors konjunktive Implikation (Konjunktor) lässt sich be-schreiben, dass aus der gleichzeitigen Erfüllung mehrerer CGs die Erfül-lung eines oder mehrerer CGs folgt. Der Junktor disjunktive Implikation(Disjunktor) hingegen drückt aus, dass die Erfüllung mindestens einesmehrerer CGs die Erfüllung eines oder mehrerer CGs zur Folge hat. Junk-toren beider Typen können über eine Implikationsbeziehung miteinanderverbunden sein. Dieser Fall ist in der Tabelle nicht veranschaulicht.

3.3.2.3 Logische Abhängigkeiten

Die zwischen CGs möglichen Beziehungen lassen sich zum einen durcheine ausschließliche Betrachtung der CG-Ausdrücke erkennen. Anhandder in den Ausdrücken enthaltenen Operatoren, Signale und Konstantenlassen sich Zusammenhänge entsprechend der im vorigen Abschnittbeschriebenen Beziehungstypen erkennen. Die so gewonnenen Abhän-gigkeiten werden als logische Abhängigkeiten bezeichnet. Sofern vor derCGSeq-Technik die SIA-Technik verwendet wird, so werden bei Betrach-tung der CG-Ausdrücke an dieser Stelle auch die durch SIA bestimmtenSignalwertebereiche berücksichtigt. Die Beziehung (s1>0) → (s1�0) lässtsich zum Beispiel durch eine reine Betrachtung der in den Ausdrückeninvolvierten Operatoren erkennen. Die Beziehung (s1==5) → (s1�0)hingegen bedarf zu ihrer Erkennung eine zusätzliche Berücksichtigungder beteiligten Konstanten. Die Signalwertebereiche sind beispielsweisefür die Erkennung der Beziehung (s1==3) → (s1>s2) zu beachten. Hier-für müsste nämlich max(s2)<3 gelten, das heißt der größtmögliche Wert,den das Signal s2 annehmen kann, ist kleiner als die Konstante 3.

Bevor das Vorgehen zur Erkennung logischer CG-Abhängigkeiten imDetail vorgestellt wird, sei dieser Schritt für das Beispiel-Modell aus Ab-bildung 13 veranschaulicht. Abbildung 15 gibt hierzu den CG-Abhängig-keitsgraphen an. Dieser enthält ausschließlich logische Abhängigkei-ten. Wie zu sehen ist, schließen sich die CG-Paare cg1 (s1�90) undcg2 (s1<90), cg3 (s1�70) und cg4 (s1<70) sowie cg5 (s1�50) und cg6(s1<50) jeweils bezüglich ihrer Erfüllung gegenseitig aus. Hierbei han-delt es sich um XOR-Beziehungen. Die CG-Paare cg1 und cg4, cg1 undcg6 sowie cg3 und cg6 können ebenfalls nicht gleichzeitig erfüllt sein,hierbei handelt es sich allerdings lediglich um NAND-Beziehungen. Ausder Erfüllung von cg1 folgt logischerweise auch die Erfüllung von cg3und cg5. Eine Implikationsbeziehung existiert ebenso zwischen cg3 undcg5. Ähnliches gilt für cg6, cg4 und cg2. Für die CGs cg9 (s3=1) undcg11 (s3>0), beziehungsweise cg10 (s3=0) und cg12 (s3�0), erkennt dieCG-Analyse von CGSeq durch Berücksichtigung des Booleschen Signal-wertebereichs von s3, dass die beiden CGs jeweils äquivalent sind. Diebeiden hierdurch entstehenden CG-Gruppen schließen sich zudem übereine XOR-Beziehung bezüglich ihrer Erfüllung aus. Letzteres gilt auchfür die CGs cg7 (s2 =0) und cg8 (s2=0).


Abbildung 15: Logische Abhängigkeiten für das Beispiel-Modell aus Ab-bildung 13

Zur Erkennung solcher logischen Abhängigkeiten führt CGSeq eineFallunterscheidung durch. Es findet ein paarweiser Vergleich aller vor-handenen CGs statt. Hierbei bilden drei Arten von Beziehungen, welchejeweils für ein CG-Paar gelten können, die Grundlage für daraus folgendeModifikationen des Abhängigkeitsgraphen:

dom−−−→,�,�0/1 : E× E → B (55)

Diese in Infixnotation verwendeten Abbildungen geben für zwei CGsan, ob die jeweils durch sie beschriebene Beziehung gilt oder nicht. Für

zwei CGs cga und cgb steht cgadom−−−→ cgb hierbei für die Aussage, dass

cgb erfüllt ist, wann immer cga erfüllt ist. Im Folgenden wird diesbe-züglich auch folgende Ausdrucksweise verwendet: cga dominiert cgb.Die Abbildung � beschreibt den gegenseitigen Ausschluss, d.h. die CGskönnen unter keinen Umständen gleichzeitig erfüllt sein. Die Abbildung�0/1 ist eine striktere Form dieser Beziehung, welche zusätzlich verlangt,dass die beiden betrachteten CGs unter keinen Umständen gleichzeitigunerfüllt sind. Im Grunde spiegeln diese Abbildungen die Implikations-,XOR- und NAND-Beziehung in Anwendung für je zwei einzelne CGswieder. Analog zu Definition 53 und Definition 54 gilt demnach auch:

cga �0/1 cgb ⇒ cga � cgbcga �0/1 cgb ⇔ cgb �0/1 cga (56)

cga � cgb ⇔ cgb � cga

Aus der Überprüfung jeglicher CG-Paare cga und cgb auf diese dreiBeziehungstypen hin lassen sich folgendermaßen Modifikationen desAbhängigkeitsgraphen ableiten. Die Feststellung dieser Fälle ist hierbeientsprechend der Reihenfolge ihrer Auflistung priorisiert.


1. Äquivalenz: cgadom−−−→ cgb∧ cgb

dom−−−→ cga ⇒ cgn(cga) = cgn(cgb)

2. Implikation: cgadom−−−→ cgb ⇒ cgn(cga)→ cgn(cgb)

3. XOR: cga �0/1 cgb ⇒ cgn(cga)⊕ cgn(cgb) (57)

4. NAND: cga � cgb ⇒ cgn(cga) ↑ cgn(cgb)

Um nun die Abbildungen dom−−−→, � und �0/1 kompakt beschreiben zu kön-nen, seien folgende Definitionen vorausgesetzt. DenWertebereich eines Si-gnals s (bzw. dessen v-ten Vektorelements), über sämtliche existierendenZeitintervalle hinweg gesehen, beschreibt die Abbildung D :SN+→P(IV)folgendermaßen:

D(sv) =⋃

ti∈T(s,v)

IS(s, v, ti) (58)

Die aus diesem Wertebereich kleinstmöglichen und größtmöglichen Wer-te eines Signals seien durch min,max :SN+→R, unter Verwendung dermin/max-Funktionen aus Definition 33, wie folgt definiert:

min(sv) = min(D(sv)) (59)

max(sv) = max(D(sv))

Ein Wert x∈R ist darüber hinaus genau dann in einem Signalwertebereichenthalten, ausgedrückt durch x

.∈D(sv), wenn der Wert in mindestenseinem Intervall enthalten ist:

x.∈D(sv) ⇔ ∃ iv∈D(sv): x∈ iv (60)

Die Anzahl möglicher Signalwerte, ausgedrückt durch |D(sv)|, ist folgen-dermaßen definiert:

|D(sv)| =∑

iv∈D(sv)

| iv | (61)

Hierbei sind |[a]|=1, |[a;b]q|=1+((b−a)/q) und |[a;b]|=∞.

Die Werte, welche die Wertebereiche zweier Signale (jeweils in Formeiner Intervallmenge) gemeinsam haben, sind darüber hinaus über denspeziellen Schnittmengenoperator

.∩ definiert:

D(sv1).∩D(sw2 ) = { x∈R | x

.∈D(sv1)∧x.∈D(sw2 ) } (62)

Zuletzt sei die Funktion BOOL : SN+→B definiert, welche angibt, ob derWertebereich eines Signals ein Boolescher ist:

BOOL(sv) = (0.∈D(sv)∧1

.∈D(sv)∧|D(sv)|=2) (63)


Die Definitionen der Beziehungen dom−−−→, � und �0/1 sind fallbasiert inTabelle 9 dargestellt. Geht es beispielsweise um die Prüfung der Be-

ziehung cgadom−−−→ cgb und cgb besteht aus der Konjunktion mehrerer

Teilausdrücke, so muss aus der Erfüllung von cga die Erfüllung eines

jeden Teilausdrucks von cgb folgen, damit die Beziehung cgadom−−−→ cgb

gilt. Ähnliche Zusammenhänge gibt es bei allen drei Beziehungstypen,falls cgb mehrere Teilausdrücke logisch verknüpft (Tabellenzeilen 1/2).

Handelt es sich bei cgb um einen relationalen Ausdruck, so sind bei allendrei Beziehungstypen jeweils drei Fälle zu unterscheiden: cga kann eineKonjunktion mehrerer Teilausdrücke, eine Disjunktion mehrerer Teilaus-drücke oder ebenfalls ein relationaler Ausdruck sein (siehe Definition 14).Die Negation eines Teilausdrucks muss an dieser Stelle nicht berück-sichtigt werden, da Negationen, wie in Abschnitt 3.3.2.1 beschrieben, ineinem vorbereitenden Schritt von CGSeq entfernt werden.

Fallcgb

Beziehung

cgadom−−→ cgb

Beziehungcga � cgb

Beziehungcga �0/1 cgb

n∧i=1

ϕi ∀ϕi: cgadom−−→ϕi ∃ϕi: cga �ϕi ∀ϕi: cga �0/1ϕi

n∨i=1

ϕi ∃ϕi: cgadom−−→ϕi ∀ϕi: cga �ϕi ∀ϕi: cga �0/1ϕi

ξ1•ξ2

Fall 1: cga=n∧

i=1

ϕi

∃ϕi:ϕidom−−→ cgb ∃ϕi:ϕi� cgb ∀ϕi:ϕi�0/1 cgb

Fall 2: cga=n∨

i=1

ϕi

∀ϕi:ϕidom−−→ cgb ∀ϕi:ϕi� cgb ∀ϕi:ϕi�0/1 cgb

Fall 3: cga=ξ3◦ξ4

siehe Tabelle 10 siehe Tabelle 11

Tabelle 9: Bedingungen zur Erfüllung der logischen Beziehungen

cgadom−−−→ cgb, cga � cgb und cga �0/1 cgb (mit cga, cgb∈E) in

Abhängigkeit von den in den Ausdrücken enthaltenen Opera-toren (wobei •, ◦∈{>,�,<,�,=, �=})


Im Falle einer Konjunktion gilt beispielsweise die Beziehung cgadom−−−→ cgb,

wenn es mindestens einen Teilausdruck in cga gibt, dessen Erfüllungdie Erfüllung von cgb zur Folge hat. Handelt es sich um eine Dis-junktion, so müssen sich beispielsweise alle Teilausdrücke von cgamit cgb gegenseitig ausschließen, damit cga � cgb gilt. Bilden sowohlcga als auch cgb relationale Ausdrücke, so ist eine spezifische Fall-unterscheidung notwendig. Diese ist auszugsweise in Tabelle 10 so-wie Tabelle 11 dargestellt. Tabelle 10 betrachtet hierbei die Beziehung

ξ3◦ξ4 dom−−−→ ξ1•ξ2, für •∈{>,�} und ◦∈{>,�,<,�,=, �=}. Tabelle 11 hinge-gen definiert die Beziehungen ξ1◦ξ2 � ξ3•ξ4 und ξ1◦ξ2 �0/1 ξ3•ξ4, für•∈{>,=} und ◦∈{>,�,<,�,=, �=}.Die Spalten in Tabelle 10 stellen vier verschiedene Fälle dar. Grundvor-aussetzung ist dabei, dass es sich bei ξ3 in ξ3◦ξ4 und bei ξ1 in ξ1•ξ2 umSignale handelt. ξ2 und ξ4 können jeweils ein Signal oder eine Konstantesein. Daraus ergeben sich vier Kombinationsmöglichkeiten, beziehungs-weise die in den Spalten dargestellten vier Fälle. Je nach Operator für •und ◦ gelten unterschiedliche Bedingungen, damit ξ3◦ξ4 dom−−−→ ξ1•ξ2gilt. Zum Beispiel gilt die Beziehung ξ3=ξ4

dom−−−→ ξ1>ξ2 (mit ξ2 undξ4 als Konstanten) genau dann, wenn es sich bei ξ3 und ξ1 einerseitsum das selbe Signal handelt (ξ1=ξ3) und die Konstante ξ2 andererseits

kleiner als die Konstante ξ4 ist. Es gilt zum Beispiel: s=5dom−−−→ s>2.

Die Fallunterscheidung in Tabelle 11 ist ähnlich gestaltet. Auch hier sindξ1 und ξ3 in jedem Fall Signale sowie ξ2 und ξ4 wahlweise jeweils einSignal oder eine Konstante. Die Bedingungen, nach denen es sich beizwei der in beiden Ausdrücken enthaltenen Signale um das selbe Signalhandeln muss, sind in dieser Tabelle allerdings bereits in den Spalten-überschriften verarbeitet. Ein Beispiel: Es seien die Ausdrücke ξ1>ξ2und ξ3�ξ4 betrachtet, wobei es sich bei allen enthaltenen Parameternum Signale handelt. Die beiden Ausdrücke schließen sich wechselseitiggegenseitig aus (�0/1), wenn nicht nur ξ1 das selbe Signal wie ξ3, son-dern auch ξ2 das selbe Signal wie ξ4 ist. Ein konkretes Beispiel hierzuist s1>s2 �0/1 s1�s2. Bezeichnen ξ2 und ξ4 allerdings unterschiedlicheSignale, so kann lediglich der einfache gegenseitige Ausschluss (�) gelten.Hierzu müsste der kleinstmögliche Wert des Signals ξ2 größer als odergleich dem größtmöglichen Wert des Signals ξ4 sein. Auch hierzu sei einkonkretes Beispiel angeführt: s1>s2 � s1�s4 gilt, wenn beispielsweisemin(ξ2)=7 und max(ξ4)=5 sind.

Im Rahmen der vorgestellten Arbeit wurde die Fallunterscheidung selbst-verständlich für alle relationalen Operatoren vorgenommen – sie wird andieser Stelle jedoch aus Platzgründen nicht voll umfassend vorgestellt.


•ξ1,ξ

3∈S

N+

∧ξ2,ξ

4∈R

ξ1,ξ

2,ξ

3,ξ

4∈S

N+

ξ1,ξ

2,ξ

3∈S

N+

∧ξ4∈R

ξ1,ξ

3,ξ

4∈S

N+

∧ξ2∈R

>

◦ξ1=ξ3

◦◦

◦ξ2<max

(min(ξ

3),min(ξ

4))

>ξ2�ξ4

>ξ1=ξ3∧ξ2=ξ4

=(ξ

1=ξ3∧max

(ξ2)<

ξ4) ∨

(ξ2=ξ3∧min(ξ

1)>

ξ4)

>,�

ξ1=ξ3

�=ξ2=ξ4=min(ξ

3)

>ξ1=ξ3∧max

(ξ2)�

ξ4

<,�

ξ1=ξ4

<ξ2=ξ3∧ξ1=ξ4

�ξ1=ξ3∧max

(ξ2)<

ξ4

�,=

ξ2<ξ4

<ξ2=ξ3∧min(ξ

1)�

ξ4

=ξ1=ξ3∨ξ1=ξ4

�ξ2=ξ3∧min(ξ

1)>

ξ4

�

◦ξ1=ξ3

◦◦

◦ξ2�max

(min(ξ

3),min(ξ

4))

=,>,�

ξ2�ξ4

=(ξ

1=ξ3∧ξ2=ξ4) ∨

(ξ2=ξ3∧ξ1=ξ4)

=(ξ

1=ξ3∧max

(ξ2)�

ξ4) ∨

(ξ2=ξ3∧min(ξ

1)�

ξ4)

>,�

ξ1=ξ3

�=min(ξ

1)=

ξ4

∧(∃

[a;b]∈

D(ξ

1)

⇒ξ2�ξ4) ∧

(∀[ξ

4;b] q∈D

(ξ1):

ξ2�ξ4+q)

∧(∀

[a]∈

D(ξ

1):

a>ξ4⇒

ξ2�a)

<,�

ξ1=ξ4

>,�

ξ1=ξ3∧ξ2=ξ4

>,�

ξ1=ξ3∧max

(ξ2)�

ξ4

=ξ1=ξ3∨ξ1=ξ4

<,�

ξ2=ξ3∧ξ1=ξ4

<,�

ξ2=ξ3∧min(ξ

1)�

ξ4

Tabell

e1

0:Be

ding

unge

nzu

rEr

füllu

ngde

rlogische

nBe

zieh

ungξ3◦ξ

4do

m−−−→

ξ1•ξ

2(A

uszu

gfür•∈

{>,�})


ξ2∈R

ξ2∈S

N+

•ξ4∈R

∧ξ1=ξ3

ξ4∈S

N+

ξ4∈S

N+

ξ4∈R

ξ1=ξ3

ξ1=ξ4

ξ1=ξ3

......

>

◦ =�0/1:BO

OL(

ξ1) ∧

ξ2=ξ4=0

�:ξ2�ξ4

�=�0/1:BO

OL(

ξ1) ∧

ξ2=0

∧ξ4=1

<�0/1:BO

OL(

ξ1) ∧

ξ2=0

∧ξ4=1

�:ξ2�ξ4

��0/1:ξ2=ξ4

�:ξ2�ξ4

◦ = < ��:ξ2�max

(ξ4)

...

◦ =�:min(ξ

2)�

min(m

ax(ξ

1),max

(ξ4))

<�:min(ξ

2)�

max

(ξ4)

��0/1:ξ2=ξ4

�:min(ξ

2)�

max

(ξ4)

......

=

◦ =�0/1:BO

OL(

ξ1) ∧

ξ2�=ξ4

�:ξ2�=ξ4

�=�0/1:ξ2=ξ4

>�0/1:BO

OL(

ξ1) ∧

ξ2=ξ4=0

�:ξ2�ξ4

��0/1:BO

OL(

ξ1) ∧

ξ2=0

∧ξ4=1

�:ξ2<ξ4

<�0/1:BO

OL(

ξ1) ∧

ξ2=ξ4=1

�:ξ2�ξ4

��0/1:BO

OL(

ξ1) ∧

ξ2=1

∧ξ4=0

�:ξ2>ξ4

◦ =�:¬(ξ

2

. ∈D(ξ

4))

>�:ξ2�min(ξ

4)

��:ξ2<min(ξ

4)

<�:ξ2�max

(ξ4)

��:ξ2>max

(ξ4)

...

◦ =�:D(ξ

2). ∩D

(ξ4)=

∅�=�0/1:ξ2=ξ4

>�:min(ξ

4)�

min(m

ax(ξ

1),max

(ξ2))

��:min(ξ

4)>

min(m

ax(ξ

1),max

(ξ2))

<�:min(ξ

4)�

min(m

ax(ξ

1),max

(ξ2))

��:min(ξ

4)<

min(m

ax(ξ

1),max

(ξ2))

......

Tabell

e1

1:Be

ding

unge

nzu

rEr

füllu

ngde

rlogische

nBe

zieh

unge

nξ1◦ξ

2�ξ3•ξ

4un

dξ1◦ξ

2�0/1ξ3•ξ

4(A

uszu

gau

sde

rFa

llun-

tersch

eidu

ngfür•∈

{>,=})-Grund

voraus

setzun

gistin

jede

mFa

ll:ξ1un

dξ3sind

Sign

ale(ξ

1,ξ

3∈S

N+)


3.3.2.4 Semantische Abhängigkeiten

Die Erfassung semantischer Abhängigkeiten stellt eine Erweiterungdes durch die Sammlung logischer Abhängigkeiten entstandenen CG-Abhängigkeitsgraphen dar. Während bei der Prüfung logischer Abhän-gigkeiten zweier CGs vorausgesetzt wird, dass beide Ausdrücke min-destens ein Signal miteinander teilen, so ist dies im Falle semantischerAbhängigkeiten nicht notwendig. Diese ergeben sich nämlich, wie bereitsangedeutet, aus der Semantik des betrachteten SL/TL-Modells.

Hierzu sei einleitend erneut das Beispiel-Modell aus Abbildung 13 be-trachtet. Den vollständigen CG-Abhängigkeitsgraph für dieses Modell,also inklusive der semantischen Abhängigkeiten, ist in Abbildung 16dargestellt. Vergleicht man diesen mit dem rein aus logischen Abhän-gigkeiten bestehenden Abhängigkeitsgraph in Abbildung 15, so fällt auf,dass es zu einem Zusammenschluss der CGs cg5, cg7, cg10 und cg12,beziehungsweise cg6, cg8, cg9 und cg11, zu je einer Gruppe äquivalenterCGs gekommen ist. Ein Blick in das Beispiel-Modell klärt auf, wieso:cg5 und cg7 beziehen sich auf ein Ein- oder Ausgangssignal des unterenRelational-Operator-Blocks. Aus der Funktionalität dieses Blocks lässtsich ableiten, dass bei Erfüllung von cg5 auch cg7 erfüllt ist. Da cg7 nurgenau dann erfüllt ist, wenn auch cg5 ist, sind diese CGs als äquivalentanzusehen. Das gleiche gilt für cg6 und cg8. Die weiteren Äquivalen-zen ergeben sich analog hierzu durch Betrachtung des NOT- und desSwitch-Blocks.

Zur Ermittlung semantischer Abhängigkeiten geht CGSeq folgender-maßen vor: Da die Prüfung dieser Abhängigkeiten Block-spezifisch ist,wird für jeden Block der Repräsentation des betrachteten SL/TL-Modells

Abbildung 16: Vollständiger Abhängigkeitsgraph für das Beispielmodellaus Abbildung 13


eine entsprechende Analyse durchgeführt. Die Blöcke werden dabei inder Ausführungsreihenfolge, wie sie auch innerhalb einer Modellaus-führung gilt, abgearbeitet. Die Analyse eines jeden Blocks untersuchtdie CGs, welche mit dessen Ein- und Ausgangssignalen in Verbindungstehen und leitet gegebenenfalls Beziehungen zwischen diesen CGs fürden CG-Abhängigkeitsgraphen ab. Blöcke mit zeitlicher Dynamik, wieein Unit-Delay-Block, werden hierbei ausgelassen. Wäre dies nicht so,müssten die CG-Beziehungen oder die CGs im Abhängigkeitsgraphenüber Zeitangaben verfügen. Da dies, insbesondere im Fall von Schlei-fen im Modell, die Komplexität eines CG-Abhängigkeitsgraphen unterUmständen deutlich vergrößern würde, wird an dieser Stelle auf einerweiterndes Konzept verzichtet. Die Realisierung einer entsprechendenErweiterung könnte Gegenstand von Folgearbeiten sein.

Werden bei der Analyse eines Blocks semantische Abhängigkeiten inForm von Implikationsbeziehungen registriert, so werden, wie in Ab-schnitt 3.3.2.2 erklärt, zwei verschiedene Typen von Implikationsbeziehun-gen verwendet: vorwärts- und rückwärtsgerichtete Implikationsbeziehun-gen. Betrachtet man die CGs, durch Zuordnung zu den in ihnen jeweilsenthaltenen Signalen, eingegliedert in das betrachtete SL/TL-Modell, sofolgen vorwärtsgerichtete (normale) Implikationsbeziehungen der Rich-tung des Signalflusses im Modell. Rückwärtsgerichtete Implikationenstehen diesem entgegen. Anders ausgedrückt: Folgt aus der Erfüllungeines CGs, welches ein Ausgangssignal eines Blocks referenziert, die Er-füllung eines CGs, das ein Eingangssignal des selben Blocks referenziert,so handelt es sich um eine rückwärtsgerichtete Implikation. Ein Beispiel:Ein CG, das verlangt, dass das Ausgangssignal eines AND-Blocks eine1 enthält (Wahrheitswert wahr am Ausgang), dominiert ein jedes CG,das beschreibt, dass eines der Eingangssignale des Blocks ungleich 0 ist(Wahrheitswerte wahr an den Eingängen). Während vorwärtsgerichteteImplikationen vor allem der Bildung einer Abarbeitungsreihenfolge derCGs für die Testdatensuche dienen, werden rückwärtsgerichtete Impli-kationen durch CGSeq einzig und allein für die erwähnte ergänzendeErreichbarkeitsprüfung genutzt.

Die Blockanalysen zur semantischen CG-Abhängigkeit fügen der Ge-samtmenge an CGs des Weiteren unter Umständen weitere CGs hinzu.Ein jedes solches CG wird virtuelles Überdeckungsziel (VCG, Plural: VCGs)genannt. Ein VCG dient im Abhängigkeitsgraph der „Brückenbildung“zwischen anderen CGs. Zum Verständnis dieser Idee sei das Beispiel-Modell in Abbildung 17 betrachtet. Ein partieller CG-Abhängigkeitsgraphfür einige der ableitbaren CGs ist ebenfalls in dieser Abbildung darge-stellt. Von dem linken der beiden Switch-Blöcke leitet sich unter anderemdas CG cg2 ab, welches den Wert 1 für das Kontrollsignal am zweitenEingang des Blocks verlangt. Dieser Switch-Block erkennt bei seiner Ana-lyse semantischer Abhängigkeiten zwar keine Zusammenhänge zwischenexistierenden CGs an seinen Ein- und Ausgängen, jedoch nutzt er die


durch SIA für seine zwei Dateneingänge gewonnen Wertebereichsan-gaben, um hieraus VCGs für sein Ausgangssignal zu erstellen. Daherentsteht vcg1 mit dem Ausdruck s5=2. Da die Erfüllung von cg2 fürdie Funktionalität des Switch-Blocks eine Durchleitung des ersten Da-teneingangs bedeutet, lässt sich schlussfolgern: cg2 dominiert vcg1. Dernachfolgende Gain-Block kann bei seiner Analyse ebenfalls keinen direk-ten Zusammenhang zwischen existierenden CGs herstellen. Allerdingskönnen auch hier VCGs entstehen. Da dieser Gain-Block eine Multiplika-tion seiner Eingabe mit dem Faktor 10 durchführt, kann das VCG vcg2mit dem Ausdruck s6=20 abgeleitet werden. Der im Signalfluss darauffol-gende Switch-Block überträgt dieses VCG auf sein Ausgangssignal, mitder Bedingung dass gleichzeitig auch sein Kontrolleingang entsprechendgestaltet ist (Konjunktion mit cg4). Aus der gleichzeitigen Erfüllung voncg4 und vcg2 folgt also die Erfüllung von vcg3, welches den Ausdrucks8=20 besitzt. Der Abhängigkeitsgraph wird nach der Erfassung allersemantischen Abhängigkeiten komplettiert, indem für jedes hinzuge-fügte VCG eine Überprüfung möglicher logischer Abhängigkeiten mitallen anderen VCGs und CGs durchgeführt wird. Daher wird auch er-kannt, dass vcg3 das CG cg5 dominiert. Aus Sicht einer Testdatensucheerscheint es mit Blick auf den entstandenen Abhängigkeitsgraphen nunsinnvoll, die CGs cg1 und cg3 gleichzeitig als Ziel anzuvisieren. Werdennämlich dabei die gesuchten Testdaten gefunden, so werden alle in derAbbildung dargestellten CGs auf einen Schlag erreicht.

Die Block-spezifischen Analysen semantischer Abhängigkeiten, inklusiveder Erstellung von VCGs, werden im Folgenden, zumindest auszugs-

&

Abbildung 17: Block-spezifisches Hinzufügen virtueller Überdeckungs-ziele (Beispiel)


weise, definiert. Hierzu sei auf drei Hilfskonstrukte oder -abbildungenverwiesen, welche in den Definitionen aufgegriffen werden. Die Mengeall derer CGs, in deren Ausdrücken ein bestimmtes Signal vorkommt, seidurch SCG :SN+→P(E) gegeben. Da es in den Blockanalysen möglichsein soll, eine solche Menge um VCGs zu erweitern, sei der Operator⊎:P(E)×E→P(E) eingeführt. Dieser fügt einer CG-Menge ein weiteres

CG oder VCG hinzu. Ist im Folgenden übrigens von CGs die Rede, so sinddamit auch eventuell vorhandene VCGs gemeint – es sei denn, es wirdexplizit unterschieden. Zuletzt wird die Funktion �:E×SN+×SN+→E

benötigt. Diese tauscht in dem Ausdruck eines CG alle Vorkommnisseeines bestimmten Signals durch ein anderes gewünschtes Signal aus.Tabelle 12 enthält die Definition der Blockanalysen, im Auszug für dieBlöcke Inport und Logical Operator.

Inport. Für diesen Block sei zunächst der Fall betrachtet, dass der Blocksich in einem virtuellen Subsystem befindet (Fall 1). Im Grunde über-trägt die Blockanalyse in diesem Fall jegliche CGs von dem entspre-chenden Eingangssignal des Subsystems auf das Ausgangssignal desInport-Blocks (Fall 1.2). Ein CG cg des Subsystem-Eingangssignals unddas korrespondierende VCG vcg des Inport-Ausgangssignals werdenin Folge im Abhängigkeitsgraphen als äquivalent aufgefasst. Existiertallerdings bereits ein CG rcg am Ausgangssignal, welches äquivalent zuvcg ist, so wird vcg nicht hinzugefügt und stattdessen rcg als äquivalentmit cg aufgefasst (Fall 1.1). Befindet sich der Inport-Block ein einembedingt ausgeführten Subsystem, wie einem Enabled Subsystem (Fall2), so müssen bei der Erfassung des Zusammenhangs zwischen cg undvcg/rcg (Fall 2.2/Fall 2.1) auch all die CGs acg berücksichtigt werden,deren Erfüllung eine Aktivierung des Subsystems bedeuten. Ist einesdavon erfüllt (Disjunktion) und zusätzlich cg erfüllt (Konjunktion), dannist auch vcg/rcg erfüllt (Implikation).

Logical Operator. In der Tabelle ist die Definition ausschließlich für denAND-Operator und den Fall, dass der Block mehrere Eingänge besitzt,angegeben. Das Vorgehen ist allerdings relativ einfach auf die weiterenOperatortypen und die Blockvariante mit nur einem Eingang zu übertra-gen. Im dargestellten Fall werden je Vektorelement der Eingangssignalefolgende drei Zusammenhänge erfasst.

1. Von allen Eingangssignalen des Blocks (Konjunktion) muss min-destens ein CG icg, welches einer Belegung des Blockeingangs mitdem Wahrheitswert wahr (Signalwert ungleich 0) gleichzusetzen ist,erfüllt sein (Disjunktion), damit in Folge auch all die CGs ocg desAusgangssignals erfüllt sind, die durch den Wahrheitswert wahram Ausgang (Signalwert gleich 1) dominiert werden.

2. Ist mindestens ein CG icg der Eingangssignale erfüllt (Disjunktion),welches einer Belegung des entsprechenden Eingangs mit demWahrheitswert falsch gleichkommt (Signalwert gleich 0), so sind


Blocktyp Semantische Abhängigkeiten und virtuelle Überdeckungsziele

Inport

∀v∈N[1,d(s1)]:∀ cg∈ SCG(sv1):

Fall 1: ∃ sb∈B:b∈BCsb ∧ btsb=Subsystem

Fall 1.1: ∃ rcg∈ SCG(sv2): rcgdom−−→vcg∧ vcg dom−−→ rcg

Abh.: cgn(cg)∪ cgn(rcg)Fall 1.2: sonst

VCG: SCG(sv2)⊎

vcgAbh.: cgn(cg)∪ cgn(vcg)

Fall 2: ∃ sb∈B:b∈BCsb ∧ btsb=Enabled Subsystem

Fall 2.1: ∃ rcg∈ SCG(sv2): rcgdom−−→vcg∧ vcg dom−−→ rcg

Abh.: (cgn(cg)∧(∨

∀ acg∈A

cgn(acg)))→ rcg

Fall 2.2: sonstVCG: SCG(sv2)

⊎vcg

Abh.: (cgn(cg)∧(∨

∀ acg∈A

cgn(acg)))→vcg

mit s1= sigin(sb,n)∧s2= sigout(b,1)∧ vcg=�(cg ,sv1,sv2)

∧A=⋃

∀w∈N[1,d(s3)]

{ccg | ccg∈ SCG(sw3 )∧

ccg dom−−→� ∨

∀u∈N[1,d(s3)]

su3>0�}

LogicalOperator

Exemplarisch für •=∧ und n>1:∀v∈N[1,maxdin(b)]:

Abh.:

(1) (∧

∀p∈POS(

∨∀ icg∈ SCG(sw1 ):

icgdom−−→〈sw1 �=0〉

cgn(icg)))

→(∧

∀ ocg∈ SCG(sv2):

〈sv2=1〉 dom−−→ ocg

cgn(ocg))

(2) (∨

∀p∈POS :∀ icg∈ SCG(sw1 ):

icgdom−−→〈sw1 =0〉

cgn(icg))→(∧

∀ ocg∈ SCG(sv2):

〈sv2=0〉 dom−−→ ocg

cgn(ocg))

(3) ∀ ocg∈ SCG(sv2): ocgdom−−→〈sv2=1〉:

∀p∈POS :∀ icg∈ SCG(sw1 ): 〈sw1 �=0〉 dom−−→ icg :

cgn(icg) �� cgn(ocg)

mit s1= sigin(b ,p)∧s2= sigout(b,1)

∧ POS=N[1,| IPb |]∧w=vc(v,s1)

Tabelle 12: Block-spezifische Abhängigkeiten zwischen an den Ein- undAusgangssignalen eines Blocks anliegenden Überdeckungs-zielen und Bildung virtueller Überdeckungsziele (Auszug)


auch alle CGs ocg des Ausgangssignals erfüllt, die durch denWahrheitswert falsch am Ausgang (Signalwert gleich 0) dominiertwerden.

3. Die Erfüllung aller CGs ocg des Ausgangssignals, die den Wahr-heitswert wahr am Ausgang (Signalwert gleich 1) zur Folge haben,implizieren jeweils die Erfüllung aller CGs icg der Blockeingangssi-gnale, welche erfüllt wären, wenn der Wahrheitswert des jeweiligenEingangs wahr ist (Signalwert ungleich 0). Bei dieser Implikations-beziehung handelt es sich allerdings um eine rückwärtsgerichteteImplikation.

Die auf diesem Wege erfolgende Ermittlung semantischer Abhängigkei-ten formt gemeinsam mit zuvor ermittelten logischen Abhängigkeitenden finalen CG-Abhängigkeitsgraphen eines SL/TL-Modells. Dieser dientsowohl der ergänzenden Erreichbarkeitsprüfung als auch der Bildungeiner Abarbeitungsreihenfolge für die CGs. Gegebenenfalls im Abhängig-keitsgraphen entstandene Zyklen der Form CGNa → ...→CGNn werdenübrigens in einem letzten Schritt beseitigt. In einem Zyklus enthalteneCGs, beziehungsweise deren Graphknoten, sind de facto äquivalent undkönnen dementsprechend auch im Graph vereinigt werden – das heißt:CGNa,...,n =CGNa ∪ ...∪CGNn. Ein Zyklus wird wohlgemerkt nicht be-seitigt, wenn eine der im Zyklus enthaltenen Implikationsbeziehungenrückwärtsgerichtet ist.

3.3.2.5 Ergänzende Erreichbarkeitsprüfung

Die in Abschnitt 3.2 vorgestellte SIA-Technik dient einer Prüfung derErreichbarkeit der betrachteten CGs. Allerdings können über diesenAnsatz unter Umständen nicht alle unerreichbaren CGs identifiziertwerden. In manchen solcher Fälle kann die CGSeq-Technik helfen. Derdurch sie erzeugte CG-Abhängigkeitsgraph kann genutzt werden, um ausder durch SIA festgestellten Unerreichbarkeit (UNSAT) oder garantiertenErfüllung (SAT) eines CG Rückschlüsse auf andere CGs zu ziehen.

Zu diesem Zweck werden die Propagierungsregeln der folgend vorge-stellten drei Kategorien „Äquivalenz“, „Implikation“ und „XOR“ aufjeden Knoten eines CG-Abhängigkeitsgraphen, der ein unerfüllbares oderstets erfülltes CG enthält, angewendet. Im Falle der vierten Kategorie(„Widerspruch“) werden alle Knoten des Graphen, welche zu diesemZeitpunkt weder als unerfüllbar noch als stets erfüllt gelten, betrach-tet. Für alle Propagierungsregeln gilt: Erfolgt eine Propagierung einesCG-Zustands auf die CGs eines anderen Graphknotens, so wird auchdieser bezüglich möglicher weiterer Propagierungsmöglichkeiten unter-sucht. Der Nachweis der Gültigkeit aller Regeln kann relativ trivial überWahrheitstabellen geführt werden.


Äquivalenz. Wurde durch SIA festgestellt, dass ein CG unerreichbar(Fall 1) oder stets erreicht (Fall 2) ist, so gilt dieser Zustand auch füralle anderen CGs der Gruppe äquivalenter CGs, welcher dieses CGangehört.

∀n∈VCG: ∀ cg1, cg2 ∈n: (64)

Fall 1: st(cg1)=UNSAT ⇒ (st(cg2)=UNSAT∧ U@(cg2)=U@(cg1))

Fall 2: st(cg1)= SAT ⇒ (st(cg2)= SAT∧ S@(cg2)= S@(cg1))

Hierauf basierend sei die Funktion st, die den Zustand eines einzel-nen CG angibt, für die weiteren Betrachtungen auch für CG-Gruppendefiniert. Gleichermaßen werden auch die Funktionen U@/S@, welchedie Zeitschritte einer Unerfüllbarkeit/garantierten Erfüllung angeben,übertragen.

st : VCG → {UNSAT, SAT,OPEN}

st(n) =

⎧⎪⎪⎪⎨⎪⎪⎪⎩UNSAT , ∀ cg∈n: st(cg)=UNSAT

SAT , ∀ cg∈n: st(cg)=SAT

OPEN , sonst

(65)

S@,U@ : VCG → P(N)

S@(n) =⋂

cg∈n

S@(cg) =⋃

cg∈n

S@(cg) , U@(n) =⋂

cg∈n

U@(cg) =⋃

cg∈n

U@(cg)

Implikation. Wird ein unerreichbares CG durch ein anderes CG impli-ziert, so ist auch dieses CG, von dem die Implikation ausgeht, unerreich-bar (Fall 1). Handelt es sich um eine Implikation über einen Disjunktoren,so gilt dies für alle CGs, die im Abhängigkeitsgraph zu diesem Junktorenführen. Ein impliziertes CG wird hingegen als stets erreicht erkannt,wenn das CG, von dem die Implikation ausgeht, stets erreicht ist (Fall2). Führt diese Implikationsbeziehung über einen Disjunktor, so müss-te eines der zu dem Junktor führenden CGs stets erreicht sein. Führtsie über einen Konjunktor, so müssten alle zu dem Junktor führendenCGs stets erreicht sein. Fall 1 und 2 gelten auch für rückwärtsgerichteteImplikationsbeziehungen.

∀n1∈(VCG∪VK∪VD),n2∈VCG: (n1,n2)∈(E→∪E��):

Fall 1: st(n2)=UNSAT ⇒ (n1 ∈VK ⇒ (unsat(n1)∧ U@(n1)=U@(n2)))

Fall 2: sat(n1) ⇒ (st(n2)= SAT∧ S@(n2)= S@(n1))

mit sat, unsat : (VCG∪VK∪VD) → B (66)


sat(e)=

⎧⎪⎪⎪⎨⎪⎪⎪⎩st(e)= SAT , e∈VCG

∃(x, e)∈E→: sat(x) , e∈VD

∀(x, e)∈E→: sat(x) , e∈VK

unsat(e)=

⎧⎪⎪⎪⎨⎪⎪⎪⎩st(e)=UNSAT , e∈VCG

∀(x, e)∈E→: unsat(x) , e∈VD

0 , e∈VK

XOR. Schließen sich zwei CGs wechselseitig gegenseitig aus und ist einesder beiden CGs unerreichbar, so gilt das andere CG als stets erreicht (Fall1). Ist eines der beiden CGs hingegen stets erreicht und gilt dies für allebetrachteten Zeitschritte einer Modellausführung, so ist das andere ander XOR-Beziehung beteiligte CG unerreichbar (Fall 2).

∀n1,n2∈VCG: (n1,n2)∈E⊕:

Fall 1: st(n1)=UNSAT ⇒ (st(n2)= SAT∧ S@(n2)=U@(n1)) (67)

Fall 2: (st(n1)= SAT∧ S@(n1)=AT)

⇒ (st(n2)=UNSAT∧ U@(n2)=AT)

Widerspruch. Die CGs einer CG-Gruppe sind unerreichbar, wenn vondieser Gruppe Implikationsbeziehungen ausgehen und es in der Mengealler, auch transitiv implizierten CGs ein Paar zweier CGs bilden lässt, diesich bezüglich ihrer Erfüllung gegenseitig ausschließen. Hierbei werdenneben normalen, vorwärtsgerichteten Implikationsbeziehungen auchrückwärtsgerichtete Implikationsbeziehungen berücksichtigt.

∀n∈VCG:

(∃n1,n2∈ IG(n): (n1,n2)∈E⊕ ∪E↑) ⇒ (st(n)=UNSAT∧ U@(n)=AT)

mit IG : (VCG ∪ VD) → P(VCG)

IG(e)=⋃

(e,x)∈(E→∪E��)

⎧⎪⎪⎪⎨⎪⎪⎪⎩{x}∪ IG(x) , x∈VCG

IG(x) , x∈VD

∅ , sonst

(68)

Abbildung 18 zeigt ein Beispiel für eine solche Situation. Dargestellt sindein Modellausschnitt mit einem Teil der hieraus ableitbaren CGs und derdazugehörige CG-Abhängigkeitsgraph. Die durch SIA ermittelten Signal-wertebereiche sind ebenfalls im Modellausschnitt zu sehen. Basierendauf diesen Wertebereichen erkennt die Erreichbarkeitsanalyse von SIAfür keines der dargestellten CGs eine Unerreichbarkeit. Die ergänzendeErreichbarkeitsprüfung von CGSeq stellt allerdings durch Anwendung


∈

∈

∈

∈

(a) Modellausschnitt mit abgeleiteten Überdeckungszielen (Auszug)

&

(b) Abhängigkeitsgraph für die Überdeckungsziele aus Abbildung (a)

Abbildung 18: Beispiel zur ergänzenden Erreichbarkeitsprüfung

der Regel aus Definition 68 einen Widerspruch fest. Verfolgt man aus-gehend von cg9 die Implikationsbeziehungen im Abhängigkeitsgraph,so lassen sich mit cg1 und cg3 zwei CGs finden, die nicht gleichzeitigerfüllt sein können. Das CG cg9 ist daher unerfüllbar.

Aus der Erkennung von weiteren unerreichbaren oder stets erreichtenCGs können sich geringfügige Transformationen des CG-Abhängigkeits-graphen ergeben. Wird beispielsweise für ein CG, welches im Graphenzu einem Disjunktoren führt, festgestellt, dass dieses unerreichbar ist, sokann die Kante von diesem CG zum Disjunktoren entfernt werden.

3.3.3 abarbeitungsreihenfolgenbildung

Wie einführend erläutert, dient die Erfassung der Abhängigkeiten zwi-schen CGs letzten Endes der Ableitung einer Abarbeitungsreihenfolge fürdie CGs. Diese Reihenfolge wird nach Durchführung von CGSeq verwen-det, um die CGs nacheinander jeweils mit Testdatensuchen anzuvisieren.


Genau genommen werden nicht die CGs anvisiert, sondern sogenannteSuchziele (SGs), welche CGSeq bildet. Bei einem SG kann es sich sowohlum ein einzelnes CG als auch um eine Kombination von CGs handeln.Bei der Behandlung des Beispiels aus Abbildung 17 in Abschnitt 3.3.2.4wurde bereits angedeutet, dass es unter Umständen von Vorteil seinkann, bei einer Testdatensuche mehrere CGs gleichzeitig anzuvisieren.Die Abarbeitungsreihenfolge bestimmt CGSeq dementsprechend für diegebildeten SGs und somit nicht direkt für die CGs. Die SG-Bildung unddie Priorisierungsmetriken, welche die Reihenfolgenbildung bewirken,werden in den nächsten zwei Abschnitten vorgestellt.

3.3.3.1 Ableitung von Suchzielen

Ein SG ist formal betrachtet eine Menge von CGs:

sg⊆E (69)

Für ein SG wird die folgende Schreibweise verwendet:

(a, ...,n) ⇔ sg = {cga, ..., cgn} (70)

Die statische Voranalyse CGSeq bildet die SGs in drei Schritten:

1. Reduzierung des Abhängigkeitsgraphen gemäß Testziel oder Nut-zerwahl

2. Bildung singulärer SGs (enthalten je ein CG)

3. Bildung zusammengesetzter SGs (enthalten mehrere CGs)

Gilt die Testdatengenerierung der Automatisierung eines Strukturtests, soerfolgt üblicherweise eine Auswahl des oder der betrachteten Überdeck-ungskriteriums/-kriterien. Möglich ist auch, dass manuell eine Auswahlaus den verfügbaren CGs getroffen wird. Eine funktionale Eigenschaft,welche es im Rahmen eines Funktionstests – wie er in dieser Arbeitbetrachtet wird (siehe Abschnitt 2.2.2) – zu erreichen oder zu widerlegengilt, kann ebenfalls als ein einzelnes ausgewähltes CGs betrachtet werden.Unabhängig von der Testart gibt es eine Teilmenge der CGs, welche eszu erreichen gilt. Im Folgenden wird ein in dieser Teilmenge enthaltenesCG auch als selektiertes CG bezeichnet. Der CG-Abhängigkeitsgraphwird durch CGSeq entsprechend dieser Teilmenge reduziert. Hierzuwerden zum einen nicht-selektierte CGs aus Gruppen äquivalenter CGsentfernt – vorausgesetzt, die Gruppe besitzt mindestens ein selektiertesCG. Zum anderen werden nicht-selektierte CGs und gegebenenfallsderen Knoten im Abhängigkeitsgraphen entfernt, falls von diesem CGausgehend keinerlei Implikationsbeziehungen zu einem selektierten CGexistieren, das heißt auch keine transitiven Verbindungen.


Nachdem ein CG-Abhängigkeitsgraph auf diese Weise zugeschnittenwurde, werden singuläre SGs gebildet. Hierzu wird nacheinander jedesselektierte CG cg herangezogen, das durch die Erreichbarkeitsprüfungenvon SIA und CGSeq nicht als unerreichbar (UNSAT) oder stets erreicht(SAT) identifiziert wurde – das heißt st(cg)=OPEN. Aus jedem solchenCG wird ein singuläres SG gebildet. Gegebenenfalls bildet für jedes cgzusätzlich ein anderes, dieses CG repräsentierendes CG ein SG. Hierzuwird durch Ablaufen der Implikationsbeziehungen im Abhängigkeits-graphen, welche direkt oder transitiv zu cg führen, eine Menge von CGsgebildet. In dieser Menge sind all die CGs enthalten, deren singuläreErfüllung jeweils die Erfüllung von cg zur Folge hätte – und cg selbst.Aus dieser Menge wird ein CG ausgewählt, welches ein singuläres SGbildet und cg somit repräsentiert. Die Auswahl erfolgt auf Grundlage derMetriken, welche primär der nachfolgenden Sortierung aller gesammel-ten SGs dienen und daher erst im nächsten Abschnitt vorgestellt werden.Ein CG wird selbstverständlich nur dann in Form eines singulären SG derentstehenden SG-Menge hinzugefügt, wenn diese noch kein singuläresSG mit dem selben CG beinhaltet.

Wieso aber werden sowohl ein selektiertes CG als auch ein hierzu pas-sendes repräsentierendes CG als SG herangezogen? Nun, handelt essich bei dem selektierten CG beispielsweise um eines, welches durcheine Testdatensuche schwer zu erreichen ist, so besteht die Hoffnung,dass das repräsentierende CG im Vergleich hierzu einfacher zu erreichenist. Dennoch wird das selektierte CG ebenfalls als singuläres SG aufge-nommen, da auch das Gegenteil der Fall sein kann. Für das Beispiel inAbbildung 13 gilt beispielsweise: Das CG cg1 (s�90) weist eine hoheKollateralüberdeckung auf und repräsentiert somit unter anderem cg5(s�50). Der Wertebereich des Signals s lässt Werte von 0 bis 100 zu. ImVergleich zu cg5 ist cg1 somit möglicherweise schwerer zu erreichen. Fürden Fall, dass die Testdatensuche für cg1 nicht erfolgreich abgeschlos-sen werden kann, ist es daher ratsam, nachfolgend auch cg5 mit einerTestdatensuche anzuvisieren.

Ausgangspunkt der Bildung zusammengesetzter SGs sind gegebenenfallsin einem CG-Abhängigkeitsgraphen vorhandene Konjunktoren. Das Vor-gehen hierbei sei anhand von Abbildung 19 erklärt. Dargestellt sind einBeispiel-Modell und ein Auszug des aus diesem Modell hervorgehendenCG-Abhängigkeitsgraphen. Wie zu sehen ist, enthält dieser Graph zweiKonjunktoren. Diese sind mit den Bezeichnern k1 und k2 benannt. Fürjeden Konjunktor wird, wie dargestellt, eine Baumstruktur aufgebaut,welche diejenigen Graphknoten enthält, die über direkte oder transitiveImplikationsbeziehungen zu dem Konjunktor führen. Gelangt CGSeq beidieser Rückverfolgung der Implikationsbeziehungen an einen weiterenKonjunktor, so endet die Rückverfolgung und in der Baumstruktur wirdeine Referenz auf die Baumstruktur des anderen Konjunktors gesetzt. Ab-bildung 19c zeigt die nach diesem Schema aufgebauten Baumstrukturen


(a) Beispielmodell

&

||

&

(b) Auszug des Überdeckungsziel-Abhängigkeitsgraphen zu (a)

(c) Bildung zusammengesetzter Suchziele über Gruppierung von Überde-ckungszielen gemäß der Abhängigkeiten aus (b)

Abbildung 19: Vorgehen zur Bildung von zusammengesetzten Suchzielenanhand eines Beispielmodells


für k1 und k2. Die in den Baumstrukturen enthaltenen CG-Gruppen wer-den anschließend bezüglich ihres Einflusses auf die jeweilige Konjunktiongruppiert. Dieser Schritt verhindert, dass zu viele zusammengesetzteSGs gebildet werden. Für das Beispiel ergeben sich die vier Gruppen g1,g2, g3 und g4. Zur Erfüllung der Konjunktion k2 ist es notwendig, dassjeweils ein CG aus den Gruppen g3 und g4 erfüllt ist. Im Falle von k1werden zum einen die Gruppen g1 und g2 als Kombination gewählt undzum anderen die Kombination g1, g3 und g4, welche durch Berücksich-tigung der referenzierten Baumstruktur von k2 entsteht. Um aus diesenGruppen-Kombinationen abschließend zusammengesetzte SGs zu bilden,wird unter Verwendung der im nachfolgenden Abschnitt vorgestelltenMetriken aus jeder Gruppe ein CG ausgewählt. Für das Beispiel ergebensich die SGs (7, 9), (21, 7, 9) und (21, 17).

In Abschnitt 2.4.2 wurde die Fitnessberechnung für ein CG im Zuge einerTestdatensuche behandelt. Bei Nutzung von CGSeq berechnet sich dieFitness für ein SG anstatt direkt für ein CG. Im Falle eines singulärenSG entspricht die Fitness der des enthaltenen CG. Im Falle eines zusam-mengesetzten SG ist die Fitness das arithmetische Mittel der Fitness derenthaltenen CGs.

3.3.3.2 Priorisierungsmetriken

Die hier vorgestellten Metriken dienen unter anderem, wie im vorigenAbschnitt festgestellt, der Bildung von SGs durch Bestimmung geeigneterCGs. Der hauptsächliche Verwendungszweck dieser Metriken ist aller-dings ein anderer. Die untereinander priorisierten Metriken bewirkennämlich eine Sortierung einer SG-Menge. Diese Sortierung bestimmt, inwelcher Reihenfolge ein jedes SG anschließend mit einem eigenen Such-vorgang zum Zwecke einer Testdatensuche anvisiert wird. Im Folgendenwerden die vier Priorisierungsmetriken vorgestellt. Abbildung 20 fasstdiese Ausführungen zusammen.

Anzahl Boolescher Signale (M1). In einem CG-Ausdruck enthaltene Si-gnale mit einem Booleschen Wertebereich sind für eine Testdatensucheproblematisch (siehe Abschnitt 2.5). Im Sinne einer effizienten Testda-tengenerierung ist es daher sinnvoll, SGs, deren CGs in Summe einehöhere Anzahl Boolescher Signale enthalten, an das Ende der Liste ab-zuarbeitender SGs zu setzen. Die Nutzung dieser Metrik setzt voraus,dass die SIA-Technik verwendet wird. Die Metrik hat unter den vier Me-triken die höchste Priorität. Der Grund hierfür ist, dass eine Bewertunggenerierter Testdaten mit einer Fitnessfunktion, die im Extremfall einenBooleschen Wertebereich besitzt, bei Nutzung eines Suchverfahrens zurTestdatengenerierung sehr nachteilig für deren Effizienz ist.


Abbildung 20: Übersicht über die zur Suchzielpriorisierungverwendeten Metriken

Anzahl implizierter CGs (M3). Hauptziel der CGSeq-Technik ist eineSteigerung der Kollateralüberdeckung bei einer Testdatensuche für einSL/TL-Modell. Aus dem CG-Abhängigkeitsgraphen lässt sich für ein CGermitteln, wie viele andere CGs mindestens erfüllt wären, wenn das be-trachtete CG bei einer Modellausführung erfüllt wäre. Hierzu gilt es, diedirekten und transitiven vorwärtsgerichteten Implikationsbeziehungen,ausgehend von dem betrachteten CG, zu traversieren. Hierbei ist jedesselektierte CG der besuchten CG-Gruppen in eine Menge implizierterCGs aufzunehmen. Im Falle eines zusammengesetzten SG ist dies fürjedes enthaltene CG durchzuführen. Die dabei entstehenden Mengen derjeweils implizierten CGs werden anschließend vereinigt. Die Anzahl derCGs in dieser vereinigten Menge ist die gesuchte Anzahl. Unter den vierMetriken hat die Anzahl implizierter CGs nur die dritthöchste Priori-tät. Warum, wird im Zusammenhang mit der nachfolgend vorgestelltenMetrik deutlich.

Modelltiefe (M2). Für jedes an einem CG-Ausdruck beteiligten Signallässt sich eine minimale Entfernung zu einem der Modelleingänge be-stimmen. Diese als Modelltiefe bezeichnete Entfernung wird durch dieAnzahl der Signale zwischen betrachtetem Signal und einem Model-leingang bemessen. Wird neben CGSeq auch die SDA-Technik genutzt,so verwendet CGSeq hierzu den durch SDA erstellten Signalabhängig-keitsgraphen. Andernfalls wird die Modelltiefe direkt aus der Strukturdes betrachteten SL/TL-Modells abgeleitet. Für die Modelltiefe eines


CG gilt: Enthält das CG mehrere Signale, so ist dessen Modelltiefe dasarithmetische Mittel der Modelltiefen der Signale. Letzten Endes wird dieModelltiefe eines SG benötigt. Im Falle eines zusammengesetzten SGs istdies ebenfalls das arithmetische Mittel der Modelltiefen der enthaltenenCGs, andernfalls die des einzigen enthaltenen CG. Die Metrik der Mo-delltiefe besitzt die zweithöchste Priorität. Dies hat folgenden Grund: Umeine möglichst hohe Kollateralüberdeckung bei einer Testdatensuche zuerreichen, sollte normalerweise die Metrik der Anzahl implizierter CGseine höhere Priorität besitzen. Allerdings handelt es sich bei dieser An-zahl nur um einen Mindestwert, da die Analyse der CG-Abhängigkeitenunter Umständen nicht alle tatsächlich existierenden Abhängigkeitenerfasst. Gibt es beispielsweise einen unbekannten Block, für den sichkeine semantischen Abhängigkeiten ableiten lassen, so wird hierdurchmöglicherweise eine Kette von Implikationsbeziehungen unterbrochen,beziehungsweise ein Glied dieser Kette erst gar nicht erkannt. Betrachtetman demzufolge einen CG-Abhängigkeitsgraphen als eine Ansammlungvon nicht zusammenhängenden Teilgraphen, so stellt die Modelltiefeder in den Teilgraphen enthaltenen CGs ein auf dieser übergeordnetenEbene betrachtet geeigneteres Maß für die zu erwartende Kollateralüber-deckung dar. Denn je näher ein CG sich bezüglich der Lage seiner Signalean den Modelleingängen befindet, desto mehr im Signalfluss folgendeCGs sollten durch das Erreichen dieses CG mit erreicht werden.

Anzahl relevanter Modelleingänge (M4). Wird die SDA-Technik ver-wendet, so ist bekannt, von welchen Modelleingängen die Erfüllungeines CG abhängt. Die Erfüllung eines SG ist entsprechend von all denenModelleingängen abhängig, von denen mindestens eines der enthalte-nen CGs abhängt. Die Verwendung dieser Metrik als weiteres Priorisie-rungskriterium adressiert nicht die Kollateralüberdeckung, sondern dieerwartungsgemäß effizientere Durchführung einer Testdatensuche beigeringerer Suchraumgröße (siehe Abschnitt 3.2.1).

Die aus dem CG-Abhängigkeitsgraphen abgeleiteten SGs werden unterZuhilfenahme dieser Metriken sortiert. Hierbei gilt: Liefert eine Metrikfür zwei oder mehrere SGs das gleiche Ergebnis, so entscheidet dienachfolgende, geringer priorisierte Metrik über die Sortierung der betref-fenden SGs untereinander. Unterscheiden sich zwei oder mehrere SGsauch nach Anwendung aller vier Metriken nicht bezüglich der ermitteltenMaße, so erfolgt eine zufällige Sortierung dieser SGs untereinander.

Durch Beachtung dieser Sortierung bei der Abarbeitung der SGs mittelsSuchvorgängen ist eine insgesamt effizientere Testdatengenerierung zuerwarten. Diese Annahme fußt auch auf kleineren Experimenten, welcheim Zuge der Entwicklung von CGSeq – insbesondere zur Bestimmungder Reihenfolge der Priorisierungsmetriken – durchgeführt wurden. Diein Kapitel 6 vorgestellten Fallstudien untersuchen in diesem Zusammen-hang, welche Auswirkungen die Nutzung einer statischen Voranalyse


wie CGSeq auf eine automatisierte Testdatengenerierung hat. Dabei wirdauch der zusätzliche Aufwand, den eine vorherige Anwendung vonCGSeq mit sich bringt, berücksichtigt und untersucht.


Das Ziel, die Kollateralüberdeckung einer suchbasierten Testdatenge-nerierung im Kontext eines Strukturtests zu steigern, wurde bereits inanderen Arbeiten adressiert. Die existierenden Ansätze unterscheidensich allerdings grundlegend von der durch CGSeq verfolgten Idee.

Fraser und Arcuri streben in einer ihrer Arbeiten [40] die Erhöhung derKollateralüberdeckung bei einem suchbasierten Strukturtest für Java-Code an. Hierbei generieren sie mittels eines genetischen Algorithmusganze Testsuiten anstatt einzelner Testdaten. Ein durch die Suche erzeug-ter Lösungsvorschlag enthält also eine ganze Menge an Testdaten. DieFitnessfunktion ist derart gestaltet, dass die Suche neben der Erfüllungeines bestimmten CG auch eine Maximierung des durch die erzeugtenTestsuiten erzielten Überdeckungsgrads anstrebt. Haben zwei Testsuitenhierbei den gleichen Überdeckungsgrad, so erhält die Testsuite mit weni-ger Testdaten einen vergleichsweise besseren Fitnesswert. Experimentezeigen, dass dieser Ansatz im Vergleich mit einem klassischen suchbasier-ten Ansatz tatsächlich zu einer höheren Kollateralüberdeckung, sowiekleineren Testsuiten, führen kann. Harman et al. verfolgen einen hierzuähnlichen Ansatz [62]. Die Suche generiert in ihrem Fall zwar keineTestsuiten, sondern einzelne Testdaten, jedoch beziehen sie das Kriteriumder Kollateralüberdeckung ebenfalls mit in eine Suche ein. Dies geschiehtim Rahmen einer sogenannten Multi-Objective Optimization, welche einergleichzeitigen Anvisierung mehrerer Ziele dient. Experimente der Auto-ren zeigen, dass ihr Vorgehen zu geringeren Testsuitegrößen und hiermitverbunden, zu einer höheren Kollateralüberdeckung führt.

Ein weiterer Ansatz weist Gemeinsamkeiten mit CGSeq auf – allerdingsbeschränkt auf einen bestimmten Teilaspekt. McMinn und Holcombebeschäftigen sich in einer Arbeit [84] mit der suchbasierten Testdaten-generierung für C-Code. Der klassische suchbasierte Ansatz wird dabeium folgende Idee ergänzt: Für bestimmte, schwer erreichbare Zuständeoder Suchziele wird auf statischem Wege aus dem Programmcode desTestobjekts eine Folge von Ereignissen (englisch: event sequence) abge-leitet. Hierbei gilt, dass das Eintreten einer Folge von Ereignissen beiAusführung des Testobjekts das Erreichen des gewünschten Zustandsoder Suchziels impliziert. Das Ziel, eine solche Ereignisfolge zu erreichen,wird entsprechend in die Fitnessfunktion aufgenommen und somit durchdie Testdatensuche berücksichtigt. Dieses Vorgehen weist Ähnlichkeiten


zu CGSeq auf. Auch CGSeq versucht, für ein anvisiertes, unter Umstän-den schwer erreichbares CG zu ermitteln, ob es andere Zustände (inForm anderer CGs) gibt, deren Erfüllung die Erfüllung des anvisiertenCG impliziert. Eine derartige Hilfestellung zum Erreichen schwer er-reichbarer (siehe hierzu auch Abschnitt 2.5 zum Thema „Blindheit derFitnessfunktion“) oder auch Boolescher Zustände ist allerdings nur einTeilaspekt von CGSeq. Primär geht es CGSeq um eine Steigerung derKollateralüberdeckung und Effizienz einer Testdatensuche. Das gewählteMittel besteht bei CGSeq, anders als bei den hier genannten Arbeiten,grundsätzlich auch nicht in der zusätzlichen Aufnahme weiterer Zie-le in eine Fitnessfunktion, sondern in der Gestaltung einer möglichstoptimalen CG-Abarbeitungsreihenfolge.

Eine Arbeit, die sich mit einer solchen Reihenfolgenbildung auseinander-setzt, stammt von Li et al. [81]. Die Autoren betrachten die strukturori-entierte Testdatengenerierung für C-Code. In diesem Kontext ist es dasZiel ihres Ansatzes, nur eine minimale Menge an Pfaden im Kontroll-flussgraphen betrachten zu müssen und dennoch den größtmöglichenÜberdeckungsgrad zu erzielen. Hierzu werden Pfade aus dem Kontroll-flussgraphen in geordneter Folge ausgewählt und anschließend für diesePfade jeweils Testdaten abgeleitet – Li et al. verwenden hierzu eine binäreSuche. Die Pfadauswahl und -ordnung basiert auf einer Gewichtung derKnoten des Kontrollflussgraphen. Die Gewichtung eines Knoten gibtan, wie viele andere Knoten durch ihn dominiert werden. Ein Knoten a

dominiert einen anderen Knoten b, wenn die Ausführung der Codezeile,welche a referenziert, die Ausführung von der zu b gehörenden Codezei-le zur Folge hat. Dieses Vorgehen ist dem von CGSeq grundlegend sehrähnlich. Bei CGSeq ist jedoch nicht etwa ein Kontrollflussgraph, sondernein CG-Abhängigkeitsgraph Grundlage für die Reihenfolgenbildung.Zudem existieren zum Zwecke dieser Reihenfolgenbildung neben derMetrik der Anzahl implizierter CGs, welche mit der Knotengewichtungbei Li et al. vergleichbar ist, weitere Metriken.

Eingebettet in den hier behandelten wissenschaftlichen Kontext zeichnetsich CGSeq durch folgende Eigenschaften und Beiträge aus:

1. Ermittlung logischer und semantischer (das heißt aus der Modell-semantik abgeleiteter) Abhängigkeiten zwischen CGs

2. CG-Erreichbarkeitsprüfung auf Basis von CG-Abhängigkeiten, inErgänzung zur SIA-Technik

3. Bildung einer Abarbeitungsreihenfolge der CGs über Metriken, dievergleichsweise „einfach“ erreichbare CGs und solche mit einerpotentiell hohen Kollateralüberdeckung bevorzugen


3.4 kombination der techniken

Bei der Vorstellung der drei statischen Voranalysen SIA, SDA und CGSeqin diesem Kapitel wurde bereits herausgestellt, dass die Ergebnisse derAnalysen nicht nur der Vorbereitung der Testdatengenerierung dienen,sondern diese auch zum Teil von den Analysen untereinander genutztwerden. In diesem Abschnitt soll das Zusammenwirken zwischen denstatischen Voranalysen und deren Einbettung in das in dieser Arbeitbehandelte Testdatengenerierungsverfahren daher zusammenfassendbetrachtet werden.

Abbildung 21 gibt hierzu einen Überblick. Die statischen Voranalysen(Bereich in der Mitte) betten sich zwischen der Initialisierung der Test-datengenerierung (Bereich oben) und der Testdatengenerierung selbst(Bereich unten) ein. Die Vorgänge und entstehenden Artefakte innerhalb

Abbildung 21: Zusammenspiel der statischen Voranalysen untereinanderund Einbettung in den Anwendungskontext

3.4 kombination der techniken 139

dieser Bereiche sind in der Darstellung entsprechend der Reihenfolgeihrer Durchführung oder ihres Auftretens nummeriert.

Im ersten Schritt wird das betrachtete SL/TL-Modell in eine Repräsen-tation überführt, mit der die nachfolgenden Vorgänge und Analysenarbeiten. Hierbei werden, wie zu Anfang dieses Kapitels erläutert, grund-legende Modelltransformationen durchgeführt. Anschließend wird dasModell auf alle betrachteten Überdeckungskriterien hin untersucht undhierbei eine Gesamtmenge von CGs abgeleitet (siehe Abschnitt 2.2.1).Der Nutzer unterstützt die Testdatengenerierung durch Angabe einerModelleingangsspezifikation (siehe Abschnitt 2.4.2). Des Weiteren wähltder Nutzer, sofern es sich um eine Testdatengenerierung im Sinne einesStrukturtests handelt, eines oder mehrere Überdeckungskriterien aus.Handelt es sich um einen anderen Anwendungsfall, wie beispielswei-se einen Funktionstest, so kann es sich hierbei auch um eine Auswahleinzelner Zieldefinitionen handeln, welche CG-ähnlich formuliert sind.Unabhängig davon resultiert diese Nutzerwahl in einer Menge selektier-ter CGs.

Bevor nun die Testdatengenerierung stattfindet, kommen die statischenVoranalysen ins Spiel. Die Überdeckungsziel-Erreichbarkeitsprüfung(SIA) ermöglicht eine Ermittlung unerreichbarer und stets erreichter CGsin der Menge sämtlicher CGs. Diese müssen bei der Testdatengenerie-rung nicht weiter betrachtet werden. SIA verwendet für diese Ermittlungdie Modellrepräsentation und die Modelleingangsspezifikation.

Die anschließend durchgeführte Modelleingang-Abhängigkeitsermittlung(SDA) prüft für ein jedes erfüllbares CG der Menge aller CGs, welcheModelleingänge bei einer Testdatengenerierung mit passenden Datenversorgt werden müssen, damit eine Erfüllung des jeweiligen CG erzieltwerden kann. Irrelevante Modelleingänge können bei einer späteren Test-datengenerierung zum Teil ausgeklammert werden. SDA nutzt nicht nurdie Modellrepräsentation, sondern über diese indirekt auch Ergebnis-se von SIA– denn SIA führt unter Umständen Modelltransformationendurch, welche im Falle von SDA die Genauigkeit der Ergebnisse erhöhenkönnen.

Die Suchzielbildung und -priorisierung (CGSeq) analysiert Abhängig-keiten zwischen sämtlichen CGs, bildet hierauf basierend unter Ver-wendung der Menge selektierter CGs sogenannte Suchziele (SGs) undbestimmt für diese eine sinnvolle Abarbeitungsreihenfolge, die bei derdarauffolgenden Testdatengenerierung Berücksichtigung findet und dorteine Effizienzsteigerung bewirken soll. Zur Abhängigkeitsanalyse nutztCGSeq unter anderem auch die Ergebnisse von SIA. Zur Bildung derAbarbeitungsreihenfolge werden sowohl Ergebnisse von SIA als auchvon SDA genutzt.


Die statischen Voranalysen sind wohlgemerkt so gestaltet, dass sie auchunabhängig voneinander arbeiten können. Jedoch kann ein solch parti-eller Einsatz zu Abstrichen bei Umfang und Genauigkeit der Analyse-Ergebnisse führen. Dieser Aspekt ist insbesondere für die Untersuchun-gen der Fallstudien dieser Arbeit von Relevanz.

Wird die Testdatengenerierung mittels einer, wie in Abschnitt 2.4.2 be-schriebenen, globalen Suche durchgeführt, so schließt sich diese in derDarstellung in Schritt acht an. In der Darstellung ist jedoch zu lesen,dass jedes SG mit einem geeigneten Testdatengenerierungsverfahrenbearbeitet wird. Diese Formulierung greift bereits auf die Inhalte desnächsten Kapitels vor. Denn das hybride Testdatengenerierungsverfah-ren dieser Arbeit verwendet anstatt einer globalen Suche mitunter auchSMT-Solving zur Erzeugung von Testdaten.

Nach jedem Suchvorgang für ein SG erfolgt übrigens eine Filterungund Neuordnung der Abarbeitungsreihenfolge. Filterung bedeutet, dassgegebenenfalls SGs entfernt werden. Ein SG ist hiervon in zwei Fällenbetroffen: einerseits, wenn alle enthaltenen CGs erreicht wurden – an-dererseits, wenn es kein unerreichtes, selektiertes CG enthält und inder Menge der von diesem SG implizierten, selektierten CGs kein uner-reichtes CG mehr vorkommt. Anlass für eine Neuordnung ist ebenfalls,dass während des vorherigen Suchvorgangs möglicherweise eines odermehrere CGs erreicht wurden. Dies ändert die Berechnungsgrundlageder initialen Abarbeitungsreihenfolge, da diese zur Sortierung die Me-trik der Anzahl der durch ein SG implizierten und gleichzeitig bislangunerreichten CGs nutzt. Es erfolgt allerdings lediglich eine erneute Be-rechnung der Metriken und eine entsprechende Sortierung der SGs. DieAbhängigkeitsanalyse von CGSeq wird nicht wiederholt.

4 GENER IERUNGSVERFAHREN

Die Hybridisierung der Testdatensuche für SL/TL-Modelle durch eineAngliederung statischer Voranalysen stellt den Hauptbeitrag dieser Ar-beit dar. Darüber hinaus wurde allerdings auch untersucht, inwieferneine Erweiterung des in der zugrundeliegenden Arbeit von Windisch[132] genutzten globalen Suchverfahrens oder der Einsatz alternativerGenerierungstechniken zu einer effizienten Testdatengenerierung fürSL/TL-Modelle beitragen können.

Zwei Ansätze wurden in diesem Zusammenhang verfolgt. Ersterer adres-siert die in Abschnitt 2.4.1 behandelte Unterscheidung lokaler und globa-ler Suchverfahren. Der folgende Abschnitt stellt ein lokales Suchverfahrenzur Testdatengenerierung für SL/TL-Modelle vor. Der zweite Ansatz,welcher Thema des darauffolgenden Abschnitts ist, befasst sich mit einerTestdatengenerierung mittels SMT-Solving. In letzterem Fall wurde eineHybridisierung der alternativen Generierungstechnik mit der globalenTestdatensuche realisiert.

4.1 generierung mittelslokaler suche

Das im Rahmen dieser Arbeit geschaffene lokale Suchverfahren basiertauf der AVM. Entsprechend seines spezifischen Anwendungsbereichs,der Testdatengenerierung für SL/TL-Modelle, wird es als alternierendeSignalparameteroptimierung (ASPO) bezeichnet. Die Zielstellung von AS-PO wird im folgenden Teilabschnitt erläutert. Anschließend wird dieFunktionsweise von ASPO erklärt und der Beitrag, den dieses Verfahrendarstellt, im Kontext verwandter Arbeiten diskutiert.

Vorweg ein Hinweis: ASPO ist im Rahmen einer Masterarbeit entstanden[63]. Die Inhalte von Abschnitt 4.1 stammen daher zum Teil aus dieserArbeit oder sind an die dortigen Darstellungen und Beschreibungenangelehnt.

141

142 generierungsverfahren

4.1.1 ziel

Es wurde bereits einführend behandelt, dass bei Suchverfahren grund-legend zwischen lokalen Suchen (LS) und globalen Suchen (GS) zuunterscheiden ist. Hierbei wurde hervorgehoben, dass eine LS tendenzi-ell effizienter im Umgang mit Problemstellungen ist, bei denen es um dasFinden eines lokalen Optimums im betrachteten Suchraum geht. Eine GShingegen besitzt ihre Stärken, wenn es um das Auffinden des globalenOptimums geht – oder allgemeiner ausgedrückt, wenn es unerwünschtist, dass die Suche in beliebigen lokalen Optima endet. Die vorliegendeArbeit geht, wie in Abschnitt 2.4.2 behandelt, vom Einsatz einer GS zurTestdatengenerierung für SL/TL-Modelle aus. Bei dieser GS handelt essich um einen längenvariablen genetischen Algorithmus (LGA).

Die Frage, ob sich für das betrachtete Anwendungsgebiet eine LS odereine GS besser eignet, lässt sich ohne eine Gegenüberstellung zweier ent-sprechender Ansätze nicht beantworten. Der an dieser Stelle vorgestellteTeilbeitrag dieser Arbeit ist durch diese Fragestellung motiviert. Erst nachBeantwortung dieser Fragestellung lässt sich über Möglichkeiten zur Hy-bridisierung beider Varianten einer suchbasierten Testdatengenerierungnachdenken. Um zu diesem Punkt zu gelangen, wird eine LS benötigt,die für SL/TL-Modelle anwendbar ist und die imstande ist, Testdaten inähnlicher Form wie der LGA zu generieren. Die Forschungsfrage lautetdaher an dieser Stelle: Lässt sich eine LS gestalten, die im Vergleich zumLGA effizienter und mit zumindest gleichbleibendem Erfolg plausibleTestdaten für ein SL/TL-Modell generiert?

Bei der hierzu entwickelten ASPO handelt es sich um eine LS, welcheTestdaten, wie auch der LGA, in Form von Optimierungssequenzen be-trachtet. Dies bedeutet, dass ein Signal, welches für jeden Modelleingangerzeugt und im Rahmen einer Suche variiert wird, als eine Sequenzvon Signalsegmenten aufgefasst wird – wobei jedes Segment drei Para-meter besitzt. Trotz einer solchen Abstrahierung von der tatsächlichenKomplexität eines Signals stellt die Verwendung von Optimierungsse-quenzen eine Herausforderung für die Anwendung von gängigen lokalenSuchverfahren dar. Der Grund hierfür ist, dass lokale Suchverfahren dieNachbarschaft eines während der Suche betrachteten Lösungsvorschlagsnicht nur sehr systematisch, sondern auch nahezu erschöpfend unter-suchen. Mit steigender Anzahl zu optimierender Parameter wächst dieKomplexität einer solchen Nachbarschaftsuntersuchung. Eine LS, welchesich diesem Problem im besonderen Maße angenommen hat, ist die AVM[76]. ASPO ist eine Variante der AVM, welche Signale anstatt gängigerProgrammvariablentypen (Zahlen oder Strings) optimiert.

ASPO führt, entsprechend der in dieser Arbeit betrachteten spezifischenTestdatenrepräsentation (Optimierungssequenzen), eine Nachbarschafts-untersuchung für Signale durch. Im folgenden Abschnitt 4.1.2 wird daher

4.1 generierung mittels lokaler suche 143

die Nachbarschaft eines Signals definiert. Der Ablauf einer LS mit ASPOwird im daran anschließenden Abschnitt 4.1.3 vorgestellt.

4.1.2 nachbarschaftsdefinition für signale

Der Nachbarschaftsbegriff im Rahmen einer LS wurde bereits in Ab-schnitt 2.4.1 eingeführt. Im Allgemeinen wird ein Lösungsvorschlag imSuchraum als benachbart bezeichnet, wenn er vom betrachteten Lösungs-vorschlag aus gesehen durch Anwendung eines sogenannten Bewegungs-operators in einem Schritt erreicht werden kann [93]. Die Größe undArt einer Nachbarschaft ist stark von der verwendeten Repräsentationeines Lösungsvorschlags und den verwendeten Bewegungsoperatoren ab-hängig. Im Folgenden werden Überlegungen bezüglich einer geeignetenNachbarschaftsdefinition für Signale, inklusive geeigneter Bewegungs-operatoren, angestellt.

4.1.2.1 Parametermodifikationen

Die Modifikationen eines Signals oder mehrerer Signale im Rahmen einerLS sollten eine möglichst systematische und ganzheitliche Untersuchungdes Suchraums ermöglichen. Eine bloße Verschiebung eines Signals aufseiner Werte- oder Zeitachse wird diesem Anspruch beispielsweise nichtgerecht. Eine gezielte Änderung einzelner Signalwerte ist ebenfalls nichtratsam. Dieses Vorgehen könnte zu Signalen führen, die im Konflikt mitder geforderten Plausibilität der Testdaten stehen. Unabhängig davon, obTestdaten mit einer GS oder einer LS generiert werden, ist es aus prakti-schen Gründen nämlich wünschenswert, dass die automatisch erzeugtenTestdaten realistische Daten darstellen. Es besteht daher die Anforderung,dass eine LS, welche zur Signalgenerierung genutzt wird, ebenfalls die inAbschnitt 2.4.2 behandelte segmentbasierte Signalrepräsentation nutzt.

Um die Nachbarschaft eines Signals mitsamt Bewegungsoperatoren zudefinieren, gilt es also, die Parameter einer Optimierungssequenz zuadressieren. Jedes Segment einer Optimierungssequenz besteht aus dreiverschiedenartigen Parametern: einem Amplitudenwert, einer Segment-breite und einem Transitionstypen. Modifikationen dieser Parameterermöglichen eine Generierung fast beliebiger Signale [133] – eine ein-schränkende Wirkung wird einzig durch Angaben in der Modellein-gangsspezifikation und durch eine mögliche Festsetzung der Anzahl vonSignalsegmenten erzielt. Führt eine LS eine Nachbarschaftsuntersuchungmittels Modifikation der Parameter einer Optimierungssequenz durch,so ist die eingangs gestellte Forderung, eine möglichst ganzheitlicheUntersuchung des Suchraums zu ermöglichen, daher erfüllt.


Die Nachbarschaft einer Optimierungssequenz ergibt sich durch dieBetrachtung der Nachbarschaften ihrer einzelnen Segmente. Die Nach-barschaft eines Segments wiederum ergibt sich durch Betrachtung derNachbarschaften der drei Parameter des Segments. Die Nachbarschafteines Amplitudenwerts, einer Segmentbreite und eines Transitionstypswird im Folgenden durch Vorstellung der jeweiligen Bewegungsopera-toren definiert. Der Auszug einer Optimierungssequenz, dargestellt inAbbildung 22a, dient hierbei der Veranschaulichung. Zu sehen sind dreiaufeinanderfolgende Segmente einer Optimierungssequenz, wobei dasmittlere, grau eingefärbte Segment Gegenstand der Nachbarschaftsunter-suchung sein soll.

amplitude

Der Amplitudenwert eines Segments beschreibt den Wert, welches dasSignal, in seinem zeitlichen Verlauf betrachtet, am Ende des Segmentseinnimmt. Der Amplitudenwert ist eine reelle Zahl. Als Bewegungsope-ratoren kommen daher Inkrement- und Dekrementoperatoren in Frage,um die direkte Nachbarschaft eines Amplitudenwerts abzustecken. DieSchrittweite der Inkrementierung und Dekrementierung kann hierbeider Modelleingangsspezifikation entnommen werden. In dieser ist fürjeden Modelleingang angegeben, in welchen unteren und oberen Am-plitudengrenzen sich ein generiertes Signal zu bewegen hat – und indiesem Zusammenhang auch, welche Quantisierung die Signalwerteaufzuweisen haben (siehe Definition 18). Die Quantisierung entsprichtder gesuchten Schrittweite.

Das Beispiel-Segment in Abbildung 22a besitzt den Amplitudenwert 3, 9.Als Schrittweite wird der Wert 0, 1 angenommen. Abbildung 22b ver-anschaulicht die Anwendung des Inkrement- und Dekrementoperators.Es resultieren zwei benachbarte Segmente, in denen der Amplituden-Parameter des Segments die Werte 3, 8 und 4, 0 besitzt. Falls der Aus-gangsamplitudenwert (in diesem Fall 3, 9) bereits die obere oder unterespezifizierte Grenze der Amplitudenwerte darstellt, kann dementspre-chend nur einer der beiden Bewegungsoperatoren angewendet werden.Die Nachbarschaft bezüglich des Amplitudenparameters besteht dannaus nur einem benachbarten Segment.

Im Falle der meisten Transitionstypen bewirkt eine Amplituden-Inkre-mentierung oder -dekremtierung eine Änderung der Steigung des Über-gangs zwischen Segmentbeginn und -ende. In der Regel wirken sichdie Bewegungsoperationen dabei auch auf das darauffolgende Segmentaus – zumindest auf das durch die gesamte Optimierungssequenz be-schriebene und als Simulationssequenz bezeichnete Signal bezogen. DerAmplitudenwert eines Segments beschreibt nämlich nicht nur den Si-gnalwert am Segmentende, sondern gleichzeitig auch den Signalwert


(a) Teil einer Optimierungssequenz mit Fokus auf das mittlere Segment

(b) Nachbarschaft des Amplitudenparameters

(c) Nachbarschaft des Breitenparameters

Abbildung 22: Betrachtung der Nachbarschaft eines Segments (Parame-ter Amplitude und Breite) einer Optimierungssequenzanhand eines Beispiels


zu Beginn des darauffolgenden Segments. Daher wirkt sich eine Modi-fikation des Amplitudenwerts eines Segments zwangsläufig auch aufdas Folgesegment aus. Ausgenommen hiervon sind Segmente mit demTransitionstyp Impuls, da bei diesen der Anfangsamplitudenwert desfolgenden Segments dem Anfangsamplitudenwert des Impulssegmentsentspricht. Der Amplitudenwert eines Impulssegments beschreibt hierbeinicht den Amplitudenwert am Segmentende, sondern den temporärenImpulsausschlag.

segmentbreite

Bei einer Segmentbreite handelt es sich ebenfalls um einen reellen Wert.Daher bilden auch hier Inkrement- und Dekrementoperatoren die Be-wegungsoperatoren. Eine Vergrößerung oder Verkleinerung einer Seg-mentbreite bewirkt eine Dehnung oder Stauchung des entsprechendenSignalabschnitts auf der Zeitachse. Ein Beispiel hierzu findet sich in Ab-bildung 22c. Als spezifizierte Abtastrate (siehe Definition 19) für die zuerzeugenden Signale wird im Falle des Beispiels ein Wert von 0, 1 Sekun-den angenommen. Unter Berücksichtigung dieser Angabe ergeben sichim Rahmen der Nachbarschaftsbetrachtung zwei benachbarte Segmente:eines, welches innerhalb der aus der Optimierungssequenz generiertenSimulationssequenz einen Zeitbereich einnimmt, der um 0, 1 Sekundenkürzer ist – und eines, welches um 0, 1 Sekunden länger ist.

Als Schrittweite, welche durch die Bewegungsoperatoren zu der Segment-breite addiert oder subtrahiert wird, lässt sich allerdings nicht direkt dieAbtastrate verwenden. Die Schrittweite muss zuerst bestimmt werden.Hierzu werden folgende Hintergrundkenntnisse benötigt: Bei einer Seg-mentbreite handelt es sich, wie in Abschnitt 2.4.2 erläutert, nicht etwa umeine Zeitangabe, sondern um eine relative Breitenangabe. Bei Überfüh-rung einer Optimierungssequenz in eine Simulationssequenz werden dieaufsummierten Breiten aller Segmente einer Optimierungssequenz näm-lich der spezifizierten Signallänge (siehe Definition 19) gleichgesetzt unddie zeitlichen Längen eines jeden Segments hierzu in Relation berechnet.Die zeitliche Länge wird hierbei durch die Anzahl an Datenpunktenangegeben. Wird die relative Breite eines Segments g mit sgwidth(g)bezeichnet und handelt es sich bei specsteps um die Gesamtanzahl anSignal-Datenpunkten (siehe Definition 20), so bestimmt sich die An-zahl der Datenpunkte, welches das Segment in der Simulationssequenzeinnimmt, folgendermaßen:

sgsteps(g) =sgwidth(g)

sgwidth ,Σ· specsteps (71)


Hierbei bezeichnet sgwidth ,Σ die Summe der Breiten aller Segmente derOptimierungssequenz.

sgwidth ,Σ =

sgΣ∑i=1

sgwidth(sg(i)) (72)

Bei sgΣ handelt es sich um die Anzahl der Segmente der Optimierungs-sequenz und sg(i) bezeichnet das i-te Segment.

Bezogen auf das Beispiel-Segment aus Abbildung 22a, welches die re-lative Breitenangabe 0, 5 besitzt, bedeutet dies: Geht man neben derangenommenen Abtastrate von 0, 1 Sekunden von einer spezifiziertenSignallänge von 30 Sekunden aus, so ergibt sich in einem ersten Schritteine Datenpunktanzahl für die Simulationssequenz von 300 (specsteps).Wird nun zudem eine aufsummierte Gesamtbreite aller Segmente von 10

angenommen (sgwidth ,Σ), so ergeben sich für das betrachtete Segment 15Datenpunkte (sgsteps(g)).

Der Genauigkeit halber sei angemerkt, dass der für ein jedes Segmentberechnete Wert sgsteps(g) möglicherweise nicht ganzzahlig ist und daheranschließend noch aufgerundet wird. Hierdurch kann für das gesamteSignal allerdings ein Überhang an Datenpunkten entstehen. Dieser Über-hang wird im Nachhinein unter Berücksichtigung einer Mindestlänge fürSegmente bei entsprechend gewählten Segmenten wieder abgeschnitten.Ein Segment, bei welchem im Zuge einer Nachbarschaftsuntersuchungeine Segmentbreitenänderung erfolgt, bleibt hiervon allerdings unbe-rührt.

Um nun unter Zuhilfenahme der effektiven Breite eines Segments (Defini-tion 71) einen kleinstmöglichen Schritt zur Änderung der Segmentbreitein der Simulationssequenz zu bewirken, ist es notwendig, die Auswir-kungen der Modifikation einer Segmentbreite auf die Skalierung derBreiten aller Segmente zu berücksichtigen. Gesucht sind die Schrittwei-ten msincr(g) und msdecr(g), welche zur relativen Segmentbreite addiertoder subtrahiert werden, um die einem Signalsegment zugeordnete An-zahl der Datenpunkte um genau einen Datenpunkt zu erhöhen oder zuverringern. Diese lassen sich folgendermaßen berechnen:

sgsteps(g) + 1 =sgwidth(g) +msincr(g)sgwidth ,Σ+msincr(g)

· specsteps⇓ (73)

msincr(g) =sgwidth ,Σ

specsteps − sgsteps(g) − 1


und

sgsteps(g) − 1 =sgwidth(g) −msdecr(g)sgwidth ,Σ−msdecr(g)

· specsteps⇓ (74)

msdecr(g) =sgwidth ,Σ

specsteps− sgsteps(g) + 1

Bei den oberen Gleichungen in Definition 73 und Definition 74 handeltes sich um Umformulierungen der effektiven Segmentbreite aus Definiti-on 71 für ein Segment, welches in der Simulationssequenz einen Daten-punkt mehr, beziehungsweise einen Datenpunkt weniger, einnimmt. DieGleichungen wurden in beiden Fällen schlichtweg umgestellt und verein-facht, so dass einzig msincr(g), beziehungsweise msdecr(g), auf der linkenSeite stehen. Somit sind die Schrittweiten zur Inkrementierung undDekrementierung einer Segmentbreite im Sinne einer Nachbarschaftsbil-dung gefunden.

Im Falle des Beispiels ergeben sich für das dort betrachtete Segment, unterBerücksichtigung der zuvor gemachten Annahmen, die Schrittweitenmsincr(g)= 5

142 für den Inkrementoperator und msdecr(g)= 5143 für den

Dekrementoperator.

transitionstyp

Der Transitionstyp eines Segments ist im Vergleich zu Amplitudenwertund Segmentbreite keine reelle Zahl, sondern ein Element aus einerMenge möglicher Transitionstypen. Diese Menge ist gegebenenfalls übereine entsprechende Auswahl in der Modelleingangsspezifikation einge-schränkt. Dies bedeutet, dass für Optimierungssequenzen, die einembestimmten Modelleingang gelten, unter Umständen nicht alle der ver-fügbaren Transitionstypen (siehe Abschnitt 2.4.2) zugelassen sind.

Für die Elemente dieser Menge kann ohne Weiteres keine Ordnung ange-nommen werden. Das heißt, es kann nicht davon ausgegangen werden,dass auf einen linearen Transitionstypen beispielsweise ein sinusförmigerTransitionstyp folgt oder Ähnliches. Die Zweckmäßigkeit einer solchenOrdnung im Rahmen einer der Testdatengenerierung dienenden LS istzudem fraglich. Zwar existieren zweifelsfrei Ähnlichkeiten zwischen derlinearen und sinusförmigen Transition sowie der Spline-Transition, dasie alle zu einem kontinuierlichen, positiven oder negativen Anstieg in-nerhalb eines Signalsegments führen, jedoch ist es für eine automatischeSuche nicht zwingend von Vorteil, zum Beispiel die Sinus-Transition alseine gesteigerte Form einer linearen Transition aufzufassen. Dies würdezu einer Priorisierung bei der Transitionstyp-Wahl führen und somitden Freiheitsgrad der Suche unnötig einschränken. Die Transitionstypen


werden daher alle als miteinander benachbart betrachtet. Ein einzelnerTransitionstyp besitzt also keine ausgewählten Nachbarn in der Menge al-ler für eine Optimierungssequenz erlaubten Transitionstypen. Die Anzahlder Nachbarn richtet sich einzig und allein nach den Einschränkungender verfügbaren Transitionstypen in der Modelleingangsspezifikation.

Der Bewegungsoperator für den Transitionstyp generiert dementspre-chend keinen, einen oder mehrere modifizierte Signalsegmente. Diesist in Abbildung 23 für die zuvor bereits als Beispiel verwendete Opti-mierungssequenz dargestellt. In diesem Fall sind alle Transitionstypenerlaubt. Im Sinne der Nachbarschaftsbildung wird der ursprüngliche li-neare Transitionstyp, welcher in den einzelnen Darstellungen gestricheltdargestellt ist, jeweils durch einen der vier anderen Transitionstypen(Sinus, Spline, Impuls und Sprung) ausgetauscht. Im Gegensatz zu denanderen Transitionstypen entspricht der Endamplitudenwert eines Seg-ments mit Impuls-Transitionstyp dessen Anfangsamplitudenwert, wiezuvor bereits herausgestellt wurde. Der Anfangsamplitudenwert einesImpulssegments wird dabei auch vom darauffolgenden Segment alsAnfangsamplitudenwert verwendet. Daher sorgt eine Veränderung desTransitionstyps hin zu dem Impuls-Typ auch für eine Veränderung inner-halb der Simulationssequenz im darauffolgenden Signalsegment. DieserUmstand kann in Abbildung 23c nachvollzogen werden.

4.1.2.2 Die Nachbarschaftsgröße als Komplexitätsfaktor

Aus den Überlegungen zu der Nachbarschaft eines Signalsegments las-sen sich Folgerungen bezüglich der Komplexität einer Nachbarschafts-untersuchung im Rahmen einer LS, die der Suche nach Signalen dient,ableiten.

Abbildung 24 stellt in diesem Zusammenhang die Nachbarschaft ei-nes Segmentes einer Optimierungssequenz dar. Die benachbarten Seg-mente ergeben sich hierbei durch Anwendung der Segmentparameter-spezifischen Bewegungsoperatoren für jeweils einen einzelnen Segment-parameter. Für den Amplitudenparameter ergeben sich ein oder zweiNachbarn, je nachdem ob die Anwendung eines der Bewegungsoperato-ren zu einem Amplitudenwert außerhalb des spezifizierten Wertebereichsführen würde oder nicht. Bezüglich der Segmentbreite ergeben sich zweiweitere Nachbarn. Für den Parameter Transitionstyp leiten sich bis zuvier benachbarte Segmente ab. Die genaue Anzahl hängt dabei davon ab,inwieweit die Menge der erlaubten Transitionstypen in der Modellein-gangsspezifikation eingeschränkt ist. Insgesamt besitzt ein Signalsegmentbis zu acht benachbarte Segmente – mindestens jedoch drei. Sofern in derModelleingangsspezifikation kein fixer Startamplitudenwert für einenModelleingang angegeben ist (siehe Definition 18), so wird dieser durch


(a) Nachbar mit dem Transitionstyp Sinus

(b) Nachbar mit dem Transitionstyp Spline

(c) Nachbar mit dem Transitionstyp Impuls

(d) Nachbar mit dem Transitionstyp Sprung

Abbildung 23: Betrachtung der Nachbarschaft eines Segments (ParameterTransitionstyp) einer Optimierungssequenz anhand einesBeispiels


den Amplitudenparameter des ersten Segments einer Optimierungsse-quenz bestimmt. Das erste Segment besitzt in diesem Fall keinen Breiten-und Transitionstyp-Parameter. Daher leiten sich für das erste Segment indiesem Fall nur ein oder zwei benachbarte Segmente ab.

Geht man von einer festen Anzahl an Signalsegmenten aus, bezeichnetmit sgΣ, so bewegt sich die Anzahl nb an Nachbarn einer gesamtenOptimierungssequenz, welche durch minimale Veränderungen einesjeden Parameters eines jeden Segments erreicht werden können, zwischenfolgenden Werten:

3 · sgΣ −2 � nb � 8 · sgΣ (75)

Entsprechend der Anzahl der betrachteten Modelleingänge steigt dieAnzahl an Nachbarn bei einer LS nach Eingangssignalen für ein SL/TL-Modell auf ein Vielfaches dieses Werts.

Hierzu sei ein kleines Beispiel betrachtet: Besitzt ein Modell fünf Ein-gänge und wird festgelegt, dass die Optimierungssequenzen für jedenModelleingang aus jeweils zehn Segmenten bestehen, so leitet sich für eingeneriertes Testdatum eine stattliche Anzahl von bis zu 400 benachbartenTestdaten ab. Zieht man als lokales Suchverfahren den in Abschnitt 2.4.1einführend vorgestellten Bergsteigeralgorithmus heran, so bedeutet dies,dass in jeder Iteration der Suche bis zu 400 Testdaten generiert werdenund diese zu evaluieren sind. Diese Herangehensweise würde zu ei-ner höchst ineffizienten Suche führen. Würde man zusätzlich bei derNachbarschaftsbetrachtung auch die gleichzeitige Modifikation mehrererParameter zulassen, steigt die Anzahl an generierten Testdaten sogarexponentiell.

∈∀

Abbildung 24: Betrachtung der Nachbarschaftsgröße eines Segments ei-ner Optimierungssequenz


Die Betrachtung der Komplexität einer Nachbarschaftsuntersuchungsoll an dieser Stelle verdeutlichen, dass die Durchführung einer LS imbetrachteten Kontext, also bei der Generierung von Signalen mittels Op-timierungssequenzen, nicht unproblematisch ist. Hier bedarf eine LSeiner anderen Herangehensweise, als sie lokale Suchverfahren wie derBergsteigeralgorithmus in seiner klassischen Form bieten. Das entwickel-te Suchverfahren ASPO setzt daher auf ein Vorgehen, welches, wie imfolgenden Abschnitt ersichtlich, der AVM ähnelt.

4.1.3 alternierendesignalparameteroptimierung

Das lokale Suchverfahren AVM zeichnet sich im Kern dadurch aus,dass es für jeden veränderlichen Parameter abwechselnd eine eigene LSdurchführt (siehe auch Abschnitt 2.4.1). Der gesamte Vorgang startetmit einem initialen, zufällig gewählten Lösungsvorschlag. Sobald die LSbei ihren fortwährenden Nachbarschaftsuntersuchungen bezüglich einesbetrachteten Parameters zu keinem, bezüglich seiner Fitness besserenLösungsvorschlag mehr führt, wird zum nächsten Parameter übergegan-gen. Auch für diesen erfolgt eine entsprechende LS. AVM beendet seineSuche, wenn das Ziel der Suche erreicht wurde oder für alle Parameterin Folge eine jeweilige Nachbarschaftsuntersuchung zu keinem besserenLösungsvorschlag führt. Die Vorgehensweise von AVM bewirkt, dass sichdie Größe der während einer LS aufzubauenden Nachbarschaft stets aufdie Größe der Nachbarschaft eines einzelnen Parameters beschränkt.

Dieses Vorgehen macht sich ASPO zunutze. Die Segmentparameter derfür alle relevanten Modelleingänge betrachteten Optimierungssequenzenwerden nacheinander behandelt. Je nach Art des Parameters reduziertsich die Zahl der bei einer Nachbarschaftsuntersuchung generiertenTestdaten auf maximal zwei im Falle eines Amplitudenparameters, zweiim Falle eines Segmentbreitenparameters und maximal vier im Falle einesTransitionstyp-Parameters. Die Funktionsweise von ASPO im in dieserArbeit betrachteten Anwendungskontext ist in Abbildung 25 dargestellt.Sie wird im Folgenden erläutert.

Um Testdaten für ein SL/TL-Modell zu generieren, übernimmt ASPO,wie in der Abbildung zu sehen, schlichtweg die Rolle des LGA. Dieeinzelnen SGs werden ebenfalls sequentiell mittels Suchvorgängen abge-arbeitet. ASPO beginnt mit einem initialen Testdatum, welches wie diePopulation initialer Testdaten im Falle des LGA ebenfalls zufällig erzeugtwird. Die Repräsentation eines Testdatums ist ebenfalls identisch, dasheißt dieses enthält je relevantem Modelleingang eine Optimierungsse-quenz. Im Unterschied zur Verwendung des LGA ist die initial, unter


∈

Abbildung 25: Ablauf der strukturorientierten Testdatengenerierung fürSL/TL-Modelle mithilfe der alternierenden Signalparame-teroptimierung


Berücksichtigung der Modelleingangsspezifikation je Optimierungsse-quenz zufällig gewählte Anzahl an Segmenten allerdings fix. Das heißt,während der Suche werden keine Segmente entfernt oder hinzugefügt.Um einen höheren Freiheitsgrad bei einer Suche zu erreichen, ist esvorstellbar, ASPO an dieser Stelle zukünftig noch zu erweitern.

Zurück zum Ablauf von ASPO: Gemäß einer Abarbeitungsreihenfolgeder Optimierungssequenz-Parameter, welche nachfolgend noch detailliertbehandelt wird, betrachtet ASPO zuerst den Parameter a (Amplitude)des 0-ten (also ersten) Segments der Optimierungssequenz für den erstenrelevanten Modelleingang als zu untersuchenden Parameter p. Ein Para-meter sei hierbei durch einen Tupel aus Nummer des Modelleingangs,Nummer des Signalsegments und Parametertyp bezeichnet. Der zuerstbetrachtete Parameter ist demnach p=(1, 0,a).

Die Menge der Nachbarn des aktuell betrachteten Testdatums, bezeich-net durch NB(k), ist initial leer. Wie für metaheuristische Suchverfahrenüblich, erfolgt eine Bewertung der generierten Testdaten mittels einerFitnessfunktion. Diese unterscheidet sich hierbei nicht von der, welcheauch bei Verwendung des LGA zum Einsatz kommt. Zu Beginn bewertetASPO nur das initiale Testdatum k, in folgenden Suchiterationen stattdes-sen die benachbarten Testdaten aus NB(k). Wurde hierbei ein Testdatummit besserer Fitness entdeckt, so übernimmt dieses die Rolle des aktuellbetrachteten Testdatums. Bildlich betrachtet verschiebt die LS in diesemFall ihre aktuelle Position im Suchraum. Kam es nicht zu einer Verbesse-rung, so rückt ASPO unter Berücksichtigung der Parameterabfolge zumnächsten Optimierungssequenz-Parameter vor.

Erfüllt das aktuell beste Testdatum k das SG oder wurden alle Parameteraller Optimierungssequenzen in Folge als Parameter p betrachtet, ohnedass in der jeweiligen Nachbarschaft ein Testdatum mit verbesserterFitness registriert werden konnte, so endet die LS für das betrachteteSG. In ersterem Fall wird das Testdatum, welches das SG erfüllt, indie resultierende Testsuite aufgenommen. Um den Suchalgorithmus inseiner Laufzeit zu beschränken, existiert zudem eine maximale Anzahlvon Fitnessfunktionsberechnungen, beziehungsweise generierter undbewerteter Testdaten. Die LS für ein SG terminiert daher auch, sobalddiese Grenze erreicht ist.

Wird die LS fortgeführt, so wird die Nachbarschaft des aktuellen Testda-tums k bezüglich des aktuell zur Modifikation herangezogenen Parame-ters p gebildet. Hierzu existieren zwei unterschiedliche Vorgehensweisen,von denen jeweils stets genau eine zur Anwendung kommt. Ist aufgrundeiner Nicht-Verbesserung der bislang besten Fitness ein Parameterwech-sel erfolgt, so wird die Nachbarschaft zunächst über sogenannte Erkun-dungsschritte gebildet. Kam es bezüglich des aktuellen Parameters p zueiner Verbesserung der Fitness und somit zu einer Änderung des aktuel-len Testdatums k, so werden sogenannte Richtungsschritte unternommen,


um die Nachbarschaft zu formen. Eine ausführliche Unterscheidung die-ser Schrittarten erfolgt im nächsten Teilabschnitt. Unabhängig davon,welche dieser Varianten in einer Suchiteration Anwendung findet, wer-den durch die Parametermodifikationen neue Testdaten gebildet. Dieseformen die Menge NB(k). Da an dieser Stelle, wie in der Abbildung zusehen ist, eine neue Suchiteration beschritten wird, verfährt ASPO imWeiteren wie in den vorigen Absätzen beschrieben.

4.1.3.1 Erkundungs- und Richtungssuche

Die in Abschnitt 4.1.2 vorgestellte Nachbarschaftsbetrachtung basiert aufeiner Anwendung von Bewegungsoperatoren, welche per Definition mini-male Veränderungen eines Optimierungssequenz-Parameters vornehmen.Derlei Veränderungsschritte werden als Erkundungsschritte bezeichnet.Richtungsschritte hingegen verändern Parameter in nur eine Richtung,beispielsweise durch ausschließliche Anwendung des Inkrementopera-tors. Zudem verwendet ASPO bei Richtungsschritten gegebenenfalls eineSchrittweite, die über das Maß einer minimalen Veränderung hinaus-geht.

erkundungssuche

Die Anwendung von Erkundungsschritten zur Nachbarschaftsbildungwird auch als Erkundungssuche bezeichnet. Ein einzelner Erkundungs-schritt wird durch genau einen Bewegungsoperator ausgeführt. Geht esbeispielsweise um einen Amplitudenwert, so kann dies ein Inkrement-oder Dekrementoperator sein. Alle für einen Parameter verfügbarenErkundungsschritte zusammen definieren dessen gesamte, direkte Nach-barschaft. Es handelt sich um direkte Nachbarn, da beispielsweise beieiner Inkrementierung eines Amplitudenwerts eine minimale Schrittweiteverwendet wird (siehe Abschnitt 4.1.2.1).

Aufgabe einer Erkundungssuche ist es, die Richtung von Parametermo-difikationen zu ermitteln, welche zu einer Annäherung an die Erfüllungdes betrachteten SG führt. Erhält man durch Dekrementierung einesAmplitudenparameters beispielsweise ein Testdatum mit besserer Fit-ness, so gilt die Richtung einer Verringerung des Amplitudenwerts alserfolgversprechend. Eine solche Erkundungssuche, die in einem Test-datum mit besserer Fitness resultiert, ist Grundlage einer anschließenddurchgeführten Richtungssuche. Eine Durchführung mehrerer, direktaufeinanderfolgender Erkundungssuchen für denselben Parameter er-folgt nicht. Wird ein Parameter allerdings nach Betrachtung aller anderenParameter zum wiederholten Male betrachtet, so erfolgt auch dann zuersteine Erkundungssuche für diesen Parameter.


richtungssuche

Führt ein Erkundungsschritt in der anschließenden Bewertung zu ei-nem Testdatum mit verbessertem Fitnesswert, so wird daraufhin einRichtungsschritt in die Richtung unternommen, die für die Verbesserungverantwortlich war. Sofern ein Richtungsschritt wiederum zu einem besse-ren Testdatum führt, so wird ein erneuter Richtungsschritt unternommen.Dieses Vorgehen endet, sobald keine Verbesserung des Fitnesswerts auf-tritt. Diese Herangehensweise gilt allerdings nur für die Amplituden- undSegmentbreitenparameter. Für einen Transitionstyp-Parameter lassen sichnach einer Verbesserung durch einen Erkundungsschritt keine weiterenNachbarn finden. Bei der Erkundungssuche wurden nämlich bereits alleVariationen des Transitionstyp-Parameters untersucht. Daher geht ASPOnach einer Erkundungssuche für einen Transitionstyp-Parameter zu demin der Abfolge nächsten Parameter über – unabhängig davon, ob dieErkundungssuche zu einem besseren Testdatum führt oder nicht. DieseFeinheit ist aus Darstellungsgründen nicht in Abbildung 25 enthalten.

Grundsätzlich wird für Richtungsschritte ebenfalls eine minimale Schritt-weite genutzt. Im Falle des Amplitudenparameters wendet ASPO jedochsogenannte Richtungssprünge an. Dieser Idee liegt folgende Problematikzugrunde: Bei wiederholter Anwendung minimaler Richtungsschrittekann es passieren, dass eine Annäherung an das SG trotz stetiger Verbes-serungen des Fitnesswertes nur sehr langsam geschieht. Korel schlägt indiesem Zusammenhang vor, die Schrittweite mit zunehmender Anzahlerfolgreicher Richtungsschritte zu erhöhen [76]. Dieses Vorgehen hatallerdings den Nachteil, dass die Richtungsschritte immer größer werden,je näher die Suche ihrem Ziel kommt. Dies birgt die Gefahr, einen zurErfüllung des Ziels gesuchten Parameterwert zu überspringen.

Die Richtungssprünge von ASPO nutzen daher stattdessen Schrittweiten,welche auf Basis der bei der vorherigen Erkundungssuche erzieltenFitnessverbesserung und der dabei verwendeten minimalen Schrittweiteprognostiziert werden. Die Schrittweite sjump eines Richtungssprungsberechnet sich hierbei folgendermaßen:

sjump =sstep

fimprove· fbest (76)

Hierbei bezeichnet sstep die bei dem zuvor mit Erfolg durchgeführtenErkundungsschritt verwendete Schrittweite. Die bei diesem Erkundungs-schritt erzielte Verbesserung des Fitnesswerts, also die Differenz zwi-schen vorherigem und dem neuen, aktuell besten Fitnesswert fbest, sei mitfimprove benannt. Die Berechnung geht davon aus, dass die Fitnesswertepositiv sind und es stets das Ziel ist, den Fitnesswert 0 zu erreichen.

Die tatsächlich verwendete Schrittweite ist allerdings zusätzlich durch diespezifizierten Amplitudengrenzen beschränkt. Hierdurch wird verhin-


dert, dass Richtungssprünge zu Amplitudenwerten führen, die außerhalbdes in der Modelleingangsspezifikation angegebenen Wertebereichs lie-gen. Darüber hinaus ist zu berücksichtigen, dass die Schrittweite einesRichtungssprungs lediglich eine Abschätzung darstellt. Um die Gefahreines Überspringens des gesuchten Testdatums im Suchraum einzudäm-men, führt ASPO nach jedem Richtungssprung eine Erkundungssuchedurch. Je nach Ausgang dieser kann anschließend eine Richtungssuchein sowohl dieselbe Richtung wie zuvor als auch in die entgegengesetzteRichtung erfolgen. Somit ermöglicht ASPO im Falle zu großer Richtungs-sprünge ein Zurückgehen. Dieses Vorgehen sowie die Anwendung vonRichtungssprüngen im Falle von Amplitudenparametern insgesamt istin der Übersicht in Abbildung 25 nicht dargestellt.

4.1.3.2 Parameterpriorisierung

ASPO arbeitet die Segmentparameter der Optimierungssequenzen einesjeden relevanten Modelleingangs in einer bestimmten Abfolge ab. DieÜberlegungen, welche Grundlage der Reihenfolgenbildung sind, wer-den in diesem Teilabschnitt vorgestellt und erklärt. Die durch ASPOerstellte Parameterabfolge ist in Abbildung 26 dargestellt. Dort ist zuerkennen, dass die Parameter in erster Linie nach der Art des Parame-ters geordnet sind. Zuerst werden alle Amplitudenparameter betrachtet,anschließend die Segmentbreiten eines jeden Segments und erst danndie Transitionstypen der Segmente. Die Parameter eines jeden Typs wer-den nachfolgend nach Zugehörigkeit zu einem Modelleingang und derPosition des dazugehörigen Signalsegments innerhalb seiner Optimie-rungssequenz geordnet. Bei Verwendung der statischen Voranalyse SDAwerden hierbei selbstverständlich nur die Modelleingänge berücksichtigt,welche für das bei der LS betrachtete SG relevant sind. Gelangt ASPObei seiner LS am letzten Parameter der Abfolge an und erfolgt auch nachdessen Bearbeitung keine Beendigung der Suche, so wird als nächsteserneut der erste Parameter der Abfolge betrachtet.

Das markanteste Merkmal der Parameterabfolge ist die Priorisierungnach Parameterart. Dieser Priorisierung liegt die Annahme zugrunde,dass der Einfluss einer Modifikation eines Parameters auf die Annähe-rung an die Erfüllung eines SG in vielen Fällen je nach Art des Parametersunterschiedlich stark ausfällt. Werden Parameter, deren Veränderung mithöherer Wahrscheinlichkeit zu einem Testdatum mit verbesserter Fitnessführen, durch ASPO bevorzugt behandelt, so kann der Aufwand und dieLaufzeit einer Suche geringer ausfallen.

Mit Blick auf die Gestaltung der CG-Ausdrücke, wie sie Gegenstandbeispielsweise einer strukturorientierten Testdatengenerierung sind (sie-he Abschnitt 2.2.1), so fällt auf, dass es in der Regel um das Erreichenbestimmter Amplitudenwerte oder das Unter-/Überschreiten bestimmter


Abbildung 26: Abarbeitungsreihenfolge der einzelnen Signalparameterbei der alternierenden Signalparameteroptimierung


Amplitudengrenzen für Signale eines SL/TL-Modells geht. Ein jederAmplitudenwert eines Signals innerhalb eines Modells ergibt sich im All-gemeinen aus Amplitudenwerten an den Eingängen des Modells. Daherist die Vermutung naheliegend, dass insbesondere die Modifikation derAmplitudenparameter der Optimierungssequenzen zu einem erfolgrei-chen Fortschreiten einer LS beitragen können. Diese werden daher in derParameterabfolge am höchsten priorisiert.

Wie in Abschnitt 4.1.2.1 herausgestellt, bewirken Modifikationen derSegmentbreitenparameter und Transitionstyp-Parameter indirekt Ände-rungen der Amplitudenwerte in einer aus einer Optimierungssequenzerzeugten Simulationssequenz. Insbesondere bei der Anvisierung vonModellzuständen, welche nur bei Stimulation des Modells mit bestimm-ten Werten zu unterschiedlichen Zeitschritten erreicht werden können,kann eine Modifikation von Breite oder Transitionstyp bestimmter Seg-mente notwendig sein. Die Modifikation einer Segmentbreite beeinflussthierbei vor allem den Grad einer Steigung innerhalb eines Abschnittsder entstehenden Simulationssequenz. Der Transitionstyp ist hingegenmeist für die Art der Steigung, beispielsweise durch einen linearen oderkurvenförmigen Verlauf, verantwortlich. ASPO weist Veränderungen vonSteigungsgraden über Modifikationen von Segmentbreiten eine höherePriorität als der Modifikation von Transitionstypen zu. Kleinere Versuchewährend der Entwicklung von ASPO haben bestätigt, dass eine solchePriorisierung entsprechend der drei Parameterarten zu einer effizienterenDurchführung einer LS führt [63].

Mit diesen Ausführungen ist die Vorstellung des lokalen SuchverfahrensASPO, welches auf eine Testdatengenerierung für SL/TL-Modelle aus-gerichtet ist, abgeschlossen. Ein Vergleich der LS von ASPO mit der GSdes LGA erfolgt im Rahmen der in Kapitel 6 vorgestellten Fallstudien.Die statischen Voranalysen werden der LS hierbei, wie zuvor in Abbil-dung 25 dargestellt, ebenfalls vorangestellt. Eine darüber hinausgehendeHybridisierung der LS mit der GS oder einem anderen Generierungsver-fahren ist nicht Teil dieser Arbeit. Sie wird aber bei der Bewertung vonASPO in Abschnitt 6.3 und im Ausblick dieser Arbeit in Abschnitt 7.2thematisiert.


Im betrachteten Anwendungsgebiet, der Testdatengenerierung für SL-oder SL/TL-Modelle, hat sich bislang nur eine recht überschaubare An-zahl von Arbeiten mit einer Anwendung eines suchbasierten Ansatzesauseinandergesetzt. Diese Arbeiten wurden bereits in Abschnitt 2.3.2aufgeführt und diskutiert. Unter diesen Arbeiten gibt es zwei, welchesich mit der Nutzung einer LS beschäftigt haben. Beide betrachten zum


Zwecke einer Testdatengenerierung für SL-Modelle das Suchverfahrender simulierten Abkühlung (englisch: Simulated Annealing). Dieses ur-sprünglich der Simulation von Abkühlungsprozessen verschiedener Ma-terialien dienende Verfahren [88] wurde einst von Kirkpatrick et al. [73]zu einem Optimierungsverfahren umfunktioniert. In diesem Zusammen-hang adressiert das Verfahren die Schwäche des Bergsteigeralgorithmus,lokale Optima bei einer Suche nicht überwinden zu können. Hierzulässt das Verfahren zum Teil Bewegungen im Suchraum zu Lösungsvor-schlägen mit einer schlechteren Fitness zu. Diese Bewegungen sind anWahrscheinlichkeiten gebunden. Da das Verfahren hierdurch eine globa-le Untersuchung des Suchraums anstrebt, wird es trotz seiner lokalenBetrachtung des Suchraums des Öfteren auch als GS klassifiziert.

Ghani et al. vergleichen die simulierte Abkühlung in Anwendung zurTestdatengenerierung für SL-Modelle mit einer GS, einem genetischenAlgorithmus [48]. Bezüglich Erfolg und Effizienz der Suchvorgänge un-terscheiden sich die beiden Ansätze meist nicht signifikant – und wenn,dann führt die GS zu besseren Ergebnissen. Allerdings ist die Aussa-gekraft dieser Untersuchung fraglich, da es sich bei den betrachtetenSL-Modellen lediglich um kleine „Spielzeugmodelle“ handelt. Zudemlegen die Autoren keinen Wert auf die Plausibilität der generierten Test-daten, das heißt eine Erzeugung von Signalen steht nicht im Vordergrundihrer Bemühungen. Das Problem der Komplexität einer Nachbarschafts-untersuchung, welches sich vor allem durch Berücksichtigung diesesAspekts über einen segmentbasierten Signalgenerierungsansatz ergibt,tritt demnach im Falle ihrer Arbeit ebenfalls nicht auf. Diese Unterschie-de und Einschränkungen gelten auch für die Arbeit von Zhan und Clark[137]. Die beiden Autoren, welche ebenfalls bei der Arbeit von Ghani etal. mitwirken, wenden auch das Verfahren der simulierten Abkühlungzur Testdatengenerierung für SL-Modelle an. Während ihr Vorgehensehr ähnlich zu dem in der Arbeit von Ghani et al. ist, geht es ihnenallerdings nicht um eine Testdatengenerierung für Strukturtests, sondernfür Mutationstests. Des Weiteren vergleichen sie ihre LS lediglich mitdem Zufallstest.

In diesem Kontext betrachtet lassen sich die Beiträge des ASPO-Verfahrensfolgendermaßen zusammenfassen:

1. Gestaltung einer LS unter Berücksichtigung der Plausibilität gene-rierter Testdaten

2. Aufstellung einer Nachbarschaftsdefinition bei Nutzung einer seg-mentbasierten Signalrepräsentation

3. Anwendungsfall-spezifische Erweiterung der AVM durch eineParameterpriorisierung und durch Richtungssprünge bei der Mo-difikation von Amplitudenparametern

4.2 generierung mittels smt-solving 161

4.2 generierung mittels smt-solving

Die Kombination der drei statischen Voranalysen mit einer automati-schen Testdatensuche stellt eine erste Hybridbildung zum Zwecke einereffizienten Testdatengenerierung für SL/TL-Modelle dar. Während dasim vorigen Abschnitt behandelte lokale Suchverfahren ASPO im Rah-men dieser Arbeit lediglich eine Alternative zum globalen SuchverfahrenLGA ist, erfolgt die in diesem Abschnitt betrachtete Anwendung desSMT-Solving zur Testdatengenerierung in hybridisierter Form mit einerSuche. So gesehen handelt es sich bei dem hier behandelten Beitrag umeine zweite Hybridbildung. Folgt man der Unterscheidung der Hybri-disierungsmöglichkeiten zu Beginn von Kapitel 3, so ordnet sich dieserBeitrag in die Kategorie der Ansätze ein, welche während oder anstelleeiner Testdatensuche unterstützend wirken.

4.2.1 ziel

Eine Testdatengenerierung mittels ausschließlich statischer Technikenwurde einführend in Abschnitt 2.3.1 behandelt. Hierbei kam vor allemdas Verfahren der symbolischen Ausführung zur Sprache. Der Begriffsymbolische Ausführung beschreibt hierbei, dass das Testobjekt zumZwecke einer Testdatengenerierung nicht tatsächlich ausgeführt wird,sondern eine statische Analyse der Testobjekt-Struktur und -Semantikstattfindet, welche in ihrem Vorgehen einer konkreten Ausführung äh-nelt. Handelt es sich beispielsweise um Programmcode, so wird wie beieiner konkreten Ausführung ebenfalls der Kontrollfluss, wie er sich ineinem KFG darstellen lässt, von den Programmeingängen ausgehendabgegangen. Im Unterschied zur konkreten Ausführung der enthaltenenBedingungen und Anweisungen werden allerdings Pfadbedingungengesammelt, deren Erfüllung ein Erreichen bestimmter Zustände, Bedin-gungen oder Anweisungen innerhalb des Testobjekts zur Folge hätte. Ausder Lösung solcher Pfadbedingungen, beispielsweise durch SMT-Solving,lassen sich Testdaten ableiten.

Eine solche symbolische Ausführung stößt allerdings an Grenzen, dennaus realen Testobjekten leiten sich mitunter Ausdrücke in Pfadbedin-gungen ab, deren Lösung durch Techniken wie dem SMT-Solving nichtbewerkstelligt werden kann. Ist eine Lösbarkeit allerdings gegeben, soliefern das SMT-Solving in der Regel sehr zügig Ergebnisse. Aus diesenErgebnissen lassen sich direkt die gesuchten Testdaten bilden. Eine Test-datengenerierung mittels SMT-Solving besitzt daher das Potential, sofernderen Anwendbarkeit gegeben ist, deutlich effizienter als eine Testdaten-suche zu sein. Die Zahl der Arbeiten im Bereich des SMT-Solving und die


dabei gemachten Fortschritte lassen vermuten, dass die Leistungsgren-zen einer symbolischen Ausführung mittels SMT-Solving heutzutagedeutlich höher liegen. Dies betrifft nicht nur die Fähigkeit modernerSMT-Solver, beispielsweise mathematische Ausdrücke verarbeiten zukönnen, sondern auch deren Skalierbarkeit. Da SL/TL-Modelle aus derindustriellen Praxis häufig sehr komplex und mächtig sind, ist dieserAspekt für eine Anwendung des SMT-Solving zur Testdatengenerierungbesonders relevant.

Dem in diesem Teil der Arbeit behandelten Ansatz liegen daher Überle-gungen und Versuche zugrunde, welche die Anwendbarkeit des SMT-Solving zur Testdatengenerierung für SL/TL-Modelle adressieren. DasResultat dieser Betrachtungen ist eine Definition von Einsatzkriterien.Aus diesen Kriterien ergibt sich eine hybride Testdatengenerierung – füreinzelne CG beziehungsweise SG wahlweise mittels SMT-Solving oderüber eine Testdatensuche. Das Ziel dieses Beitrags ist es, über eine solchhybride Lösung für die Gesamtheit der betrachteten CGs/SGs effizienterTestdaten erzeugen zu können als es der ausschließliche Einsatz einerTestdatensuche zu leisten imstande ist.

Der folgende Abschnitt behandelt das SMT-Solving im Allgemeinen. An-schließend werden die angesprochenen Einsatzkriterien und der Ansatzdieser Arbeit zur Testdatengenerierung mittels SMT-Solving vorgestellt.Dessen Hybridisierung mit einer Testdatensuche wird danach behandelt.Wie bei der Vorstellung der vorherigen Beiträge endet auch dieser Teilder Arbeit mit einer Betrachtung verwandter Arbeiten.

4.2.2 satisfiability modulo theories

Die Abkürzung SMT steht für Satisfiability Modulo Theories und bezeichneteine Klasse sogenannter Solver (zu Deutsch: Löser), welche der Lösungmathematischer, durch aussagenlogische und arithmetische Ausdrückebeschriebener Erfüllbarkeitsprobleme dienen. Im Allgemeinen bilden die-se Probleme eine Kategorie des Constraint-Satisfaction-Problems (CSP, zuDeutsch: Bedingungserfüllungsproblem) [34]. Die Aktivität des Lösenssolcher Probleme wird in dieser Arbeit als SMT-Solving bezeichnet.

Wie De Moura und Bjørner in einem einführenden Artikel [34] zum The-ma SMT erklären, kann SMT als eine Erweiterung von SAT angesehenwerden. SAT ist eine Abkürzung für den englischen Begriff Satisfiability(zu Deutsch: Erfüllbarkeit). Mit SAT werden Erfüllbarkeitsprobleme derAussagenlogik bezeichnet. Ein SAT-Solver adressiert also die Frage, obein aussagenlogischer Ausdruck wie beispielsweise (a∧b)∨¬a, in dema und b Boolesche Variablen darstellen, erfüllbar oder unerfüllbar ist.


Kann die Erfüllbarkeit festgestellt werden, liefert ein SAT-Solver üblicher-weise ein sogenanntes Modell, welches als Beleg der Erfüllbarkeit eineVariablenbelegung enthält. Dies gilt gleichermaßen für SMT-Solver.

Das durch SAT betrachtete Boolesche CSP ist für praktische Anwendun-gen jedoch oftmals nicht ausreichend. In der Praxis lassen sich Problememanchmal nicht oder nur schwer mit ausschließlich Booleschen Opera-toren und Variablen ausdrücken. Die Verwendung der Prädikatenlogikerster Stufe ist für viele Anwendungsfälle beispielsweise deutlich komfor-tabler. SMT ergänzt SAT daher dahingehend, dass zusätzlich sogenannteHintergrund-Theorien berücksichtigt werden können [92]. Um beispiels-weise Ausdrücke der Form a>b∧b=c+ 5 mit a,b, c∈Z lösen zu können,ist eine Theorie notwendig, welche eine entsprechende Arithmetik undsomit letzten Endes die Bedeutung der Symbole >, =, + und 5 defi-niert. Darüber hinaus existieren auch Theorien zum Umgang mit Arrays,Listen, Zeichenketten und mehr.

Zur Lösung von Ausdrücken spezieller Theorien übersetzen SMT-Solvereinen Ausdruck entweder in ein SAT-lösbares Problem oder verwendenTheorie-spezifische Lösungsstrategien und Entscheidungsprozeduren.Ansätze, welche auf die erstere Herangehensweise setzen, werden häufigauch als eager (zu Deutsch: begierig oder eifrig) bezeichnet – Ansätzeder zweiten Kategorie hingegen als lazy (zu Deutsch: faul oder träge).Diese Wortwahl verdeutlicht, dass eine unter Umständen schwierige undherausfordernde Überführung hin zu einem SAT-tauglichen Problembei der Konstruktion eines SMT-Solvers in der Regel die präferierteLösung darstellt. Allerdings ist dies nicht für alle ergänzenden Theorienüberhaupt möglich. Die hintergründige Funktionsweise von SMT- undSAT-Solvern soll an dieser Stelle allerdings nicht zu weit vertieft werden.Bei Interesse empfiehlt sich ein Blick in das Buch Handbook of Satisfiabilityvon Biere et al. [18] und insbesondere in das dort enthaltene Kapitel vonBarrett et al. bezüglich SMT [13].

Bedeutsamer für das in dieser Arbeit mittels SMT-Solving verfolgteZiel ist, welche Theorien und logischen Konstrukte einzelne SMT-Solverunterstützen und inwiefern sie zu einer effizienten Lösung einer größe-ren Menge entsprechender Ausdrücke imstande sind. Denn währendSAT-Probleme bereits NP-vollständig sind, gilt die Lösung von in derPrädikatenlogik erster Stufe definierten Problemen in der Theorie sogarals unentscheidbar [92].

Beispiele aktueller SMT-Solver sind Z3 [19, 33], MathSAT 5 [25] undCVC4 [15]. Viele SMT-Solver ermöglichen unter anderem die Nutzungvon Quantoren oder nicht-linearer Funktionen. Z3 kann sogar mit derMultiplikation zweier reellwertiger Variablen in Ausdrücken umgehen.Eine Lösung von Problemdefinitionen, welche derlei Sprachmittel ver-wenden, können die Solver allerdings nicht garantieren. Aufgrund seinerBreite an unterstützten Theorien und Konstrukten ist die Wahl eines


SMT-Solvers im Rahmen dieser Arbeit auf Z3 gefallen. Auch bezüglichLaufzeit und Effizienz überzeugt der Z3-Solver im Vergleich mit ande-ren SMT-Solvern [16, 26]. Der Z3-Solver findet übrigens auch in demin Abschnitt 2.3.3 erwähnten Testwerkzeug Pex [100] zum Zwecke einerTestdatengenerierung für .NET-Programme Anwendung.

Zum Verständnis der folgenden Abschnitte ist ein weiterer Aspekt vonRelevanz. Im Bemühen um eine höhere Akzeptanz und einfachere An-wendbarkeit der SMT-Solver sowie eine einfachere Vergleichbarkeit undAustauschbarkeit derselben haben Forscher und Entwickler, welche imBereich des SMT-Solving aktiv sind, ein einheitliches Austauschformatnamens SMT-LIB geschaffen [14, 27]. Der Großteil der derzeit verfügba-ren SMT-Solver kann in diesem Format aufgestellte Problemdefinitionenverarbeiten. Auch wenn in der Umsetzung der in dieser Arbeit vorge-stellten Testdatengenerierung mittels SMT-Solving eine direkte Kommu-nikation über eine Schnittstelle des Z3-Solvers erfolgt, wird für einzelneDarstellungen im Folgenden die SMT-LIB-Sprache genutzt. Die hierfürwichtigsten Grundzüge dieser Sprache lassen sich kurz erklären: JeglicheOperationen, das heißt sowohl aussagenlogische, relationale als auchandere mathematische Operationen, werden eingeklammert in Präfix-Schreibweise ausgedrückt. Als Beispiele seien die Ausdrücke (= x y)(Gleichheit), (=> a b) (Implikation), (and a b) (Konjunktion), (or a b)(Disjunktion), (not a) (Negation) und (∗ x y) (Multiplikation) genannt– wobei x,y als Zahlenwerte und a,b als Boolesche Variablen deklariertsind.

4.2.3 einsatzkriterien

Eine Testdatengenerierung mittels SMT-Solving stellt im Grunde einesymbolische Ausführung dar. Vergleicht man eine symbolische Aus-führung von SL/TL-Modellen allerdings mit derer von Programmcode,so ist Folgendes festzustellen: SL/TL-Modelle enthalten im Vergleichzu herkömmlichem Programmcode einen deutlich geringeren Anteilan Kontrollfluss. Während Blöcke von Anweisungen in Programmcodesehr häufig bedingt ausgeführt werden, gesteuert beispielsweise überif-else-Anweisungen oder for-Schleifen, so kommen hiermit vergleichbareStrukturen in realen SL/TL-Modellen, umgesetzt beispielsweise durchdie Verwendung bedingter Subsysteme, weniger häufig vor. Bei einerTestdatengenerierung für Programmcode durch symbolische Ausfüh-rung wird üblicherweise jeweils nur ein einzelner Programmpfad zurAbleitung von Testdaten herangezogen. Dies ist im Falle von SL/TL-Modellen grundsätzlich nicht anders. Allerdings bewirkt der geringereAnteil an Kontrollfluss in Modellen, dass die Betrachtung eines einzelnenCG oder SG nicht zu einer derart starken Reduktion der Komplexi-tät der jeweiligen Problemstellung für das SMT-Solving führt, wie es


bei Programmcode im Allgemeinen der Fall wäre. Daher ist eine Test-datengenerierung durch symbolische Ausführung für SL/TL-Modellegrundsätzlich herausfordernder.

Wie im vorigen Abschnitt angedeutet, ist die Anwendbarkeit des SMT-Solving entsprechend der Beschaffenheit und Größe einer Problemstel-lung begrenzt oder unter dem Gesichtspunkt der Effizienz der Lösungeiner Problemstellung durch SMT-Solving zumindest fraglich. Eine sys-tematische Analyse, unter welchen Bedingungen eine Testdatengenerie-rung mittels SMT-Solving praktisch durchführbar ist oder nicht, gestaltetsich schwierig, da der Sprachumfang von SL/TL-Modellen sehr groß istund die Möglichkeiten der Kombination verschiedener Blocktypen undder Verwendung unterschiedlicher Strukturierungskonzepte zu komplexsind. Daher konzentrieren sich die Bemühungen dieser Arbeit in dieserHinsicht auf das Sammeln von Erfahrungswerten in der Anwendungdes SMT-Solving zur Testdatengenerierung für reale SL/TL-Modelle derFirma Daimler. Hierbei wurden Modellausschnitte verschiedenen Um-fangs betrachtet. Es erfolgte eine schrittweise Skalierung, das heißt eineschrittweise Vergrößerung der betrachteten Modellausschnitte. Auf dieseWeise konnte identifiziert werden, ab welcher Modellgröße – welchesich beispielsweise durch die Anzahl der enthaltenen Blöcke bemessenlässt – oder bei Vorhandensein welcher Blocktypen eine Anwendungdes SMT-Solving problematisch ist. Die Versuche dienten darüber hin-aus dem Finden einer für das SMT-Solving geeigneten Definition derProblemstellungen einer Testdatengenerierung. Diese Definition wirdwohlgemerkt erst im nachfolgenden Abschnitt vorgestellt.

Bezüglich der Grenzen eines SMT-Solving-Einsatzes konnte festgestelltwerden, dass die Größe eines SL/TL-Modells, zumindest im Falle derbetrachteten Beispiele, keinen signifikanten Einfluss auf die Anwendbar-keit des SMT-Solving hat. Es wurde jedoch deutlich, dass die Art der inden Modellausschnitten vorkommenden Blöcke einen starken Einflussauf eine grundsätzliche oder effiziente Lösbarkeit der Testdatengenerie-rungsaufgaben mittels SMT-Solving nimmt. So ist das Vorhandenseinvon Blöcken, welche gewisse mathematische Operationen wie die An-wendung trigonometrischer Funktionen (Sinus, Kosinus und Weitere)bewerkstelligen, problematisch. Zudem erhöht die Existenz zeitdynami-scher Blöcke, wie Unit Delay oder Discrete-Time Integrator, die Komplexitäteiner Problemstellung ungemein – insbesondere wenn mehrere solcheBlöcke in Kombination auftreten.

In Konsequenz setzt diese Arbeit beim Einsatz von SMT-Solving auf Ein-satzkriterien, welche das Vorhandensein bestimmter Blocktypen in denSignalpfaden eines CG adressieren. Die Signalpfade eines CG umfassenin diesem Zusammenhang alle Blöcke des betrachteten SL/TL-Modells,die visuell betrachtet zwischen den für ein CG relevanten Modellein-gängen (siehe Abschnitt 3.2) und den am CG beteiligten Modellsignalen


liegen – und die direkt oder transitiv über Signale verbunden sind. Eineinzelner Signalpfad ist hierbei eine jede Abfolge von Signalverbindun-gen, die von einem der am CG beteiligten Modellsignale zu einem derModelleingänge führen. Die Einsatzkriterien werden für die CGs einesSG geprüft. Kommt in den hierbei betrachteten Signalpfaden ein Blockvor, dessen Typ durch die Einsatzkriterien ausgeschlossen ist, so erfolgtdie Testdatengenerierung für dieses SG nicht per SMT-Solving.

Die Menge der bei diesem Vorgehen akzeptierten Blocktypen basiert aufden zuvor geschilderten Erfahrungswerten. Die Blocktyp-Untermengeist dabei recht strikt definiert, damit ein SMT-Solving letzten Endes nurdann stattfindet, wenn dieses vom verwendeten SMT-Solver zügig, dasheißt innerhalb weniger Sekunden, durchgeführt werden kann. Über dieEinsatzkriterien sind zum einen Blöcke ausgeschlossen, deren Funktions-weise nicht bekannt ist oder nicht ohne weitergehende Analysen ermitteltwerden kann (Beispiel: S-Function-Blöcke). Zum anderen sind Blöckeausgeschlossen, welche für ein SMT-Solving problematische mathema-tische Funktionen anwenden – wie beispielsweise die zuvor erwähntentrigonometrischen Funktionen. Blöcke mit weniger problematischen ma-thematischen Operationen wie Summen- oder Produktbildungen sindhingegen zugelassen. Darüber hinaus sind keine Blöcke erlaubt, welcheeine zeitliche Dynamik besitzen. Eine zumindest teilweise Miteinbezie-hung zeitlicher Dynamik in das SMT-Solving ist wohlgemerkt denkbar,wird in dieser Arbeit allerdings nicht weiter untersucht. Betreffend einerweniger strikten Auslegung der Einsatzkriterien insgesamt ergibt sichvermutlich noch Potenzial zu einer weiteren Effizienzsteigerung des indieser Arbeit insgesamt entstandenen hybriden Testdatengenerierungs-verfahrens.

4.2.4 definition des testdatengenerierungs-problems

Damit SMT-Solving zur Testdatengenerierung eingesetzt werden kann,erfolgt für jedes SG eine Problemdefinition. Diese stellt die Grundlage zurErzeugung entsprechender Testdaten via SMT-Solving dar. Eine solcheProblemdefinition wird im Folgenden als Testdatengenerierungsproblem(TDGP, Plural: TDGPs) bezeichnet. Zur Erstellung eines TDGP wirddie selbe Repräsentation des SL/TL-Modells verwendet, welche auchfür die statischen Voranalysen genutzt wird. Diese Modellrepräsentationwird im Zuge der statischen Voranalysen gegebenenfalls transformiert(siehe Absatz zwei zu Beginn von Kapitel 3 und Abschnitt 3.1.3). Diedurchgeführten Transformationen stellen lediglich eine Zuschneidungdes Modells auf die für eine Testdatengenerierung relevanten Aspektesowie eine Vereinfachung aufgrund der Ergebnisse der statischen Vor-analysen dar. Daher kann diese Modellrepräsentation ohne Probleme zur


Ableitung von TDGPs genutzt werden. Die zuvor durchgeführten Trans-formationen sind sogar von Vorteil, denn Vereinfachungen im Modellführen zu Vereinfachungen der TDGPs.

Ein TDGP wird durch eine rückwärts gerichtete symbolische Ausführungje CG, welches Teil eines SG ist, geformt. Dies bedeutet, die Blöcke desbetrachteten Modells werden nicht entsprechend ihrer Ausführungsrei-henfolge, beginnend mit den Modelleingängen, symbolisch ausgeführt –sondern in umgekehrter Reihenfolge, ausgehend von den an einem CGbeteiligten Modellsignalen. Ein solches Vorgehen wird im Englischen alsBackward Symbolic Execution bezeichnet [52]. Der Vorteil einer rückwärtsgerichteten symbolischen Ausführung besteht in ihrer Orientierung aneiner bestimmten Zielstellung. Diese verhindert, dass irrelevante Pfa-de – im betrachteten Anwendungsfall Signalpfade – analysiert werden.Würde nämlich eine klassische symbolische Ausführung durchgeführtwerden, so würden von allen Modelleingängen ausgehend auch Signal-pfade analysiert werden, welche in keinerlei Zusammenhang mit dembetrachteten CG stehen. Würde man übrigens fest davon ausgehen, dassdie statische Voranalyse SDA genutzt wird, so ist auch eine klassischesymbolische Ausführung denkbar. Denn dann wäre bekannt, welche Mo-delleingänge für ein CG relevant sind und die symbolische Ausführungkönnte ausgehend von nur diesen Eingängen beginnen. Das nachfolgendvorgestellte Vorgehen zur Bildung der TDGPs lässt rein theoretisch beideVorgehensweisen zu. Abbildung 27 veranschaulicht das Vorgehen.

vorformulierung von bedingungen

Grundsätzlich besteht das TDGP eines jeden SG aus einer Menge von Be-dingungen (englisch: Constraints), welche im Folgenden, wo notwendig,in der SMT-LIB-Sprache formuliert sind. In die Bedingungsmenge einesTDGP fließen nicht nur Bedingungen ein, die sich (1) aus den Blockfunk-tionalitäten entlang der relevanten Signalpfade ableiten, sondern auchBedingungen, welche sich (2) für die beteiligten Modelleingänge aus derModelleingangsspezifikation ergeben. Hinzu kommen selbstverständlichBedingungen, welche die Zielstellung der Testdatengenerierung, dasheißt (3) die Ausdrücke der in dem SG enthaltenen CGs abbilden. Daeinzelne Modellblöcke und Modelleingänge im Falle von (1) und (2),sowie einzelne Modellsignale in allen drei Fällen, meist für die Bedin-gungsmengen mehrerer TDGPs relevant sind, eine einmalige Bildungder dazugehörigen Bedingungen allerdings genügt, erfolgt diese in viervorbereitenden Schritten.

Im ersten vorbereitenden Schritt wird für jedes Modellsignal über eine Be-dingung eine Variable deklariert. Bei einem vektorisierten Signal erfolgtfür jede Signaldimension eine Variablendeklaration. Spielt ein Signalbei der Ableitung von Bedingungen aus Blockfunktionalität, Modellein-gangsspezifikation oder CG-Ausdrücken eine Rolle, so wird die hierzu


Abbildung 27: Ermittlung der Suchziel-Problemdefinitionen für den Ein-satz eines SMT-Solvers

deklarierende Bedingung in die Bedingungsmenge des TDGP aufgenom-men – vorausgesetzt, sie ist in dieser Menge noch nicht enthalten.

Im zweiten vorbereitenden Schritt werden für jeden Modelleingang die inder Modelleingangsspezifikation angegebenen Wertebereiche, falls ange-geben inklusive Quantisierung, in Bedingungen übertragen. Hierdurchwird sichergestellt, dass die durch SMT-Solving erzeugten Testdatendiese Wertebereichseinschränkungen einhalten. Lautet der Wertebereicheines Modelleingangs beispielsweise [10;20]2 und bezeichnet s das vomInport-Block ausgehende Signal, so leiten sich die Bedingungen (� s 10),(� s 20) und (is_int (div (− s 10) 2)) ab. Letztere Bedingung verlangt,dass der für s generierte Wert die Quantisierung 2 berücksichtigt.

Im dritten vorbereitenden Schritt werden für jeden im Modell enthaltenenBlock Bedingungen abgeleitet, die dessen Funktionalität formulieren.Für drei ausgewählte Blocktypen sind die abzuleitenden Bedingungenin Tabelle 13 aufgeführt. Im Folgenden werden die dortigen Formu-lierungen erläutert. Allgemein gilt: Die Sammlung von Bedingungenerfolgt je Ausgang eines Blocks, das heißt gegebenenfalls auch je Vek-torelement eines Ausgangssignals. Die Abbildung OC :SN+→P(SMT)ordnet dementsprechend jedem aus dem Block ausgehenden Signal(mit Vektorindex-Angabe) eine Menge von Bedingungen zu. Die Menge


Blocktyp SMT-Definition

Inport

Voraussetzung: ∃ sb∈B:b∈BCsb

∀v∈N[1,d(s1)]: OC(sv)={

(= sv sv1)}

mit s= sigout(b,1)∧s1= sigin(sb,n)

LogicalOperator

Exemplarisch für: •=∧ und n>1


OC(sv)=⎧⎨⎩(=> (and (not (= sw1 0)) ... (not (= swn 0))) (= sv 1)) ,

(=> (or (= sw1 0) ... (= swn 0)) (= sv 0))

⎫⎬⎭

mit s= sigout(b,1)∧sx= sigin(b,x)∧w=vc(v,s)

Gain

∀v∈N[1,max(n,d(b,1))]:

OC(sv)={

(= sv (∗ gfmin(v,n) svc(v,s1)1 ))

}mit s= sigout(b,1)∧s1= sigin(b,1)

Tabelle 13: Übersetzung der Funktionalität eines jeden Blocks in für dasSMT-Solving verwendbare Bedingungen (Auszug)

SMT bezeichnet hierbei die Menge aller möglichen SMT-LIB-konformenBedingungen. Von Blöcken, die gemäß der Einsatzkriterien nicht zuberücksichtigen sind, leiten sich keine Bedingungen ab.

Inport. Für einen Inport-Block sind nur dann Bedingungen zu formulie-ren, wenn sich dieser in einem Subsystem befindet. Andernfalls handeltes sich um einen Modelleingang und ein solcher wurde bereits im zweitenvorbereitenden Schritt behandelt. Ist der Inport-Block allerdings inner-halb eines Subsystems, so wird eine Bedingung formuliert, die ausdrückt,dass die seinem Ausgangssignal (gegebenenfalls je Vektorindex) zuge-ordnete Variable der Variablen des entsprechenden Eingangssignals desübergeordneten Subsystems (mit gleichem Vektorindex) entspricht.

Logical Operator. Die Bedingungen, welche sich für einen Logical-Opera-tor-Block ableiten, sind in der Tabelle beispielhaft für den AND-Operatorund die Blockvariante mit mehreren Eingängen angegeben. Eine Bedin-gung formuliert hierbei, unter welcher Voraussetzung der Block denWert 1 (wahr) ausgibt – nämlich dann, wenn der Signalwert eines jedenBlockeingangs ungleich 0, also wahr, ist. Die zweite Bedingung gibt an,dass der Block den Wert 0 (falsch) ausgibt, sofern einer der in den Blockeingehenden Signalwerte gleich 0 (falsch) ist.


Gain. Für einen Gain-Block leitet sich eine Bedingung ab. Diese gibt an,dass die dem Ausgangssignal des Blocks (gegebenenfalls je Vektorindex)zugeordnete Variable der mit einem Faktor multiplizierten Variable desEingangssignals des Blocks (mit gleichem Vektorindex) entspricht. DerFaktor ist hierbei, wie in Abschnitt 2.1.2 definiert, ein unter Umständenvektorisierter Blockparameter.

Die in der Tabelle angegebenen Bedingungsdefinitionen gelten, wie auchdie Bedingungsdefinitionen aller weiteren SL/TL-Blocktypen, im Übri-gen auch für Blöcke, welche sich in bedingten Subsystemen befinden.Die Bedingung zur Ausführung eines bedingten Subsystems ist näm-lich schon an anderer Stelle berücksichtigt: Befinden sich die an einemCG beteiligten Signale innerhalb des bedingten Subsystems, so fließtdessen Ausführungsbedingung bereits über den CG-Ausdruck (sieheAbschnitt 2.2.1) mit in die Bedingungsmenge eines TDGP ein. Befindensich die an einem CG beteiligten Signale entlang des Signalflusses imModell betrachtet hinter einem bedingt ausgeführten Subsystem, so wirddessen Ausführungsbedingung bei der Bildung der Bedingungen fürden oder die sich im Subsystem befindlichen Outport-Block/-Blöckeaufgenommen.

Im vierten vorbereitenden Schritt wird für jedes CG, welches Teil einesSG ist, einmalig eine Bedingung gebildet. Diese beschreibt die Erfüllungdes CG und kann daher direkt aus dem CG-Ausdruck abgeleitet werden.Für das CG mit dem Ausdruck s1>5∧s2=1 leitet sich beispielsweise dieBedingung (and (> s1 5) (= s2 1)) ab.

komposition der bedingungen

Die für Signale, Modelleingänge, Blöcke und CGs vorformulierten Be-dingungen werden anschließend je SG in ein TDGP überführt. Diesgeschieht durch eine rückwärts gerichtete symbolische Ausführung. Initi-al werden die vorformulierten Bedingungen der CGs des jeweiligen SGin das TDGP aufgenommen. Anschließend werden, ausgehend von denSignalen, welche an diesen CGs beteiligt sind, alle Signalpfade bis hin zuden Modelleingängen traversiert. Die in den Signalpfaden enthaltenenBlöcke werden hierbei in umgekehrter Reihenfolge zu ihrer eigentlichenAusführungsreihenfolge (siehe Abschnitt 2.1.2) besucht.

Je Block kommt es zu einer symbolischen Ausführung. Hierbei werdendie vorformulierten Bedingungen für die Blockausgänge, welche in einemder Signalpfade liegen, in das TDGP aufgenommen. Für das Signal einesjeden solchen Blockausgangs wird (gegebenenfalls je Vektorindex) zudemdie Bedingung, welche die dazugehörige Variablendeklaration enthält,aufgenommen. Handelt es sich bei dem betrachteten Block um einenInport-Block, der zugleich einen Modelleingang darstellt, so wird das


TDGP um die vorformulierten Bedingungen ergänzt, welche für diesenModelleingang aus der Modelleingangsspezifikation gebildet wurden.

Kommt es zu der symbolischen Ausführung eines Blocks, der den zuvorvorgestellten Einsatzkriterien nicht entspricht, so wird die Traversierungder Signalpfade abgebrochen und das in diesem Zusammenhang behan-delte SG als für SMT-Solving ungeeignet markiert. Dadurch ist bei derspäteren Abarbeitung aller SGs nachvollziehbar, für welche SGs eine Test-datengenerierung nicht mittels SMT-Solving durchzuführen ist. DieserAspekt der TDGP-Bildung ist auch in Abbildung 27 dargestellt.

4.2.5 signalgenerierung

Ein TDGP stellt die Eingabe für einen SMT-Solver dar. Der Solver prüftdie Erfüllbarkeit des TDGP. Seine Antwort lautet sat (erfüllbar), unsat(unerfüllbar) oder unknown (unbekannt). Letztere Antwort bedeutet, dassder Solver das TDGP nicht lösen konnte. Durch die Verwendung vonEinsatzkriterien für das SMT-Solving ist die Wahrscheinlichkeit im An-wendungsfall dieser Arbeit jedoch gering, dass ein TDGP mit unknownausgewertet wird. Auch sollte die Antwort unsat selten vorkommen, so-fern die statischen Voranalysen SIA und CGSeq eingesetzt werden, umeinen Großteil der unerfüllbaren CGs vorab zu identifizieren. Dennochist eine Behandlung dieser möglichen Fälle notwendig. Bevor allerdingsdie Einbettung des SMT-Solving in den TestdatengenerierungsprozessThema dieses Kapitels ist, soll es an dieser Stelle erst einmal darumgehen, wie im Falle der Antwort sat Testdaten gebildet werden.

Das zur Erfüllung eines SG gesuchte Testdatum lässt sich über ein Modellbilden, welches der SMT-Solver für ein erfüllbares TDGP erzeugt. Dader Modellbegriff in dieser Arbeit bereits anderweitig genutzt wird, seidieses Modell als Lösungsmodell bezeichnet. Ein Lösungsmodell stellteinen Beleg der Erfüllbarkeit dar, also ein Beispiel, für welches die be-trachtete Bedingungsmenge erfüllt ist. Im vorliegenden Anwendungsfallenthält ein Lösungsmodell Wertebelegungen für jene Variablen einesTDGP, welche die aus den Inport-Blöcken der obersten Hierarchie-Ebenedes SL/TL-Modells ausgehenden Signale und somit die Modelleingängebezeichnen. Da die Einsatzkriterien dazu führen, dass kein TDGP zeit-liche Dynamik enthält, liegt im Lösungsmodell je Modelleingang nurein Variablenwert und nicht etwa mehrere Werte für unterschiedlicheZeitschritte vor.

Um aus den Variablenbelegungen ein plausibles Testdatum zu formen,gilt es bei einer Testdatengenerierung mittels SMT-Solving, wie schon imFalle des LGA (siehe Abschnitt 2.4.2) und der ASPO (siehe Abschnitt 4.1),die Modelleingangsspezifikation zu berücksichtigen. Auf einfachstemWege ist dies durch eine Überführung des Solver-Lösungsmodells in


Optimierungssequenzen, wie sie auch durch LGA und ASPO verwendenwerden, realisierbar. Je Modelleingang ist demnach eine Optimierungsse-quenz zu erzeugen. Hierbei ist zu berücksichtigen: Die Variablenbelegun-gen des Lösungsmodells adressieren nur einen einzigen Zeitschritt derfür die Modelleingänge zu erzeugenden Signale (Simulationssequenzen).Daher reicht es aus, wenn die Variablenbelegung des Lösungsmodells füreinen Modelleingang im Verlauf des hierfür erzeugten Signals nur ein-mal enthalten ist. Dies kann erzielt werden, indem der Amplitudenwerteines einzigen Segments der entsprechenden Optimierungssequenz aufden Wert der Variablenbelegung gesetzt wird. Auf alle auf diese Weiseadressierten Modelleingänge bezogen müssen diese Amplitudenwerte al-lerdings alle zum gleichen Zeitschritt in den aus Optimierungssequenzengenerierten Simulationssequenzen enthalten sein.

Dies wird folgendermaßen sichergestellt: Ist für keinen der Modelleingän-ge in der Modelleingangsspezifikation ein Startamplitudenwert angege-ben, so bilden die Variablenbelegungen des Lösungsmodells die Startam-plitudenwerte der jeweiligen Optimierungssequenzen. Mit Startamplitu-denwert ist hierbei der Amplitudenparameter des ersten Signalsegmentsgemeint. Da dieses Segment keine weiteren Parameter besitzt, sondernlediglich den Startamplitudenwert für das Folgesegment angibt, ent-hält eine jede Simulationssequenz die dazugehörige Variablenbelegungzum ersten Zeitschritt. Gibt es für mindestens einen Modelleinganghingegen einen Startamplitudenwert, so bildet eine jede Variablenbe-legung den Amplitudenwert des jeweils letzten Segments einer jedenOptimierungssequenz. Hierdurch tauchen die Variablenbelegungen inden Simulationssequenzen stets im allerletzten Zeitschritt auf.

Alle anderen, zu diesem Zeitpunkt noch offenen Parameter der Opti-mierungssequenzen, das heißt Amplituden-, Breiten- und Transitionstyp-Parameter der enthaltenen Segmente, werden unter Berücksichtigungder Modelleingangsspezifikation zufällig bestimmt. Dies gilt übrigensauch für alle Parameter der Optimierungssequenzen, welche für Mo-delleingänge erzeugt werden, denen durch das Solver-Lösungsmodellkeine Variablenbelegung zugewiesen ist. Der Zufall wird an dieser Stelleaus folgendem Grund miteinbezogen: Wie im nachfolgenden Abschnittzu erfahren ist, wird das betrachtete SL/TL-Modell mit dem wie hierbeschrieben erzeugten Testdatum ausgeführt. Auf das Ziel der Testda-tengenerierung für alle betrachteten SGs bezogen ist es wünschenswert,dass die hierbei erzielte Kollateralüberdeckung möglichst hoch ist. Einezufällige Bestimmung der irrelevanten Segmentparameter bei der Er-zeugung eines jeden Testdatums ist hierzu dienlicher als ein Festsetzendieser Parameter auf immer gleiche Standardwerte. Diese Überlegungspielte bereits bei der Erzeugung von Signalen für irrelevante Model-leingänge im Rahmen der statischen Voranalyse SDA eine Rolle (sieheAbschnitt 3.2.2).


4.2.6 kombination von suche und smt-solving

Die Einbettung der Testdatengenerierung mittels SMT-Solving in dashybride Testverfahren dieser Arbeit ist in Abbildung 28 dargestellt. Ins-besondere ist dort Form und Ablauf des Hybrids aus SMT-Solving undTestdatensuche zu erkennen. Die Formulierung der TDGPs für jedesSG erfolgt, wie zu sehen, nach Durchführung der statischen Voranaly-sen. Hierbei werden auch die Einsatzkriterien geprüft, so dass für jedesSG angegeben ist, ob der Versuch einer Testdatengenerierung mittelsSMT-Solving unternommen werden soll.

Anschließend werden für die SGs, gemäß der durch die statische Vorana-lyse CGSeq bestimmten Abarbeitungsreihenfolge, Testdaten generiert.Hierbei kommt vorzugsweise SMT-Solving zum Einsatz, sofern ein SGals hierfür geeignet gilt. Andernfalls wird eine Testdatensuche angesto-ßen. Das Vorgehen einer Testdatensuche, sei es mittels des LGA oderder ASPO, wurde in dieser Arbeit bereits ausführlich behandelt. Sollenfür ein SG Testdaten per SMT-Solving generiert werden, so wird derSMT-Solver mit dem vorbereiteten TDGP ausgeführt. Antwortet der Sol-ver mit unsat, so wird zum nächsten SG übergegangen. Enthält das SGzudem nur ein einziges CG, so wird dieses als unerfüllbar markiert. ImFalle eines zusammengesetzten SG bleibt hingegen offen, welches derenthaltenen CGs für die Unerfüllbarkeit verantwortlich ist. Antwortetder SMT-Solver mit unknown, so war er nicht erfolgreich. Daher wird indiesem Fall eine Testdatensuche für das SG angestoßen. Antwortet derSolver mit sat, so wird, wie im vorigen Abschnitt ausführlich beschrieben,aus dem Lösungsmodell des Solvers ein Testdatum geformt.

Um zu verifizieren, dass dieses Testdatum tatsächlich das Erreichender CGs des betrachteten SG bewirkt, wird das SL/TL-Modell mit demTestdatum ausgeführt. Dieser Schritt dient außerdem der Ermittlung,welche anderen CGs und somit SGs eventuell zufällig mit erreicht wer-den (Kollateralüberdeckung). Bestätigt die Modellausführung, dass dasTestdatum das aktuell betrachtete SG erfüllt, so wird es in die insgesamtzu erstellende Testsuite aufgenommen. Anschließend wird zum nächstenSG übergegangen. Kommt die statische Voranalyse CGSeq zum Einsatz,so wird zuvor noch die Abarbeitungsreihenfolge der SGs aktualisiert.Der Sinn und Zweck dieses Schritts ist in Abschnitt 3.4 dargelegt.

Mit der Hybridisierung von Suche und symbolischer Ausführung erfährtdas in Abschnitt 3.3.3.2 vorgestellte Vorgehen zur SG-Reihenfolgenbildungdurch CGSeq eine Änderung. Die über eine Priorisierung der SGs gebilde-te Reihenfolge unterscheidet nun zwischen SGs, für welche SMT-Solvingangewendet wird, und denen, für die vorab schon feststeht, dass eineTestdatensuche durchgeführt wird. Diese Boolesche Metrik erhält denBezeichner M0. SMT-Solving-taugliche SGs werden hierbei bevorzugt,das heißt sie landen in der Abarbeitungsreihenfolge vor sonstigen SGs.


Abbildung 28: Kombination von Suche und SMT-Solving zu einem hy-briden Testdatengenerierungsverfahren für SL/TL


Die sonstigen SGs werden anschließend entsprechend der ursprünglichverwendeten Metriken priorisiert. SMT-Solving-taugliche SGs hingegenwerden zuerst nach der geringeren Modelltiefe eines SG (M2) und beidiesbezüglicher Gleichheit nach der höheren Anzahl implizierter CGs(M3) geordnet. Dies bedeutet, dass in diesem Fall die Priorisierungsme-triken der Anzahl Boolescher Signale (M1) und der Anzahl relevanterModelleingänge (M4) entfallen. Der Grund hierfür ist, dass diese Metri-ken für eine Testdatengenerierung durch SMT-Solving keine Relevanzhaben. Boolesche Zieldefinitionen stellen zum einen kein Problem füreine solche Testdatengenerierung dar und zum anderen betrachtet dierückwärts gerichtete symbolische Ausführung bedingt durch ihre Funkti-onsweise ohnehin ausschließlich relevante Modelleingänge. Vergleichendzur Darstellung der ursprünglichen Priorisierung in Abbildung 20 stelltAbbildung 29 die erweiterte Priorisierung dar.

Da die Bildung der TDGP, wie in Abbildung 28 erkennbar, erst nachden statischen Voranalysen und somit erst nach CGSeq stattfindet, istdie SG-Reihenfolge nach der TDGP-Bildung zu aktualisieren. Alternativdazu könnte die TDGP-Bildung auch innerhalb von CGSeq erfolgen –zwischen Bildung der SGs und deren Priorisierung.

Abbildung 29: Anpassung der Suchzielpriorisierung bei Verwendungvon SMT-Solving und Suche in Kombination


Mit diesen Ausführungen ist der letzte Baustein des hybriden Testver-fahrens dieser Arbeit vorgestellt. Der Baustein ergänzt die bereits umstatische Voranalysen erweiterte Testdatensuche um eine Testdatengene-rierung durch symbolische Ausführung. Zwischen Testdatensuche undsymbolischer Ausführung erfolgt hierbei eine SG-spezifische, Kriterien-basierte Auswahl. Die in Kapitel 6 vorgestellten Fallstudien untersuchen,ob und inwieweit sich eine derartige Hybridisierung positiv auf dieEffizienz einer automatisierten Testdatengenerierung auswirkt.


Im Grundlagen-Kapitel dieser Arbeit in Abschnitt 2.3.1 wurden bereitszwei verwandte Arbeiten, eine von Roy und Shankar [101, 102] sowie einevon Pasareanu et al. [96], im Kontext einer symbolischen Ausführung fürSL-Modelle behandelt. Wie dort bereits herausgestellt wurde, unterschei-den sich die Ansätze der beiden Arbeiten vom hier präsentierten Ansatzin mehreren Punkten. Die zwei wesentlichsten Punkte sind hierbei, dassdie Plausibilität der generierten Testdaten dort nicht betrachtet wirdund die Grenzen einer symbolischen Ausführung in Anwendung fürSL-Modelle entweder nicht erörtert oder nicht adressiert werden.

Eine Hybridisierung mehrerer Testdatengenerierungstechniken über eineKriterien-basierte Auswahl ist Gegenstand einer Arbeit von Peranandamet al. [95] (behandelt in Abschnitt 2.3.3). Die verwendeten Kriteriennennen die Autoren allerdings nicht. Die Plausibilität der generiertenTestdaten steht zudem nicht im Fokus ihres Ansatzes.

Eine verwandte Arbeit, welche sich mit einer Anwendung des SMT-Solving für SL-Modelle beschäftigt, stammt von Herber et al. [65]. Auchwenn es den Autoren nicht um die Generierung von Testdaten geht, son-dern um eine formale Verifikation von Modellen (Model-Checking undInvariantenprüfung), so behandeln sie doch auch eine Übersetzung derFunktionalität eines SL-Modells hin zu einer für SMT-Solving tauglichenRepräsentation. Die Übersetzung erfolgt allerdings in die Eingabesprachedes Verifikationswerkzeugs UCLID. Dieses nutzt zur Erfüllung seinerVerifikationsaufgaben SMT-Solving.

In Bezug zu diesen Arbeiten zeichnet sich der in diesem Teil der vorlie-genden Arbeit vorgestellte Ansatz durch folgende Eigenschaften aus:

1. Definition von Einsatzkriterien zur Testdatengenerierung mittelsSMT-Solving für SL/TL-Modelle

2. Beachtung der Signalplausibilität bei Erzeugung über SMT-Solving

3. Hybridisierung von Suche, symbolischer Ausführung und stati-schen Voranalysen

Teil III

R E A L I S I E R U N G U N D E VA L U I E R U N G

5 TESTWERKZEUG-PROTOTYP

Die in dieser Arbeit vorgestellten Ideen und Techniken wurden in einprototypisches Testwerkzeug überführt. Dieses ermöglicht eine automa-tisierte Testdatengenerierung für SL/TL-Modelle. Das Werkzeug, wel-ches im Folgenden unter Verwendung des Namens TASMO (Testing viaAutomated Search for Models) vorgestellt wird, dient im Rahmen dervorliegenden Arbeit hauptsächlich der Evaluierung der zuvor behandel-ten Beiträge. Darüber hinaus dient der Werkzeug-Prototyp allerdingsauch der Heranführung der Konzepte des suchbasierten Tests mitsamtergänzender Techniken an die Praxiswelt. TASMO nutzt einen Teil derImplementierung, die im Rahmen der Arbeit von Windisch [132] entstan-den ist. Dies betrifft im Wesentlichen die Umsetzung des SuchverfahrensLGA und des segmentbasierten Signalgenerierungsansatzes.

In den folgenden drei Abschnitten werden technische Hintergründe zuTASMO, der Ablauf einer Anwendung des Werkzeugs sowie Herausfor-derungen bei der Entwicklung eines solchen Werkzeugs beleuchtet.

5.1 architektur

Ein Blick in Abbildung 30 verrät, dass TASMO grundlegend aus zweiKomponenten besteht: einer Client- und einer Server-Anwendung. DieFunktionalitäten des Testwerkzeugs sind zum wesentlichen Teil in derProgrammiersprache Java realisiert. Dieser Teil von TASMO stellt dieServer-Anwendung dar. Die Client-Anwendung kommuniziert mit dieser.Die Client-Anwendung ist mit der ML-eigenen Skriptsprache m geschrie-ben und kann in das ML-Werkzeug integriert werden. Auf diese Weisekann der Anwender direkt aus dem SL-Editor heraus für ein geöffnetesSL/TL Modell oder für einen Ausschnitt aus einem solchen (virtuel-les Subsystem) eine Testdatengenerierung initiieren. TASMO ist hierbeistrukturell so aufgebaut, dass verschiedene Testdatengenerierungsszena-rien (siehe Abschnitt 2.2) unterstützt werden können. Eine vollständigeImplementierung ist im Rahmen dieser Arbeit allerdings nur für denStrukturtest erfolgt.

Nachfolgend wird die Architektur von TASMO vorgestellt. Die Darstel-lung dieser in Abbildung 30 begleitet die Ausführungen.

179

180 testwerkzeug-prototyp

Abbildung 30: Architektur des entwickelten Tool-Prototypen

Simulink Plug-in. Diese Komponente enthält die Client-Anwendungund realisiert die Integration von TASMO in den SL-Editor. Ist ein Mo-dell in diesem geöffnet, so kann über einen Menüeintrag die Testdaten-generierung angestoßen werden. Der Client prüft dann, ob die Server-Anwendung bereits läuft. Ist dies der Fall, so übermittelt der Client demServer die vom Nutzer gewünschte Aufgabe (Testart und Modellinforma-tionen) – andernfalls wird zuerst ein Start der Server-Anwendung initiiert.Bevor aber beispielsweise die Aufgabe einer Testdatengenerierung zum

5.1 architektur 181

Zwecke eines Strukturtests übermittelt wird, prüft die Client-Anwendungeine Reihe von Vorbedingungen, wie die Ausführbarkeit des im SL-Editorgeöffneten Modells, und sammelt im Falle eines positiven ErgebnissesInformationen über das Modell (Unterkomponente Data Export). Diesestehen der Server-Anwendung im Anschluss zur Verfügung. Insbeson-dere wird die Struktur des betrachteten SL/TL-Modells exportiert. EinModellparser nutzt hierzu die Programmierschnittstelle (API) von MLund überführt das Modell in eine XML-Datei. Bei dem Parser handelt essich um eine Weiterentwicklung des SL-Parsers von Scheible [107].

Controller. Die Controller-Komponente der Server-Anwendung bildetdie Funktionslogik der verschiedenen Anwendungsfälle ab, wobei derPrototyp nur die strukturorientierte Testdatengenerierung umsetzt. ZurErfüllung ihrer Teilaufgaben greift die Komponente auf die KomponentenCore und In/Out zurück. Zur visuellen Darstellung der Abläufe und zurInteraktion mit dem Anwender nutzt sie die GUI-Komponente.

GUI. Diese Komponente regelt auf Anweisung der Controller-Komponentedie grafische Darstellung der Benutzeroberfläche von TASMO und stelltder Controller-Komponente zudem Benutzerinteraktionen und -eingabenzur Verfügung. Die Vorbereitung einer Testdatengenerierung durch denAnwender erfolgt hierbei in Form eines Wizard. Bei diesem handelt essich um einen aus mehreren Schritten bestehenden Benutzerdialog. Wäh-rend einer Testdatengenerierung wird zudem deren Fortschritt grafischdargestellt (Unterkomponente Progress Monitor). Sowohl innerhalb desWizards als auch während der Testdatengenerierung kann die Unter-komponente Model Browser genutzt werden. Diese stellt das betrachteteSL/TL-Modell grafisch dar und reichert die Darstellung durch zusätzli-che Informationen, wie die sich von den Blöcken des Modells ableitendenoder die durch die Testdatengenerierung aktuell verfolgten CGs, an.

In/Out. Diese Komponente stellt zum einen Kommunikationsschnitt-stellen zur Verfügung, wie beispielsweise zur Interaktion von TASMOmit einer Instanz des ML-Werkzeugs. Zum anderen ermöglicht sie dasAblegen und Einlesen verschiedener Daten, welche entweder Grundlageeiner Testdatengenerierung sind oder welche während einer Testdatenge-nerierung entstehen. Es existieren folgende Unterkomponenten.

Client Request Parser. Dieser verarbeitet die XML-basierten Aufträge derClient-Anwendung. Im Falle einer strukturorientierten Testdatengenerie-rung enthält ein Auftrag unter anderem Angaben zu dem Speicherpfaddes SL/TL-Modells, dessen Dateinamen sowie den Namen und Pfadeines vom Client erzeugten Arbeitsordners für abzulegende Dateien undErgebnisse. In diesem Ordner legt die Client-Anwendung übrigens auchdas als XML-Datei extrahierte SL/TL-Modell ab.

Matlab Import. Diese Unterkomponente liest die von der Client-Anwen-dung exportierten Modellinformationen ein und erstellt aus ihnen eine


Modellrepräsentation: Von dieser werden im Falle eines Strukturtests CGsabgeleitet. Zudem dient sie der Durchführung der statischen Voranalysen(siehe Kapitel 3) und der symbolischen Ausführung via SMT-Solving(siehe Abschnitt 4.2).

Input Specification. Diese Unterkomponente kann eine vom Nutzer erstell-te Modelleingangsspezifikation in einem XML-Format abspeichern undin umgekehrter Richtung auch wieder einlesen.

Test Data. Erzeugte Testdaten können durch diese Unterkomponente ineinem XML-Format abgelegt werden. Zudem können Testdaten, welcheunter Umständen aus anderweitigen Tests stammen, eingelesen werden.Diese können beispielsweise bei einer automatisierten Testdatengene-rierung im Sinne eines Strukturtests als Grundlage dienen. Auf diesenAspekt wird im nächsten Abschnitt noch näher eingegangen. Der Proto-typ TASMO unterstützt aktuell allerdings nur das eigene XML-Format.

Test Execution. Diese Unterkomponente bewerkstelligt die Ausführungeiner Kopie des betrachteten SL/TL-Modells mit Testdaten. Hierzu ge-hören auch die Initialisierung und Instrumentierung der Modell-Kopiesowie das Auslesen der protokollierten Signalverläufe. Zur Kommunika-tion mit ML und zur Auswertung der protokollierten Daten werden dieJava-Bibliotheken matlabcontrol1 und JMatIO2 eingesetzt.

Test Report. Statistiken und Ergebnisse einer abgeschlossenen Testdatenge-nerierung werden von dieser Unterkomponente in einem Web-basiertenBericht zusammengefasst.

Constraints. Wie in Abschnitt 2.3.2 erwähnt, können in dem suchbasiertenAnsatz von Windisch [132] zusätzliche Testdaten-Bedingungen berück-sichtigt werden. Derartige Bedingungen kann die UnterkomponenteConstraints in eine Datei überführen oder aus einer Datei einlesen.

Settings. Diese Unterkomponente verwaltet, das heißt speichert und lädt,generelle Einstellungen des TASMO-Werkzeugs. Für die Durchführungder Fallstudien dieser Arbeit enthalten die Einstellungen übrigens auchParameter, über die sich die einzelnen statischen Voranalysen (SIA, SDA,CGSeq) de-/aktivieren lassen und über die sich das zu verwendendeTestdatengenerierungsverfahren (LGA, ASPO oder der Hybrid aus LGAund SMT-Solving) auswählen lässt.

Database. Für die Auswertung der Fallstudien dieser Arbeit sammelt dieseUnterkomponente relevante Daten in einer SQLite-Datenbank.

Core. Die Core-Komponente stellt den Kern der Funktionalität von TAS-MO dar und enthält verschiedene Datenstrukturen und Algorithmen. Sieist in die nachfolgend aufgeführten Unterkomponenten gegliedert.

1 https://code.google.com/p/matlabcontrol (letzter Zugriff: 01.04.2014)2 http://sourceforge.net/projects/jmatio (letzter Zugriff: 01.04.2014)

https://code.google.com/p/matlabcontrol

http://sourceforge.net/projects/jmatio

5.2 nutzersicht und funktionsweise 183

Model. Die Struktur der internen Repräsentation des betrachteten SL/TL-Modells wird unter Verwendung dieser Unterkomponente gebildet. Siebildet sowohl generische Strukturelemente wie Signale oder Blöcke ab,als auch spezifische Blocktypen – unterschieden nach SL-eigenen undTL-eigenen Blocktypen sowie dem speziellen SF-Blocktyp.

Goals. Der Aufbau eines CG-Ausdrucks sowie eines SG ist in dieser Un-terkomponente definiert. Die Ableitung der CGs von einem Modell undderen Zuordnung zu Überdeckungskriterien ist ebenfalls hier enthalten.Darüber hinaus stellt die Unterkomponente Funktionen zur Berechnungder Fitness eines CG oder SG zur Verfügung.

Analysis. Diese Unterkomponente enthält die Umsetzungen der dreistatischen Voranalysen SIA, SDA und CGSeq. Zusätzlich existieren eineReihe von Funktionen zur Modelltransformation. Diese werden unteranderem von SIA verwendet.

Search. Die zur Testdatengenerierung verwendeten Algorithmen sindBestandteil dieser Unterkomponente: das globale Suchverfahren LGA,das lokale Suchverfahren ASPO und die symbolische Ausführung mittelsSMT-Solving. Die einzelnen Algorithmen greifen zu ihrer Erfüllung ins-besondere auf die folgenden drei Komponenten zurück: Signal Generation,Test Execution und Fitness aus der Komponente Goals.

Signal Generation. Die Erzeugung von Optimierungssequenzen und derenUmwandlung in Simulationssequenzen realisiert diese Komponente.

Signal Constraints. Die Struktur zusätzlicher Testdaten-Bedingungen unddas Vorgehen zur Berücksichtigung solcher bei einer Testdatensuche istGegenstand dieser Unterkomponente. Da dieser Aspekt nicht im Fokusder vorliegenden Arbeit steht, unterscheidet sich diese Komponente nichtvon der diesbezüglichen Umsetzung im Rahmen der Arbeit von Windisch[132]. Dies bedeutet auch, dass zusätzliche Testdaten-Bedingungen vonTASMO zwar neben dem LGA auch von ASPO berücksichtigt werden,nicht aber durch das SMT-Solving.

5.2 nutzersicht und funktionsweise

Die zuvor beschriebenen Bausteine werden vom TASMO-Werkzeug zumZweck einer automatisierten Testdatengenerierung für ein SL/TL-Modellbenutzt. Hierbei steht, wie auch im Rahmen der vorliegenden Arbeit ins-gesamt, der Strukturtest im Vordergrund. In diesem Szenario ergibt sichbei Verwendung von TASMO der folgend erläuterte Ablauf. Dieser ist inAbbildung 31 dargestellt und betrachtet sowohl die Sicht des Anwendersauf den gesamten Vorgang, als auch die wichtigsten internen Funktiona-litäten von TASMO. Diese bleiben dem Anwender allerdings verborgen.


Eine Interaktion mit dem Anwender ist nur an den Stellen notwendig,die in der Darstellung mit einer kleinen Figur markiert sind.

Eine Testdatengenerierung zur strukturellen Überdeckung eines im SL-Editor geöffneten Modells wird vom Anwender durch Anklicken desentsprechenden Menüeintrags von TASMO im SL-Editor eingeleitet. TAS-MO ermittelt daraufhin die benötigten Modelldaten und erzeugt eineeigene Modellrepräsentation. Diese nutzt TASMO im nächsten Schritt,um die Beschaffenheit der Eingänge des Modells zu analysieren. Beiden Ein- und Ausgängen des Modells handelt es sich nämlich unterUmständen um Bus-Systeme oder Vektorsignale, wobei Beides sogarin verschachtelter Form vorkommen kann. Damit TASMO weiß, wieviele und welche Signale tatsächlich zu generieren sind, ist eine Schnitt-stellenanalyse notwendig. Nach dieser geht TASMO alle Blöcke der

Abbildung 31: Ablauf der strukturorientierten Testdatengenerierung undNutzerinteraktion mit dem Tool-Prototypen


Modellrepräsentation durch und leitet die CGs aller in dieser Arbeitunterstützten Überdeckungskriterien ab (siehe Abschnitt 2.2.1). Wie zuBeginn des dritten Kapitels erwähnt, führt TASMO zudem initiale Mo-delltransformationen durch. Diese reduzieren das Modell auf den für dieTestdatengenerierung relevanten Modellanteil.

Dem Anwender bleibt diese Initialisierung verborgen. Nachdem er imSL-Editor die strukturorientierte Testdatengenerierung angewählt hat,zeigt sich ihm als Nächstes das Fenster des TASMO-Werkzeugs mitdem ersten Schritt eines Wizards (siehe Abbildung 32a). Der Wizarddient der Vorbereitung der Testdatengenerierung durch den Anwender.Im ersten Schritt erfolgt die Spezifikation der Modelleingänge, wie inAbschnitt 2.4.2 behandelt. Zum Beispiel müssen für jeden Modellein-gang Wertebereichsangaben gemacht werden. Anschließend besteht dieMöglichkeit, für jeden Modelleingang zusätzliche Bedingungen in einertemporalen Logik anzugeben. Obwohl dieser Aspekt, wie im vorigenAbschnitt angesprochen, nicht im Fokus dieser Arbeit steht, enthält derTASMO-Wizard einen entsprechenden Schritt, um die Möglichkeiteneiner suchbasierten Testdatengenerierung zu verdeutlichen. Der dritteSchritt des Wizards erlaubt es dem Anwender, bereits existierende Testda-ten wiederzuverwenden. Da einem Strukturtest in der Praxis häufig einFunktionstest, beziehungsweise ein anforderungsbasierter Test, voraus-geht (siehe Abschnitt 2.1.3), existieren demnach auch bereits Testdatenoder Testfälle. Diese erzielen bereits einen gewissen Überdeckungsgrad.Um TASMO nur nach Testdaten für noch nicht erreichte CGs fahnden zulassen, ist im Wizard daher die Möglichkeit eines Imports von Testfällenoder Testdaten vorgesehen. Im letzten Schritt des Wizards wählt der An-wender das oder die gewünschte/-n Überdeckungskriterium/-kriterien,oder wahlweise einzelne CGs der unterstützten Überdeckungskriteri-en aus (siehe Abbildung 32b). Die Auswahl einzelner CGs kann derAnwender hierbei auch im erwähnten Modellbrowser tätigen.

Ist der Anwender am Ende des Wizards angelangt, das heißt hat eralle verpflichtenden Angaben (Modelleingangsspezifikation und Kri-terien/CGs-Wahl) und gegebenenfalls optionale Angaben (Testdaten-Bedingungen und Testdaten-Import) gemacht, so startet die automati-sche Durchführung des gesamten Testdatengenerierungsprozesses (sieheAbbildung 33a). Hierbei werden im ersten Schritt die drei statischenVoranalysen SIA, SDA und CGSeq ausgeführt. Wegen der Fallstudiendieser Arbeit ist es möglich, dass einzelne Voranalysen deaktiviert sind.Im Falle der Deaktivierung von CGSeq gilt: Es werden trotzdem SGsgebildet, diese enthalten aber jeweils nur ein selektiertes CG (siehe Ab-schnitt 3.3.3.1). Die SGs werden in diesem Fall zudem zufällig sortiert.Im zweiten Schritt wird eine Kopie des betrachteten SL/TL-Modells fürspätere Ausführungen mit Testdaten vorbereitet. Hierzu wird eine neue,für den Anwender nicht sichtbare Instanz des ML-Werkzeugs geöffnetund in dieser Workspace-Daten sowie die Modellkopie geladen. Zudem


(a) Modelleingangsspezifikation

(b) Überdeckungskriterien-Wahl oder Überdeckungsziel-Auswahl

Abbildung 32: Einblick in den Wizard des Werkzeug-Prototypen

wird die Modellkopie instrumentiert, das heißt für alle Signale, welchezur Auswertung der CGs protokolliert werden müssen, wird ein entspre-chendes Feature des SL-Werkzeugs aktiviert. Die protokollierten Datenwerden hierdurch nach einer Modellausführung im ML-Workspace ab-gelegt. Im dritten Schritt werden gegebenenfalls importierte Testdatenausgeführt und registriert, welche CGs, und somit SGs, durch diese be-reits erreicht sind. Im vierten Schritt erfolgt die Testdatengenerierungfür alle noch nicht erreichten SGs, je nach Voreinstellung durch die AS-


(a) Testdatengenerierung

(b) Testreport

Abbildung 33: TASMO: Testdatengenerierung und Testreport

PO, den LGA oder den Hybrid aus LGA und SMT-Solving. Die hierbeierstellte Testsuite wird nach Beendigung der Testdatengenerierung ineinem XML-Format abgespeichert. Zudem wird jedes in der Testsuiteenthaltene Testdatum als ausführbares m-Skript abgelegt, so dass derAnwender das SL/TL-Modell später noch einmal mit diesem Testdatumausführen kann. Im letzten Schritt erzeugt TASMO einen Bericht mit Sta-tistiken, wie dem erreichten Überdeckungsgrad, und einer Detailansichtder erzeugten Testdaten (siehe Abbildung 33b).


5.3 technische und praktischeherausforderungen

Die Entwicklung eines Werkzeugs wie dem Prototypen TASMO birgteine Reihe von technischen und praktischen Herausforderungen. Die-se sollen an dieser Stelle in aller Kürze angerissen werden. Neben derbereits erwähnten Schnittstellenanalyse, welche notwendig ist, um dieSignalstruktur an den Modelleingängen zu bestimmen, stellen bestimmteEigenheiten und Sonderfälle der ML- und SL-Umgebung sowie Indivi-duallösungen in der Entwicklungspraxis weitere Herausforderungen.

So erlaubt es SL beispielsweise nicht, Signale zu protokollieren, welche di-rekt aus bedingten Subsystemen ausgehen und die zu einem Merge-Blockführen. TASMO löst dieses Problem, indem es im Zuge der Modellin-strumentierung zwischen Subsystem und Merge-Block einen Gain-Blockmit dem Faktor eins einfügt. Ein solcher Gain-Block verändert die Signal-werte nicht, sein Ausgangssignal lässt sich jedoch protokollieren. Eineweitere Schwierigkeit besteht in der effizienten Übertragung einer hohenAnzahl protokollierter Signalverläufe von ML in ein Java-basiertes Werk-zeug. Eine direkte Übertragung, bei der jeder Signalverlauf innerhalbeiner Programmschleife übermittelt wird, dauert außerordentlich lange.Um die Übertragung protokollierter Daten möglichst schnell zu gestalten,lässt TASMO diese von ML in eine sogenannte MAT-Binärdatei exportie-ren und importiert diese im Java-Werkzeug. Diese beiden Operationenlaufen selbst bei recht vielen protokollierten Signalen sehr schnell ab.

Auch wenn das prototypische Werkzeug TASMO bereits viele Eigenhei-ten und Sonderfälle berücksichtigt, so bedarf es dennoch einer weiter-gehenden Entwicklung, um aus TASMO ein in der industriellen Praxiseinsetzbares Werkzeug zu formen. Beispielsweise gilt es, das Vorhan-densein individueller Entwicklungsumgebungen in SL zu berücksich-tigen. In vielen Entwicklungsprojekten kommen nämlich individuelle,in der m-Sprache implementierte Tool-Suiten zum Einsatz. Diese schaf-fen beispielsweise direkte Verknüpfungen zu im Entwicklungsprozessbenachbarten Werkzeugen oder regeln den Zugriff auf gemeinsame Res-sourcen. Da ein SL/TL-Modell ohne die Initialisierung einer solchenEntwicklungsumgebung oftmals nicht ausgeführt werden kann, ist eineentsprechende Initialisierung in der ML-Instanz, welche bei TASMO derModellausführung dient, zu bewerkstelligen. Dies ist aufgrund der vie-len Formen einer Initialisierung – beispielsweise über ein m-Skript mitgrafischer Benutzeroberfläche oder über eine Batch-Datei – nicht immerunproblematisch. Ein weiteres Problem besteht in dem Vorhandenseinverschiedener Programmversionen von SL und TL in Entwicklungspro-jekten. Ein praxistaugliches Werkzeug muss die Unterschiede dieserVersionen berücksichtigen.

6 FALLSTUD IEN

Zur Bewertung der Beiträge dieser Arbeit wurde der Werkzeug-PrototypTASMO eingesetzt. Es galt, im Sinne eines Strukturtests Testdaten fürzwei reale SL/TL-Modelle aus der Automobilindustrie zu erzeugen. Dieeinzelnen Beiträge dieser Arbeit, das heißt die statischen VoranalysenSIA, SDA und CGSeq sowie das lokale Suchverfahren ASPO und diesymbolische Ausführung mittels SMT-Solving, wurden hierbei jeweilseiner gesonderten Untersuchung unterzogen. Dieses Kapitel stellt zu-nächst den Versuchsaufbau der Fallstudien vor. Anschließend werdenderen Ergebnisse präsentiert, eingeordnet und die Beiträge dieser Arbeitbewertet.

6.1 versuchsaufbau

Der Versuchsaufbau adressiert neben den Eckdaten der verwendetenSL/TL-Modelle die zu beantwortenden Thesen und die der Beantwor-tung dienenden Kriterien. In diesem Zusammenhang werden verschiede-ne Konfigurationen des hybriden Testverfahrens aufgestellt. Die Ergeb-nisse der mit diesen Konfigurationen durchgeführten Fallstudien werdenim Anschluss an diesen Abschnitt vorgestellt.

6.1.1 testobjekte/modelle

Die für die Fallstudien verwendeten SL/TL-Modelle entstammen aktu-ellen Entwicklungsprojekten der Daimler AG. Es werden zwei verschie-dene Modelle betrachtet. Das im folgenden als Modell A bezeichneteSL/TL-Modell realisiert eine Funktion in einem alternativen (elektri-schen/hybriden) Antriebsstrang eines Fahrzeugs. Das zweite, als ModellB bezeichnete SL/TL-Modell implementiert Funktionalitäten, die imBereich des Fahrzeuginnenraums zur Anwendung kommen. Über dieFunktionalitäten, Schnittstellen und Inhalte beider Modelle können andieser Stelle aus Gründen der Geheimhaltung leider keine detailliertenAngaben gemacht werden. Um aber dennoch einen Eindruck bezüg-lich der Komplexität dieser Modelle und einer Testdatengenerierung für

189

190 fallstudien

diese zu erhalten, seien folgende Größenangaben und Charakteristikengenannt.

Modell A enthält eine hohe dreistellige Anzahl an Blöcken – Modell B istbezüglich der Blockanzahl fast dreimal so umfangreich. Modell B weistim Vergleich zu Modell A einen höheren Anteil logischer Blocktypenauf – das heißt Blocktypen, deren ausgehende Signale einen BooleschenWertebereich haben. Modell A enthält mehr Schleifen (Rückkopplungen)und somit eine höhere zeitliche Dynamik als Modell B. Die Schnittstellenbeider Modelle enthalten eine niedrige zweistellige Anzahl an Eingängen– wobei Modell B mehr Eingänge als Modell A besitzt.

Für beide Modelle wurde im Rahmen der Fallstudien jeweils eine Model-leingangsspezifikation gebildet. Die dort gemachten Angaben basierenzum einen auf Informationen, die – wie zum Beispiel die Wertebereichs-angaben – aus Modell-begleitenden Entwicklungsdokumenten stammen,und zum anderen auf Auskünften der Modellentwickler. Trotz einergeringeren Anzahl an Eingängen ist der für die Testdatengenerierung soentscheidende Suchraum im Fall von Modell A größer (beziehungsweisekomplexer) als bei Modell B. Während nämlich nur 17% der Eingängevon Modell A einen Booleschen Wertebereich aufweisen, so sind dies beiModell B ganze 50%.

Neben der individuellen Spezifikation der Modelleingänge gilt es, diezeitliche Länge und Abtastrate der zu generierenden Signale vorabModelleingangs-übergreifend festzulegen. Die Abtastrate ist in den Simu-lationseinstellungen eines Modells vermerkt und kann direkt übernom-men werden. Sie liegt im Falle beider Modelle im Millisekundenbereich.Als zeitliche Länge für die zu generierenden Signale wurden 30 Se-kunden im Fall von Modell A und 20 Sekunden im Fall von Modell Bgewählt. Dieser Festlegung liegt eine manuelle Betrachtung der zeitlichenDynamik der Modelle zugrunde, denn es ist sicherzustellen, dass diegenerierten Signale ausreichend lang sind. Sind sie nämlich zu kurz, sokönnte dies zur Unerreichbarkeit mancher CGs führen.

Das hybride Testverfahren dieser Arbeit hatte in den Fallstudien dieAufgabe, Testdaten zur strukturellen Überdeckung beider Modelle zugenerieren. Eventuell in den Entwicklungsprojekten bereits existierendeTestfälle oder Testdaten, beispielsweise aus anforderungsbasierten Tests,wurden nicht berücksichtigt. Als Überdeckungskriterien wurde sowohldie Bedingungsüberdeckung (CC) als auch die Entscheidungsüberde-ckung (DC) herangezogen. Für diese beiden Kriterien leiten sich fürModell A insgesamt 600 CGs und für Modell B insgesamt 1113 CGs ab.

6.1 versuchsaufbau 191

6.1.2 thesen

In diesem Abschnitt werden Thesen aufgestellt. Diese verkörpern Erwar-tungen an die Beiträge dieser Arbeit. Die Fallstudien dienen der Stützung,Relativierung oder Widerlegung dieser Erwartungen. In Kapitel 1 wurdeauf Seite 8 die zentrale These dieser Arbeit aufgestellt. Diese lautet:

Die Effizienz des Ansatzes von Windisch zur suchbasierten Testdatengenerierungfür SL-Modelle lässt sich durch eine Hybridisierung derselben mit geeignetenstatischen oder dynamischen Techniken deutlich erhöhen.

Diese These wird für die Fallstudien nun in einzelne Thesen aufge-schlüsselt. Diese adressieren jeweils den Einfluss der einzelnen Beiträgedieser Arbeit auf die Effizienz des suchbasierten Ansatzes. Die Gültig-keit dieser Thesen impliziert die Gültigkeit der zentralen These dieserArbeit. Darüber hinaus werden ergänzende Thesen aufgestellt, welcheweitergehende Aspekte der einzelnen Beiträge oder die automatisierteTestdatengenerierung insgesamt adressieren. Solche Thesen sind in derfolgenden Auflistung jeweils mit einem kleinen Sternchen markiert. Eineausführliche Erklärung der aufgelisteten Thesen erfolgt, sofern jeweilsnotwendig, im Zuge der Analyse der Fallstudienergebnisse hinsichtlichdieser Thesen.

Für die statische Voranalyse SIA werden folgende Thesen aufgestellt:

These T1a. Existieren in einem Modell unerreichbare CGs, so steigert derEinsatz von SIA die Effizienz der Testdatengenerierungsvorgänge insgesamt.

These T1b. Der zeitliche Aufwand von SIA ist geringer als der Zeitgewinn,den der Einsatz von SIA für die Testdatengenerierungsvorgänge insgesamtbewirkt.

These T1c. Der durch Testdatensuchen erzielte Überdeckungsgrad ist bei Ein-satz von SIA mindestens genauso hoch wie ohne diesen.

Die zweite statische Voranalyse SDA wird unter Berücksichtigung fol-gender Thesen bewertet:

These T2a. Der Einsatz von SDA steigert die Effizienz der Testdatengenerie-rungsvorgänge insgesamt.

These T2b. Der zeitliche Aufwand von SDA ist geringer als der Zeitgewinn,den der Einsatz von SDA für die Testdatengenerierungsvorgänge insgesamtbewirkt.

These T2c. Der durch Testdatensuchen erzielte Überdeckungsgrad ist bei Ein-satz von SDA mindestens genauso hoch wie ohne diesen.

Die dritte statische Voranalyse CGSeq wird anhand folgender Thesenevaluiert:

192 fallstudien

These T3a. Der Einsatz von CGSeq steigert die Effizienz der Testdatengenerie-rungsvorgänge insgesamt.

These T3b. Der zeitliche Aufwand von CGSeq ist geringer als der Zeitgewinn,den der Einsatz von CGSeq für die Testdatengenerierungsvorgänge insgesamtbewirkt.

These T3c. Der durch Testdatensuchen erzielte Überdeckungsgrad ist bei Ein-satz von CGSeq mindestens genauso hoch wie ohne diesen.

These T3d*. Die Bildung einer Abarbeitungsreihenfolge der SGs durch CGSeqführt bei den Testdatensuchen zu einer höheren Kollateralüberdeckung oder einererhöhten Anzahl erfolgreich abgeschlossener Suchen.

These T3e*. Der Einsatz von CGSeq bewirkt, dass die durch Testdatensuchenerzeugte Testsuite weniger Testdaten enthält.

Da die drei statischen Voranalysen zum Teil untereinander auf ihreErgebnisse zurückgreifen, wird auch die Kombination aller drei Vorana-lysen betrachtet. Folgende Thesen werden in diesem Zusammenhanguntersucht:

These T4a. Der gemeinsame Einsatz von SIA, SDA und CGSeq bewirkt,im Vergleich zum Einsatz nur eines Teils dieser Techniken, eine zusätzlicheEffizienzsteigerung der Testdatengenerierungsvorgänge insgesamt.

These T4b. Der zeitliche Aufwand von SIA, SDA und CGSeq insgesamt istgeringer als der Zeitgewinn, den der Einsatz dieser Techniken für die Testdaten-generierungsvorgänge insgesamt bewirkt.

Die Generierung von Testdaten über den Hybrid aus (globaler) Testda-tensuche und symbolischer Ausführung wird über die folgenden Thesenbewertet:

These T5a. Die Kriterien-basierte Testdatengenerierung mittels Suche und sym-bolischer Ausführung steigert die Effizienz der Testdatengenerierungsvorgängeinsgesamt.

These T5b. Der durch den Hybrid aus Suche und symbolischer Ausführungerzielte Überdeckungsgrad ist mindestens genauso hoch wie der durch ausschließ-liche Suchen erreichte.

Das lokale Suchverfahren ASPO, welches in dieser Arbeit wohlgemerktnicht in die Bildung eines Hybrids aus Testdatengenerierungstechnikeneingeflossen ist, wird innerhalb der Fallstudien über folgende Thesebewertet:

These T6. Das lokale Suchverfahren ASPO ist für zumindest einen Teil derCGs in der Lage, die jeweils gesuchten Testdaten effizienter zu finden als dasglobale Suchverfahren LGA.


Je nachdem, in welchen Situationen und wie häufig ASPO dies gelingt,stellt sich die Frage, inwiefern eine solche lokale Suche innerhalb deshybriden Testdatengenerierungsverfahrens eine für deren Ergebnisseoder Effizienz gewinnbringende Rolle übernehmen könnte. Eine Untersu-chung dieser Fragestellung steht allerdings nicht im Fokus der Arbeit.

6.1.3 konfigurationen

Zur Untersuchung der einzelnen Thesen erfolgt eine Aufstellung ver-schiedener Konfigurationen des hybriden Testverfahrens. Jede dieserKonfigurationen wird verwendet, um strukturorientiert Testdaten fürdie Modelle A und B zu generieren. Hierbei werden Daten bezüglich be-stimmter Metriken und Kriterien gesammelt – wie im nächsten Abschnittbehandelt. Diese Daten werden durch Gegenüberstellungen verschiede-ner Konfigurationen verglichen, um Rückschlüsse auf die Gültigkeit dereinzelnen Thesen zu ziehen.

Die in den Fallstudien betrachteten Konfigurationen sind in Tabelle 14dargestellt. Die Konfiguration C1 stellt hierbei den Ansatz von Windischdar, das heißt C1 verwendet ausschließlich die globale Suche LGA zurTestdatengenerierung. C1 nutzt zudem keine der in dieser Arbeit einge-führten statischen Voranalysen. C2 bis C7 nutzen hingegen jeweils eineoder mehrere der in dieser Arbeit vorgestellten zusätzlichen Techniken.Vergleiche dieser Konfigurationen mit beispielsweise dem Zufallstestoder einem kommerziellen Werkzeug erfolgen in dieser Arbeit nicht.Windisch führte einen solchen Vergleich bereits in seiner Arbeit durch[132]. Da sein Ansatz dabei zu überlegenen Ergebnissen führte, müssen

Statische Voranalysen Generierung

Konfiguration SIA SDA CGSeq GS LS SMT

C1 - - - x - -C2 x - - x - -C3 x x - x - -C4 x - x x - -C5 x x x x - -C6 x x x x - xC7 x x x - x -

Tabelle 14: In den Fallstudien betrachtete Konfigurationen des hybridenTestdatengenerierungsverfahrens

194 fallstudien

sich die verschiedenen Konfigurationen des hier behandelten hybridenTestverfahrens nur mit der Konfiguration C1 messen.

Die Aufstellung der Konfigurationen ist in der in der Tabelle dargestelltenVollständigkeit nicht vorab erfolgt, sondern ist das Ergebnis schrittwei-ser Untersuchungen. So wurde beispielsweise zuerst die SIA-Technikevaluiert und hierfür C2 mit C1 verglichen. Da C2 hierbei bezüglich dererzielten Überdeckung und der Effizienz als Gewinner hervorging, wur-de in der Konfiguration C3, die der Evaluierung der SDA-Technik dient,auch die SIA-Technik aktiviert. C3 wurde dann mit C2 verglichen. Wäredie SIA-Technik in C3 nicht aktiviert, so hätte ein Vergleich mit C1 erfol-gen müssen – durch die Betrachtung unerreichbarer CGs hätte dies dieLaufzeit der Fallstudien allerdings unnötig ausgedehnt. Eine Ausnahmedieses schrittweisen Vorgehens bildet die Evaluierung von CGSeq. Dieseerfolgt über die Konfiguration C4. Hierbei wurde auf eine Aktivierungder SDA-Technik verzichtet, um unterscheiden zu können, wie stark dieAuswirkungen der beiden Techniken SDA und CGSeq jeweils sind. Einegemeinsame Aktivierung von SDA und CGSeq erfolgt stattdessen in C5zur Evaluierung aller statischen Voranalysen in Kombination.

Zusammenfassend stellt sich die Evaluierung der verschiedenen Beiträgedieser Arbeit anhand der zuvor definierten Thesen und über Vergleicheder Konfigurationen folgendermaßen dar:

Evaluierung der SIA-Technik. Auswertung der Thesen T1a, T1b und T1cdurch Vergleich von C2 mit C1

Evaluierung der SDA-Technik. Auswertung der Thesen T2a, T2b undT2c durch Vergleich von C3 mit C2

Evaluierung der CGSeq-Technik. Auswertung der Thesen T3a, T3b, T3c,T3d und T3e durch Vergleich von C4 mit C2

Evaluierung der Voranalysen-Kombination. Auswertung der ThesenT4a und T4b durch Vergleich von C5 mit C1/C2/C3/C4

Evaluierung des Hybrids aus LGA und SMT. Auswertung der ThesenT5a und T5b durch Vergleich von C6 mit C5

Evaluierung der lokalen Suche ASPO. Auswertung der These T6 durchVergleich von C7 mit C5

6.1.4 kriterien

Bei Ausführung der aufgestellten Konfigurationen des hybriden Testver-fahrens sind Daten zu sammeln, die eine Bewertung der aufgestelltenThesen zulassen. Die im Folgenden aufgeführten Metriken stellen hierbeidie wesentlichen Datenquellen dar.


Anzahl unerreichbarer CGs (D1). Die SIA-Technik, darauf aufbauendauch die CGSeq-Technik und zuletzt auch das SMT-Solving (siehe Ab-schnitt 4.2.6) sind in der Lage, unerreichbare CGs zu identifizieren. EinCG ϕ, welches unerreichbar ist, bekommt den Zustand st(ϕ)=UNSATzugewiesen. Die Metrik D1 gibt nach Abschluss des hybriden Testverfah-rens die Anzahl aller CGs mit diesem Zustand an.

Anzahl erreichter CGs (D2). All jenen CGs ϕ, für welche durch eineTestdatensuche oder SMT-Solving erfüllende Testdaten generiert werdenkonnten, wird der Zustand st(ϕ)= SAT zugewiesen. Die Metrik D2 gibtderen Anzahl an. Werden SIA und zusätzlich gegebenenfalls CGSeqeingesetzt, so enthält diese Anzahl auch die Anzahl der als stets erreichterkannten CGs. Auch wenn D2 als ein absolutes Maß nicht unterscheidet,welche der Techniken für den SAT-Zustand verantwortlich ist, wird dieAnzahl erreichter CGs in den Darstellungen der Ergebnisse zum Teilnach verantwortlicher Technik aufgeschlüsselt.

Laufzeit (D3). Während der Ausführungen der einzelnen Konfiguratio-nen werden verschiedene zeitliche Messungen vorgenommen. So wer-den die Laufzeiten von SIA (Metrik D3a), SDA (D3b) und CGSeq (D3c)gemessen – vorausgesetzt, die jeweilige Technik kommt zum Einsatz.Zudem werden die Laufzeiten aller bei Ausführung einer Konfigurationstattfindenden Testdatensuchen aufsummiert (D3d). Finden Testdaten-generierungen mittels SMT-Solving statt, so werden deren Laufzeitenebenfalls aufsummiert (D3e).

Anzahl betrachteter Testdaten (D4). Jegliche erzeugten Testdaten, ganzgleich ob durch den LGA, die ASPO oder SMT-Solving geschehen, wer-den durch diese Metrik erfasst.

Größe der Testsuite (D5). Ein Testdatum, welches während der Ausfüh-rung einer Konfiguration ein bislang unerreichtes CG erstmalig erreicht,wird in die resultierende Testsuite aufgenommen. Die Metrik D5 bezeich-net die Anzahl der Testdaten in dieser Testsuite.

Anzahl anvisierter SGs (D6). Die Testdatengenerierungstechniken LGA,ASPO und SMT-Solving arbeiten jeweils ein oder mehrere SGs ab. Diesgilt auch, wie in Abschnitt 5.2 erklärt, wenn die statische Voranalyse CG-Seq nicht zum Einsatz kommt. Da die CGs eines SG bei der Abarbeitungeines anderen SG unter Umständen erreicht werden (Kollateralüber-deckung), kann die Anzahl der bei Ausführung einer Konfigurationtatsächlich anvisierten und abgearbeiteten SGs variieren.

Erfolgsquote (D7). Der Versuch, mittels LGA, ASPO oder SMT-SolvingTestdaten zur Erfüllung aller CGs eines SG zu finden, kann erfolgreichoder erfolglos sein. Die Erfolgsquote bemisst prozentual, wie häufig derErfolgsfall eintritt. Die Metrik wird hierbei auf zweierlei Weise interpre-tiert – und zwar zum einen bezogen auf mehrere Anvisierungen einesbestimmten SG bei mehrfachen Ausführungen einer Konfiguration (D7a),

196 fallstudien

und zum anderen bezogen auf die Anvisierungen mehrerer verschiede-ner SGs innerhalb der Ausführung einer Konfiguration (D7b).

Tabelle 15 stellt dar, welche dieser Metriken in die Auswertung einerjeden der aufgestellten Thesen einfließen. Bei der Analyse der Ergebnissewerden diese Zusammenhänge aufgegriffen. Daher sei an dieser Stellenur ein Beispiel genannt: Die These T1a adressiert die erwartete Effi-zienzsteigerung der Testdatensuchen durch den Einsatz der statischenVoranalyse SIA (Konfiguration C2). Grundvoraussetzung einer höherenEffizienz ist, dass die Anzahl der erreichten CGs mindestens genausohoch ist wie ohne den Einsatz von SIA (C1). Des Weiteren setzt die Thesedie Existenz unerreichbarer CGs voraus. Daher werden die Anzahlenunerreichbarer und erreichter CGs benötigt (D1 und D2). Die Effizienzder Testdatensuchen wird in den Fallstudien durch deren aufsummierte

These D1 D2 D3a D3b D3c D3d D3e D4 D5 D6 D7a D7b

T1a x x - - - x - x - - - -

T1b - - x - - x - - - - - -

T1c x x - - - - - - - - - -

T2a - x - - - x - x - - - -

T2b - - - x - x - - - - - -

T2c x x - - - - - - - - - -

T3a - x - - - x - x - - - -

T3b - - - - x x - - - - - -

T3c x x - - - - - - - - - -

T3d - - - - - - - - - x - x

T3e - - - - - - - - x - - -

T4a - x - - - x - x - - - -

T4b - - x x x x - - - - - -

T5a - x - - - x x x - - - -

T5b x x - - - - - - - - - -

T6 - - - - - - - x - - x -

Tabelle 15: Relevanz der Metriken für die Auswertung der Thesen


Laufzeiten und, zur Absicherung der auf diesem Wege gewonnenen Er-kenntnisse, auch durch die Anzahl generierter Testdaten bewertet. Daherfließen zusätzlich die Metriken D3d und D4 in die Auswertung von TheseT1a ein.

6.1.5 einstellungen und randbedingungen

Die in den Fallstudien verwendeten Einstellungen der verwendetenSuchalgorithmen sowie weitere Randbedingungen, welche nicht bei derVorstellung der Thesen, Konfigurationen und Kriterien Erwähnung fan-den, sind Thema dieses Abschnitts.

grundlegendes

Wie zu Beginn dieses Kapitels bemerkt, wurde zur Durchführung derFallstudien das im Rahmen dieser Arbeit entstandene prototypischeWerkzeug TASMO verwendet. TASMO wurde für die Fallstudien mitzusätzlichen Möglichkeiten zur Protokollierung verschiedener Daten aus-gestattet. Hierdurch sammelt TASMO während der Durchführung seinerAufgaben vor allem für die zuvor aufgeführten Metriken relevante Daten.Die Protokollierung wirkt sich durch eine Erhöhung der Laufzeiten aufdie Messergebnisse der Fallstudien aus – bezogen auf die Gesamtlaufzei-ten ist der Einfluss hierbei allerdings so gering, dass er vernachlässigtwerden kann. Die Benutzeroberfläche von TASMO wurde bei Durchfüh-rung der Fallstudien nicht genutzt. Stattdessen wurden Skripte erstellt,welche die Abläufe vollständig automatisieren. Notwendige Nutzeranga-ben, wie die Angabe einer Modelleingangsspezifikation oder die Wahlder Überdeckungskriterien, wurden zuvor vorbereitet und durch dieSkripte gesteuert. Auf diesem Wege konnte der manuelle Aufwand beider Fallstudiendurchführung so gering wie möglich gehalten werden.

Der Rechner, mit dem die Studien durchgeführt wurden, verfügt übereinen Intel Core 2 Duo Prozessor (P8600, 2.4 GHz), 4 GB Arbeitsspeicherund das BetriebssystemWindows 7 (64-bit). Zur Ausführung des TASMO-Werkzeugs wurde das Java Runtime Environment in Version 7 genutzt.ML/SL lag in der Version 2009b und TL in der Version 3.1 vor.

Die Suchalgorithmen LGA und ASPO treffen in ihren Abläufen zumTeil zufällige Entscheidungen, sei es bei der Bildung initialer Testdatenoder, im Falle des LGA, bei der Kombination, Mutation und Selektionvon Testdaten. Um die Aussagekraft und die statistische Signifikanz derbei den Fallstudien gesammelten Daten zu stützen, werden daher alleKonfigurationen (C1 bis C7) mehrfach ausgeführt und für die Analyseder Ergebnisse jeweils das Mittel der gemessenen Werte gebildet. Inder Literatur zum Thema suchbasiertes Testen wird in der Regel eine

198 fallstudien

30-fache Wiederholung genutzt, um zufallsbedingte Ausschläge in denErgebnissen zu kompensieren. Dies wurde auch in den Fallstudien dervorliegenden Arbeit so gehandhabt. Die Resultate der Fallstudien weisenallerdings, so viel sei an dieser Stelle vorweggenommen, nur sehr geringeSchwankungen auf, so dass auch eine geringere Wiederholungszahlgenügt hätte.

lokale suche

Die Untersuchung des lokalen Suchverfahrens ASPO, welche wie dessenEntwicklung auch im Rahmen einer Masterarbeit [63] stattfand, unter-scheidet sich von den Untersuchungen der sonstigen Beiträge dieserArbeit. In den Konfigurationen C1 bis C6, welche der Evaluierung vonSIA, SDA, CGSeq, der Voranalysen-Kombination und des Hybrids ausLGA und SMT-Solving dienen, ist jeweils die Erfüllung aller für dieÜberdeckungskriterien CC und DC relevanten CGs das Ziel. Für dieEvaluierung von ASPO wurden hingegen 12 CGs ausgewählt, allesamtaus Modell A. Diese wurden durch Ausführung der Konfigurationen C5(LGA mit statischen Voranalysen) und C7 (ASPO mit statischen Vorana-lysen) jeweils einzeln anvisiert, ebenfalls 30-mal. Die Konfiguration C5kam also in zweierlei Form zur Anwendung.

Die Auswahl von 12 CGs dient der Fokussierung des Vergleichs zwischenlokaler und globaler Suche. Bei den Ausführungen der KonfigurationenC1 bis C6 zur Evaluierung der anderen Beiträge dieser Arbeit wurde näm-lich erkannt, dass die Testdatensuchen sich in der Regel nur mit einemkleinen Kreis an CGs wirklich auseinandersetzen müssen. Ein Großteilder CGs wird nämlich bereits durch die ersten, initial generierten Test-daten erreicht. Drei der bei Modell A als schwierig erreichbar erkanntenCGs fließen daher in die Menge der zur Analyse von ASPO betrachteten12 CGs ein. Zudem wurden nach folgenden Kriterien neun weitere CGsausgewählt: unterschiedliche Tiefe im Modell, Nicht-/VorhandenseinBoolescher Signale im CG-Ausdruck und eine unterschiedliche Anzahlrelevanter Modelleingänge. Auf die Charakteristika der einzelnen CGswird bei der Analyse der Ergebnisse eingegangen.

Für die der Evaluierung von ASPO dienenden Ausführungen der Konfi-gurationen C5 und C7 gelten darüber hinaus folgende Einstellungen. DieBelegungen der Parameter des LGA entsprechen zum Großteil den in derArbeit von Windisch gewählten Belegungen (siehe Tabelle 10 auf Seite161 seiner Arbeit [132]). Folgende Ausnahmen gelten: Die Populationbesteht in jeder Iteration des LGA aus 20 Individuen (Testdaten). DieAnzahl der Iterationen ist zudem auf maximal 200 Iterationen begrenzt.Da der LGA unter diesen Randbedingungen insgesamt maximal 4000Testdaten erzeugen kann, wird die Erzeugung des 4000. Testdatums auchfür die ASPO als zusätzliches Abbruchkriterium verwendet. In der Mo-delleingangsspezifikation wird sowohl für den LGA als auch für ASPO

6.2 ergebnisse 199

festgelegt, dass die zu erzeugenden Optimierungssequenzen zwischen 4und 50 Segmente enthalten dürfen. Die genaue Anzahl wird bei der initia-len Erzeugung von Testdaten jeweils zufallsbasiert bestimmt. Währendder LGA die Segmentanzahl während seiner Suche allerdings variierenkann, ändert sich diese bei ASPO nicht (siehe Abschnitt 4.1.3).

globale suche

Für den LGA, welcher in den Konfigurationen C1 bis C6 zur Evaluierungvon SIA, SDA, CGSeq, der Voranalysen-Kombination und des Hybridsaus LGA und SMT-Solving eingesetzt wurde, gelten zum Großteil eben-falls die Einstellungen, die Windisch für seine Fallstudien wählte. DiePopulationsgröße wurde allerdings auch hier auf 20 Individuen gesetzt.Darüber hinaus wurden die (neben der Erfüllung des anvisierten SG)zusätzlichen Abbruchkriterien der Suche ein wenig strenger definiert. Ins-besondere im Fall von Konfiguration C1, bei der keinerlei unterstützendeTechniken zum Einsatz kommen, wären die Laufzeiten der Testdaten-suchen ansonsten zu lang ausgefallen, um die Fallstudien dieser Arbeitinsgesamt in angemessener Zeit durchführen zu können. Ein zusätzlichesAbbruchkriterium besteht daher im Erreichen der 40. Suchiteration. EineSuche wird zudem abgebrochen, wenn in acht aufeinanderfolgendenIterationen keine Verbesserung des bis dato besten Fitnesswerts auftritt.Diese Einschränkungen gelten wohlgemerkt nicht für die Ausführungenvon C5, welche der Evaluierung der lokalen Suche dienen.

6.2 ergebnisse

Bei den wie zuvor beschrieben durchgeführten Experimenten wurden fürdie genannten Kriterien Daten gesammelt. Diese werden im Folgendenpräsentiert. Über Vergleiche dieser Daten von verschiedenen Konfigura-tionen werden die Thesen anschließend beantwortet – und die einzelnenBeiträge dieser Arbeit somit bewertet.

6.2.1 messdaten

Die gesammelten Daten werden gruppiert nach verschiedenen Aspektenvorgestellt. Für die Ausführungen der Konfigurationen C1 bis C6, beidenen eine Betrachtung aller für die Überdeckungskriterien CC und DCrelevanten CGs stattfand, wird zunächst die erzielte Modellüberdeckungthematisiert (Metriken D1 und D2). Anschließend werden die verschiede-nen Laufzeiten sowie die Anzahl der betrachteten Testdaten behandelt

200 fallstudien

(D3 und D4). Die Ergebnisse für die restlichen Metriken (D5, D6 und D7)folgen danach. Zum Schluss werden die Ergebnisse der Ausführungenvon Konfiguration C5 und C7, welche dem Vergleich von globaler undlokaler Suche dienen, präsentiert (Metriken D4 und D7).

überdeckungsgrad

Zu Beginn sei der Überdeckungsgrad betrachtet, welchen die Konfigura-tionen C1 bis C6 erzielen. Die Diagramme in Abbildung 34b (für ModellA) und in Abbildung 34c (für Modell B) stellen diesen dar. Der Überde-ckungsgrad ergibt sich hierbei gemäß Definition 13 (siehe Seite 33) ausder Anzahl der erreichten CGs (D2) im Verhältnis zur CG-Gesamtanzahl,abzüglich der Anzahl der gegebenenfalls als unerreichbar identifiziertenCGs (D1). Es ist zu beachten, dass die dargestellten Werte gemittelt sind,und zwar über die jeweils 30 Durchläufe einer Konfiguration.

Modell A. Die Konfiguration C1 konnte für 556 der insgesamt 600 CGserfüllende Testdaten finden. Da C1 nicht in der Lage ist, unerreichbareCGs zu erkennen, ergibt sich ein Überdeckungsgrad von 92,6%. DieAktivierung der SIA-Technik in C2 führt dazu, dass in jedem der 30Durchläufe 33 unerreichbare und 69 stets erreichte CGs identifiziert wur-den. Über Testdatensuchen konnten neben den bereits als stets erreichtbekannten CGs weitere 487 CGs erfüllt werden. Der Überdeckungsgradvon C2 beträgt daher 98%. Die zusätzliche Aktivierung der SDA-Technikin C3 führte dazu, dass die Anzahl der CGs, für welche über Testda-tensuchen erfüllende Testdaten gefunden werden konnten, um einesgestiegen ist. Dies resultiert in einem Überdeckungsgrad von 98,2%. Beider Konfiguration C4, welche neben SIA die CGSeq-Technik, allerdingsnicht die SDA-Technik nutzt, beträgt der Überdeckungsgrad wie schonbei C2 daher auch nur 98%. Abgesehen davon, dass die CGSeq-Technikweitere 38 stets erreichte CGs identifizieren konnte und somit insgesamt107 stets erreichte CGs bekannt sind, konnte bei Konfiguration C4 keineweitere Auswirkung auf die erzielte Überdeckung festgestellt werden. InC5 waren alle statischen Voranalysen aktiv. Wie schon bei Aktivierungder SDA-Technik in C3 konnte auch C5 einen Überdeckungsgrad von98,2% erzielen. Dieser blieb auch in C6 unverändert. Es ist allerdingszu erkennen, dass mit 379 ein großer Teil der erreichten CGs durchüber SMT-Solving erzeugte Testdaten erfüllt wurden – Testdatensuchenüberdeckten weitere 71 CGs.

Modell B. Die Ergebnisse bezüglich des erzielten Überdeckungsgrads fal-len für Modell B recht ähnlich aus. Die Konfiguration C1 konnte 1055 voninsgesamt 1113 CGs überdecken (Überdeckungsgrad 94,7%). SIA identifi-zierte in C2 52 unerreichbare und 96 stets erreichte CGs. Die Testdatensu-chen überdeckten weitere 959 CGs, so dass der Überdeckungsgrad imFall von C2 99,4% beträgt. Der Einsatz der SDA-Technik in C3 hatte im

6.2 ergebnisse 201

(a) Legende

(b) Modell A

(c) Modell B

Abbildung 34: Effektivität der Konfigurationen C1 bis C6 im Vergleich(jeweils für die Modelle A und B): Dargestellt ist die Über-deckung der CGs (∅ 30 Durchläufe) sowie der sich hierausergebende Überdeckungsgrad.

202 fallstudien

Vergleich hierzu keine Auswirkung auf die erzielte Überdeckung. Konfi-guration C4 identifizierte durch den Einsatz der CGSeq-Technik 4 weiterestets erreichte und 6 weitere unerreichbare CGs. Damit blieben keineCGs übrig, welche nicht durch Testdatensuchen erfüllt werden konntenund es ergibt sich ein Überdeckungsgrad von 100%. Der Einsatz allerVoranalysen in C5 erzielte ebenfalls einen Überdeckungsgrad von 100%.Bei der hybriden Testdatengenerierung über Suche und SMT-Solving inKonfiguration C6 wurde ebenfalls eine vollständige Überdeckung dererreichbaren CGs erzielt. Auch bei Modell B war hierbei das gegenüberden Testdatensuchen priorisierte SMT-Solving für einen Großteil derCG-Erfüllungen verantwortlich (845 CGs gegenüber 110 CGs).

aufwand

Als nächstes werden die Ergebnisse der Konfigurationen C1 bis C6 bezüg-lich des Aufwands der Testdatengenerierung vorgestellt. Als wesentlichesMaß dient hierbei die Laufzeit. Diese ist als Summe der Metriken D3d(Laufzeit Testdatensuche) und D3e (Laufzeit symbolische Ausführungund SMT-Solving) in Abbildung 35 für die Modelle A und B dargestellt.Die in den Diagrammen enthaltenen Werte sind auch hier über die jeweils30 Durchläufe gemittelt.

(a) Modell A

(b) Modell B

Abbildung 35: Effizienz der Konfigurationen C1 bis C6 im Vergleich (je-weils für die Modelle A und B): Laufzeit der Testdaten-generierung im Format Stunden:Minuten:Sekunden (∅ 30Durchläufe)

6.2 ergebnisse 203

Modell A. Die Testdatensuchen von Konfiguration C1 benötigen insge-samt rund 9 h und 25 min, um die aus den CGs gebildeten singulären SGsabzuarbeiten. Der Ausschluss unerreichbarer und stets erreichter CGs –beziehungsweise der jeweils entsprechenden SGs – durch den Einsatz derSIA-Technik bewirkt in C2, dass die Laufzeit der Testdatensuchen nurnoch rund 2 h und 8 min beträgt. In dieser Zeit nicht enthalten ist, dassSIA selbst im Schnitt rund 48 s benötigte (D3a). Die zusätzliche Aktivie-rung der SDA-Technik in C3 reduziert die Laufzeit der Testdatensuchenauf rund 1 h 59 min. SDA selbst benötigte nur circa eine Sekunde (D3b).Eine im Vergleich zum Einsatz von SDA etwas größere Reduzierungder Laufzeit bewirkt der Einsatz der CGSeq-Technik. In KonfigurationC4 dauern die Testdatensuchen nur noch rund 52 min. Der zeitlicheAufwand von CGSeq selbst fiel mit im Schnitt 15 s vergleichsweise geringaus (D3c). Bei Einsatz aller drei Voranalysen in Kombination kommen dieWechselwirkungen zwischen diesen Analysen zum Tragen. Im Falle vonC5 bewirkte dies eine weitere Reduzierung der Laufzeit auf rund 48 min.Die hybride Testdatengenerierung über Suche und SMT-Solving in C6dauerte im Vergleich hierzu sogar nur rund 36 min. Von dieser Laufzeitentfielen 56 s auf die symbolische Ausführung (inklusive SMT-Solving)und 35 min 32 s auf Testdatensuchen (D3d und D3e).

Modell B. Die Ergebnisse der Anwendung der Konfigurationen C1 bisC6 für Modell B fallen bezüglich der Aufwandseinsparungen ähnlich aus.Der Einsatz von SIA (Laufzeit 15 s, D3a) verringert die Laufzeit von über14 h (C1) auf 1 h 17 min (C2). Ist zusätzlich SDA (Laufzeit 1 s, D3b) aktiv,beträgt die Laufzeit nur noch 1 h 8 min (C3). Durch den Einsatz vonCGSeq (Laufzeit 20 s, D3c) sinkt die Laufzeit auf nur rund 16 min (C4)und bei Einsatz aller Voranalysen in Kombination beträgt diese sogar nurrund 11 min (C5). Wird zusätzlich noch das SMT-Solving verwendet (C6),erfolgt die gesamte Testdatengenerierung in etwas weniger als 9 min. DerAnteil von symbolischer Ausführung und SMT-Solving beträgt hierbei 1min 12 s (D3d) – die Testdatensuchen dauern 7 min 36 s (D3e).

Um die anhand der Laufzeiten hinsichtlich des Aufwands gemachtenBeobachtungen zu untermauern, wurde zusätzlich ausgewertet, wie vieleTestdaten von den Konfigurationen jeweils generiert und betrachtet wur-den (Metrik D4). Die hierbei protokollierten Anzahlen bestätigen im Fallebeider Modelle die anhand der Laufzeiten gemachten Beobachtungen.Auf eine zusätzliche Auflistung oder Darstellung wird daher an dieserStelle verzichtet.

suchziele, erfolgsquote und testsuite

Um weitere Aspekte der CGSeq-Technik und auch der automatisiertenTestdatengenerierung insgesamt bewerten zu können, wurden eine Rei-he weiterer Messungen vorgenommen. So wurde bei Ausführung dereinzelnen Konfigurationen festgehalten, wie viele Suchziele überhaupt

204 fallstudien

durch Testdatensuchen oder SMT-Solving anvisiert wurden (D6). Zudemwurde protokolliert, in wie vielen Fällen eine solche Anvisierung pro-zentual gesehen erfolgreich, das heißt mit der Erfüllung des jeweiligenSG, endet (D7b). Außerdem wurde registriert, wie umfangreich die er-zeugten Testsuiten sind (D5). Die Ergebnisse dieser drei Messungen beiAusführung der Konfigurationen C1 bis C6 sind in den Abbildungen36, 37 und 38, jeweils für Modell A und B, dargestellt. Nachfolgendwerden die in den Diagrammen enthaltenen Werte, welche über die je 30Konfigurationsausführungen gemittelt sind, erläutert.

Suchziele. Im Fall von Modell A waren bei Konfiguration C1 im Schnittcirca 45 SGs Gegenstand von Testdatensuchen. Durch den Ausschlussunerreichbarer SGs mittels SIA wurden in C2 nur rund 14 SGs anvisiert.Bei Nutzung der SDA-Technik (C3) waren es nur unwesentlich weniger.Die Verwendung von CGSeq in C4 und C5 führte allerdings zu einermerklichen Verringerung dieser Anzahl auf rund 10 SGs. Da in C6 SGs,welche SMT-Solving-geeignet sind, gegenüber SGs mit einer potenzi-ell hohen Kollateralüberdeckung priorisiert werden, liegt die Anzahlanvisierter SGs mit rund 15 wieder etwas höher. Mit einer Ausnahmesind alle diese Beobachtungen auch im Fall von Modell B auszumachen.Die Ausnahme: Die Nutzung von CGSeq (beispielsweise in C4) führtbei Modell B zu einer höheren Anzahl anvisierter SGs. Die Analyse derErgebnisse im nächsten Abschnitt erörtert, warum.

Erfolgsquote. Die Quote der anvisierten SGs, für welche mit Erfolg erfül-lende Testdaten gefunden werden konnten, erhöht sich erwartungsgemäß,wenn unerreichbare SGs zuvor aussortiert werden. Im Fall von Modell Asteigt die Erfolgsquote hierdurch von rund 3,9% (C1) auf rund 16,8% (C2),im Fall von Modell B von rund 3,1% auf rund 25%. Die Fokussierungder Testdatensuchen auf relevante Modelleingänge mittels SDA lässtdie Erfolgsquoten in C3 auf rund 20,5% (Modell A) und rund 32,1%(Modell B) ansteigen. Die Vorsortierung der SGs durch CGSeq bewirktein den Fallstudien eine deutliche Erhöhung der Erfolgsquoten. Bei C4betrug diese rund 70,2% für Modell A und circa 98% für Modell B. Diegemeinsame Nutzung aller drei Voranalysen (C5) sowie die partielle Test-datengenerierung mittels SMT-Solving (C6) erhöhte diese Erfolgsquotenin den Fallstudien nochmals geringfügig.

Testsuite. Die Größe der Testsuite sank in den Fallstudien bei Einsatz derCGSeq-Technik (C4 und C5), allerdings nur marginal. Im Fall von ModellA enthalten die durch die Konfigurationen C1 bis C3 – also diejenigenKonfigurationen, die CGSeq nicht einsetzen – erzeugten Testsuiten mitim Schnitt an die 7 Testdaten. Bei den Konfigurationen C4 und C5 enthal-ten die Testsuiten im Schnitt nur ein Testdatum weniger. Auffälliger istim Vergleich hierzu, dass der Einsatz des SMT-Solving, beziehungsweisedie Art des Einsatzes, in den Fallstudien zu einer recht deutlichen Ver-größerung der Testsuiten führte (C6). Für Modell A enthält eine Testsuite,

6.2 ergebnisse 205

(a) Modell A

(b) Modell B

Abbildung 36: Anzahl der durch die Konfigurationen C1 bis C6 anvi-sierten SGs im Vergleich (∅ 30 Durchläufe, jeweils für dieModelle A und B)

(a) Modell A

(b) Modell B

Abbildung 37: Erfolgsquote der Konfigurationen C1 bis C6 für die anvi-sierten Suchziele im Vergleich (∅ 30 Durchläufe, jeweilsfür die Modelle A und B)

206 fallstudien

(a) Modell A

(b) Modell B

Abbildung 38: Größe der durch die Konfigurationen C1 bis C6 erzeugtenTestsuiten im Vergleich (∅ 30 Durchläufe, jeweils für dieModelle A und B)

die aus einer Ausführung von Konfiguration C6 hervorgegangen ist, imSchnitt 10-11 Testdaten. Alle diese Beobachtungen wurden auch bei Mo-dell B gemacht. Die Verringerung der Testsuite-Größe bei Verwendungvon CGSeq fällt hier allerdings noch geringer aus.

lokale suche

Zur Evaluierung der lokalen Suche (LS) wurden, wie im Zuge des Ver-suchsaufbaus beschrieben, 12 ausgewählte CGs aus Modell A jeweilseinzeln 30-mal mit der globalen Suche (GS), also dem LGA (C5), und30-mal mit der LS (ASPO, C7) anvisiert. Hierbei wurde gemessen, in wievielen der 30 Durchläufe jeweils erfüllende Testdaten gefunden werdenkonnten. Diese Erfolgsquote (D7a) je CG und Suchverfahren ist in Ab-bildung 39 dargestellt. Für 11 der 12 betrachteten CGs konnten beideSuchverfahren in mindestens einem der je 30 Durchläufe ein erfüllendesTestdatum finden. Bei CG 1 bis 9 war die GS stets erfolgreich, im Fall vonCG 11 zudem in 93% der Fälle. Die LS konnte nur für 3 der 12 CGs (CG1 bis 3) in jedem Durchlauf erfüllende Testdaten finden – im Falle einesweiteren CG war die LS zumindest bei 67% der Durchläufe erfolgreich(CG 5). Nur im Fall eines einzigen CG, nämlich CG 10, konnten beideSuchverfahren in keinem Durchlauf passende Testdaten finden.

Zum Vergleich des Aufwands beider Verfahren wird die Anzahl der beieiner Suche betrachteten Testdaten (D4) herangezogen. Diese ist für die

6.2 ergebnisse 207

Abbil

dung

39

:Vergleich

der

loka

len

Such

e(K

onfigu

ration

C7)

mit

der

glob

alen

Such

e(K

onfigu

ration

C5)

bezü

glich

ihrer

Effektivität

anha

ndau

sgew

ählter

CGs:Wie

häufi

gwurde

jede

sCG

in30

Durch

läufen

erreicht?

208 fallstudien

Abbil

dung

40

:Ve

rgleichde

rloka

lenSu

che(K

onfig

urationC

7)mitde

rglob

alen

Such

e(K

onfig

urationC

5)be

züglichihrerEffiz

ienz

anha

ndau

sgew

ählte

rCGs:Wie

vieleTestda

tenwurde

nbe

ieiner

Such

efüreinCG

(∅30

Durch

läufe)

untersuc

ht?

6.2 ergebnisse 209

12 CGs und beide Suchverfahren in Abbildung 40 veranschaulicht. Diedort dargestellten Werte sind ebenfalls über die jeweils 30 Durchläufegemittelt. Für zwei der drei CGs, welche sowohl die LS als auch dieGS in jedem der Durchläufe erreichte (CG 1 bis 3), konnte die LS mitgeringerem Aufwand passende Testdaten finden (CG 1 und 2). Im Falleder CGs 4 bis 9, welche die GS stets und die LS vereinzelt erfüllen konnte,betrachtete die GS stets weniger Testdaten als die LS. Bei CG 10 warenLS und GS beide in allen 30 Durchläufen erfolglos. Die GS stieß daheran ihr Abbruchkriterium von 4000 generierten Testdaten. Die LS endetebereits nach 405 betrachteten Testdaten, da einzelne Modifikationenaller Testdatenparameter zu keinem besseren Testdatum mehr führten(siehe Abschnitt 4.1.3). Dieses Abbruchkriterium ist auch für die relativgeringe Anzahl betrachteter Testdaten im Falle der Anwendung der LSfür CG 11 und 12 verantwortlich. Im Falle dieser beiden CGs war dieLS auch eher selten erfolgreich. Die GS war bei CG 11 und 12 häufigererfolgreich, die Suchvorgänge waren jedoch mit einem relativ hohenAufwand verbunden.

6.2.2 analyse der statischen voranalysen

Die Ergebnisse werden im Folgenden vertiefend betrachtet und analy-siert, vor allem hinsichtlich der aufgestellten Thesen. Dieser Abschnittbehandelt hierbei die statischen Voranalysen SIA, SDA und CGSeq.

6.2.2.1 Analyse der Überdeckungsziel-Erreichbarkeitsprüfung

These T1a. Existieren in einem Modell unerreichbare CGs, so steigert derEinsatz von SIA die Effizienz der Testdatengenerierungsvorgänge insgesamt.

In den zwei verwendeten Modellen existieren unerreichbare CGs (Me-trik D1). Dies wurde durch SIA festgestellt und im Anschluss an dieFallstudien zur Bestätigung durch eine manuelle Analyse der Modellenachvollzogen. Die Anzahl erreichter CGs (D2) ist in den Fallbeispielenbei Nutzung von SIA genauso hoch wie ohne SIA. Die Effektivität dergesamten Testdatengenerierung wurde durch SIA also nicht negativ be-einflusst. Der Aufwand der Testdatensuchen war durch den Ausschlussunerreichbarer und stets erreichter CGs allerdings deutlich geringer. BeiModell A verringerte SIA die Laufzeit (D3d) um 77% und bei Modell Bsogar um 91%. Die Fallbeispiele untermauern somit die Gültigkeit derThese.

These T1b. Der zeitliche Aufwand von SIA ist geringer als der Zeitgewinn,den der Einsatz von SIA für die Testdatengenerierungsvorgänge insgesamtbewirkt.

210 fallstudien

Bei Modell A betrug die Laufzeit von SIA (D3a) 48 s, bei Modell Blediglich 15 s. Die durch den Einsatz von SIA eingesparte Laufzeit beiden Testdatensuchen beläuft sich hingegen auf über 7 h (Modell A)beziehungsweise auf über 13 h (Modell B). Diese Zeitgewinne ergebensich durch Subtraktion der Messungen für die Metrik D3d aus denKonfigurationen C1 und C2. Im Fall beider Modelle war die Laufzeitvon SIA, verglichen mit dem für die Suchen bewirkten Zeitgewinn,verschwindend gering.

These T1c. Der durch Testdatensuchen erzielte Überdeckungsgrad ist bei Ein-satz von SIA mindestens genauso hoch wie ohne diesen.

Ohne Einsatz von SIA (C1) erzielt die Testdatensuche einen Überde-ckungsgrad von 92,6% (Modell A) beziehungsweise 94,7% (Modell B).Mit SIA (C2) beträgt er 98% beziehungsweise 99,4%. Es wurden aller-dings keine zusätzlichen CGs erreicht (D2) – die Steigerung ergibt sichaus dem Ausschluss der identifizierten unerreichbaren CGs (D1) bei derBerechnung des Überdeckungsgrads. Würden diese nicht herausgerech-net werden, wären die Überdeckungsgrade von C1 und C2 im Fall beiderModelle identisch. Dies erfüllt allerdings ebenso die aufgestellte These.

Ergänzendes. Für Modell B konnten durch SIA und ergänzend durchCGSeq alle unerreichbaren CGs identifiziert werden. Im Fall von ModellA blieben bei allen Konfigurationen mindestens 10 CGs unerreicht. ImAnschluss an die Durchführung der Fallstudien wurde daher untersucht,warum für diese CGs keine Testdaten gefunden werden konnten. Esstellte sich heraus, dass 8 der 10 unerreichten CGs unerreichbar sind.Diese wurden durch SIA jedoch nicht erkannt, da die Block-spezifischenWertebereichsberechnungen von SIA innerhalb von TASMO nicht für allein Modell A vorkommenden Blocktypen implementiert wurden – bei-spielsweise für Lookup-Table-Blöcke. Bei einer spezifischen Unterstützungaller relevanten Blocktypen hätte SIA also 8 weitere unerreichbare CGserkannt und die Laufzeit der Testdatengenerierungsvorgänge wäre somitnochmals deutlich geringer ausgefallen.

6.2.2.2 Analyse der Modelleingang-Abhängigkeitsermittlung

These T2a. Der Einsatz von SDA steigert die Effizienz der Testdatengenerie-rungsvorgänge insgesamt.

Die Anzahl erreichter CGs (D2) ist bei Nutzung von SDA im Fall vonModell B genauso hoch wie ohne SDA (Vergleich C3 mit C2) und im Fallvon Modell A sogar um im Schnitt rund ein CG höher. Die Effektivitätder Testdatengenerierung nimmt durch die Einführung der SDA-Technikalso nicht ab, sondern kann durch sie unter Umständen gesteigert wer-den. Durch die Unterstützung der Suchen über eine Fokussierung auf

6.2 ergebnisse 211

relevante Modelleingänge reduziert sich zudem die Laufzeit der Testda-tensuchen (D3d) – wie auch die Anzahl der betrachteten Testdaten (D4) –geringfügig. Für Modell A reduzierte sich die Laufzeit um 7% und fürModell B um 12%. Die effizienzsteigernde Wirkung der SDA-Technikkonnten die Fallstudien demnach bestätigen.

These T2b. Der zeitliche Aufwand von SDA ist geringer als der Zeitgewinn,den der Einsatz von SDA für die Testdatengenerierungsvorgänge insgesamtbewirkt.

Die Ausführung der SDA-Technik dauerte bei beiden Modellen stetsrund eine Sekunde (D3b). Da durch SDA im Fall von Modell A im Schnittrund 8 min und im Fall von Modell B im Schnitt rund 9 min an Laufzeitfür die Testdatensuchen (D3d) eingespart werden konnte, deuten dieFallstudien auf die Gültigkeit dieser These hin.

These T2c. Der durch Testdatensuchen erzielte Überdeckungsgrad ist bei Ein-satz von SDA mindestens genauso hoch wie ohne diesen.

Während der Überdeckungsgrad ohne Einsatz von SDA (C2) für ModellA bei 98% lag, konnte er durch die Einbindung von SDA (C3) mit 98,2%geringfügig erhöht werden. Bei Modell B änderte sich der Überdeckungs-grad nicht, er blieb bei 99,4%. Für die betrachteten Fallbeispiele erweistsich diese These demnach als gültig.

Ergänzendes. Für alle CGs, welche durch SIA nicht als unerreichbar oderstets erreicht identifiziert wurden und die daher nicht vor Stattfindenvon SDA aussortiert werden, ermittelte SDA, dass im Schnitt 35% derEingänge von Modell A, beziehungsweise 41% der Eingänge von ModellB, zur CG-Erfüllung relevant sind. Beschränkt man die Menge der hierbeibetrachteten CGs auf diejenigen CGs, welche in Konfiguration C3 als Teileines SG auch tatsächlich anvisiert wurden, so handelt es sich um imSchnitt 54% (Modell A), beziehungsweise 75% (Modell B) relevante Ein-gänge. Diese Werte verdeutlichen, wie stark die durch die SDA-Technikerzielte Suchraumreduktion für Modelle aus der Praxis sein kann. DieAuswirkung des SDA-Einsatzes spiegelt sich im Übrigen auch in derErfolgsquote bezüglich der Erfüllung anvisierter SGs (D7) wieder. ImFalle der Aktivierung von SDA stieg in den Fallstudien beider Modelledie Erfolgsquote (Vergleich von C3 mit C2). Dies deutet darauf hin, dassdie Suchraumreduktion von SDA eine zielgerichtetere Suche zur Folgehaben kann. Durch die Belegung von irrelevanten Modelleingängen mitzufällig generierten Signalen scheint sich zudem die von den Suchvorgän-gen ausgehende Kollateralüberdeckung leicht zu erhöhen. Dies bedeutet,mehr SGs/CGs wurden bei der Anvisierung anderer SGs/CGs zufälligmit erreicht. Dies geht daraus hervor, dass im Falle beider Modelle in C3,im Vergleich zu C2, weniger SGs anvisiert werden mussten.

212 fallstudien

6.2.2.3 Analyse der Suchzielpriorisierung

These T3a. Der Einsatz von CGSeq steigert die Effizienz der Testdatengenerie-rungsvorgänge insgesamt.

Im Falle beider Modelle erreichten die Testdatensuchen nach Durchfüh-rung von CGSeq (C4) eine ebenso hohe Anzahl an CGs (D2) wie ohneeine vorherige Durchführung von CGSeq (C2). Die Nutzung von CGSeqwirkt sich also nicht negativ auf die Effektivität der Testdatengenerierungaus. Die Effizienz dieser steigt allerdings deutlich. Die Laufzeit der Test-datensuchen (D3d) in Konfiguration C4 verkürzte sich im Vergleich zuC2 um circa 1 h 15 min (Modell A), beziehungsweise circa 1 h (Modell B).Dies entspricht einer Reduktion der Laufzeit um 59%, beziehungsweise79%. Die höhere Laufzeitverringerung bei Modell B erklärt sich dadurch,dass die Erreichbarkeitsprüfung von CGSeq, welche SIA bezüglich derErkennung unerreichbarer sowie stets erreichter CGs ergänzt, für ModellB 6 weitere unerreichbare CGs erkannte. Es bleibt festzustellen, dass dieThese durch beide Fallbeispiele nachdrücklich gestützt wird.

These T3b. Der zeitliche Aufwand von CGSeq ist geringer als der Zeitgewinn,den der Einsatz von CGSeq für den gesamten Testdatengenerierungsvorgangbewirkt.

Den verkürzten Laufzeiten der Testdatensuchen (D3d) bei Nutzung vonCGSeq steht eine vergleichsweise geringe Ausführungsdauer von CGSeqselbst gegenüber (D3c). Während der Zeitgewinn, wie bei der Analyseder vorherigen These herausgestellt, bei beiden Modellen bei mindes-tens einer Stunde liegt, benötigt CGSeq vorab im Schnitt lediglich 16 s(Modell A) beziehungsweise 20 s (Modell B). Da sich der Aufwand vonCGSeq also in Grenzen hält, ist der Einsatz dieser Technik unter diesemGesichtspunkt nicht bedenklich.

These T3c. Der durch Testdatensuchen erzielte Überdeckungsgrad ist bei Ein-satz von CGSeq mindestens genauso hoch wie ohne diesen.

Die Aktivierung von CGSeq hatte keine Auswirkung auf die Anzahlerreichter CGs (D2), sowohl bei Modell A als auch bei Modell B. Wiezuvor festgestellt, erkannte CGSeq bei Modell B allerdings 6 weitereunerreichbare CGs (D1). Während der Überdeckungsgrad also bei ModellA unabhängig vom Einsatz der CGSeq-Technik gleichbleibend bei 98%liegt, steigert der Einsatz von CGSeq den Überdeckungsgrad für ModellB von 99,4% auf 100%. In beiden Fällen gilt jedoch die These.

These T3d. Die Bildung einer Abarbeitungsreihenfolge der SGs durch CGSeqführt bei den Testdatensuchen zu einer höheren Kollateralüberdeckung oder einererhöhten Anzahl erfolgreich abgeschlossener Suchen.

Die durch CGSeq durchgeführte Priorisierung der SGs erfolgt unterZuhilfenahme verschiedener Metriken. Diese adressieren sowohl die

6.2 ergebnisse 213

Schwierigkeit der Testdatengenerierung für ein SG als auch die Höhe derKollateralüberdeckung, welche das Erreichen eines SG mit sich bringt. Da-her war vom Einsatz von CGSeq in den Fallstudien eine Auswirkung auffolgende zwei Fallstudienmetriken zu erwarten: die Anzahl anvisierterSGs (D6) sowie die Erfolgsquote aller durchgeführten Testdatensuchen(D7). Werden leichter zu erreichende SGs den schwer zu erreichendenSGs vorgezogen, so sollte die Erfolgsquote steigen. Ist die Kollateralüber-deckung anvisierter SGs höher als diejenige von SGs, welche ohne einevorherige Durchführung von CGSeq durch Testdatensuchen anvisiertwerden, so sollten insgesamt weniger SGs überhaupt anvisiert werden.

Die Frage, welche dieser beiden Einflüsse bei der Suchzielpriorisierungstärker zum Tragen kommt, ist stark von der Beschaffenheit des betrach-teten Modells und der sich aus diesem ableitenden CGs abhängig. ImFall von Modell B existieren im Vergleich zu Modell A anteilig gese-hen deutlich mehr CGs, welche Bedingungen über Signale mit einemBooleschen Wertebereich beschreiben. Auch wenn vom Erreichen dieserunter Umständen eine hohe Kollateralüberdeckung zu erwarten ist, sostellt CGSeq die dazugehörigen SGs in der Abarbeitungsreihenfolge hin-ten an. Die zu erwartende Schwierigkeit des Erreichens eines SGs hatbei Modell B also, so ist zu vermuten, einen größeren Einfluss bei derReihenfolgenbildung als die abgeschätzte Kollateralüberdeckung.

Die Fallstudien bestätigen diese Vermutung. Sowohl bei Modell A alsauch bei Modell B steigt zwar die Erfolgsquote der Testdatensuchendeutlich – von circa 17% auf rund 70% (Modell A), beziehungsweise voncirca 25% auf rund 98% (Modell B) –, jedoch verringert sich die Anzahlanvisierter SGs nur bei Modell A. Während bei Modell A ohne Nutzungvon CGSeq (C2) im Schnitt 13,8 SGs anvisiert werden, sind es mit CGSeq(C4) durchschnittlich 10,6 SGs. Bei Modell B steigt dieser Wert hingegenvon 9,1 auf 13,6. Beide Fälle entsprechen der aufgestellten These undes wird deutlich, wie CGSeq bei der SG-Reihenfolgenbildung mehrereAspekte vereint – zum Vorteil der Effizienz der Testdatengenerierung.

These T3e. Der Einsatz von CGSeq bewirkt, dass die durch Testdatensuchenerzeugte Testsuite weniger Testdaten enthält.

Die Größe der für einen Strukturtest generierten Testsuiten ist in der Pra-xis von Relevanz, da meist kein Testorakel existiert, welches die funktio-nale Korrektheit des Testobjekts für die erzeugten Testdaten automatischprüft oder bewertet. Da dieser Umstand eine manuelle Durchsicht dergenerierten Testdaten notwendig macht, steht und fällt der Aufwand die-ses manuellen, der automatischen Testdatengenerierung nachgeordnetenVorgangs mit der Größe der Testsuite.

Sowohl bei Modell A als auch bei Modell B enthält die durch Konfigu-ration C4 erzeugte Testsuite weniger Testdaten als die von C2 erzeugte

214 fallstudien

Testsuite. Auch wenn die Unterschiede jeweils nicht sonderlich groß sind,stützen diese Ergebnisse die durch die These adressierte Annahme.

6.2.2.4 Analyse der Voranalysen-Kombination

These T4a. Der gemeinsame Einsatz von SIA, SDA und CGSeq bewirkt,im Vergleich zum Einsatz nur eines Teils dieser Techniken, eine zusätzlicheEffizienzsteigerung der Testdatengenerierungsvorgänge insgesamt.

In den Konfigurationen C2 (SIA), C3 (SIA und SDA) und C4 (SIA und CG-Seq) wurden die einzelnen Voranalyse-Techniken eingesetzt. Im Vergleichmit C1, wo keine der Voranalysen zum Einsatz kam, erzielte jede dieserdrei Konfigurationen eine Effizienzsteigerung - bei gleichbleibender oderverbesserter Effektivität. Da die drei Voranalyse-Techniken untereinan-der auf ihre Ergebnisse zurückgreifen (siehe Abschnitt 3.4), sofern dieseverfügbar sind, ist zu vermuten, dass die gemeinsame Nutzung aller dreiTechniken in Konfiguration C5 die effizienteste Konfiguration aus C1 bisC5 darstellt. Die Fallstudien bestätigen diese These. Sowohl bei ModellA als auch Modell B entsprechen die Anzahl der durch C5 erreichtenCGs (Metrik D2) und die Anzahl der identifizierten unerreichbaren CGs(D1) den diesbezüglich jeweils höchsten Werten aus C1 bis C4. Währenddie gemeinsame Nutzung von SIA, SDA und CGSeq keinen negativenEinfluss auf die Effektivität zeigt, reduziert sich die Laufzeit der durch-geführten Testdatensuchen (D3d) im Vergleich zur diesbezüglich zuvorbesten Konfiguration C4 geringfügig – und zwar bei beiden Modellenum rund 4 min.

These T4b. Der zeitliche Aufwand von SIA, SDA und CGSeq insgesamt istgeringer als der Zeitgewinn, den der Einsatz dieser Techniken für die Testdaten-generierungsvorgänge insgesamt bewirkt.

Insgesamt, das heißt bei gemeinsamer Nutzung (C5), reduzierten die Vor-analysen die Laufzeit der Testdatensuchen (D3d) im Vergleich zu C1 umüber 8 h (Modell A) beziehungsweise um über 14 h (Modell B). Rechnetman die Laufzeit der drei Analysen zusammen (D3a, D3b, D3c), so istderen Aufwand mit 1 min 5 s (Modell A) beziehungsweise 36 s (ModellB) zu bemessen. Gegenüber der erzielten Laufzeiteinsparung fällt dieserZusatzaufwand nicht ins Gewicht. Der höhere zeitliche Aufwand derAnalysen für Modell A gegenüber denen für Modell B ergibt sich im Übri-gen hauptsächlich aus der höheren Zahl von Schleifen (Rückkopplungen)in Modell A. Diese machen insbesondere die Wertebereichsanalyse durchSIA etwas aufwändiger.

6.2 ergebnisse 215

6.2.3 analyse des smt-solver-einsatzes

These T5a. Die Kriterien-basierte Testdatengenerierung mittels Suche und sym-bolischer Ausführung steigert die Effizienz der Testdatengenerierungsvorgängeinsgesamt.

In Konfiguration C6 wurden für ein anvisiertes SG bevorzugt Testdatenmittels symbolischer Ausführung und SMT-Solving erzeugt, sofern dieaufgestellten Einsatzkriterien dies zuließen. Andernfalls fand eine Suchedurch den LGA statt. Die von CGSeq bestimmte SG-Abarbeitungsreihen-folge zog zudem SMT-Solving-geeignete SGs nach vorne. Dieser Konfigu-ration stand die Konfiguration C5 gegenüber, bei der alle SG-Anvisierung-en mittels Testdatensuchen stattfanden. Insgesamt wurden durch C6 imSchnitt genauso viele CGs erreicht (Metrik D2) wie durch C5. Die Hy-bridisierung der Suche mit einer symbolischen Ausführung hatte imFalle beider Modelle also keine negativen Folgen für die Effektivität derTestdatengenerierungsvorgänge insgesamt. Die Laufzeit dieser (Summeaus D3d und D3e) konnte allerdings gesenkt werden. Bei Modell A fieldie Laufzeit im Schnitt um rund 12 min geringer aus und bei Modell Bum rund 3 min. Die Fallstudien stützen daher die These.

These T5b. Der durch den Hybrid aus Suche und symbolischer Ausführungerzielte Überdeckungsgrad ist mindestens genauso hoch wie der durch ausschließ-liche Suchen erreichte.

Wie erwähnt erreichte die Konfiguration C6 bei beiden Modellen, imVergleich zu C5, eine gleich hohe Anzahl von CGs (D2). Die Anzahl derjeweils durch SIA und CGSeq identifizierten CGs ist ebenfalls identisch.Daher ist auch der jeweils von C5 und C6 erzielte Überdeckungsgradgleich – 98,2% für Modell A und 100% für Modell B. Die Fallbeispielebestätigen die These somit.

Ergänzendes. Im Zuge der Präsentation der protokollierten Daten wurdedargelegt, dass die Testdatengenerierungen mittels symbolischer Aus-führung und SMT-Solving im Vergleich zu den Testdatensuchen nureinen geringen Anteil der gesamten Laufzeit bei C6 einnahmen. Hierzuergänzend sei erwähnt, dass im Fall von Modell A rund 37% der SG-Anvisierungen in C6 durch symbolische Ausführung und SMT-Solvingstattfanden – die übrigen circa 63% wurden mittels Testdatensuchenanvisiert. Bei Modell B waren es rund 42% durch symbolische Ausfüh-rung/SMT-Solving und circa 58% durch Testdatensuchen. Diese Zahlenliefern einen Eindruck, wie groß der Anteil der SGs ist, für welche dasSMT-Solving überhaupt eingesetzt wurde, und wie stark sich die SMT-Solving-Einsatzkriterien innerhalb dieser Hybridisierung auswirken.

Bei den Ausführungen der Konfiguration C6 fiel zudem auf, das sowohldie Anzahl der anvisierten SGs (D6) als auch die Größe der erzeugtenTestsuiten (D5) durch die Kombination der Suche mit dem SMT-Solving

216 fallstudien

höher ausfallen. Beide diese Begebenheiten sind Folge der PriorisierungSMT-Solving-geeigneter SGs in der Abarbeitungsreihenfolge. Das Kriteri-um der Kollateralüberdeckung eines SG rückt durch diese Priorisierungetwas weiter in den Hintergrund. Da die SMT-Solving-geeigneten SGsim Schnitt also eine geringere Kollateralüberdeckung auslösen, müssenmehr SGs anvisiert werden und im Erfolgsfall daher auch mehr Testdatenin die Testsuite aufgenommen werden. Um diesem Nebeneffekt entge-genzuwirken, könnten Techniken zur Testsuite-Minimierung helfen.

6.2.4 analyse des lokalen suchverfahrens

These T6. Das lokale Suchverfahren ASPO ist für zumindest einen Teil derCGs in der Lage, die jeweils gesuchten Testdaten effizienter zu finden als dasglobale Suchverfahren LGA.

Die Fähigkeiten und die Leistung des lokalen Suchverfahrens ASPO wur-de durch Ausführungen der Konfigurationen C6 (lokale Testdatensuchemit ASPO) und C5 (globale Testdatensuche mit LGA) für 12 ausgewählteCGs aus Modell A untersucht. Wie bei der Vorstellung der Ergebnissedargelegt, gab es hierbei drei CGs, welche sowohl von C5 als auch C6 injeder der 30 Ausführungen erfüllt werden konnten. Bei zwei dieser dreiCGs gelangte ASPO effizienter zu erfüllenden Testdaten als LGA – dielokale Suche betrachtete hierbei höchstens nur halb so viele Testdatenwie die globale Suche.

Ergänzendes. Betrachtet man die Charakteristik dieser drei CGs, so fälltauf, dass sich die an ihnen beteiligten Signale innerhalb von Modell Arelativ nah an den Eingängen befinden. Zudem hängt ihre Erfüllungjeweils auch nur von wenigen dieser Eingänge ab. Dies bedeutet, derSuchraum ist vergleichsweise klein und die Fitnesslandschaft weist wo-möglich wenige Eigenschaften auf, die für eine lokale Suche hinderlichsind – beispielsweise Plateaus oder lokale Optima.

Bei den übrigen neun der insgesamt 12 CGs konnte das lokale Such-verfahren ASPO nicht überzeugen. ASPO fand nur in wenigen Fällenerfüllende Testdaten und konnte, auf alle 30 Ausführungen bezogen,auch hinsichtlich der Effizienz den LGA nicht übertrumpfen. In den Ein-zelfällen, wo die lokale Suche mit Erfolg erfüllende Testdaten fand, wardie Anzahl der insgesamt betrachteten Testdaten jedoch oftmals geringer.Dies zeigt wohlgemerkt, dass die lokale Suche durch ihre systematischeVorgehensweise effizienter als eine globale Suche sein kann. Die neunangesprochen CGs sind tiefer innerhalb des Modells anzusiedeln alsdie drei zuvor behandelten CGs. Ihre Erfüllung ist zumeist auch vonmehr Modelleingängen abhängig. Die globale Suche war in den Fall-studien in der Lage, mit der größeren Komplexität der Suchräume undFitnesslandschaften dieser CGs umzugehen.

6.3 bewertung 217

Einzig bei drei dieser neun CGs schaffte es auch der LGA nicht im-mer, erfüllende Testdaten zu finden. Bei diesen für eine Testdatensucherecht herausfordernden CGs muss der lokalen Suche allerdings zugu-tegehalten werden, dass sie eine erfolglose Suche deutlich frühzeitigerbeendete als es die globale Suche tat. Grund hierfür ist das Vorgehenvon ASPO: Sobald die individuelle Änderung eines jeden Parameterszu keinem besseren Testdatum mehr führt, wird die Suche beendet. Dieglobale Suche geht an dieser Stelle weniger systematisch vor und kanntenur den Abbruch bei Erfolg oder bei Erreichen einer maximalen Zahlan Optimierungsiterationen. Würde allerdings zusätzlich das ansons-ten in den Fallstudien dieser Arbeit verwendete Abbruchkriterium derFitness-Stagnation Anwendung finden, so wäre auch diese Schwäche derglobalen Suche zumindest gelindert.

Eine weitergehende Analyse der Fallstudienergebnisse zeigte, dass nebender Suchraum- und Fitnesslandschaftskomplexität ein weiterer Faktordie Überlegenheit der globalen Suche begünstigte. Da die globale Suchegrundsätzlich mit einer Vielzahl initial generierter Testdaten startet, istdie Wahrscheinlichkeit im Vergleich zur lokalen Suche deutlich höher,dass das jeweils betrachtete CG bereits zufällig durch eines dieser Testda-ten erfüllt wird. Die lokale Suche hingegen startet mit nur einem initialenTestdatum. Erfüllt dieses das CG nicht, so bewegt sich die Suche mithohem Aufwand Stück für Stück durch den Suchraum, um – falls über-haupt möglich – zu einem erfüllenden Testdatum zu gelangen, welchesdie globale Suche möglicherweise schon in ihrer ersten Iteration findet.

6.3 bewertung

Das hybride Testverfahren, bestehend aus den statischen VoranalysenSIA, SDA und CGSeq, dem globalen Suchverfahren LGA und der symbo-lischen Ausführung über SMT-Solving, konnte die Gültigkeit der Arbeits-these in den durchgeführten Fallstudien unterstreichen. Diese lautet:

Die Effizienz des Ansatzes von Windisch zur suchbasierten Testdatengenerierungfür SL-Modelle lässt sich durch eine Hybridisierung derselben mit geeignetenstatischen oder dynamischen Techniken erhöhen.

Die Auswertung der einzelnen Thesen, welche für die Bausteine deshybriden Testverfahrens aufgestellt wurden, bestätigt diese Annahme. Sowirkt sich das Hinzufügen der zusätzlichen Techniken SIA, SDA, CGSeqund SMT-Solving zum Ansatz der suchbasierten Testdatengenerierungvon Windisch zum einen positiv auf den erreichten Überdeckungsgradauf. Zum Anderen sinkt der Aufwand der Testdatengenerierung imRahmen eines Strukturtests drastisch. Dies ließ sich in den Fallstudiennicht nur an den gemessenen Laufzeiten festmachen, sondern auch an der

218 fallstudien

Zahl der Testdaten, welche betrachtet werden mussten, um zu der letztenEndes gesuchten Testsuite zu gelangen: Ohne die zusätzlichen Techniken(Konfiguration C1) wurden im Schnitt 6094 (Modell A) und 8126 (ModellB) Testdaten auf dem Weg zu den in die Testsuiten aufgenommenenTestdaten „besucht“ – mit den Erweiterungen dieser Arbeit (C6) waren esim Schnitt nur 485 (Modell A) und 91 (Modell B) Testdaten. Die TechnikenSIA und CGSeq sorgten hierbei für die höchsten Effizienzsteigerungen.

Die Größe der erzeugten Testsuiten ist darüber hinaus als positiv zu be-werten. Teil eines Strukturtests ist es nämlich auch, die korrekte Funktio-nalität des Testobjekts für die aus ihm abgeleiteten Testdaten sicherzustel-len. Werden Testdaten automatisch erzeugt und existiert kein Testorakel,welches die Frage der korrekten Funktionalität automatisiert beantwor-tet, so muss das Testobjekt-Verhalten für die einzelnen Testdaten dergenerierten Testsuite manuell untersucht werden. Je kleiner die Testsuite,desto weniger aufwändig ist dies. Die von dem hybriden Testverfahren inden Fallstudien erzeugten Testsuiten sind von diesbezüglich praktikablerGröße. Dennoch sind Bemühungen hinsichtlich einer Minimierung derTestsuite-Größen und einer automatisierten Verwertung der generiertenTestdaten (Testorakel) natürlich wünschenswert.

Neben dem hybriden Testverfahren untersuchten die Fallstudien auchdie Eignung des im Rahmen dieser Arbeit geschaffenen lokalen Such-verfahrens ASPO zur Testdatengenerierung für SL/TL-Modelle. Auchwenn die Ergebnisse zeigen, dass das lokale Suchverfahren ASPO nichtgeeignet ist, um das globale Suchverfahren LGA in seiner Funktion inner-halb des in dieser Arbeit behandelten hybriden Testverfahrens abzulösen,so stellte sich dennoch (erwartungsgemäß) heraus, dass die Vorzügevon ASPO in Einzelfällen zum Tragen kommen. Es stellt sich daher dieFrage, wie und in welchen Situationen ASPO innerhalb einer Testdaten-suche eingesetzt werden könnte, um diese noch effizienter oder effektiverzu gestalten. Mischformen aus lokaler und globaler Suche, wie die inAbschnitt 2.4.1 behandelten memetischen Algorithmen, sind ein denkba-rer Ansatz. Derartige Überlegungen und Untersuchungen, ausgerichtetauf eine Testdatengenerierung für SL/TL-Modelle, könnten Gegenstandzukünftiger Arbeiten sein.

Abschließend stellt sich die Frage, wie allgemeingültig die Resultatedieser Fallstudien sind und welche Faktoren dies maßgeblich beeinflus-sen. Als Fallbeispiele dienten zwei SL/TL-Modelle aus der Automo-bilindustrie. Bei Verwendung anderer Modelle könnte beispielsweisedie Effizienzsteigerung deutlich geringer ausfallen, beispielsweise wennnur wenige oder keine unerreichbaren CGs existieren. Die zwei Model-le dieser Studien wurden jedoch bewusst aus zwei unterschiedlichenFahrzeugdomänen gewählt. Sie sind unterschiedlich groß und weisenverschiedene Charakteristiken auf. Daher sind sie durchaus als reprä-sentativ anzusehen. Natürlich wäre eine Bestätigung der gemachten

6.3 bewertung 219

Beobachtungen für Modelle aus anderen Industrien hilfreich. WeitereFaktoren, welche die Allgemeingültigkeit der Studien beeinflussen, sindder gewählte Anwendungsfall des Strukturtests sowie die gewähltenÜberdeckungskriterien. Die verwendeten Überdeckungskriterien sind inder Praxis weit verbreitet. Der Strukturtest stand im Fokus der Arbeit –Fallstudien zur Anwendung des hybriden Testverfahrens für beispiels-weise Funktionstests wären der nächste logische Schritt. Zuletzt ist daraufhinzuweisen, dass Fehler in der prototypischen Umsetzung des hybridenTestverfahrens nicht ausgeschlossen werden können. Die Wahrschein-lichkeit eines Fehlverhaltens wurde allerdings durch ausgiebige Testsminimiert. Die Fallstudienergebnisse (wie die Unerreichbarkeit von CGsund die durch eine Testsuite erzielte Modellüberdeckung) wurden zudemdurch manuelle Prüfungen nachvollzogen.

7 ZUSAMMENFASSUNGUND AUSBL ICK

Die modellbasierte Entwicklung der Software eingebetteter Systeme mit-tels SL und die automatische Codegenerierung mittels TL ist in derAutomobilindustrie weit verbreitet. Da TL-konforme SL-Modelle im Ent-wicklungsprozess in der Regel die ersten ausführbaren Artefakte darstel-len, ist die Qualitätssicherung und insbesondere der Test dieser Modelleim Sinne einer möglichst frühzeitigen Fehlerfindung besonders attraktiv.Aufgrund des steigenden Umfangs und der wachsenden Komplexitätvon Software in modernen Fahrzeugen bedarf es einer Systematisierungund Automatisierung der Testprozesse und Testaktivitäten.

Diese Arbeit adressiert in diesem Kontext die automatische Erzeugungvon Testdaten zum Test von SL/TL-Modellen. Der Fokus liegt hierbei aufdem Strukturtest, bei welchem Testdaten zur Überdeckung der Struktureines Modells hinsichtlich zustandsbezogener Kriterien gesucht sind.Die vorliegende Arbeit ist die Fortsetzung einer Vorarbeit von Windisch[132], welche die strukturorientierte Testdatengenerierung für SL-Modelledurch einen suchbasierten Ansatz realisierte. Die Anwendung dieses An-satzes zur automatischen Testdatengenerierung für komplexe Modelleaus der industriellen Praxis zeigte, dass dieser Ansatz im Vergleich mitdem Zufallstest und einem kommerziellen Werkzeug zu einer höherenModellüberdeckung führt. Die Laufzeit dieser Automatisierung fiel aller-dings, zu Lasten der Anwendbarkeit des Ansatzes in der industriellenPraxis, sehr hoch aus. Das bestehende Potenzial einer Laufzeitverringe-rung stellte die Hauptmotivation der vorliegenden Arbeit dar.

7.1 zusammenfassung

Die Grundidee dieser Arbeit besteht in der geeigneten Hybridisierungdes suchbasierten Ansatzes mit zusätzlichen Techniken. Mit dem Ziel,eine effiziente Testdatengenerierung zu ermöglichen, wurden fünf Tech-niken entwickelt. Hierbei handelt es sich einerseits um drei statischoperierende Analysetechniken, welche vor der Durchführung automa-tischer Testdatensuchen verschiedene Aufgaben übernehmen, um dieEffizienz des suchbasierten Ansatzes insgesamt zu steigern. Andererseitswird der suchbasierte Ansatz um eine Testdatengenerierung durch einesymbolische Ausführung, welche auf SMT-Solving zurückgreift, ergänzt.

221

222 zusammenfassung und ausblick

Hinzu kommt ein lokales Suchverfahren, welches allerdings nicht Teil desgebildeten Hybrids wurde. Zweck und Grundzüge dieser fünf Beiträgewerden im Folgenden zusammengefasst.

hybridisierung der suche mit voranalysen

Überdeckungsziel-Erreichbarkeitsprüfung. Die mit dem Kürzel SIA be-zeichnete Technik hat das Ziel, die Erreichbarkeit der zustandsbezoge-nen Ziele (Überdeckungsziele, CGs) innerhalb des zu testenden SL/TL-Modells zu prüfen. Unerreichbare CGs werden herausgefiltert, so dassder suchbasierte Ansatz nicht mit hohem Aufwand nach nicht auffindba-ren Testdaten fahndet. SIA führt zu diesem Zweck eine abstrakte Inter-pretation des SL/TL-Modells unter Verwendung einer eigens definiertenIntervallsemantik durch. Diese Interpretation berücksichtigt die zeitlicheDynamik von SL/TL-Modellen und führt Modelltransformationen durch,welche den anderen der in dieser Arbeit vorgestellten Techniken zugutekommen. Resultat dieser Analyse sind Wertebereichsangaben für dieSignale des zu testenden SL/TL-Modells. Aus diesen lässt sich ableiten,ob ein CG unerreichbar ist.

Modelleingang-Abhängigkeitsermittlung. Die mit der Abkürzung SDAvorgestellte Technik hat das Ziel, den bei einer Testdatensuche betrachte-ten Raum aller in Frage kommenden Testdaten (Suchraum) einzugren-zen und somit die Suche zu fokussieren. SDA analysiert unter Berück-sichtigung der Funktionalitäten der im Modell enthaltenen Blöcke dieAbhängigkeiten zwischen allen Signalen im Modell. Ein Abhängigkeits-verhältnis drückt dabei aus, dass sich die Wertebelegung innerhalb einesSignals auf Wertebelegungen in einem anderen Signal auswirken können.Die ermittelten Abhängigkeiten nutzt SDA, um Modelleingänge, dieirrelevant für das Erreichen eines CG sind, von einer Testdatensuche fürdieses CG auszuschließen. Die Suche kann sich somit auf das Findenpassender Testdaten für relevante Modelleingänge konzentrieren.

Suchzielpriorisierung. Bei einem Strukturtest sind in der Regel für eineVielzahl von CGs Testdaten zu finden. Der suchbasierte Ansatz beruhtdarauf, dass grundsätzlich für jedes CG eine Testdatensuche durchzu-führen ist. Bei einer Testdatensuche kann es vorkommen, dass andere alsdas betrachtete CG zufällig mit erreicht werden (Kollateralüberdeckung).Um die Effizienz der gesamten Automatisierung zu steigern, ist es zumeinen das Ziel der mit CGSeq abgekürzten Suchzielpriorisierung, dieKollateralüberdeckung der Testdatensuchen zu erhöhen. Zum anderenversucht CGSeq, Testdatensuchen für einfacher zu bearbeitende CGsvorzuziehen. CGSeq analysiert hierzu die Abhängigkeiten zwischen allenbetrachteten CGs. Die Abhängigkeiten geben unter anderem wieder, dassdie Erfüllung eines CG zur Erfüllung eines anderen CG führt. CGSeq

7.1 zusammenfassung 223

berücksichtigt hierbei auch Abhängigkeiten, die sich aus der Funktionali-tät des Modells ergeben. Basierend auf den ermittelten Abhängigkeitenüberführt CGSeq einzelne CGs oder Kombinationen von CGs in so-genannte SGs (Suchziele). Diese priorisiert CGSeq durch Anwendungverschiedener Metriken für die darauffolgenden Testdatensuchen.

hybridisierung der suche mit smt-solving

Eine im Unterschied zum suchbasierten Ansatz rein statisch operierendeTestdatengenerierungstechnik ist die symbolische Ausführung. Diesesammelt im Zuge einer symbolischen Ausführung Bedingungen, derenErfüllung die Erfüllung eines CG zur Folge haben. Aus der Lösung dieserBedingungen mit beispielsweise einem SMT-Solver lassen sich Testda-ten ableiten. Dieser Ansatz ist in vielen Fällen in der Lage, mit hoherGeschwindigkeit Testdaten zu generieren, weist aber in der Anwendungfür SL/TL-Modelle zweifelsohne Einschränkungen auf. Die vorliegendeArbeit erarbeitete daher einen Ansatz zur Testdatengenerierung mittelsSMT-Solving, welcher das SMT-Solving, bezogen auf ein einzelnes CGoder SG, nur dann einsetzt, wenn spezielle Einsatzkriterien zutreffen. An-dernfalls wird eine Testdatensuche durchgeführt. Der Ansatz ist zudemin der Lage, plausible, soll heißen realistische Testdaten zu erzeugen.

lokales suchverfahren

Die Vorarbeit von Windisch setzte zur Durchführung der Testdatensu-chen primär einen genetischen Algorithmus ein. Dieser gehört zur Klasseder globalen Suchen (GS). Daneben existiert die Klasse lokaler Suchen(LS). Verfahren zur LS suchen im Suchraum im Unterschied zu einer GSmeist nur an einer anstatt an mehreren Stellen gleichzeitig. Dem geringe-ren Grundaufwand und der äußerst systematischen sowie gründlichenVorgehensweise einer LS steht das Risiko entgegen, nicht in wichtigeBereiche des Suchraums gelangen zu können. Motiviert durch die schwie-rige Abwägbarkeit dieser Vor- und Nachteile untersuchte die vorliegendeArbeit, ob eine LS im betrachteten Anwendungskontext erfolgreich undeffizient Testdaten generieren kann. Hierzu wurde eine auf der AVMbasierende LS namens ASPO entwickelt. Diese ist ausgerichtet auf dieSuche plausibler Testdaten für SL/TL-Modelle.

validierung

Die in dieser Arbeit vorgestellten Techniken wurden prototypisch ineinem Werkzeug implementiert. Mit diesem Werkzeug wurden zur Eva-luierung der Beiträge dieser Arbeit Fallstudien durchgeführt. Zwei reale,aus der Automobilindustrie stammende SL/TL-Modelle dienten hierbeials Fallbeispiele. Es wurden verschiedene Konfigurationen des hybriden


Testverfahrens aufgestellt, in welchen die einzelnen Techniken dieserArbeit jeweils aktiviert oder deaktiviert waren. Auf diese Weise konntendie Auswirkungen der einzelnen Beiträge auf die strukturorientierteTestdatengenerierung gesondert analysiert und bewertet werden.

Die vier Techniken, welche in das hybride Testverfahren eingeflossensind – namentlich SDA, SIA, CGSeq und das SMT-Solving – konnten inden Fallstudien allesamt ihren Einsatz rechtfertigen. Durch den gemein-samen Einsatz all dieser Techniken in Kombination mit einer globalenTestdatensuche konnte die Laufzeit der Strukturtest-Automatisierungim Falle beider Modelle um über 90% reduziert werden. Die größtenAnteile an diesen Laufzeitverringerungen sind hierbei den statischenVoranalysen SIA und CGSeq zuzuschreiben. Die zusätzliche Laufzeitdurch Anwendung dieser Techniken war, gemessen an der erzielten Lauf-zeitverringerung, verschwindend gering. Darüber hinaus wirkte sich derEinsatz jeder zusätzlichen Technik nicht negativ auf die erzielte Modell-überdeckung aus. Ganz im Gegenteil: Die SDA-Technik schaffte es beieinem der Modelle sogar, die Überdeckung zu erhöhen.

Die Evaluierung des lokalen Suchverfahrens ASPO ergab zum einen, dassder Einsatz der globalen Suche für die Breite der Testdatengenerierungs-probleme, die sich durch die aus einem SL/TL-Modell abgeleiteten CGsstellen, erfolgversprechender ist. Im Falle mancher CGs konnte die LSallerdings mit geringerem Aufwand erfüllende Testdaten finden. Dahersteht die Überlegung im Raum, globale und lokale Suche in geeigneterWeise miteinander zu kombinieren. Dieser Schritt wurde allerdings imRahmen dieser Arbeit nicht gegangen.

Der entwickelte Werkzeug-Prototyp und die durchgeführten Fallstudi-en zeigen, dass die Hybridisierung des suchbasierten Ansatzes, wie indieser Arbeit realisiert, in einem Testdatengenerierungsverfahren fürSL/TL-Modelle mündet, welches sowohl praxistauglich als auch anwen-derfreundlich ist. Angewendet für einen Strukturtest stellte sich dabeiauch heraus, dass das hybride Testverfahren über seine Testdatengenerie-rung relativ kleine Testsuiten zusammenstellt, so dass deren manuelleWeiterverwendung zu funktionalen Tests auch ohne Vorhandensein einesautomatischen Testorakels praktikabel ist.

7.2 ausblick

Auch wenn die vorgestellte Arbeit im betrachteten Themengebiet deutli-che Fortschritte erzielen konnte, gibt es dennoch Anknüpfungspunkteund weitere Ideen, welche Grundlage zukünftiger Arbeiten sein könnten.Derlei Aspekte werden zum Abschluss dieser Arbeit in diesem Abschnittadressiert.

7.2 ausblick 225

weiterentwicklung der beiträge dieser arbeit

Bei der Ausarbeitung der fünf in dieser Arbeit vorgestellten Beiträgewurden an bestimmten Stellen Einschränkungen gemacht und Festle-gungen getroffen, um den Aufwand der Entwicklung dieser Technikeninsgesamt in einem durchführbaren Rahmen zu halten. Die Erarbeitungzusätzlicher Lösungen könnte die Qualität dieser Techniken steigern.

Zeitliche Dynamik. So berücksichtigen die Voranalysen SDA und CG-Seq bei Bildung ihrer Abhängigkeitsgraphen nicht die zeitliche Dynamikin einem SL/TL-Modell. Eine entsprechende Berücksichtigung erhöhtdie Komplexität der Analysen und ist daher nicht immer trivial zu lösen.Lässt sich dies jedoch bewerkstelligen, so können der Testdatensuchezum Beispiel Hinweise geliefert werden, zu welchen Zeitschritten oderZeitphasen eine passende Stimulation bestimmter Modelleingänge not-wendig ist, um ein SG zu erreichen (Erweiterung von SDA), oder welcheCGs in Kombination zu verschiedenen Zeitschritten zu erfüllen sind, umbestimmte andere CGs zu erreichen (Erweiterung von CGSeq).

Stateflow und iterative Subsysteme. Darüber hinaus wäre es sinnvoll,die statischen Techniken dieser Arbeit um spezielle Behandlungen fürSF-Blöcke zu erweitern. Diese Blöcke, welche ihre Funktionalität überZustandsdiagramme abbilden, werden von den Voranalysen und beider symbolischen Ausführung als unbekannte Blöcke aufgefasst. Zudemwurde in dieser Arbeit das SL-Konstrukt der Programmschleifen nichtbetrachtet. Über spezielle Blöcke lassen sich beispielsweise while-Schleifenbilden. Der Schleifenkörper befindet sich dabei innerhalb eines speziellenSubsystems und die dort enthaltenen Blöcke werden je nach Schleifenbe-dingung pro Zeitschritt gegebenenfalls mehrfach ausgeführt.

Testdaten-Bedingungen. Die vorgestellte Arbeit berücksichtigt zudemdie in der Arbeit von Windisch [132] vorgestellte Einbeziehung zusätzli-cher Testdaten-Bedingungen (siehe Abschnitt 2.4.2) nicht explizit. Wäh-rend sowohl globale als auch lokale Suche mit dem diesbezüglichenAnsatz von Windisch kompatibel sind, beachtet das SMT-Solving diezusätzlichen Bedingungen in dieser Arbeit nicht. Idealerweise solltenauch die Voranalysen SIA und CGSeq etwaige Testdaten-Bedingungenberücksichtigen.

Grenzen der symbolischen Ausführung. Der in dieser Arbeit verfolg-te Ansatz einer Testdatengenerierung durch SMT-Solving setzt auf ei-ne vorherige Prüfung von Einsatzkriterien. Da diese Kriterien unterUmständen eine Testdatengenerierung durch SMT-Solving für ein SGausschließen, obwohl diese durchführbar wäre, ist eine weitergehendeUntersuchung der Grenzen des SMT-Solving in dem betrachteten Kon-text ratsam. Insbesondere die Aufnahme von Modellfunktionalitätenmit zeitlicher Dynamik in das SMT-Solving könnte die Effizienz dergesamten Testdatengenerierung für ein Modell nochmals steigern.


Lokale Suche. Wie in der Zusammenfassung der Arbeit bereits ange-deutet, könnte die Intelligenz des suchbasierten Ansatzes darüber hin-aus durch eine geschickte Kombination von lokaler und globaler Sucheerhöht werden. Für das lokale Suchverfahren selbst existieren zudempotenzielle Verbesserungsmöglichkeiten, wie die Wiederaufnahme vonerfolglosen Suchen mit anderen initialen Testdaten oder die Generierungvon Optimierungssequenzen mit variabler Segmentanzahl.

weiterverwendung generierter testdaten

Das hybride Testverfahren dieser Arbeit automatisiert, wie in den Fall-studien demonstriert, das Auffinden von Testdaten für einen Strukturtest.Eingesetzt in einem praktischen Umfeld stellt sich jedoch die Frage,wie mit den erzeugten Testdaten umzugehen ist – denn zur Identifika-tion möglicher Fehler im Modell ist eine Überprüfung des Testobjekt-verhaltens bei Ausführung mit diesen Testdaten notwendig. Existierenbeispielsweise Auswertungsskripte aus funktionalen Tests, so wäre ei-ne Wiederverwendung dieser denkbar. Sind keine solchen Skripte oderanderweitige Testorakel verfügbar, wäre es hilfreich, zumindest eingren-zen zu können, welche Anforderungen aus der Spezifikation bei derÜberprüfung der Testdaten jeweils von Relevanz sind. Existieren (tran-sitive) Verlinkungen zwischen Anforderungen und Subsystemen (odersogar einzelnen Blöcken) in Modellen, so könnte ein Mapping zwischenden durch ein Testdatum überdeckten CGs und, über deren Zuordnunginnerhalb des Modells, den relevanten Anforderungen erfolgen. Da au-tomatisch generierte Testdaten meist funktionale Tests ergänzen, stelltsich zudem die Frage, ob die funktionalen Testfälle oder sogar die Spezi-fikation möglicherweise Lücken aufweisen. Eine automatische Analyseder Nähe automatisch generierter Testdaten zu den Testfällen vorherigerFunktionstests wäre daher wünschenswert.

wiederverwendung generierter testdaten

Unter zweierlei Gesichtspunkten könnten Überlegungen zur Wieder-verwendung automatisch generierter Testdaten angestellt werden. Zumeinen innerhalb der Testdatengenerierung für den Strukturtest eines Mo-dells und zum anderen bei Testdatengenerierungen für Strukturtestsverschiedener Modellversionen. Die Testdatensuchen, welche das hy-bride Testverfahren durchführt, starten initial mit einem Satz zufälliggenerierter Testdaten. Möglicherweise lassen sich Zusammenhänge inner-halb eines Modells oder zwischen CGs ausnutzen, um den Satz initialerTestdaten konstruktiver zu gestalten. Wird ein überarbeitetes oder ver-ändertes Modell zudem einem erneuten Strukturtest unterzogen, stelltsich die Frage, inwiefern zuvor generierte Testdaten wiederverwendbarsind.

7.2 ausblick 227

funktionstests

In Abschnitt 2.2 wurden verschiedene Szenarien und Testarten behandelt,in denen eine automatisierte Testdatengenerierung für SL/TL-Modellesinnvoll erscheint. Der Strukturtest wurde dabei als Repräsentant derverschiedenen Szenarien ausgewählt und bildete fortan den Fokus beider Ausgestaltung der Techniken dieser Arbeit – sowie in den Fallstu-dien. Es empfiehlt sich eine Evaluierung des entstandenen hybridenTestverfahrens in einem anderen Kontext, insbesondere zu Zwecken vonFunktionstests (siehe Abschnitt 2.2.2). In diesem Anwendungsfall wärezudem zu klären, ob und inwieweit die SL- und TL-Sprachmittel zur De-finition funktionaler Modelleigenschaften genügen – und welche neuen,speziellen Blocktypen gegebenenfalls ergänzend benötigt werden.

weitere ideen und ansätze

Beim Studium verwandter Arbeiten sowie der Gestaltung und Entwick-lung der Beiträge dieser Arbeit sind weitere Ideen und Überlegungenentstanden, welche an dieser Stelle nicht unerwähnt bleiben sollen.

Signallänge. Die Größe des Suchraums hängt neben der Anzahl rele-vanter Modelleingänge wesentlich von der Länge der zu generierendenSignale ab. Diese wird vom Anwender vorab spezifiziert. Eine statischeAnalyse des Modells könnte die zum Erreichen eines CG erforderlicheMindestlänge der Signale möglicherweise automatisch bestimmen.

Adaptive Abbruchkriterien. Wie im Zuge der Vorstellung der CGSeq-Technik betont, sind die bei einem Strukturtest auftretenden CGs übli-cherweise unterschiedlich einfach oder schwer durch eine Testdatensuchezu erfüllen. Je nach Schwierigkeitsgrad könnte man einer Testdatensucheeinen geringeren oder höheren Suchaufwand zugestehen. So könnte fürdie maximal erlaubte Anzahl an Optimierungsiterationen im Falle einesCG mit einer geringen Modelltiefe ein niedriger Wert gewählt werdenals für ein CG mit einer hohen Modelltiefe.

Gezielte Testdatenmodifikation. Die Fitness eines Testdatums bestimmtsich im betrachteten Kontext, wie in Abschnitt 2.4.2 dargestellt, aus ei-ner Sequenz von Distanzwerten - oder anders ausgedrückt: aus einemFitness-Signal. Zwischen Fitnessbestimmung und Testdatenmodifikationkommt es bei einer Testdatensuche zu einem Informationsverlust. DieInformation, bei welchem Zeitschritt das Fitness-Signal den geringstenDistanzwert aufweist, spielt nämlich bei den Änderungsoperatoren desLGA und auch der ASPO keine Rolle. Diesbezüglich gezieltere Testda-tenmodifikationen könnten die Suche beschleunigen.

Testdatenregionen. Verschiedene andere Arbeiten im Bereich der au-tomatisierten Testdatengenerierung [2, 70] beschäftigen sich mit derIdentifikation von Bereichen ähnlicher oder sogar redundanter Testdaten


im Suchraum. Eine Technik, welche bei der Testdatensuche für ein CGRegionen im Suchraum erkennt, welche hinsichtlich der CG-Erfüllungäquivalent sind, könnte dem Erfolg und der Effizienz einer Suche überauszuträglich sein.

Modelltransformationen. Bei der automatisierten Testdatengenerierungfür Programmcode werden Teile des Codes oder der abgeleitete Kon-trollflussgraph oftmals transformiert, um die Testdatengenerierung zuerleichtern. Bei solchen Transformationen handelt es sich in der Regelum semantikbewahrende Transformationen. Das hybride Testverfahrendieser Arbeit transformiert das zu testende Modell in dieser Hinsicht be-reits zum Teil. Allerdings wurde dieser Aspekt nur im Ansatz untersucht.Die Arbeit von Tran et al. [119], welche sich ausgiebig mit der Transfor-mation von SL-Modellen beschäftigt, könnte als Ausgangspunkt einersystematischen Betrachtung von Modelltransformationen zum Zweckeeiner verbesserten Testbarkeit dienen.

Werkzeug-Features. Neben derlei technischen Überlegungen sind imZuge dieser Arbeit auch Aspekte aufgekommen, welche die Akzep-tanz und Anwendbarkeit eines Testdatengenerierungswerkzeugs fürSL/TL-Modelle in der Praxis adressieren. Einer dieser Aspekte betrifftdie Existenz von individuellen Modellböcken, deren Funktionalität derModellierer durch Programmcode beschreibt. Auch dieser Programm-code könnte bei einem Strukturtest miteinbezogen und durch Code-Überdeckungskriterien adressiert werden. Des Weiteren sollten Tech-niken zur Testsuite-Minimierung zum Einsatz kommen, um nach derTestdatengenerierung eine möglichst kleine Testsuite ausgeben zu kön-nen. Das Werkzeug sollte zudem Überdeckungskriterien wie MC/DCunterstützen. In dieser Arbeit wurde dieses Kriterium nicht behandelt.Es existieren allerdings Arbeiten [8, 46], welche zeigen, dass mit einemsuchbasierten Ansatz auch dieses Kriterium behandelt werden kann. Zu-letzt sei darauf hingewiesen, dass aktuelle Versionen des SL-Werkzeugseine parallelisierte Ausführung von Modellsimulationen ermöglichen. Inder Version, welche im Rahmen dieser Arbeit genutzt wurde, ist diesnicht möglich. Eine Parallelisierung der Modellausführungen könnte dieLaufzeit des hybriden Testverfahrens nochmals deutlich reduzieren.

L I TERATURVERZE ICHN IS

[1] R. K. Ahuja, Özlem Ergun, J. B. Orlin und A. P. Punnen (2002).A survey of very large-scale neighborhood search techniques. DiscreteApplied Mathematics, 123(1–3), 75–102. ISSN 0166-218X. (Zitiertauf Seite 55.)

[2] R. Alur, A. Kanade, S. Ramesh und K. C. Shashidhar (2008). Sym-bolic Analysis for Improving Simulation Coverage of Simulink/StateflowModels. In Proceedings of the 8th ACM International Conferenceon Embedded software, Seiten 89–98. EMSOFT ’08, ACM, NewYork, NY, USA. ISBN 978-1-60558-468-3. (Zitiert auf Seite 227.)

[3] S. Anand, E. K. Burke, T. Y. Chen, J. Clark, M. B. Cohen, W. Gries-kamp, M. Harman, M. J. Harrold und P. McMinn (2013). AnOrchestrated Survey of Methodologies for Automated Software Test Ca-se Generation. Journal of Systems and Software, 86(8), 1978–2001.ISSN 0164-1212. (Zitiert auf den Seiten 40 und 41.)

[4] A. Arcuri und L. C. Briand (2011). Adaptive Random Testing: AnIllusion of Effectiveness. In M. B. Dwyer und F. Tip, Herausgeber,Proceedings of the 20th International Symposium on SoftwareTesting and Analysis, Seiten 265–275. ISBN 978-1-4503-0562-4.(Zitiert auf den Seiten 45 und 46.)

[5] A. Arcuri, M. Z. Iqbal und L. Briand (2010). Formal Analysis ofthe Effectiveness and Predictability of Random Testing. In Proceedingsof the 19th International Symposium on Software Testing andAnalysis, Seiten 219–230. ISSTA ’10, ACM. ISBN 978-1-60558-823-0.(Zitiert auf Seite 45.)

[6] A. Arcuri, M. Iqbal und L. Briand (2012). Random Testing: TheoreticalResults and Practical Implications. IEEE Transactions on SoftwareEngineering, 38(2), 258–277. ISSN 0098-5589. (Zitiert auf Seite 45.)

[7] M. Association (2014). Modelica. URL https://www.modelica.org.Letzter Zugriff: 05/2014. (Zitiert auf Seite 13.)

[8] Z. Awedikian, K. Ayari und G. Antoniol (2009). MC/DC automatictest input data generation. In Proceedings of the 11th Annual Confe-rence on Genetic and Evolutionary Computation, Seiten 1657–1664.GECCO ’09, ACM, New York, NY, USA. ISBN 978-1-60558-325-9.(Zitiert auf Seite 228.)

229

https://www.modelica.org

230 literaturverzeichnis

[9] M. Baluda, P. Braione, G. Denaro und M. Pezzè (2010). StructuralCoverage of Feasible Code. In Proceedings of the 5th Workshop onAutomation of Software Test, Seiten 59–66. AST ’10, ACM, NewYork, NY, USA. ISBN 978-1-60558-970-1. (Zitiert auf Seite 33.)

[10] A. Baresel, M. Conrad, S. Sadeghipour und J. Wegener (2003). TheInterplay between Model Coverage and Code Coverage. In ConferenceOn Computer Aided Systems Theory. (Zitiert auf den Seiten 30, 31und 37.)

[11] A. Baresel, H. Pohlheim und S. Sadeghipour (2003). Structural andfunctional sequence test of dynamic and state-based software withevolutionary algorithms. In E. Cantú-Paz, J. A. Foster, K. Deb, L. D.Davis, R. Roy, U.-M. O’Reilly, H.-G. Beyer, R. Standish, G. Kendall,S. Wilson, M. Harman, J. Wegener, D. Dasgupta, M. A. Potter, A. C.Schultz, K. A. Dowsland, N. Jonoska, und J. Miller, Herausgeber,Genetic and Evolutionary Computation — GECCO 2003, Band 2724von Lecture Notes in Computer Science, Seiten 2428–2441. SpringerBerlin Heidelberg. ISBN 978-3-540-40603-7. (Zitiert auf Seite 59.)

[12] M. Barr (2013). Toyota and Unintended Acceleration. URLhttp://embeddedgurus.com/barr-code/2013/10/an-update-on-toyota-and-unintended-acceleration. Letzter Zugriff: 05/2014.(Zitiert auf Seite 4.)

[13] C. Barrett, R. Sebastiani, S. A. Seshia und C. Tinelli (2009). Satis-fiability Modulo Theories, Kapitel 26, Seiten 825–885. Band 185 von[18]. (Zitiert auf Seite 163.)

[14] C. Barrett, A. Stump und C. Tinelli (2010). The SMT-LIB Standard:Version 2.0. In A. Gupta und D. Kroening, Herausgeber, Procee-dings of the 8th International Workshop on Satisfiability ModuloTheories. (Zitiert auf Seite 164.)

[15] C. Barrett, C. Conway, M. Deters, L. Hadarean, D. Jovanovi?,T. King, A. Reynolds und C. Tinelli (2011). Cvc4. In G. Gopalakris-hnan und S. Qadeer, Herausgeber, Computer Aided Verification,Band 6806 von Lecture Notes in Computer Science, Seiten 171–177.Springer Berlin Heidelberg. ISBN 978-3-642-22109-5. (Zitiert aufSeite 163.)

[16] C. Barrett, M. Deters, L. M. de Moura, A. Oliveras und A. Stump(2013). 6 Years of SMT-COMP. J. Autom. Reasoning, 50(3), 243–277.(Zitiert auf Seite 164.)

[17] K. Berns, B. Schürmann und M. Trapp (2010). Eingebettete Systeme- Systemgrundlagen und Entwicklung eingebetteter Software. View-eg+Teubner. ISBN 978-3-8348-0422-8. (Zitiert auf Seite 12.)

http://embeddedgurus.com/barr-code/2013/10/an-update-on-toyota-and-unintended-acceleration

http://embeddedgurus.com/barr-code/2013/10/an-update-on-toyota-and-unintended-acceleration

literaturverzeichnis 231

[18] A. Biere, M. J. H. Heule, H. van Maaren und T. Walsh, Herausgeber(2009). Handbook of Satisfiability, Band 185 von Frontiers in ArtificialIntelligence and Applications. IOS Press. ISBN 978-1-58603-929-5, 980Seiten. (Zitiert auf den Seiten 163 und 230.)

[19] N. Bjørner (2012). Taking satisfiability to the next level with z3. InB. Gramlich, D. Miller, und U. Sattler, Herausgeber, AutomatedReasoning, Band 7364 von Lecture Notes in Computer Science, Seiten1–8. Springer Berlin Heidelberg. ISBN 978-3-642-31364-6. (Zitiertauf Seite 163.)

[20] P. Boström und J. Björkqvist (2005). Optimisation-based black-boxtesting of assertions in Simulink models. Technischer Bericht 711,Åbo Akademi University. (Zitiert auf Seite 47.)

[21] A. Brillout, N. He, M. Mazzucchi, D. Kroening, M. Purandare,P. Rümmer und G. Weissenbacher (2010). Mutation-based testcase generation for simulink models. In F. Boer, M. Bonsangue,S. Hallerstede, und M. Leuschel, Herausgeber, Formal Methods forComponents and Objects, Band 6286 von Lecture Notes in ComputerScience, Seiten 208–227. Springer Berlin Heidelberg. ISBN 978-3-642-17070-6. (Zitiert auf Seite 43.)

[22] E. Bringmann und A. Krämer (2008). Model-Based Testing of Automo-tive Systems. In Proceedings of the 2008 International Conferenceon Software Testing, Verification, and Validation, Seiten 485–493.ICST ’08, IEEE Computer Society, Washington, DC, USA. ISBN978-0-7695-3127-4. (Zitiert auf Seite 12.)

[23] V. H. S. Campos, R. E. Rodrigues, I. R. de Assis Costa und F. M.Q. a. Pereira (2012). Speed and Precision in Range Analysis. In Procee-dings of the 16th Brazilian Conference on Programming Languages,Seiten 42–56. SBLP’12, Springer-Verlag, Berlin, Heidelberg. ISBN978-3-642-33181-7. (Zitiert auf Seite 94.)

[24] T. Y. Chen, F.-C. Kuo, R. G. Merkel und T. H. Tse (2010). AdaptiveRandom Testing: The ART of Test Case Diversity. Journal of Systemsand Software, 83(1), 60–66. ISSN 0164-1212. (Zitiert auf Seite 45.)

[25] A. Cimatti, A. Griggio, B. Schaafsma und R. Sebastiani (2013). TheMathSAT5 SMT Solver. In N. Piterman und S. Smolka, Herausgeber,Proceedings of TACAS, Band 7795 von LNCS. Springer. (Zitiert aufSeite 163.)

[26] D. Cok, A. Griggio, R. Bruttomesso und M. Deters (2013). The 2012SMT Competition. In P. Fontaine und A. Goel, Herausgeber, SMT2012, Band 20 von EPiC Series, Seiten 131–142. EasyChair. ISSN2040-557X. (Zitiert auf Seite 164.)


[27] D. R. Cok (2013). The SMT-LIBv2 Language and Tools: A Tuto-rial. Online. URL https://www.lri.fr/~conchon/TER/2013/2/SMTLIB2.pdf. Letzter Zugriff: 05/2014. (Zitiert auf Seite 164.)

[28] M. Conrad (2004). Modell-basierter Test eingebetteter Software imAutomobil: Auswahl und Beschreibung von Testszenarien. Dissertation,Technische Universität Berlin. (Zitiert auf Seite 29.)

[29] M. Conrad und S. Sadeghipour (2002). Einsatz von Überdeckungskri-terien auf Modellebene - Erfahrungsbericht und experimentelle Ergebnisse.Softwaretechnik-Trends, 22(2). (Zitiert auf Seite 34.)

[30] P. Cousot und R. Cousot (1976). Static Determination of DynamicProperties of Programs. In Proceedings of the Second InternationalSymposium on Programming, Seiten 106–130. (Zitiert auf denSeiten 71 und 93.)

[31] P. Cousot und R. Cousot (1977). Abstract Interpretation: A Uni-fied Lattice Model for Static Analysis of Programs by Construction orApproximation of Fixpoints. In Proceedings of the 4th ACM SIGACT-SIGPLAN Symposium on Principles of Programming Languages,Seiten 238–252. POPL ’77, ACM, New York, NY, USA. (Zitiert aufSeite 71.)

[32] P. Cousot, R. Cousot, J. Feret, L. Mauborgne, A. Miné, D. Monni-aux und X. Rival (2005). The ASTRÉE analyzer. In ProgrammingLanguages and Systems, Proceedings of the 14th European Sympo-sium on Programming, volume 3444 of Lecture Notes in ComputerScience, Seiten 21–30. Springer. (Zitiert auf Seite 94.)

[33] L. De Moura und N. Bjørner (2008). Z3: An Efficient SMT Solver. InProceedings of the Theory and Practice of Software, 14th Interna-tional Conference on Tools and Algorithms for the Constructionand Analysis of Systems, Seiten 337–340. TACAS’08/ETAPS’08,Springer-Verlag, Berlin, Heidelberg. ISBN 3-540-78799-2, 978-3-540-78799-0. (Zitiert auf Seite 163.)

[34] L. De Moura und N. Bjørner (2011). Satisfiability Modulo Theories:Introduction and Applications. Commun. ACM, 54(9), 69–77. ISSN0001-0782. (Zitiert auf Seite 162.)

[35] D. do Couto Teixeira und F. M. Q. Pereira (2011). The Designand Implementation of a Non-Iterative Range Analysis Algorithm on aProduction Compiler. SBLP. SBC, Seiten 45–59. (Zitiert auf Seite 94.)

[36] dSpace (2014). TargetLink. URL http://www.dspace.com. LetzterZugriff: 05/2014. (Zitiert auf Seite 5.)

https://www.lri.fr/~conchon/TER/2013/2/SMTLIB2.pdf

https://www.lri.fr/~conchon/TER/2013/2/SMTLIB2.pdf

http://www.dspace.com


[37] F. Elberzhager, A. Rosbach und T. Bauer (2013). Analysis and Testingof Matlab Simulink Models: A Systematic Mapping Study. In Procee-dings of the 2013 International Workshop on Joining AcadeMiAand Industry Contributions to Testing Automation, Seiten 29–34.JAMAICA 2013, ACM, New York, NY, USA. ISBN 978-1-4503-2161-7. (Zitiert auf Seite 30.)

[38] M. D. Ernst (2003). Static and Dynamic Analysis: Synergy and Duality.In WODA 2003: Workshop on Dynamic Analysis, Seiten 24–27.Portland, Oregon. (Zitiert auf den Seiten 7 und 70.)

[39] I. O. for Standardization / Technical Committee 22 (ISO/TC 22)(2009). ISO/DIS 26262 - Road vehicles — Functional safety. (Zitiertauf den Seiten 13 und 16.)

[40] G. Fraser und A. Arcuri (2011). Evolutionary Generation of WholeTest Suites. In 11th International Conference on Quality Software(QSIC), Seiten 31–40. ISSN 1550-6002. (Zitiert auf Seite 136.)

[41] G. Fraser und F. Wotawa (2007). Improving Model-Checkers for Softwa-re Testing. In International Conference on Quality Software, Seiten25–31. IEEE Computer Society, Los Alamitos, CA, USA. ISSN1550-6002. (Zitiert auf den Seiten 5 und 42.)

[42] G. Fraser, A. Arcuri und P. McMinn (2013). Test Suite Generationwith Memetic Algorithms. In Proceeding of the Fifteenth AnnualConference on Genetic and Evolutionary Computation Conference,Seiten 1437–1444. GECCO ’13, ACM, New York, NY, USA. ISBN978-1-4503-1963-8. (Zitiert auf Seite 56.)

[43] A. A. Gadkari, S. Mohalik, K. Shashidhar, A. Yeolekar, J. Sureshund S. Ramesh (2007). Automatic Generation of Test-Cases UsingModel Checking for SL/SF Models. In Proceedings of the 4th Model-Driven Engineering, Verification and Validation Workshop, Seiten33–46. (Zitiert auf Seite 43.)

[44] A. A. Gadkari, A. Yeolekar, J. Suresh, S. Ramesh, S. Mohalik undK. C. Shashidhar (2008). AutoMOTGen: Automatic Model OrientedTest Generator for Embedded Control Systems. In Proceedings of the20th International Conference on Computer Aided Verification,Seiten 204—-208. (Zitiert auf Seite 43.)

[45] T. Gawlitza, J. Leroux, J. Reineke, H. Seidl, G. Sutre und R. Wilhelm(2009). Polynomial precise interval analysis revisited. In S. Albers,H. Alt, und S. Näher, Herausgeber, Efficient Algorithms, Band5760 von Lecture Notes in Computer Science, Seiten 422–437. SpringerBerlin Heidelberg. ISBN 978-3-642-03455-8. (Zitiert auf Seite 93.)


[46] K. Ghani und J. A. Clark (2009). Automatic Test Data Generation forMultiple Condition and MCDC Coverage. In Proceedings of the 20094th International Conference on Software Engineering Advances,Seiten 152–157. ICSEA ’09, Washington, DC, USA. ISBN 978-0-7695-3777-1. (Zitiert auf Seite 228.)

[47] K. Ghani und J. A. Clark (2009). Widening the Goal Posts: ProgramStretching to Aid Search Based Software Testing. In 1st InternationalSymposium on Search Based Software Engineering, Seiten 122–131.(Zitiert auf Seite 47.)

[48] K. Ghani, J. A. Clark und Y. Zhan (2009). Comparing Algorithms forSearch-Based Test Data Generation of Matlab Simulink Models, Seiten2940–2947. IEEE. ISBN 978-1-4244-2958-5. (Zitiert auf Seite 160.)

[49] P. Godefroid, N. Klarlund und K. Sen (2005). DART: Directed Auto-mated Random Testing. In Proceedings of the 2005 ACM SIGPLANConference on Programming Language Design and Implementa-tion, Seiten 213–223. PLDI ’05, ACM, New York, NY, USA. ISBN1-59593-056-6. (Zitiert auf den Seiten 5, 48 und 49.)

[50] A. Goldberg, T. C. Wang und D. Zimmerman (1994). Applicationsof Feasible Path Analysis to Program Testing. In Proceedings of the1994 ACM SIGSOFT International Symposium on Software Testingand Analysis, Seiten 80–94. ISSTA ’94, ACM, New York, NY, USA.ISBN 0-89791-683-2. (Zitiert auf den Seiten 70 und 94.)

[51] K. Grimm (1995). Systematisches Testen von Software: eine neue Metho-de und eine effektive Teststrategie. Dissertation, Technische UniversitätBerlin. (Zitiert auf den Seiten 29 und 31.)

[52] S. Gulwani und S. Juvekar (2009). Bound analysis using back-ward symbolic execution. Technischer Bericht, Microsoft Research.(Zitiert auf Seite 167.)

[53] G. Hamon (2005). A Denotational Semantics for Stateflow. In Pro-ceedings of the 5th ACM International Conference on EmbeddedSoftware, Seiten 164–172. EMSOFT ’05, ACM, New York, NY, USA.ISBN 1-59593-091-4. (Zitiert auf Seite 17.)

[54] G. Hamon (2008). Simulink Design Verifier - Applying Automated For-mal Methods to Simulink and Stateflow. In AFM’08: Third Workshopon Automated Formal Methods. (Zitiert auf Seite 43.)

[55] G. Hamon und J. Rushby (2007). An Operational Semantics forStateflow. International Journal on Software Tools for TechnologyTransfer, 9(5-6), 447–456. ISSN 1433-2779. (Zitiert auf Seite 17.)


[56] G. Hamon, L. de Moura und J. Rushby (2004). Generating EfficientTest Sets with a Model Checker. In 2nd International Conference onSoftware Engineering and Formal Methods, Seiten 261–270. IEEEComputer Society, Beijing, China. (Zitiert auf Seite 43.)

[57] M. Harman (2007). The Current State and Future of Search BasedSoftware Engineering. In 2007 Future of Software Engineering, Seiten342–357. FOSE ’07, IEEE Computer Society, Washington, DC, USA.ISBN 0-7695-2829-5. (Zitiert auf Seite 55.)

[58] M. Harman und R. Hierons (2001). An Overview of Program Slicing.Software Focus, 2(3), 85–92. ISSN 1529-7950. (Zitiert auf Seite 106.)

[59] M. Harman und P. McMinn (2010). A Theoretical and EmpiricalStudy of Search-Based Testing: Local, Global, and Hybrid Search. IEEETransactions on Software Engineering, 36(2), 226–247. ISSN 0098-5589. (Zitiert auf den Seiten 46, 52, 54 und 56.)

[60] M. Harman, C. Fox, R. Hierons, L. Hu, S. Danicic und J. Wegener(2002). VADA: A Transformation-Based System for Variable DependenceAnalysis. In Proceedings of the 2nd IEEE International Workshopon Source Code Analysis and Manipulation, Seiten 55–64. (Zitiertauf Seite 105.)

[61] M. Harman, Y. Hassoun, K. Lakhotia, P. McMinn und J. Wegener(2007). The Impact of Input Domain Reduction on Search-based TestData Generation. In Proceedings of the the 6th Joint Meeting ofthe European Software Engineering Conference and the ACMSIGSOFT Symposium on the Foundations of Software Engineering,Seiten 155–164. ESEC-FSE ’07, New York, NY, USA. ISBN 978-1-59593-811-4. (Zitiert auf Seite 105.)

[62] M. Harman, S. G. Kim, K. Lakhotia, P. McMinn und S. Yoo (2010).Optimizing for the Number of Tests Generated in Search Based TestData Generation with an Application to the Oracle Cost Problem. In3rd International Conference on Software Testing, Verification,and Validation Workshops (ICSTW), Seiten 182–191. (Zitiert aufSeite 136.)

[63] K. Hartig (2013). Einsatz lokaler Suchverfahren zur strukturorientiertenTestdatengenerierung für Simulink-/TargetLink-Modelle. Diplomarbeit,TU Berlin. (Zitiert auf den Seiten 141, 159 und 198.)

[64] N. He, P. Rümmer und D. Kroening (2011). Test-Case Generation forEmbedded Simulink via Formal Concept Analysis. In Proceedings ofthe 48th Design Automation Conference, Seiten 224–229. DAC ’11,ACM, New York, NY, USA. ISBN 978-1-4503-0636-2. (Zitiert aufSeite 43.)


[65] P. Herber, R. Reicherdt und P. Bittner (2013). Bit-precise formal verifi-cation of discrete-time MATLAB/Simulink Models using SMT Solving.In 2013 Proceedings of the International Conference on EmbeddedSoftware (EMSOFT), Seiten 1–10. (Zitiert auf Seite 176.)

[66] R. Höhn und S. Höppner, Herausgeber (2008). Das V-Modell XT:Grundlagen, Methodik und Anwendungen. Springer, Berlin. ISBN978-3-540-30249-0. (Zitiert auf Seite 28.)

[67] S. Horwitz, T. Reps und D. Binkley (1988). Interprocedural SlicingUsing Dependence Graphs. In Proceedings of the ACM SIGPLAN1988 Conference on Programming Language Design and Implemen-tation, Seiten 35–46. PLDI ’88, ACM. ISBN 0-89791-269-1. (Zitiertauf Seite 98.)

[68] K. Inkumsah und T. Xie (2007). Evacon: A Framework for IntegratingEvolutionary and Concolic Testing for Object-Oriented Programs. InProceedings of the 22nd IEEE/ACM International Conference onAutomated Software Engineering, Seiten 425–428. ASE ’07, ACM,New York, NY, USA. ISBN 978-1-59593-882-4. (Zitiert auf Seite 50.)

[69] N. Instruments (2014). LabView. URL http://www.ni.com/labview/d. Letzter Zugriff: 05/2014. (Zitiert auf Seite 13.)

[70] A. Kanade, R. Alur, F. Ivancic, S. Ramesh, S. Sankaranarayanan undK. C. Shashidhar (2009). Generating and Analyzing Symbolic Traces ofSimulink/Stateflow Models. In Proceedings of the 21st InternationalConference on Computer Aided Verification, Seiten 430–445. CAV’09, Springer-Verlag, Berlin, Heidelberg. ISBN 978-3-642-02657-7.(Zitiert auf den Seiten 44 und 227.)

[71] O. Kindel und M. Friedrich (2009). Softwareentwicklung mit AUTO-SAR: Grundlagen, Engineering, Management in der Praxis. dpunkt,Heidelberg. ISBN 978-3-898-64563-8. (Zitiert auf Seite 13.)

[72] J. C. King (1975). A New Approach to Program Testing. SIGPLANNot., 10(6), 228–233. ISSN 0362-1340. (Zitiert auf den Seiten 5und 41.)

[73] S. Kirkpatrick, C. D. Gelatt und M. P. Vecchi (1984). Optimizationby Simulated Annealing: Quantitative Studies. Journal of StatisticalPhysics, 34(5-6), 975–986. ISSN 0022-4715. (Zitiert auf Seite 160.)

[74] R. Kirner (2009). Towards Preserving Model Coverage and StructuralCode Coverage. EURASIP Journal on Embedded Systems, 2009,6:1–6:16. ISSN 1687-3955. (Zitiert auf Seite 37.)

[75] S. Kirstan (2011). Kosten und Nutzen modellbasierter Entwicklungeingebetteter Softwaresysteme im Automobil. Dissertation, TechnischeUniversität München. (Zitiert auf Seite 12.)

http://www.ni.com/labview/d

http://www.ni.com/labview/d


[76] B. Korel (1990). Automated Software Test Data Generation. IEEETransactions on Software Engineering, 16(8), 870–879. (Zitiert aufden Seiten 46, 54, 105, 142 und 156.)

[77] K. Lakhotia, P. McMinn und M. Harman (2009). Automated Test DataGeneration for Coverage: Haven’t We Solved This Problem Yet? In Pro-ceedings of the 2009 Testing: Academic and Industrial Conference -Practice and Research Techniques, Seiten 95–104. TAIC-PART ’09,IEEE Computer Society, Washington, DC, USA. ISBN 978-0-7695-3820-4. (Zitiert auf Seite 49.)

[78] K. Lakhotia, P. McMinn und M. Harman (2010). An EmpiricalInvestigation Into Branch Coverage for C Programs Using CUTE andAUSTIN. Journal of Systems and Software, 83(12), 2379–2391. ISSN0164-1212. (Zitiert auf den Seiten 49 und 70.)

[79] K. Lakhotia, N. Tillmann, M. Harman und J. De Halleux (2010).FloPSy: Search-Based Floating Point Constraint Solving for SymbolicExecution. In Proceedings of the 22nd IFIP WG 6.1 Internatio-nal Conference on Testing Software and Systems, Seiten 142–157.ICTSS’10, Springer-Verlag, Berlin, Heidelberg. ISBN 3-642-16572-9,978-3-642-16572-6. (Zitiert auf Seite 49.)

[80] E. Legros, W. Schäfer, A. Schürr und I. Stürmer (2011). Mate - a mo-del analysis and transformation environment for matlab simulink.In H. Giese, G. Karsai, E. Lee, B. Rumpe, und B. Schätz, Herausge-ber, Model-Based Engineering of Embedded Real-Time Systems,Band 6100 von Lecture Notes in Computer Science, Seiten 323–328.Springer Berlin Heidelberg. ISBN 978-3-642-16276-3. (Zitiert aufSeite 17.)

[81] J. J. Li und H. Yee (2004). Code-coverage guided prioritized test genera-tion. In Proceedings of the 28th Annual International ComputerSoftware and Applications Conference (COMPSAC), Band 2, Seiten178–181. ISSN 0730-3157. (Zitiert auf Seite 137.)

[82] P. Liggesmeyer (2009). Software-Qualität: Testen, Analysieren undVerifizieren von Software. Spektrum Akademischer Verlag. ISBN9783827420565. (Zitiert auf Seite 31.)

[83] P. McMinn (2011). Search-Based Software Testing: Past, Present andFuture. In IEEE 4th International Conference on Software Testing,Verification and Validation Workshops (ICSTW), Seiten 153–163.(Zitiert auf den Seiten 5, 46 und 52.)


[84] P. McMinn und M. Holcombe (2004). Hybridizing evolutionarytesting with the chaining approach. In K. Deb, Herausgeber, Gene-tic and Evolutionary Computation – GECCO 2004, Band 3103 vonLecture Notes in Computer Science, Seiten 1363–1374. Springer BerlinHeidelberg. ISBN 978-3-540-22343-6. (Zitiert auf den Seiten 64und 136.)

[85] P. McMinn und M. Holcombe (2005). Evolutionary Testing of State-Based Programs. In Proceedings of the 2005 Conference on Geneticand Evolutionary Computation, Seiten 1013–1020. GECCO ’05.ISBN 1-59593-010-8. (Zitiert auf Seite 57.)

[86] P. McMinn, M. Harman, D. Binkley und P. Tonella (2006). TheSpecies per Path Approach to Search-Based Test Data Generation. InProceedings of the 2006 International Symposium on SoftwareTesting and Analysis, Seiten 13–24. ISSTA ’06, ACM, New York,NY, USA. ISBN 1-59593-263-1. (Zitiert auf Seite 64.)

[87] P. McMinn, M. Harman, K. Lakhotia, Y. Hassoun und J. Wegener(2012). Input Domain Reduction through Irrelevant Variable Removaland Its Effect on Local, Global, and Hybrid Search-Based Structural TestData Generation. IEEE Transactions on Software Engineering, 38(2),453–477. ISSN 0098-5589. (Zitiert auf Seite 105.)

[88] N. Metropolis, A. W. Rosenbluth, M. N. Rosenbluth, A. H. Tellerund E. Teller (1953). Equation of State Calculations by Fast Compu-ting Machines. The Journal of Chemical Physics, 21(6), 1087–1092.(Zitiert auf Seite 160.)

[89] W. Miller und D. Spooner (1976). Automatic Generation of Floating-Point Test Data. IEEE Transactions on Software Engineering, SE-2(3),223–226. (Zitiert auf Seite 46.)

[90] S. Mohalik, A. A. Gadkari, A. Yeolekar, K. Shashidhar und S. Ra-mesh (2013). Automatic Test Case Generation from Simulink/StateflowModels Using Model Checking. Software Testing, Verification andReliability. ISSN 1099-1689. (Zitiert auf Seite 43.)

[91] R. E. Moore (1966). Interval Analysis. Prentice-Hall. (Zitiert aufSeite 73.)

[92] L. Moura und N. Bjørner (2009). Satisfiability modulo theories: Anappetizer. In M. V. Oliveira und J. Woodcock, Herausgeber, FormalMethods: Foundations and Applications, Seiten 23–36. Springer-Verlag, Berlin, Heidelberg. ISBN 978-3-642-10451-0. (Zitiert aufSeite 163.)

[93] F. Neri, C. Cotta und P. Moscato (2011). Handbook of MemeticAlgorithms. Studies in Computational Intelligence, Springer. ISBN9783642232466. (Zitiert auf den Seiten 55 und 143.)


[94] J. Oh, M. Harman und S. Yoo (2011). Transition Coverage Testingfor Simulink/Stateflow Models Using Messy Genetic Algorithms. InProceedings of the 13th Annual Conference on Genetic and Evolu-tionary Computation (GECCO), Seiten 1851–1858. ACM. (Zitiertauf Seite 47.)

[95] P. Peranandam, S. Raviram, M. Satpathy, A. Yeolekar, A. Gadkariund S. Ramesh (2012). An integrated test generation tool for enhancedcoverage of Simulink/Stateflow models. In Proceedings of the Confe-rence on Design, Automation and Test in Europe, Seiten 308–311.(Zitiert auf den Seiten 50 und 176.)

[96] C. S. Pasareanu, J. Schumann, P. Mehlitz, M. Lowry, G. Karsai,H. Nine und S. Neema (2009). Model Based Analysis and Test Genera-tion for Flight Software. In Proceedings of the 3rd IEEE InternationalConference on Space Mission Challenges for Information Techno-logy, Seiten 83–90. (Zitiert auf den Seiten 43 und 176.)

[97] Reactive Systems (2014). Reactis. URL http://www.reactive-systems.com. Letzter Zugriff: 05/2014. (Zitiert auf den Seiten 33und 51.)

[98] R. Reicherdt und S. Glesner (2012). Slicing MATLAB Simulink models.In 34th International Conference on Software Engineering (ICSE),Seiten 551–561. ISSN 0270-5257. (Zitiert auf Seite 106.)

[99] G. F. Renfer (1962). Automatic Program Testing. In Proceedings of3rd Conference of the Computing and Data Processing Societyof Canada. University of Toronto Press. (Zitiert auf den Seiten 5und 45.)

[100] M. Research (2014). Pex – White box Unit Testing for .NET. URL http://research.microsoft.com/en-us/projects/Pex. Letzter Zugriff:05/2014. (Zitiert auf den Seiten 49 und 164.)

[101] P. Roy und N. Shankar (2010). SimCheck: An Expressive Type Systemfor Simulink. In C. Muñoz, Herausgeber, Proceedings of the SecondNASA Formal Methods Symposium (NFM 2010), NASA/CP-2010-216215, Seiten 149–160. NASA, Langley Research Center, HamptonVA 23681-2199, USA. (Zitiert auf den Seiten 43 und 176.)

[102] P. Roy und N. Shankar (2011). SimCheck: A Contract Type System forSimulink. Innovations in Systems and Software Engineering, 7(2),73–83. ISSN 1614-5046. (Zitiert auf den Seiten 43 und 176.)

[103] J. Rumbaugh, I. Jacobson und G. Booch (2004). Unified ModelingLanguage Reference Manual, The (2nd Edition). Pearson Higher Edu-cation. ISBN 0321245628. (Zitiert auf Seite 12.)

http://www.reactive-systems.com

http://www.reactive-systems.com

http://research.microsoft.com/en-us/projects/Pex

http://research.microsoft.com/en-us/projects/Pex


[104] S. Sadeghipour und M. Lim (2005). Einsatz automatischer Testvektor-generierung im modellbasierten Test. In A. B. Cremers, R. Manthey,P. Martini, und V. Steinhage, Herausgeber, GI Jahrestagung (2),Band 68 von LNI, Seiten 475–479. GI. ISBN 3-88579-397-0. (Zitiertauf den Seiten 30 und 39.)

[105] M. Satpathy, A. Yeolekar und S. Ramesh (2008). Randomized directedtesting (REDIRECT) for Simulink/Stateflow models. In Proceedingsof the 8th ACM international conference on Embedded software,Seiten 217–226. (Zitiert auf Seite 50.)

[106] J. Schäuffele und T. Zurawka (2010). Automotive Software Enginee-ring. ATZ-MTZ-Fachbuch, Westdeutscher Verlag GmbH, 4. Auflage.ISBN 9783834893680. (Zitiert auf den Seiten 4 und 13.)

[107] J. Scheible (2012). Automatisierte Qualitätsbewertung von MATLABSimulink-Modellen in der Automobil-Domäne. Dissertation, Universi-tät Tübingen. (Zitiert auf den Seiten 17 und 181.)

[108] K. Sen und G. Agha (2006). CUTE and jCUTE: Concolic Unit Testingand Explicit Path Model-Checking Tools. In Proceedings of the 18thInternational Conference on Computer Aided Verification, Seiten419–423. CAV’06, Springer-Verlag, Berlin, Heidelberg. (Zitiert aufSeite 50.)

[109] K. Sen, D. Marinov und G. Agha (2005). CUTE: A Concolic UnitTesting Engine for C. In Proceedings of the 10th European SoftwareEngineering Conference held jointly with 13th ACM SIGSOFTInternational Symposium on Foundations of Software Engineering,Seiten 263–272. ESEC/FSE-13, ACM, New York, NY, USA. ISBN1-59593-014-0. (Zitiert auf den Seiten 5, 48 und 49.)

[110] A. Spillner und T. Linz (2010). Basiswissen Softwaretest: Aus- undWeiterbildung zum Certified Tester – Foundation Level nach ISTQB-Standard. dpunkt, Heidelberg, 4. Auflage. ISBN 978-3-89864-358-0.(Zitiert auf Seite 4.)

[111] E. Technologies (2014). SCADE Suite. URL http://www.esterel-technologies.com/products/scade-suite? LetzterZugriff: 05/2014. (Zitiert auf Seite 13.)

[112] The Mathworks (2013). MATLAB and Simulink Deployed toInternational Space Station for NASA SPHERES Project. URLhttp://www.mathworks.de/company/newsroom/MATLAB-and-Simulink-Deployed-to-International-Space-Station-for-NASA-SPHERES-Project.html. Letzter Zugriff: 05/2014. (Zitiertauf Seite 5.)

[113] The Mathworks (2014). Matlab. URL http://www.mathworks.de/products/matlab. Letzter Zugriff: 05/2014. (Zitiert auf Seite 5.)

http://www.esterel-technologies.com/products/scade-suite?

http://www.esterel-technologies.com/products/scade-suite?

http://www.mathworks.de/company/newsroom/MATLAB-and-Simulink-Deployed-to-International-Space-Station-for-NASA-SPHERES-Project.html



http://www.mathworks.de/products/matlab

http://www.mathworks.de/products/matlab


[114] The Mathworks (2014). Matlab Simulink. URL http://www.mathworks.de/products/simulink. Letzter Zugriff: 05/2014.(Zitiert auf den Seiten 5 und 33.)

[115] The Mathworks (2014). Polyspace. URL http://www.mathworks.de/products/polyspace. Letzter Zugriff: 05/2014. (Zitiert auf Sei-te 94.)

[116] The Mathworks (2014). Simulink Design Verifier. URL http://www.mathworks.de/products/sldesignverifier. Letzter Zugriff:05/2014. (Zitiert auf Seite 51.)

[117] F. Tip (1995). A Survey of Program Slicing Techniques. Journal ofProgramming Languages, 3, 121–189. (Zitiert auf Seite 105.)

[118] P. Tonella (2004). Evolutionary Testing of Classes. In Proceedingsof the 2004 ACM SIGSOFT International Symposium on SoftwareTesting and Analysis, Seiten 119–128. ISSTA ’04, ACM, New York,NY, USA. ISBN 1-58113-820-2. (Zitiert auf Seite 50.)

[119] Q. M. Tran, B. Wilmes und C. Dziobek (2013). Refactoring of SimulinkDiagrams via Composition of Transformation Steps. In 8th InternationalConference on Software Engineering Advances (ICSEA). (Zitiertauf den Seiten 17, 95 und 228.)

[120] S. Varshney und M. Mehrotra (2013). Search Based Software Test DataGeneration for Structural Testing: A Perspective. SIGSOFT SoftwareEngineering Notes, 38(4), 1–6. ISSN 0163-5948. (Zitiert auf Seite 46.)

[121] T. E. J. Vos, A. I. Baars, F. F. Lindlar, P. M. Kruse, A. Windischund J. Wegener (2010). Industrial Scaled Automated Structural Tes-ting with the Evolutionary Testing Tool. In Proceedings of the 2010Third International Conference on Software Testing, Verificationand Validation, Seiten 175–184. ICST ’10, IEEE Computer Socie-ty, Washington, DC, USA. ISBN 978-0-7695-3990-4. (Zitiert aufSeite 62.)

[122] T. E. J. Vos, A. I. Baars, F. F. Lindlar, A. Windisch, B. Wilmes,H. Gross, P. M. Kruse und J. Wegener (2012). Industrial Case StudiesFor Evaluating Search Based Structural Testing. International Journalof Software Engineering and Knowledge Engineering, 22(08), 1123–1149. (Zitiert auf Seite 46.)

[123] T. E. J. Vos, F. F. Lindlar, B. Wilmes, A. Windisch, A. I. Baars, P. M.Kruse, H. Gross und J. Wegener (2013). Evolutionary FunctionalBlack-Box Testing in an Industrial Setting. Software Quality Journal,21(2), 259–288. ISSN 0963-9314. (Zitiert auf Seite 47.)

http://www.mathworks.de/products/simulink

http://www.mathworks.de/products/simulink

http://www.mathworks.de/products/polyspace

http://www.mathworks.de/products/polyspace

http://www.mathworks.de/products/sldesignverifier

http://www.mathworks.de/products/sldesignverifier


[124] M. A. Vouk (1990). Back-to-back testing. Information and SoftwareTechnology, 32(1), 34–45. ISSN 0950-5849. Special Issue on SoftwareQuality Assurance. (Zitiert auf Seite 39.)

[125] Y. Wang, Y. Gong, J. Chen, Q. Xiao und Z. Yang (2008). An Applica-tion of Interval Analysis in Software Static Analysis. In Proceedings ofthe 2008 IEEE/IFIP International Conference on Embedded andUbiquitous Computing - Volume 02, Seiten 367–372. EUC ’08, IEEEComputer Society, Washington, DC, USA. ISBN 978-0-7695-3492-3.(Zitiert auf den Seiten 73 und 94.)

[126] J. Wegener, A. Baresel und H. Sthamer (2001). Evolutionary Test En-vironment for Automatic Structural Testing. Information and SoftwareTechnology, 43(14), 841–854. ISSN 0950-5849. (Zitiert auf Seite 46.)

[127] J. Wegener, K. Buhr und H. Pohlheim (2002). Automatic Test DataGeneration For Structural Testing Of Embedded Software Systems ByEvolutionary Testing. In Proceedings of the Genetic and EvolutionaryComputation Conference, Seiten 1233–1240. GECCO ’02, MorganKaufmann Publishers Inc., San Francisco, CA, USA. ISBN 1-55860-878-8. (Zitiert auf den Seiten 46 und 48.)

[128] K. Weicker (2007). Evolutionäre Algorithmen. Leitfäden der Infor-matik, Vieweg+Teubner Verlag. ISBN 9783835102194. (Zitiert aufSeite 54.)

[129] M. Weiser (1981). Program Slicing. In Proceedings of the 5thInternational Conference on Software Engineering, Seiten 439–449.ICSE ’81, IEEE Press, Piscataway, NJ, USA. ISBN 0-89791-146-6.(Zitiert auf Seite 105.)

[130] B. Wilmes und A. Windisch (2010). Considering Signal Constraintsin Search-Based Testing of Continuous Systems. In 2010 Third Interna-tional Conference on Software Testing, Verification, and ValidationWorkshops (ICSTW), Seiten 202–211. (Zitiert auf den Seiten 47und 51.)

[131] A. Windisch (2009). Search-based Testing of Complex Simulink ModelsContaining Stateflow Diagrams. In 31st International Conference onSoftware Engineering, Seiten 395–398. (Zitiert auf den Seiten 47und 62.)

[132] A. Windisch (2011). Suchbasierter Strukturtest für Simulink Modelle.Dissertation, TU Berlin. (Zitiert auf den Seiten 6, 33, 47, 48, 51, 53,56, 58, 60, 61, 63, 64, 70, 141, 179, 182, 183, 193, 198, 221 und 225.)


[133] A. Windisch und N. Al Moubayed (2009). Signal Generation forSearch-Based Testing of Continuous Systems. In International Confe-rence on Software Testing, Verification and Validation Workshops,Seiten 121–130. ICSTW ’09. (Zitiert auf den Seiten 47, 51, 59, 62und 143.)

[134] T. Xie, N. Tillmann, P. de Halleux und W. Schulte (2009). Fitness-Guided Path Exploration in Dynamic Symbolic Execution. In Procee-dings of the 39th Annual IEEE/IFIP International Conference onDependable Systems and Networks (DSN 2009), Seiten 359–368.(Zitiert auf Seite 70.)

[135] Y. Zhan und J. Clark (2004). Search based automatic test-datageneration at an architectural level. In K. Deb, Herausgeber, Geneticand Evolutionary Computation – GECCO 2004, Band 3103 vonLecture Notes in Computer Science, Seiten 1413–1424. Springer BerlinHeidelberg. ISBN 978-3-540-22343-6. (Zitiert auf den Seiten 47, 48und 62.)

[136] Y. Zhan und J. A. Clark (2006). The State Problem for Test Generationin Simulink. In Proceedings of the 8th Annual Conference onGenetic and Evolutionary Computation, Seiten 1941–1948. GECCO’06, ACM, New York, NY, USA. ISBN 1-59593-186-4. (Zitiert aufden Seiten 48 und 62.)

[137] Y. Zhan und J. A. Clark (2008). A Search-Based Framework for Au-tomatic Testing of Matlab/Simulink Models. Journal of Systems andSoftware, 81(2), 262–285. ISSN 0164-1212. (Zitiert auf den Seiten 47,48 und 160.)

ABB I LDUNGSVERZE ICHN IS

Abbildung 1 Übersichtsbild des entwickelten Verfahrens . . . 9Abbildung 2 Entwicklungs- und Testprozess im V-Modell . . . 29Abbildung 3 Kontrollfluss von Programmcode . . . . . . . . . 32Abbildung 4 Automatisierter Funktionstest (Beispiel) . . . . . 38Abbildung 5 Ablauf eines suchbasierten Tests . . . . . . . . . . 53Abbildung 6 Strukturorientierte Testdatensuche für SL/TL . . 57Abbildung 7 Signalkodierung und -generierung . . . . . . . . . 58Abbildung 8 Beispiel zur statischen Voranalyse SIA . . . . . . 72Abbildung 9 Zeitintervall-Bildung für Signale . . . . . . . . . . 82Abbildung 10 Vereinigung von einelementigen Intervallen . . . 84Abbildung 11 Beispiel zur statischen Voranalyse SDA . . . . . . 97Abbildung 12 Nutzen der SIA-Modelltransformationen für SDA 102Abbildung 13 Beispiel zur statischen Voranalyse CGSeq . . . . . 108Abbildung 14 Funktionsweise der Suchzielpriorisierung . . . . 109Abbildung 15 Logische Abhängigkeiten (Beispiel) . . . . . . . . 115Abbildung 16 Semantische Abhängigkeiten (Beispiel) . . . . . . 121Abbildung 17 Virtuelle Überdeckungsziele (Beispiel) . . . . . . 123Abbildung 18 Ergänzende Erreichbarkeitsprüfung (Beispiel) . . 129Abbildung 19 Bildung von Suchzielen (Beispiel) . . . . . . . . . 132Abbildung 20 Metriken zur Suchzielpriorisierung (Übersicht) . 134Abbildung 21 Zusammenspiel der statischen Voranalysen . . . 138Abbildung 22 Nachbarschaft einer Optimierungssequenz (Teil 1) 145Abbildung 23 Nachbarschaft einer Optimierungssequenz (Teil 2) 150Abbildung 24 Nachbarschaftsgröße eines Signalsegments . . . . 151Abbildung 25 Vorgehen des lokalen Suchverfahrens ASPO . . . 153Abbildung 26 Abarbeitungsreihenfolge der Signalparameter . . 158Abbildung 27 Problemdefinition für SMT-Solver . . . . . . . . . 168Abbildung 28 Kombination von Suche und SMT-Solving . . . . 174Abbildung 29 SMT-Solving: Anpassung der Suchzielpriorisierung 175Abbildung 30 Architektur des Tool-Prototypen TASMO . . . . . 180Abbildung 31 Anwendung von TASMO . . . . . . . . . . . . . . 184Abbildung 32 Wizard-Oberfläche von TASMO . . . . . . . . . . 186Abbildung 33 TASMO: Testdatengenerierung und Testreport . . 187Abbildung 34 Erreichte Überdeckung (Fallstudien) . . . . . . . . 201Abbildung 35 Laufzeit der Testdatengenerierung (Fallstudien) . 202Abbildung 36 Anzahl anvisierter Suchziele (Fallstudien) . . . . 205Abbildung 37 Erfolgsquote bei Suchzielen (Fallstudien) . . . . . 205Abbildung 38 Größe der erzeugten Testsuiten (Fallstudien) . . . 206Abbildung 39 Effektivität lokaler/globaler Suche (Fallstudien) . 207Abbildung 40 Effizienz lokaler/globaler Suche (Fallstudien) . . 208

244

TABELLENVERZE ICHN IS

Tabelle 1 Hilfsfunktionen und -definitionen für Simulink . 18Tabelle 2 Funktionsweise von SL/TL-Blocktypen . . . . . . 24Tabelle 3 Modellüberdeckungskriterien . . . . . . . . . . . . 33Tabelle 4 Überdeckungsziele für SL/TL-Blocktypen . . . . 35Tabelle 5 Funktionsweise der Zielfunktionsberechnung . . 61Tabelle 6 Intervallsemantik für SL/TL-Blocktypen . . . . . 78Tabelle 7 Signal-Abhängigkeit bei SL/TL-Blocktypen . . . 100Tabelle 8 Syntax eines CG-Abhängigkeitsgraphen . . . . . 113Tabelle 9 Log. Beziehungen zwischen Überdeckungszielen 117Tabelle 10 Implikationsbeziehung zwischen Ausdrücken . . 119Tabelle 11 Ausschlussbeziehung zwischen Ausdrücken . . . 120Tabelle 12 Semantische Abhängigkeiten zwischen CGs . . . 125Tabelle 13 Transformation der Blöcke nach SMT . . . . . . . 169Tabelle 14 Fallstudien-Konfigurationen . . . . . . . . . . . . 193Tabelle 15 Übersicht über Bewertungskriterien (Fallstudien) 196

245

ABKÜRZUNGSVERZE ICHN IS

In diesem Verzeichnis sind die verwendeten Abkürzungen und Kurz-schreibweisen, gegebenenfalls mit Pluralform, aufgeführt. Zu jedem Ein-trag ist hierbei die Seite gelistet, auf welcher der dazugehörige Begrifferstmals genannt oder erklärt ist.

ASPO Alternierende Signalparameteroptimierung . 141

AVM Alternating Variable Method . . . . . . . . . . . . . . . . 54

CC Bedingungsüberdeckung . . . . . . . . . . . . . . . . . . . . 31

CG CGs Überdeckungsziel . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

CGSeq Suchzielpriorisierung . . . . . . . . . . . . . . . . . . . . . . . 107

CSC Subsystem-Bedingungsüberdeckung . . . . . . . . 33

CSP Constraint-Satisfaction-Problem . . . . . . . . . . . . . 162

DC Entscheidungsüberdeckung . . . . . . . . . . . . . . . . . 31

GS Globale Suche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

HC Hill Climbing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

KFG Kontrollflussgraph . . . . . . . . . . . . . . . . . . . . . . . . . . 31

LGA Längenvariabler genetischer Algorithmus . . . 60

LS Lokale Suche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

MC/DC Modified Condition/Decision Coverage . . . . 32

ML Matlab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

PAP Programmablaufplan . . . . . . . . . . . . . . . . . . . . . . . 31

SAT Erfüllbarkeitsproblem der Aussagenlogik . . . 162

SDA Modelleingang-Abhängigkeitsermittlung . . . 96

SF Stateflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

SG SGs Suchziel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

SIA Überdeckungsziel-Erreichbarkeitsprüfung . . 69

SL Simulink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

SMT Satisfiability Modulo Theories . . . . . . . . . . . . . . 162

TASMO Testing via Automated Search for Models . . . 179

TDGP TDGPs Testdatengenerierungsproblem . . . . . . . . . . . . . 166

TL TargetLink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

VCG VCGs Virtuelles Überdeckungsziel . . . . . . . . . . . . . . . . 122

246

E I D E S S TAT T L I C H E E R K L Ä R U N G

Die selbständige und eigenhändige Anfertigung dieser Arbeit versichereich an Eides statt.

Berlin, März 2015

Benjamin Wilmes

Hybrides Testverfahren für Simulink/TargetLink-Modelle · deren Test, ist eine größtmögliche...

Documents

Transcript of Hybrides Testverfahren für Simulink/TargetLink-Modelle · deren Test, ist eine größtmögliche...