Spezifikation von Fahrzeug-Testabläufen und Abgleich mit manuell erzeugten Testanordnungen in der Automobilproduktion. cand.-inform.

Transkript

1 Spezifikation von Fahrzeug-Testabläufen und Abgleich mit manuell erzeugten Testanordnungen in der Automobilproduktion Diplomarbeit von cand.-inform. Tobias Schneider An der Fakultät für Informatik Systeme der Informationsverwaltung Institut für Programmstrukturen und Datenorganisation (IPD) Erstgutachter: Zweitgutachter: Betreuende Mitarbeiterin: Prof. Dr.-Ing. Klemens Böhm Prof. Dr. Walter F. Tichy Dipl.-Inform. Jutta Mülle Bearbeitungszeit: KIT Universität des Landes Baden-Württemberg und nationales Forschungszentrum der Helmholtz-Gesellschaft

2

3 iii Eidesstattliche Erklärung Eidesstattliche Erklärung Hiermit versichere ich, die vorliegende Arbeit selbstständig und unter ausschließlicher Verwendung der angegebenen Literatur und Hilfsmittel erstellt zu haben. Die Arbeit wurde bisher in gleicher oder ähnlicher Form keiner anderen Prüfungsbehörde vorgelegt und auch nicht veröffentlicht. Karlsruhe, Unterschrift iii

4

5 Inhaltsverzeichnis 1 Einleitung Motivation Zielsetzung Überblick Grundlagen und Literaturanalyse Status quo der Testplanerzeugung Einsatzsystem Testplan Boolesche Erfüllbarkeitsprüfung Aussagenlogik Alphabet der Aussagenlogik Syntax der Aussagenlogik Semantik der Aussagenlogik Erfüllbarkeitsproblem der Aussagenlogik Literaturanalyse Anforderungen Laufzeit Abfolgenformate Diagnosebereite und verbaute Komponenten an Prozessorten Abfolgen und ihre Vorbedingungen Logischer-Ausdruck-Satz bei Verzweigungen im Testplan Gleichzeitige offene Verbindungen zu Steuergeräten Abhängigkeiten Abhängigkeiten zwischen Abfolgen Abhängigkeiten zwischen Steuergeräten Abhängigkeiten zwischen Bezeichner Schnittstellen zum Einbringen der Daten in das Modell Modellierung Datenerhebung Das Automobil Die Abfolgen Die Test-Umgebung Die Softwareauslieferung Formalisierung Automobil-Modell Abfolgen-Modell Test-Umgebungs-Modell Software-Auslieferungs-Modell Datenbankentwurf Realisierung des Automobilmodells Realisierung des Abfolgenmodells Realisierung des Test-Umgebungsmodells Gesamtarchitektur der Datenbank v

6 vi Inhaltsverzeichnis 5 Datenintegration Test-Umgebung Abfolgen Komponenten-Abhängigkeiten Fahrzeug-Optionen und deren Familien Diagnosebereitschaft einer Komponente an den Prozessorten Befüllung im Überblick Konzeption der Testplanüberprüfung Testplan Überprüfung des Testplans Architektur Algorithmische Überprüfung Abfolgeformate Gleichzeitig offene Verbindungen zu Steuergeräten Diagnosebereite und verbaute Komponenten an Prozessorten Sequentielle Abhängigkeiten Parallele Abhängigkeiten Überprüfung mittels SAT Solver Implementierung Aufbau Datenintegration AAAFT Das Framework Kommandozeilen Parameter Konfigurationsdatei Datenintegration Verifikation Fehlermeldungen Configurations -Paket Database -Paket DataManager -Paket ExternalTestplanConverter -Paket ModelChecking -Paket Evaluierung Wissenserhebung Verifikation der Testpläne Zusammenfassung und Ausblick Zusammenfassung Ausblick Literaturverzeichnis 89 vi

7 Abbildungsverzeichnis 2.1 UML-Diagramm: Testplan (SIDIS Pro) UML-Diagramm: Signature des Testplans (SIDIS Pro) UML-Diagramm: Abfolge (SIDIS Pro) UML-Diagramm: Parallele Struktur, ParallelBlockContainerStatement (SIDIS Pro) UML-Diagramm: Sequentielle Struktur, BlockStatement (SIDIS Pro) Mobile Prüfstation MPS 7, Quelle: [AG12] Automobil-Modell Entitäten ER-Diagramm: Automobil-Modell Abfolgen-Modell Entitäten ER-Diagramm: Abfolgen-Modell Test-Umgebungs-Modell Entitäten ER-Diagramm: Test-Umgebungs-Modell ER-Diagramm: Software-Auslieferungs-Modell Datenbankschema des Automobil-Modell Datenbankschema des Abfolgen-Modell Datenbankschema des Test-Umgebungs-Modell Vollständiges Datenbankschema Wurzelknoten des Austauschformates: Test-Umgebung Prozessort und dessen optionale Ressourcen und initiale Zustände Ressourcen eines Prozessortes Wurzelknoten mit Abfolgen und Zuständen Zustand Abfolge mit Attributen und Spezialisierungen Attributgruppe referenceattribute Abfolgen Referenz Wurzelknoten und Komponente des Austauschformates Wurzelknoten mit Listen von normalen und speziellen Fahrzeug-Optionen Fahrzeug-Optionen und -Familien Spezielle Fahrzeug-Optionen Austauschformate und deren zu befüllende Informationen Modell der Testplanüberprüfung Flussdiagram der Datenintegration Flussdiagramm der Verifikation Implementierung: DataIntegration -Paket Implementierung: Database -Paket Implementierung: Configuration -Paket Implementierung: DataManager -Paket Implementierung: ExternalTestplanConverter -Paket Implementierung: ModelChecking -Paket Testplanausschnitt mit Abfolgen Lebenszyklus der Software vii

8

9 Tabellenverzeichnis 2.1 Beschreibung der Leseart der aussagenlogischen Formeln Wahrheitstabelle der aussagenlogischen Formeln Abhängigkeiten zwischen Abfolgen Abhängigkeiten zwischen Bezeichnern einer Komponente Typ der Abfolgen-Abhängigkeiten in der Datenbank Attributgruppe zum referenzieren externer Inhalte. [Gro12] Sequentielle Abhängigkeiten Parallele Abhängigkeiten Äquivalente Elemente von SIDIS Pro in OTX Kommandozeilen Parameter der einzelnen Einstiegspunkte der Implementierung Fehlermeldungen der Verifikation Implementierung: Handler zur Informationsextraktion Neue Abhängigkeiten zwischen Abfolgen Absolute Laufzeit der Verifikation in Millisekunden ix

10

11 1. Einleitung 1.1 Motivation Produktkonfiguration und Qualitätssicherung spielen eine Hauptrolle auf dem Markt komplexer Produkte wie zum Beispiel in der Automobilindustrie. Speziell in dieser Industrie werden Fahrzeuge zum großen Teil auf Wunsch des Käufers zusammengestellt und geliefert. Diese Spezialisierung des Fahrzeugs erzeugt eine hohe Komplexität sowohl für die Konfiguration als auch für die Qualitätssicherung des Fahrzeugs, da es keine einheitliche Fließbandproduktion im klassischen Sinne, sondern eine flexible, auf den Kunden zugeschnittene Produktion gibt. Für die Konfiguration sowie zur Sicherstellung der gleichbleibenden Qualität werden in der Automobilindustrie Verfahren eingesetzt, um diesen Standard zu halten bzw. diesen für die Zukunft zu verbessern. Bei diesen Verfahren, welche direkt am Automobil in der Produktion angewendet werden, handelt es sich um Testpläne, die eine Abfolge von sequentiell und parallel geschalteten Einzeltests in sich bereit halten. Diese Einzeltests greifen auf die im Fahrzeug verbauten Komponenten zu und dienen der Konfiguration sowie der Überprüfung der Qualität. Da sich die Fahrzeugkomponenten in einer stetigen Weiterentwicklung befinden und immer wieder neue Komponenten entstehen, kann dies Änderungen der strukturellen Anordnung der Einzeltests aufgrund von physikalischen Abhängigkeiten der Komponenten zur Folge haben. Aus diesem Grund befinden sich auch die Testpläne in einer stetigen Weiterentwicklung. Nicht nur die andauernde Weiterentwicklung und die daraus steigernde Komplexität, sondern auch das manuelle Erstellen der Testpläne durch Mitarbeiter birgt die Gefahr in sich, dass ein inkorrekt modellierter Testplan in die Produktion gelangt. Die Gründe, warum ein inkorrekter Testplan in die Produktion gelangen könnte, ist dadurch gegeben, dass zum einen die Abhängigkeiten zwischen Einzeltests in keiner zentral zugänglichen Datenbasis gespeichert sind, sodass neue Mitarbeiter lediglich über das Wissen der etablierten Mitarbeiter an Informationen über den Testplan gelangen. Zum anderen kann es durch die mündliche Weitergabe oder durch nicht so erfahrene Mitarbeiter passieren, dass unvollständiges oder sogar inkorrektes Wissen über die Abhängigkeiten der Einzeltests weitergegeben wird. Dieses Problem und die stetig steigende Komplexität des Testplans erfordern eine zentrale Wissensbasis mit allen Abhängigkeiten, Regeln und Fakten eines Testplans sowie ein Programm zur Verifikation 1 von Testplänen anhand der erstellten Wissensbasis. Mit dem Wissen aus der Wissensbasis wird es möglich sein, das gesammelte Wissen über die Testpläne der Mitarbeiter zentral zu speichern und dieses Wissen allen Mitarbeitern ohne Einschränkung zur Verfügung zu stellen. Da dieses Wissen erst der erste Schritt ist, um Fehler in einem 1 Bei dieser Verifikation handelt es sich um keine Verifikation im klassischen Sinne. Die Verifikation könnte durch Testen oder Prüfen ersetzt werden, da jedoch im Kontext die Rede von Testplänen und Prüfprogrammen (bei den Fahrzeugherstellern) ist, wurde Verifikation als Schlagwort zur besseren Abgrenzung im folgenden in diesem Sinne benutzt. 1

12 2 1. Einleitung Testplan zu erkennen, wird über die Verifikation der zweite Schritt zur korrekten Modellierung von Testplänen erreicht. 1.2 Zielsetzung Das Ziel dieser Arbeit ist es, eine Wissensbasis zu erstellen und anhand dieser eine Verifikation von Testplänen durchzuführen. Um dieses Ziel zu erreichen, müssen mehrere Zwischenschritte gegangen werden. Die Anforderungen decken verschiedene Bereiche des Testplans ab und sind essenziell für die spätere Verifikation. Denn würden bestimmte Anforderungen nicht oder inkorrekt erhoben, so könnte eine korrekte Verifikation basierend auf den Anforderungen, welche zu Mechanismen, Datenstrukturen, Regeln und Architektur der Verifikationssystems führen, nicht vorgenommen werden. Nachdem die Anforderungen korrekt erhoben wurden, ist eine Maßnahme zur Realisierung der Testplanverifikation der Aufbau einer Wissensbasis für gültige Abhängigkeiten, Regeln und Fakten der zu testenden Objekten. Diese Wissensbasis muss zum einen so konkret sein, dass die Anforderungen, welche zur Verifikation von Testplänen in der Wissensbasis vorhanden sein müssen, aufgenommen, zum anderen so generisch gehalten werden, dass neue Anforderungen ohne großen Aufwand in die Wissensbasis aufgenommen werden können. Sobald das Modell der Wissensbasis zur Verfügung steht, ist ein Bestandteil der Zielsetzung, dass eine Realisierung der Wissensbasis und eine entsprechende Implementierung entwickelt wird. Diese Implementierung ermöglicht eine zentrale Speicherung der gesammelten Abhängigkeiten, Regeln und Fakten eines Testplans. Die Erfassung des Wissens durch die Anwender muss unterstützt werden. Dies ist ein fortlaufender Prozess und startet mit einer ersten Erhebung, wird aber iterativ durch die Weiterentwicklung der Testumgebung und der zu testenden Objekte während der gesamten Lebenszeit des Systems fortgesetzt. Nachdem zum einen die Abhängigkeiten, Regeln und Fakten eines Testplans in der Wissensbasis zur Verfügung gestellt werden, kann mittels des Programmes zur Verifikation die einzelnen Testpläne auf ihre Korrektheit überprüft werden. 1.3 Überblick In diesem Abschnitt wird ein Überblick über die Kapitel dieser Arbeit und deren Inhalt gegeben. Im Kapitel Grundlagen und Literaturanalyse wird im Abschnitt 2.1 auf die derzeitige Testplanerzeugung und deren Probleme eingegangen. Danach wird ein Überblick über das gesamte Einsatzsystem, im Abschnitt 2.2, und dessen drei Stufen gegeben. Anschließend werden, im Abschnitt Testplan, die verschiedenen Formate von Testplänen vorgestellt. Die Abfolgen eines Testplans sowie die Beziehungen dieser untereinander sind die Grundkomponenten, welche bei der Verifikation überprüft werden. Zudem wird in diesem Abschnitt auf die verschiedenen Typen von Abfolgen und ihre Bezeichnung eingegangen. Das nächste Kapitel Anforderungen beschäftigt sich mit den Anforderungen, welche durch Analyse der verschiedenen Testplanformate, wie zum Beispiel des standardisierten OTX Formates, und Gespräche mit Experten aus der Automobilindustrie erhoben wurden. Diese Anforderungen und die aus der Modellierung entstehenden Abhängigkeiten, Regeln und Fakten eines Testplans werden im Kapitel Modellierung anhand von Modellen aufgezeigt. Diese Modelle bilden die Grundlage für die später erzeugte Datenbank. Die Datenbank wird im Abschnitt 4.3 formalisiert. Um das Wissen von Anwendern zu erfassen, wurden entsprechende Schnittstellen zur Integration der Daten angelegt. Im Kapitel Datenintegration werden die verschiedenen Austauschformate vorgestellt. Diese Austauschformate wurden ausgehend von den noch nicht vorhandenen maschinenlesbaren Informationen aus der Automobilindustrie erstellt. Dazu wurden zum einen XML Schemata und passende XML Dateien, mit Informationen der Abhängigkeiten aus der Automobilindustrie, erzeugt. Nachdem die Datenbank mit den Informationen zur Verfügung steht, widmen wir uns der Konzeption der Testplanüberprüfung im Kapitel 6. In diesem Kapitel werden die verschiedenen Maßnahmen zur Verifikation der Testpläne entworfen und erläutert. 2

13 1.3. Überblick 3 Die Implementierungskonzeption im Kapitel 7 zeigt, wie die erhobenen Anforderungen mit Hilfe des Wissen aus der Datenbank mittels der Software für die Verifikation überprüft werden. Da die Konzeption der Verifikation aus zwei Teilen besteht ergibt sich bei daraus, dass auch die Implementierung aus zwei Teilen besteht. Zum einen aus der Datenintegration und zum anderen aus der eigentlichen Komponente AAAFT (Automatisiertes Anordnen von Arbeitsschritten des Fertigens und Testens). Im Evaluierungskapitel 8 wird die entworfene Testsystemarchitektur sowie deren Komponenten validiert. Eine Zusammenfassung dieser Arbeit ist im Kapitel 9.1 vorhanden. Im letzten Abschnitt Ausblick wird das weitere Vorgehen sowie weiterführendes Potenzial dieser Arbeit aufgezeigt. 3

14

15 2. Grundlagen und Literaturanalyse 2.1 Status quo der Testplanerzeugung In der Automobilindustrie werden die Testpläne (Abschnitt 2.3) manuell mit einem Autorentool erstellt und im Debugmodus freigetestet. Dies bedeutet, dass die Testpläne in einer Simulationsumgebung ausgeführt werden. Eines der großen Probleme ist, dass es Abhängigkeiten zwischen den Arbeitsschritten eines Testplans gibt und diese bis dato nur in den Köpfen der Testplanentwickler bekannt sind. Dadurch ist es sehr umständlich und schwierig, einem neuen Entwickler diese Informationen vollständig und korrekt zu vermitteln und zu jedem Zeitpunkt bei der Testplanentwicklung eine korrekte Modellierung vorzunehmen. Trotz geschulter Testplanentwickler kann es zu nicht korrekt modellierten Testplänen aufgrund von falscher Modellierung der Abhängigkeiten der Arbeitsschritte der Testpläne oder bis dato nicht bekannten Abhängigkeiten zwischen einzelnen Arbeitsschritten des Testplans kommen und diese im schlimmsten Fall erst bei der Überprüfung eines Automobiles am Prozessort erkannt werden. Durch diese späte Kenntnisnahme eines Fehlers im Testplan besteht die Gefahr, dass der komplette Prüfvorgang verzögert und somit die Produktion still stehen könnte. Aufgrund zunehmender Komplexität der Testpläne wird es immer wichtiger diese auf Korrektheit in Bezug der Arbeitsschritte innerhalb der Testpläne sowie der Beziehungen dieser Arbeitsschritten untereinander zu überprüfen. Aus diesem Grund wird im kommenden Abschnitt 2.2 ein System vorgestellt, welches nicht nur die Korrektheit der Testpläne anhand eines Regelwerkes überprüfen wird, sondern aufgrund der steigenden Komplexität des Regelwerkes in der Lage sein soll, Vorschläge für eine optimalere Anordnung dieser Arbeitsschritte bzw. eine optimale automatisierte Anordnung von Arbeitsschritten auf der Basis des Regelwerkes ohne das Eingreifen eines Testplanentwicklers zu gewährleisten. 2.2 Einsatzsystem Im Einsatzsystem wird die Testplanunterstützung über drei Stufen aufgeteilt angesehen. In der vorliegenden Arbeit wird die erste Stufe behandelt und implementiert, sowie schon bekannte Anforderungen und weitere Spezifikationen für die folgenden Stufen spezifiziert. In der zweiten Stufe soll dann aufbauend auf der ersten Stufe ein Optimierungsverfahren entwickelt, welches die eingelesenen Testpläne aufgrund von dynamischen Informationen (siehe Kapitel 6) wie zum Beispiel den WLAN-Durchsatz, Aktive Testläufe im System, Ehrfahrungswerte der Abfolgen sowie Abgebrochene Tests optimieren wird. Weitere dynamische Informationen sind denkbar und sollten im Laufe der weiteren Arbeit hinzugefügt werden. Die dritte Stufe ist die komplexeste Stufe dieses Systems und soll anhand aller gegebenen festen und dynamischen Informationen automatisch einen optimalen Testplan für ein konkretes Automobil erstellen. Diese Stufe wird in der Lage sein, für jedes einzelne Fahrzeug einen eigenen optimalen Testplan ohne Leerzeiten und mit optimaler Zeitdauer zu erstellen. Bis dato werden Testpläne für eine ganze Modellreihe erstellt, bei denen es aufgrund von optionalen Ausstattungen einzelner Fahrzeuge zu Leerzeiten kommen kann. 5

16 6 2. Grundlagen und Literaturanalyse Entwicklungsstufen des Einsatzsystems im Überblick: Stufe 1 Testpläne werden von Hand erzeugt und bestimmte Merkmale mit einer zugrundeliegenden Wissensbasis verglichen. Bei Inkonsistenzen werden Fehlermeldungen ausgegeben. Stufe 2 Automatisches Erstellen von Prozessortprogrammen vor Laufzeit. Von Hand erzeugte Testpläne werden eingelesen und Optimierungsvorschläge in der Entwicklungsumgebung angezeigt. Auf diese Vorschläge kann der Entwickler eingehen. Stufe 3 Optimaler Ablauf für jedes Fahrzeug (Ordnung/Reihenfolge der Abfolgen wird erst zur Laufzeit festgelegt.) 2.3 Testplan In diesem Abschnitt werden die einzelnen Komponenten eines Testplans aufgezeigt und erläutert, damit in den nächsten Kapiteln, aufbauend auf diesen Informationen, Anforderungen an Komponenten konkret untersucht und dargestellt werden können. Es gibt verschiedene Formate von Testplänen, die derzeit in der Automobilindustrie verwendet werden. Der Großteil dieser Testpläne liegt in einem proprietären Format vor, welches von Programmen wie zum Beispiel das SIDIS Pro: Ein Prüf- und Diagnosesystem für die Fahrzeug-Endmontage von Siemens [Gro12] benutzt wird. Ein weiteres Programm mit einem proprietären Format ist das PRODIS.Automation von Diagnostics Systems Applications [App12]. Aufgrund der Vielfalt proprietärer Formate und deren Komplikationen beim Einlesen von Testplänen wird zum Zeitpunkt dieser Ausarbeitung im Auftrag der großen deutschen Automobilherstellern Daimler AG und der Volkswagen AG ein Format namens OTX (Open Test sequence exchange) [ZS11] von der ISO 1 spezifiziert. Das Ziel von OTX [Int12] ist es, eine Sprache für Fahrzeugdiagnose bereitzustellen, die es ermöglicht, Diagnosesequenzen grafisch darzustellen und gleichzeitig so eindeutig zu beschreiben, dass sie ausgeführt werden können. Der Standard soll umfangreich genug werden, um proprietäre Lösungen in Entwicklung, Produktion und Kundendienst zu ersetzen. Sowohl die proprietären als auch das OTX Format enthalten ähnliche Grundstrukturen und -komponenten. Als erstes wird auf die verschiedenen Komponenten der Formate eingegangen, welche für diese Arbeit von Bedeutung sind. Da wir uns in dieser Arbeit mit dem Programm SIDIS Pro und dessen Format zur Testplanerstellung beschäftigen werden, wird aufgrund der Übersichtlichkeit die folgenden UML-Diagramme der Komponenten und deren Beziehungen im Format von SIDIS Pro beschrieben. Aufgrund der internen, auf OTX basierenden, Datenstruktur des Programmes, auf welches die verschiedenen Eingabeformate abgebildet werden, werden an dieser Stelle keine Einschränkungen auf das SI- DIS Pro Eingabeformate vorgenommen. Das SIDIS Pro wurde an dieser Stelle als Repräsentant ausgewählt, da dies ein gängiges Eingabeformat ist, welches viele Art von Funktion unterstützt. Die erste Komponente ist die Wurzelkomponente des Testplans. In dieser wird eine Vielzahl von Informationen über den Testplan gespeichert. Außerdem wird die Struktur des gesamten Testplans anhand der Beziehungen zu weiteren Komponenten aufgebaut. Im SIDIS Pro Format wird diese Komponente als Element mit dem Namen CheckProgram bezeichnet. 1 International Organization for Standardization, 6

17 2.3. Testplan 7 Abbildung 2.1: UML-Diagramm: Testplan (SIDIS Pro) Anhand des UML Diagramms aus Abbildung 2.1 wird deutlich, dass zu einem Testplan eine Vielzahl von Attributen gehört. Diese beinhalten Informationen über den Autor, die Version, das Datum, eine Beschreibung und weitere wichtige Informationen über den Testplan. Zudem sind im Testplan unter dem Element Signature 0 bis Parameter enthalten. Diese Parameter erzeugen Variablen, die zur Laufzeit des Testplan bestimmte Informationen, zum Beispiel über den Ausführungsort des Testplans oder auch für Konfigurationen innerhalb des Testplans (siehe Kapitel 3.4), enthalten. Abbildung 2.2: UML-Diagramm: Signature des Testplans (SIDIS Pro) Nach der Signature kann entweder maximal ein Element vom Typ SimpleType String oder 7

18 8 2. Grundlagen und Literaturanalyse eine Sequenz kommen. In der Sequenz darf maximal ein Element vom Typ FunctionsDeclarationStatements, über welches logische Funktionen in den Testplan eingebracht werden können, oder vom Typ Statements enthalten sein. In dieser Arbeit werden wir uns intensiv mit den Statements beschäftigen, da in diesen die CheckModuleCallStatements enthalten sind. Diese Check- ModuleCallStatements bilden die Blattknoten des XML-Baumes und sind als Abfolgen in der Automobilindustrie bekannt. Diese Abfolgen enthalten alle für diese Arbeit relevanten Informationen für die Verifikation des Testplans. Eine Abfolge kann als Modul, eine funktionsorientierte Gruppe von Computerbefehlen, angesehen werden, welche eine bestimmte Anordnung von Programmschritten in sich birgt und zudem mit genau einem Steuergerät oder dessen LIN-Teilnehmer 2 kommuniziert. Die Beziehung zwischen Steuergerät und LIN-Teilnehmer kann als ein Master-Slave Beziehung angesehen werden, wobei der Slave optional ist. Das eigentliche Steuergerät, der Master, kann direkt, der Slave hingegen lediglich über den Master, angesprochen werden und ohne diesen nicht existieren. Jedes Mastersteuergerät kann zudem n Slaves bedienen. Sowohl der Master als auch der Slave können eine optionale Lage des Steuergerätes, welche aus genau zwei Buchstaben oder Ziffern besteht, beinhalten. Außerdem kann ein Steuergerät eine optionale Variante besitzen, wodurch man Steuergeräte mit einheitlicher Lage unterscheiden kann. Ein sogenannter Bezeichner am Ende des Abfolgenamens, beschreibt die Zweck dieser Abfolge. Es gibt zwei verschiedene Arten von Abfolgen. Zum einen die bekannte Abfolge (A) und zum anderen eine Spezialisierung dieser Abfolge die funktionale Abfolge (F). Der Unterschied zwischen diesen Abfolgearten ist, dass die allgemeine Abfolge genau mit einem Steuergerät oder dessen Slave kommuniziert. Eine funktionale Abfolge hingegen hat die Möglichkeit, mit bis zu n verschiedenen Steuergeräten oder dessen Slaves zu kommuniziert. Abbildung 2.3: UML-Diagramm: Abfolge (SIDIS Pro) Eine der wichtigsten Informationen für die Verifikation der Testabläufe ist im Attribut ReferenceName gespeichert. In diesem Attribut wird der Abfolgename gespeichert, welcher Rückschlüsse auf die Art der Abfolge, die Art des verwendeten Steuergerätes, den optionalen Slave sowie den Bezeichner in sich hält. 2 LIN, Local Interconnect Network, beschreibt das Netzwerk zwischen Steuergerät und dessen LIN- Teilnehmer 8

19 2.3. Testplan 9 Das Format des ReferenceName, der beiden Arten von Abfolgen, wird in der folgenden Auflistung anhand eines regulären Ausdrucks [Fri07] definiert: Abfolge A_<SGKBZ>[_Lage][_<LINKBZ>[_Lage]][ Variante] <Bezeichner> Funktionale Abfolge F_(<SGKBZ>[_Lage][_<LINKBZ>[_Lage]])+ <Bezeichner> Legende: SGKBZ = Steuergerätkurzbezeichnung LI NKBZ = LIN-Steuergerätkurzbezeichnung Lage = Position des Steuergerätes im Fahrzeug Als nächstes werden wir uns nun um die Struktur der Testpläne kümmern, in denen die Abfolgen eingebettet sind. Es gibt zwei grundlegende Strukturen: Zum einen können die Abfolgen in einer sequentiellen und zum anderen in einer parallelen Struktur eingebettet sein. Diese Strukturen ermöglichen es, beim Ausführen eines Testplans auf mehreren Threads 3 gleichzeitig zu arbeiten (parallele Struktur) oder eine bestimmte sequentielle Reihenfolge strikt einzuhalten. Parallele Strukturen werden mit dem ParallelBlockContainerStatement (Abbildung 2.4) realisiert. Dieses Element beinhaltet 0 bis n BlockStatements oder TryCatchBlockStatements, welche wiederum SimpleStatements aufnehmen können. Da ein ParallelBlockContainerStatement wiederum von SimpleStatement erbt und dadurch wieder in einem BlockStatement vorkommen kann, ist es in dieser Struktur möglich, beliebige parallele Verschachtelungen in einem Testplan zu realisieren. Abbildung 2.4: UML-Diagramm: Parallele Struktur, ParallelBlockContainerStatement (SIDIS Pro) Abfolgen, die strikt sequentiell in einem Testplan vorkommen, werden in den meisten Fällen in einem BlockStatement aufgenommen. Es ist auch möglich eine Abfolge ( CheckModuleCallStatement ) ohne eine BlockStatement in den Testplan aufzunehmen, dies wird in der Regel lediglich bei einzelnen Abfolgen direkt unter dem Wurzelelement (CheckProgram) vorgenommen. 3 Ein Thread bezeichnet in der Informatik einen Ausführungsstrang oder eine Ausführungsreihenfolge in der Abarbeitung eines Programms. 9

