Deliverable D_MT_2.2_3 Nachweis der Gleichwertigkeit von Software-Artefakten, Phase 3 Version 1.0
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Deliverable D_MT_2.2_3
Nachweis der Gleichwertigkeit von Software-Artefakten,
Phase 3
Version 1.0
Projektbezeichnung SPES 2020
Verantwortlich Dr. Hans-Werner Wiesbrock
QS-Verantwortlich
Erstellt am 14.09.2010
Zuletzt geändert 26.01.2012 17:53
Freigabestatus Vertraulich für Partner
X ProjektöffentlichNachweis der Gleichwertigkeit von Software-Artefakten, Phase 3
Öffentlich
Bearbeitungszustand in Bearbeitung
X vorgelegt
fertig gestellt
Zuletzt geändert: 26.01.2012 17:57 2/69Weitere Produktinformationen
Erzeugung Hans-Werner Wiesbrock (HWW)
Mitwirkend Sadegh Sadeghipour (Sad)
Änderungsverzeichnis
Änderung
Geänderte
Beschreibung der Änderung Autor Zustand
Kapitel
Nr. Datum Version
3 21.12.11 0.9 Kap. 4 & 5 Ergänzung: Kap. 4.10, HWW
5.1,5.2,5.3. ,5.5
Überarbeitung Kap. 5.4
4 26.01.12 1.0 Alle Allgemeine Überarbeitung SadNachweis der Gleichwertigkeit von Software-Artefakten, Phase 3 Kurzfassung Dieses Dokument präsentiert die dritte Phase der MT-Task 2.2 Nachweis der Gleichwertigkeit von Software-Artefakten (Deliverable D_MT_2.2_3). Der Anwen- dungskontext ist die erneute Zertifizierung einer schon zertifizierten sicherheitskriti- schen medizintechnischen Software-Komponente, die neu implementiert wurde. Die Kriterien der Gleichwertigkeit von Software-Komponenten, vor allem Werte- und Zeittoleranzen zwischen den Ausgangsgrößen der beiden zu vergleichenden Kom- ponenten, werden auf der Basis der Risikoanalyse berechnet und festgelegt. Nach- weis der Gleichwertigkeit kann im Hinblick verschiedener Aspekte erfolgen. Diese Aspekte sind unter anderem Anforderungen, Strukturen, Zuverlässigkeit, Robustheit, Sicherheit und Performanz der zu vergleichenden Komponenten. Ferner werden testmodellbasierte Ansätze vorgestellt, die zum Nachweisn der Gleichwertigkeit her- angezogen werden können. Eine formale Definition der „Ähnlichkeit“ als Verallge- meinerung der Gleichwertigkeit in verschiedenen Situationen bietet eine algorithmi- sche Grundlage zum automatischen Vergleich von Ausgangsgrößen von Software- Komponenten. Zuletzt geändert: 26.01.2012 17:57 4/69
Nachweis der Gleichwertigkeit von Software-Artefakten, Phase 3
Inhalt
1 Einordnung und Kurzbeschreibung ..................................................................... 6
1.1 Motivation und Einordnung........................................................................... 6
1.2 Management Summary ................................................................................ 6
1.3 Überblick ...................................................................................................... 6
2 Hintergrund.......................................................................................................... 7
3 Risikoanalyse ...................................................................................................... 8
3.1 Systemzerlegung.......................................................................................... 9
3.2 Fehlertypen ................................................................................................ 11
3.3 Austausch von Komponenten .................................................................... 15
4 Aspekte der Äquivalenz ..................................................................................... 16
4.1 Allgemeine Vorbetrachtung ........................................................................ 17
4.2 Anforderungen ........................................................................................... 19
4.3 Erfahrungsdaten ......................................................................................... 20
4.4 Struktur....................................................................................................... 21
4.5 Schnittstellen .............................................................................................. 29
4.6 Zuverlässigkeit ........................................................................................... 32
4.7 Robustheit .................................................................................................. 33
4.8 Sicherheit ................................................................................................... 37
4.9 Performanz ................................................................................................. 40
4.10 Testmodellbasierte Ansätze ....................................................................... 43
5 Allgemeine Kriterien für einen Vergleich von Ausgängen .................................. 54
5.1 Snapshot-Messungen ................................................................................ 54
5.2 Messungen bei Änderungen ...................................................................... 55
5.3 Systematische zeitliche Verschiebungen und Wertabweichungen ............. 56
5.4 Überprüfung auf Gleichheit über allgemeine Eigenschaften ...................... 58
5.5 Regelbasierte Auswertung ......................................................................... 62
6 Zusammenfassung ............................................................................................ 67
7 Literaturverzeichnis ........................................................................................... 68
Zuletzt geändert: 26.01.2012 17:57 5/69Nachweis der Gleichwertigkeit von Software-Artefakten, Phase 3 1 Einordnung und Kurzbeschreibung Der Anwendungskontext dieses Dokuments ist die erneute Zertifizierung einer schon zertifizierten sicherheitskritischen medizintechnischen Software-Komponente, die neu implementiert wurde. Die Zertifizierungsbehörde verlangt in solchen Fällen den Nachweis, dass die Neuimplementierung mit dem alten Stand gleichwertig ist. Wir betrachten die Risikoanalyse als Grundlage der Gleichwertigkeitsdefinition und prä- sentieren verschiedene Aspekte, die das Vorgehen des Nachweises der Gleichwer- tigkeit bestimmen. 1.1 Motivation und Einordnung Das Ziel dieses Dokuments ist die Beschreibung eines methodischen Zugangs zur Gleichwertigkeit von Software-Komponenten in der Medizintechnik. Im SPES Pro- jektkontext kann es vor allem unter ZP-AP 4 (Sicherheitsnachweis, Zertifizierung und Qualitätssicherung nicht-funktionaler Anforderungen) eingeordnet werden. 1.2 Management Summary Dieses Dokument präsentiert die erste, zweite und dritte Phase der MT-Task 2.2 Nachweis der Gleichwertigkeit von Software-Artefakten. Der Anwendungskontext ist die erneute Zertifizierung einer schon zertifizierten sicherheitskritischen medizintech- nischen Software-Komponente, die neu implementiert wurde. Der Grund der Neuim- plementierung kann beispielsweise die Erneuerung der Architektur sein, um wichtig gewordene Qualitätsmerkmale wie Erweiterbarkeit und Interoperabilität gerecht zu werden, oder Portierung der Software auf neue leistungsfähigere Hardware. Die Definition der Gleichwertigkeit von Software-Komponenten ist stark durch die potentiellen Gefahren, die von der Software ausgehen, geprägt. Deshalb bildet die Risikoanalyse die Grundlage der Gleichwertigkeitsdefinition. Die hier präsentierte komponentenbasierte Sicherheitsanalyse bietet vor allem die Möglichkeit, Werte- und Zeittoleranzen zwischen den Ausgangsgrößen der beiden zu vergleichenden Kom- ponenten zu berechnen und diese dann in die Definition der Gleichwertigkeit einflie- ßen zu lassen. Sobald die Gleichwertigkeit definiert ist, stellt sich die Frage, wie man beim Nachweis der Gleichwertigkeit vorgeht. Es werden verschiedene Aspekte benannt und erläu- tert, die das Vorgehen beeinflussen. Diese Aspekte sind unter anderem Anforderun- gen, Strukturen, Zuverlässigkeit, Robustheit, Sicherheit und Performanz der zu ver- gleichenden Komponenten. Zu jedem Aspekt werden die Voraussetzungen und die Umsetzung erläutert, sowie die Kriterien zur Gleichwertigkeit von Komponenten defi- niert. Ferner werden die Aspekte bewertet. Ferner werden die testmodellbasierten Ansätze zum Nachweis der Gleichwertigkeit vorgestellt und erläutert. Die technische Frage, wie ein automatischer Vergleich der Ausgangsgrößen der bei- den zu vergleichenden Komponenten, welche durch Tests in Bezug auf eine oder mehrere oben genannten Aspekte produziert wurden und einer aus der Risikoanaly- se abgeleiteten Gleichwertigkeitsdefinition unterliegen, wird im letzten Kapitel beant- wortet. 1.3 Überblick Im Kapitel 2 werden die Hintergründe des Äquivalenznachweises von Software- Artefakten in der Medizintechnik erläutert. Kapitel 3 beschreibt eine Methode der Ri- Zuletzt geändert: 26.01.2012 17:57 6/69
Nachweis der Gleichwertigkeit von Software-Artefakten,
Software Phase 3
sikoanalyse, die auf der Systemzerlegung basiert. Dadurch können die erlaubten
Werte- und Zeittoleranzen einer Software-Komponente,
Software Komponente, die mit anderen Komponen-
Kompone
ten interagiert, berechnet werden. Kapitel 4 erläutert verschiedene Aspekte, die das
Vorgehen des Äquivalenznachweises,
Äquivalenznachweises, vor allem die einzusetzende Prüfmethode,
bestimmen. Kapitel 5 beschreibt die formale Grundlage des algorithmischen Ver- Ve
gleichs von Signalverläufen zur Feststellung ihrer „Ähnlichkeit“. Kapitel 6 fasst den
Inhalt des Dokuments zusammen und gibt einen Ausblick.
Aus
2 Hintergrund
Medizintechnische
echnische Geräte sind sicher und zuverlässig zu entwickeln. Das ergibt sich
unmittelbar aus den potentiellen Gefahren, die ein Fehlverhalten für den Anwender
nach sich ziehen kann, und spiegelt sich in den diversen Richtlinien wider, die einzu-
halten sind (z.B. IEC 62304 und ISO 14971).
Damit wachsen auch die Aufwände, um die qualitätsabsichernden Zulassungsverfah-
Zulassungsverfa
ren zu passieren. Lange Produktzykluszeiten
Produktzyklus einerseits und die Entwicklung neuer
Technologien andererseits drängen auf partielle Ersetzungen oder Aufwertungen
bestehender Systeme. Der Austausch einer Softwarekomponente kann erforderlich
sein, wenn sich neue Programmierparadigmen und -architekturen
architekturen bewähren und
durchsetzen, die modellbasierte Vorgehensweise gegenüber dem herkömmlichen
he
Codieren Einzug findet, verbesserte Kommunikationsstandards
Kommun alte Standards erset-
erse
zen, alte Compiler nicht mehr gewartet werden oder die die Software auf eine neue,
leistungsfähigere Hardwareplattform portiert wird. Wie in vielen Bereichen können
notwendige und erprobte Richtlinien und mit ihnen häufig verbundene Zertifizie-
Zertifizi
rungsprozesse auch zum Hemmschuh für sinnvolle Neuentwicklungen und nutzbrin-
nutzbri
gende Erweiterungen werden. Wie lassen sich bewährte Systeme trotzdem durch
und mit neuen Technologien
Technologien ersetzen und erweitern und zugleich die Erfüllung der
hohen Qualitätsanforderungen nachweisen?
Abbildung 1 Konstruktive und analytische Maßnahmen
Diese Fragestellung hat enge Parallelen in der allgemeinen Systementwicklung.
Grundsätzlich sind hier zwei Ansätze zu verfolgen. Zum Einen auf der konstruktiven
Seite: Wie kann man durch geeignete Architekturen eine hohe Flexibilität gewährleis-
ten? Und zum Anderen auf der analytischen Seite: Wie lässt sich durch Testen und
Zuletzt geändert: 26.01.2012 17:57 7/69Nachweis der Gleichwertigkeit von Software-Artefakten, Phase 3 weitere Prüfmethoden die vergleichbare Sicherheit zum Altstand nachweisen? (Abbildung 1). Wie kann man ein System erstellen, welches flexibel auf Änderungen reagieren kann? Die objektorientierte Analyse (OOA) antwortete hier mit Kapselung. Es sind geeignete Komponenten zu identifizieren, in der möglichst weitgehend die eigentliche Funktionalität verborgen ist. (Balzert, 1996). Entwurfsmuster unterstützen dabei den Entwickler (Gamma, Helm, Johnson, & Vlissides, 1995) (Buschmann, Meunier, Rohnert, Sommerlad, & Stal., 1998). Dann lassen sich einzelne, gekapselte Kompo- nenten kontrollierbar austauschen. Wie lässt sich analytisch sicherstellen, dass beim Erweitern nicht unerwartete Ne- beneffekte auftreten? Auch hier gibt es Standardmethoden: Back-To-Back Tests oder Regressionstests, d.h. die alternative Repräsentation bzw. modifizierte Version wird gegen die alte Version evaluiert. Im Kontext sicherheitsrelevanter Alt- und Neu- systeme ist hierbei jedoch offen, wie diese Tests aufzusetzen, welche Testdaten zu wählen sind und wie mögliche Abweichungen in ihren Ausgaben beurteilt werden sollen. Im medizintechnischen Bereich sind neben einer eventuellen objektorientierten Ana- lyse vor allem die Sicherheitsmodelle zu berücksichtigen. Um eine Komponentener- weiterung qualifiziert abzusichern, sind dann insbesondere Fehlerbaumanalyse oder FMEA auf die einzelnen Komponenten herunterzubrechen. Diese wirken ihrerseits auf die gewählten Architekturen zurück (Kaiser, Liggesmeyer, & Mäckel, 2003)(H. Giese & Schilling, 2004). Für eine systematische Antwort zu den nötigen Tests und ihren tolerierbaren Abweichungen bilden Sicherheitsmodelle die Grundlage, wie im Folgenden gezeigt werden soll. Die Ausgangsfrage ist, wie sich effizient eine Erweiterung eines bestehenden, zertifi- zierten Systems rezertifizieren lässt. Hier bietet es sich in der Medizintechnik an, das erweiterte System gegen das alte zu überprüfen und zu zeigen, dass das neue Sys- tem in den vergleichbaren Anteilen äquivalent zu dem bewährten System ist. Interna- tionalen medizinischen Zulassungsprozessen entsprechend, können gleichwertige Teile eines sicherheitskritischen Gerätes wechselweise ausgetauscht werden, sofern die Gleichwertigkeit nachgewiesen wird. Dies gilt ebenso auch für Software-Artefakte (Modelle, Module, Testfälle etc.). Aus einem detaillierten Sicherheitsmodell können systematisch Kriterien abgeleitet werden, die den Begriff der Äquivalenz operationa- lisieren. Allgemein kann man dynamische Methoden und statische Analysen hier vorsehen, die für einen Nachweis der Gleichwertigkeit herangezogen werden können. So ist hier das Back-To-Back Testen zu nennen und auch das Model Checking. Im Folgen- den werden verschiedene Kriterien zur Definition von Äquivalenz vorgestellt und mit- einander verglichen. 3 Risikoanalyse Mit dem Vordringen softwareintensiver, eingebetteter Systeme in sicherheitsrelevan- te Bereiche steigen die Anforderungen an Sicherheit und Zuverlässigkeit. Nach IEC 62304 ist die Systementwicklung durch ein geeignetes Risikomanagement (gemäß ISO 14971) abzusichern. Dazu gehört ein Verfahren zur Erkennung und Minimierung von Einflüssen und Risiken. Typische Sicherheitsmodelle in der Medizintechnik sind FMEA (Failure Mode and Effects Analysis, Fehlermöglichkeits- und Einflussanalyse oder kurz Auswirkungsanalyse) und FTA (Fault Tree Analysis, Fehlerbaumanalyse). Zuletzt geändert: 26.01.2012 17:57 8/69
Nachweis der Gleichwertigkeit von Software-Artefakten, Phase 3 Ursprünglich wurden diese Modelle für Bauteile entwickelt, die nach längerem Ge- brauch Verschleißerscheinungen und Abnutzung zeigen und deshalb nach einer ge- wissen Zeit mit einer zu bemessenden Wahrscheinlichkeit ausfallen werden. Für die Anwendung auf Software, die nicht altert, gibt es verschiedene alternative Ansätze einer Erweiterung. Im Kontext der dieser Arbeit zugrundeliegenden Motivation eines gleichwertigen Komponentenaustausches ist die Berücksichtigung der Komponen- tenarchitektur im Sicherheitsmodell bedeutsam. 3.1 Systemzerlegung Für die komponentenbasierte Risikoanalyse existieren Ansätze, welche auf die be- währten Risikoanalysemethoden FTA (Fault Tree Analysis) und FMEA (Failure Mode and Effects Analysis) aufsetzen. Kaiser et. al (Kaiser, Liggesmeyer, & Mäckel, 2003) entwickelten einen komponentenbasierten Zugang für die Fehlerbaumanalyse. Giese et.al. (Giese, Tichy, & Schilling, 2004) schlagen einen eng mit der UML verzahnten Weg vor, Hazard-Analyse und Komponentenmodell zu vereinen. Ihre Grundidee ist, dass Fehler in den SW-Komponenten klassifiziert und darüber typisiert werden kön- nen. Die Fehlerauswirkungen pflanzen sich dann über getypte Ports in anderen Komponenten fort. Zu weiteren Ansätzen siehe (Grunske, Kaiser, & Papadopoulos, 2005). In dieser Arbeit wird das Konzept von typisierten Fehlern leicht ausgebaut, um darüber auch geeignete Vergleichskriterien abzuleiten. Die Vorgehensweisen soll an einem einfachen Beispiel skizziert werden. Ausgehend von der Architektur lassen sich die verschiedenen Komponenten identifi- zieren. Abbildung 2 Beispiel einer Systemzerlegung In Abbildung 2 ist ein generischer Aufbau eines eingebetteten Systems als Schich- tenmodell mit Treiber/Vorverarbeitung/Algorithmen-Komponenten beschrieben, wel- ches Sensordaten aufnimmt und einen Aktuator ansteuert. Ein zugehöriges Sicherheitsmodell identifiziert die einzelnen Fehler qualitativ und analysiert deren Ursachen und Wirkungen. In einer komponentenbasierten Entwick- lung ist diese Analyse über Komponentendiagramme mit Ports zu verfeinern, über die diese Fehler weitergegeben werden, siehe (Giese, Tichy, & Schilling, 2004). Die- ser Ansatz lässt sich dahingehend leicht erweitern, dass auch eine abstrakte Fehler- fortpflanzung über solche Diagramme zu beschreiben ist. Zuletzt geändert: 26.01.2012 17:57 9/69
Nachweis der Gleichwertigkeit von Software-Artefakten, Phase 3 Die Motivation hierzu sei an einem Beispiel erläutert. Sensoren besitzen bereits sys- tembedingt nur beschränkte Trennschärfen. Auch Aktuatoren sind durch eine Träg- heit geprägt, die sich in Werteungenauigkeiten und Zeitverschiebungen manifestie- ren. Um diese Ungenauigkeiten und ihre Auswirkungen erfassen und bewerten zu können, werden zwei Fehlertypen betrachtet: zum Einen fehlerhafte Werte, zum An- deren verfrühte oder verspätete Werte (Abbildung 3). Abbildung 3 Wert- und Zeitfehlertypen Eine Sicherheitsanalyse hat die Ursachen und Wirkungen solcher Werte- und Zeit- abweichungen zu untersuchen. Da nun geringste Abweichungen in den einzelnen Teilkomponenten in einer späteren Komponente zu einer potentiellen Gefährdung aufsummiert werden können, ist die Analyse so zu erweitern, dass sie auch diese Fälle erfassen kann. Im Rahmen der UML eignen sich dafür Komponentendiagram- me, wobei die verschiedenen Abweichungen und ihre Fortpflanzung durch Ports wei- tergegeben werden. Die Überlegungen zu systembedingten Abweichungen der Sensorik raten an die Sicherheitsanalyse induktiv zu entwickeln, d.h. eine FMEA über die einzelnen Kom- ponenten zu entwerfen. Andererseits ließe sich aus den Trägheiten des Aktuators und identifizierten Toleran- zen bei fehlerhaften Ansteuerungen eine deduktive komponentenbasierte Fehler- baumanalyse durchführen. In dem hier vorgestellten Ansatz zur Sicherheitsanalyse sollen beide Ansätze verfolgt werden. Für die Komposition einzelner Teile zum System jedoch ist eine komponen- tenbasierte FMEA (Giese, Tichy, & Schilling, 2004) geeigneter, da sie konzeptionell das Zusammenfügen unter Berücksichtigung von Abweichungsklassen und ihrer Fortpflanzung unterstützt. Für die Identifikation der möglichen Abweichungen in den einzelnen Komponenten nutzen wir hingegen eine FTA mit vorgegebenen erlaubten Abweichungen, siehe (Kaiser, Liggesmeyer, & Mäckel, 2003). Beispiel: Defibrillator I In einem stark vereinfachten Beispiel nehmen wir an, dass das System bei kritischen Sensorwerten einen Stromimpuls abgeben soll. Als mögliche Fehler des Gesamt- systems identifizieren wir: falscher Stromwert, falscher Zeitpunkt der Abgabe. Eine Fehlerbaumanalyse der Aktuatorkomponente geht dann von diesen Fehlverhalten aus. Zuletzt geändert: 26.01.2012 17:57 10/69
Nachweis der Gleichwertigkeit von Software-Artefakten, Phase 3
Abbildung 4 FTA für den Aktuator
Anhand des Komponentendiagrams erkennt man, dass diese Analysen weiter auf
die Verarbeitungs- und Sensorkomponente herunterzubrechen sind, wobei die Ports
zu der Aktuatorkomponente eben die identifizierten Abweichungen respektieren
(Abbildung 4).
3.2 Fehlertypen
In medizintechnischen Geräten können verschiedenste Fehler auftreten, angefangen
von unterlassenen Aktionen bis zu leicht übersteuerten Regelungen.
Beispiel: Defibrillator II
Anforderung: Der Spannungsstoß wird rampenförmig angefahren,
von 0 – 700 [V] in 0.2 [ms].
Realisierung: Exponentieller Anstieg von 0 - 700 [V] in 0.2 [ms].
Diese Abweichung ist sicherlich nicht schwerwiegend. Entscheidend für die Wirkung
ist lediglich, dass nach einer gewissen Zeit eine definierte Spannung anliegt und
nicht, wie diese im Detail erreicht wird. Was also ein Fehler ist, welche Abweichung
zur Gefährdung führt, ist differenzierter zu betrachten.
Eingebettete System zeichnen sich dadurch aus, dass sie kontinuierlich Datenströme
verarbeiten. Für einen Vergleich sind deshalb ganze Werteverläufe zu betrachten. Im
Wesentlichen lassen sich dann Softwarefehler phänomenologisch charakterisieren
durch Abweichungen in den Wertesequenzen und Zeitpunkten ihrer Aktion. Das
macht einen operationalen Vergleich wesentlich komplizierter. In einer umfassenden
Analyse ist dies obligatorisch.
Zuletzt geändert: 26.01.2012 17:57 11/69Nachweis der Gleichwertigkeit von Software-Artefakten, Phase 3
Beispiel: Defibrillator III
Der Aktuator selbst besitzt eine gewisse Trägheit in der Ansteuerung und auch die
beabsichtigte Wirkung kann naturbedingt z.B. eine gewisse Verzögerung unkritisch
erlauben. Deshalb können wir Abweichungen Delta_Y in der Sollvorgabe, aber auch
Delta_T in der zeitlichen Ansteuerung tolerieren. Diese Größen sind aufgrund der
Kenndaten des Aktuators offensichtlich quantifizierbar. Sie sind systembedingt und
können durch entsprechende Experimente/Tests überprüft werden. Eine etwas diffe-
renziertere Sicht zeigt, dass es unterschiedliche Schweregrade bei Abweichungen
gibt: harmlose Abweichungen, mittlere Abweichungen, bei denen der Patient im
schlimmsten Fall Unannehmlichkeiten aushalten muss, und ernste Abweichungen,
die für ihn bedrohlich sein können. Als einfachsten Ansatz lassen sich entsprechende
Fehlertypen je nach Abweichungen in Wert und Zeitpunkten der Aktionen klassifizie-
ren, d.h. kleine, mittlere und hohe Abweichungen (Abbildung 5).
Abbildung 5 Verfeinerte Fehlertypen
Dieser Ansatz wird nun etwas detaillierter beleuchtet.
Beispielhaft sei die Einordnung von potentiellen Abweichungen gegeben durch fol-
gende Klassen:
Abweichungen im Wert:
• zwischen [0,0.8] - gering,
• zwischen [0.8, 3] – mittlerer Schaden
Abweichungen bezüglich der Zeit:
• [0,1] gering
• [1,1.8] mittel
Die Abweichungen werden über Ports zwischen den Komponenten weitergegeben,
Zuletzt geändert: 26.01.2012 17:57 12/69Nachweis der Gleichwertigkeit von Software-Artefakten, Phase 3 die entsprechend den Abweichungsklassen getypt sind. Die Sollvorgaben werden über eine I/O Driver-Komponente an den Aktuator gege- ben. Auch hier kann es zu Verfälschungen und Verzögerungen kommen. Gemäß den identifizierten Abweichungsklassen können wir nun eine Fehlerbaumanalyse für die Komponente betrachten. Beispielhaft wurde hierzu die Vorverarbeitungskompo- nente dargestellt (Abbildung 6). Auf der linken Hälfte der Darstellung ist die Ursache- Wirkungsanalyse für kleinere Abweichungen durchgeführt worden, auf der rechten die der mittleren. Die Ausgangsdreiecke führen zu den entsprechenden Ports. Abbildung 6 Qualitative Fehlerbaumanalyse für die Vorverarbeitungskomponente Je nach Art der Komponente kommen weitere mögliche Fehlerursachen hinzu, die in einer Sicherheitsanalyse zu identifizieren sind. Eine erschöpfende Modellierung ergibt eine detaillierte Sicht auf die möglichen Feh- ler, Abweichungen und ihre Auswirkungen. Dieses Verfahren sollte durchgängig wei- ter verfeinert werden, indem man die möglichen Abweichungen gemäß der potentiel- len Schadensgrade in Wertebereichen von Delta_v und Zeiten, Delta_t, klassifiziert und so in die entsprechenden Fehler- bzw. Abweichungstypen differenziert. Im obi- gen Beispiel wurde dies für leichte und mittlere Abweichungen skizziert. Diese detailliertere Analyse ist notwendig, da z.B. Sensormessungen und Microcontroller-Berechnungen durch die Technik bedingt nur eine begrenzte Diskri- minierung leisten, d.h. Rundungs- und Diskretisierungsabweichungen sind systema- tisch mit einzubeziehen. So kann dann erfasst werden, dass z.B. eine zeitliche Ab- weichung von 0.2 s unkritisch sein kann, hingegen um 1 s sehr wohl gefährdend. Addieren sich nun tolerierbare Abweichungen mit weiteren Verzögerungen, verur- sacht z.B. durch eine Berechnung in einer anderen Komponente, so kann die Ge- samtabweichung kritisch werden. Eine so ausgearbeitete Ursache-Wirkungsanalyse lässt sich als eine abstrakte Fehlerfortpflanzungsberechnung lesen und dient einer besseren Abschätzung des potentiellen Risikos. Zuletzt geändert: 26.01.2012 17:57 13/69
Nachweis der Gleichwertigkeit von Software-Artefakten, Phase 3 Anhand einer solchen Verfeinerung des Sicherheitsmodells lassen sich Kennzahlen über die Werte- und Zeittoleranzen ableiten, die von den einzelnen Komponenten einzuhalten sind. Ihre Konsistenz muss über die Fehlerfortpflanzungsanalyse zu ei- nem Komponentendiagramm geprüft werden. In einer abstrakten Fehlerfortpflan- zungsanalyse, bei der wir nicht die zugrundeliegenden Algorithmen und mathemati- schen Operationen berücksichtigen, wird davon ausgegangen, dass Abweichungen in den einzelnen Komponenten sich schlimmstenfalls addieren. Man geht also vom „Worst Case“ auf Komponentenebene aus. Beispiel: Seien K1 ,.., Kn die Eingangskomponenten der Komponente K. Seien ∆v bzw. ∆t Ab- weichungen in den Eingaben von K, die nicht zu kritischen Reaktionen der Kompo- nente führen. Durch verschiedenen Maßnahmen sei ferner sichergestellt, dass die Komponenten K1 ,.., Kn höchstens Abweichungen ∆v1,.., ∆vn bzw. ∆t1,.., ∆tn in Wer- ten und Zeiten haben. Falls dann Σ ∆v1+···+∆vn
Nachweis der Gleichwertigkeit von Software-Artefakten, Phase 3 Beispiel: Defibrillator IV Eine Analyse des Aktuators und der medizinischen Indikation zeigt, dass im Falle des Eingreifens eine Verzögerung um 100 [ms] tolerabel ist und auch die Ansteue- rung bis auf 0.1 [A] genau sein muss. Der verwendete Sensor hat eine Antwortzeit < 1 [ms] und eine Mess-Signifikanz von 0.01%. Diese quantitativen Angaben werden über einen Ursache-Wirkungsgraphen auf die einzelnen Komponenten herunter gebrochen. Insbesondere lassen sich entspre- chende konsistente Toleranzen für die beteiligten Komponenten ableiten. Nach dem skizzierten Modell der Fehlerfortpflanzung ist darauf zu achten, dass bei der Kompo- sition die erlaubten Abweichungen konservativ, d.h. nach dem „Worst-Case“ addiert werden müssen. Für einen abgesicherten Austausch sind dann in allen Vergleichen die vorgegebenen Toleranzen einzuhalten. Beispiel: Defibrillator VForderung: Die Berechnungskomponente ‚Algorithm‘ muss spätestens nach 80 [ms] die Auswer- tung der Sensordaten und die Vorgabe des Sollwertes bis auf 0.06 [A] genau be- rechnet haben. Diese abgeleiteten und geforderten Toleranzeigenschaften bilden dann die Grundla- ge für die Bewertung zweier Berechnungskomponenten auf Gleichwertigkeit. Zwei Komponenten müssen innerhalb eines Werte- und Zeitkorridors der vorgegeben Größenordnung gleich sein! 3.3 Austausch von Komponenten Grundannahme der gesamten, hier angestellten Betrachtungen ist, dass der Aus- tausch einer einzelnen Softwarekomponente systematisch durch geeignete Techni- ken und Nachweise abgesichert werden kann. Dazu stelle man sich das Gesamtsys- tem vor und eine Komponente, die ersetzt werden soll (Abbildung 7). Die farbig mar- kierte SW-Komponente soll ausgetauscht werden. Gedanklich legen wir nun um die- se Komponente herum einen etwas größeren Rahmen (rechtes Bild, um damit einen Sicherheitskorridor um die alte Komponente sinnbildlich darzustellen. Ausgehend von einer komponentenbasierten Sicherheitsanalyse prüfen wir, welche Abweichun- gen in den Verhalten beider Komponenten nicht gefährdend sind. Zuletzt geändert: 26.01.2012 17:57 15/69
Nachweis der Gleichwertigkeit von Software-Artefakten, Phase 3 Abbildung 7 Austausch einer Komponente Wir identifizieren auf diese Weise erlaubte Abweichungen, die in dem vorgesehenen Kontext der Komponenten nicht zu Beeinträchtigungen führen. Diese Daten bilden die Grundlage für den Vergleich und für die Wahl des geeigneten Äquivalenzkriteriums. Im vorhergehenden Kapitel 3.2 haben wir uns vorrangig auf Klassen von Werte- und Zeitabweichungen beschränkt, da sie fundamental für einen Vergleich sind und sie in abstrakten Fehlerfortpflanzungen analysiert. Sie berücksichtigen jedoch nur unzurei- chend den Kontext, in welchem Komponenten ausgetauscht werden sollen. Abwei- chungen mögen in diesem Szenario unproblematisch sein, in anderen Szenarien aber zu höchst kritischen Situationen führen. Ein Nachweis für den abgesicherten Austausch hat den geplanten Zielkontext mit einzubeziehen. Der Wirkzusammen- hang bestimmt inhaltlich, wie dieser Nachweis zu führen ist. Anders formuliert: Das Setting für den Nachweis wird von dem geplanten Einsatz vorgegeben. So ergibt sich grob folgendes Bild: Wie und auf welche Art zu testen oder die Gleich- heit zu prüfen ist, wird durch den Kontext definiert. Die Vergleichskriterien sind aus Sicherheitsanalysen abzuleiten. 4 Aspekte der Äquivalenz Gleichwertigkeit zweier Systeme oder Teile, die gegeneinander ausgetauscht werden sollen, ist für einen Nachweis, der auch in Konflikten Bestand haben kann, zu opera- tionalisieren. Die einfache Gleichheit von Strukturen ist hier meist nicht zielführend, da sich Gleichwertigkeit auf einen Kontext bezieht in dem ein Teil durch ein anderes zu ersetzen ist. Der Kontext wird in der Risikoanalyse beleuchtet. Äquivalenz hat sich also auch an diesen Kontexten zu orientieren. Es lassen sich verschiedene Ansätze finden, die im Folgenden vorgestellt und erläutert werden. Bevor hier näher auf einzelne Äquivalenzkriterien eingegangen wird, sind zunächst die verschiedenen Aspekte zu identifizieren, die für eine Gleichwertigkeit verschiede- ner Systeme relevant sind. Zuletzt geändert: 26.01.2012 17:57 16/69
Nachweis der Gleichwertigkeit von Software-Artefakten, Phase 3
• Anforderungen
• Erfahrungsdaten
• Struktur
o Architektur
o Modell
o Code
• Schnittstellen
• Zuverlässigkeit
• Robustheit
o Negativtests
o Markov-gesteuerte Tests
• Sicherheit
o Model Checking
o Theorem Proving
o Symbolische Ausführung
• Performanz
o Echtzeitanforderungen
o Speicheranforderungen
o Last- und Stresstests
• Testmodellbasierte Ansätze
o Datenpartitionierung
o Zustandsautomaten und Testmodelle
o Testorakel
Die Aspekte stehen nicht in einer hierarchischen Ordnung zueinander und schließen
sich auch nicht gegenseitig aus. Vielmehr werden durch sie komplementäre Sicht-
weisen auf das Problem beschrieben, die helfen sollen, die gestellte Aufgabe adä-
quat zu lösen. So werden in der Regel verschiedene Aspekte zur Beurteilung der
Äquivalenz herangezogen, die sich in ihrer Herangehensweise ergänzen sollen.
In den weiteren Ausbaustufen dieses Berichts werden Techniken zur Umsetzung
dieser Aspekte in Prüfverfahren präsentiert.
4.1 Allgemeine Vorbetrachtung
Um zwei Systeme als äquivalent zu klassifizieren, sind zumindest zwei Vorausset-
zungen nötig. Zum Einen bedarf es definierter Eigenschaften und Gesichtspunkte,
die für eine Einstufung herangezogen werden, zum Anderen aber auch klarer Bewer-
tungsmerkmale, die für einen Vergleich verwendet werden.
Dies soll vorab an einem einfachen Beispiel erläutert werden. Betrachten wir den zu-
grundeliegenden Code zweier Softwaresysteme. Man kann diesen Text natürlich für
einen Buchstabenvergleich heranziehen. In diesem Fall wird die textuelle Darstellung
als Eigenschaft gewählt. Zwei in diesem Sinne ‚gleiche‘ Programme könnten sich
dann noch im Schrifttyp unterscheiden, wären aber trotzdem offensichtlich im engs-
ten Sinne gleichwertig zu nennen. Doch wären zwei Systeme, die in verschiedenen
Programmiersprachen geschrieben wurden, niemals ‚gleich‘.
Andererseits könnten wir syntaktische Eigenschaften eines Programmes zur Hilfe
nehmen, also z.B. bestimmte Metriken wie die Verschachtelungstiefe nutzen. Doch
Zuletzt geändert: 26.01.2012 17:57 17/69Nachweis der Gleichwertigkeit von Software-Artefakten, Phase 3 ist offensichtlich, dass hier ‚gleiche‘ Programme in der Regel fernab einer semanti- schen Gleichwertigkeit sein dürften. Betrachten wir zunächst die in der allgemeinen Softwareentwicklung etablierten Techniken von Back-To-Back oder Regressionstests. Die allgemeine Idee dieser Tests ist, eine Menge von gleichen Testeingaben auf die zwei Repräsentationen (Back-To-Back Tests) oder Versionen (Regressionstests) zu geben und die jeweili- gen Ausgaben zu vergleichen. Damit stellen sich unmittelbar zwei Fragen: Welche Testdaten sollen betrachtet werden (Testsuite) und welche Vergleichskriterien sind heranzuziehen? Ausgehend von einer Risikoanalyse können diese Fragen systema- tisch beantwortet werden (Abbildung 8). So legt eine Risikoanalyse beispielsweise fest, ob zum Nachweis korrekter Umsetzung eine bestimmte Testtiefe erreicht wer- den muss oder andere Aspekte zu verifizieren sind. Ferner zeigt sie, ob komplette Werteverläufe vorzugeben oder bestimmte Eigenschaften von Signalen und ihren Abhängigkeiten gefordert sind. Entsprechend sind dann Wertevergleiche mit Wert- und Zeittoleranzen für einen Vergleich heranzuziehen. Abbildung 8 Use Cases für den Nachweis der Äquivalenz (Back-To-Back Tests) Im Hinblick auf die Anwendung in der Medizintechnik muss jedoch die Einstufung des Gefährdungspotentials stets mit einbezogen werden. Je nach Kontext und Risiko des geplanten Einsatzes sind die Kriterien und Testansätze für einen Vergleich zu wählen, so dass wir ein dreidimensionales Bild erhalten (Abbildung 9): Zuletzt geändert: 26.01.2012 17:57 18/69
Nachweis der Gleichwertigkeit von Software-Artefakten, Phase 3
Risiko Klasse
Implantat
III
Bewertungskriterien
IIb Diagnose
IIa Med. t < 0.01
Unterstützung
I X < 0.1
t < 0.1
Back-To-Back Struktur Model Checking Testansätze
Tests
Stochastische
Robustheitstest
Abbildung 9 Äquivalenz von Komponenten in der Medizintechnik
Im Folgenden werden zunächst verschiedene Gesichtspunkte identifiziert, die für ei-
nen Vergleich herangezogen werden können, und ihre Bedeutung in der Medizin-
technik aufgezeigt. Doch neben diesen damit verbundenen Eigenschaften sind auch
Kriterien zu formulieren, nach denen die zwei Artefakte dann als gleich eingestuft
werden. Diese findet man in den jeweiligen Unterkapiteln.
4.2 Anforderungen
Nach DIN EN 62340 ist die korrekte Umsetzung von Systemanforderungen durch
Tests verfolgbar nachzuweisen. Meist werden die Anforderungen auch auf die ein-
zelnen Komponenten heruntergebrochen. Ausgehend von den Komponentenanfor-
derungen lassen sich dann alle nachweisenden Tests über eine Tracing-Analyse
identifizieren. Diese bilden die anforderungsbasierte Testsuite. Zwei Komponenten
sind dann gleichwertig im Sinne der Anforderungen, wenn beim Durchlaufen der an-
forderungsbasierten Testsuite ihre Ausgaben gemäß definiertem Vergleichskriterium
übereinstimmen.
4.2.1 Bewertung
Sicherlich ist eine Mindestbedingung für die Gleichwertigkeit zweier medizintechni-
scher Systeme, dass Sie sich bezüglich der an sie gestellten Anforderungen gleich
verhalten.
4.2.2 Voraussetzungen
Die beiden Software-Artefakte liegen als ausführbare Programme vor.
Beide haben eine gleiche Menge von Anforderungen zu erfüllen.
a. Vorhandene Testsuite
Es liegt eine Testsuite für die Systeme vor, welche die Anforderungen voll-
ständig abdeckt.
b. Nicht vorhandene Testsuite
Es liegt keine Testsuite für die Systeme vor oder nur eine, welche die Anforde-
rungen zu weniger als hundert Prozent abdeckt.
Zuletzt geändert: 26.01.2012 17:57 19/69Nachweis der Gleichwertigkeit von Software-Artefakten, Phase 3
Es wurden Vergleichskriterien zur Beurteilung gleichwertiger Ausgaben vereinbart.
4.2.3 Umsetzung und Kriterium
Auf beiden Systemen werden die Tests aus der Suite durchgeführt. Die Ergebnisse
müssen gemäß vereinbarten Kriterien übereinstimmen.
a. Vorhandene Testsuite
In diesem Fall ist die Durchführung und der Vergleich über alle Tests für eine
Äquivalenzbestimmung ausreichend.
b. Nicht vorhandene Testsuite
Es sind zunächst über verschiedene Methoden (z.B. Klassifikationsbaum-
Methode oder Äquivalenzklassen -Methode) die Suite der spezifizierten Test-
fälle zu erweitern, so dass eine hundertprozentige Anforderungsüberdeckung
erreicht wird. Anschließend lässt sich Fall a. anwenden.
4.2.4 Anmerkung
Bei eingebetteten Systemen ist nicht offensichtlich, wann zwei Testausgänge als
gleich zu bewerten sind. Es werden durch sie kontinuierlich Messdaten erfasst und
verarbeitet und entsprechende Reaktionen geregelt. Dabei kann es betriebsbedingt
zu kleinsten Zeit- und Werteverschiebungen kommen. Wann also zwei Ausgänge als
‚gleich‘ zu bewerten sind, bedarf einer eigenen Analyse.
Beispiel:
Wenn der Herzschlag seit 3 s nicht mehr gemessen wurde, soll das Notsignal akti-
viert werden.
Da in diesem Beispiel verschiedene Komponenten miteinander kommunizieren müs-
sen (z.B. Elektrode, EKG Gerät und Notsignal), können leichte Verzögerungen auf-
treten. So wird bei einem System bereits nach 3.001 [s] das Notsignal aktiviert, bei
einem anderen erst nach 3.005 [s]. Diese Abweichung ist aber für ein korrektes
Funktionieren unerheblich. In Kapitel 5 werden verschiedene Ansätze hierzu vorge-
stellt.
4.3 Erfahrungsdaten
Häufig werden Produkte, die bereits lange schon auf dem Markt sind, erweitert oder
mit neuen Technologien neu implementiert. Neben Wartungsverpflichtungen und
verkaufsstrategischen Erwägungen sollten auch qualitätssichernde Überlegungen
dazu führen, begleitend möglichst umfassend Einsatz- und Erfahrungsberichte zu
sammeln. Diese Erhebungsdaten können genutzt werden, um typische Anwendungs-
fälle des zukünftigen Systems zu identifizieren, statistisch zu gewichten und zur Qua-
litätssicherung zu nutzen. Dazu werden nach Gewichtung typische Testszenarien
erstellt, die diese Use Cases abdecken. Dabei können natürlich auch aufgezeichnete
Daten verwendet werden. Zwei Systeme heißen dann gleichwertig bezüglich der Er-
fahrungsdaten, wenn sie bezüglich dieser Testsuite sich in einem noch zu definie-
renden Sinne gleich verhalten.
Zuletzt geändert: 26.01.2012 17:57 20/69Nachweis der Gleichwertigkeit von Software-Artefakten, Phase 3 4.3.1 Bewertung Da sich in den Erfahrungsdaten die tatsächlich genutzten Anwendungen widerspie- geln, ist dieses Kriterium gerade zur Absicherung typischer Situationen sehr nützlich. Durch die statistische Gewichtung lassen sich die Szenarien in ihrer Anzahl ent- schieden optimieren. 4.3.2 Voraussetzungen Es liegen statistische Daten über die bisherige Nutzung vor. 4.3.3 Umsetzung und Kriterium Ausgehend von den statistischen Daten werden Anzahl und Typus der verschiede- nen Testfälle identifiziert, die diese Anwendungsfälle abdecken. Die beiden Systeme werden nach diesen so erstellten Testsuiten überprüft. Zwei Systeme heißen dann äquivalent, wenn sie nach einem zuvor definierten Bewertungskriterium zu ‚gleichen‘ Ausgängen führen. 4.3.4 Anmerkung Auch hier lässt sich kein allgemeines Vergleichskriterium empfehlen. Zu sehr hängt es von den jeweiligen Systemen und vor allem Kontexten ab, in denen sie operieren. Meist ist der direkte Vergleich der Ausgabedaten mit Zeitstempel, bei der keinerlei Abweichungen in den Werten oder in der Zeit auffallen dürfen, zu eng. Doch welche Abweichungen noch erlaubt sein dürfen, hängt sehr stark von der Zielumgebung der Systeme ab. 4.4 Struktur In diesem Kapitel betrachten wir die Struktur der Vergleichsobjekte, deren Äquiva- lenz nachzuweisen ist. In Kapitel 4.10 (Testmodellbasierte Ansätze) werden wir auch Strukturen des Testmodells berücksichtigen. Weit eingesetzte Kriterien für die Testtiefe von Testsuiten sind Überdeckungsmaße. So wird insbesondere in sicherheitskritischen Bereichen ein bestimmter Grad der Zweigüberdeckung oder MCDC (Modified Condition/Decision Coverage) verlangt (Liggesmeyer, 2002). Dazu muss eine Testsuite erstellt werden, die diese Überde- ckung erreicht. Da eine Re-Implementierung jedoch andere Strukturen aufweisen kann, ist für den Nachweis der Äquivalenz eine Testsuite zu erstellen, die diese Überdeckungstiefe bezüglich beider Komponenten erreicht. Zwei Komponenten sind dann gleichwertig im Sinne der Strukturüberdeckung, wenn beim Durchlaufen der strukturbasierten Testsuite ihre Ausgaben gemäß definiertem Vergleichskriterium übereinstimmen. Abhängig von der Sicherheitseinschätzung sind hier die geeigneten Strukturüberdeckungsmaße für den Äquivalenznachweis heranzuziehen (Liggesmeyer, 2002). Strukturbasierte Überdeckungskriterien können sich auf die Architektur, die internen Schnittstellen, das Modell oder den Programmcode des Testobjekts beziehen. 4.4.1 Architektur Die grundlegende Struktur ist die Architektur, d.h. der Bauplan des Systems. Man kann hier verschiedene Grundmuster identifizieren: das Schichtenmodell, das Bro- kermodell für verteilte Systeme oder auch Microkernel für adaptive Systeme, siehe (Buschmann, Meunier, Rohnert, Sommerlad, & Stal., 1998). Die Struktur beschreibt Zuletzt geändert: 26.01.2012 17:57 21/69
Nachweis der Gleichwertigkeit von Software-Artefakten, Phase 3
das System auf der höchsten Abstraktionsebene. Äquivalent in dieser Kategorie ist
also das Vorliegen isomorpher Baupläne.
Beispiel:
Viele Systeme sind nach dem Schichtenmodell aufgebaut (Abbildung 10). Zwei Sys-
teme sind genau dann äquivalent, wenn sie den gleichen architektonischen Aufbau
besitzen.
IO L a y e r
IO In te rfa c e
P r e p a r a tio n L a y e r
P re p D a ta In te rfa c e
A lg o rith m L a y e r
Abbildung 10 Schichtenarchitektur
4.4.1.1 Bewertung
Als höchste Abstraktionsebene des Systems ist die Architektur meist zu grob, so
dass ein äquivalenter Aufbau wenig über die Gleichwertigkeit aussagt. Vielmehr ist
es eine Voraussetzung, um detailliertere Äquivalenzen definieren und überprüfen zu
können.
4.4.1.2 Voraussetzungen
Die Einsicht in den Code und deren Aufbau muss vorliegen sowie eine Architektur-
beschreibung.
4.4.1.3 Umsetzung und Kriterium
Da die Architektur ein Bauplan ist, lässt er sich nur bedingt und unvollständig auto-
matisch aus bestehender Software ermitteln. Empfohlen wird hier ein Review.
4.4.1.4 Anmerkung
Um die Gleichwertigkeit von medizintechnischen Systemen mit vertretbarem Auf-
wand zeigen zu können, ist es notwendig, die Äquivalenz auf die kleineren Teile
herunterbrechen zu können. Dies setzt allerdings die gleiche Architektur der betrach-
teten Systeme voraus.
4.4.2 Modell
Wird die Software modellbasiert entwickelt, die Implementierung also grafisch durch-
geführt, so können die damit verbundenen Konstrukte ebenfalls zur Betrachtung der
Zuletzt geändert: 26.01.2012 17:57 22/69Nachweis der Gleichwertigkeit von Software-Artefakten, Phase 3
Gleichwertigkeit herangezogen werden. Dabei sind im Wesentlichen zwei grundle-
gende Unterscheidungen vorzunehmen:
1. Diskrete Strukturen
Sie basieren auf endlichen Daten, einzelnen Ereignissen oder endlichen Ar-
beitsmodi. Meist werden sie mit Hilfe von endlichen Automaten modelliert.
2. Kontinuierliche Strukturen
Dies sind vor allem Signalverarbeitungen, die auf Datenströmen, z.B. kontinu-
ierliche Sensordaten, aufsetzen und eine Regelstrecke durchgängig an-
steuern.
4.4.2.1 Endliche Automaten
Endliche Automaten werden heute zumeist als Zustandsautomaten modelliert. Aus-
gehend von der grundlegenden Arbeit Chows (Chow, 1978) gibt es verschiedene
Algorithmen, die die Äquivalenz solcher Automaten zeigen. Im Wesentlichen betrach-
tet man dazu verschiedene Eingaben in der Zeit und ihre zugehörigen Ausgaben
(Traces). Andererseits ist die Sprachmächtigkeit der verschiedenen Zustandsauto-
maten vielfach erweitert worden, z.B. Statecharts, und damit auch der damit verbun-
dene Aufwand zum Nachweis ihrer Äquivalenz.
Da hier endliche Automaten betrachtet werden, lassen sich theoretisch all ihre Zu-
stände erfassen und so vollständige Äquivalenzen nachweisen. Dies ist der Aus-
gangspunkt für das Model Checking (siehe 4.8.2). Zumeist ist die vollständige Zu-
standsäquivalenz eine zu starke Forderung und nicht mit vertretbarem Aufwand zu
zeigen. Ferner ist der häufigste Grund für den Nachweis der Äquivalenz in einer Wei-
terentwicklung begründet. Wir können mittels neuer Technologien und technischer
Möglichkeiten das alte System sinnvoll durch neue Funktionalitäten erweitern. Des-
halb werden nur eingeschränkte Eigenschaften für einen Vergleich herangezogen.
Beispiel:
Im folgenden Beispiel (Abbildung 11) haben die Automaten Eingangsgrößen n ∈ {0,
1, …}. Abhängig von dieser Größe werden sie geschaltet.
Zuletzt geändert: 26.01.2012 17:57 23/69Nachweis der Gleichwertigkeit von Software-Artefakten, Phase 3
[n>3]
n = {0,1,2,3,4,5,6,7,8,9}
State1 State2
[n3]
State1
[n==4]
[n>4 ]
State4 State5
[nNachweis der Gleichwertigkeit von Software-Artefakten, Phase 3
Beispiel:
n = {0,1,2,3,4,5,6,7,8,9, 10, 11}
[n>3] State 2
State1
[n==4] [n>4]
[n!=4 ]
State4 State5
[n3]
State 2
State1
n = {0,1,2,3,4,5,6,7,8,9, 10, 11} [n==4]
[n!=4 ]
State4 State5
[nNachweis der Gleichwertigkeit von Software-Artefakten, Phase 3
der ursprünglichen besitzt. Kurz gesagt: Das Streichen der inneren Strukturen eines
Zustandes lässt sich dann eindeutig und konsistent durchführen.
4.4.2.3 Umsetzung und Kriterium
Das allgemeine Vorgehen ist wie folgt:
1. Festlegen der Strukturkriterien
Was ist der maßgebliche Eingabebereich und wie sieht der relevante Zu-
standsautomat aus?
2. Automatische Testdatengenerierung
Es wird mit Hilfe der verschiedenen Werkzeuge eine Testsuite erstellt, die ei-
ne genügend hohe Strukturüberdeckung gemäß den festgelegten Kriterien er-
reicht.
3. Back-To-Back Tests der Systeme
Die beiden zu überprüfenden Systeme werden mit den gleichen Testdaten ge-
trieben und es wird überprüft, ob die Ausgänge gleich sind.
Typischerweise hat das Altsystem eine gröbere Struktur und einen kleineren Einga-
bebereich. Um also ein Altsystem gleichwertig durch ein Neues zu ersetzen, sind der
beschränkte Eingabebereich und die alte Zustandsstruktur zu beachten. Zwei Zu-
standssysteme heißen dann bezüglich einer gemeinsamen Vergröberung äquivalent,
genau dann wenn die Zustandsautomaten isomorph sind.
Beispiel:
Es werden der obere Automat A1 in Abbildung 11 und der untere A4 in Abbildung 12
betrachtet. Als gemeinsame Vergröberung wird der Automat A1 gewählt mit dem
eingeschränkten Wertebereich {0, 1, …,9} als Eingabedaten. Der Automat A4 wird
durch Streichen der inneren Struktur von State 2 vergröbert. Dann bemerkt man
leicht, dass beide Automaten isomorph sind. Der Automat A1 ist also gleichwertig
durch den Automaten A4 zu ersetzen.
4.4.2.4 Anmerkung
Ausgehend von Model Checking und weiteren Technologien wie Constraint Based
Analysis, Evolutionäre Algorithmen oder Stochastische Testdatengenerierung wur-
den verschiedene Werkzeuge entwickelt, die sehr differenziert Testdaten zur Struk-
turüberdeckung von diversen Zustandsautomaten erzeugen, siehe z.B. ATG oder
Reactis (BTC Embedded Systems) (Reactis Systems Inc). Diese Werkzeuge können
effektiv eingesetzt werden, um verschiedene Äquivalenzen nachzuweisen. Dazu
werden zu den Automaten, eingeschränkt auf den abgestimmten Eingabebereich,
genügend viele Testdaten generiert. Als Kriterien zur Testtiefe können abhängig von
der Sicherheitsebene z.B. Zustandsüberdeckung, Transitionsüberdeckung oder
MCDC für Guards herangezogen werden. Die zu vergleichenden Automaten werden
mit den Testdaten getrieben. Anschließend werden die Traces, wie oben skizziert,
auf die vereinbarte Vergröberung eingeschränkt. Damit sind sie direkt miteinander
vergleichbar.
Falls keine Abweichungen auftreten und die generierten Testsuiten eine genügende
Testtiefe erreichen (operationalisierbar über geeignete Überdeckungsmetriken) kön-
nen die Automaten als äquivalent erachtet und gleichwertig ausgetauscht werden.
Der Vorteil dieses Zuganges ist, dass er weitestgehend automatisiert durchgeführt
werden kann.
Zuletzt geändert: 26.01.2012 17:57 26/69Nachweis der Gleichwertigkeit von Software-Artefakten, Phase 3 4.4.2.5 Modellstrukturen Neben den endlichen Automaten gibt es eine Vielzahl weiterer Kontrollstrukturen, die in einem Modell eingebaut werden können. Switch-Blöcke, boolesche Ausdrücke, Signaldefinitionen und -auswertungen können als Beispiele genannt werden. Sie un- terscheiden sich nur geringfügig von den wesentlichen Strukturen eines üblichen Programmcodes, so dass sich die Ausführungen in 4.4.3 direkt übertragen lassen. 4.4.2.6 Regelungsbausteine In kontinuierlichen Systemen, insbesondere in Regelungen, werden häufig erprobte Bausteine wie PID-Regler eingesetzt. Im Allgemeineren sollen hier Modellteile mit echtem kontinuierlichen Verhalten betrachtet werden. Angesichts der möglichen (quasi-kontinuierlichen) Eingaben über beliebige Zeiten hinweg ist leicht einzusehen, dass die Gleichwertigkeit zweier Systeme sich nicht sinnvoll durch einen vollständigen Eingabe- Ausgabe-Vergleich definieren lässt. Die Menge aller zu betrachtenden Eingaben ist zur Definition der Gleichwertigkeit ange- messen einzuschränken. Im Wesentlichen laufen die verschiedenen Kriterien auf die Auswahl einer geeigne- ten Menge von Testszenarien hinaus, d.h. einer Testsuite, die auf beiden Systemen ausgeführt und deren Ergebnisse gegeneinander verglichen werden. Sie unterschei- den sich zumeist nur in den zugrundeliegenden Leitlinien ihrer Auswahl und den Kri- terien zur Beurteilung der Gleichwertigkeit ihrer Ausgaben. Es lassen sich grob die folgenden Aspekte für eine Restriktion identifizieren (Abbildung 13): a. Anforderungsbasiert b. Strukturbasiert c. Statistisch über Erfahrungserhebung Abbildung 13 Verschiedene Aspekte für einen Vergleich von Regelungsbausteinen Da bereits in den verschiedenen Kapiteln ausführlich auf diese Kriterien eingegangen wurde, sei hier nur auf diese verwiesen: Anforderungen: Abschnitt 4.2 Erfahrungsdaten: Abschnitt 4.3 Struktur: Abschnitt 4.4 4.4.3 Code Der Code ist die Implementierung von Algorithmen, d.h. von geeigneten Verarbei- tungsvorschriften der Eingaben zu Ausgabedaten. Für eine Beurteilung der Gleich- wertigkeit zweier Systeme können deshalb die zugrundeliegenden Programmierkonstrukte verwendet werden, die zur Realisierung eingesetzt wurden. Allerdings macht es keinen Sinn, diese syntaktisch miteinander vergleichen zu wol- Zuletzt geändert: 26.01.2012 17:57 27/69
Nachweis der Gleichwertigkeit von Software-Artefakten, Phase 3 len. Verschiedene Programmiersprachen oder auch Umsetzungen von Algorithmen würden jeden Vergleich sofort fehlschlagen lassen. Für eine Beurteilung der Gleichwertigkeit zweier Implementierungen ist deshalb zu zeigen, ob sie einen semantisch gleichwertigen, zugrundeliegenden Algorithmus be- sitzen. Es ist also nachzuweisen, dass Eingaben gleichwertig verarbeitet werden. Wiederum ist es nicht praktikabel, alle möglichen Eingaben zu untersuchen. Man muss sich für einen Vergleich auf eine geeignete Untermenge von Testszenarien beschränken. In dieser Betrachtung ist nun der Umstand relevant, dass zur Implementierung der Algorithmen dezidierte Programmkonstrukte eingesetzt werden. Ausgehend vom Code/Modell lassen sich diese verschiedene Strukturen identifizieren, die dann als Grundlage für die Auswahl geeigneter Testsuiten dienen können (Abbildung 14). Abbildung 14 Verschiedene Aspekte für die Auswahl geeigneter strukturorientierter Testsuiten Es werden also Testsuiten definiert, die bezüglich abgestimmter Strukturüberde- ckungskriterien eine gewisse Testtiefe für beide Systeme erreichen. Ferner werden Vergleichskriterien zur Beurteilung der Ausgaben vereinbart. Wenn dann die beiden Systeme bezüglich aller Tests aus der Testsuite gleichwertige Ausgaben liefern, sind diese Systeme als gleichwertig im Sinne eines Strukturvergleiches anzusehen. Eine ausführliche Diskussion der verschiedenen Überdeckungsmaße, die hier zur Angabe der Testtiefe einer Testsuite benutzt werden, findet man z.B. bei (Liggesmeyer, 2002). Die geeignete, zu wählende Struktur hängt dabei sehr von dem Algorithmus und von dem Kontext der Applikation ab. So werden datenintensive Komponenten sicherlich besser über Datenflusskriterien verglichen, Steuerungskomponenten mehr über Kontrollstrukturen. 4.4.3.1 Bewertung Liegt das System als Code vor, so sollten auf jeden Fall für den Nachweis der Gleichwertigkeit zweier Systeme ihre Programmstrukturen berücksichtigt werden. In ihnen sind die zugrundeliegenden Algorithmen und Datenflüsse in eine feste Form transformiert worden und Abweichungen sind hier kritisch. Zum Anderen können Nachweise weitestgehend durch geeignete Werkzeuge unterstützt und optimiert werden. Dies betrifft sowohl die Erstellung geeigneter Testsuiten als auch die Durch- führung und Beurteilung der Ausgaben. 4.4.3.2 Voraussetzungen Das System liegt als Code vor. Zuletzt geändert: 26.01.2012 17:57 28/69
Sie können auch lesen
