|
Wenn wir genau darauf achten, dass wir nur »clear SOUP« verwenden, also Software, für die wir den Quellcode, die vollständige Fehlerhistorie sowie verlässliche und langfristige Nutzungsdaten haben, dann kann COTS-Software für viele sicherheitskritische Medizingeräte eine gute Lösung darstellen. Im Folgenden stellen wir eine Checkliste vor, die bei der Überprüfung helfen soll, ob eine CTOS-Komponente ein geeigneter Kandidat für unser Geäte ist, speziell ob es sich um »clear SOUP« handelt.
Ansprüche an die funktionale Sicherheit
Wir starten mit den Aussagen des Softwareanbieters zur funktionalen Sicherheit seiner Software:
→ Macht der Anbieter überhaupt Aussagen zur funktionalen Sicherheit?
→ Decken sich die Aussagen mit unseren Ansprüchen an die funktionale Sicherheit?
→ Sind Kontext und Grenzen der Aussagen definiert? Treffen die Aussagen beispielsweise für Dauerbetrieb oder nur für kurzfristigen Betrieb zu?
→ Ist die Wahrscheinlichkeit des Auftretens kritischer Fehler in den Aussagen zur funktionalen Sicherheit spezifiziert?
→ Oder umgekehrt: Gibt es Aussagen zur Betriebssicherheit der Software?
→ Definiert der Anbieter eine »ausreichende Betriebssicherheit«? Wie werden die Aussagen zur Betriebssicherheit quantifiziert? Besteht die Quantifzierung nur aus den (im Grunde bedeutungslosen) 99,999%, oder bekommt man sinnvolle Angaben zur Verfügbarkeit und Zuverlässigkeit im relevanten Umfeld?
→ Gibt es quantifizierte Aussagen des Anbieters zur Verfügbarkeit: Zu wie viel Prozent reagiert die Software auf Ereignisse im geforderten Zeitrahmen? Und zur Zuverlässigkeit: Wie viele der Reaktionen sind korrekt?
Prozesse
Ein genau definierter und dokumentierter Prozess für den gesamten Lebenszyklus der Software ist eine absolut notwendige Anforderung - ohne ihn brauchen wir bei der Auswahl gar nicht weiterzumachen:
→ Arbeiter der Softwarehersteller nach einem Qualitätsmanagementsystem?
→ Erfüllt das Qualitätsmanagement die Anforderungen eines Standards aus der ISO-9000-Familie, des SPICE-Standards ISO 15504 (Software Process Improvement Capability Determination) oder des CMMI-Standards (Capability Maturity Model Integration)?
→ Welche Prozesse verwendet der Hersteller für die Quellcodeverwaltung (Versionsverwaltung)?
→ Wie werden aufgetretene Fehler dokumentiert, nachverfolgt und gelöst? Und zwar sowohl die während der Verifikation gefundenen als auch die im realen Einsatz aufgetretenen Probleme.
→ Werden Fehler klassifiziert und anschließend einer umfassenden Analyse unterzogen?
Fehlerbaumanalyse
Die Fehlerbaumanalyse (Bild 1), zum Beispiel mit Hilfe »Bayesscher Netze«, ist ein wichtiges Verfahren, um Designfehler zu eliminieren und die Wahrscheinlichkeit eines Ausfalls abzuschätzen. Zudem ergeben sich wichtige Resultate, die für Zulassungen eingebracht werden können:
→ Wurde die Software einer Fehlerbaumanalyse unterzogen?
→ Wurden sowohl »a priori« (von der Ursache zur Wirkung) als auch »a posteriori« (von der Wirkung zur Ursache) Nachweise geführt?
→ Bekommen wir Einsicht in die Ergebnisse der Fehlerbaumanalyse?
Statische Analyse
Statische Analysen sind unverzichtbar, um verdächtige Codesegmente zu identifizieren, und ihre Verwendung wird von Zulassungsbehörden wie der FDA explizit empfohlen:
→ Verwendet der Hersteller statische Analysen, um potenzielle Fehler im Produkt finden zu können?
→ Welche Werkzeuge zur statischen Analyse kommen zum Einsatz - zum Beispiel syntaktische Analysen gegen gängige Coding-Standards, Abschätzung der Fehlerwahrscheinlichkeit, Korrektheitsnachweise (etwa durch Assertions im Quellcode) oder symbolische Ausführung?
→ Welche Dokumente stellt der Hersteller der COTS-Software zur Untermauerung der Ergebnisse der statischen Analyse zur Verfügung?
Nutzungshistorie
Eine nachweisbare Nutzungshistorie ist für die Überprüfung der Aussagen zur Betriebssicherheit von COTS-Software unumgänglich. Jeder, der ein Softwaresystem herstellt, für das er irgendwann einmal (und sei es in ferner Zukunft) einen Nachweis zur Betriebssicherheit liefern muss, sollte das Sammeln von Nutzungsdaten fix in sein Geschäftsmodell einbauen:
→ Kann der Anbieter der COTS-Software Nutzungsdaten vorlegen?
→ Wie weit reichen die Daten zurück?
→ Wie aussagekräftig sind die Daten?
→ Wie viele Daten liegen insgesamt vor?
→ Decken die Daten nur einen kleinen oder einen großen Teil der gesamten Laufzeit ab?
→ Woher bekommt der Hersteller die Daten?
→ Liefert der Anbieter zusätzlich Daten aus der Fehleranalyse oder nur reine Nutzungsdaten?
Dokumente und Nachweise
Entwurfsdokumente und Validierungsergebnisse sind wesentliche Unterschiede zwischen »SOUP« und »clear SOUP«:
→ Welche Entwurfsdokumente liefert der Hersteller mit seiner Software mit?
→ Stellt der Hersteller Dokumente zum Entwurf der Softwarearchitektur und Dokumente zum Detailentwurf zur Verfügung?
→ Welche Testpläne wurden verwendet, und kann man die Ergebnisse einsehen?
→ Welche zusätzlichen Validierungsmethoden hat man angewendet, sind die Methoden und Ergebnisse einsetzbar?
→ Führt der Anbieter eine Anforderungs-Rückverfolgbarkeits-Matrix von der Anforderungsdefinition bis zur Auslieferung? Ist diese für Kontrollen verfügbar?
→ Welche Aufzeichnungen gibt es zum Lebenszyklus der Software bezüglich Änderungen, Problemen und deren Lösung?
Safety-Manual
Das Safety-Manual ist ein weiteres K.O.-Kriterium für die Auswahl: Gehört kein Sicherheitshandbuch zum Lieferumgang der COTS-Software, versuchen Sie es besser bei einem anderen Anbieter:
→ Stehen explizite Aussagen zur funktionalen Sicherheit im Safety-Manual?
→ Werden Aussagen zum Kontext und zu Einschränkungen in Bezug auf die funktionale Sicherheit gemacht? Diese sollten das Betriebsumfeld und die Art der Verwendung umfassen. Ein paar Beispiele: »Diese Liste der unterstützten Prozessorarchitekturen ist vollständig«; »Es ist nicht zulässig, Gleitkommaoperation in einem Signal-Handler auszuführen«; »Kritische Budgets können maximal der Zeitfenstergröße entsprechen«.
→ Wird ein Training zur sicheren Nutzung des Produktes angeboten?
|
