ein System gilt gemeinhin dann als „echtzeitfähig“, wenn ein streng definiertes Zeitverhalten vorliegt. Es hat also weniger mit der Geschwindigkeit der Bearbeitung der Daten zu tun, als vielmehr mit der Verlässlichkeit der Bearbeitungszeit.
Ich würde hier gerne zur Diskussion stellen, ab wann ein
System „Echtzeitfähig“ ist und was genau man unter „Echtzeit“
versteht.
Wenn die Regelung/Steuerung, auch unter ungünstigen Bedingungen, schneller als die die Zeitkonstante der Regelstrecke ist.
Alles Andere bringt eigentlich meist nicht viel.
Bei einem grossen Ofen, mit einer Zeitkonstante von 30Min, brauchst du die Temperatur nicht alle ms zu erfassen.
Beim Heizelement eines Thermodruckers sieht das dann ganz anders aus.
das wichtigste an der Echtzeitfähigkeit ist garnicht die Reaktionszeit an sich - wie schon gesagt, richtet sich die nach den Anforderungen, und für eine Gebäudeheizung wären auch Minuten noch völlig ausreichend, während eine Motorsteuerung für Werkzeugmaschinen schon besser als msec sein sollte.
Entscheidend ist aber, dass diese Reaktionszeit unter allen Umständen garantiert wird. Weder Windows noch Linux sind daher echtzeitfähig, da verschiedene Vorgänge wie CD lesen, HD schreiben usw. das System fast beliebig lange blockieren können, besonders wenn Fehler auftreten. Wenn ich z.B. eine schlecht gebrannte CD einlege, bleibt auch auf meinem neuesten XP-System die Maus quälend lange einfach stehen. So etwas muss ein Echtzeitsystem mit absoluter Sicherheit ausschliessen.
Daher ist auch die aus Kostengründen immer wieder aufkommende Idee, man könnte alles mögliche (Werkzeugmaschinen, Abwasseranlagen, Kernkraftwerke…) einfach mit einem handlesüblichen PC steuern, von vornherein zum Scheitern verurteilt.
Gruss Reinhard
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Also kann ma es auch so sagen…
Ein System ist dann echtzeitfähig, wenn eine zu erbringende Funktion innerhalb einer durch die Umgebungsbedingungen vorgegebenen Zeitspanne rechtzeitig ausgeführt wird.
Diese Zeitspanne erstreckt sich über das Intervall [R,D], wobei R (Release) den frühesten erlaubten und D (Deadline) den spätesten noch gültigen Zeitpunkt für die Beendigung der Ausführung angibt.
Diese Definition gibt sehr gut die Relativität der Echtzeitfähigkeit wieder.
Zeitspannen die für bestimmte Einsatzbedingungen weit ausreichen, sind für andere nicht akzeptabel.
Daher ist auch die aus Kostengründen immer wieder aufkommende
Idee, man könnte alles mögliche (Werkzeugmaschinen,
Abwasseranlagen, Kernkraftwerke…) einfach mit einem
handlesüblichen PC steuern, von vornherein zum Scheitern
verurteilt.
Ist es natürlich nicht, wenn man ein Echtzeitbetriebssystem einsetzt. Ein Handelsüblicher PC mit QNX z.B. erfüllt harte Echtzeitanforderungen wunderbar. http://www.qnx.com/
mir fällt auf Anhieb kein Beispiel dafür ein, dass ein System zu schnell reagiert - m.a.W. ich denke, R in deiner Definition ist immer 0, bzw. sofortige Reaktion ist zulässig (und i.A. sowieso unmöglich).
Gruss Reinhard
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
mir fällt auf Anhieb kein Beispiel dafür ein, dass ein System
zu schnell reagiert - m.a.W. ich denke, R in deiner Definition
ist immer 0, bzw. sofortige Reaktion ist zulässig (und i.A.
sowieso unmöglich).
Jegliche Form von mechanischen Kontakten muss entprellt werden. Da hat schon mancher Anfänger Probleme gehabt, wenn EIN Tastendruck als 20 Impulse ausgewertet wurde …
Unterdrückung von Störimpulsen an Eingängen.
Regelstrecken kommen ins Schwingen, müssen also gewollt verzögert we4rden.
Viele Stellglieder benötigen Totzeiten, dürfen also nicht sofort nacheinander Ein und wieder Ausgeschaltet werden.
Jegliche Form von mechanischen Kontakten muss entprellt
werden. Da hat schon mancher Anfänger Probleme gehabt, wenn
EIN Tastendruck als 20 Impulse ausgewertet wurde …
Unterdrückung von Störimpulsen an Eingängen.
Regelstrecken kommen ins Schwingen, müssen also gewollt
verzögert we4rden.
Viele Stellglieder benötigen Totzeiten, dürfen also nicht
sofort nacheinander Ein und wieder Ausgeschaltet werden.
Das ist nur das was mir gerade eingefallen ist.
MfG Peter(TOO)
Hallo Peter,
natürlich ist das Entprellen usw. ein Problem, aber eine verzögerte Interrupt-Antwort ist nicht die Lösung dafür, aber das würde hier viel zu weit führen. Störimpulse werden von der Software aussortiert, aber dazu muss sie erst einmal reagieren. Auch Verzögerungen in Regelstrecken wie bei elektrischen Heizungen müssen im Regelalgorithmus berücksichtigt werden und nicht dadurch, dass das System verspätet reagiert.
Im Gegenteil, um Prellen, Störungen und Regelverzögerungen korrekt zu erfassen und zu bearbeiten, muss das System u.U. deutlich „echtzeitiger“ ausgeführt werden als für das eigentliche Problem notwendig. Zumindest ist das die heute übliche Lösung, weil die Rechenkapazität dafür vorhanden ist, während Hardware-Elemente wie RC-Glieder zusätzlichen Aufwand bedeuten und viel schlechter anpassbar sind.
Konkret: ich schicke einem Kunden mit einer miesen Tastatur lieber ein EPROM mit geänderter Software als hinzufahren und unzählige Kondensatoren auszulöten und durch grössere zu ersetzen.
natürlich ist das Entprellen usw. ein Problem, aber eine
verzögerte Interrupt-Antwort ist nicht die Lösung dafür, aber
das würde hier viel zu weit führen. Störimpulse werden von der
Software aussortiert, aber dazu muss sie erst einmal
reagieren. Auch Verzögerungen in Regelstrecken wie bei
elektrischen Heizungen müssen im Regelalgorithmus
berücksichtigt werden und nicht dadurch, dass das System
verspätet reagiert.
Im Gegenteil, um Prellen, Störungen und Regelverzögerungen
korrekt zu erfassen und zu bearbeiten, muss das System u.U.
deutlich „echtzeitiger“ ausgeführt werden als für das
eigentliche Problem notwendig. Zumindest ist das die heute
übliche Lösung, weil die Rechenkapazität dafür vorhanden ist,
während Hardware-Elemente wie RC-Glieder zusätzlichen Aufwand
bedeuten und viel schlechter anpassbar sind.
Moment, du machst da einen Denkfehler:
Das Echtzeitsystem ist eine Blackbox !
Durch das Entprellen, egal ob per Software oder mit RC-Gliedern, ergibt sich automatisch eine minimale Zeitverzögerung zwischen dem Ändern eines Eingangs und und einer Reaktion am Ausgang. Ist diese Zeit kleiner als deine Entprellzeit hast du einen Fehler in deiner Software.
Da wir beide uns hauptsächlich um das Innenleben der Blackbox kümmern, haben wir eine etwas andere Sichtweise )
Daher ist auch die aus Kostengründen immer wieder aufkommende
Idee, man könnte alles mögliche (Werkzeugmaschinen,
Abwasseranlagen, Kernkraftwerke…) einfach mit einem
handlesüblichen PC steuern, von vornherein zum Scheitern
verurteilt.
die Gründe liegen aber keinesfalls beim Echtzeitproblem.
PC-technik wird schon lange auch im industriellen Umfeld
für sehr viele Aufgaben benutzt.
Dafür wird dann eben spezielle Hardware benötigt, die
durchaus auf PC-Technik basiert -> Industrie-PC.
Es muß ja nicht mit Windows sein, welches als OS tatsächlich
wenig echtzeitfähig ist.
Ein ganz anderes Problem sind die erfoderlichen Hardware-
spezifikationen und die notwendige Zuverlässigkeit bei
stark sicherheitsrelevanten anwendungen, wie z.B.
Kernkraftwerk. Da wird dann wohl auch an entsprechenden
Stellen spezielle Hardware benutzt.