Echtzeit

In der Informatik spricht man von Echtzeit (englisch: real-time), wenn die Dauer eines Vorgangs (auch eine Wartezeit) vorhersehbar ist. Beispiel für ein Echtzeitsystem: Sitzt man vor einer funktionierenden Uhr, so ist es vorhersehbar, wann diese das nächste Mal tickt oder wann die Glocken (so vorhanden) schlagen werden (also Echtzeit). Sitzt man hingegen vor einem beliebigen funktionierenden Telefonapparat, so kann man nicht absehen, wie lang man warten muss, bis dieser das nächste mal klingelt (Dauer nicht vorhersehbar).

Man unterscheidet zwischen hartem und weichem Echtzeitverhalten. Weiches Echtzeitverhalten bedeutet, dass die Dauer eines Vorgangs die angegebene Obergrenze üblicherweise nicht überschreitet. Dies kann durch Messungen und statistische Berechnungen gezeigt werden und ist für Multimediaanwendungen (z. B. Computerspiele) üblicherweise ausreichend. Hartes Echtzeitverhalten bedeutet im Gegensatz dazu, dass anhand von Hardwarespezifikationen und Modellrechnungen eine beweisbare obere Grenze für die Dauer eines Vorgangs angegeben werden kann. Dies ist bei kritischen Anwendungen beispielsweise in der Regelungstechnik von Bedeutung (Motorsteuerung, Reaktorsteuerung etc). Im Rahmen dieses Artikels wird (wenn nicht explizit anders angegeben) von der Definition des harten Echtzeitverhaltens ausgegangen.

Erklärung des Begriffs Echtzeit

Der Begriff Echtzeit legt lediglich fest, dass ein System auf ein Ereignis innerhalb eines vorgegebenen Zeitrahmens reagieren muss. Der Begriff sagt nichts über die Geschwindigkeit oder Verarbeitungsleistung eines Systems aus. In der Umgangssprache wird dies fälschlicherweise jedoch oft so verwendet, anstelle der zutreffenderen Begriffe verzögerungsarm oder verzugsarm. Zur Beschreibung einer Steuerungs- und Regelungsaufgabe reicht es aber nicht aus, nur Echtzeit zu fordern. Die Anforderungen sind erst vollständig definiert, wenn außerdem die Zeit angegeben wird, in der das System mit Sicherheit reagiert haben muss. Je nach Art der Anwendung kann sich diese Reaktionszeit innerhalb eines weiten Bereichs bewegen:

• Für Einsatzbereiche wie Temperaturregelungen oder Füllstandsüberwachungen sind häufig Reaktionszeiten von einigen Sekunden ausreichend (realisiert mit günstigen Mikrocontrollern, einfache Speicherprogrammierbare Steuerung (SPS)).

• Automatisierungslösungen mit einer Speicherprogrammierbaren Steuerung (SPS) oder auf einem Feldbussystem basierende Produktionslinien kommen typischerweise mit Reaktionszeiten im Millisekunden-Bereich aus.

• Echtzeit-Anwendungen auf dem Computer wie Spiele oder Demos^[1] erfordern bei der Aktualisierung der Bildschirmanzeige Reaktionszeiten von ≤ 63 ms (≥ 14-16 Bilder pro Sekunde) um als flüssiger Ablauf wahrgenommen zu werden.

• Bei den Reaktionszeiten von Computer-Programmen auf Eingaben durch Anwender mit Eingabegeräten (Tastatur, Maus etc.) sind ≤ 10 ms gefordert, um subjektiv als sofort wahrgenommen zu werden.

• Schnelle digitale Regelungen, Steuerungen, Filterungen und Überwachungen, Messdaten-Onlineauswertung benötigen häufig Echtzeit-Systeme, die im Mikrosekunden-Bereich arbeiten.

Umsetzungsansätze

Feste periodische Triggerung

Eine Methode, die geforderte Reaktionszeit für spezifische Anwendungen zu erfüllen, ist der Einsatz einer eigenen Funktionseinheit, die nur diese Aufgabe mit einer fixen Frequenz, gewonnen aus der Reaktionszeit $f=\tfrac{1}{\mathrm{Reaktionszeit}}$, erfüllt. Ein Beispiel ist eine Digitalisierung mit einem ADC als Funktionseinheit und einem Taktquarz, z. B. von Klängen für eine Audio-CD mit einer nötigen Frequenz von 44,1 KHz (entspricht einer Reaktionszeit ≤22,7 Mikrosekunden). Eine solche Lösung erfüllt zuverlässig das harte Echtzeitkriterium, da sie spezifisch zur Erfüllung einer einzigen Aufgabe designt wurde. Bei multiplen Aufgaben sind mehrere Funktionseinheiten mit eigenen Taktfrequenzen erforderlich, dadurch ergeben sich asynchrone und teure Lösungen.

Synchrone Ansätze

