Schriftenreihe. Toolgestützte Verifikation verteilter technischer Steuerungssysteme auf der Basis von Aktivitätsdiagrammen. von.

Transkript

1 Schriftenreihe Toolgestützte Verifikation verteilter technischer Steuerungssysteme auf der Basis von Aktivitätsdiagrammen von Dirk Zander RUHR - UNIVERSITÄT BOCHUM Fakultät Maschinenbau S Institut Product and Service Engineering Lehrstuhl für Regelungstechnik und Systemtheorie

2 Toolgestützte Verifikation verteilter technischer Steuerungssysteme auf der Basis von Aktivitätsdiagrammen Dissertation zur Erlangung des Grades Doktor-Ingenieur der Fakultät für Maschinenbau der Ruhr-Universität Bochum von Dirk Zander aus Herten Bochum 2009

3 Dissertation eingereicht am: Tag der mündlichen Prüfung: Vorsitzender: Erster Referent: Prof. Dr.-Ing. E. Weidner Prof. Dr.-Ing. G. Reinig Zweite Referentin: P.D. Dr.-Ing. A. Braune Dritter Referent: P.D. Dr.-Ing. C. Esen Herausgeber: Lehrstuhl für Regelungstechnik und Systemtheorie Ruhr Universität Bochum

4 Vorwort Die vorliegende Arbeit entstand in den Jahren 2005 bis 2009 während meiner Tätigkeit als wissenschaftlicher Mitarbeiter am Lehrstuhl für Regelungssysteme und Steuerungstechnik der Ruhr-Universität-Bochum und wurde von der Fakultät für Maschinenbau als Dissertation angenommen. Mein besonderer Dank gilt Prof. Dr.-Ing. G.Reinig, der mit seinen wertvollen Anregungen zum gelingen dieser Arbeit beigetragen hat. Für die Übernahme des Korreferats danke ich Frau Dr.-Ing. A. Braune vom Institut Automatisierungstechnik der TU Dresden, sowie Herrn Dr.-Ing. C. Esen. Bei meinen Kollegen und Mitarbeitern, insbesondere Herrn Dr.-Ing. Murat Ünlü, Herrn Dipl.-Ing. Tim Lübbert und Herrn Dipl.-Ing. Florian Behrens, bedanke ich mich für die vielen wertvollen Diskussionen und die gute Zusammenarbeit. Mein Dank gilt auch den studentischen Mitarbeitern und Diplomanden, die an der Arbeit mitgewirkt haben. Nicht zuletzt möchte ich mich bei jenen Mitarbeitern von Airbus Deutschland GmbH bedanken, die durch ihre Kooperationsbereitschaft zur industriellen Erprobung der entwickelten Methoden verholfen haben. Dirk Zander

5

6 Kurzfassung zur Dissertation Kurzfassung Dissertation: Toolgestützte Verifikation verteilter technischer Steuerungssysteme auf der Basis von Aktivitätsdiagrammen Mit dem Wunsch nach mehr Komfort und Funktion und seitens der Hersteller nach einer wirtschaftlich tragenden Realisierung heutiger technischer Systeme, wird dem Elektronikanteil vieler Produkte eine stetig steigende Bedeutung beigemessen. So ist in den letzten Jahren eine klare Tendenz zugunsten hybrider (Hardware und Software) Lösungen zu verzeichnen. Dazu werden z.b. Eingebettete Systeme, das sind im technischen Umfeld integrierte Einbaurechner, mit teilweise komplexen Steuerungs-, Regelungs- und Kommunikationsfunktionen eingesetzt. Es werden zunehmend dezentrale Steuerungen in Form von untereinander kommunizierenden eingebetteten Systemen verbaut, die im Verbund Systemfunktionen realisieren. Mit der steigenden Komplexität moderner eingebetteter Systeme wachsen aber auch die Anforderungen an die Entwicklungsmethoden für diese Systeme. Das umfasst sowohl den Entwurf (Design), als auch die Validations- und Verifikationsphase. Gerade im Bereich sicherheitskritischer Systeme, z.b. im Passagierflugzeugbau besteht im Sinne einer Zertifizierung die Notwendigkeit die Zuverlässigkeit nachzuweisen. Derzeitige Methoden zum Nachweis beschränken sich oft nur auf eine reine Software- oder Hardwareverifikation. Des Weiteren ist z. Z. eine im Produktentwicklungsprozess durchgängige formale Beschreibung der Systeme selten. So liegen Systemspezifikationen in textueller Form, bzw. als Anforderungsbeschreibungen vor. Für eine effiziente Produktverifikation solcher Systeme muss eine computerverwertbare und damit automatisierbare Beschreibung existieren, auf die dann entsprechende Testalgorithmen angewandt werden können. Bisherige generative Black-Box-Methoden zur Testfallspezifikation basieren oft auf einer reinen Kombinatorik der Eingangs (und Ausgangsgrößen) und bilden somit schon bei Systemen mittlerer Größe einen zu großen Stimuliraum für vollständige Tests ab (kombinatorische Explosion). Die hybride Nutzung der spezifikationsbasierten Vorgehensweise (Black-Box) mit renommierten White-Box-Methoden, speziell unter der Verwendung einer Verhaltensmodellierung für den zu implementierten Steuerungscode ist neu. Der Schwerpunkt dieser Arbeit liegt bei der Entwicklung dieser hybriden Vorgehensweise mit dem Ziel eine Verbesserung zur systematischen und automatisierten Ü- berprüfung der Korrektheit und Zuverlässigkeit von Steuerungen komplexer hybrider technischer Systeme im Sinne einer gegebenen Anforderungsspezifikation zu leisten.

7 Kurzfassung zur Dissertation Im Rahmen dieser Arbeit wird eine automatisierte Black-Box-Testmethode für die Qualitätssicherungsphase der Produktverifikation hergeleitet, die das Zeitverhalten, aber auch logische Verknüpfungen im Steuerungscode berücksichtigt. Dazu werden Prinzipien bereits existierender und damit renommierter implementationsorientierter (White-Box) Methoden zur Verifikation verteilter eingebetteter Systeme angepasst und ebenfalls implementiert. Zu deren Umsetzung wurde im Rahmen dieser Arbeit eine Modellierungssprache entwickelt, die es ermöglicht, textuelle Spezifikationen als semi-formale Verhaltensmodelle zu erstellen. Mit der Hilfe der eigens entwickelten Algorithmen zur Definition der Testfallspezifikation werden ein höherer Automatisierungsgrad und damit eine Effizienzsteigerung in der Verifikationsphase der Modul- und Integrationstests erreicht. Die entwickelten Methoden und Tools wurden unter realen, industrienahen Bedingungen im Bereich der Kabinenautomation im Passagierflugzeugbau erfolgreich erprobt.

8 Inhalt Inhalt 1 EINLEITUNG ZIEL MOTIVATION ÜBERSICHT ÜBER DIE VORLIEGENDE ARBEIT STAND UND EINORDNUNG DES ARBEITSGEBIETES Trend in der Softwareentwicklung für eingebettete Systeme Entwicklung eingebetteter Systeme Werkzeuge für die Entwicklung eingebetteter Systeme Werkzeuge zur Validation und Verifikation eingebetteter Systeme SYSTEMDESIGN UND VALIDIERUNG KOMPLEXER EINGEBETTETER STEUERUNGSSYSTEME BEGRIFFE UND TAXONOMIE PRODUKT- / SYSTEMENTWICKLUNG EINGEBETTETER SYSTEME EINTEILUNG DER TESTMETHODEN Statische und manuelle Testmethoden Teststrategien und Testansätze zu dynamischen Stichproben-Tests Implementationsorientierte Methoden (White Box Methoden) Spezifikationsorientierte Methoden (Black-Box-Methoden) Klassifikation datenbereichsbezogener Methoden Klassifikation funktionsorientierter Verfahren Datenbereichsbezogene Generierung vollständiger Testvektoren PRODUKT-VERIFIKATION VERTEILTER STEUERUNGSSYSTEME AUSWAHL GEEIGNETER TESTVERFAHREN PFADORIENTIERTE STIMULIGENERIERUNG Theoretische Grundlagen zur entwickelten Methode Graphentheorie Timed Petri Nets Modellierung von Testmodellen: Systemmodelle Verhaltensmodelle Strukturmodelle Toolbasierte Methode zur Produktverifikation von verteilten Steuerungssystemen Schritt 1 Datenbasis erfassen Schritt 2 Klassifizierung der Elemente Schritt 3 Modellierung Schritt 4 Kontrollflussorientierte Äquivalenzklassenbildung Schritt 5 Automatische Testdurchführung Schritt 6 Automatische Testauswertung Schritt 7 Generierung von Test Reports Teststrategien Modultests Integrationstests Systemtests Einordnung der pfadorientierten Stimuligenerierung INDUSTRIELLES ANWENDUNGSBEISPIEL GEGENSTAND DER UNTERSUCHUNG AUFBAU UND FUNKTION DES SYSTEMS VERSUCHSAUFBAU SOFTWAREUNTERSTÜTZUNG (TOOLCHAIN) TESTSTRATEGIE UND AUSWERTUNG ZUSAMMENFASSUNG UND AUSBLICK... 85

9 Inhalt 6 VERZEICHNISSE LITERATURVERZEICHNIS INTERNET REFERENZEN ANHANG ABKÜRZUNGEN WEITERE ABBILDUNGEN UND AUSZÜGE

10 Inhalt Abbildungen Abbildung 1: Evolution von Software, Datenbussen und Computerleistung der Airbus Flotte 1 Abbildung 2: Abstraktes Vorgehensmodell Produktentwicklungsstrategie... 2 Abbildung 4: Soll-Schichtenmodell mit gekennzeichneten unerwünschten Abhängigkeiten... 7 Abbildung 5: Toolbasierte Methode zur Verifikation von verteilten Steuerungen...11 Abbildung 6: Vorgehensmodell...19 Abbildung 7: Produktentwicklung nach dem V-Modell...20 Abbildung 8: Requirement Management im V&V-Prozess...21 Abbildung 9: Verifikation von Produkteigenschaften am Beispiel aus der Luftfahrt...22 Abbildung 10: Testmethodenbaum statische und dynamische Methoden...23 Abbildung 11: Spezifikationsorientierte Testmethoden...26 Abbildung 12: Methode zur datenbereichsbezogenen vollständigen Testfallspezifikation mit den Schlüsselwörtern der umgesetzten Skriptsprache...31 Abbildung 13: Einteilung von Systemmodellen...38 Abbildung 14: Schematische Darstellung der toolbasierten Verifikationsmethode...40 Abbildung 15: Spezifikationsverfahren...42 Abbildung 16: Informationsquellen zur Modellbildung...44 Abbildung 17: Sprachelemente: State und Action und deren Eigenschaften...47 Abbildung 18: Auflistung der Verknüpfungselemente...48 Abbildung 19: Beispiel eines Decision Nodes...49 Abbildung 20: Beispiel eines Merge Nodes...49 Abbildung 21: Beispiel eines Fork Nodes...50 Abbildung 22: Beispiel eines Join Nodes...50 Abbildung 23: Beispiel einer Zeittafel...55 Abbildung 24: Pfadregeln Identifikation der relevanten Pfadelemente...60 Abbildung 25: Pfadregeln Generierung der Kontrollflusspfade...60 Abbildung 26: Pfadregeln Verarbeitung der Zeitinformationen in Kantenrichtung...61 Abbildung 27: Summationseffekt von Fehlern...67 Abbildung 28: Stimuli-Aufschaltpunkte für unabhängige Größen...68 Abbildung 29: Stimuli-Aufschaltpunkte für kombinierte...69 Abbildung 30: Auswahlverfahren von Testmethoden...71 Abbildung 31: Auswahl einiger Integrationsstrategien...73 Abbildung 32: Vereinfachte, schematische Darstellung des Abwassersystems...77 Abbildung 33: Zeitverhalten eines Spülzyklus...79 Abbildung 34: Aufbau des Testequipments...81 Abbildung 35: Vorgehensweise und Softwareschnittstellen der Industrieanwendung...82 Abbildung 36: EventDesigner - Strukturmodell des Industriebeispiels Abbildung 37: EventDesigner - Eingabe charakteristischer Zeitintervalle an den Abbildung 38: EventDesigner - Definition allgemeiner Parameter zur Abbildung 39: EventDesigner - Auswahlfenster zur Generierung der Abbildung 40: EventDesigner - Analysefenster zur Modellstruktur Abbildung 41: EventDesigner - Parametrisierung der Testfallmuster Abbildung 42: EventDesigner - Beispielausschnitt einer Teststimulidatei (Testtreiber) Tabellen Tabelle 1: Kriterien unterschiedlicher Graphen-Algorithmen...36 Tabelle 2: Klassifizierung der Test-Methoden in der Softwaretechnik...74

11

12 Einleitung 1 Einleitung Eine gesteigerte Nachfrage nach höherem Komfort, einer besseren Verfügbarkeit und allgemein nach mehr Funktionalität ist in der heutigen Zeit charakteristisch für viele technische Produkte. Immer stärker entscheidet der Elektronikanteil des Gesamtsystems, also das hier im Vordergrund stehende eingebettete System (embedded system), über die erreichte Innovation und die gesamte Wertschöpfung neuer Produkte. Im besonderen Maße gilt dies für den Automotive / Fahrzeugbau oder auch für den Passagierflugzeugbau. Historisch ist bei beiden Branchen eine stetige Verbesserung der Produkteigenschaften zu verzeichnen. Technisch bedeutet dieser Zuwachs, dass die Systeme auch zunehmend komplexer gestaltet werden müssen, um diese Anforderungen zu erfüllen. Es werden öfter dezentrale Steuerungen in Form von untereinander kommunizierenden eingebetteten Systemen verbaut, die im Verbund Systemfunktionen realisieren. Um trotz der gestiegenen Komplexität die Zuverlässigkeit 1 der Systeme zu gewährleisten und den Produktionsaufwand, bzw. die Herstellungskosten gering zu halten, sind angemessene Methoden für den Systementwurf (Design) als auch für die Qualitätssicherung gefragt. Als Beispiel 2 der zunehmenden Komplexität sei hier der neu entwickelte Airbus A380 genannt. Abbildung 1 zeigt die Entwicklung der Rechnerleistung, Speicher und Netzwerkbandbreite über zwei Dekaden von fünf Flugzeugen. Die Leistung von Rechnern, Bussen und daraus resultierend auch der Software wächst exponentiell an. Abbildung 1: Evolution von Software, Datenbussen und Computerleistung der Airbus Flotte 1 Die Fähigkeit eines Systems oder einer Komponente unter Berücksichtigung inhärenter Fehler die erwarteten Funktionen unter spezifizierten Bedingungen über eine bestimmte Zeit durchzuführen 2 Vgl. dazu Froment, P. A380 Avionics Architecture,

13 Einleitung Heutige Methoden zum Entwurf, bzw. Design komplexer Steuerungssysteme werden bereits in großem Maße diesen Anspruch gerecht. So werden z.b. iterative Vorgehensmodelle (Wasserfallmodelle) für die Produktentwicklung vom V-Modell 3, wo die Qualitätssicherung eine integrative Komponente ist, zunehmend abgelöst. Mit dem Prinzip, ein komplexes System in mehrere weniger komplexe zu teilen (Zerlegung anhand der Produktstruktur), die Sub-Systeme getrennt voneinander zu entwerfen und anschließend wieder mit einer gewissen Schnittstellenaktivität zu vereinen, können theoretisch beliebig komplexe Systeme entworfen werden. Eine moderne Vorgehensweise für den Entwurf ist das Requirement Based Engeneering (RBE). Es werden Anforderungsspezifikationen für verschieden abstrakte Systemebenen über klar definierte Requirements beschrieben und über die Ebenen hinweg verknüpft. So kann eine relativ allgemeine Anforderung im Produktentwicklungsprozess sukzessive konkretisiert werden, bis die Komplexität ausreichend gering für die Realisierung ist. Die Verknüpfung der Requirements gewährleistet eine Traceability (Zugehörigkeit) untereinander. Abbildung 2: Abstraktes Vorgehensmodell Produktentwicklungsstrategie Entsprechend der Anforderungen an die Entwurfsmethoden steigen auch die Anforderungen an das Qualitätsmanagement und damit an die Verifikations- und Validierungsmethoden, die wie in Abbildung 2 dargestellt, stark mit dem Produktentwicklungsprozess verwoben sein können. Als wesentliche Phasen können die Requirement Validation, die Design Verification, die Produkt Verification und die Product Validation genannt werden. 3 V-Modell: Vorgehensmodell in der Produktentwicklung, vgl.[37] 2

14 Einleitung 1.1 Ziel Ein wesentliches Ziel dieser Arbeit ist, einen methodischen Beitrag zur systematischen und automatisierten Überprüfung der Korrektheit und Zuverlässigkeit von Steuerungen komplexer hybrider technischer Systeme im Sinne einer gegebenen Anforderungsspezifikation zu leisten. Insbesondere die Klasse der durchzuführenden funktionalen Tests in der Validations.- und Verifikationsphase während einer Produktentwicklung werden hier betrachtet. Einer Automatisierung von Modul- und Integrationstests, mit dem Schwerpunkt, synergetische fehlerhafte Effekte zwischen der verwendeten Hardware und implementierten Software sowie deren fehlerhafte Auswirkung zu finden, soll zu einer Effizienzsteigerung des Testprozesses beitragen. Eine Untersuchung bestehender spezifikationsorientierter Methoden 4 aus der Testliteratur von reinen Softwaresystemen ergab, dass diese auf die Charakteristika vorliegender Hardware-Software-Systeme angepasst werden müssen. Ein wesentlicher Punkt dabei ist, dass Methoden zum Testen reiner Softwaresysteme i.d.r. nur Kombinatorik und Reihenfolgen von Stimuli berücksichtigen. Um jedoch dem dynamischen Charakter vorliegender Systeme gerecht zu werden, müssen unter anderem die genauen Aufschaltzeitpunkte der Stimuli, bzw. die relativen Zeitabstände unter den Stimuli, berücksichtigt werden. Im Rahmen dieser Arbeit wird eine automatisierte Black-Box-Testmethode für die Qualitätssicherungsphase der Produktverifikation hergeleitet, die das Zeitverhalten der Systeme, aber auch mit einer gewissen Annahme logische Verknüpfungen im Steuerungscode berücksichtigt. Dazu werden Prinzipien bereits existierender und damit renommierter implementationsorientierter 5 (White-Box-) Methoden zur Überprüfung der Korrektheit und Zuverlässigkeit verteilter eingebetteter Systeme angepasst und ebenfalls implementiert. Spezifikationsorientierte Testmethoden können in datenbereichsbezogene und funktionsorientierte Methoden eingeteilt werden. Während erstere ausschließlich die Eingangs.- und Ausgangsgrößen eines Systems zur Herleitung von Testvektoren nutzen, muss für funktionsorientierte Methoden auch die innere Struktur berücksichtigt werden. Die hier entwickelte Methode kann den funktionalen zustandsbasierten Test-Verfahren zugeordnet werden. In der Regel ist eine Spezifikation komplexer Systeme in funktionale Zusammenhänge gegliedert, wobei eine einzelne Funktion das Sollverhalten des Systems für eine einzelne Teilaufgabe des Systems beschreibt. Die Menge aller Funktionen mit ihren Abhängigkeiten zueinander, entspricht dann einem spezifizierten Sollverhalten des Gesamtsystems. Die steigende Komplexität der zu verifizierenden Funktionen, die generell mit der Anzahl der Steuerungseinheiten (embedded systems) im Verbund 4 Beim spezifikationsorientierten Testen werden Testfälle bzw. Testdaten durch Analyse der Spezifikation erzeugt, ohne die innere Struktur des Systems zu berücksichtigen (Black-Box-Tests) 5 Beim implementationsorientierten Testen werden die Testdaten durch eine strukturelle Analyse des Systems gewonnen. (White-Box-Tests) 3

15 Einleitung ansteigt, ist oft ein Kriterium dafür, dass herkömmliche Test-Methoden nicht angewandt werden. Ein Ziel dieser Arbeit ist daher die Herleitung einer Notation, die sowohl komplexe Zusammenhänge, wie z.b. geräteübergreifende Funktionen im Rahmen von Integrationstests behandelt. Auch muss eine intuitive Überführung der Spezifikationen in ein Computermodell vom Tester möglich sein. Ein weiteres Ziel ist eine Implementierung neuer, bzw. kombinierter Methoden zum systematischen Testen. Eine Modellierung von Verhaltensmodellen wird dazu als grundlegendes Prinzip zur praxisnahen Überführung technischer Spezifikationen in ein semi-formales Modell gewählt. Eine reale Produktverifikation unterliegt immer einer zeitlichen (und finanziellen) Beschränkung. Deshalb gibt es Bestrebungen, in möglichst kurzer Testzeit eine große Testüberdeckung zu realisieren. Diese quantitative Anforderung an den Testprozess kann mit einer automatischen Testdurchführung umgesetzt werden. Um in der zur Verfügung stehenden Zeit zusätzlich eine hohe Fehleraufdeckung zu ermöglichen, müssen die einzelnen Testfälle auch eine gewisse Qualität bezüglich dieses Kriteriums aufweisen. Die Methodik zielt auf eine Steigerung der Effizienz des Testprozesses ab. Sowohl eine automatische Durchführung der Tests als auch eine systematische Herleitung der Testfälle tragen dazu bei. Als wesentliche Punkte zur Effizienzsteigerung können genannt werden: Testmodell kann in den frühen Phasen der Systementwicklung erstellt werden, damit ergibt sich ein Zeitvorteil, wenn der Prüfling zum Test vorliegt Automatische Aufschaltung von Testvektoren durch eine durchgehende Toolunterstützung Automatische Auswertung der Systemreaktionen für die Klasse von Tests die zum spezifizierten Verhalten des Prüflings gehören Eine verbesserte Überprüfung der Eigenschaften, die sich aus dem hybriden Charakter ergeben (HW / SW) Es sei darauf hingewiesen, dass nicht-funktionale Qualitätsmerkmale, wie z. B. die Sicherheit, die Benutzbarkeit, die Interoperabilität, die Prüfung der Dokumentation oder die Zuverlässigkeit eines Systems, nicht zum Umfang der Methode gehören. Ebenso ist eine wirtschaftliche Betrachtung der Verifikationsphase nicht im Rahmen dieser Arbeit vorgesehen. 1.2 Motivation Die Entwicklung reaktiver Systeme ist traditionell sehr fehleranfällig, da eine Vielzahl von möglichen Abläufen zu nicht, oder nur schwer reproduzierbaren Fehlersituationen führen können. Schon sehr kleine Modelle bzw. Systeme sind in ihrem Verhalten oft schwer durchschaubar und können subtile Fehler enthalten. Reale Systeme aus 4

16 Einleitung der Praxis, wie aus dem hier genannten Anwendungsfeld des Flugzeugbaus, sind viel größer. Reaktive Systeme kommen allerdings gerade dort häufig zur Anwendung wo Fehler teuer sind, oder eine Gefährdung bedeuten. Deshalb werden Verfahren gebraucht, welche die Korrektheit eines Systems bzgl. gewisser Spezifikationen nachweisen. Generelle Motivation Erfordernis, Produkt-Verifikationsmethoden zu verbessern und damit eine Fortführung der bereits am Lehrstuhl entwickelten Methoden Eine Evaluation von realen Tests aus dem Airbus A380 Programm ergab, dass Fehler oft nicht tief verschachtelt sind und auch oft auf synergetische Effekte zwischen Hardware und Software zurückzuführen sind. Daraus kann eine Klasse von automatisch durchführbaren Black-Box Tests extrahiert werden. Bestehenden Methoden Eine Arbeit, die sich mit der Verifikationsmethodik verteilter Steuerungssysteme beschäftigt, wurde am hiesigen Lehrstuhl erarbeitet [55]. Die dort entwickelte Methode stellt eine datenbereichsbezogene Methode dar, welcher die einzelnen Funktionen des zu testenden Systems unterworfen werden. Um eine solche Verifikation durchführen zu können, müssen neben den Aufschaltwerten der Stimuli auch ihre Aufschaltzeiten ermittelt werden. Da die Anzahl der Tests mit der Anzahl der Aufschaltzeitpunkte exponentiell steigt, liegt ein Schwerpunkt darin, möglichst repräsentative Aufschaltzeitpunkte zu ermitteln. Die vorgestellte Methode kann zu den folgenden Punkten zusammengefasst werden: 1. Extrahieren von zeitlichen Informationen der stimulierbaren Größen aus technischen Dokumenten 2. Diskretisierung der kontinuierlichen Zeit durch Bilden von Äquivalenzklassen 6 auf Basis charakteristischer Zeiten des Systems 3. Ermittlung der Aufschaltzeitpunkte unter Anwendung der erarbeiteten Regeln, Reduzierung des Stimuliraumes Sti.5 Sti.4 Sti.3 Sti.2 Sti.1 IN 1 IN 2 IN 3 IN 4 IN 5 IN... DBB- Methode unabhängig abhängig T1 T2 T3 T4 Steuerung char. Zeit t? Specification OUT 1 OUT 2 OUT 3 OUT 4 OUT 5 OUT... Func1.1...set IN1 TRUE for 1s Func1.1...when pressed for 3s... Abbildung 3: Datenbereichsbezogene Teststimuli Generierung t 6 Unter Äquivalenzklassen werden Bereiche von Eingangsdaten verstanden, für die gilt, dass das Testen mit einem Wert dieses Bereichs repräsentativ für alle ist. 5

