Softwarestrategien für den zuverlässigen Betrieb moderner IoT-Geräte

Damit die Geräte im IoT sicher und zuverlässig funktionieren, ist eine solide Software-Architektur unerlässlich.Mentor Graphics

Die IoT-Technologie (Internet of Things) erstreckt sich immer weiter in eine Vielzahl von Industriebereichen. Weil damit auch die Abhängigkeit von diesen vernetzten Geräten und deren Informationen steigt, spielen Faktoren wie Betriebszeit und Zuverlässigkeit eine wichtige Rolle, sowohl für den Erfolg des einzelnen Geräts als auch des größeren IoT-Ökosystems. Ein intelligentes Gerät im Haushalt, ein Remote-Gerät in der Industrie und eine Infotainment-Head-Unit im Auto muss zuverlässig arbeiten und eine robuste Konnektivität besitzen.

Ein intelligentes IoT-Haushaltsgerät könnte über eine attraktive Benutzeroberfläche verfügen, die eine beliebige Anzahl von Befehlen verarbeitet. Ein derartiges Gerät kann von einem Smartphone oder Tablet ferngesteuert werden und mit dem Stromnetz kommunizieren, um seine Aktivitäten in die Nebenzeit zu verlegen, wenn die Strompreise niedriger sind. Industrielle Systeme stellen noch strengere Echtzeit-Steuerungsanforderungen und es muss gewährleistet sein, dass die Echtzeitsteuerung und andere wichtige Tätigkeiten unabhängig von der Funktion auf höherer Ebene ablaufen.

Die Automobilindustrie investiert in das vernetzte Auto, sei es für Telematik-Aufgaben oder damit der Fahrer zusätzliche Apps in sein Infotainment-Systeme laden kann. Um sicherzustellen, dass IVI-Systeme (In-Vehicle Infotainment) zuverlässig arbeiten, führen die Automobilhersteller sehr viele Tests durch. App-Downloads dürfen zum Beispiel wichtige Funktionen eines IVI-Systems wie die Videoübertragung einer Rückfahrkamera nicht stören. In diesem Szenario ist Android eine praktikable Option für die Apps-Umgebung, während das Kern-IVI-System auf einer Linux-Plattform basieren kann. Im industriellen Umfeld umfasst ein ähnliches Szenario beispielsweise ein Echtzeit-Betriebssystem (Real-Time Operating System, RTOS) für die wichtigsten Echtzeit-Steuerfunktionen und Linux als Allzweck-Betriebssystem, das die Benutzeroberfläche liefert und die Datenkommunikation überwacht.

Bild 1: Durch ein Prozessmodell lassen sich die Steuerungsaufgaben von der Konnektivität und anderen Aufgaben sauber trennen. Damit sind auch Remote-Updates unkritisch.Mentor Graphics

Memory-Management-Unit von komplexen SoCs

Einer der Schlüssel für den Aufbau eines zuverlässigen IoT-Geräts ist die Integration eines voll ausgestatteten Echtzeitbetriebssystems, das in der Regel ein isoliertes Prozessmodell enthält. Das Nucleus RTOS von Mentor Graphics verfügt über eine solche Fähigkeit und bietet Entwicklern die Möglichkeit, mithilfe der Memory Management Unit (MMU), die auf vielen System-on-Chips (SoC) verfügbar ist, Code-Module zu isolieren und zu schützen. Bild 1 zeigt, wie Echtzeit-Steuerungsaufgaben den geschützten Speicherbereich des Kernels gemeinsam nutzen, während sich die anderen Software-Tasks in ihren eigenen voneinander getrennten, geschützten Speicherbereichen befinden. Die Funktionen für Konnektivität und Remote-Update nutzen die gleichen Bereiche, während das UI und sonstige Applikations-Tasks anderen isolierten Bereichen zugewiesen werden. Dieser Ansatz zur Trennung der Subsysteme schützt Funktionen im Konnektivitäts- oder Benutzeroberflächensubsystem davor, den Kernel oder Echtzeit-Steuerungsaufgaben zu korrumpieren.

