Testen eingebetteter Systeme

Westfälische Wilhelms-Universität MünsterAusarbeitungTesten eingebetteter Systemeim Rahmen des Seminars „Qualitätsmanagement in der Softwaretechnik“Jens RolfesThemensteller: Prof. Dr. Herbert KuchenBetreuer: Prof. Dr. Herbert KuchenInstitut für WirtschaftsinformatikPraktische Informatik in der Wirtschaft

Kapitel 1: Einführung1 EinführungMit eingebetteten Systemen werden „Elektronik-Systeme bezeichnet, die in größereUmgebungen integriert sind. Sie werden eigens für spezielle Anwendungen entworfenund führen dedizierte Funktionen innerhalb eines Gesamtsystems aus. EingebetteteSysteme können sowohl Standard-Mikroprozessoren und -Mikrocontroller, als auch andie jeweilige Anwendung angepaßte spezielle Hard- und Software enthalten.“ [FG04a]Sie finden sich sowohl in kostenintensiven Investitionsgütern der Luftfahrtindustrie, derEnergie erzeugenden Industrie als auch in Großserienprodukten, angefangen vonüblichen Haushaltsgeräten bis zu KFZ-Komponenten wieder. So sind z.B. in modernenAutomobilen mittlerweile über 80 eingebettete Systeme vorhanden.Die obige Definition hat bereits angedeutet, dass sich eingebettete Systeme bzgl. ihresphysikalischen Aufbaus relativ stark unterscheiden. Die Lösungen reichen je nachAnforderung vom 1-Chip-Computer für den Einsatz in preiswerten Konsumgütern bishin zu großen Rechnern für die Steuerung komplexer technischer Anlagen, z.B. fürProduktionssysteme. Eins ist ihnen jedoch gemeinsam: Sie übernehmen vielfältige undkomplexe Regelungs- und Steuerungsaufgaben.In Abgrenzung zu herkömmlichen Computern treten anstelle der Schnittstelle Mensch-Maschine spezielle I/O-Schnittstellen zu dem umgebenden System. Das eingebetteteSystem kann mittels Sensorik bzw. Aktuatorik Eigenschaften aus der Umgebungablesen bzw. verändern - d.h. es ist dazu in der Lage, eigenständig zu agieren.Das meist nicht mögliche oder auch fehlende menschliche Eingreifen im Falle vonFehlermeldungen oder Ausfällen aufgrund falsch interpretierter Messwerte bzw. falschausgewählter Reaktionen verlangt bereits bei der Entwicklung der Systeme genaueKenntnis über die Systemumgebung in Form eines internen Modells. Um Gefahrendurch den Betrieb eingebetteter Systeme für Mensch und Umgebung zu vermeiden, sindhohe Sicherheits- und Zuverlässigkeitsanforderungen unter Berücksichtigung einerwirtschaftlich effizienten Entwicklung einzuhalten. Für den Nachweis gegenüberAuftraggebern oder Zulassungsbehörden bei genehmigungspflichtigen Produkten bzgl.der Einhaltung von Anforderungen, gesetzlichen Regelungen und Standards sindbesondere Tests eine unabdingbare Voraussetzung bei der Entwicklung eingebetteterSysteme [Fr01] [LR04].3

Kapitel 2: Qualität als Merkmal beim Entwurf eingebetteter SystemeIn Kapitel 2 wird der Begriff Qualität in Bezug auf eingebettete Systeme weiterabgegrenzt und ein kurzer Überblick über die Entwicklung und Testmethoden gegeben.Kapitel 3 befasst sich mit verschiedenen Analyse- und Testmethoden und stelltausgewählte Techniken näher vor.2 Qualität als Merkmal beim Entwurf eingebetteter Systeme2.1 Charakterisierung von QualitätsmerkmalenDas Qualitätsmerkmal Korrektheit hat grundsätzlich die gleiche Bedeutung wie bei derSoftwareentwicklung, d.h. die Funktion eines eingebetteten Systems gilt als korrekt,wenn sie konsistent zur funktionalen Spezifikation und fehlerfrei ist. Da die zuentwickelnden Systeme aufgrund zunehmender Komplexität und der Verwendungsoftware-basierter Entwicklungssysteme kaum mehr fehlerfrei sein können, werdenerhöhte Anforderungen an die Entwicklung gestellt, um Fehlfunktionen und Ausfälle imBetrieb auszuschließen [Li02] [SD02].Unter dem Begriff Sicherheit wird Sicherheit im technischen Sinne verstanden. Sieumfasst die Fähigkeit eines eingebetteten Systems, Gefährdungen für die Gesundheitund das Leben des Bedienpersonals, unbeteiligter Dritter sowie für die Umgebungaufgrund von Fehlfunktionen zu verursachen. Dazu müssen sämtliche Komponentendes Systems bei der Entwicklung soweit wie möglich gegen Ausfall,konstruktionsbedingte Fehlfunktionen sowie Fehlfunktionen der Systemumgebunggesichert werden [Fr01] [Li02].Zuverlässigkeit versteht sich als Maß für die Funktionstüchtigkeit eines Systems. Siewird in der Regel als Wahrscheinlichkeit, dass eine Funktion innerhalb einer vorherdefinierten Zeitdauer und unter vorher festgelegten Arbeitsbedingungen einwandfreiausgeführt wird, angegeben. Z.B. als „Mean Time to Failure“ (MTTF), demErwartungswert für die Zeitspanne bis zum Ausfall eines Systems, als „Mean Timebetween Failure“ (MTBF), dem Erwartungswert für die Zeitspanne zwischen zweiAusfällen oder als Überlebenswahrscheinlichkeit, die die Wahrscheinlichkeit angibt,dass ein System zu einem bestimmten Zeitpunkt intakt arbeitet. Zuverlässigkeit hängtdabei stark von der Art und Intensität der Systemnutzung ab [Li02].Verfügbarkeit ist ein Maß für die Fähigkeit, zu einem gegebenen Zeitpunktfunktionsfähig zu sein. Sie wird in der Wahrscheinlichkeit, dass das System zu einem4

