Diskussion:Echtzeitsystem

Zeitsteuerung

Ausage:

> Bei der Zeitsteuerung werden Verarbeitungen auf Grund eines vorher festgelegten Zeitplans gestartet.

> Der Vorteil liegt darin, dass Überlastungen grundsätzlich ausgeschlossen werden können.

Warum ? wenn datenabhängige verzweigungen vorkommen kann sowohl hier auch systemüberlastung auftreten, 

Eher: Das System ist besser vom Rechenaufwand abzuschätzen, sodass überlastungen leichter vermieden werden können.

>Das Verhalten der Anwendung ist für alle Zeit vorhersagbar, was die Zeitsteuerung für sicherheitskritische Anwendungen eignet. Der Nachteil der >Zeitsteuerung ist der höhere Planungsaufwand und der damit verbundene notwendige Werkzeug-Einsatz.

- Warum mehr Planungsaufwand als bei Ereignissteuerung ?

mittel-harte Echtzeitanforderungen

Gibt es wirklich die Klassifizierung in "mittel-harte Echtzeitanforderung"? Die Erklärung ("Hier geht man davon aus, dass wenn ein System zu spät reagiert, die Ergebnisse als ungültig verworfen werden müssen.") dazu klingt stark nach einer weichen Echtzeitanforderung. Vergleiche mit Videokonferenz! - Denn hier werden Pakete, die zu spät ankommen einfach weggeworfen. Gibt es andere Meinungen, ansonsten wäre es wünschenswert, wenn der Beitrag über die "mittel-harte Echtzeitanforderung" entfernt wird. -- Der Michl 16:16, 18. Jan 2006 (CET)

Rakete

Patriot-Rakete = MIM-104 Patriot? --Abdull 11:45, 28. Mär 2006 (CEST)

Ich glaub der Author verwechselt Echtzeit und Reaktionszeit.

Zitat: "anderer Begriff Echtzeit" Der Begriff „Echtzeit“ legt lediglich fest, dass ein System auf ein Ereignis innerhalb eines vorgegebenen Zeitrahmens reagieren muss. Der Begriff sagt nichts über die Geschwindigkeit oder Verarbeitungsleistung eines Systems aus. In der Umgangssprache wird dies fälschlicherweise jedoch oft so verwendet, anstelle des zutreffenderen Begriffes „verzögerungsfrei. Zitatende

Der Begriff Echtzeit sagt aus, dass bei harten Bedingungen das Ergebnis in der definierten Zeit gefunden sein muss - reagieren alleine reicht nicht aus! Genau da unterscheiden sich nämlich harte und weiche Bedingungen. Oder wie würdest du darauf reagieren, wenn die Sicherheitsschaltung eine Kernkraftwerkes eine Notabschaltung in der vorgebenen Zeit nur erkennen, aber nicht handeln müsste?

• Weiche Echtzeitbedingung: Das System reagiert in der angegebenen Zeitspanne und präsentiert im Regelfall das Ergebnis
• Harte Echtzeitbedingung: Der gesamte Vorgang ist im angegebenen Zeitfenster auch im Worst-Case abgeschlossen.

Weil im Artikel schon einmal darüber so halbgar diskutiert wurde: Es gibt auch mittelharte Echtzeitbedingungen wobei zwei Zeitspannen definiert werden: Die erste ist die weiche, in der das System reagieren muss, die zweite bis das System entweder das Ergebniss liefern oder den Vorgang abbrechen muss. Mich verwundert das Fehlen hier, weil es ist fast der häufigste Fall. Bankbuchungssysteme funktionieren so: innerhalb fünf Sekunden muss das System eine Buchung annehmen und innerhalb weiterer 10 Sekunden, als nach insgesamt 15 Sekunden muss die positive Rückmeldung einer erfolgreichen Buchung auflaufen, sonst wird storniert.

Übrigens: Ein Zitat hat immer eine Quelle und einen Autor - bitte diese auch nennen. 84.170.76.250 22:10, 15. Aug. 2010 (CEST)

DIN-Norm

Ich habe den Kleinst-Artikel Realzeitbetrieb der die DIN-Norm Sprachregelung beschrieb eingearbeitet. Ob das hier passt wird auch in diesem Löschantrag diskutiert.--inschanör 07:14, 10. Feb. 2007 (CET)

