Medizingeräte als Wearable Device entwickeln

Bild 1: Die Software-Plattform für Medical Wearables muss allen nicht-applikationsspezifischen Code abdecken.Mentor Graphics

In Zukunft werden viele tragbare Medizingeräte als Medical Wearables nahtlos in unser Leben integriert sein. Statt primär an das System zu denken, müssen Entwickler die Dienstleistung im Blick haben die das Gerät bereitstellt. Dabei müssen sie sehr stringenten Herstellungsanforderungen gerecht werden. So müssen tragbare medizinische Geräte klein sein, sie müssen immer verbunden sein und eine lange Batterielaufzeit vorweisen. Die höhere Funktionalität wird auch die nötigen Rechenressourcen nach oben treiben. Entwickler müssen darüber hinaus in einem sehr konkurrenzbetonten Markt mit steigender Komplexität bestehen. Um diesen Anforderungen zu genügen, sollten sie auf eine Plattform setzen (Bild 1), die schnell, flexibel, einfach zu nutzen und kosteneffektiv ist.

Geräteprofil

Medizinische Wearables gibt es in zwei Kategorien: Einmal-/Wegwerf-Produkte und wiederverwendbare Geräte. Wegwerfprodukte sind ein relativ neues Marktsegment mit kurzer Produktlebenszeit und daher hohen Wachstumschancen. Im Gegensatz dazu zeichnen sich wiederverwendbare Geräte durch eine deutlich längere Produktlebenszeit und viel höhere Ansprüche an Sicherheit und Zuverlässigkeit aus.

Bei Wegwerfprodukten geht es um hohe Volumina und knappe Margen. Deshalb müssen sie ein Maximum an Funktionalität mit dem kleinstmöglichen Prozessor bereitstellen. Um hier den Umsatz zu maximieren, ist es üblich, eine ganze Produktpalette für ein großes Spektrum an Endanwendern anzubieten. Dabei ist es aber nicht wirtschaftlich, für jedes dieser unterschiedlich ausgestatteten Produkte eigene Applikationen zu schreiben. Die Entwickler müssen daher mit einer gemeinsamen Applikationsbasis arbeiten, die sich an unterschiedliche Rechenressourcen anpassen lässt. Solch eine Umgebung muss bis auf das minimalistischste System herunter skalieren, das oft nur sehr kleine Speicherkapazitäten hat, und trotzdem auch komplexe Applikationen unterstützen können.

Der Markt mit wiederverwendbaren Geräten stellt ganz andere Herausforderungen. Der Gerätehersteller sollte sich hier von der kurzlebigen Natur der Prozessoren entkoppeln. Die Lebenszeit der Halbleiter variiert von Hersteller zu Hersteller. Die Endkunden erwaten aber Bauteilersatz für zehn Jahre und mehr. Will ein Entwickler dieses Problem lösen und die Langlebigkeit seines Applikations-Codes erhalten – was er muss, um profitabel zu bleiben – dann braucht er ein stabiles Programmier-API, statt auf einen bestimmten Prozessor zu setzen.

Vernetzung

Der Trend, Geräte so weit zu miniaturisieren dass man sie problemlos tragen kann, besteht schon lange. Heute erwarten die Anwender jedoch auch globale Connectivity, entweder per direktem Online-Zugang für Cloud-Dienste oder eine Anbindung an ein lokales Vermittlungsgerät, etwa ein medizinisches Wearable gepaart mit dem Smartphone, das dann den Weg ins Internet ebnet. Diese Anbindung kann zeitweise oder dauerhaft über eine bedrahtete oder eine drahtlose Verbindung stattfinden.

Drahtgebundene Connectivity ist am kostengünstigsten, aber sie bietet auch die geringste Flexibilität. Wenn die Geräte über ein vom Hersteller des Wearables gestelltes Kabel mit einem anderen Gerät verbunden werden, dann können auch sehr einfache Schnittstellen wie SPI und I²C zum Einsatz kommen. Für eine Verbindung mit einem PC oder ähnlichem ist allerdings ein offenerer Standard wie USB erforderlich. Jeder Ingenieur, der mit diesen verschiedenen Verbindungsmethoden schon gearbeitet hat, weiß, dass die Unterschiede zwischen den Protokollen für USB und den einfacheren Ansätzen extrem hoch sind. Dabei ist es auch noch sehr wahrscheinlich, dass sich die Wahl der Anbindung über die Lebenszeit des Geräts oder sogar schon während der Entwicklungsphase ändert. Um also die Applikation von der darunterliegenden Verbindungsmethode zu trennen, bietet sich das Betriebssystem als effektivste Möglichkeit an.

