Echtzeit bedeutet nicht einfach schnell

In der Robotersteuerung bedeutet die Bezeichnung einer Aufgabe als echtzeitfähig nicht einfach, dass sie schnell ausgeführt wird. Ihr Ergebnis muss vielmehr innerhalb einer für die Anwendung relevanten Frist verfügbar sein. Muss eine Steuerungsaufgabe Sensoren auslesen, eine Reaktion berechnen und Aktoren vor einem bestimmten Grenzwert aktualisieren, sind sowohl die Ausführungszeit als auch deren Schwankungen wichtig – ebenso die Möglichkeit, die Frist zu verfehlen. Ein niedriger Durchschnitt reicht nicht als Nachweis für vorhersehbares Verhalten.

Diese Unterscheidung ist wichtig, weil eine Aufgabe bei den meisten Ausführungen schnell sein und in anderen Fällen dennoch zu lange dauern kann. Ein Durchschnitt beschreibt das typische Verhalten, zeigt für sich genommen aber weder, was in den langsamsten Fällen geschieht, noch wie oft sie auftreten. Um die zeitliche Anforderung zu bewerten, muss die Reaktion im Verhältnis zur einzuhaltenden Frist betrachtet werden, statt lediglich Durchschnittsgeschwindigkeiten zu vergleichen. Entscheidend ist, ob die Aufgabe unter den untersuchten Bedingungen rechtzeitig abgeschlossen wird – nicht, ob sie normalerweise schnell ist.

Die konkrete Anforderung hängt von der Funktion ab. Eine Überwachungsoberfläche kann Verzögerungen tolerieren, die in einem Regelkreis unzulässig wären. Auch für Datenerfassung, Verarbeitung und die Kommunikation mit Aktoren können unterschiedliche Fristen gelten. Vor der Wahl einer Architektur sollte daher feststehen, welche Aufgabe reagieren muss, welche Frist gilt, wie oft sie wiederkehrt und welche Folgen eine verspätete Reaktion hätte. Ohne solche Anforderungen droht „Echtzeit“ zu einer ungenauen Bezeichnung statt zu einem überprüfbaren Kriterium zu werden. Ihre getrennte Definition verhindert außerdem, dass Schritte mit unterschiedlichen Funktionen und zeitlichen Anforderungen gleichgesetzt werden.

Was ROS 2 zur Ausführung beiträgt

Die ROS-2-Dokumentation behandelt Echtzeitprogrammierung als Thema mit Anforderungen und Implementierungsschwierigkeiten, nicht als Eigenschaft, die durch die Verwendung des Frameworks automatisch entsteht. Deshalb sollte man die von ROS 2 bereitgestellten Werkzeuge vom Nachweis unterscheiden, dass eine konkrete Anwendung ihre Fristen einhält. Technische Dokumentation kann die Konfiguration und Analyse unterstützen, ersetzt aber weder die Definition der Roboteranforderungen noch Tests der gewählten Implementierung.

Insbesondere darf das Vorhandensein von Konfigurationsmechanismen nicht als Garantie verstanden werden, dass ein Ergebnis innerhalb einer Ende-zu-Ende-Frist eintrifft. Ein Datenpfad kann Kommunikation, Scheduling, Verarbeitung und eine Reaktion der Aktoren umfassen; die gemessene Zeit hängt vom untersuchten Pfad und den Ausführungsbedingungen ab. Die richtige Interpretation ist bedingt: Jeder Mechanismus muss innerhalb einer konkreten Konfiguration und zusammen mit dem Rest der Anwendung bewertet werden.

Bei der Bewertung einer Konfiguration sollte beschrieben werden, welche Komponenten am relevanten Pfad beteiligt sind und welche zeitliche Grenze geprüft wird. Das erleichtert die Interpretation von Messungen und verhindert, dass das Ergebnis einer einzelnen Konfigurationsoption zugeschrieben wird. Die herangezogene Dokumentation behandelt Echtzeitprogrammierung als Implementierungsfrage; sie formuliert keine allgemeine Garantie für jeden Roboter. Eine aussagekräftige Bewertung macht daher den Umfang jeder Messung und Schlussfolgerung deutlich.

Executor, Callbacks und Scheduling

Executor gehören zur Ausführungsarchitektur von ROS 2. Wissenschaftliche Untersuchungen zum Scheduling von Verarbeitungsketten in einem multithreaded ROS-2-Executor betrachten Scheduling und Reaktionszeiten im Kontext der gesamten Kette, statt nur die Geschwindigkeit eines einzelnen Knotens zu messen. Das unterstreicht, dass die Arbeitsorganisation und die Abhängigkeiten zwischen Aufgaben für die konkret geplante Konfiguration bewertet werden müssen.

In der Praxis bedeutet die Bewertung eines Executors, die Organisation der Arbeit zu untersuchen und nicht nur die Laufzeit einer Funktion, wenn sie ohne weitere Aufgaben ausgeführt wird. Die Bearbeitung von Callbacks gehört zum Pfad von einer Eingabe bis zu einer Reaktion; Entscheidungen über die Verteilung und Ausführung sind deshalb gemeinsam mit dem restlichen Pfad zu betrachten. Die Zahl der Threads allein beschreibt das Scheduling nicht vollständig. Wichtig ist auch, wie sie sich zu den Aufgaben verhält, die die Anwendung tatsächlich ausführt.

