Echtzeit, Echtzeitsysteme
- Ersteller PuckPoltergeist
- Erstellt am
PuckPoltergeist
Grand Admiral Special
Da hier in einem anderen Thread einige Fragen zu Echtzeit(systemen) auftauchten, und auch einiges an Blödsinn geschrieben wurde, hier mal etwas Licht in diesem Dunkel. 
Zuerst einmal zu einer häufig anzutreffenden und falschen Annahme, Echtzeit hat nichts mit Geschwindigkeit zu tun, und sagt auch nichts darüber aus. (Die meisten Echtzeitsysteme sind mit Microcontrollern realisiert, die nur ein Bruchteil der Leistung heutiger Gigahertz-Bolliden haben.)
Echtzeit bedeutet lediglich rechtzeitig, nicht mehr. Wenn jeden Freitag 16:00Uhr ein Wochenabschlussbericht an den Geschäftsführer geschickt werden muss, und das mit einem popeligen 386er mit DOS realisiert wird, ist das auch ein Echtzeitsystem.
Für die Steuerung eine Kernkraftwerks sieht das schon wieder ganz anders aus. Wenn da die Neutronenanzahl ansteigt, muss dass innerhalb von x mSec registriert und die Steuerstäbe eingefahren werden. Der Rechner, der das realisiert, ist auch ein Echtzeitsystem, aber hier mit ganz anderen Anforderungen.
Bei Echtzeitsystemen wird nun auch noch zwischen harter und weicher Echtzeit unterschieden. Für harte Echzeit muss ein Job bis spätestens zu einem bestimmten Datum abgearbeitet sein. Liegt das Ergebnis auch nur einen Tick später vor, ist es nutzlos. Ein Beispiel dafür wäre das oben genannte Kernkraftwerk. Wenn nicht innerhalb einer fest vorgegebenen Zeit der Neutronenanstieg erkannt und darauf reagiert wird, kommt es zur Katastrophe. Dann ist es sinnlos die Regelstäbe noch 2cm einzufahren, weil das die Kernreaktion nicht mehr ausreichend bremsen würde.
Weiche Echtzeit heißt, dass ein Ergebniss zu einem vorgegebenen Datum vorhanden sein muss. Wenn das nicht der Fall ist, sinkt der Nutzen des Ergebniss mit der Zeit, die es später eintrifft. Häufig sinkt der Nutzen exponentiell mit der Verzögerungszeit. Ein Beispiel hierfür wäre die Videobearbeitung oder Videostreaming. Ein Bild muss zu einem bestimmten Zeitpunkt vorhanden (dekodiert) sein. Kommt es später, so laufen Ton und Bild nicht mehr synchron. Je später das Bild vorhanden ist, desto mehr läuft die Synchronität auseinander. Bis zu einem gewissen Punkt es das tolerierbar, weil der Mensch das eh nicht mitbekommt, wenn Audio und Video nicht 100%ig synchron laufen. Irgendwann fällt es aber auf. Dann kann man immer noch einzelne Frames wegschmeißen. Im Gegensatz zur harten Echtzeit ist ein Ergebnis also nicht sofort mit überschreiten der Zeitschranke nutzlos, es verliert erstmal "nur" an Wert.
Hier erkennt man schon, dass Echtzeit einen sehr weiten Bereich umfasst, und immer an das Einsatzgebiet gekoppelt ist. Aus diesem Einsatzgebiet leiten sich immer die Hard- und Softwareanforderungen ab. Für die Kraftwerkssteuerung wird ein spezielles System benötigt, welches die Anforderungen dort erfüllt. Das lässt sich mit einem PC nicht mehr realisieren. Hingegen bei einem Videoserver ist das mit Standardhardware absolut zu machen. Schon der Standard-Linuxkernel ermöglicht weiche Echtzeit. Für harte Echtzeit ist er hingegen nicht ausgelegt. Das läuft dem Einsatz auf Servern und Desktops/Workstations vollkommen entgegen, weil es sie sehr träge machen würde.
Ich hoffe, ich konnte den Echtzeit-Begriff hier etwas verständlicher machen.
Zuerst einmal zu einer häufig anzutreffenden und falschen Annahme, Echtzeit hat nichts mit Geschwindigkeit zu tun, und sagt auch nichts darüber aus. (Die meisten Echtzeitsysteme sind mit Microcontrollern realisiert, die nur ein Bruchteil der Leistung heutiger Gigahertz-Bolliden haben.)
Echtzeit bedeutet lediglich rechtzeitig, nicht mehr. Wenn jeden Freitag 16:00Uhr ein Wochenabschlussbericht an den Geschäftsführer geschickt werden muss, und das mit einem popeligen 386er mit DOS realisiert wird, ist das auch ein Echtzeitsystem.
Für die Steuerung eine Kernkraftwerks sieht das schon wieder ganz anders aus. Wenn da die Neutronenanzahl ansteigt, muss dass innerhalb von x mSec registriert und die Steuerstäbe eingefahren werden. Der Rechner, der das realisiert, ist auch ein Echtzeitsystem, aber hier mit ganz anderen Anforderungen.
Bei Echtzeitsystemen wird nun auch noch zwischen harter und weicher Echtzeit unterschieden. Für harte Echzeit muss ein Job bis spätestens zu einem bestimmten Datum abgearbeitet sein. Liegt das Ergebnis auch nur einen Tick später vor, ist es nutzlos. Ein Beispiel dafür wäre das oben genannte Kernkraftwerk. Wenn nicht innerhalb einer fest vorgegebenen Zeit der Neutronenanstieg erkannt und darauf reagiert wird, kommt es zur Katastrophe. Dann ist es sinnlos die Regelstäbe noch 2cm einzufahren, weil das die Kernreaktion nicht mehr ausreichend bremsen würde.
Weiche Echtzeit heißt, dass ein Ergebniss zu einem vorgegebenen Datum vorhanden sein muss. Wenn das nicht der Fall ist, sinkt der Nutzen des Ergebniss mit der Zeit, die es später eintrifft. Häufig sinkt der Nutzen exponentiell mit der Verzögerungszeit. Ein Beispiel hierfür wäre die Videobearbeitung oder Videostreaming. Ein Bild muss zu einem bestimmten Zeitpunkt vorhanden (dekodiert) sein. Kommt es später, so laufen Ton und Bild nicht mehr synchron. Je später das Bild vorhanden ist, desto mehr läuft die Synchronität auseinander. Bis zu einem gewissen Punkt es das tolerierbar, weil der Mensch das eh nicht mitbekommt, wenn Audio und Video nicht 100%ig synchron laufen. Irgendwann fällt es aber auf. Dann kann man immer noch einzelne Frames wegschmeißen. Im Gegensatz zur harten Echtzeit ist ein Ergebnis also nicht sofort mit überschreiten der Zeitschranke nutzlos, es verliert erstmal "nur" an Wert.
Hier erkennt man schon, dass Echtzeit einen sehr weiten Bereich umfasst, und immer an das Einsatzgebiet gekoppelt ist. Aus diesem Einsatzgebiet leiten sich immer die Hard- und Softwareanforderungen ab. Für die Kraftwerkssteuerung wird ein spezielles System benötigt, welches die Anforderungen dort erfüllt. Das lässt sich mit einem PC nicht mehr realisieren. Hingegen bei einem Videoserver ist das mit Standardhardware absolut zu machen. Schon der Standard-Linuxkernel ermöglicht weiche Echtzeit. Für harte Echtzeit ist er hingegen nicht ausgelegt. Das läuft dem Einsatz auf Servern und Desktops/Workstations vollkommen entgegen, weil es sie sehr träge machen würde.
Ich hoffe, ich konnte den Echtzeit-Begriff hier etwas verständlicher machen.
Zuletzt bearbeitet:
reddevil156
Vice Admiral Special
Ja, das hast du!
Hat doch nen Sticky oder nen Eintrag in ne FAQ verdients
Hat doch nen Sticky oder nen Eintrag in ne FAQ verdients
rkinet
Grand Admiral Special
http://www.fh-wedel.de/~si/seminare/ws01/Ausarbeitung/6.linuxrt/LinuxRT0.htm
Ok, von Profis geschrieben und auch noch Linux.
Unter http://www.fh-wedel.de/~si/seminare/ws01/Ausarbeitung/6.linuxrt/LinuxRT2.htm eine schöne Übersicht, was ein 'normales OS' kann und eben Echtzeit.
Auf jeden Fall ist erkennbar, daß das OS hier Probleme verursacht, nicht die CPU-Hardware.
Virtualisierung könnte hier die friedliche Koexistenz zwischen einem gewohnten OS und einem Spezial-OS, daß Signalverarbeitung (Audio, Video, Filter etc.) in Echtzeit (= garantierte Reaktionsteiten - kein Darstellungsabbruch) ermöglichen.
@PuckPoltergeist - wozu soll ein Kernkraftwerk zur mechanischen Steuerung der Brennstäbe Spezial-Computer benötigen ?
Die Computer dort sind anders als unsere, nur die wurden ja auch schon vor Jahrzehnten entwickelt und dürfen wg. den AKW-Genehmigungen nicht verändert werden.
Im Prinzip könnte man dort robuste CPUs wie die der NASA / Marsmission verwenden, also selektierte PowerPC o.ä., verwenden. Wenn eines neu gebaut müßte
UND - wieso mal wieder keinen einzigen Link von Dir ?
Ok, von Profis geschrieben und auch noch Linux.
Unter http://www.fh-wedel.de/~si/seminare/ws01/Ausarbeitung/6.linuxrt/LinuxRT2.htm eine schöne Übersicht, was ein 'normales OS' kann und eben Echtzeit.
Auf jeden Fall ist erkennbar, daß das OS hier Probleme verursacht, nicht die CPU-Hardware.
Virtualisierung könnte hier die friedliche Koexistenz zwischen einem gewohnten OS und einem Spezial-OS, daß Signalverarbeitung (Audio, Video, Filter etc.) in Echtzeit (= garantierte Reaktionsteiten - kein Darstellungsabbruch) ermöglichen.
@PuckPoltergeist - wozu soll ein Kernkraftwerk zur mechanischen Steuerung der Brennstäbe Spezial-Computer benötigen ?
Die Computer dort sind anders als unsere, nur die wurden ja auch schon vor Jahrzehnten entwickelt und dürfen wg. den AKW-Genehmigungen nicht verändert werden.
Im Prinzip könnte man dort robuste CPUs wie die der NASA / Marsmission verwenden, also selektierte PowerPC o.ä., verwenden. Wenn eines neu gebaut müßte
UND - wieso mal wieder keinen einzigen Link von Dir ?
@PuckPoltergeist
"Echtzeit" ist demnach also vollständig von Software und Hardware abgekoppelt.
Man definiert einen Einsatzbereich mit bestimmten Zeit-Vorgaben und entwirft nach diesen Vorgaben dann entsprechende Lösungen. Da in der Automation von Maschinen in der Produktion, oder auch in Automobilen genau dieses zeitgenaue Verhalten gefordert wird, kommen vielfach abweichende Lösungen vom Desktop zustande ... THX
MFG Bokill
"Echtzeit" ist demnach also vollständig von Software und Hardware abgekoppelt.
Man definiert einen Einsatzbereich mit bestimmten Zeit-Vorgaben und entwirft nach diesen Vorgaben dann entsprechende Lösungen. Da in der Automation von Maschinen in der Produktion, oder auch in Automobilen genau dieses zeitgenaue Verhalten gefordert wird, kommen vielfach abweichende Lösungen vom Desktop zustande ... THX
MFG Bokill
PuckPoltergeist
Grand Admiral Special
Es wird der Rahmen für die Hard- und Software vorgegeben. Die Realisierung kann dann auf viele verschiedene Arten geschehen. Alles, was sich innerhalb dieses Rahmens bewegt, ist ein Echtzeitsystem.
Die Anforderungen für Echtzeit- und Desktopsysteme sind zu großen Teilen vollkommen entgegensätzlich. Es werden da eigentlich konträre Bedingungen gestellt, weshalb auch unterschiedliche Lösungen zustande kommen.