17 Einleitung Mit dieser Vorgehensweise wurde auf dem Gebiet der Teststimuligenerierung für zeitbehaftete Systeme Grundlagenarbeit geleistet. Die datenbereichsbezogene Generierung des vollständigen 7 Stimuliraumes, mit einer geeigneten Reduzierung, eignet sich für das umfassende Testen einzelner Modul-Funktionen. Sie bietet durch die computergestützte Generierung der Testfälle einen hohen Automatisierungsgrad und mit der Kompatibilität zu manuell erstellten Testfällen, eine sinnvolle Schnittstelle für das Expertenwissen. Allerdings wird für das Testen von Sequenzen bzw. Kombinationen mehrerer Funktionen, aufgrund der Komplexität der hier betrachteten Systeme, eine nicht zu bewältigende Menge von Testfällen generiert. Daher kann diese Methode alleine nicht uneingeschränkt für das Testen auf der Integrationsebene und Systemebene eingesetzt werden. Die vorliegende Arbeit strebt an, das zu verbessern. Mit den bisherigen Methoden ergeben sich folgende Problemfelder: Problem reiner Black Box Tests: Problematisch beim Black-Box-Testverfahren ist die Testüberdeckung, da Interna eines Steuerungsprogramms nicht berücksichtigt werden. So kann es vorkommen, dass gewisse Programmteile, wie Schleifen oder Ausnahmebehandlungen, bei Black Box Tests nie oder immer mit 'harmlosen' Daten durchlaufen werden. Sinnvolle Testfälle, die sich nicht aus der Verwendung, sondern einzig aus dem Aufbau und der Formulierung des Testobjektes ergeben, werden beim Black-Box-Test nicht systematisch durchgeführt. Als Konsequenz können unentdeckte Fehler im Steuerungscode verbleiben. Der hier vorgestellte Ansatz berücksichtigt unter einer gewissen Annahme die Interna eines Steuerungsprogramms, sodass Testvektoren gezielt generiert werden können. Problem der zunehmenden Komplexität der Systeme / Softwarearchitektur Ein aktueller Trend ist, in zunehmendem Maße Hardware-Komponenten durch Softwareteile zu substituieren und zusätzlich immer mehr Funktionalität zu implementieren. Das ist ausschlaggebend dafür, dass eingebettete Systeme auch zunehmend komplexer werden. Zwingend notwendig für den Entwurf, bzw. für Änderungen oder Erweiterungen ist daher, dass ein Softwareentwurf modular und ohne Abhängigkeiten und Kopplungen innerhalb der gesamten Software gestaltet wird. Es muss eine konstant gute Softwarequalität gewährleistet werden. Der Termindruck und oftmals ein falsches Entwicklungskonzept können die Ursachen dafür sein, dass die Qualität abnimmt und das System ein fehlerhaftes Verhalten zeigt. Da mit steigender Komplexität des Systems die Abhängigkeiten exponentiell zunehmen, verstärkt sich der Effekt schlechter Qualität in der Regel. Maßnahmen dagegen ist ein ganzheitliches Entwicklungskonzept, welches schon auf der Prozessebene mit der Definition von z.b. iterativen Vorgehensmodellen beginnt, 7 Eine Generierung von Testdaten im wörtlichen Sinne von "vollständig" ist schon aufgrund der "kontinuierlichen Zeit" nicht möglich. Hier wird eine Diskretisierung der Zeit angenommen 6

18 Einleitung bis hin zur Nutzung von standardisierten Methoden, sowie praxisbewährter Komponenten wie z.b. die UML 8 oder RTOS 9. Eine gute Softwarearchitektur für eingebettete Systeme hat eine: zeitliche Entkopplung funktionale Entkopplung Daten-Entkopplung Prioritäten-Entkopplung Treiber/Interrupt Service Ebene Im optimalen Fall sollte mit diesen Empfehlungen eine Applikation entstehen, die lediglich das Prozess-Know-How in sich vereint, jedoch plattformunabhängig ist. Eine solche Applikation kann somit nach dem Austausch der Hardware- und Echtzeitbetriebssystem- Ebene wieder verwendet werden ( reuse ). Allerdings ist oft bei real entstandener Software zu beobachten, dass diese Schichten nicht sauber entkoppelt sind. Abbildung 4 verdeutlicht diesen Zusammenhang. Abbildung 4: Soll-Schichtenmodell mit gekennzeichneten unerwünschten Abhängigkeiten Funktionalitäten aus Treibern werden direkt aus der Applikation ausgeführt, Interrupt- Service-Routinen beeinflussen direkt die Applikation und proprietäre Bibliotheken werden direkt angesprochen. Eine saubere Verwendung des Schichtenmodells, ohne die Verwendung von Querbeziehungen, kann den Aufwand und die Kosten für eine solche Portierung auf ein Minimum reduzieren. Damit wird deutlich, dass eine unsaubere Verwendung des Schichtenmodells eine Ursache für ein fehlerhaftes Verhalten sein kann. Unter Umständen zeigt sich ein solches Verhalten erst nach längerer Betriebszeit oder wenn spezielle Ressourcen in Ausnahmesituationen benutzt werden. Häufig reichen zu ihrer Aufdeckung keine normalen Applikationstest 10. Erst mit systematischen und gezielt auf die hier beschriebenen Probleme eingestellten Tests, können diese Fehler gefunden werden. 8 UML = Unified Modeling Language 9 RTOS = Real Time Operating System - Echtzeitbetriebssystem 10 Testen des Normalverhaltens 7

19 Einleitung Beispiel: Eine unsauber programmierte Funktion greift direkt und ohne Nutzung der dafür vorgesehenen RTOS-Routine auf Hardwareressourcen zu. Die Anwendung funktioniert wie gewünscht, doch erst bei einem Stresstest 11 tritt ein fehlerhaftes Verhalten auf, da z.b. die Prioritätenvergabe des RTOS umgangen wurde. 1.3 Übersicht über die vorliegende Arbeit Dem Systementwickler stehen immer mehr Modellierungssprachen, Methoden und Werkzeuge für den Entwurf zur Verfügung und ermöglichen damit umfangreiche Simulationen in der Designphase bis hin zur plattformbezogenen Codegenerierung der Steuerungsalgorithmen für den Einsatz im realen Steuergerät. Allerdings sind Standards wie beispielsweise die UML meist sehr umfangreich und bieten dem Designer viele Möglichkeiten der Spezifikation (siehe dazu Kap ). Umfassende Simulationen des gesamten Steuerungssystems, mit dem Potential daraus Testfallspezifikationen abzuleiten, liegen oftmals nicht vor, da der Aufwand für das Erstellen gewöhnlich zu kosten- und zeitintensiv ist. Das gilt insbesondere für große Systeme und Systeme mit hybridem 12 Charakter, bei denen speziell eine genaue Simulation der kontinuierlichen Anteile problematisch sein kann. In einigen Fällen kann das genaue Systemverhalten erst am realen System beobachtet werden. Im Rahmen dieser Arbeit wird eine neue, auf diese Anwendung angepasste grafische Modellbildung entwickelt. Sie ist angelehnt an der aus der UML2.0 bekannten Notation der Aktivitätsdiagramme, die oft für Re-Engineering Aufgaben genutzt wird. Da die Informationsquelle für die zu erstellenden Testmodelle eine nichtformale Spezifikation ist und nur mit einer gewissen Sicherheit auf die reale Umsetzung zu schließen ist, werden hier sog. Verhaltensmodelle erstellt. Als durchgehende Datenstruktur wurde ein gerichteter Graph mit einer Erweiterung für zeitbehaftete Systeme und einer Sicht auf die Systemstruktur gewählt. Hintergrund für die Entwicklung der Modellierungssoftware (EventDesigner) ist eine Implementierung von Testmethoden und Testalgorithmen, die eine automatisierte und systematische Verifikation auf Modul- und Integrationsebene für das spezifizierte Normal- sowie Abnormalverhalten ermöglichen. Wobei das grundlegende Testprinzip das Black-Box-Testen ist, also eine Testfallspezifikation ohne konkrete Kenntnisse darüber, wie die verwendete Hardware und implementierte Steuerungssoftware des Testobjekts konkret realisiert ist. Reine datenbereichsbezogene Black-Box-Methoden wie die Äquivalenzklassenmethode, die Grenzwertmethode und die Ursache-Wirkungsgrafmethode bilden ohne eine gute Abstrahierung einen zu großen Stimuliraum. Sie lassen sich da- 11 Tests, die an der Leistungsgrenze, hinsichtlich einer maximalen Performance, des System durchgeführt werden 12 Hybride Systeme bestehen aus interagierenden diskreten und kontinuierlichen Komponenten 8

20 Einleitung her nicht uneingeschränkt anwenden und finden sich hier eher als ein Bestandteil der Gesamtmethode wieder. Das Kapitel 2.3 führt in das Thema der Testmethoden ein. Im Gegensatz zum datenbereichsbezogenen Testen, ist für das hier zur Anwendung kommende funktionsorientierte Generieren von Testdaten, das Wissen über systeminterne Informationen, wie z.b. Sequenzen, Schleifen oder Bedingungen, eine Voraussetzung. Um Methoden aus dem funktionsorientiertem Testen nutzen zu können, ist es sinnvoll, eine abstrakte aber ausreichend genaue Rekonstruktion des Steuerungscodes in Form eines Verhaltensmodells vorzunehmen, um basierend auf den so gewonnenen Programmausführungspfaden 13 systematische Tests durchzuführen. Liegen Daten zu den Steuerungsalgorithmen in Form von technischen Dokumenten, Requirements oder in Prosa geschriebene Spezifikationen vor, kann mit einer gewissen Sicherheit ein (Soll-)Verhalten der Steuerung beschrieben werden. Methoden aus dem implementationsorientiertem 14 Testen wie z.b. das Pfadüberdeckungstesten eignen sich prinzipiell für den vorliegenden Fall. Sie basieren auf der Datenstruktur eines Kontrollflussgraphen und eignen sich daher für Methoden aus dem pfadorientierte Testen. Eine Anwendung ist bisher nur im Bereich des reinen Testens von Software und damit zugehörig zu den White-Box-Methoden, bekannt. Jedoch müssen sie auf den hiesigen Anwendungsfall angepasst werden. Ein wichtiges Ziel dabei ist die Verarbeitung der Zeitinformationen und die Behandlung der in der Modellierung verwendeten Verknüpfungsglieder. Diese Arbeit stellt in Kapitel 3 eine einfache Methode zur modellbasierten Testfallspezifikation auf der Basis von Verhaltensmodellen vor und zeigt, wie sich die Modelle mit pfadorientierten Methoden direkt in Tests zur Verifikation von realen Steuergeräten umsetzen lassen. Mit den implementierten Basisalgorithmen, wie die kontrollflussorientierte Äquivalenzklassenbildung, können Testvektoren zur Verifikation eines spezifizierten Normalverhaltens eines Systems generiert werden. Erste algorithmische Erweiterungen ermöglichen zusätzlich Testfallspezifikationen zu generieren, die ein spezifiziertes Abnormalverhalten einer Steuerung überprüfen. Des Weiteren besteht die Möglichkeit, spezielle Testdaten zur automatischen Verifikation eines fehlerhaften Verhaltens, basierend auf synergetischen Effekten zwischen der Steuerungssoftware und der verwendeten Hardware, zu erstellen. Berücksichtig ist auch, eine freie Skalierung der zu erzeugenden Testdaten von einem Testexperten zu ermöglichen. Ein zu Grunde liegendes Prinzip dabei ist, dass ein Testexperte die implementierten Algorithmen entsprechend einer Testaufgabe oder des Expertenwissens parametrisiert und nicht an eine bestimmte Teststrategie gebunden ist. Dennoch bleibt mit der Kenntnis der Funktionsweise der implementierten Algorithmen eine vollständige Transparenz erhalten. 13 Kontrollflusspfade 14 White Box Testen, also Kenntnis des Programmcodes 9

21 Einleitung Festlegung allgemeiner Anforderungen an eine pfadorientierte Methode zur Testfallspezifikation: Generiere Testdaten so, dass im Steuerungscode alle Funktionen die in der Spezifikation gefordert werden, ausgeführt werden. Teste Existenz Wähle die Testdaten möglichst so, dass jede Verzweigung im Steuerungscode mindestens einmal durchlaufen wird Teste Überdeckung Wähle spezielle Testdaten derart, dass alle Sonderfälle erfasst werden. Generiere zufällige Testdaten, auch wenn sie nicht sinnvoll erscheinen, um Testlücken aufgrund scheinbarer Selbstverständlichkeiten zu vermeiden. Darüber hinaus ist neben dem implementierten Steuerungscode die Kenntnis über das Verhalten der Steuerstrecke, sowie das Verhalten der Sensorik und Aktorik, eine weitere wichtige Komponente, um hinreichend genaue Testvektoren zu erstellen. Die hier vorgestellte Modellierungssprache bietet die Möglichkeit, sowohl das Verhalten der Steuerstrecke als auch der Sensorik und Aktorik modelltechnisch abzulegen. Es sei an dieser Stelle noch mal darauf hingewiesen, das es sich dabei nicht um eine Simulation, sondern um eine Beschreibung des Verhaltens handelt. Eingebettete Systeme, die als dezentrale Steuereinheiten eingesetzt werden, sind in der Regel nur ein Teil eines komplexen technischen Umfelds. Zusammen mit einer Vielzahl weiterer technischer Komponenten bilden sie eine Systemstruktur. Um ein möglichst großes Spektrum an Informationen für eine automatische Generierung von Testfällen zu nutzen, werden auch Informationen aus der Systemstruktur in Form eines groben Systemmodells verwendet. Für eine tooltechnische Realisierung der hier motivierten Lösung ergeben sich weitere Anforderungen: Grafische Definition / Modellierung eines Strukturmodells Semiformale Eingabe von Spezifikationen / Steuerungsverhalten o Schlüssiges mathematisches Modell o Geringer Zeitaufwand für eine Modellierung Implementierung bisheriger Algorithmen zur datenbereichsbezogenen Testdatengenerierung für Tests auf Geräteebene Implementierung von Algorithmen zur funktionsorientierten Testdatengenerierung für Tests auf Geräte- und Integrationsebene Automatische Auswertung gemessener HWITL-Tests 15 für Tests, die ein spezifiziertes Normalverhalten repräsentieren Eine automatische Dokumentation der durchgeführten Tests Im Folgenden wird eine Kurzbeschreibung der Gesamtmethode gegeben, für eine ausführliche Beschreibung sei auf das Kapitel verwiesen. 15 HWITL = Hardware in the loop Tests 10

22 CFG-Tool by D.Z. and F.B. Einleitung Die Vorgehensweise wurde während der Produktverifikation eines Sub-Systems des Passagierflugzeugs Airbus A380 entwickelt. Eine Nachträgliche Auswertung von Testdaten hat gezeigt, dass ein großer Teil aller aufgetretenen Fehler nicht tief verschachtelt sind und mit großer Sicherheit mit der hier vorgestellten Vorgehensweise gefunden werden können. Generate Test Cases.95s 1.05s 3s 3.5s 4s 4.1s 5s 6.4s.95s 1.05s Path 1 Path 2 Case #1 Case #2 Case n Case #1 Case #2 Case n Attributes Abbildung 5: Toolbasierte Methode zur Verifikation von verteilten Steuerungen Die Testmethode gliedert sich in acht verschiedene Punkte. Zur Verdeutlichung der Abbildung 5 sind diese Punkte im Folgenden noch einmal kurz zusammengefasst. Im weiteren Verlauf wird auf jeden dieser Punkte eingegangen. Datenbasis Analyse der technischen Dokumente und Erfassen für das Testen wichtiger Systeminformationen. Klassifizierung Aufstellen der relevanten Elemente und Reduzierung der Komplexität durch Modularisierung. Modellierung Aufbau eines semi-formalen Verhaltensmodells Transformierung Erstellen eines gerichteten Graphen 11

23 Einleitung Generierung der Testdaten nach der kontrollflussorientierten Äquivalenzklassenbildung Auswahl der primären Methode zur Testdatengenerierung (path coverage / decision coverage) in Abhängigkeit der allgemeinen Teststrategie Auswahl der sekundären Methode (level of detail / power interrupt / CAN stress) in Abhängigkeit der speziellen Teststrategie (Bsp. Testen des spez. Abnormalverhaltens) Automatische Testdurchführung Automatische Testauswertung Generierung von Test Reports 1.4 Stand und Einordnung des Arbeitsgebietes Diese Arbeit hat die Fortführung der Arbeiten auf dem Themengebiet des Testens der Zuverlässigkeit 16, Korrektheit und Robustheit von Steuerungen komplexer hybrider technischer Systeme zum Ziel. Obwohl darauf geachtet wird, dass die im Rahmen dieser Arbeit realisierten Methoden allgemein anwendbar sind, liegt der Schwerpunkt der Erprobung der entwickelten Methoden auf eingebetteten Steuerungssystemen. Mit ihrer zunehmenden Bedeutung beschäftigen sich vermehrt Arbeiten mit Entwurfsmethoden für solche Steuerungssysteme. Im Vergleich dazu sind Arbeiten zu Testmethoden weiterhin gering. Die vorhandenen Arbeiten zu den Testmethoden untersuchen hauptsächlich Fehlerabwehrstrategien, während die vorliegende Arbeit der Fehleroffenbarungsstrategie zuzuordnen ist. Grundsätzlich ist die hier beschriebene Teststrategie zum spezifikationsorientierten Testen als Ergänzung zum implementationsorientierten Testen zu sehen. Während spezifikationsorientierte Tests im Entwicklungsprozess, z.b. nach dem V-Modell 17, unmittelbar im Anschluss an die Implementierungsphase stattfinden einige Ansätze erlauben sogar das Testen vor der Implementierung, um die Korrektheit des Entwurfs im Bezug auf bestimmte Spezifikationsanforderungen zu überprüfen -, schließt sich das implementationsorientierte Testen in anschließenden Entwicklungsphasen daran an Trend in der Softwareentwicklung für eingebettete Systeme Der Softwareentwicklung sicherheitskritischer eingebetteter Systeme, wird in der heutigen Zeit zunehmend einen höheren Stellenwert beigemessen. Ein anhaltender Trend, immer öfter Hardwaresegmente eines Systems (auch sicherheitskritische) durch Softwarekomponenten aus Kostengründen zu substituieren, ist der Hauptfaktor für diese Entwicklung. Fehler in der Software sicherheitsrelevanter Systeme, wie z.b. 16 Die Fähigkeit eines Systems oder einer Komponente unter Berücksichtigung inhärenter Fehler die erwarteten Funktionen unter spezifizierten Bedingungen über eine bestimmte Zeit durchzuführen [32]. 17 Der Bundesminister des Innern, Vorgehensmodell. Planung u. Durchführung von IT-Vorhaben,

24 Einleitung einem Fly-By-Wire System können Menschenleben gefährden oder nachhaltige wirtschaftliche Konsequenzen nach sich ziehen. Daraus ergibt sich die strikte Erfordernis, dass die Steuerungsalgorithmen dieser Systeme mit der höchst möglichen Integrität versehen sind. Dieser Trend bewirkt mit zunehmender Komplexität der Systeme allerdings auch ein zunehmendes Risiko, dass Fehler während der Entwicklung intrudiert werden. Deshalb müssen Fehleroffenbarungsstrategien in der Softwaretechnik im gleichen Maße angepasst werden. Die Aktivitäten, die während der Entwicklungsphase die Korrektheit und Zuverlässigkeit sicherstellen, werden mit den Begriffen Validation und Verifikation zusammengefasst. Mit grundlegenden Strategien und Methoden des Testens von Software-Systemen und im Besonderen mit dem spezifikations- und funktionsorientierten Testen, dem strukturorientierten Testen, mit Integrations- und Systemtests, der Komplexitätsmessung sowie dem Management des Testens behandeln die Arbeiten [36][52]. Riedemann [2] gibt darüber hinaus auch noch einen guten Überblick über weitere Methoden und Literaturstellen. Es gibt eine Reihe von Arbeiten, die sich mit der vollständigen formalen Verifikation von Steuerungsprogrammen und hybriden Systemen beschäftigen. Diese können zum Bereich der Fehlerabwehrstrategie zugeordnet werden. Als charakteristische Arbeiten können [1][20][27][28] genannt werden. Während der Verifikationsphase wird die Software (der Steuerungscode) typischerweise gegen ein dokumentiertes Sollverhalten geprüft. Dieses ist oft als Anforderungsspezifikation (Requirement-Based-Specification), also einem Satz von Einzelanforderungen mit einer Unterscheidung nach funktionalen und nicht-funktionalen Anforderungen abgelegt. Funktionale Anforderungen beschreiben Aktionen eines Systems im Rahmen von Operationen, die auf externe Ereignisse reagieren. Nichtfunktionale Anforderungen sind Randbedingungen, wie z.b. Speicherbeschränkungen oder einzuhaltende Echtzeitbedingungen der Software. C. Rupp [30] beschreibt den Requirements-Engeneering Prozess und gibt an, wie eine ständige Veränderung während des Produktentstehungsprozesses zu managen ist. Im Rahmen einer Integrationsteststrategie ist eine Vererbung von automatisierten Testfällen aus den Modultests hin zu den Integrationstests eine effiziente Art der Prüfung [6]. Methoden und Vorgehensweisen zur reinen Softwareverifikation für den Zuverlässigkeitsnachweis beschreibt u.a. W.Ehrenberger [15][55], sowie G.Thaller in [54]. Hier liegt allerdings auch ein Schwerpunkt auf der Softwarevalidation. Unter Validierung wird in der Softwaretechnik der Prozess verstanden, der eine entwickelte Software gegen die Wünsche des Kunden prüft. 13

25 Einleitung Die Definition IEEE 1012 für den Software Validation & Verification Plan (SVVP) beschreibt den minimalen Standard, wie eine Validierung und Verifikation einer Software dokumentiert werden soll. In der DIN sind für Anwendungssoftware Prüfgrundsätze für den Einsatz zur Vergabe von Software Gütesiegeln definiert. IEEE 730:1989, Standard for Software Quality Assurance Plans. IEEE 829:1983 (1991), Standard for Software Test Documentation. IEEE 1008:1987, Standard for Software Unit Testing. IEEE 1012:1986, Standard for Software Verification and Validation. IEEE 1028:1988 (1993), Standard for Software Reviews and Audits. IEEE 1044:1993, Standard for Classification of Software Anomalies. ISO , The Tree and Tabular Combined Notation (TTCN) Entwicklung eingebetteter Systeme Das ESPRESS-Verbundprojekt [8] Ingenieurmäßige Entwicklung sicherheitsrelevanter eingebetteter Systeme wurde vom Bundesministerium für Bildung und Forschung gefördert und von der Daimler Chrysler-Forschung koordiniert. An diesem nahmen mehrere Industrie- und Hochschulpartner teil. Das Projekt hatte zum Ziel, die Produktivität bei der Entwicklung komplexer sicherheitsrelevanter eingebetteter Systeme zu verbessern und eine Steigerung der Verlässlichkeit der Systeme selbst. Im Zentrum stand die Erarbeitung von Methoden zum Zuverlässigkeitsnachweis mittels Fehleroffenbarungsstrategie. Das bei diesem Projekt ausgearbeitete Systementwicklungsmodell orientiert sich an dem V-Modell und umfasst die Phasen von der Anforderungsanalyse und -spezifikation über die Codierung, bis zur Validation und Verifikation. In der Spezifikationsphase werden funktionale Spezifikation und Spezifikation von Sicherheitsanforderungen getrennt. In der Entwurfsphase werden konkrete Funktionen für die funktionalen und Sicherheitsanforderungen formuliert. Als Ergebnis wird eine ausführbare Spezifikation erwartet, aus der Code generiert und Testfälle abgeleitet werden können. Hierzu wurde eine neue formale Notation geschaffen, die eine Kombination von Statecharts mit der formalen Methode Z darstellt. Diese Kombination soll die Spezifikation von dynamischem Verhalten mittels Statecharts ermöglichen, da dies mit der formalen Methode Z nicht möglich ist [10]. Aus diesen ausführbaren Spezifikationen wird sowohl die Codegenerierung wie auch die Testfallgenerierung vorgenommen [12][22][47][48]. Da die Testfallgenerierung jedoch alle möglichen Kombinationen berücksichtigt, ergibt sich hierbei schon für Systeme mittlerer Komplexität das Problem der kombinatorischen Explosion. Weiterhin kann als problematisch angesehen werden, dass Tests, die zeitliche Aspekte beinhalten, wie z.b. Aufschaltungszeit oder reihenfolge, nur manuell definiert werden können [10][17][96]. Beinhaltet die Steuerung Zeitglieder wie z.b. Timer o.ä., hängt das Verhalten der Steuerung entscheidend von Zeitpunkten der Eingangssequenzen ab. Eine Arbeit, die Methoden und Algorithmen zur Generierung von geeigneten Stimuli für Steuerungen mit Zeitverhalten erforscht ist [55]. 14

26 Einleitung Werkzeuge für die Entwicklung eingebetteter Systeme Eine modellbasierte Beschreibung von eingebetteten Systemen ist ein gängiges Mittel um ein Echtzeit-System zu entwerfen. Bereits aus den Achtzigerjahren ist die Specification and Description Language (SDL), damals für Telekommunikationssysteme eingesetzt, bekannt. Im Jahre 1993 wurde von der IEC eine graphische Modellierung für Industriesteuerungen (SPS) in der IEC standardisiert. Die in der heutigen Zeit wohl bekanntesten Werkzeuge sind u.a. Matlab / Simulink" 18, Rhapsody von Telelogic 19 basierend auf der UML2.1 und Artisan Studio von Artisan 20. Esterel Technologies und Artisan Software Tools integrieren modellbasierte Entwicklungsumgebungen, um eine vollständige System to Deployment -Lösung für sicherheitskritische eingebettete Systeme zu bieten. Sicherheitskritische Systeme - Entwurfmethoden Das Entwurfstool SCADE 21 entstand ursprünglich aus dem etablierten Simulations- Software Paket namens Simulink (basiert auf Matlab), welches die dynamische Modellierung von Systemen ermöglicht. Anwender dieser Software sind nach Auskunft der Herstellerfirma Esterel Technologies Luft- und Raumfahrtbehörden sowie das Militär, als auch die Automobilindustrie. SCADE ermöglicht die Generierung von C- Code aus dem entworfenen Modell, wobei der Quellkode auf Plausibilität geprüft wird und eine Zertifizierung stattfindet. Dieser qualitativ hochwertige Code genügt den Anforderungen nach IEC und qualifiziert SCADE als ein Entwicklungstool bis Level-A (entspricht der höchsten Einstufung), womit sich dessen Einsatz gerade im sicherheitskritischen Bereich anbietet. In Zusammenarbeit mit dem Spezifikationsgenerator DOORS wird das Testen eines SCADE-Entwurfes gegen eine Spezifikation ermöglicht. DOORS eignet sich allgemein für die Erstellung eines Requirement Document, ist also nicht auf einen speziellen Anwendungsfall zugeschnitten. Trotz dieser Arbeitserleichterung und der Zeitersparnis im Projektmanagementbereich existieren einige Schwachstellen bei SCADE, auf die nun kurz eingegangen wird. SCADE ermöglicht als Entwurfstool nur eine Zertifizierung der Software auf Applikationsebene und spart dabei die Schnittstellen zwischen der Hard- und Software aus. Da dies aber gerade bei verteilten Systemen eine entscheidende Rolle spielt, und bei solchen Anwendungsfällen oft sehr hardwarenahe Treiber eingesetzt werden, kann die Validierung nur unvollständig erfolgen. Es sind z.b. physikalische Effekte der Steuerstrecke oder begrenzte Hardwareressourcen, die oftmals ein scheinbar fehlerfreies System versagen lassen. Zudem zertifiziert SCADE nur die Module, die standardmäßig vorhanden sind. Will man also die Unzulänglichkeiten in der Hardwareberücksichtigung durch Implementierung eigener Module umgehen, so wird der manipulierte Quellcode nicht nach den vorgeschriebenen Normen zertifiziert, womit der eigentliche Vorteil entfällt. 18 Fa. MathWorks [W3] 19 Fa. Telelogic [W4] 20 Fa. Artisan Software [W5] 21 Fa. Esterel Technologies [W6] 15