20 10 2. Grundlagen und Literaturanalyse Abbildung 2.5: UML-Diagramm: Sequentielle Struktur, BlockStatement (SIDIS Pro) Diese Strukturen werden uns in den nächsten Kapiteln intensiv beschäftigen. Denn es werden beim Verifizieren der Testpläne bestimmte Anforderungen an die Abfolgen und deren Struktur zueinander gestellt. Die Anforderungen der Komponenten und der Struktur können in zwei Teilgebiete unterteilt werden: Zum einen in die Abhängigkeiten zwischen den Abfolgen und zum anderen in syntaktische und allgemeingültige Regeln eines Testplans. 2.4 Boolesche Erfüllbarkeitsprüfung Die Boolesche Erfüllbarkeitsprüfung wird in dieser Arbeit für die Verifikation der LAS, siehe Anforderung 3.5, eingeführt. Die LAS sind als boolesche aussagenlogische Formeln im Testplan realisiert, weshalb in den nächsten Abschnitten zuerst auf die Aussagenlogik und darauf auf deren Erfüllbarkeitsproblem eingegangen wird. Boolesche aussagenlogische Formeln können mittels eines SAT Solvers auf ihre Korrektheit überprüft werden. Die Logik wurde bereits zwischen 382 und 322 vor Christus von dem Philosophen Aristoteles begründet. Dieser entwickelte die Syllogistik, welche heute als formale Logik bekannt ist. Diese Logik ist angesiedelt zwischen der Informatik, der Mathematik und der Philosophie und beschäftigt sich damit, aus einer gegebenen Prämisse oder Behauptung, eine Konsequenz zu folgern. Die Aussagen, aus denen die Logik aufgebaut ist, müssen folgende Bedingungen erfüllen: 1. Prinzip der Zweiwertigkeit Jede Aussage ist entweder wahr oder falsch 2. Kompositionalitätsprinzip Der Wahrheitswert von Aussagen, die durch logische Operatoren zusammengesetzt sind, lässt sich durch die Komposition eindeutig bestimmen. Ein logischer Operator dient zur Verknüpfung zwischen atomaren Aussagen. Die logischen Operatoren, von denen am häufigsten gebraucht gemacht wird sind: Negation ( ), Konjunktion ( ), Disjunktion ( ), Implikation ( ) und die Äquivalenz ( ) Die wichtigsten Teilgebiete der formalen Logik sind: 1. Aussagenlogik Mit seinem algebraischen Logikkalkül schuf George Boole 1847 den Grundstein für die Aussagenlogik, welche Gottlob Frege mit dem ersten aussagenlogischen Kalkül mit Schlussregel, im Rahmen seiner Begriffsschrift 1879, formulierte. Diese Begriffsschrift war die Vorlage für den Aussagenkalkül, entwickelt 1910 von Bertrand Russel, welche sich später durchsetzte. 2. Prädikatenlogik Die Prädikatenlogik, welche auf der Aussagenlogik basiert und diese erweitert wurde Ende 19. Jahrhunderts von Gottlob Frege und Charles Sanders Peirce entwickelt. Die Erweiterung besteht aus Prädikaten, Funktionen und Quantoren. Prädikate sind platzhaltende 10

21 2.4. Boolesche Erfüllbarkeitsprüfung 11 Aussagen, welche erst in Verbindung mit bestimmten Argumenten untersucht und ausgewertet werden und einen bestimmten Sachverhalt, wie z. B. eine Beziehung zwischen Objekten, abbilden können. Quantoren werden verwendet um alle Objekte des Universums auf eine bestimmte Anfrage anzuwenden. Dabei gibt es zwei verschiedene Quantorentypen. Eine Aussage, vor der der Allquantor ( ) gestellt wurde, wird genau dann als wahr ausgewertet, wenn diese Aussage auf alle Objekte des Universums zutrifft. Beim Existensquantor ( ) wird genau dann wahr zurückgegeben, wenn mindestens ein Objekt diese Aussage erfüllt Aussagenlogik Die Aussagenogik ist ein Teilgebiet der Logik. Eine Logik wird durch ein Alphabet, Syntax und Semantik definiert. Dabei bezieht sich die Syntax auf die reine formale Beziehung zwischen den Zeichen aus dem Alphabet. Die Semantik hingegeben beschreibt, wie eine Aussage durch eine Interpretation einen Wahrheitswert zugeordnet wird. Die Aussagenlogik kann somit als Sprache mit einem Alphabet und einer Menge an aussagenlogischen Formeln festgelegt werden. Das nachfolgende Kapitel wurde auf der Basis von [Wit] und [FN10] aufgebaut und durch weitere spezifische Informationen, die für diese Arbeit wichtig sind, erweitert Alphabet der Aussagenlogik Das Alphabet besteht aus den folgenden drei Mengen: 1. Der Menge O der aussagenlogischen Operatoren O = {,,,, } 2. der Menge der aussagenlogischer Variablen V. Die Menge V kann wie folgt, mit der Hilfsmenge {x,, } rekursiv definiert werden: a) x ist eine aussagenlogische Variable: x V b) Falls α V dann ist auch α und α V Daraus ergibt sich die Menge der aussagenlogischen Variablen V = {x, x, x, x, x, x,...} Die Anzahl der Striche kann zur Vereinfachung dazu genommen werden um die Stelligkeit auszudrücken. Somit folgt aus der oberen Menge: V = {x, x 1, x 1,x 1 1, x 2, x 2,...} Da in einer aussagenlogischen Formel nicht alle Variablen verwendet werden müssen, werden wir Variablenbezeichner, welche bei Bedarf mit den Elementen aus V belegt werden dürfen, einfügen. Als Variablenbezeichner werden Großbuchstaben aus dem deutschen Alphabet benutzt, welche zudem rekursiv mit dieser Menge erweitert werden können. Mit der Aussage A V ist somit gemeint, dass A als Platzhalter für eine aussagenlogische Variablen x i V benutzt wird. 3. und der zweielementige Menge K des aussagenlogischen Konstantenbezeichners Dabei gilt O V K = K = {, } Syntax der Aussagenlogik Da wir nun das Alphabet der Aussagenlogik (AL) definiert haben, können wir auf dieser aufbauend die Syntax definieren. Dabei werden die aussagenlogischen Formeln (AF) rekursiv definiert: 1. Die Elemente der Menge {K V} sind atomare Formeln, welche die Basis der Menge der aussagenlogischen Formeln F bilden. 11

22 12 2. Grundlagen und Literaturanalyse Form Bezeichnung Leseart Wahr Wahr Falsch Falsch A Negation von A nicht A A B Konjunktion von A und B A und B A B Disjunktion von A und B A oder B A B Implikation von A und B wenn A dann B A B Äquivalenz von A und B A genau dann wenn B Tabelle 2.1: Beschreibung der Leseart der aussagenlogischen Formeln 2. Wenn A und B Formeln sind A, (A), B, (B), A B, A B, A B, B A, A B F Wie die Formeln der Aussagenlogik gelesen werden können, ist in der Tabelle 2.1 nachzulesen. Zusätzlich zu den bisherigen Definitionen definieren wir uns die Klammerung der aussagenlogischen Formeln. Diese Klammerung dient dazu, die Formeln eindeutig zu lesen. 1. Falls Klammern für das Verständnis nicht gebraucht werden, können diese weggelassen werden. 2. Der Operator bindet stärker als die Operatoren,, und 3. Die Operatoren und binden stärker als und 4. Untereinander binden die Operatoren,, und gleich stark 5. Bei einer iterierten Verknüpfung mit dem Operator oder werden immer Klammern verwendet Semantik der Aussagenlogik In den letzten zwei Abschnitten haben wir sowohl das Alphabet als auch die Syntax der Aussagenlogik definiert. Letztere beschreibt, welche aussagenlogischen Formeln mit Hilfe des Alphabets erzeugt werden können. Im folgenden Abschnitt zeigen wir nun, wie einer allgemeinen Formel über eine Definition einer Interpretation ein Wahrheitswert zugewiesen werden kann. Definition 1 (Interpretation) Eine Interpretation ist eine Abbildung I : F K, welche einer aussagenlogischen Formel F einen Wahrheitswert aus K zuordnet. Diese Interpretation wird auch Belegung genannt. Eine aussagenlogische Variable kann genau zwei Wahrheitswerte annehmen. Eine aussagenlogische Formel mit n Variablen besitzt hingegen 2 n verschiedene Interpretationen, welche die Formel im Gesamten sowohl zu als auch zu auswerten lassen kann. Die folgende Wahrheitstafel stellt für die verschiedenen Wahrheitswerte der Variablen A und B den Wahrheitswert deren Verknüpfung mit den Operatoren,,, und dar. Bei der Interpretation geklammerter Formeln wird wie folgt vorgegangen: 1. Terme in Klauseln werden zuerst ausgewertet 2. Formeln, die aus mehreren Termen bestehen, werden nach der Auswertung der einzelnen Termen ausgewertet Wie schon beschrieben wurde, können Formeln sowohl zu als auch zu ausgewertet werden. Wird eine Formel durch eine bestimmte Interpretation zu ausgewertet, nennt man diese Interpretation ein Modell dieser Formel. 12

23 2.4. Boolesche Erfüllbarkeitsprüfung 13 A B A A B A B A B A B Tabelle 2.2: Wahrheitstabelle der aussagenlogischen Formeln Definition 2 (Modell) Eine Interpretation I einer Formel f F ist genau dann ein Modell, wenn [[ f ]] I = Definition 3 (Semantische Äquivalenz) Zwei aussagenlogische Formel f, g F sind genau dann semantisch Äquivalent zu einander, wenn für jede von beiden passende Interpretation I stets gilt: [[ f ]] I = [[g]] I. Die aussagenlogische Formeln f,g nehmen also für jede Interpretation den gleichen Wahrheitswert an. Man schreibt für die semantische Äquivalenz von f, g F: f g Definition 4 (Erfüllbarkeit) Eine aussagenlogische Formel f F ist genau dann erfüllbar, wenn es eine Interpretation I gibt mit I : F Definition 5 (Allgemeingültigkeit) Eine aussagenlogische Formel f F ist genau dann allgemeingültig oder eine Tautologie, wenn f bei allen Interpretation I den Wahrheitswert hat. I : F Ist eine Formel f F allgemeingültig bzw. eine Tautologie, so folgt daraus, dass diese Formel f erfüllbar ist und jede erfüllbare Interpretation I einer der Formel f heißt Modell von f. Definition 6 (Kontradiktion) Eine aussagenlogische Formel f F ist genau dann Kontradiktion oder eine widerspruchsvoll, wenn f bei allen Interpretation I den Wahrheitswert hat. I : F Lemma Eine aussagenlogische Formel f F ist genau dann Allgemeingültig, wenn f eine Kontradiktion ist. Lemma Eine aussagenlogische Formel f F ist genau dann erfüllbar, wenn f keine Tautologie ist. Im nächsten Abschnitt wird nun aufbauend auf der Aussagenlogik die Prädikatenlogik erster Ordnung vorgestellt. Diese erweitert die Aussagenlogik im Wesentlichen durch drei neue Konstrukte. Prädikate sind platzhaltende Aussagen, welche erst in Verbindung mit bestimmten Argumenten untersucht und ausgewertet werden. Funktionen liefern ein bestimmtes Objekt zu den 13

24 14 2. Grundlagen und Literaturanalyse übergebenen Argumenten zurück. Quantoren werden verwendet um alle Objekte des Universums auf eine bestimmte Anfrage anzuwenden. Dabei gibt es zwei verschiedene Quantorentypen. Eine Aussage, vor der der Allquantor ( ) gestellt wurde, wird genau dann zu wahr ausgewertet, wenn diese Aussage auf alle Objekte des Universums zutrifft. Beim Existensquantor ( ) wird genau dann wahr zurückgegeben, wenn mindestens ein Objekt diese Aussage erfüllt Erfüllbarkeitsproblem der Aussagenlogik Sei f eine aussagenlogische Formel über die Aussagenvariablen x 1,..., x n, so kann SAT eine Aussage treffen, ob es eine Belegung bzw. Interpretation der Aussagenvariablen gibt, welche den Wahrheitswert der Formel f zu wahr auswerten lässt oder nicht. Definition 7 (Konjunktive und Disjunktive Normalformen) Ein Literal kann sowohl positive als auch negativ sein. Ein positives Literal wird als Variable bezeichnet und ein negatives Literal als negierte Variable. Eine Formel f liegt genau dann in disjunktiver Normalform (DNF) bzw. in konjunktiver Normalform (KNF) vor, wenn sie eine Disjunktion von Konjunktionstermen bzw. Konjunktion von Disjunktionstermen ist, d.h. die Formel f hat die Form: DNF n m i ( )x ij i=1 j=1 KNF n m i ( )x ij i=1 j=1 Wobei ( )x ij die Literale sind und eine Disjunktion von Literalen auch Klausel genannt wird. In den letzten Jahren wurden viele neue Algorithmen zum Lösen von Erfüllbarkeitsproblemen von aussagenlogischen Formeln entwickelt und vorgestellt. Alle dieser Algorithmen haben leider ein exponentielles Worst-Case-Laufzeitverhalten. In der Datenverarbeitung wird unter dem Laufzeitverhalten die Anzahl der Rechenschritte in Abhängigkeit der Länge der Eingabe verstanden, um eine optimale Lösung eines Problems zu finden. Es interessiert also weniger, wie lange ein Computer benötigt, um ein optimales Ergebnis zu finden, sondern wie stark der Zeitbedarf bei größeren Datenmengen als Eingabe anwächst. Die Worst-Case-Laufzeit gibt an, wie lange der Algorithmus maximal benötigen kann. Diese Laufzeit ist in den meisten Fällen nur bei wenigen Eingaben eines Algorithmus zu beobachten, bei denen der Suchraum komplett durchsucht werden muss. Ein exponentielles Wachstum der Laufzeit abhängig von der Länge der Eingabeparameter, sagt aus, dass durch die Eingabelänge n die Suche nach dem optimalen Ergebnis e n Zeiteinheiten dauern kann. Die erfolgreichsten Algorithmen zur Überprüfung der Erfüllbarkeit von aussagenlogischen Formeln basieren auf dem DPLL-Algorithmus [DLL62]. Dieser benutzt verschiedene Heurisiken, wie zum Beispiel das Backjumping [Dec03], um das optimale Ergebnis oder zumindest ein sehr gutes Ergebnis in einer besseren Laufzeit als der genannten Worst-Case-Laufzeit zu erhalten. Der DPLL- Algorithmus basiert auf dem DP-Algorithmus [DP60], welcher für prädikatenlogische Formeln erster Ordnung entwickelt wurde. Dieser Algorithmus hat jedoch den großen Nachteil, dass dieser nur dann terminiert, wenn die prädikatenlogische Formel allgemeingültig war. In dem Fall, dass sie es nicht war, terminierte der Algorithmus nie. Der DPLL-Algorithmus wurde zunächst für prädikatenlogischen Formeln eingesetzt, jedoch später auf die aussagenlogischen Formeln reduziert. Dieser benötigt als Eingabewert eine aussagenlogische Formel in konjunktiver Normalform. Mit dieser Normalform ist es möglich, die einzelnen Klauseln der Formel getrennt zu betrachten und zu interpretieren. Da die konjunktive Normalform aus "Konjunktionen von Disjunktionstermen" besteht, muss jeder Disjunktionsterm als wahr ausgewertet werden. Ist dies nicht der Fall, wird die komplette Formel zu false ausgewertet und es muss keine weitere Behandlung stattfinden. Außerdem muss in 14

25 2.5. Literaturanalyse 15 jedem Disjunktionsterm mindestens ein Literal als wahr ausgewertet werden können, damit der Disjunktionsterm als wahr ausgewertet werden kann. Der DPLL-Algorithmus interpretiert alle booleschen Variablen der Formel zu Beginn als uninterpretiert Variablen, bei denen versucht wird, ihren Wahrheitswert sukzessiv explizit oder implizit zuweisen zu können, um jede einzelne Klausel der Konjunktionen zu erfüllen. 2.5 Literaturanalyse Im Bereich der Testplan-Verifikation sind nur einige wissenschaftliche Artikel relevant für unsere Zielsetzung. An der Universität Tübingen wurde 2003 unter der Leitung von Carsten Sinz die Arbeit Formal Methods for the Validation of Automotive Product Configuration Data [SKK03] in Kooperation mit der Daimler AG verwirklicht, bei der unter der Anwendung von formalen Methoden eine Validierung von kritischen Geschäftsdaten vorgenommen wurde. Dabei wurde ein speziell für diese Anforderungen modifizierter SAT-Solver entwickelt, mit dessen Hilfe Inkonsistenzen innerhalb einer Menge von Bedingungen detektiert wurden. Bei der Menge von Bedingungen handelte es sich um die benötigten Fahrzeug-Komponenten, welche bei einer individuellen Zusammenstellung eines Fahrzeuges verbaut werden müssen. Der entwickelte SAT-Solver, BIS, ist in der Lage, anhand der Ausstattung eines Fahrzeuges die Verträglichkeit dieser und der zusätzlich benötigten Ausstattungen zu prüfen und auf Änderungen der Produktionsumgebung einzugehen. Diese Veröffentlichung war für diese Arbeit interessant, da sie zum einen die Brücke zur Automobilindustrie schlägt und zum anderen SAT-Solver zur Überprüfung verwendet. Auf dieser Basis an Informationen war der erste Ansatz dieser Arbeit, dass es möglich sein könnte, alle Anforderungen an einen Testplan anhand von aussagenlogischen Formeln darzustellen und diese mittels eines Standard SAT-Solvers zu überprüfen. Dieser Ansatz bestätigte sich aufgrund der komplexeren Struktur der Testpläne mit ihren zeitlichen Abhängigkeiten zwischen Abfolgen sowie der nicht ausreichenden Spezialisierung von Standard SAT-Solver für das Problem dieser Arbeit nicht. Eine Erweiterung eines SAT-Solvers, sollte in der vorliegenden Arbeit nicht durchgeführt werden. Am General Motors R&D India Science Lab in Bangalore wurde 2008 das Tool Paper Auto- MOTGen: Automatic Model Oriented Test Generator for Embedded Control Systems [GYS + 08] unter der Leitung von Ambar A. Gadkari veröffentlicht. In diesem Paper wird ein Werkzeug präsentiert, welches automatisch Testfälle für das Testen von Steuergeräten generiert. Dieses Paper könnte für die Umsetzung der 3. Stufe des Einsatzsystems hilfreich sein. Die derzeitige Implementierung verwendet SAL [Lab12] zur Generierung von Testdaten und zum Überprüfen der Unerreichbarkeit der erfassten Ziele. Implementiert wurde AutoMOTGen sowohl in den Sprachen Java als auch C++ und benutzt MATLAB für die Extraktion der relevanten Informationen aus dem MATLAB Simulink/Stateflow Modellen [TM12]. Ein weitere Veröffentlichung im Gebiet der Generierung von Testsequenzen wurde von Mats P. E. Heimdahl et all veröffentlich. In dieser Veröffentlichung mit dem Titel Auto-generating Test Sequences using Model Checkers: A Case Study [HRV + 03] wird beschrieben, dass zur Unterstützung bei der Generierung von Testsequenzen Model Checker angewandt werden. Dabei nutzt der Ansatz die Möglichkeit der Generierung von Testplänen mittels Beweisen und Gegenbeispielen eines Model Checkers aus. Außerdem wird die Problematik der state-space explosion, wenn die Menge der Kombinationen durch die Zunahme einzelner Einheiten förmlich explodiert, beschrieben. Deshalb geht Heimdahl darauf ein, dass es essentiell ist, das Programm anhand von großen realistischen Beispielen aus der Industrie zu testen und besonderen Wert auf die Skalierung zu legen. Geschrieben wurde die Implementierung in der Sprache RSML e [THM99] [TWH00]. Das Framework für die spezifische Testplangenerierung wurde mit dem Model Checker NuSMV [CCG + 02] verwirklicht. Diese Erkenntnisse könnten für die Stufen 2 und 3 eine erste Richtung andeuten, in welche die Entwicklung des automatisierten Erzeugens von Testplänen gehen könnte. Eine weitere Veröffentlichung im Bereich der Verifikation von Modellen, welche in MATLAB Simulink geschrieben wurden, ist die von Eckard Bringmann und Andreas Krämer mit dem Titel Model-based Testing of Automotive System [BK08b]. Diese beschreibt, wie sich die Entwicklung eingebetteter Systeme in der Automobilindustrie von einer elektrischen und mechanischen 15

26 16 2. Grundlagen und Literaturanalyse Disziplin zu einer Kombination aus Elektrik/Mechanik und Software entwickelt hat, wodurch die modellgetriebene Entwicklung sowie deren Software zur Verifikation der Modelle weiter vorangeschritten ist. Heutzutage werden Softwarekomponenten mit MATLAB/Simulink modelliert, anstatt diese in C oder Assembler zu schreiben. Da jedoch die Verifikation dieser modellgetriebenen Entwicklung bis dato nur sehr schlecht unterstützt wird, präsentieren Bringman und Krämer das Werkzeug Time Partition Testing (TPT). Dieses Werkzeug meistert die im Bereich der Automobilindustrie vorkommenden modellgetriebenen Komplexitäten, dies sind Komplexitäten, welche bei einer modellgetriebenen Softwareentwicklung 4 auftreten. Es untersucht Softwarekomponenten auf ihre Korrektheit, indem der Testfall in einen kompakten Bytecode transformiert wird. Dieser Bytecode wurde speziell auf die Bedürfnisse von automatischen TPT Tests angepasst und von der virtuellen Maschine des TPT ausgeführt. Die aufgezeichneten Testdaten werden nun anhand eines Python-Skriptes auf Korrektheit überprüft. Dieser Ansatz beschreibt eine andere Art von Überprüfungen, denn es werden Softwarekomponenten auf ihre Korrektheit untersucht, wohingegen in der vorliegenden Arbeit eine Verifikation anhand der Struktur von Sequenzen vorgenommen wird. Der Zusammenhang dieser beiden Ansätze ist, bis auf die Überprüfung der korrekten Modellierung, nicht gegeben. Zudem basiert die vorliegende Arbeit nicht auf einer modellgetriebene Softwareentwicklung. Dieses Kapitel zeigt auf, dass es nur wenige Veröffentlichungen im Gebiet dieser Arbeit gibt und noch viel Potenzial für weitere Forschung gegeben ist. Als Ergebnisse für diese Arbeit sind zwei der Veröffentlichungen relevant. Zum einen die Veröffentlichung von Carsten Sinz, wodurch die Überprüfung der LAS durch SAT-Solver in Augenschein genommen wurde und zum anderen die Veröffentlichung von Mats P. E. Heimdahl et all, welche eventuell für die Stufen 2 und 3 eine Basis zur Generierung von Testplänen bilden könnte. Die Entwicklung von Testsequenzen wird durch die Einführung des OTX-Standards [Int12] vorrangetrieben. Die vorliegende Arbeit nutzt ebenfalls diesen Standard für die einheitliche Überprüfung der Testsequenzen, welche im Abschnitt 2.3 und im Kapitel 6 genauer beschrieben ist. 4 Modellgetriebene Softwareentwicklung ist ein Oberbegriff für Techniken, die automatisiert aus formalen Modellen lauffähige Software erzeugen 16

27 3. Anforderungen Durch die Analyse der Testumgebungen und der Testpläne wurden im Laufe dieser Arbeit entsprechende Anforderungen an die Verifikation von Testplänen erhoben. Diese Anforderungen werden zum einen an das Gesamtsystem und zum anderen an die Abfolgen der Testpläne gestellt. Die Verifikation soll alle möglichen Fehlerquellen erkennen und die Aufmerksamkeit des Anwenders auf diese Fehler lenken, die Laufzeit sollte so gering wie möglich sein und die entwickelte Software eine breite Palette an Schnittstellen für das Einbinden der Daten in das System bieten. In den nächsten Kapiteln werden die verschiedenen Anforderungen an das System vorgestellt. Zuerst wird auf das Gesamtsystem und später speziell auf die Abfolgen eingegangen. 3.1 Laufzeit Die Laufzeit des Einsatzsystems sollte sich in die bestehende Testumgebung einfügen, sodass durch das Einsatzsystem möglichst keine neuen Wartezeiten künstlich erzeugt werden. Bei der ersten sowie der zweiten Stufe sollte die Laufzeit keine großen Auswirkungen haben, sodass die Überprüfung eines Testplans nur einen Bruchteil der Zeit in Anspruch nimmt, die ein Entwickler benötigt um diesen Testplan zu erzeugen, das heißt, dass eine möglichst nahe Ausgabe einer Fehlermeldung erfolgen soll. In der dritten Stufe wird, ein "Optimaler Ablauf für jedes Fahrzeug zur Laufzeit" direkt am Prozessort erzeugt. Daher sollte sich diese Laufzeit in den bestehenden Prozess einfügen. 3.2 Abfolgenformate Eine Abfolge besitzt ein spezifisches Format, siehe Kapitel Testplan, welches sich von den verschiedenen Abfolgetypen unterscheidet. Aus diesem Format sind sowohl der Typ der Abfolge als auch die beteiligten Komponenten, welche mit dieser Abfolge angesprochen werden, zu erkennen. Mit welcher Test- bzw. Konfigurationsroutine die Komponenten angesprochen werden, wird über den Bezeichner sichergestellt. Dieser dient als Beschreibung der Funktionalität der Abfolge. Anhand von diesen Informationen können die Abhängigkeiten der Abfolgen untereinander in den folgenden Abschnitten spezifiziert werden. Falls die Syntax im Testplan mit der angegebenen Syntax übereinstimmt, aber die Semantik keinen Sinn ergibt, so muss dies vom System erkannt und ein Fehler angezeigt werden. Da es in einem Testplan aufgrund von Designfehlern beim Erzeugen eines Testplans dazu kommen kann, dass Abfolgen in einer falschen Syntax vorliegen, muss eine aussagekräftige Warnung ausgegeben und diese Abfolgen für die weitere Verifikation des Testplans ignoriert werden, da eine korrekte Zuordnung der verwendeten Komponenten und des Bezeichners nicht möglich ist. Daher werden diese falschen Abfolgen beim Verifizieren der Abhängigkeiten zwischen Abfolgen und Komponenten und weiteren Anforderungen ignoriert, jedoch ein Fehler für die falsche Modellierung des Testplans angezeigt. 17

