Vector Software. Verifizierung und Validierung von Software unter IEC :2010

Transkript

1 Vector Software W H I T E P A P E R Verifizierung und Validierung von Software unter IEC :2010 Übersicht Dieses Whitepaper soll Systementwicklern als Referenz dienen, welche zu zertifizierende Software erstellen, oder einen Prozess einhalten müssen, der die Konformität mit IEC erfordert. Das Whitepaper wird sich auf die Verifizierung und Validierung von sicherheitstechnischer Software (IEC 61508:3:2010, Teil 3) konzentrieren. Außerdem wird eine Auswahl von Techniken und Maßnahmen erläutert, die für die Validierung der Software, basierend auf dem Safety Integrity Level (SIL), relevant ist. Einige dieser Techniken können angewendet werden um Kosten und Mühen zu verringern, die bei der Software- Zertifizierung nach IEC :2010 entstehen können. Einleitung Bei industriellen Automatisierungssystemen ist der Wettbewerbsdruck sehr groß. Unternehmen müssen stets innovativ sein, um sich erfolgreich am Markt zu behaupten. Dies funktioniert nur, wenn sie immer wieder neue Produkte und Funktionen auf den Markt bringen, von denen die meisten große Mengen an Software beinhalten. Einst waren diese Produkte rein mechanische Geräte, inzwischen wurden sie aber von integrierten Geräten mit embedded Software in allen Hauptsystemen abgelöst. Hierzu gehören: die industrielle Prozess-, Kontroll-, Automatisierungsindustrie, Automobilindustrie, Großmaschinen und der Bergbau. Die Kostenkontrolle für industrielle automatisierte embedded Systeme ist von großer Bedeutung für Zulieferer, da hier ein viel höheres Softwarevolumen als in anderen sicherheitskritischen Branchen, wie z.b. der Luftfahrt und der Bahn, vorkommt. Ausführliche Software Tests sind bislang immer sehr kostenintensiv gewesen. Vergleicht man aber die Kosten, die entstehen, um die Softwarefehler frühzeitig zu finden mit den direkten Kosten und der Beschädigung des guten Rufes des Produktes oder der Marke, die mit Rückrufen oder System- Ausfallzeiten verbunden sind, so sind Letztere weitaus höher. Daher stellen heutzutage gründliche Tests eine absolute Notwendigkeit in der industriellen Automatisierungsindustrie dar.

2 Industrielle Automatisierungssysteme die sicherheitstechnische Funktionen ausführen, welche auch als elektrische, elektronische oder programmierbare Systeme bekannt sind, werden oft mit Blick auf den IEC Standard entwickelt. Dieser von der International Electrotechnical Commission (IEC) entwickelte Standard ist heute sehr etabliert. IEC ist der Standard, für die funktionale Sicherheit von programmierbaren elektronischen Systemen. Der Standard ist in sieben Teile aufgeteilt; in diesem Paper wird der Fokus auf der Softwaresektion liegen: Teil 3: Anforderungen an Software (zur Einhaltung erforderlich). Dieses Dokument soll zum besseren Verständnis der Verifizierung und Validierung von Software unter IEC :2010 führen. Es soll keine umfassende Übersicht des Standards sein, sondern eher einen Überblick über die verschiedenen Testkategorien und Anforderungen geben und erläutern, wie diese erfüllt werden können. In diesem Dokument wird folgende Legende genutzt: R Recommended Activity (empfohlene Aktivität) HR Highly recommended Activity (sehr empfohlene Aktivität) Software Verifizierung Durch das Analysieren von 7.4.7, 7.4.8, 7.5, 7.7, 7.8 und 7.9 und den Bezug hiervon auf die Tabellen in Anlage A, können die folgenden Aktivitäten in Bezug auf die Verifikation und Validierung von Software zusammengefasst werden. Methode / Maßnahme SIL A. Wahrscheinlichkeits- Tests - R R R B. Dynamische Analyse und Tests R HR HR HR C. Datenspeicherung und analyse HR HR HR HR D. Functional und Black Box Testen HR HR HR HR E. Performance Testen R R HR HR F. Interface Testen R R HR HR G. Testmanagement und Automatisierungswerkzeuge R HR HR HR H. Nachvollziehbarkeit zwischen Softwaredesign Spezifikation und Test Spezifikation R R HR HR I. Numerische offline Analyse R R HR HR J. Wirkungsanalyse HR HR HR HR K. Zertifizierte Werkzeuge und Übersetzer oder besseres Vertrauen durch Nutzung Tabelle 1 Methoden / Maßnahmen aus IEC :2010, Teil 3, Anlage A R/HR HR HR HR Seite2

