Software-Lifecycle-Management für medizinische Geräte
Updates - Alarmstufe Rot!
Fehlerbehaftete Software kann für die Hersteller enorme rechtliche und finanzielle Risiken bergen - von den Gefahren für die Sicherheit und Gesundheit der Patienten einmal ganz abgesehen. Aber auch bei Updates und Post-Release-Software gilt Alarmstufe Rot, wie eine Studie der FDA belegt. Grund ist oft die lückenhafte Reproduzierbarkeit des Entwicklungsprozesses. Durch die Anwendung eines Application-Lifecycle-Managements im Rahmen des Gesamtprojekts lassen sich diese Risiken wirksam abmildern.
Fast achtzig Prozent der softwarebedingten Rückrufe sind auf Defekte zurückzuführen, die bei Änderungen an der Software nach der ursprünglichen Produktion und Distribution entstanden. Dies ist das Ergebnis einer Studie, in der die Food and Drug Administration (FDA) insgesamt 3140 Rückrufe medizinischer Geräte zwischen 1992 und 1998 untersuchte. Hauptursache dieser kritischen Fehler war die Reproduzierbarkeit. Die FDA weist jedem Softwaremodul in einem medizinischen Gerät abhängig davon, wie kritisch es für dessen Sicherheit ist, einen Software-Bedenklichkeitsgrad (Software Level of Concern) zu: »major« (erheblich), »moderate« (mittel) oder »minor« (geringfügig) (Tabelle 1).
| Software Level of concern | Beschreibung |
|---|---|
| major (erheblich) |
Ein Ausfall oder ein latenter Fehler kann direkt zum Tod oder zu einer schwerwiegenden Gesundheitsschädigung des Patienten oder Bedieners führen oder durch falsche oder verzögerte Information bzw. durch das Handeln des Gesundheitsdienstleisters indirekt den Tod oder eine schwerwiegende Gesundheitsschädigung des Patienten oder Bedieners zur Folge haben. |
| moderate (mittel) | Ein Ausfall oder ein latenter Fehler kann direkt zu einer geringfügigen Gesundheitsschädigung des Patienten oder Bedieners führen oder durch falsche oder verzögerte Information bzw. durch das Handeln des Gesundheitsdienstleisters indirekt eine geringfügige Gesundheitsschädigung des Patienten oder Bedieners zur Folge haben. |
| minor (geringfügig) |
Es ist unwahrscheinlich, dass Ausfälle oder latente Fehler Gesundheitsschädigungen für Patienten oder Bedieners zur Folge haben. |
Tabelle 1: Die FDA ordnet medizinische Geräte gemäß dem »Software Level of Concern« ein. Dieser basiert auf einer Abschätzung der Schwere einer Gesundheitsschädigung für einen Patienten oder Bediener, die ein Gerät infolge von Ausfällen, Fehlern oder schlicht durch seinen bestimmungsgemäßen Gebrauch ermöglichen oder verursachen kann.
Reichen Hersteller ein Gerät zur Zertifizierung ein, so müssen sie nachweisen, dass die Gefahren angemessen identifiziert sind und ein effektives Risikomanagement erfolgt. Dies müssen sie um eine Rückverfolgbarkeit vom Design über die Implementierung und den Test bis zum Risikomanagement ergänzen. Um auf dem internationalen Markt agieren zu können, müssen die Hersteller außerdem weitere Gesetze und Vorschriften erfüllen, was diese Aufgabe noch komplizierter macht.
Beispiele in Bezug auf Medizingeräte sind die Normen ICS 11.100.20 und ICS 11.040.01, die IEC 62304 und die FDA-Richtlinie nach dem Code of Federal Regulations, 21 CFR Subchapter H - Medical Devices. Es überrascht daher nicht, dass die Hersteller medizinischer Geräte beklagen, achtzig Prozent ihres Budgets für die Softwareentwicklung werde von der Dokumentation und den Tests verschlungen.
Ist die Entwicklung von Medizingeräte-Software jedoch ein reproduzierbarer Prozess, so ist sichergestellt, dass für die Zertifizierung des ursprünglichen Produkts ebenso wie für jede spätere Version immer die gleichen Software-Qualitätskriterien angewandt werden. Die Kriterien für die Softwarequalität berücksichtigen dabei nicht nur die zentrale Funktion des Geräts, sondern auch den Safety-Integrity-Level, der von der FDA als Software-Level-of-Concern eingestuft wird. So wäre es beispielsweise wirtschaftlich nicht sinnvoll, bei der Entwicklung der Software für ein elektronisches Fieberthermometer (Bedenklichkeitsgrad: geringfügig) die gleichen strikten Vorgaben anzuwenden wie bei der Software für einen Defibrillator (Bedenklichkeitsgrad: erheblich).
Richtlinien zur Einführung eines reproduzierbaren Prozesses für die Qualitäts- und Sicherheitsanforderungen medizinischer Geräte, der die internationalen Normen erfüllt oder übertrifft, können von der FDA und der internationalen Gemeinschaft bezogen werden. In ihrem Dokument »Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices« vom 11. Mai 2005 umreißt die FDA klar die für die Zertifizierung eines medizinischen Geräts erforderliche Dokumentation. Demnach müssen darin die Spezifikation der Software-Anforderungen und des Softwaredesigns sowie die Rückverfolgbarkeit enthalten sein.
Notwendig ist auch eine Beschreibung der Software-Entwicklungsumgebung. Darin muss skizziert sein, welcher beziehungsweise welche Softwareentwicklungs-Prozesse für das Gerät verwendet wurden. Die FDA erkennt hierfür als Konsensstandard die internationale Norm IEC 62304 (Medizingeräte-Software - Software-Lebenszyklus-Prozesse) an. Somit genügt jeder Software-Entwicklungsprozess, der dieser Norm entspricht, auch den Vorschriften der FDA.
Reproduzierbarkeit als Schlüssel
Die Definition eines reproduzierbaren Software-Entwicklungsprozesses ist von entscheidender Bedeutung. Bild 1 zeigt den Entwicklungsprozess, den die IEC 62304 für Medizingeräte-Software propagiert. Dabei handelt es sich um einen rigorosen Prozess, der durch die gesamte Softwareentwicklung hindurch das Konzept des Risikos (bzw. der Sicherheit) enthält. Auch schließt es die Notwendigkeit von Konfigurationsmanagement- und Mängelverfolgungssystemen (Defect Tracking) ein.
Die FDA-Forderung nach Reproduzierbarkeit setzt auf der IEC 62304 auf, denn der dort beschriebene Software-Entwicklungsprozess gilt als Schlüsselfaktor. So ist gewährleistet, dass jede abstrakte, also auf der höchsten Ebene formulierte Anforderung, die ihren Ursprung in dem mit »Systementwicklungsaktivitäten« (Bild 1) bezeichneten Schritt hat, vom Anforderungs-Zerlegungsbaum durch den Softwaredesignprozess hindurch bis zur Implementierung und Umsetzung in Programmcode verfolgt werden kann. Diese Rückverfolgbarkeit muss sich schließlich auch auf die Validierungs- und Verifikationsaktivitäten erstrecken, mit denen sichergestellt wird, dass die Medizingeräte-Software die an sie gestellten Funktions- und Sicherheitsanforderungen erfüllt.
Das Resultat ist eine Rückverfolgbarkeitsmatrix (Requirements Traceability Matrix, RTM), die sämtliche Rückverfolgbarkeitsinformationen in einem einzigen Dokument oder einer Datenbank zusammenfasst. Diese RTM bildet die Zerlegung einer jeden Anforderung in eine oder mehrere Unteranforderungen, Designelemente und Code sowie Validierungs- und Verifikationsaktivitäten ab.
Das Umgekehrte ist ebenso möglich: Alle Validierungs- und Verifikationsaufgaben, Designelemente und Unteranforderungen lassen sich zu der beziehungsweise den ihnen zugrundliegenden Anforderungen - ob primär oder abgeleitet - zurückverfolgen. Eine RTM zu pflegen hat zwei Vorteile: Erstes unterstützt sie den Zertifizierungsprozess, indem die RTM klar dokumentiert, wie die abstrakt formulierten Anforderungen als Code umgesetzt wurden.
Zweitens hilft sie bei der Beurteilung der Auswirkungen von Anforderungen beziehungsweise von Design- oder Softwareänderungen. Der letztgenannte Punkt ist besonders wichtig im Zusammenhang mit Post-Release-Software, denn die Konsequenzen jeglicher Änderungen lassen sich präzise abschätzen, indem ermittelt wird, wie viele Anforderungen, wie viele Design- und Codeelemente sowie wie viele Verifikations- und Validierungsaktivitäten betroffen sind.
Im Zusammenhang mit Anforderungen sind die beiden hauptsächlichen Anforderungsquellen sorgfältig zu beachten: primäre Anforderungen, die sich aus der funktionalen Definition des Systems ergeben, und abgeleitete Anforderungen, die aus einer primären Anforderung gefolgert oder abgeleitet werden. Zum Beispiel kann eine primäre Anforderung besagen, dass ein System in der Lage sein muss, »zwischen den Blutgruppen 0 und B zu unterscheiden«.
Eine abgeleitete Anforderung kann aus der Anwendung einer proprietären Labortechnik bestehen, einschließlich möglicherweise notwendiger Rahmenbedingungen für diese Bestimmung. Eine Rückverfolgbarkeitslösung muss sowohl primäre als auch abgeleitete Anforderungen abdecken. Von ganz einfachen Medizingeräte-Softwareprojekten einmal abgesehen, ist das manuelle Erstellen und Pflegen einer Traceability-Matrix eine mühevolle und fehleranfällige Aufgabe, wenn sie zwischen den abstrakten High-Level- und ausformulierten Low-Level-Anforderungen erfolgt. In einem typischen Projekt wird sich die Zahl der Anforderungen auf der System- und Betriebsebene im Zuge der Zerlegung in Unteranforderungen bis um den Faktor fünf erhöhen.
Hoher Aufwand für die Traceability-Matrix
Kommen noch die abgeleiteten Anforderungen hinzu und bildet man alles auf das Design und die Code-Implementierung ab, wird das manuelle Erstellen und Managen der Traceability-Matrix noch um ein Vielfaches komplexer. Werden abgesehen von diesen manuellen Traceability-Arbeiten auch die Validierungs- und Verifikationsaktivitäten mit einbezogen, so wird deutlich, weshalb der Arbeitsaufwand und die Fehlerwahrscheinlichkeit um eine Zehnerpotenz ansteigen. Dazu ein konservatives Beispiel: Wenn sich jede abstrakte Anforderung in fünf Unteranforderungen auffächert, die wiederum auf jeweils eine Prozedur im Programmcode abgebildet wird, und wenn wiederum jede dieser Prozeduren für die Validierung und die Verifikation fünf Testfälle benötigt (Known-good- und Known-bad-Eingänge sowie Grenzwerttests für drei Eingangsparameter), so wird sofort klar, um welch eine anspruchsvolle Aufgabe es sich hier handelt.
Schließlich muss die RTM die 1:1-, 1:n- und n:1-Abbildungen von den ursprünglich einhundert Anforderungen über die Zerlegung in fünfhundert Unteranforderungen bis zu den fünfhundert Prozeduren im Programmcode sowie schließlich bis zu den 2500 Testfällen verfolgen. Es mag deshalb verlockend sein, diesen Schritt einfach wegzulassen.
Die Auswirkungen, die diese Abbildung von den abstrakten Anforderungen über die Zerlegung, das Design und die Implementierung bis zur Validierung und Verifikation hat, sind jedoch speziell für die Zertifizierung von so großer Tragweite, dass sie keinesfalls ignoriert werden können. Durch eine automatisierte Requirements-Traceability-Lösung kann ein Entwicklungsteam jedoch die unzähligen Details auf kosteneffektive Weise beherrschen.
Angesichts der Tatsache, dass jedes Medizingeräteprojekt, in dem Software vorkommt, mindestens einen Prozessor, eine integrierte Entwicklungsumgebung (IDE) und ein Echtzeitbetriebssystem (RTOS) sowie andere Entwicklungswerkzeuge enthält, sollten die Entwicklungsteams nach einer Lösung Ausschau halten, die der enormen Vielfalt kleinster Details in Embedded-Geräten Rechnung trägt und auf diese Weise sicherstellt, dass ein reproduzierbarer Software-Entwicklungsprozess ausgearbeitet und aufrechterhalten werden kann.
Die Rückverfolgung von Anforderungen über sämtliche Phasen der Softwareentwicklung hinweg wird häufig als »Application Lifecycle Management« (ALM) bezeichnet. Möglich wird das ALM mithilfe von Tools zur Vereinfachung und Integration von Software-Entwicklungsaktivitäten, zu denen das Anforderungsmanagement, die Rückverfolgbarkeit, die Codierung, die Softwareanalyse, das Testen und das Konfigurationsmanagement gehören.
Gleich ob es um eine Anforderung, eine Codezeile oder einen Testfall geht - jedes im Zuge des Entwicklungsprozesses entstehende Artefakt hat seinen eigenen Lebenszyklus und Arbeitsablauf. Der ALM-Lösung kommt hierbei die Aufgabe zu, ein Gerüst zu schaffen, welches das Erstellen und Ausarbeiten eines jeden Artefakts in seinem gesamten Lebenszyklus als Komponente eines kompletten Produkts unterstützt.
Bild 2 illustriert den Weg einer ALM-Lösung durch die verschiedenen Funktionsabschnitte in einem Embedded-Software-Entwicklungslebenszyklus. Die Toolsuite von LDRA folgt jedem dieser Abschnitte. Dabei fungiert »TBmanager« als die Schnittstelle, welche die Requirements-Traceability-Verbindungen zwischen den verschiedenen Komponenten einer Applikation grafisch abbildet. Unabhängig davon, ob es sich um ein neues Produkt oder um eine neue Version eines bestehenden Produkts handelt, beginnt der Ablauf in der Regel mit der Erfassung der Anforderungen. Hier verwendet man entweder eine formelle Requirements-Management-Lösung oder greift auf herkömmliche Textverarbeitungswerkzeuge zurück.
Mit zunehmender Weiterentwicklung und Ausarbeitung der Anforderungen werden diese in Unteranforderungen zerlegt. Auch abgeleitete Anforderungen kommen in dieser Phase ins Spiel. Eine Embedded-ALM-Lösung unterstützt sowohl das Requirements-Management als auch die Fähigkeit, die Entwicklung der Anforderungen durch den Zerlegungsprozess zu verfolgen, einschließlich der Umsetzung der Anforderungen in der Softwaredesign-Phase.
Rückverfolgbarkeit rechnergestützt managen
Ist diejenige Phase des Prozesses erreicht, in der mit dem Schreiben des Codes begonnen wird, schließt die ALM-Traceability-Lösung auch die Software selbst ein, sodass eine lückenlose Abbildungskette von den abstrakten Anforderungen durch das Design hindurch bis zum eigentlichen Code besteht. In dieser Phase kann die Validierung und Verifikation des Codes erfolgen.
Die Validierung und Verifikation sicherheitskritischer Embedded-Software gliedert sich in eine Reihe verschiedener Phasen, beginnend mit dem Erstellen des ersten Codes. Eine Embedded-ALM-Lösung leistet angefangen beim Schreiben des Codes Hilfestellung beim Erstellen qualitativ hochwertiger Software. Hierzu dient eine Kombination aus statischer Analyse, Unit- und Modul-tests sowie dynamischer Code-Analyse.
Eine statische Analyse beurteilt den in Entwicklung befindlichen Code, ohne ihn auszuführen, und stellt damit sicher, dass Fehler und Defekte im Code zum Zeitpunkt des Erstellens aufgedeckt werden können. Verschiedene Branchen haben eine Reihe von Codierungsstandards speziell für High-Reliability-Software entwickelt. Medizintechnik-Entwickler können Konzepte von diesen Branchen übernehmen und darüber hinaus auch andere sicherheitskritische Standards wie MISRA-C:2004 beziehungsweise MISRA C++ (Motor Industry Software Reliability Association) anwenden.
Diese Standards identifizieren Codekonstrukte, die bekanntermaßen latente Defekte in der Software hervorrufen, welche die Verlässlichkeit beeinträchtigen und somit vermieden werden sollten. Statische Analyse-Tools setzen diese Standards durch und decken zusätzlich weitere Softwareprobleme (z.B. unnötige Komplexität) auf, die sich auf die Prüfbarkeit oder Pflegbarkeit des Codes auswirken.
Sobald verifiziert ist, dass der Medizingeräte-Code den gewählten Codestandard erfüllt, ist er bereit für die Unit- und Modultests. Sind die Unit- und Modultest-Tools in eine Embedded-ALM-Lösung eingebunden, lassen sich anforderungs-basierter Tests erstellen. Das Elegante an dieser Integration in eine ALM-Lösung ist, dass sich das Ergebnis dieser Tests (bestanden/nicht bestanden) zurück auf die ursprünglichen Anforderungen abbilden lässt, sodass die Projektleiter den aktuellen Status stets im Blick haben.
Bei der Ausführung des Codes im Zuge von Unit-, Modul- oder Systemtests besteht die Möglichkeit, den Code einer dynamischen Analyse zu unterziehen. Zum Beispiel ist es mit einer Überdeckungsanalyse möglich, die bisher erreichte Testeffektivität zu ermitteln. Auch hier überprüft die ALM-Integration die Vollständigkeit der Informationen und den Rückbezug aller Artefakte zu den ursprünglichen Anforderungen, sodass die Projektmanager den aktuellen Status überwachen können.
Eine ALM-Lösung erlaubt nicht nur die Überwachung und das Management von Software während ihres Entwicklungsprozesses, sondern sorgt außerdem für die Rückverfolgbarkeit der Anforderungen durch den Entwicklungsprozess hindurch bis zum Code. Die zugehörigen Verifikationsaktivitäten mitsamt ihren Ergebnissen stellen ferner sicher, dass sich die Dokumentation für den Projektstatus und/oder die Zertifizierung auf Knopfdruck erstellen lässt.
Die monatelange Arbeit im Zuge eines manuellen Traceability-Prozesses entfällt damit. Erfahrungen aus anderen Branchen wie etwa der Avionik haben gezeigt, dass das Streben nach Zertifizierung eines sicherheitskritischen Softwareprojekts Anreize für die Anwendung reproduzierbarer Software-Entwicklungsprozesse schafft. Entwicklungsprozesse in der Avionik haben immer wieder bewiesen, welchen Nutzen die Anwendung rückverfolgbarer Anforderungen in einem Toolpaket hat, das mit den zahlreichen wechselseitigen Beziehungen in einem Applikations-Lebenszyklus zurechtkommt.
Über den Autor:
Bill St. Clair leitet die US-Niederlassung von LDRA Technology. Er war leitender Architekt des Embedded-Syste-Verifikationstools TBreq.
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