Bild 2: Das Prozessmodell trennt kritische Bereiche innerhalb eines Echtzeitbetriebssystems.Mentor Graphics

Einer der Vorteile eines RTOS im Vergleich zu einem Allzweck-Betriebssystem ist die Echtzeit-Natur seines Kernels. Ein RTOS bietet hartes Echtzeit-Scheduling mit garantierten Laufzeiten für Tasks mit hoher Priorität. Ein Prozessmodell-fähiges RTOS bewahrt deterministisches Echtzeit-Scheduling, auch wenn man einen Speicherschutz verwendet. Der Speicherschutz verändert weder die Priorität der Aufgaben noch die Reaktionsfähigkeit des Systems. Bild 2 zeigt, dass die Benutzeranwendung (Task 7) und die Remote-Update-Task, obwohl sie sich in verschiedenen, isolierten Speicherbereichen befinden, mit der gleichen Prioritätsstufe ablaufen können. Steuerungs- und Konnektivitäts-Tasks werden dagegen mit einer höheren Priorität ausgeführt. In der geschützten RTOS-Umgebung kann der Entwickler die Prioritäten der Aufgaben individuell einstellen, ohne dass er sie in einer gemeinsamen Speicherregion kombinieren müsste.

Ein RTOS, das auf einem Prozessmodell basiert, erlaubt den Prozessmodulen (eine Sammlung aus Tasks oder Bibliotheksfunktionen innerhalb eines gemeinsamen isolierten Speicherbereichs) auch, dass sie während des Systembetriebs dynamisch geladen und entladen werden. Neben der offensichtlichen Möglichkeit eines System-Updates kann der Entwickler ein Gerät für verschiedene Betriebsarten dynamisch neu konfigurieren und zwischen verschiedenen Konfigurationen der Task-Isolierung und Priorität hin und her wechseln.

Multicore-Architekturen mit mehreren Betriebssystemen

Viele moderne Embedded-Geräte verwenden Mehrkern-Prozessoren, vor allem wegen ihrer Rechenleistung und den Konnektivitätsoptionen. Mit diesen Prozessoren ist es praktikabel und sicher, mehrere Betriebssysteme gleichzeitig zu verwenden: Eines ist zum Beispiel für die Konnektivität und das UI zuständig, während ein anderes die ordnungsgemäße Ausführung von wichtigeren Funktionen besonders zuverlässig erledigt. Selbst in Anwendungen, bei denen die Sicherheit sehr wichtig ist, erwarten die Verbraucher heute ein User-Interface wie sie es vom Smartphone oder Tablet kennen.

Früher erreichten Entwickler die Sicherheit und Zuverlässigkeit durch physikalische Trennung. Dies geschah mit mehreren getrennten Prozessoren auf derselben oder verschiedenen Platinen und gewährleistete ein robustes Design. Bei den heutigen konsolidierten Embedded-Systemen empfiehlt sich die Verwendung mehrerer Betriebssysteme und eines Type-1-Hypervisors. Der Hypervisor trennt und virtualisiert die Geräteressourcen und gewährleistet, dass wichtige Fahrzeugfunktionen eine höhere Priorität als vernetzte Anwendungen erhalten.

Bild 3: Trennung vernetzter Apps in einem Gastbetriebssystem mit einem Type-1-Hypervisor.Mentor Graphics