Kapitel 2: Qualität als Merkmal beim Entwurf eingebetteter Systemegegebenen Zeitpunkt die geforderte Funktion unter definierten Arbeitsbedingungeneinwandfrei ausführt, ausgedrückt [Li02].Bei reaktiven Systemen ist Echtzeitfähigkeit eine wesentliche funktionaleQualitätseigenschaft, deren Nicht-Einhaltung zu kritischen Situationen bzw.Instabilitäten im System führen kann. Von harter Echtzeitfähigkeit wird gesprochen,wenn neben der inhaltlichen Korrektheit der Systemreaktion ebenso die genaueEinhaltung der gegebenen (oberen und unteren) Zeitschranken von Relevanz ist. Beinicht-reaktiven Systemen wird Echtzeitfähigkeit als eine nicht-funktionaleQualitätseigenschaft angesehen. Die Einhaltung von vorgegebenen Zeitschranken dientin diesem Fall z.B. einer erhöhten Benutzerfreundlichkeit, führt aber nicht zu kritischenoder instabilen Situationen. Diese Form wird weiche Echtzeitfähigkeit genannt [Fr01][Li02].2.2 Entwurf und Test eingebetteter SystemeDie Entwicklung eingebetteter Systeme unterliegt teils widersprüchlichenAnforderungen. Auftraggeber erwarten eine zügige Verfügbarkeit der Systeme, ummöglichst als erste am Markt präsent zu sein (time to market). Zeitgleich werden hoheAnforderungen an die Zuverlässigkeit der Systeme gestellt und aufgrund zunehmenderKomplexität und Heterogenität der Produkte rechner- und softwaregestützte Werkzeugeverwendet, die eine ebenso hohe Komplexität aufweisen. Ziel des Testens eingebetteterSysteme ist es, dass die aus der Spezifikation abgeleiteten Anforderungen in deneinzelnen Entwicklungsphasen (Abbildung 1) unter Berücksichtigung der beschriebenenQualitätsmerkmale konsistent umgesetzt werden und dass das System korrekt arbeitet[Da96].Gegenüber der herkömmlichen Softwareentwicklung besitzen Tests eingebetteterSysteme eine besondere Relevanz: Fehlerhaft auf den Massenmarkt ausgelieferteSysteme lassen sich nur schwer oder gar nicht korrigieren, Ausfälle von Systemen insicherheitskritischen Bereichen gelten als nicht akzeptabel. Zudem lassen sich„Patches“ zur Fehlerkorrektur meist nicht zu einem vertretbaren Preis realisieren oderkönnen evtl. gar nicht aufgespielt werden und die Nachbesserung erfordert teureRückrufaktionen.Präventive Techniken, die in den frühen Phasen der Entwicklung vor derImplementierung bzw. Fertigung eingesetzt werden, spielen eine besondere Rolle: Auf5

Kapitel 2: Qualität als Merkmal beim Entwurf eingebetteter SystemeModellen basierende Analysemethoden ermöglichen die Identifikation vonProblembereichen und potentiellen Fehlern sowie die Quantifizierung von Risiken undAusfallwahrscheinlichkeiten. Formale Beweistechniken erlauben einen vollständigenKorrektheitsbeweis vor der eigentlichen Fertigung eines Systems. Dies kannbeispielsweise auf Basis eines Vergleichs zwischen einer Schaltung, evtl. in einerformalen Sprache beschrieben, und der zugrunde liegenden Spezifikation erfolgen(siehe dazu [Kr99]).Nach der Implementierung rücken messende Techniken in den Vordergrund. Siebenötigen keine zugrunde liegenden Modelle und ermöglichen Tests direkt ameingebetteten System. Die durch Messungen gewonnenen Daten werden durchstochastische Analysen weiter verdichtet (siehe dazu [Da96] [Li02]). Die auf dieseWeise sich ergebenden Testergebnisse können neben dem Nachweis derKorrektheit/Fehlerfreiheit des Systems z.B. auch gegenüber Auftraggebern oderBehörden zum Nachweis der Einhaltung spezifischer Anforderungen und gesetzlicherRegelungen verwendet werden. Gegenüber den präventiven Methoden besitzen sieallerdings den Nachteil, dass identifizierte Problembereiche u.U. aufwendig undkostenintensiv nachgebessert werden müssen.Zusätzlich können grundsätzlich die aus der Softwareentwicklung bekanntendynamischen Methoden eingesetzt werden. Folgend werden drei verschiedenepräventive Methoden sowie zwei messende Techniken näher betrachtet.Abbildung 1: V-Modell (vgl. [GR02] S. 3; [Ba98] S. 101)6

Kapitel 3: Testtechniken für eingebettete Systeme3 Testtechniken für eingebettete Systeme3.1 Präventive, modellierende Analysemethoden3.1.1 Fehlermöglichkeits-, -einfluss- und -kritikalitätsanalyseDie Fehlermöglichkeits-, -einfluss- und –kritikalitätsanalyse [FG04b] [Fr89] [Li02] –folgend FMECA (Failure Modes, Effects and Criticality Analysis) genannt - ist eineWeiterentwicklung der FMEA (Failure Modes and Effects Analysis) aus den 60erJahren. Ursprünglich wurde sie zur Untersuchung der Flugsicherheit entwickelt, ist aberanschließend schnell in andere industrielle Bereiche vorgedrungen. Bei der FMECAhandelt es sich um eine sog. Vorwärtsanalyse. Das Ziel ist es, in den verschiedenenPhasen einer Produktentwicklung oder Prozessdefinition möglichst früh potentielleFehler zu erkennen, deren Folgen zu spezifizieren und diese zu bewerten. AufGrundlage dieser Bewertung lassen sich anschließend für die mit den größten Risikenbehafteten Fehler entsprechende Gegenmaßnahmen entwickeln und einleiten.Es wird zwischen der Komponenten-FMECA, der Prozess-FMECA und der System-FMECA unterschieden. Die Komponenten-FMECA untersucht ein Teil- bzw.Gesamtsystem auf alle denkbaren und möglichen Ausfälle. Dabei geht sie von derjeweiligen Funktion im System aus. Als Ursachen kommen konstruktive oderfertigungstechnische Fehler in Frage. Die Prozess-FMECA untersucht dagegen Fehlerin der Fertigung und Montage sowie deren Ursachen, um anschließend notwendigeVerbesserungsmaßnahmen zu definieren. Die System-FMECA betrachtet schließlichein Produkt bzw. System ganzheitlich. Im Folgenden wir der Ablauf der Methodeanhand der Komponenten-FMECA dargestellt.AnalysephaseDa mit Hilfe der FMECA bereits vor der eigentlichen Implementierung Fehler undderen Ursachen erkannt werden sollen, sind bei der Durchführung sämtliche verfügbareErfahrungen zu Problemen heranzuziehen. Dazu werden Mitarbeiter ausverschiedensten Bereichen, z.B. Entwicklung, Fertigungsplanung, Fertigung,Qualitätssicherung etc., hinzugezogen.Zuerst werden alle Stammdaten einer zu untersuchenden Komponente und derenUntergruppen inkl. Schnittstellen zu anderen (Teil-)Systemen erfasst. Anschließend7