3 A. Wahrscheinlichkeits- Testen Wahrscheinlichkeits- Testen dient der Ableitung von Maßnahmen wie MTBF (Mean Time Between Failures), sowie der Verfügbarkeit oder der Wahrscheinlichkeit einer sicheren Ausführung. Die Wahrscheinlichkeit von Fehlern kann durch die Wiederholung der Tests mit diversen frei ausgewählten Werten für die häufigsten genutzten Tests reduziert werden. B. Dynamische Analyse und Testen Dieser Teil deckt viele Tests ab, von denen die Großzahl durch eine Mischung aus Systemtests (Der gesamte Software- Build wird getestet) und Unit-/ Modultests geprüft werden. Die meisten dieser Aktivitäten werden in IEC :2010, Teil 3, Anlage B Tabelle B.2 und unten aufgezeigt. SIL Methode / Maßnahme Testfallausführung durch Grenzwertanalyse R HR HR HR 2. Testfallausführung durch Fehlerrate R R R R 3. Testfallausführung durch Fehlerplatzierung - R R R 4. Testfallausführung durch Modellbasierte Testfallgenerierung R R HR HR 5. Performance Modeling R R R HR 6. Äquivalenzklassen und Eingangs- Partitionstests R R R HR 7a. Strukturelle Abdeckung (Eingangspunkte) 100% HR HR HR HR 7b. Strukturelle Abdeckung (Anweisungen) 100% R HR HR HR 7c. Strukturelle Abdeckung (Zweige) 100% R R HR HR 7d. Strukturelle Abdeckung (MC/DC) 100% R R R HR Tabelle 2 Dynamische Analyse und Testen - IEC :2010, Teil 3, Anlage B Tabelle B.2 Obwohl all diese Aktivitäten technisch gesehen auf dem Systemlevel durchgeführt werden können, spezifiziert der IEC 61508:3 Standard, dass diese während der dynamischen Analyse und der Testphase auf dem Unit- oder Modullevel ausgeführt werden müssen und auf den Spezifikationen der Software und / oder der Spezifikation und dem Code basieren muss. Bei all diesen Methoden ist es möglich ein hohes Maß an Automatisierung zu erreichen. Dies wird im Folgenden weiter erläutert. 1. Testfallausführung durch Grenzwertanalyse Diese Testarten sollen potentielle Softwarefehler an Parametergrenzen oder Grenzen, die auf der Parameterart basieren, beheben. Die beste Art, dieses Ziel zu erreichen ist, die Unit Tests bei der Software durchzuführen, sodass diese Grenzwerte direkt in die Funktionen eingegeben Seite3

