Echtzeit-Betriebssysteme entdecken

In den 1980er Jahren schaltete das Versandunternehmen Federal Express (heute FedEx) einige hervorragende TV-Werbekampagnen. Darin pries das Unternehmen seinen Lieferservice über Nacht an. Die Spots endeten mit dem Slogan: „Federal Express. Wenn es wirklich dringend über Nacht zugestellt werden muss. Echtzeit-Betriebssysteme (RTOS) sind ein bisschen ähnlich. Wie FedEx sind sie darauf abgestimmt, die Lieferung von Bits nach einem genauen Zeitplan zu garantieren. Wie FedEx würde man sich nicht in jedem Szenario auf RTOS verlassen. Allzweck-Betriebssysteme wie Windows oder Linux sind für die überwiegende Mehrheit der Aktivitäten gut geeignet. Genauso wie die meisten Pakete mit der Post verschickt werden können.

Der Unterschied besteht darin, dass ein RTOS so konzipiert ist, dass jede Anwendung, jeder Dienst, jede Nachricht, jede Aufgabe und jeder Thread so behandelt wird, dass eine sofortige, konsistente und gesicherte Ausführung gewährleistet ist – ein Konzept, das als Determinismus bekannt ist. Multithreading und Multitasking – beides Kernkonzepte von Allzweck-Betriebssystemen – werden in einem RTOS anders gehandhabt. So können die Programmierer:innen genau steuern, welche programmierspezifischen Elemente in der Warteschlange Vorrang haben und wie das System reagiert, wenn es ausgelastet ist. Das Ergebnis: Die wichtigsten Aufgaben wie beispielsweise die Echtzeitverarbeitung von und die Reaktion auf Druck- und Temperaturdaten in einem Kernkraftwerk werden innerhalb eines streng definierten Zeitplans erledigt, und zwar jedes Mal.

Es gibt eigentlich zwei Arten von RTOS, harte Echtzeit-Betriebssysteme und weiche Echtzeit-Betriebssysteme. Die anspruchsvollsten Szenarien erfordern harte Echtzeit-Betriebssysteme.

• Harte Echtzeit: Sie soll garantieren, dass die Fristen für Antworten immer eingehalten werden. Die Überschreitung einer Frist wird als vollständiger Systemausfall betrachtet.
• Weiche Echtzeit: Sie ist für die Einhaltung von Antwortfristen optimiert. Die Überschreitung einer Frist führt zu einer schrittweisen Verschlechterung der Systemleistung. Bei wiederholter Überschreitung von Fristen kann dies zu einem Systemausfall führen.

Wann benötigen Sie ein RTOS?

Die meisten RTOS-Anwendungen lassen sich in zwei große Kategorien einteilen: Die Reaktion auf Ereignisse und die Steuerung im geschlossenen Regelkreis. Ein gutes Beispiel für Ersteres ist eine Anwendung zur Qualitätskontrolle in der Fertigung. Dort erfassen Kameras Teile entlang einer Montagelinie. Die optische Erkennung identifiziert Defekte, um einen Korrekturprozess zu aktivieren. Das System ist in der Lage, ein komplexes Ereignis zu erkennen und innerhalb eines sehr kurzen Zeitfensters Maßnahmen zu ergreifen. Szenarien mit geschlossenen Regelkreisen befassen sich mit der fortlaufenden Überwachung und Steuerung, beispielsweise eines Kühlsystems, das kontinuierlich Druck- und Durchflusswerte misst. So werden die Ventileinstellungen dynamisch angepasst, um innerhalb definierter Grenzen zu bleiben.

Das Aufkommen des industriellen Internet of Things (IIoT) hat eine neue Generation von Geräten hervorgebracht, die auf RTOS-Frameworks angewiesen sind, um eine effektive Entscheidungsfindung und Prozessautomatisierung zu ermöglichen. Da Embedded-Systeme immer „intelligenter“ werden, macht die Notwendigkeit eines erhöhten Maßes an Autonomie die Entscheidungsfindung in Echtzeit zu einer wichtigen Komponente für ein effizientes Hardware-Management. Die Geräte in einer IIoT-Umgebung müssen nicht nur in der Lage sein, miteinander zu kommunizieren, sondern auch Daten an die Cloud oder den Fog weiterzuleiten und ebenso schnell Befehle zu empfangen. Echtzeit-Umgebungen werden immer mehr zur bevorzugten Lösung für Netzwerkadministrator:innen und Automatisierungsprofis, die die Industrie 4.0 vorantreiben.

Gibt es Nachteile bei einem RTOS?

Wie der FedEx-Priority-Overnight-Service verlangt auch ein RTOS einen Aufpreis. Diese streng begrenzten und angepassten Systeme verzichten auf die Feinheiten von Allzweck-Betriebssystemsoftware wie Windows und viele Linux-Distributionen. Außerdem muss die Software, die von den Entwickler:innen für ein RTOS geschrieben wird, mit äußerster Präzision erstellt werden, sonst drohen schwere Fehler. Man denke nur an die Raumsonde Mars Pathfinder. Sie erlitt kurz nach ihrer Landung im Jahr 1997 eine Reihe von Systemrücksetzungen aufgrund eines Prioritätsumkehrungsfehlers im RTOS-Anwendungscode. Dieser wurde von den Jet Propulsion Laboratories geschrieben. Das Team hatte das Glück, dass es den Fehler in seinen Labors reproduzieren und ein Programm in C-Sprache hochladen konnte, um den Konflikt zu lösen. 

RTOS-Produkte wie QNIX Neutrino, Wind River VxWorks und Microsoft Windows Embedded Compact (ehemals Windows CE) sind leistungsstarke Werkzeuge. In unternehmenskritischen Umgebungen ermöglichen sie eine hohe Konsistenz, aber sie sind nicht für jede Aufgabe geeignet. Wenn es aber, bildlich gesprochen, „unbedingt über Nacht gehen muss“, kann ein RTOS die beste Wahl sein.