Grössere IoT-Geräte verwenden meist Linux als Grundlage, da es bereits viel bietet (Boards, Kernel, Treiber, usw.). Trotzdem ist es ein weiter Weg, damit ein Produkt zu bauen. Denn die Geräte sind im Kern letztlich immer noch ein Embedded-System, an welches die üblichen Anforderungen gestellt werden (z.B. selbständig, zuverlässig und wartungsarm). Gleichzeitig kommt man an automatischen Software-Updates kaum mehr vorbei. Fertige Plattformen wie Ubuntu Core oder Azure Sphere können einem dabei viel Arbeit abnehmen. Während sich der Entwickler auf die Applikation konzentriert, kümmert sich der Hersteller um die Wartung der Plattform und das Stopfen von Sicherheitslücken. Nachfolgend werden die Vor- und Nachteile einer solchen Plattform gegenüber einem Eigenbau aufgezeigt.
Kleinere und grössere Systeme
Die Domäne der Embedded-Systeme ist ein weites Feld. Es reicht vom kleinen stromsparenden Microcontroller für einfache Sensorik-Anwendungen bis hin zu einem leistungsfähigen System-on-Chip (SoC) mit einer desktopähnlichen Benutzeroberfläche.
Abbildung 1: Grössenordnungen von Embedded-Systemen
Dieser Beitrag fokussiert sich auf grössere Systeme. Solche bauen fast immer auf Linux auf. Das Betriebssystem Linux wurde zwar ursprünglich nicht für den Embedded-Bereich konzipiert, ist aber trotzdem durch seine Offenheit, Hardwareunterstützung und sein reichhaltiges Ökosystem zur ersten Wahl geworden. Wem aber die Aufstartzeit zu lange dauert oder wer grossen Wert auf Stromsparfunktionen legt, sollte sich eher an den mittleren oder kleineren Systemen orientieren.
Erwartungen an ein Embedded-System
Im Alltag sind wir überall von Embedded-Systemen umgeben und denken nicht weiter über deren Anforderungen nach. Trotzdem erwarten wir selbstverständlich, dass diese Geräte auf Anhieb funktionieren und wartungsfrei sind, d.h. sie sollen sich automatisch von Fehlern erholen. Zudem sollen sie robust gegen Stromausfall sein und der Benutzer soll sie nicht “kaputtkonfigurieren” können. Im Zeitalter vom Internet of Things sollte das Gerät schliesslich auch noch mit der Cloud verbunden sein und sich darüber selbst aktualisieren können, um bekannt gewordene Sicherheitslücken zu beheben.
Am Ende sind dies eine Menge von Anforderungen, die bei einem Standard-Linux fehlen und zuerst einmal implementiert werden müssen. Dafür sind Anpassungen auf mehreren Ebenen nötig. Nur schon die eigene Umsetzung eines robusten automatischen Updates kann bereits einen beträchtlichen Aufwand bedeuten. Die laufende Wartung der Plattform, um zeitnah Security-Patches zu integrieren, ist ebenfalls nicht zu unterschätzen.
Abbildung 2: Nötige Anpassungen an Linux
Fertige Plattformen
Als Geräteentwickler wäre es sinnvoller, sich auf die Applikation konzentrieren zu können, statt mit einer eigenen Plattform das Rad neu zu erfinden. Zum Glück gibt es hier Lösungen von mehreren Herstellern:
Google bot ursprünglich mit Android Things eine abgespeckte Embedded-Variante seines Smartphone-Betriebssystems an, welches leider auf Eis gelegt wurde. Canonical hat mit Ubuntu Core schon seit einigen Jahren eine Variante seiner bekannten Linux-Distribution für den Embedded-Bereich im Angebot. Auch Microsoft mischt hier in jüngerer Zeit mit der Azure Sphere Plattform kräftig mit. Ursprünglich hat Microsoft mit Windows IoT Core bereits eine Nicht-Linux-Plattform für diesen Anwendungsbereich angeboten, was aber bisher kaum erfolgreich war.
Nachfolgend werden Ubuntu Core und Azure Sphere näher vorgestellt.
Ubuntu Core
Ubuntu Core ist als Referenzimplementation für mehrere Boards verfügbar, u.a. Raspberry Pi. Die Plattform ist rund um das Deployment von Applikations-Containern (“Snaps” genannt) aufgebaut, welche untereinander und gegenüber dem Kern-Betriebssystem streng isoliert sind. Die Verteilung der Snaps geschieht über einen App-Store von Canonical. Sogar das Betriebssystem liegt in Snaps auf mehreren Ebenen vor und kann sich somit selbst atomar aktualisieren.
Abbildung 3: Aufbau der Ubuntu Core Plattform in Form von Snaps
Die Isolation zwischen den Containern geschieht mit Bordmitteln von Linux, wie z.B. AppArmor und cgroups. Snaps sind signiert und beinhalten ein Read-Only-Dateisystem, das direkt gemountet wird. Dies alles führt dazu, dass die Applikationen mehrheitlich eine gewohnte Linux-Umgebung vorfinden und deshalb nur wenige Anpassungen an bestehender Software nötig sind, um daraus Snaps zu erzeugen. Das dabei verwendete Werkzeug Snapcraft unterstützt die Build-Toolchain (z.B. Make, CMake) von gängigen Sprachen wie C/C++, Java oder Python. Canonical bietet sogar automatische Snap-Builds direkt aus einem GitHub-Repository an.
Snaps können für mehrere Hardware-Architekturen gebaut werden, u.a. auch für ein normales Desktop-Ubuntu (was für Prototypen und Tests nützlich ist). Über den Store von Canonical werden neue Snap-Releases automatisch auf die Geräte verteilt, wobei verschiedene Kanäle wie “beta”, “candidate” oder “stable” zur Verfügung stehen.
Das Geschäftsmodell von Canonical besteht aus dem kommerziellen Support für die
Software-Entwicklung wie etwa der Portierung von Ubuntu Core auf ein neues Board. Für eine eigene Hardware-Plattform wird zudem auch die Verwendung eines privaten App-Stores nötig, was ebenfalls etwas kostet.
Azure Sphere
Seit Februar 2020 ist mit Azure Sphere auch von Microsoft eine ähnliche IoT-Plattform allgemein verfügbar. Deren Kern ist der System-on-Chip (SoC) namens MT3620, der von Microsoft mitentwickelt wurde und der bereits viele hardwarebasierte Security-Funktionen enthält. Der starke Fokus auf die Security geht sogar so weit, dass man als Entwickler den stark abgespeckten Linux-Kernel im Azure Sphere OS eigentlich nie zu Gesicht bekommt, da kein direkter Zugriff auf den Kernel oder auf ein Dateisystem möglich ist.
Abbildung 4: Aufbau der Azure Sphere Plattform, verteilt auf mehrere Cores
Auf dem Hauptprozessor interagiert die Applikation mit der Plattform ausschliesslich über definierte Schnittstellen, etwa einer reduzierten C-Standard-Bibliothek oder weiteren Bibliotheken, welche den Zugriff auf die Cloud oder die Peripherie (GPIO, I2C, SPI, usw.) implementieren. Als besonderes Goodie besitzt der MT3620 noch zwei weitere Cortex-M4F-Kerne, die unabhängig vom Azure Sphere OS frei benutzbar sind und sich gut für die Ausführung von Echtzeitaufgaben mit direktem Hardwarezugriff eignen. Falls nötig kann darauf ein beliebiges Echtzeitbetriebssystem zum Einsatz kommen, wobei Microsoft hier mit dem Azure RTOS (ehemals ThreadX) ebenfalls eine Lösung anbietet.
Im Kauf des Chips ist bereits die Lizenz für das Betriebssystem und die Nutzung der Infrastruktur für automatische Updates enthalten.
Gemeinsamkeiten
Beide Plattformen streichen das einfache und automatische Update des Betriebssystems heraus, garantiert für 10 Jahre. Die Wartung des Betriebssystems durch den Hersteller erspart dem Entwickler zwar viel Wartungsaufwand, erfordert aber auch eine starke Isolation zwischen Betriebssystem und Applikation (damit diese nichts vom Update wissen muss). Dabei können die Zugriffsrechte der Applikation auf die Systemressourcen und die Peripherie feingranular eingestellt werden.
Abgesehen davon gibt es nur wenig Gemeinsamkeiten. Ubuntu Core ist eher für grössere Systeme gedacht, welche auf gängige Funktionen und Bibliotheken von Linux zurückgreifen wollen. Bei Azure Sphere ist das Linux-System hingegen so stark abgespeckt und auf Sparsamkeit getrimmt, dass es sich eher wie eine kleinere Microcontroller-basierte Plattform anfühlt.
Unterschiedliche Zielsetzungen
Aus der jeweiligen Architektur lassen sich die unterschiedlichen Zielsetzungen der Plattformen ablesen. Mit Azure Sphere adressiert Microsoft den wichtigsten Pferdefuss des IoT, nämlich die Security. Deshalb wurde gleich eine eigene Hardware-Architektur entworfen, die das berücksichtigt. Um das Vertrauen in die Plattform nicht zu untergraben, hat der Entwickler keine volle Kontrolle über alle Security-Funktionen. Die Verwaltung der Geräte übernimmt natürlich die Azure Cloud und auch durch die vorinstallierte Azure IoT SDK Bibliothek ergibt sich eine Präferenz. Der Applikation ist es aber freigestellt, sich mit einer anderen Cloud zu verbinden.
Bei Ubuntu Core steht das robuste, atomare Deployment mehrerer Apps und die Isolation dazwischen im Vordergrund. Die Softwareinstallation auf den Geräten befindet sich immer in einem klar definierten Zustand. Eine weitergehende Wartung einzelner Geräte ist nicht mehr nötig. Die Plattform gibt kaum vor, ob und mit welcher Cloud sich die Applikation verbinden soll. Ebenso bestehen viele Freiheiten in der Applikationsentwicklung (Sprache, Bibliotheken, usw.) und eine Portierung von Ubuntu Core auf andere Prozessoren und Boards ist grundsätzlich möglich (Unterstützung durch den kommerziellen Support von Canonical ist wohl ratsam).
Damit werden sich Linux-Cracks bei Ubuntu Core durch die grösseren Freiheiten wohler fühlen, während man bei Azure Sphere durch die Visual Studio Integration näher am Microsoft-Universum bleibt.
Die Plattformen in der Praxis
Bei genauerer Betrachtung ist keine der beiden Plattformen kostenlos, was je nach Umfeld eine Einstiegshürde sein kann. Zudem macht sich der Applikationsentwickler von einem Hersteller abhängig und muss sich auf eine restriktive Umgebung mit wenig Freiheiten einstellen können. Es ist auch kein eigener Update-Server möglich. Dies alles kann die Akzeptanz noch schwieriger machen.
Wer den Mut hat, sich darauf einzulassen, kann in kurzer Zeit ein IoT-Produkt realisieren, welches die gängigen Erwartungen an ein Embedded-System von Anfang an erfüllt. In realen Projekten hat sich zum Beispiel gezeigt, dass die Entwickler den Aufwand für einen eigenen Update-Mechanismus unterschätzen, z.B. bei der Integration von Komponenten wie SWUpdate, RAUC, hawkBit oder Mender. Ebenso wird meist der Aufwand nicht eingeplant, die Applikation regelmässig auf einen neueren Linuxkernel zu portieren.
Bei Ubuntu Core bietet die Plattform genug Anpassungsmöglichkeiten, z.B. bei der Zugriffsberechtigung aus einer Applikation auf ein neues USB-Peripheriegerät. Ebenso positiv fiel die automatische Benachrichtigung durch Canonical auf, dass in der eigenen veröffentlichten Applikation (Snap) veraltete Bibliotheken mit Sicherheitslücken entdeckt wurden.
Bei Azure Sphere konnte dafür eine Beispielapplikation dank der guten Dokumentation schnell zum Laufen gebracht werden. Weniger gut gefiel der fest vorgegebene SoC, dem gewisse Peripherien wie etwa USB, CAN oder Ethernet fehlen. Dadurch kommt die Plattform eventuell für das eigene Produkt nicht mehr in Frage. Dies gilt besonders dann, wenn eine spezifische Eigenschaft gefragt ist (Low-Power, Rechenleistung, Speichergrösse).
Ausblick
Microsoft hat Azure Sphere zu Beginn des Jahres 2020 noch einmal stärker ins Rampenlicht gerückt. Leider gibt es neben dem MT3620 immer noch keine Unterstützung für einen alternativen SoC. Chips anderer Hersteller (NXP und Qualcomm) sind erst angekündigt. Wenn es hier einmal mehr Wahlmöglichkeiten geben sollte, dann könnte Microsoft mit seiner Marktmacht in diesem Segment eine führende Rolle übernehmen. Ob es auch mal grössere Systeme (in der Klasse eines Raspberry Pi) mit Azure Sphere geben wird bleibt unklar.
Im Vergleich dazu ist es rund um Ubuntu Core etwas stiller. Ein grosser Vorteil ist, dass Canonical das Konzept der Snaps auch auf anderen Systemen im Server- oder Desktopbereich forciert und sogar auf andere Linux-Distributionen portiert hat. Dadurch ist die Entwicklung von Snaps salonfähiger geworden und die Hürde zur Applikationsentwicklung für Ubuntu Core ist weniger hoch.
Wie sich beide Plattformen in der Zukunft entwickeln und ob es noch Alternativen geben wird ist schwer abzuschätzen. Es ist aber damit zu rechnen, dass fertige Plattformen in diesem Segment immer wichtiger werden.
