6. Validierung
Zum Nachweis der Verlässlichkeit ist Testen allein nicht ausreichend, weitere Maßnahmen sind gefordert wie formales Design, statistische Analyse und nachträgliche Design-Validierung. Testen findet indirekt Fehler im Design oder in der Implementierung, da es die Störungen und Ausfälle aufdeckt, die durch Fehler verursacht werden. Tests sind die wichtigste Methode zum Entdecken und Beheben sogenannter Bohrbugs: Bugs, die reproduzierbar sind und auch beim Debuggen noch auftreten. Bei ‚Heisenbugs‘ aber stoßen Entwickler schnell an Grenzen, denn derselbe Fehler führt zu unterschiedlichsten Störungen. Für den Nachweis von Sicherheitsaussagen helfen Methoden wie die statische Analyse. Dieses Vorgehen empfehlen u.a. Organisationen wie die FDA, inklusive Syntaxüberprüfungen gegen Code-Standards, Fehlerwahrscheinlichkeitsabschätzungen, Überprüfung der Korrektheit durch Assertions im Quellcode sowie symbolische Ausführung. Daten zur Betriebsbewährtheit informieren über den gesamten Lebenszyklus über Betriebsstunden der Software und während dieser Zeit aufgetretene Fehler. Bei der Fehlereinstreuung bauen Testingenieure absichtlich Fehler ein, die helfen sollen, die Fehlererkennung zu testen und mittels statistischer Auswertung die Zahl der noch verbliebenen echten Fehler einzuschätzen. Die formale und semi-formale Entwurfsverifikation erfolgt normalerweise schon vor der Implementierung, kann aber auch nachträglich vorgenommen werden.
7. Cots und Soup
Alles selbst zu entwickeln birgt oft mehr Risiken als ausgewählte kommerzielle oder Commercial Off-The-Shelf-Komponenten (Cots) zu verwenden. Und auch die Verwendung von Software Of Uncertain Provenance (Soup), also Software unbestimmter Herkunft, ist zulässig, sofern für diese Komponenten ausreichende Daten für den Sicherheitsnachweis des Systems zur Verfügung stehen. Die Implementierung von Betriebssystemen, Netzwerkprotokollen oder Datenbanken erfordert spezialisiertes Know-how und eine Cots-Lösung hat häufig den Vorteil mehrerer Millionen nachgewiesener Betriebsstunden. Cots-Software ist aus der Sicht eines Entwicklers meist auch Soup. Die Standards IEC61508 und IEC62304 gehen davon aus, dass Soup verwendet wird. Für Systeme, die SIL3 oder SIL4 benötigen, fordert EN50128, dass „eine Strategie entwickelt werden muss, wie man Fehler in der Cots-Software aufspüren und das System vor diesen Fehlern schützen kann“. Es müssen ausreichend dokumentierte Nachweise vorliegen, um die Auswirkungen von Soup auf die Sicherheitsanforderungen des Systems quantifizieren zu können, also belastbare Daten zur Betriebsbewährtheit, Fehlerhistorie und andere historische Daten. Man sollte zudem den Quellcode und die Testpläne anfordern, um die Software mit Werkzeugen zur statischen Codeanalyse zu prüfen. Auch wichtig sind detaillierte Einblicke in die Prozesse, die der Hersteller bei der Erstellung der Software angewendet hat. Alternativ kann ein externer Auditor bestätigen, dass die verwendeten Prozesse für die Sicherheitsanforderungen des Gerätes angemessen sind.
8. Zertifizierte Komponenten und ihre Hersteller
Auch die Verwendung von Komponenten, die bereits Sicherheitszertifizierungen vorweisen, können die Entwicklung und Validierung zwar beschleunigen und die Zulassung erleichtern. Doch Organisationen wie die FDA, MHRA und ihre Entsprechungen für andere Bereiche vergeben prinzipiell nur für fertige Geräte Zulassungen, nicht für Einzelkomponenten. Trotzdem können bereits zertifizierte Komponenten, z.B. der QNX Safe-Kernel zertifiziert nach IEC61508, den Zulassungsprozess massiv vereinfachen. Um diese Zertifizierungen zu bekommen, mussten diese Komponenten a) in einer Umgebung mit adäquaten Prozessen und Qualitätsmanagement entwickelt werden und b) sachgemäßen Tests und Validierungen unterzogen werden und c) muss der Hersteller die notwendigen Unterlagen zur Verfügung stellen, die wiederum die Zulassung des Gesamtproduktes unterstützen.
