Flexible Integration in der Medizintechnik-Software mit Publish/Subscribe Messaging Justin Moon (Product Manager, Medical) Ben VandenBelt, B.Eng (Senior Developer, Medical Team) QNX Software Systems [email protected], [email protected]

Inhalt Viele Medizingeräte müssen eine Vielfalt unterschiedlichster Hardware- und Softwarekomponenten in sich vereinen. Zudem sollen sie auch noch eine moderne und umfangreiche Mensch-Maschine-Schnittstelle (MMS) unterstützen. Persistent Publish/Subscribe (PPS) Messaging stellt einen vielseitigen, einfach implementierbaren und zuverlässigen Messaging-Mechanismus zur Verfügung, der das Systemdesign erheblich vereinfacht und die Implementierung einer MenschMaschine-Schnittstelle erleichtert.

Einführung Design, Entwicklung und Markteinführung eines elektronischen medizinischen Gerätes benötigen oft sehr viel mehr Zeit, Geld und Entwicklungsaufwand als man z.B. für ein Gerät mit ähnlich hoher Komplexität im Bereich der Unterhaltungselektronik aufwenden müsste. Neben den allgemein üblichen Anforderungen an Entwicklung und Validierung müssen medizinische

Geräte auch noch strengste Anforderungen an die funktionale Sicherheit und die Zulassungskriterien erfüllen. Design, Entwicklung und Validierung müssen deshalb innerhalb eines exakt definierten Rahmens ablaufen, die Anforderungen an die funktionale Sicherheit des Gerätes müssen durch eine umfangreiche und lückenlose Validierung nachgewiesen werden. Und selbstverständlich muss das Gerät die notwendigen Marktzulassungen nach FDA 510(k), MDD oder anderen internationalen/länderspezifischen Behörden schaffen. Dieses Paper beschreibt PPS Messaging in einem beispielhaft aufgebauten Patientenmonitor ("QNX Medical Demo"), der medizinische Daten sammelt und zur Verfügung stellt. Dieser portable Technologiedemonstrator integriert Blutdruckmesser, Spirometer, Pulsoximeter, EKG und eine Insulinpumpe. Diese Komponenten sind mit einem QNX-Continua Interoperability-Manager verbunden und verwenden QNX-PPS-Messaging für die Kommunikation mit

Abbildung 1: Der „QNX Medical Demo“ Technologiedemonstrator.

1

Flexible Integration in der Medizintechnik-Software mit Publish/Subscribe Messaging

einer auf Qt-basierten Mensch-MaschineSchnittstelle. PPS wird auch für die Kommunikation mit einem Remote-Manager verwendet, der eine abgesicherte Internetverbindung zu einer Datenbank und einem Tablet-PC herstellt. Zur Umsetzung dieser Spezifikationen haben wir uns beim Kommunikationsparadigma für PPS entschieden, weil sich unterschiedlichste Komponenten damit sehr einfach integrieren lassen.

kritische Herausforderung werden! Nachdem ein Teil der Komplexität auf die Anwendungsebene und damit in die Entwicklung der Anwendungen verschoben wird, können nicht nur Entwurfs- und Entwicklungspläne, sondern vor allem auch die Validierung der Geräte und damit letztlich deren Zulassung nachteilig beeinflusst werden.

Asynchrone Kommunikation

Send/Receive/Reply (also synchrone) Kommunikation ist allgemein weniger weit verbreitet als asynchrone Kommunikation. Bei Echtzeitsystemen beispielsweise spielt sie eine wichtige Rolle, da viele Prozesse zwingend auf eine Rückmeldung warten müssen, ehe sie fortfahren können. Anders als bei asynchroner Kommunikation übernimmt das entsprechende System-Framework die Fehlerbehandlung und die Speicherverwaltung.

