Wikipedia - Benutzerbeiträge [de]

Echtzeitsystem

2020-06-05T10:38:26Z

Rob-kaiser: /* Literatur */

Als '''Echtzeitsysteme''' ({{enS|real-time systems}}) werden „Systeme zur ''unmittelbaren'' Steuerung und Abwicklung von Prozessen“<ref>''Informatik – Ein Fachlexikon für Studium und Praxis''. Dudenverlag, Mannheim 2003, ISBN 3-411-10023-0, S. 537</ref> 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 [[Motorsteuerung]]en, 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 Zeitintervalls garantiert berechnet ist, also vor einer bestimmten Zeitschranke vorliegt. Die Größe des Zeitintervalls 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. {{lang|en|''hard real-time''}}), weicher Echtzeit (engl. {{lang|en|''soft real-time''}}) und fester Echtzeit (engl. {{lang|en|''firm real-time''}}) unterschieden. Hierfür gelten jeweils unterschiedliche Echtzeitanforderungen.

* '''harte''' Echtzeitanforderungen: Eine Überschreitung der Antwortzeit wird als ein Versagen gewertet. Nach einer exakten Zeiterfassung der bereitzustellenden Anwendung sind Berechnungen gemäß der Theorie der Echtzeitsysteme notwendig. Echtzeitsysteme liefern das korrekte Ergebnis immer innerhalb der vorgegebenen Zeitschranken. Auf diese Eigenschaft kann man sich beim Einsatz eines harten Echtzeitsystems verlassen.

* '''weiche''' Echtzeitanforderungen: Solche Systeme arbeiten ''typischerweise'' alle ankommenden Eingaben ''schnell genug'' ab. Die Antwortzeit erreicht beispielsweise einen akzeptablen [[Mittelwert]] oder ein anderes [[Statistik|statistisches]] Kriterium. Die Zeitanforderungen sind hier als Richtlinien zu sehen. Ein Überschreiten der Zeitanforderung muss nicht als Versagen gewertet werden. Zum einen kann die Zeit häufig überschritten werden, solange sie sich noch in einem Toleranzbereich befindet. Zum anderen kann sie selten stark überschritten werden.<ref name="Echtzeitsysteme-S321">{{Literatur |Autor=Heinz Wörn, Uwe Brinkschulte |Titel=Echtzeitsysteme. Grundlagen, Funktionsweisen, Anwendungen |Verlag=Springer |Ort=Berlin u. a. |Datum=2005 |ISBN=3-540-20588-8 |Seiten=321 |DOI=10.1007/b139050}}</ref>

* '''feste''' Echtzeitanforderungen: Bei festen Echtzeitanforderungen droht kein unmittelbarer Schaden.<ref name="Echtzeitsysteme-S321" /> Nach Ablauf der Zeitanforderungen ist das Ergebnis der Berechnung jedoch nutzlos und kann verworfen werden.

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 Nutzen 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 [[Normung|Begriffsnorm]] hat sich in der Praxis als alleinig akzeptierte Definition nicht durchsetzen können, es dominieren die Begriffe aus dem englischen Sprachraum.

