Systemzuverlässigkeit

Confidence-from-Use bei Medizinprodukten

12.09.14 | Autor / Redakteur: Chris Hobbs * / Franz Graser

Computertomographie: Medizingeräte sollten nicht nur fehlerfreie Ergebnisse liefern, sondern auch die Strahlungsdosis möglichst gering halten. Zuverlässigkeit ist hier oberstes Gebot.
Computertomographie: Medizingeräte sollten nicht nur fehlerfreie Ergebnisse liefern, sondern auch die Strahlungsdosis möglichst gering halten. Zuverlässigkeit ist hier oberstes Gebot. (Erasmus Medical Center, Rotterdam, The Netherlands/Siemens)

Das Testen wird heute nicht nur als Demonstration der korrekten Funktion eines Systems gesehen. Es dient auch zur Ermittlung des auf Erfahrungswerten aus der Anwendung beruhenden Vertrauensniveaus.

Testen spielt für softwarebasierte Medizingeräte heute eine ganz andere Rolle als noch vor zehn Jahren. Der risikobasierte Ansatz aus der IEC 29119 „Software Testing“ (2013) spiegelt eine Veränderung wider, die explizit oder implizit bereits von den meisten Testgruppen übernommen wurde. Heutzutage sieht man das Testen nicht mehr nur als Demonstration der korrekten Funktion des Systems, sondern als Mittel zur Erzeugung von Nachweisen für die sogenannte Confidence-from-Use – das auf Erfahrungswerten aus der Anwendung beruhende Konfidenzniveau.

Beim Verifizieren eines medizinischen Embedded-Geräts, in dem Software eingesetzt wird, steht man vor einer zentralen Herausforderung: Der Zustandsraum eines laufenden Programms ist so groß, dass eine hundertprozentige Testabdeckung schlechterdings unmöglich ist. Jeder Versuch, das Programm testen zu wollen, kann daher nicht mehr als eine sehr kleine statistische Stichprobe sein.

Einer der Fallstricke, der explizit in der IEC TIR80002-1 (Medizingerätesoftware – Leitfaden zur Anwendung der ISO 14971 auf Medizingerätesoftware) erwähnt wird, besteht gerade darin, sich auf „Testen als Mittel zur Risikokontrolle“ zu verlassen, obwohl eine hundertprozentige Testabdeckung unmöglich ist.

Der Zustandsraum der Software

Es lässt sich relativ einfach zeigen, dass ein modernes Embedded-Betriebssystem (zum Beispiel das QNX Neutrino OS oder Embedded Linux) mehr als 10300 mögliche interne Zustände aufweist. Um dies in Relation zu setzen: Die Eddington-Zahl (die Anzahl der Protonen im beobachtbaren Universum) beträgt rund 1080. Zudem läuft das OS auf einem Prozessorchip mit internen Daten- und Befehlscaches, die sich zu jedem Zeitpunkt in vielen verschiedenen Zuständen befinden können, die allesamt für den Benutzer unsichtbar sind und vom Tester nicht reproduziert werden können.

Und dann ist da noch das eigentliche Anwendungsprogramm. Betrachten wir nun das folgende Programm, das die durchaus überschaubare Aufgabe hat, die Summe aus zwei und zwei zu berechnen und die Antwort – etwa eine einem Patienten zu verabreichende Dosis – auszugeben:

#include

int main()

{

char x;

x = 2 + 2;

printf("%d\n", x);

return 0;

}

Als Entwickler mag man geneigt sein, dieses Programm als reichlich trivial einzustufen. Das ist aber gar nicht so. Das Programm wird mit der Bibliothek libc verlinkt, welche die printf-Funktion bereitstellt, und es wird auf dem besagten OS ausgeführt, welches selbst schon mindestens 10300 mögliche Zustände aufweist. Um zu beweisen, dass das Ergebnis von 2 + 2 unter allen Umständen korrekt berechnet wird, müssten wir das Programm in jedem einzelnen dieser Zustände testen, was offenkundig unmöglich ist.

Nun habe ich dieses Programm gerade 1000 Mal auf meinem Linux-Laptop getestet, und die Antwort lautete jedes Mal „4“. Vom Standpunkt der Testabdeckung ist dies ohne Bedeutung. So können wir keine Aussage darüber treffen, ob gegebenenfalls während eines dieser Tests der Timer-Interrupt des Computers mit der Anweisung _Lockfileatomic(stdout); in printf zusammenfiel, oder ob noch ein weiterer Thread versuchte, stdout zur gleichen Zeit zu blockieren wie unser Programm – all das würde das Programm sicherlich in unterschiedliche Zustände versetzen. Was, wenn ein anderer Prozess stdout blockiert hat und in diesem Prozess ein Fehler auftritt, bevor er seine Verarbeitung vollendet? Würde unsere Berechnung nun für immer auf die Freigabe von stdout warten? Dies wäre eine Bedingung, die während des Testens nur sehr schwierig herzustellen ist, die aber eine der Testbedingungen sein sollte.

Inhalt des Artikels:

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Kommentar abschicken

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 42867989 / Software-Test & -Betrieb)

Embedded Software Engineering Report abonnieren

4 mal jährlich: Die kostenlose Pflichtlektüre für Embedded­-Software- und Systems-Entwickler, von Analyse bis Wartung und Betrieb

* Ich bin mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung und AGB einverstanden.
Spamschutz:
Bitte geben Sie das Ergebnis der Rechenaufgabe (Addition) ein.