Was ist Real-Time?

Was ist Real-Time?

In den letzten Monaten habe ich mich mit Echtzeitsystemen und dem Konflikt zwischen zwei wichtigen Ansätzen beschäftigt. Diese Konflikt hat mich veranlasst, tiefer über das Konzept der zeitgesteuerten Systeme nachzudenken, und ich beginne, dies als einen bedeutenden und wertvollen Paradigmenwechsel im Vergleich zu meinem früheren Verständnis zu betrachten.

Um die Weichen richtig zu stellen, müssen wir mit dem Verständnis des Konzepts der „Echtzeit“ beginnen. In diesem Artikel werde ich „Echtzeit“ als Synonym für „deterministisch“ verwenden. Echtzeit erfordert, dass jede Aktion, die in einem Echtzeitsystem ausgeführt wird, zu einem festgelegten Zeitpunkt abgeschlossen sein muss (innerhalb vorgegebener Fehlergrenzen und mit einer vorgegebenen maximalen Unsicherheit, auch Jitter genannt).

Der klassische Umgang mit Echtzeitanforderungen beginnt mit der Beobachtung, dass die Welt um uns herum asynchron ist. Wir werden ständig mit Ereignissen bombardiert, auf die wir reagieren müssen. Echtzeit-Systeme sind daher so konzipiert, dass sie vorhersehbar reaktiv sind. Externe Ereignisse führen zu Unterbrechungen, die die notwendigen Aktionen auslösen können, um auf die Ereignisse zu reagieren. Synchronisationsmechanismen (z.B. Semaphoren, Spinlocks, etc.) werden verwendet, damit die Software warten kann und bereit ist, „sofort“ zu reagieren, wenn es etwas zu tun gibt. Wenn Konflikte durch das Eintreffen mehrerer eng beieinander liegender (oder gleichzeitiger) Ereignisse entstehen, werden die Konflikte zunächst durch die Anwendung des Prioritätskonzepts und dann durch den Einsatz cleverer und komplexer Planungsalgorithmen gelöst. Meines Erachtens ist dies eine Verschwendung von Rechenleistung und sollte durch einen anderen, unzuverlässigen Mechanismus zur Erreichung der gewünschten Ziele von Leistung und Reaktivität ersetzt werden.

Solche Systeme sind sowohl weit verbreitet als auch extrem leistungsfähig. Leider ist es sehr schwierig, sie zu zertifizieren, wenn es um die funktionale Sicherheit geht. Das Problem resultiert typischerweise aus der Notwendigkeit, nachzuweisen, dass die Fehlertoleranzzeiten eingehalten werden. Wird ein sicherheitsrelevantes Problem erkannt, muss das System innerhalb einer bestimmten maximalen Zeitspanne reagieren, in der der Fehler toleriert werden kann. In einem normalen POSIX[1]-orientierten Echtzeitbetriebssystem (RTOS) wird die tatsächliche Reaktionszeit durch den internen Zustand des Systems und durch asynchrone Ereignisse aus unabhängigen Quellen beeinflusst. So kann beispielsweise die Anzahl der aktiven Threads die Zeit für die Einplanung beeinflussen. Da die Leistung des Systems bei der Reaktion auf ein Problem nicht genau vorhergesagt werden kann, ist die Zertifizierung eine Herausforderung. Man ist gezwungen, statistische Argumente zu verwenden, die einen ausreichend großen Stichprobenraum erfordern, um sinnvoll zu sein. Dies wiederum führt zu umfangreichen und zeitaufwändigen Tests.

Seit vielen Jahren ist dies auch meine Ansicht. Ich finde es jetzt faszinierend zu beobachten, wie diese Sicht durch meine jüngste vertiefte Analyse des Konzepts der zeitgesteuerten Systeme verändert wird.

Lassen Sie uns damit beginnen, die Idee des Determinismus noch einmal zu überdenken. Jede Aktion in einem deterministischen System wird zu einem bestimmten Zeitpunkt ausgeführt. Wenn dies aufgezeichnet würde, wäre das Ergebnis eine einfache Liste von Zeiten und Aktionen. Was passiert, wenn wir das umkehren? Lassen Sie uns alle anderen Unterbrechungen im System eliminieren und nur den Timer-Interrupt verwenden. Der Timer kann dann verwendet werden, um jede Aktion in unserer Liste auszulösen, so dass sie genau zum richtigen Zeitpunkt durchgeführt wird. Das Ergebnis ist die Schaffung eines streng deterministischen Systems anstelle eines „reaktiven“ Systems.

Was sind die Stolpersteine, die es zu berücksichtigen gilt?

