Anzeige
RTOS in IoT-Geräten verwenden

RTOS: Elf Mythen

Die UBM Embedded Developer-Umfrage des Jahres 2015 ergab, dass mehr als 60% der aktuellen Projekte Echtzeitfähigkeiten bieten und dass mehr als ein Drittel mit einer grafischen Benutzeroberfläche (GUI) ausgestattet ist. Mehr als 70% der Befragten gaben an, dass sie ein Echtzeit-Betriebssystem (RTOS) oder einen Scheduler verwenden. Von den verbleibenden 30%, die kein RTOS nutzen, wurde mit 79% als wichtigster Grund hierfür genannt, dass die Anwendung kein RTOS erforderte. Dennoch ranken sich die verschiedensten Mythen um die Gründe für die Verwendung (oder auch Nichtverwendung) eines RTOS.

 (Bild: Express Logic GmbH)

(Bild: Express Logic)

Mythos Nr. 1: Die meisten IoT-Geräte brauchen kein RTOS.

Die Embedded-Industrie registriert bereits eine intensive Abkehr von 8- und 16bit-Mikroprozessoren, was sowohl an den Forderungen nach verbesserter Geräte-Funktionalität als auch am attraktiven Preis-Leistungs-Verhältnis der neuen 32bit-Mikroprozessoren liegt. IoT-Geräte benötigen eine Netzwerkanbindung und eine GUI und verlangen deshalb generell nach 32bit-Mikroprozessoren, allein schon um über den nötigen Adressraum und hinreichend Verarbeitungsleistung verfügen zu können. Ähnliche Entwicklungen vollziehen sich bei der Software. Allein die gesteigerten Vernetzungs-Anforderungen erfordern die Verarbeitung von Kommunikations-Protokollstacks auf dem 32bit-Embedded-Prozessor, was die Verwendung eines RTOS zwingend erforderlich macht. Auch die GUI-Design- und Laufzeit-Software von Drittanbietern stützt sich meist auf RTOS-Dienste.

Mythos Nr. 2: Eine Polling-Loop-Architektur funktioniert genau so gut wie ein RTOS.

Viele ältere 8- und 16bit-Bausteine nutzen eine Polling-Loop-Softwarearchitektur, um die Verarbeitungszeit auf die verschiedenen Threads zu verteilen. Diese Technik ist zwar leicht zu verstehen und eignet sich gut für einfache Geräte. In komplexeren Anwendungen stößt sie aber an ihre Grenzen. Das Problem besteht darin, dass die Reaktionszeit eines jeden Threads in der Schleife von der Verarbeitung der übrigen Polling-Schleife abhängig ist, sodass als Worst-Case-Reaktionszeit entsprechend die größtmögliche Verarbeitungszeit durch die Schleife angesetzt werden muss. Wenn sich die Verarbeitung in der Polling-Schleife dynamisch ändert, verändert sich die Reaktionszeit eines jeden Threads genauso. Je mehr Komplexität zu der Pollingabfrageschleife hinzugefügt wird, umso schwieriger wird es, die Echtzeitanforderungen vorherzusagen und einzuhalten, was wiederum Auswirkungen auf die Zuverlässigkeit von IoT-Geräten hat. Im Gegensatz dazu ist die Reaktionszeit bei der Verwendung eines RTOS konstant. Darüber hinaus koordiniert das RTOS im Hintergrund die Zuweisung des Prozessors zu den Thread-Prioritäten, sodass sich die Anwendungssoftware nicht darum kümmern muss, wieviel Verarbeitungszeit jeder Thread beansprucht. Nicht zuletzt haben Änderungen in den Verarbeitungs-Verantwortlichkeiten eines bestimmten Threads keine Auswirkungen auf die Reaktionseigenschaften von Threads mit höherer Priorität.

Mythos Nr. 3: Ein RTOS bringt einen Mehraufwand mit sich, der mein IoT-Gerät überfordern würde.

Selbstverständlich verursacht ein RTOS einen gewissen Overhead im Zusammenhang mit API-Aufrufen und Kontextwechseln. Dieser Mehraufwand ist jedoch gering, außerdem konstant und wahrscheinlich geringer als der Aufwand einer komplexen Polling-Schleife. So erfordern RTOS-Kontextwechsel auf einem Cortex-M typisch weniger als 120 Zyklen (diese Zahl kann von Architektur zu Architektur und von RTOS zu RTOS variieren). Damit eine Polling-Schleife (oder eine andere RTOS-Alternative) hier besser abschneidet, müsste sie vorhersagen und garantieren können, dass die Worst-Case-Verzögerung beim Aktivieren eines Threads weniger als 120 Zyklen beträgt (das sind etwa 50 bis 60 Zeilen C-Code). Für das Prüfen jedes Threads in der Schleife und die Ausführung des Codes für jeden aktiven Thread dürfen somit weniger als 60 Instruktionen notwendig sein. Selbst wenn kein anderer Thread etwas zu tun hätte, würde allein das Abfragen jedes Threads Zyklen beanspruchen, bis schließlich der Thread, der die Bearbeitung angefordert hat, abgefragt wird. Dies mag bei Schleifen mit fünf bis zehn Threads noch funktionieren, doch bei größeren Schleifen lassen sich die besagten 60 Instruktionen nicht mehr einhalten. In einer Worst-Case-Analyse muss all den intervenierenden Threads Verarbeitungszeit zugewiesen werden, sodass Echtzeit-Eigenschaften selbst bei einer minimalen Schleife mit zwei Threads praktisch unmöglich zu realisieren sind.