27 Einleitung Werkzeuge zur Validation und Verifikation eingebetteter Systeme Grundsätzlich bieten Entwurftools auch die Möglichkeit, die Validation und Verifikation eines Produktes zu unterstützen. So können beispielsweise Simulationen von Steuergeräten in der frühen Entwurfsphase dazu beitragen, das Systemverhalten zu analysieren. Wird zusätzlich prototypische Hardware verwendet, kann das gewünschte Sollverhalten auf einem produktnahem System, ggf. mit einer Anbindung von Sensoren, Aktoren und einer Kommunikationsschicht, bereits für fortgeschrittene komplexe Verifikationen genutzt werden. So lässt sich mit dem UML-Tool Rhapsody das Systemverhalten einer Steuerung entwerfen und mit entsprechenden Compilern einen ausführbaren Code für ein eingebettetes System erstellen. Eine weitere Werkzeugkette bietet Matlab mit dem Real-Time Workshop, Emedded Coder an: Er erzeugt C-Code aus Simulink- und Stateflow-Modellen, der so übersichtlich und effizient ist wie professioneller, handgeschriebener Code. Der erzeugte Code ist außerordentlich kompakt und schnell beides sind unabdingbare Voraussetzungen für Embedded Systems, das On-Target Rapid Prototyping, in der Massenfertigung eingesetzte Mikroprozessoren sowie für Echtzeitsimulatoren. Vorhandene Anwendungen, Funktionen und Daten lassen sich vollständig in den generierten Code integrieren. [W7] Zur Ermittlung funktionaler Black-Box-Tests ist die Klassifikationsbaummethode ( classification tree method - CTE 22 ) im Bereich von eingebetteter Software eine verbreitete Methode [17]. Es wird eine funktionale Spezifikation des Testobjekts analysiert, um testrelevanten Aspekte eines Problems zu erkennen. Durch eine Auswahl der Werte, welche diese Aspekte annehmen können, werden möglichst relevante Testfälle erzeugt. Eine Aufteilung des Problems in verschiedene Aspekte reduziert die Komplexität des ursprünglichen Testproblems. Diese, ursprünglich 1993 vorgestellte Methode diente zunächst nur der Spezifikation von abstrakten Testfällen. CTE wird im Rahmen einer Dissertation an der TU-Berlin für die Anwendung mit eingebetteten Systemen erweitert. Arbeiten, die eine Testdatengenerierung aus Klassifikationsbäumen behandeln sind [13][35]. Ein an CTE angebundenes Werkzeug zur automatisierten Testdurchführung von in C geschriebener Software eingebetteter Systeme ist TESSY 22. Eine Stärke liegt in der einfachen Durchführung von automatisierten Regressionstests. 22 TESSY und CTE entstanden bei Daimler Chrysler Software Technology in Berlin 16

28 Systemdesign und Validierung komplexer eingebetteter Steuerungssysteme 2 Systemdesign und Validierung komplexer eingebetteter Steuerungssysteme Dieses Kapitel gibt zuerst einen Überblick über die hier verwendeten Begriffe und der Taxonomie. Anschließend wird kurz der Produktenwicklungsprozess nach dem Prinzip des "Requirement Based Engeneering" beschrieben. Es wird verdeutlicht, dass die verschiedenen Validierungs- und Verifikationsphasen integrative Prozesse sind, die schon zu Beginn der Systementwicklung berücksichtigt werden müssen. Im Zentrum dieser Arbeit steht die Weiterentwicklung von Methoden zur Verifikation von eingebetteten Systemen. Deshalb wird hier speziell die Phase der Produktverifikation und die damit verbundenen Testphasen genauer betrachtet, um im weiteren Verlauf die wichtigsten bestehenden Verfahren und Testmethoden hinsichtlich einer Eignung für den Einsatz in der Phase der Integrationstests zu bewerten. 2.1 Begriffe und Taxonomie Das Testen ist eine Praxis, die in sehr unterschiedlichen Bereichen eine Anwendung findet. Es wird überall dort getestet, wo ein Vergleich eines Werks mit einer Zielvorstellung durchgeführt wird. Da dieses Verfahren interdisziplinär Anwendung findet, hat sich auch ein teilweise sehr divergentes Verständnis für die Taxonomie und Bedeutung der in diesem Umfeld verwendeten Fachbegriffe entwickelt. Im Allgemeinen werden die dynamischen Verfahren zu Qualitätssicherung als das Testen verstanden. Messen: Prüfen: Unter einer Messung versteht man die quantitative Bestimmung des Wertes einer Messgröße. Das Prüfen im technischen Sinne ist das Feststellen, ob der Prüfgegenstand die festgelegten Bedingungen erfüllt. Mit dem Prüfen ist immer eine Entscheidung verbunden, mit dem Messen nicht. Teststimuli; Testvektor: Da in der Regel nicht alle möglichen Eingaben geprüft werden, ist das Ziel die Erzeugung einer Stichprobe der Eingaben, die repräsentativ, fehlersensitiv (Fehler sollen entdeckt werden!), redundanzarm und ökonomisch sind. Verifikation: Beweis der Korrektheit eines Modells bzgl. einer vorgegebenen Spezifikation. Dabei werden alle möglichen Abläufe des Modells, insbesondere alle möglichen Eingaben, also jedes Verhalten der Umgebung des Modells betrachtet. 17

29 Systemdesign und Validierung komplexer eingebetteter Steuerungssysteme Validierung: Qualität: Requirements: Testobjekt: Testeigenschaft: Testerfolgskriterium: Testfall: Testfallspezifikation: Test: Testen: Testszenario: Testvorfall: Testlog: Als Validierung bezeichnet man die Prüfung, ob ein Lösungsansatz für ein bestimmtes reales Problem verwendungsfähig ist, bzw. ob das implementierte System den vorher aufgestellten Anforderungen genügt. Qualität ist die Beschaffenheit einer Einheit bezüglich ihrer Eignung, festgelegte und vorausgesetzte Erfordernisse zu erfüllen (DIN 55350, Teil 11) Mit Requirements (deutsch: Anforderungen ) ist sowohl die qualitative als auch die quantitative Definition einer benötigten Eigenschaft bzw. Funktion aus Sicht des Auftraggebers gemeint. Jedes Systemelement, das Gegenstand des Tests ist. Merkmal des Testobjektes, die es zu testen gilt. Regel für die Entscheidung, ob ein Test bestanden ist oder nicht Einmalige Ausführung eines Systems durch die Auslösung eines Ereignisses. Beschreibung der Vor- und Nachbedingungen und der Entscheidungsregeln für einen Testfall. Eine Menge logisch zusammenhängender Testfälle, die in einem Stapel oder in einer Sitzung ausgeführt werden. Ausführung eines Modells (z. B. im Simulator) mit dem Ziel, Fehler zu finden. Vollständiges Testen, d. h. Testen aller möglichen Abläufe eines Modells ist i. d. R. unmöglich, da deren Zahl meist astronomisch hoch ist. Testen kann daher i. a. nur die Anwesenheit von Fehlern, nie jedoch deren Abwesenheit beweisen. Plan für die Ausführungsfolge der Testfälle. Jedes unerwartete Ereignis während eines Tests. Protokoll der Testausführung. 18

30 Systemdesign und Validierung komplexer eingebetteter Steuerungssysteme 2.2 Produkt- / Systementwicklung eingebetteter Systeme Eine Systementwicklung umfasst sowohl die Entwicklung des zu erstellenden Systems, als auch die Entwicklung zusätzlich notwendiger Unterstützungssysteme, wie zum Beispiel Test- und Wartungssysteme, die in den verschiedenen Systemlebenszyklen benötigt werden. Die Entwicklung folgt dabei in der Regel einer hierarchischen Zerlegung des Systems in immer kleinere Einheiten, bis diese schließlich die Größe von Modulen erreicht haben, für die eine Realisierung möglich wird. Entsprechend sind in der Regel im V-Modell Teilsysteme jeweils hierarchisch in Segmente, HW- Einheiten, SW-Einheiten, Externe Einheiten, HW-Komponenten, SW-Komponenten, HW-Module und SW-Module gegliedert. Diesem hierarchischen Systemaufbau folgend, wird während der Systementwicklung die Spezifikation und die Zerlegung des Systems vorgenommen. Die in Abbildung 6 dargestellten Entscheidungspunkte stellen die grundlegenden Stufen der Verfeinerung der Spezifikation und der Zerlegung des Systems dar. Abbildung 6: Vorgehensmodell Für jeden dieser Zerlegungsschritte ist ein präzise festgelegtes Vorgehen vorgegeben, das auf einem einheitlichen Muster basiert und eine lückenlose Verfolgung der Umsetzung der Anforderungen ermöglicht. Dabei werden bei jedem dieser Schritte zunächst die Anforderungen aus den übergeordneten Systemelementen übernommen, die Zerlegung entworfen, die Realisierung der Systemelemente spezifiziert und schließlich die Anforderungen der nächsten Ebene der Systemelemente zugeordnet. Die Realisierung und Integration des Systems erfolgt im Vergleich zur Spezifikation und Zerlegung in umgekehrter Reihenfolge. Ausgehend von den realisierten HW- Modulen und SW-Modulen, werden die komplexeren Elemente und schließlich das System integriert. Dabei wird die Verifikation und Validierung auf jeder Konstruktionsstufe durchgeführt. 19

31 Systemdesign und Validierung komplexer eingebetteter Steuerungssysteme In Abbildung 7 sind die wichtigsten V&V-Phasen detaillierter im V-Modell eingeordnet. Es sind folgende Prozessschritte durchzuführen, um die Zuverlässigkeit der Entwicklungstätigkeiten zu prüfen: Validation der Anforderungen Verifikation des Entwurfs Produktverifikation Produktvalidation Abbildung 7: Produktentwicklung nach dem V-Modell Requirement Validation (grüne Pfeile) Überprüfung, ob die aufgestellten Requirements die Anforderungen befriedigen Design Verifikation (rote Pfeile) Überprüfung, ob ein spezifizierter Entwurf (Design) den Requirements entspricht Produkt Verifikation (blaue Pfeile) Überprüfung, ob das Produkt dem Entwurf entspricht, bzw. Überprüfung, ob das Produkt den gestellten Requirements entspricht Produkt Validation (orange Pfeile) Überprüfung, ob das finale Produkt auch den vom Kunden gestellten Anforderungen (Wünschen) entspricht Das ingenieurmäßige Erheben der Anforderungen (englisch: requirements engineering) ist ein Teil des Software- und Systementwicklungsprozesses. Ziel ist es, die Anforderungen des Auftraggebers an das zu entwickelnde System zu ermitteln und zu verwalten. Requirements Management, V&V, RbE Das Requirement based Engineering, kurz RbE, ist ein wichtiger Bestandteil in der heutigen Entwicklung von immer komplexer werdenden Produkten. Das anforderungsbasierte Entwickeln von komplexen Produkten bzw. Systemen hat zum Ziel, 20

32 Systemdesign und Validierung komplexer eingebetteter Steuerungssysteme alle Anforderungen (Funktionen, Sicherheit, Wartbarkeit,...), die an ein Produkt gestellt werden, abgesichert umzusetzen. Von Beginn der Entwicklung an, identifiziert der Autor eines Requirements eindeutig, was als Lieferung erwartet wird und wie es verifiziert wird (Design Verification und Product Verification). Durch eine Validation, Verifikation und Überwachung der Entwicklung während des gesamten Produktlebenszykluses soll gewährleistet werden, dass alle Anforderungen der jeweiligen Nutzer, Abteilungen oder Auftraggeber an das Produkt, bzw. Endprodukt berücksichtigt und aufeinander abgestimmt werden (Bsp.- Tool DOORS von Telelogic). Typischerweise werden Produkt- und Prozessrequirements unterschieden: Produktrequirements sind als solche definiert, die einen direkten Einfluss auf den Entwurf des Produktes haben. Sie formalisieren die Anforderungen des Auftraggebers z.b. bezüglich der Funktion oder Leistung und inkludieren u.a. eine Zertifikation, Sicherheitsaspekte, Entwurfrichtlinien, Testbarkeit. Nicht-Produktbezogene Requirements sind als solche definiert, die keinen direkten Einfluss auf den Entwurf oder das Design, aber Einfluss auf den Entwicklungsprozess haben. Ein Requirement Management Plan beinhaltet beide Typen und definiert damit verbundene Aktivitäten wie das Requirement Capturing, eine Validation und Kaskadierung der Anforderungen. Letztendlich wird über eine Verifikation des Produktes, als Bestandteil des V&V Prozesses, die Einhaltung der spezifizierten Anforderungen bestätigt. Abbildung 8: Requirement Management im V&V-Prozess 21

33 Systemdesign und Validierung komplexer eingebetteter Steuerungssysteme Abbildung 8 illustriert vereinfacht den Zusammenhang zwischen dem Requirement Management und den V&V-Aktivitäten innerhalb des RbE-Prozesses. Mit dieser Vorgehensweise erhöht sich die Qualität des Endproduktes bei kürzerer Entwicklungszeit und geringeren Entwicklungskosten. Die Produktivität im Produktentwicklungsprozess wird gesteigert und die Modifikationskosten in nachgelagerten Prozessschritten werden gesenkt. Ein Ziel ist, bestehende Fehler bereits in der frühen Phase der Produktentwicklung zu identifizieren. Um sicherzustellen, dass die Produkteigenschaften die formalisierten Anforderungen und auch die Erwartungen des Auftraggebers erfüllen, müssen die Validations- und Verifikationsaktivitäten eine Rückkopplung auf den Produktentwicklungsprozess bewirken. Abbildung 9 verdeutlicht diesen Zusammenhang. Abbildung 9: Verifikation von Produkteigenschaften am Beispiel aus der Luftfahrt Das Mittel zur Umsetzung, der vom RbE-Prozess vorgeschriebenen Qualitätssicherung (Produkt Verifikation), ist das Testen der Produkteigenschaften gegen seine Spezifikation. Dazu existieren eine Vielzahl kommerzieller und auch teilweise spezieller Testsuiten bzw. Testtools. Folgendes Kapitel ordnet die, diesen Tools zugrunde liegenden Testmethoden ein, um im weiteren Verlauf im Besonderen die Produktverifikationsmethoden zu betrachten. 22

34 Systemdesign und Validierung komplexer eingebetteter Steuerungssysteme 2.3 Einteilung der Testmethoden Unter dem Vorgang Testen existiert im Allgemeinen ein teilweise stark divergentes Verständnis. Oft wird eine konstruktive Haltbarkeit eines Testobjekts damit verbunden, z.b. in der Form, dass mit einer destruktiven Methode getestet wird. Oder einfaches Ausprobieren einer Objekteigenschaft, bzw. einer Funktion, ohne eine zur Grunde liegenden erkennbaren Methodik. Eine professionelle Anwendung der Validations- und Verifikationsmaßnahmen aus den heutigen Qualitätssicherungsprozessen bedingt aber eine reproduzierbare, bewertbare und im Sinne einer Zertifizierung auch nachweisbare Vorgehensweise. Zwingende Voraussetzung dafür ist der Einsatz der richtigen Testmethode, bzw. die richtige Kombination verschiedener Testmethoden für den jeweiligen Anwendungsfall. Abbildung 10: Testmethodenbaum statische und dynamische Methoden Statische und manuelle Testmethoden Abbildung 10 zeigt eine Übersicht statischer und dynamischer Testmethoden. Statische Testmethoden sind den analysierenden Verfahren zuzuordnen. Aus der Klasse der informellen Methoden können die Inspektion und das Review als Hauptvertreter genannt werden. Unter einer Inspektion wird die Durchführung einer Kontrolle, in der Regel mit Hilfe von Checklisten, verstanden. Ein oder mehrere Experten bewerten, ob die zu inspizierende Komponente eine bestimmte Eigenschaft erfüllt. Typische Anwendung für eine Inspektion ist eine Kontrolle der Präzision, Konsistenz oder die Einhaltung von Standards. 23

35 Systemdesign und Validierung komplexer eingebetteter Steuerungssysteme Ein Review ist eine Begutachtung auf der Basis von Dokumenten und soll eine qualitative Bewertung der Korrektheit ergeben. Der Gutachter wird auf offensichtliche Defizite oder Verbesserungsmöglichkeiten hinweisen, aber nicht nach Rechtschreibfehlern oder sprachlichen Unzulänglichkeiten suchen. Selbst wenn Schlussfolgerungen, Ableitungen etc. ohne zusätzliches Wissen oder Datenmaterial nachvollziehbar sind, ist es nicht die Aufgabe des Gutachters, deren Korrektheit oder Konsistenz im Detail zu überprüfen. Er kann nur die Signifikanz und Aktualität der Fragestellung, die Originalität und Validität des Lösungsansatzes und die Plausibilität der Resultate im Kontext überprüfen, sowie auf methodische Fehler hinweisen. Das Verfahren des Walkthroughs gehört zu den manuellen dynamischen Verfahren des Testens. Darunter wird eine Evaluierung eines Dokumentes durch Ausführen der Funktionen, in Form manueller Simulationen auf dem Papier verstanden. Gewöhnlich wird das in einem Team durchgeführt, indem hauptsächlich der Autor des Dokumentes die von den anderen Team-Mitgliedern erstellten Testfälle beantwortet. Daher ist eine typische Anwendung dieses Verfahrens auch die Phase der Testfallspezifikationserstellung. Unter Umständen kann eine zuvor erarbeitete FMEA 23 -Analyse mit einem Expertenteam die Qualität der erstellten Testfälle verbessern Teststrategien und Testansätze zu dynamischen Stichproben-Tests Entgegen der statischen Methoden, führen dynamisch testende Verfahren stets das zu testende System aus und sind daher den Stichproben-Tests zuzuordnen. Sie lassen sich wiederum in spezifikationsorientierte und implementationsorientierte Methoden unterteilen. Erstere sind klassische Black-Box-Methoden, bei denen keine genauen Informationen zur konkreten Umsetzung der Steuerungsalgorithmen, bzw. Realisierung der Steuerung, vorliegen. Lediglich eine Spezifikation, bzw. die technische Dokumentation des Testobjekts dient als Informationsquelle. Für gewöhnlich stehen auch nur die Standard Ein- und Ausgänge eines Gerätes zur Verfügung. Ggf. existieren spezielle Debug -Möglichkeiten, wie beispielsweise das Auslesen eines Fehlerspeichers über eine serielle Schnittstelle. Spezifikationsorientierte Tests kommen verstärkt bei Integrationstests, Systemtests und Abnahmetests zum Einsatz. Dabei kann die Granularität der mit diesen Methoden erzeugten Testvektoren sehr unterschiedlich sein. Sie reicht von einem vollständigen Stimuliraum im Rahmen von intensiven Modultests bis hin zu ausgewählten Benutzerszenarien zur systemübergreifenden Stimulation. Für eine Anwendung von implementationsorientierten Methoden müssen in der Regel alle Implementierungsdetails, speziell ein (Programm-) Kontrollflussgraph vorliegen. Gewöhnlich werden sie zur Programmverifikation, bzw. Softwareverifikation eingesetzt. 23 FMEA Failure Mode and Effect Analysis 24

36 Systemdesign und Validierung komplexer eingebetteter Steuerungssysteme Implementationsorientierte Methoden (White Box Methoden) Zustandsbasierte Testmethoden Zustandsbasierte Testmethoden basieren auf Zustandsautomaten, die heute oft als UML-Diagramm dargestellt werden. Einsetzbar sind zustandsbasierte Methoden außer in technischen Anwendungen auch beim Test grafischer Benutzeroberflächen und von Objektorientierten-Klassen, die durch Zustandsautomaten definiert sind. Um die Vollständigkeit der so ermittelten Testfälle zu prüfen, gibt es verschiedene Kriterien. Im Wesentlichen muss sichergestellt werden, dass für einen Test die gewünschten, ggf. alle Zustände / Zustandsübergänge durchlaufen werden und alle Ereignisse, welche Zustandübergänge hervorrufen, getestet werden. In der Beschreibung eines Zustandsautomaten sind üblicherweise keine Fehlerfälle vorgesehen. Diese sind zusätzlich zu spezifizieren, indem zu jeder Kombination {Ausgangszustand; Ereignis} (auch für im Automaten nicht spezifizierte Kombinationen) der Folgezustand und die ausgelösten Aktionen angegeben werden. Liegen diese Informationen formal vor, können diese Kombinationen getestet werden. Strukturorientierte Verfahren Anders als bei den Black-Box-Methoden beruhen die Verfahren der White-Box- Methoden auf einer Analyse der Struktur des Testobjekts und sind daher ein codebasiertes Testverfahren. Im günstigsten Fall ist die Kontroll-Struktur aus dem Systementwurf bekannt. Eine Analyse des Quellcodes hat zum Ziel, die Testfälle so zu erstellen, dass z.b. alle Teile des Quellcodes mindestens einmal ausgeführt werden, oder alle Pfade in einem Programm durchlaufen werden. Dieser Struktur- oder Pfad- Test ist eine formale White-Box-Spezifikationsmethode und wird hauptsächlich für Modultests und Integrationstests eingesetzt. Die Elemente eines Graphen sind Anweisungsblöcke, Entscheidungen und Kanten zwischen diesen Elementen. Ein Testfall wird dabei als einzelner Pfad durch ein Programm oder Routine gekennzeichnet. Und ein Pfad durch eine Routine ist jede ausführbare Sequenz von Instruktionen, die bei einem Eingangspunkt in die Routine beginnt und an einem der Austrittspunkte endet. Eine Ansammlung mehrerer Pfade, die jeweils von einem Start- zu einem Endpunkt reichen, wird Strukturtest genannt. Das Testmaß des Strukturtest (path coverage) wird bestimmt durch die Länge der Aktionskombinationen (Pfad-Teilstücke) sämtlicher unterschiedlicher Pfade. Wünschenswert ist eine vollständige Test-Überdeckung, d.h. alle möglichen Pfade werden mindestens einmal durchlaufen. Dies ist i.d.r. aber nur für kleine Projekte möglich, daher werden Näherungsverfahren verwendet, die im Folgenden kurz vorgestellt werden. Die wichtigsten Kriterien für Kontrollflussbezogene Verfahren sind die: 25

37 Systemdesign und Validierung komplexer eingebetteter Steuerungssysteme Anweisungsüberdeckung: Alle Anweisungen sollen mindestens einmal ausgeführt werden. Zweigüberdeckung: Alle durch Selektion oder Iteration bedingten Verzweigungen sind mindestens einmal zu verfolgen. Bedingungsüberdeckung: Bedingungen in Schleifen und Auswahlkonstruktionen werden getestet. Pfadüberdeckung: Alle Pfade werden einmal durchlaufen, das ist i.a. nur in Näherungen zu erreichen Spezifikationsorientierte Methoden (Black-Box-Methoden) Unter dem Begriff Spezifikationsorientiertes Testen wird eine Verifikation des Testobjekts unter der Zuhilfenahme einer meist informellen Spezifikation verstanden. Eine häufig vertretende und bekannte Methode ist das Zufällige Testen oder die Fehlererwartungsmethode. Dabei geht der Testexperte mit dem Wissen der Spezifikation und einer gewissen Erwartungshaltung, wie ein fehlerhaftes Verhalten anzustoßen ist, die Funktionen durch. Diese Methoden sind den unsystematischen, datenbereichsbezogenen Verfahren zuzuordnen. Äquivalenzklassenmethode Datenbereichsbezogen systematisch unsystematisch Grenzwertanalyse Ursache-Wirkungsgraf Zufälliges Testen Fehlererwartungsmethode Spezifikationsorientierte Verfahren Testen auf Basis algebraischer Spezifikationen Reihenfolgebedingungen Automaten Äquivalenztest Alle Transitionen Funktionsbezogen Funktionale Formen Entwurforientiertes Testen PETRI Netze, SADT Abbildung 11: Spezifikationsorientierte Testmethoden Bekannte Vertreter aus den datenbereichsbezogenen aber systematischen Verfahren sind die Äquivalenzklassenmethode und im Allgemeinen darauf aufbauend, die Grenzwertanalyse. Eine Anwendung dieser Verfahren ist sehr bekannt und findet sich in unterschiedlichen Testdomänen wieder. Im weiteren Verlauf wird gezeigt, wie 26

