In der Technik ist eine schnelle Reaktion bedeutungslos, wenn sie nicht garantiert werden kann. Ein System, das zuverlässig in 50 ms reagiert, ist deterministischer als eines, das nur manchmal in 5 ms reagiert. Diese Unterscheidung mag überflüssig erscheinen, bis ein verpasster Deadline dazu führt, dass ein Roboterarm einen Arbeiter trifft oder ein Sicherheitsventil nicht rechtzeitig schließt.
Determinismus ist eine wirkliche Anforderung
Die Echtzeit-Verarbeitung ist formal definiert als die Fähigkeit eines Systems, auf eine Eingabe innerhalb eines begrenzten, vorhersagbaren Zeitfensters zu reagieren, unabhängig von Systemlast, thermischen Bedingungen oder gleichzeitiger Aktivität. Diese Grenze wird als Deadline bezeichnet, und ob die Überschreitung dieses Deadlines akzeptabel ist, bestimmt die Klasse des betreffenden Echtzeitsystems.
Hard real-time (Nulltoleranz für eine Verzögerung)
Keine Toleranz für Deadline-Überschreitungen. Ein verpasster Deadline bedeutet einen Systemausfall. Beispiele sind Flugsteuerungssysteme, Airbag-Auslösung, Antiblockiersysteme und chirurgische Robotik. Eine Verzögerung von 1 ms ist dasselbe wie gar keine Reaktion.
Soft real-time (Leistungsdegradation ohne Systemausfall)
Toleriert gelegentliche Deadline-Überschreitungen mit kontrollierter Leistungsverschlechterung statt katastrophalem Ausfall. Ein Video-Codec, der ein Bild auslässt, erzeugt ein sichtbares Artefakt, bringt aber kein Flugzeug zum Absturz. Beispiele sind Audioverarbeitung, industrielle HMI-Systeme und vernetzte Telemetrie.
Firm real-time (verspätetes Ergebnis ist nutzlos, jedoch nicht gefährlich)
Verspätete Ergebnisse sind nutzlos, aber nicht gefährlich. Beispiele sind automatisierte Handelssysteme und bestimmte Sensor-Fusion-Pipelines.
Diese Klassifizierungen wirken sich direkt auf technische Entscheidungen aus. Eine Hard-real-time-Anforderung schließt in der Regel Standard-Linux als primäre Laufzeitumgebung aus. Bei einer Soft-real-time-Anforderung ist dies nicht der Fall.
Timing-Diagramm mit zwei überlagerten Reaktionskurven: ein Standard-Linux-Prozess (unregelmäßig, mit sichtbaren Latenzschwankungen von 2 bis 5 ms) und eine RTOS-Aufgabe (flache, konstante Linie unter Millisekunden-Reaktionszeit). Beide reagieren auf denselben sich wiederholenden Interrupt.
Warum Standard-Betriebssysteme den Hard-real-time-Test nicht bestehen
Linux, Windows und die meisten Allzweck-Betriebssysteme sind als faire Scheduler konzipiert. Sie verteilen laufend Ressourcen auf Prozesse, verarbeiten Interrupts, verwalten den Speicher und optimieren die Reaktionsfähigkeit im Durchschnitt. Das Wort „Durchschnitt“ ist nämlich das Problem.
Unter einem Standard-Linux-Kernel kann die Interrupt-Latenz von wenigen Mikrosekunden bis zu mehreren Millisekunden schwanken, je nachdem, was das System gerade sonst tut. Für eine Soft-real-time-Anwendung ist diese Schwankung akzeptabel. Für eine Hard-real-time-Anwendung, etwa die Steuerung der Ausgangsstufe eines Leistungswandlers bei einer Schaltfrequenz von 100 kHz, ist eine Jitter-Schwankung von 2 ms eine Hardwarestörung, die nur darauf wartet, einzutreten.
Ein Echtzeitbetriebssystem (RTOS) wie FreeRTOS, Zephyr oder VxWorks verwendet einen präemptiven, prioritätsbasierten Scheduler mit deterministischer Interrupt-Verarbeitung. Die Worst-Case-Interrupt-Latenz ist begrenzt und messbar. Aufgaben mit höherer Priorität verdrängen Aufgaben mit niedrigerer Priorität sofort und nicht erst, wenn der Scheduler dazu kommt.
Unterhalb des RTOS: DSP und FPGA
Die Echtzeitverarbeitung hat nicht beim RTOS begonnen. Bevor Allzweckprozessoren schnell genug waren, um ihnen begrenzte Reaktionszeiten anvertrauen zu können, erreichte man Determinismus, indem man Silizium fest für die jeweilige Aufgabe reservierte.
Digitale Signalprozessoren, wie die TMS320-Familie von TI sowie die SHARC- und Blackfin-Prozessoren von Analog Devices, wurden um eine Multiply-Accumulate-Einheit mit einer Ausführungszeit von einem Taktzyklus, eine Harvard-Speicherarchitektur, Schleifen ohne Overhead und eine Ringadressierung für die Verzögerungsleitungen von Filtern herum aufgebaut. Die praktische Konsequenz ist wichtiger als die bloße Aufzählung der Merkmale: Ein auf einem DSP bare-metal, ohne Betriebssystem und ohne Scheduler, ausgeführter Filterkern benötigt bei jeder Ausführung eine feste Anzahl von Taktzyklen. Die Worst-Case-Ausführungszeit wird nicht statistisch über einen langen Testlauf ermittelt, sondern anhand des Instruktionslistings berechnet, noch bevor die Platine überhaupt zum ersten Mal eingeschaltet wird.
Ein Field-Programmable Gate Array (FPGA) führt denselben Gedanken noch einen Schritt weiter, indem es den Instruktionsstrom vollständig eliminiert. Es gibt keinen Scheduler, der Tasks präemptieren könnte, keinen Interrupt-Controller, der über die Reihenfolge entscheiden müsste, und keinen gemeinsamen Bus, um den konkurriert werden müsste. Stattdessen ist der Algorithmus als parallele Logik implementiert, und sein Timing ist eine Funktion von Taktfrequenz und Signallaufzeiten, die während der Synthese durch eine statische Timing-Analyse verifiziert werden. Der Jitter wird in Taktzyklen angegeben, nicht in Mikrosekunden. Genau das macht ein FPGA zur einzigen praktikablen Option für die Verarbeitung mit Abtastraten von einigen zehn bis mehreren hundert Megahertz, für Protokoll-Timing mit Toleranzen im Nanosekundenbereich oder für Hunderte von Kanälen, die tatsächlich gleichzeitig und nicht im Zeitmultiplex verarbeitet werden müssen.
Zusammen betrachtet bilden diese vier Optionen eine Skala, auf der Flexibilität gegen Determinismus eingetauscht wird: Ein GPOS bietet die größte Flexibilität, aber nur statistische Timing-Garantien; ein RTOS begrenzt die Worst-Case-Latenz auf Mikrosekunden und behält dabei ein vertrautes Softwaremodell bei; ein bare-metal betriebener DSP liefert taktgenaue Ausführung, allerdings um den Preis einer deutlich engeren Entwicklungsumgebung; und ein FPGA liefert Determinismus schon durch seine Konstruktion, bei dem höchsten Entwicklungsaufwand pro Funktion.
Moderne Entwürfe entscheiden sich selten nur für eine davon. Heterogene SoCs vereinen alle auf einem einzigen Chip, und genau deshalb passt die Zynq-Plattform zur TETRA-Basisstation: Die programmierbare Logik übernimmt den schnellsten Signalpfad, ein Arm-Core betreibt ein RTOS für die zeitkritische Steuerung und der zweite betreibt Linux für Verwaltung und Konnektivität. Die Entscheidung lautet nicht, welche Technologie die beste ist, sondern welcher Deadline auf welche Ebene gehört.
Was Edge-Verarbeitung für Echtzeitsysteme ermöglicht
Die Verarbeitung näher an den Sensor zu verlagern, eliminiert die größte und am wenigsten vorhersagbare Latenzquelle in den meisten IoT-Architekturen: das Netzwerk.
Die Round-Trip-Latenz über die Cloud (typischerweise 50–200 ms) ist für Echtzeitzwecke nicht nur langsam, sondern nicht-deterministisch. Ein überlastetes Netzwerk kann diese Latenz in den Sekundenbereich verschieben.
Die Edge-Verarbeitung stellt den Determinismus wieder her, indem sie das Netzwerk vollständig aus dem Regelkreis entfernt. Dadurch werden zwei konkrete Fähigkeiten verfügbar:
Geschlossener Regelkreis im Mikrosekundenbereich
Ein Sensor kann einen Aktuator auslösen, ohne dass Daten die lokale Hardware verlassen. Bei der Motorsteuerung können die Strommessung, die PID-Berechnung und die Anpassung des PWM-Ausgangs auf einem korrekt konfigurierten RTOS in weniger als 10 µs abgeschlossen werden: eine Leistung, die cloudvermittelte Steuerung um mehrere Größenordnungen nicht erreichen kann.
Sicherer Betrieb bei Konnektivitätsverlust
Kritische Systeme können einen sicheren Zustand auch dann aufrechterhalten, wenn die externe Konnektivität verloren geht. Ein Überdruckventil, das auf Basis lokaler Edge-Logik auslöst, ist nicht darauf angewiesen, dass die Cloud erreichbar ist. In der sicherheitskritischen Zertifizierung (IEC 61508, ISO 26262) ist dies oft eine formale Anforderung: Die Sicherheitsfunktion darf nicht von externer Kommunikation abhängen.
Zusammenfassung
Bei der Echtzeit-Datenverarbeitung geht es letztlich um garantiertes Verhalten, nicht um reine Leistung. Ob diese Garantie von einem RTOS, einem bare-metal betriebenen DSP oder einem FPGA kommt, ergibt sich aus dem Deadline selbst und nicht aus einer Vorliebe für die eine oder andere Technologie. Für industrielle und sicherheitskritische Anwendungen ist es die Verbindung des richtigen Maßes an Determinismus mit edge-lokaler Verarbeitung, die deterministisches Verhalten erreichbar und zertifizierbar macht.
Externe Quellen
Texas Instruments: Referenzhandbuch zu CPU und Befehlssatz des DSP TMS320C62x