Mythos Nr. 4: Ein RTOS macht die Entwicklung komplexer.

Kleine Gerätefirmware-Projekte mit einem Gesamt-Speicherbedarf von meist weniger als 32KB lassen sich problemlos von einem oder zwei Firmwareentwicklern bewältigen. Beide müssen das Laufzeitverhalten und die Anforderungen des Geräts in ihrer Gesamtheit verstehen, weil die Logik zur Zuweisung des Prozessors auf den gesamten Applikations-Code verteilt ist. Wenn jedoch der Funktionsumfang eines solchen Geräts wächst, indem beispielsweise Protokolle für die Cloud-Kommunikation hinzukommen, wird das Entwicklerteam größer, sodass nicht mehr jeder die Verarbeitungsanforderungen der Firmware versteht. In diesem Fall muss die Kommunikation unter den von den verschiedenen Teammitgliedern entwickelten Codemodulen so gestaltet und umgesetzt werden, dass eine Synchronisation der Threads untereinander und ein Informationsaustausch möglich ist. Ein RTOS dagegen macht die Entwicklung einfacher, wenn die Funktionalität zunimmt. Mit einem RTOS kann sich jeder Firmwareentwickler auf seinen spezifischen Abschnitt der Firmware konzentrieren, ohne sich um die Verarbeitungsanforderungen der übrigen Firmware des Geräts zu kümmern. Darüber hinaus gibt es effiziente, konsistente und genau definierte Dienste für die Inter-Thread-Kommunikation (Messaging, Semaphoren usw.).

Mythos Nr. 5: Mit einem RTOS wird das Hinzufügen neuer Features zu meinem Gerät schwieriger.

Ein RTOS nimmt sich im Hintergrund der Prozessorzuweisungs-Logik an, sodass sich die Echtzeit-Performance einer hochprioren Task problemlos garantieren lässt – ganz gleich, ob die Firmware 32KB oder 1MB groß ist oder wie viele Threads es in der Applikation gibt. Allein dies vereinfacht das Pflegen der Applikation und das Hinzufügen neuer Features zu einem Gerät. Hinzu kommt, dass die meisten kommerziellen RTOS-Lösungen einen umfangreichen Bestand an fertig integrierter Middleware mitbringen, mit dem sich das Hinzufügen von Netzwerk-Features, Dateisystemen, USB und GUIs vereinfacht.

Das könnte Sie auch interessieren

Der Kiss 4U V3 SKW Rackmount Server von Kontron verfügt über einen leistungsfähigen Intel Xeon W-2100 Prozessor. Damit eignet sich der Rackmount Server optimal für KI- oder Machine-Learning-Anwendungen und kann komplexe, rechenintensive Prozesse und Analysen von großen Datenmengen mühelos verarbeiten.

Der Kontron KBox B-201 wurde als neuer High-Performance-Rechner in kompakter Bauweise in die Kontron Embedded-Box-PC-Familie eingefügt. Aktuelle Prozessoren der 7. Generation Intel Core ermöglichen zusammen mit einem Intel Q170 Express Chipset eine besonders starke Leistung bei geringem Geräuschpegel (max. 34dB(A)). Dafür ist der Boxed-PC mit einem leisen Lüfter ausgestattet und eignet sich somit auch für den Einsatz in lärmsensitiven Umgebungen.

Auf der Grundlage seiner jüngsten Analyse des europäischen Enterprise Augmented-Reality-(AR)-Marktes zeichnet Frost & Sullivan Re’flekt mit dem European Product Leadership Award 2018 für die herausragende AR-Plattform Reflekt One aus. Die AR-Plattform verwandelt vorhandene CAD-Daten und Content in gedruckte Handbücher und visuelle Anleitungen.

HCC Embedded hat seine existierende FTL-Lösung (Flash Translation Layer) für NAND-Speicher durch eine deterministische Ausführungskontrolle erweitert.

Regensburg verfügt als erste Stadt Deutschlands über ein öffentlich zugängliches Netz für das IoT, das stadtweit verfügbar ist.

Kontron stellt mit dem CP3005-SA eine neue Generation von 3U CompactPCI CPU-Boards vor. Das Blade verfügt über vier- oder sechskernige Intel Prozessoren der 8. Generation oder einen Intel Xeon E-2176 Prozessor. Der Intel Xeon Prozessor eignet sich insbesondere für Serverapplikationen sowie für Anwendungen, in denen Speicher mit Fehlerkorrektur (Error Correcting Code (ECC)) benötigt wird.

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige