Funktionale Sicherheit bei medizinischen Betriebssystemen ist grundlegend erforderlich. Daher nutzt man meist Realtime Operating Systems (RTOS).
Ein kritisches Element in jedem digitalen medizinischen Gerät ist sein Betriebssystem. Medizinische Geräte sind nicht wie Desktop-PCs. Sogar für FDA-Geräte der Klasse I und II sind zufällige Ausfälle und Neustarts nicht akzeptabel. Benutzer werden konditioniert fehlerhaftes Verhalten von ihrem Desktop PC zu erwarten, wenn es aber um die Gesundheit von Patienten geht, ist dieses Verhalten nicht tolerierbar.
Wenn funktionale Sicherheit für ein Gerät erforderlich ist, sollte das eingesetzte Betriebssystem ein Realtime Operating System (RTOS) sein. RTOSs sind entwickelt worden, um Verfügbarkeit und Zuverlässigkeit zu gewährleisten, damit Geräte, in denen sie eingesetzt werden, strenge technische und gesetzliche Anforderungen erfüllen können.
RTOS-Architekturen
Die beiden gängigsten RTOS-Architekturen sind monolithische Kernel und Microkernel. Im monolithischen Modell werden zwar Benutzer-Applikationen als speichergeschützte Prozesse ausgeführt, wodurch das Betriebssystem vor fehlerhaftem Applikationscode geschützt wird. Aber alle Komponenten des OS selbst – Kernel, Netzwerkstack, Dateisysteme, Treiber – laufen zusammen in einem einzigen Speicheradressraum. Wenn dort ein Fehler auftritt, könnte das gesamte System abstürzen. Dies ist die Achillesferse monolithischer Betriebssystemarchitekturen.
In einem Microkernel-RTOS befinden sich Anwendungen, Gerätetreiber, Dateisysteme und Netzwerkstack außerhalb des Kernels in separaten Adressräumen und sind daher sowohl vom Kernel als auch voneinander isoliert. Dieser Ansatz bietet eine höhere Systemstabilität. Ein Fehler in einer Komponente führt nicht zum Ausfall des gesamten Systems (Abb. 1).
Die Architektur ist natürlich nur eines von vielen Merkmalen, die bei der Auswahl eines RTOS bewertet werden müssen. Ein RTOS muss in erster Linie Echtzeitanforderungen erfüllen. Dies bedeutet, dass Aktivitäten der Anwendung innerhalb eines bestimmten Zeitfensters und auf deterministische Weise ausgeführt werden müssen.
Die Gewährleistung von ausreichend CPU-Zeit ist ebenfalls von entscheidender Bedeutung. Ein Lösungsansatz hierfür ist die Zeitpartitionierung. Beim Fixed-Partitioning kann keine Aufgabe in einer bestimmten Partition mehr als den statisch definierten Prozentsatz der CPU-Zeit dieser Partition verbrauchen.
Bei Adaptiver Partitionierung kann der Systemdesigner CPU-Zyklen für einen Prozess oder eine Gruppe von Prozessen reservieren. Im Gegensatz zur festen Partitionierung werden bei der adaptiven Partitionierung CPU-Zyklen von Partitionen, die gerade untätig sind, dynamisch Partitionen zugewiesen, die von der zusätzlichen CPU-Zeit profitieren können.
Eine Microkernel-RTOS-Architektur bietet außerdem hervorragende Schutzmaßnahmen gegen Programmfehler, die durch das Systemkaskadieren. Ein High-Availability-Manager kann das System überwachen und bei Ausfall einer Software-Komponente mehrstufige Wiederherstellungsaktionen durchführen, d.h.:
- abgestürzte Prozesse neu starten, ohne das ganze System neu zu starten.
- die Kommunikation zwischen Prozessen wiederherstellen.
- spezifische Fehlerbehebungsaktionen durchführen.
Hypervisor
Ein Hypervisor kann Funktionen mit gemischter Kritikalität isolieren und partitionieren. Beispielsweise können sicherheitskritische Steuerfunktionen von nicht-sicherheitskritischer Funktionalität, wie einer grafischen Oberfläche, die unter einem Gastbetriebssystem läuft, isoliert werden. Durch diese Trennung werden auch Sicherheitszertifizierungen erleichtert, da sie nun selektiver durchgeführt werden können.
Cybersecurity
Über die Zertifizierung für medizinische Softwarefunktionen nach IEC 62304 hinaus müssen Hersteller medizinischer Geräte zunehmend Cybersicherheitsstandards für vernetzte Geräte einhalten. Medizinische Geräte müssen vor Cyberbedrohungen geschützt werden und Anbieter von Betriebssystemen müssen Entwicklern Lösungen zur Minderung der Cybersicherheitsrisiken in ihren Produkten bereitstellen (Abb. 2).
- Secure boot – Stellt sicher, dass ein Gerät nur den vorgesehenen Code und die Anwendungen startet.
- Trusted disk und file-based encryption – Schützt Daten auf der Festplatte und verhindert das Extrahieren von Daten.
- Security policies und discretionary access control – Verweigert Prozessen den unbefugten Zugriff auf Systemressourcen und Peripheriegeräte.
- Pathtrust – Verhindert, dass ein Angreifer eigenen Code auf dem System ausführen kann.
- Process manager abilities – Schränkt die Berechtigungen für Prozesse so ein, dass sie mit den geringsten erforderlichen Berechtigungen ihre Aufgaben ausführen können.
Ein weiterer Aspekt, der nicht übersehen werden darf, ist die Möglichkeit, Geräte vor Ort oder drahtlos zu patchen. Die Aufsichtsbehörden arbeiten zunehmend mit Medizinprodukteherstellern zusammen, um diese Themen anzugehen.
Compliance
Die Bereitstellung von Komponenten wie dem RTOS-Kernel, die bereits eine Sicherheitszertifizierung erhalten haben, wie z. B. der IEC 62304 Klasse C, sollte alle relevante Dokumente, einschließlich der Dokumentation der Entwicklungs- und Verifizierungsprozesse, enthalten.
Die Verwendung guter Entwicklungstools kann entscheidend dazu beitragen, im System konkrete Beweise für Funktionalität und Verhalten aufzuzeigen. Analysetools bieten beispielsweise Code Coverage, System Profiling und Memory Analysis. Reports aus diesen Tools können als Beweismittel bei der Erstellung von Compliance-Unterlagen dienen.
Zusammenfassung
Medizinprodukte müssen strenge Anforderungen wie Zuverlässigkeit und strengste Compliance-Standards erfüllen, um zertifiziert zu werden. Geräte, die nicht ausfallen und neu starten dürfen, erfordern ein Microkernel-RTOS mit praktikablen Strategien für funktionale Sicherheit, Ressourcenzuweisung, Konnektivität, Datenintegrität und Cybersicherheit. Ein RTOS-Lieferant mit einer Erfolgsbilanz erfolgreicher Produktsicherheitszertifizierungen trägt dazu bei, die Kosten für die Erlangung von FDA-, MDD- und anderen Zertifizierungen zu senken.
Dieser Artikel erschien in der Ausgabe 5/20 der MED engineering -mba
Autor:
Field Application Manager
QNX Software Systems
