Echtzeiteigenschaften und Latenzzeiten Ist mein System so Real-Time wie gedacht?

Anbieter zum Thema

Open Source Automation Development Lab (OSADL) eG

MicroConsult Academy GmbH

Moderne Produktionsanlagen nutzen Embedded-Systeme zur Steuerung, die zuverlässig und vorhersagbar reagieren müssen. Sensoren senden Daten an zentrale Computer, die darauf basierend Aktionen auslösen. Dabei sind geringe Latenzzeiten entscheidend, um alle Abläufe möglichst in Echtzeit zu gewährleisten. Aber wie schaffe ich es, diese Latenz so genau wie möglich zu ermitteln?

Moderne Produktionsprozesse benötigen komplexe Werkzeugmaschinen und Produktionsanlagen, wobei die Kontrolle der Abläufe in den einzelnen Maschinen und Systeme von Steuerungscomputern übernommen werden. Diese sogenannten Embedded-Systeme bestehen in der Regel aus einem Rechner mit einem Prozessor, der sogenannten CPU (Central Processing Unit), und der zugehörigen Peripherie, wie Arbeitsspeicher, Massenspeicher, Kommunikationseinheiten, Ein- und Ausgabeeinheiten und Netzteil. Da diese Computer für die zuverlässige Steuerung von Prozessen verantwortlich sind, ist es unabdingbar, dass das Verhalten dieser Systeme jederzeit vorhersehbar ist und über die gesamte Lebensdauer auch bleibt. Auf die Steuerungstechnik bezogen bedeutet dies, dass ein System jederzeit, egal in welchem Betriebszustand, in einem vorhersagbaren Zeitintervall auf Ereignisse oder Zustände reagieren muss.

Besonders klar und eindeutig wird dies, wenn man Endlagenschalter betrachtet, die einen Antrieb beim Erreichen einer Endlage abschalten oder aber auch Aktoren, die bei das Öffnen eines Zugangs überwachen und dies nur bei Stillstand einer Maschine zulassen dürfen. War es früher üblich, dass ein Sensor über analoge Elektronikkomponenten mit einem Aktor verbunden war und auf diesen wirken konnte, ist es heute gängige Praxis, dass alle Sensordaten einer Anlage durch eine zentrale Steuerung erfasst werden. Dort werden die auflaufenden Daten verarbeitet und es wird „entschieden“, wie sich das System verhalten soll und welche Steuervorgänge aufgrund der Datenlage getroffen werden. Hier zeigt sich ein wesentlicher Unterschied zur direkten, analogen Verarbeitung von Daten, wie z.B. Schaltzuständen. Bei diesen erfolgt die Verarbeitung unmittelbar und direkt, während bei einer computerbasierten Steuerung das Auswerten der Daten eine gewisse Zeit in Anspruch nimmt und damit die Reaktion auf ein Ereignis immer mit einer gewissen Verzögerung stattfindet. Dies ist für sich betrachtet grundsätzlich kein Problem und bei jeder Art digitaler Datenverarbeitung üblich. Jedoch muss bei dieser Art der Steuerung eine zeitliche Grenze festgelegt werden, die ein System als Reaktion auf ein Ereignis niemals über-schreiten darf. Es muss weiterhin sichergestellt sein, dass das System in jedem Zustand innerhalb dieser Zeit reagiert.

Bildergalerie

Dafür hat sich der Begriff der Latenz als Kenngröße etabliert. Diese ist eine entscheidende Kenngröße und bei der Projektierung z.B. einer Maschinensteuerung je nach Anforderung zu beachten.

Ermittlung der Echtzeiteigenschaften

Als vor etwa zwei Dekaden Computer in industriellen Steuerungen aus einem Rechenkern und überschaubarer Peripherie bestanden, war es relativ einfach möglich, die Latenzen einer Steuerung zu bestimmen, auf denen ein solches System basierte: Für jede Instruktion war bekannt, wie viele Programmschritte die Verarbeitung durch die CPU benötigt. So war es möglich, unter Zuhilfenahme des Programmcodes genau festzustellen, wie lange die Ausführung eines Programmteiles, wie z.B. die Verarbeitung einer Interrupt-Service-Routine (ISR) dauert.