28 18 3. Anforderungen 3.3 Diagnosebereite und verbaute Komponenten an Prozessorten Eine Komponente eines Fahrzeuges ist nur an einer bestimmten Menge von Prozessorten diagnosebereit bzw. verbaut. Falls eine Abfolge in einem Testplan an einem Prozessort eine Fahrzeug- Komponente ansprechen möchte, welche nicht vorhanden oder diagnosebereit ist, kann es zu direkten Fehlern der angesprochenen Abfolge oder zu indirekten Fehlern aufgrund möglicher kausaler Beziehungen zu anderen Abfolgen kommen. Damit diese Fehlerquellen ausgeschlossen werden, wird eine weitere Anforderung an die Verifikation der Testpläne gestellt, sodass an einem Prozessort, an dem ein bestimmter Testplan ausgeführt wird, bekannt sein muss, ob alle Komponenten, die in diesem Testplan angesprochen werden, auch an diesem Prozessort diagnosebereit bzw. verbaut sind. Dabei gilt die Regel, dass alle Komponenten, welche an einem früheren Prozessort diagnosebereit bzw. verbaut waren, auch an den nachfolgenden Prozessorten diagnosebereit bzw. verbaut sind. 3.4 Abfolgen und ihre Vorbedingungen Durch die Zuweisung eines Wertes einer Variable durch eine Abfolge kann eine Abfolge verschiedene Konfigurationen für zeitlich später gesehene Abfolgen vornehmen. Abfolgen können bestimmte Vorbedingungen besitzen, welche in Relation mit den Variablen eines Testplans stehen. So kann zum Beispiel eine Abfolge A nur ausgeführt werden, wenn die Variable Zündung des Fahrzeuges auf wahr steht, also die Zündung des Fahrzeuges eingeschaltet ist. Bei der Verifikation des Testplans muss geprüft werden, ob eine bestimmte Abfolge anhand ihrer Vorbedingungen ausgeführt werden kann. Ist dies nicht der Fall, muss eine Fehlermeldung ausgegeben werden. 3.5 Logischer-Ausdruck-Satz bei Verzweigungen im Testplan Da der Testplan für eine Modellreihe erstellt wird, sind alternative Pfade im Testplan für die einzelnen Modelle vorhanden. Diese werden durch einen sogenannte Logischer-Ausdruck-Satz (LAS) für das bestimmte Modell zur Laufzeit ausgewählt. Bei diesen Verzweigungen wird lediglich ein Pfad weiter verfolgt, wodurch der andere Pfad logischerweise ignoriert wird. Durch das exklusive Ausführen eines Pfades, entstehen zwei Mengen von Abhängigkeiten im Testplan. Da es beim Erstellen von Testplänen zu Fehlern kommen kann und davon der LAS nicht verschont bleibt, muss der LAS auf Korrektheit überprüft werden, sodass nur Fahrzeug-Optionen in diesem LAS vorkommen, welche auch in der zu prüfenden Modellreihe verfügbar sind. Zum anderen muss der LAS, welcher ein boolescher Ausdruck ist, darauf hin überprüft werden, ob dieser ein Modell hat oder nicht. Hätte der LAS kein Modell, sowohl mit als auch ohne dessen Einschränkungen, so würde der Pfad, welcher bei einer Auswertung des LAS als wahr betreten werden sollte, niemals ausgewählt. Da dies eine inkorrekte Modellierung des Testplans darstellt, muss der LAS überprüft werden. 3.6 Gleichzeitige offene Verbindungen zu Steuergeräten Da ein Testplan und somit die Abfolgen an einem Computer ausgeführt werden und dieser mit den Steuergeräten kommunizieren muss, werden für den Transport der Pakete von Computer zu Steuergerät sogenannte Kommunikationsprotokolle [Sha08], auch Protokolle genannt, benutzt. Durch diese Protokolle 1 wurde eine Vereinbarung getroffen, nach der die Datenübertragung zwischen zwei oder mehreren Parteien abläuft. 1 Ein Protokoll ist ein Kommunikationsprotokoll für den Austausch von Daten zwischen Computern, die in einem Rechnernetz miteinander verbunden sind. Die Vereinbarung besteht aus einem Satz von Regeln und Formaten (Syntax), die das Kommunikationsverhalten der kommunizierenden Instanzen in den Computern bestimmen (Semantik). 18

29 3.7. Abhängigkeiten 19 Bei dieser Arbeit wurden von den Abfolgen zwei verschiedene Protokolle zum Diagnostizieren der Steuergeräte verwendet, zum einen das UDS 2 und zum anderen das KWP Protokoll [ZS11]. Aufgrund derzeit vorgegebener technischer Rahmenbedingungen können maximal 14 Steuergeräte parallel diagnostiziert werden. Von diesen 14 Verbindungen dürfen wiederum maximal 10 Verbindungen von einem bestimmten Protokoll gehalten werden. Korrekte Anzahl gleichzeitig offener Verbindungen: Anzahl aller offenen Verbindungen <= 14 Anzahl offener Verbindungen UDS <= 10 Anzahl offener Verbindungen KWP2000 <= Abhängigkeiten Abfolgen untereinander haben bestimmte Abhängigkeiten, welche beim Verifizieren der Testpläne eine große Bedeutung haben. Es gibt zum Beispiel Abfolgen, die aufeinander aufbauen und somit in strikt sequentieller Reihenfolge ausgeführt werden müssen und Abfolgen, die zu anderen Abfolgen nicht parallel ausgeführt werden dürfen, da es sonst zu Komplikationen zwischen den Steuergeräten oder deren LIN-Teilnehmern kommen kann. In den nächsten Abschnitten werden diese Abhängigkeiten zwischen den Abfolgen beschrieben und eingeordnet Abhängigkeiten zwischen Abfolgen Die speziellste aller Abhängigkeiten ist die Abhängigkeit zwischen Abfolgen. Diese beinhaltet nicht nur die allgemeineren Abhängigkeiten zwischen Steuergeräten (Kapitel 3.7.2) und Bezeichner (Kapitel 3.7.3) sondern auch die Kombinationen dieser beiden Abhängigkeiten. Konkret bedeutet dies, dass eine Abfolge sowohl anhand ihres Bezeichners als auch der Steuergeräte und LIN-Teilnehmer keine Konflikte auslösen darf. Unter diese Art von Abhängigkeiten zwischen kompletten Abfolgen fallen die in der Tabelle 3.1 genannten Abhängigkeiten. Name Sequentiell davor Optional sequentiell davor Sequentiell danach Sequentiell danach mit Abstand Nicht parallel Beschreibung Wenn eine Abfolge A im Testplan vorhanden ist, muss eine Abfolge B sequentiell vor der Abfolge A erscheinen. Wenn eine Abfolge A sowie eine zweite Abfolge B im Testplan vorhanden sind, muss die Abfolge B sequentiell vor der Abfolge A erscheinen. Falls die Abfolge B nicht vorhanden ist, tritt diese Abhängigkeit nicht in kraft. Wenn eine Abfolge A im Testplan vorhanden ist, muss eine Abfolge B sequentiell nach der Abfolge A erscheinen. Wenn eine Abfolge A im Testplan vorhanden ist, darf eine Abfolge B nicht innerhalb der nächsten n Abfolgen sequentiell nach der Abfolge A erscheinen. Eine Abfolge A darf nicht parallel zu einer Abfolge B ausgeführt werden. Tabelle 3.1: Abhängigkeiten zwischen Abfolgen Wie diese zwei allgemeineren Anforderungen, die Abhängigkeiten zwischen Steuergeräten und Bezeichnern, aussehen, wird in den nächsten zwei Kapiteln besprochen. Dabei ist zu beachten, dass bei der Verifikation pro Abfolge jede dieser drei Abhängigkeiten überprüft werden muss. Sofern es keine Abhängigkeit zwischen zwei Abfolgen gibt, bedeutet dies nicht, dass es keine Abhängigkeit zwischen den Steuergeräten dieser Abfolgen gibt. 2 Unified Diagnostic Services 3 Key-Word-Protokoll

30 20 3. Anforderungen Abhängigkeiten zwischen Steuergeräten Bei den Steuergeräten und deren LIN-Teilnehmern wird aus technischen Gründen eine Anforderung deklariert, welche es nicht zulässt, auf mehrere Steuergeräte oder denselben LIN-Teilnehmer parallel zugreifen zu können. Ein einfaches Beispiel ist, wenn zwei Abfolgen, welche parallel geschaltet sind, dasselbe Steuergerät oder LIN-Teilnehmer oder jeweils eins von beidem diagnostizieren wollen. Dies ist aufgrund der physikalischen Struktur des LIN-Busses der Steuergeräte nicht möglich und darf deshalb in keinem Testplan vorhanden sein. Ähnlich ist dies bei identischen Steuergeräten, welche in einer parallelen Struktur zueinander stehen. Zudem wurden in der Automobilindustrie weitere Steuergeräte identifiziert, welche durch parallelen Zugriff mit anderen Steuergeräten zu Problemen führen. Auch diese parallele Anordnung der Steuergeräte muss vorzeitig beim Verifizieren des Testplans erkannt und ausgegeben werden. Parallele Einschränkungen von Steuergeräten kurz zusammengefasst: Dasselbe Steuergerät oder LIN-Teilnehmer dürfen nicht parallel diagnostiziert werden Ein Steuergerät darf nicht parallel zu seinem LIN-Teilnehmer diagnostiziert werden Bestimmte Steuergeräte dürfen nicht mit anderen Steuergeräten parallel diagnostiziert werden. Eine Liste dieser Steuergeräte wird durch die Automobilindustrie vorgegeben Abhängigkeiten zwischen Bezeichner Der Bezeichner beschreibt den Zweck einer Abfolge, welche ein oder mehrere Steuergeräte anspricht, wie in 2.3 angedeutet. Innerhalb dieser Bezeichner kommt es zu verschiedenen Abhängigkeiten, sodass eine bestimmte Abfolge in sequentieller Anordnung vor oder nach einer bestimmten anderen Abfolge des selben Steuergerätes mit einem anderen bestimmten Bezeichner kommen muss. Zum Beispiel kann man sich vorstellen, dass der Bezeichner Verbauprüfung, ob ein Steuergerät im Automobil verbaut wurde und korrekt angesprochen werden kann, in sequentieller Sicht vor einer Abfolge Anfrage an dieses Steuergerät im Testplan kommen muss. Dabei müssen die genannten Abfolgen das gleiche Steuergerät ansprechen. Ohne diese strikte sequentielle Reihenfolge könnte nicht gewährleistet werden, ob das Steuergerät im Fahrzeug verbaut ist oder nicht und es würde eventuell eine Anfrage an ein nicht verbautes Steuergerät gestellt. Die nachfolgende Tabelle 3.2 ähnelt stark der Tabelle 3.1, jedoch werden in dieser Tabelle allgemeinere Regeln, welche sich auf den Bezeichner innerhalb einer Komponente beziehen definiert, während bei der vorherigen Tabelle hingegen Regeln in Bezug auf die gesamte Abfolge definiert wurden. Eine Liste dieser Bezeichner und ihre Abhängigkeiten wird von der Automobilindustrie vorgegeben. Sequentielle Bedingungen des Bezeichners kurz zusammengefasst: Name Sequentiell davor Sequentiell danach Beschreibung Ein Bezeichner A einer Abfolge mit der Komponente C muss vor dem Bezeichner B einer Abfolge mit der Komponente C kommen. Ein Bezeichner A einer Abfolge mit der Komponente C muss nach dem Bezeichner B einer Abfolge mit der Komponente C kommen. Tabelle 3.2: Abhängigkeiten zwischen Bezeichnern einer Komponente 3.8 Schnittstellen zum Einbringen der Daten in das Modell Da die in den vorherigen Kapiteln genannten Anforderungen derzeit nicht maschinenlesbar zugänglich sind oder sogar noch nicht einmal im Prosa niedergeschrieben wurden, muss das Wissen über den Aufbau und die Strukturierung von Testplänen elektronisch erfasst und maschinell verarbeitbar gemacht werden. Anhand diesen Informationen wird der Testplan auf Korrektheit überprüft. Wichtig für die Anforderungen ist, dass mehrere Schnittstellen bereit gestellt werden, sodass diese Informationen sowohl maschinell als auch von Hand gefüllt und angepasst werden 20

31 3.8. Schnittstellen zum Einbringen der Daten in das Modell 21 können ohne dass weiteres Wissen, z.b. über die effektive Speicherung der Daten, vorhanden ist. Die Schnittstellen stellen eine abstrakte Sicht auf die Informationen dar und ermöglichen dem Anwender die Kommunikation zwischen diesen und der Außenwelt. Der Anwender sollte über diese Schnittstellen in der Lage sein, die genannten Informationen ohne konkretes Wissen über die Speicherung der übergebenen Daten zu befüllen, diese Daten zu verändern oder zu löschen. 21

32

33 4. Modellierung In den folgenden Abschnitten wird beschrieben, wie die Abhängigkeiten und Regeln, sowie die für die Testpläne und deren Einsatz wichtigen Informationen erfasst und maschinell verarbeitbar, für die Verifikation der Testpläne, zur Verfügung gestellt werden. Da es derzeit noch keine Datenbasis mit diesen Informationen gibt, wird eine Datenbasis der erhobenen Informationen von Testplänen und deren Einsatzumgebung aufgebaut. In den nächsten Abschnitten beschäftigen wir uns damit, alle Informationen für die erste Stufe, sowie alle derzeit bekannten Informationen für die zweite und dritte Stufe zu erheben (Kapitel Datenerhebung). In den darauf folgendem Abschnitten Formalisierung werden, aufbauend auf den erhobenen Daten, verschiedene Modelle entwickelt, welche sowohl das Regelwerk als auch Fakten abbilden werden. Letztendlich wird im Abschnitt Datenbankentwurf eine relationale Datenbank vorgestellt, welche die Modelle aus den vorrangegangenen Kapiteln mit all ihren Informationen, Fakten und Regeln abbilden wird. 4.1 Datenerhebung Die folgenden Informationen wurden anhand von weitreichenden Analysen von manuell erzeugten Testplänen in Bezug auf deren Abfolgen und den zugrundeliegenden Beziehungen zwischen den Abfolgen und Untersuchungen mit dem standardisieren Testplanformat OTX vorgenommen. Additiv zu diesen Erkenntnissen fanden über einen längeren Zeitraum, Gespräche, mit Experten aus der Automobilindustrie, statt. In diesen Gesprächen wurde das Wissen in den Köpfen der Testplanentwickler als weitere Erkenntnis gewonnen. Aus den relevanten Informationen wurden vier große Bereiche klassifiziert, welche sich durch deren Einsatz für die Verifikation der Testpläne abgrenzen. Der erste große Bereich beschreibt das Automobil bzw. das Fahrzeug-Projekt. In diesem Bereich wird das Fahrzeug mit allen relevanten Informationen zur Verifikation dargestellt. Der zweite große Bereich sind die Eigenschaften und Anforderungen der Abfolgen im Testplan (siehe Kapitel Testplan). Dieser Bereich beschäftigt sich ausschließlich mit den Abfolgen, der Beziehung der Abfolgen untereinander und, in Bezug auf die Fahrzeug-Komponenten, mit dem Fahrzeug-Projekt Bereichs. Der dritte Bereich beinhaltet die Informationen über die sogenannte "Test-Umgebung". Darunter fallen Informationen wie zum Beispiel das Werk, die Montagelinien in den Werken und die Prozessorte an einer Montagelinie, sowie deren Ressourcen und die Beziehung dieser zu den Abfolgen. Der vierte und letzte Bereich bezieht sich auf das Übertragen von Informationen auf das Automobil. Alle Bereiche im Überblick: Automobil Beinhaltet alle relevanten Informationen über das Fahrzeug-Projekt. Abfolgen Informationen über die Abfolgen und deren Beziehung untereinander. Test-Umgebung Hat alle Informationen über die Ortschaften, an denen die Testpläne ausgeführt werden. 23

34 24 4. Modellierung Softwareauslieferung Beschäftigt sich mit dem Übertragen von speziell für ein Fahrzeug zugeschnittener Software Das Automobil Bei der Erhebung der Informationen über das Automobil ergaben sich drei Bereiche. Da die Testpläne nicht nur von einem bestimmten Fahrzeugmodell getestet werden sollen, sondern die Testpläne von verschiedenen Fahrzeugen auf ihre Korrektheit geprüft werden und Fahrzeuge in Modellreihen gruppiert sind, müssen wir zuerst wissen, auf welches Fahrzeug und somit auf welche Modellreihe sich der Testplan bezieht. Unsere erste Information ist also, dass wir die Fahrzeuge in Modellreihen gruppieren und betrachten werden. Wie es in der Automobilindustrie seit Jahren üblich ist, hat der Kunde die Möglichkeit, sein Fahrzeug zu einem gewissen Grad selbst zusammen zu stellen zu können. Diese Möglichkeit wird ihm durch eine Vielzahl von Optionen geben, aus denen der Kunde aussuchen kann. Daraus folgt, dass Fahrzeuge sehr unterschiedlich in ihrer Ausführung sein können, denn jede Modellreihe hat eine Vielzahl von Optionen, die entweder fest in das Fahrzeug eingebaut werden müssen oder optional, also indirekt über den Kunden, ausgewählt werden. Eine Option wird durch eine PR- Nummer 1 angegeben und identifiziert ein bestimmtes Produkt, welches im Automobil verbaut werden soll. Die Optionen werden in sogenannte Familien geordnet, bei denen zu einem konkreten Fahrzeug genau eine Option aus einer Familie ausgewählt werden muss. Sollte es der Fall sein, dass keine Option aus einer Familie gewählt werden soll, so gibt es die Option "keine Option ausgewählt" in jeder Familie. Zur besseren Verständnis der Optionen hier ein Beispiel: Der Kunde hat die Möglichkeit zwischen einem normalen Radio mit geringer Ausstattung oder einem erweiterten Radio mit besserer Ausstattung zu wählen. Bei Letzterem beinhaltet die Ausstattung zudem ein GPS-Navigationsgerät 2, welches eine zusätzliche Komponente im Fahrzeug für den GPS-Empfang erfordert. Sowohl das normale Radio als auch das erweiterte Radio haben bestimmte PR-Nummern und sind zusammen in einer Familie eingeordnet, welche zu dem Fahrzeug aus einer bestimmten Modellreihe gehört. Aus dieser Familie muss der Kunde genau eine Option auswählen. Wählt der Kunde nun das erweiterte Radio mit der GPS-Komponente muss zudem die GPS-Komponente im Auto verbaut werden. Die Komponenten eines Fahrzeuges gestalten den letzten Bereich des Automobils. Die Komponente kann zu einer festen Option gehören und muss in jedes Fahrzeug verbaut werden, oder zu einer optionalen Option gehören und nur durch eine bestimmte Bedingung in das Fahrzeug verbaut werden. Diese Bedingung wird in einem "LAS" Ausdruck gespeichert, welcher aus boolesch zusammengesetzten PR-Nummern (Optionen) besteht. LAS steht für "Logischer-Ausdruck- Satz" und beschreibt, unter welchen Bedingungen eine Komponente im Fahrzeug verbaut werden muss. Eine Komponente muss genau dann verbaut werden, wenn sich der LAS aufgrund des Fahrzeugdatensatzes eines konkreten Fahrzeuges als wahr ausgewertet lässt. Eine PR-Nummer, welche in dem booleschen LAS als Variable angesehen wird, wird genau dann der Wahrheitswert wahr zugeordnet, wenn diese PR-Nummer im Fahrzeug Datensatz vorhanden ist. Wenn zum Beispiel in einem Fahrzeugdatensatz, der beschreibt, welche Optionen in einem konkreten Fahrzeug verbaut werden müssen, die PR-NUMMER 1kd vorhanden ist, dann bedeutet dies, dass bei den hinteren Rändern Scheibenbremsen eingebaut werden müssen, da 1kd als Schlüssel für den Ausdruck "Scheibenbremse hinten" steht. Weitere Bedingungen für den Verbau einer Komponente sind die Eigenschaften "Einsatz" und "Entfall", welche ein Datum beinhalten, ab dem diese Komponente verbaut werden kann ("Einsatz") und/oder ab welchem Datum sie nicht mehr verbaut werden darf ("Entfall"). Diese Eigenschaften können eingesetzt werden um alte Komponenten im laufenden Betrieb gegen neue auszutauschen, indem im LAS beide Komponenten verodert vorhanden sind und der Entfall der alten Komponente auf den Einsatz der neuen Komponenten fällt. Weitere Eigenschaften einer Komponente sind der Name, das Kürzel und die Lage der Komponente im Fahrzeug. Die Lage kann zudem in Stufe zwei zur Optimierung des Testplans anhand des Laufweges des Werkers (Mitarbeiter in einem Werk) eingesetzt werden. 1 Produktnummer 2 Global Positioning System 24

35 4.1. Datenerhebung 25 Komponenten in einem Testplan können, wie in den Anforderungen (Kapitel Anforderungen) gezeigt wurde, Abhängigkeiten untereinander besitzen. Diese Abhängigkeit ist eine der zentralen Bestandteile für die Verifikation des Testablaufs einer Modellreihe. Da es nicht nur eine bestimmte Abhängigkeit zwischen Komponenten geben muss, werden die Abhängigkeiten in Arten unterteilt. Jede Art hat bestimmte Eigenschaften, welche für die spätere Unterscheidung der Verifizierungsart wichtig ist. Zum Beispiel kann eine Art das nicht parallele und eine weitere Art eine strikt sequentielle Ausführung von Abfolgen sein. Eine Komponente kann entweder ein "Steuergerät" oder "Kein Steuergerät" sein. Ein Steuergerät ist ein Mikrocontroller [Rot02], der digital angesprochen werden kann, um von diesem Informationen zu bekommen oder an diesen zu übergeben. Um mit einem Steuergerät kommunizieren zu können, wird ein Protokoll verwendet. Im Kapitel Gleichzeitige offene Verbindungen zu Steuergeräten wurde bereits darauf eingegangen, dass es derzeit zwei verschiedene Protokolle gibt, welche in der Automobilindustrie eingesetzt werden. Zum einen das UDS und zum anderen das KWP2000 Protokoll. Da es zwei disjunkte Mengen von Steuergeräten gibt, die jeweils nur über ein bestimmtes Protokoll angesprochen werden können, ist über jedes Steuergerät bekannt, mit welchem Protokoll es angesprochen werden kann. Steuergeräte sind zudem im Master-Slave Prinzip aufgebaut. Dieses Prinzip erspart es, mehrfach vorkommende Funktionalitäten redundant in Steuergeräte zu implementieren. Um diese Redundanz zu umgehen, wird eine mehrfach vorkommende Funktionalität lediglich im Master realisiert, auf welche die Slaves dieses Masters zugreifen können. Unter den Komponenten, die nicht zu den Steuergeräten gehören, befinden sich mechanische Komponenten, die sich stark von Steuergeräten unterscheiden und nicht digital angesprochen werden können. In diese Kategorie fallen zum Beispiel Türen und Reifen. Informationen des Automobils auf einen Blick: Fahrzeuge werden in Modellreihen gruppiert. Eine Modellreihe hat eine Vielzahl von Optionen. Eine Option hat eine PR-Nummer. Optionen werden in Familien gruppiert. Eine Familie von PR-Nummern wird selbst als PR-Nummer dargestellt. Aus einer Familie muss genau eine Option ausgewählt werden. Ein Fahrzeug besitzt mindestens eine Komponente. Eine Komponente hat: einen Namen. ein Kürzel. eine Lage. einen optionalen LAS. Einsatz. Entfall. einen Master und ist ein Slave oder ist ein Master. Eine Komponente kann eine Abhängigkeit zu einer anderen Komponente besitzen. Komponenten können Steuergeräte oder "Keine Steuergeräte" sein. Über den LAS einer Komponente werden Rückschlüsse über deren Verbau geschlossen. 25

36 26 4. Modellierung Die Abfolgen Abfolgen und die Spezialisierung zu "funkionalen" Abfolgen wurden im Kapitel 2.3 Testplan geklärt. Für das Aufstellen des Modells werden in diesem Kapitel alle relevanten Informationen beschrieben. Eine Abfolge besitzt einen Bezeichner, welcher eine Kurzbeschreibung über die Funktionalität der Abfolge angibt, und greift auf 1 bis n Komponenten zu. Der Bezeichner hat zudem in der Verifikationsphase eine wichtige Bedeutung, denn über diesen Bezeichner werden bestimmte Abhängigkeiten definiert (siehe Kapitel Abhängigkeiten zwischen Bezeichner) und verifiziert. Eine solche Abfolge beinhaltet 1 bis n Schritte, die für das Verifizieren der Testpläne nicht von Bedeutung sind. Aber genau diese Schritte können auf Komponenten zugreifen. Dabei ist zu unterscheiden, dass in einer "normalen" Abfolge immer genau auf eine und in einer "funktionalen" Abfolge auf 1 bis n Komponenten zugegriffen wird. Eine weitere Abhängigkeit, die in den Anforderungen im Kapitel 3.7 beschrieben wurde, ist die Abhängigkeit zwischen einer Abfolge mit bis zu n anderen Abfolgen, wobei sich diese Abhängigkeit sowohl auf das Steuergerät als auch den Bezeichner beziehen kann. Wie bereits angesprochen wurde, sind Abfolgen in der Lage mit dem Fahrzeug zu kommunizieren und können in den meisten Fällen autonom, ohne Eingreifen eines Werkers, abgeschlossen werden. Bei einigen Abfolgen ist dies jedoch nicht der Fall und ein Eingreifen eines Werkers zur korrekten Terminierung der Abfolge ist zwingend notwendig. Beim Anlernen der Fahrzeugschlüssel an ein bestimmtes Fahrzeug zum Beispiel, muss der Werker die Schlüssel, die von Werk aus an kein bestimmtes Fahrzeug gebunden sind, zum Anlernen an die vorgesehene Schnittstelle des Fahrzeuges halten. Erst wenn die Schlüssel an der Position angelegt sind, kann die Abfolge die Schlüssel für das Fahrzeug anlernen. Analog zu den Komponenten aus dem Automobil besitzen Abfolgen eine Eigenschaft, welche über die Fahrzeug-Optionen eines Fahrzeugdatensatzes die Ausführung einer Abfolge anstoßen oder verweigern kann. Dies wird über den LAS geregelt. Es wird gerade dann eine Abfolge ausgeführt, wenn der LAS als wahr ausgewertet wird. Weitere Eigenschaften, um die Ausführung einer Abfolge anzustoßen bzw. zu verweigern, ist der Einsatz und Entfall. Diese werden durch ein Datum repräsentiert und sind analog zum Einsatz und Entfall der Komponenten definiert. Der LAS sowie der Einsatz und Entfall sind zum Zeitpunkt dieser Arbeit in der Praxis nicht vorhanden, werden aber aufgrund von langfristiger Konsistenzerhaltung eingeführt und können eventuell schon ab der zweiten Stufe zur Optimierung der Testpläne hilfreich sein. Die Vorbedingungen werden über Zustände bestimmter Variablen gesteuert, welche der Modellreihe zugeordnet sind, und können von Abfolgen sowohl erfordert als auch verändert werden. Darunter fallen Zustände wie zum Beispiel: eine Abfolge darf nur dann ausgeführt werden, wenn die Zündung des Fahrzeuges ein- oder ausgeschaltet ist oder das Panoramadach an einer vordefinierten Position steht. Da ab der zweiten Stufe des Einsatzsystems anhand von Erfahrungswerte der Abfolgen eine Optimierung des Testplans vorgenommen werden soll, werden diese Informationen vorsorglich erhoben. Zu den Informationen zählt die Durchschnittliche Dauer, welche eine durchschnittliche zeitliche Dauer der Abfolge während der Prüfung in einem Testplan, und die Verbaurate, welche die Anzahl der Vorkommen dieser Abfolge in den Testplänen, wiederspiegelt. Informationen der Abfolgen auf einen Blick: Eine Abfolge greift auf genau eine Komponente zu. Die spezialisierte funktionale Abfolge hat mindestens zwei Komponenten. Abfolgen werden nur dann ausgeführt, wenn ihre Vorbedingungen eines Zustandes, der LAS, Einsatz und Entfall nicht verletzt wurden. Zustande gehören zu einer bestimmten Modellreihe. Eine Abfolge hat Abhängigkeiten zu anderen Abfolgen über: ihren Bezeichner. ihre Steuergeräte. ihre Steuergeräte und Bezeichner. 26

