Website durchsuchen

Echtzeitsystem

Als Echtzeitsysteme (englisch real-time systems) werden „Systeme zur unmittelbaren Steuerung und Abwicklung von Prozessen“ bezeichnet, die dafür an sie gestellte quantitative Echtzeitanforderungen erfüllen müssen. Diese kommen in diversen Technikgebieten zur Anwendung, etwa in der Prozessleittechnik, in Motorsteuerungen, in der Satellitensystemtechnik, in Signal- und Weichenstellanlagen, in der Robotik und in weiteren Bereichen.

Oft besteht die Anforderung darin, dass ein Ergebnis innerhalb eines vorher fest definierten Zeitintervalles garantiert berechnet ist, also vor einer bestimmten Zeitschranke vorliegt. Die Größe des Zeitintervalles spielt dabei keine Rolle: Während bei einigen Aufgaben (z.B. in der Motorsteuerung) eine Sekunde bereits zu lang sein kann, reichen für andere Probleme Stunden oder sogar Tage. Ein Echtzeitsystem muss also nicht nur ein Mess- oder 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 realisieren. Daher spricht man auch von „in Echtzeit“, wenn Programme ohne spürbare Verzögerung arbeiten. Diese Definition ist jedoch sehr unsauber. Grundsätzlich falsch ist es, „Echtzeitsystem“ als Synonym für „besonders schnell“ anzusehen. Im Gegenteil, Echtzeitsysteme müssen entsprechende Leerläufe einplanen, um auch in besonders fordernden Situationen ihren Echtzeitanforderungen gerecht zu werden.

Harte, weiche und feste Echtzeit

Definition

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

Je nach Problemstellung und Blickwinkel wird auch folgende Definition verwendet:

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

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.

Beispiele

Umsetzung

Echtzeit beschreibt das zeitliche Ein- bzw. Ausgangsverhalten eines Systems, sagt aber nichts über dessen Realisierung aus. Ein Echtzeitsystem kann ein Rechner mit einer geeigneten Software oder eine reine Hardware-Lösung sein. Für Anforderungen mit sogenannten weichen Grenzen werden häufig Standard-EDV-Systeme verwendet. Für Anforderungen mit harten Grenzen werden spezielle Architekturen (Hardware und Software) verwendet, z.B. Mikrocontroller-, FPGA- oder DSP-basierte Lösungen.

Feste periodische Triggerung

Ein Ansatz, eine 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={\frac {1}{Reaktionszeit}}, erfüllt. Ein Beispiel einer Hardwareumsetzung ist eine Digitalisierung mit einem ADC als Funktionseinheit und einem Taktquarz, z.B. zur Digitalisierung 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. Jedoch, eine komplexe Echtzeitaufgabe zerlegt nach diesem Prinzip (wie z.B. eine Regelung mit vielen Eingangsparametern mit großer Dynamik in den geforderten Reaktionszeiten), kann durch die zu lösende Asynchronität und redundante Systemteile teuer und komplex werden.

Synchrone Ansätze

Ein verallgemeinerter Ansatz für mehrere Aufgaben ist die Verwendung einer einzigen, gleichgetakteten (synchronen) Lösungsplattform, umgesetzt typischerweise mit Mikrocontrollern, DSPs, CPUs oder FPGAs. Die für die Echtzeitbedingung geforderten Reaktionszeiten werden in diesem Lösungskonzept dadurch zu erfüllen versucht, 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 ≤ 1 s und auf eine Drehzahl d unter ≤ 1 ms mit dem Setzen eines Abschaltsignals O=1 reagiert werden. Eine 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 d,PORT1   ; einlesen der aktuellen drehzahl-Werte
  in t,PORT2   ; einlesen der aktuellen temp-Werte

:drehcheck
  cmp d,a      ; prüfe die Drehzahl
  jg  tempcheck; wenn Grenzwert nicht erreicht, springe zu :tempcheck
  out PORT3,O  ; Grenzwert erreicht! setze Abschaltsignal

:tempcheck
  cmp t,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 Marke :loop (Endlosschleife)

Unter der Annahme, dass jeder Befehl auf diesem Prozessor (jede Codezeile) einen Taktzyklus an Zeit kostet, wird ein Prüfdurchlauf t_{{loop}} in 6 Taktzyklen durchgeführt, mit einer Worst-case-Reaktionszeit von 12 Taktzyklen für die Temperatur ({\displaystyle {\frac {12}{2000000}}=0{,}006\,ms}) und 11 für die Drehzahl ({\displaystyle {\frac {11}{2000000}}=0{,}0055\,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 doppelte 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, nicht abzählbar) und/oder nicht 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 ab, geregelt durch ein Echtzeitbetriebssystem. Die minimale Reaktionszeit wird durch die Zeitdauer für einen vollständigen Wechsel von einem Prozess niederer Priorität zu einem Prozess höherer Priorität definiert. 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).

Prinzipiell ist auch ein PC echtzeitfähig, allerdings nicht oder nur sehr bedingt, wenn er mit klassischen Multitasking-Betriebssystemen betrieben wird, da dann viele asynchrone Prozesse nicht-deterministisch ablaufen. 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.

Bei einer Software, die Echtzeitbedingungen erfüllen soll, muss die maximale Laufzeit bestimmbar sein und darf keinen nicht oder nur bedingt beeinflussbaren Faktoren unterliegen, muss also deterministisch sein. Dies wird u.a. durch folgende System- oder Softwareeigenschaften beeinflusst:

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.

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.

Trenner
Basierend auf einem Artikel in: Wikipedia.de
Seitenende
Seite zurück
©  biancahoegel.de
Datum der letzten Änderung:  Jena, den: 02.10. 2022