38 Systemdesign und Validierung komplexer eingebetteter Steuerungssysteme mit diesen klassischen Verfahren das Problem einer kombinatorischen Explosion beim vollständigen datenbereichsbezogenen Testen von zeitbehafteten Systemen bewältigt werden kann Klassifikation datenbereichsbezogener Methoden Klassische Äquivalenzklassenbildung und Verbesserung durch die Grenzwertanalyse Das Prinzip der Äquivalenzklassenbildung beruht auf einer Unterteilung des Wertebereiches eines Eingabeparameters in Intervalle, innerhalb derer für einen beliebig ausgewählten Wert, ein konstantes Verhalten des Testobjekts zu erwarten ist. Es entspricht demnach also einer Gruppierung von Testfällen mit gleichartigem Verhalten des Testobjekts mit dem Hintergrund, dass nur ein einziger Repräsentant pro Äquivalenzklasse als Testfall ausgewählt werden muss. Mit dieser Vorgehensweise soll eine hohe Fehlererkennungsrate mit einer möglichst geringen Anzahl von Testfällen erreicht werden. Für zeitbehaftete Systeme kann die Äquivalenzklassenbildung auch zur Bestimmung der genauen Aufschaltzeitpunkte von Stimuli herangezogen werden. Abfolge : Analyse und Spezifikation der Eingabedaten, der Ausgabedaten und der Bedingungen gemäß den Spezifikationen Bildung der Äquivalenzklassen durch Klassifizierung der Wertebereiche für Ein- und Ausgabedaten Bestimmung der Testfälle durch Werteauswahl für jede Äquivalenzklasse Äquivalenzklassen werden allgemein unter logischen Gesichtspunkten erstellt, indem insbesondere auf die Gleichartigkeit der Klassen- bzw. Objekteigenschaften sowie deren Ermittlung geachtet wird. Es werden zwei Arten von Äquivalenzklassen unterschieden: gültige Äquivalenzklassen ungültige Äquivalenzklassen Bei gültigen Äquivalenzklassen werden gültige Eingabedaten, bei ungültigen Äquivalenzklassen ungültige Eingabedaten verwendet. Äquivalenzklassenbildung mit mehreren Eingabeparametern: Für den Fall, dass mehrere Eingabeparameter für eine Verifikation nötig sind, müssen die einzelnen Repräsentanten der gültigen Äquivalenzklassen entsprechend zu Testfällen kombiniert werden. Um in diesem Fall jeden Test ausführen zu können, müssen alle Eingabeparameter während der Tests mit Werten belegt werden. Es werden für alle Repräsentanten der gültigen Äquivalenzklassen alle möglichen Permutationen gebildet. Repräsentanten ungültiger Äquivalenzklassen werden nur mit gültigen Repräsentanten kombiniert, d.h. pro Testfall darf nur ein ungültiger Parameter enthalten sein. In der Regel sind an ungültige Parameter Prozeduren geknüpft, 27

39 Systemdesign und Validierung komplexer eingebetteter Steuerungssysteme die im Testobjekt eine Ausnahmebehandlung, also ein spezifiziertes Abnormalverhalten auslösen. Werden mehrere ungültige Werte kombiniert, kann i.d.r. nicht nachvollzogen werden, welcher die Ausnahmebehandlung verursacht hat. Verteilte eingebettete Steuerungssysteme bilden einen Anwendungsfall für die Methode der Äquivalenzklassenbildung mit mehreren Eingabeparametern. Darüber hinaus ist bei diesen Systemen nicht nur der eigentliche Aufschaltwert, sondern auch der genaue Aufschaltzeitpunkt eine wichtige Größe für eine Klassifizierung nach gültigen und ungültigen Äquivalenzklassen. Betrachtung der Grenzwerte einer Äquivalenzklasse Wie bereits erwähnt ist ein beliebiger Wert innerhalb einer gültigen Äquivalenzklasse ein Repräsentant dieser Klasse, das gilt auch für Werte an den Grenzen dieser Klasse. Eine Wahl dieser Werte ist sinnvoll, um nachzuweisen, dass Randwerte durch die Implementierung korrekt zugeordnet werden. Um das Testobjekt in Bezug auf Eingabewerte an den Äquivalenzklassen-Grenzen zu untersuchen, wird eine Grenzwertanalyse durchgeführt. An den Bereichsgrenzen, also an der oberen und an der unteren Äquivalenzklassengrenze, werden zusätzliche Testfälle erzeugt. Diese sind im Idealfall nur mit einem minimalen Abstand zu den Bereichsgrenzen positioniert. Ein typischer Fehlerfall der, mit dieser Methode gefunden werden kann, ist eine falsche Implementierung eines Schleifenkonstrukts. Wird beispielsweise als Schleifenabbruchkriterium ein < anstelle eines <= geschrieben, so ist die Bereichsgrenze dieser Äquivalenzklasse nicht korrekt implementiert. Ein Testfall an dieser Grenze kann den Fehler finden. Ursache- Wirkungsgraph Bei dieser Methode werden Ursachen und Wirkungen jeder Teilspezifikation identifiziert. Eine Ursache ist dabei eine einzelne Eingabebedingung oder eine Äquivalenzklasse von Eingabebedingungen. Eine Wirkung stellt eine Ausgabebedingung oder eine Systemtransformation dar. Die Teilspezifikation wird in einen Boole schen Graphen überführt, der Ursachen und Wirkungen durch logische Verknüpfungen verbindet 24. Anschließend wird der Graph um Abhängigkeiten auf Grund von syntaktischen Zwängen oder Umgebungsbedingungen ergänzt. Die folgenden Arten von Abhängigkeiten zwischen Ursachen werden dabei unterschieden: 1. Exklusive Abhängigkeit: Die Anwesenheit einer Ursache schließt andere Ursachen aus. 2. Inklusive Beziehung: Mindestens eine von mehreren Ursachen liegt vor (z.b. ist eine Ampel immer grün, gelb oder rot oder rot und gelb zusammen. Wenn sie funktioniert und eingeschaltet ist). 3. One-and-only-one-Beziehung: Es liegt genau eine von mehreren Ursachen vor (z.b. Taster gedrückt oder Taster nicht gedrückt). 24 Eine umfassende Beschreibung der Ursache-Wirkungs-Graph Methode, sowie Beispiele hierzu finden sich in [36] 28

40 Systemdesign und Validierung komplexer eingebetteter Steuerungssysteme 4. Requires-Abhängigkeit: Die Anwesenheit einer Ursache ist Voraussetzung für das Vorhandensein einer anderen (z.b. Alter > 21 und Alter > 18). 5. Maskierungsabhängigkeit: Eine Ursache verhindert, dass eine andere Ursache eintreten kann. In der Literatur wird das UWG-Verfahren den datenbereichsbezogenen Methoden zugeordnet, es kann aber auch im Rahmen funktionsorientierter Verfahren genutzt werden, wenn die Bildung des Ursache-Wirkungsgraphs auf Funktionsebene geschieht. Das heißt, es werden auch innere Zustände und Verzweigungen in den Graphen aufgenommen Klassifikation funktionsorientierter Verfahren Eine allgemeine Definition der funktionsorientierten Testmethoden besagt, dass Testfälle bestimmt werden, mit denen geprüft werden soll, inwieweit das Testobjekt die vorgegebenen Spezifikationen erfüllt. Man spricht auch davon, dass gegen die Spezifikationen getestet wird. Je nach Testobjekt und Testart sind die Spezifikationen dabei von unterschiedlicher Art. Beim Modultest wird z.b. gegen die Modulspezifikation getestet, beim Schnittstellentest gegen die Schnittstellenspezifikation und beim Abnahmetest gegen die fachlichen Anforderungen, wie sie etwa in einem Pflichtenheft niedergelegt sind. Damit entspricht diese Definition der des spezifikationsorientierten Testens. Deshalb sei darauf hingewiesen, dass die hier genannten funktionsorientierten Verfahren immer im Zusammenhang mit einer Verifikation einer Steuerungsfunktion behandelt werden. Ein funktionsorientiertes Verfahren liefert Testvektoren zum Korrektheitsnachweis von Steuerungsfunktionen, die ggf. auch verteilt über verschiedene Steuerungen implementiert sein können. Function Detection Function Detection hat als Ziel, die Korrektheit aller Funktionen im System zu zeigen. Der Aufwand, Korrektheit für alle Funktionen in allen Umständen zu zeigen, ist bis auf sehr kleine Systeme zu hoch. Die Korrektheit mancher Funktionen ist jedoch wichtiger als die anderer. Daher muss der Tester bei begrenzter Zeit (also immer) den Fokus auf die wichtigsten Funktionen legen. Funktionale Äquivalenzklassenbildung Ist ein Verfahren bei dem die Eingangsbereiche, für die der Tester ein identisches Ausgangsverhalten erwartet, in funktionale Äquivalenzklassen zusammengefasst. Dadurch wird eine Reduzierung des Stimuliraumes ermöglicht. Die klassische funktionale Äquivalenzklassenbildung betrachtet allerdings keine Wechselwirkungen zwischen den unterschiedlichen Klassen. 29

41 Systemdesign und Validierung komplexer eingebetteter Steuerungssysteme Funktionale zustandsbasierte Verfahren Strukturorientierte Testverfahren können im Rahmen von spezifikationsbasierten Tests eingesetzt werden, wenn eine ausreichend gute Modellbildung auf der Basis der (meist) nicht formalen Dokumentationen möglich ist. Eine Spezifikation, oder ein Teil dieser muss als Datenbasis in Form eines Graphen (gerichteter Graph) bzw. eines formalen Zustandautomaten abgelegt werden. Wie im weiteren Verlauf noch genauer gezeigt wird, ist die Grundlage der hier vorgestellten Methode an diesem Prinzip angelehnt. Jedoch wird hier eine Spezifikation in einen hierarchischen Zustandsübergangsgraphen mit einer, an den Anwendungsfall angepassten Klassifizierung der physikalischen Struktur, übersetzt. Das ermöglicht eine Implementierung verschiedener, teilweise kombinierter Testmethoden, wie z.b. der kontrollflussbasierten Äquivalenzklassenmethode oder der kontrollflussbasierten Grenzwertanalyse Datenbereichsbezogene Generierung vollständiger Testvektoren Eine konkrete Anwendung der datenbereichsbezogenen Methoden (vgl ) im Umfeld verteilter zeitbehafteter Steuerungssysteme bedarf einer besonderen Betrachtung. Für eine Erzeugung von Testvektoren mit dieser Methode, muss bei eingebetteten Systemen auch zusätzlich das Zeitverhalten des Testobjektes berücksichtigt werden. Eine diesbezügliche Weiterentwicklung ist in [55] beschrieben und wird, aufgrund der Relevanz für diese Arbeit, im Folgenden kurz zusammengefasst. Die entwickelte Methode stellt eine datenbereichsbezogene Methode dar, welcher die einzelnen Funktionen des zu testenden Systems unterworfen werden. Um eine solche durchführen zu können, müssen neben den Aufschaltwerten der Stimuli auch ihre Aufschaltzeiten ermittelt werden. Da die Anzahl der Tests mit der Anzahl der Aufschaltzeitpunkte exponentiell steigt, liegt ein Schwerpunkt darin, möglichst repräsentative Aufschaltzeitpunkte zu ermitteln. Zur Ermittlung der genauen Aufschaltzeitpunkte wird zunächst die Zeit in sog. Äquivalenzklassen diskretisiert. Äquivalenzklassen werden unter der Annahme gebildet, dass sich der innere Zustand der betrachteten Komponente nur zu den Zeitpunkten ändert, bei denen Änderungen der Ein-/Ausgangsbelegungen auftreten, bzw. Kommunikationsnachrichten gesendet oder empfangen werden. Dazwischen wird der Gesamtzustand als konstant angenommen. Mit dieser Annahme ist sichergestellt, dass immer unterschiedliche Gesamtzustände des Systems getestet werden. Besonders bei Systemen mit stark unterschiedlichen Zeitgliedern, führt die Bildung von Äquivalenzklassen auf Basis dieser charakteristischen Zeiten, im Vergleich zu einer äquidistanten Einteilung basierend auf dem kleinsten Zeitglied, zu einer Reduzierung der Aufschaltzeitpunkte. 30

42 Systemdesign und Validierung komplexer eingebetteter Steuerungssysteme Auch Steife Systeme 25 können dadurch in vergleichsweise wenige Äquivalenzklassen aufgeteilt werden.... WF MPI TA CAN#2 CAN#1 RVD FVD1 FVD2 RV FVPS 1 FVPS 2 Stimuli für Modultests Test Spülsequenz eventdef ActorFailures... eventdef SensorFailures... Test Datentransfer eventdef CANMesages1... eventdef CANMesages2... eventgroup und/oder eventcomb eventgroup und/oder eventcomb Stimuli für Integrationstests eventgroup und/oder eventcomb oder scenario MCI eventdef SensorActorEvents... Abbildung 12: Methode zur datenbereichsbezogenen vollständigen Testfallspezifikation mit den Schlüsselwörtern der umgesetzten Skriptsprache Nachdem die zu testende Funktion in homogene Klassen 26 aufgeteilt ist, werden die Aufschaltzeitpunkte festgelegt. Da jede homogene Klasse einen Systemzustand repräsentiert, wird je ein Zeitpunkt willkürlich (zu einer beliebigen Zeit) innerhalb einer Klasse gelegt. Im weiteren Verlauf wird diese Platzierung als Festlegung der Zeitpunkte nach der Äquivalenzklassenmethode bezeichnet. Eine Verbesserung stellt ein Festlegen der Testzeitpunkte nach der Grenzwertmethode dar. Dabei wird nicht nur ein beliebiger Wert aus den gebildeten Äquivalenzklassen gewählt, sondern Werte an den Grenzen der Klassen. Diese Werte haben eine besondere Bedeutung, da erfahrungsgemäß an solchen Übergangsstellen bei der Implementierung vermehrt Fehler auftreten. Insbesondere kann es durch kritische Wettläufe, Oszillationen 27 o.ä. - im Allgemeinen asynchronen Vorgängen - zu Bedingungen kommen, die in der Spezifikation oder der Implementierung übersehen wurden. Solche Fälle können durch geschickte Wahl der Stimulizeitpunkte mittels der Grenzwertmethode abgetestet werden. 25 Systeme mit stark unterschiedlichen Zeitgliedern führen bei der Diskretisierung nach dem kleinsten Zeitglied schon bei kleinen Systemen zu einer praktisch nicht zu bewältigenden Dimension des Zustandsraumes. 26 Unter der Homogenität einer Äquivalenzklasse wird verstanden, inwieweit ein beliebiger Wert dieser Klasse repräsentativ für alle anderen Werte der Klasse ist. Ist die Klasse homogen, so hat jeder beliebige Wert der Klasse die gleiche Aussage im Bezug auf das untersuchte Kriterium. 27 kritische Wettläufe Oszillationen, siehe [16] 31

43 Systemdesign und Validierung komplexer eingebetteter Steuerungssysteme Ein weiteres Merkmal der betrachteten Systeme ist, dass oft die Zeitdauer bestimmter Vorgänge nicht bekannt ist. Beispielsweise kann das Öffnen eines Ventils unter verschiedenen Randbedingungen unterschiedlich lange dauern. Für solche Vorgänge wurden Regeln zur Ermittlung der Testzeitpunkte für Äquivalenzklassen mit Kernund Übergangsintervallen erarbeitet. Mit der Kenntnis der Aufschaltzeitpunkte der Teststimuli und die zu stimulierenden Ein- und Ausgänge kann eine vollständige Teststimuligenerierung vorgenommen werden. Dabei werden alle möglichen Kombinationen von simultanen, sequentiellen und den kombinierten simultan-sequentiellen Stimuli zu den mittels o.g. Methode ermittelten Zeitpunkten aufgeschaltet (Abbildung 12). Die hier vorgestellte Methode wurde programmtechnisch derart umgesetzt, dass Testfälle im Sinne einer Testfalldefinition mit einer entwickelten Skriptsprache, automatisch generiert werden und damit zu den vom Experten manuell erstellten Testfällen kompatibel sind. Sie lassen sich mit den Möglichkeiten der Skriptsprache entsprechend kombinieren. Bei der vollständigen Teststimuligenerierung werden in vielen Fällen für eine Durchführung in einer vorgegebenen Zeit, zu viele Tests erzeugt. Mit der Eliminierung vieler nicht relevanter Stimuli, kann eine sinnvolle Reduzierung der Tests mit Hilfe der Definitionssprache realisiert werden. Eine Maßnahme ist die Unterteilung der Steuerungseingänge in abhängige und unabhängige Größen. Unabhängige Größen sind Eingänge einer Steuerung, die eine Funktion initiiert, z.b. der digitale Eingang der Spülanforderung (Flush Switch) in einer Flugzeugtoilette. Abhängige Größen sind sämtliche Ausgänge einer Steuerung, sowie Sensoreingänge, die beispielsweise von der Steuerstrecke abhängen. Eine solche Einteilung wird auch mit den Mitteln der Skriptsprache unterstützt. Abhängige und unabhängige Stimuli bilden jeweils eine Gruppe. Eine weitere sinnvolle Gruppierung bildet die Menge der Stimuli, die aus dem Simulationsumfeld entnommen werden können. Erst durch diese Einteilung ist es möglich, aus der Menge der abhängigen Größen die Kombinationen zu eliminieren, die als weniger relevant angesehen werden können. Darunter werden Fehleraufschaltungen verstanden, die aufgrund ihrer Kombination in hohem Maße unwahrscheinlich sind. Ein solcher Fall ist eine simultane Aufschaltung einzelner abhängiger Größen, die im realen technischen System angeschlossene Geräte (z.b. Sensoren) mit einer hohen (Einzel-) Ausfallwahrscheinlichkeit repräsentieren. Es kann festgelegt werden, wie viele Fehler gleichzeitig auftreten können. Dies kann in Abhängigkeit der Kritikalität 28 eines Systems erfolgen. Für die Bewertung der, mit dieser Methode erstellten Tests, kann das Testwirksamkeitsmaß teilweise aus dem Testen von SW-Systemen übernommen werden, musste aber teilweise für betrachtete HW/SW-Systeme angepasst werden. 28 Die Kritikalität einer Einheit drückt aus, welche Bedeutung ihrem Fehlverhalten beigemessen wird. 32

44 Produkt-Verifikation verteilter Steuerungssysteme 3 Produkt-Verifikation verteilter Steuerungssysteme In diesem Kapitel wird beschrieben, wie mit Methoden aus dem implementationsorientierten Testen (White Box Testen) eine automatisierte, spezifikationsbasierte Verifikation von verteilten eingebetteten Systemen durchgeführt werden kann. Dazu musste eine Software (Event Designer) entwickelt werden, die sowohl eine einfache Eingabe der testrelevanten Informationen aus einer Spezifikation erlaubt, als auch die Möglichkeit bietet, entsprechende neue Testalgorithmen zu implementieren. 3.1 Auswahl geeigneter Testverfahren Die in Kapitel beschriebenen Testmethoden können wie folgt gegenübergestellt werden: Implementierungsorientiertes Testen: + Theoretisch ist die Vollständigkeit der Testdaten möglich, da der gesamte Zustandsraum bekannt ist + Auch ohne einer Spezifikation ist das Testen möglich - Fehler durch nicht implementierte Teile können nur zufällig entdeckt werden. - I.d.R. müssen Testdaten neu ermittelt werden, wenn eine Änderung der Implementierung durchgeführt wird - Erneutes Durchführen aller Tests erforderlich bei Änderung der Implementierung Spezifikationsorientiertes Testen: + Nicht implementierte, aber spezifizierte Teile können entdeckt werden. + I.d.R. sind keine neuen Testdaten erforderlich bei Änderung der Implementierung. + Tests sind unabhängig von Art der Realisierung - Eine vollständige Testdatengenerierung kann nicht garantiert werden, da der Gesamtzustandsraum nicht abhängig von der Implementierung ist - Qualität der Testdaten hängt entscheidend von der Qualität der Spezifikation ab. - Erneutes Durchführen aller Tests erforderlich bei Änderung der Implementierung Ein wesentlicher Vorteil des spezifikationsorientierten Testens ist, dass die Tests unabhängig von der Art der Realisierung sind. Dies ist für Steuergeräte besonders wichtig, da es viele unterschiedliche Realisierungsarten gibt (SPS, Mikrocontroller, FGPA, etc.). Die Ansätze für die verschiedenartigen Realisierungsarten sind unterschiedlich weit fortgeschritten. Der rein spezifikationsorientierte Ansatz erlaubt eine sehr hohe Flexibilität des Testens, da neben den Steuergeräten auch intelligente Sensoren und Aktoren getestet werden können, die immer mehr Verbreitung finden. 33

45 Produkt-Verifikation verteilter Steuerungssysteme Beim implementierungsorientierten Testen werden weiterhin nur die Steueralgorithmen getestet, aber nicht die Hardware. Fehler, die durch Hardware auftreten, können somit nicht entdeckt werden. Die hier beschriebene Vorgehensweise strebt an, mit den entwickelten Algorithmen Testdaten zu generieren, die sowohl Softwarefehler findet, als auch Fehler, die in der Integrationsphase durch die Zusammenschaltung der Steuerungssoftware mit der Zielhardware, begründet liegen. Da dazu sowohl implementationsorientierte als auch spezifikationsbasierte Grundlagen zu Einsatz kommen, wird hier von einer hybriden Vorgehensweise gesprochen. 3.2 Pfadorientierte Stimuligenerierung In der Phase der Produktverifikation, also den Tests von Eigenschaften am realen Gerät gegen seine Spezifikation oder technischer Dokumentation, kann eine pfadorientierte Stimuligenerierung ein Bestandteil des gesamten Verifikationsprozesses sein. Eine pfadorientierte Stimuligenerierung setzt voraus, dass zum Zeitpunkt der Tests ein Computermodell mit einer Simulation oder dem Verhalten des zu testenden Steuerungscodes vorliegt und entsprechende Algorithmen existieren, die die Testfälle extrahieren, bzw. eine Testfallspezifikation erstellen. Im Rahmen dieser Arbeit ist dazu eigens eine Modellierungssoftware entstanden, die diese Möglichkeiten bietet. Es ist möglich, informelle Spezifikationen und technische Dokumentationen in ein semiformales Modell (EventDesiger-Modell) zu überführen, um anschließend Testfallspezifikationen zu generieren. Das geschieht mit der Hilfe von implementierten Algorithmen, die im Wesentlichen auf den, bereits in Kapitel 2.3 beschriebenen Testmethoden basieren. Zur Umsetzung dieser hybriden Vorgehensweise, also einer Nutzung implementationsoriertierter Methoden in einer Anwendung von spezifikationsorientierten Tests, bedarf es einer Software, die eine computergestützte Verarbeitung der Szenarien zulässt. Für eine Nachbildung des zu verifizierenden Steuerungsverhaltens wird hier eine Rekonstruktion der Spezifikation mit der Hilfe von gerichteten Graphen verwendet. Eine gängige Anwendung dieser Technik findet sich in der Softwaretechnik wieder, dem Re-Engeneering, mit der Hilfe von so genannten Aktivitätsdiagrammen. Sie bilden entgegen der herkömmlichen Zustandsdiagramme, die Zustandsänderungen ab. Dieses Modellierungsprinzip ist auf die Graphentheorie zurückzuführen. In Kapitel wird deshalb kurz auf diese Grundlage eingegangen und eine Gegenüberstellung der hier verwendeten pfadorientierten Testdatengenerierung zu bekannten graphentheoretischer Anwendungen gezeigt. Eine wesentliche Eigenschaft eingebetteter Systeme ist u.a. die Echtzeitfähigkeit, also die Fähigkeit, in einer kalkulierbaren Zeit eine Systemantwort zu liefern. Entsprechend wichtig ist es, die Zeitbehaftung solcher Steuerungen mit in die Verifikation einzubeziehen. Dazu muss sie auch modelltechnisch verwertbar als Datensatz abgelegt werden. Eine Möglichkeit bieten so genannte Timed-Petri-Nets. Während 34

46 Produkt-Verifikation verteilter Steuerungssysteme Standard Petrinetze durch einen gerichteten, aber zeitlosen Graphen dargestellt werden, wird bei Timed-Petri-Nets die Zeit an die Transitionen gebunden. Kapitel führt in dieses Thema ein. Zur Umsetzung der, in dieser Arbeit hergeleiteten Testalgorithmen ist eine Modellierungsumgebung nötig, die es erlaubt, mit einem angemessenen Aufwand sämtliche, testrelevante Informationen aus einer textuellen Spezifikation modelltechnisch abzulegen. Kapitel ordnet Verhaltensmodelle grundsätzlich ein und beschreibt kurz die wichtigsten Entwurfprinzipien von Systemmodellen Theoretische Grundlagen zur entwickelten Methode Graphentheorie Definition: Ein Graph ist eine Menge von Knoten (oder Ecken) und Kanten. Knoten sind einfache Objekte, die Namen und andere Eigenschaften haben können; eine Kante ist eine Verbindung zwischen zwei Knoten. Graphen werden erstellt, indem die Knoten durch Punkte markiert werden und diese durch Linien verbunden werden. Eine wichtige Eigenschaft ist, dass Graphen grundsätzlich unabhängig von der reinen Darstellung sind. Der Kontrollflussgraph eines Programms P ist ein gerichteter Graph G= (N,E) mit 2 ausgezeichneten Knoten n_start, n_final Ein Knoten stellt Anweisungen (oder strikt sequenzielle Anweisungsfolgen dar). Eine Kante aus der Menge der Kanten E NxN beschreibt den Kontrollfluss zwischen zwei Anweisungen. Eine Kante aus E wird auch Zweig genannt. Die beiden ausgezeichneten Knoten stellen die Anfangs- und Endeanweisung eines Programms dar. Unter einem Block wird eine nichtleere Folge von Knoten verstanden, die ausschließlich durch den ersten Knoten betreten werden kann, die - sobald der erste Knoten durchlaufen wird - in der vorgegebenen Reihenfolge deterministisch genau einmal durchlaufen wird, die bezüglich der ersten beiden Eigenschaften maximal ist. Pfad/vollständiger Weg Folge von Knoten und Kanten, die mit dem Startknoten beginnt und mit dem Endeknoten endet Wege (T,P) Ist die Menge der vollständigen, endlichen Wege w des Kontrollflussgraphen (des Programms P), für die es ein Testdatum t aus der Menge der Testdaten T gibt, das den Weg w ausführt. Ein Zyklus ist ein Weg im Kontrollflussgraphen mit mindestens zwei Knoten, der an demselben Knoten beginnt und endet. 35

