Software-Entwicklung für die Endoskopie Sichere, schnelle minimalinvasive Chirurgie

Endoskopiegeräte werden immer komplexer, da der Markt auch hier kostengünstigere Lösungen mit immer mehr Funktionen verlangt. Zudem spielt die Geschwindigkeit der Geräte eine Rolle - wenn die »Schüsselloch«-Chirurgie schneller durchgeführt werden kann, erholt sich der Patient schneller und das medizinische Personal schafft mehr Operationen in der gleichen Zeit. Damit Endoskophersteller diese Anforderungen erfüllen können, sollten sie die richtigen Software-entwicklungstools für das Design, Debugging und die Validierung kritischer Softwarebestandteile zusammen mit einem zuverlässigen und sicheren Betriebssystem nutzen.

Für Entwickler medizintechnischer Geräte der Klasse II und III sind die Anforderungen beim Design sicherer und effizienter Geräte innerhalb eines bestimmten Zeitrahmens äußerst vielfältig. Im Mittelpunkt steht stets die Sicherheit des Patienten und des Bedienpersonals.

Um sichere und zuverlässige Geräte zu entwickeln, sind divergierende Aspekte zu erfüllen: kurze Time-to-Market, Wettbewerb, Entwicklungs- und Materialkosten sowie behördliche Auflagen.

Bis zum Jahr 2009 haben sich die meisten Softwareentwickler in der Medizintechnik auf Entwicklungsmethoden, Werkzeuge und Prozesse sowie Standards verlassen, die nicht für die Softwareentwicklung n der Medizintechnik optimiert waren.

Heute orientieren sich viele Unternehmen an Branchenstandards wie der IEC 62304, um sichere und effiziente Geräte schnell entwickeln zu können, ohne dabei Einbußen bei der Produktqualität und Sicherheit für Patienten und Bedienpersonal hinnehmen zu müssen.

Mit der IEC 62304 können Softwareentwickler einen international anerkannten Standard nutzen, der einen Rahmen für Lebenszyklus-Prozesse, Aktivitäten und Aufgaben rund um das Design und die Wartung medizintechnischer Software steckt (Bild 1).

Einige wichtige Aspekte tragen zum erfolgreichen Entwickeln komplexer medizintechnischer Geräte bei: Erstens, die effiziente Nutzung von Standards, die speziell für die medizintechnische Softwareentwicklung ausgelegt sind und die Risikobegrenzung während des Entwicklungsprozesses. Zweitens, die richtige Wahl der Hardware und des Betriebssystems (OS), was entscheidend für den Gesamterfolg des Projekts ist.

Daher wählte der Endoskophersteller Stryker Endoscopy das Echtzeitbetriebssystem »Integrity« von Green Hills Software. Die auf dem Betriebssystem laufende Applikationssoftware ist sehr komplex, sodass sich das Entwicklungsteam auch auf die integrierte Entwicklungsumgebung (IDE) »Multi« des Toolanbieters verlässt, um Anwendungen entwickeln, testen und verifizieren zu können, damit die Patientensicherheit garantiert wird. Bei der Entwicklung wurden sämtliche Funktionen der »Green Hills Platform for Medical Devices« genutzt.

Kritisch von unkritisch trennen

Neben einem formalen Regelwerk zur Softwareentwicklung, das schließlich zu einem verkürzten Zulassungsprozess führt, regt die IEC 62304 zu einer klaren Softwarearchitektur an. Die Entwickler müssen sämtliche Softwarebestandteile nach ihrer Sicherheitsrelevanz klassifizieren. Die Bestandteile werden in »A«, »B« oder »C« eingeteilt - je nach ihrer potenziellen Gefährdung für den Patienten oder Bedienenden.

Klasse »C« bedeutete dabei die Gefahr schwerster Auswirkungen wie Verletzung oder gar Tod. Anhand dieser Klassifizierung können die Entwickler kritische von nicht kritischen Anwendungen trennen. Diese lassen sich dann während der Laufzeit konzeptionell aufteilen, indem die Separations-Kernel-Architektur des Betriebssystems zum Einsatz kommt, welche die verschiedenen Anwendungen voneinander trennt (Bild 2).