Asynchrone Kommunikation ist allgemein bekannt und so weit verbreitet, dass wir an dieser Stelle auf eine genaue Erklärung verzichten wollen. Viele Systeme basieren auf asynchroner Kommunikation, aber aufgrund ihrer Eigenschaften eignet diese sich oft nicht ideal für Systeme, die eine große Vielzahl unterschiedlicher Hard- und Softwarekomponenten in sich vereinen müssen. Im Zusammenhang mit Kommunikationsmodellen für komplexe medizinische Geräte sollte man sich klar machen, dass asynchrones Messaging eine absolute Low-Level-Lösung ist, die die ganzen Probleme der Fehlerbehandlung, der Korrektheit der Semantik der Kommunikation sowie der Speicherverwaltung an die Anwendungsebene delegiert. Somit muss man beim Entwurf eines Systems mit asynchroner Kommunikationsstruktur ein Protokoll (oder womöglich mehrere Protokolle) entwickeln, das die fehlerfreie Kommunikation durch alle beteiligten Schichten sicherstellt. Zudem muss man dafür sorgen, dass der Anwendung immer genug Speicher für die Message-Buffer, speziell bei hohem Kommunikationsaufkommen, zur Verfügung steht.

Abbildung 2. Bei asynchroner Kommunikation wartet ein Prozess nicht auf die Rückmeldung des Empfängers.

Bei einfachen Systemen stellt das kein großes Problem dar, aber bei komplizierten oder skalierbaren Systemen kann das ganz schnell eine

2

Send/Receive/Reply

Abbildung 3. Bei synchroner Kommunikation wartet ein Prozess bis er eine Antwort vom Empfänger seiner Nachricht erhalten hat.

Jeder Server kommuniziert direkt mit seinen Clients und muss deshalb wissen, wie er auf die Anfragen der Clients reagieren muss. Bei einem derartig eng gekoppelten System zieht eine Änderung in einer Komponente häufig eine Menge Änderungen in anderen Komponenten nach sich, das bremst und behindert den Entwicklungsprozess und macht das System insgesamt anfälliger. Lösungen, die "auf Basis initialer Kommunikationsanforderungen entworfen und implementiert wurden ... werden schnell brüchig, sobald neue Anforderungen eingearbeitet werden müssen. Üblicherweise basieren sie auf direkten Punkt-zu-Punkt Verbindungen zwischen Anwendungen/Komponenten"1. 1

Jerry Krasner. “Making the case for commercial communication integration middleware”. Embedded.com (29. Dez. 2009).

Flexible Integration in der Medizintechnik-Software mit Publish/Subscribe Messaging

Maschinen- oder Menschen-lesbare Objekte? Ein PPS-Service kann sowohl mit maschinenlesbaren als auch mit für Menschen verständlichen Objekten realisiert werden. Wir haben uns für eine für Menschen lesbare Form entschieden, da die Vorteile bei Entwicklung und Fehlersuche den Nachteil der etwas größeren Objekte aufwiegen. Für Menschen lesbare Objekte erlauben einfaches Debuggen von der Kommandozeile aus mit Bordmitteln wie z.B. dateibasierten Utilities - z.B. cat für Subscribe und echo für Publish: Beispiel: cat /pps/media/PlayCurrent cat /pps/media/.all?wait

oder: echo "attr::value">>/pps/objectfilename

Ähnlich einfach kann man Debugging-Informationen über die Objekte und ihre Eigenschaften sammeln, man benötigt nur ein einfaches Programm als Subscriber, welches die Informationen ausgibt.

Anders ausgedrückt: Wird Send/Receive/Reply Messaging für ein System verwendet, das wächst und neue und unterschiedliche Komponenten integrieren muss, so steigt die Systemkomplexität enorm. Es wird immer schwieriger, das System warten und erweitern zu können, ohne die Leistung und die bei Medizingeräten absolut kritische Zuverlässigkeit zu beeinträchtigen.

Persistent Publish/Subscribe Send/Receive/Reply-Messaging ist bei Echtzeitbetriebssystemen wie z.B. QNX Neutrino, welche absolut strengste Anforderungen an Zuverlässigkeit und Verfügbarkeit erfüllen müssen, etabliert und fraglos notwendig. Allerdings stellt sich die Frage, ob Send/Receive/Reply (ebenso wie asynchrone Kommunikation) wirklich erste Wahl für die Anwendungsebene ist – insbesondere bei komplexen Systemen, welche in der Lage sein müssen, unterschiedlichste Anwendungen und Funktionalitäten schnell und unkompliziert zu integrieren. Das Problem dabei ist, dass

