PREEMPT_RT für Embedded Linux: Wann hilft es bei Zeitvorgaben?
PREEMPT_RT kommt infrage, wenn ein Gerät mit Linux eine wichtige Aufgabe zu spät erledigt, weil das Betriebssystem sie zu lange auf ihre Ausführung warten lässt. PREEMPT_RT kann diese Verzögerung verringern. Die Aktivierung allein garantiert jedoch weder die Reaktionszeit des gesamten Geräts noch einen störungsfreien Betrieb. Vor der Entscheidung für eine Umstellung brauchen Sie eine zeitliche Anforderung, Messungen auf der Zielhardware und Klarheit darüber, wo die Verzögerung entsteht.
Für Produktverantwortliche ist diese Unterscheidung entscheidend. Eine verspätete Messung kann eine andere Lösung erfordern als die langsame Anzeige bereits erfasster Daten. Lautet der Auftrag nur „Zuverlässigkeit mit PREEMPT_RT verbessern“, kann ein Dienstleister das Ergebnis eines Systemtests verbessern, während das Problem des Nutzers bestehen bleibt.
Legen Sie zuerst fest, was rechtzeitig geschehen muss
Die Anforderung sollte Anfang und Ende des gemessenen Vorgangs beschreiben. Geht es um die Zeit vom Sensorsignal bis zur Änderung eines Ausgangs, vom Messbeginn bis zum gespeicherten Ergebnis oder vom Tastendruck bis zur Reaktion auf dem Bildschirm? Darauf aufbauend lassen sich die zulässige Dauer und die Bedingungen festlegen, unter denen sie eingehalten werden muss.
Halten Sie auch fest, welche Folgen eine Verspätung hat. Vielleicht muss eine Messung wiederholt, ein Ergebnis verworfen oder die Arbeit der Station unterbrochen werden. Das Team braucht diese Information, um die Fehlerbehandlung und den Testumfang festzulegen. Der Schutz von Menschen erfordert eine gesonderte Bewertung des gesamten Geräts; die Wahl des Kernels ersetzt diese Arbeit nicht.
Eine durchschnittliche Reaktionszeit reicht nicht aus, wenn schon eine einzelne Überschreitung den Prozess beeinträchtigt. Dann sollte der Bericht auch die größte beobachtete Verzögerung, die Anzahl der Überschreitungen und die Testbedingungen nennen. Der höchste Messwert beschreibt die untersuchte Stichprobe. Er ist keine garantierte Obergrenze für die gesamte Nutzungsdauer des Geräts.
Was PREEMPT_RT verändert
Der Linux-Kernel verwaltet den Zugriff von Programmen auf Prozessor und Hardware. PREEMPT_RT macht größere Teile seiner Arbeit unterbrechbar. Dadurch kann eine Aufgabe, der eine höhere Priorität zugewiesen wurde, früher ausgeführt werden. Auch die Behandlung von Interrupts und Sperren zwischen Aufgaben ändert sich. Einige Kernelbereiche bleiben nicht unterbrechbar; die PREEMPT_RT-Dokumentation erläutert diese Grenzen.
Seit Version 6.12 gehört PREEMPT_RT auf unterstützten Architekturen zum regulären Linux-Kernel. Es muss jedoch in der Konfiguration aktiviert werden. Zusätzliche RT-Patches werden weiterhin entwickelt; der Leitfaden des Real-Time-Linux-Projekts beschreibt die Auswahl von Versionen und Einstellungen.
Für Auftraggeber zählt der Nachweis, dass die gewählte Konfiguration mit den Treibern zusammenarbeitet und die benötigte Aufgabe tatsächlich besser ausführt. Die Abnahmekriterien sollten das Verhalten des Geräts beschreiben und sich nicht auf die Bestätigung beschränken, dass ein RT-Kernel startet.
Wo ein anderer Kernel allein nicht weiterhilft
Die Reaktion eines Geräts hängt von mehr als dem Betriebssystem ab. Auch Speicherzugriffe, Verbindungen zwischen Komponenten und die hardwarenahe Software, die Firmware, spielen eine Rolle. Die Kernel-Dokumentation zu den Grenzen der Hardware erläutert, wie dadurch Verzögerungen entstehen können.
Wartet die Anwendung auf die Antwort eines externen Dienstes, beseitigt eine andere Zuteilung der Prozessorzeit diese Wartezeit nicht. Dauert die Berechnung selbst zu lange, muss ihre Ausführungszeit gemessen werden. PREEMPT_RT kann zur Lösung beitragen, sollte aber die Suche nach der Ursache nicht ersetzen.
Sie können auch beim bestehenden System bleiben. Erfüllt es die Anforderungen unter den vereinbarten Bedingungen, braucht eine Kerneländerung eine konkrete Begründung. Muss eine Aufgabe auch während eines Linux-Neustarts weiterlaufen, sollte eine separate Steuerung in Betracht gezogen werden. Dabei geht es um die Aufteilung der Verantwortung zwischen Gerätekomponenten, einschließlich der Kosten für Kommunikation, Tests und Wartung.
Beispiel: Ein Datenexport verzögert neue Messungen
Angenommen, eine Messstation erfasst Sensordaten, zeigt Ergebnisse an und ermöglicht dem Bediener den Export früherer Messungen. Während des Exports werden einige neue Messungen zu spät abgeschlossen und müssen wiederholt werden. Dies ist ein hypothetisches Beispiel, kein Kundenprojekt und kein Messergebnis für PREEMPT_RT.
Das Team prüft zunächst, ob die Messaufgabe zu spät Prozessorzeit erhält oder erst danach aufgehalten wird: beim Auslesen des Sensors, bei der Berechnung oder beim Speichern. Es kann helfen, das Schreiben des Berichts vom Messvorgang zu trennen. Ein Versuch mit RT ist dann begründet, wenn die Diagnose auf Verzögerungen hinweist, die sich durch diese Änderung beeinflussen lassen.
Bei der Abnahme müssen Messung und Export gleichzeitig auf dem vorgesehenen Gerät laufen. Neben der Einhaltung der Zeitvorgaben sind die Richtigkeit und Vollständigkeit der Ergebnisse zu prüfen. Auch der Bediener muss das Gerät weiterhin bedienen können. Bessere Zeiten durch das Weglassen von Daten lösen das Problem nicht. Ein langsamerer Export kann dagegen akzeptabel sein, wenn das Unternehmen dies bewusst vereinbart und der Nutzer den Fortschritt sieht.
Welche Nachweise Sie vor der Umstellung brauchen
Mit cyclictest lässt sich untersuchen, wie spät Testaufgaben nach dem vorgesehenen Zeitpunkt weiterlaufen. Das Werkzeug misst nicht den gesamten Weg vom Sensor bis zum abgeschlossenen Gerätevorgang. Das Team kann außerdem rtla timerlat einsetzen, um Verzögerungen zu untersuchen und bei Überschreiten eines gewählten Schwellenwerts eine Ablaufaufzeichnung zu speichern. Diese Ergebnisse ergänzen den Anwendungstest.
Fordern Sie einen Vergleich der bestehenden und der vorgeschlagenen Version anhand derselben Szenarien. Der Bericht sollte Hardware, Softwareversionen, Konfiguration, Last und Testdauer angeben. Berücksichtigen Sie Vorgänge, die das Gerät tatsächlich gleichzeitig ausführt, sowie seine Einsatzbedingungen. Prüfen Sie auch das Verhalten bei einer Zeitüberschreitung: Wird der Fehler sichtbar, und könnte ein unvollständiges Ergebnis als gültig weitergegeben werden?
Zu den Kosten der Umstellung gehören die Diagnose, mögliche Änderungen an Anwendung oder Treibern, ein Testaufbau und die spätere Prüfung von Updates. Vereinbaren Sie, wer die gewählte Version pflegt, nach Änderungen erneut testet und die Rückkehr zur vorherigen Version vorbereitet, falls ein Update den Betrieb verschlechtert.
Ein klarer Auftrag beginnt daher mit einem konkreten Vorgang und einem Abnahmekriterium: „Messungen müssen auch während eines Exports innerhalb der vereinbarten Zeit abgeschlossen sein; jede Überschreitung muss erkannt werden.“ Damit lässt sich beurteilen, ob PREEMPT_RT das Problem des Produkts löst und welche Arbeiten tatsächlich erforderlich sind.