Kapitel 3: Testtechniken für eingebettete Systemewerden alle Funktionen der Komponente näher beschrieben und alle potentiellen Fehlernotiert. Alle bedeutet, dass die Fehler unabhängig davon betrachtet werden, wiewahrscheinlich das Auftreten oder die Folgen eines Fehlers zu bewerten sind. Wichtigfür die umfassende Auflistung aller potentiellen Fehler sind Erfahrungen aus derBranche, aus der Entwicklung von Vorgängern sowie Erkenntnisse aus der Entwicklungvon früheren Prototypen und bereits im Vorfeld durchgeführten FMECAs. DieVollständigkeit der Auflistung kann zudem durch Methoden der Teamarbeit wieBrainstorming verbessert werden.Im nächsten Schritt werden unter der Annahme, dass ein Fehler aufgetreten ist, diepotentiellen Folgen des Fehlers untersucht. Maßgeblich für die Beschreibung der Folgenist zum einen, wie sich die Wirkung des Fehlers im System oder bei der Montagedarstellt und zum anderen, wie der Kunde bzw. der Anwender die Fehlerfolgenempfinden würde. Im letzten Schritt der Analysephase werden den potentiellen FehlernUrsachen zugeordnet. Diese sind so genau zu beschreiben, dass sich hierausentsprechende Maßnahmen zur Fehlervermeidung ableiten lassen.RisikobewertungIn der zweiten Phase der FMECA werden den in der Analysephase identifiziertenpotentiellen Fehlern Risikoprioritätszahlen zugeordnet sowie für die jeweilige Funktionder Komponente bereits bestehende bzw. vorgesehene Prüfmaßnahmen dokumentiert.Unter diesen sind sämtliche Maßnahmen zu verstehen, die dazu dienen, Fehler zuvermeiden sowie auftretende Fehlerursachen und Fehler zu entdecken. DieseMaßnahmen stammen in der Regel aus Spezifikationen, Prüfvorschriften,Industriestandards, gesetzlichen Vorschriften sowie unternehmensspezifischenVorgehensweisen. Zur Berechnung der Risikoprioritätszahl werden dieEintrittswahrscheinlichkeit für den potentiellen Fehler, die Bedeutung der Folgen sowiedie Wahrscheinlichkeit des Nicht-Entdeckens des potentiellen Fehlers auf einer Skalavon 1 bis 10 bewertet und anschließend das Produkt gebildet.Die Eintrittswahrscheinlichkeit für den potentiellen Fehler bewertet die angenommeneHäufigkeit sämtlicher erwarteter Ausfälle innerhalb der geplanten Lebensdauer derKomponente. Die geplante Lebensdauer schließt die Lebensdauer des umgebendenSystems ein. Die Bewertung erfolgt auf einer Skala von 1 bis 10 für ein sehrunwahrscheinliches Auftreten bis zu einem sehr wahrscheinlichen Auftreten –8

Kapitel 3: Testtechniken für eingebettete Systemevollkommen unabhängig von anderen Parametern wie zu erwartenden Prüfmaßnahmenoder der Relevanz des Fehlers.Die Bedeutung der Folgen bewertet die erwarteten Auswirkungen eines potentiellenFehlers aus Sicht des Kunden bzw. Anwenders. Die Skala beginnt bei 1 für eine sehrgeringe Wahrscheinlichkeit, dass der Fehler wahrnehmbare Auswirkungen auf dasVerhalten des Systems gegenüber dem Kunden aufzeigt bzw. dass der Kunde denFehler überhaupt bemerkt. Sie endet bei 10 für einen äußerst schwerwiegenden Fehler,der mit sehr hoher Wahrscheinlichkeit wahrgenommen wird und möglicherweise dieSicherheit der Umgebung beeinträchtigt.Unter der Annahme, dass die Ursache des potentiellen Fehlers eingetreten ist, bewertetdie Wahrscheinlichkeit des Nicht-Entdeckens die Wirksamkeit aller derzeitigvorgesehener Prüfmaßnahmen vor Auslieferung des Systems an den Kunden. Die Skalabeginnt bei 1 für eine sehr hohe Wahrscheinlichkeit des Entdeckens und endet bei 10für eine sehr niedrige Wahrscheinlichkeit des Entdeckens, z.B. bei Fehlern, die erstnach einiger Gebrauchszeit auftreten.Das Gesamtrisiko eines potentiellen Fehlers wird nun mit der Risikoprioritätszahlermittelt, dem Produkt aus der Eintrittswahrscheinlichkeit, der Bedeutung der Folgensowie der Wahrscheinlichkeit des Nicht-Entdeckens. Die Risikoprioritätszahl ist keine„echte“ Wahrscheinlichkeitsangabe, gilt aber als einheitliches Maß für das Gesamtrisikoeines potentiellen Fehlers. Durch die Verwendung der Ordinalskala macht sieverschiedene Fehlermöglichkeiten miteinander vergleichbar: Umso größer dieRisikoprioritätszahl, umso mehr Einfluss hat ein potentieller Fehler auf die Sicherheitund Zuverlässigkeit eines Systems und umso bedeutender sind Maßnahmen, die dasRisiko senken können.MaßnahmenentwicklungNach der Risikobewertung erfolgt der eigentliche Kernpunkt der FMECA: Anhand dervorausgegangenen Analyse und Risikobewertung werden geeignete Maßnahmenbeschlossen, um die identifizierten Fehlerursachen zu vermeiden, z.B. durchkonstruktive oder fertigungstechnische Verbesserungen. Dies geschieht sukzessivbeginnend mit den Fehlerursachen, die die höchste Risikoprioritätszahl aufweisen. Nachdem Beschluss der Maßnahmen wird das Restrisiko der Fehlerursachen erneut mittelsBerechnung der Risikoprioritätszahl quantifiziert und in die Rangfolge derFehlerursachen eingeordnet.9