Bild 3 zeigt den Mentor Embedded Hypervisor in einem Fahrzeug-Infotainment-System, wo die Funktionalität der vernetzen Applikationen in Android implementiert ist und der Rest des IVI-Systems auf Linux basiert. Ein Hypervisor geht aber über diese einfache Trennung hinaus. Er bietet auch einen Mechanismus, um den Zugriff von Peripheriekomponenten auf bestimmte Anwendungsbereiche einzuschränken. Im Falle eines IVI-Systems kann man den Zugriff auf den CAN-Bus des Fahrzeugs beschränken: Zum Beispiel soll nur das Infotainment-System Zugriff auf CAN-Daten erhalten, während die vernetzten Apps in Android nur per Interprozesskommunikation (IPC) mit dem Linux-basierten Fahrzeug-Infotainment-Applikationen kommunizieren dürfen, nicht aber direkt mit dem CAN-Bus. Gleichzeitig sollen sowohl Linux als auch Android Zugriff auf die lokale SD-Card mit Multimedia-Daten haben. Bild 4 veranschaulicht, wie ein Hypervisor Peripheriekomponenten direkt abbildet und paravirtualisiert. Dies gestattet es dem Entwickler, den Zugriff auf den CAN-Bus zu beschränken und andere Ressourcen wie die SD-Card gemeinsam zu nutzen.

Bild 4: Mit einem Hypervisor können die voneinander isolierten Komponenten auf sichere Weise Peripheriekomponenten gemeinsam nutzen.Mentor Graphics

Bisher wurden zwei mögliche Ansätze für das Design von IoT-Systemen dargestellt, die Verwendung eines RTOS und eines Type-1-Hypervisor. Es gibt viele verschiedene Permutationen und der ideale Ansatz hängt vom konkreten Gerät ab. Alle vernetzten Systeme profitieren jedoch von Tests, die das korrekte Arbeiten im Feld sicherstellen. Automatisierte Sicherheitstests zum Durchführen von Stresstests an vernetzten Geräten sind nur ein Beispiel, um Ausfälle im Protokoll-Stack oder in Prozesssteuerungsfunktionen festzustellen. Zudem lässt sich das Funktionieren eines Gerätes mithilfe von simulierten Angriffen ermitteln. Weitere notwendige Tests sind das Senden von ungültigen oder fragmentierten Paketen sowie die Ausführung von Test-Frameworks, die bekannte Schwachstellen im Software-Stack ausnutzen. Diese Tests können die Robustheit der vernetzen IoT-Geräte während des Betriebs erhöhen.

Updates ohne Ärger

Benutzer von Mobilgeräten sind damit vertraut, dass sie ihr Gerät häufig aktualisieren müssen, um Fehler zu patchen, Sicherheitsupdates durchzuführen oder die Geräte-Performance zu erhöhen. All dies wird mühelos „über die Luft“ erreicht. IoT-Geräte müssen dieselben Fähigkeiten bieten. Sowohl das Prozessmodell-basierte RTOS als auch die Verwendung eines Type-1-Hypervisors erleichtern ein Design, das sich auf sichere Weise über die Luft aktualisiert. Durch die Abtrennung des Anwendungs-Subsystems, das dynamisch geladen und entladen werden kann, ermöglichen beide Ansätze im Laufe der Zeit das Updaten spezieller Subsysteme, das Beheben von Fehlern oder das Lösen von Zuverlässigkeitsproblemen während des Einsatzes im Feld.

Die Bandbreite heutiger IoT-Geräte und neue Funktionsanforderungen zwingen Entwickler, Code aus verschiedenen Quellen wie eigenen, kommerziellen und Open-Source-Code zu integrieren. Das Mischen dieser Quellen erhöht das Risiko negativer Auswirkungen auf die Reaktionsfähigkeit und Zuverlässigkeit eines vernetzten IoT-Gerätes. Doch es gibt eine Reihe von Optionen, um die Konnektivität von den Steuerfunktionen zu trennen. Dazu gehören zum Beispiel die Verwendung eines Light-Weight-Prozessmodells mit einem Echtzeitbetriebssystem und der Einsatz eines Hypervisors zur Abtrennung und zur gemeinsamen Nutzung sicherer Ressourcen zwischen Anwendungs-Subsystemen und Designs mit mehreren Betriebssystemen. Der Einsatz dieser Techniken gewährleistet, dass das nächste IoT-Gerät auf dem höchst möglichen Level für optimale Gerätekonnektivität und Zuverlässigkeit arbeitet.

(lei)