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 wirkt überflüssig, bis ein verpasster Deadline dazu führt, dass ein Roboterarm einen Menschen trifft oder ein Sicherheitsventil nicht rechtzeitig schließt.
Determinismus ist eine wirkliche Anforderung
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 ihre Überschreitung 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, 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. Eine Soft-real-time-Anforderung nicht.
Warum Standard-Betriebssysteme den Hard-real-time-Test nicht bestehen
Linux, Windows und die meisten Allzweck-Betriebssysteme sind als faire Scheduler konzipiert: Sie verteilen 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äts-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.
Bei Consilia werden Entscheidungen über den Software-Stack direkt durch die Deadline-Analyse bestimmt. Im TETRA-Basisstationsprojekt etwa nutzen wir die Dual-Core-Architektur der Zynq-Plattform bewusst: Ein ARM-Core betreibt ein RTOS für die Low-Level-Signalverarbeitung, bei der das Timing nicht ein Thema einer Diskussion ist, während der zweite Linux für übergeordnete Dienste betreibt, bei denen Flexibilität wichtiger ist als Mikrosekunden-Präzision.
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 diesen Wert 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. Für industrielle und sicherheitskritische Anwendungen ist die Kombination aus einem geeigneten RTOS und edge-lokaler Verarbeitung das, was deterministisches Verhalten erreichbar und zertifizierbar macht.