47 Produkt-Verifikation verteilter Steuerungssysteme Ein einfacher Zyklus ist ein Zyklus, bei dem alle Knoten (außer Anfangs- und Endknoten) verschieden sind. Zur Lösung graphentheoretischer Probleme werden in der Literatur [26][46] diverse Algorithmen beschrieben, die aber im Hinblick auf eine Test-Pfad-Generierung in einem gerichteten Graphen, der aus der Modellierung eines dezentralen Steuerungssystems hervorgeht, nicht geeignet sind. In diesen Algorithmen werden zumeist nur Start-, End- und gewöhnliche Knoten berücksichtigt, während in der beabsichtigten Test-Pfad-Generierung zwischen Anfangs- (Quellen) und End-Knoten (Senken), UND- und ODER-Gliedern und gewöhnlichen Knoten zu unterscheiden ist. Da weder UND- noch ODER-Glieder definiert sind, werden auch keine nebenläufigen Pfad-Strukturen im Sinne der Test-Pfad- Generierung betrachtet. Darüber hinaus erfolgt die Traversierung 29 der Graphen meist nur unidirektional von einem Start-Element aus. Oftmals wird in der Literatur zur Erläuterung der Graphentheorie und den darauf angewandten mathematischen Algorithmen, das Beispiel einer Routenplanung im Straßenverkehrsnetz angeführt. Dabei ist primär das Ziel, von einem ausgewählten Start- Ort auf dem kürzesten oder auch schnellsten Weg 30 zu einem Ziel-Ort zu gelangen. Wohingegen bei dem hier betrachteten Anwendungsfall das Ziel ist, u.a. sämtliche Start- und Endknoten eines Netzes sowie dessen Topologie zu erfassen. In Tabelle 2 ist ein Vergleich dieser beiden Anwendungsgebiete angeführt. Kriterium Anwendungsfall: Routenplanung Anwendungsfall: Test-Pfad- Generierung Anzahl der Startknoten 1 Mehrere Anzahl der Endknoten 1 Mehrere Knotentypen Start-, End- und gewöhnliche Knoten Quellen, Senken, UND- und ODER-Verknüpfungen so wie gewöhnliche Knoten Kantentypen Gewichtete Kanten In einem ersten Schritt ungewichtete Kanten, da zuerst die reine Netz-Topologie relevant ist. In weiteren Schritten werden Zeitinformationen an den Kanten notiert Traversierung Unidirektional Multidirektional Einsatzzweck Auffindung des kürzesten Pfades Auffindung eines zusammenhängenden Netzes Tabelle 1: Kriterien unterschiedlicher Graphen-Algorithmen 29 Durchschreitung, Durchwanderung 30 Je nach gewünschtem Kriterium kommen unterschiedliche Kantengewichtungen in Betracht 36

48 Produkt-Verifikation verteilter Steuerungssysteme Um einer ausreichend genauen Verhaltensmodellierung von verteilten Steuerungssystemen gerecht zu werden, müssen Nebenläufigkeiten berücksichtigt werden. Dazu steht als zentrales Element der Synchronisationsknoten zu Verfügung, welcher für die hier beschriebene Testpfad-Generierung eine bidirektionale Pfadbetrachtung erfordert. In der hier beschriebenen Methode ist die Graphentheorie ein grundlegendes Modellierungselement Timed Petri Nets Carl Adam Petri hat mit seiner Dissertation 1962 eine begriffliche Grundlage entwickelt, die reale Systeme auf einheitliche und exakte Weise in Form von Petri-Netzen beschreibt. Mit Petrinetzen können nebenläufige und parallele Systeme mit Hilfe einer grafischen Notation beschrieben und analysiert werden. Während Standard Petrinetze durch einen gerichteten, bipartiteren aber zeitlosen Graphen dargestellt werden, wird bei Timed-Petri-Nets die Zeit an die Transitionen gebunden. Die Einteilung des Zeitfortschritts kann stochastisch, d.h. zufällige Schaltdauer oder deterministisch mit einer konstanten Schaltdauer sein. Mit zeitbehafteten Petrinetzen besteht die Möglichkeit, das funktionale Verhalten eines Systems zu beschreiben und quantitativ zu analysieren. Das Schaltverhalten eines zeitbehafteten Petrinetzes (TPN) kann wie folgt angegeben werden: Wird die Transition t zum Zeitpunkt T abs PN-schaltbereit, dh. unmittelbar zuvor waren nicht alle Eingangsplätze besetzt, sie sind es aber zum Zeitpunkt T abs dann ist die Transition t im Zeitraum [T abs + s1(t), T abs + s2(t)] TPN schaltbereit, wenn die PN Schaltbereitschaft zu keinem Zeitpunkt unterbrochen und durch keinen Schaltvorgang einer im Konflikt stehenden Transition gestört wurde. Um mit der hier vorgestellten Verhaltensmodellierung ebenfalls das Zeitverhalten eines Systems berücksichtigen zu können sind, Regeln in Anlehnung an die deterministischen zeitbehafteten Petrinetze umgesetzt. 37

49 Produkt-Verifikation verteilter Steuerungssysteme Modellierung von Testmodellen: Systemmodelle Verhaltensmodelle Strukturmodelle Klassifikation von Systemmodellen Beim diskreten Systemmodell, im Unterschied zum kontinuierlichen Modell, beschränkt man die Betrachtung auf gewisse Einrastwerte des Systems. Die beobachteten Variablen oder Signale des Systems sind dann wertdiskret. Tastet man die Werte bei einem kontinuierlichen Systemmodell zu bestimmten Zeitpunkten ab, sind sie wertkontinuierlich und zeitdiskret. Abbildung 13: Einteilung von Systemmodellen Bei einem diskreten Systemmodell genügt es oft, die zeitliche Betrachtung durch eine Folgenbetrachtung zu ersetzen, wo es nur noch auf die zeitliche Reihenfolge der Einrastwerte oder Ereignisse ankommt, die nicht in zeitlich gleichen Abständen eintreffen müssen. Wird der zeitliche Ablauf berücksichtigt, so können die diskreten Werte entweder über den gesamten Verlauf (zeitkontinuierlich, ohne Abtastung) oder nur zu bestimmten Zeitpunkten (zeitdiskret, mit Abtastung) beobachtet werden. Ein zeit- und wertdiskretes Signal bezeichnet man häufig als digitales Signal. Können nur zwei diskrete Werte auftreten, handelt es sich zudem um ein binäres Signal. Die hier betrachteten Modelle können dem entsprechend zu den diskreten Systemmodellen mit Zeitbetrachtung zugeordnet werden. Entwurfsmethoden Grundsätzlich können Modelle nach dem Top-Down oder Buttom-Up-Prinzip entworfen werden. Das grundsätzliche Bottom-Up-Prinzip schreibt vor, möglichst feingranular Teilfunktionen zu entwerfen und sie dann zu einer Gesamtaufgabe zusammenzusetzen. Der Top-Down-Entwurf besteht darin, bezogen auf das hier beschriebene Anwendungsfeld, Verhaltensmodelle eines Systems schrittweise in Strukturmodelle umzusetzen und so lange zu verfeinern, bis daraus die physikalische Implementie- 38

50 Produkt-Verifikation verteilter Steuerungssysteme rung unmittelbar ersichtlich ist. Für den Entwurf von Testmodellen mit der hier beschriebenen Vorgehensweise wird eine Top-down-Dekomposition, also eine Zerlegung einer Systemfunktion in einfachere Teilfunktionen, empfohlen. Verhaltensmodelle Verhaltensmodelle beschreiben ausschließlich die funktionalen Eigenschaften eines Systems, während Strukturmodelle über die funktionalen und nicht-funktionalen Eigenschaften eines Systems und dem inneren Aufbau Auskunft geben. Häufig bestehen Strukturmodelle eines technischen Systems aus gerichteten Graphen mit Knoten- und Kantengewichten. Die Knoten entsprechen den Komponenten eines Systems und die Kanten beschreiben die Abhängigkeit zwischen den Komponenten und die Richtung des Informationsflusses. Die Strukturmodelle der Informationstechnik sind in der Praxis häufig ad hoc an den jeweiligen Anwendungsbereich angepasst Toolbasierte Methode zur Produktverifikation von verteilten Steuerungssystemen Die Methode der systematischen computergestützten Testfallspezifikation auf Basis von spezifikationsorientierten Verhaltensmodellen und Strukturinformationen verteilter Steuerungssysteme, besteht aus acht Schritten. Eine detaillierte Beschreibung der einzelnen Schritte, sowie eine industrienahe Beispielanwendung folgen anschließend. Ziel für die Testfallerstellung ist es, einen gerichteten Graphen (Wald) zu erhalten, der das spezifizierte Systemverhalten sowohl für die implementierten Steuerungsalgorithmen und die Zielhardware aufweist. Die in dem Verhaltensgraphen enthaltenen unterschiedlichen Pfade stellen die Testszenarien dar. Es ergeben sich Anforderungen für ein Tool, die wie folgt zusammengefasst werden können: Es muss die Möglichkeit bieten, sowohl mit einer gewissen Abstraktion eine Hardwareschicht (strukturelle / topologische Sicht) als auch eine Softwareschicht (logische Sicht) darzustellen, um entsprechende testverwertbare Informationen zu speichern. Die Modellierung muss ausreichend präzise für eine Testaufgabe sein, aber auch abstrakt genug, um ein komplexes System darzustellen. Zur Implementierung der hier vorgestellten Testmethoden ist ein statisches Modell ausreichend. Die Datenstruktur der Modellbildung muss mathematisch eindeutig sein. Gewählt wird dazu das Prinzip gerichteter Graphen. Ein Hierarchisierungskonzept zur Reduzierung der Komplexität ist nötig Einfache Benutzerschnittstelle, möglichst basierend auf bereits bestehenden Methoden. Schnittstellen zu bekannten Testtools und Nutzung professioneller Testapparate und Strukturen 39

51 Produkt-Verifikation verteilter Steuerungssysteme Abbildung 14: Schematische Darstellung der toolbasierten Verifikationsmethode Folgende Schritte verdeutlichen die Vorgehensweise: 1. Datenbasis - Analyse der technischen Dokumente und Erfassen für das Testen wichtiger Systeminformationen. 2. Klassifizierung - Aufstellen der relevanten Elemente und Reduzierung der Komplexität durch Modularisierung. 3. Modellierung - Aufbau eines semi-formalen Verhaltensmodells 4. Transformierung Erstellen eines gerichteten Grafen (Kontrollfluss Grafen). 5. Generierung der Testdaten (kontrollflussorientierte Äquivalenzklassenbildung): Auswahl der primären Methode zur Testdatengenerierung (path coverage / decision coverage) in Abhängigkeit der allgemeinen Teststrategie Auswahl der sekundären Methode (level of detail / power interrupt / CAN stress) in Abhängigkeit der speziellen Teststrategie (Bsp. Testen des spez. Abnormalverhaltens) 6. Automatische Testdurchführung 7. Automatische Testauswertung 8. Generierung von Test Reports 40

52 Produkt-Verifikation verteilter Steuerungssysteme Schritt 1 Datenbasis erfassen Ziel dieses Schrittes ist die Analyse der technischen Dokumente und Erfassen für das Testen wichtiger Systeminformationen. Einen ersten Überblick über das zu testende System verschafft eine Auflistung aller verwendeten Hardwarekomponenten. Hierbei wird der Spezifikation oder der technischen Dokumentation die Hardwarestruktur des Systems entnommen. Je nach Vollständigkeit der Dokumente müssen gegebenenfalls weitere Informationen von den Systemingenieuren erfragt werden. In der Regel wird allerdings in der Entwurfsphase eines verteilten Systems die Hardware- Systemstruktur definiert und in Form von technischen Zeichnungen, aus denen die hierarchische Gliederung hervorgeht, festgelegt. Bei den hier betrachteten Systemen gliedern sich einzelne Steuerungseinheiten (in der Regel Mikrocontroller) und ihre angeschlossenen Sensoren, bzw. Aktoren, im weiteren Verlauf als Module bezeichnet, zu einem Teilsystem. Geräte die keine eigene Mikrocontroller gesteuerte Logik besitzen, wie z.b. einfache Sensoren oder Aktoren werden als Komponenten bezeichnet. Alle Teilsysteme zusammen werden als Gesamtsystem bezeichnet. Für verteilte Steuerungssysteme ist die Kommunikation der Module untereinander ein zentrales Element. Sie ist ein charakteristisches Merkmal eines verteilten Systems und wird meist durch eine Feldbustechnologie, wie z.b. dem Profibus, dem Interbus oder dem CAN-Bus, realisiert. Module sind über Busse miteinander verbunden und kommunizieren untereinander. Daher ist in der Regel mindestens ein Controller je Modul für den Nachrichtenaustausch notwendig. Die Kommunikation des für diese Arbeit zur Verfügung stehenden Systems basiert auf der CAN-Bus Technologie. Die hier vorgeschlagene Vorgehensweise sowie die gewählte Strukturhierarchie, richtet sich deshalb in erster Linie an dieser Netzwerktopologie 31. In diesem ersten Schritt gilt es also, das System entsprechend einzuteilen und die Systemgrenzen klar zu definieren. Eine Funktionsbeschreibung lässt sich, auf der Grundlage ihrer Formalität, grob in drei Klassen einteilen: Informelle, semiformale und formale Spezifikationen. Semiformale Verfahren haben eine definierte, eindeutige Syntax. Das können grafische Notationen mit präzisen Regeln zur Erstellung der Diagramme (z.b. Kontrollflüsse) oder textuelle Notationen mit ähnlichen Regeln sein. Informelle Techniken haben kein komplettes Regelwerk zur Erstellung von Modellen. Die Ausdrucksmöglichkeiten werden kaum eingeschränkt. Abbildung 15 veranschaulicht den Zusammenhang zwischen dem Grad der Formalität und der Produktentwicklungszeit anschaulich. 31 Unter einer Netzwerk-Topologie versteht man die Anordnung von Netzwerk-Stationen und Leitungen 41

53 Produkt-Verifikation verteilter Steuerungssysteme Abbildung 15: Spezifikationsverfahren 32 Bezeichnet man ein fertiges Produkt, mit seinem vollständig implementierten Steuerungscode und endgültiger Hardware als 100% formal definiert, kann eine formale Spezifikation in den frühen Produktentwicklungsphasen schnell einen hohen Formalitätsgrad erreichen. Rein informelle Spezifikationen erfordern innerhalb der Entwicklerteams u.a. einen erhöhten Kommunikationsaufwand, was sich zu Anfang der Entwicklung negativ auswirkt. Erst in der späten Phase, für gewöhnlich zur Zeit der Programmierung bzw. Implementierung, ist der Formalitätsgrad hoch. Betrachtet man im V-Modell die Phasen der Produktverifikation, so erkennt man, dass die exekutive Verifikation erst mit der Fertigstellung der Produkte beginnt. Für eine iterative Produktentwicklung, bei der z.b. zuerst eine Simulation, dann ein Prototyp und anschließend weitere Varianten mit zunehmenden Fertigstellungsgrad erstellt werden, beginnt eine Produktverifikation im Entwicklungsprozess entsprechend früher. Zu diesem Zeitpunkt liegt eine vollständige Spezifikation, entweder nicht formal, teilweise formal oder z.b. als Computermodell vollständig formal vor, und kann entsprechend für den Entwurf eines Verhaltensmodells zur Verifikation genutzt werden. Im Sinne einer Fehlervermeidung bzw. Kostenreduzierung muss möglichst früh im Entwicklungsprozess eine Validierungs- und Verifikationsstrategie festgelegt werden. So werden im Idealfall bereits zur Spezifikationsphase Testanforderungen festgelegt. Das Wissen darüber kann aus der Erfahrung der Designer mit anderen Projekten kommen oder systematisch ermittelt werden. In der Regel wird dieser Schritt mehr oder weniger streng an einen Standard gebunden und hat seine konkrete Ausprägung in einem System Validierungs- und Verifikationsplan. Damit ist eine strategische Grundlage festgelegt, die im weiteren Verlauf sukzessive, bis hin zu konkreten Testfällen verfeinert wird. 32 Vgl. hierzu software-engineering, offizielle Homepage des Frauenhofer-Instituts für Experimentelles Software Engineering, [W8] 42

54 Produkt-Verifikation verteilter Steuerungssysteme Das hier entwickelte Werkzeug bietet die Möglichkeit, bereits in den frühen Phasen der Produktverifikation, ggf. zur Zeit des Entwurfs, ein System grob granular, also entsprechend dem eingangs beschriebenen Top-Down-Prinzip, modelltechnisch abzulegen. Am Beispiel eines verteilten Steuerungssystems können Strukturinformationen, wie Art und Anzahl intelligenter Komponenten und die Netzwerktopologie sowie eine grobe Einteilung der Systemfunktionen modelliert werden. Diese Darstellung kann bereits während der Entwicklungsphase ein unterstützendes Hilfsmittel für die Systemdesigner im Rahmen der Design Verifikation sein. Spätestens mit den konkreten Testanforderungen ist mit den zur Verfügung stehenden Informationen, ein ausreichend genaues Modell für die Testaufgabe zu erstellen. Expertenwissen Neben den in Prosa geschriebenen Dokumenten, ist eine wichtige Quelle das Wissen, bzw. die Erfahrung der Testexperten. So hat sich gezeigt, dass während der Produktverifikation des Airbus A380 Kabinensystems erfahrene Testexperten mit einer dynamischen Fehlererwartungs-Testmethode oftmals schneller Fehler aufgedeckt haben als verwendete automatische Verfahren. Kapitel beschreibt diese Testmethode. Es gibt bereits Methoden, Expertenwissen computergestützt abzulegen um es für artverwandte Anwendungen abrufbar zu haben. So genannte wissensbasierte Systeme werden bereits erfolgreich z.b. zur Erstellung von medizinischen Prognosen eingesetzt. Im technischen Bereich hat die damit verwandte Fuzzy Logic eine gewisse Verbreitung gefunden. Das Nutzen des Expertenwissens liegt daher nahe und dient zusätzlich als Datenquelle für die Verifikation mit der hier vorgestellten Methode. Messungen Nicht alle physikalische Zusammenhänge können mit einem angemessenen Aufwand durch mathematische Modelle beschrieben werden. Oft dienen während der Entwurfsphase Simulationen der Steuerstrecke als Grundlage für eine Spezifikation der Steueralgorithmen. Theoretisch können sie auch für die Erstellung von Verfikationsmodellen verwendet werden, doch die Diversivität von verwendeten Simulationswerkzeugen würde hier den Aufwand für nötige Schnittstellenfunktionen nicht rechtfertigen. Die hier entwickelte Methode mit der programmtechnischen Umsetzung in Form von EventDesigner dient in erster Linie dem ausführenden Tester als unterstützendes Werkzeug. In der Regel arbeiten Testexperten im direkten, hardwarenahen Umfeld zur Steuerstrecke. Dazu werden für die Verifikation Testaufbauten, bzw. ganze Testrigs des entwickelten Systems mit realer physikalischer Steuerstrecke aufgebaut. Es können daher aufwendig zu simulierende physikalische Zusammenhänge meist relativ einfach an der realen Anlage gemessen werden. 43

55 Produkt-Verifikation verteilter Steuerungssysteme Beispiel: Eine Toilettensteuerung eines Passagierflugzeugs mit einer Betriebsspannung von 17VDC bis 40VDC verfährt ein Vakuumventil nach Anforderung, entsprechend der, in der Spezifikation gezeigten Sequenz. Zwei diskrete Endlagenschalter registrieren die Positionen auf und zu. Eine Testaufgabe im Rahmen dieses Beispiels kann sein, dass zu den Motorlaufzeiten zusätzliche Stimuli, wie z.b. Stromunterbrechungen aufgeschaltet werden sollen, die ein spezifiziertes Abnormalverhalten testen. Die Motor Verfahrzeit ist in diesem Beispiel u.a. von der Betriebsspannung und ggf. von der momentanen Druckdifferenz abhängig. Eine Simulation dieser Einflüsse scheint aufwendig und eine einfache Messung mit den Extremwerten (Grenzwerten) dieser physikalischen Parameter ist schnell durchgeführt. Diese Messungen sind relativ einfach mit der, im weiteren Verlauf beschriebene Sprache in einem Verhaltensmodell zu hinterlegen. Messungen an einer realen Anlage, bzw. am Testaufbau sind daher eine weitere wichtige Informationsquelle für die Modellierung. Abbildung 16: Informationsquellen zur Modellbildung Zusammenfassend können die in Abbildung 16 genannten Quellen zur Informationsgewinnung und damit zur Modellierung mit Event Designer genannt werden. Damit verdeutlicht sich auch der unterstützende Charakter des Werkzeugs für den Tester Schritt 2 Klassifizierung der Elemente Aufstellen der relevanten Elemente und Reduzierung der Komplexität Reale verteilte Steuerungssysteme bestehen aus einer Vielzahl unterschiedlicher und oft nicht standardisierter Bauteile. So werden z.b. unterschiedlichste elektrische Leitungen für verschiedene Leistungsklassen (TTL, 12VDC, 28VDC, 110VAC, 230VAC), bis hin zur Verwendung in Kommunikationsnetzen, verwendet. Um nur die für die Aufgabe benötigten Informationen aus dem System zu extrahieren und sie 44

56 Produkt-Verifikation verteilter Steuerungssysteme modelltechnisch abzulegen, muss eine Vereinfachung, bzw. eine Klassifikation der Bauteile vorgenommen werden. Die im weiteren Verlauf aufgeführten Struktur- und Sprachelemente sind an bereits bestehenden Tools und Methoden angelehnt und haben keinen Anspruch auf Allgemeingültigkeit oder Vollständigkeit. Sie dienen hier als praxisbewährte Ansammlung nötiger Elemente zur Benutzerinteraktion, um die hier erarbeitete Testmethodik zu verwenden. Weitere Elemente können zur Spezialisierung oder zur Verlagerung der Methodik in einen anderen Anwendungsbereich hinzugefügt werden. Die Strukturelemente, Abbildung 36 zeigt ein Beispiel, dienen zur Modellierung der Hardwarestruktur des zu testenden Systems. Diese veranschaulicht dem Tester das System mit seinen realen Schnittstellen und Komponenten. Eine Klassifizierung realer Komponenten stellt sicher, dass nur testrelevante Informationen modelliert werden. Zu den Strukturelementen wird das Element Unit zugeordnet, sie steht für jede intelligente Komponente (Mikrocontroller gesteuerte Komponente) im System. In der Strukturansicht sind ebenfalls Ports, also die Schnittstellen der Komponenten wie bspw. digitale Ein- oder Ausgänge einer Mikrocontrollersteuerung zu definieren. An diesen Stellen werden die physikalischen Größen logischen Werten zugeordnet. Am Beispiel eines Spannungssignals an einem digitalen Eingang einer Steuerung, kann die Zuordnung wie folgt definiert sein: Eingangsspannung Definition der Wertäquivalenzklassen 0V 3V NotValid_lowerBound - Nicht_gültige_untere_Grenze 3V 10V False - Falsch 10V 32V True - Wahr 32V 40V NotValid_upperBound - Nicht_gültige_obere_Grenze Es ergeben sich durch die Definition der physikalischen Größen weitere Äquivalenzklassen, die mit entsprechendem Testequipment auch stimuliert werden können. Die Verbindungen, also Transitionen im Strukturmodell, stehen für eine physikalische Verbindung. Dies sind für gewöhnlich die Verdrahtungen der Aktoren und Sensoren, bzw. der Datenbusse. Hier werden die Transitionen nach Massenfluss, Energiefluss und Informationsfluss klassifiziert. Da hier der Fokus auf eine Verhaltensbeschreibung der internen Steuerungslogiken liegt, sind die Transitionen im weiteren Verlauf den Sprachelementen zugeordnet. Eine Erweiterung ist die Möglichkeit, speziell mit den Transitionen das Zeitverhalten modelltechnisch abzubilden. Das Basissprachelement ist die Action, sie bildet eine Zustandsänderung des Systems ab. Weitere Sprachelemente sind der State mit den speziellen Ausprägungen als Start-Node und End-Node, das Send-Event und Receive-Event, so wie zur Hierarchisierung die Activity. Mit den Verknüpfungselementen Decision-Node, Merge-Node, Fork-Node und Join-Node wird der Kontrollfluss, also die logische Verknüpfung unter den Pfaden, aufgebaut. Im weiteren Verlauf werden diese Elemente näher erklärt. 45