4 werden können. Es gibt allerdings einige Spezialfälle, welche hinreichend getestet werden sollten. Zu diesen gehören: Die Parameter auf Null setzen, wenn diese eine andere Variable in der Funktion teilen. Leere ASCII Funktionen testen Ein leeres Stapel- oder Listenelement testen Eine Null Matrix testen Einen Nulltabelleneintrag testen Die Maximal- und Minimalwerte des Typs und eventuell der funktionalen Grenzen testen Die Werte außerhalb der Grenzen testen Einige Testautomatisierungswerkzeuge können die Konstruktion dieser Testfälle sogar weiter automatisieren, da sie die Möglichkeit bieten, automatisch Testfälle zu generieren, die alle Eingabewerte auf ihre Minimum-, Maximum- und Mittelwerte testen. Diese Art von Testfällen werden MIN-MID-MAX Testfälle genannt. Die Minimum- und Maximumwerte werden durch das Testen des Spektrums jedes Typs, der im Programm, auf der Zielplatine oder im Simulator vorhanden ist, bestimmt. Folglich garantiert die Nutzung des Testautomatisierungswerkzeuges auf entweder der Platine oder dem Simulator, dass das Spektrum der durch automatisch generierte MIN-MID-MAX Tests getesteten Grenzwerte im jeweiligen System gültig ist. Wie oben bereits erläutert, können diese Werkzeuge Test- spezifische Werte vorantreiben. Sie können sogar andere Werte testen, die nicht direkt erwähnt wurden, wie Not-A-Number (NAN), positive und negative Unendlichkeit von Gleitkomma-Variablen, etc. 2. Testfallausführung mit Fehlerrate Diese Testfälle basieren auf Testerfahrungen und Intuition in Kombination mit Wissen und Neugier über das getestete System. Dies kann zu der Erstellung weiterer Testfälle führen um Fehler in der Software hervorzurufen. Diese Aktivität kann auf dem System Level durchgeführt werden, allerdings ist eine Durchführung auf dem Unit Level ebenso sinnvoll (wie beim IEC :2010, Teil 3, Anhang A, Tabelle A.5 notwendig). Somit kann sichergestellt werden, dass alle Komponenten der Software so fehlerfrei wie eben möglich sind. Die Erfahrungen, die durch das Testen während der Implementierungszeit gesammelt werden (wie in diesem Dokument bereits erläutert wurde), können zur Erstellung weiterer Testfälle führen, welche während der Regressions- Testphase erneut verwendet werden können. Seite4

5 3. Testfallausführung durch Fehlerinjektion Das Ziel dieser Teststrategie ist es, absichtlich Fehler zu verursachen, um herauszufinden, ob die Fehler durch die Testfälle identifizieren werden. Wenn manche Fehler nicht entdeckt werden, müssen zusätzliche Testfälle bereitgestellt werden. Dier Fehlerinjektion kann einfach auf dem Unit Level vollzogen werden. Ein Testfall in einem Testautomatisierungswerkzeug kann auch für (1) eingefügte Fehlerbedingungen festgelegt werden und, in vielen Fällen (2) bestätigen, dass diese Fehlerbedingungen entdeckt wurden. Beispielsweise können Zeiger absichtlich auf Null belassen werden, oder Ausnahmen absichtlich erhöht werden, um abzuschätzen, wie das System mit solchen Situationen fertig wird. 4. Testfallausführung durch Modellbasierte Testfallgenerierung Diese Teststrategie ermöglicht die frühe Erkennung von Unklarheiten zwischen dem ursprünglichen Modell und dem entwickelten/ generierten Quellcode. Da sie aus den während des Modellbasierten Testens (MBT) definierten Testfällen entstanden ist, wird so die automatisierte Generierung von Testfällen gewährleistet, wenn am Quellcode gearbeitet wird. Der Großteil der Test- Automatisierungswerkzeuge sind heute in der Lage, Testfalldaten in ein Comma Separated Values Format (CSV) zu importieren. Wenn Model basierte Testfälle in ein CSV Format, oder ein anderes einfach einzulesendes Format, exportiert werden können, ist es ebenso möglich, diese auch schnell in das Unit- Test- Automatisierungswerkzeug zur Quellcode- Verifizierung zu importiert. 5. Leistungsmodellierung Diese Aktivitäten zielen darauf ab die Leistung zu kalkulieren. Dazu gehören die Prozessorzeit, die Kommunikationsbandbreite, die Auslastung der Speichergeräte und so weiter. Test- Automatisierungswerkzeuge können dazu genutzt werden, Testvektoren für diese Arten von Aktivitäten einzufügen, wobei die Kalkulation von Prozessorzeit, Bandbreite, Verarbeitungsmenge, etc., mithilfe anderer Werkzeuge, wie einem Debugger, erstellt werden. Eine interessante Funktion, welche man während der Auswahl eines Test- Automatisierungswerkzeuges im Hinterkopf behalten sollte, ist die Möglichkeit, dies unter der Kontrolle eines Debuggers auszuführen. 6. Äquivalenzklassen und Input Partitions- Testen Diese Strategie strebt das adäquate Testen der Software durch die Bestimmung der Partitionen auf der Input Domain an, die zur Ausführung der Software notwendig ist. Diese Testfälle zielen auf ein ausreichendes Testen des Programmes ab. Sie können entweder auf Software Spezifikationen oder der internen Programmstruktur (oder beidem) basieren. Diese Tests können unbemerkt auf dem Systemtest Level durchgeführt werden, speziell sogar, wenn High Level Anforderungen getestet werden. Allerdings können Entwickler auch Low Seite5

