Echtzeitfähigkeit

Die Theorie des Echtzeitsystems (englisch real-time system) definiert dieses als ein Computersystem, das ein Ergebnis innerhalb eines vorher fest definierten Zeitintervalles garantiert berechnet, also bevor eine bestimmte Zeitschranke erreicht ist. Die Größe des Zeitintervalles spielt dabei keine Rolle: Während bei einigen Aufgaben (Motorsteuerung) eine Sekunde bereits zu lang sein kann, reichen für andere Probleme Stunden oder sogar Tage. Ein Echtzeitsystem muss also nicht nur ein Berechnungsergebnis mit dem richtigen Wert, sondern dasselbe auch noch rechtzeitig liefern. Andernfalls hat das System versagt.

In der Praxis lässt sich eine beliebig kleine Zeitschranke mangels genügend schneller Hardware nicht immer darstellen. Daher spricht man auch von „in Echtzeit“, wenn Programme ohne spürbare Verzögerung arbeiten. Diese Definition ist jedoch sehr unsauber. Auch bei Computerspielen spricht man manchmal von Echtzeit, dabei meint man, dass das Spiel über eine eigene, kontinuierlich fließende Zeit verfügt, statt das Spielgeschehen mittels Trigger oder ähnlichen Mechanismen aufrecht zu erhalten. Grundsätzlich falsch ist es, „Echtzeitsystem“ als Synonym für „besonders schnell“ anzusehen, da auch ein langsames System für gewisse Aufgaben schnell genug sein kann.

Harte und weiche Echtzeit

Abhängig von den Folgen wird manchmal zwischen harter Echtzeit (englisch: hard real-time) und weicher Echtzeit (englisch: soft real-time) unterschieden. Hierfür gelten jeweils unterschiedliche Echtzeitanforderungen.

• weiche Echtzeitanforderungen: Solche Systeme arbeiten typischerweise alle ankommenden Eingaben schnell genug ab. Die Antwortzeit erreicht einen akzeptablen Mittelwert; signifikante Abweichungen von diesem sind selten, obwohl grundsätzlich mit vereinzeltem Auftreten größerer Abweichungen zu rechnen ist. Das Wesen einer weichen Echtzeitanforderung wird bei folgender durchaus praktizierten Entwicklungsvariante deutlich. Dabei ist das abschätzende Bauchgefühl eines möglichst erfahrenen Entwicklers Grundlage eines heuristischen Trial-and-error-Prozesses, der dann letztendlich zu einem - mitunter ebenfalls per Bauchgefühl bewertetem - befriedigendem Ergebnis führt.
• harte Echtzeitanforderungen: Eine Überschreitung der Antwortzeit wird als ein Fehler gewertet. Nach einer exakten Zeiterfassung der bereitzustellenden Anwendung sind Berechnungen gemäß der Theorie der Echtzeit-Systeme notwendig. Echtzeitsysteme liefern das korrekte Ergebnis immer innerhalb der vorgegebenen Zeitschranken. Auf diese Eigenschaft kann man sich beim Einsatz eines Echtzeitsystems verlassen.

Beispiele:

• Systeme für Videokonferenzen müssen Bild und Ton innerhalb von Mikrosekunden aufnehmen, vorverarbeiten, versenden und darstellen. Wenn dies bei einigen Bildern nicht gelingt, „ruckelt“ die Darstellung zwar etwas, es kann danach jedoch ohne negative Folgen weitergearbeitet werden. Das System muss also nur weiche Echtzeitanforderungen erfüllen.
• Die elektronische Motorsteuerung in einem Auto muss harte Echtzeit erfüllen, sonst stottert der Motor oder das Auto bleibt stehen. Der Ausfall bzw. eine nicht korrekt eingehaltene harte Echtzeit kann einen mechanischen Schaden oder im schlimmsten Fall einen Unfall verursachen.

Je nach Problemstellung und Blickwinkel wird auch folgende Definition verwendet:

• weiche Echtzeitanforderungen: Das System muss in der angegebenen Zeitspanne reagieren, nicht jedoch das vollständige Ergebnis liefern. Tritt keine Reaktion ein, gilt der Vorgang als fehlgeschlagen und wird abgebrochen. Alternativ können weiche Echtzeitsysteme auch zeitweise das Ergebnis zwar korrekt, aber zu spät liefern.
• harte Echtzeitanforderungen: Das System muss im definierten Zeitfenster das Ergebnis vollständig präsentieren.

Innerhalb der weichen Echtzeitsysteme finden sich manchmal weitere Klassifikationen, die die Überschreitungen der Antwortzeiten feiner differenzieren. Häufige Kriterien sind:

• Das Ergebnis hat keinen Wert mehr; die Berechnung wird abgebrochen und verworfen.
• Der Wert (die Bedeutung oder der Nutzen, nicht der numerische Wert) des Ergebnisses sinkt ab Ende der Antwortzeit.
• Eine Überschreitung der Antwortzeit wird hingenommen, und das Ergebnis wird angenommen, wenn es vorliegt.

Bereits die Definition von weichen Echtzeitsystemen ist von eher umgangssprachlicher Natur, so dass eine feinere Unterteilung erst recht schwierig zu geben ist.

Die DIN-Norm 44300 definiert unter Echtzeitbetrieb (dort Realzeitbetrieb genannt) den Betrieb eines Rechnersystems, bei dem Programme zur Verarbeitung anfallender Daten ständig betriebsbereit sind, derart, dass die Verarbeitungsergebnisse innerhalb einer vorgegebenen Zeitspanne verfügbar sind. Diese Begriffsnorm hat sich in der Praxis als alleinig akzeptierte Definition nicht durchsetzen können, es dominieren die Begriffe aus dem englischen Sprachraum.

Umsetzung

Echtzeit beschreibt das zeitliche Ein-/Ausgangsverhalten eines Systems, sagt aber nichts über dessen Realisierung aus. Ein Echtzeit-System kann ein Rechner mit einer geeigneten Software, kann aber auch eine reine Hardware-Lösung sein. Für Anforderungen mit sogenannten weichen Grenzen werden normalerweise reguläre EDV-Systeme verwendet. Für Anforderungen mit harten Grenzen werden spezielle Architekturen (Hardware und Software) verwendet. Prinzipiell ist auch ein PC echtzeitfähig, allerdings nicht oder nur sehr bedingt, wenn er mit klassischen Multitasking-Betriebssystemen betrieben wird. Echtzeitbetriebssysteme sind oftmals ebenfalls multitaskingfähig, verfügen jedoch über einen anderen Scheduler als konventionelle Systeme. Es gibt auch Lösungen, bei denen ein bestehendes Standardbetriebssystem durch Hinzufügen spezieller Software echtzeitfähig gemacht wird. Dies hat den Vorteil, dass nur die wirklich zeitkritischen Vorgänge im Echtzeitsystem ablaufen müssen und für den Rest die normalen APIs (inkl. Compiler oder GUIs) des zugrundeliegenden Betriebssystems verwendet werden können.

Auch in speicherprogrammierbaren Steuerungen (SPS) und Prozessleitsystemen (PLS) werden Echtzeitbetriebssysteme eingesetzt, die aber dem Anwender nicht direkt zugänglich sind.

Um die Echtzeitfähigkeit eines mittels Software realisierten Echtzeitsystems theoretisch nachweisen zu können, müssen die Häufigkeit der externen Ereignisse, die Laufzeit der einzelnen Programmteile und die Zeitschranken bekannt sein.

Die Software, die unter Echtzeitbedingungen läuft, muss einige Eigenschaften - insbesondere bei harten Grenzen - aufweisen:

• Die maximale Laufzeit eines Moduls muss berechenbar sein und darf keinen nicht oder nur bedingt beeinflussbaren Faktoren unterliegen. Dies ist ein Problem bei komplexer I/O (z. B. Festplatte mit Cache und automatischem Ruhezustand) oder bei einem Netzwerk mit nicht deterministischem Zeitverhalten (z. B. TCP/IP). Es muss daher dafür gesorgt werden, dass die Echtzeitmodule von der virtuellen Speicherverwaltung des Betriebssystems unbeeinflusst bleiben und niemals ausgelagert werden (typischerweise verwenden Echtzeitsysteme deshalb überhaupt keine virtuelle Speicherverwaltung).
• Bei Rekursion muss die maximale Rekursionstiefe, bei Schleifen muss die maximale Anzahl an Iterationen feststehen.
• Der Bedarf an Ressourcen, insbesondere der Bedarf an Speicher muss bekannt sein. Die Laufzeitumgebung und die Hardware müssen den Ressourcenbedarf decken können.
• Die Laufzeit von Betriebssystemaufrufen und von Routinen der Laufzeitumgebung muss mit berücksichtigt werden. Problematisch ist hier zum Beispiel der Einsatz automatischer Speicherbereinigung (Garbage Collector), dessen Laufzeit sehr pessimistisch abgeschätzt werden muss.
• Das Verhalten bei drohender Zeitüberschreitung muss definiert und vorhersehbar sein.

Beispiele für Echtzeitsysteme

Rechner zur Steuerung von technischen Einrichtungen oder Prozessen wie Maschinen, verfahrenstechnischen Anlagen oder Verkehrsmitteln sind praktisch immer Echtzeitsysteme. Ein Echtzeitsystem reagiert also auf alle Ereignisse rechtzeitig und verarbeitet die Daten „schritthaltend“ mit dem technischen Prozess. Es wird sozusagen nicht vom technischen Prozess abgehängt - weder im Normalfall noch in kritischen Situationen.

• Die Temperatur eines Apparates in einer verfahrenstechnischen Anlage ändert sich meist nur innerhalb von Minuten. Eine Steuerung, die innerhalb von mehreren Sekunden auf Abweichungen reagiert, kann daher noch als echtzeitfähig gelten. Die Reaktionszeit liegt im Sekundenbereich.
• Die Airbag-Steuerung im Auto muss dauernd und innerhalb kürzester Zeit die Messwerte der Sensoren verarbeiten und entscheiden, ob und wie stark der Airbag ausgelöst wird; die Reaktionszeit liegt im Bereich von 1 ms.
• Ein Antiblockiersystem (ABS) im Auto hat typischerweise eine Regelfrequenz von 1kHz, d. h. die Reaktionszeit liegt unter 1 ms.
• In Werkzeugmaschinen ändert sich die gegenseitige Lage von Werkstück und Werkzeug. Heutige CNC-Steuerungen haben zeitliche Auflösungen der Bewegungsregelung von 125 µs.
• In einem Auto muss das elektronische Motormanagement zu bestimmten Zeitpunkten seine Ergebnisse (einzuspritzende Benzinmenge, Zündzeitpunkt) liefern. Später eintreffende Ergebnisse sind wertlos. Die Reaktionszeit hängt direkt von der Drehzahl ab und geht für typische Motoren bei hohen Drehzahlen bei vielen Zylindern herunter bis auf 1 ms.
• Für die genaue Ablenkung von Elektronenstrahlen, z. B. beim Elektronenstrahlschweißen, müssen Magnetfelder mit Frequenzen von 100 kHz bis 1 MHz geregelt werden. Die Reaktionszeit liegt zwischen 1 µs und 10 µs.
• Raketentechnik: Die härtesten Echtzeitanforderungen betreffen die Patriot-Raketen, die zum Abschuss anderer Raketen eingesetzt werden. Bei Begegnungsgeschwindigkeiten von mehreren 1000 m/s und einzuhaltenden Trefferradien von weniger als einem Meter müssen Zeitschranken im Nanosekundenbereich eingehalten werden. Die Reaktionszeit geht bis unter 1 ns.