Die Konstruktion der Zeittabelle ist eine komplexe Aufgabe. Es erfordert ein detailliertes Verständnis des dynamischen Verhaltens des Systems, das nur selten verfügbar ist. Es ist selten, eine Software-Architekturanalyse zu finden, die ausreichend tief geht, um Timing-Interaktionen vollständig zu beschreiben. Darüber hinaus kann die Integration aller erforderlichen Aktivitäten in ein einziges Gesamtkonzept leicht eine große Anzahl von Ingenieurstunden in Anspruch nehmen, wenn sie von Hand durchgeführt wird. Berichten zufolge hat die Luft- und Raumfahrtindustrie Erfahrung damit, Monate auf diese Weise zu verbringen. Dies ist ein Bereich, der eine gute Tool-Unterstützung erfordert, um die Suche nach einer optimalen Lösung zu automatisieren (oder um zu erkennen, wenn keine Lösung existiert).

Wie sieht es mit externen Ereignissen aus, die wirklich asynchron sind? Diese müssen durch eine Abfrage in so regelmäßigen Abständen bewältigt werden, dass immer wieder kritische Ereignisse sofort bemerkt werden. Dies ist jedoch nicht die klassische „aktive Warteschleife“, die eine unbegrenzte Verschwendung von Verarbeitungskapazität darstellt. Stattdessen ist es ein wiederholter Zeittrigger in kontrollierten Intervallen, um das Auftreten eines potenziellen Ereignisses zu überprüfen. Wenn ein Überlauf des Eingangspuffers, der zum Verlust von Daten führt, ein Problem darstellen würde, muss das System oft genug anfragen, um sicherzustellen, dass dies nicht passieren kann. Ebenso, wenn der Unterlauf des Ausgangspuffers ein Problem darstellt, müssen diese Puffer auch regelmäßig neu gefüllt werden, solange Daten zum Senden verfügbar sind.

Meine erste Reaktion auf das Konzept der kontinuierlichen Anfrage ist eine reflexartige Ablehnung. Das wichtigste Argument ist, dass es sich um eine unproduktive Nutzung der Verarbeitungszeit handelt. Die verlorene Zeit wird jedoch gezählt, indem man addiert, wie oft das System anfragt und nichts zu tun findet. Der Vorteil bei zeitgesteuerten Systemen ist, dass eine absolute Garantie für die Häufigkeit und den Zeitpunkt aller beteiligten Verarbeitungsschritte besteht. Die Abfragefrequenzen müssen bei jedem Schritt entlang des Datenwegs an die Verarbeitungszeiten angepasst werden. Die Anzahl der „unproduktiven“ Umfragen ist am Ende sehr gering.

Dieses Konzept kann auch die Anforderungen der funktionalen Sicherheit erfüllen, denn es behält das Zeitverhalten des Systems den Aspekt der vollständigen Deterministik bei. Das absolut zuverlässige Verhalten des Systems ermöglicht es, leicht zu überprüfen, ob Probleme innerhalb der vorgegebenen Zeit nach der Erkennung behoben werden.

Ein weiteres Argument gegen das zeitgesteuerte Konzept ist, dass ein erheblicher Teil der Verarbeitungskapazität ungenutzt ist. Das für eine Aktion reservierte Zeitintervall muss lang genug sein, um die Worst-Case-Durchführungszeit zu berücksichtigen. Normalerweise werden die Aktionen früher abgeschlossen, so dass das System bis zum nächsten Triggerzeitpunkt nichts zu tun hat. Ich habe vor kurzem ein Unternehmen gesehen, das eine Lösung für dieses Problem hat. Ihr RTOS, das für die Unterstützung zeitgetriebener Konzepte entwickelt und optimiert wurde, ermöglicht das Zusammenleben mit einem zweiten Betriebssystem. Dieses zweite Betriebssystem (z.B. Linux) wird dann als „Leerlauf-Task“ des zeitgesteuerten RTOS geplant. Dies ermöglicht extrem starke Echtzeitgarantien in der zeitgesteuerten Umgebung und ermöglicht es weniger zeitkritischen Aktivitäten, in einer traditionelleren Umgebung zu arbeiten.

Ich habe erkannt, dass der klassische POSIX-orientierte Echtzeitansatz nur relativ schwache Garantien für deterministisches Verhalten bieten kann. Der zeitgesteuerte Ansatz bietet viel mehr Garantien, erfordert aber eine beträchtliche Menge an Infrastruktur (spezialisiertes Betriebssystem und Werkzeuge), um sein Versprechen erfüllen zu können. In der Welt von morgen, mit der Entwicklung des autonomen Fahrens und der daraus resultierenden Notwendigkeit von „fail-operational“ Verhalten, wird die zeitgesteuerte Philosophie wahrscheinlich zu einem sehr wertvollen Werkzeug werden.

[1] Portable Operating System Interface, ISO/IEC/IEEE 9945 konforme Programmierschnittstelle zwischen Anwendungssoftware und Betriebssystem

‍