RTOS in IoT-Geräten verwenden

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.

Mythos Nr. 6: Ein RTOS erschwert das Portieren von Applikationen.

Anwendungen mit RTOS greifen über ein API auf ihre Dienstfunktionen zu, wodurch das RTOS plattformunabhängig wird. Der Wechsel auf einen anderen Prozessor wird vereinfacht, da keine der Dienst-Referenzierungen der Applikation geändert werden muss. Anders ausgedrückt: die Applikation läuft überall dort, wo auch das RTOS läuft, und das heißt bei den meisten kommerziellen und Open-Source-RTOS-Produkten, dass sie auf praktisch jeder 32bit-Prozessorarchitektur lauffähig ist. Bei nur geringen Änderungen an ihrem Code profitieren Entwickler also von der Portierbarkeit ihrer Applikationen.

Mythos Nr. 7: Ein RTOS belegt zu viel Speicher.

Ein RTOS benötigt für seinen Betrieb sowohl Befehlsspeicher (meist Flash) als auch Datenspeicher (RAM). Ein gutes kommerzielles RTOS aber braucht nur wenig von beidem: meist sind es rund 2KB Befehlsspeicher und 1KB RAM. Selbstverständlich sind diesbezüglich auch die Anforderungen der Applikation zu erfüllen, wodurch es noch vorteilhafter ist, wenn das RTOS mit wenig Speicher auskommt.

Mythos Nr. 8: Ein RTOS benötigt zu viele Verarbeitungszyklen.

Tatsache ist, dass ein RTOS Verarbeitungszyklen für Kontextwechsel, API-Aufrufe usw. benötigt, jedoch stehen diese Zyklen in direktem Zusammenhang mit dem, was die Applikation verwendet. Wenn etwa eine bestehende Polling-Schleife unverändert aus einem einzigen Thread in einem RTOS ausgeführt wird, entsteht keinerlei Mehraufwand, und die Schleife wird genau so verarbeitet wie zuvor. Zusätzlicher Verarbeitungsaufwand durch das RTOS entsteht erst dann, wenn RTOS-Dienste genutzt werden. Hinzu kommt, dass ohne ein RTOS die Applikation selbst für alle erforderlichen Verarbeitungsaufgaben verantwortlich ist, einschließlich der Zyklen, die für das Polling, die Funktionsaufrufe und die Interruptverarbeitung aufgewendet werden. Wenn man also von ganz einfachen Anwendungen absieht, ist es wahrscheinlich, dass das RTOS weniger Zyklen benötigt als die Applikation, wenn sie alle Aufgaben allein bewältigen müsste.

Mythos Nr. 9: Ich habe nicht die Zeit, die Verwendung eines RTOS zu erlernen.

Der Aufwand zur Einarbeitung in ein RTOS ist proportional zu dem, was von der Applikation genutzt wird. Z.B. würde für das Verlegen einer bestehenden Polling-Schleife in einen einzelnen Thread praktisch kein zusätzlicher Lernaufwand entstehen. Die Fallstricke, die bei der Verwendung einer Polling-Loop-Architektur lauern, sorgen aber dafür, dass das Studieren und erneute Untersuchen der Leistungsfähigkeit der gesamten Firmware den Aufwand zum Erlernen eines RTOS sehr schnell bei weitem übersteigt, besonders wenn man den ursprünglichen Code nicht selbst geschrieben hat. Die meisten Anbieter guter kommerzieller Echtzeit-Betriebssysteme bieten außerdem Vor-Ort-Schulungen und äußerst umfangreiche Dokumentation an. Abgesehen davon ist ein gutes kommerzielles RTOS auch einfach zu verstehen und anzuwenden.

Mythos Nr. 10: Ein kommerzielles RTOS kann ich mir nicht leisten.

Das alte Sprichwort, das man das bekommt, was man bezahlt, gilt auch für RTOS-Produkte. Bei kostenlosen oder Open-Source-RTOS-Produkten besteht nicht das garantierte Eigeninteresse an Kompaktheit, Effizienz und einfacher Anwendung. Das Fehlen stetiger Einnahmen bringt auch einen Mangel an Forschung und Entwicklung, Produktevolution und – was am wichtigsten ist – Fähigkeit zur umfassenden Unterstützung des Kunden mit sich. Ein RTOS ohne zielgerichteten Support zu nutzen, ist jedoch genauso, als würde man die Zahlenfolge ‚1234‘ als Passwort für alles verwenden: es kann funktionieren, aber irgendwann holt es einen ein. Die Kosten für die meisten kommerziellen RTOS-Lizenzen beginnen in der Größenordnung von 10.000 US-Dollar für eine Non-Royalty-Lizenz mit komplettem Quellcode und vollwertiger Unterstützung. Dies stellt einen enormen Wert dar und kostet doch nur einige Monate Gehalt eines typischen Embedded-Firmware-Entwicklers. Außerdem ist es ein einmaliger Lizenzkauf, sodass die Lizenz anschließend unbegrenzt lange genutzt werden kann. Ein entsprechender Entwickler kostet dagegen jeden einzelnen Monat zwischen 5.000 und 10.000 US-Dollar.

Mythos Nr. 11: Ein RTOS wäre ein Overkill für meine Anwendung.

Die Kriterien, ab wann sich ein RTOS lohnt, lassen sich nur schwierig präzise angeben. Wenn aber ein Gerät insgesamt weniger als 16KB Speicher (ROM und RAM zusammen) enthält, ist die Wahrscheinlichkeit groß, dass ein RTOS tatsächlich ein Overkill wäre. Solche Geräte dienen meist einem ganz bestimmten Zweck und sind überwiegend mit einem 8- oder 16bit-Mikroprozessor bestückt. Sobald die Firmware für ein Gerät mehr als 32KB Speicher umfasst oder ein Kommunikations-Protokoll (wie alle IoT-Geräte) oder eine GUI enthält, ist ein RTOS nahezu unverzichtbar. Doch auch ein 32KB großes, für einen bestimmten Zweck und nicht für das IoT vorgesehenes Gerät kann von einem RTOS profitieren, einfach um Vorder- und Hintergrund-Tasks in zwei separate Threads gliedern zu können. Eine solche Konfiguration würde nur 32KB zusätzlichen Speicher für das RTOS erfordern, während im Gegenzug die Firmware deutlich einfacher würde und sich künftig leichter erweitern ließe. Angesichts des rapiden Wachstums des IoT und der neuen Geräte, die es nutzen sollen, wird es immer wahrscheinlicher, dass auch Entwickler, die bisher ohne RTOS entwickelt haben, schon in naher Zukunft die Verwendung eines RTOS ins Auge fassen werden.

Autor: William E. Lamie
Co-Founder + CEO
Express Logic
www.rtos.com

Express Logic GmbH
www.rtos.com

Das könnte Sie auch Interessieren