Kapitel 3: Testtechniken für eingebettete SystemeSystem/KomponenteESKlimaautomatikPotentielleFehlerLeiterbahn aufHauptplatineunterbrochenController-chipohne KontaktPotentielleFolgengestörte oderkeine Funktionder Klimaautomatikgestörte oderkeine Funktionder KlimaautomatikPotentielleFehlerursachenThermischeÜberlastungaufgrundAussentemperaturPrüfmaßnahmen I II III RPZEmpfohleneGegenmaßnahmen5 8 8 320 MaterialfestlegungüberprüfenTransportschaden 7 8 8 448 Einsatz spezifischerTransportmittelChipsockelaußerhalb der Normvisuelle Kontrolle,Funktionsprüfung6 8 10 480 Spezifikation mit Sockel-/Chiplieferant überprüfenArbeitsfehler beimEinsetzen des ChipDerzeitiger ZustandTemperaturprüfung2Std, 80°C; elektr.FunktionsprüfungTabelle 1: FMECA "ES Klimaautomatik" (vgl. [Fr89] S.49)5 8 9 360 Arbeitsplan überprüfenTabelle 1 zeigt einen Ausschnitt aus einer Beispiel-FMECA, die für eineKlimaautomatik in der KFZ-Zuliefererindustrie angefertigt wurde. Die Auswertungergibt, dass für die Fehlerursache „Chipsockel außerhalb der Norm“ die höchsteRisikoprioritätszahl berechnet wurde. Neben dem potentiellen Fehler finden sichebenfalls die Auswirkungen für den Kunden bei Auftreten des potentiellen Fehlers –Ausfall der Klimaautomatik – sowie derzeitige Prüfmaßnahmen und empfohleneGegenmaßnahmen wieder, um den Fehler zu vermeiden. Aufgrund der hohenRisikoprioritätszahl sind die vorgeschlagenen Gegenmaßnahmen zuerst durchzuführen.Anschließend wird die Risikoprioritätszahl erneut ermittelt und sukzessiv weiterepotentielle Fehlerursachen abgearbeitet bis alle Risikoprioritätszahlen ein akzeptablesNiveau erreicht haben.3.1.2 FehlerbaumanalyseDas Ziel der Fehlerbaumanalyse [FG04c] [Fr01] [IONM03] [Li02], eine in den 60erJahren entwickelte Methode, ist die Analyse von sicherheitskritischen Ausfällen und dieÜberführung in ein grafisches Modell, dem sog. Fehlerbaum. Dieser stellt denZusammenhang zwischen verschiedenen Ursachen und einer damit verbundenenbestimmten Wirkung dar.Die Basis der Methode stellt ein Modell des Systems dar. Der Vorteil der Verwendungeines Modells ist, dass sich die Analyse präventiv in einer frühen Entwicklungsphasedurchführen lässt. Dies ermöglicht die frühzeitige Identifikation von Problemen undhilft, größere kostspielige Modifikationen am System nach der Implementierung zuvermeiden. Zudem gilt der Fehlerbaum als leicht verständliches und anwendbaresMittel. Als nachteilig anzusehen ist der Aufwand für die Erstellung und Anwendung desModells, die Erfahrung mit und genaue Kenntnis von dem System erfordern. Die10

Kapitel 3: Testtechniken für eingebettete SystemeQualität des Modells bzw. die Übereinstimmung der Realität mit dem Modell spielt eineentscheidende Rolle für die Verlässlichkeit der Ergebnisse dieser Methode.Die Fehlerbaumanalyse gliedert sich in einen qualitativen als auch in einenquantitativen Bereich. Bei der qualitativen Analyse werden ausgehend von einemunerwünschten (Top-)Ereignis – in der Regel ein Komponenten- oder Teilsystemausfall– systematisch die Ursachen des Ereignisses bis hin zu nicht mehr zerlegbarenBasisereignissen ermittelt und durch logische Verknüpfungen miteinander in Beziehunggesetzt. Die Analyse umfasst neben den Systemfunktionen dieUmgebungsbedingungen, die Systemkomponenten sowie die Organisation und dasVerhalten des Systems. Durch die Kenntnis von Zuverlässigkeitskenngrößen in Formvon Wahrscheinlichkeiten für das Eintreten von Basisereignissen lassen sich in derquantitativen Analyse entsprechende Zuverlässigkeitskenngrößen für das Top-Ereignisermitteln. Die Kenntnis von einem Top-Ereignis beruht dabei entweder auf Erfahrungenoder Dokumentationen funktionsgleicher/-ähnlicher Systeme oder auf gedanklichenProzessen, die vor der erstmaligen Implementierung durchgespielt werden.Ein Fehlerbaum selbst repräsentiert eine hierarchische bool’sche Funktion, die ausmehreren Ebenen mit Ereignissen besteht. Die Basisereignisse auf der untersten Ebenesind z.B. Geräte-, Bedien- oder Softwarefehler. Die Verknüpfung von Ereignissenerfolgt durch verschiedene logische Operatoren, sog. Gates. Geht von einem Ereignisder Wert 1 (wahr) aus, bedeutet dies den Ausfall eines Funktionselements. Bei demWert 0 (falsch) liegt eine intakte Situation vor. Für die Modellierung stehen u.a.folgende Elemente zur Verfügung:Eine Nicht-Verknüpfung, die den Eingangswert negiert wieder ausgibt, eine Und-Verknüpfung, deren Ausgang nur wahr wird, wenn alle Eingangswerte wahr sind sowieeine Oder-Verknüpfung, deren Ausgang wahr wird, sobald an einem Eingang ein Signalanliegt. Ferner gibt es ein Symbol, um Exklusiv-Oder-Bedingungen darzustellen, beidem der Ausgang genau dann wahr wird, wenn genau ein Eingangswert wahr ist. Dassog. m/n-Gate besitzt n Eingänge und einen Ausgang. Der Ausgang wird genau dannwahr, wenn mindestens m der Eingangswerte wahr sind. Die quantitative Analyse einesFehlerbaums mit Wahrscheinlichkeiten setzt voraus, dass nur die eben genanntenVerknüpfungen für den Fehlerbaum verwendet werden. Für komplexere Situationenstehen weitere Symbole zur Verfügung, die allerdings eine quantitative Analyseausschließen:11