Send/Receive/Reply Sender und Empfänger stark aneinander bindet. Publish/Subscribe-Kommunikationsmodelle existieren in der ein oder anderen Form schon seit über 20 Jahren. Ein ähnliches, virtuell synchrones Messaging-Modell wurde von K.P. Birman und T. A. Joseph 1987 als "Mechanismus für ein fehlertolerantes, asynchrones Schwarzes Brett" beschrieben2. Vor 20 Jahren hat Nortel ein vergleichbares Modell für die Fehlerüberwachung von Telefonanlagen, wie z.B. der DMS-100, entwickelt und diese Technologie für das Netzwerk-Monitoring und Reporting-Systeme verwendet. Ein kurzer Blick ins Internet genügt, um eine ganze Menge an Beispielen für Publish/ Subscribe-Implementierungen zu finden. Wenn man etwas ausführlicher sucht, zum Beispiel im ACMPortal, lassen sich Hunderte von Dokumenten finden, die sich mit Aspekten von Publish/Subscribe oder anderen Observer-Pattern in der Datenverarbeitung beschäftigen. Sprachunabhängigkeit QNX PPS macht sich die Funktionalität des Standard-POSIX-Dateisystems zu Nutze. Somit kann es mit jeder Programmiersprache und in jeder Umgebung eingesetzt werden, unter anderem z.B. mit C, C++, Java, Adobe Flash, ksh-Skripten usw. Egal in welcher Sprache eine Komponente geschrieben wurde, sie kann mit allen anderen Komponenten kommunizieren, auch wenn diese mit einer anderen Sprache implementiert wurden. Man muss also keinerlei Detailinformationen über die anderen Komponenten besitzen.

Uns geht es primär um die Frage, wie ein Publish/Subscribe-Mechanismus, welcher sogar über den Neustart eines Systems hinaus Persistenz garantiert ("Persistent Publish/Subscribe", kurz PPS), das Design und Deployment von EmbeddedSystemen vereinfachen kann, die nicht nur eine Vielzahl von unterschiedlichen Hard- und 2

Kenneth P. Birman and Thomas A. Joseph. “Exploiting Virtual Synchrony in Distributed Systems”. Cornell University. Februar 1987. Siehe auch Kenneth P. Birman, Building Secure and Reliable Network Applications. Greenwich: Manning, 1996.

3

Flexible Integration in der Medizintechnik-Software mit Publish/Subscribe Messaging

Softwarekomponenten unterstützen müssen, sondern darüber hinaus auch noch mit hochentwickelten Mensch-Maschine-Schnittstellen (MMS) kommunizieren sollen. Wir haben für die QNX Medical Demo eine Qt-basierte MMS verwendet, aber die Vorteile des PPS können selbstverständlich auch Schnittstellen zu Gute kommen, die mit anderen Grafik-Technologien realisiert wurden. “Push” oder “Pull”? Die Default-Implementierung des QNX PPS-Services arbeitet als push Publishing-System. Dabei schreibt der Publisher seine Daten in Objekte, die Subscriber lesen diese dann entweder nach einer Benachrichtigung oder wann immer sie wollen. Manche Daten, beispielweise ein Datenzähler an einer Schnittstelle, ändern sich aber viel zu schnell, als dass man sie mit dem standardmäßig verwendeten Push-Service effizient verteilen könnte. Deshalb bietet QNX PPS eine Option, die es dem Subscriber ermöglicht, PPS als pull-Service zu betreiben. Wenn ein Subscriber, der ein Objekt mit dieser Option geöffnet hat, einen read() Aufruf startet, dann bekommen alle Publisher des Objektes eine Benachrichtigung, nun ihre aktuellen Daten in das Objekt zu schreiben. Der Lesezugriff des Subscribers blockiert so lange, bis die Objekt-Daten aktualisiert wurden und liefert dann die neuen Daten zurück.

Objekten eintragen lassen, generell kann ein PPSObjekt sowohl mehrere Publisher als auch mehrere Subscriber besitzen. Somit können Publisher, die auf Daten zugreifen, die jeweils unterschiedlichen Objektattributen entsprechen, ein gemeinsames Objekt für die Kommunikation mit allen Subscribern dieses Objektes verwenden. Selbstverständlich muss ein Client zunächst wissen, welche Objekte für ihn interessant sind. Als Publisher muss man wissen, welche Information wann veröffentlicht werden soll, für Subscriber muss klar sein, welche Objekte und insbesondere welche Objektattribute überhaupt von Interesse sind. Dafür müssen sich PPS-Clients nicht um die Fehlerbehandlung und die Pufferung von Daten über das hinaus kümmern, was für die POSIXStandardfunktionen open(), read() und write() notwendig ist. Sie sollen nur bestätigen, dass sie die Daten sinnvoll interpretieren können und festlegen, ob ihr Lesezugriff blockierend sein soll oder nicht. Den Rest erledigt der PPS-Service. Clients müssen also nur wissen, dass eine Nachricht gelesen wurde und dass die Leser in der Lage waren, die Nachricht erfolgreich zu parsen. Da die Subscriber read() für das Abfragen der Objekte verwenden, müssen sie sich ebenfalls nicht um die Verwaltung von Datenpuffern für diese Objekte kümmern.

Der pull-Mechanismus erlaubt dem Subscriber also die Abfrage der Daten mit der jeweils benötigten Frequenz, letztlich können wir hier von "Publishing on demand" sprechen.

Ein objektbasiertes System PPS ist ein objektbasierter Service mit Publishern und Subscribern in einer lose gekoppelten Kommunikationsstruktur. Jeder PPS-Client kann, je nach Anforderung, entweder nur Publisher, nur Subscriber oder aber auch beides gleichzeitig sein. Das Publishing erfolgt stets asynchron, die PPSObjekte sind in den Namensraum des Dateisystems integriert. Publisher verändern Objekte und ihre Attribute und schreiben sie in das Dateisystem. Sobald ein Publisher ein Objekt modifiziert, werden alle Subscriber dieses Objektes durch den PPSService informiert. Clients können sich bei mehreren

4

Abbildung 4: Ein Screenshot des QNX Medical Demo Hauptbildschirms.

Persistenz Persistent Publish/Subscribe hält die Daten auch über einen Neustart des Systems hinweg verfügbar und konsistent. Zunächst werden die Daten im Speicher gehalten. Sie werden, wenn gewünscht, zur Laufzeit oder spätestens beim Runterfahren des

Flexible Integration in der Medizintechnik-Software mit Publish/Subscribe Messaging

Systems persistent gespeichert. Beim Hochfahren werden die Daten entweder sofort, oder beim ersten Zugriff wieder hergestellt ("deferred loading"). Natürlich benötigt dieser Mechanismus ein zuverlässiges Dateisystem und Speichermedium, z.B. eine Festplatte oder NAND bzw. NOR Flashspeicher. Neben der Persistenz von Daten über Neustarts hinweg kann PPS-Messaging auch Systemstarts vereinfachen. Angenommen sei ein System, welches ein anderes Messaging-Modell verwendet: Startet der Client nach dem Server, so muss er direkt vom Server die aktuellen Daten anfordern, es könnten sich die Daten ja in der Zeitspanne zwischen dem Serverstart und dem Hochfahren des Clients verändert haben. Das ist auch der Fall, wenn der Client aus irgendeinem Grund den Kontakt zum Server verliert. Und natürlich gilt das für jeden Client im System, dem der Server antworten muss. Bei PPS hingegen stellt der Service seine Objekte beim Start wieder her und zieht jede Änderung sofort nach. Ein beliebiger Client, egal ob beim Start oder bei der Wiederaufnahme der Verbindung, muss einfach nur die Objekte lesen, um an die aktuellen Daten zu kommen.

