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)
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.