37 4.1. Datenerhebung 27 Es gibt Abfolgen die Ressourcen für die korrekte Terminierung benötigen. die Zustände verändern können. die bestimmte Zustände zur Ausführung benötigen können. Eine Abfolge hat: einen Bezeichner. einen optionalen LAS. Einsatz. Entfall. Ehrfahrungswerte Durchschnittliche Dauer Verbaurate Ein Zustand hat: einen Namen. einen prozessortübergreifenden Initialwert Die Test-Umgebung Bei der Test-Umgebung handelt es sich um den konkreten Ort, an dem die Testpläne am Automobil durchgeführt werden. Dieser Prozessort ist einer Hierarchie unterworfen. Auf der obersten Ebene ist das Werk, in dem eine bestimmte Anzahl von Montagelinien vorhanden ist. Dieser Montagelinien bestehen aus bis zu n verschiedenen Prozessorten, welche die unterste Ebene der Hierarchie darstellen. Da sich die Werke aufgrund der geographischen Lage und damit verbundenen unterschiedlichen Gebäudearten und -formen sowie länderspezifischen Vorschriften stark voneinander unterscheiden und dadurch die Montagelinien und letztendlich die Prozessorte, der Ort an dem der Testplan an einem Automobil durchgeführt wird, davon betroffen sind, kann es nicht den einen Prozessort in jedem Werk geben, bei dem ein bestimmter Testplan durchgeführt werden kann. Aufgrund der verschiedenen Ausstattung und weiteren besonderen Merkmalen der Prozessorte muss für jeden einzelnen Prozessort in den Werken zum Beispiel bekannt sein, welche Komponenten an einem Prozessort diagnosebereit bzw. verbaut sind oder nicht und über welche Ressourcen dieser Prozessort verfügt, sodass zum Beispiel bei der Verifikation von Testplänen bekannt ist, ob eine Komponente, auf die an einem Prozessort zugegriffen werden soll, auch diagnosebereit ist oder nicht und ob eine bestimmte Prüftechnik an diesem Prozessort vorhanden ist. Auch die Montagelinien können pro Werk aus unterschiedlichen Prozessorten bestehen und sich sowohl in der Anzahl der Prozessorte als auch deren Reihenfolge und Ausstattungen stark unterscheiden. Aus diesen Gründen muss für jeden Prozessort bekannt sein, an welcher Montagelinie und in welchem Werk dieser positioniert ist. Um ein Werk eindeutig identifizieren zu können, hat dieses eine eindeutige Nummer, eine Kurzbezeichnung und einen Standort. Eine Montagelinie eines Werkes wird lediglich durch dessen Namen beschrieben. Dieser Name ist unter alle Montagelinien eindeutig. Eine Montagelinie ist zudem genau einem Werk zugeordnet. Ein Prozessort wird, wie die Montagelinie, eindeutig durch einen Namen identifiziert und muss genau einer Montagelinie zugeordnet sein. Außerdem ist innerhalb einer Montagelinie eine sequentielle Reihenfolge der Prozessorte, über den nachfolgenden Prozessort, vorhanden. Diese sequentielle Reihenfolge beinhaltet keine Zyklen oder ähnliche Formen, sondern wird als einfache Liste angesehen. Um an einem Prozessort bestimmte Abfolgen ausführen zu können, werden unter Umständen Ressourcen an diesem Prozessort benötigt. Dabei kann es sich zum Beispiel um ein Mobile Prüfstation 7 (MPS7) (siehe Abbildung 4.1) handeln. Da eine Ressource in mehrfacher Ausführung an einem Prozessort bereitstehen kann, 27

38 28 4. Modellierung wird für eine Ressource, unter die auch ein Werker fällt, das Vorkommen der Ressource angegeben. Sind von einem Typ, zum Beispiel dem Prüfsystem MPS7, alle Vorkommen an einem Prozessort parallel in Gebrauch oder eine bestimmte Ressource an einem Prozessort nicht vorhanden, so kann dies beim Verifizieren des Testplans erkannt werden. Ein Prozessort beeinflusst den Initialwert eines Zustandes in einem Testplan, welcher während einer Ausführung eines Testplans von Abfolgen erfordert bzw. verändert werden kann, indem dieser prozessortspezifisch gesetzt werden kann, sodass Zustände, welche an einem vorherigen Prozessort gesetzt wurden, übernommen werden können. Zustände, die keine prozessortspezifische Initialisierung erhalten, werden auf den Wert undefiniert gesetzt. Abbildung 4.1: Mobile Prüfstation MPS 7, Quelle: [AG12] Eine weitere Information, welche eine Beziehung zwischen dem Automobil und der Test-Umgebung darstellt, ist, ob eine bestimmte Komponente des Fahrzeuges an einem bestimmten Prozessort diagnosebereit oder verbaut ist. Wobei sich diagnosebereit auf die Steuergeräte und verbaut auf Nicht Steuergeräte bezieht. Ein Steuergerät ist genau dann diagnosebereit, wenn es in das Fahrzeug eingebaut und verkabelt wurde und zur Kommunikation bereit ist. Ein Nicht Steuergerät ist genau dann verbaut, wenn es an das Fahrzeug montiert wurde. Dabei ist eine Komponente an mindestens einem Prozessort unter der Bedingung optionaler Ressource diagnosebereit/verbaut und an einem Prozessort unter der Bedingung der Ressourcen und weiteren Eigenschaften mindestens eine Komponente diagnosebereit/verbaut. Anhand der verfügbaren Ressourcen sowie der Information, ob eine Komponente des Fahrzeuges an einem bestimmten Prozessort diagnosebereit (Steuergerät) oder verbaut ( Nicht Steuergerät ) ist, lassen sich Rückschlüsse auf die Ausführbarkeit eines Testablaufs innerhalb eines Prozessortes schließen. Informationen der Test-Umgebung auf einen Blick: Ein Werk hat eine eindeutige Nummer. eine Kurzbezeichnung. einen Standort. mindestens eine Montagelinie. Eine Montagelinie hat einen eindeutigen Namen. ist genau einem Werk zugeordnet. hat mindestens einen Prozessort. Ein Prozessort hat einen eindeutigen Namen. ist genau einer Montagelinie zugeordnet. kann einen nachfolgenden Prozessort haben. 28

39 4.2. Formalisierung 29 kann Ressourcen halten. hat verbaute / diagnosebereite Komponenten unter der Bedingung der Ressourcen / Eigenschaften. hat prozessortbezogene Zustände mit Initial- und Endwert aus den Abfolgen. Eine Ressource hat einen eindeutigen Namen. gehört zu einem Prozessort. kann maximal n parallele Zugriffe haben Die Softwareauslieferung Dieser Bereich beinhaltete in der Anfangsphase dieser Arbeit einen hohen Stellenwert. Doch umso weiter diese Arbeit vorrangeschritten ist, wurde klar, dass das Augenmerk auf den bereits vorgestellten Bereichen liegt. Aus diesem Grund wird in dieser Arbeit nur aufgezeigt, dass dieser Bereich bereits angedacht wurde sowie dessen Informationen dargestellt. Bei der Softwareauslieferung soll eine Abfolge in der Lage sein, Informationen in einem zeitlich definierten Fenster versenden zu können. Diese Fenster sind durch einen Start- und Endpunkt definiert. Die Software besteht aus einzelnen Software-Komponenten, die zu einem Software-Paket zusammengesetzt werden. Informationen der Softwareauslieferung auf einen Blick: Abfolge benutzt Software-Paket Software-Paket besteht aus Software-Komponenten Ein Software-Paket kann in einem Zeitlichen Fenster ausgeliefert werden. Ein Zeitliches Fenster hat einen Start- und Endpunkt. 4.2 Formalisierung Aus der Basis der gesammelten Informationen der vorherigen Abschnitte werden nun vier Modelle vorgestellt, welche die einzelnen Bereiche und deren Beziehungen untereinander abbilden werden. Dabei beschäftigen wir uns mit dem Automobil-, Abfolgen-, Test-Umgebungs- und dem Software-Auslieferungs-Modell. Alle kommenden Modelle dieses Kapitels wurden als Entity-Relationship-Modell (ER-Modell) nach Peter Chen [Che76] entworfen. Das ER-Modell bietet die Konzepte Entität und Beziehung an. Eine Entität repräsentiert ein für den modellierten Ausschnitt wichtiges Umweltobjekt mit Attributen zur näheren Beschreibung und Beziehungen (sog. Relationships) dienen der Modellierung der Zusammenhänge zwischen Entitäten. Als Notationstil zur Beschreibung der Kardunalitäten der Beziehungen, wurde die Min-Max- Notation [Eic06a] verwendet, da die Chen-Notation nur beschränkte Aussagen zu einer Beziehung erlaubt. Mit der (min,max)-notation können sowohl untere als auch obere Schranken ausgedrückt werden Automobil-Modell Aufbauend auf den Informationen, die durch die Erhebung des Automobils im Kapitel gesammelt wurden, wird in diesem Kapitel die für die Testpläne und ihren Einsatz relevanten Ausschnitt der Realwelt modelliert. Da bekannt ist, dass es mehrere Modellreihen geben kann, welche einzeln als Fahrzeug-Projekt angesehen werden, verpacken wir dieses Attribut als String in die Entität Fahrzeug-Projekt. Eine weitere wichtige Information ist, dass ein Fahrzeug-Projekt mindestens eine Fahrzeug-Komponente besitzt und dass eine Komponente entweder ein Steuergerät oder ein Nicht Steuergerät ist. Aus diesen Informationen extrahieren wir die weiteren Entitäten: Zum einen die Fahrzeug-Komponente, zum anderen die Steuergeräte und die 29

40 30 4. Modellierung Nicht Steuergeräte. Aufgrund der Tatsache, dass die Fahrzeug-Komponenten eine Generalisierung der zwei zuletzt genannten Entitäten ist, werden diese als Spezialisierung der Fahrzeug- Komponenten in das Modell aufgenommen. Da die Fahrzeug-Komponente nur aus den zwei Spezialisierungen besteht, wird diese Entität als abstrakte Entität deklariert. Die Fahrzeug-Komponente besitzt für alle Spezialisierungen wichtige Attribute, sodass diese nicht redundant im Modell vorkommen müssen. Aus der Datenerhebung in Kapitel 4.1 sind die Attribute für die Komponenten bereits bekannt, sodass diese direkt übernommen werden können. Attribute der Fahrzeug-Komponente : Name Kürzel Lage Einsatz Entfall Der LAS, Logischer-Ausdruck-Satz, wird nicht als Attribut, sondern als neue Entität aufgrund der Informationen, dass ein LAS wiederum andere LAS beinhalten kann, in das Modell aufgenommen. Wie diese Hierarchie der LAS in das Modell einfließt und die Beziehungen zwischen dem LAS und anderen Entitäten sind, wird zu einem späteren Zeitpunkt dieses Abschnittes dargelegt. Die genannten Attribute decken sich vollständig mit den Attributen der Nicht Steuergeräte, wodurch diese Entität keine weiteren Attribute erhält. Die Steuergeräte hingegen kommunizieren unter anderem über Protokolle mit einem Mobilen Prüfsystem. Deshalb muss bekannt sein, mit welchem Protokoll die Steuergeräte angesprochen werden können. Aus diesem Grund erhält die Entität Steuergerät das Attribut Protokoll. Außerdem wurde in den erhobenen Informationen festgehalten, dass ein Steuergerät ein Master oder ein Slave sein kann. Diese Information wird als reflexive Beziehung der Steuergeräte realisiert, wobei ein Steuergerät maximal einen Master hat und ein Master 1 bis n Slaves haben darf. Weiter ist bekannt, dass eine bestimmte Modellreihe mindestens eine Option haben muss. Aus dieser Information wird die letzte Entität Fahrzeug-Optionen erzeugt, welche mit der Information Eine Option hat eine PR-Nummer das Attribut PR-Nummer vom Typ String erhält. Es wurden somit sechs Entitäten aus dem Automobil-Modell identifiziert, welche in der nachfolgenden Liste sowie in der Abbildung 4.2 mit ihren Attributen und Spezialisierungen dargestellt werden: Fahrzeug-Projekt Fahrzeug-Komponente (abstrakt) Steuergerät Nicht-Steuergerät Fahrzeug-Optionen Logischer-Ausdruck-Satz Da nun alle Entitäten des Automobil-Modell s bekannt sind, werden diese anhand der gegebenen Informationen miteinander in Beziehung gesetzt. Als erste Beziehung aus den Informationen im Kapitel ist Eine Modellreihe hat eine Vielzahl von Optionen zu nennen. Dadurch wird die Beziehung hat von Fahrzeug-Projekt zu Fahrzeug-Optionen erzeugt, bei der in bidirektionaler Richtung jeweils die Kardinalitäten 1 bis n gesetzt werden, denn jede Entität dieser Beziehung benötigt mindestens ein Objekt der anderen Entität. Würde diese Beziehung mit einer 0-Kardinalität beschrieben werden, so könnte es Fahrzeug-Projekt ohne Fahrzeug-Optionen ausgestattet sein. Dies ist aber aus den Informationen aus dem vorherigen Abschnitt nicht legitim. Da eine Option in Familien gruppiert wird und auch Eine Familie als PR-Nummer dargestellt wird, erhält die Entität Fahrzeug-Optionen eine reflexive Beziehung namens Familie, mit dem Attribut Name, welches die Familien identifiziert. Die Kardinalitäten müssen aufgrund der Tatsache, dass eine PR-Nummer nicht zwingend in einer Familie vorkommen kann, mit dem Rollennamen gehört zu auf 0 bis 1 gesetzt werden. So können auch speziellere PR-Nummern, 30

41 4.2. Formalisierung 31 Fahrzeug Komponente (abstrakt) Name : String Kürzel : String Lage : String Einsatz : Datum Entfall : Datum Fahrzeug Projekt Modellreihe : String Fahrzeug Optionen PR-Nummer : String Ist eine Ist eine Steuergeräte Protokoll : String LIN : boolean Nicht Steuergeräte Logischer-Ausdruck-Satz Abbildung 4.2: Automobil-Modell Entitäten die bei Sonderaktionen eingesetzt werden und nicht sinnvoll in einer Familie gruppiert werden können, angelegt werden. Eine Familie besteht hingegen aus mindestens einer Fahrzeug-Option, wodurch die Kardinalität 1 bis n gesetzt wird. Außerdem ist bei den Fahrzeug-Optionen, bei PR-Nummern aus Familien eine Einschränkung vorhanden, sodass Aus einer Familie [...] genau eine Fahrzeug-Option ausgewählt [muss]. Diese Information wird als Integritätsbedingung den Fahrzeug-Optionen hinzugefügt. Da der LAS als neue Entität eingeführt wird und bekannt ist, dass eine Fahrzeug-Komponente einen optionalen LAS besitzt, wird eine Beziehung beinhaltet zwischen der Fahrzeug-Komponente und der Logischer-Ausdruck-Satz erzeugt, wobei eine Fahrzeug-Komponente maximal einen LAS beinhaltet, woraus folgt, dass die Kardinalität bei dem Logischen-Ausdruck-Satz auf 0 bis 1 gesetzt wird. Auf der entgegengesetzten Richtung ist ein LAS nicht an eine bestimmte Komponente gebunden, muss aber, falls er existiert, mindestens einer zugewiesen sein. Daraus folgt die Kardinalität 1 bis n an der Entität Fahrzeug-Komponente. Über die Entität Logischer-Ausdruck-Satz und Fahrzeug-Optionen wird ausgewählt, ob eine bestimmte Fahrzeug-Komponente verbaut wird oder nicht. Daher wird eine Beziehung beinhaltet zwischen der Logischer-Ausdruck-Satz und der Fahrzeug-Optionen benötigt. Die Kardinalitäten sind, dass eine Fahrzeug-Komponente 0 bis n Fahrzeug-Optionen haben darf. Die 0 tritt genau dann auf, wenn eine Fahrzeug-Komponente eine feste Option ist und immer verbaut werden muss. Dann wird der LAS nicht über einen Logischen-Ausdruck-Satz beschrieben, sondern direkt auf den Wert wahr gesetzt. Eine Fahrzeug-Option gehört zu mindestens einer Fahrzeug- Komponente. Denn eine Fahrzeug-Option, die zu keiner Fahrzeug-Komponente gehört, wird nicht berücksichtigt. Wie im Kapitel Abhängigkeiten zwischen Steuergeräten beschrieben wurde, gibt es Abhängigkeiten zwischen Steuergeräten. Um diese allgemeiner darstellen zu können, wird eine reflexive Beziehung abhängig mit dem Attribut Art auf die Entität Fahrzeug-Komponente erzeugt. Durch diese ist es sowohl möglich, eine Abhängigkeit innerhalb von Steuergeräten und Nicht Steuergeräten als auch im kartesischen Produkt 3 der beiden Entitäten zu erzeugen. Da nicht jede Fahrzeug-Komponente zwingend eine Abhängigkeit voraussetzt, wird die Kardinalität dieser Beziehung auf 0 bis n gesetzt. Das fertige Automobil-Modell, mit allen Entitäten und Beziehungen, kann in der Abbildung 4.3 betrachtet werden Abfolgen-Modell Anhand der Informationen des vorherigen Abschnittes wird das daraus entstandene ER- Modell vorgestellt. Zuerst beschäftigen wir uns mit den Entitäten. Diese sind bei diesem Modell, bis auf die Abfolge, nicht direkt aus den Informationen zu extrahieren. Da es verschiedene Abhängigkeiten unter Ab- 3 A B := {(a, b) a A, b B} 31

42 32 4. Modellierung gehört zu Fahrzeug Projekt Modellreihe : String (1,N) (1,N) hat besitzt Name : String Familie gehört zu (1,N) (0,1) Fahrzeug Option (1,N) PR-Nummer : String Art : String (1,N) (1,N) Fahrzeug Komponente (abstrakt) Name : String Kürzel : String Lage : String Einsatz : Datum Entfall : Datum Ist eine Ist eine (0,N) abhängig beinhaltet (0,1) beinhaltet (1,N) (0,N) Logischer-Ausdruck-Satz Integritätsbedingung: LAS beschreibt über die Fahrzeug Optionen ob eine bestimmte Fahrzeug Komponente verbaut wird. (0,N) ist enthalten enthält (0,N) Steuergerät Protokoll : String Nicht Steuergerät kann beinhalten (1,N) (0,1) LIN Master Abhängigkeits-Bedingung: Pro Familie genau eine Fahrzeug Option in Fahrzeug-Datensatz Abbildung 4.3: ER-Diagramm: Automobil-Modell folgen gibt und diese verschiedene Eigenschaften haben, werden zuerst die Abhängigkeiten und deren Auswirkung auf das komplette Modell besprochen. Wie im Kapitel Abhängigkeiten beschrieben wurde, gibt es Abhängigkeiten zwischen Abfolgen, welche für alle Komponenten einer bestimmte Modellreihe gültig sind und Abhängigkeiten, welche zwischen zwei konkreten Abfolgen existieren. Aus diesem Grund werden zwei neue Entitäten, zum einen die Standard Abfolge, welche sich auf die allgemeinen Abhängigkeiten ohne konrekten Einfluss eines bestimmten Steuergerätes einer Modellreihe bezieht, und eine Komponentenspezifische Abfolge, welche sich auf konkrete Abfolgen bezieht, eingeführt. Diese beiden neuen Entitäten werden als Spezialisierung der Entität Abfolge eingeführt. Da eine Abfolge optional Vorbedingungen besitzt, welche bestimmte Zustände voraussetzt, wird eine zusätzliche Entität Zustand mit dem Attribut Name und dem optionalen prozessortübergreifenden Attribut Endwert eingeführt. 32

43 4.2. Formalisierung 33 Alle Entitäten des Abfolgen-Modells im Überblick (siehe auch Abbildung Abfolgen-Modell Entitäten): Abfolge (abstrakt) Standard Abfolge Komponentenspezifische Abfolge Zustand Abfolge (abstrakt) Bezeichner : String LAS : String Einsatz : Datum Entfall : Datum Ist eine Ist eine Zustand Name : String Endwert : String Erfahrungswerte DurchschnittlicheDauer : Long Verbaurate : Double Standard-Abfolge Komponentenspezifische Abfolge Abbildung 4.4: Abfolgen-Modell Entitäten Die Entität Abfolge bekommt alle eindeutigen Attribute aus den erhobenen Daten: Bezeichner LAS Einsatz Entfall Da es sich bei der Standard- und Komponentenspezifischen Abfolge um eine Spezialisierung der abstrakten Abfolge handelt und diese keine weiteren unabhängigen Attribute enthalten, werden diese Entitäten ohne weitere Attribute angelegt. Da alle Entitäten und ihre Attribute in das Modell eingeflossen sind, beschäftigen wir uns mit den Beziehungen zwischen den Entitäten. Aus den erhobenen Daten ist bekannt, dass eine Abfolge auf 1 bis n Fahrzeug-Komponenten zugreifen kann. An dieser Stelle muss zwischen der Standard- und der Komponentenspezifischen Abfolge unterschieden werden, denn nur die Komponentenspezifische Abfolge greift auf 1 bis n Fahrzeug-Komponenten zu. Dagegen hat die Standard Abfolge eine Beziehung zu Fahrzeug-Projekt, um zu verdeutlichen, dass eine Standard Abfolge für alle Fahrzeuge aus der Modellreihe gültig ist. Ein Beispiel dafür ist, dass Abfolgen mit dem Bezeichner Verbauprüfung sequentiell immer vor einer Abfolge mit dem Bezeichner WFS_Anfrage kommen müssen. Diese Abhängigkeit ist für mindestens ein Fahrzeug-Projekt gültig. Dagegen ist bei der Komponentenspezifischen Abfolge die Abhängigkeit abhängig von der Fahrzeug- Komponente, welche durch die Abfolge angesprochen wird. Deshalb hat die Komponentenspezifischen Abfolge lediglich eine Beziehung hat zu der Fahrzeug-Komponente mit den Kardinalitäten, dass eine Fahrzeug-Komponente eine Komponentenspezifischen Abfolge haben kann, aber eine Komponentenspezifischen Abfolge mindestens eine Fahrzeug-Komponente hat. Die Abhängigkeiten werden im ER-Modell als reflexive Beziehung abhängig mit dem Attribut Art 33

44 34 4. Modellierung der abstrakten Abfolge dargestellt. Dadurch sind alle in den Anforderungen deklarierten Abhängigkeiten abgedeckt, da Standard und Komponentenspezifischen Abfolge sowohl zu sich selbst als auch untereinander 0 bis n Abhängigkeiten haben können. Da es zwischen Abfolgen mehrere Arten von Abhängigkeiten gibt, siehe Abschnitt 3.7, müssen diese im Modell unterschieden werden können. Dazu wird das bereits eingeführte Attribut Art verwendet. Anhand dieses Attributs kann eine Unterscheidung der verschiedenen Abhängigkeitsarten zwischen Abfolgen repräsentiert werden, sodass zum Beispiel im Falle der Abhängigkeit nicht parallel als Art nichtparallel hinterlegt werden könnte. Anhand dieser Information sowie den beteiligten Abfolgen kann eine eindeutige Zuweisung der Abhängigkeit vorgenommen werden. Abhängigkeiten, welche transitiv aufgebaut sind, müssen, zum heutigen Zeitpunkt, aufgebrochen und einzeln angegeben werden. Innerhalb eines Testplans kann auf Zustände des Fahrzeuges zurückgegriffen werden. Diese Zustände repräsentieren zum Beispiel, ob die Zündung des Fahrzeuges eingeschaltet ist oder ob die Prüfung des Schiebedachs derzeit aktiv ist. Zum einen gibt es Abfolgen, welche zum Beispiel eine eingeschaltete Zündung zur korrekten Terminierung benötigen, darum ist es notwendig, diese Zustände bei der Überprüfung des Testplans zu berücksichtigen. Zum anderen können über diese Zustände Eigenschaften des Fahrzeuges prozessortübergreifend weitergegeben werden, sodass ab dem n-ten Prozessort bekannt ist, dass das Fahrzeug zum Beispiel über die Bereifung verfügt. Damit vor der Ausführung einer Abfolge getestet werden kann, ob ein bestimmter Zustand vorliegt, verfügen Abfolgen über optionale Vorbedingungen. Diese müssen vor der Ausführung der Abfolge erfüllt sein, damit die Abfolge ausgeführt werden kann. Aus diesem Grund wird die Beziehung erfordert zwischen der abstrakten Abfolge und der Entität Zustand eingeführt. Dabei erfordert eine Abfolge 0 bis n Zustände und ein Zustand ist von mindestens einer Abfolge die Vorbedingung (1 bis n als Kardinalität). Da Zustände zu einer kompletten Modellreihe gehören, sodass diese prozessortübergreifend zur Verfügung stehen, wird die Beziehung gehört zu zwischen der Entität Zustand und Fahrzeug-Projekt eingefügt. Ein Zustand kann nicht nur als Vorbedingung einer Abfolge gefordert sein, sondern auch von dieser verändert werden. Darum wird analog zu der Beziehung erfordert die Beziehung verändert, mit den gleichen Kardinalitäten, hinzugefügt. Denn eine Abfolge kann optional bis zu n Zustände verändern, aber ein Zustand muss von mindestens einer Abfolge verändert werden. Wäre dies nicht der Fall und ein Zustand muss nicht zwingend von einer Abfolge verändert werden, so würden die Zustände standardmäßig mit undefined initialisiert und würden diesen Wert niemals verlassen. Aufgrund der derzeitigen Modellierung ist noch nicht bekannt, auf welchen Bereich sich die Zustände beziehen. Ausgehend von den erhobenen Daten beziehen sich die Zustände jedoch auf die Modellreihe. Somit muss eine weitere Beziehung gehört zu zwischen den Entitäten Zustand und Fahrzeug-Projekt erzeugt werden. Eine weitere Eigenschaft, die an eine Abfolge geknüpft ist, ist ob eine Abfolge eine Ressource benötigt oder nicht. Dies wird aus dem Beispiel der erhobenen Daten mit dem Anlernen des Schlüssels und der damit verbundenen Werkereinbindung deutlich. Da ein Werker als Ressource gesehen wird und weitere Ressourcen denkbar sind, muss eine Beziehung benötigt zwischen diesen Entitäten erzeugt werden. Die beschreibt, dass eine Abfolge von einer Ressource und eine Ressource von einer Abfolge benötigt werden könnte. Daher werden diese Kardinalitäten je auf 0 bis n gesetzt. Diese Beziehungen und die zuvor erarbeiteten Entitäten werden im ER-Modell 4.5 abgebildet Test-Umgebungs-Modell Aufbauend auf den Informationen aus dem Kapitel wird nun ein ER-Modell erstellt, welches die Informationen der Test-Umgebung auf ein Modell abbildet. Wir beginnen zuerst damit, die Entitäten und deren Attribute zu beschreiben und dann diese Entitäten anhand der bekannten Beziehungen in Relation zueinander zu setzen. Wie man aus den Informationen des genannten Kapitels leicht erkennen kann, gibt es vier Entitäten in diesem Modell: Das Werk Die Montagelinie 34