Bild 2: Es gibt viele Möglichkeiten zur drahtlosen Anbindung, die sich auch laufend ändern.Mentor Graphics

Drahtlose Zukunft

Die Zukunft der medizinischen Wearables liegt aber in der drahtlosen Anbindung. Während USB komplexer als SPI ist, sind die vielen drahtlosen Anbindungsmöglichkeiten noch weit komplexer als USB. Das gilt besonders, wenn auch noch Sicherheitsfunktionen involviert sind. Dabei gibt es eine Vielzahl von Standards für die drahtlose Kommunikation, angefangen bei NFC über Bluetooth/BLE und Wi-Fi, bis hin zur Kommunikation über das Mobilfunknetz (Bild 2). In der drahtlosen Kommunikation ändern sich Technologie, Protokolle aber auch Optionen sehr schnell. Noch wichtiger ist aber die Dynamik in diesem Bereich. Denn Lösungen, die derzeit als zu teuer erscheinen, können morgen schon der wirtschaftlichste Standard sein, während der Applikations-Code hingegen typischerweise sehr langlebig ist.

Eine RTOS-Umgebung (Echtzeitbetriebssystem), die heute in ein minimalistisches Gerät mit SPI-artigem Interface passt und trotzdem die Migration auf eine vollständige Anbindung ans Mobilfunknetz (entweder innerhalb einer Produktfamilie oder über die Lebenszeit eines Produkts) erlaubt, gibt OEMs die Option, auch zukünftige Anforderungen zu meistern.

Leistungsaufnahme

Die Laufzeit der Batterie ist bekanntermaßen ein kritischer Faktor aller mobilen Geräte. Bei medizinischen Wearables, die von Personen getragen werden, spielt aber auch das Gewicht eine wichtige Rolle. Batterien sind die schwerste und sperrigste Komponente in einem tragbaren Gerät. Geht es also um ein Gerät, das eine Person den ganzen Tag bis vielleicht in den Abend hinein tragen muss (etwa ein 24-h-Blutdruckmessung), reicht es nicht aus, die Leistungsaufnahme zu minimieren, um die Batterielaufzeit zu verlängern. Es muss vielmehr die Leistungsaufnahme so stark sinken, dass die Batterie auch so klein wie möglich ausfallen kann.

Geräte wie Smartphones sind für eine bestimmte Batteriegröße ausgelegt, die eine spezifische Menge an mAh liefert. Wenn man diesen Parameter als festen Referenzwert nimmt und eine entsprechende Batterielebenszeit erreicht, führt das typischerweise zu Produkten, die die Erwartungen der Konsumenten erfüllen. Dieser Ansatz funktioniert aber nicht bei medizinischen Wearables. Sobald die Batterielaufzeit bestimmt ist, muss man vielmehr alles tun, um die Leistungsaufnahme zu senken: mit jeder Einsparung kann man eine kleinere und leichtere Batterie einsetzen.

Power-Management

Heutige Prozessoren sind mit beindruckend vielen Funktionen ausgestattet, um Energie einzusparen. Nur leider sind diese Möglichkeiten meist komplex und oft auch noch hochgradig voneinander abhängig. Darüber hinaus sind oft auch noch Schaltungen implementiert, für die überhaupt keine Stromsparmöglichkeiten bestehen. Zum Beispiel beeinflusst die Taktfrequenz des Bausteins die Taktfrequenzen der Kommunikation, auch wenn damit die Leistungsaufnahme der Kommunikationsperipherie nicht sinkt. All das stellt für den Applikationsentwickler noch eine zusätzliche Hürde dar, obwohl er schon genug damit zu tun hat, die Zielapplikation fertigzustellen. Die Fähigkeit jedes einzelne nAh aus der Batterie sinnvoll zu nutzen, bestimmt aber schlussendlich die Konkurrenzfähigkeit des Endprodukts am Markt.

Bild 3: Optimierungen in der Leistungsaufnahme betreffen bei Wearables alle Komponenten.Mentor Graphics

