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
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, 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 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 oder die SHARC- und Blackfin-Prozessoren von Analog Devices wurden um eine Multiply-Accumulate-Einheit mit Einzeltaktausführung, eine Harvard-Speicherarchitektur, Zero-Overhead-Schleifen und zirkulare Adressierung für Filter-Verzögerungsleitungen herum aufgebaut. Wichtiger als die Liste der Merkmale ist die praktische Konsequenz: Ein DSP-Filterkern, der bare-metal läuft, ohne Betriebssystem und ohne Scheduler, führt jedes Mal eine feste Anzahl von Taktzyklen aus. Die Worst-Case-Ausführungszeit wird nicht statistisch über einen langen Testlauf gemessen, sondern aus dem Instruktionslisting berechnet, noch bevor die Baugruppe überhaupt zum ersten Mal eingeschaltet wird.
Ein Field Programmable Gate Array (FPGA) führt denselben Gedanken einen Schritt weiter, indem es den Instruktionsstrom vollständig entfernt. Es gibt keinen Scheduler, der Aufgaben verdrängen könnte, keinen Interrupt-Controller, der über die Reihenfolge entscheiden müsste, und keinen gemeinsamen Bus, um den konkurriert würde. Stattdessen existiert der Algorithmus als parallele Logik, und sein Timing ist eine Funktion von Taktfrequenz und Signallaufzeit, die während der Synthese durch statische Timing-Analyse verifiziert wird. 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 bearbeitet 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.
