Normengerechte Entwicklung
COTS-Software für medizinische Geräte?
Immer umfangreichere Produkte sollen immer schneller fertiggestellt werden - ein enormer Druck. In anderen Branchen werden Kosten mittels COTS-Softwarekomponenten (COTS: Commercial Off The Shelf) gesenkt. Aber in der Medizintechnik kann das schnell zu einer undurchsichtigen Technologie-»Suppe« (SOUP, nach IEC 62304: Software of Uncertain Provenance) führen. Dies wiederum geht zu Lasten der Sicherheit und führt womöglich zu Ärger bei der Zulassung.
Anders als beispielsweise die in der Industrie übliche Norm IEC 61508 legt die Medizintechnik-Norm IEC 62304 keine der üblichen Limits für Fehlerraten fest. Sie macht zum Qualitäts- und Risikomanagement vielmehr zwei Annahmen:
- Die Software für das medizinische Gerät wird »unter einem Qualitätsmanagementsystem entwickelt und gewartet« (z.B. ISO 13485 oder ISO 90003).
- Das Risikomanagement erfolgt nach ISO 14971, und einige zusätzliche Anforderungen nach IEC 62304, Abschnitt 7 werden erfüllt.
Bezeichnenderweise schreibt die IEC 62304 jedoch nicht vor, wie die Anforderungen zu erfüllen sind. Sie legt kein Softwareentwicklungsmodell fest und definiert keine Dokumente, die man für den Nachweis der Konformität zur Verfügung stellen muss. Dafür legt die Norm die Prozesse (inklusive Risikomanagement),
Aktivitäten und Aufgaben für den gesamten Lebenszyklus der Software fest. Zudem werden Sicherheitsklassen abhängig vom Gefährdungspotenzial definiert (A bis C) (Bild 1).
Schließlich, und das hat nun besondere Bedeutung für die hier diskutierte Fragestellung, wird in der IEC 62304 ausdrücklich auf die Verwendung von »SOUP« (Software of Unknown Provenance, Software unklarer Herkunft) eingegangen. Sie wird dort wie folgt definiert: »Software, die fertiggestellt und allgemein verfügbar ist und nicht speziell für das Gerät entwickelt wurde, in dem sie verwendet wird (allgemein als ‚Off-the-shelf‘-Software bekannt). Ebenso Software, die bereits früher entwickelt wurde und für die keine ausreichende Dokumentation der Entwicklungsprozesse verfügbar ist.«
Die IEC 62304 gibt somit sogar zwei Definitionen für »Software unklarer Herkunft«. Die Verwendung von SOUP wird nicht verboten - im Gegenteil, einige Abschnitte gehen speziell auf die Verwendung ein: In Abschnitt 5.1.1 »Software development plans« findet man beispielsweise: »der Plan muss ... Softwarekonfigurationen und Change-Management inklusive SOUP-Konfigurationen berücksichtigen«, und SOUP ist ausdrücklich das Thema in 5.3.4: »Specify system hardware and software required by SOUP item«. Die Frage ist also nicht, ob COTS- oder SOUP-Software in Medizin-geräten verwendet werden kann, sondern a) wie sich entscheiden lässt, ob eine bestimmte COTS-Software für ein spezifisches Gerät geeignet ist, und b) wie sich nachweisen lässt, dass diese Software die funktionale Sicherheit des Gerätes nicht beeinträchtigt.
»SOUP« und »clear SOUP«
Manche Software-anbieter machen es sich bei der Unterscheidung zwischen COTS und SOUP etwas zu leicht: COTS ist demnach Software, hinter der ein Hersteller steht, der seinen guten Ruf und seinen Geschäftserfolg riskieren würde, wenn die gelieferte Software nicht wie beschrieben funktionieren würde. Hinter SOUP hingegen steht niemand. Diese Unterscheidung scheint durchaus sinnvoll, man kauft ja beispielsweise Medikamente auch lieber bei einer Apotheke als auf einer dubiosen Webseite.
Letztlich ist die Unterscheidung aber irrelevant, da COTS so gut wie immer auch SOUP bedeutet: Die Prozesse, die bei der Entwicklung eingehalten wurden - oder eben auch nicht -, der Quellcode, die Fehlerhistorie, also praktisch alles, was wir bei einer selbst entwickelten Software selbstverständlich hätten, alles dies steht uns nicht zur Verfügung. Deshalb sollten wir lieber »undurchsichtige Suppe« (SOUP) und »klare Suppe« (clear SOUP) unterscheiden. Diese Unterscheidung basiert nicht auf kommerziellen Kriterien (kommerziell vertrieben oder nicht), sondern allein auf der Verfügbarkeit von Ergebnissen und Dokumenten, die wir für den Nachweis unserer Aussagen zur funktionalen Sicherheit sowie den Nachweis des Sicherheitslevels unseres System benötigen.
Ein Beispiel: Komplexe Medizintechnik-Geräte benötigen für ihre Softwarefunktionen meist ein Betriebssystem. Technische Aspekte wie Kapselung aller Softwarekomponenten, Hochverfügbarkeits-Manager oder Zeitpartitionierung spielen bei der Auswahl oft eine wichtige Rolle. Doch kann man nicht in bestimmten Fällen einfach ein Betriebssystem aus der Konsumelektronik einsetzen?
Microsoft Windows ist beispielsweise ein COTS-System, und es gibt für dieses Betriebssystem sicher einen genau dokumentierten Entwicklungsprozess. Der Hersteller arbeitet vermutlich auch genau nach diesem exakt definierten Prozess, und natürlich besitzt er auch den Quellcode, den man theoretisch bis ins Detail untersuchen könnte; die Fehlerhistorie ist wohl ebenfalls komplett erfasst und dokumentiert.
Nachdem diese Informationen aber weder für uns noch für andere öffentliche Untersuchungen freigegeben sind, können wir beim Windows-Betriebssystem nicht von »clear SOUP« sprechen. Im Gegensatz dazu machen Open-Source-Projekte wie Apache oder Linux sowohl den Quellcode als auch die Fehlerhistorie jedem frei zugänglich, der sich dafür interessiert und diese genauer untersuchen möchte.
Aufgrund jahrelanger aktiver Verwendung sind die Charakteristiken der Software bekannt. Auch wenn die Software eigentlich »von unbekannter Herkunft«, also »SOUP« ist, kann sie genau wie selbst entwickelte Software geprüft werden: Jeder kann sie zum Beispiel einer symbolischen Ausführung oder Code-Coverage-Analysen unterziehen.
Somit könnte man meinen, Open-Source-Software wäre »clear SOUP« - wir können sie untersuchen, verifizieren und validieren, als hätten wir sie selbst geschrieben. Das klingt zunächst sehr attraktiv, aber leider ist Open-Source-Software auch nicht die optimale Lösung für medizinische Geräte, denn die Prozesse, unter denen die Software entwickelt wurde, sind nirgendwo sauber definiert und dokumentiert - genau das fordert aber der Standard IEC 62304.
Wir können nicht nachvollziehen, wie die Software entworfen, programmiert und verifiziert wurde. Aber ohne dieses Wissen ist der Nachweis unserer Aussagen zur funktionalen Sicherheit nahezu unmöglich. Dazu kommt noch, dass SOUP- oder COTS-Software häufig mehr Funktionen in das System einbringt als eigentlich benötigt. Das führt zu nie verwendeten Codeteilen, einem Zustand, von dem Standards zur funktionalen Sicherheit explizit abraten. Klar ist aber: Wenn ein Anbieter von COTS-Software den Quellcode des Produkts und seine Fehlerhistorie veröffentlicht, dann nähern wir uns »clear SOUP«.
Manche Anbieter gehen einen Schritt weiter und liefern nicht nur »clear SOUP«, sondern auch noch das Rezept dafür, indem sie ihren Kunden den genauen Entwicklungsprozess inklusive der gesamten Historie offenlegen - eine wichtige Belegesammlung, die wir verwenden können, um unsere Aussagen zur Zuverlässigkeit und Verfügbarkeit der Software zu untermauern. Andere gehen sogar noch weiter und geben alle Nachweise zur Untersuchung frei, die sie für Produktzertifizierungen (zum Beispiel gemäß IEC 61508 SIL3) bereitstellen mussten.
Einkauf von COTS-Software
Letztlich geht es bei der Verwendung von COTS-Software für ein medizinisches Gerät um die Frage: »Welchen Nachweis liefert der Anbieter, dass sein Produkt genau das ist, was wir brauchen?« Neben Aspekten wie Funktionsumfang, Kosten, Support, usw. interessiert uns vor allem, ob uns die COTS-Software dabei unterstützt, die notwendigen Zulassungen zu bekommen.
Wenn wir davon ausgehen, dass COTS-Software, nachdem wir sie ja nicht selbst entwickelt haben, irgendeine Form von SOUP ist, müssen wir feststellen, welche Form von SOUP es ist. Sollte es sich um Software handeln, für die wir keine ausreichende Dokumentation des Entwicklungsprozesses zur Verfügung haben, so wird es sehr schwierig, die Verwendung in unserem System zu rechtfertigen. Zum einen verursacht der Nachweis der funktionalen Sicherheit zusätzliche Arbeit und Kosten, zum anderen wird die Software nie den im Standard IEC 62304 geforderten Nachweis der Einhaltung definierter Software-Lebenszyklusprozesse erfüllen können.
Wenn die Software hingegen tatsächlich »clear SOUP« ist, wird unsere Arbeit bedeutend einfacher: Das ist dann der Fall, wenn die Software zwar womöglich nicht direkt für die Verwendung in einem Medizingerät entwickelt wurde, aber eine lückenlose Dokumentation der Entwicklungsprozesse vorliegt. Wenn eine Software alle Punkte der »COTS-Checkliste« erfüllt (siehe Kasten), dann haben wir einen heißen Kandidaten für unser Gerät gefunden.
Über den Autor:
Chris Hobbs ist Senior Developer Safe Systems bei QNX.
- COTS-Software für medizinische Geräte?
- Die Checkliste: COTS-Software in Medizinanwendungen
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Dynamische Softwareanalyse
Sicher trotz COTS-Software
Embedded Office
IEC-62304-Zertifizierungskit für Echtzeitkernel…