45 4.2. Formalisierung 35 (0,N) Ressource (0,N) benötigt Wert: String Wert: String verändert erfordert gehört zu (1,N) (1,N) Zustand (1,N) Name : String Endwert : String Fahrzeug Projekt (1,N) (1,N) hat (1,N) (0,N) (0,N) ist Vorbedingung Ist eine (1,N) Standard-Abfolge besitzt (1,N) Fahrzeug Komponente (0,N) Abfolge (abstrakt) Art : String Bezeichner : String LAS : String Einsatz : Datum Entfall : Datum (0,N) abhängig hat Ist eine Erfahrungswerte DurchschnittlicheDauer : Long Verbaurate : Double Komponentenspezifische Abfolge (1,N) Legende: Entity aus angrenzenden Modell Abbildung 4.5: ER-Diagramm: Abfolgen-Modell Der Prozessort und Die Ressource Da sich ein Werk von anderen Werken unterscheiden muss und wir die Informationen über die Nummer, die Kurzbezeichnung und den Standort eines Werkes haben, werden diese Informationen als Attribut der Werke aufgenommen. Die Nummer ist dabei eine globale Werksnummer und kann als Schlüssel der Entity aufgefasst werden. Eine Montagelinie sowie der Prozessort und dessen Ressourcen werden global durch ihren Namen identifiziert. Daher wird zusätzlich das Attribut Name vom Typ String aufgenommen, welches diese Information hält. Eine Ressource hat zu dem Namen ein weiteres Attribut, welches aussagt, wie oft auf eine bestimmte Ressource parallel zugegriffen werden darf. Dieses Attribute wird maxanzahlparallelzugriffe genannt und ist vom Typ Integer. Wie man in der Abbildung 4.2.3, Test-Umgebungs-Modell, erkennen kann, wurden genau diese Entitäten mit ihren Attributen in das Modell aufgenommen. Nun müssen diese Entitäten anhand der Informationen aus den erhobenen Daten zueinander in Beziehung gesetzt werden. Wir wissen, dass ein Werk mindestens eine Montagelinie hat und eine Montagelinie genau einem Werk zugeordnet ist. Also wird das Werk mit der Montagelinie über die Beziehung hat verbunden und die Kardinalitäten angepasst, sodass ein Werk 1 bis n 35

46 36 4. Modellierung Werk Nummer : Int Kurzbezeichnung : String Standort : String Montagelinie Name : String Prozessort Name : String Ressource Name : String maxanzahlparallelerzugriff : Int Abbildung 4.6: Test-Umgebungs-Modell Entitäten Montagelinien hat und eine Montagelinie zu genau einem Werk gehört. Analog dazu wird die Beziehung zwischen den Entitäten Montagelinie und Prozessort dargestellt. Wie man den erhobenen Daten weiter entnehmen kann, kann Ein Prozessort [...] Ressourcen haben. Anhand von dieser Information wird der Prozessort über eine hat Beziehung mit der Ressource verbunden und die Kardinalitäten angepasst, sodass ein Prozessort 0 bis n Ressourcen hat, null, da eine Ressource nicht zwingend ist, und einer Ressource können 1 bis n Prozessorten zugewiesen werden. Zudem geht aus den Daten hervor, dass Ein Prozessort [...] einen nachfolgenden Prozessort [...] hat, welche eine sequentielle Reihenfolge der Prozessorte auf einer bestimmten Montagelinie wiedergibt. Diese Information wird als rekursive Beziehung Reihenfolge an der Entität Prozessort dargestellt. Die Kardinalitäten sind dabei jeweils 0 bis 1, da sowohl der erste als auch der letzte Prozessort in der sequentiellen Reihenfolge ohne Zyklus keinen Vorgänger oder Nachfolger haben darf. Die komplette Umsetzung der beschriebenen Informationen ist in der Abbildung 4.7 zu betrachten. Modellübergreifend ist bekannt, dass an einem Prozessort bestimmte Fahrzeug-Komponenten (aus der Abbildung 4.3) unter der Bedingung der Ressourcen und Eigenschaften verbaut bzw. diagnosebereit sein können. Diese Information wird über eine dreistellige Beziehung verbaut / diagnosebereit zwischen dem Prozessort der Fahrzeug-Komponente und der Ressource bzw. Eigenschaft dargestellt. Wobei die Kardinalitäten so zu lesen sind, dass: An einem Prozessort mit 0 bis n Ressourcen mindestens eine Fahrzeug-Komponente diagnosebereit bzw. verbaut wird. (Ausgehend vom Prozessort) Eine Fahrzeug-Komponente unter der Bedingung von 0 bis n Ressourcen an einem bestimmten Prozessort an 1 bis n Prozessorten diagnosebereit bzw. verbaut ist. (Ausgehend von der Fahrzeug-Komponente) Ein Prozessort hat zudem die Möglichkeit, initiale Werte der Zustände eines Testplans zu setzen. Diese wird über die Beziehung setzt mit den Beziehungsattributen Inital - und Endwert ermöglicht. Da nicht jeder Prozessort initiale Zustände setzen muss bzw. ein Zustand nicht zwingend von einem Prozessort gesetzt werden muss, werden beide Kardinalitäten dieser Beziehung auf 0 bis n gesetzt. Mit Hilfe dieser Beziehung sind prozessortbezogene Initial- und Endzustände möglich Software-Auslieferungs-Modell Die in diesem Teil des Modells erfassten Informationen über Testpläne und Komponenten haben derzeit für den Einsatz bei der Automobilüberprüfung und -konfiguration noch keine große Relevanz und werden daher in dieser Arbeit nicht weiter behandelt. Daher wird an dieser Stelle das Software-Auslieferungs-Modell zwar eingeführt, jedoch in den kommenden Kapiteln nicht weiter bearbeitet. Die erhobenen Informationen für die Softwareauslieferung aus dem Abschnitt wurden in diesem Modell umgesetzt. 36

47 4.3. Datenbankentwurf 37 Werk Nummer : Int Kurzbezeichnung : String Standort : String Montagelinie Name : String (1,N) (1,1) (1,N) hat Reihenfolge hat diagnosebereit / verbaut (0,N) Fahrzeug Komponente (abstrakt) vorheriger (0,1) (0,1) (0,N) (0,N) Prozessort Name : String nächster (1,1) (0,N) hat (1,N) Ressource InitialWert : String EndWert : String (1,N) Name : String maxanzahlparallelerzugriffe : Int Legende: setzt (0,N) Zustand Entity aus angrenzenden Modell Abbildung 4.7: ER-Diagramm: Test-Umgebungs-Modell 4.3 Datenbankentwurf In den letzten Abschnitten dieses Kapitels wurde die Datenbasis anhand von Modellen präsentiert und deren Entitäten und Relationships des ER-Modells beschrieben. In den folgenden Abschnitten wird die Umsetzung des erarbeiteten ER-Modells in eine relationalen Datenbank [Cod83] erläutert. Bei einer relationalen Datenbank handelt es sich um eine elektronische Datenverwaltung, welche auf einem relationalen Datenbankmodell beruht [Cod80]. Das Datenbankmodell definiert, auf welche Art und Weise Daten in einem Datenbanksystem gespeichert und bearbeitet werden können. Eine relationale Datenbank kann als Sammlung von Relationen (Tabellen) angesehen werden. Jede Zeile (Tupel) in einer Tabelle ist ein Datensatz (record). Jedes Tupel besteht aus einer Reihe von Attributwerten (Attribute = Eigenschaften), den Spalten der Tabelle. Einer der Vorteile der relationalen Datenbanken ist, dass sie eine relationale Anfragesprache, in den meisten Fällen SQL [CB74], verwenden. Relationenalgebra [Cod83] ist eine formale Sprache, mit der sich Abfragen über ein relationales Schema formulieren lassen. Sie erlaubt es, Relationen miteinander zu verknüpfen und/oder zu reduzieren und komplexere Informationen daraus herzuleiten. Auf Basis dieser relationalen Datenbank werden die zugrundeliegenden Anforderungen gespeichert und der Testplan mit diesen Informationen abgeglichen. Damit die Anforderungen in die erzeugte Datenbank integriert werden können, wird im Kapitel Datenintegration auf die Austauschformate und deren Eigenschaften eingegangen. Die konkrete Implementierung der Integration der Daten in die Datenbasis über die Austauschformate wird im Kapitel 7 beschrieben. Das Abbilden der Entity-Typen und der Beziehungstypen des ER-Modells in die Relationenschemata wird wie folgt vorgenommen: Entity-Typen werden als Relationenschema mit ihren Attributen übernommen. Primärschlüssel wird anhand des Schlüssels des ER-Modells übernommen. Beziehungs-Typen werden als Relationenschema mit ihren Attributen übernommen. Primärschlüssel besteht aus den Schlüsseln der beteiligten Entity-Typen. 37

48 38 4. Modellierung Abfolge (abstrakt) (0,N) benutzt (0,N) ausliefern (1,N) Software Paket (1,N) (1,N) Zeitliche Fenster Startpunkt : Datum Endpunkt : Datum Software Komponente Name : String (1,1) besteht aus Legende: Entity aus angrenzenden Modell Abbildung 4.8: ER-Diagramm: Software-Auslieferungs-Modell Fremdschlüssel werden im ER-Modell durch die Verbindungen zwischen den Beziehungs-Typen und der Entity-Typen dargestellt und nicht direkt angegeben. Diese entstehen erst bei der Abbildung in das relationale Datenbankschema. Die Kapazitätserhaltung bei der Abbildung zwischen dem vorgestellten ER-Modell in das relationale Datenbankmodell ist ohne Kapazitätsverlust vorzunehmen. Dazu werden Abbildungsregeln der verschiedenen Beziehungstypen vorgestellt [Eic06b]: 1:1 Beide Primärschlüssel werden je ein Schlüssel, einer wird Primärschlüssel. 1:n Der Primärschlüssel der n-seite wird Schlüssel. m:n Es wird eine neue Beziehungsrelation eingeführt, welche beide Primärschlüssel als Schlüssel erhält. Die einzelnen Schlüssel der Beziehungsrelation sind wiederum Fremdschlüssel zu den beteiligten Entityrelationen. In den folgenden Abbildungen der Datenbankmodellierung, der einzelnen spezifizierten Modelle, gilt folgende Konvention: Blau Diese Relationen (Entityrelationen) repräsentieren Tabellen, welche mit Basisinformationen gefüllt werden. Türkis Diese Relationen (Beziehungsrelationen) repräsentieren die Beziehung zwischen Basisinformationen. Auch erkennbar an der Syntax RS_*. Weiß Relationen aus einem angrenzendem Modell. Als Notationsstil der Fremdschlüsselbeziehungen wurde die Martin-Notation [Ode12] gewählt Realisierung des Automobilmodells In diesem Abschnitt wird das Automobil-Modell auf das relationales Schema abgebildet. Da aus dem Automobil-Modell die Entities und Relationships bekannt sind, wird an dieser Stelle nicht konkret auf diese eingegangen. Die Konsistenz der Relationen und wie diese sichergestellt wird, sowie die besondere Umsetzung des Modells in die Datenbasis, wird an dieser Stelle intensiver erläutert. Da aus dem Automobil-Modell hervorgeht, dass eine Fahrzeug-Option in Familien strukturiert ist, wobei eine Fahrzeug-Option in maximal einer Familie sein darf, werden die Fahrzeug-Familien 38

49 4.3. Datenbankentwurf 39 (OptionsFamilies) und die Fahrzeug-Optionen (VehicleOptions) als Basisrelation dargestellt. Da, wie schon genannt, eine Fahrzeug-Option nur in einer Familie sein darf, wird dies als eine 1 zu n Beziehung darstellt. Um nur konsistente Daten in der Datenbank zu halten, werden Integritätsbedingungen eingeführt. Darunter fallen Primary Keys (Primäre Schlüssel, in Abbildung: Goldene Schlüssel) und Foreign Keys (Fremdschlüssel, in Abbildung: Silberne Schlüssel) sowie einzelne Unique Constraints (Zwangsbedingungen). Mit der Hilfe von Primary Key s wird sichergestellt, dass von Attributen, welche einem Primary Key entsprechen, keine doppelt vorhanden sein dürfen und das Referenzieren über einen Foreign Key ermöglicht. Der Primary Key wird wie im Abschnitt 4.3 definiert umgesetzt. Abbildung 4.9: Datenbankschema des Automobil-Modell Die Fahrzeug-Komponenten werden durch ihr Kürzel (Shortcut) und deren Verbauort im Fahrzeug (Location) identifiziert. Daher werden diese Attribute für die Beschreibung der Abhängigkeiten zwischen den einzelnen Komponenten benutzt (siehe Abbildung 4.9, RS_ComponentDependencies). Um die verschiedenen Abhängigkeiten zwischen Komponenten eines Fahrzeuges unterscheiden zu können, wird das Attribut type eingeführt. Mit diesem ist es möglich, für jede Abhängigkeit die Art aus dem Modell darzustellen. Zum Beispiel werden als type = 0 die nicht parallel diagnostizierbar Abhängigkeiten beschrieben. Damit keine Abhängigkeiten zwischen Komponenten erzeugt werden, welche es nicht gibt, wurden Fremdschlüssel zum Referenzieren der Fahrzeug-Komponenten mittels der angesprochenen m:n Abbildungsregel erzeugt. Somit wird sichergestellt, dass die Komponenten in der Relation RS_COMPONENTDEPENDENCIES auch in der Relation VEHICLECOMPONENTS vorhanden sein müssen. Der LAS besteht laut dem Automobil-Modell aus Fahrzeug-Optionen, welche mittels boolescher Operatoren in Beziehung gesetzt werden. Da in der Ausbaustufe 1 des Zielsystems diese Informationen noch nicht zwingend gebraucht werden und auch noch nicht bekannt ist, in welcher Form diese zu einem späteren Zeitpunkt benötigt werden, werden die LAS derzeit als boolesche Formel vom Typ String abgespeichert. Da aus dem Modell bekannt ist, dass die Fahrzeug-Komponenten entweder Steuergeräte oder Nicht Steuergeräte sein können, wird das Attribut type zur Relation VEHICLECOMPONENTS aufgenommen. Durch dieses Attribut kann angegeben werden, ob es sich um ein Steuergerät, type = SG, oder ein Nicht Steuergerät mit type = nsg handelt. Erweiterungen durch weitere Parameter des Attributes type sind möglich. 39

50 40 4. Modellierung Alle weiteren Attribute der Fahrzeug-Komponenten sind analog zum Automobil-Modell hinzugefügt worden. Die Relation RS_VehProjComp beschreibt die Fahrzeug-Komponenten, die in einem bestimmten Fahrzeug-Projekt verbaut werden können. Die Fremdschlüssel werden anhand der Abbildungsregel des m:n Beziehungstyps vorgenommen Realisierung des Abfolgenmodells Das Abfolgen-Modell konzentriert sich auf die Abfolgen, deren Typen und deren Beziehungen zu den Zuständen, Ressourcen, Fahrzeug-Komponenten und -Projekten. Dieses Modell werden wir in diesem Abschnitt auf ein relationales Schema übertragen. Da das Modell als ER-Modell aufgebaut wurde, sind sowohl die Entitäten als auch die Beziehungen untereinander vorhanden. Der einzige Unterschied werden die Standard- und Komponentenspezifischen Abfolgen sein. Da sich diese Entities in ihren Attributen nicht unterscheiden, wurden sie in einer einzigen Relation aufgenommen. Um dennoch die Typen von Abfolgen unterscheiden zu können, wird das Attribut type eingeführt, bei dem type = 0 für eine Standard Abfolge und type = 1 für eine Komponentenspezifische Abfolge steht. Da sich die Tupel in der Relation nur durch ihre Beziehungen zum Fahrzeug-Projekt (Standard Abfolge, RS_VehProjSeq) und zu der Fahrzeug-Komponente (Komponentenspezifische Abfolge, RS_VehCompSeq) unterscheiden, wurde eine sequenceid eingeführt. Diese ID hat als Wertebereich die ganzen Zahlen und wird bei jedem neuen Eintrag um eins erhöht. Durch den Contraint Primärschlüssel wird sichergestellt, dass jede ID eindeutig ist, wodurch jedes einzelne Tupel direkt angesprochen werden kann. Die weiteren Attribute der Abfolgen (Sequences) wurden 1:1 aus dem Modell entnommen. Abbildung 4.10: Datenbankschema des Abfolgen-Modell Da eine Abfolge bestimmte Zustände erfordert und verändern kann, wurden zwei Beziehungsrelationen, anhand der bekannten m:n Abbildungsregel von Beziehungstypen, eingeführt, die dies abbilden. Für das Verändern von Zuständen die Relation RS_ChangeCondition und für die Vorbedingung von Abfolgen die Relation RS_DemandCondition. Die Relation RS_VehProJSeqCond, welche alle möglichen Zustände eines Fahrzeug-Projektes der Abfolgen hält, wurde identisch erstellt. 40

51 4.3. Datenbankentwurf 41 Analog zu den Zuständen kann eine Abfolge eine Ressource erfordern. Diese Beziehung wurde bis auf das nicht vorhandene Attribut value analog zu der Beziehung zwischen Abfolgen und Zuständen in die Datenbank aufgenommen. In der folgenden Tabelle 4.1 wird das Attribut type auf die bekannten Abhängigkeiten aus dem Abschnitt 3.7 abgebildet. Typ Beschreibung 0 Sequentiell davor 1 Sequentiell danach 2 Optional sequentiell davor 3 Nicht parallel 4 Sequentiell danach mit Abstand Tabelle 4.1: Typ der Abfolgen-Abhängigkeiten in der Datenbank Realisierung des Test-Umgebungsmodells Das Test-Umgebungs-Modell wird in diesem Absatz auf ein relationales Schema abgebildet. Da aus dem Entity-Relationship-Modell sowohl die Entities (Basisrelationen) als auch die Relationships (Beziehungsrelationen) zwischen diesen direkt abgebildet werden können, erkennt man in der Abbildung Datenbankschema des Test-Umgebungs-Modell, dass die Relationen Factories, Assemblylines, Processplaces und Resources als Basisrelationen sowie RS_shoring und RS_ProcessplaceResource als Beziehungsrelationen abgebildet werden. Abbildung 4.11: Datenbankschema des Test-Umgebungs-Modell Die Relation VehicleComponents ist aus dem Automobil-Modell zur Visualisierung von RS_Shoring sowie die RS_SequenceConditions aus dem Abfolgen-Modell für die Relation RS_ProcessplaceCondition vorhanden. Alle Attribute des Test-Umgebungs-Modells wurden mit ihren Wertebereichen abgebildet. 41

52 42 4. Modellierung Da die Konsistenz der Relationen sehr wichtig ist und es nicht gewollt ist, dass zum Beispiel eine Montagelinie eine Fabrik als Standort referenziert, welche nicht mehr vorhanden ist, werden Primär- und Fremdschlüssel anhand der definierten Abbildungsregeln eingeführt. Analog bei Montagelinien und Werken. Da die Prozessorte bei einer Montagelinie in einer festen Reihenfolge stehen, kann über die optionalen Attribute NextProcessplace und PreviousProcessplace der Vor- bzw. Nachfolger angegeben werden. Bei diesen Attributen ist kein (NN, Not Null) angegeben, was besagt, dass nicht zwingend ein Prozessort angegeben werden muss. Dies ist zum Beispiel für den letzten Prozessort in der Reihenfolge wichtig, da dieser natürlich keinen weiteren Prozessort angeben kann. Die Zuordnung der Ressourcen mit ihrer Anzahl (Quantity) zu den Prozessorten in der Relation RS_ProcessplaceResource sowie bei der Relation RS_ProcessplaceCondition wird über die Abbildungsregel m:n vorgenommen. In der zuletzt genannten Relation, welche die Attribute initialvalue und endvalue beinhalten, wobei der endvalue optional ist, kann anhand von diesen Attributen eine prozessbezogene Initialisierung ausgewählter Zustände vorgenommen werden Gesamtarchitektur der Datenbank Die in den letzten drei Abschnitten vorgestellten Teile des Datenbankschemas werden in der folgenden Abbildung 4.12 zu einem Datenbankschema zusammengefügt. Auf Basis dieses Schemas wird dann eine Datenbank erstellt, in der alle Regeln, Fakten und Abhängigkeiten gespeichert werden. Der physische Datenbankentwurf könnte eventuell zu einem späteren Zeitpunkt zur Optimierungen der Zugriffszeiten eingeführt werden. 42

53 4.3. Datenbankentwurf 43 Abbildung 4.12: Vollständiges Datenbankschema 43

54

55 5. Datenintegration Das Ziel der Datenintegration ist es, die im Kapitel Formalisierung konzipierte Datenbasis mit den Informationen über das Automobil, der Test-Umgebung und den Abfolgen, sowie deren Beziehungen untereinander zu füllen. Einige Teile des Modells liegen bereits aus der Automobilindustrie in einem maschinenlesbaren Format vor. Andere Teile dagegen sind weder in Prosa noch in einem maschinenlesbaren Format vorhanden. Für die nicht vorhandenen Informationen werden im Folgenden XML-Schemata [W3C12] entwickelt, welche diese Informationen des Modells repräsentieren und zur Datenintegration verwendet werden können. Als erstes wird auf das Austauschformat des Test-Umgebungs-Modells eingegangen, danach auf das Abfolgen-Modell. Diese Modelle liegen in keinem maschinenlesbaren Format vor und werden somit komplett in neuen XML-Schemata aufgenommen. Einige Informationen des Automobil-Modells sind in einem maschinenlesbaren Format vorhanden und können für die Integration der Daten verwendet werden. Da aufgrund der Redundanzreduzierung alle bereits existierende Informationen verwendet werden sollen, werden in diesem Modell nur die nicht vorhandenen Informationen als neue XML-Schemata modelliert. Bei diesen Austauschformaten handelt es sich um international zu verwendende Daten und da in der Informatik generell englische Benennungen üblich sind, werden die Austauschformate in Englisch spezifiziert. 45

56 46 5. Datenintegration 5.1 Test-Umgebung Abbildung 5.1: Wurzelknoten des Austauschformates: Test-Umgebung Aus dem ER-Diagramm: Test-Umgebungs-Modell ist bekannt, dass es Werke ( factories ), Montagelinien ( assemblylines ), Prozessorte ( processplaces ) und Ressourcen ( resources ) gibt. Diese Elemente werden als Entitäten in das XML-Schema aufgenommen. Aufgrund der Beziehungen zwischen Werken und Montagelinien, sowie Montagelinien und Prozessorten und der Einschränkung, dass eine Montagelinie bzw. ein Prozessort zu genau einem Werk bzw. einer Montagelinie gehören, werden die Montagelinien als Kindelement der Fabriken (Abbildung 5.2(a)) und analog die Prozessorte als Kindelemente der Montagelinien angelegt (Abbildung 5.2(b)), 46

57 5.1. Test-Umgebung 47 (a) Fabriken und deren Montagelinien (b) Montagelinien und deren Prozessorte wodurch die n zu 1 Beziehung sichergestellt wird. Da eine Ressource mehrfach von verschiedenen Prozessorten ausgewählt werden kann, wird das Element resource (Abbildung 5.3) unabhängig dargestellt und kann über das Referenzelement resourceref referenziert werden. Da an einem Prozessort zum Beispiel die Ressource Werker mehrfach benötigt werden könnte und man nicht für jeden Prozessort und Werkeranzahl eine neue Ressource einführen möchte, wird das aus dem Modell bekannte Attribut Anzahl als Attribut referenceresourcecount des Elementes resourceref angegeben. Durch dieses Attribut ist es möglich, die Anzahl der Ressourcen für einen bestimmten Prozessort anzugeben. Ein Prozessort verfügt jedoch nicht nur über Ressourcen, sondern hat zudem die Möglichkeit, Zustände eines Testplans zu initialisieren bzw. Endwerte am Schluss eines Testplandurchlaufes zu fordern. Darum werden conditionref s eingeführt, über diese die Zustände aus dem Abfolgen-Austauschformate referenziert und mit Initial- und Endwerten versehen werden können. Der Prozessort sowie dessen Ressourcen und Zustände werden in der Abbildung 5.2 dargestellt. Abbildung 5.2: Prozessort und dessen optionale Ressourcen und initiale Zustände Da man nicht nur eine Montagelinie pro Werk bzw. ein Prozessort pro Montagelinie haben möchte, können von diesen Elementen mehrere erzeugt werden. Um dies zu realisieren wird eine Sequenz von 0 bis n processplace, assemblyline bzw. resource angelegt. Um eine korrekte Modellierung zu gewährleisten, werden diese Sequenzen in einem eigens dafür angelegtem Element (zum Beispiel: assemblylines, processplaces) angelegt. Die bekannten Attribute aus der Abbildung ER-Diagramm: Test-Umgebungs-Modell wurden übernommen. 47

58 48 5. Datenintegration Abbildung 5.3: Ressourcen eines Prozessortes 5.2 Abfolgen Wie schon angesprochen, sind für das Abfolgen-Modell keinerlei maschinenlesbare Informationen für die Datenintegration vorhanden. Darum wird zuerst jede Entität aus dem Abfolgen- Modell als XML-Element für das XML-Schema dargestellt. Darunter fallen zu einem die Abfolge ( sequence ) und deren Spezialisierungen, die Standard-Abfolge ( standardsequence ) und die Komponentenspezifische-Abfolge ( componentspecificsequence ), sowie der Zustand (condition), welcher durch eine Abfolge verändert bzw. als Vorbedingung gefordert wird. Diese Entitäten werden direkt mit ihren Attributen als Elemente mit deren Attributen umgesetzt. Abbildung 5.4: Wurzelknoten mit Abfolgen und Zuständen Zuerst beschäftigen wir uns mit dem Zustand ( condition ), siehe Abbildung 5.5. Das Element Zustand wird unabhängig von der Abfolge angesehen und daher direkt unter der Wurzel angebracht. Über eine Sequenz können optional 1 bis n Zustände eingebracht werden. Optional, da die Zustände ( condition ) aufgrund der Übersichtlichkeit und besseren Zugriffsmöglichkeit in dem Element conditions gehalten werden und dieses Element optional angelegt werden kann, da aus der Modellierung bekannt ist, dass eine Abfolge nicht zwingend einen Zustand verändern 48

