Heilende Software

Marktveränderungen

Marktveränderungen

Die Forderung nach einer langen Lagerbeständigkeit ist bei Geräten wie einem Defibrillator besonders wichtig. Falls das Gerät mit Batterien versorgt wird, muss es ohne erneut aufgeladen zu werden, seine gesamte Lebensdauer überstehen. Dies bedeutet, dass die Systemsoftware so entwickelt werden muss, dass sie die Gerätebatterie nur minimal belastet. Eine Methode ist der Einsatz von zwei Prozessoren. Ein kleinerer Prozessor hält die Systemfunktionen aufrecht, evaluiert Hardware, gewährleistet die Systembereitschaft und erstellt Statusreports. Ein größerer Prozessor ist für ein intuitives HMI und Echtzeitereignisse wie zum Beispiel das Monitoring der Vitalparameter des Patienten zuständig und liefert elektrische Impulse, sobald erforderlich. Gleichzeitig wird die Leistungsaufnahme für einen kompletten Produktlebenszyklus minimiert.

Audio-Fähigkeiten und eine einfache, intuitive grafische Benutzerschnittstelle (GUI) mit minimalen Optionen sind bei einem Defibrillator anstelle einer komplizierten Schnittstelle ebenfalls zu begrüßen. Eine sichere und stabile Kommunikation ist ebenfalls wichtig. Nach einem Einsatz muss die Einheit Daten an einen Administrator liefern, der relevante Daten an den für den Patienten zuständigen Arzt zur Begutachtung weiterleiten kann. In diesem Fall erfordert die Kommunikation den Einsatz eines GSM-Protokoll-Stacks. Während des Einsatzes ist eine CPU mit wesentlich höherem Leistungsvermögen notwendig, um zu bestimmen, ob die Abgabe eines Elektroschocks gerechtfertigt ist.

Der Einsatz eines einfachen »Round-Robin«-Schedulers ist wegen dieser Anforderungen nicht ausreichend. Dies begründet abhängig von mehreren Faktoren einschließlich Fast-Boot- und Low-Power-Anforderungen den Einsatz eines RTOS oder General-Purpose-OS. Minimale Software würde ein RTOS rechtfertigen, das typischerweise sehr viel kleiner ist als ein General-Purpose-OS. Eine kleinere Codegröße bedeutet geringere RAM-Anforderungen und somit eine geringere Leistungsaufnahme sowie weniger auszuführenden Code. Falls Zeit ein kritischer Faktor ist, ist ein RTOS gerechtfertigt. Falls ein medizinisches Gerät außerhalb von Notfällen verwendet wird, könnte ein General-Purpose-OS akzeptabel und Middleware ebenfalls von Vorteil sein.

Zusätzliche Überlegungen

Entwickler von Medizingeräten sollten im Hinblick auf die Systemsoftware auch folgende Eigenschaften berücksichtigen: Modularität, Skalierbarkeit, Funktionssicherheit (Safety), Datensicherheit (Security), Konnektivität und Benutzerschnittstelle. Geräte müssen sich an sich ändernde Netzwerkanforderungen anpassen lassen. Somit muss das OS auf einer modularen, erweiterbaren und zukunftssicheren Architektur basieren, bei welcher der Kernel von Middleware, Protokollen, Applikationen und anderen Paketen getrennt ist, damit sich diese Elemente ohne Änderungen am Kernel hinzufügen oder erweitern lassen. Die Skalierbarkeit der Systemsoftware ist ebenfalls sehr wichtig, wenn man die Verbreitung von Geräten, angefangen bei Systemen mit kleinem Formfaktor und für nur eine Applikation bis hin zu komplexen Systemen für mehrere Applikationen, berücksichtigt. Ein einziges RTOS, das so skaliert werden kann, dass es die Anforderungen mehrerer Produktklassen hinsichtlich Speichergröße, Funktionsumfang und Verarbeitungsmöglichkeiten erfüllt, kann Herstellern helfen, den ROI (Return on Investment) zu steigern, die Entwicklungskosten zu senken und die Time-to-Market zu verkürzen.

Sicherheit ist bei Medizingeräten von entscheidender Bedeutung. Doch nicht alle Applikationen sind lebenswichtig. Es gibt Software, die es erlaubt, mehrere Applikationen mit unterschiedlichen Kritikalitätsgewichtungen auf der gleichen Hardwareplattform zu betreiben (Bild 2).

Hingegen sind Eigenschaften im Hinblick auf die Datensicherheit nicht nur wichtig, um das System vor Schadsoftware oder schädlichen Applikationen zu schützen, sondern auch eine sichere Speicherung und Übertragung von Daten sowie manipulationssichere Designs zu ermöglichen. Entscheidend ist, dass diese Eigenschaften auf OS-Ebene unterstützt werden. Auf Benutzer- oder Applikationsebene wären sie ineffizient, teuer und risikobehaftet.

Im Hinblick auf Konnektivität werden Medizingeräte zunehmend mit öffentlichen Netzwerken verbunden. Dies bedeutet, dass Systemsoftware eventuell Kommunikationsprotokolle wie CAN, Bluetooth, Continua, 802.15.4, Wi-Fi und Ethernet unterstützen muss. Hinzu kommt, dass sich die Anwenderschnittstelle zu einem wichtigen Unterscheidungsmerkmal wandelt. Somit werden leistungsstarke und dennoch einfach handhabbare HMI-Funktionen immer bedeutender.

1. Heilende Software
2. Marktveränderungen
3. Kommerziell oder Open Source?

Lesen Sie mehr zum Thema