Funktionale Sicherheit über den Entwicklungs-Lebenszyklus hinaus sicherstellen

Anbieter zum Thema

Axivion GmbH

Parasoft® Deutschland GmbH

RTI Real-Time Innovations

LDRA Inc

Software-Modultests und Test sowie Integration der Software

Dynamische Analysetechniken (Modul-, Integrations- und Systemtests) sehen die Ausführung des Codes vor, während es bei statischen Analysetechniken um eine automatisierte „Inspektion“ des Codes geht. Modultests sind gezielt auf bestimmte isolierte Softwareprozeduren oder Funktionen fokussiert. Die Integrationstests stellen sicher, dass die Anforderungen eingehalten werden, wenn alle Module zusammenarbeiten.

Die Norm ISO 26262-6:2011 listet Techniken und Kennzahlen für die Durchführung von Modul- und Integrationstests an der Ziel-Hardware auf. Fehlereinstreuung und Ressourcentests weisen zusätzlich die Robustheit und Resilienz nach und sorgen gegebenenfalls für die Back-to-Back-Prüfung von Modell und Code, um die korrekte Interpretation des Designs nachzuweisen. Die mit diesen Techniken zusammenhängenden Artefakte dienen als Referenz für ihr Management und als Nachweis für ihre Fertigstellung. Es handelt sich bei diesen Artefakten um die Softwaremodul-Designspezifikation, die Testprozeduren, den Verifikationsplan und die Verifikations-Spezifikation. Mit dem Abschluss einer jeden Testprozedur werden Pass/Fail-Resultate gemeldet, und die Einhaltung der Anforderungen wird entsprechend verifiziert.

Bildergalerie

Vom Software-Modultest zum Integrationstest

Das Beispiel in Bild 4 macht deutlich, wie ein Test-Tool hier helfen kann. Das Softwareinterface wird auf der Funktionsebene exponiert, sodass der Anwender Eingaben und erwartete Ausgaben als Basis für ein Test Harness eingeben kann. Der Test Harness wird anschließend kompiliert und auf der Ziel-Hardware ausgeführt, woraufhin die erwarteten und tatsächlichen Ausgaben verglichen werden können.

Modultests werden zu Integrationstests, wenn ein Aufrufbaum ausgeführt und nicht mit Stubs umgesetzt wird. Folglich kann man in beiden Fällen die gleichen Testdaten zur Validierung verwenden. Diese anforderungsbasierten Tests generieren Structural-Coverage-Kennzahlen um zu zeigen, welcher Anteil des Codes ausgeführt wurde, und um nachzuweisen, dass keine nicht gewünschten Funktionalitäten vorhanden sind.

Die gebotenen Kennzahlen können sich auf Funktionen, Aufrufe, Anweisungen, Verzweigungen und die MC/DC Coverage beziehen. Modul- und Systemtest-Einrichtungen können gemeinsam operieren, sodass die Coverage-Daten für den Großteil des Quellcodes durch einen dynamischen Systemtest generiert und anschließend durch Modultests ergänzt werden können. Dies spricht beispielsweise jegliche defensiven Konstrukte an, die während des regulären Systembetriebs nicht zugänglich sind. Sollten Änderungen notwendig werden – sei es infolge eines fehlgeschlagenen Tests oder als Reaktion auf eine modifizierte Anforderung –, können sämtliche betroffenen Modul- und Integrationstests einfach wiederholt (regressionsgeprüft) werden. Die Modultests lassen sich zum Nachweis der Robustheit ausweiten, indem man die Eingangsdaten automatisch generiert und mit Grenzwerten und Äquivalenz-Grenzwerten zusammenhängenden Testfälle ausführt.

Die Bedeutung bidirektionaler Rückverfolgbarkeit

Die bidirektionale Rückverfolgbarkeit setzt voraus, dass jede Entwicklungsphase exakt die jeweils vorangehende Phase widerspiegelt. Wenn die exakte Abfolge des V-Modells eingehalten wird, werden sich die Anforderungen theoretisch niemals ändern, sodass die Tests niemals ein Problem aufdecken. Die Realität ist freilich anders.

Was passiert im Fall einer Codeänderung als Reaktion auf einen fehlgeschlagenen Integrationstest – möglicherweise deshalb, weil die Anforderungen nicht stimmig sind oder weil ein Codierfehler vorliegt? Es ist zu fragen, welche anderen Softwaremodule von dem geänderten Code abhängig waren. Aus solchen Szenarien können schnell Situationen entstehen, in denen die Rückverfolgbarkeit zwischen den Produkten der Softwareentwicklung verlorengeht.

Softwaredesigns müssen bidirektional rückverfolgbar sein – also sowohl auf die Software-Anforderungen als auch auf die Softwarearchitektur. Die Softwaremodule werden dann spezifikationsgemäß und zum Design rückverfolgbar implementiert. Automatisierte „Requirements Traceability Tools“ stellen Beziehungen zwischen Anforderungen und Testfällen her, was ein Ermitteln der Testabdeckung gestattet (Bild 5). Die Auswirkungen von fehlgeschlagenen Testfällen, geänderten Anforderungen und einer unzureichenden Anforderungs-Abdeckung lassen sich erfassen und adressieren. Zudem können Artefakte wie zum Beispiel Rückverfolgbarkeits-Matrizen automatisch erzeugt werden, um Nachweise für die Einhaltung der jeweiligen Norm zu erbringen.

Die anfängliche strukturelle Abdeckung entsteht in der Regel im Rahmen dieses Prozesses, aus der Ausführung des Funktionstests auf instrumentiertem Code. Dabei werden nicht ausgeführte Abschnitte des Codes, die einer weiteren Analyse bedürfen, aufgedeckt. Dies führt zur Hinzufügung oder Modifikation von Testfällen, zu Änderungen an den Anforderungen und zur Entfernung von totem Code. In der Regel stellt eine iterative Abfolge aus Prüfung, Korrektur und Analyse sicher, dass die Designspezifikationen eingehalten werden.

Automatisierung der funktionalen Sicherheit während des Entwicklungs-Lebenszyklus und darüber hinaus

Obwohl Prozess-Standards in erheblichem Umfang zur Safety und Security beitragen, bringen sie zweifellos auch Aufwand mit sich. Der Einsatz automatisierter Tools während des gesamten Entwicklungs-Lebenszyklus kann entscheidend zur Verringerung eben dieses Aufwands beitragen und gleichzeitig einen großen Teil des Risikos für menschliche Fehler beseitigen. Dies ist heute von nie dagewesener Bedeutung.

Mit dem Einzug der Vernetzung endet der Entwicklungsprozess nicht mehr mit der Einführung eines Produkts. Sobald im Feld eine neue Sicherheitslücke entdeckt wird, wird eine Änderung der Anforderungen notwendig. Die erforderliche Reaktion verstärkt die Forderung nach Automatisierung nicht nur während des Entwicklungs-Lebenszyklus, sondern auch danach.

Der Autor

* Mark Pitchford erwarb seinen Abschluss als Bachelor of Science an der Trent University, Nottingham, und ist seit mehr als 20 Jahren Diplomingenieur. Von 2007 bis 2014 arbeitete er als FAE bei LDRA. Im Anschluss wechselte er als Technical Manager für den Bereich EMEA zu Lynx Software Techno¬logies, bevor er im Februar 2017 zu LDRA zurückkehrte. Dort ist er als Tech¬nical Specialist tätig.

Nachweisbare Tests für funktionale Sicherheit auf Serienhardware durchführen

Funktionale Sicherheit mit IEC 61508: Systematische Fehler mit Struktur und Prozessen eindämmen

(ID:45583548)