Utopische Reaktionszeit

Wie soll die Patriot die Zeit unter eine 1 ns schaffen? --inschanör 21:58, 22. Feb. 2007 (CET)

• Indem man auf die analoge Rechentechnik zurückgreift. Wer meint in einer Patriot einen "Wintel" zu finden liegt ein bischen falsch. Die Berechnung der Flugbahn sowie der Steuerimpulse erfolgt nicht mittels diskreter Algorythmen, sondern auf Basis eines analogen Differentialrechners, läuft kontinuierlich ab und nicht getaktet wie in einem Digitalrechner. Das Limit in Bezug auf die Rechengeschwindigkeit sind die Elektronenlaufzeiten - einem kontinuierlichen Eingangssignal steht ein kontinuierliches Steuersignal gegenüber. Zwar hat auch in das System Patriot die digitale Rechentechnik einzug gehalten - jedoch nicht im Bereich der Fluglagesteuerung.

Die Verwendung der Analogtechnik hat durchaus auch militärische Gründe. Sie ist - zumindest bisher - in bestimmten Anwendungen störsicherer in gefechtsverseuchter Umgebung. Controller lassen sich mit relativ bescheidenen Mitteln zum Absturz zu bringen, die dann in der abzuwehrenden Rakete untergebracht sein könnten. Manche den Controller speisenden Sensoren lassen sich nunmal nicht hinter einer Abschirmung montieren, da dann auch das zu messende Signal zum Teufel wäre. Nicht nur Wintel, sondern auch ein RTOS, ja selbst Compiler sind hier oft verpönt. Hier kommt noch der schnelle Assemblerprogrammierer zum Zuge. Entschuldigt bitte die angesichts der Anwendung gefühlskalte Ausdrucksweise, aber anders ist es nicht prägnant zu erklären. -- 84.132.92.168 03:12, 29. Mär. 2008 (CET)

Im Beispiel zur Patriot-Rakete ist von Reaktionszeiten unter 1ns die Rede, begründet mit der hohen Längsgeschwindigkeit der Rakete. Folgende Überschlagsrechnung soll zeigen, dass diese Angabe oder zumindest die Begründung fehlerhaft sein müssen: Die Patriot fliegt mit 1700 m/s auf eine ebenso schnelle Rakete zu. Sie soll in einem Abstand <1m gezündet werden. Die Begegnungsgeschwindigkeit beträgt 3400m/s. Das entspricht 1m alle 300µs oder auch 1m alle 300000ns. Aus der Reisegeschwindigkeit allein kann die Reaktionszeit <1ns also nicht abgeleitet werden. -- 93.203.170.43 01:46, 20. Jun. 2011 (CEST)

Ja, sieht wirklich merkwürdig aus. Die Faustregel ist ja immer: 1 ns sind 30 cm (bei Lichtgeschwindigkeit): Und wir sind hier halt immer noch arg weit von der Lichtgeschwindigkeit weg. Auch wenn im Text wahrscheinlich einzelne Rechenschritte gemeint sein könnten, von denen man ja weit mehr als einen braucht, bevor sich so ein Steuerelement wirklich bewegt. --PeterFrankfurt 09:17, 20. Jun. 2011 (CEST)

Wollen wir das offensichtlich falsche Beispiel also vielleicht mal löschen? Oder spricht etwas dagegen? --92.206.9.89 12:45, 5. Jul. 2011 (CEST)

Löschen traue ich mich nicht. Die konkrete Erwähnung von 1 ns kann man aber ohne große Verrenkungen vermeiden. Wenn es dann in mehrere (auch > 10 ns) geht, kann ich es mir schon eher vorstellen. --PeterFrankfurt 02:43, 6. Jul. 2011 (CEST)

Warum nicht? Ich mein, Du hast ja schließlich am 5. Feb. 2008 um 19:50 auch hier hinein editiert. Und dass ein Faktor 10 nicht ausreicht, um das aufgezeigte Dilemma (wie gesagt, 300000ns ^= 1m Flugstrecke) zu lösen, ist denke ich auch klar. --92.206.96.178 19:38, 19. Jul. 2011 (CEST)