6 Level Anforderungen testen wollen und/ oder einige ihrer Partitions- Testfälle auf der internen Programmstruktur basieren lassen (wie erforderlich bei IEC :2010, Teil 3, Anhang A, Tabelle A.5). Praktisch werden diese Aktivitäten, sobald ein Test- Automatisierungswerkzeug genutzt wird. Ein Unit- Testwerkzeug kann Wertebereiche und Wertelisten entweder in einem Kombinationsmodus, oder in einem nicht-kombinationsmodus testen. Die Ausführung dieser komplexen Testfälle wird einfach durch Knopfdruck gestartet. Unit- Test- Automatisierungswerkzeuge beinhalten auch typischerweise eine Funktion, die ein Partitions- Testfallgenerator zur automatisierten Erstellung von zusätzlichen Testfällen auf einer bereitgestellten Domain genannt wird. 7a. Strukturelle Abdeckung Einstiegspunkte Die Einstiegspunkt- Abdeckung versucht zu ermöglichen, dass jede Funktion/ Prozedur mindestens einmal abgerufen wird. Dabei ist es nicht von Bedeutung, wie viel Code tatsächlich innerhalb der Funktion/ Prozedur ausgeführt wurde. 7b. Strukturelle Abdeckung Statement Abdeckung Die Statement Abdeckung versucht individuelle Codezeilen in einer vorgegebenen Unit abzudecken. Die folgende Zeile würde zum Beispiel nur einen einzigen Testfall benötigen um abgedeckt zu sein. if(i < 10 && j == 0 k > 12) Es sollte darauf hingewiesen werden, dass ein einzelner Testfall der mit false bewertet wird keine zusätzlichen Zeilen abdeckt, die in diesem IF Statements enthalten sind. Gleichermaßen wird ein Testfall, der als true bewertet wird nicht den Inhalt eines ELSE Statements abdecken, wenn ein ELSE Statement an das IF Statement angehängt ist. Jedoch deckt sowohl der true Testfall, als auch der false Testfall das IF Statement per se ab. Einige Unit- Test- Automatisierungswerkzeuge mit automatisierten Testfallgenerierungsmöglichkeiten können den Entwicklern helfen, Testfälle zur Maximierung der Statement Abdeckung zu entwickeln. Zum Beispiel werden automatisiert generierte Testfälle basierend auf den Basis- Pfaden (den unabhängigen Pfaden im Code) oftmals eine hohe Statement Abdeckung aufweisen. 7c. Strukturelle Abdeckung Branch Abdeckung Branch Abdeckung konzentriert sich auf den Zustand der Entscheidungspunkte, der entweder true oder false sein kann. Die folgende Codezeile, benötigt z.b, zwei Testfälle zur Abdeckung einen, bei dem das IF Statement als true und einen bei dem es als false bewertet wird. if(i < 10 && j == 0 k > 12) Seite6