59 5.2. Abfolgen 49 oder einen Zustand als Vorbedingung haben muss. Ein Zustand hat die bekannten Attribute name und endvalue sowie das Attribut modelltype, mit welchem die Modellreihe referenziert werden kann. Abbildung 5.5: Zustand Mit dem Attribut modelltype ist es möglich, dieses Austauschformat mit Zuständen aus verschiedenen Modellreihen zu befüllen. Analog ist dieses Attribut bei den Abfolgen ( sequence ) vorhanden. Eine Abfolge beinhaltet mehrere Kindelemente. Zum einem kann ausgewählt werden, ob es sich um eine Standard- oder eine Komponentenspezifische-Abfolge handelt, indem man eins der beiden Elemente standardsequence oder componentspecificsequence erzeugt. Es ist nicht möglich, keines oder beide auszuwählen. Da eine Standard-Abfolge (Abbildung 5.7(a)) eine Beziehung zu einem oder mehreren Modellreihen besitzt, ist als Kindelement der standard- Sequence eine Sequenz von projectref zwingend notwendig. Dieses Element beinhaltet das Attribut modelltype zum Referenzieren der Modellreihe. Analog dazu muss eine Komponentenspezifische-Abfolge componentspecificsequence (Abbildung 5.7(b)) mindestens eine Komponente referenzieren. Da diese Komponenten in einer externen Datei spezifiziert wurden, werden für das Element componentref vier Attribute eingeführt, welche die Komponente und die externe Datei eindeutig identifizieren. Die Komponente wird durch die Attribute componentshortcut und das optionale Attribut componentlocation spezifiziert. Die Datei kann anhand deren Ordner referencedirectory sowie den Dateinamen referencefile identifiziert werden. (a) Standard Abfolge (b) Komponentenspezifische Abfolge Um allgemeiner auf externe Dateien referenzieren zu können, bei der die Referenzen keiner Konvention unterliegen, wird die Attributgruppe referenceattribut eingeführt, welche in der Abbildung 5.7 sowie mit expliziter Beschreibung der einzelnen Parameter in der Tabelle 5.2 aufgezeigt wird. 49

60 50 5. Datenintegration Abbildung 5.6: Abfolge mit Attributen und Spezialisierungen Abbildung 5.7: Attributgruppe referenceattribute 50

61 5.2. Abfolgen 51 Name Typ Einschränkung Obligatorisch Beschreibung ReferenceName xs:string keine Ja Gibt das zu referenzierende Element an. ReferenceType ReferenceType: auf Component, Ja Gibt den xs:string Project, Sequence Referenttyp an und Resource ReferenceFile xs:string keine Ja Gibt den Dateinamen an. ReferenceDirectory xs:string keine Ja Ordner der Datei. ReferenceNameId xs:string keine Nein Id des Dateinamens. ReferenceFileId xs:string keine Nein Id der Datei. ReferenceDirectoryId xs:string keine Nein Id des Ordners. Tabelle 5.1: Attributgruppe zum referenzieren externer Inhalte. [Gro12] Name Beschreibung Abbildung Sequential Abfolge muss vor der referenzierten Abfolge im Testplan 5.8(a) kommen SequentialOptional Abfolge muss vor der referenzierten Abfolge im Testplan 5.8(c) kommen, falls diese vorhanden ist SequentialAfter Abfolge muss nach der referenzierten Abfolge im Testplan kommen 5.8(d) Tabelle 5.2: Sequentielle Abhängigkeiten Da in dieser Arbeit eine Abfolge als Blackbox angesehen wird, jedoch für die späteren Stufen dies nicht mehr der Fall sein wird und Dateien zur Beschreibung von Abfolgen bereits vorhanden sind, können diese optional anhand der genannten Attributgruppe über das Element referenceelement referenziert werden. Da wir nun die spezifischen Unterschiede der Abfolgen geklärt haben, kommen wir nun zu den allgemeineren Referenzen und Abhängigkeiten, die eine Abfolge hat. Zum einen ist bekannt, dass eine Abfolge einen oder mehrere Zustände verändern kann, oder diese als Vorbedingung zum Ausführen der Abfolge vorausgesetzt werden. Aus diesem Grund werden zwei Sequenzen von Elementen eingeführt, die genau dies darstellen. Zum einen die conditiondemandref, für die Vorbedingungen, und zum anderen conditionchange- Ref, für das Verändern von Zuständen, welche beide wiederum conditionrefs in sich halten. Die conditionref verweist innerhalb des Austauschformates mit dem Attribut referencecondition auf einen Zustand und über das Attribut value kann angegeben werden, zu welchem Wert ein Zustand geändert werden soll bzw. was dieser als Vorbedingung beinhalten muss. Diese Zustands-Referenzen sind optional angelegt, da aus dem Modell hervorgeht, dass eine Abfolge nicht zwingend einen Zustand verändern bzw. erfordern muss. Zudem benötigen bestimmte Abfolgen Ressourcen aus dem Test-Umgebungs-Modell. Diese Referenz wird über das Element resourceref mit den Attributen aus der Attributgruppe belegt. Auch dieses Element ist optional und kann analog zu den Referenzen der Zustände deklariert werden. Das letzte, was dieses Austauschformat benötigt, ist die Abhängigkeit zu anderen Abfolgen zu beschreiben. Die derzeit bekannten Abhängigkeiten sind sowohl sequentielle als auch parallele Abhängigkeiten zu anderen Abfolgen. Die ersten Abhängigkeiten sind die sequentiellen Abhängigkeiten, welche durch das Schlagwort sequential identifiziert werden. Es gibt drei verschiedene Typen von sequentiellen Abhängigkeiten: Die weiteren Abhängigkeiten sind die parallelen Abhängigkeiten: 51

62 52 5. Datenintegration Name Beschreibung Abbildung notparallel Abfolge darf nicht parallel mit der referenzierten Abfolge im 5.8(b) Testplan ausgeführt werden Tabelle 5.3: Parallele Abhängigkeiten (a) Sequentielle Abhängigkeiten (b) Nicht parallele Abhängigkeit (c) Sequentiell optionale Abhängigkeiten (d) Sequentiell nachfolgende Abhängigkeiten Abbildung 5.8: Abfolgen Referenz Alle internen Referenzen eines Austauschformates wurden über Key und KeyRef realisiert. Diese Contraints wurden unterhalb des Wurzelknotens angelegt. Zugleich wird dadurch ausgeschlossen, dass es zum Beispiel mehrere Zustände mit gleichem Namen geben darf. Dasselbe gilt für Abfolgen. 5.3 Komponenten-Abhängigkeiten Obwohl Informationen über die Modellreihe und ihre Komponenten und deren Bezug über den LAS zu den Fahrzeug-Optionen vorhanden sind, fehlen leider die Informationen, welche Komponente nicht parallel diagnostizierbar mit anderen Komponenten ist. Das neue Austauschformat benötigt nur wenige Elemente. Wir müssen die Komponente identifizieren und mit anderen in Beziehung setzen. Als Wurzelknoten, siehe Abbildung 5.9(a), wird das Element componentdependencies verwendet, welches sowohl eine Liste von 1 bis n Komponenten components als auch contraints (Rahmenbedingungen) hält. Die Komponente wird im Element component angelegt und erhält für das Kürzel das Attribut componentacronym und componentlocation sowie zum Referenzieren der Modellreihe das Attribut modelltype. Um dieses Austauschformat zukunftssicher zu gestalten, sodass weitere Abhängigkeiten Problemlos hinzugefügt werden können, ist es unter dem Element componente möglich, neue Kindelemente, analog zum Element notparallel, mit einer Referenz hinzuzufügen, welche diese neuen Abhängigkeiten beschreiben, siehe Abbildung 5.9(a). 52

63 5.4. Fahrzeug-Optionen und deren Familien 53 (a) Wurzelknoten (b) Komponente Abbildung 5.9: Wurzelknoten und Komponente des Austauschformates Da derzeit nur die parallele Abhängigkeit bekannt ist, wird das Element notparallel hinzugefügt. Dieses beinhaltet mehrere reflexive Referenzen auf die Abkürzung und Position der Komponenten. Sind nun zwei Komponenten über diese Referenz verbunden, bedeutet dies, dass diese nicht parallel angesteuert werden dürfen. Um Redundanz zu verringern, ist es ausreichend, wenn nur die Referenz von Komponente A zu Komponente B vorhanden ist. Eine Visualisierung dieser Beziehung wird in den Abbildungen 5.10(a) und 5.10(b) gezeigt. (a) Abhängigkeit: Nicht parallel Diagnostizierbar. (b) Referenzobjekt der nicht parallelen Abhängigkeit Auch in diesem Austauschformat wurden Schlüssel und Schlüsselbeziehungen eingeführt, über welche die Komponenten referenziert werden und gleichzeitig dafür gesorgt wird, dass kein Kürzel einer Komponente doppelt vorhanden sein kann. Ein weiteres Kindelement der Komponente ist das optionale Element referenceelement. Dieses ist mit der Attributgruppe Abfolgen versehen worden und hat somit die Möglichkeit, Komponenten aus anderen Dateien, zum Beispiel der ECU_Konfiguration, zu referenzieren. 5.4 Fahrzeug-Optionen und deren Familien Die Fahrzeug-Optionen des Fahrzeuges und deren Familien in Bezug auf ein Fahrzeug-Projekt, werden in dem folgenden Kapitel als Austauschformat besprochen und erzeugt. Als Elemente werden die Fahrzeug-Optionen vehicleoption mit dem Attributen PrNummer (Abbildung 5.11(a)) sowie die Fahrzeug-Optionen-Familien vehicleoptionfamily mit den Attributen PrNummer, FamilyName und modelltype angelegt (Abbildung 5.11(b)). 53

64 54 5. Datenintegration Abbildung 5.10: Wurzelknoten mit Listen von normalen und speziellen Fahrzeug- Optionen Der Wurzelknoten und dessen direkte Kindknoten sind in der Abbildung 5.10 zu sehen. (a) Fahrzeug-Optionen (b) Familien von Fahrzeug-Optionen Abbildung 5.11: Fahrzeug-Optionen und -Familien Da bekannt ist (Abbildung 5.10), dass eine Option zu einer oder in Spezialfällen zu keiner Familie gehört, wird zwischen speziellen und normalen Fahrzeug-Optionen unterschieden. Spezielle Fahrzeug-Optionen werden direkt unter der Wurzel im Element specialvehicleoptions als Sequenz angelegt und haben ein optionales Vorkommen von 1 bis n. Abbildung 5.12: Spezielle Fahrzeug-Optionen 54

65 5.5. Diagnosebereitschaft einer Komponente an den Prozessorten 55 Fahrzeug-Optionen, die einer Familie zugeordnet sind, sind unter dem Familien Element vehicle- OptionFamily als vehicleoption angelegt und halten die aus dem Modell bekannten Attribute. Auch in diesem Austauschformat wurde anhand von Schlüsseln festgelegt, dass zum Beispiel eine Familie einen eindeutigen Namen und eine eindeutige PR-Nummer besitzen muss. 5.5 Diagnosebereitschaft einer Komponente an den Prozessorten Da für das komplette Test-Umgebungs-Modell keinerlei maschinenlesbare Daten zur Datenintegration vorhanden sind, ist auch die Beziehung diagnostizierbar / verbaut zwischen der Fahrzeug- Komponente, dem Prozessort und den Ressourcen nicht gegeben. Da diese Beziehung von den Komponenten ausgeht, wird diese nicht in das Austauschformat der Test-Umgebung integriert, sondern ein gesondertes Austauschformat für diese Beziehung erzeugt. In diesem Austauschformat handelt es sich lediglich um eine Beziehung zwischen drei Komponenten, bei der eine Komponente an einem Prozessort unter der optionalen Bedingung einer Ressource diagnostizierbar bzw. verbaut sein muss. Aus diesem Grund wird als Element die Komponente, component, eingeführt mit dem bekannten Kindelement referenceelement, welches eine externe Datei für weitere Informationen referenziert. Der Wurzelknoten und das Element component werden in der Abbildung 5.13(a) und 5.13(b) gezeigt. (a) Wurzelknoten und Komponentenelement (b) Komponentenelement Aufgrund der Tatsache, dass von einer Komponente aus mindestens ein Prozessort referenziert werden muss, wird ein Referenzelement processplaceref angelegt, welches als Attribute die Attribute der Attributgruppe beinhaltet. Analog dazu werden die Ressourcen als resourceref referenziert, wobei diese optional angegeben werden können, da nicht jede Komponente die Bedingung einer Ressource an einem Prozessort beansprucht. 5.6 Befüllung im Überblick In der folgenden Grafik, Abbildung 5.13, wird ein Überblick für alle verwendeten Austauschformate und deren zu befüllende Daten der Datenbasis aufgezeigt. Die Dateien ECU_Konfiguration und LAS wurden von der Automobilindustrie übernommen und zur Integration von Komponenten und deren Attribute sowie der LAS benutzt. Die anderen Dateien sind die in den vorherigen Abschnitten beschriebenen neu erzeugten Austauschformate. 55

66 56 5. Datenintegration Fahrzeug Optionen Fahrzeug Familien Beziehung der Fahrzeug-Optionen zu Fahrzeug-Projekten Sowie deren Attribute Beziehung abhängig zwischen Fahrzeug- Komponenten Mit deren Attributen Abfolge (abstrakt) Standard Abfolgen Komponentenspezifische Abfolgen Abhängigkeiten zwischen den Abfolgen Zustände Mit deren Beziehungen und Attributen Fahrzeug-Optionen-Modell Komponentenabhängigkeiten Abfolgen-Modell ECU_Konfiguration LAS Test-Umgebungs-Modell Beziehung diagnosebereiter Komponenten Fahrzeug Projekte Fahrzeug Komponente - Steuergeräte - Nicht Steuergeräte Mit deren Beziehungen und Attributen Werke Montagelinien Prozessorte Ressourcen Mit deren Beziehungen und Attributen Beziehung diagnosebereit / verbaut zwischen Fahrzeug-Komponenten, Prozessorten und Ressourcen Abbildung 5.13: Austauschformate und deren zu befüllende Informationen 56

67 6. Konzeption der Testplanüberprüfung In diesem Kapitel wird die Überprüfung des Testplans und die daraus resultierende Architektur vorgestellt. Anhand dieses Modells wird aufgezeigt, wie die Datenbasis anhand der Modelle gefüllt, die Testabläufe in eine standardisierte Objektstruktur übertragen werden, die Überprüfung des Testplans aufgeteilt bzw. ausgeführt wird und Vorüberlegungen für die Stufen 2 und 3 vorgenommen wurden. 6.1 Testplan Im Kapitel 2.3 wurde angesprochen, dass es derzeit verschiedene proprietäre Testplanformate zum einen und zum anderen das sich derzeit in der Entwicklung befindende standardisierte Testplanformat OTX [Int12] gibt, welches von einer Gruppe der ISO spezifiziert wird. Um all diese Formate und auch eventuell neu aufkommende proprietäre Formate in der Zukunft unterstützen zu können, wird als Grundlage der Verifikation der Testpläne das standardisierte Format OTX gewählt. Dies bedeutet, dass zur Laufzeit die Testpläne auf das OTX Format abgebildet werden (siehe Tabelle Äquivalente Elemente von SIDIS Pro in OTX ). Damit ist es möglich, eine einheitliche Überprüfung der verschiedenen proprietären Formate vorzunehmen. SIDIS Pro OTX Wurzelknoten CheckProgram otx Variablendeklaration Parameters declarations Programmablauf Statements procedures Parallele Regionen ParallelBlockContainerStatement parallel Parallele Region ParallelBlocks lane Abfolgen CheckModuleCallStatement action (Typ: ProcedureCall ) Zuweisungen AssignmentStatement action (Typ: Assignment) Tabelle 6.1: Äquivalente Elemente von SIDIS Pro in OTX 6.2 Überprüfung des Testplans Die Überprüfung des Testplans ist eine der Kernaufgaben dieser Arbeit. Die Testpläne mit deren Abfolgen sowie den zeitlichen Abhängigkeiten sind nicht direkt über die Aussagenlogik zu unterstützen. Bei der Literaturanalyse stellte sich heraus, dass kein Model-Checker [BK08a] zur Verfügung steht, welcher mit der erforderlichen Komplexität in entsprechender Zeit umgehen 57

68 58 6. Konzeption der Testplanüberprüfung kann und deshalb ist eine vollständige Überprüfung anhand eines Model-Checker nicht möglich. Ein weiteres Problem der SAT Solver ist, dass das Erfüllbarkeitsproblem der Aussagenlogik in der Komplexitätsklasse NP-Vollständig [GJ79] eingeordnet wird. Eine wesentliche Eigenschaft NP-vollständiger Probleme ist, dass sie sich vermutlich nicht effizient lösen lassen, sodass ihre Lösung auf realen Rechnern viel Zeit in Anspruch nimmt. Diese Eigenschaft wirkt sich in der Praxis nicht immer negativ aus, besonders wenn die Größenordnung der Eingabe sich in Grenzen hält. Dies ist leider bei dieser Arbeit nicht der Fall. Geht man von einem Testplan von mehreren hundert Abfolgen aus, würden alleine die sequentiellen Beziehungen zwischen diesen Abfolgen in die Zehntausende gehen, wodurch jedoch erst ein kleiner Teil der Anforderungen abgedeckt wäre. Zudem müssten die generierten Formeln in die für einen SAT Solver vorgesehene konjunktive Normalform gebracht werden. Carsten Sinz beschreibt in seiner Arbeit [SKK03], dass sich die Übersetzung einer Formel in die KNF in derselben zeitlichen Größenordnung befindet, wie das Lösen der Formeln für sich. Satz " Advanced methods were successful but they still took about as long as the SAT checking proper. Speed is important in our application, because thousands of theorems must be proved while the documentation specialist waits." Aufgrund dieser Feststellung und aus dem Grund, dass keine Objekte und Beziehungen modelliert werden können, kommen SAT Solver für die vollständige Überprüfung nicht in Frage. Mit der Prädikatenlogik [Ham78] hätte man die Möglichkeit, Objekte und ihre Beziehungen zu modellieren. Da die Prädikatenlogik eine Erweiterung der Aussagenlogik ist, steigt die Komplexität des Problems. Für das im Jahre 1928 gestellte Entscheidungsproblem der Prädikatenlogik von David Hilbert [Zac05], wurde 1936 von Alan Turing und Alonzo Church festgestellt, dass dieses unlösbar ist, siehe Halteproblem [Tur36]. Satz Das Halteproblem beschreibt die Frage, ob die Ausführung eines Algorithmus zu einem Ende gelangt. Obwohl das für viele Algorithmen leicht beantwortet werden kann, konnte der Mathematiker Alan Turing beweisen, dass es keinen Algorithmus gibt, der diese Frage für alle möglichen Algorithmen und beliebige Eingaben beantwortet. Diesen Beweis vollzog er an einer Turingmaschine. Diese Arbeiten zeigen uns auf, dass die Prädikatenlogik für die vollständige Überprüfung der Anforderungen an diese Arbeit, wie die Aussagenlogik, nicht verwendet werden kann: Zum einen aufgrund der genannten Gründe und zum anderen aus dem Grund, dass lediglich für die Prädikatenlogik mit einstelligen Prädikaten 1. Stufe gezeigt wurde, dass dies gelöst werden kann [Cza00]. Für diese Arbeit müssen Beziehungen zwischen Abfolgen modelliert werden, welche ein zweistelliges Prädikat bedingt, wie zum Beispiel Abfolge A ist sequentiell vor Abfolge B, sequentiellvor(a,b). Auf Basis dieser Informationen wurde für diese Arbeit eine Aufteilung der Überprüfung in eine Algorithmische Überprüfung sowie eine Überprüfung mittels SAT Solver vorgenommen. Das einzelne Vorgehen dieser Überprüfungen wird in den nächsten Abschnitten dieses Kapitels erläutert. Im Abschnitt wird die Architektur der Software mit dessen Komponenten und Besonderheiten vorgestellt Architektur Damit eine korrekte Überprüfung der Anforderungen stattfinden kann, wird zum einen eine Schnittstelle zum Einlesen und zur Konvertierung der Testpläne auf die auf OTX basierende Objektstruktur sowie eine weitere Schnittstelle zum Integrieren der Daten in die Datenbank gebraucht. Auf Basis dieser Informationen kann eine Überprüfung der Testpläne über die Algorithmische Überprüfung und die Überprüfung mittels Model-Checker stattfinden. Damit im Fehlerfall eine eindeutige und detaillierte Fehlermeldung ausgegeben werden kann, muss eine Fehlerausgabe vorhanden sein. 58

69 6.2. Überprüfung des Testplans 59 Auf der Grundlage dieser Informationen wird die Architektur in vier Teile unterteilt: 1. Das Einlesen des Testplans in eine zur Laufzeit bestehende Objektstruktur, OTX 2. Die Austauschformate und die Integration der Daten die Datenbasis mit den Regeln und Fakten der Überprüfung sowie die Dynamischen Informationen 3. Die Testplanüberprüfung mittels Algorithmischer Überprüfung und der Überprüfung mittels Model-Checker 4. Der Ausgabe der Überprüfung auf Korrektheit des Testplans Testplan Automobil- Modell Abfolgen- Modell Test- Umgebungs- Modell Gewählte Optionen Konvertierung in einheitliches Format Integration der Daten WLAN- Durchsatz Objektstruktur Datenbasis Dynamische Informationen Aktive Testläufe Ehrfahrungswerte Vorverarbeitung der Daten Abgebrochene Tests Algorithmische Überprüfung Überprüfung mittels Model-Checker Vorgeschlagener Testablauf ist vereinbar mit der Modell Datenbasis. Ja Testplan gültig? Nein Inkonsistenzen werden aufgezeigt. Abbildung 6.1: Modell der Testplanüberprüfung Aus dem Abschnitt 6.1 ist bekannt, wie der Testplan zur Laufzeit gespeichert wird. Dies ist in der Architektur der Software in der oberen linken Ecke angesiedelt, Testplan und Objektstruktur. Der Testplan wird als OTX-Objekt gespeichert und ausgehend von diesem für die Algorithmische Überprüfung verwendet und einem Vorverarbeitungsschritt übergeben, welcher relevante Informationen für den Model-Checker extrahiert und aufbereitet. Die Datenbasis wird, siehe Kapitel 5, mittels der Austauschformate gefüllt. Auf Basis der Regeln und Fakten der Datenbasis und der angesprochenen Objektstruktur wird eine Überprüfung des Testplans vorgenommen. Als Ergebnis wird eine Ausgabe erwartet, welche besagt, ob der Testplan korrekt ist oder nicht. Im Falle, dass dies nicht der Fall sein wird, wird eine ausführliche Fehlerbeschreibung ausgegeben. Die Dynamischen Informationen, auf der rechten Seite der Grafik, wurden bereits für die Stufe 2 und 3 eingeführt. Anhand von diesen Informationen könnte zum Beispiel in der Stufe 3 direkt auf äußere Umstände bei der Testplanerzeugung eines einzelnen Fahrzeuges eingegangen werden. Da diese Informationen von Fahrzeug zu Fahrzeug verschieden sind, zum Beispiel die gewählten Optionen eines Käufers, wird von dynamischen Informationen gesprochen. Die Dynamischen Informationen werden in dieser Arbeit nicht weiter behandelt. 59

70 60 6. Konzeption der Testplanüberprüfung Algorithmische Überprüfung Bei der Algorithmischen Überprüfung wird zum Überprüfen der einzelnen Anforderungenm welche in diesem Abschnitt vorgestellt werden, Informationen aus der Wissensbasis, mit denen diese Überprüfungen überhaupt erst vollzogen werden kann, herangezogen. Da es verschiedene Typen von Anforderungen gibt, wird in diesem Abschnitt zuerst auf die Abfolgeformate der einzelnen Abfolgen eingegangen. Denn würde der Abfolgenamen einer Abfolge nicht korrekt geparst werden können, wodurch essenzielle Informationen wie zum Beispiel die Komponenten und der Bezeichner extrahiert werden, so könnte keine korrekte Überprüfung der Abfolgen und ihre Beziehungen untereinander erfolgen. Die Überprüfung dieser Anforderung und die Anforderung der Gleichzeitig offene Verbindungen zu Steuergeräten, werden bei einer Simulation des Durchlaufes eines Testplans mit der Verifikationssoftware geprüft. Bei diesem Durchlauf werden für die spätere Überprüfung der weiteren Anforderungen mehrere Objektstrukturen, zum Beispiel mit Beziehungsinformationen über die Abfolgen, aufgebaut. Anhand dieser Objektstrukturen können die Überprüfungen der Diagnosebereite und verbaute Komponenten an Prozessorten, Sequentielle Abhängigkeiten und der Parallele Abhängigkeiten vorgenommen werden. Da sich bestimmte Anforderungen in ihrem Informationsbedürfnis ähneln, zum Beispiel, dass diese die Struktur, Informationen zu sequentiell vor- oder nachgelagerten Abfolgen oder parallele Abfolgen benötigen, wurden diese Arten von Abhängigkeiten in den Abschnitt Sequentielle Abhängigkeiten und zusammengefasst. Aufbauend auf der gut gewählten Struktur der Datenbasis ist eine Überprüfung entlang der Informationen aus dieser möglich. Hierzu werden Prüfroutinen beschrieben, welche eng an der Struktur der Datenbasis angelehnt sind und dieses strukturelles Wissen nutzen. Ein Vorteil ist, dass die Prüfroutinen bei kleineren Änderungen nicht angepasst werden müssen. Das Wissen in der Datenbasis ist nicht fixiert, sondern kann sich ständig ändern, zum Beispiel wenn neue Abhängigkeitsinformationen über Abfolgen und Komponenten für einen schon bekannten und implementierten Abhängigkeittyp erhoben werden oder ein neues Fahrzeugmodell eingefügt wird. Die Strukturierung der Datenbasis bleibt durch diese neuen Informationen unverändert, wodurch keine Anpassungen der Prüfroutinen durchgeführt werden müssen. Diese Prüfroutinen wurden speziell für die jeweiligen Bedürfnisse der Anforderungen entwickelt, wobei sich das Grundkonzept der verschiedenen Prüfroutinen ähnelt. Es werden die zu überprüfenden Informationen aus dem Testplan extrahiert und mittels der in der Datenbank abgespeicherten Regelbasis verglichen. Würde ein Konflikt vorliegen, so könnte dieser mit einer aussagekräftigen Fehlermeldung, aufgrund der Informationen aus der Datenbasis, visualisiert werden Abfolgeformate Anhand des zugrundeliegenden Testplans und der Abfolgennamen sowie der definierten Syntax eines Abfolgenamens aus Abschnitt 2.3 kann die Anforderung Abfolgenformate beim ersten Kontakt beim Durchlauf durch den Testplan mit einer Abfolge überprüft werden. Falls die Syntax der Abfolge im Testplan nicht mit der definierten Syntax übereinstimmt, wird eine Ausgabe erzeugt und diese Abfolge für die spätere Verifikation ignoriert. Diese Abfolgen werden ignoriert, da keine Informationen über die Komponenten und den Bezeichner aus dem Abfolgenamen extrahiert werden können. Dafür ist eine einheitliche Syntax wichtig. Die Überprüfung des Abfolgennamens wird über einen regulären Ausdruck, siehe Abschnitt 2.3, vorgenommen. Falls sich die Abfolgeformate ändern würden, müsste eine Anpassung des Parsens vorgenommen werden, sodass die Komponenten und der Bezeichner eindeutig erkannt werden. Diese Abfolgenamen werden in SIDIS Pro als auch in OTX identisch behandelt Gleichzeitig offene Verbindungen zu Steuergeräten Für die Überprüfung Gleichzeitige offene Verbindungen zu Steuergeräten sind aus der Datenbasis die einzelnen Protokolltypen der Steuergeräte bekannt. Diese werden genutzt, um bei dem ersten Kontakt beim Durchlaufen des Testplans mit einem Steuergerät die Verbindung zu diesem aufzubauen. Alle weiteren Vorkommen zu einer Abfolge mit diesem Steuergerät vor einem Verbindungsabbau des gleichen Steuergerätes werden ignoriert, sodass keine Verbindung zu einem Steuergerät mehrfach als geöffnet betrachtet wird. Sobald ein Verbindungsabbau auf eine Komponente ausgeführt wird, wird diese Verbindung geschlossen, kann bei einem erneuten Vorkommen 60

