Mobile-Menu

Internet der Dinge Sicherstellung des zuverlässigen Betriebs vernetzter IoT-Geräte

Autor / Redakteur: Andrew Caples * / Franz Graser

Konnektivität und Zuverlässigkeit lauten zwei der wichtigsten Anforderungen an Geräte, die mit dem IoT vernetzt sind. Echtzeitbetriebssysteme (RTOS) tragen zur sicheren Trennung wichtiger System-Tasks bei.

Anbieter zum Thema

Moxa Europe GmbH
TXOne Networks
Bild 1: Trennung der Steuerungsaufgaben von der Konnektivität und den Remote-Updates durch ein Prozessmodell
Bild 1: Trennung der Steuerungsaufgaben von der Konnektivität und den Remote-Updates durch ein Prozessmodell
(Quelle: Mentor Graphics)

Das Internet der Dinge (Internet of Things – IoT) umfasst Anwendungen von sogenannten Wearables über Smart-Meter und intelligente Haushaltsgeräte bis hin zu Autos. Faktoren wie Betriebszeit und Zuverlässigkeit spielen bei diesen Geräten eine zentrale Rolle. Ein intelligentes Haushaltsgerät und eine Infotainment-Head-Unit im Automobil stehen für eine Klasse von IoT-Systemen, die sowohl Konnektivität als auch zuverlässige Ausführung erfordern.

Ein Echtzeit-Betriebssystem (RTOS) mit einem isolierten Prozessmodell wie Nucleus von Mentor Graphics erlaubt es Code-Module mit Hilfe der Memory Management Unit (MMU), die auf vielen System-on-Chips (SoC) verfügbar ist, zu isolieren und zu schützen. Bild 1 zeigt, wie Echtzeit-Steuerungsaufgaben den geschützten Speicherbereich gemeinsam nutzen, während sich die anderen Software-Tasks in ihren voneinander getrennten und geschützten Speicherbereichen befinden.

Die Funktionen für Konnektivität und ferngesteuerte Aktualisierung nutzen die gleichen Bereiche, während die UI und sonstige Applikations-Tasks anderen isolierten Bereichen zugewiesen werden. Dieser Ansatz zur Isolierung der Subsysteme für Anwendungen schützt Funktionen im Konnektivitäts- oder Benutzeroberflächen-Subsystem davor, den Kernel oder Echtzeit-Steuerungsaufgaben zu korrumpieren.

Echtzeit-Kernel garantiert Laufzeiten für wichtige Tasks

Einer der Vorteile eines RTOS ist die Echtzeit-Natur des Kernels. Ein RTOS bietet hartes Echtzeit-Scheduling mit garantierten Laufzeiten für Tasks mit hoher Priorität. Ein Prozessmodell-fähiges RTOS bewahrt beim Hinzufügen des Speicherschutzes deterministisches Echtzeit-Scheduling. 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 ausgeführt werden können. Steuerungs- und Konnektivitäts-Tasks werden dagegen mit einer höheren Priorität ausgeführt. Dies ist eine erhebliche Abweichung von der Art und Weise, wie Prozesse bei einem Allzweck-Betriebssystem implementiert sind. In der geschützten RTOS-Umgebung kann der Entwickler die Prioritäten der Aufgaben individuell einstellen, ohne dass sie in einer gemeinsamen Speicherregion kombiniert werden müssen.

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

Die Mehrkern-Prozessoren in heutigen Embedded-Geräten machen die Konsolidierung mehrerer Betriebssysteme zu einem praktikablen und sicheren Ansatz für die Sicherstellung der Konnektivität sowie der ordnungsgemäßen Ausführung von wichtigeren Funktionen. Selbst im Automobil, wo die Sicherheit extrem wichtig ist, erwarten die Verbraucher, dass ein IVI-System Zugriff auf Applikationen bietet, die auf Smartphones und Tablets zu finden sind.