Ein verallgemeinerter Ansatz für mehrere Aufgaben ist die Verwendung einer einzigen, gleichgetakten (synchronen) Lösungsplattform, umgesetzt typischerweise mit Mikrocontrollern, DSPs, CPUs oder FPGAs. Die für die Echtzeitbedingung geforderten Reaktionszeiten werden in diesem Lösungskonzept versucht dadurch zu erfüllen, dass alle Aufgaben sequentiell so schnell wie möglich abgearbeitet werden. Die Echtzeitbedingung ist sicher erfüllt, wenn die kleinste geforderte Reaktionszeit unter den Aufgaben doppelt so groß ist wie die maximale Laufzeit für einen Gesamtdurchlauf aller Aufgaben.

Ein Beispiel wäre eine Echtzeit-Regelung mit einem Mikrocontroller, der mehrere Eingabeparameter entgegennimmt, eine Reaktion berechnet und diese zurückgibt. Angenommen, es soll auf das Überschreiten einer Temperatur t mit einer Reaktionszeit von weniger als einer Sekunde und auf eine Drehzahl d unter einer Millisekunde mit dem Setzen eines Abschaltsignals O=1 reagiert werden. Ein technisch einfache Lösung auf einem Mikroprozessor mit einer 2 MHz-Taktfrequenz wäre eine einfache Endlos-Programmschleife (Beispiel in Intel-Syntax Pseudoassemblercode, Semikolon ist Kommentarzeichen):

  mov a, 10000 ; Grenzwert der Drehzahl
  mov b, 30    ; Grenzwert der Temperatur 
  mov O,1      ; Abschaltsignal
 
:loop          ; Markierung im Programmfluss (keine Instruktion, wird vom Assembler für Sprungadressen verwendet)
  in t,PORT1   ; Einlesen der aktuellen Temperatur-Werte 
  in d,PORT2   ; Einlesen der aktuellen Drehzahl-Werte
 
:drehcheck 
  cmp t,a      ; prüfe die Drehzahl
  jg  tempcheck; wenn Grenzwert nicht erreicht springe zu :tempcheck      
  out PORT3,O  ; Grenzwert erreicht! setze Abschaltsignal
 
:tempcheck 
  cmp d,b      ; prüfe die Temperatur
  jg  loop     ; wenn Grenzwert nicht erreicht, springe zu :loop 
  out PORT3,O  ; Grenzwert erreicht! setze Abschaltsignal
 
  jmp loop     ;unbedingter Sprung zur :loop Marke (Endlosschleife)

Unter der Annahme, dass jeder Befehl auf diesem Prozessor (jede Codezeile) einen Taktzyklus an Zeit kostet, wird ein Prüfdurchlauf t_loop in sechs Taktzyklen durchgeführt, mit einer worst-case Reaktionszeit von zwölf Taktzyklen für die Temperatur ($\tfrac{12}{2000000}=0{,}006\,\mathrm{ms}$) und 11 für die Drehzahl ($\tfrac{11}{2000000}=0{,}0055\,\mathrm{ms}$). Die harten Echtzeitanforderungen sind mit dieser Regelung erfüllt, jedoch um Größenordnungen schneller als es eigentlich nötig wäre (ineffizient). Eine Erweiterung der Echtzeitregelung z. B. um den Test eines Drucks p ist durch diese Überdimensionierung des Systems möglich. Jedoch, die erreichte Reaktionszeit für jede der Teilaufgaben wächst mit der Gesamtablaufzeit t_loop mit. Die Grenze dieses Designs ist also erreicht, wenn im worst-case Fall die Gesamtablaufzeit t_loop die Reaktionszeit für eine Teilaufgabe überschreitet.

Dieses Konzept ist das übliche Paradigma auf dem Computer bei Multimediaanwendungen wie Video, Demos und Spielen. Typischerweise wird damit nur das weiche Echtzeitbedingungskriterium erfüllt, da eine worst-case Abarbeitungszeit/Reaktionszeit aufgrund der Komplexität des Systems nicht bestimmbar (oder wie im obigen Beispiel, abzählbar) und/oder deterministisch ist. Bei Multimediaanwendungen äußert sich dieser Nichtdeterminismus z. B. über variierende FPS oder Reaktionszeiten bei Eingaben. Gründe für diesen Nichtdeterminismus sind das Vorhandensein mehrerer Codepfade mit unterschiedlichen Ausführungszeiten, das Warten der Ausführung auf Ein- oder Ausgaben oder einfach Aufgaben mit variabler Komplexität (z. B. variierende Szeneriekomplexität in Computerspielen).

Prozessbasierte Ansätze

Auf komplexen Echtzeitsystemen (wie einer SPS oder einem als Echtzeitsystem agierenden Computer) laufen in der Regel verschiedene Prozesse gleichzeitig und mit unterschiedlicher Priorität, geregelt durch ein Echtzeitbetriebssystem, ab. Die Reaktionszeit beschreibt die Zeitdauer für einen vollständigen Wechsel von einem Prozess niederer Priorität zu einem Prozess höherer Priorität. Dieser Wechsel wird dann eingeleitet, wenn ein definiertes Ereignis eintritt, z. B. generiert durch einen externen Trigger (in der Computertechnik Interrupt) oder interne Timer. Die eigentliche Abarbeitung des aufgerufenen Prozesses beginnt erst nach dem ausgeführten Prozesswechsel. Hiermit wird die Erfüllung des harten Echtzeitkriteriums einer höherpriorisierten Aufgabe erzwungen indem die Ausführung einer niedrigerpriorisierten Aufgabe unterbrochen wird (Präemptives Multitasking).