Um dies zu ermitteln, musste im Programm nachgesehen werden, welche Instruktionen für eine bestimmte Aktion (z.B. Ablauf einer ISR) verarbeitet werden. Mithilfe einer Tabelle des Computerherstellers, in der die Dauer einzelner Programmanweisungen gelistet war, konnte dann durch einfaches Aufaddieren der Zeiten die Gesamtdauer eines Ablaufes bestimmt werden. Durch diese sogenannte Pfadanalyse war so die Latenz einfach zu ermitteln, indem man das Programm analysierte und die Anzahl der Programmschritte der zeitkritischen Sequenzen und deren Ablaufdauer bestimmte.

Bei heutigen Prozessoren ist die Bestimmung der Latenzen auf diese Weise nicht mehr möglich. Die Aufgabe der CPU als zentrales Element einer Steuerung ist zwar in modernen Systemen im Wesentlichen gleich geblieben, jedoch kamen durch die stetige Weiterentwicklung Komponenten und beeinflussende Faktoren hinzu:

• Ein- bis mehrstufiger Cache, eine oder mehrere Recheneinheiten für Fließkommaoperationen, eine Einheit zur Grafikausgabe.

• Sogenannte Schlaf- und Leistungsstadien. Diese sorgen dafür, dass die Prozessoren in Bezug auf Energieverbrauch und Wärmeentwicklung effizient genutzt werden.

• Aktuelle Prozessorgeneration bestehen heute in der Regel nicht mehr nur aus einer CPU, sondern integrieren mehrere CPU-Kerne (z.B. 2,4,6 usw.) auf einem Chip und bestehen so streng genommen aus mehreren Prozessoren und der dazugehörigen Peripherie.

Aufgrund dieser Komplexität sind die Vorgänge, die auf einer CPU ablaufen, um das Management des Prozessors zu organisieren, nicht mehr ohne Weiteres vorhersehbar oder mit einer Pfadanalyse kalkulierbar. Dies führt bei den Entwicklern von Echtzeitsystemen zu einem Dilemma: Die zu erwartende Zeit, die vom Zeitpunkt des Eintreffens eines Signals bis zur Reaktion des Systems benötigt wird (Latenz), ist nicht mehr direkt zu bestimmen. Die einzige Möglichkeit, auf einem solchen System die Latenz zu ermitteln, ist die Zeit zu messen, die vom Ein-treten eines externen Ereignisses bis zur Verarbeitung im System vergeht. Dazu hat sich im Be-reich der Echtzeitsysteme auf Basis von Linux mit PREEMPT_RT ein Verfahren etabliert, das im Folgenden beschrieben wird.

Wo wird die Zeit verbraucht – Latenzen auf der Spur

Zur Verarbeitung eines Signals wird an verschiedenen Punkten Zeit benötigt, die in Ihrer Summe dann die resultierende Latenz ergeben. Es lassen sich dabei drei Stellen in der Prozessverarbeitung nennen, die summiert die Ursache für die Latenz bilden (siehe Abbildung 1):

• Offset: Zeitverbrauch, um den Start der Bearbeitungsroutine zu initiieren.

• Aufwachzeit: Der Zeitraum, bis die Routine in der Auftragsbearbeitung eingereiht ist.

• Umschaltzeit: Zeit, die zum Umschalten in den neuen Kontext benötigt wird.

Dabei unterliegen die einzelnen Latenzen, sowie deren Summe, Schwankungen (sog. Jitter), die unterschiedliche Ursachen haben können (z.B. Signallaufzeiten, hardware- und/oder softwarebedingte Unterbrechungen).

Latenzermittlung durch Simulation einer Echtzeitanwendung

Zur messtechnischen Ermittlung der Latenzen wird die interne Infrastruktur eines Systems und hierbei die verfügbaren Zeitgeber genutzt. Die Messung wird mit dem Programm cyclictest ausgeführt. Diese Software ist in der RT-Testsuite enthalten und bei den großen Linuxdistributionen als Paket verfügbar, der Quellcode ist auch bei https://www.kernel.org/kernel.org/pub/linux/utils/rt-tests/ verfügbar und kann von dort bezogen, kompiliert und installiert werden. Mit dem daraus kompilierten Programm wird das Programm cyclictest gestartet. Zur Durchführung eine Messung wird das Programm wie folgt aus der Kommandozeile gestartet (Beispiel):