Skalierbarkeit Bei PPS kennen sich Publisher und Subscriber nicht. Ihre einzige Verbindung ist ein Objekt, das für beide von Bedeutung ist. Dieses Messaging-Modell gibt Entwicklern maximale Flexibilität beim Entwurf eines Systems: Entscheidungen zu den Verbindungspunkten der Module und zum Datenfluss können, sofern notwendig, in die Laufzeit des Systems verschoben werden. Da diese Verbindungen nicht fest programmiert und nicht direkt zugewiesen sind, können sie je nach Situation und Anforderung angepasst werden. Sie können sogar zur Laufzeit des Systems dynamisch verändert werden. Dieses lose gekoppelte PPS-MessagingModell vereinfacht auch die Integration neuer Softwarekomponenten: Da sich Publisher und Subscriber gar nicht kennen müssen, muss ein Entwickler bei der Erweiterung um neue Komponenten nur wissen, welche Daten diese benötigen und welche sie für andere PPS-Clients veröffentlichen sollen. Es müssen keine Anpassungen an der API vorgenommen werden und die Komplexität des Systems wird durch die neuen Komponenten nicht größer.

QNX Medical Demo Die im Rahmen des QNX Medical Device Programms entwickelte medizintechnische Demo-Anwendung läuft auf dem QNX Neutrino RTOS, das hervorragend für die limitierte Rechenleistung von portablen medizinischen Geräten geeignet ist. Die angeschlossenen Messgeräte, die über einen auf Continua basierenden Interoperability-Manager verbunden sind, liefern via PPS Daten an eine QtBenutzeroberfläche.

Qt und CESL Beim User-Interface haben wir uns für Qt entschieden, beim Interoperability-Manager für die "Continua Enabling Software Library" (CESL), da beide Technologien im Bereich der Medizingeräte weit verbreitet sind. Qt stellt eine wohl bekannte Menge von Oberflächenelementen für die Programmierung mit C++ zur Verfügung und besitzt eine lange und erfolgreiche Historie von Implementierungen auf Geräten, die ihre Zulassung durch die FDA oder andere Behörden erhalten haben. Mit Qt verfügen wir über alle Elemente, die wir für eine klare und effektive SmartScreenOberfläche benötigen: Exaktes Layout, Ebenen und Multimedia-Unterstützung. Die in der Continua-Bibliothek angebotenen Protokolle bieten nicht nur einen einfachen Kommunikationsmechanismus für verschiedenartige medizinische Geräte, sondern auch standardisierte Protokolle mit einer umfangreichen Historie erfolgreicher Ausbringungen in medizinischen Geräten. Kurz: Qt und Continua erfüllten alle unsere Anforderungen und sind in der Medizingeräteindustrie als zuverlässig bekannt und beliebt.

Vereinfachte Architektur Einer der wichtigsten Vorteile des PPS-Messaging bei der QNX Medical Demo-Anwendung ist die flexible Architektur aufgrund des lose gekoppelten Messaging-Modells. Wenn wir, warum auch immer, die Continua-Bibliothek oder Qt für die MenschMaschine-Schnittstelle durch eine andere Technologie ersetzen müssten, so wäre das mit wenig Aufwand möglich. Ersetzt man beispielsweise die MMS-Technologie, so wären der Interoperability-Manager und der Remote Server davon nicht betroffen, umgekehrt würde eine

5

Flexible Integration in der Medizintechnik-Software mit Publish/Subscribe Messaging

Abbildung 5: PPS-Messaging beim QNX Medical Demo Patientenmonitor. PPS übernimmt die gesamte Kommunikation zwischen der MMS und dem Interoperability-Manager, ebenso mit dem Remote Manager.

Änderung an den Managern keine Anpassungen der MMS notwendig machen. Zudem erleichtert das PPS-Messaging-Modell die Integration neuer Geräte, die über Continua-Standardprotokolle für USB, Bluetooth oder TCP an das System angebunden werden können. Beispielsweise könnten wir ein EEG zur QNX Medical Demo hinzufügen, indem wir es über die Continua-Protokolle mit dem Interoperability-Manager verbinden und geeignete PPS-Objekte erzeugen, die die Daten zur Datenbank, zur lokalen MMS und der MMS des Tablet-PCs kommunizieren. Natürlich muss man die Schnittstelle noch um die notwendigen Anzeigen und Controls erweitern.