57 Produkt-Verifikation verteilter Steuerungssysteme Basiselemente der entwickelten Sprache Sprachelement: Zustand (state) Das hier verwendete Sprachelement ist der Zustand im klassischen Sinn. Er repräsentiert, bezogen auf einen internal state Kontrollflusspfad, ein konstantes Verhalten der Steuerung. Für die Modellierung ist dieses Element in erster Linie zur Verbesserung der Lesbarkeit bzw. des Verständnisses einzusetzen. Für die Testdatengenerierung hat dieses Element z.z. keine Bedeutung. Sprachelement: Aktion (action) Eine Aktion ist das elementare Sprachelement in der Modellierung von Verhaltensmodellen. Sie charakterisiert port = port = eine Zustandsänderung an einem diskreten Ein- oder Ausgang und definiert damit eine Signaländerung zu einem bestimmten Zeitpunkt. Parameter: Port, Signaländerung bus : message : bit name bus : message : bit name Sprachelement: Sende Aktion / Empfangs Aktion (send event / receive event) Zur Modellierung von Kommunikationsereignissen werden die Sprachelemente send e- vent und receive event bereitgestellt. Bezogen auf die Modellierungsregeln, entsprechen sie einer normalen Aktion. Mit der Angabe des Datenbusses (Bsp. CAN#1), der CAN-ID und des betreffenden Bits können spezifizierte Nachrichten modelliert werden. Parameter: Beschreibung, Bus, Message ID, Message Bit, Wert, Name des Bit Abbildung 17 zeigt den Zusammenhang zwischen den Sprachelementen State, bzw. Action und einem Signalverlauf mit der Angabe gültiger und ungültiger Äquivalenzklassen. Angegeben sind auch die Signaleigenschaften bzgl. der Möglichkeit, es zu stimulieren und/oder zu messen. Diese Information ist eng mit dem Testaufbau und dem dazu benötigten Testequipment verknüpft. 46

58 Produkt-Verifikation verteilter Steuerungssysteme Abbildung 17: Sprachelemente: State und Action und deren Eigenschaften Sprachelement: Transition In klassischen Zustandsdiagrammen bilden Transitionen die Zustandsübergänge ab. In Zustandsübergangsdiagrammen, wie dem hier zugrunde liegenden Prinzip der Aktivitätsdiagramme, werden diese durch die Aktionen abgebildet. Transitionen verbinden diese und stehen daher für ein konstantes Verhalten. information energie mass [ t_min > t > t_max] Wesentlich für die hier entwickelte Sprache ist, eine Reduzierung der Komplexität des realen Systems herbeizuführen, ohne das wichtige Informationen verloren gehen. Um eine Klassifizierung sämtlicher Transportwege eines technischen Systems vorzunehmen, wird eine aus der Verfahrenstechnik bekannte Vereinfachung entliehen. Dazu werden verschiedene Typen von Transitionen wie folgt definiert. Eine Massenflusstransition (mass flow) repräsentiert alle Stoff- und Kraftflüsse, eine Energieflusstransition alle elektrischen Leistungssignale und die Informationsflusstransition sämtliche logischen Signale. Um allerdings zeitbehaftete eingebettete Systeme ausreichend gut modelltechnisch abzulegen, müssen auch spezifizierte Zeitinformationen mit modelliert werden. Dazu 47

59 Produkt-Verifikation verteilter Steuerungssysteme werden hier die timed transitions eingeführt. Gemäß dem Tokendenken wandert eine Marke nicht unendlich schnell über eine Transition, sondern erhält mit der Angabe von zeitlichen Äquivalenzklassen eine gewisse Geschwindigkeit. Abbildung 37 zeigt die Definition der Transitionen im Tool EventDesigner. Parameter: Beschreibung, Zeit Sprachelemente: Entscheidung, Aufspaltung, Zusammenführung, Synchronisation Die vier Verknüpfungselemente sind die Basis für eine Modellierung der Steuerungslogik. Abbildung 18: Auflistung der Verknüpfungselemente Das Sprachelement Decision Node stellt die klassische Exklusiv-ODER- Verknüpfung dar. Diese kann verwendet werden, wenn aus der zu formalisierenden Spezifikation hervorgeht, dass alternative Programmausführungspfade vorliegen. Bsp.: Nach Erfassen des Sensorsignals S1 soll der Aktor A1 angesteuert werden. Liegt das Signal S1 länger als 2 Sekunden an, wird der Aktor A2 angesteuert. 48

60 Produkt-Verifikation verteilter Steuerungssysteme Abbildung 19: Beispiel eines Decision Nodes Hier wird ein Erkennen der positiven Flanke des Sensorsignals S1 mit der Hilfe des Sprachelements Aktion vor dem Decision Node eingefügt und die beiden Fälle (Zeit < 2s und Zeit >= 2s), sowie Aktionen (Aktoransteuerung) mit fallenden Flanken, an den ausgehenden Transitionen des Entscheidungsknoten angefügt. Es wird also an jedem ausgehenden Pfad des Entscheidungsknoten eine Bedingung geknüpft, die den weiteren Verlauf im Graphen bestimmt. Mit diesem Sprachelement werden daher direkt die Hauptpfade im Verhaltensmodell und damit auch die Haupttestpfade für die Testdatengenerierung festgelegt. Für den Fall, dass unterschiedliche Pfade zu einem Pfad ohne Synchronisation der Signale zusammengefügt werden müssen, kann das Element Merge Node genutzt werden. Sämtliche, in das Element eingehende Pfade sind ODER-Verknüpft. Die Zusammenführung wird beispielsweise verwendet, wenn auf einen Ausgang mehrere unabhängige Steuerungsalgorithmen zugreifen. Bsp.: Funktion Wartung Im Wartungsfall wird das Ventil (A1) für 2s angesteuert.... Funktion Spülzyklus Nach Erkennung des Sensorsignals S1 soll das Ventil (A1) angesteuert werden. Pfad 1 Pfad 2 Fkt: Maintenance Fkt: Flush Cycle X A1 = Abbildung 20: Beispiel eines Merge Nodes 49

61 Produkt-Verifikation verteilter Steuerungssysteme Geht aus einer Spezifikation hervor, dass eine parallele Verarbeitung mehrerer Signale vorliegt, wird das Element Fork Node verwendet. Unter parallele Verarbeitung wird in diesem Zusammenhang verstanden, dass aufgrund einer Aktion verschiedene parallele Pfade im Graphen weiterführen. Liegt eine Marke am Eingang des Elements vor, wird auf allen ausgehenden Pfaden eine Marke erzeugt. Bsp.: Wird Sensor S1 betätigt, wird nach 2s Aktor 1 (A1) und nach 3s Aktor 2 (A2) geschaltet. S1 = t = 2s t = 3s A1 = A2 = Abbildung 21: Beispiel eines Fork Nodes Um mit der Hilfe der Modellierungssprache eine Synchronisation verschiedener Signale zu realisieren, wird der Join Node verwendet. Dem Sinn nach muss an allen eingehenden Kanten eine Marke anliegen, damit auf der ausgehenden Seite eine Marke erzeugt wird. In dem hier betrachteten technischen Umfeld bedeutet das, dass eine UND-Verknüpfung der eingehenden Signale vorliegt. Bsp.: Wenn das System im Zustand In Flight ist und der Sensor S1 betätigt wird, dann schaltet der Aktor A1 nach 2s. InFlight = true S1 = t = 2s A1 = Abbildung 22: Beispiel eines Join Nodes Mit den hier genannten einfachen Verknüpfungselementen kann ein großer Teil der spezifizierten Funktionen typischer Steuerungssysteme modelliert werden. Für sehr 50

62 Produkt-Verifikation verteilter Steuerungssysteme komplexe Verknüpfungen würde sich unter Umständen eine Darstellung als Verknüpfungstabelle eignen. Sprachelement: Aktivität (activity) Die Aktivität dient zur Strukturierung (Hierarchisierung) des Modells. Umfangreiche Verhaltensmodelle können in kleinere und übersichtlichere Teile Func1 gegliedert werden, ähnlich wie bei der Verschachtelung von Programmen in Unterprogramme (Funktionen). Modellierte Teile können (und sollten) in Prosa beschrieben werden, um eine maximale Transparenz für den Benutzer zu ermöglichen. Ggf. können auch zugehörige Abschnitte der geschriebenen Spezifikationen mit in die Beschreibung aufgenommen werden. Parameter: Beschreibung Sprachelement: Startzustand, Endzustand (start node, end node) In Kontrollflussstrukturen müssen eindeutige Start- und Endzustände angegeben sein, um als Datenbasis einen gerichteten Graphen zu erhalten. Sie bilden also die Quelle und die Senke eines Kontrollflusses. Parameter: Beschreibung Strukturelement: Gerät (unit) Zur Modellierung der Komponenten eines eingebetteten Systems steht das Strukturelement MC Unit zur Verfügung. So können beispielsweise für Mikrocontrollersteuerungen, Sensoren und Aktoren separate Verhaltensbeschreibungen vorgenommen werden. Soll das Verhalten einer Steuerstrecke modelltechnisch abgelegt werden, kann ebenfalls das Strukturelement Unit genutzt werden. Parameter: Beschreibung Strukturelement: Port Das Element Port dient zur Definition der diskreten (analogen) Eingänge und Ausgänge eines Gerätes. Im Falle einer Steuereinheit können das die Eingänge der Sensoren und Ausgänge für die power out#1 Aktoren sein. Es wird festgelegt, welcher physikalische Wert (Bsp. Spannung) welchem logischen Signal im Modell entspricht. Zudem können weitere physikalische Grenzen bzgl. des angelegten Signals angegeben werden, um sie im Rahmen der MC in#1 OUT_1 IN_1 OUT2 IN_2 OUT_3 IN_3 OUT_4 IN_4 Power 28VDC Zuordnung der logischen Signale zu den physikalischen Größen Bsp.: 0V-3V := FALSE 3V-17V := NOT VALID 17V-33V := TRUE 51

63 Produkt-Verifikation verteilter Steuerungssysteme Testdatengenerierung als zusätzliche Äquivalenzklassen zu nutzen. Für gewöhnlich werden bei diskreten Ports die maximal zulässige Spannung und Stromstärke, so wie die maximale Frequenz spezifiziert. Parameter: Beschreibung, Zuordnung HW SW Schritt 3 Modellierung Überführen informeller Spezifikationen in semiformale Modelle Während der letzte Abschnitt die Frage beantwortet, mit welchen Mitteln eine Formalisierung des realen Systems vorgenommen werden kann, wird hier anhand von Beispielen konkret gezeigt, wie eine in Textform geschriebene Funktion modelliert wird. Diese sind teilweise dem Industriebeispiel aus Kapitel 4 entnommen. Letztendlich obliegt es dem Testexperten, ein Verifikationsmodell entsprechend der geforderten Testaufgabe zu modellieren und auch die zur Verfügung stehenden Spezifikationen müssen nicht den hier verwendeten entsprechen. Die nachfolgenden Schritte sind deshalb als Empfehlung zu sehen. 1. Hierarchisierung der Steuerungsfunktionen und definieren der Activities 2. Ein- und Ausgänge aus den Spezifikationen ermitteln und definieren von Aktionen und Zuständen 3. Extrahieren charakteristischer Zeitintervalle, sowie weiterer physikalischer Ä- quivalenzklassen 4. Formalisierung Konstruktion der Kontrollflussgraphen Hierarchisierung der Steuerungsfunktionen und Definition der Activities Wie bereits in Abschnitt beschrieben, wird hier eine Top-Down-Modellierung empfohlen. Daher ist der erste Schritt eine Analyse der zur Verfügung stehenden Dokumente bzgl. der Struktur. Bezogen auf ein Steuergerät muss untersucht werden, welche Hauptfunktionen und welche Nebenfunktionen spezifiziert sind und vor allem, wie sie verschachtelt sind. Eine eindeutige Einteilung kann unter Umständen aber nicht immer ermittelt werden, da hier ein sog. Re-Engeneering durchgeführt wird und die genaue Implementierung entsprechend dem Black-Box-Prinzip unbekannt ist. Eine Möglichkeit einer Klassifizierung von Funktionen aus dieser Domäne besteht darin, sie nach Art der Aufgaben bzw. Funktionen zu gliedern. So können sie beispielsweise nach den Typen Eingabefunktion, Versorgungsfunktion, Ansteuerfunktion, Kommunikationsfunktion und Verarbeitungsfunktion unterteilt werden und dann im Modell entsprechend in eigenen Aktivitäten abgelegt werden. Eine genaue Strukturierung obliegt letztendlich dem Benutzer und wird von Anwendung zu Anwendung unterschiedlich sein. Aktivitäten beinhalten eine Befehlabfolge, bestehen gewöhnlich aus mindestens zwei Aktionen und sind in der Anzahl ihrer integrierten Sprachelemente nicht begrenzt. Sie 52

64 Produkt-Verifikation verteilter Steuerungssysteme können weitere Aktivitäten aufrufen und eine Struktur aus mehreren Aktivitätsebenen besitzen. Um die Lesbarkeit des Modells zu steigern, sollte die Namensgebung der Aktivitäten entsprechend der spezifizierten Funktion vorgenommen werden. Ein- und Ausgänge aus den Spezifikationen ermitteln und Definieren von Aktionen und Zuständen Die Ermittlung der Ein- und Ausgänge und der inneren Zustände der spezifizierten Funktionen bilden einen wichtigen Teil der Modellierung. Bei der weiteren Analyse der Spezifikationen werden im zweiten Schritt alle eingehenden und ausgehenden Signale ermittelt und benannt. Zuerst werden alle Signale einer Steuerung, die über Schnittstellen physikalisch nach außen geführt sind, definiert. Diese externen Signale werden mit dem Sprachelement Port modelliert. Hier wird dem Signal ein eindeutiger Name, sowie den Äquivalenzklassen gültige und ungültige Wertebereiche zugeordnet. Dieses Signal ist damit als potentieller Stimulus definiert und kann später innerhalb eines Graphen mit Zeit- und Wertinformationen an eine Aktion gebunden werden. Eine Aktion ist definiert als eine Signaländerung zu einem bestimmten Zeitpunkt und mit der logischen Verknüpfung verschiedener Aktionen wird das Verhalten einer Steuerung modelliert. Das heißt, Aktionen beinhalten keine Befehlabfolge und bestehen aus nur einem Vorgang (Signalwechsel). Ein Beispiel für eine Aktion wäre in dem vorliegenden Fall die Ansteuerung eines Aktors (z.b. digitaler Ausgang), oder eines Sensorsignals (z.b. digitaler Eingang). Auch hier gilt es, den Signalen signifikante Namen zu geben. An dieser Stelle sei darauf hingewiesen, dass bereits mit der bloßen Definition der externen Ports, potentiell die Algorithmen zur datenbereichsbezogenen Stimuligenerierung zur Generierung von Treiberdateien, genutzt werden können. Da dabei auf die Kenntnis der inneren Struktur verzichtet wird, ist auch ein Kontrollflussgraph nicht nötig. Zur besseren Lesbarkeit eines Modells trägt auch die Verwendung des Sprachelements inner Zustand bei. Da diese weder direkt beobachtbar noch direkt stimulierbar sind, werden sie zur Generierung nicht herangezogen. In der Regel sind sie einer Spezifikation nicht direkt zu entnehmen und auch deren reale Existenz in Form eines Programmteils ist oft spekulativ. Allerdings werden in Funktionsbeschreibungen öfters Zeitspannen beschrieben, in der das Verhalten einer Steuerung als konstant angesehen wird. Diese Zeitspannen können mithilfe des Elements innerer Zustand definiert werden. Als Beispiel sei an dieser Stelle die Steuerung einer Verkehrsampel genannt. Die Dauer der einzelnen Leuchtphasen können den Zuständen und die Zeitpunkte der Leuchtsignalwechsel den Aktionen entsprechen. 53

65 Produkt-Verifikation verteilter Steuerungssysteme Extrahieren charakteristischer Zeitintervalle und weitere physikalischer Äquivalenzklassen Für die Verhaltensmodellierung ist eine genaue Definition charakteristischer Zeitintervalle nötig. Hierzu muss eine Spezifikation auf alle vorkommenden Zeiten, bzw. Zeitintervalle untersucht werden, um sie dann im Sprachelement Transition zu hinterlegen. Sie dienen als Basis für die spätere Einordnung der Äquivalenzklassen. Normalerweise beschreiben Sequenzdiagramme mit grafischer Notation den Zeitverlauf von Signalen, oder sie stehen mit in der Funktionsbeschreibung. Als Beispiel dazu dient folgender Auszug aus einer Spezifikation: Function X-1: During idle time, the MPI shall detect Flush Switch closure within 50ms after the Flush Switch signal becomes active. Function X-1 I The MPI shall set (1) bit Flush switch status when Flush switch closure is detected. Reset (0) otherwise. Function X-1 II The Flush Switch signal must be deactivated and reactivated again before detecting another Flush Switch closure. Deactivation of the Flush Switch shall be detected within 200 ms after release of the switch. Function X-1 III An active Flush Switch signal shall be ignored during a flush cycle. The flush switch signal shall be inhibited for 1 s after the completion of a flush cycle. An active Flush Switch signal shall not cause consecutive Flush Requests. Function X-1 IV Continuously active flush signal for longer than 3 minutes shall set (1) Flush Switch Failure and shall not cause more than one Flush Request (no consecutive Flush Requests are allowed). Die markierten Stellen sind für die Testdatenerzeugung relevante Zeiten. Es können folgende charakteristische Zeitintervalle entnommen werden: closure detection within 50 ms after flush switch active active flush switch for more than 3 minutes flush switch failure Demnach setzt sich die Äquivalenzklasse aus drei Teilen zusammen: ungültig < 50ms <= gültig <= 180s < gültig mit Fehlermeldung Mit den entsprechenden Eingabedaten: 50 <= flush switch closure detection <= < ignore flush switch signal < < flush switch failure < max 54

66 Produkt-Verifikation verteilter Steuerungssysteme Falls in der Spezifikation Zeittafeln existieren, vereinfacht sich das Extrahieren charakteristischer Zeitpunkte oder Zeitintervalle. Als Beispiel dafür dient folgender Auszug aus einer Spezifikation mit zusätzlicher Zeittafel: Function X-3 Rinse Valve Actuation for Main and Upper Decks MPIs /-.05 second into the flush cycle, the Rinse Valve shall be activated for a duration determined based on Weight-Threshold actuation: 1) /-.05 seconds if Weight-Threshold has been activated or; 2) /-.05 seconds if Weight-Threshold has not been activated. Abbildung 23: Beispiel einer Zeittafel Die Äquivalenzklassen für einen Testfall lassen sich einfach anhand der Zeitintervalle in einer Zeittafel, wie in Abbildung 23 dargestellt, bilden. Für die Rinse Valve Operation ergeben sich dann die zwei folgenden Äquivalenzklassen: Weight-Treshold active ungültig < 2.10s +/-.02s <= gültig <= 3s +/-.02s < ungültig Weight-Threshold inactive ungültig < 2.10s +/-.02s <= gültig <= 3s +/-.02s < ungültig Die Ermittlung kennzeichnender Zeitpunkte ist für die spätere Testfallgenerierung insofern wichtig, da diese charakteristischen Zeitpunkte die Basis für die Ermittlung der genauen Aufschaltzeitpunkte der Teststimuli im Testverlauf sind. Anhand dieser Aufschaltzeitpunkte werden die Eingabedaten für den späteren Testverlauf definiert. Je nach gewählter Teststrategie werden Aufschaltzeitpunkte um die Grenzwerte der Zeitintervalle oder nach dem einfachen Äquivalenzklassenverfahren gebildet. Auf die 55

67 Produkt-Verifikation verteilter Steuerungssysteme genaue Arbeitsweise, sowie auf den Bezug zwischen den zu wählenden Generierungsmethoden und den Teststrategien, wird in Abschnitt eingegangen. Formalisierung Konstruktion der Kontrollflussgraphen An dieser Stelle erfolgt nun die eigentliche Überführung der vorliegenden informellen Spezifikation in einen Kontrollflussgraphen mit der Hilfe der Verknüpfungselemente und den gewonnenen Zeitinformationen. Nach der Definition der Zustände und der sinnvollen Benennung der Aktivitäten sowie Aktionen und der Analyse der Zeitinformationen, werden die Elemente entsprechend der logischen Aussage verknüpft. Verwendung des Verknüpfungselements Entscheidung : Das Sprachelement Entscheidung entspricht einer EXKLUSIV-ODER-Verschaltung im herkömmlichen Sinn. Sie kommt dort zum Einsatz, wo aus einer Funktionsbeschreibung hervorgeht, dass eine oder mehrere nachfolgende Alternativen existieren. Ein eingehender Token wird genau zu einer Ausgangstransition geleitet. So besteht die Möglichkeit, unterschiedliche Pfade für verschiedene Zeitintervalle (Äquivalenzklassen) eines Signals zu konstruieren. Folgendes einfaches Beispiel verdeutlicht den Zusammenhang: Bsp.: After Flush Switch signal active less than 1s the LED shall be switched off, for a signal duration up to 20s the LED shall blink and for an activation longer than 20s a failure message shall be send. Nach einer steigenden Flanke des Signals Flush Switch, modelliert als Aktion, wird das Sprachelement Entscheidung mit drei weiterführenden Transitionen eingefügt. Diese beinhalten die drei Zeit-Äquivalenzklassen und enden jeweils in Aktionen des Signals Flush Switch mit fallenden Flanken. Für die Generierung der Testpfade bedeutet jede ausgehende Transition einer Entscheidung einen neuen Testpfad. In Abschnitt wird darauf näher eingegangen. Verwendung des Verknüpfungselements Zusammenführung Müssen für eine Aufgabe mehrere alternative Pfade per einfacher ODER- Verknüpfung zu einem Pfad vereint werden, kann das Sprachelement Zusammenführung benutzt werden. Eingangsseitig können ein oder mehrere Token anliegen, um ausgangsseitig einen Token zu erhalten. Bsp.1: Push Button A or B or C to set the output signal Z. Bsp.2: During one of the flight phases 1 to 5 an output signal 56

68 Produkt-Verifikation verteilter Steuerungssysteme Verwendung des Verknüpfungselements Aufspaltung : Soll dargestellt werden, dass ein Signal (ein Pfad) quasi gleichzeitig Einfluss auf mehrere weitere Pfade hat, muss eine Aufspaltung benutzt werden. Ein, im Eingang anliegender Token bewirkt eine Vervielfachung der Token, entsprechend der Anzahl an Ausgangstransitionen. Diese UND-Verknüpfung kann genutzt werden, um beispielsweise das quasi gleichzeitige Ansteuern mehrerer digitaler Ausgänge einer Steuerung zu modellieren. Verwendung des Verknüpfungselements Synchronisation : Das Sprachelement Synchronisation hat im gewissen Sinn eine Ventilfunktion. Es müssen im Eingang alle Token anliegen, damit ein Token zum Ausgang weitergeleitet wird. Bsp.: Press Button 1 and Button 2 to evaluate Schritt 4 Kontrollflussorientierte Äquivalenzklassenbildung Es liegt ein Verhaltensmodell einer Steuerung vor, das je nach Güte und Interpretation der zugrunde liegenden Spezifikationen dem realen Verhalten entspricht und zur Generierung der Testvektoren geeignet ist. Mit dem Hintergrund, dem Testexperten eine möglichst große Transparenz zu bieten, sind bis zu dieser Stelle noch keine testmethodenspezifische Informationen eingeflossen. Erst im nächsten Schritt wird, je nach Testaufgabe, eine Strategie zur Testfallspezifikation vom Tester gewählt. Grundsätzlich wird dabei zwischen der datenbereichsbezogenen vollständigen Stimuligenerierung und der hier entwickelten funktionsorientierten pfadbasierten Stimuligenerierung unterschieden. Beiden Vorgehensweisen ist gemeinsam, dass spezifizierte oder gemessene Werte, bzw. Zeitintervalle einer realen Steuerung diskretisiert werden müssen um eine kombinatorische Explosion zu vermeiden. Grundlegendes Prinzip ist dazu eine wert- und/oder zeitbezogene Äquivalenzklassenbildung und Grenzwertbildung. Die minimalen Informationen, die aus einer informellen Spezifikation extrahiert und semiformal für eine Anwendung dieser Methode vorliegen müssen, sind eine Auflistung der zu stimulierenden Ein- und Ausgänge, sowie sämtliche charakteristische Zeitintervalle. Soll lediglich eine datenbereichsbezogene Generierung durchgeführt werden, kann auf eine Modellierung der genauen inneren logischen Zusammenhänge verzichtet werden. Diese Methode eignet sich als Ausgangspunkt für automatisierte wissensbasierte Tests, in der Regel aber für weniger komplexe Testaufgaben und einer sehr hohen Testintensität Testintensität: Maß für die Häufigkeit einer partiellen Testdurchführung. I.d.R mit jeweils leicht unterschiedlichen Parametern 57

69 Produkt-Verifikation verteilter Steuerungssysteme Eine funktionsorientierte und pfadbasierte Stimuligenerierung ist ausgelegt, funktionsübergreifende, bzw. modulübergreifende Testvektoren mit höherer Abstraktion zu erzeugen. Mit dem Verfahren der vollständigen Stimuligenerierung, bei dem unter Umständen sämtliche stimulierbaren Eingänge über sämtliche Zeit- Äquivalenzklassen vollständig miteinander kombiniert werden, sind Integration.- bzw. Systemtests i.d.r. nicht durchführbar. Kleinere Module, bzw. einzelne Funktionen können so in einem ersten Schritt sehr ausgiebig getestet werden. Für Integrationstests wird für gewöhnlich ein höheres Abstraktionsmaß benötigt, das sowohl die Testaufgabe gut darstellen kann, aber auch neuen, darauf angepassten Algorithmen zur Testfallspezifikation eine Plattform bietet. Dazu werden neben den zu stimulierenden Ein- bzw. Ausgängen und der charakteristischen Zeitintervalle zusätzlich noch Informationen über eine innere Verschaltung, also der implementierten Steuerungslogik des Testobjekts, benötigt. Ein Verhaltensmodell, basierend auf der Datenstruktur eines Graphen, ist eine Möglichkeit diese Plattform bereitzustellen. Theoretische Grundlagen zu geeigneten Testmethoden für eine Anwendung mit Kontrollflussgraphen sind bereits ausgiebig in der Literatur zum Software-Testen behandelt werden (siehe Kapitel 2.3). Für eine Anwendung mit der hier entwickelten Modellierung von Verhaltensmodellen müssen sie erweitert, bzw. angepasst werden. Als Ausgangspunkt werden folgende Methoden betrachtet: Pfadüberdeckung Testziel: Alle Pfade vom Beginn bis Ende des Graphen / Teilgraphen werden durchlaufen. Jeder generierte Pfad entspricht einem Testfall. Anweisungsüberdeckung Testziel: Alle Knoten (Anweisungsblöcke) des Graphen/ Teilgraphen werden mindestens einmal durchlaufen. Zweigüberdeckung Testziel: Alle Zweige (Übergänge zwischen Anweisungsblöcken) des Graphen werden mindestens einmal durchlaufen. Jeder Knoten wird dabei isoliert betrachtet. Beispiel: if-schleifen Bedingungsüberdeckung Testziel: Überprüfung der Entscheidungen in einem Programm einfache Bedingungsüberdeckung - Jede atomare Bedingung muss mindestens einmal in einem Testfall wahr (richtig) als auch einmal falsch sein mehrfache Bedingungsüberdeckung Kombinationen atomarer Bedingungen minimale Mehrfachbedingungsüberdeckung - Jede Entscheidung im Flussdiagramm einmal wahr oder falsch 58