71 6.2. Überprüfung des Testplans 61 der Komponente in einer Abfolge wieder geöffnet werden. Falls diese Komponente ein Master ist, werden sowohl alle Verbindungen zu dessen Slaves als auch zu sich selbst geschlossen. Die Information, welche Komponente Master und Slave ist, und welcher Slave zu welchem Master gehört, wurde in der Datenbasis in der Relation der Fahrzeug-Komponenten hinterlegt. Durch die Information, ob eine Verbindung zu einem Steuergerät, mit dessen Protokolltyp, geöffnet bzw. geschlossen ist, wird bei jeder Synchronisation eines Parallellblockes eine Überprüfung gestartet. Falls an den Synchronisationspunkten sowie am Ende des Testplans mehr als die aus dem Abschnitt 3.6 bekannte Anzahl der Verbindungen offen ist oder am Ende des Testplans nicht alle Verbindungen zu den Steuergeräten korrekt geschlossen wurden, muss ein Fehler mit Informationen über das Steuergerät ausgebeben werden Diagnosebereite und verbaute Komponenten an Prozessorten Um zu überprüfen, ob die Fahrzeug-Komponenten eines Testplans an dem Prozessort an dem der Testplan ausgeführt wird, diagnosebereit bzw. verbaut sind, wird der Testplan zur Analyse des Testplans durchlaufen und wichtige Informationen in einer Objektstruktur zur Laufzeit gespeichert. Bei diesem Durchlauf werden unter anderem die Fahrzeug-Komponenten extrahiert und als Menge gespeichert, denn für die Überprüfung dieser Anforderung sind nicht die Beziehungen oder die Reihenfolge, sondern das Vorkommen der einzelnen Fahrzeug-Komponenten wichtig. Die Menge der Fahrzeug-Komponenten wird aus den Namen der Abfolgen eines Testplans extrahiert, siehe Testplan. Mit Hilfe dieser Menge und der Informationen des Automobil- bzw. Test- Umgebungs-Modells (siehe Abbildung 4.7 ER-Diagramm: Test-Umgebungs-Modell ) kann anhand der Beziehung, ob eine Fahrzeug-Komponente diagnosebereit / verbaut an einem Prozessort unter der Bedingung einer optionalen Ressource ist, geprüft werden, ob Fahrzeug-Komponenten im Testplan vorkommen, welche an diesem Prozessort noch nicht diagnosebereit bzw. verbaut sind Sequentielle Abhängigkeiten Die Anforderungen Abhängigkeiten zwischen Abfolgen, Abhängigkeiten zwischen Bezeichner und Abfolgen und ihre Vorbedingungen haben die Gemeinsamkeit, dass sie sequentiell von ihren Vorgänger- oder Nachfolgerabfolgen abhängig sind. Im Testplan, siehe Abschnitt 2.3, wurde auf die strukturellen Beziehungen zwischen Abfolgen eingegangen. Diese wird für diese Anforderungen ausgenutzt, damit die Abfolgen paarweise in die Beziehung: Abfolge A wird vor/nach Abfolge B ausgeführt gesetzt werden, sodass für eine Abfolge alle Vorgänger und Nachfolger bekannt sind. Abfolgen werden mit ihren nach- bzw. vorgelagerten Abfolgen direkt in Beziehung gesetzt. Transitivitäten bei den Abhängigkeiten zwischen Abfolgen werden nicht betrachtet, sondern müssen über eine direkte Regel in der Datenbasis einzeln repräsentiert werden. Anhand dieser Informationen und der Regeln und Fakten aus der Datenbasis, sowie den Informationen aus dem Abfolgenamen ist es möglich, die genannten Anforderungen zu überprüfen und aussagekräftige Fehlermeldungen im Fehlerfall auszugeben. Bei der Anforderung Abfolgen und ihre Vorbedingungen werden zusätzlich Listen mit den zu veränderten Werten des Zustandes einer Abfolge, den Vorbedingungen einer Abfolge und den Variablen mit ihren jeweils aktuellen Werten gehalten, sodass eine direkte Überprüfung dieser Anforderung möglich ist. Hierbei wird ein Durchlauf des Testplans simuliert und bei jeder auszuführenden Abfolge deren Ausführbarkeit anhand der gespeicherten Werten der Vorbedingungen getestet Parallele Abhängigkeiten Zu den parallelen Abhängigkeiten gehört die Anforderung Abhängigkeiten zwischen Steuergeräten und die Nicht parallele Abhängigkeit der Abfolgen, siehe Abschnitt Aufgrund der strukturellen Beschaffenheit des Testplans, welche im Abschnitt 2.3 aufgezeigt wurden, können diese anhand dieser Abfolgen und deren Fahrzeug-Komponenten in eine parallele Beziehung gesetzt werden. Mithilfe dieser und der Information über die Komponentenabhängigkeiten aus der Datenbasis lässt sich ein Rückschluss über die Korrektheit dieser Beziehung ziehen. Dabei ist für eine Abfolge bzw. Komponente bekannt, mit welchen Abfolgen bzw. Komponenten sie in 61

72 62 6. Konzeption der Testplanüberprüfung paralleler Ausführung steht. Da aus der Datenbasis eine kleinere Menge von Regeln der Nicht- Parallelität bekannt ist, wird die Liste aus der Datenbank verwendet um diese gegen die erzeugte Liste aus dem Testplan laufen zu lassen. Wird ein Fehler entdeckt, muss ein Fehler mit Detailinformationen über die Abfolgen und die Kategorie des Fehlers ausgegeben werden Überprüfung mittels SAT Solver Die Überprüfung mittels SAT Solver wird an den Teilen der Anforderungen eingesetzt, bei denen dieser mit booleschen Formeln direkt sowie mit Einschränkungen indirekt umgegangen wird. Dies trifft speziell auf die Anforderung Logischer-Ausdruck-Satz bei Verzweigungen im Testplan zu. Bei dieser Anforderung soll sowohl überprüft werden, ob der zugrundeliegende LAS ein Modell (Erläuterung siehe Kapitel ) hat, als auch, ob ein Modell mit der Einschränkung, dass von jeder Fahrzeug-Optionen-Familie maximal eine Option verbaut sein darf, vorhanden ist. Letzteres wird durch eine boolesche Formel eingeschränkt, sodass es n Konjunktionen gibt, wobei n die Anzahl der Fahrzeug-Optionen einer Fahrzeug-Familie repräsentiert und in jeder Konjunktion genau eine dieser Variablen positiv sein muss. Für die positiven Variablen der Konjunktionen gilt dabei, dass deren Schnittmenge die leere Menge ist. Dies bedeutet, dass alle positiven Variablen der Konjunktionen paarweise verschieden sein müssen. Wäre dies nicht der Fall, so könnte es entweder Redundanz oder Inkonsistenzen in der Formel geben. Die Konjunktionen werden verodert. Durch diese Veroderung der einzelnen Konjunktionen wird gewährleistet, dass die Formel genau dann wahr ist, wenn maximal eine Variable positiv und die restlichen Variablen negativ sind. Die gesamte Formel liegt aufgrund deren Struktur in der disjunktiven Normalform (DNF) vor. Als Beispiel bei der Familie der Rechts- und Linkslenker mit den Fahrzeug-Optionen Rechtslenker (Variable: RL) und Linkslenker (Variable: LL): (RL LL) ( RL LL) Bei diesem Beispiel ist n = 2 und eine leere Schnittmenge, da {RL} {LL} =. Die Fahrzeug-Optionen sind in der Datenbank mit ihren Familien gespeichert. Anhand der Fahrzeug- Optionen, welche im LAS enthalten sind, werden die Familien mit ihren Fahrzeug-Optionen aus der Datenbank geholt und mit dem beschriebenen Vorgehen in eine Bedingung, maximal eine Fahrzeug-Option pro Familie kann wahr sein, als Formel in konjunktive Normalform gesetzt. Falls mehrere Fahrzeug-Optionen derselben Familie im LAS enthalten sind, wird dies nur einmalig ausgeführt. Diese Bedingungen der einzelnen Familien werden mit dem booleschen Operator, da jede Bedingung betrachtet werden muss, verbunden. Nachdem alle Familienbedingungen erzeugt und verbunden wurden, wird der LAS mit den Familienbedingungen, mittels einer Verknüpfung, in Beziehung gesetzt, sodass der LAS unter der Bedingung der Familienbedingungen geprüft wird. Für jede Überprüfung eines LAS wird das Regelwerk der Familienbedingungen erneut aufgebaut. Da jedoch in verschiedenen LAS Fahrzeug-Optionen gleicher Familien vorkommen können, werden die erzeugten Familienbedingungen zwischengespeichert. Da die SAT-Solver als Eingabeformat die konjunktive Normalform (KNF) benötigen, muss die genannte Formel mit der Einschränkung von Fahrzeug-Optionen einer Familie in eine äquivalente Formel in KNF umgewandelt werden. Da die Anzahl der Formeln eher gering ist, haben die erläuterten Probleme aus dem Abschnitt 6.2 kaum Einfluss. Diese Formeln werden als Regeln einer Wissensbasis angesehen und werden zur Überprüfung des LAS bei Verzweigung in einem Testplan herangezogen. Sofern der SAT-Solver ein Modell mit dieser Einschränkung findet, ist belegt, dass jeder Pfad dieser Verzweigung im Testplan theoretisch ausgeführt werden kann, wodurch Fehler durch den Testplanentwickler gefunden werden können. 62

73 7. Implementierung Die Implementierung wird in zwei Hauptkomponenten untergliedert: In eine Komponente zur befüllung der Datenbasis, siehe Abschnitte sowie und in eine Komponente zur Verifikation von Testplänen gegen die Wissensbasis, siehe in den Abschnitten sowie Da sich die Implementierungen in gewissen Teilen überschneiden, wie zum Beispiel beim Einlesen der Parameter über die Kommandozeile und der Konfigurationsdatei, werden diese Teile der Implementierung gesondert in den Abschnitten Kommandozeilen Parameter und Konfigurationsdatei behandelt. 7.1 Aufbau In den nächsten zwei Abschnitten werden der Aufbau und die Modelle der Datenintegration sowie der Verifikation der Testpläne erläutert. Dabei wird zuerst auf das Modell und dessen Eigenschaften eingegangen. Der Aufbau wird anschließend kurz angerissen, da in den Abschnitten Datenintegration und Verifikation explizit auf die einzelnen Pakete der Programme eingegangen wird Datenintegration Die Implementierung der Datenintegration wurde entwickelt, um Daten auf einfache und verständliche Weise, ohne Kenntnisse der effektiven Speicherung innerhalb der Datenbasis, in diese integrieren zu können. Ein Grundstein für die Integration der Daten sind die bekannten Austauschformate, welche im Kapitel Datenintegration definiert wurden. Mit diesen ist es auf einfache Art möglich, Daten in die Datenbasis einzubringen oder bereits eingebrachte Daten zu aktualisieren. 63

74 64 7. Implementierung Start der Datenintegration Dateien für die Befüllung der Datenbank Einlesen und Verarbeiten der Kommandozeilenparameter Ja Daten korrekt? Nein Fehlerausgabe Fahrzeug Projekt und Komponenten Komponenten- Abhängigkeiten Projekt Optionen Information der Datenintegration Programm wird beendet Abfolgen Test-Umgebung Komponente ist diagnosebereit/verbaut an Prozessort Abbildung 7.1: Flussdiagram der Datenintegration In der Abbildung 7.1 ist ein Flussdiagramm der Datenintegration zu sehen. Zuerst werden die Kommandozeilen Parameter eingelesen. Diese sind für die Datenintegration in der Tabelle 7.1 angegeben. Sofern diese korrekt übergeben wurden, werden die übergebenen Austauschformate ausgelesen und deren Daten in die Datenbasis integriert. Bei der Integration über die Austauschformate ist die Reihenfolge der einzelnen Austauschformate von Bedeutung. Wie man in der Abbildung der Datenbasis 4.12 erkennen kann, wurden die einzelnen Relationen via Fremdschlüsselbeziehungen mit einander in Beziehung gesetzt, um die Integrationsbedingungen der einzelnen Einträgen korrekt darzustellen und keine Beziehung zwischen Einträge erzeugt, welche nicht vorhanden sind. Aufgrund dieser Integrationsbedingung ist die Reihenfolge der Integration über die Austauschformate essentiell, sodass zum Beispiel keine Abhängigkeiten zwischen Komponenten erzeugt werden, wobei die Komponenten für diese Abhängigkeit erst zu einem späteren Zeitpunkt integriert werden. Die angegebene Reihenfolge im Flussdiagramm ist aus diesem Grund verpflichtend. 64

75 7.1. Aufbau AAAFT Die Implementierung der Verifikation wurde entwickelt um die zuvor eingefügten Daten, welche aus Regeln und Fakten bestehen, der Datenbasis zu nutzen, um mit diesen Informationen einen Testplan zu verifizieren. Die Kommandozeilen Parameter können im folgenden Abschnitt eingesehen werden. Anhand des übergebenen Testplans wird eine Objektstruktur im OTX Format erzeugt. Ist der Testplan bereits im OTX Format vorhanden, wird ein Mapping via Java Architecture for XML Binding (JAXB) [Sch06] vorgenommen. Ist der Testplan jedoch in einem proprietären Format übergeben worden, wird anhand deren Struktur und Meta-Informationen ein korrektes Mapping ausgewählt und mittels XSLT [Tid02] durchgeführt. Anschließend wird analog zum vorherigen Fall ein Mapping auf die interne OTX Objektstruktur vorgenommen. Die OTX Objektstruktur wird parallel durchlaufen und die ersten Tests zur Verifikation, Einhaltung der Vorbedingungen bei Abfolgen und gleichzeitig offene Verbindungen zu Komponenten, vorgenommen sowie essentielle Daten und ihre strukturellen Beziehungen untereinander extrahiert. Start der Verifikation Einlesen und Verarbeiten der Kommandozeilenparameter Testplan Ja Daten korrekt? Nein Fehlerausgabe Ja Proprietäres Testplanformat? Nein Konvertiere via XSLT den proprietären Testplan in OTX Wandle OTX Testplan in Objektstruktur zur Laufzeit um Fehlerausgabe bei zu vielen parallelen Verbindugen Teste gleichzeitige offene Verbindungen zu Steuergeräten Durchlaufe Objektstruktur parallel und extrahiere Komponenten und Abfolgen sowie deren Strukturen untereinander Extrahiere nur Abfolgen bei denen der Abfolgenamen korrekt ist. Ansonsten wird ein Fehler ausgebeben und die Abfolge ignoriert. Programm wird beendet Fehlerausgabe bei falscher Vorbedingung der Abfolge Teste die Abfolge auf korrekte Vorbedingungen und setze die Zustände durch Abfolge Informationen korrekt extrahiert? Nein Ja Fehlerausgabe bei Verletzung der Abhängigkeit Teste Komponenten auf Abhängigkeiten Fehlerausgabe bei Verletzung der Abhängigkeit Teste Abfolgen auf Abhängigkeiten Fehlerausgabe bei offenen Verbindungen Teste ob alle Verbindungen zu Komponenten geschlossen wurden. Abbildung 7.2: Flussdiagramm der Verifikation Sobald diese Daten korrekt extrahiert wurden, werden weitere Tests zur Verifikation vorgenom- 65

76 66 7. Implementierung men. Komponenten und Abfolgen werden auf die bekannten Anforderungen aus Kapitel 3 geprüft und schließlich getestet, ob alle Verbindungen zu Komponenten am Ende eines Testplans geschlossen wurden. Falls diese Tests auf Fehler innerhalb eines inkorrekt modellierten Testplans stoßen, wird eine aussagekräftige Fehlermeldung ausgegeben. Diese Fehlermeldungen wurden in Kategorien eingeteilt, welche im Abschnitt beschrieben wurden. 7.2 Das Framework Kommandozeilen Parameter Die Übergabe von Parametern durch die Kommandozeile (Commandline) ist eine gängige Art, um Konfigurationen und Parameter vom Anwender an ein Programm zu übergeben. Innerhalb des Frameworks handelt es sich um zwei verschiedene Programme: Zum einen das Programm zur Befüllung der Datenbasis und zum anderen zur Verifikation des Testplans anhand der Regeln und Fakten aus der Datenbasis. Deshalb gibt es zwei Einstiegspunkt (Main-Methoden) zum Starten dieser Programme. Aus diesem Grund unterscheiden sich die Kommandozeilen Parameter dieser zwei Einstiegspunkte leicht. inputfile Übergabe des Testplans inputfiles Übergabe der Austauschformate. Getrennt mittels Semikolon. processplace Übergabe des Prozessortes als String (VP1,VP2,..) debug Schaltet den Debug-Mode ein. inputfile inputfiles processplace debug Verifikation Ja Nein Nein Nein Datenintegration Nein Ja Nein Nein Tabelle 7.1: Kommandozeilen Parameter der einzelnen Einstiegspunkte der Implementierung In der Tabelle 7.1 werden die obligatorischen Vorkommen der Parameter beschrieben. Würde einer dieser Kommandozeilenparameter nicht korrekt oder gar nicht übergeben werden, so wird der Anwender anhand einer aussagekräftigen Fehlermeldung darauf hingewiesen. Um ein Gefühl für eine Kommandozeilenparameterübergabe zu bekommen, wird als nächstes ein Beispiel für die Befüllung und die Verifikation angegeben. Verifikation -inputfile "D:/Diplomarbeit/Testplaene/ABL_VP2.xml" -debug Datenintegration -inputfiles "C:/Austauschformate/TestAmbientModellTest.xml;... ;D:/ComponentDependenciesTest.xml" -debug Konfigurationsdatei Konfigurationen, auf die schnell zugegriffen werden sollen und die sich von einem Durchlauf zum Nächsten unterscheiden können, wurden im vorherigen Abschnitt eingeführt. Da es jedoch auch Konfigurationen gibt, die über eine längere Zeitdauer unverändert bleiben, wurde eine Konfigurationsdatei angelegt, in der alle nützlichen Konfigurationen untergebracht werden können. Für das Einlesen und Verwenden dieser Konfigurationsdatei wurde die von Java bereitgestellte Klasse Properties [Sun12] verwendet. In dieser werden die Informationen über die Datenbankanbindung sowohl für die MySQL (Präfix: m*) als auch für die Oracle (Präfix: o*) Datenbank und Informationen über das Mapping und Anforderungen gespeichert. Auszug der Konfigurationsdatei: 66

77 7.2. Das Framework 67 ############################ # Database connection info # ############################ databasetype = MYSQL # mysql muri = localhost mdatabase = Datenbankname mport = meinport musername = meinbenutzername mpw = meinpasswort # oracle ouri = localhost osid = meinsid oport = meinport ousername = meinbenutzername opw = meinpasswort ############################ # Mapping # ############################ sidispro2otxxslt = xslt/sidispro2otx.xslt otxfromsidisprotemp = temp/otxfromsidisprotemp.otx otxxsd = xsd/core/otx.xsd ############################ # Dependencies # ############################ maxconnectionsuds = 10 maxconnectionskwp = 10 maxconnectionskwpuds = 14 ############################ Da jeweils für Oracle und MySQL eigene Datenbankverbindungen angegeben werden können, müssen diese bei einem Wechsel der Datenbank nicht gesondert editiert werden. Die derzeit aktive Datenbankverbindung wird anhand der Einstellung databasetype angegeben. Diese Konfigurationsdatei ist im Hauptverzeichnis des Java Programmes mit dem Namen AAAFT.properties zu finden. Unter Mapping sind die derzeit wichtigen Informationen für das Mapping der proprietären Formate, SIDIS Pro, auf OTX via XSLT sowie das OTX Schema und den neu erzeugten Testplan im OTX Format gespeichert. Diese wurden in der Konfigurationsdatei angesiedelt, sodass diese Werte ohne erneutes Übersetzen 1 des Programmcodes verändert werden können. Analog gilt dies bei bestimmten Werten der Abhängigkeiten, wie in diesem Fall der Anzahl der gleichzeitig offenen Verbindungen einzelner und aller Protokolle. Das Auslesen und Setzen der Konfigurationsdatei wird über die Methoden setpropertyfile(...) und getpropertyfile() der Configuration Klasse vorgenommen Datenintegration Die Datenintegration ist ein Teilkomponente des A 3 FT (AAAFT, Automatisiertes Anordnen von Arbeitsschritten des Fertigens und Testens) Frameworks. Es wird unabhängig von der Verifika- 1 Ein Compiler ist ein Computerprogramm, das andere Programme aus einer Quellsprache zu ihrem semantischen Äquivalent in einer Zielsprache umwandelt. 67

78 68 7. Implementierung tionskomponenten gestartet, benutzt jedoch in einigen Fällen dieselben Klassen wie die Verifikationskomponente (Datenbankverbindungen, Parser für die Kommandozeile,...). Angesiedelt ist die Datenintegrationskomponente im dataintegration Paket (siehe Abbildung 7.3). In diesem Paket befindet sich die DataIntegrationStartUp Klasse. Diese Klasse beinhaltet eine Main-Methode über welche die Datenintegration mit den definierten Austauschformaten aus dem Kapitel Datenintegration in die relationale Datenbank aus Kapitel 4.3 eingefügt werden kann. Abbildung 7.3: Implementierung: DataIntegration -Paket Zuerst werden einige Konfigurationen, wie zum Beispiel das Setzen des Java Loggers, der Konfigurationsdatei und weiterer Konfigurationen in der Startklasse, vorgenommen. Damit die Konfigurationen aus der Kommandozeile (siehe Abschnitt 7.2.1) in das Programm einfließen können, wurde eine Parser Klasse angelegt. Das Objekt dieser Klasse filtert über die Methode parse- CommandLineDataIntegration() alle wichtigen Informationen aus der Kommandozeile. Falls eine obligatorische Information nicht vorhanden ist, wird eine aussagekräftige Fehlermeldung ausgegeben und das Programm beendet. Sofern alle Informationen in der Kommandozeile vorhanden sind, wird die Datenintegration gestartet. In der Klasse DataIntegration werden die verschiedenen Strategien zum Integrieren der einzelnen Austauschformate in der richtigen Reihenfolge gestartet. Aufgrund der Schlüsselbeziehungen zwischen den einzelnen Relationen der Datenbank ist es wichtig, dass zuerst Basisrelationen und zu einem späteren Zeitpunkt die Beziehungsrelationen gefüllt werden. Wäre dies nicht der Fall und wurde man zuerst eine Beziehungsrelation füllen, so würde eine Fehlermeldung für einen nicht vorhandenen Fremdschlüssel geworfen werden. Aus diesem Grund ist die Reihenfolge des Ausführens der einzelnen Strategien wichtig und muss eingehalten werden. Die einzelnen Strategien implementieren das DataIntegrationInterface, wodurch die öffentliche Methode execute() implementiert werden muss. In dieser Methode vollzieht sich die wesentliche Arbeit der Datenintegration. Da über die Kommandozeilenparameter lediglich eine Liste von Austauschformaten angegeben wird, muss jede Strategie für sich die richtige Datei der Austauschformate filtern. Darum wurde die Methode find*inputfile(...) implementiert, welche als Übergabeparameter eine Arrayliste mit allen durch die Kommandozeile übergebenen Dateien enthält. Aus den übergebenen Dateien wird anhand deren Strukturmerkmale die korrekte Datei für die einzelnen Strategien ausgewählt. Da die Austauschformate in XML vorliegen wird zum Parsen das Framework Virtual Token Descriptor for extensible Markup Language (VTD-XML, [Xim12]), welches unter der freien GNU General Public License (GPL) [Ros04] veröffentlich wird, benutzt. Mit Hilfe dieses Tools wird der XML-Baum durchlaufen und alle wichtigen Informationen für die Integration der Daten extrahiert und mittels der in der Kommandozeile ausgewählten Datenbankanbindung, welche im Database -Paket vorhanden ist (siehe Abbildung 7.4), in die Datenbank eingetragen. Falls ein Tupel erneut eingetragen werden sollte, wird ein SQLIntegrityCons- 68

79 7.2. Das Framework 69 traintviolationexception geworfen und abgefangen. Anhand dieses Fehlers ist klar, dass ein Konflikt mit einer Integritätsbedingung, also ein Konflikt mit einem Primärschlüssel, vorhanden ist, woraufhin das Einfügen des Tupels durch ein Update auf das Tupel mit diesem Primärschlüssel durchgeführt wird. Somit ist ein Editieren der Daten in der Datenbank gewährleistet. Abbildung 7.4: Implementierung: Database -Paket Zum Integrieren der Daten in die Datenbank wurde die Datenschnittstelle Java DataBase Connectivity (JDBC) [Cor12] verwendet. JDBC ist eine Datenbankschnittstelle der Java-Plattform, die eine einheitliche Schnittstelle zu Datenbanken verschiedener Hersteller bietet und speziell auf relationale Datenbanken ausgerichtet ist. Aufgrund dieses Frameworks ist es unproblematisch, verschiedene Datenbanktypen zu unterstützen, wie in diesem Fall MySQL [WAM02] und Oracle [Ora12]. Der Transfer der Daten wurde über PreparedStatement geregelt. Diese haben den Vorteil, dass der Typ der einzufügenden Variablen in ein SQL Statement angegeben werden kann, wodurch die Typsicherheit der einzelnen Variablen gewährleistet wird. Die einzelnen Strategien wurden jeweils als eine einzige Transaktion durchgeführt. Dies wurde durch die Befehle setautocommit(false), wodurch ein implizites commiten der einzelnen Updates auf der Datenbank verhindert wird, sowie durch das einmalige Commiten am Schluss der Transaktion sichergestellt. Durch diese Maßnahme kann es, bei Problemen bei der Integration der Daten, zu keiner partiellen Integration der Daten kommen, da die bekannten Eigenschaften ACID (Atomarität, Konsistenz, Isoliertheit und Dauerhaftigkeit, [Eic06a]) einer Datenbank, in diesem Fall besonders die Eigenschaft der Atomarität, dafür sorgt, dass eine Transaktion ganz oder gar nicht ausgeführt wird und dadurch im Fehlerfall keine inkonsistenten Zustände in der Datenbank vorhanden sein können Verifikation Fehlermeldungen In diesem Abschnitt werden die verschiedenen Fehlermeldungen der Verifikation kategorisiert und erläutert. Jede dieser Fehlermeldungen enthält eine zur Laufzeit eindeutige Zuweisung der Fehlermeldung zu den Abfolgen, welche diese Fehlermeldung ausgelöst haben. Falls eine Fehlermeldung durch mehrere Abfolgenpaare ausgelöst werden würde, werden alle Abfolgenpaare angegeben. 69

