Software für Medizingeräte Fünf Tipps für die statische und dynamische Code-Analyse

Anbieter zum Thema

Parasoft® Deutschland GmbH

MES Electronic Connect GmbH & Co. KG

IBR Leiterplatten GmbH & Co. KG

RECOM Power GmbH

Statische und dynamische Analysen sind der Schlüssel zur Einhaltung von Vorschriften beim Testen von Software, aber die Verfahren sind nicht einfach zu implementieren. Auch die Cybersicherheit ist ein wichtiger Schwerpunkt mit spezifischen Anforderungen an die statische und dynamische Code-Analyse.

Die zunehmende Vernetzung und Komplexität moderner Medizingeräte durch Techniken wie künstliche Intelligenz, maschinelles Lernen und das Internet der Dinge stellt Hersteller vor große Herausforderungen. Laut Schätzungen der WHO sind weltweit etwa zwei Millionen Medizingeräte im Einsatz, die eine wichtige Rolle in modernen Gesundheitssystemen spielen. Diese Geräte müssen strenge regulatorische Richtlinien einhalten, um die Sicherheit und Wirksamkeit zu gewährleisten.

Die statische und dynamische Code-Analyse bei Medizingeräten

Statische und dynamische Softwareanalysen sind entscheidend, um die Einhaltung dieser Vorschriften sicherzustellen. Allerdings sind diese Verfahren nicht einfach zu implementieren. Die FDA legt besonderen Wert auf die Cybersicherheit von Medizingeräten und hat spezifische Anforderungen an die statische und dynamische Code-Analyse definiert.

Software ermöglicht in immer mehr Medizingeräten wichtige Funktionen. Dazu gehören beispielsweise medizinische Bilder zu analysieren oder Diagnosen zu erstellen, der Einsatz intelligenter Implantate mit Sensoren oder robotergestützte chirurgische Eingriffe. Software für Medizingeräte hat die Medizin zwar vorangebracht, birgt aber auch Risiken. Zu den Ursachen zählen Programmierfehler, Fehlfunktionen der Hardware oder Anwenderfehler.

Eine gründliche Risikoanalyse ist unerlässlich

Diese Risiken können Patienten, medizinisches Personal oder andere Personen schädigen. Zusätzlich bergen die Geräte Risiken für die Cybersicherheit, da sie medizinische Daten erfassen, speichern, verarbeiten und übertragen. Darum unterliegt die Programmierung und der Einsatz von Medical-Device-Software-Regulierungsbehörden wie der Food and Drug Administration (FDA) und der European Medical Device Regulation (MDR). Um jedoch zu wissen, ob die Software für medizinische Geräte den Vorschriften entspricht, ist eine gründliche Risikoanalyse unerlässlich.

Die Software ist oft komplex und muss innerhalb strenger Standards funktionieren. Potenzielle Risiken, die während des Entwicklungsprozesses auftreten können, müssen identifiziert, analysiert und schließlich minimiert werden. Ein effektives Risikomanagement bei der Programmierung von Software für Medizinprodukte umfasst eine Reihe verschiedener Aktivitäten (Bild 1):

• Identifizierung potenzieller Gefahren und Risiken im Zusammenhang mit dem Gerät und seiner Software.

• Bewertung der Wahrscheinlichkeit und des Schweregrads der Risiken.

• Implementierte Risikokontrollen mindern oder beseitigen Gefahren.

• Wirksamkeit dieser Kontrollen überwachen.

Der regulatorische Rahmen mit ISO 13485 und IEC 62304

Die ISO 13485 und IEC 62304 sind zwei wichtige Normen, die Hersteller von Medizinprodukten und zugehöriger Software einhalten müssen, um die behördlichen Anforderungen zu erfüllen. Die ISO 13485 legt die Anforderungen für ein umfassendes Qualitätsmanagementsystem für das Design und die Herstellung von Medizinprodukten. Darüber hinaus definiert die internationale Norm IEC 62304 die zu berücksichtigenden Softwareentwicklungsprozesse, Dokumentationsanforderungen sowie Verifikations- und Validierungsverfahren für Medical Device Software. Beide Normen bilden einen gemeinsamen Handlungsrahmen für alle Lebenszyklusprozesse für Software für Medizinprodukte und dienen als Standards für Risikoanalysen bei Medizinprodukten.