Bild 2: Das Prozessmodell trennt kritische Bereiche innerhalb eines Echtzeitbetriebssystems
Bild 2: Das Prozessmodell trennt kritische Bereiche innerhalb eines Echtzeitbetriebssystems
(Quelle: Mentor Graphics)
Vor dem IoT und vernetzen Fahrzeugen wurden Sicherheit und Zuverlässigkeit durch mehrere getrennte Prozessoren erreicht. Das garantierte ein robustes Design. Bei den heutigen konsolidierten Embedded-Systemen empfiehlt sich die Verwendung mehrerer Betriebssysteme, die durch einen Type-1-Hypervisor getrennt sind. Der Hypervisor trennt und virtualisiert die Geräteressourcen und gewährleistet, dass wichtige Fahrzeugfunktionen eine höhere Priorität als vernetzte Anwendungen erhalten.

Ein Hypervisor geht über die einfache Trennung hinaus. Er bietet auch einen Mechanismus, um den Zugriff von Peripheriekomponenten auf bestimmte Anwendungsbereiche zu beschränken. Im Falle eines IVI-Systems kann man den Zugriff auf den CAN-Bus des Fahrzeugs beschränken, indem dem Fahrzeug-Infotainment-System nur Zugriff auf CAN-Daten erlaubt wird und bei vernetzten Apps in Android der Zugriff auf Daten nur über die Interprozesskommunikation (IPC) mit dem Linux-basierten Fahrzeug-Infotainment-Applikationen erfolgt.

Gleichzeitig sollen sowohl Linux als auch Android Zugriff auf die lokale SD-Card mit den Multimedia-Daten haben. Ein Hypervisor kann Peripheriekomponenten direkt abbilden und paravirtualisieren, also eine Schnittstelle zu ihnen bereitstellen. Dies erlaubt es Entwicklern, den Zugriff auf den CAN-Bus zu beschränken und andere Ressourcen wie die SD-Karte gemeinsam zu nutzen.

Over-the-Air-Aktualisierung muss eingeplant werden

Wir haben zwei mögliche Ansätze für das Design von IoT-Systemen dargestellt: die Verwendung eines RTOS und eines Type-1-Hypervisors. 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 und Stresstests an vernetzten Geräten sind ein Beispiel, um Ausfälle im Protokoll-Stack oder in Prozesssteuerungsfunktionen festzustellen.

Zudem lässt sich das Funktionieren eines Gerätes mit Hilfe simulierter Angriffe 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.

Benutzer von Mobilgeräten sind damit vertraut, dass sie ihr Gerät häufig aktualisieren müssen, um Fehler zu patchen, Sicherheitsupdates vorzunehmen oder die Performance zu erhöhen. All dies wird mühelos „über die Luft“ erreicht. Sowohl das Prozessmodell-basierte RTOS als auch die Verwendung eines Type-1-Hypervisors erleichtern das Design von Embedded-Systemen, die sicher über die Luft aktualisiert werden können.

Durch die Abtrennung des Anwendungs-Subsystems, das dynamisch geladen und entladen werden kann, erlauben beide Ansätze das Updaten spezieller Subsysteme, das Beheben von Fehlern oder das Lösen von Zuverlässigkeitsproblemen während des Einsatzes im Feld.

Die Bandbreite der IoT-Geräte erfordert häufig, dass Entwickler Code aus diversen Quellen wie eigenen, kommerziellen und Open-Source integrieren. All diese Quellen erhöhen das Risiko negativer Auswirkungen auf die Reaktionsfähigkeit und Zuverlässigkeit eines vernetzten IoT-Gerätes.

Ein RTOS mit einem Prozessmodul zur Abtrennung der Anwendungs-Subsysteme und einem Type-1-Hypervisor zur Konsolidierung mehrerer Betriebssysteme ist ein sinnvoller Ansatz zur Vernetzung von Anwendungen und Systemen, die einen hohen Sicherheitslevel oder Zuverlässigkeit in der Ausführung erfordern.

Neben der Auswahl der Systemarchitektur und Technik müssen Designer auch die Zeit für Tests zur Gewährleistung des Betriebs einplanen, die Betriebsdauer des Geräts bedenken und die Möglichkeit berücksichtigen, die Software möglichst schnell, naht- und mühelos zu aktualisieren.

* Andrew Caples ist Product-Marketing-Manager bei der Embedded Software Division (ESD) von Mentor Graphics.

(ID:43115053)

Weiterführende Inhalte