7 Um der IEC-61508:3 zu entsprechen, sollte ein Test- Automatisierungswerkzeug in der Lage sein, Statement und Branch Abdeckungsanalysen während einer einzigen Testausführung zu produzieren. 7d. Strukturelle Abdeckung MC/DC (Modified Condition/Decision Coverage) MC/DC benötigt die höchste Anzahl an Tests, um den Abdeckungsanforderungen zu genügen. Dieser Abdeckungslevel zeigt, dass alle Unterbedingungen, die Teil eines bedingten Statements sind, eigenständig das Resultat des bedingten Statements selbst beeinflussen können. Im folgenden Statement zum Beispiel: if(i < 10 && j == 0 k > 12) Wenn der Wert für I geändert wird, während die Werte der anderen Unterbedingungen stabil bleiben, wird sich der Endwert verändern. Diese Aufgabe kann auch für die erfahrensten Entwickler sehr aufwendig sein. Allerdings kann dieses Testen besonders effizient mithilfe einer Wahrheitstabelle durchgeführt werden. Diese kann automatisiert durch den Code generiert werden und sollte deutlich aufzeigen, bei welchen Testfallpaaren das Erreichen der MC/DC Abdeckung notwendig ist. Daraufhin zeigt sie auf, welche Testfälle und Testfallpaare bereitgestellt wurden, wie in Abbildung 1 dargestellt. Seite7

8 Abbildung 1 MC/DC Wahrheitstabelle Weitere Überlegungen Alle beschriebenen Tests können auf dem Host, einem Simulator, oder auch direkt auf der Zielhardware durchgeführt werden. Für genauere Ergebnisse wird empfohlen, diese Tests zumindestens auf einem Simulator ablaufen zu lassen. Sie sollten, wann immer es möglich ist, auf der Platine durchgeführt werden, (1) um zu garantieren, dass die Ergebnisse den Besonderheiten jeder Umgebung entsprechen und (2) um das Testen zu beschleunigen, das mit den Software/Hardware Integrationstest- Aktivitäten zusammenhängt. Diese Aktivitäten werden in Tabelle A.6. verdeutlicht. C. Datenerfassung und Analyse Testen Wenn Testfälle erstellt und ausgeführt werden, sollte die Möglichkeit bestehen Aufzeichnungen über jegliche Besonderheiten in Verbindung mit den Testfällen, die Gründe warum sie erstellt wurden und jegliche Ergebnisinterpretationen, zu machen. Test- Automatisierungswerkzeuge erlauben üblicherweise angehängte zusätzliche Informationen, um weitere Informationen anhand von Testfallszenarien zu gewinnen. Seite8

9 D. Funktionales und Black-Box Testen Das Testen während des Software Designs und deren Implementierung wird für alle SIL Level empfohlen. Verschiedene Möglichkeiten passender Teststrategien werden in IEC :2010, Teil 3, Anhang B, Tabelle B.3 (siehe auch Tabelle 3) behandelt. Technik / Messung SIL Testfallausführung von Ursache- Wirkung- Diagrammen - - R R 2. Testfallausführung von Modellbasierter Testfallgenerierung R R HR HR 3. Prototyping/Animation - - R R 4. Äquivalenzklassen und Input Partitions- Testen, einschließlich Grenzwertanalyse R HR HR HR 5. Prozess Simulation R R R R Tabelle 3 Funktionales und Black-Box Testen in IEC :2010, Teil 3, Anhang B, Tabelle B.3 1. Testfallausführung von Ursache- Wirkung- Diagrammen Ursache- Wirkung- Diagramme beziehen sich auf die Modellierung in schematischer Form und der Abfolge der Ereignisse, die sich in einem System als Konsequenz der Kombinationen von Basisereignissen entwickeln können. 2. Testfallausführung von Model- basierter Testfallgenerierung Wie bereits erläutert, ist es oftmals wünschenswert, den tatsächlichen Quellcode zusätzlich zur Model- basierten Simulation zu testen. Code- basierte Testwerkzeuge ermöglichen den Import von Model- basierten Testfällen, um die Notwendigkeit zur Neudefinierung der Testdaten zu verringern. Resultat der Ausführung dieser Tests ist die Code Abdeckung (Code Coverage), um die Vollständigkeit der generierten Testfälle zu beweisen. 3. Prototyping/Animation Prototyping und Animation prüfen die Durchführbarkeit der Implementierung des Systems gegenüber den gegebenen Randbedingungen. 4. Äquivalenzklassen und Partitionstests, einschließlich Grenzwertanalyse Grenzwertanalyse und Äquivalenzklassen/Input Partitionstests wurden bereits in diesem Dokument erläutert (bei Verifizierung und Testen). Wenn diese Tests direkt auf der Zielplatine ausgeführt werden, sollten sie nicht mehr modifiziert werden müssen. Wenn sie direkt auf dem Host oder auf einer Simulation ausgeführt werden, können die mit den Aktivitäten zusammenhängenden Testfälle einfach innerhalb eines Unit- Test- Automatisierungswerkzeuges wiederverwendet werden. An diesem Punkt können zusätzliche, auf dem Systemlevel durchgeführte Testfälle, empfehlenswert sein. Seite9