Kapitel 3: Testtechniken für eingebettete SystemeMit der Sekundär-Verknüpfung können durch einen Primärausfall verursachteSekundärausfälle beschrieben werden. Dies heißt konkret: Ändert sich der Wert desersten Eingangs von falsch zu wahr, wird der Wert des Ausgangs mit einer durch denzweiten Eingang beschriebenen Dauer und Wahrscheinlichkeit ebenfalls auf wahrgestellt.Abbildung 2: Fehlerbaumsymbole (vgl. [Li02] S. 435)Die Reserve-Verknüpfung dagegen realisiert redundante Funktionseinheiten, in demmittels Umschaltvorrichtungen von dem ersten Eingang automatisch auf den zweitenEingang umgeschaltet wird, sobald am ersten Eingang das Signal wahr anliegt. Eineweitere Umschaltvorrichtung ermöglicht das Zurückschalten, z.B. nach einer erfolgtenReparatur oder einem Austausch der defekten Funktionseinheit. Sollten beideFunktionseinheiten an den Eingängen der Reserve-Verknüpfung den Wert wahr füreinen Ausfall einnehmen, wird auch der Ausgang der Reserve-Verknüpfung auf wahrgestellt. Ein Anwendungsbeispiel sind Umschaltvorgänge bei einem Stromausfall aufNotstromaggregate und zurück. Weitere Symbole dienen z.B. für die Darstellung vonSignaleingängen und Kommentaren. Abbildung 2 gibt einen Überblick über diegrafische Darstellung der Symbole.Anhand des Beispiels in Abbildung 3 wird im Folgenden die qualitative sowiequantitative Analyse näher erläutert. Dargestellt wird ein Fehlerbaum für einLenkungssystem aus dem KFZ-Bereich, Stichwort „Steer-by-Wire“. Untersucht werdensoll die Wahrscheinlichkeit für einen Ausfall des Systems innerhalb der ersten 10Betriebsjahre. Das System besteht aus einer mechanischen sowie einer12

Kapitel 3: Testtechniken für eingebettete Systemeelektrisch/elektronischen Komponente. Aufgrund von gesetzlichen Vorgaben bestehtLetztere aus zwei redundant geschalteten Subsystemen. Sollte Subsystem 1, ausfallenwird die Funktion vollständig von Subsystem 2 übernommen. Als Basisereignisse füreinen Systemausfall kommen u.a. Fehler bzw. Defekte im Bereich der Kabel in Frage.Aufgrund statistischer Untersuchungen in der Vergangenheit ist bekannt, dass an einemKabel mit einer Wahrscheinlichkeit von 1% innerhalb der nächsten 10 Jahre ein Defektauftritt. Die Fehlerquote bzgl. der Mechanik ergibt sich aus einem anderen Fehlerbaum.Andere Angaben ergeben sich analog.Abbildung 3: Fehlerbaum "Lenkung"Die quantitative Analyse des Fehlerbaums erfolgt auf Basis der Ausfallfunktion F. F(t)gibt die Wahrscheinlichkeit an, eine Funktionseinheit zu einem bestimmten Zeitpunktausgefallen anzutreffen. Die Ausfallfunktion für den Ausgang einer Und-Verknüpfungergibt sich aus dem Produkt der Ausfallfunktionen der n Eingänge:F ( t)=An∏i=1F ( t)i13

Kapitel 3: Testtechniken für eingebettete SystemeDie Ausfallfunktionen für den Ausgang einer Oder-Verknüpfung berechnet sich wiefolgt:F ( t)= 1−Damit ergibt sich für die Ausfallfunktion der obersten Oder-Verknüpfung des Beispielsfolgende Berechnung:FAAn∏i=1(1 − F ( t))(( 1−F )*( 1−F )) = 1−( 0,9 * 0,9534) ≈ 0,1420 14,20%=Ei1−4=Die Berechnungen besitzen allerdings nur Gültigkeit, wenn die miteinander verknüpftenEreignisse stochastisch unabhängig voneinander sind. Im Falle der Identitätverwendeter Ereignisse, d.h. ein Ereignis wird mehrfach als Basisereignis einesFehlerbaums angegeben, liegt eine spezielle Form der stochastischen Abhängigkeit vor.Diese lässt sich unter Anwendung der de Morgan’schen-Regeln auflösen, in dem derFehlerbaum so umgeformt wird, dass jedes Basisereignis maximal einmal imFehlerbaum vorkommt.3.1.3 Markov-AnalyseDie Markov-Analyse [FG04d] [Li02] [Si04] ist ebenfalls eine Technik für dieSicherheits- und Zuverlässigkeitsmodellierung. Sie basiert auf der Idee, eineKomponente oder ein System mit einem erweiterten Zustandsautomaten zu modellieren.Die einzelnen Zustände stellen z.B. den normalen Betriebszustand, einenfehlerbehafteten (reparierbaren) Zustand und den Zustand des Totalausfalls dar (sieheAbbildung 4).Abbildung 4: Zustandsautomat Markov-AnalyseDie möglichen Zustände des Automaten werden zudem mit Zustandsübergängenversehen und jeder Übergang durch eine Übergangswahrscheinlichkeit charakterisiert.Dies sind in der Regel die sog. Fehlerwahrscheinlichkeit λ sowie die14