Das System wird dadurch von Grund auf sicherer und zuverlässiger, da ein Fehler in einer Partition isoliert bleibt und laufende Anwendungen in einer anderen Partition nicht beeinträchtigen kann. Durch eine solche Trennung können sich mehrere Anwendungen auch die gleiche Verarbeitungseinheit teilen, was Kosten hinsichtlich der Gesamtstückliste und weiterer physikalischer Hardwareressourcen einspart.

Bei dieser Art von Softwarearchitektur hilft die IEC 62304 dabei, das System in Softwareeinheiten aufzuteilen, um die Units und das System einfacher verifizieren zu können. Die zugrunde liegende Betriebssystem-Technologie bietet den Anwendungen in den getrennten Adressräumen eine Methode, um effizient und fehlerfrei untereinander kommunizieren zu können. Mit dieser Architektur lassen sich auch die Schnittstellen zwischen den einzelnen Softwarebestandteilen darstellen, um die Anforderungen der IEC 62304 zu erfüllen.

Das Betriebssystem Integrity nutzt einen Echtzeit-Scheduler, der mehrere Prioritätsstufen unterstützt. Die Entwickler können somit einen periodenmonotonen Algorithmus verwenden, um allen Tasks Prioritäten zuzuweisen und somit die Schedulability des Systems zu maximieren und sicherzustellen, dass alle kritischen Zeitbedingungen erfüllt werden.

Die Partitionierungsarchitektur des OS eignet sich auch zur Einrichtung einer Überwachungseinheit (Health Monitor). Durch die Inter-Adressraum-Kommunikation des Betriebssystems kann diese Anwendung einfach mit allen laufenden Applikationen kommunizieren, um den Status aller kritischen und nicht kritischen Tasks im System zu überwachen. Die Überwachungseinheit kann damit dauerhaft nach Fehlern Ausschau halten und notwendige, kritische Tasks in sichere Zustände versetzen, sobald ein Fehler auftritt.

Mit der Partitionsaufteilung wurde auch ein Adressraum erstellt, der die Kommunikation zu und von anderen Geräten von Stryker Endoscopy im Operationssaal handhabt. Mit einem eigenen Schnittstellenbus können Geräte des Herstellers untereinander kommunizieren, was eine nahtlose Integration, einen Datenaustausch und eine universelle Steuerung von einer zentralen Stelle aus ermöglicht.

Durch die Implementierung als partitionierter Adressraum wird die Software und Hardware modularisiert und lässt sich einfach auf ein anderes Gerät des Herstellers portieren, welches zukünftig vielleicht das gleiche OS verwendet. Die Architektur des Betriebssystems unterstützt eine Virtualisierung, die Stryker Endoscopy allerdings bei diesem Gerät nicht nutzt. Damit könnten verschiedene Gast-Betriebssysteme zusammen auf einer Plattform neben dem Host-Betriebssystem laufen (Bild 2).

Stryker kann damit in Zukunft verschiedene Betriebssysteme für unterschiedliche funktionskritische Ebenen installieren. So könnte »Android« auf einer virtuellen Maschine laufen und die Benutzerschnittstelle steuern; und das ausgewählte OS könnte auf einer anderen virtuellen Maschine laufen und wäre für alle sicherheitskritischen Funktionen verantwortlich.

Von der Entwicklung der Architektur bis zum detaillierten Design und zur Implementierung ermöglicht die integrierte Entwicklungsumgebung das schnelle Entwickeln, Testen und modifizieren der Applikation, um beispielsweise Softwareelemente in die entsprechenden OS-Partitionen zu platzieren. Im vorliegenden Endoskop-Projekt war der ARM-Target-Simulator besonders hilfreich, mit dem sich das Design durch Testen und Debuggen lange vor der Verfügbarkeit der Hardwareplattform validieren lässt, was Zeit und Geld einspart.