10 5. Prozess Simulation Prozess Simulationen testen die Funktion eines Softwaresystems, ohne das komplette System dafür in Betrieb zu nehmen. E. Performance Testen Laut IEC :2010, Teil 3, Anhang B, Tabelle B.6, sind Avalanche/Stress Tests, Reaktionszeiten und Speicherbeschränkungen, sowie Leistungsanforderungen abhängig vom SIL Level entweder empfehlenswert oder sehr empfehlenswert. Diese können partiell automatisiert sein und ein Test- Automatisierungswerkzeug nutzen. Zum Beispiel kann die Zeit, die zur Ausführung einer Funktion benötigt wird auf dem Unit- Test- Level kalkuliert werden. In einem weiteren Beispiel dieser Tests kann der gleiche Testfall mehrere Male ausgeführt werden, eventuell auch zusammen mit System- Level- Threads. F. Interface Testen Während des Software Designs und der Implementierung wird empfohlen, das Interface des Codes (auf dem Funktionsaufruf- Level) zu testen. Es gibt mehrere ausführbare Level der Vollständigkeit des Testens. Die wichtigsten Level erfordern Folgendes: Das Testen aller Funktionsparameter mit extremen Werten zur gleichen Zeit, oder auch nach einander (während normale Werte für die übrigen Parameter genutzt werden). Das Testen aller Werte für alle Parameter, einschließlich der Kombination durch spezifische Testbedingungen. Extreme Werte können anhand von Funktionsbereich oder Typ spezifiziert werden. Unzulässige Werte können ebenfalls getestet werden. Das kombinatorische Testen sollte für das Testen alle möglichen Permutationen von Inputs erlauben. G. Test Management und Automatisierungswerkzeuge Die Herausforderung während der Implementierung ist hierbei, dass die Entwickler keinen Zugang zum vollständigen Quellcode haben denn definitionsgemäß ist dieser noch in der Entwicklung. Hier wird nun ein Unit- oder Modul- basierter Testansatz erwartet. Um in der Lage zu sein die Software zu testen während sie implementiert wird, müssen Software Stubs vorhanden sein. Diese Software Stubs sind Codestücke, die an die Stelle von regulärem Code treten (zum Beispiel, wenn der reguläre Code noch implementiert werden muss), sodass die Verlinkung einer spezifischen Datei, Klasse oder sogar eines Moduls abgeschlossen werden kann. Ohne abgeschlossene Verlinkung kann der Code nicht erfolgreich getestet werden. Software Unit- Test- Automatisierungswerkzeuge sind für diese Aufgabe ideal geeignet. Entwickler können die Werkzeuge nutzen, um eine vollständige Testumgebung einschließlich der Stubs - zu generieren, ohne jeglichen Testcode oder Testskripte bereit zu stellen. Es werden lediglich der zu testende Code und der Pfad zum Inhalt benötigt. Diese wenigen Seite10

11 Informationen reichen aus, um den gesamten Code der Testumgebung, der zum Unit- oder Modul- Testen nötig ist, mithilfe dieser Werkzeuge automatisiert zu generieren (Test-Treiber, Stubs...). Die Entwicklung des Testcodes würde normalerweise mehrere Stunden dauern, kann aber durch diese Methode in nur wenigen Minuten fertig gestellt werden. Ein Beispiel hierzu wird in Abbildung 2 veranschaulicht. Abbildung 2 Software- Testwerkzeug- Automatisierung Unit Test- Automatisierungswerkzeuge ermöglichen die Testausführung auf dem Host, einem Simulator oder direkt auf der Produktplattform (auch als eingebettete Zielhardware bekannt). Dies wird üblicherweise mit einem Interface namens Runtime Support Package (RSP) durchgeführt. Alle Anlagen zur Testausführung und zur Erfassung aller Testberichte werden durch das RSP kontrolliert. Ein Beispiel hierzu wird in Abbildung 3 verdeutlicht. Seite11