Kapitel 3: Testtechniken für eingebettete SystemeReparaturwahrscheinlichkeit µ. Die Fehlerwahrscheinlichkeit ist z.B. dieWahrscheinlichkeit λ 1-2 , dass der Automat vom normalen Betriebszustand in denfehlerbehafteten Zustand übergeht. Die Reparaturwahrscheinlichkeit µ 2-1 wiederum gibtdie Wahrscheinlichkeit an, dass der Automat vom fehlerbehafteten Zustand in dennormalen Betriebszustand übergeht. Der Übergang zeigt damit die erfolgreicheReparatur der Komponente an.In Abhängigkeit von einem bestimmten Zeitpunkt lässt sich nun die Wahrscheinlichkeitberechnen, dass sich die Komponente bzw. das System in einem bestimmten Zustandbefindet. Das Besondere bei der Markov-Analyse ist die Eigenschaft, dass derzukünftige Zustand der Komponente nur von dem gegenwärtigen Zustand festgelegtwird und von früheren Zuständen unabhängig ist. Alle Informationen über frühereZustände sind in dem gegenwärtigen Zustand enthalten. Die Wahrscheinlichkeit desSystems, sich in einem fehlerbehafteten Zustand oder im Zustand des Totalausfalls zubefinden, wird als ein Maß für die Unzuverlässigkeit angesehen.Die Markov-Analyse soll an dem Beispiel aus Abbildung 4 kurz dargestellt werden:Dazu wird neben dem beschriebenen Zustandsraum eine Anfangsverteilung benötigt.Sie gibt die initialen Aufenthaltswahrscheinlichkeiten der einzelnen Zustände an, alsodie Wahrscheinlichkeit, dass sich die Komponente bei Initialisierung (Zeitpunkt t=0) ineinem bestimmten Zustand befindet. Die bereits beschriebenenÜbergangswahrscheinlichkeiten werden in der sog. Übergangsmatrix festgehalten.Anfangsverteilung:Übergangsmatrix:p ( 0) =( 0,90 0,05 0,05)⎛ 0,95⎜P = ⎜0,40⎜⎝ 00,050,4000 ⎞⎟0,20⎟1,00 ⎟⎠Aus dem Zustandsraum, der Anfangsverteilung und der Übergangsmatrix lässt sich z.B.die Wahrscheinlichkeit, dass sich die Komponente zum Zeitpunkt t=3 in einembestimmten Zustand befindet, wie folgt berechnen:p(3)= p(0) * P=( 0,8285 0,0704 0,1011)3=( 0,90 0,05 0,05)⎛0,8875⎜* ⎜0,5954⎜⎝ 00,07440,068900,0381⎞⎟0,3358⎟1 ⎟⎠15

Kapitel 3: Testtechniken für eingebettete Systemeden Vorteil, dass nicht nur zufälliges Fehlverhalten, z.B. zufällige Fehlreaktionenaufgrund von Materialermüdungen, sondern auch systematische Fehler aufgedecktwerden.Abbildung 5: Back-to-Back-Test (vgl. [Li02] S. 176)Für den Back-to-Back-Test, der hauptsächlich in der Phase des Modultests eingesetztwird, werden mehrere Teams beauftragt, das System auf Basis der gleichenSpezifikation zu implementieren. Um gehaltvolle Aussagen aus dem Back-to-Back-Testzu erhalten, ist es wichtig, dass die an der Entwicklung beteiligten Teams vollkommenunabhängig voneinander arbeiten. Nur so kann gewährleistet werden, dass gleichartigesystematische Fehler nicht mit in die Entwicklung einfließen. Nach erfolgterImplementierung werden die Systeme mit identischen Testdaten versorgt und derenErgebnisse miteinander verglichen. Bei Identität der Testergebnisse wird auf dieKorrektheit der Systeme geschlossen, während bei unterschiedlichen Testergebnissendie Ursachen festgestellt und behoben werden müssen.Durch die Identität der Testergebnisse wird implizit auf die Korrektheit derImplementierung bzgl. der zugrunde liegenden Spezifikation geschlossen. Dies bedeutetjedoch zugleich, dass trotz identischer Testergebnisse – gemäß der Spezifikation alskorrekte Testergebnisse aufgefasst - ein Fehlverhalten der Systeme vorliegen, z.B. wenndie Systeme zufällig fehlerhafte, aber identische, Testergebnisse produzieren. Diesverdeutlicht die Relevanz der Unabhängigkeit der Entwicklungen, um systematischeFehler zu vermeiden, sowie den Bedarf nach weiteren Testverfahren.18

Kapitel 3: Testtechniken für eingebettete SystemeDie redundante Entwicklung der Systeme verursacht ebenfalls um den Faktor n höhereEntwicklungskosten, wobei n für die Anzahl der zu entwickelnden Versionen steht. Umdiese wirtschaftlich sinnvoll begründen zu können, sind diverse Voraussetzungen zuerfüllen: Das System ist in der Spezifikation exakt auf die notwendigen Funktionalitätenabzugrenzen, um die Komplexität bzgl. Eingaben und Ausgaben in Grenzen zu halten.Der Anwendungsbereich besteht aus möglichst kleinen Funktionseinheiten, diesicherheitskritischen Aspekten unterliegen. Deren Reaktionen und Ausgaben solltenmöglichst einfach sein, um den Vergleich der Testergebnisse simpel zu gestalten.Zudem sollte die Anzahl durchzuführender Testfälle möglichst groß sein sowieweitestgehend automatisiert bearbeitbar sein.3.2.2 Hardware in the Loop-TestDie Grundidee beim Hardware-in-the-Loop-Test [Hö99] [Li02] [Sp01] liegt in derRealisierung von Testszenarien unter weitgehender Simulation der Umgebung desTestobjekts. Dazu werden die Schnittstellen des Testobjekts durch elektrischeSimulationen nachgebildet, deren Steuerung ein Simulator – in der Regel einentsprechend ausgestattetes PC-System – übernimmt. Auf Basis eines vorher erstelltenSimulationsmodells lassen sich komplexe Verhaltensmuster der simulierten Gerätenachbilden und die Reaktionen und Ausgaben des Testobjekts untersuchen. ZumEinsatz kommt diese Testmethode neben der Phase des Integrationstests beimFunktions- und Systemtest. Anhand des Einsatzes des Simulationsmodells VeLoDyn fürdie Echtzeitsimulation der Fahrzeuglängsdynamik von Kraftfahrzeugen und dem Testvon Steuergeräten [GR02] werden folgend die Anforderungen und Potentiale an einSimulationssystem erläutert.Bei der Entwicklung eines Simulationssystems muss mitunter die Vernetzung diverserHardware- und Softwarekomponenten wie Simulationshardware, Messgeräte,Applikationen, Simulationsmodelle etc. berücksichtigt werden. Außerdem bedarf es derVerwaltung einer größeren Menge von Testdaten, sog. Profilen, sowie der Ablage vonTestergebnisse in geeigneten Systemen.Zur weiteren Testdurchführung wird ein sog. Simulator benötigt. Dieser besteht in derRegel aus einer (echzeitfähigen) Simulationshardware, entsprechenden für dieSimulation notwendigen I/O-Schnittstellen sowie diversen Applikationen zurTestablaufsteuerung, Messung der Testergebnisse, Auswertung und19