6

In einem System mit einem anderen MessagingModell wären die Komponenten alle stark aneinander und an die MMS gebunden. Jede Komponente muss alle anderen Komponenten kennen, mit denen sie Daten austauscht. So eine Architektur macht jede Änderung oder Erweiterung zeitaufwändig und riskant. Ein weiterer Vorteil des PPS-Messaging ist die Vereinfachung der Tests und des Nachweises der funktionalen Sicherheit, da man nach einer Erweiterung durch eine neue Komponente nicht mehr die Kommunikation aller anderen Komponenten erneut testen muss.

Flexible Integration in der Medizintechnik-Software mit Publish/Subscribe Messaging

Schlussendlich vereinfacht PPS außerdem (Re-)Branding, Lokalisierung und SchnittstellenUpdates. Da die MMS mit dem Rest des Systems nur über PPS-Objekte kommuniziert, muss ein Oberflächen-Designer nur sicherstellen, dass die neue Oberfläche dieselben Objekte für Publish/Subscribe verwendet, die die alte MMS auch verwendet hat. Unterhalb der MMS ändert sich keine einzige Codezeile. Diese Trennung erlaubt die Realisierung einer ganzen Produktreihe von Geräten, die auf einem exakt identischen System basieren, aber unterschiedliche Schnittstellen verwenden, andere Features freischalten oder mit speziell angepassten Mensch-Maschine-Schnittstellen für verschiedene Länder (Schriften, Präferenzen für Farben, Farbbedeutungen) ausgestattet sind.

Geräten und Komponenten. Da die Komponenten für ihre Kommunikation lediglich Publish/SubscribeOperationen auf Objekte anwenden, die sie für die jeweilige Implementierung benötigen, müssen sie sich nicht untereinander kennen. Das macht die Erweiterung oder Veränderung des Systems sehr einfach. Änderungen, Upgrades und Erweiterungen werden somit einfacher zu bewältigende Aufgaben, das Risiko unbeabsichtigter Destabilisierung des Systems wird deutlich geringer.

Literaturhinweise Birman, Kenneth P. and Thomas A. Joseph. “Exploiting Virtual Synchrony in Distributed Systems”. Cornell University. Februar, 1987. Siehe auch Kenneth P. Birman, Building Secure and Reliable Network Applications. Greenwich: Manning, 1996. Cieplak, Kris. “Rapid Development and Reusable Design for the Connected Car”. QNX Software Systems, 2010. Hobbs, Chris. “Building Functional Safety into Complex Software Systems, Teil I”. QNX Software Systems, 2011.

Abbildung 6: Übersicht über die QNX Medical Demo mit Verbindung zu einer externen Datenbank.

Fazit Die QNX Medical Demo demonstriert die Verwendung von PPS-Messaging in einer lose gekoppelten Architektur eines Medizingerätes. Dieses Design erlaubt eine flexible und zuverlässige Kommunikation zwischen der MMS und einem Interoperability-Manager, der ContinuaStandardprotokolle unterstützt. Dieser Interoperability-Manager kommuniziert mit externen

Hobbs, Chris. “Building Functional Safety into Complex Software Systems, Teil II”. QNX Software Systems, 2011. Krasner, Jerry. “Making the case for commercial communication integration middleware”. Embedded.com (29. Dezember, 2009). Leroux, Paul. “Exactly When Do You Need an RTOS?” QNX Software Systems, 2009.

7

Flexible Integration in der Medizintechnik-Software mit Publish/Subscribe Messaging

Über QNX Software Systems QNX Software Systems ist Hersteller innovativer Embedded-Technologien, dazu gehören Middleware, Entwicklungs-werkzeuge 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 Verteidigungs-systeme und viele andere betriebs- und sicherheitskritische Applikationen. Die QNXFirmenzentrale 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. 302216 MC411.102

8