12 Abbildung 3 Test- Automatisierungswerkzeug arbeitet mit dem Runtime Support Package Selbst wenn sich die Umgebung verändert (zum Beispiel durch einen neuen Ziel- Prozessor, oder eine andere Code- Version), können Testfälle mithilfe eines Unit- Test- Automatisierungswerkzeuges, problemlos von den Testumgebungen exportiert und zu den Testumgebungen importiert werden. Üblicherweise werden die Testfall- Daten in diesen Werkzeugen von der Testumgebung in einer Textdatei separat gespeichert, sodass sie so in die Testumgebungen reimportiert werden können, die sich auf spezifische Units fokussieren. Dies geschieht einfach per Knopfdruck. So wird nicht nur viel Zeit eingespart, sondern auch Hilfestellung während der Testfall- Definitions- Aktivitäten gegeben. H. Rückverfolgbarkeit zwischen Software Design Spezifizierungen und Test Spezifizierungen Laut IEC 61508:3, ist es das Ziel der Rückverfolgbarkeit, sicher zu stellen, dass nachgewiesen allen Anforderungen vernünftig nachgekommen wurde und kein nicht verfolgbares Material eingefügt wurde. Dies beinhaltet allerdings ebenfalls unbeschränkt die Rückverfolgbarkeit zwischen Software- Anforderungen und Testfällen. Normalerweise integriert ein Test- Automatisierungswerkzeug Anforderungen durch ein Modul namens Requirements Gateway, mithilfe von Werkzeugen von Drittanbietern, deren Funktion es ist Software- Anforderungen zu pflegen, dazu gehört zum Beispiel IBM Rational DOORS oder Polarion. Mithilfe dieser Integration können die Nutzer bestimmte Software- Anforderungen herunterladen und diese daraufhin mit Testfällen verbinden. Daraufhin können sie diese Informationen wieder zurück auf das Anforderungs- Management- System mitsamt dem Status des Testfalles (PASS/FAIL) hoch laden. So wird die Erstellung der Rückverfolgbarkeits- Matrix enorm vereinfacht. Seite12

13 I. Offline numerische Analyse Das Ziel dieser Metriken ist es, die Attribute von Programmen anhand der Eigenschaften der Software selbst vorher zu sagen, und nicht anhand ihrer Entwicklungs- oder Testhistorie. In der Regel beinhalten Test- Automatisierungswerkzeuge die cyclomatische Komplexität als Teil ihrer Standard Analyse. Zusätzliche Metriken können üblicherweise durch die Nutzung eines statischen Analyse- Werkzeuges erlangt werden. J. Wirkungsanalyse (Impact Analyse) Die Wirkungsanalyse zielt auf die Identifizierung eines Änderungs- oder Erweiterungseffektes eines Software Systems auf andere Module in demselben Software System oder auch in anderen Software Systemen, ab. Dies führt zur erneuten Verifizierung des veränderten Moduls, aller betroffenen Module oder sogar des gesamten Systems, was selbst von der Wirkungsanalyse abhängt. Unit- Test- Automatisierungswerkzeuge verfügen normalerweise über vollständige Regressions-Test Fähigkeiten. Dies bedeutet auch, dass die Testfälle, die für frühere Code- Versionen geschrieben wurden, auch nahtlos auf dem neu entwickelten Code laufen können. Wenn ein Testfall veraltet ist (aufgrund einer Änderung der Anzahl von Parametern oder ihres Beispieltyps), wird dieser einfach ignoriert, oder zur Überarbeitung gekennzeichnet. Dank dieser Eigenschaft von Test- Automatisierungswerkzeugen wird es ermöglicht, dass der gesamte Satz von Testfällen auf einem gegebenen Model mit aktualisiertem Code innerhalb von wenigen Minuten erneut laufen gelassen werden kann. So wird auch der notwendige Wartungsaufwand optimiert. Die Tests können einfach über Nacht erneut ausgeführt werden, da der Prozess des Regressions- Testens vollständig automatisiert ablaufen kann. K. Zertifiziertes Werkzeug und Übersetzer oder erhöhtes Vertrauen aufgrund der Nutzung Diverse Werkzeuge und Übersetzer werden gebraucht, um Vorteile durch die Nutzung zu erzielen, entweder anhand einer formaler Zertifizierung des Werkzeuges, oder durch vorherige Nutzung. Wenn das Werkzeug formell zertifiziert wird, sind die folgenden Dokumentationen notwendig: Ein Zertifikat der Behörde unter Angabe ihrer Zertifizierung (siehe Abbildung 4 für ein Beispiel). Werkzeug- Betriebsanforderungen (Tool Operational Requirements = TOR) o Das Dokument beinhaltet verifizierbare Anforderungen für das Werkzeug oder den Übersetzer im Verifizierungsprozess, sowie Informationen über die Betriebsumgebung des Projektes, die einen Einfluss auf die vom Werkzeug produzierten Ergebnisse haben könnten (z.b. Mikroprozessor Architektur) Seite13