70 Produkt-Verifikation verteilter Steuerungssysteme Die bereits in Kapitel beschriebenen Unterschiede zu bereits existierenden Algorithmen fordern eine neue, auf das hiesige Problem angepasste Methode zur Pfadgenerierung. Ausgangspunkt für die Entwicklung der kontrollflussorientierten Äquivalenzklassenbildung sind die Merkmale des Pfadüberdeckungs-Kriteriums aus dem Bereich des kontrollflussorientierten Testens [42][36]. Bei Anwendung dieses Kriteriums wird beabsichtigt, sämtliche unterschiedliche Pfade der logischen Struktur eines Test-Objekts zu durchlaufen. Der Nachteil, dass die Anzahl der Pfade exponentiell mit der Anzahl der Variablen oder Verzweigungen steigt, kommt erst einmal nicht zum Tragen, da eine computergestützte Pfad-Generierung angestrebt wird. Kontrollflussorientierte Äquivalenzklassenbildung Die Generierung und anschließende Parametrisierung von Testvektoren beruht grundsätzlich auf eine kontrollflussorientierte Äquivalenzklassenbildung an Pfadelementen, die sich auf Basis eines Überdeckungskriteriums ergeben. Die kontrollflussorientierte Äquivalenzklassenbildung lässt sich in folgende Phasen gliedern: Festlegung der zu beobachtenden Start- oder Enditems 34 Identifikation der relevanten Pfadelemente Generierung der Kontrollflusspfade Verarbeitung der Zeitinformationen in Kantenrichtung Verarbeitung der Zeitinformationen entgegen der Kantenrichtung Festlegung der zu beobachtenden Start- oder Enditems: Die Festlegung der zu beobachtenden Start- oder Enditems sollte individuell durchgeführt werden, um den Testumfang in einem überschaubaren Maß zu halten. Identifikation der relevanten Pfadelemente In dem durch die Festlegung der zu beobachtenden Start- oder Enditems reduzierten, funktionalen Bereich eines (komplexen) verteilten Systems, kommt das Kriterium der Pfadüberdeckung zum Einsatz. Das bedeutet, dass sämtliche von diesen Items ausgehenden Kontrollflüsse für die weiteren Betrachtungen von Interesse sind. Voraussetzung für die anschließende Pfadgenerierung ist erst einmal die Identifikation der relevanten Pfadelemente, für die folgende Regeln aufgestellt werden: 34 Startitem und Enditem sind Modellierungselemente für Ein- oder Ausgänge des realen Systems 59

71 Produkt-Verifikation verteilter Steuerungssysteme Abbildung 24: Pfadregeln Identifikation der relevanten Pfadelemente Bei der Identifikation ist zu beachten, dass die Traversierung des Teilgraphen in und entgegen der Kantenrichtung erfolgen kann. (Intention: Reduktion des komplexen Systems auf einen Teilbereich). Abbildung 24 zeigt diesen Zusammenhang. Generierung der Kontrollflusspfade Nach der Identifikation der relevanten Elemente erfolgt die Generierung der Kontrollflusspfade. Diese beginnt bei den Startitems und wird sukzessive bis zu den Enditems auf Grundlage der einfachen Booleschen Operationen Verodern und Veruden durchgeführt. Es ergibt sich im Laufe dieser Generierung eine Pfadhistorie für jedes relevante Pfaditem, die wiederum die Basis für die Generierung der Historie der Nachfolge-Items ist. Abbildung 25: Pfadregeln Generierung der Kontrollflusspfade 60

72 Produkt-Verifikation verteilter Steuerungssysteme Schlussendlich liegen die relevanten Pfade in den Enditems vor. Intention der Kontrollflusspfad-Generierung ist, für jeden Testfall die wesentlichen Start- und Enditems zu finden (die Startitems sind später zu stimulieren, die Enditems zu beobachten). Verarbeitung der Zeitinformationen in Kantenrichtung Für jeden relevanten Pfad werden ausgehend von den Startitems die Zeitinformation, die in Form von Delays (Zeitverzögerung) vorliegen oder nach ODER-Elementen spezifiziert wurden, die aufspaltenden Charakter besitzen, verarbeitet. Abbildung 26: Pfadregeln Verarbeitung der Zeitinformationen in Kantenrichtung Ergebnis der Verarbeitung der Zeitinformationen ist, dass für jeden Testfall bzw. - pfad die Äquivalenzklassen für die relevanten Enditems vorliegen. Verarbeitung der Zeitinformationen entgegen Kantenrichtung Analog zur Verarbeitung der Zeitinformationen in Kantenrichtung, erfolgt diese entgegen der Kantenrichtung. Ausgangspunkte sind jedoch nun die Enditems, für die bereits die testfallspezifischen Äquivalenzklassen vorliegen. Des Weiteren erfolgt die Verarbeitung der Zeitinformation hierbei nicht additiv, sondern subtraktiv. Resultat ist, dass ebenfalls für jedes Startitem testfallspezifische Äquivalenzklassen vorliegen. Parametrisierung der Testvektoren Mit den bisherigen Schritten ist ein Teil-Graph gemäß der kontrollflussorientierten Äquivalenzklassenbildung aus dem modelltechnisch abgelegten Verhalten der Steuerung identifiziert. In der Regel entspricht eine Aufschaltung dieser Tests auf das Testobjekt dem spezifizierten Normalverhalten der Steuerung. Damit sind die Funktionen einer Steuerung gemeint, die im Normalbetrieb, also nicht im Störfall, ausgeführt werden. Entsprechend sind Funktionen, die zum spezifizierten Abnormalverhalten zugeordnet werden können solche, die im Fehlerfall ausgeführt werden. Jegliche andere Reaktion des Testobjekts kann zum nicht spezifizierten Verhalten zugeordnet werden. Eine Abgrenzung der Funktionen nach diesen Kriterien ist ggf. nicht immer eindeutig. 61

73 Produkt-Verifikation verteilter Steuerungssysteme Um Treiberdateien mit Testfällen für eine Verifikation des spezifizierten Normalverhaltens zu generieren, müssen sämtliche Werte und Zeitintervalle innerhalb gültiger Äquivalenzklassen liegen. Werte außerhalb dieser Klassen würden einer Verifikation des spezifizierten Abnormalverhaltens oder einer Verifikation des nicht spezifizierten Verhaltens entsprechen. Abbildung 41 zeigt beispielhaft, wie eine Parametrisierung aussehen kann. Wie bereits eingangs erwähnt, ist der weit aus größere Anteil der implementierten Funktionen sicherheitskritischer Systeme darauf verwendet, abnormale Fälle des Systems zu behandeln. Das sind Ausnahmefälle, die im eigentlichen Betrieb im Idealfall nicht eintreten. In der Phase der Qualitätssicherung müssen auch diese Funktionen auf ein spezifikationsgemäßes Verhalten verifiziert werden. Für die Testdurchführung müssen in der Regel spezielle Testaufbauten, mit der Möglichkeit ein fehlerhaftes Verhalten zu stimulieren, vorgenommen werden. Als Ergebnis der Testdatengenerierung werden entsprechend der oben genannten Regeln, Treiberdateien mit den aufzuschaltenden Stimuli und den zugehörigen Aufschaltzeitpunkten erzeugt. Diese können im Rahmen einer Hardware-In-The-Loop Testumgebung, z.b. Matlab [W3] oder StateDesigner 35, eingelesen und automatisch ausgeführt werden. Sie liegen im weit verbreiteten XML-Format vor und können leicht auf andere Formate angepasst werden. Als Beispiel sei auf Abbildung 42 verwiesen. Grundsätzlich wird hier zwischen den Testdaten, die nach der datenbereichsbezogenen Methode und denen die nach der funktionsorientierten Methode erzeugt werden, unterschieden. Erstere zeichnen sich durch eine simultane und / oder sequentielle vollständige Kombination der Signale und der Aufschaltzeitpunkte aus. Die Qualität der einzelnen Testfälle bzgl. einer Zuordnung, ob und wo jeder Fall spezifiziert ist und damit auch bzgl. der Fehleraufdeckung, ist teilweise eingeschränkt. Für gewöhnlich werden aber mit dieser Methode sehr viele aber wenig komplexe Testfälle erzeugt, so dass sich der oben genannte Nachteil bei richtiger Anwendung durch die Masse an Testfällen wieder aufheben kann. Funktionsorientierte Testdaten sind nicht vollständig simultan und / oder sequentiell, sondern entsprechend der im Verhaltensmodell zugrunde liegenden Verknüpfungselemente, kombiniert. Entgegen der datenbereichsbezogenen Methode kann hier bezüglich der Qualität von Klasse statt Masse gesprochen werden. Die generierten Testdaten sind also eher komplex, angepasst an das Sollverhalten der zu testenden Steuerung, aber auch aufwendiger in der Testfallspezifikation. Sie können noch in Testfälle, die das spezifizierte Normalverhalten stimulieren und solche, die das spezifizierte Abnormalverhalten stimulieren, unterschieden werden. Eine Treiberdatei die letztere Fälle enthält, beinhaltet zusätzlich spezielle Stimuli, die in der Hardware-In- The-Loop Umgebung entsprechend definiert werden müssen. Soll beispielsweise das Verhalten einer Steuerung bei einem Leitungsbruch verifiziert werden, so muss 35 Die Entwicklung von StateDesigner beschreibt M.Rempe [Heft 47] 62

74 Produkt-Verifikation verteilter Steuerungssysteme der Testaufbau so ausgelegt sein, dass diese Leitung über ein Relais mit einem speziellen Signal unterbrochen werden kann. Da die Qualität der Testfälle stark variieren kann ist es sinnvoll, Qualitätsmerkmale zu definieren. Eine allgemeingültige Einordnung kann allerdings nur im konkreten Fall vorgenommen werden. Als grobe Einteilung können folgende Merkmale aufgeführt werden: Fehlerfindungsrate: Fehlerlokalisierung: Überdeckung: Komplexität: Generalität: Gute Testfälle haben eine hohe Wahrscheinlichkeit, Fehler zu finden. Es können Rückschlüsse gezogen werden, wo sich im System sich ein Fehler tatsächlich befindet. Die Überdeckung gibt einen Prozentsatz der vom Testfall abgedeckten Testbasis an. Komplexe Testfälle können oft eine ganze Schar von einfachen Testfällen ersetzen. Es gilt also, einen Kompromiss zwischen der Anzahl und der Komplexität von Testfällen zu schließen. Als Faustregel gilt, dass Testfälle so allgemein wie möglich und so genau wie nötig beschrieben werden sollten. Die Anzahl der Kombinationen von Aktionen, Bedingungen, Pfaden, Anforderungen etc., die getestet werden, bestimmen die Test-Intensität (Testüberdeckung, Coverage), die ihrerseits wieder Einfluss auf die Anzahl der einzigartigen Testfälle hat. Bei der Spezifikation von Testfällen ist darauf zu achten, dass Fehler so früh und so günstig (im Sinne der Wirtschaftlichkeit) wie möglich gefunden werden können. Durch die Verwendung geeigneter Testfall-Spezifikationsmethoden kann der richtige Mix aus Überdeckung, Zeit und Geld gefunden werden Schritt 5 Automatische Testdurchführung Das hier beschriebene Tool EventDesigner ist dafür konzipiert, automatisch Testfallspezifikationen zu generieren. Eine Anwendung als Hardware-In-The-Loop Tool ist nicht vorgesehen, da für diesen Bereich sehr leistungsfähige Werkzeuge existieren. Die erstellten Treiberdateien können von unterschiedlichen HWIL- Testumgebungen zur automatischen Ausführung eingelesen werden. In [41] wird die Simulationsumgebung StateDesigner beschrieben, die sich u.a. zur automatischen Testdatenaufschaltung, sowie zur Messung eignet. Dazu muss ein Interfacemodell erstellt werden, das die in der Treiberdatei aufgeführten Aktionen interpretiert und über eine Schnittstelle zum Testequipment auf das Testobjekt aufschaltet. Zusätzlich werden alle Ereignisse, z.b. Signalwechsel an diskreten Ports oder das Eintreffen von CAN-Nachrichten mit einem Zeitstempel versehen und gespeichert. 63

75 Produkt-Verifikation verteilter Steuerungssysteme Weitere, kommerzielle Möglichkeiten einer automatischen Testausführung zur Verifikation von verteilten Steuerungssystemen bieten z.b. National Instruments 36 mit LabView oder Mathwoks mit Matlab/Simulink. Um die, mit EventDesiger generierten Testvektoren zu nutzen, muss lediglich die Möglichkeit bestehen, eine Text- oder XML-Datei einzulesen. Eine Teststeuerung arbeitet die einzelnen Testfälle ab. Für kleinere Projekte bietet sich ggf. an, zur Testaufschaltung spezielle Testcontroller zu nutzen. Es können beispielsweise ein Mikrocontrollerboard 37 mit einem Datenspeicher, eine an das Testobjekt angepasste Leistungselektronik und Feldbusschnittstellen verwendet werden. Ein einfacher Test-Scheduler (Teststeuerung), der eine sequentielle Testfallaufschaltung steuert, sowie eine Datenspeicherung, der gemessenen Werte vornimmt, ist zu entwerfen. Eine im Datenspeicher abgelegte Treiberdatei kann dann automatisiert aufgeschaltet werden. Im Rahmen der Systemverifikation des Water/Waste-System des Airbus A380, wurde im großen Umfang StateDesigner als HWITL Umgebung genutzt. Eigens entwickelte Testcontroller, basierend auf den Prozessoren C167, Atmel 8bit sowie ARM7 kamen u.a. während der durchgeführten Flugtests zum Einsatz. In Laborversuchen hat sich bereits die Eignung der genannten kommerziellen Tools zur systematischen Verifikation gezeigt Schritt 6 Automatische Testauswertung Das Prinzip der hier vorgeschlagenen Testdatenauswertung beruht auf einem Vergleich gemessener Werte mit dem spezifizierten Verhalten des Testobjekts. Ein Testexperte würde dazu eine Spezifikation studieren und nach einer Testdurchführung manuell die gemessenen Werte vergleichen. Liegt allerdings eine Spezifikation formal, z.b. in Form eines Simulationsmodells, oder semi-formal in Form eines Verhaltensmodell vor, kann prinzipiell computergestützt ein Vergleich durchgeführt werden. EventDesigner generiert dazu zusätzliche Informationen aus einem Verhaltensmodell. Es werden nicht nur Daten zur Stimulation, sondern auch Äquivalenzklassen von zu beobachtenden Ereignissen aus einem Graphen abgeleitet. Dieser Datensatz korreliert mit dem entsprechenden Datensatz aus einer Messung, so dass ein Abgleich automatisch durchgeführt werden kann Schritt 7 Generierung von Test Reports Eine praxisnahe Norm, die sich gut als Grundlage für eine betriebliche Testkonvention nutzen lässt, ist die IEEE-Std Sie ist ursprünglich als Dokumentationsvorlage für Software-Systemtest konzipiert, aber auch ausreichend allgemeingültig gehal- 36 [W9] 37 [W10] 64

76 Produkt-Verifikation verteilter Steuerungssysteme ten, um ihre Anwendung in anderen Bereichen zu finden. So eignet sie sich für den hiesigen Anwendungsfall als Vorlage für die Qualitätssicherung von verteilten eingebetteten Systemen, obwohl hier der Fokus auf dem Black Box Testen liegt. Der IEEE 1008 Standard for Software Unit Testing ist eine Richtlinie für den Modultest. Er definiert Module (software units) und wie man sie testen sollte. Leider fehlt dieser Norm noch die Reife der Ersten. Sie hat eher den Charakter einer Schulungsunterlage, mit ungefähr der gleichen Verbindlichkeit. Eine allgemeingültige, erprobte und praxisgerechte Methodik für den Modultest hat sich bisher noch nicht durchgesetzt 38. Folgende Punkte sind u.a. in der IEEE 829 definiert, die im weiteren Verlauf zur Strukturierung beitragen 39. Übersicht Test Plan (test plan): Der Test Plan bestimmt Abgrenzung, Vorgehensweise, Mittel und Ablaufplan der Testaktivitäten. Er definiert die Elemente und Produktfunktionen, die getestet werden sollen, die Testaufgaben, die durchgeführt werden müssen, das verantwortliche Personal für jede Aufgabe und das Risiko, das mit dem Plan verbunden ist. Test Spezifikation (test specification) Test Design Spezifikation (test design specification): Die Test Design Spezifikation verfeinert die Beschreibung der Vorgehensweise für das Testen der Software. Sie identifiziert die Produktfunktionen, die von den Tests abgedeckt werden müssen. Sie beschreibt weiterhin die Testfälle und Testabläufe, die benötigt werden, um Tests zu bestehen und spezifiziert die Bestehens- oder Verfehlenskriterien der einzelnen Produktfunktionen. Testfall Spezifikation (test case specification): Die Testfall Spezifikation dokumentiert die zu benutzenden Eingabewerte und erwarteten Ausgabewerte. Testfälle sind vom Test Design getrennt. Dies erlaubt die Verwendung der Testfälle in mehreren Designs und die Wiederverwendung in anderen Situationen. Test Ablauf Spezifikation (test procedure specification): Beschreibung aller Schritte zur Durchführung der spezifizierten Testfälle und Implementierung des zugehörigen Test Designs. 38 Quelle: Harry M. Sneed, Mario Winter. Testen objektorientierter Software. Das Praxishandbuch für den Test objektorientierter Client/Server-Systeme. Hanser 2001, S Teilweise übernommen aus [W11] 65

77 Produkt-Verifikation verteilter Steuerungssysteme Test Beschreibung (test reporting) Testfall Übertragungsbeschreibung (test item transmittal report): Die Testfall Übertragungsbeschreibung beschreibt die Übertragung der Testfälle für den Fall, dass getrennte Entwicklungs- und Testteams eingebunden sind, oder dass ein offizieller Zeitpunkt für den Beginn einer Testausführung erwünscht ist. Test Protokoll (test log): Das Test Protokoll dient zur Aufzeichnung der Ereignisse während einer Testausführung. Test Störfall Beschreibung (test incident report): Es beschreibt alle Ereignisse, die während einer Testausführung auftreten und weitere Nachprüfungen erfordern. Test Zusammenfassung (test summary report): Fasst die Test Aktivitäten zusammen, die mit einem oder mehreren Test Design Spezifikationen zusammenhängen. Während eine Testfall-Übertragungsbeschreibung sämtliche testrelevanten, abteilungsübergreifenden Zusammenhänge erklärt und in einer Störfall- Beschreibung alle nicht geplanten Vorkommnisse aufgeführt werden, ist im Test Protokoll jeder durchgeführte Test erläutert. Nach einer durchgeführten Verifikation und einem Vergleich der gemessenen Werte mit den im Modell abgelegten Informationen, kann ein automatisch generierter Report erzeugt werden, der an die oben genannte Norm angelehnt ist. Dieser beinhaltet allgemeine Informationen, wie z.b. den Namen des Testers, das Datum, eine fortlaufende Test-ID und grafische Notationen aus der Systemstruktur, als auch eine Auflistung sämtlicher durchgeführter Einzeltests. So werden nicht nur Testfälle dokumentiert, die ein fehlerhaftes Verhalten des Testobjektes initiiert haben, sondern auch solche, bei denen das System spezifikationsgetreu reagiert Teststrategien In diesem Kapitel wird gezeigt, wie die entwickelte Methode zur Produktverifikation im Rahmen von Modultests und Integrationstests eingesetzt werden kann. Ziel des Testprozesses ist die Minimierung des Restrisikos verbleibender Fehler und somit eine Bewertung der realen Qualität des Testobjektes. 66

78 Produkt-Verifikation verteilter Steuerungssysteme Die in Kapitel beschriebene Umsetzung der kontrollflussbasierten Äquivalenzklassenbildung bildet keine Teststrategie ab, sondern bietet dem Testexperten durch eine Parametrisierung kombinierter und bewährter Testmethoden, eine automatisiert durchführbare Testfallspezifikation. Eine Teststrategie ist stark von der Testaufgabe, bzw. von den Vorgaben des Qualitätsmanagements abhängig. So obliegt es dem Tester, eine Teststrategie mit dem Ziel festzulegen, eine möglichst hohe Fehleraufdeckung zu erhalten. In der Regel kann ein Anteil sämtlicher durchzuführender Tests auch systematisch und automatisiert durchgeführt werden. Um im weiteren Verlauf diesbezüglich eine konkrete Zuordnung herzuleiten, wird zunächst dargestellt, wie eine Fehlerausbreitung im Produktentwicklungsprozess vorliegen kann. Abbildung 27: Summationseffekt von Fehlern Abbildung 27 zeigt einen möglichen Summationseffekt von Fehlern während eines Entwicklungsprozesses. Potentiell addieren sich Fehler oder Mängel aus jeder Phase des Prozesses. Während der Test- und Integrationsphase wird ein System gegen eine entsprechende Spezifikation verifiziert und validiert, so dass für die meisten Systeme neben eines Anteils korrekten Systemverhaltens je ein Anteil korrigierter Fehler, bekannter unkorrigierter Fehler und unbekannter Fehler vorliegt. Welche Tests in diesem Zusammenhang pauschal automatisiert durchführbar sind, kann ohne eine genaue Kenntnis des Systems und der zugrunde liegenden Eingangsinformationen nicht angegeben werden. Allerdings kann eine weitere Unterteilung aus dieser Menge nach Art der implementierten Funktion vorgenommen werden: 67

79 Produkt-Verifikation verteilter Steuerungssysteme Verifikation des spezifizierten und modellierbaren Normalverhaltens Verifikation des spezifizierten und modellierbaren Abnormalverhaltens Nicht automatisiert durchführbare Tests, bzw. Fälle, welche nur mit hohem Aufwand automatisierbar sind, können nach Verifikation des spezifizierten und nicht modellierbaren Verhaltens Verifikation des nicht spezifizierten Verhaltens eingeteilt werden. Verifikation des spezifizierten und modellierbaren Normalverhaltens Mit der in Kapitel beschriebenen Methode der kontrollflussorientierten Ä- quivalenzklassenbildung, nach dem Prinzip der Pfadüberdeckung, kann eine Klasse von Tests zur Verifikation des spezifizierten Normalverhaltens hergeleitet werden. Es wird für einen selektierten Teil-Graphen, also Teilfunktion der Steuerung, jeder Pfad separat betrachtet. Wie in Abbildung 19 zu sehen, werden an den ODER-Verknüpfungen Pfade aufgeteilt und dadurch neue Testfälle generiert. Es werden nach dem Prinzip der Äquivalenzklassenbildung die Mittelwerte angenommen, um mit einer geringen Auswahl an Testfällen sicher jeden gültigen Zustand zu stimulieren. Die kontrollflussorientierte Grenzwertanalyse bietet zusätzlich die Möglichkeit, Stimuli an den Grenzwerten zu platzieren. Abbildung 28: Stimuli-Aufschaltpunkte für unabhängige Größen Zur Verdeutlichung zeigt Abbildung 28 eine Zeittafel eines einzelnen Signals. Die rot markierten Bereiche stellen gemäß der Spezifikation ungültige Werte, die grün markierten, gültige Werte dar. Eingezeichnet sind Stimuli nach der Äquivalenz- 68

80 Produkt-Verifikation verteilter Steuerungssysteme klassenmethode und der Grenzwertanalyse, sowohl innerhalb als auch außerhalb der gültigen Bereiche. Werden zwei oder mehrere Signale kombiniert, so wie in Abbildung 29 als UND- Verknüpfung, verschieben sich die gültigen Bereiche. Entsprechend müssen auch die Teststimuli anders platziert werden. Abbildung 29: Stimuli-Aufschaltpunkte für kombinierte unabhängige Größen (UND-Verknüpfung) Verifikation des spezifizierten und modellierbaren Abnormalverhaltens Ein Großteil der implementierten Steuerungsalgorithmen sicherheitskritischer, bzw. robust ausgelegter Systeme, behandelt das Abnormalverhalten eines Systems. Das sind vorsorglich implementierte Funktionen, die im Falle eines Fehlverhaltens das System in einem sicheren Zustand halten, sowie eine Störung anzeigen oder protokollieren. Diese Funktionen zu überprüfen, bedarf es der Möglichkeit (Testhardware), entsprechendes Fehlverhalten auch zu stimulieren. Eine Verifikation des spezifizierten und nicht modellierbaren Verhaltens und eine Verifikation des nicht spezifizierten Verhaltens, ist nicht Gegenstand dieser Arbeit, muss aber im Rahmen einer Systemvalidierung mit entsprechenden Methoden behandelt werden. So kann die erst genannte Verifikation mit der Hilfe von Expertenwissen mit einer manuellen Ausführung der Tests durchgeführt werden. Die Klasse des nicht spezifizierten Verhaltens, also Funktionen die ggf. zusätzlich, bzw. unnötig implementiert wurden oder unerwünschte Seiteneffekte, können unter Umständen mit Zufallstests gefunden werden. 69

81 Produkt-Verifikation verteilter Steuerungssysteme Modultests Gebräuchliche Methoden zur Verifikation von eingebetteten Systemen sind in Kapitel 2.3 beschriebenen. Oftmals basieren die durchzuführenden Tests auf der Erfahrung und dem Wissen eines Testexpertenteams. Daher ist eine gute Empfehlung, in einem solchen Fall zu Beginn einer Modultestreihe, zunächst nach dem Prinzip der dynamischen Fehlererwartungsmethode Tests von einem Systemexperten durchführen zu lassen. Erst wenn offensichtliche Fehler gefunden sind, sollten automatisierte Methoden zum Einsatz kommen. Eine dynamische Methode davon kann die hier beschriebene Pfadüberdeckungsmethode, basierend auf Verhaltensmodellen sein. Ganz allgemein dient eine Pfadüberdeckung zur Ermittlung von Testfällen bzw. einer Testfallspezifikation. Im ursprünglichen Sinn stellen Pfade eine Menge von Gesamtwegen des Kontrollflusses durch den (Source-) Code eines Testobjekts dar. Je nach festgelegtem Ziel, sind ein gewisser Anteil oder alle Pfade im Code des Testobjekts zu durchlaufen. Reale Programme weisen oft eine sehr große Anzahl von möglichen Pfaden auf, so dass ein Durchlaufen sämtlicher Pfade während eines Tests unter Umständen nicht möglich ist. Eine Voraussetzung für eine Anwendung ist allerdings die Kenntnis des implementierten Steuerungscodes und damit des Programm- Kontrollflusspfads. Die hier beschriebene Vorgehensweise basiert allerdings auf eine reine Black-Box- Methodik, bei der eine eindeutige Kenntnis des implementierten Steuerungscodes nicht nötig ist. Als Quelle dient lediglich ein Verhaltensmodell, basierend auf der technischen Dokumentation des Testobjekts. In Anlehnung an den ursprünglichen Anwendungsbereich, den White-Box-Methoden, werden im Folgenden Empfehlungen für ein pfadbasiertes Vorgehen im Rahmen von Black-Box-Modultests gezeigt. Für den Fall, dass eine Analyse der technischen Dokumentation, bzw. der Spezifikation durchgeführt wurde, kann eine erste Auswahl der konkreten Testmethode nach dem folgenden Schema vorgenommen werden. 70

