Embedded-Betriebssysteme
Ein OS für die Gesundheit
Fortsetzung des Artikels von Teil 1
Betriebssystemarchitektur
Ein Echtzeit-OS ist also in vielen Embedded Systemen sinnvoll - vielleicht mit Ausnahme von den manchmal schon Wegwerfprodukten ähnlichen Geräten aus dem Bereich der Unterhaltungselektronik. Doch gibt es auch bei Echtzeitbetriebssystemen große Unterschiede, weshalb es sich lohnt, genauer hinzuschauen. Primär ist auf die Architektur des Betriebssystems zu achten, denn diese hat eine direkte Auswirkung auf die Verlässlichkeit und die Fähigkeit, unentdeckte Programmierfehler zu kompensieren. Man unterscheidet drei Architekturen: Realtime Executive, Monolith und Microkernel.
Das Modell der »Realtime Executive« (Bild 3) ist inzwischen gute 50 Jahre alt, trotzdem ist es noch die Basis einiger Echtzeitbetriebssysteme. Hierbei laufen alle Softwarekomponenten - OS-Kern, Netzwerk, Dateisystem, Treiber und Applikationen - gemeinsam in einem großen Speicherbereich. Dies ist zwar in manchen Szenarien effizient, hat jedoch zwei gravierende Nachteile: Zum einen kann ein einziger Programmierfehler irgendwo in der gesamten Software - egal ob kleiner Flüchtigkeitsfehler oder gravierender Logikfehler - den Betriebssystemkern oder irgendeine andere Komponente durcheinanderbringen. Und zwar immer dann, wenn versehentlich Speicher anderer Softwaremodule überschrieben wird.
Jobangebote+ passend zum Thema
Die Folge: Unvorhersehbares, falsches Systemverhalten bis zum Komplettabsturz. Der zweite Nachteil: Die Ursache solcher Abstürze ist oft nur mit sehr großem Aufwand zu finden. Ein OS auf Basis dieser Architektur in einem Medizintechnikgerät zu verwenden ist also nur dann ohne Risiko, wenn es keinem wirklich wichtigen Zweck dient.
Doch selbst ein automatischer Medikamenten-Dispenser für zu Hause darf nicht abstürzen, denn abgesehen davon, dass dies den Benutzer verwirrt und die Akzeptanz verringert, kann ein Absturz auch Datenverlust bedeuten und das Gerät gibt eventuell eine Dosis zu viel oder zu wenig aus, was für den Patienten fatal sein kann. Bei vielen Betriebssystemen bilden die OS-Komponenten einen monolithischen Block (Bild 4), der im privilegierten Modus des Prozessors ausgeführt wird, während Applikationen in eigenen Speicherbereichen laufen.
Das Risiko, dass einzelne Applikationen das Gesamtsystem aus dem Tritt bringen können, wird somit verringert. Da die Betriebssystemkomponenten wie Kernel, Dateisystem, Netzwerkprotokolle und Treiber jedoch nach wie vor in einem gemeinsamen Speicherbereich laufen, kann ein einziger kleiner Programmierfehler in irgendeiner dieser Komponenten dazu führen, dass das gesamte System abstürzt.
Viele bekannte Betriebssysteme folgen dieser Architektur, weshalb es trotz hohen Aufwands bis heute nicht gelungen ist, sie vollständig stabil zu bekommen. Das ist auch der Grund, warum die hohen Anforderungen des Medizintechniksektors mit solchen Betriebssystemen meist nur mit viel Aufwand zu erfüllen sind. Maximale Sicherheit gewährleistet ein Microkernel-Ansatz (Bild 5).
Hierbei laufen alle Softwaremodule - Anwendungen, Systemdienste, Treiber - jeweils in einem eigenen, gekapselten Speicherbereich. Der OS-Kern selbst (Microkernel) übernimmt nur absolut zentrale Funktionen wie Prozess-management, Synchronisation, Interruptzuweisung, etc. Die Menge an Code, der vertraut werden muss, ist also sehr gering. Damit ist sichergestellt, dass Programmierfehler in eigenen oder zugekauften Softwarekomponenten zu keiner Zeit andere Prozesse oder den Betriebssystemkern beschädigen können.
Der Microkernel bleibt so stets intakt. So kann beispielsweise eine ausgefallene Komponente neu gestartet werden, während bei einem OS auf Basis der Realtime-Executive oder der monolithischen Architektur das System gegebenenfalls komplett zurückzusetzen und neu hochzufahren ist. Das kann Sekunden oder Minuten dauern, während ein Microkernel-basiertes System innerhalb von Millisekunden wieder in einen definierten Zustand versetzt werden kann. So lassen sich auch höchste Anforderungen an Verfügbarkeit erfüllen.
Andere Kriterien
Die Softwarearchitektur des Betriebssystems ist natürlich nur ein Aspekt, auf den es zu achten gilt, wenn man vor der OS-Auswahl steht. Weitere wichtige Features sind:
- Präemptierbarkeit (Unterbrechbarkeit) des Betriebssystemkerns, damit auch aggressive zeitliche Anforderungen erfüllt werden können,
- Mechanismen zur Vermeidung von Prioritätsumkehr, die ansonsten leicht zu falschem Systemverhalten oder Ausfall führen kann, sowie
- Vergabe von CPU-Zeitbudgets für kritische Prozesse, damit die Hauptfunktionen des Systems jederzeit die erforderliche CPU-Zeit zur Verfügung haben.
Ein präemptiver Betriebssystemkern ist immer dann wichtig, wenn zeitliche Anforderungen strikt einzuhalten sind. Drückt beispielsweise ein Patient mit letzter Kraft den Notrufknopf, muss dieser den Alarm auslösen. Der Alarm muss gegebenenfalls über ein Netzwerk weitergeleitet werden - alle beteiligten Prozesse müssen also entsprechend reagieren.
Wenn der Druck auf den Notrufknopf vom System gerade nicht erkannt wird, weil es in diesem Moment beispielsweise aus einer Datenbank die Information abruft, wann der Patient ans Mittagessen zu erinnern ist, hilft dies dem Patienten wenig, wenn er gerade mit eventuell gebrochener Hüfte am Boden liegt. In den meisten generischen Betriebssystemen ist der OS-Kern nicht unterbrechbar. Das heißt, selbst ein Prozess mit hoher Priorität kann keinen Betriebssystem-Funktionsaufruf unterbrechen, sondern muss warten, bis dieser Aufruf fertig ist - selbst wenn er vom unwichtigsten Prozess im ganzen System kam. Hinzu kommt noch, dass viele Systemfunktionen an sich gar keine Priorität im eigentlichen Sinne kennen.
Wenn also eine hochpriore Applikation Funktionen aus einem Treiber nutzt, geht im Augenblick des Treiberaufrufs die Prioritätsinformation verloren. Deshalb kann es oft zu Reaktionsverzögerungen kommen - bei einem Desktop-PC nur ärgerlich, bei einem Medizintechniksystem eventuell fatal. Auch deshalb sind also Echtzeitbetriebssysteme (Achtung: nicht angepasste Desktop- oder Server-Systeme) vorzuziehen, denn in einem Echtzeitbetriebssystem sind auch Kernfunktionen unterbrechbar.
Technisch lässt es sich nicht vermeiden, dass es Zeitfenster gibt, in denen keine Unterbrechung möglich ist. In einem guten Echtzeit-OS sind diese Zeitfenster jedoch extrem klein - meist nur einige Hundert Nanosekunden. Aus Betriebssystemsicht ist es natürlich nicht einfach, den hohen Anforderungen an vorhersagbares Zeitverhalten gerecht zu werden.
Am besten gelingt dies mit einem Konzept, bei dem der OS-Kernel nur Funktionen zur Verfügung stellt, die schnell auszuführen sind. Das wiederum erreicht man am besten, indem man zeitintensive und komplexe Vorgänge außerhalb des Kernels erledigt, bis hin zum Laden und Starten von Prozessen. Genau dieses Konzept verfolgt ein Microkernel, womit das Thema Architektur also auch hier eine wichtige Rolle spielt.
Ein echtzeitfähiges Microkernel-OS bietet also deutlich mehr Schutz als andere Ansätze, aber das allein bewahrt noch nicht vor jedem erdenklichen Fehler. Eins der bekanntesten Probleme ist die Prioritätsumkehr, auch Prioritätsinversion genannt. Sie erlangte zweifelhafte Berühmtheit, als sie im Jahre 1997 zu großen Schwierigkeiten beim Mars-Pathfinder-Projekt führte. Prioritätsumkehr bedeutet, dass ein Prozess mit niedriger Priorität einen mit hoher Priorität daran hindert, seine Aufgabe zu erledigen.
Ein Beispiel (Bild 6): Ein Prozess mit hoher Priorität (die Alarmsteuerung) hat Daten an einen Prozess mit niedriger Priorität gesendet (die Patientendaten-Archivierung) und wartet jetzt auf die Rückmeldung, dass diese ordnungsgemäß geschrieben wurden.
Ein dritter Prozess (die Patientendaten-Verarbeitung) hat eine niedrigere Priorität als die Alarmsteuerung, aber eine höhere als die Datenarchivierung. Wenn die Patientendaten-Verarbeitung aktiv wird, unterbricht sie damit erwartungsgemäß die Archivierung. Doch indirekt wird auch die Alarmsteuerung unterbrochen, obwohl sie doch die höchste Priorität hat.
Da der Datenarchivierer sich nicht rechtzeitig zurückmelden kann, kann der Alarmsteuerungsprozess die zeitlichen Anforderungen nicht mehr erfüllen. Prioritätsvererbung verhindert Prioritätsumkehr, indem die Priorität eines wartenden höher priorisierten Prozesses (»Auftraggeber«) an den entsprechenden niedriger priorisierten Prozess (»Auftragnehmer«) vererbt wird. Und zwar exakt so lange, bis dieser die Aufgabe erledigt oder die Ressource freigegeben hat, auf die der hochpriore Prozess gewartet hat.
In unserem Beispiel würde also der Datenarchivierer die Priorität der Alarmsteuerung kurzfristig erben. Dadurch könnte er, so lange er quasi für den Alarmsteuerungsprozess arbeitet, nicht vom Datenverarbeitungsprozess unterbrochen werden. Er würde seine Rückmeldung an die Alarmsteuerung geben können und dann auf seine ursprüngliche Priorität zurückfallen. Die Alarmsteuerung kann dann weiterarbeiten, ohne vom Datenverarbeitungsprozess gestört zu werden (Bild 7).
Ohne solche Mechanismen kann es im schlimmsten Fall passieren, dass der Datenarchivierer »für immer« unterbrochen wird - beispielsweise bei einem Fehler im Datenverabeitungsprozess, der zu einer Endlosschleife führt.
Damit wäre die Alarmfunktion des Systems ausgehebelt - ein kritisches Systemversagen. Prioritätsvererbung trägt daher viel bei, wenn zeitlich aggressive Anforderungen zu erfüllen und eine hohe Verlässlichkeit zu gewährleisten sind. Steht also die Auswahl eines OS für ein Medizintechniksystem an, ist es wichtig, dessen Mechanismen zur Vermeidung von Prioritätsinversionen zu verstehen.
Verfügbarkeit von Funktionen
Oft ist es auch wichtig, die Verfügbarkeit bestimmter Funktionen garantieren zu können. Wenn eine wichtige Softwarekomponente nicht genügend CPU-Zeit mehr bekommt, ist sie für andere Komponenten nicht mehr verfügbar, die dann wiederum für den Benutzer nicht mehr zur Verfügung stehen - mit den entsprechenden Konsequenzen.
Beispiel: Ein Herzmonitor hat über ein Netzwerk eine Verbindung zu einem zentralen Patientenüberwachungssystem. Bricht hier gelegentlich die Verbindung ab, könnte das Zentralsystem fälschlicherweise annehmen, dass ein Alarm ausgelöst werden muss - oder umgekehrt: Der Patient benötigt tatsächlich Hilfe, aber niemand weiß es, da der Alarm nicht ausgelöst wurde. Dass Prozesse nicht ausreichend CPU-Zeit bekommen, kann viele Gründe haben.
Von einer »Denial-of-Service-Attacke« (absichtlich oder durch einen Programmfehler irgendwo im Netzwerk zufällig verursacht) bis hin zu einem Software-Update, mit dem eigentlich nur neue Funktionen hinzukommen sollten. Denn so wie auf einer Autobahn ein einziges Auto zu viel einen Stau verursachen kann, so kann ein einziges neues Feature in einem Softwaresystem dazu führen, dass bestimmte Applikationen nicht mehr ausreichend CPU-Zeit bekommen und deshalb nicht mehr wie erwartet reagieren oder arbeiten.
Traditionell gab es für solche Probleme nur zwei ziemlich unbequeme Lösungen: Hardware aufrüsten (teuer und eventuell schwierig, vor allem bei Systemen, die schon ausgeliefert sind) oder programmtechnische Anpassungen in den neuen oder den bestehenden Programmteilen (eventuell sehr aufwändig, auch bezüglich der Zertifizierung). Deshalb sollte ein Betriebssystem für Medizintechnikprojekte die Möglichkeit bieten, bestimmte CPU-Zeitbudgets für kritische Applikationen festzulegen.
- Ein OS für die Gesundheit
- Betriebssystemarchitektur
- Partitionierte Zeit
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