=== Beispiele ===
* Systeme für [[Videokonferenz]]en müssen Bild und Ton innerhalb von Millisekunden 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.
* Ein Programm, das (längere) Videosequenzen aufzeichnen soll, muss hingegen harte Echtzeitanforderungen erfüllen. Wenn es nicht gelingt, die Videodaten schnell genug auf den Datenträger zu speichern, gehen Bilder verloren und das Video ist für viele Anwendungen unbrauchbar.
* Die elektronische [[Motorsteuerung]] in einem [[Automobil|Auto]] muss harte Echtzeitanforderungen erfüllen, sonst [[Stottern (Motor)|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.

== 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]]-, [[Field Programmable Gate Array|FPGA]]- oder [[Digitaler Signalprozessor|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 <math>f=\frac{1}{\text{Reaktionszeit}}</math>, erfüllt. Ein Beispiel einer Hardwareumsetzung ist eine [[Digitalisierung]] mit einem [[Analog-Digital-Umsetzer|ADC]] als Funktionseinheit und einem [[Schwingquarz|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 [[Mikrocontroller]]n, [[Digitaler Signalprozessor|DSPs]], [[CPU]]s oder [[Field Programmable Gate Array|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 (Natur und Technik)|Regelung]] mit einem Mikrocontroller, der mehrere Eingabeparameter entgegennimmt, eine Reaktion berechnet und diese zurückgibt. Angenommen, es soll auf das Überschreiten einer Temperatur <math>t</math> mit einer Reaktionszeit ≤ 1 s und auf eine Drehzahl <math>d</math> unter ≤ 1 ms mit dem Setzen eines Abschaltsignals <math>O=1</math> reagiert werden. Eine technisch einfache Lösung auf einem Mikroprozessor mit einer 2-MHz-Taktfrequenz wäre eine einfache [[Endlosschleife|Endlos-Programmschleife]] (Beispiel in Intel-Syntax [[Assemblersprache|Pseudoassemblercode]], Semikolon ist Kommentarzeichen):

<syntaxhighlight lang="asm">
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)
</syntaxhighlight>

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

Dieses Konzept ist das übliche Paradigma auf dem Computer bei Multimediaanwendungen wie [[Mediaplayer|Video]], [[Demoszene|Demos]] und [[Computerspiele|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 [[Bildwiederholfrequenz|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 [[Computerspiel]]en).

=== Prozessbasierte Ansätze ===
Auf komplexen Echtzeitsystemen (wie einer SPS oder einem als Echtzeitsystem agierenden Computer) laufen in der Regel verschiedene [[Prozess (Computer)|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 [[Personal Computer|PC]] echtzeitfähig, allerdings nicht oder nur sehr bedingt, wenn er mit klassischen [[Multitasking]]-Betriebssystemen betrieben wird, da dann viele [[asynchron]]e Prozesse nicht-deterministisch ablaufen. [[Echtzeitbetriebssystem]]e sind oftmals ebenfalls multitaskingfähig, verfügen jedoch über einen anderen [[Prozess-Scheduler|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 [[GUI]]s) des zugrundeliegenden Betriebssystems verwendet werden können.

Auch in [[Speicherprogrammierbare Steuerung|speicherprogrammierbaren Steuerungen]] (SPS) und [[Prozessleitsystem]]en (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:
* Ein Problem ist komplexe I/O, z. B. [[Festplatte]]n mit Cache und automatischem Ruhezustand oder Netzwerk-Kommunikation mit nicht-deterministischem Zeitverhalten (z. B. [[Internet Protocol|IP]]).
* Die Laufzeit von Betriebssystem- und Bibliotheksaufrufen muss mit berücksichtigt werden.
* Der Bedarf an Ressourcen, insbesondere der Bedarf an [[Dynamischer Speicher|Speicher]], muss bekannt sein. Die Laufzeitumgebung und die Hardware müssen den Ressourcenbedarf decken können.
* Bei [[Rekursion]] muss die maximale Rekursionstiefe, bei [[Schleife (Programmierung)|Schleifen]] muss die maximale Anzahl an [[Iteration]]en feststehen.
* Speicherverwaltung: Es muss daher dafür gesorgt werden, dass die Echtzeitmodule von der [[Virtuelle Speicherverwaltung|virtuellen Speicherverwaltung]] des Betriebssystems unbeeinflusst bleiben und niemals ausgelagert werden (typischerweise verwenden Echtzeitsysteme deshalb überhaupt keine virtuelle Speicherverwaltung).
* Besonders problematisch ist auch zum Beispiel der Einsatz [[Automatische Speicherbereinigung|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 [[Verfahrenstechnik|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.
* Graphische Anwendungen auf dem [[Computer]] wie [[Computerspiel|Spiele]] oder [[Demoszene|Demos]]<ref name="CESCG-2002">{{cite web|author=Boris Burger, Ondrej Paulovic, Milos Hasan|url=http://www.cescg.org/CESCG-2002/BBurger |work=CESCG-2002|title=Realtime Visualization Methods in the Demoscene |publisher=[[Technische Universität Wien]] |language=en|date=2002-03-21|accessdate=2011-03-21}}</ref> erfordern bei der Aktualisierung der [[Bildschirmanzeige]] Reaktionszeiten von ≤ 63 ms (≥ 14–16 [[Frames per second|Bilder pro Sekunde]]), um als flüssiger Ablauf wahrgenommen zu werden.
* Computer-Programme, deren Reaktionszeiten auf Anwender-Eingaben mit [[Eingabegerät]]en ([[Tastatur]], [[Maus (Computer)|Maus]] etc.) unter 10 ms liegen, werden subjektiv als ''sofort'' wahrgenommen (siehe [[Usability]]).

* Die [[Airbag]]-Steuerung im [[Automobil|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]] im [[Automobil|Auto]] hat typischerweise eine Regelfrequenz von ≥100 Hz, d. h. die Reaktionszeit liegt unter 10 ms.
* In [[Werkzeugmaschine]]n ändert sich die gegenseitige Lage von Werkstück und Werkzeug. Heutige [[Computerized Numerical Control|CNC-Steuerungen]] haben zeitliche Auflösungen der Bewegungsregelung von 125 µs.
* In einem Auto muss das elektronische [[Motormanagement]] zu bestimmten Zeitpunkten seine Ergebnisse (einzuspritzende Kraftstoffmenge, 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 [[Schweißen#Elektronenstrahlschweißen|Elektronenstrahlschweißen]], müssen Magnetfelder mit Frequenzen von 100 kHz bis 1 MHz geregelt werden. Die Reaktionszeit liegt zwischen 1 µs und 10 µs.

== 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ät]]en 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 [[Asynchron]]itä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 ==
* [[Simulation]]

== Literatur ==
* Dieter Zöbel: ''Echtzeitsysteme - Grundlagen der Planung''. Springer Vieweg, 2020, ISBN 978-3-662-60421-2.
* Sascha Roeck: ''Echtzeitsimulation von Produktionsanlagen mit realen Steuerungssystemen''. Jost-Jetter Verlag, 2007, ISBN 3-939890-24-3.
* [[Hermann Kopetz]]: ''Real Time Systems. Design Principles for Distributed Embedded Applications'' (= ''The Kluwer International Series in Engineering and Computer Science.'' Vol. 395). Kluwer Academic Publishers, Boston MA u. a. 1997, ISBN 0-7923-9894-7.
* H. Zedan (Hrsg.): ''Real-time Systems. Theory and Applications.'' Proceedings of the conference, organized by the British Computer Society, York, 28. – 29. September 1989. North-Holland u. a., Amsterdam u. a. 1990, ISBN 0-444-88625-7.

== Weblinks ==
* ''Comp.realtime: Frequently Asked Questions (FAQ)'':
*: regelmäßig in der Newsgroup ''comp.realtime'' gepostet
*:* [http://www.faqs.org/faqs/realtime-computing/faq/ im HTML-Format]
*:* [ftp://rtfm.mit.edu/pub/usenet/comp.realtime/ über anonymous FTP]
* [http://www.faqs.org/faqs/realtime-computing/ faqs.org]
* [http://www.dedicated-systems.com/encyc/ dedicated-systems.com]
* [http://www.dedicated-systems.com/magazine/magazine.htm dedicated-systems.com]
* [https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions Linux Realtime FAQ]

== Einzelnachweise ==
<references />

[[Kategorie:Echtzeitsystem| ]]

[[nl:Realtime]]

Echtzeitsystem

2020-06-05T10:35:40Z

Rob-kaiser: /* Literatur */ Verweis auf aktuelles Lehrbuch hinzugefügt

Als '''Echtzeitsysteme''' ({{enS|real-time systems}}) werden „Systeme zur ''unmittelbaren'' Steuerung und Abwicklung von Prozessen“<ref>''Informatik – Ein Fachlexikon für Studium und Praxis''. Dudenverlag, Mannheim 2003, ISBN 3-411-10023-0, S. 537</ref> 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 [[Motorsteuerung]]en, 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 Zeitintervalls garantiert berechnet ist, also vor einer bestimmten Zeitschranke vorliegt. Die Größe des Zeitintervalls 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. {{lang|en|''hard real-time''}}), weicher Echtzeit (engl. {{lang|en|''soft real-time''}}) und fester Echtzeit (engl. {{lang|en|''firm real-time''}}) unterschieden. Hierfür gelten jeweils unterschiedliche Echtzeitanforderungen.

* '''harte''' Echtzeitanforderungen: Eine Überschreitung der Antwortzeit wird als ein Versagen gewertet. Nach einer exakten Zeiterfassung der bereitzustellenden Anwendung sind Berechnungen gemäß der Theorie der Echtzeitsysteme notwendig. Echtzeitsysteme liefern das korrekte Ergebnis immer innerhalb der vorgegebenen Zeitschranken. Auf diese Eigenschaft kann man sich beim Einsatz eines harten Echtzeitsystems verlassen.

* '''weiche''' Echtzeitanforderungen: Solche Systeme arbeiten ''typischerweise'' alle ankommenden Eingaben ''schnell genug'' ab. Die Antwortzeit erreicht beispielsweise einen akzeptablen [[Mittelwert]] oder ein anderes [[Statistik|statistisches]] Kriterium. Die Zeitanforderungen sind hier als Richtlinien zu sehen. Ein Überschreiten der Zeitanforderung muss nicht als Versagen gewertet werden. Zum einen kann die Zeit häufig überschritten werden, solange sie sich noch in einem Toleranzbereich befindet. Zum anderen kann sie selten stark überschritten werden.<ref name="Echtzeitsysteme-S321">{{Literatur |Autor=Heinz Wörn, Uwe Brinkschulte |Titel=Echtzeitsysteme. Grundlagen, Funktionsweisen, Anwendungen |Verlag=Springer |Ort=Berlin u. a. |Datum=2005 |ISBN=3-540-20588-8 |Seiten=321 |DOI=10.1007/b139050}}</ref>

* '''feste''' Echtzeitanforderungen: Bei festen Echtzeitanforderungen droht kein unmittelbarer Schaden.<ref name="Echtzeitsysteme-S321" /> Nach Ablauf der Zeitanforderungen ist das Ergebnis der Berechnung jedoch nutzlos und kann verworfen werden.

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 Nutzen 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 [[Normung|Begriffsnorm]] hat sich in der Praxis als alleinig akzeptierte Definition nicht durchsetzen können, es dominieren die Begriffe aus dem englischen Sprachraum.

=== Beispiele ===
* Systeme für [[Videokonferenz]]en müssen Bild und Ton innerhalb von Millisekunden 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.
* Ein Programm, das (längere) Videosequenzen aufzeichnen soll, muss hingegen harte Echtzeitanforderungen erfüllen. Wenn es nicht gelingt, die Videodaten schnell genug auf den Datenträger zu speichern, gehen Bilder verloren und das Video ist für viele Anwendungen unbrauchbar.
* Die elektronische [[Motorsteuerung]] in einem [[Automobil|Auto]] muss harte Echtzeitanforderungen erfüllen, sonst [[Stottern (Motor)|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.

== 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]]-, [[Field Programmable Gate Array|FPGA]]- oder [[Digitaler Signalprozessor|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 <math>f=\frac{1}{\text{Reaktionszeit}}</math>, erfüllt. Ein Beispiel einer Hardwareumsetzung ist eine [[Digitalisierung]] mit einem [[Analog-Digital-Umsetzer|ADC]] als Funktionseinheit und einem [[Schwingquarz|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 [[Mikrocontroller]]n, [[Digitaler Signalprozessor|DSPs]], [[CPU]]s oder [[Field Programmable Gate Array|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 (Natur und Technik)|Regelung]] mit einem Mikrocontroller, der mehrere Eingabeparameter entgegennimmt, eine Reaktion berechnet und diese zurückgibt. Angenommen, es soll auf das Überschreiten einer Temperatur <math>t</math> mit einer Reaktionszeit ≤ 1 s und auf eine Drehzahl <math>d</math> unter ≤ 1 ms mit dem Setzen eines Abschaltsignals <math>O=1</math> reagiert werden. Eine technisch einfache Lösung auf einem Mikroprozessor mit einer 2-MHz-Taktfrequenz wäre eine einfache [[Endlosschleife|Endlos-Programmschleife]] (Beispiel in Intel-Syntax [[Assemblersprache|Pseudoassemblercode]], Semikolon ist Kommentarzeichen):

<syntaxhighlight lang="asm">
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)
</syntaxhighlight>

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

Dieses Konzept ist das übliche Paradigma auf dem Computer bei Multimediaanwendungen wie [[Mediaplayer|Video]], [[Demoszene|Demos]] und [[Computerspiele|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 [[Bildwiederholfrequenz|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 [[Computerspiel]]en).

=== Prozessbasierte Ansätze ===
Auf komplexen Echtzeitsystemen (wie einer SPS oder einem als Echtzeitsystem agierenden Computer) laufen in der Regel verschiedene [[Prozess (Computer)|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 [[Personal Computer|PC]] echtzeitfähig, allerdings nicht oder nur sehr bedingt, wenn er mit klassischen [[Multitasking]]-Betriebssystemen betrieben wird, da dann viele [[asynchron]]e Prozesse nicht-deterministisch ablaufen. [[Echtzeitbetriebssystem]]e sind oftmals ebenfalls multitaskingfähig, verfügen jedoch über einen anderen [[Prozess-Scheduler|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 [[GUI]]s) des zugrundeliegenden Betriebssystems verwendet werden können.

Auch in [[Speicherprogrammierbare Steuerung|speicherprogrammierbaren Steuerungen]] (SPS) und [[Prozessleitsystem]]en (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:
* Ein Problem ist komplexe I/O, z. B. [[Festplatte]]n mit Cache und automatischem Ruhezustand oder Netzwerk-Kommunikation mit nicht-deterministischem Zeitverhalten (z. B. [[Internet Protocol|IP]]).
* Die Laufzeit von Betriebssystem- und Bibliotheksaufrufen muss mit berücksichtigt werden.
* Der Bedarf an Ressourcen, insbesondere der Bedarf an [[Dynamischer Speicher|Speicher]], muss bekannt sein. Die Laufzeitumgebung und die Hardware müssen den Ressourcenbedarf decken können.
* Bei [[Rekursion]] muss die maximale Rekursionstiefe, bei [[Schleife (Programmierung)|Schleifen]] muss die maximale Anzahl an [[Iteration]]en feststehen.
* Speicherverwaltung: Es muss daher dafür gesorgt werden, dass die Echtzeitmodule von der [[Virtuelle Speicherverwaltung|virtuellen Speicherverwaltung]] des Betriebssystems unbeeinflusst bleiben und niemals ausgelagert werden (typischerweise verwenden Echtzeitsysteme deshalb überhaupt keine virtuelle Speicherverwaltung).
* Besonders problematisch ist auch zum Beispiel der Einsatz [[Automatische Speicherbereinigung|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 [[Verfahrenstechnik|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.
* Graphische Anwendungen auf dem [[Computer]] wie [[Computerspiel|Spiele]] oder [[Demoszene|Demos]]<ref name="CESCG-2002">{{cite web|author=Boris Burger, Ondrej Paulovic, Milos Hasan|url=http://www.cescg.org/CESCG-2002/BBurger |work=CESCG-2002|title=Realtime Visualization Methods in the Demoscene |publisher=[[Technische Universität Wien]] |language=en|date=2002-03-21|accessdate=2011-03-21}}</ref> erfordern bei der Aktualisierung der [[Bildschirmanzeige]] Reaktionszeiten von ≤ 63 ms (≥ 14–16 [[Frames per second|Bilder pro Sekunde]]), um als flüssiger Ablauf wahrgenommen zu werden.
* Computer-Programme, deren Reaktionszeiten auf Anwender-Eingaben mit [[Eingabegerät]]en ([[Tastatur]], [[Maus (Computer)|Maus]] etc.) unter 10 ms liegen, werden subjektiv als ''sofort'' wahrgenommen (siehe [[Usability]]).

* Die [[Airbag]]-Steuerung im [[Automobil|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]] im [[Automobil|Auto]] hat typischerweise eine Regelfrequenz von ≥100 Hz, d. h. die Reaktionszeit liegt unter 10 ms.
* In [[Werkzeugmaschine]]n ändert sich die gegenseitige Lage von Werkstück und Werkzeug. Heutige [[Computerized Numerical Control|CNC-Steuerungen]] haben zeitliche Auflösungen der Bewegungsregelung von 125 µs.
* In einem Auto muss das elektronische [[Motormanagement]] zu bestimmten Zeitpunkten seine Ergebnisse (einzuspritzende Kraftstoffmenge, 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 [[Schweißen#Elektronenstrahlschweißen|Elektronenstrahlschweißen]], müssen Magnetfelder mit Frequenzen von 100 kHz bis 1 MHz geregelt werden. Die Reaktionszeit liegt zwischen 1 µs und 10 µs.

== 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ät]]en 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 [[Asynchron]]itä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 ==
* [[Simulation]]

== Literatur ==
* Dieter Zöbel: ''Echtzeitsysteme - Grundlagen der Planung''. Springer Verlag, 2020, ISBN 978-3-662-60421-2.
* Sascha Roeck: ''Echtzeitsimulation von Produktionsanlagen mit realen Steuerungssystemen''. Jost-Jetter Verlag, 2007, ISBN 3-939890-24-3.
* [[Hermann Kopetz]]: ''Real Time Systems. Design Principles for Distributed Embedded Applications'' (= ''The Kluwer International Series in Engineering and Computer Science.'' Vol. 395). Kluwer Academic Publishers, Boston MA u. a. 1997, ISBN 0-7923-9894-7.
* H. Zedan (Hrsg.): ''Real-time Systems. Theory and Applications.'' Proceedings of the conference, organized by the British Computer Society, York, 28. – 29. September 1989. North-Holland u. a., Amsterdam u. a. 1990, ISBN 0-444-88625-7.

== Weblinks ==
* ''Comp.realtime: Frequently Asked Questions (FAQ)'':
*: regelmäßig in der Newsgroup ''comp.realtime'' gepostet
*:* [http://www.faqs.org/faqs/realtime-computing/faq/ im HTML-Format]
*:* [ftp://rtfm.mit.edu/pub/usenet/comp.realtime/ über anonymous FTP]
* [http://www.faqs.org/faqs/realtime-computing/ faqs.org]
* [http://www.dedicated-systems.com/encyc/ dedicated-systems.com]
* [http://www.dedicated-systems.com/magazine/magazine.htm dedicated-systems.com]
* [https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions Linux Realtime FAQ]

== Einzelnachweise ==
<references />

[[Kategorie:Echtzeitsystem| ]]

[[nl:Realtime]]

Echtzeitsystem

2020-06-05T10:26:58Z

Rob-kaiser: /* Beispiele */

Als '''Echtzeitsysteme''' ({{enS|real-time systems}}) werden „Systeme zur ''unmittelbaren'' Steuerung und Abwicklung von Prozessen“<ref>''Informatik – Ein Fachlexikon für Studium und Praxis''. Dudenverlag, Mannheim 2003, ISBN 3-411-10023-0, S. 537</ref> 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 [[Motorsteuerung]]en, 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 Zeitintervalls garantiert berechnet ist, also vor einer bestimmten Zeitschranke vorliegt. Die Größe des Zeitintervalls 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. {{lang|en|''hard real-time''}}), weicher Echtzeit (engl. {{lang|en|''soft real-time''}}) und fester Echtzeit (engl. {{lang|en|''firm real-time''}}) unterschieden. Hierfür gelten jeweils unterschiedliche Echtzeitanforderungen.

* '''harte''' Echtzeitanforderungen: Eine Überschreitung der Antwortzeit wird als ein Versagen gewertet. Nach einer exakten Zeiterfassung der bereitzustellenden Anwendung sind Berechnungen gemäß der Theorie der Echtzeitsysteme notwendig. Echtzeitsysteme liefern das korrekte Ergebnis immer innerhalb der vorgegebenen Zeitschranken. Auf diese Eigenschaft kann man sich beim Einsatz eines harten Echtzeitsystems verlassen.

* '''weiche''' Echtzeitanforderungen: Solche Systeme arbeiten ''typischerweise'' alle ankommenden Eingaben ''schnell genug'' ab. Die Antwortzeit erreicht beispielsweise einen akzeptablen [[Mittelwert]] oder ein anderes [[Statistik|statistisches]] Kriterium. Die Zeitanforderungen sind hier als Richtlinien zu sehen. Ein Überschreiten der Zeitanforderung muss nicht als Versagen gewertet werden. Zum einen kann die Zeit häufig überschritten werden, solange sie sich noch in einem Toleranzbereich befindet. Zum anderen kann sie selten stark überschritten werden.<ref name="Echtzeitsysteme-S321">{{Literatur |Autor=Heinz Wörn, Uwe Brinkschulte |Titel=Echtzeitsysteme. Grundlagen, Funktionsweisen, Anwendungen |Verlag=Springer |Ort=Berlin u. a. |Datum=2005 |ISBN=3-540-20588-8 |Seiten=321 |DOI=10.1007/b139050}}</ref>

* '''feste''' Echtzeitanforderungen: Bei festen Echtzeitanforderungen droht kein unmittelbarer Schaden.<ref name="Echtzeitsysteme-S321" /> Nach Ablauf der Zeitanforderungen ist das Ergebnis der Berechnung jedoch nutzlos und kann verworfen werden.

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 Nutzen 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 [[Normung|Begriffsnorm]] hat sich in der Praxis als alleinig akzeptierte Definition nicht durchsetzen können, es dominieren die Begriffe aus dem englischen Sprachraum.

=== Beispiele ===
* Systeme für [[Videokonferenz]]en müssen Bild und Ton innerhalb von Millisekunden 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.
* Ein Programm, das (längere) Videosequenzen aufzeichnen soll, muss hingegen harte Echtzeitanforderungen erfüllen. Wenn es nicht gelingt, die Videodaten schnell genug auf den Datenträger zu speichern, gehen Bilder verloren und das Video ist für viele Anwendungen unbrauchbar.
* Die elektronische [[Motorsteuerung]] in einem [[Automobil|Auto]] muss harte Echtzeitanforderungen erfüllen, sonst [[Stottern (Motor)|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.

== 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]]-, [[Field Programmable Gate Array|FPGA]]- oder [[Digitaler Signalprozessor|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 <math>f=\frac{1}{\text{Reaktionszeit}}</math>, erfüllt. Ein Beispiel einer Hardwareumsetzung ist eine [[Digitalisierung]] mit einem [[Analog-Digital-Umsetzer|ADC]] als Funktionseinheit und einem [[Schwingquarz|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 [[Mikrocontroller]]n, [[Digitaler Signalprozessor|DSPs]], [[CPU]]s oder [[Field Programmable Gate Array|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 (Natur und Technik)|Regelung]] mit einem Mikrocontroller, der mehrere Eingabeparameter entgegennimmt, eine Reaktion berechnet und diese zurückgibt. Angenommen, es soll auf das Überschreiten einer Temperatur <math>t</math> mit einer Reaktionszeit ≤ 1 s und auf eine Drehzahl <math>d</math> unter ≤ 1 ms mit dem Setzen eines Abschaltsignals <math>O=1</math> reagiert werden. Eine technisch einfache Lösung auf einem Mikroprozessor mit einer 2-MHz-Taktfrequenz wäre eine einfache [[Endlosschleife|Endlos-Programmschleife]] (Beispiel in Intel-Syntax [[Assemblersprache|Pseudoassemblercode]], Semikolon ist Kommentarzeichen):

<syntaxhighlight lang="asm">
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)
</syntaxhighlight>

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

Dieses Konzept ist das übliche Paradigma auf dem Computer bei Multimediaanwendungen wie [[Mediaplayer|Video]], [[Demoszene|Demos]] und [[Computerspiele|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 [[Bildwiederholfrequenz|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 [[Computerspiel]]en).

=== Prozessbasierte Ansätze ===
Auf komplexen Echtzeitsystemen (wie einer SPS oder einem als Echtzeitsystem agierenden Computer) laufen in der Regel verschiedene [[Prozess (Computer)|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 [[Personal Computer|PC]] echtzeitfähig, allerdings nicht oder nur sehr bedingt, wenn er mit klassischen [[Multitasking]]-Betriebssystemen betrieben wird, da dann viele [[asynchron]]e Prozesse nicht-deterministisch ablaufen. [[Echtzeitbetriebssystem]]e sind oftmals ebenfalls multitaskingfähig, verfügen jedoch über einen anderen [[Prozess-Scheduler|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 [[GUI]]s) des zugrundeliegenden Betriebssystems verwendet werden können.

Auch in [[Speicherprogrammierbare Steuerung|speicherprogrammierbaren Steuerungen]] (SPS) und [[Prozessleitsystem]]en (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:
* Ein Problem ist komplexe I/O, z. B. [[Festplatte]]n mit Cache und automatischem Ruhezustand oder Netzwerk-Kommunikation mit nicht-deterministischem Zeitverhalten (z. B. [[Internet Protocol|IP]]).
* Die Laufzeit von Betriebssystem- und Bibliotheksaufrufen muss mit berücksichtigt werden.
* Der Bedarf an Ressourcen, insbesondere der Bedarf an [[Dynamischer Speicher|Speicher]], muss bekannt sein. Die Laufzeitumgebung und die Hardware müssen den Ressourcenbedarf decken können.
* Bei [[Rekursion]] muss die maximale Rekursionstiefe, bei [[Schleife (Programmierung)|Schleifen]] muss die maximale Anzahl an [[Iteration]]en feststehen.
* Speicherverwaltung: Es muss daher dafür gesorgt werden, dass die Echtzeitmodule von der [[Virtuelle Speicherverwaltung|virtuellen Speicherverwaltung]] des Betriebssystems unbeeinflusst bleiben und niemals ausgelagert werden (typischerweise verwenden Echtzeitsysteme deshalb überhaupt keine virtuelle Speicherverwaltung).
* Besonders problematisch ist auch zum Beispiel der Einsatz [[Automatische Speicherbereinigung|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 [[Verfahrenstechnik|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.
* Graphische Anwendungen auf dem [[Computer]] wie [[Computerspiel|Spiele]] oder [[Demoszene|Demos]]<ref name="CESCG-2002">{{cite web|author=Boris Burger, Ondrej Paulovic, Milos Hasan|url=http://www.cescg.org/CESCG-2002/BBurger |work=CESCG-2002|title=Realtime Visualization Methods in the Demoscene |publisher=[[Technische Universität Wien]] |language=en|date=2002-03-21|accessdate=2011-03-21}}</ref> erfordern bei der Aktualisierung der [[Bildschirmanzeige]] Reaktionszeiten von ≤ 63 ms (≥ 14–16 [[Frames per second|Bilder pro Sekunde]]), um als flüssiger Ablauf wahrgenommen zu werden.
* Computer-Programme, deren Reaktionszeiten auf Anwender-Eingaben mit [[Eingabegerät]]en ([[Tastatur]], [[Maus (Computer)|Maus]] etc.) unter 10 ms liegen, werden subjektiv als ''sofort'' wahrgenommen (siehe [[Usability]]).

* Die [[Airbag]]-Steuerung im [[Automobil|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]] im [[Automobil|Auto]] hat typischerweise eine Regelfrequenz von ≥100 Hz, d. h. die Reaktionszeit liegt unter 10 ms.
* In [[Werkzeugmaschine]]n ändert sich die gegenseitige Lage von Werkstück und Werkzeug. Heutige [[Computerized Numerical Control|CNC-Steuerungen]] haben zeitliche Auflösungen der Bewegungsregelung von 125 µs.
* In einem Auto muss das elektronische [[Motormanagement]] zu bestimmten Zeitpunkten seine Ergebnisse (einzuspritzende Kraftstoffmenge, 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 [[Schweißen#Elektronenstrahlschweißen|Elektronenstrahlschweißen]], müssen Magnetfelder mit Frequenzen von 100 kHz bis 1 MHz geregelt werden. Die Reaktionszeit liegt zwischen 1 µs und 10 µs.

== 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ät]]en 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 [[Asynchron]]itä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 ==
* [[Simulation]]

== Literatur ==
* Sascha Roeck: ''Echtzeitsimulation von Produktionsanlagen mit realen Steuerungssystemen''. Jost-Jetter Verlag, 2007, ISBN 3-939890-24-3.
* [[Hermann Kopetz]]: ''Real Time Systems. Design Principles for Distributed Embedded Applications'' (= ''The Kluwer International Series in Engineering and Computer Science.'' Vol. 395). Kluwer Academic Publishers, Boston MA u. a. 1997, ISBN 0-7923-9894-7.
* H. Zedan (Hrsg.): ''Real-time Systems. Theory and Applications.'' Proceedings of the conference, organized by the British Computer Society, York, 28. – 29. September 1989. North-Holland u. a., Amsterdam u. a. 1990, ISBN 0-444-88625-7.

== Weblinks ==
* ''Comp.realtime: Frequently Asked Questions (FAQ)'':
*: regelmäßig in der Newsgroup ''comp.realtime'' gepostet
*:* [http://www.faqs.org/faqs/realtime-computing/faq/ im HTML-Format]
*:* [ftp://rtfm.mit.edu/pub/usenet/comp.realtime/ über anonymous FTP]
* [http://www.faqs.org/faqs/realtime-computing/ faqs.org]
* [http://www.dedicated-systems.com/encyc/ dedicated-systems.com]
* [http://www.dedicated-systems.com/magazine/magazine.htm dedicated-systems.com]
* [https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions Linux Realtime FAQ]

== Einzelnachweise ==
<references />

[[Kategorie:Echtzeitsystem| ]]

[[nl:Realtime]]

Charlie Mariano

2007-05-05T10:42:09Z

Rob-kaiser:

[[Bild:Charlie_Mariano_2003.JPG|thumb|240px|right|Charlie Mariano, Jazz an der Donau, Straubing 2003]]'''Charlie Mariano''' (* [[12. November]] [[1923]] in [[Boston]], [[USA]] als ''Carmine Ugo Mariano'') ist ein US-amerikanischer [[Jazz]]-Saxophonist und Flötist.

Mariano, der als Kind Klavierunterricht bekam und erst mit 17 Jahren zum Saxophon wechselte, begann bereits [[1941]] in professionellen Showbands und spielte in der Folge mit zahlreichen Jazzgrößen (u. a. [[Charlie Parker]], [[Stan Kenton]], [[Dizzy Gillespie]], [[McCoy Tyner]], [[Charles Mingus]]). Bereits 1949 veröffentlichte er Schallplatten unter eigenem Namen. Insbesondere seine Solos auf der Plattenaufnahme der Ballettmusik "The Black Saint and the Sinner Lady" (1963) von Mingus zeigen, welche Ausdrucksstärke und Intensität Mariano auf dem [[Altsaxophon]], seinem Hauptinstrument, entwickeln kann.

Ende der sechziger Jahre verbrachte er längere Zeit in Südindien, um die dortige Musik und insbesondere das Blasinstrument [[Nagaswaram]] zu studieren. Daraus resultieren bis heute andauernde Kooperationen mit südindischen Musikern wie denen des [[Karnataka|Karnataka College of Percussion]] (diverse Tourneen, zuletzt [[2005]]).

Seit Anfang der [[1970er]] arbeitete Mariano vornehmlich in Europa. Dabei hat er sich einerseits dem [[Rockjazz]] zugewandt, in den er Elemente der südindischen Musik einfließen ließ (bei Embryo (München) und in [[Jasper van't Hof]]s "Pork Pie"). Andererseits betonte er - insbesondere in eigenen Gruppen, aber auch in der Gruppe von [[Eberhard Weber]] und im Zusammenspiel mit [[Zbigniew Seifert]] - das lyrische Spiel. Mariano gehört auch zu den Gründungsmitgliedern des [[United Jazz and Rock Ensemble]], der "Band der Bandleader". Neben vielen anderen Besetzungen, auch mit jüngeren Musikern, tritt er häufig im Trio mit [[Ali Haurand]] und [[Daniel Humair]] auf. Seit seiner Zusammenarbeit für das Album "Savannah Samurai" (1998) mit dem Freiburger Jazzbassisten [[Dieter Ilg]] unterhalten Mariano und Ilg ein kammermusikalisches Jazz-Duo.

Nicht nur in der Pop-Musik hat er seine Spuren durch Mitwirkung auf zahlreichen Alben ( z. B. von [[Herbert Grönemeyer]], [[Konstantin Wecker]], [[Embryo (Band)|Embryo]] u. v. a) hinterlassen, sondern auch im Kontext der sog. [[Weltmusik]] bei [[Rabih Abou-Khalil]], mit [[Dino Saluzzi]] oder den [[Dissidenten (Band)|Dissidenten]].

Von 1959 bis 1967 war er mit der Jazzpianistin und Bandleaderin [[Toshiko Akiyoshi]] verheiratet, mit der er auch zusammen musizierte. 1963 wurde eine gemeinsame Tochter, die Sängerin und Schauspielerin [[Monday Michiru]], geboren. Nachdem Mariano längere Zeit ein Nomadenleben zwischen den USA, Europa und Asien geführt hatte, lebte er seit [[1986]] ständig mit der Zeichnerin Dorothee Mariano in [[Köln]]. Im Jahr 2005 hat er sich von Dorothee getrennt.

== Diskografie (Auswahl) ==
* ''[[Ray Borden Orchestra]]'' 1947
* ''Charlie Mariano Octet'' 1949
* ''Charlie Mariano - Boston All Stars'' 1951
* ''Charlie Mariano Quartett'' 1955
* ''Toshiko - Mariano Quartett'' 1960
* ''Charles Mingus - The Black Saint and the Sinner Lady'' 1963
* ''Charlie Mariano - Folk Soul'' 1967
* ''[[Embryo]]'' - ''We keep on'' 1972
* ''Jazz - India'' 1972
* ''Charlie Mariano'' - Reflections 1974
* ''Pork Pie - Transitory'' 1974
* ''Eberhard Weber Colours'' 1975
* ''Pork Pie - The door is open'' 1975
* ''The United Jazz + Rock Ensemble - Live im Schützenhaus'' 1977
* ''Philip Cathrine - Charlie Mariano - Jasper Van´t Hof - Sleep My Love'' 1979
* ''Trio'' 1980
* ''Charlie Mariano & Karnataka College of Percussion: Jiyoth'' 1983
* ''Sangam'' 1983
* ''[[Herbert Grönemeyer]]'' - [[4630 Bochum]] 1984
* ''Shigihara - Mariano - Wells - Küttner - Tears of Sound'' 1984
* ''Charlie Mariano Group - Plum Island'' 1985
* ''Konstantin Wecker - Wieder Dahoam'' 1986
* ''André Jaume & Charlie Mariano - Abbaye de l´epau'' 1990
* ''Charlie Mariano - Jasper van't Hof - INNUENDO'' 1992
* ''[[Rabih Abou Khalil]] '' - ''Blue Camel'' 1992
* ''Birthday Presents for Charlie M.'' 1993
* ''Charlie Mariano & Friends - Seventy'' 1994
* ''Nassim'', 1998
* ''Charlie Mariano: Bangalore'', 1998
* ''Jasper van't Hof, Charlie Mariano, Steve Swallow - Brutto Tempo'' 2001
* ''[[Theo Jörgensmann]]'' - ''Fellowship'', 2005
* ''Charlie Mariano & Dieter Ilg:'' Due, 2005
Mariano hat bis heute insgesamt an mehr als 200 Schallplatten und CDs mitgewirkt.

== Weblinks ==
* {{PND|119125099}}

[[Kategorie:Mann|Mariano, Charlie]]
[[Kategorie:US-Amerikaner|Mariano, Charlie]]
[[Kategorie:Weltmusik-Künstler|Mariano, Charlie]]
[[Kategorie:Fusion-Musiker|Mariano, Charlie]]
[[Kategorie:Jazz-Saxophonist|Mariano, Charlie]]
[[Kategorie:Geboren 1923|Mariano, Charlie]]

{{Personendaten|
NAME=Mariano, Charlie
|ALTERNATIVNAMEN=
|KURZBESCHREIBUNG=), amerikanischer Saxophonist
|GEBURTSDATUM=[[12. November]] [[1923]]
|GEBURTSORT=[[Boston]], [[USA]]
|STERBEDATUM=
|STERBEORT=
}}

[[en:Charlie Mariano]]

Benutzer:Rob-kaiser

2007-03-30T14:04:01Z

Rob-kaiser: AZ: Die Seite wurde neu angelegt.

{{BenutzerMenüleiste}}
[[Benutzer:Rob-kaiser|Rob-kaiser]] 16:04, 30. Mär. 2007 (CEST)