Die Lösung des Problems besteht darin, die Applikation auf einer Software-Plattform zu entwickeln, die sich um das Power-Management kümmert (Bild 3). Die meisten großen General-Purpose-Betriebssysteme sind mit ziemlich ausgeklügelten Power-Management-Funktionen ausgestattet; allerdings eignen sich diese Betriebssysteme nicht für die üblichen Prozessoren in tragbaren medizinischen Geräten. Die meisten Echtzeitbetriebssysteme bieten ebenfalls gewisse Power-Management-Funktionen. Die häufigste ist die Unterdrückung des System-Ticks, mit der der Kernel den periodischen Timer-Tick bis zum nächsten Timer-Event aussetzt, solange keine Tasks aufgerufen sind. Für Wearables sind aber noch weitere intelligente Methoden notwendig, und die sind in der RTOS-Welt eher selten zu finden. Derzeit unterstützt nur das Nucleus-RTOS von Mentor Graphics alle Aspekte der Energieeinsparung, einschließlich dynamischer Frequenz-Spannungs-Skalierung (DVFS) sowie die vollständige Kontrolle der verschiedenen Stromlevels aller Peripherals, mit allen Interaktionen zwischen den Peripherals und dem Core-Takt (Bild 4).

Bild 4: Ein strukturiertes Power-Framework vereinfacht die Entwicklung.Mentor Graphics

Beschränkungen in der Größe

Um dem Formfaktor von medizinischen Wearables zu entsprechen, steht für die Elektronik mit all ihren Komponenten nur wenig Platz zur Verfügung. Darüber hinaus gibt es auch nicht viele Möglichkeiten, Wärme abzuführen. Das Problem mit der Abwärme hängt natürlich mit der bereits besprochen Leistungsaufnahme zusammen. Die Beschränkungen der physikalischen Größe führen normalerweise dazu, dass ein SoC als Hauptprozessor gewählt wird. Diese Bausteine zeichnen sich gemessen an ihrer Größe durch eine beeindruckende Anzahl an Peripherals aus. Bei der Speicherkapazität lässt sich die Geometrie aber nicht austricksen. Jede zusätzliche Applikation braucht mehr Speicher. Und Speicher in kleinen Geräten, egal ob flüchtig oder nicht-flüchtig, hat seinen Aufpreis.

Das letzte was ein Entwickler brauchen kann, ist, dass die Applikation mit dem RTOS um den Speicher konkurriert. Das allein ist schon Grund genug, keine General-Purpose-Betriebssysteme in medizinischen Wearables eizusetzen. Wenn also ein RTOS in Betracht kommt, sollte der Entwickler darauf achten, dass es sich auf eine minimale Größe herunterskalieren lässt und zwar sowohl beim Code als auch bei den Daten. Wünschenswert ist hier ein Bereich von 2 kByte Code für einen abgespeckten Kernel. Mit demselben RTOS muss der Entwickler auch den obersten Leistungsbereich mit all seinen Services, wie beispielsweise Kommunikation im Mobilfunknetz, abdecken können. Wenn das nicht der Fall ist, müsste der Entwickler seine Applikation auf mehrere Betriebssysteme portieren und sie dort auch weiter unterstützen.

Schlussfolgerung

Um in einem Markt überleben zu können, der sich durch vollkommen unterschiedliche Komplexitäten, einen hohen Preisdruck und eine sich stetig weiterentwickelnde Hardware auszeichnet, müssen Entwickler ihre Applikationen auf einer leistungsfähigen und flexiblen Plattform realisieren. Diese Plattform muss einerseits von der Hardware abstrahieren, anderseits aber auch die Möglichkeit bieten, spezielle Hardware-Funktionen zu optimieren. Die Plattform wird dabei nicht länger durch die verarbeitende Architektur oder die verschiedenen Peripherals definiert, solange den Entwicklern eine entsprechende Programmierumgebung zur Verfügung steht.

Standardplattformen, die diese Anforderungen erfüllen, sind beispielsweise Windows, Android, iOS, oder Linux. Sie haben aber eine feste untere Grenze, wenn es um die minimalen Hardwareanforderungen geht. Diese Grenzen passen oft nicht zu den Einschränkungen hinsichtlich Preis, Leistungsaufnahme und physikalischer Größe, die bei medizinischen Wearables vorherrschen. Mentor Graphics sieht sein Nucleos-RTOS hingegen als optimale Basis: diese hochgradig anpassbare und erweiterbare Umgebung lässt sich an einen sehr breiten Einsatzbereich anpassen.

(lei)