14 Werkzeugs- Qualifikationsdaten (Tool Qualification Data = TQD) o Das Dokument beinhaltet die Testdaten und Ergebnisse aus der Durchführung der Qualifikations- Testsuite. Diese werden benötigt, um alle Anforderungen der TOR mit Hilfe der Betriebsumgebung des Projektes zu verifizieren. Compliance Analyse zum IEC Standard o Dies wird normalerweise innerhalb eines Workflow- Handbuches erfasst, in welchem beschrieben wird, wie das Werkzeug innerhalb von festgelegten Grenzen genutzt werden sollte, um zu gewährleisten, dass die so erlangten Ergebnisse zum Nachweis der Konformität mit einem Standard annehmbar sind. Seite14

15 Abbildung 4 Test- Automatisierungswerkzeug mit Runtime Support Package Wenn sich das Werkzeug auf erhöhtes Vertrauen durch die Nutzung verlässt, sollte ein Nachweis über andere ähnliche Sicherheits- bezogene Systeme bereit gestellt werden, bei welchen das Werkzeug bereits genutzt wurde. Seite15

16 Fazit In diesem Whitepaper wurden alle Bestimmungen des IEC 61508:3 Standards behandelt, die mit der Validierung und Verifizierung von Sicherheits- bezogener Software zusammen hängen. Software Unit Test Lösungen ermöglichen Automatisierung und Flexibilität, was zur radikalen Verringerung der verwendeten Zeit zur Erfüllung der Software Verifizierungs- und Validierungsanforderungen führt, die in Standards, wie dem IEC 61508:3 spezifiziert sind. Weiter wurden Techniken zur Nutzung dieser Werkzeuge erläutert, welche genutzt werden können, um die Effizienz bei der Arbeit mit diesen Klauseln zu verbessern. Referenzen International Electrotechnical Commission Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems Part3: Software Requirements. (IEC :2010). Über Vector Software Vector Software, Inc., Software ist der weltweit führende unabhängige Anbieter von Software Test Lösungen für sicherheitskritische und geschäftskritische embedded Anwendungen. Vector Software s VectorCAST Produktlinie automatisiert und bewältigt komplexe Aufgaben im Zusammenhang mit Modul, Integrations- und Systemlevel Tests. VectorCAST Produkte unterstützen C, C++, und Ada Programmiersprachen. Vector Software, Inc South County Trail, Suite 310 East Greenwich, RI USA T: F: E: info@vectorcast.com Vector Software Golden Cross House 8 Duncannon Street London WC2N 4JF, UK T: F: E: info@vectorcast.com Vector Software St. Tӧniser Str. 2A Kempen Germany T: F: E: info@vectorcast.com Seite16