Kapitel 3: Testtechniken für eingebettete SystemeDokumentationserzeugung (Abbildung 6). Mittels einer Steuerungssoftware auf demKontrollsystem ist es möglich, Testprozesse zu parametrisieren als auch zu visualisierenund somit Einfluss auf die Umgebung des Testobjektes zu nehmen. Simulationen ineinem festen Zeittakt gewährleisten die Untersuchung von Anforderungen an dieEchtzeitfähigkeit des Testobjekts.Abbildung 6: Testsystem für Hardware-in-the-Loop-TestsDer Ablauf eines Testprozesses wird dabei nicht rein zufällig bestimmt, sondern eswerden sog. Testprofile eingesetzt. Diese enthalten vorher definierte Stimuli, diewährend der Simulation an die Schnittstellen des Testobjekts übertragen werden. Beider Auswahl der Stimuli ist auf eine möglichst gute Kombination von Eingangs- undAusgangssignalen für den Test zu achten, damit für den geplanten realen Einsatz desTestobjekts repräsentativ kritische Grenz- und Fehlerfälle ebenso gut abgedeckt sindwie normale Betriebszustände.Beispielsweise erlaubt die Modularisierung des Simulationsmodells VeLoDyn dasumfassende Testen eines Steuergeräts: Das Modul „Getriebe-Steuergerät“ realisiert diedirekte Anbindung des Steuergeräts an das Modell. Hier werden einerseits Reaktionenund Ausgaben über die Aktuatoren des Steuergeräts in den Simulator eingelesen alsauch Sensorsignale wie Umdrehungszahlen für das Steuergerät generiert. Mit demModul „Fahrzeug und Umgebung“ werden alle relevanten Teile des Fahrzeugs von derMotorisierung über die Bedienelemente bis zur Umgebung des Fahrzeugs simuliert. Mit20

Kapitel 3: Testtechniken für eingebettete Systemedem Modul „Fahrautomat“ werden zufällige und vorher definierte Fahrzuständenachgebildet. Die Integration der Module erlaubt zusätzlich die vollständigeAutomatisierung des Testablaufs.Durch die Simulation lassen sich Fehler explizit in das Modell injizieren. Kurzschlüsse,offene Leitungen oder Spannungsabfälle im Bordnetz sowie Defekte von mechanischenKomponenten lassen sich durch den Simulator nachstellen. Unabhängig von der realenUmgebung können so extreme Umweltbedingungen durch Änderung der Parametersimuliert und Tests von Gefahrensituationen (Crashtests, Auslösungen von Airbags etc.)gefahrlos und kostenoptimal durchgeführt werden.Die Diagnose der durchgeführten Simulation wird anschließend gegen einFehlerlastenheft automatisch geprüft und dokumentiert. In der Dokumentation werdensowohl Eingabe-/Ausgabewerte als auch entsprechende Auswertungen in Form vonTabellen und Diagrammen festgehalten. Anschließend wird mit den nächsten Testsfortgefahren. Die automatisierte Dokumentation gewährleistet zusätzlich einestandardisierte Form der Testergebnisse und damit das schnelle Einarbeiten für neue anden Tests beteiligte/interessierte Personen.Die Entwicklung eines Simulationssystems erfordert einen hohen zeitlichen Aufwandsowie entsprechende Entwicklungskosten. Nachhaltige wirtschaftliche Vorteile stellensich vor allem durch die Automatisierung der Testabläufe und die weitestgehendeWiederverwendung des Systems heraus. Durch eine Formalisierung desSimulationssystems wird dieser Aspekt zusätzlich gefördert. Positive Effekte ergebensich bereits nach wenigen Zyklen durch eine Reduktion des zeitlichen Testaufwands.[GR02] und [Hö99] berichten von Reduktionen von Prüfzeiten zwischen 50% bis 90%in Folgeprojekten gegenüber dem erstmaligen Einsatz.In Verbindung mit dem Rapid Prototyping sind Tests auf die korrekte Funktionsweisedes Testobjekt bereits vor der eigentlichen Implementationsphase möglich. Zudemermöglichen Hardware-in-the-Loop-Tests die Nutzung von Βeobachtungspunkten, diebei Tests in der realen Welt nicht oder nur schwer zugänglich wären. Simulationen infesten Zeittakten ermöglichen die Validierung von geforderten hartenEchtzeitfähigkeiten. Ferner werden Tests im Geräteverbund durchführbar, die zu einerReduktion von Schnittstellen zu anderen Geräten während des Tests und damit desTestaufwands im apparativen sowie personellen Bereich führen.21