# cyclictest -l100000000 -m -S -p99 -i200 -h400

Die Aufrufparameter von cyclictest haben hier folgende Bedeutung:

-l100.000.000 Anzahl der Iterationen
-m Allokation des gesamten, benötigten Speichers
-S Ablauf auf allen CPU-Kernen
-p99 Festlegen der Priorität, hier als Echtzeit
-i200 Zeitintervall 200 µs
-h400 Maximum der gespeicherten Klassen

Dadurch wird in der vorgestellten Konfiguration für jeden Prozessorkern zyklisch ein Timer für ein festgelegtes Intervall i gestartet und die geplante Startzeit t₀ vermerkt. Anschließend wird der reale Startzeitpunkt t₁ des Timerstarts ermittelt. Aus diesem ergibt sich die Latenz t_L als Differenz der tatsächlichen Startzeit t₁ zur geplanten Startzeit t0 _:

t_L= t₁ - t₀

In der Praxis wird die Messung für jeden zu messenden Prozessorkern gestartet, über eine vorbestimmte Anzahl von Messungen iteriert und die auftretenden Latenzen werden gezählt. Um dabei aussagekräftige Ergebnisse zu erhalten, ist es üblich, über mehrere Stunden zu messen, z.B. 100 Millionen Messzyklen mit jeweils 200 µs Dauer (entspricht einer Messdauer von 100.000.000 x 200 µs = 20.000 s, also 5:33:20 h). Die Messung schließt mit der Ausgabe der Latenzdaten in Form einer Liste, wobei Spalte 1 die Klassen des Histogramms enthält, hier je µs eine Klasse, und die folgenden Spalten die Anzahl der in der Messung jeweils aufgetretenen Klassen pro CPU-Kern enthält (Spalte 2: CPU-Kern #0, Spalte 3: CPU-Kern #1 usw.):

Je mehr Zyklen die Messung durchläuft (d.h. je länger diese durchgeführt wird), desto genauer ist das Ergebnis. Je häufiger diese Messungen wiederholt werden, desto sicherer lassen sich Aussagen über die Echtzeitfähigkeit des untersuchten Systems machen.

Extern getriggerte Latenzermittlung

Ein weiteres Verfahren zur Latenzermittlung bietet die OSADL-Latencybox. Diese fungiert als zyklischer Trigger mit konfigurierbarer Zyklendauer für externe Ereignisse und nimmt die Antwort des Systems entgegen. Das externe Signal triggert das zu messende System über sie serielle Schnittstelle. Dort erfolgt die Verarbeitung des Echtzeitprozesses, der Abschluss wird jeweils über das Parallelinterface signalisiert. Dieses Signal wird von der OSADL-Latencybox registriert und abgelegt. Nach Ablauf der Messung steht ein gesammelter Datensatz als Histogramm zur Verfügung und kann zur weiteren Auswertung als Grafik ausgegeben werden.

Innovate Your Software – for a Smarter Future

Deutschlands Leitkongress der Embedded-Softwarebranche

Das Programm des ESE Kongress umfasst 96 Vorträge, 15 Seminare und 3 Keynotes. Seien Sie dabei, wenn sich die Embedded-Software-Community trifft, und nutzen Sie Diskussionen und Expertengespräche für einen ergiebigen Wissenstransfer und erfolgreiches Networken. Während der vier Kongresstage erwartet Sie zudem eine große Fachausstellung mit den führenden Firmen der Branche. Erfahren Sie alles über die neuesten Trends, Herausforderungen und Lösungen im Embedded Software Engineering, von KI, Safety und Security bis hin zu Management und Innovation.

Jetzt mehr erfahren und anmelden!

Latenzermittlung auf Betriebssystemebene

Neben der oben beschriebenen Latenzermittlung gibt es auch die Möglichkeit, diese auf Betriebssystemebene zu erfassen. Dazu wird der Linuxkernel über eine Softwareerweiterung (Patch) mit zusätzlicher Funktionalität versehen. Dieser latency_histograms.patch wird von OSADL gepflegt und bereitgestellt und ist für alle aktuellen Versionen (Kernelversionen ≥ 4.19) für Linux PREEMPT_RT zum Download verfügbar (https://www.osadl.org/?id=2943).

Interne Latenzhistogramme

Durch Anwendung und Konfiguration des Patches können innerhalb des Betriebssystems unterschiedliche Latenzen gemessen und - im Gegensatz zur o.g. Latenzermittlung mit cyclictest - mit zeitlichem Bezug erfasst werden. Im Einzelnen können mit dem Patch folgende zeitliche Messstrecken erfasst werden (Abbildung 3):

• missed timer offset - zeigt die Differenz zwischen dem effektiven und dem geplanten Programmstart

• wakeup - bestimmt die Dauer der Aufwachzeit bis zur Übergabe der Kontrolle an diesen Prozess

• timerandwakeup - die Gesamtlatenz als Summe des Timer-Offsets missed timer offset und der Aufwachlatenz wakeup

• context switch time - Messung vom Beginn des Kontextwechsels bis zur Rückkehr des entsprechenden Systemaufrufs

• timerwakeupswitch - die Gesamtlatenz als Summe der Latenz für den verpassten Timer-Offset missed timer offset , das Aufwachen wakeup und den Kontextwechsel context switch time aufzeichnet

Diese Daten werden bei aktivierten Latenzhistogrammen unter dem Systemverzeichnis /sys/kernel/debug/latency_hist mit dem jeweiligen Namen des Histogramms abgelegt. Diese Daten können nun zyklisch (z.B. im 5 Minuten Intervall) abgerufen und ausgewertet werden. Anschließend müssen die Histogramme wieder zurückgesetzt werden, um dann erneut die Aufzeichnung zu starten.

Mit diesem Verfahren können die Daten zyklisch mit der Auflösung von einem sinnvoll gewählten Zeitraster erfasst und mit zeitlichem Bezug abgelegt werden. Es bietet sich an, diese Daten mit einer Monitoringsoftware aufzuzeichnen und auszuwerten. Durch die Darstellung entsteht die Möglichkeit, zu analysieren in welcher Phase der Preemption eine ungewollte Verzögerung verursacht wird.

Täter-/Opfer Tabelle

Weiterhin ermöglicht der Patch, in einem festgelegten Intervall den Namen des Prozesses, der die Verzögerung erfährt, sowie den Namen des verursachenden Prozesses pro Zyklus zu ermit-teln und mit diesem Verfahren eine Täter/Opfer-Tabelle (Tabelle 1) zu erstellen, die wertvolle Informationen zum Echtzeitverhalten bereitstellt:

In dieser sind die Prozesse absteigend nach Ihrer erzeugten Verzögerung dargestellt und zeigen die dadurch verursachte Latenz sowie den Prozess, dessen Ausführung während dieser Phase verzögert wurde. Durch Analyse dieser Tabelle ist es möglich, Prozesse zu identifizieren, die Latenzen verursachen.

Interpretation von Latenzmessungen

Bei einem korrekt funktionierenden Echtzeitsystem ist – als Faustformel – davon auszugehen, dass die Anzahl der Zyklen, die erforderlich sind, um auf ein Ereignis zu reagieren bei je nach Prozessor etwa 100.000 Zyklen liegt. Daraus lässt sich einfach anhand des Prozessortaktes freq eine Formel entwickeln, womit die höchste zu erwartende Latenz t_Lat abgeschätzt werden kann:

t_Lat = 10⁵*1/freq

Damit ergibt sich für eine CPU, die mit einem Prozessortakt von 1,5 GHz arbeitet, eine zu erwartende höchste Latenz von 67 µs:

t_Lat = 10⁵ * 1/(1.5*10⁹ ) s = 6.67 * 10^-5 = 67µs

Somit eröffnet die Faustformel die Möglichkeit, eine grobe Abschätzung eines Systems vorzunehmen.

Auswertung durch Erzeugung von Latenzplots

Als Ergebnis der im ersten Abschnitt beschriebenen Latenzmessung mit cyclictest wird ein Histogramm in Form einer Tabelle mit der Häufigkeit der aufgetretenen Latenzen ausgegeben. Zur Auswertung der Messung ist die grafische Darstellung mit einem Programm wie gnuplot geeignet. Als Ergebnis entsteht ein Latenzhistogramm, welches die Verteilung der Latenzen zeigt und einen Überblick über das Echtzeitverhalten des untersuchten Systems gibt.

Beispielhaft sind hier drei typische Beispiele von verschiedener Latenzaufzeichnungen dargestellt, deren Verlauf in dieser Form häufig anzutreffen ist:

Langzeiterfassung

Die erfassten Latenzdaten können weiterhin dazu benutzt werden, um die Aufzeichnung der Latenzen über einen längeren Zeitraum darzustellen. Dazu werden jeweils neu erzeugte Latenzhistogramme an eine dreidimensionale Darstellung angefügt, wodurch es möglich wird, ein nahezu beliebig langes Diagramm zu generieren und somit auch eine Darstellung über einen sehr langen Beobachtungszeitraum zu erzeugen. Durch die logarithmische Y-Achse können mit Hilfe dieser Darstellung selbst singuläre Latenzspitzen deutlich erkannt werden. Ebenso werden Veränderungen im Echtzeitverhalten durch z.B. Veränderungen an der Kernelkonfiguration sichtbar.

Das komplette Vorgehen aus Latenzmessung, Datenspeicherung und anschließender Diagrammerzeugung lässt sich sehr gut per Skript, z.B. bash automatisieren.

Zusammenfassung

Die Ermittlung von Latenzen ist eine unverzichtbare Maßnahme, um die Echtzeiteigenschaften eines Systems aufzeigen zu können. Die unmittelbare Berechnung der Latenzen aus dem Programmkontext ist bei aktuellen Prozessoren nicht mehr möglich, womit es keinen direkten Nachweis für die Echtzeitfähigkeit gibt. Bei der Messung der Latenzen mit den aufgezeigten Verfahren ist zum einen die Möglichkeit einer schnellen Abschätzung des Latenzverhaltens gegeben, indem man die Latenzen erfasst und anhand eines grafischen Histogramms eine Abbildung dieser Latenzen erhält. Durch die Latenzermittlung können bei weitgehenderer Kenntnis der Hard- und Software eines Systems Einschätzungen zu Eigenschaften getroffen werden, die Einfluss auf die Latenzen haben. Zum anderen ist besonders die Langzeitmessung und deren Auswertung von entscheidender Bedeutung, weil mit dieser Art der Darstellung eine Dokumentation des Echtzeitverhaltens über lange Zeiträumen möglich ist und damit eine Aussage zum Determinismus eines Systems möglich wird. Weiterhin bietet die Latenzmessung die Möglichkeit, Umstände zu erkennen, die das Echtzeitverhalten ungünstig beeinflussen. Neben hardwarebedingten Latenzen oder solchen, die durch das Management im BIOS ihre Ursachen begründet finden, können auch Fehler in der Softwarekonfiguration des Betriebssystems oder Interferenzen mit anderer Hardware erkannt werden.

Durch die Anwendung ergänzender Software in Form der OSADL Add-on-Patches können weitere, interne Latenzmessungen durchgeführt werden und sogar die Quellen der verursachenden Software analysiert werden. All diese Möglichkeiten sind durch die Quelloffenheit des Betriebssystems Linux und der angewendeten Software für jede Person, die Software entwickelt oder testet, gegeben. Jedoch ist eine sehr gute Kenntnis des Betriebssystems, der angewendeten Treiber und der Hardwarekomponenten nötig, um die komplexen Zusammenhänge bei der Ermittlung der Ursachen unerwünschter Latenzen richtig zu interpretieren. (sg)

Der Beitrag wurde mit freundlicher Genehmigung des Autors dem Tagungsband Embedded Software Engineering Kongress 2023 entnommen.

(ID:50213417)