Weil ich mich einfach auf dem Gebiet der Analogelektronik nicht sattelfest genug fühle, das mit abschließender Gewissheit zu entscheiden. Möglich sind manchmal Sachen, an die der Laie nicht im Traum denkt. Richtige Quellen wären mal toll, hat nicht jemand ein Patriot-Handbuch oder die Konstruktionsunterlagen rumliegen? WP verlangt sowas theoretischerweise... --PeterFrankfurt 03:07, 20. Jul. 2011 (CEST)

So, 2. Versuch (diesmal hoffentlich richtig): Der Benutzer Kinley hat die Info über die Patriot Raketen am 3. Okt. 2005 um 11:38 hier eingefügt. Das kann man in der Versionsgeschichte verfolgen. Vielleicht sollte man ihn anschreiben, ob er Paper oder Ähnliches als Quelle empfehlen kann? Ich bin leider nicht so versiert mit der Wikipedia, aber ich schau mal, ob ich was hinbekomme. --92.206.11.97 10:23, 2. Aug. 2011 (CEST)

Der Benutzer Kinley ist nicht mehr in der Wikipedia aktiv. Außer ihm weiß keiner, warum die Patriot-Systeme Zeiten im Nanosekunden-Bereich einhalten müssen. Paper findet man dazu im Internet nicht. Dass die Angabe von Nanosekunden höchstwahrscheinlich Unsinn ist, habe ich oben dargelegt. Wär es an der Zeit, die entsprechende Passage jetzt zu löschen? Oder was wäre jetzt der nächste Schritt? --92.206.93.70 12:56, 29. Aug. 2011 (CEST)

Also wenn ich die Beiträge hier so lese, dann wundert mich ehrlich gesagt gar nichts mehr. Da wird mal schnell die Begegnungsgeschwindigkeit als Basis für die Reaktionszeit "abgeleitet". Eine solche Herleitung ist genuaso an den Haaren herbeitgezogen wie die 1ns und zeugt einfach nur, das man <NUHR/> viel öffter anwenden sollte. Das Problem ist bei allen digitalen Steuerungen die Zeit, die zwischen dem Messen der Messgröße und der Aktion der Steuerung vergeht. Das sind Analogrechner bis heute im Vorteil. Im übrigen kommt nur ein Laie auf die Idee, eine Rakete von vorne abschießen zu wollen, wenn sich die beiden Geschwindigkeiten addieren, die Treffersignatur am geringsten ist und noch dazu die Flugbahn des generischen Projektils am schlechtesten Messen und berechen läßt. Eine Rakete wird immer von der Seite, von unten abgeschossen oder - wie es Jäger in der Wildniss vormachen - von schräg hinten, wenn die eigene Rakete deutlich schneller ist als die Gegnerische.

Eine Rakete wie die Patriot ist rund 1500m/s schnell. Je näher meine Rakete an der berechneten Stelle des Zusammentreffens ist, desto präziser muss sie sein. Bei 5m Länge des gegnerischen System muss die Stelle des Zusammentreffens in allen drei Dimensionen auf 500 Mikrosekunden genau erreicht werden. Schon in 1 km Entfernung entscheidet ein Steuerlagefehler von 5cm über Hit oder Miss - in der verbleibenden dreiviertel Sekunde ist eine präzise Korrektur einfach nicht mehr möglich.

Dies bedeutet, dass die Steuerung und die Feindanalyse erheblich schneller sein muss als der Zeitraum, der für das Zusammentreffen zur Verfügung steht. Die notwendigen Reaktionszeiten liegen zwar nicht im einstelligen ns-Bereich - wohl aber im hohen zweistelligen bis niedrigen dreistelligen. 79.212.175.113 18:52, 10. Nov. 2012 (CET)

Kleiner Formfehler im Assemblerprogramm unter Umsetzung, Synchrone Ansätze

bei prüfe auf Temperatur: cmp d,b d enthält aber die Drehzahl, nicht die Temperatur, ich glaube da ist einfach wurde d mit t vertauscht. habs einfach mal die Kommentare geändert (nicht signierter Beitrag von 79.214.166.142 (Diskussion) 16:24, 22. Aug. 2011 (CEST))

utopisches Beispiel Patriot-Rakete