Kapitel 4: Schlussbetrachtung4 SchlussbetrachtungDer Einsatz eingebetteter Systeme in sicherheitskritischen Szenarien stellt erhöhteAnforderungen an die Qualitätsmerkmale Sicherheit, Zuverlässigkeit und Verfügbarkeitder Systeme. Um diese zu gewährleisten und nachzuweisen bedarf es spezifischerTesttechniken. Gegenüber der herkömmlichen Softwareentwicklung ist auswirtschaftlichen Gründen ein erhöhter Aufwand für das Testen eingebetteter Systemenotwendig, um aufwendige und kostspielige Modifikationen nach der Implementierungoder gar Auslieferung an den Kunden zu vermeiden.Präventive Techniken unterstützen effektiv die frühzeitige und systematischeIdentifikation von Problemebereichen, deren Ursachen und Risiken. Zudem tragen siezur Vermeidung von nicht-notwendigen Entwicklungskosten durch Fehlentwicklungenbei. Zur Steigerung ihrer Effizienz gilt es zur einfachen Verständlichkeit undHandhabbarkeit eine präzise semantische Beschreibung hinzuzufügen, die eineIntegration in Entwicklungssysteme zur Steigerung der Reproduzierbarkeit,Wiederverwendungsrate und Wirtschaftlichkeit gewährleisten.Messende Techniken wie der Back-to-Back-Test und der Hardware-in-the-Loop-Testermöglichen eine kostenoptimale Automatisierung von ganzen Testsequenzen. Diesermöglicht den Nachweis der Korrektheit eingebetteter Systeme gegenüberAuftraggebern und Behörden unter wirtschaftlich effizienten Gesichtspunkten. DurchTesttechniken aus dem Bereich der Softwareentwicklung lassen sich die spezifischenTesttechniken z.B. für unkritische Bereiche sinnvoll ergänzen.22

LiteraturverzeichnisLiteraturverzeichnis[Ba98][Da96][FG04a][FG04b][FG04c][FG04d]Helmut Balzert: Lehrbuch der Software-Technik: Software-Management,Software-Qualitätssicherung, Unternehmensmodellierung, Spektrum, Akad.Verlag, 1998.Mario Dal Cin: Rechnerarchitektur: Grundzüge des Aufbaus und derOrganisation von Rechnerhardware, Teubner, 1996.Fraunhofer-Gesellschaft: Eingebettete Systeme, Fraunhofer Gesellschaft zurFörderung der angewandten Forschung e.V., April 2004,http://www.visek.de/?2981Fraunhofer-Gesellschaft: Failure Modes and Effects Analysis (FMEA),Fraunhofer Gesellschaft zur Förderung der angewandten Forschung e.V.,April 2004, http://www.visek.de/?15200Fraunhofer-Gesellschaft: Fault Tree Analysis (FTA), FraunhoferGesellschaft zur Förderung der angewandten Forschung e.V., April 2004,http://www.visek.de/?15244Fraunhofer-Gesellschaft: Markov-Analyse, Fraunhofer Gesellschaft zurFörderung der angewandten Forschung e.V., April 2004,http://www.visek.de/?15246[Fr89] Wolf D. Franke: FMEA: Fehlermöglichkeits- und –einflußanalyse, 2.überarb. Auflage, Verlag Moderne Industrie, 1989.[Fr01][GR02][Hö99]Martin Fränzle: Eingebette Systeme I: Skriptum zur Vorlesung imWintersemester 2001/02, Fachbereich Informatik der Carl von OssietzkyUniversität, 2001, http://ca.informatik.uni-oldenburg.de/~fraenzle/ES-I-WS0102/skript-ES-I.pdfClemens Gühmann, Jens Riese: Testautomatisierung in der Hardware-inthe-LoopSimulation, IAV GmbH, Mai 2002, http://www.mdt.tuberlin.de/publ/pdf/Autoreg2002-7.pdfHans-Martin Hörcher: Testautomation in der Telekommunikation, in:Softwaretechnik-Trends, Band 19, Heft 1, Februar 1999,http://pi.informatik.unisiegen.de/stt/19_1/19_1_fg217_beitraege/19_1_fg217_TAV6hoe.ps[IONM03] IO new management: Risiken systematisch idnetifizieren und bewerten, IOnew management: Zeitschrift für Unternehmenswissenschaften undFührungspraxis, Nr. 09_03, o. Seitenangabe, HandelsZeitung FachverlagAG, 2003[Ka02]Bernhard Kaiser: Integration von Sicherheits- und Zuverlässigkeitsmodellenin den Entwicklungsprozess Eingebetteter Systeme, in: Softwaretechnik-Trends, Band 22, Heft 4, November 2002, http://pi.informatik.unisiegen.de/stt/22_4/03_Technische_Beitraege/Kaiser_02_Integration.ps23

Literaturverzeichnis[Ka03][Kr99][Li02][LR04][SD02]Bernhard Kaiser: A Fault-Tree Semantics to model Software-ControlledSystems, in: Softwaretechnik-Trends, Band 23, Heft 3, August 2003,http://pi.informatik.unisiegen.de/stt/23_3/03_Technische_Beitraege/Kaiser_03_SWT.psThomas Kropf: Introduction to formal hardware verification, Springer,1999.Peter Liggesmeyer: Software-Qualität: Testen, Analysieren und Verifizierenvon Software, Spektrum, Akad. Verlag, 2002.Peter Liggesmeyer, Martin Rothfelder: Sicherheit und Zuverlässigkeiteingebetteter Systeme: Realisierung, Prüfung und Nachweis,Seminarunterlage, DIA Deutsche Informatik-Akademie, 2004.Axel Sikora, Rolf Drechsler: Software-Engineering und Hardware-Design:Eine systematische Einführung, Carl Hanser Verlag, 2002.[Si04] Christian Siegel: Facharbeit Mathematik: Markov-Ketten, April 2004,http://www.siegel-christian.de/seiten/facharbeit/markow.html[Sp01]Bernhard Spitzer: Modellbasierter Hardware-in-the-Loop Test voneingebetteten Systemen, Dissertation, Universität Fridericiana Karlsruhe,Dezember 2001, http://www.ubka.uni-karlsruhe.de/cgibin/psgunzip/2001/elektrotechnik/12/12.ps24