Wie findet man das richtige Betriebssystem für neue Medizintechnik-Produkte?
Justin Moon, Product Manager Medical Malte Mundt, Field Application Engineer QNX Software Systems
jmoon@qnx.com, mmundt@qnx.com
Inhalt
Die Medizintechnik, insbesondere der Bereich Remote- Care, wird derzeit von drei Trends dominiert: Alternde Bevölkerung, starker Kostendruck im Gesundheitswesen, sowie mehr Fokus auf Präventivmedizin. Studien aus den USA zeigen, dass sich die Umsätze mit Remote-Care- Systemen im laufenden Jahr verdoppeln – auf über 1,3 Milliarden US-Dollar.
In diesem Whitepaper geht es deshalb um die Auswahl eines Embedded-OS für Remote-Care-Systeme und andere medizinische Geräte, bei denen Zuverlässigkeit, Robustheit und funktionale Sicherheit eine große Rolle spielen. Es werden die wichtigsten Kriterien aufgezeigt, anhand derer Medizintechnik-Hersteller potentiell einzusetzende Betriebssysteme qualifiziert beurteilen können.
Wachsende Herausforderung
Es ist bekannt, dass die Bevölkerung der
Industrienationen zusehends altert: Im Jahr 2020 werden z.B. in Frankreich 27% der Einwohner über 60 Jahre alt sein. Ähnliches gilt für Deutschland sowie die USA, in Japan werden es sogar 34% sein1. Diese Menschen fordern selbstverständlich nach wie vor die bestmögliche medizinische Betreuung, doch die Kosten steigen immer weiter und niemand weiß, wie lange die existierenden Finanzierungssysteme diese Lasten tragen können.
Deshalb denken die entsprechenden Gesetzgeber immer häufiger über Änderungen im Gesundheitsweisen nach.
Remote-Care statt Arztpraxis
Regierungen und internationale Gremien wie die World Health Organization (WHO) haben festgestellt, dass im Gesundheitswesen überproportional viel von
1 Gerundete Bevölkerungsdaten von der United Nations Population Division, World Population Prospects: The 2008 Revision Population Database, 2008.
Bild 1: Ein netzwerkgestütztes Remote-Care Patienten-Überwachungssystem
Krankenhäusern und Spezialisten abhängt. Dies kostet nicht nur viel Geld, sondern behindert in manchen Fällen auch Verbesserungen des Gesundheitswesens2. Es ist jedoch schon eine Bewegung weg vom herkömmlichen Krankenhaus-basierten Modell festzustellen.
Beispielsweise wurde im kanadischen Bundesstaat Ontario im Jahr 2004 ein “Family Health Team”
Programm eingeführt, um gesundheitliche Betreuung sicher zu stellen und gleichzeitig das Gesundheitssystem finanziell zu entlasten. Ähnlich war die Motivation beim Ontario Telemedicine Network (OTN), das aber gleichzeitig noch die Gesundheitsversorgung in abgelegeneren Gegenden verbesserte3.
Solche Initiativen mit Fokus auf eine weniger von Krankenhäusern/Arztpraxen abhängige medizinische Grundversorgung sind natürlich erst möglich durch innovatives Denken und die Nutzung moderner Technologien wie z.B. digitale Bildverarbeitung, Videokommunikation, drahtlose Übertragung usw. So entstehen oft neue, robuste, portable und verhältnismäßig kostengünstige medizinische Geräte, die außerhalb einer Praxis benutzt werden können, oft sogar durch den Patienten selbst4. Blutzuckermessgeräte oder z.B.
Systeme, die ältere Menschen daran erinnern, regelmäßig und in richtiger Dosierung ihre Medikamente
einzunehmen, erfreuen sich zunehmender Beliebtheit.
Diabetiker können so ihren Blutzuckerspiegel selbst messen, anstatt eine Ambulanz aufzusuchen, und ältere Menschen können weiter zu Hause wohnen, anstatt in ein Pflegeheim wechseln zu müssen. In beiden Fällen steigt also die Lebensqualität, gleichzeitig sinken die Kosten zur Erhaltung der Gesundheit.
Kein Wunder also, dass die Nachfrage nach solchen Remote-Care Geräten steigt. In der Bloomberg
Businessweek schrieb Olga Kharif im Jahr 2010, dass in den USA der Umsatz mit drahtlosen Medizintechnik-
2 World Health Organization, The world health report 2008:
primary healthcare now more than ever. Genf, 2008, S. 11f.
3 Ontario Telemedicine Network: www.otn.ca.
4 Beispielsweise wurde Low Cheng Ooi, Vorsitzender des Changi General Hospital in Singapur in einem Artikel zum Thema “Wie wird die technische Entwicklung die Zukunft der
Gesundheitsversorgung beeinflussen?” (FutureGov vom 1.9.
2010) folgendermaßen zitiert: “Mehr und mehr Haushalte verfügen über Breitband-Netzanbindung, gleichzeitig entwickeln sich portable Medizintechnik-Geräte immer weiter – mit innovativer Technik können viele Aspekte der
Gesundheitsversorgung in den Haushalt verlegt werden.”
Geräten für Endbenutzer 600 Millionen US-Dollar betrug - für 2011 wurden $1,3 Milliarden prognostiziert5. Kharif nennt dann einige der Großkonzerne, die deshalb ihr Engagement in diesem Bereich stark ausbauen wollen, z.B. Qualcomm, AT&T, Microsoft und General Electric.
Das Betriebssystem ist fundamental
Um Marktanteile zu gewinnen und auch zu halten, müssen sich die Medizintechnik-Hersteller heute den Anforderungen mehrerer Interessengruppen stellen: Da sind die Nutzer (Patienten und Ärzte), die Finanzierer (gesetzliche und private Krankenkassen,
Regierungsvertreter) sowie natürlich prüfende und zertifizierende Instanzen (Stichwort Medizinprodukte- Richtlinie/MDD, in den USA die FDA usw.). Gezeigt und bewiesen werden muss nicht nur, dass die entwickelten Systeme praktikabel sind und eine wirtschaftlich sinnvolle Alternative darstellen, sondern auch, dass sie besser, vielleicht auch noch kostengünstiger sind als Geräte der Mitbewerber und selbstverständlich auch, dass die Systeme sicher sind.
Bild 2: Nach Branchen sortiert: Bei wie viel Prozent der Projekte wird das Betriebssystem zuerst festgelegt?
(nach Balacco u.a.).
Ein wichtiger Teil vieler elektronischer Medizingeräte ist das Betriebssystem (OS), denn alles, was keine Hardware ist, hängt vom OS ab: Wenn das OS versagt, kann das ganze Gerät ausfallen. Und so ein Medizintechnik-System ist kein Desktop-PC: Selbst bei Geräten, die lediglich die Anforderungen der FDA Klasse I oder II erfüllen müssen, sind zufällige Programm-Abstürze oder Neustarts inakzeptabel. Wird am Bürocomputer oder zu Hause ein
5 Olga Kharif: “Qualcomm, AT&T Move in on 'M-Health'”, Bloomberg Businessweek, 23.8.2010.
Absturz oft noch kopfschüttelnd hingenommen, ist bei Medizintechnik die Toleranz gleich Null, wenn es um die Gesundheit des Patienten – oder die eigene – geht.
In der Medizintechnik wird deshalb immer deutlicher wahrgenommen, wie viel vom Betriebssystem abhängt.
Bei Embedded-Systemen wird branchenübergreifend nämlich noch oft die Hardwareplattform zuerst festgelegt, erst dann das OS. Neben Smartphone-Herstellern hat aber vor allem die Medizintechnikbranche inzwischen das entsprechende Gespür für die Relevanz des OS entwickelt:
Laut einer Untersuchung von VDC Research6 wird bereits in 36% der Projekte inzwischen zuerst das Betriebssystem ausgewählt und erst dann die Hardware.
Überblick OS-Auswahlkriterien
Ein Betriebssystem muss auf drei Ebenen betrachtet werden: Unternehmerische Anforderungen,
Voraussetzungen für die Konformität mit bestimmten Normen und Richtlinien, sowie technische Aspekte.
Unternehmerische Anforderungen
Es gelten prinzipiell die unternehmerischen Anforderungen, die jeder Hersteller von Embedded- Systemen in unterschiedlichem Maße hat: Kosten, Qualität der Software, eventuelle Zeitersparnis, Portabilität, verfügbarer Support, Historie/Seriosität des Herstellers, Anbieter von Komplementärprodukten/- dienstleistungen, Kundenreferenzen sowie langfristige Perspektive.
Konformität und Zulassung
Je nach Land muss der Hersteller nachweisen, dass sein Produkt bestimmten Richtlinien und Vorschriften entspricht. Für die Zulassung spielt in den USA zum Beispiel FDA 510(k) eine wichtige Rolle, in Europa die Medizinprodukte-Richtlinie (Medical Device Directive, MDD), sowie diverse nationale Standards. Darüber hinaus regeln Bestimmungen wie z.B. der U.S. Health Insurance Portability and Accountability Act (HIPAA) die Sicherheit und Vertraulichkeit medizinischer Daten.
Da diese Konformitätsanforderungen den Kosten- und Zeitaufwand erhöhen, ist es von großem Vorteil, ein Betriebssystem einzusetzen, das bereits in vielen Geräten genutzt wird, die schon durch die FDA oder ähnliche
6 Steve Balacco u.a.: 2010 Survey Year, Track 2: Embedded System Engineering Survey Data, Vol. 3: Vertical Markets. VDC Research, 2010, S. 19-20.
Institutionen abgenommenen wurden. Auch wenn die Benutzung eines solchen OS nicht gleich garantiert, dass man schnell und einfach durch den Zertifizierungsprozess kommt, so hilft es doch sehr, Unsicherheitsfaktoren zu eliminieren - womit deutlich mehr Zeit bleibt, sich auf gerätespezifische Aspekte zu konzentrieren.
Technische Voraussetzungen
Die technischen Anforderungen an ein Betriebssystem für die Medizintechnik lassen sich unter folgenden drei Gesichtspunkten zusammenfassen:
Verlässlichkeit - arbeitet durchgehend korrekt und reagiert wie erwartet im geforderten Zeitrahmen Konnektivität - kann mit diversen Komponenten und
Systemen direkt oder über Netzwerke kommunizieren Datenintegrität und Sicherheit - Daten werden sicher
gespeichert und vor unautorisiertem Zugriff geschützt Plattform-Unabhängigkeit
Zusätzlich ist interessant, auf welchen Prozessortypen ein OS eingesetzt werden kann, denn dies erlaubt ggf. die Entwicklung von modularen Systemen, dessen Software- Komponenten sich dann sehr viel einfacher in anderen Produkten oder Produktvarianten wiederverwenden lassen. Beispielsweise könnte es von einem Patienten- Überwachungssystem eine Variante für Arztpraxen geben und eine Version für die Anwendung zu Hause (Bild 1), welche vom Patienten selbst bedient werden kann. In dieser Variante sind ggf. nicht alle Funktionen des Praxensystems verfügbar und es kommt deshalb vielleicht mit einer günstigeren Hardware aus. Durch Einsatz des gleichen Betriebssystems und Wiederverwendung der entwickelten Software-Komponenten lässt sich so in vielen Fällen eine deutliche Kosteneinsparung erzielen.
Verlässlichkeit: Definition
Bei einem Betriebssystem bedeutet Verlässlichkeit zweierlei:
Verfügbarkeit - reagiert das System in angemessenem Zeitrahmen? Wie viele Fälle gibt es, in denen es das nicht tut?
Zuverlässigkeit - reagiert das System richtig? Wie viele Fälle gibt es, in denen es das nicht tut?
Ein verlässliches OS reagiert also, wie es soll und wann es soll, in dem Zeitrahmen, der erforderlich ist. Was heißt das konkret für ein Embedded-OS in einem
Medizintechnikgerät?
Echtzeit-OS oder Universal-OS?
Wenn Verlässlichkeit wie oben definiert tatsächlich essenziell ist, sollte man unbedingt in Erwägung ziehen, ein Echtzeit-Betriebssystem einzusetzen und lieber einen Bogen um universelle, „generische“ Betriebssysteme zu machen.
Generische Betriebssysteme
Das Hauptproblem bei generischen Betriebssystemen ist, dass diese oftmals eine Art “eierlegende Wollmilchsau”
darstellen. Die Funktionalitäten können dabei schnell oder langsam sein, viel oder wenig Ressourcen benötigen, doch was immer sie auch tun – es gibt keine Garantie, dass sie ihre Aufgaben immer wie gewünscht erfüllen. Solche Betriebssysteme sind für viele Aufgaben ausgelegt und erfüllen diese gut, manchmal auch sehr gut, aber es fehlt der hohe Grad an Verfügbarkeit und Zuverlässigkeit, der für viele Medizintechniksysteme eine Grundvoraussetzung ist.
Bild 3: In einem Microkernel-OS laufen auch Betriebssystem-Komponenten im Standard-
Benutzermodus innerhalb geschützter Speicherbereiche.
Durch diese Kapselung wird ein Maximum an Schutz für die einzelnen Prozesse und den OS-Kern erreicht.
Außerdem sind die Hardware-Anforderungen eines Universal-Betriebssystems oft sehr viel höher als die eines echtzeitfähigen Embedded-OS. Das bedeutet unter Umständen, dass Projektanforderungen auch mit günstigerer Hardware erfüllbar sein können. Zusätzlich ist auch die Hitzeentwicklung größerer Prozessoren oft problematisch.
Echtzeitbetriebssysteme
Im Gegensatz zu generischen Betriebssystemen sind Echtzeitbetriebssysteme von vornherein mit Fokus auf Verfügbarkeit und Zuverlässigkeit konzipiert worden. Ein Entwickler, der ein Embedded-System mit einem Echtzeit- OS entwirft, kann sicher sein: Das Betriebssystem erfüllt auch sehr hohe Anforderungen an Verfügbarkeit und führt die ihm aufgetragenen Aufgaben erwartungsgemäß aus, während es ansonsten unauffällig im Hintergrund bleibt.
Damit wird es dann auch deutlich leichter, gesetzliche Vorgaben und Richtlinien zu erfüllen, außerdem kann es dem Hersteller helfen, Kosten einzusparen7.
Betriebssystem-Architektur
Ein Echtzeit-OS ist also in vielen Embedded-Systemen sinnvoll – vielleicht mit Ausnahme von manchen schon Wegwerfprodukten ähnlichen Geräten aus dem Bereich der Unterhaltungselektronik. Doch Achtung: Auch bei Echtzeit-Betriebssystemen gibt es 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.
Die Realtime Executive Architektur
Das Modell der Realtime Executive ist inzwischen gute 50 Jahre alt, trotzdem ist es noch die Basis einiger
Echtzeitbetriebssysteme. Hierbei laufen alle Software- Komponenten – 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 durcheinander bringen. Und zwar immer dann, wenn versehentlich Speicher anderer Software-Module überschrieben wird.
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.
7 Mehr Details finden Sie im Artikel “Exactly When Do You Need an RTOS?” von Paul Leroux, QNX Software Systems, 2009.
Bild 4: In einer Realtime Executive können kleinste Fehler in beliebigen Software-Modulen das gesamte System
kompromittieren.
Ein OS auf Basis dieser Architektur in einem
Medizintechnik-Gerä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.
Monolithische Architektur
Bei vielen Betriebssystemen bilden die OS-Komponenten einen monolithischen Block, 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 reduziert.
Da die Betriebssystem-Komponenten 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 100% stabil zu bekommen.
Das ist auch der Grund, warum die hohen Anforderungen des Medizintechnik-Sektors mit solchen Betriebssystemen meist nur mit viel Aufwand zu erfüllen sind.
Microkernel-Architektur
Maximale Sicherheit wird nur durch einen Microkernel- Ansatz gewährleistet: Hierbei laufen alle Softwaremodule – Anwendungen, Systemdienste, Treiber – jeweils in einem eigenen, gekapselten Speicherbereich. Der OS- Kern selbst (Microkernel) übernimmt nur absolut zentrale Funktionen wie Prozessmanagement, Synchronisation, Interruptzuweisung usw. Die Menge an Code, der vertraut werden muss, ist also sehr gering. Damit ist sichergestellt, dass Programmierfehler in eigenen oder zugekauften Software-Komponenten zu keiner Zeit andere Prozesse oder den Betriebssystemkern beschädigen können. Der Microkernel bleibt durch diesen Schutz 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 ggf. komplett resettet und neu hochgefahren werden muss. 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.
Was ist sonst noch wichtig?
Die Software-Architektur 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, welche ansonsten leicht zu falschem
Systemverhalten oder Ausfall führen kann Bild 5: In einem monolithischen OS ist der OS-Kern zwar
vor fehlerhaftem Applikationscode geschützt, aber Probleme in Treibern, im Netzwerk-Stack oder im
Dateisystem können ihn immer noch zum Absturz bringen.
• Vergabe von CPU-Zeitbudgets für kritische Prozesse, damit die Hauptfunktionalität des Systems jederzeit die erforderliche CPU-Zeit zur Verfügung hat
• Multicore-Unterstützung sowie Migrationsweg für Single-CPU-Software zu Multicore-Systemen
Zeitliche Anforderungen erfüllen
Ein präemptiver Betriebssystem-Kern ist immer dann wichtig, wenn zeitliche Anforderungen strikt eingehalten werden müssen, sprich höhere Ansprüche gestellt werden als an ein Gerät aus der Unterhaltungselektronik. Drückt beispielsweise ein Patient mit letzter Kraft den
Notrufknopf, muss dieser den Alarm auslösen. Der Alarm muss ggf. ü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 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 Treiber- Aufrufs die Prioritätsinformation verloren.
Deshalb kann es oft zu Reaktionsverzögerungen kommen – bei einem Desktop-PC “nur”
ärgerlich, bei einem Medizintechnik-System eventuell fatal.
Auch deshalb sind also Echtzeit-Betriebssysteme (Achtung: nicht “angepasste” Desktop- oder Server-Systeme) vorzuziehen, denn in einem Echtzeit-Betriebssystem 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, in dem 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.
Schutz gegen Prioritätsumkehr
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
Bild 7: Die Patientendaten-Archivierung blockiert die Patienten-Alarmsteuerung, obwohl die Alarmsteuerung eine höhere Priorität hat – eine klassische Prioritätsinversion.
Bild 6: In einem Microkernel-OS sind alle Treiber, Protokoll-Stacks und andere Systemdienste gekapselt, ebenso wie Applikationen. So wird maximale Systemstabilität erreicht.
Prioritätsinversion genannt. Sie erlangte zweifelhafte Berühmtheit, als sie im Jahre 1997 zu großen
Schwierigkeiten mit dem Mars-Pathfinder-Projekt führte8. Prioritätsumkehr bedeutet, dass ein Prozess hoher Priorität durch einen Prozess mit niedriger Priorität daran gehindert wird, seine Aufgabe zu erledigen.
Ein Beispiel: 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 Daten-Archivierung. 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 Daten-Archivierer sich nicht rechtzeitig zurückmelden kann, kann der Alarmsteuerungs-Prozess die zeitlichen Anforderungen nicht mehr erfüllen.
Prioritätsvererbung
Prioritätsvererbung verhindert Prioritätsumkehr, in dem 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 Daten-Archivierer die Priorität der Alarmsteuerung kurzfristig erben. Dadurch könnte er, so lange er quasi für
8 Michael Barr: “Introduction to Priority Inversion”, Embedded Systems Programming, Volume 15: Number 4, April 2002.
den Alarmsteuerungs-Prozess arbeitet, nicht vom Datenverarbeitungs-Prozess 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 Datenverarbeitungs-Prozess gestört zu werden.
Ohne solche Mechanismen kann es im schlimmsten Fall sein, dass der Daten-Archivierer “für immer”
unterbrochen wird – beispielsweise bei einem Fehler im Datenverabeitungs-Prozess, 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 erfüllt und eine hohe Verlässlichkeit gewährleistet werden müssen. Steht also die Auswahl eines OS für ein Medizintechnik-System an, ist es wichtig, dessen Mechanismen zur Vermeidung von Prioritätsinversionen zu verstehen. Es lohnt sich enorm, nachzuvollziehen, wie effektiv diese arbeiten - sowohl für die Produktentwicklung als auch die Zertifizierung, sowie für die Marktlebensdauer des Gerätes.
Verfügbarkeit garantieren
Oft ist es auch wichtig, Verfügbarkeit bestimmter
Funktionalität garantieren zu können. Wenn eine wichtige Software-Komponente nicht genügend CPU-Zeit mehr bekommt, ist sie für andere Komponenten nicht mehr verfügbar, welche 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- Attack” (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 Software- System dazu führen, dass bestimmte Applikationen nicht mehr ausreichend CPU-Zeit bekommen und deshalb nicht mehr wie erwartet reagieren oder arbeiten.
Bild 8: Die Priorität der Patienten-Alarmsteuerung wird an die Patientendaten-Archivierung vererbt. Dadurch wird
verhindert, dass sie von der Patientendaten-Verarbeitung unterbrochen werden kann.
Traditionell gab es für solche Probleme nur zwei ziemlich unbequeme Lösungen: Hardware aufrüsten (teuer und evtl. schwierig, vor allem bei Systemen, die schon ausgeliefert sind), oder programmtechnische
Anpassungen in den neuen – oder den bestehenden – Programmteilen (evtl. sehr aufwändig, auch bezüglich der Zertifizierung).
Deshalb sollte ein Betriebssystem für Medizintechnik- Projekte die Möglichkeit bieten, bestimmte CPU- Zeitbudgets für kritische Applikationen festzulegen.
Zeit-Partitionen
Mittels Zeit-Partitionen kann sichergestellt werden, dass kritische Systemkomponenten immer genug CPU-Zeit zur Verfügung haben. So wird verhindert, dass bestimmte Prozesse zu viel CPU-Zeit “an sich reißen”. Dabei gibt es zwei Varianten: Feste (statische) Partitionierung und adaptive Partitionierung.
Stellt das Betriebssystem Zeit-Partitionen zur Verfügung, kann der Entwickler die Systemfunktionalität in Gruppen – die Partitionen – aufteilen und jeder Partition ein CPU- Zeitbudget (in Prozent) zuweisen. Dann kann kein Prozess mehr CPU-Zeit verbrauchen, als seiner Partition
zugewiesen wurde. Wurden z.B. 30% zugewiesen, müssen sich die Prozesse innerhalb dieser Partition diese 30%
CPU-Zeit teilen und können nicht mehr verbrauchen.
Damit ist sichergestellt, das Prozesse in anderen Partitionen entsprechend verfügbar sind.
Problematisch kann es werden, wenn die Partitionsgrößen fest (statisch) sind. Denn eine Begrenzung von Prozessen auf eine bestimmte Menge CPU-Zeit bedeutet auch, dass CPU-Zeit, die in einer Partition nicht verbraucht wird, auch anderen Partitionen, die vielleicht bereits am Limit sind, nichts nützt. Das heißt: Mit statischen Zeit-Partitionen
sichert man den darin liegenden Prozessen nicht nur bestimmte Mengen CPU-Zeit zu, sondern beschränkt sie auch auf genau diese Menge – bremst sie also selbst dann aus, wenn die CPU eigentlich gar nicht voll ausgelastet ist.
Zeit-Partitionen, die sich anpassen
Die adaptive Partitionierung, ein relativ neues Zeit- Partitionierungsverfahren, ist eine mögliche Lösung. Auch hiermit lassen sich Zeit-Partitionen erstellen, mit denen der Entwickler jedem Systemteil eine bestimmte Menge CPU-Zeit zuordnen kann.
Im Gegensatz zur festen Partitionierung geht es hier allerdings darum, eine Mindestmenge an CPU-Zeit zu garantieren. Das heißt: Die Partition kann über die zugewiesene CPU-Zeit verfügen – und ggf. über mehr, wenn in anderen Partitionen nicht das gesamte zugewiesene Zeitbudget genutzt wurde. Damit kann die CPU voll ausgenutzt werden, das System läuft insgesamt schneller, und trotzdem erhalten alle Software-
Komponenten garantiert die ihr zugewiesene
Mindestmenge an CPU-Zeit. In ihre Schranken werden Prozesse erst dann gewiesen, wenn sie stark mit anderen Prozessen in anderen Partitionen um CPU-Zeit
konkurrieren. Der Partitionierer greift dann ein und stellt sicher, dass die Zeitbudgets eingehalten werden.
Bild 10: Adaptive Zeit-Partitionen garantieren vorgegebene CPU-Zeitbudgets für bestimmte Prozesse und deren Threads, können sich aber dynamisch anpassen.
Bild 9:Statische Zeit-Partitionen stellen sicher, dass Prozesse das zugewiesene CPU-Zeitbudget bekommen, sind aber unflexibel.
System mit Selbstheilungskräften
Ein Microkernel-OS bietet sehr guten Schutz vor Software- Problemen und damit verbundenen Kettenreaktionen. In Geräten, bei denen eine enorm hohe Verfügbarkeit gewährleistet werden muss, kann man sich dies zunutze machen, in dem man (neben eventuellen Hardware- basierten Verfügbarkeitslösungen) einen Software- basierten Hochverfügbarkeits-Manager einsetzt. Dieser kann kritische Systemkomponenten überwachen und mehrstufige Recovery-Aktionen durchführen, wenn er feststellt, dass ein Prozess abgestürzt ist oder nicht mehr reagiert. Ein guter Hochverfügbarkeitsmanager kann:
• ein abgestürztes Programm, egal welcher Art, automatisch neu starten – ohne einen System-Reset zu erzwingen
• dafür sorgen, dass Interprozess-
Kommunikationsverbindungen danach wieder aufgebaut werden
• vom Systementwickler definierte Recovery-Aktionen durchführen, mit denen Applikationen auf bestimmte Fehlerfälle reagieren können, um Konsequenzen abzuwenden und das System schnell wieder in einen definierten Zustand zu bringen
• sich auch selbst überwachen und wiederherstellen, falls er aus irgendeinem Grund ein internes Problem haben sollte
Multicore-Support
Wegen steigender Leistungsanforderungen nimmt die Zahl der Geräte mit Multicore-CPUs zu, trotz der höheren Kosten und der Komplexität, die solche Prozessoren bedeuten. Von Bildverarbeitung bis zu Sprachsteuerung gibt es immer rechenintensivere Aufgaben.
Das bedeutet: Selbst, wenn die aktuelle Generation eines bestimmtes Gerätes heute noch keine Multicore-CPU braucht - bei der nächsten kann das schon ganz anders sein. Deshalb sollte das Betriebssystem Multicore unterstützen. Zusätzlich sollte es möglich sein, Prozesse an bestimmte CPU-Cores zu binden, um die Migration von einer Single-CPU-Umgebung zu vereinfachen. Weiter als die von den meisten unterstützte “Prozessor-Affinität”
geht Bound Multiprocessing (BMP), bei dem festgelegte Core-Zuordnungen auch an neu gestartete Prozesse und Threads vererbt werden. Unter dem Aspekt der
Zertifizierung ist außerdem wichtig, ob existierende Software-Komponenten ohne weiteres in einer Multicore- Umgebung wiederverwendet werden können.
Netzwerkfähigkeiten
In der Medizintechnik, vor allem bei Remote-Care Systemen, sind auch die Netzwerkfähigkeiten des Betriebssystems wichtig. Die Relevanz wird noch deutlich zunehmen, da sich Patienten, Ärzte, Krankenhaus- Betreiber und Versicherer gleichermaßen mehr und mehr der Möglichkeiten der Vernetzung bewusst werden.
Entsprechend ausgestattet könnten Patienten sich frei bewegen – arbeiten, einkaufen oder sogar Urlaub machen – und gleichzeitig medizinisch betreut werden.
Abhängig vom Gerät und der Art der Daten, die versendet und empfangen werden sollen, kann es nötig werden, sich mit Normen wie der IEC 61784 zu beschäftigen,
insbesondere mit der Nutzung von nach 61158
“unzuverlässigen” Medien (z.B. Ethernet) zur zuverlässigen Übertragung von sicherheitskritischen Informationen.
QNX Adaptive Partitioning QNX bietet mit “Adaptive Partitioning” eine Zeit- Partitionierungslösung, die ohne Code- oder Designänderungen auf existierende QNX-Systeme angewandt werden kann.
Der Systemdesigner kann damit Applikationen in Partitionen hineinstarten und der Partitionierer stellt sicher, dass jede Partition das ihr zugewiesene CPU- Zeitbudget bekommt. Innerhalb der Zeit-Partitionen läuft jeder Prozess entsprechend seiner Priorität.
Ferner hat der Systemdesigner die Möglichkeit, je nach Anwendungsszenario auch dynamisch die
Partitionsbudgets anzupassen, um eine optimale Performance zu erreichen.
QNX High Availability Framework
QNX bietet ein Framework für Hochverfügbarkeit (High Availability), mit dem applikationsspezifische Recovery- Szenarien programmiert werden können. Damit ist es möglich, schnell wieder einen definierten Zustand herzustellen, bevor Software-Fehler einen Domino- Effekt im System auslösen können.
Das QNX High Availability Framework besteht aus einer Programmierschnittstelle zum Hochverfügbarkeits- Manager sowie einer Client-Recovery-Library, die für viele “libc”-I/O-Aufrufe spezielle Hochverfügbarkeits- Varianten zur Verfügung stellt.
Das User-Interface
Bei der Entwicklung eines User-Interface gibt es viele Fallstricke und Stolpersteine, worüber an anderer Stelle schon viel geschrieben wurde. Allein ein Thema wie Entwicklung einer Benutzerschnittstelle eines
Blutdruckmessgeräts für Menschen mit leichter kognitiver Beeinträchtigung wäre eher etwas für eine Doktorarbeit.
Hier deshalb lediglich die wichtigsten zwei Punkte – ein Betriebssystem für ein medizintechnisches Gerät sollte:
• diverse Grafiklösungen unterstützen und ggf.
kombinieren, damit die Anforderungen an das Gerät umgesetzt werden können – von OpenGL ES bis zu Adobe Flash
• von der System-Architektur her ermöglichen, dass viele Komponenten unabhängig vom User-Interface implementiert und in mehreren Projekten
wiederverwendet werden können
Datenintegrität und -sicherheit
Patientendaten sind vertraulich. Egal ob Europa oder Amerika, Regierungen haben ein Auge auf dieses Thema und bei Datenlecks ist mit Klagen oder Strafzahlungen zu rechnen. Darüber hinaus muss sichergestellt werden, dass die Daten korrekt und bei Bedarf auch verfügbar sind.
Datenintegrität und –sicherheit bedeuten also:
• dass Daten nicht beschädigt oder gelöscht werden bzw. verloren gehen
• dass nur berechtige Personen und Systeme Zugriff auf die Daten haben - Standardeinstellung sollte sein, den Zugriff zu verweigern, Zugriffsrechte wie
Lesen/Schreiben müssen explizit vergeben werden Das Betriebssystem kann zum Thema Datenintegrität und Datensicherheit viel beitragen – wichtig sind die Kernel- Architektur, das Dateisystem, Verschlüsselung und Autorisierungsmechanismen.
Kernel-Architektur
Das oben besprochene Thema Betriebssystem-
Architektur spielt auch bei der Datensicherheit eine große Rolle, denn wenn der Kernel kompromittiert wird, ist das ganze System verwundbar. Je verlässlicher also der Kernel, desto besser für die Daten. Auch hier spricht viel für eine Microkernel-Architektur, wie auch Eugen Bacic von Bell Security Solutions in einer Untersuchung von 2006 feststellte9. Da alle Systemkomponenten in voneinander isolierten, gekapselten Speicherbereichen mit geringstmöglichen Privilegien laufen, gibt es viel weniger Software-Teile, die überhaupt sicherheitsrelevant sind. Ein solches System lässt sich deshalb wesentlich besser absichern und prüfen.
Dateisysteme
Bei Dateisystemen wird in der Regel nach Medien (z.B.
NAND, NOR, RAM) und/oder Typ (POSIX, EXT2, FAT, ETFS) unterschieden. Doch es ist auch wichtig, sich zu fragen: Wie nutzt das medizinische Gerät, um das es geht, eigentlich das Dateisystem? Mit diesem Wissen kann man sich die Charakteristika von Dateisystemen eines OS dann näher anschauen:
Performance - je nach Medium kann es wichtig sein, ob das Dateisystem Unterstützung für Defragmentierung
9 Eugen Bacic: “Security as a Core Competency of the QNX Neutrino Microkernel”, Cinnabar Networks (Bell Security Solutions) und QNX Software Systems, 2006.
QNX Safe Kernel
Der QNX Neutrino RTOS Safe Kernel wurde durch Sira nach IEC 61508 Safety Integrity Level 3 (SIL 3) zertifiziert.
Alle Voraussetzungen für einen Safe Kernel nach IEC 61508 werden erfüllt:
• Design Safe State - es existiert ein klar definierter Zustand, in den der Kernel im Falle einer unerwarteten Fehlersituation zurückfallen kann
• Isolation - Prozesse sind voneinander, aber auch vom Kernel, isoliert
• Vorhersagbares Zeitverhalten - Prioritätsvergabe auf Thread-Ebene, Lazy Allocations deaktivierbar, Scheduling-Verhalten mit Techniken wie Deadline oder Rate Monotonic analysierbar
QNX Secure Kernel
Der QNX Neutrino RTOS Secure Kernel ist nach den strengen Anforderungen der Common Criteria ISO/IEC 15408 Evaluation Assurance auf Level (EAL) 4+
zertifiziert.
Durch die Zertifizierung abgedeckt ist der QNX Neutrino Kernel inklusive Multicore-Unterstützung
(symmetrisches Multiprocessing und Bound Multiprocessing) sowie die Zeit-Partitionierung.
bietet, oder ob fehlerhafte Blöcke erkannt und als nicht nutzbar markiert werden, wenn dies nicht in Hardware geschieht.
Konsistenzwahrung - was tut das Dateisystem, um beispielsweise nach einem plötzlichen Stromausfall noch eine konsistente Sicht auf die Daten zu gewährleisten?
Abhängigkeit - inwiefern ist das Gesamtprodukt später vom Dateisystem abhängig? Gibt es Möglichkeiten, bis zu einem gewissen Grad unabhängig vom Dateisystem zu arbeiten?
Zugriffsmechanismen - je nach Medium kann es erforderlich sein, mit einer speziellen Programmierschnittstelle auf das Filesystem zuzugreifen. Um Medium oder Dateisystem
austauschbar zu halten, ist ein Zugriff über Standard- POSIX- bzw. C-Aufrufe vorteilhaft (z.B. open(), read(), write(), close() usw.).
Verschlüsselung und Autorisierung
Es gibt leider viele Möglichkeiten, Applikationen aufzubauen, die in irgendeiner Form ein sicherheitstechnisches Problem darstellen. Ein Betriebssystem kann Applikationsentwicklern und Systemdesignern nicht die Verantwortung dafür
abnehmen, aber es sollte gerade deshalb selbst so sicher wie irgend möglich sein. Das wichtigste sind die
Zugangsmöglichkeiten zum System – standardmäßig sollte so wenig wie möglich erlaubt sein, die Zugangswege müssen bekannt sein und nur bei Notwendigkeit
überhaupt erst Bestandteil des Gesamtprodukts werden.
Hinzu kommt die Unterstützung von
Verschlüsselungsprotokollen und –mechanismen, wie z.B.
IPSec (Internet Protocol Security), WPA/WPA2 (WiFi Protected Access), IEEE 802.1X und RADIUS (Remote Authentication Dial In User Service), sowie lokale Datenverschlüsselung, beispielsweise mittels DES (Data Encryption Standard).
Konformität
Ein Medizintechniksystem muss den Vorgaben und Richtlinien der Gesetzgeber bzw. Behörden der Länder entsprechen, in denen es verkauft werden soll. Die entsprechenden Nachweise sind zu erbringen – vorher kann das in die Entwicklung investierte Geld für den Hersteller nicht zu gewinnbringendem Umsatz werden.
Doch wie jedes Unternehmen konkurriert auch eine
Medizintechnik-Firma mit anderen, die ähnliche Produkte entwickeln und eventuell eher am Markt sind. Zwar gibt es nicht die klassischen, in der Öffentlichkeit eher
wahrgenommenen Kalender-abhängigen Zeitrahmen (z.B.
Weihnachtsgeschäft), trotzdem spielt der Zeitfaktor oft eine wichtige Rolle. Denn je länger es dauert, ein Gerät zu entwickeln, desto mehr kostet die Entwicklung schließlich, und desto mehr Zeit hat ein Wettbewerber eventuell, um sich Marktanteile zu sichern. Vor allem bei Neueinführung bestimmter Technologien etabliert sich derjenige, der als erstes am Markt war, oft zum Standard.
Deshalb ist es wichtig, auch und gerade beim Aspekt der Zertifizierung zu überlegen, wie Zeit und damit Geld gespart werden kann. Beim Betriebssystem gibt es hierbei die Möglichkeit, einen OS-Kernel einzusetzen, der bereits eine sicherheitsrelevante Zertifizierung erhalten hat, z.B.
IEC 61508 Safety Integrity Level 3 (SIL 3). Die gesamte Applikationssoftware steht ja quasi auf dem
Betriebssystem als Fundament – und wenn dafür der Nachweis für extrem geringe Auswahlwahrscheinlichkeit schon erbracht wurde, ist der Weg zu einer Zertifizierung nach IEC 62304 deutlich leichter. Es ist also auf jeden Fall hilfreich, einen OS-Anbieter zu suchen, der bereits erfolgreich verschiedene Zertifizierungen durchlaufen hat10.
Entwicklungswerkzeuge
In einer Studie von 2010 hat VDC Research einige interessante Umfrageergebnisse veröffentlicht: Im Medizintechnikbereich gaben 55,3% der Befragten an, dass ihre aktuellen Projekte hinter dem Zeitplan zurücklagen, bei über 40% waren es mehr als drei Monate11. Als Begründung wurde alles Mögliche genannt:
von hoher Projekt-Komplexität bis zu schlechtem Management.
Doch was immer die Gründe für Verzögerungen sind, an den Entwicklungswerkzeugen sollte es möglichst nicht liegen. Moderne Embedded-Betriebssysteme bieten mit Echtzeit-Prioritäten, Multicore-Unterstützung und Zeit- Partitionierung viele mächtige Mechanismen, doch um diese optimal einzusetzen, bedarf es guter
10 Siehe “Einsatz eines IEC 61508-zertifizierten Kernels für sicherheitskritische Systeme”, Chris Hobbs, QNX 2010.
11 Steve Balacco u.a.: 2010 Survey Year, Track 2: Embedded System Engineering Survey Data, Vol. 3: Vertical Markets. VDC Research, 2010, S. 27.
Entwicklungswerkzeuge. Vor allem die Systemanalyse ist essentiell, damit nachvollziehbar wird, ob die eigene Applikation im Zusammenspiel mit dem Betriebssystem sich exakt so verhält wie gewünscht.
Nachweise erbringen
Gute Werkzeuge können außerdem helfen, konkrete Nachweise bezüglich Funktionalität und Systemverhalten zu erbringen. Code Coverage, System Profiling und Memory-Analyse12 liefern wertvolle Informationen, die im Rahmen der Konformitätsprüfung die Nachweis-
Erbringung unterstützen können.
Fazit
Der demografische Wandel in Kombination mit den Sparzwängen im Gesundheitswesen führt zu einem steigenden Bedarf im Bereich Remote-Care. Es entstehen viele neue medizintechnische Systeme, die oft noch sicherer und noch einfacher zu bedienen sein müssen als bisherige Geräte, da sie nicht von Spezialisten, sondern vom Patienten selbst verwendet werden. Damit steigen die Ansprüche an die Entwickler, denn es wird höchste Verlässlichkeit erwartet und komplexe
Zulassungsprozesse sind zu meistern. Das
Betriebssystem, auf dem die Gerätesoftware aufsetzt, spielt hier eine entscheidende Rolle: Mit dem Wissen über die richtigen Auswahlkriterien kann der Medizintechnik- Hersteller eine fundierte Entscheidung für das
einzusetzende Embedded-OS treffen. Damit steigen die Erfolgschancen des Projekts, Zeitbedarf und
Entwicklungsaufwand können reduziert werden. Höchste Sicherheit bietet ein OS auf Microkernel-Basis. Bei Geräten, die während des Betriebs nicht spontan ausfallen und neu starten dürfen, ist ein Microkernel sogar ein Muss, denn nur diese Architektur ermöglicht den Entwicklern, effektive Strategien für höchste Verlässlichkeit und Verfügbarkeit für ihr System zu entwerfen. Wichtig für die Betriebssystemauswahl sind neben der Architektur außerdem Echtzeitfähigkeit, Zeit- Partitionierung und Datenintegrität . Ein Betriebssystem- Hersteller sollte ferner OS-Versionen mit
Sicherheitszertifizierungen im Programm haben, damit man für die Anforderungen der FDA, MDD usw. bestens ausgerüstet ist.
12 Mehr finden Sie z.B. im Artikel “Memory Errors in Embedded Systems: Analysis, Prevention, and Risk Reduction” von Elena Laskavaia u.a., QNX Software Systems 2010.
Literaturhinweise
Bacic, Eugen: “Security as a Core Competency of the QNX Neutrino Microkernel”, Cinnabar Networks (Bell Security) und QNX Software Systems, 2006. www.qnx.com
Balacco, Steve u.a.: 2010 Survey Year, Track 2: Embedded System Engineering Survey Data, Vol. 3: Vertical Markets.
Natick, Massachusetts, VDC Research, 2010.
Canadian Medical Association: “Canada's Physicians lead the way in charting a new course for healthcare”, 8/2010.
www.newswire.ca/en/releases/archive/August2010/03/
c7852.html
Hicks, Robin: “How will technology change the future of healthcare?”, FutureGov, 1.9.2009.
www.futuregov.asia/articles/2009/sep/01/how-will- technology-change-future-healthcare/
Hobbs, Chris: “Einsatz eines IEC 61508-zertifizierten Kernels für sicherheitskritische Systeme”, QNX Software Systems, 2010. www.qnx.com
Kharif, Olga: “Qualcomm, AT&T Move in on 'M-Health'”, Bloomberg Businessweek, 23.8.2010.
http://www.businessweek.com/technology/content/aug20 10/tc20100823_511801.htm
Laskavaia, Elena u.a.: “Memory Errors in Embedded Systems: Analysis, Prevention, and Risk Reduction”, QNX Software Systems, 2010. www.qnx.com
Leroux, Paul: “Exactly When Do You Need an RTOS?”, QNX Software Systems, 2009. www.qnx.com
Leroux,Paul: “Using Resource Partitioning to Build Secure, Survivable Embedded Systems”, QNX Software Systems, 2009. www.qnx.com
Nagarajan, Shiv u.a.: “Processor Affinity or Bound Multiprocessing? Easing the Migration to Embedded Multicore Processing”, QNX Software Systems, 2009.
www.qnx.com
Rosser, Walter W. u.a.: “Patient-Centered Medical Homes in Ontario”, New England Journal of Medicine, 362:e7, Januar 2010.
www.nejm.org/doi/full/10.1056/NEJMp0911519 United Nations Population Division, World Population Prospects: The 2008 Revision Population Database, 2008.
http://esa.un.org/unpp/
World Health Organization, The world health report 2008:
primary healthcare now more than ever, Genf, 2008.
Über QNX Software Systems
QNX Software Systems ist Hersteller innovativer Embedded-Technologien, dazu gehören Middleware, Entwicklungswerkzeuge und Betriebssysteme. Die komponentenbasierte Architektur des QNX® Neutrino® RTOS, die QNX Momentics® Tool Suite und die QNX Aviage® Middleware-Reihe bilden gemeinsam das zuverlässigste und skalierbarste Fundament für leistungsfähige Embedded- Systeme. Weltweit bekannte Firmen wie z.B. Cisco, Daimler, General Electric, Lockheed Martin oder Siemens nutzen QNX- Technologie für Telematik- und Infotainmentsysteme, Industrieroboter, Netzwerk-Router, medizinische Geräte, Sicherheits- und Verteidigungssysteme und viele andere betriebs- und sicherheitskritische Applikationen. Die QNX-Firmenzentrale ist in Ottawa, Kanada, die deutsche Niederlassung befindet sich in Hannover.
www.qnx.com
© 2011 QNX Software Systems Limited, a subsidiary of Research In Motion Ltd. All rights reserved. QNX, Momentics, Neutrino, Aviage, Photon and Photon microGUI are trademarks of QNX Software Systems Limited, which are registered trademarks and/or used in certain jurisdictions, and are used under license by QNX Software Systems Limited. All other trademarks belong to their respective owners. 302210 MC411.97GERMAN
