Rowebots Unison MedicalOS: Eine solide Plattform für die Entwicklung von medizinischen Monitorgeräten
Die Einführung von kleinen, tragbaren medizinischen Geräten verwandelt die medizinische Versorgung und gibt Patienten größere Freiheit. Obwohl diese Geräte klein sind, sind sie auch komplex und müssen zertifiziert werden. Es lohnt sich, einen Vorsprung zu gewinnen, indem man mit einer Plattform anfängt, das vom Anfang an ein kleines aber reiches RTOS bietet. Das RTOS sollte auch eine gute Auswahl von geprüften Peripherie- und Kommunikationskomponenten mitbringen.
Von Kim Rowe, Geschäftsführer, RoweBots, Ltd.
Kleine, intelligente medizinische Geräte, die am Körper getragen oder zuhause installiert werden, retten heute Leben. Aber darüber hinaus verkürzen sie den Aufenthalt im Krankenhaus und erlauben älteren Patienten länger zuhause zu leben. Und dadurch versenken sie die Kosten der medizinischen Versorgung. Indem sie lebenswichtige Körperfunktionen direkt spüren und interpretieren können, können sie Alarme melden, sowie sich mit Medizinern und Spezialisten durch die Cloud verbinden. Das erlaubt dem Arzt, Stufen der Ernsthaftigkeit für einzelnen Patienten zu definieren.
Firmen, die diese Geräte entwickeln, müssen mit verschiedenen Herausforderungen rechnen. Zu diesen gehören die normalen Fragen von Größe, Gewicht und Energieverbrauch sowie Sicherheit und die Aufgabe, die richtige Kombination von Funktionen zu finden. Dazu kommen die Probleme der Zertifikation—oft von verschiedenen Ländern und mit verschiedenen Zertifikationsebenen. Obwohl die spezifischen Erfordernisse für medizinische Geräte oft weit verschieden sind, teilen sie auch gewisse geneinsame Eigenschaften.
Um sich den Bedürfnissen der medizinischen OEM-Gemeinschaft zu widmen, hat RoweBots Unison MedicalOS geschaffen. MedicalOS ist eine spezifische Verpackung von dem Flaggschiff-RTOS Unison, das auf medizinische Anwendungen gezielt ist. Die Absicht ist es, für eine breite Auswahl von medizinischen Geräten eine Reihe ausgewählter, vorqualifizierter Komponenten zu bieten. Der Entwickler sollte nicht gezwungen werden, durch eine verwirrende Menge von unnötigen Komponenten zu suchen, sondern diejenigen leicht finden und bewerten können, die für seine Ziele, die geeignetsten sind. Einer der wichtigsten Gebiete ist die medizinische Versorgung in der Wohnung. Hier handelt es sich um ein Gerät, das am Körper getragen wird und entweder mit einem Smartphone oder mit einem PC im Hause verbunden ist. Dieses System verbindet sich dann mit dem Internet und schließlich zu Anwendungen in der Cloud.
Der Zweck ist, dem Patienten die größte Freiheit zu geben, indem seine spezifische medizinische Kondition ständig überwacht wird. Es sollte möglich sein, verschiedene Alarmstufen zu melden. Zum Beispiel—es ist Zeit ein spezifisches Medikament zu nehmen. Bei verschiedenen Alarmstufen könnten Meldungen an Ärzte oder andere Pfleger geschickt werden, oder in andren Fällen den Notstand signalisieren. Das fordert die Fähigkeit, die Daten richtig analysieren und behandeln (speichern oder übertragen) zu können. Eine weitere Funktion wäre die Fähigkeit, gewisse Medikamente zu tragen und sie automatisch zu verabreichen.
Ein weiterer Aspekt der häuslichen Pflege befasst sich mit Ort und Bewegung. Ein Beschleunigungsmesser kann, zum Beispiel, feststellen, ob ein älterer Patient gefallen ist und ob er wieder aufgestanden ist oder nicht. Wenn ein Patient in der Nacht aufsteht, um aufs Klo zu gehen, ist er wieder ins Bett zurückgekommen? Hat er gegessen und seine Medikamente genommen? Wenn ein Alarm gesendet wird, wohin sollte man Hilfe schicken?
Aus diesen Möglichkeiten kann man sehen, dass ein bestimmtes Gerät eine eigenartige Kombination von Funktionen haben kann, die von spezialisierten Peripheriegeräten definiert sind. Dazu kommen Sensoren für Temperatur, Druck, Blutsauerstoff und Licht unter anderen. Diese Sensoren liefern Daten an spezifische Softwarefunktionen, die sie für genaue Zwecke bewerten. Dazu ist es auch besonders wichtig, dass medizinische Geräte vor unbefugtem Zugriff gesichert werden aber auch für autorisierte Konfiguration und Datenabruf zugänglich sind. Sie müssen die nötigen drahtlosen Kommunikationsstandarten unterstützen. Sie müssen zeitlich genau synchronisieren, GPS Ortsdaten senden können und oft sogar Motorsteuerung liefern.
Mit einer soliden Plattform anfangen
Die Entwicklung von Systemen mit solcher Verschiedenheit und Komplexität ganz von vorne anzufangen wäre natürlich eine mühselige Arbeit. Das MedicalOS-Paket von RoweBots bietet eine stabile und vielseitige Plattform mit einer großen Auswahl von unterstützten MCUs und Peripheriegeräten zusammen mit dem Unison RTOS, das auf die Bedürfnisse ganz kleiner Systeme zugeschnitten ist. Unison gründet sich auf dem POSIX-Standard und gebraucht Nano-Kernel-Technologie. Das bedeutet einen sehr kleinen Speicherbedarf von ungefähr 20K Flash und 8K RAM. Ein ganzes System, das aussieht wie eine sehr kleine Linux-Konfiguration, könnte in dem Bereich von 300K Flash und 70K RAM liegen—ohne Sicherheitsmodule. Mit Sicherheitsmodulen, wäre das eher 400K Flash und 100K RAM je nachdem welche Funktionen eingebaut sind—immer noch ein kleiner Speicherbedarf.
Wegen der großen Auswahl an medizinischen Geräten und ihren Unterstützungssystemen—zum Beispiel Gateways im Hause—unterstützt MedicalOS die ganze Reihe von Prozessoren und MCUs, die vom vollen Unison RTOS unterstützt wird. Das Unison-RTOS liefert ein volles POSIX-RTOS mit Datei-I/O, Socket-I/O und völlig kompatiblen Fehlercoden. Die RoweBots-Implementierung liefert ultra-kleine eingebettete Lösungen, die einen einzelprozess/multithreaded-Modell darstellen.
Noch ein Vorteil ist es, dass dieses kleine, modulare und leistungsfähige RTOS mit genau den richtigen Softwaremodulen ausgestattet werden kann. Module für Peripheriegeräte und drahtlose Verbindung bauen ein Fundament für ein echt kleines und leistungsfähiges tragbares Gerät.
Im MedicalOS-Packet befindet sich eine Auswahl von schon geprüften Softwaremodulen, die schnell und sicher integriert werden können, um die Bedürfnisse des Entwicklungsprojekts zu erfüllen. Dazu kommt noch eine Reihe von modernen und sicheren Netzwerkprotokollen, die sicheren Zugang für ferngesteuerte Konfiguration und Kontrolle liefern. Zum Beispiel, Secure Shell (SSH) bietet einen sicheren Kanal über ein ungesichertes Netzwerk, für eine Client-Server-Architektur, die mit dem Secure File Transfer Protokoll (SFTP) arbeitet.
eingebaute Sicherheit
Auf dem Gebiet von medizinischen Geräten ist es schwer, die Wichtigkeit der Sicherheit genügend zu betonen. Es gibt natürlich staatliche Regelungen, die das Privatleben von Patienten schützen. Aber diese Geräte können in einer Menge unterschiedlicher Netzwerkumgebungen gebraucht werden. Zu diesen gehören Internetverbindungen in Privathäusern, die sich mit Cloud-Servern und weiter zu Ärzten und Spezialisten—und noch weiter zu Krankenhausnetzwerken—verbinden. Kleine Geräte müssen in der Lage sein, sichere Verbindungen zu verhandeln, nicht nur um Daten zu schützen, sondern auch um sich gegen Hacking und unbefugten Zugang zu wehren.
Von äußerster Wichtigkeit für die Sicherheit in kleinen Geräten ist die Unison-Speicherverwaltung. Die POSIX-Kompatibilität mit Linux hängt in der RTOS-Welt meistens mit dem API zusammen. Hinzu kommt die Tatsache, dass viele Entwickler mit dem API vertraut sind und, dass es eine große Menge Open-Source-Code gibt, die frei zugänglich ist und die für Embedded Systems adaptiert werden kann. Ein sehr wichtiger Unterschied bei Unison—der aber „hinter den Kulissen“ steht—ist die Speicherverwaltung, die entwickelt wurde, um die Gefahren der dynamischen Ladung zu eliminieren. Dynamische Ladung kann allerdings für Flexibilität und Konfiguration sehr nützlich sein. Aber für Sicherheit kann sie eine echte Gefahr darstellen.
In der Linux-Welt kann Programmcode einfach in RAM geladen werden und dann unter Kontrolle des Betriebssystems laufen. Linux verlässt sich auf das Betriebssystem, zu verhindern, dass Benutzercode die Kontrolle nicht ergreift und nicht bestimmen kann, welche Programme gestartet werden. Aber solcher Schutz kann manchmal durchbrochen werden. Dasselbe gilt für viele RTOS-Implementierungen, deren Schutz auch durchbrochen werden kann, weil sie groß und komplex sind. Dann kann auch die kleinste Sicherheitslücke Zugang zum Speicher erlauben, wo ein Hacker spezifische Bits ändern kann, um den ganzen Sicherheitsmechanismus zu umgehen. Da die Malware vom Gerät laufen muss, muss die in den Speicher des Geräts geladen werden.
Obwohl Unison die API-Kompatibilität von Linux behalten hat—mit allen Vorteilen für den Entwickler—ist sein Speichermodell geändert worden, um einen höheren Sicherheitsgrad für Embedded-Geräte zu gewährleisten. Mit Unison läuft der Programmcode aus Flashspeicher. Das bedeutet, dass Code zuerst in den Flashspeicher geladen werden muss, bevor er überhaupt laufen kann. Und das ist viel schwieriger als das Laden in RAM. Bei Unison gibt es zwei starke Barrieren, die das Laden von unbefugtem Code verhindern. Das erste ist die Tatsache, dass flash-basierter Code ein einheitliches Code-Bild ist und wann es läuft, läuft es von eben dem Code-Bild, ohne dass Teile in RAM dynamisch geladen werden. RAM wird natürlich für die vorübergehende Speicherung von Variablen und Stacks gebraucht, aber alle Befehle laufen vom Flash.
Das bedeutet, dass kein externes Programm in den Speicher des Geräts geladen werden kann—auch unter Kontrolle des Betriebssystems nicht, denn der Code muss von Flash aus laufen. Das Flashprogrammbild kann nur dadurch geändert werden indem ein völlig neues Programmbild aufgeladen wird—vermutlich eins, in dem die Malware im Zusatz zu dem normalen Anwendungscode enthalten wird.
Die Unison Feld-Upgrade-Funktion fordert die Ladung des gesamten Softwarebilds—nicht nur zusätzlichen Funktionen, wie bei dynamischer Ladung der Fall ist. Eine Kopie der ganzen Flashanwendung zu bekommen ist für einen Hacker äußerst schwierig, wenn nicht unmöglich. Eine weitere Hürde ist die Tatsache, dass die Upgrade-Funktion ein Programm auf dem Gerät ist, das Verschlüsselung verwendet. Wenn das aufzuladende Programm verschlüsselt ist, kann es nur mit dem richtigen Schlüssel entschlüsselt werden. Dieser Schlüssel gehört dem Besitzer des Programms und des Geräts und wird getrennt vom Gerät aufbewahrt. Man kann also nicht an diesen Schlüssel kommen, indem man das Gerät hackt. Ein Hacker könnte also die Kennwort-Benutzername-Barriere durchbrechen und trotzdem nicht in der Lage sein, den Code für seine Zwecke zu ändern.
Im Zusatz zu dieser grundlegenden architektur-basierten Sicherheitsmaßnamen bietet Unison MedicalOS noch eine Reihe Sicherheitskomponente. Zu diesen gehören sichere Email oder sichere SMTP zusammen mit sicheren Webseiten oder HTTPS, um geschichtete Sicherheitsstrategien zu implementieren. Sichere Verwaltung—SNPM v3—sichert die Authentifizierung sowie die Übertragung von Daten zwischen Verwaltungsstation und SNMP-Agent. Ein sicherer Bootloader erfordert, dass die Dateien, die für Flash-Update herunterladen werden, verschlüsselt und geprüft werden, bevor sie endlich geladen werden. Es gibt auch ein „PowerSafe“ verschlüsseltes Dateiensystem. Sichere und zuverlässige drahtlose Kommunikation ist auch für medizinische Geräte unentbehrlich. MedicalOS unterstütz Bluetooth Classic und Smart-Smartready zusammen mit Wi-Fi und 6loWPAN mit 802.15.5 Radios. Weitere Funktionen für Grafik, Kamera- und Video-Integration geben dem Entwickler eine reiche Auswahl an Möglichkeiten für den Bau medizinischer Systeme.
Referenzbausatz erleichtert die Entwicklung
RoweBots bietet einen Referenzbausatz, der dem Entwickler hilft, ein System für Gesundheitsfürsorge zu Hause zu bauen und mit der Cloud zu verbinden. Im Zusatz zudem MedicalOS-Paket, kommt der Bausatz mit verschiedenen weiteren Elementen. Unter diesen sind ein drahtloser Router, ein Windows-Server und ein Android-Fon. Dazu kommen noch drei Bretter, die alle auf drei Varianten des ARM Cortex-M4 Prozessors basieren. Die drei Bretter sind der FRDMßK64F von Freescale (Abbildung 1a), der Tiva 129 von Texas Instruments (Abbildung 1b) und der STM3240G von STMicrosystems (Abbildung 1c).
1a
1b
1c
1: Entwickler von medizinischen Geräten habe Zugang zu einem Entwicklungsbausatz mit einer Wahl von drei Plattformbrettern: der FRDMßK64F von Freescale (a), der Tiva 129 von Texas Instruments (b) und der STM3240G von STMicrosystems (c). Diese Bretter zusammen mit einer breiten Auswahl von Sensoren und Peripheriegeräten bieten verschiedene Funktionen, um verschiedene Klassen von Geräten zu bauen.
Dieser Bausatz erlaubt dem Entwickler ein System mit MedicalOS-basierten Geräten zu konfigurieren, die an anderen stationären Systemen und weiter mit der Cloud verbunden sind. Alle drei Bretter verbinden über TCP/IP v4-v6 mit dem drahtlosen Router und weiter zur Cloud und Smartphone wie in Abbildung 2.
Der FRDM-K64F hat zum Beispiel einen Beschleunigungsmesser/Magnetmesser und dazu noch einen RGB LED an Bord. Der Tiva 129 und der STM3240G haben 320 x 240 Touchscreen-Anzeigen. Alle drei Bretter haben auch den I2C-Bus, womit man Sensoren anschließen kann. Zu den Sensoren in diesem Bausatz gehören:
- Der InvenSense MPU9150—ein Beschleunigungsmesser/Gyroskop mit 9 Achsen
- Der Intersil ISL29023 digitaler Lichtsensor
- Der Bosch BMP180 Druck/Temperatur-Sensor
- Der Senserion SHT21 Luftfeuchtigkeit/Temperatur-Sensor
- Der Texas Instruments TMP006 Infrarot-Temperatursensor, der Temperatur ohne Kontakt messen kann
Alle können auch Batteriedaten lesen.
Mit diesem Bausatz kann man die verschiedenen Komponente verbinden, um Daten- und Befehlstransport zu prüfen und sie dann als Plattform benutzen, um die Entwicklung von neuen und innovativen medizinischen Anwendungen zuversichtlich anzufangen.
Verbindung mit der Cloud
„Dinge,“ die mit dem Internet verbunden sind, haben den Zweck, Daten, zu sammeln und zu benutzen, um zu Ergebnissen zu kommen, die dann für Analyse benutzt werden oder um Entscheidungen zu treffen und Befehle an die Geräte zurückzusenden. Die Konnektivität, die in diesen IoT-Geräten eingebaut ist, hat eindeutig auch diesen Zweck. Das kann oft Millionen von verbundenen Geräten bedeuten, die alle Daten in die Cloud senden. Und diese Cloud ist eigentlich ein Server oder mehrere Server in Datenzentren, die Analyse und Managementanwendungen laufen und auch mit diesen Geräten kommunizieren und sie kontrollieren. Nicht jeder Kunde hat einen eigenen Server/Datenzentrum. Diese werden meistens als Dienstzentren betrieben. womit Kunden mit Hub-Software verbinden.
MedicalOS unterstützt die Microsoft Azure Cloud Computerdienst. Mit Azure können Entwickler Verwendungen und Dienste mit Hilfe einer globalen Microsoft Netzwerk von Datenzentren bauen und verwalten. Medizinische Geräte verbinden sich oft durch ein lokales oder privates Netzwerk an Randsysteme. Diese Randsysteme haben oft analytische Funktionen oder machen Entscheidungen. Sie bieten oft Zugang an Ärzte oder Krankenhäuser je nach den Bedürfnissen der Verwendung. Aber dies Randsysteme sind auch mit der Cloud verbunden, wie in dem Microsoft Azure-Beispiel in Abbildung 2.
Geräte verbinden sich drahtlos mit anderen Geräten oder mit einem Randserver mit dem Gebrauch von verschiedenen drahtlosen Protokollen wieWi-Fi, LoRa, 6LoRa oder anderen. Um dann weiter mit den Clouddiensten zu verbinden wird der Randserver mit Gebrauch von einem Protokoll wie MQTT, AMQT oder HTTPS über Internet IP verbinden. Anwendungen in den Cloudservern, die autorisierten Personen zugänglich sind, machen von diesen Daten Gebrauch, um die kleinen Geräte zu überwachen und kontrollieren. Die Möglichkeit, sich durch einen vorgefertigten Hub mit einer Reihe von Diensten—die abonniert werden können—privat und sicher zu verbinden ist ein großer Schritt in Richtung zur vollen Unterstützung einer wirkenden Verwendung. Lösungen wie Azure bieten auch eine freundliche Umgebung für die Entwicklung weiterer Anwendungen, die die Kapazität der vernetzten Geräte (Abbildung 2).
Figure 2: Microsoft Azure bietet eine vorgefertigte Cloud-Umwelt und Konnektivität für IoT-Geräte. Hier können sie ihre Daten senden und überwacht werden. Sie können auch von authorisierten Personen kontrolliert warden und Befehle bekommen.
Entwicklungswerkzeuge
Die Einstellung Unisons zur Frage der Entwicklungswerkzeuge ist, eine Umgebung zu schaffen, die preisgünstig aber noch vielseitig und erweiterbar ist. Sie soll dem Entwickler die Möglichkeit bieten, genau die richtige Umgebung für seine Projekte zusammenzustellen. Das hießt eine starke Betonung der Eclipse-kompatibelen „integrated development environments“ (IDEs). Diese sind für die von Unison unterstützten Prozessoren von verschiedenen Herstellern erhältlich. Da sie Eclipse-kompatibel sind, passen sie leicht in die von Unison angebotenen Remedy IDE ein, die schon auf Eclipse basiert ist. Diese gibt dem Entwickler am Anfang einen Editor, eine Compilerkette und einen Debugger. Dazu passen noch alle Werkzeuge von anderen IDE-Herstellern leicht hinein.
RoweBots bietet auch den GNU C/C++ Compiler für alle unterstützten Prozessoren an. Embedded GNU C/C++ Entwickler tendieren seit einiger Zeit in Richtung GNU C/C++, da er für eine große Wahl von Prozessoren als zuverlässig und kostengünstig bekannt ist. Die modulare Art von Eclipse IDE erleichtert es dem Entwickler, Eclipse-kompatible Werkzeuge nach Wunsch auszutauschen.
Zusätzlich werden noch zwei wichtige Werkzeuge mit Unison RTOS auch kostenlos geliefert. Diese sind Remedy RTOS Viewer und Remedy RED Analyzer, die für die Entwicklung mit Unison spezifisch gebaut wurden. Der Remedy RTOS Viewer ist im IDE integriert, um die Werkzeugpakete von Keil, Mentor Graphics, Texas Instruments und Microsemi, unter anderen, zu unterstützen. Die Integration im IDE ermöglicht die Beschauung von allen registrierten Objekten und Kernelstrukturen im Unison Raum eischließlich Semaphore, Nachrichtenwarteschlangen und Mutexes sowie Threads und ihren Status. Dazu kommen noch Stack Nutzung und Speicherpool-Status. Aktualisierungen passieren automatisch jedes Mal, wann ein Breakpoint getroffen wird.
Der Remedy RED Analyzer bringt drei Arten von Analyse: Remote Control (Fernsteuern), um Zielvariablen einzustellen und dynamische Ereignisablaufverfolgung zu kontrollieren; Ereignis—zeitbasierte Auslösung und Anzeige; und Datensammelung, Übertragung und Anzeige. Der Gebrauch von diesen Funktionen ermöglicht es, dem Entwickler den Zeitablauf und Resourceverbrauch innerhalb des Unison Betriebssystems genau zu visualisieren und für die Bedürfnisse der Anwendung präzise einzustellen. Remedy RED besteht aus einem host-basierten Bildanzeiger und einem Fernsteuer-Server und Datenlogger auf dem Zielsystem (Abbildung 3). Die gesammelten Daten werden zum Anzeiger übertragen, damit der Entwickler sie aus verschiedene Perspektiven beschauen und analysieren kann. Er kann Auslösungspunkte und Datensammlungsoptionen wählen, um auf spezifische Probleme genau zu konzentrieren.
3: Der Remedy RED Analyzer gibt dem Entwickler volle Einsicht in das Timing, Resourcenverbrauch und Verhalten des Unison RTOS.
Ein Beispiel für den Gebrauch des Remedy RED Analyzers ist die Analyse von komplizierten Timing Verhältnisse. Zum Beispiel—Es kann passieren, dass ein System mit einer Vielfalt an verschiedenen I/O (allerdings selten) eine Kondition begegnen kann, das zu einem Systemzusammenbruch führt. Der Zusammenbruch scheint zufällig und Datensammlung ist schwierig. Mit dem Remedy RED aber kann man das Problem verfolgen und eine Diagnose machen, indem man ein Rückverfolgung und ein Auslöseereignis auf den verdächtigten I/O aufstellt. Man kann damit die Konditionen sammeln, die zum Zusammenbruch führten. Durch die Analyse der daten kann man dann auf die Spuren des Versagens kommen. Der Entwickler kann auch die Datenbreite erweitern, um eine komplette Analyse und Lösung für das Problem zu finden.
Noch ein wichtiges Werkzeug, das mit Unison geliefert wird, ist der Remedy Bootloader. Der Bootloader ermöglicht es, ein neues Programm ins Zielsystem zu laden. Das ist während der Entwicklung sicher wichtig aber auch im Felde, da das Laden von Upgraden auch unter Fernsteuerung erfolgen kann. Der Bootloader hat auch eine Verschlüsselung/Enschlüsselungsfunktion, die für die Sicherheit bei ferngesteuerten Upgrades wichtig ist. Die Reboot Phase kopiert das Programm in die Flashspeicher und übergibt dann die Kontrolle an das neue Programm. Sollte die Ladung des Upgrades versagen, dann fällt das System auf das frühere Programm zurück. Dieses Verfahren sichert, dass Vor-Ort-Kundendienst vermieden wird.
Der Bau eines Systems auf einer soliden Plattform beginnt mit dem Unison RTOS, das selber mager (lean) ist. Das heißt, es wird auf Standarten wie der POSIX API gebaut, um austauschbare Module, Protokolle und Gerätetreiber zu haben. Das macht es auch anpassbar (adaptable), damit Anwendungen leicht verbessert, auf andere Hardware übertragen und für Kundenwünsche adaptiert werden können. Es bringt mit sich eine reiche Zahl von Sicherheitsfunktionen, die ganz am Anfang eingebaut werden können. Es ist auch möglich, Zuverlässigkeit einzubauen. Dank Determinismus und Nullboottime kann ein System schnell genug reagieren, um auf eine gefährliche Situation zu reagieren. Es kann sofort halten und zu einem sicheren Status zurückgebracht oder auf eine Notaktion dirigiert werden.
Unison liefert auch Vollständigkeit und Konnektivität. Es bietet eine große Reihe von drahtlosen und anderen Kommunikationsmodulen; es unterstützt Speicher, Kamera, Anzeige, Berührungssensoren und andere Sensorsysteme zusammen mit der Universalkonnektivität über USB. Unison bietet auch Zugang zum Cloud. Eine breite Gruppe von Protokollen steht bereit, auch auf der Cloudseite, leicht und sicher Daten zu übertragen und Befehle auszuführen. Entwickler brauchen die neuesten Werkzeuge und Komponente, um mit dem raschen Fortschritt im Internet of Things Schritt zu halten. In der Welt von Unison RTOS bedeutet das die Fähigkeit mit anderen Spitzentechnologien wie Microsoft Azure arbeiten zu können und auch die Möglichkeit, die neuesten Werkzeuge und IDEs anzuwenden.
Unison MedicalOS geht vom soliden Unison-RTOS-Plattform aus und bringt eine zuverlässige Anzahl von günstigen Eigenschaften mit sich. Diese werden dann auf die Anforderungen der tragbaren Technik gerichtet und raffiniert. Die Kernkomponente des Unison RTOS, ihre drahtlosen Protokolle, die fertige Bereitschaft einer reichen Zahl von Sensoren und Peripheriegeräten, winzige Grafikpakete, Android Konnektivität, Energieverwaltung, eine breite Auswahl von MCUs und mehr—das alles gibt dem Entwickler die Mittel in die Hand, vom ersten Tag an, in sein Projekt echte Wert einzubauen.