80 70 7. Implementierung Kategorie Beschreibung Testplan error Es wurde kein passendes XSLT-Schema für den übergebenen Testplan gefunden. Testplanformat error Der Testplan beinhaltet keine Abfolgen oder die Konvertierung ist fehlgeschlagen. Parallel error Die Anforderung, dass Komponenten und Abfolgen, die nicht parallel im Testplan vorkommen dürfen, wurde verletzt. Die Komponenten und die Abfolgen werden in der Fehlermeldung ausgegeben. Sequential before error Die Anforderung, dass Abfolgen in strikt sequentieller Reihenfolge vor einer anderen Abfolge kommen müssen, wurde verletzt. Connection error Die Verbindung einer Komponente ist am Ende des Testplans geöffnet bzw. die Grenze an gleichzeitig offenen Verbindungen zu Steuergeräten ist überschritten. Precondition error Der Wert des Zustandes, welcher von einer Abfolge als Vorbedingung gefordert wurde, ist nicht korrekt. Resource error Eine Ressource, welche bei der Beziehung diagnostiziert/verbaut einer Komponente benötigt wird, ist nicht am Prozessort vorhanden. Database error Anfrage an Datenbank konnte nicht korrekt vollzogen werden. Condition error Bedingung eines If-Else Blockes ist Fehlerhaft. Syntax error Die Syntax einer LAS-Formel ist nicht korrekt. Input error Übergebene Parameter inkorrekt oder nicht vorhanden. Parsing warning Wird ausgegeben, wenn ein Abfolgename nicht dem definierten Syntax entspricht. Tabelle 7.2: Fehlermeldungen der Verifikation Anhand dieser Tabelle und der Zuordnung der Abfolgen in der Fehlermeldung ist eine eindeutige und einfache Fehlerbehandlung möglich Configurations -Paket Das Configuration -Paket ist ein Hilfspaket, in dem Hilfsklassen zum Parsen, Messen der Laufzeit, Abspeichern von Konfigurationen und Konstanten angelegt wurde. Die zwei Hauptklassen dieses Pakets sind die Klassen Parser und Configuration. Diese werden zwingend für den korrekten Ablauf des Programmes benötigt. Die Klasse Parser enthält alle Funktionen zum Parsen von Abfolgenamen, Kommandozeilen Parameter, sowohl für die Datenintegration als auch für die Verifikation, sowie zwei kleinere Funktionen zum Parsen des Modellreihennamen und des Kürzels der Komponente. Das Parsen der Abfolgenamen extrahiert nicht nur die Komponenten sowie den Bezeichner, sondern testet den Abfolgenamen auf dessen Korrektheit der Anforderung Abfolgenformate. Dabei wird über einen regulären Ausdruck geprüft, ob der Abfolgename eine korrekte Syntax besitzt. Ist dies nicht der Fall, wird ein Parsing error mit der fehlerhaften Abfolge ausgegeben. Die Funktionen parsecommandline(...) und parsecommandlinedataintegration(...) übernehmen die Aufgabe, welche im Abschnitt beschrieben wurde. Sie extrahieren alle wichtigen Informationen aus den Kommandozeilen Parametern und speichern diese in der Configuration Klasse zur Laufzeit ab. Auf Basis der gespeicherten Konfigurationen wird ein korrekter Ablauf des Programmes überhaupt erst ermöglicht. Die Configuration Klasse speichert alle wichtigen Konfigurationen des Programmes zur Laufzeit. Diese Klasse ist als Singleton (Entwurfsmuster) [GHJV94] realisiert, wodurch nur ein Objekt 70

81 7.2. Das Framework 71 Abbildung 7.5: Implementierung: Configuration -Paket dieser Klasse existiert. Dadurch wird sichergestellt, dass jedes Objekt, welches Informationen von dieser Klasse erhalten möchte, diese auch bekommt und nicht mehrere Objekte dieser Klasse mit unterschiedlichen Informationen im System enthalten sind Database -Paket Das Database -Paket wurde im vorherigen Abschnitt eingeführt. In der Abbildung 7.4 ist der Aufbau dieses Paketes zu erkennen. Dieses Paket gewährleistet den Datenbankzugriff sowohl für die Datenintegration als auch für die Abfrage der Regeln und Fakten aus der Datenbasis, welche für die Verifikation benötigt werden. Über das Interface Database werden alle wichtigen Funktionen der konkreten Implementierungen, MysqlDatabase und OracleDatabase, gefordert. Die zwei konkreten Implementierungen für den Zugriff auf eine Mysql und Oracle Datenbank werden über die Konfigurationsdatei aus dem Abschnitt mit den Verbindungsinformationen versorgt. Die Funktionen der einzelnen Implementierungen sind selbsterklärend und werden nicht genauer betrachtet DataManager -Paket Im DataManager -Paket gibt es lediglich die DataManager Klasse. Diese Klasse hält die zur Laufzeit wichtigen Informationen. Es werden zum Beispiel die Zustände der Modellreihe sowie 71

82 72 7. Implementierung die Vorbedingungen der Abfolgen dieser Modellreihe gespeichert. Diese und weitere Informationen des DataManagers werden zu einem späteren Zeitpunkt für die Verifikation des Testplans verwendet und werden aus Performanzgründen einmalig aus der Datenbank extrahiert und zur Laufzeit gespeichert. Außerdem speichert der DataManager den in OTX konvertierten Testplan via addcheckroutine(...), sodass auf diesen zentral bei der Verifikation zugegriffen werden kann. Abbildung 7.6: Implementierung: DataManager -Paket Diese Klasse kann als Datenbank zur Laufzeit betrachtet werden. Daher wurde diese Klasse wie auch die Configuration Klasse als Singleton implementiert, sodass nur ein Objekt dieser Klasse im Programm vorhanden ist, welches alle übergebenen Informationen, auch die Datenbank Verbindung, in sich birgt. Da in der Verifikationsphase parallel auf diese Klasse zugegriffen wird, wurde die getinstance() Methode synchronisiert um ein thread-sicheres Zugreifen zu ermöglichen ExternalTestplanConverter -Paket Da in den vorherigen Abschnitten die Hilfspakete und ihre Klassen beschrieben wurden, werden wir uns nun um einen der zwei größeren Komponenten der Verifikation kümmern. In diesem Paket werden die proprietären Testplanformate eingelesen und in das standardisierte OTX Format umgewandelt. Der Einstieg in dieses Paket ist die TestplanConverterStart Klasse. Diese Klasse enthält die Methode doexternaltestplanconversion(). Diese Methode wählt anhand der Struktur des übergebenen Testplans die richtige XSLT Strategie mit Hilfe der privaten Funktion checkfortestplantype() aus und wendet diese auf den Testplan an. Wird keine Strategie gefunden, wird ein Testplan error ausgegeben. Um diesen Teil der Implementierung leicht erweiterbar zu halten, wurde das Entwurfsmuster Strategie (engl. Strategy) verwendet [GHJV94]. Dieses Entwurfsmuster aus dem Bereich der Softwareentwicklung gehört zu der Kategorie der Verhaltensmuster. Das Muster definiert eine Familie austauschbarer Algorithmen mit einheitlicher Schnittstelle. Mit Hilfe von diesem Entwurfsmuster ist es möglich, auf einfache Art und Weise weitere Strategien zur Konvertierung der proprietären Formate hinzuzufügen. Wurde die richtige Strategie gefunden, wird die Konvertierung des Testplans angestoßen. Die Konvertierung in Java via XSLT wird mit dem Java API for XML Processing (JAXP) [Gri02] Framework realisiert. Dieses Framework ist in der Lage, anhand einer vordefinierten XSLT Transformationsdatei, eine Transformation auf einer XML-Datei, bei uns der zu testende Testplan, durchzuführen. Für die Konvertierung des Testplans von SIDIS Pro in das standardisierte OTX For- 72

83 7.2. Das Framework 73 mat wird das XSLT Schema SIDISPro2OTX.xslt, welches über die Konfigurationsdatei eingelesen wird, verwendet. Abbildung 7.7: Implementierung: ExternalTestplanConverter -Paket Sobald der Testplan in OTX vorliegt, wird diese XML-Datei mittels JAXB auf die aus dem Abschnitt bekannte OTX-Objektstruktur abgebildet. Diese OTX-Objektstruktur ist im Paket otx zu finden und wird nicht explizit erwähnt, da sie auf der Basis des OTX Schemas mittels dem ab Java-6-JDK 2 mitgelieferten Programm xjc aus der OTX Schema-XSD-Datei generiert wurde und aus 200 Klassen besteht. Nachdem die Objektstruktur erzeugt wurde, wird diese anhand des OTX-Schemas validiert. Um eine korrekte und eindeutige Ausgabe bei einer fehlerhaften Konvertierung des proprietären Testplans in das OTX Format zu erhalten, wurde ein ValidationEventHandler namens MyValidationEventHandler angelegt. Dieser erzeugt aussagekräftige Fehlermeldungen bei einer inkorrekten Konvertierung. Dieser Handler muss explizit im JAXB Framework beim unmarshalling angegeben werden. Ist dies nicht der Fall, werden keinerlei Fehlermeldungen ausgegeben und der neu konvertierte Testplan wird auch mit Fehlern als korrekt angenommen. Der konvertierte Testplan wird im DataManager zur Verfügung gestellt ModelChecking -Paket Das ModelChecking -Paket ist die Hauptkomomponente der Verifikation. Dieses Paket enthält sowohl die Klassen zum Extrahieren der Informationen aus dem Testplan als auch die verschiedenen Checker, Klassen zum Überprüfen der Anforderungen, und Handler, Klassen zum Extrahieren von Informationen, aus der relationalen Datenbank. In diesem Abschnitt werden wir zuerst auf die Handler und die Informationen, welche sie extrahieren, danach auf das parallele Durchlaufen des Testplans sowie die ersten Checks eingehen. Anschließend werden auf der Basis der aus dem Testplan extrahierten Abfolgen sowie deren Beziehungen weitere Tests beschrieben. Wie in der Abbildung 7.8 zu sehen ist, sind im unteren Drittel dieser Abbildung die verschiedenen Handler als Klassen dargestellt. Die Handler werden, siehe Tabelle 7.3, zum Extrahieren der Informationen aus der Datenbank benötigt: 2 Java Development Kit 73

84 74 7. Implementierung Name Beschreibung SequenceInformationHandler Extrahiert Informationen aus dem Bereich des Abfolgen-Modells. TestAmbientInformationHandler Extrahiert Informationen aus dem Bereich des Test- Umgebungs-Modell. ComponentInformationHandler Extrahiert Informationen aus dem Bereich der Fahrzeug-Komponenten. VehicleOptionsHandler Extrahiert Informationen aus dem Bereich der Fahrzeug-Optionen. Tabelle 7.3: Implementierung: Handler zur Informationsextraktion Abbildung 7.8: Implementierung: ModelChecking -Paket 74

85 7.2. Das Framework 75 Die Hauptmethoden der angesprochenen Handler wurden so konzipiert, dass keine Einzelabfragen an die Datenbank gestellt werden, sondern eine Liste mit relevanten Informationen eingeholt und diese intern als Liste oder HashMap gespeichert werden. Durch diese Maßnahme genügt es, in den meisten Fällen, eine einzige SQL-Abfrage, wodurch die Performanz gesteigert wird, zu stellen. Zudem werden die erzeugten Listen und HashMaps in dem im Abschnitt vorgestellten DataManager gespeichert, wodurch ein zentraler Zugriff auf diese Daten ermöglicht wird. In der Grafik 7.9 ist ein Teil eines Testplans mit dessen Abfolgen, schwarze Kästchen, sowie parallelen und sequentiellen Regionen zu erkennen. Der Testplan wird in der Methode domodelchecking() in der Klasse ModelCheckingStart gestartet. Da der Testplan parallel durchlaufen wird und dieses Problem dem bekannten Fork/Join Muster entspricht, wird das neu eingeführte Fork/Join-Framework aus Java 7 verwendet. Das Fork/Join-Framework aus dem java.util.concurrent Paket löst dieses Probleme effektiv. Wie der Name schon andeutet, handelt es sich bei Fork um das Aufteilen einer großen Aufgabe in viele kleine. Dies kann man sich anhand einer Gabel (engl. Fork) und deren Zacken vorstellen. Der Join dient zur Synchronisation der Ergebnisse und führt die verschiedenen kleineren Aufgaben zusammen. Die Fork/Join-Bibliothek stellt die Klasse ForkJoinPool als Koordinator zur Verfügung und enthält zur Task-Beschreibung den Typ ForkJoinTask. Von der abstrakten Basisklasse ForkJoinTask gibt es bisher zwei Unterklassen: RecursiveAction (Tasks ohne Ergebnisse) und RecursiveTask (Tasks mit Ergebnissen). Da Daten aus dem Testplan extrahiert werden sollen, wird die Unterklasse RecursiveTask verwendet. Mit dieser ist es möglich, Ergebnisse beim Zusammenführen der Kindelemente mit dem Vaterelement zu übergeben und diese weiter in die Berechnung einfließen zu lassen. Die Implementierung des RecursiveTaks ist in der Klasse OtxInformationExtractor realisiert. In dieser wird die compute() Methode überschrieben. Als Übergabeparamter enthält die Klasse OtxInformationExtractor eine Liste von Abfolgen und parallelen Regionen. Wie bereits erwähnt, ist in der Abbildung 7.9 ein Teil eines Testplans dargestellt. An der Position (1) wird der erste Fork, das Erzeugen neuer Tasks, vorgenommen. Dazu werden in diesem Fall zwei neue Tasks erstellt, welche als Initialparameter eine Liste von Abfolgen und parallelen Regionen übergeben bekommen. Die erzeugten Tasks werden dem ForkJoin Pool übergeben. Der ForkJoin Pool hält eine Menge von Threads, welche die übergebenen Tasks bearbeiten. Wie man in der Abbildung erkennen kann, enthält der rechte Tasks keine weiteren parallelen Regionen. Deshalb wird innerhalb dieses Tasks kein neuer Task erzeugt. Der Thread setzt jede neue Abfolge mit den bereits gespeicherten Abfolgen innerhalb seines Threads in Bezug und wartet danach auf die Synchronisation an der Position (6). Der linke Thread verarbeitet zunächst die ersten drei Abfolgen und erzeugt darauf an der Position (2) zwei weitere Tasks. Da das Aufteilen der Tasks bei jeder parallelen Region analog verläuft und diese bereits besprochen wurde, untersuchen wir als nächsten Schritt die Synchronisationen, beginnend an der Position (4). Bei einer Synchronisation werden die Teilergebnisse der endenden Threads gesammelt, sodass die Abfolgen der verschiedenen Tasks zum einen parallel zu sich und zum anderen sequentiell mit den vorherigen Abfolgen des gleichen Stranges in Beziehung gesetzt werden können. Aus diesem Grund übergeben die sechs endenden Threads deren Hauptthread ihre Ergebnisse. Dieser setzt die übergebenen Abfolgen zum einen in Beziehung zu einander (parallele Abhängigkeiten) und zum anderen in Beziehung zu dessen eigenen Abfolgen (sequentielle Abhängigkeiten). Dieses Vorgehen wird analog an den Positionen (5) und (6) vorgenommen. Wird eine Abfolge erreicht, wird diese verarbeitet. Im ersten Schritt wird der Abfolgename extrahiert und geparsed, sodass ein Objekt der Klasse Sequence (Abfolge) zur Laufzeit erstellt werden kann. Dieses Objekt enthält alle relevanten Informationen, die Komponenten, den Bezeichner und weitere Informationen über eine Abfolge. Dieses Abfolgen-Objekt wird zum einen in eine interne Liste des auszuführenden Threads gespeichert, als auch in Bezug zu vorherigen Abfolgen gesetzt, sodass die Beziehung eine Abfolge A muss vor einer Abfolge B ausgeführt werden bereits vorhanden ist. Da eine Abfolge zur Ausführung bestimmte Vorbedingungen erwartet und Zustände setzen kann, siehe Anforderung 3.4, werden diese Anforderungen an dieser Stelle überprüft und die Zustände gesetzt. Dazu werden am Anfang der Verifikation zu den bekannten Abfolgen in der Datenbank alle wichtigen Informationen, über den SequenceInformationHandler, extrahiert, verglichen und gesetzt. Um die aktuellen Werte der Zustände zu überblicken, wird eine globale, 75

86 76 7. Implementierung (1) (2) (3) (5) (4) (6) Abfolge Abbildung 7.9: Testplanausschnitt mit Abfolgen synchronisierte HashMap mit den Zuständen sowie deren Werte angelegt. Aufgrund des parallelen Durchlaufes des Testplans muss diese HashMap strikt synchronisiert werden, da es sonst zu Wettlaufsituationen 3 kommen kann. Da bei jeder Synchronisation geprüft werden muss, ob die Anzahl der offenen Verbindungen die obere Grenze nicht überschreitet, wird bei jeder Abfolge deren Komponente inspiziert und beim ersten Kontakt des Programmes mit einer neuen Komponente deren Verbindung geöffnet und bei einem Verbindungsabbau wieder geschlossen. Wird eine Verbindungsabbau auf einen Master ausgeführt, so werden auch die Verbindungen zu dessen Slaves geschlossen. Eine Liste mit den Master und deren Slaves wird in DataManager gehalten und über den ComponentInformation- Handler zu Beginn der Überprüfung eingeholt. Wird anstatt einer Abfolge eine parallele Region erreicht, so wird für jeden Strang der parallelen Region ein neuer Thread, OtxInformationExtractor, gestartet und auf deren Ergebnisse gewartet. Sobald die Ergebnisse vorhanden sind, werden die Komponenten und Abfolgen auf die schon vorhandenen sowie die erhaltenen Ergebnisse zu sich selbst in Beziehung gesetzt. Zum einen bedeutet dies, dass die bereits gespeicherten Abfolgen dieses Threads vor den Abfolgen aus den Ergebnissen im Testplan vorkommen und zum anderen, dass die Abfolgen aus den Ergebnissen jeweils parallel zueinander sind. Am Ende der Synchronisation werden alle erhaltenen Ergeb- 3 Eine Wettlaufsituation ist genau dann vorhanden, wenn mindestens zwei Threads auf eine Ressource zugreifen und einer davon auf diese schreibt. 76

87 7.2. Das Framework 77 nisse zu den bereits existierenden Ergebnissen des aktuellen Threads hinzugefügt, sodass diese wiederum an den Vater zurückgegeben werden können. Auf diese Weise wird der Baum in kleine Teilprobleme unterteilt und gelöst und das wachsende Gesamtergebnis bis zur Wurzel weitergegeben. Wurden nun alle Informationen über die Komponenten und Abfolgen und deren Beziehung zueinander extrahiert, können die Überprüfungen des Testplans gestartet werden. Da die Ergebnisse bis zur ModelCheckingStart Klasse, dem Start des parallelen Durchlaufens, durchgereicht wurden, werden die Überprüfungen in dieser Klasse gestartet. Um die Überprüfung übersichtlicher zu gestalten, wurde für die einzelnen Typen, Komponenten, Abfolgen und Verbindungstests einzelne Klasse angelegt. Diese sind in der Abbildung 7.8 mit den Klassennamen: SequenceDependencyCheck Überprüft die verschiedenen Anforderungen der Abfolgen ComponentDependenciesCheck Überprüft die Anforderungen der Komponenten ConnectionsCheck Überprüft auf parallele Verbindungen als auch, ob alle Verbindungen am Ende des Testplans geschlossen wurden Die Überprüfungen der verschiedenen Klassen sind ähnlich zueinander aufgebaut. Aus diesem Grund werden die Überprüfungen am Beispiel der Anforderungen sequentiell davor und nicht parallel erläutert. Aus dem parallelen Durchlauf des Testplans werden für diese Überprüfungen ähnliche Objektstrukturen aufgebaut. Die Grundstruktur sind zwei verschachtelte HashMaps sowie eine Liste mit Paaren von Abfolgen. Sequentieller Fall Die erste HashMap beinhaltet als Schlüssel die Abfolge, welche in einer Beziehung zu anderen Abfolgen steht und vor diesen im Testplan ausgeführt wird. Als Wert der ersten HashMap wird eine weitere HashMap angelegt. Diese beinhaltet die in Beziehung stehenden Abfolgen als Schlüssel und als Wert eine Liste mit Paaren der genannten Abfolge aus der ersten und zweiten HashMap. Über die jeweiligen Schlüssel ist eine direkte Überprüfung der Abhängigkeiten in O(1) möglich. Da die sequentielle Beziehung zweier Abfolgen redundant, aufgrund von Verzweigungen, in einem Testplan vorkommen kann, werden, in der angesprochenen Liste, alle Paare von Abfolgen der Beziehung aus dem Schlüssel der ersten und der zweiten HashMap gespeichert. Paralleler Fall Analog zum sequentiellen Fall wird im parallelen Fall die gleiche Struktur angelegt. Es wird jedoch die Optimierung vorgenommen, dass bei redundanten Beziehungen zwischen Abfolgen lediglich eine Richtung gespeichert wird. Das heißt, falls die Beziehung Abfolge A ist parallel zu Abfolge B und die Beziehung Abfolge B ist parallel zu Abfolge A in einem Testplan vorhanden ist, zwar beide in der Liste der Paare eingetragen werden, jedoch nur ein Eintrag in der ersten HashMap für diese Beziehung vorhanden ist. Somit muss bei der Verifikation der Anforderung nur eine Überprüfung für beide Richtungen stattfinden. Anhand der besprochenen Objektstrukturen der Abfolgen kann eine Überprüfung vorgenommen werden. Im sequentiellen Fall ist in der Datenbank eine muss bevor Beziehung gespeichert. Dies bedeutet, dass diese Abfolgen nicht in invertierter Reihenfolge vorkommen dürfen. Aus diesem Grund wird die in der Datenbank gespeicherte Beziehung invertiert und mittels der Objektstruktur überprüft, ob diese Struktur im Testplan vorhanden ist. Würde diese Struktur vorhanden sein, so müsste ein Fehler mit den Abfolgen aus der Liste der Abfolgenpaare ausgegeben werden. Bei der parallelen Überprüfung ist dies einfacher. Da aus der Datenbank bekannt ist, dass die gespeicherten Beziehungen nicht vorhanden sein dürfen, muss lediglich, ohne Invertierung, geprüft werden, ob diese Beziehung im Testplan existiert. Falls dies der Fall ist, muss eine Fehlermeldung ausgegeben werden. In beiden Fällen kann es zu falschen positiven Fehlermeldungen ( false positive alerts ), aufgrund von IF-Else Blöcken kommen. Um diese Fehlermeldungen vor der Ausgabe zu filtern, muss anhand der Bedingung des If bzw. Else Blockes überprüft werden, ob sich diese Bedingungen unterscheiden und somit ein false positive vorliegt oder die Bedingungen identisch sind und ein korrekter Fehler im Testplan gefunden wurde. 77

88 78 7. Implementierung Die Überprüfung der weiteren Anforderungen aus dem Kapitel 3.7, werden analog behandelt. Die Objektstruktur wird lediglich mit verändertem Inhalt (Bezeichner, Komponenten, u.ä.) zur optimalen Überprüfung der spezifischen Anforderungen, gefüllt. Überprüfung des Logischen-Ausdruck-Satz Die Überprüfung der Logischen-Ausdruck-Satz (LAS), welcher die Anforderung 3.5 abdeckt und im Abschnitt Überprüfung mittels SAT Solver angesprochen wurde, wird über den bekannten SAT-Solver Algorithmus DPLL [DLL62] überprüft. Dazu werden beim parallelen Durchlauf des Testplans die Referenzen der LAS extrahiert und in einer HashMap gespeichert. Falls Referenzen mehrfach im Testplan vorkommen, werden diese Referenzen lediglich einmal gespeichert, da eine mehrfache Überprüfung der gleichen Referenz nicht nötig ist. Nachdem die Referenzen extrahiert wurden, werden diese der Methode checklas(...), einem Objekt der Klasse LASCheck, übergeben. In dieser Methode werden über den VehicleOptionsHandler die einzelnen Fahrzeug- Optionen der Fahrzeug-Familien, welche im LAS indirekt über die Fahrzeug-Optionen vorhanden sind, aus der Datenbank geholt. Die einzelnen Fahrzeug-Optionen werden, wie im Abschnitt gezeigt, miteinander in Beziehung gesetzt. Sobald alle Fahrzeug-Optionen der einzelnen Fahrzeug-Familien in Beziehung gesetzt wurden, wird der zu überprüfende LAS mit der booleschen Verknüpfung an die Bedingungen hinzugefügt. Würde der LAS kein Modell haben oder würden die Bedingungen der Fahrzeug-Familien, dass maximal eine Variable einer Fahrzeug- Familie wahr sein darf, verletzt sein, würde eine aussagekräftige Fehlermeldung angezeigt werden. Für die korrekte Verifikation der LAS wird eine eindeutige und vollständige Klammerung der booleschen Formeln, LAS, zwingend notwendig und wird vorausgesetzt. Bei Termen mit mehr als zwei Variablen muss eine eindeutige Reihenfolge der Klammerung vorhanden sein. Zum Beispiel bei dem Term, mit der aussagenlogischen Formel, A und B und C muss der Term nach der korrekten Klammerung als ((A und B) und C) angegeben werden. Dies ist analog bei Variablen, welche mit oder oder einer Kombination von und und oder, in Beziehung gesetzt werden. 78

89 8. Evaluierung In diesem Kapitel wird die Evaluierung der Implementierung vorgenommen. Die Evaluierung ist in zwei Schritte unterteilt. Zuerst werden die Anforderungen, Regeln und Fakten in der Datenbank abgelegt. Nachdem die Datenbank vollständig aufgebaut worden ist, kann auf der Basis dieser Daten die Verifikation der Testpläne vorgenommen werden. Falls bei der Verifikation Fehler aufgrund von nicht vorhandenen Informationen in der Datenbank aufgetreten sind, können diese durch Ergänzungen/Veränderungen, zum Beispiel durch Hinzufügen bis dato nicht bekannter Abhängigkeiten zwischen Abfolgen, durch erneute Wissenserhebung in die Datenbank aufgenommen werden. Da bei der Evaluierung der vollständige Anwendungszyklus der Software vom Erstellen der Austauschformate über die erste Datenintegration bis hin zur Verifikation und der erneuten Anpassung der Datenbank betrachtet wird, kann diese Evaluierung als vollständig angesehen werden. Abbildung 8.1: Lebenszyklus der Software Für die Evaluierung wurden alle Anforderungen, welche vor der ersten Befüllung der Datenbank erhoben wurden, angewandt. Dies bedeutet, dass alle Anforderungen bis auf die aus der Tabelle 8.1 der neuen Abhängigkeiten evaluiert wurden. 79