Mit der richtigen Umgebung schnell entwickeln

Die Softwareelemente, die innerhalb einer Partition arbeiten, werden zu wiederverwendbaren Elementen, die in zukünftigen Medizingeräten zum Einsatz kommen können. Für das Testen von Benutzerschnittstellen und zum Prototyping ermöglichen die IDE und das Betriebssystem eine schnelle Modellierung der Benutzerschnittstelle, um einen korrekten Betrieb zu gewährleisten.

Dazu kamen bei Stryker die GUI-Softwarelösung »PEG+« von Swell Software und der Screen-Designer »PEG WindowBuilder« zum Einsatz. Benutzerfreundlichkeit ist ein wesentliches Merkmal für einen sicheren Betrieb medizinischer Geräte. Ein Prototyping in dieser Sache gewährleistet daher auch die richtige Funktion. Viele Faktoren beeinflussen die Codequalität. Dazu gehören auch die Fertigkeiten der Softwareentwickler sowie die Tools und die Entwicklungspraktiken.

Nach IEC 62304 hat jede Softwarekomponente ihren eigenen Verifikationsprozess. Als Teil dieses Prozesses nutzten die Entwickler bei Stryker die optimierten Debugging- und Testtechniken der IDE »Multi«.

Im Einklang mit anerkannten Praktiken verwendete das Team während des Softwareentwicklungsprozesses ein Tool zur statischen Analyse, wobei eine Reihe von Fehlern beseitigt wurden, die sonst durch den Compiler oder durch eine erneute Code-Durchsicht nicht einfach aufzudecken gewesen wären. Zu solchen Fehlern zählen zum Beispiel Pufferüberläufe, Ressourcenlecks und Nullzeiger-Dereferenzierungen.

Ebenfalls genutzt wurde das IDE-interne Werkzeug zur statischen Analyse, das eine enge Kopplung zwischen dem Static-Analysis-Tool und dem Debugger herstellt, sodass sich Entwicklungsarbeit schnell und iterativ gestaltet. Damit lässt sich eine statische Analyse automatisch während des Kompiliervorgangs erledigen, anstatt diese manuell nach der Kompilierung durchführen zu müssen.

Während Werkzeuge zur statischen Analyse zu einer höheren Codequalität beitragen, reichen sie alleine aber nicht dazu aus, die Qualität einer Anwendung zu gewährleisten. Daher nutzte das Team auch das Code-Profiler-Tool der IDE, das einen umfassenden Bericht über die zeilenweise Codeausführung erstellt und somit angibt, welche Zeilen des Anwendungscodes ausgeführt wurden.

Damit lassen sich Unit-Tests erstellen, die alle Elemente des Codes genau ausführen. Dies spart im Gegensatz zur manuellen Durchführung Zeit, Aufwand und Kosten. Die gesamte Dokumentation ist leicht zugänglich und wird automatisch erstellt. Wie bei der Entwicklung von Embedded-Software üblich, sind es nur wenige Fehler, für deren Behebung die meiste Zeit aufzubringen ist.

In solchen schwierigen Situationen hilft die Debugging-Umgebung, Probleme mit Task-Prioritäten (Bild 3) als auch Probleme in hardwarenahen Programmteilen zu lösen. Mithilfe der Trace-Daten lässt sich der Code beim Debugging zeitlich vorwärts und rückwärts durchsuchen, was die Fehlersuche erheblich vereinfacht. Diese Funktion war maßgeblich an der Lösung sicherheitskritischer Probleme des Medizingeräts beteiligt. In der Regel ermöglichen diese Werkzeuge eine einfache Untersuchung der Systemereignisse, der Daten- und Ablaufsteuerung, der Ressourcen-zuweisung, der Selbstdiagnose und des Speichermanagements.

Über die Autoren:

Stefan Benamou ist Staff Engineer bei Stryker Endoscopy und Jim McElroy ist Director Industry Business Development bei Green Hills Software.