Folgendes Beispiel soll den Zusammenhang zwischen der Reaktionszeit und dem Einfluss auf die zu realisierende Anwendung verdeutlichen: Ein fiktives Echtzeitsystem habe eine angenommene Antwortzeit oder Reaktionszeit (auch Totzeit oder Latenz) von 10 µs. Auf diesem Echtzeitsystem sollen verschiedene Prozesse mit unterschiedlichen Zykluszeiten ablaufen. Je nach Zykluszeit des Prozesses nimmt die Reaktionszeit einen beträchtlichen Anteil ein:

Prozess	Frequenz	Zykluszeit bzw. Periodendauer	Reaktionszeit in % von der Zykluszeit
Prozess 1	1 kHz	1000µs	1%
Prozess 2	10 kHz	100µs	10%
Prozess 3	50 kHz	20µs	50%
Prozess 4	100 kHz	10µs	100%

Während bei Prozess 1 und 2 die Reaktionszeit nur einen kleinen Anteil der Prozesszykluszeit einnimmt, somit diese sicherlich realisierbar sind, sieht man deutlich den mit 50 Prozent größeren Anteil der Reaktionszeit bei Prozess 3. Nicht mehr realisierbar wäre Prozess 4, denn hier nimmt die Reaktionszeit ganze 100 Prozent der Prozesszykluszeit ein, somit steht keine Rechenleistung für die eigentliche Aufgabenrealisierung mehr zur Verfügung. Daraus folgt: je schneller Prozesse ablaufen sollen, desto kürzer muss die Reaktionszeit des Echtzeitsystems sein, um möglichst viel Rechenleistung für die Abarbeitung des Prozesses zur Verfügung zu stellen. Ideal wäre eine Reaktionszeit von 0, was unmöglich ist, aber mikrosekundengenaue Reaktionszeiten weit unter einer Mikrosekunde kommen dem schon sehr nahe.

Anwendungsbereiche

Diese Anwendungsbereiche beziehen sich auf umgangssprachliche Echtzeitanwendungen. Diese entsprechen den Kriterien von Echtzeitanwendungen wenn überhaupt nur als "weich". Übertragungen über das Internet sind durch einen nicht definierten Übertragungsweg per se nicht Echtzeitfähig, sondern werden oft nur aus Marketingzwecken so genannt.

Echtzeit-Finanzdaten

In der Finanzbranche spricht man von Echtzeit- oder Realtime-Daten meistens im Zusammenhang mit Börsen- bzw. Kursdaten. Empfänger von Realtime-Daten erhalten Bid-/Ask- und Last-Quotierungen nahezu im selben Moment, in dem sie an den Börsenplätzen veröffentlicht werden. Die Übertragung erfolgt über eine Direktanbindung oder indirekt über Datenlieferanten (Daten-Vendoren). Neben den üblichen Börsen-Daten werden auch andere Daten vom Finanzmarkt, z. B. News und Presse-Meldungen, als Realtime-Daten angeboten. Insbesondere Trader von Wertpapieren arbeiten in der Regel mit Echtzeit-Daten. Da in Netzwerken immer mit Kollisionen zu rechnen ist, kann jedoch oft nur ein eingeschränktes Echtzeitverhalten erwartet werden.

Echtzeit-Abfahrtszeiten im Öffentlichen Verkehr

Im öffentlichen Verkehr zeigt die Echtzeit-Technologie Abfahrtszeiten von Zug, Tram und Postauto auf die Minute genau an. Eventuelle Verspätungen sind für den Fahrgast also jederzeit ersichtlich.

In der Schweiz (Ostschweiz) verfügt PostAuto über ein eigenes rechnergestütztes Betriebsleitsystem. Dieses System ermöglicht es, Echtzeit-Abfahrtsinformationen von allen Fahrzeugen zu sammeln, auszuwerten und zu publizieren. Die Informationen können sowohl an Haltestellen als auch in Fahrzeugen und übers Mobiltelefon als App abgerufen werden. PostAuto betreibt Applikationen, die den Fahrgästen über das Mobiltelefon den Zugriff auf Echtzeitinformationen ermöglichen. Die Echtzeitinformation ist für fünf verschiedene Technologien aufbereitet: iPhone- und Android-App, Java, mobile Website und SMS.

Siehe auch

• Laufzeit
• Echtzeitsystem
• Echtzeit-Ethernet
• Echtzeit-Programmierung
• Echtzeitbetriebssystem
• Simulation
• Speicherprogrammierbare Steuerung (SPS)

Einzelnachweise

1. ↑ Boris Burger, Ondrej Paulovic, Milos Hasan (21. März 2002): Realtime Visualization Methods in the Demoscene (en). CESCG-2002. Technische Universität Wien. Abgerufen am 21. März 2011.