Bei einer Verarbeitungskette kann die Analyse die beteiligten Schritte und ihre Beziehungen umfassen. Die Struktur des Executors und die Abhängigkeiten zwischen Aufgaben gehören zum untersuchten System. Ergebnisse einer Analyse oder eines Experiments für eine bestimmte Version und Konfiguration dürfen nicht ohne Weiteres auf andere Versionen, Lasten oder Plattformen übertragen werden. Die zitierte Forschung behandelt eine konkrete multithreaded Konfiguration; sie ist keine Garantie für alle ROS-2-Systeme.

Was außerhalb des Frameworks liegt

ROS 2 beseitigt nicht den Einfluss des Betriebssystems oder der Plattform, auf der es ausgeführt wird. Die Projektdokumentation zur Echtzeitprogrammierung beschreibt das Thema als eine Reihe von Anforderungen und Implementierungsschwierigkeiten, nicht als Eigenschaft, die allein durch die Nutzung von ROS 2 aktiviert wird. Als konkretes Beispiel empfiehlt die Dokumentation des ROS-2-Treibers von Universal Robots für diesen Treiber ein Ubuntu-System mit Echtzeitfähigkeiten und weist darauf hin, dass ein Kernel mit geringer Latenz in vielen der im Leitfaden beschriebenen Situationen ausreichen kann. Diese Empfehlung bezieht sich auf diesen Treiber und darf nicht auf alle Roboter oder Anwendungen verallgemeinert werden.

Daher müssen zwei ROS-2-Implementierungen kein gleiches zeitliches Verhalten zeigen, wenn sie sich hinsichtlich Plattform oder Arbeitslast unterscheiden. Beobachtungen müssen an die Bedingungen gebunden sein, unter denen sie gewonnen wurden: Systemkomponenten und Konfiguration sind für die Interpretation des Ergebnisses wichtig. Ohne diese Angaben lässt sich anhand eines einzelnen Werts nicht erkennen, ob er die Bedingungen abbildet, denen die Anwendung ausgesetzt sein wird.

Es reicht auch nicht, zu prüfen, ob Nachrichten ankommen oder eine Demonstration unter kontrollierten Bedingungen funktioniert. Ein Test sollte Arbeitslast und Ablauf der Anwendung abbilden, relevante Zeiten erfassen und langsame Fälle berücksichtigen, nicht nur Mittelwerte. Gemessen werden sollte Ende zu Ende, vom Ereignis, das die Arbeit auslöst, bis zur für den Roboter wichtigen Reaktion. Bei sicherheits- oder missionskritischen Anforderungen sollten Leistungsnachweise Teil einer umfassenderen Bewertung von Architektur und Risiko sein; ein isolierter Leistungstest ist keine Zertifizierung.

Eine sinnvolle Prüfung vor der Einführung von ROS 2

Dokumentieren Sie zunächst jede Frist: welches Ereignis sie auslöst, welche Reaktion sie erfüllt, wie oft sie wiederkehrt und welcher Spielraum besteht. Zeichnen Sie anschließend die Verarbeitungskette zwischen Sensoren, Knoten und Aktoren auf. Notieren Sie für jeden Abschnitt die beteiligten Komponenten, ihre Aufgaben und ihre Abhängigkeiten von anderen Aufgaben. So wird aus einer allgemeinen Erwartung eine Reihe überprüfbarer Fragen; außerdem lässt sich leichter feststellen, ob eine Verzögerung aus der Kommunikation, dem Scheduling oder der Anwendungsarbeit stammt.

Die Beschreibung jeder Frist sollte außerdem klar zwischen dem Beginn der Arbeit und der als gültig betrachteten Reaktion unterscheiden. Diese Genauigkeit ermöglicht den Vergleich der Messwerte mit der jeweiligen Anforderung, statt aus Bequemlichkeit einen anderen Abschnitt zu messen. Gibt es mehrere Schritte, erleichtert es die Interpretation, ihre Beziehungen innerhalb der Kette beizubehalten. So wird die lokale Leistung einer Komponente nicht mit der vollständigen Reaktion verwechselt, die der Roboter benötigt.

Legen Sie als Nächstes die zu bewertende ROS-2-Version, Middleware, das Betriebssystem, die Hardware und die Konfiguration fest. Testen Sie die erwartete Arbeitslast sowie plausible ungünstige Bedingungen, messen Sie einzelne Schritte und die vollständige Reaktion und bewahren Sie die Konfiguration zusammen mit den Ergebnissen auf. Wiederholen Sie die Tests nach wesentlichen Änderungen und gleichen Sie Schlussfolgerungen mit der für die jeweilige Version geltenden Dokumentation ab. Ziel ist nicht der abstrakte Nachweis, dass ROS 2 „Echtzeit“ ist, sondern die Feststellung, ob eine definierte Implementierung definierte Anforderungen unter dokumentierten Bedingungen erfüllt. Die herangezogenen Quellen belegen Konfigurations- und Analysefähigkeiten, aber keine universelle Einhaltungsgarantie für jeden Roboter.