82 Produkt-Verifikation verteilter Steuerungssysteme ja (Funktionsorientiertes Verfahren) Liegt eine Funktionsbeschreibung inklusive der inneren Verschaltung vor? nein nur Anweisungen nur Anweisungen und atomare, nicht zusammengesetzte Bedingungen nur Anweisungen und atomare, nicht zusammengesetzte Bedingungen und Schleifen nur Anweisungen und zusammen-gesetzte Bedingungen Enthält die Funktion... nur Anweisungen und zusammen-gesetzte Bedingungen und Schleifen Datenbereichsbezogene Verfahren Anweisungsüberdeckungstest Zweigüberdeckungstest Genügt es, Schleifen einmal zu wiederholen? Überprüfung aller atomaren Bedingungen ausreichend? ja Genügt es, Schleifen einmal zu wiederholen? nein ja Boundary inerior- Pfadtest nein Strukturierter Pfadtest ja Minimaler Mehrfach- Bedingungsüberdeckungstest Zweigüberdeckungstest und einfacher Bedingungsüberdeckungstest nein Boundary inerior- Pfadtest Strukturierter Pfadtest Überprüfung aller atomaren Bedingungen ausreichend? ja nein Einfacher Bedingungsüberdeckungstest Abbildung 30: Auswahlverfahren von Testmethoden Minimaler Mehrfach- Bedingungsüberdeckungstest Unter einem vollständigen Pfadüberdeckungstest wird ein Test, bzw. eine Testreihe verstanden, bei der sämtliche Pfade, inklusive aller Schleifendurchgänge getestet werden. Das kann zu einer nicht zu bewältigenden Menge an durchzuführenden Tests führen, so dass ggf. weiter Einschränkungen vorgenommen werden müssen. Ein Boundary-Interior Pfadüberdeckungstest ist prinzipiell ein vollständiger Pfadüberdeckungstest, mit der Einschränkung, dass die Schleifendurchläufe auf <=2 reduziert werden. Die hier entwickelte Testmethode ist den Boundary Pfadüberdeckungstests zuzuordnen. Für jede Schleife gibt es 2 Gruppen von Pfaden: Boundary-Test: Jede Schleife wird keinmal betreten. Jede Schleife wird genau einmal betreten und alle Pfade in dem Schleifenkörper werden einmal abgearbeitet. Interior-Test: Das Schleifeninnere gilt als getestet, wenn alle Pfade, die bei zweimaligem Durchlaufen möglich sind, abgearbeitet wurden. Eine weitere Spezialisierung ist der strukturierte Pfadüberdeckungstest. Im Prinzip wird dieser durchgeführt wie ein Boundary-Interior Pfadüberdeckungstest, nur dass die Anzahl der Schleifendurchläufe auf eine vorgegebene natürliche Zahl n reduziert werden. 71

83 Produkt-Verifikation verteilter Steuerungssysteme Integrationstests Nachdem die einzelnen Komponenten erfolgreich bestandene Modultests durchlaufen haben und für sich isoliert fehlerfrei funktionsfähig sind, werden sie in das System integriert. Der Begriff Integrationstest bezeichnet also in der Produktverifikation eine aufeinander abgestimmte Reihe von Einzeltests, die dazu dienen, verschiedene voneinander abhängige Komponenten eines komplexen Systems im Zusammenspiel miteinander zu testen. Eine Integrationsstrategie, bzw. der Integration Flow legt fest, in welcher zeitlichen Reihenfolge integriert wird. In der Praxis haben sich dazu so genannte Integrationsflussdiagramme etabliert. Mit der Voraussetzung, dass jede Systemkomponente bereits auf Modulebene qualifiziert ist, haben Integrationstests zum Ziel, ein fehlerfreies Zusammenwirken der Systemkomponenten zu überprüfen. Die generelle Vorgehensweise ist das schrittweise Zusammensetzen der System-Komponenten, mit einer regelmäßigen Überprüfung auf Fehler nach jeder neuen Komponente. Man unterscheidet zwischen einer testzielorientierten und einer vorgehensorientierten Integrationsstrategie. Für die erstere gilt, dass die Testfälle anhand der Testziele erstellt werden und lediglich nur die dazu notwendigen System-Komponenten zusammengebaut werden. Wird die Integrationsreihenfolge allerdings aus der Systemarchitektur abgeleitet und ist damit die Integration von der Vorgehensweise im Entwurf abhängig, spricht man von einer vorgehensorientierten Integrationsstrategie. Des weiteren ist zwischen einer nicht-inkrementellen Integration, bei der alle, bzw. sehr viele Komponenten gleichzeitig integriert werden und einer inkrementellen Integration zu unterscheiden. Hier werden die Komponenten step-by-step zusammengefügt. Die erste Variante birgt den Nachteil, dass alle Komponenten zur Verfügung stehen müssen und Fehler schwer zu lokalisieren sind, aber keine Simulationen, nicht vorhandener Geräte, nötig sind. Bei der inkrementellen Strategie werden in der Regel Simulationen (Platzhalter oder Stubs ) benötigt, aber dafür können die Komponenten direkt integriert werden, wenn sie erstellt sind. Zwischen diesen Extremen (testzielorientierten und vorgehensorientierten sowie einer inkrementellen und einer nicht-inkrementellen Integration) ist jeweils, bezogen auf den jeweiligen Anwendungsfall, eine Strategie zu wählen. Folgende Abbildung veranschaulicht den Zusammenhang. 72

84 Produkt-Verifikation verteilter Steuerungssysteme inkrementell nicht-inkrementell bottom-up inside-out outside-in top-down hardest-in big bang funktionsorientiert Nach der Verfügbarkeit vorgehensorientiert testzielorientiert Abbildung 31: Auswahl einiger Integrationsstrategien Die Prüfung der System-Komponenten beginnend von der Wurzel der Baum- oder Schichtenhierarchie, wird hier als top-down Integration verstanden. Es wird schrittweise integriert und fehlende System-Komponenten werden simuliert. Ein Vorteil liegt darin begründet, dass ein frühzeitig erstelltes Simulationsmodell aus Sicht des Nutzers bereits einen Teil der Funktionen des endgültigen Systems ausführt. Bei zunehmender Integrationstiefe steigt die Schwierigkeit, bestimmte Testsituationen zu erzeugen und ein Zusammenwirken von zu prüfender Software, Systemsoftware und Hardware wird sehr spät geprüft. Bei der bottom-up Vorgehensweise werden zuerst die Basiskomponenten und anschließend die darauf aufbauenden Komponenten integriert. Hier wird zwar das Zusammenwirken von Systemsoftware, Hardware und zu prüfender Software früh getestet, aber ein lauffähiges Gesamtsystem ist erst am Ende verfügbar, so dass Fehler in der Produktdefinition erst spät gefunden werden können. Während die Integrationsstrategien inside-out und outside-in eine Mischung aus den oben genannten sind, werden bei der Strategie hardest-first zuerst die potenziell fehlerhaften und die am schwierigsten zu implementierenden System- Komponenten implementiert und getestet. Für eine funktionsorientierte Integrationsstrategie müssen sämtliche Ressourcen für eine gewählte Funktion, die beispielsweise auch über mehrere Komponenten verteilt implementiert ist, vorliegen. Eine Auswahl der richtigen Strategie muss von einem Testexperten getroffen werden, da sie direkt von dem zu testenden System und den Möglichkeiten der Testdurchführung, bzw. der Testaufbauten abhängt. Grundsätzlich können Testdaten mit der in Kapitel 3.2 gezeigten Methode für alle der hier aufgeführten Integrationsteststrategien erzeugt werden. 73

85 Produkt-Verifikation verteilter Steuerungssysteme Systemtests Unter einem Systemtest wird die Testphase verstanden, bei der das gesamte System gegen eine Spezifikation, bzw. das Gesamtsystem gegen seine Anforderungen getestet wird. Dazu muss das System vollständig integriert sein. In der Domäne des Passagierflugzeugbaus gehören z.b. Ground-Tests und Flight-Tests zu den Systemtests. Gesetzliche Regularien und firmenspezifische Direktiven schränken die Möglichkeiten der Testdatenaufschaltung für funktionale Tests teilweise stark ein. Das gilt im Besonderen für eine Stimulation des spezifizierten Abnormalverhaltens. Der Fokus liegt bei diesen Systemtests u.a. auf dem Testen der operationalen Eigenschaften Einordnung der pfadorientierten Stimuligenerierung In Anlehnung an die Softwaretechnik lassen sich Testverfahren verschiedenartig klassifizieren [W1]. Die dort gebräuchlichen Methoden können beispielsweise in prüftechnische, system-strukturelle, ablauforientierte und informationsstand-abhängige Verfahren eingeteilt werden [Behrens 06]. Verfahrensklasse Testmethoden prüftechnisch statische Tests, dynamische Tests system-strukturell Komponenten-, Modul-, Integrationsund Systemtests ablauforientiert Schnittstellen-, Regressions-, Stress-, Akzeptanztests... informationsstandabhängig Black-Box-Test, Grey-Box-Tests, White-Box-Tests Tabelle 2: Klassifizierung der Test-Methoden in der Softwaretechnik Weil eine Modellierung des Strukturverhaltens eines dezentralen Steuerungssystems auf Basis einer informellen Spezifikation und damit gewissermaßen informationsstands- oder wissens-abhängig erfolgt, wird ein Vergleich mit dem Black- und dem White-Box-Testen durchgeführt. Ein wesentliches Merkmal von Black-Box-Tests ist die spezifikationsbasierte Ableitung von Testfällen ohne Kenntnis der inneren Struktur oder Funktionsweise des zu testenden Objekts bzw. Systems. Die Tests werden in der Regel nicht von den Personen entwickelt und durchgeführt, welche auch das innere Strukturverhalten des zu testenden Objekts implementiert haben. Sowohl die Äquivalenzklassen- als auch die Grenzwertanalysemethode sind typische Verfahren des Black-Box-Testens. 74

86 Produkt-Verifikation verteilter Steuerungssysteme Voraussetzung für eine Testevaluierung nach dem White-Box-Prinzip ist eine genaue Kenntnis der inneren Struktur der zu testenden Komponente, dass heißt für den Fall von intelligenten Steuerungen, der Steuerungs-Code. In der Regel werden deshalb die White-Box-Tests von den Entwicklern der jeweiligen Komponente durchgeführt. An dieser Stelle besteht die Möglichkeit, kontrollflussorientierte Verfahren im Sinne der Software Testliteratur [42] zur Verifikation heranzuziehen. Zu diesen gehört unter anderem das Pfadüberdeckungsverfahren. Bei der implementierten Testmethode wird die innere Struktur oder Funktionsweise eines dezentralen Steuerungssystems gemäß einer informellen Spezifikation nachgebildet, wobei allerdings das tatsächlich implementierte Verhalten der Komponenten unbekannt ist. Die Ableitung der Testfälle erfolgt auf Grundlage der nachgebildeten inneren Struktur, kontrollflussorientiert. Mit Hilfe der vorgestellten Pfadgenerierungs- Methode werden sämtliche Pfade der inneren Struktur erfasst. Diese Vorgehensweise ist demnach mit dem Pfadüberdeckungsverfahren vergleichbar. Von den generierten Pfaden wird auf die zu stimulierenden Ports der Mikro-Controller geschlossen. Die konkreten Stimuli-Beaufschaltungen ergeben sich schließlich nach der Äquivalenzklassen- und Grenzwertanalysemethode. Insgesamt wird durch den angestellten Vergleich deutlich, dass die implementierte Testmethode wesentliche Merkmale beider Testmethoden vereint. Aufgrund der Tatsache, dass sowohl das modellierte Strukturverhalten als auch das Zeitverhalten des Steuerungssystems bei der Generierung von Testfällen berücksichtigt werden, wird die Anzahl der generierten Testfälle vergleichsweise gering gehalten. Diese Anzahl ist insbesondere geringer als jene, die sich durch rein kombinatorische Operationen von Test-Stimuli ergeben, die im Rahmen einer Black-Box-Methode datenbereichsorientiert hergeleitet werden. 75

87 Produkt-Verifikation verteilter Steuerungssysteme 76

88 Industrielles Anwendungsbeispiel 4 Industrielles Anwendungsbeispiel Dieses Kapitel beschreibt die, mit der hier erarbeiteten Methode durchgeführten experimentellen Beweise bei dem Kooperationspartner Airbus Deutschland in Hamburg. Der Versuchszeitraum überschneidet sich mit der Endphase der Entwicklungszeit des Airbus A380. So konnte die Vorgehensweise parallel zur realen Produkt Verifikation des Water-Waste-Systems des A380 sukzessive erarbeitet und getestet werden. Der hier gezeigte Verifikationsschritt stellt einen repräsentativen Ausschnitt aus der gesamten Test-Kampagne dar. Er zeigt, wie die toolgestützte Methode mit den Schritten aus Kapitel real angewandt wird. Es wird auch ersichtlich, welche Strategie (siehe 3.2.3) zugrunde liegt. Mit einer abschließenden Analyse der generierten Testdaten und der heutigen Kenntnis über die real aufgetretenen Fehler im System wird in einer Bewertung deutlich, mit welchem Zeitaufwand welche Klassen von Fehlerfällen, mit einer Anwendung der Methode, gefunden werden können. Damit kann eine qualitative Aussage über die hergeleitete Methode zu ihrer Eignung für einen Teil der Produkt Verifikation von verteilten Steuerungssystemen gegeben werden. 4.1 Gegenstand der Untersuchung Am Beispiel eines Water-Waste-Systems im Bereich des Passagierflugzeugbaus, wird die erarbeitete Methode experimentell untersucht. Der Fokus dieser Untersuchung liegt auf der Phase erweiteter Modultests und der Integrationstests. Während bei den Modultests intensiv einzelne Funktionen separater Steuerungen in gekapselten HWITL-Tests gegen eine Gerätespezifikation verifiziert werden, kommt es bei den Integrationstests auf eine geräteübergreifende Teststrategie an. Bis zu einer gewissen Komplexität der Modulfunktionen ist eine Anwendung der datenbereichsbezogenen Vorgehensweise empfehlenswert. Abbildung 32: Vereinfachte, schematische Darstellung des Abwassersystems 77

89 Industrielles Anwendungsbeispiel Integrationstests haben zum Ziel, neben zahlreicher nicht-funktionaler geräteübergreifender Anforderungen, auch funktionale Anforderungen zu überprüfen. Dieses Beispiel beschränkt sich auf eine Verifikation funktionaler Anforderungen. Als typisches Beispiel für ein verteiltes Steuerungssystem im Flugzeugbau wird hier im weiteren Verlauf gezeigt, wie die entwickelte Methode die Geräteintegration für das Waste-System (Abwassersystem) des Airbus A380 unterstützt. Das bedeutet, es müssen Integrationstest-Szenarien gefunden werden, die sicherstellen, dass eine neu integrierte Komponente mit den anderen System-Komponenten spezifikationsgemäß zusammenarbeitet. Da eine Aufstellung sämtlicher Szenarien an dieser Stelle zur Erklärung der grundsätzlichen Vorgehensweise unnötig ist, wird lediglich auf eine zentrale, aber geräteübergreifende Funktion eingegangen. 4.2 Aufbau und Funktion des Systems Das Waste-System des A380 ist in vier unabhängige Rohrleitungsstränge eingeteilt, die sich jeweils auf den Flugzeugdecks und Seiten verteilen. An jedem Strang können, vom Kunden definiert, an verschiedenen Positionen Toilet-Compartments und Galleys verbaut werden. Zu den Komponenten eines Compartments, die mit dem Abwassersystem verbunden sind, gehören in erster Linie die Toiletten und Waschbassins. Es können aber auch Urinale, Bidets oder Duschen verbaut werden, in den Kücheneinheiten z.b. die Abwasserbecken. Jede dieser Komponenten sind für sich betrachtet eingebettete Systeme. Sie besitzen eine digitale Steuerung, die entsprechend der spezifizierten Logik Sensorsignale erfasst und Aktoren ansteuert, sowie über einen oder mehrere Datenbusse kommuniziert. Der Abwassertransport basiert auf dem Vakuumprinzip, d.h. in niedrigen Flughöhen wird mit der Hilfe eines Vakuumgenerators Luft aus den Abwassertanks evakuiert und in großen Höhen ein Ventil zur Außenumgebung geöffnet, so dass aufgrund der Druckdifferenz ein Abwassertransport von den Toiletten, etc. zum Tank realisiert wird. Eine Messung des Abwasserfüllstandes ist über zwei redundante Komponenten umgesetzt. Zum einen wird mit einem intelligenten Sensor das Erreichen eines maximalen Füllstandes ermittelt, zum anderen sind zwei Drucksensoren verbaut, die aufgrund der ermittelten Druckdifferenz den Füllstand errechnen und ihn über einen Datenbus anderen Komponenten zur Verfügung stellen. Weitere verteilte Steuerungen übernehmen Aufgaben wie die Ansteuerung des Vakuum Generators oder des Bypassventils zur Außenumgebung. Entsprechend der oben beschriebenen physikalischen Struktur des Rohrleitungssystems ist auch der Datenbus, hier handelt es sich um den Controller Area Network (CAN-Bus), unterteilt. Für jeweils jede Seite und jedes Deck existiert ein CAN-Bus Strang. Sie laufen in einer zentralen Kabinensteuerung zusammen, die auch einen Knotenpunkt zu anderen Systemen, wie z.b. dem Frischwassersystem, bildet. 78

90 Industrielles Anwendungsbeispiel Die Spezifikationen der Komponenten sind in nicht formaler Form abgelegt. Sämtliche funktionalen Zusammenhänge des Systems zu beschreiben würde den Umfang dieser Arbeit sprengen, deshalb wird hier lediglich beispielhaft aber realitätsnahe auf eine komponentenübergreifende Funktion eingegangen. Zu den Komponenten zählen ein sog. Toilettencontroller, ein Vacuum-Generator-Motor-Controller, ein Füllstandscontroller sowie ein Kabinen-Controller, jeweils mit der dazugehörigen Sensorik und Aktorik. Die geräteübergreifende Funktion die hier betrachtet wird, ist der Flush Cycle, also die Spülfunktion einer Toilette. Diese Funktion beinhaltet neben dem eigentlichen Algorithmus zur Ansteuerung der Spülfunktion (Normalverhalten) auch mehrere Ausnahmebehandlungen (Abnormalverhalten). Spezifikation Toilettencontroller : Normalverhalten: Eine Aufgabe der Steuerung ist die Ansteuerung eines Frischwasserzulaufs (RV) und eines Abwasser Ventils (FV) nach Anforderung eines Spülzykluses, durch Betätigen des Anforderungsknopfes (FS) durch einen Benutzer. Dazu muss der zeitliche Ablauf, bzw. die Reihenfolge aus Abbildung 33 eingehalten werden. Nach Erkennen eines Spülwunsches wird zuerst eine Indikation (LEDGRNX) aktiviert, dann das Zulaufventil für 0.3s (±0.05s) aufgefahren. 2.5s (±0.1s) nach Anforderung fährt das FV zwecks Abwasserabtransports für 4s (±0.5s) auf. Per CAN-Datenbus werden Statusmeldungen über den momentanen Zustand der Steuerung und auch Anforderungen (Requests) an andere Steuerungen gesendet. Sobald ein Spülzyklus beginnt, wird der Status (Flush Active Bit) und eine Anforderung für Vakuum (VG Request BIT) zur Vakuum Generator Steuerung gesendet. Abbildung 33: Zeitverhalten eines Spülzyklus 79

91 Industrielles Anwendungsbeispiel Abnormalverhalten: Ein in der Toilettenschüssel montierter Füllstandssensor (Bowl Full Sensor) detektiert im Fehlerfall einen zu hohen Wasserstand und sendet eine entsprechende Statusmeldung. In den folgenden Fällen muss die Ausführung eines Spülzyklusses unterbunden werden (Disabling). Bowl Full Sensor meldet zu hohen Füllstand Tank Füllstandssensor meldet einen vollen Abwassertank Vakuum Generator meldet Fehler Cabin Controller meldet System in Service Mode Vakuum Generator Steuerung (VGMC) Die Vakuum Steuereinheit steuert eine Evakuierungspumpe an, die einen Unterdruck im Abwassersystem aufbaut. Durch die Druckdifferenz zwischen der Kabinenumgebung und innerhalb des Abwassertanks, wird das Abwasser von den Toiletten durch ein Rohrleitungssystem zu den Tanks transportiert. Normalverhalten: Wird eine Nachricht von einer Toilettensteuerung mit einer Vakuumanforderung empfangen, soll der Motor von der Steuerung ausschaltverzögert für 4s (±0.5s) aktiviert werden. Ein diskreter Endlagenschalter am Fahrwerk erfasst, ob das Fahrwerk ein- oder ausgefahren ist. Basierend auf dieser Information ermittelt die Steuerung den Zustand, ob sich das Flugzeug im Flug oder auf dem Boden befindet. Entsprechender Zustand wird über den CAN-Bus als Statusnachricht gesendet. Kabinen Controller (Cabin Controller) Als zentrale Komponente eines Kabinensystems bildet er einen Netzwerk- Knotenpunkt verschiedener Systeme. Er übernimmt unter anderem Aufgaben wie das Weiterleiten der Feldbustelegramme zwischen verschiedenen Sub-Systemen, ein Konfigurationsmanagement oder eine Indikation wichtiger Systemzustände. Normalverhalten: Sobald der Endlagenschalter der Service-Klappe geöffnet wird (Servicefall) und das Flugzeug am Boden ist, geht das System in den Zustand In Service über. Während eines Fluges wird die jeweils aktuelle Flugphase (1 bis 12,) bereitgestellt von der Flugsteuerung, an das Kabinensystem weitergeleitet. Füllstandssensor (Liquid Level Sensor) Ein diskreter induktiver Füllstandssensor ist im oberen Bereich des Abwassertanks montiert und registriert einen maximal zulässigen Füllstand. 80

92 Industrielles Anwendungsbeispiel Normalverhalten: Wird von 20 Einzelmessungen mindestens 15-mal eine Tank-Voll-Bedingung ermittelt, soll dem System dieses Ergebnis über eine Statusnachricht gesendet werden. In den Flugphasen Steigflug und Sinkflug wird die Messung nicht ausgewertet. Eine zuvor eingetretene Tank-Voll-Bedingung soll bis zum Wechsel der Flugphase von 12 zu 1 registriert bleiben. 4.3 Versuchsaufbau Das zu integrierende Testobjekt muss mit entsprechenden Schnittstellen zur Aufschaltung der Teststimuli versehen werden. Da hier nach dem Black-Box-Prinzip vorgegangen wird, stehen nur die regulären Ein- und Ausgänge (DI,DO,AI,AO, sowie Datenbusse) zur Verfügung. In diesem Anwendungsfall sind sämtliche IO s parallel zu der Sensorik und Aktorik, auf die Ein- bzw. Ausgänge mehrerer Speicher Programmierbaren Steuerungen (SPS) gelegt. Da hier im Vordergrund ein verteiltes Steuerungssystem steht, es hinsichtlich geräteübergreifender Funktionalität zu verifizieren, sind sämtliche Komponenten des Systems an verteilten SPSen kontaktiert. Damit existiert zur Verifikation des dezentralen Systems auch entsprechendes verteiltes Testequipment. Abbildung 34 zeigt diesen Zusammenhang schematisch. Abbildung 34: Aufbau des Testequipments Für die reale Durchführung dieser Verifikationskampagne stand ein komplettes Testrig mit den Ausdehnungen des realen Flugzeugs zur Verfügung. An zentraler Stelle (Steuerstand) können die generierten Testscenarien auf das System beaufschlagt werden. Darüber hinaus besteht die Möglichkeit, nicht vorhandene Kompo- 81

93 Industrielles Anwendungsbeispiel nenten als Simulation zu integrieren. Im folgenden Abschnitt wird näher auf die Softwarestruktur der verwendeten Testapplikationen eingegangen. 4.4 Softwareunterstützung (Toolchain) Es werden verschiedene Softwarekomponenten für die Produktverifikation benötigt. Ausgehend von Programmen der SPSen, die gewöhnlich nach der IEC61131 erstellt werden, liegt die Hauptaufgabe im Weiterleiten (Routing) zwischen dem Test- Datenbus und den parallel zum Testobjekt angeschlossenen Signalen. Abbildung 35: Vorgehensweise und Softwareschnittstellen der Industrieanwendung Auf einem zentralen Rechnersystem ist eine HWITL-Testsoftware installiert. Das kann beispielsweise Matlab 40, wie in Abbildung 35 gezeigt, oder wie hier angewandt, eine eigene Entwicklung namens StateDesigner sein. Die Aufgabe dieser Software besteht darin, einen eingelesenen Testtreiber auf das reale System aufzuschalten. Im weiteren Verlauf wird diese Softwarekomponente als Teststeuerung bezeichnet. Eine weitere Aufgabe der Teststeuerung besteht darin, den Zustand des Systems während der Tests zu speichern. Der Fokus dieser Arbeit liegt allerdings nicht auf dieser Softwarekomponente, sondern auf dem Entwurf der Testfallspezifikation mittels des Tools EventDesigner. Eine Verhaltensbeschreibung des Systems, vom Testexperten entworfen und ggf. mit Expertenwissen modifiziert, ist die Basis für die Generierung der Treiberdateien. 40 Fa. Mathworks 82