Suchen

Gastkommentar Manchmal geht es nicht ohne Echtzeit-Betriebssystem

| Redakteur: Franz Graser

Die – relativ geringen – Kosten von Echtzeitbetriebssystemen (RTOS) werden im Zeitalter des Internets der Dinge bei weitem von den Vorteilen aufgewogen, die sie für ein Geräte-Design mit sich bringen. Das meint William Lamie, Gründer und CEO des RTOS-Spezialisten Express Logic.

Firma zum Thema

William Lamie: Der Gründer und CEO von Express Logic plädiert für Echtzeitbetriebssysteme im Umfeld des Internets der Dinge.
William Lamie: Der Gründer und CEO von Express Logic plädiert für Echtzeitbetriebssysteme im Umfeld des Internets der Dinge.
(Bild: Express Logic)

Heutige Produkte für das Internet of Things (IoT) erfordern die Verwendung eines 32-Bit-Prozessors, damit sie den nötigen Adressraum bereitstellen, die Netzwerk-Konnektivität unterstützen, eine reaktionsschnelle GUI bieten können und für die Verarbeitung von Third-Party-Software geeignet sind. Der Umstieg auf 32-Bit-Hardware sorgt ferner für einen zunehmenden Einsatz kommerzieller Echtzeit-Betriebssysteme. Deren relativ geringe Kosten werden bei weitem von den Vorteilen aufgewogen, die sie für ein Design mit sich bringen. Nachfolgend sind sechs Situationen aufgeführt, in denen es kostspieliger sein kann, kein RTOS zu nutzen.

Wenn Ihre Anwendung nach schneller, garantierter Echtzeit-Reaktionsgeschwindigkeit verlangt: Einfache Applikationen enthalten häufig eine auf Abfrageschleifen (Polling Loops) basierende Softwarearchitektur, um die Verarbeitungszeit auf die verschiedenen Threads zu verteilen. In den heutigen komplexen Geräten aber wird die Worst-Case-Ansprechzeit so lang wie die maximale Zeit, die zum Verarbeiten der kompletten Polling-Schleife benötigt wird. Werden dagegen mit einem RTOS die Thread-Prioritäten richtig vergeben, ist der Zeitbedarf der einzelnen Threads für die Applikation irrelevant und es wird eine konstante Reaktionszeit erreicht.

Wenn Sie den Verarbeitungsaufwand reduzieren müssen: Obwohl ein RTOS ebenfalls einen gewissen Verarbeitungsaufwand (für API-Aufrufe und Kontextwechsel) mit sich bringt, ist dieser Aufwand gering und vor allem konstant. Wird dagegen eine Polling-Schleife komplexer, übersteigt ihr Verarbeitungsaufwand sehr wahrscheinlich den eines RTOS. Ohne RTOS ist die Applikation selbst für alle anfallenden Arbeiten zuständig – einschließlich der Zyklen, die für das Pooling, Funktionsaufrufe und die Interruptbehandlung benötigt werden. Von ganz einfachen Anwendungen abgesehen, dürfte ein RTOS weniger Zyklen erfordern als die Applikation, wenn sie all diese Aufgaben mit wahrnehmen müsste.

Wenn Sie die Entwicklung vereinfachen müssen: Wenn der Funktionsumfang eines Geräts wächst, kann ein RTOS die Entwicklung sogar vereinfachen, denn es ist nicht mehr notwendig, dass eine Person allein die Verarbeitungsanforderungen sämtlicher Firmware-Komponenten in vollem Umfang versteht. Mit einem RTOS kann sich jeder Firmwareentwickler auf seinen speziellen Teil des Designs konzentrieren. Überdies stehen effiziente, konsistente und bestens definierte Dienste für die Inter-Thread-Kommunikation (etwa Messaging, Semaphoren und dergleichen) zur Verfügung.

Wenn Sie ohne großen Aufwand neue Features hinzufügen möchten: Unsichtbar sorgt ein RTOS für die Prozessorzuweisung, um die Echtzeitfähigkeit jedes Threads mit hoher Priorität zu garantieren – gleich ob die Firmware 32 KB oder 1 MB groß ist und gleich wie viele Threads sie enthält. Das Pflegen der Applikation und das Nachrüsten neuer Features wird dadurch einfacher. Für die meisten kommerziellen RTOS-Produkte gibt es außerdem einen großen Umfang an fertig integrierter Middleware zum Hinzufügen von Netzwerkfunktionen, Dateisystemen und USB- oder GUI-Funktionen.

Wenn Ihre Applikation einfach portierbar sein soll: Mit einem RTOS greifen Applikationen über ein API auf dessen Dienstfunktionen zu. Hierdurch wird das RTOS plattformunabhängig und der Wechsel auf einen anderen Prozessor vereinfacht sich, weil keiner der Serviceaufrufe der Applikation geändert werden muss.

Wenn Sie eine Sicherheits-Zertifizierung benötigen: Viele kommerzielle RTOS-Produkte besitzen bereits eine Zertifizierung durch die Regulierungsbehörden, sodass sich die System-Zertifizierung beschleunigt. Ohne fertig zertifiziertes RTOS müssten die Entwickler entweder ihren eigenen Scheduling-Code zertifizieren lassen oder Artefakte für die verwendete RTOS-Software vorlegen, was häufig den Kosten- oder Zeitaufwand erhöht.

(ID:43715561)