Ihre Einhaltung ist zwingend für die behördliche Genehmigung der Entwicklung von Medical Device Software und für den Nachweis, dass ein Hersteller hochwertige Produkte liefern kann. Um diese regulatorischen Vorgaben einzuhalten, müssen Hersteller die Softwaretests ihrer Medizinprodukte regelmäßig auf Programmierfehler, Verstöße gegen Programmierstandards, Syntaxverletzungen oder unsichere Konfigurationen überprüfen. Hierfür kommen statische Code-Analyse und dynamische Analyse zum Einsatz.

Die statische Code-Analyse

Die statische Code-Analyse überprüft automatisch, ob bekannte Programmierrichtlinien wie MISRA, CERT, AUTOSAR oder JSF eingehalten werden und sie erkennt potenzielle Fehler wie Nullzeiger-Dereferenzierung, Division durch Null und Pufferüberläufe. Moderne statische Analysewerkzeuge ergänzen die traditionelle Code-Review-Praxis, indem sie den manuellen Aufwand um mindestens 30 Prozent reduzieren.

In den meisten Fällen wird der erste Durchlauf eines statischen Analysewerkzeugs gegen den aktuellen Code Tausende von Fehlern aufdecken, beispielsweise mehr als 20.000. Es scheint, als brauchte es Jahre, um sie alle zu beheben.

Fünf Expertentipps für die statische und dynamische Code-Analyse

Tipp 1: Disziplinierte Entwicklungsteams kompilieren in der Regel mit -Wall und -Werror (in GCC), oder /Wall /WX (in Visual Studio) oder mit ähnlichen Optionen in anderen Compilern. Eine einfache und kostengünstige Möglichkeit, sich auf die Ausführung der statischen Analyse vorzubereiten, ist das Beheben von Compiler-Warnungen. Die Überprüfung der Compiler-Ausgabe in einem paranoiden Modus kann das Gesamtvolumen der Verstöße gegen die statische Analyse senken. Viele Compilerwarnungen sollten behoben werden. Doch es gibt Projekte, bei denen ein Compiler allein nicht ausreicht und aus Compliance-Gründen keine akzeptable Option ist. Ist der Compiler geleert, sollte man statische Analysewerkzeuge verwenden, die wesentlich tiefer in den Code eindringen und viele weitere Hinweise liefern.

Tipp 2: Entwickelt man Software für Medizinprodukte, sollten man sich mit dem Thema der automatisierten statischen Code-Analyse befassen. Die statische Analyse wird sicherlich ein Diskussionsthema bei einem internen/externen Audit oder sogar bei einer Einreichung vor der Markteinführung sein. Der Schlüssel liegt darin, das Werkzeug so einzusetzen, dass die Entwicklung nicht an Dynamik verliert, während man sich auf die Qualitätsverbesserung konzentriert und sich nicht mit den Eigenheiten und dem Rauschen des Werkzeugs auseinandersetzen muss. Diese Gratwanderung erfordert Übung und Fachwissen. Geht man der Ursache der gemeldeten Fehler auf den Grund, wird man wahrscheinlich feststellen, dass viele von ihnen leicht zu beheben sind.

Viele Verstöße gegen den bestehenden Code müssen nicht sofort bearbeitet werden, sondern es reicht in Ausfallzeiten. Wichtig ist, bei der Entwicklung von Code keine neuen Verstöße einzubauen (sogenannte technische Schulden). Moderne Tools wie Parasoft C/C++test verfügen über Funktionen, die das Rauschen herausfiltern und sich auf das Beheben der dringendsten aktuellen Verstöße gegen die statische Analyse konzentrieren können. Das Dynamic Application Security Testing (DAST) prüft den laufenden Code und zeigt die Codeabdeckung, die Angemessenheit und Qualität von Unit-Tests, Speicherlecks und andere potenzielle Schwachstellen auf.