weiter oben wurde darüber schon diskutiert und gefragt ob das utopische Beispiel gelöscht werden soll. Ich habe mir erlaubt dies zu tun. Absolut utopisch.

Begründung 1: Ein Regelkreis besteht aus einer sensorik welche den Ist-Wert misst. Einem Regler der das Auswertet und einem Aktor, welcher den Prozess beeinflusst. Es macht überhaupt keinen Sinn Einen superschnellen Regler zu bauen, wenn das Gesamtsystem langsam reagiert. Dann ist eben die Lenkung der Flaschenhals. Die wird irgend eine Form von Mechanik haben. Da geht nanosekunden Reaktionszeit einfach nicht.

Begründung 2: Signallaufzeit: Licht macht in der ns 30cm. Was nützt es, wenn das Signal in 1 ns durch den Rechner geht aber mind. 10 ns (3m) braucht vom Radar (vorne) zur Lenkung(hinten) zu gelangen.

Begründug 3: Auch ein Analogrechner kann das nicht so schnell. Das ding muss integrieren. Analog integrieren heißt Kondensatoren laden. 1 ns -> quatsch

Begründung 4: Nehmen wir mal kurz an, das mit der ns stimmt. dann wäre die aussage: Härteste anforderungen bei Patriot trotzdem sehr merkwürdig, denn die SM3 raketen schiessen noch deutlisch schnellere ziele ab.

Indiez: Der letzte Befürworter dieser hat sich vor 3 Jahren ausgeklinkt (nicht signierter Beitrag von 87.182.3.145 (Diskussion) 20:19, 22. Aug. 2011 (CEST))

Harte Echtzeitanforderungen

Nach einer exakten Zeiterfassung der bereitzustellenden Anwendung sind Berechnungen gemäß der Theorie der Echtzeitsysteme notwendig. 

Diesen Satz verstehe ich (bin immerhin IT-ler) in einer Definition nicht. Kann jemand den mal bitte klarer vertändlich formulieren?

--Christian.Engel (Diskussion) 11:21, 14. Sep. 2012 (CEST)

Ich denke das soll heißen, dass man die WCET berechnen muss. (Hab leider gerade keine Zeit das schön zu schreiben)

--Morty (Diskussion) 08:33, 21. Sep. 2018 (CEST)

Synchrone Ansätze: FPGAs

FPGAs zu erwähnen und dann vom Ansatz "dass alle Aufgaben sequentiell so schnell wie möglich abgearbeitet werden" zu sprechen halte ich für mehr als unglücklich. Zu den Stärken von FPGAs zählt eben gerade die mögliche Nebenläufigkeit, so dass alle Aufgaben, welche keine direkten Abhängigkeiten haben eben nicht sequentiell, sondern parallel bearbeitet werden. Die Aufgabenlösung kann natürlich jeweils sequentielle Bestandteile haben aber das ist in vielen Fällen nur ein Abwägen von Hardware-Ressourcen, Rechenzeit und Größe der Hardwarestruktur (zu große Hardwareblöcke bringen keinen Gewinn mehr, da die Signallaufzeiten den Geschwindigkeitsgewinn durch Parallelisierung auffressen). Wenn Aufgaben sich nicht nebenläufig lösen lassen, so ist dies erstmal Eigenschaft des Problems und nicht der zur Lösung verwendeten Hardware.

Ich finde auf diesen Aspekt sollte besser eingegangen werden. Ggf. könnten hierbei auch Mehrkernprozessoren betrachtet werden. Wobei diese dadurch, dass sie tendenziell mehr Hardware enthalten die nicht von den Kernen gleichzeitig verwendet werden kann, natürlich nur bedingt Aufgaben nebenläufig lösen können. --77.187.162.185 23:46, 13. Aug. 2013 (CEST)

Definition von fester Echtzeit

Die Definition von fester Echtzeit unterscheidet sich wohl in den beiden Beiträgen Echtzeit und Echtzeitsystem. In dem Beitrag zur "Echtzeit" steht:

• feste Echtzeit wird manchmal verwendet um eine schärfere Anforderung als bei der harten Echtzeit zu definieren. Bei der festen Echtzeit ist keine Variation auch nach unten bei der Reaktionszeit erlaubt (Isochronität). Ein praktisches Beispiel wäre ein ADC-Baustein der idealerweise mit einer fixen Taktrate arbeiten sollte (in der Realität durch Jitter des Takts eingeschränkt).

während im Beitrag des Echtzeitsystems steht:

• feste Echtzeitanforderungen: Bei festen Echtzeitanforderungen droht kein unmittelbarer Schaden. Nach Ablauf der Zeitanforderungen ist das Ergebnis der Berechnung jedoch nutzlos und kann verworfen werden.

Es wird nicht klar, ob es sich nun um eine kritischere oder um eine unkritischere Grenze handelt. Werden die Ausführungszeiten auch nach unten hin eingehalten (Isochronität), oder geht es wirklich nur um die Unbrauchbarkeit der Daten, wenn die notwendige Zeitanforderung nicht eingehalten wird? Hilby84 (Diskussion) 16:15, 11. Dez. 2013 (CET)

IMO ist die bei Echtzeit falsch.

--Morty (Diskussion) 08:34, 21. Sep. 2018 (CEST)

Defekte Weblinks

Dieser Baustein verhindert die automatische Archivierung dieses Abschnitts und seiner Unterabschnitte.

Die folgenden Weblinks wurden von einem Bot („GiftBot“) als nicht erreichbar erkannt.
Ausführliche Erläuterungen und Hilfe zur korrekten Behebung dieser Fehler finden sich auf Wikipedia:Defekte Weblinks. Ist ein von einem Bot als defekt gemeldeter externer Link doch erreichbar, dann bitte berichten – wie auch sonstige Probleme.

• http://www.dedicated-systems.com/encyc/
  • Vielleicht ist eine archivierte Version geeignet: archive.orghttp://giftbot.dwl.invalid/http://www.dedicated-systems.com/encyc/
• http://www.dedicated-systems.com/magazine/magazine.htm
  • Vielleicht ist eine archivierte Version geeignet: archive.orghttp://giftbot.dwl.invalid/http://www.dedicated-systems.com/magazine/magazine.htm

– GiftBot (Diskussion) 10:59, 28. Nov. 2015 (CET)

Quelle für 10 ms bei Eingabeverarbeitung?

Der aktuelle Artikel sagt: "Computer-Programme, deren Reaktionszeiten auf Anwender-Eingaben mit Eingabegeräten (Tastatur, Maus etc.) unter 10 ms liegen, werden subjektiv als sofort wahrgenommen (siehe Usability)." Die Zahl ist nicht mit einer Quelle belegt. Weder beim Querlesen unter Usability noch in einer kurzen Web-Suche habe ich einen Beleg dafür gefunden. Ist jemandem eine Quelle dieser Zahl bekannt?

Von Jakob Nielsen gibt es eine (englische) Quelle: "0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result." https://www.nngroup.com/articles/response-times-3-important-limits/ --91.64.117.56 17:16, 31. Aug. 2017 (CEST)

Limitierung Reaktionszeit durch Hardware und Software

Zitat aus dem Artikel: "In der Praxis lässt sich eine beliebig kleine Zeitschranke mangels genügend schneller Hardware nicht immer realisieren." - Leider nicht präzise genug formuliert. Es fehlt der Beitrag der Software. Selbst auf schnellster Hardware kann es wegen ungünstig programmierter Software zu endlosen Antwortzeiten kommen. - Dies steht auch hier bereits https://de.wikipedia.org/wiki/Echtzeit, Zitat: "Durch die Hardware und Software muss sichergestellt werden, dass keine Verzögerungen auftreten, welche die Einhaltung dieser Bedingung verhindern könnten."

Vorschlag: "In der Praxis lässt sich eine beliebig kleine Zeitschranke mangels genügend schneller Hardware oder Limitierungen in der Software nicht immer realisieren."

Meinungen? --BauerJKH (Diskussion) 20:16, 23. Aug. 2022 (CEST)

Passt für mich. Natürlich ist die Software gerade dann kritisch, wenn das System z.B. auf einem eigentlich nicht für harte Echtzeit ausgelegten Betriebssystem laufen soll. --PaterMcFly Diskussion ^Beiträge 12:07, 24. Aug. 2022 (CEST)