Gestaltungsparadigmen

Bei der Realisierung gibt es zwei Gestaltungsparadigmen: ereignisgesteuert und zeitgesteuert.

Bei der Ereignissteuerung wird auf ein von außen kommendes Ereignis (meist mittels Interrupt) schnellstmöglich reagiert, d. h. eine Verarbeitung gestartet. Gegebenenfalls wird eine gerade laufende Verarbeitung dabei unterbrochen. Die Ereignissteuerung hat den Vorteil, dass sie mit sehr geringem Zeitverlust auf das Ereignis reagiert. Weil sie intuitiv ist, ist sie auch weit verbreitet. Der Hauptnachteil ist, dass es nicht verhinderbar ist, dass mehrere Ereignisse innerhalb kurzer Zeit auftreten können und es damit zu einer Überlastung des Echtzeitsystems (mit Verlust von Ereignissen und/oder Überschreitung von Zeitlimits) kommen kann. Um dieses Problem zu umgehen, muss klar definiert werden, welche Ereignisse mit welcher maximalen Häufigkeit auftreten können. Typischerweise wird mittels Prioritäten bestimmt, in welcher Reihenfolge gleichzeitig auftretende Ereignisse abgearbeitet werden sollen. In einer harten Echtzeitumgebung muss sichergestellt werden, dass auch im ungünstigsten Fall (maximale Anzahl und Frequenz aller möglichen Ereignisse) selbst der Prozess mit der niedrigsten Priorität sein Ergebnis immer noch innerhalb der Zeitschranken abliefern kann, d. h. immer noch genügend Rechenzeit zugeteilt bekommt, um seine Aufgabe zu erfüllen.

Bei der Zeitsteuerung werden Verarbeitungen aufgrund eines vorher festgelegten Zeitplans gestartet. Jedem Prozess wird also eine genau definierte Zeitscheibe im Scheduler zugeteilt (z. B. alle 100 ms genau 10 ms). Der Vorteil liegt darin, dass Überlastungen grundsätzlich ausgeschlossen werden können (sofern der Prozess niemals die zugeteilte Zeit überschreitet). Das Verhalten der Anwendung ist für alle Zeit vorhersagbar, was die Zeitsteuerung für sicherheitskritische Anwendungen geeignet macht. Der Nachteil der Zeitsteuerung ist der höhere Planungsaufwand (die Zeitzuteilung muss während der Implementation der Prozesse genau bekannt sein) und der damit verbundene notwendige Werkzeugeinsatz. Ein weiterer Vorteil ist, dass bei der Zeitsteuerung die vorhandenen Ressourcen (CPU-Zeit, Speicher) zu 100 Prozent ausgelastet werden können, während das bei der Ereignissteuerung aufgrund ihrer Asynchronität nicht möglich ist. Bei der Ereignissteuerung muss bei den Ressourcen immer etwas Reserve eingeplant werden, damit das System bei großer Last Zeit „aufholen“ kann.

Siehe auch

• Echtzeit
• Maximale Laufzeit
• Echtzeitbetriebssystem
• Speicherprogrammierbare Steuerung
• Prozessleitsystem
• Simulation

Literatur

• Real-Time Systems – Hermann Kopetz; Kluwer Academic Publishers; ISBN 0-7923-9894-7
• Real-time Systems: Theory and Applications - H. S. M. Zedan; Elsevier Science Pub; ISBN 0444886257

Weblinks

• Beitrag "Comp.realtime: Frequently Asked Questions (FAQs)":
  • regelmäßig in der Newsgroup "comp.realtime" gepostet
  • im HTML-Format: http://www.faqs.org/faqs/realtime-computing/faq/
  • über anonymous FTP: ftp://rtfm.mit.edu/pub/usenet/comp.realtime/
• http://www.faqs.org/faqs/realtime-computing/
• http://www.dedicated-systems.com/encyc/
• http://www.dedicated-systems.com/magazine/magazine.htm
• Linux Realtime FAQ