Tipp 3: Wenn die Hauptzielplattform nicht standardmäßig unterstützt wird, sollte man nach geeigneten Alternativen suchen. Vielleicht gibt es eine Schwesterplattform mit mehr Schnittstellen und Speicher, die von einem dynamischen Analysewerkzeug unterstützt wird, so dass sie für Unit-Tests und einige Integrationstests verwendbar ist. Eine weitere Alternative ist der Einsatz von Hardwaresimulatoren, die ARM Fast Models und QEMU ausführen. Obwohl Tests auf der Zielplattform besser sind, entscheiden sich viele Teams für Unit-Tests und einige Anwendungsintegrationstests auf der Workstation des Entwicklers (Linux, Mac, Windows), um von einem schnelleren Entwicklungszyklus und einer größeren Anzahl von Tools zu profitieren. In diesem Fall muss der eingebettete Code für die Kompilierung mit einem Host-Compiler portiert werden.

Es gibt eine Vielzahl von Compilern, Build-Tools, Frameworks und Ausführungsmethoden. Dynamische Analysewerkzeuge unterstützen einige Build-Techniken mit internen Annahmen darüber, wie Entwickler sie verwenden könnten. Selbst wenn der Code portabel ist, wird das Projektteam daher höchstwahrscheinlich zusätzliche Zeit benötigen, um die Einstellungen eines dynamischen Analysewerkzeugs an das Build-System des Projekts anzupassen. Es wird dringend empfohlen, den Aufwand im Voraus abzuschätzen, um den besten langfristigen Ansatz für die zukünftige Entwicklung und Unterstützung zu finden.

Tipp 4: Moderne dynamische Analysewerkzeuge generieren automatisch Sätze von Unit-Tests, um die Codeabdeckung zu erhöhen. Aber Werkzeuge sind unabhängig von den verschiedenen Szenarien, in denen der produktive Code verwendet werden soll. Vor allem wenn die Codeabdeckung erhöht und die Grenze zwischen reinen Unit-Tests und Integrationstests überschritten werden soll. Der generierte Unit-Test muss manuell aktualisiert und es müssen neue Tests geschrieben werden. Nur Entwickler wissen, was der Code bei positiven und negativen Testergebnissen tun soll.

Für eine Reihe ausgewählter Dateien in einem kritischen Abschnitt können die automatisch generierten Unit-Tests von 40 bis 100 Prozent für jede Datei abdecken. Im Durchschnitt liegen die Werte für das gesamte Projekt zwischen 25 und 60 Prozent. Automatisch generierte Unit-Tests, die nur den Quellcode als Eingabe verwenden, können oft perfekt auf fehlerhaftem Code laufen. Die automatische Generierung sollte als guter Einstieg in den Unit-Test-Prozess genutzt werden. Die manuelle Erstellung von Testfällen verbessert die Qualität des Codes.

Tipp 5: Die FDA verlangt, dass alle Werkzeuge, die während der formalen Entwicklung zum Einsatz kommen, für den beabsichtigten Gebrauch validiert werden. In der Regel mit dem speziellen Testprotokoll namens IUV (Intended Use Validation). Führende Anbieter von statischen und dynamischen Analysewerkzeugen erstellen die notwendigen Prozeduren und Dokumentationen. Wie bei jedem generischen Paket sollte ein Teil des Aufwands für die Überprüfung und Anpassung der Dokumente reserviert werden. Das Qualification Kit von Parasoft bietet eine Reihe von Testfällen, die man in der eigenen Umgebung ausführen kann.

Eine Suite von Software-Testautomatisierungslösungen von Parasaoft bietet Best Practices für den Test medizi­nischer Geräte in C/C++-, Java- und .NET-Anwendungen. (heh)

Lesen Sie außerdem

Digitale Produkte

Wann ist eine Software ein Medizinprodukt?

MDR-Compliance

Klinische Bewertung elektronischer und digitaler Medizinprodukte

* Ricardo Camacho ist Director of Safety & Security Compliance bei Parasoft.

(ID:50019213)