it-swarm.com.de

Unterschiede zwischen harter Echtzeit, weicher Echtzeit und fester Echtzeit?

Ich habe die Definitionen für die unterschiedliche Vorstellungen von Echtzeit gelesen, und die Beispiele für harte und weiche Echtzeitsysteme sind für mich sinnvoll. Es gibt jedoch keine echte Erklärung oder kein Beispiel für ein festes Echtzeitsystem. Gemäß dem obigen Link:

Firm: Unregelmäßige Terminüberschreitungen sind tolerierbar, können jedoch die Servicequalität des Systems beeinträchtigen. Der Nutzen eines Ergebnisses ist nach Ablauf der Frist gleich Null.

Gibt es eine klare Unterscheidung zwischen fester Echtzeit- oder harter oder weicher Echtzeit und gibt es ein gutes Beispiel, das diese Unterscheidung veranschaulicht?

In Kommentaren bat Charles darum, Tag-Wikis für die neuen Tags einzureichen. Das Beispiel eines "festen Echtzeitsystems", das ich für das firm-real-time Tag zur Verfügung stellte, war ein Milchportionssystem. Wenn das System nach Ablauf der Zeit Milch liefert, wird die Milch als "nicht nützlich" angesehen. Man kann das Essen von Getreide ohne Milch ertragen, aber die Qualität des Erlebnisses verschlechtert sich.

Dies ist genau die Idee, die ich in meinem Kopf gebildet habe, als ich die Definition zuerst las. Ich suche nach einem viel besseren Beispiel und vielleicht nach einer besseren Definition von fester Echtzeit, die meine Vorstellung davon verbessern wird.

77
jxh

Harte Echtzeit bedeutet, dass Sie alle Termine unbedingt einhalten müssen. Sehr wenige Systeme haben diese Anforderung. Einige Beispiele sind Nuklearsysteme, einige medizinische Anwendungen wie Schrittmacher, eine Vielzahl von Verteidigungsanwendungen, Avionik usw.

Systeme mit fester/weicher Echtzeit können einige Fristen einhalten, aber die Leistung kann sich verschlechtern, wenn zu viele ausgelassen werden. Ein gutes Beispiel ist das Soundsystem in Ihrem Computer. Wenn Sie ein paar Bits vermissen, keine große Sache, aber zu viele, und Sie werden das System schließlich beeinträchtigen. Ähnlich wären seismische Sensoren. Wenn Sie ein paar Datenpunkte verpassen, keine große Sache, aber Sie müssen die meisten von ihnen erfassen, um die Daten zu verstehen. Noch wichtiger ist, dass niemand sterben wird, wenn er nicht richtig funktioniert.

Die Leitung ist unscharf, da selbst ein Schrittmacher um einen kleinen Betrag ausgeschaltet werden kann, ohne den Patienten zu töten, aber das ist der allgemeine Gist.

Es ist wie der Unterschied zwischen heiß und warm. Es gibt keine echte Kluft, aber Sie wissen es, wenn Sie es fühlen.

95
Joel

Harte Echtzeit

Die harte Echtzeit - Definition betrachtet jede versäumte Frist als Systemausfall. Diese Planung wird häufig in unternehmenskritischen Systemen eingesetzt, bei denen die Nichteinhaltung von zeitlichen Beschränkungen zu einem Verlust von Leben oder Eigentum führt. 

Beispiele:  

  • Der Air France Flight 447 stürzte in den Ozean, nachdem ein Sensorfehler eine Reihe von Systemfehlern verursacht hatte. Die Piloten stoppten das Flugzeug und reagierten auf veraltete Instrumentenablesungen. Alle 12 Besatzungsmitglieder und 216 Passagiere wurden getötet.

  • Das Mars Pathfinder-Raumschiff war fast verloren, als das System durch eine Prioritätsumkehr neu gestartet wurde. Eine Aufgabe mit höherer Priorität wurde nicht rechtzeitig abgeschlossen, da sie von einer Aufgabe mit niedrigerer Priorität blockiert wurde. Das Problem wurde behoben und das Raumfahrzeug landete erfolgreich.

  • Ein Tintenstrahldrucker verfügt über einen Druckkopf mit Steuerungssoftware zum Ablegen der korrekten Tintenmenge auf einen bestimmten Teil des Papiers. Wenn eine Frist nicht eingehalten wird, ruiniert der Druckauftrag.


Feste Echtzeit

Die Definition von Firm Real-Time ermöglicht selten verpasste Termine. In diesen Anwendungen kann das System Aufgabenfehler überstehen, solange sie ausreichend beabstandet sind, der Wert der Aufgabenerfüllung jedoch auf null sinkt oder unmöglich wird. 

Beispiele:

  • Fertigungssysteme mit Roboter Fertigungsstraßen, bei denen ein Termin nicht eingehalten wird, führt dies zu einer fehlerhaften Montage eines Teils. Solange zerstörte Teile selten genug sind, um von der Qualitätskontrolle erfasst zu werden, und nicht zu teuer sind, wird die Produktion fortgesetzt.

  • Eine Digitalkabel-Set-Top-Box decodiert Zeitstempel, wann Frames auf dem Bildschirm erscheinen müssen. Da die Frames zeitreihenabhängig sind, führt ein versäumter Termin zu Jitter, wodurch die Servicequalität abnimmt. Wenn das verpasste Bild später verfügbar wird, wird nur noch mehr Jitter angezeigt, so dass es unbrauchbar ist. Der Betrachter kann das Programm trotzdem genießen, wenn Jitter nicht zu oft auftritt.


Weiche Echtzeit

Die soft EchtzeitDefinition erlaubt häufig verpasste Termine und solange die Aufgaben rechtzeitig ausgeführt werden, haben ihre Ergebnisse immer noch einen Wert. Abgeschlossene Aufgaben können bis zum Stichtag einen ansteigenden Wert haben und abnehmen. 

Beispiele:

  • Wetterstationen verfügen über viele Sensoren zum Ablesen von Temperatur, Luftfeuchtigkeit, Windgeschwindigkeit usw. Die Messwerte sollten in regelmäßigen Abständen gemessen und übertragen werden, die Sensoren sind jedoch nicht synchronisiert. Auch wenn eine Sensorablesung im Vergleich zu den anderen früh oder spät erfolgt, kann sie dennoch relevant sein, solange sie nahe genug ist.

  • Eine Videospielkonsole führt Software für eine Spielengine aus. Es gibt viele Ressourcen, die zwischen den Aufgaben geteilt werden müssen. Gleichzeitig müssen Aufgaben gemäß dem Zeitplan ausgeführt werden, damit das Spiel korrekt ausgeführt werden kann. Solange die Aufgaben absolut pünktlich sind, wird das Spiel Spaß machen, und wenn nicht, kann es nur ein wenig verzögert werden.


Siewert: Echtzeit eingebettete Systeme und Komponenten.
Liu & Layland: Scheduling-Algorithmen für das Multiprogrammieren in einer harten Echtzeitumgebung.
Marchand & Silly-Chetto: Dynamische Einplanung weicher aperiodischer Aufgaben und periodischer Aufgaben mit Sprüngen .

68
John E Harriss

Nach dem Lesen der Wikipedia-Seite und anderer Seiten zum Echtzeit-Computing. Ich habe folgende Schlüsse gezogen:

1> Für ein hartes Echtzeitsystem, wenn das System die Frist nicht einhält, selbst wenn das System als fehlerhaft betrachtet wird.

2> Für ein Festes Echtzeitsystem gilt das System selbst dann als nicht fehlerhaft, wenn das System die Frist möglicherweise mehr als einmal (d. H. Für mehrere Anforderungen) nicht einhält. Auch die Antworten auf die Anforderungen (Antworten auf eine Abfrage, das Ergebnis einer Aufgabe usw.) sind wertlos, wenn die Frist für die jeweilige Anforderung abgelaufen ist (Der Nutzen eines Ergebnisses ist nach seiner Frist null) . Ein hypothetisches Beispiel kann ein Sturmvorhersagesystem sein (wenn ein Sturm vor dem Eintreffen vorhergesagt wird, hat das System seine Arbeit erledigt, eine Vorhersage, nachdem das Ereignis bereits stattgefunden hat oder wenn es passiert, ist wertlos).

3> Für ein Soft-Echtzeit-System gilt das System selbst dann als nicht fehlerhaft, wenn das System die Frist möglicherweise mehr als einmal (d. H. Für mehrere Anforderungen) nicht einhält. In diesem Fall sind die Ergebnisse der Anforderungen jedoch nicht wertlos Wert für ein Ergebnis nach dem Stichtag ist nicht Null, sondern verschlechtert sich im Laufe der Zeit nach dem Stichtag. Beispiel: Streaming von Audio-Video.

Hier ist ein Link zu einer Ressource, die sehr hilfreich war.

42
Meghendra

Es ist beliebt, eine große Katastrophe mit der Definition von harter Echtzeit in Verbindung zu bringen, aber dies ist nicht relevant. Jedes Versäumnis, eine harte Echtzeitbeschränkung zu erfüllen, bedeutet einfach, dass das System beschädigt ist. Der Schweregrad des Ergebnisses, wenn etwas als "gebrochen" bezeichnet wird, ist für die Definition nicht wesentlich.

Fest und weich werden einfach nicht als fehlerhaft erklärt, wenn eine bestimmte Frist nicht eingehalten wird.

Ein gutes Beispiel für harte Echtzeit von der verlinkten Seite:

Frühe Videospielsysteme wie die Vektorgrafiken Atari 2600 und Cinematronics hatten aufgrund der Beschaffenheit der Grafik- und Timing-Hardware harte Echtzeitanforderungen.

Wenn etwas in der Video-Erzeugungsschleife nur einen einzigen Termin verpasste, würde die gesamte Anzeige stören, was unerträglich wäre, selbst wenn es selten wäre. Das wäre ein defektes System, und Sie würden es für eine Rückerstattung zurück in den Shop bringen. Es ist also schwer in Echtzeit.

Natürlich kann jedes System Situationen unterliegen, mit denen es nicht umgehen kann. Daher muss die Definition auf die erwarteten Betriebsbedingungen beschränkt werden. In sicherheitskritischen Anwendungen muss der Benutzer schreckliche Bedingungen einplanen ("das Kühlmittel ist verdampft", " die Bremsen sind ausgefallen ", aber selten" ist die Sonne explodiert ").

Und vergessen wir nicht, dass es manchmal einen impliziten "Betriebszustand" gibt, während jemand beobachtet. Wenn niemand sieht, dass Sie gegen die Regeln verstoßen (oder wenn sie es getan haben, aber sie sterben das Feuer, bevor Sie es jemandem sagen), und niemand beweisen kann, dass Sie die Regeln danach verletzt haben, dann ist es so, als ob Sie nie gegen die Regeln verstoßen hätten!

11
sh1

Die einfachste Möglichkeit, zwischen den verschiedenen Arten von Echtzeitsystemtypen zu unterscheiden, ist die Beantwortung der Frage: 

Ist eine verspätete Systemreaktion (nach Ablauf der Frist) noch sinnvoll oder nicht?

Abhängig von der Antwort, die Sie für diese Frage erhalten, könnte Ihr System in eine der folgenden Kategorien aufgenommen werden:

  1. Hard : Nein und verzögerte Antworten werden als Systemfehler betrachtet 

Dies ist der Fall, wenn das Versäumnis der Deadline das System unbrauchbar macht. Zum Beispiel sollte das System, das das Auto-Airbagsystem steuert, den Zusammenstoß erkennen und den Beutel schnell aufblasen. Der gesamte Vorgang dauert ungefähr eine fünfundzwanzigstel Sekunde. Wenn das System beispielsweise mit einer Verzögerung von 1 Sekunde reagiert, könnten die Folgen tödlich sein, und es wäre von Vorteil, wenn der Sack aufgeblasen wird, wenn das Auto bereits abgestürzt ist.

  1. Firm : Nein, aber verspätete Antworten sind kein Systemfehler 

Dies ist der Fall, wenn der Termin nicht eingehalten werden kann, dies jedoch die Qualität der Dienstleistung beeinträchtigt. Als einfaches Beispiel kann ein Video-Verschlüsselungssystem betrachtet werden. Normalerweise wird das Verschlüsselungskennwort im Server (Video-Kopfende) generiert und an die Set-Top-Box des Kunden gesendet. Dieser Vorgang sollte synchronisiert werden, damit normalerweise die Set-Top-Box das Kennwort empfängt, bevor die verschlüsselten Videoframes empfangen werden. In diesem Fall kann eine Verzögerung zu Videoproblemen führen, da die Set-Top-Box die Frames nicht decodieren kann, da sie noch kein Kennwort erhalten hat. In diesem Fall könnte der Dienst (Film, ein interessantes Fußballspiel usw.) beeinträchtigt werden, wenn die Frist nicht eingehalten wird. Ein verzögertes Empfangen des Passworts ist in diesem Fall nicht sinnvoll, da die mit diesem verschlüsselten Frames die Störungen bereits verursacht haben. 

  1. Soft : Ja, aber der Systemdienst ist beeinträchtigt 

Wie aus der Wikipedia-Beschreibung der Nutzen eines Ergebnisses nimmt nach Ablauf der Frist ab. Das bedeutet, eine Antwort aus dem System außerhalb der Frist zu erhalten, ist für den Endbenutzer immer noch nützlich, aber seine Nützlichkeit nimmt nach Erreichen der Frist ab. Ein einfaches Beispiel für diesen Fall ist eine Software, die automatisch die Temperatur eines Raums (oder eines Gebäudes) steuert. In diesem Fall reagiert das System bei Verzögerungen beim Ablesen der Temperatursensoren etwas langsam auf brüske Temperaturänderungen. Am Ende reagiert es jedoch auf die Änderung und passt die Temperatur entsprechend an, um sie beispielsweise konstant zu halten. In diesem Fall ist also die verzögerte Reaktion nützlich, aber sie verschlechtert die Servicequalität des Systems. 

7
rkachach

Eine weiche Echtzeit ist am leichtesten zu verstehen, wobei die Ergebnisse auch dann als gültig betrachtet werden, wenn das Ergebnis nach Ablauf der Frist erhalten wird.

Beispiel: Webbrowser- Wir fordern eine bestimmte URL an. Das Laden der Seite dauert einige Zeit. Wenn das System mehr Zeit als erwartet benötigt, um uns die Seite zur Verfügung zu stellen, wird die erhaltene Seite nicht als ungültig betrachtet. Wir sagen nur, dass die Leistung des Systems nicht den Anforderungen entspricht (System hat geringe Leistung gebracht!).

Wenn im System {harte Echtzeit das Ergebnis nach Ablauf der Frist erhalten wird, gilt das System als vollständig ausgefallen.

Beispiel: Wenn ein Roboter eine Aufgabe ausführt, z. B. Linienverfolgung usw. Wenn sich ein Hindernis auf seinem Weg befindet und der Roboter diese Informationen nicht innerhalb einer programmierten Frist (fast sofort!) Verarbeitet, ist dies der Roboter soll seine Aufgabe nicht erfüllt haben (das Robotersystem kann auch völlig zerstört werden!). 

Wenn in Firm Real Time das Ergebnis der Prozessausführung nach Ablauf der Frist kommt, wird dieses Ergebnis verworfen, das System wird jedoch nicht als ausgefallen bezeichnet. 

Beispiel: Satellitenkommunikation zur Überwachung der Feindposition oder einer anderen Aufgabe. Wenn die Bodencomputerstation, zu der die Satelliten die Frames periodisch senden, überlastet ist und der aktuelle Frame (Paket) nicht rechtzeitig verarbeitet wird und der nächste Frame erscheint, ist das aktuelle Paket (derjenige, der die Frist nicht eingehalten hat) ohne Bedeutung ob die Verarbeitung abgeschlossen wurde (oder halb erledigt oder fast abgeschlossen ist), wird verworfen/verworfen. Der Bodencomputer gilt jedoch nicht als vollständig ausgefallen. 

5
Rubal

Um "weiche Echtzeit" zu definieren, ist es am einfachsten, sie mit "harter Echtzeit" zu vergleichen. Im Folgenden werden wir sehen, dass der Begriff "feste Echtzeit" ein Missverständnis über "weiche Echtzeit" darstellt.

In zufälliger Weise haben die meisten Menschen implizit ein informelles Denkmodell, das Informationen oder Ereignisse als "Echtzeit" betrachtet.

• wenn oder soweit es sich für sie mit einer Verzögerung (Latenz) manifestiert, die sich auf die wahrgenommene Währung beziehen kann

In einem Zeitrahmen, in dem die Information oder das Ereignis einen akzeptablen zufriedenstellenden Wert für sie hat.

Es gibt zahlreiche unterschiedliche Ad-hoc-Definitionen für "harte Echtzeit", aber in diesem mentalen Modell wird harte Echtzeit durch den Begriff "wenn" dargestellt. Unter der Annahme, dass Echtzeitaktionen (z. B. Aufgaben) Fertigstellungsfristen haben, ist der akzeptable Wert des Ereignisses, das alle Aufgaben erfüllen, auf den Sonderfall beschränkt, in dem alle Aufgaben ihre Termine einhalten.

Bei harten Echtzeitsystemen wird sehr stark davon ausgegangen, dass alles in Bezug auf die Anwendung, das System und die Umgebung statisch ist und als 'priori' bekannt ist - z. B. welche Aufgaben sie sind, dass sie periodisch sind, ihre Ankunftszeiten, ihre Fristen und ihre Fristen, die sie gewinnen Es gibt keine Ressourcenkonflikte und insgesamt die zeitliche Entwicklung des Systems. In einem Flugzeugflugsteuerungssystem oder einem Kraftfahrzeugbremssystem und vielen anderen Fällen können diese Annahmen normalerweise erfüllt werden, so dass alle Fristen eingehalten werden.

Dieses mentale Modell ist absichtlich und sehr nützlich allgemein genug, um sowohl harte als auch weiche Echtzeit zu umfassen - weich wird durch den Ausdruck "in dem Ausmaß, dass" dies berücksichtigt. Nehmen Sie beispielsweise an, dass das Task Completion-Ereignis einen suboptimalen, aber akzeptablen Wert hat, wenn

  • nicht mehr als 10% der Aufgaben verfehlen ihre Fristen
  • oder keine Aufgabe ist mehr als 20% verspätet
  • oder die durchschnittliche Verspätung aller Aufgaben beträgt nicht mehr als 15%
  • oder die maximale Verspätung aller Aufgaben beträgt weniger als 10%

Dies sind alles gängige Beispiele für weiche Echtzeitfälle in einer Vielzahl von Anwendungen.

Erwägen Sie die Einzelanwendung, Ihr Kind nach der Schule abzuholen. Das hat wahrscheinlich keine tatsächliche Frist, stattdessen gibt es einen Wert für Sie und Ihr Kind, je nachdem, wann das Ereignis stattfindet. Zu früh verschwendet Ressourcen (z. B. Ihre Zeit), und zu spät hat einen negativen Wert, da Ihr Kind möglicherweise allein gelassen wird und möglicherweise Schaden erleidet (oder zumindest unangenehm ist).

Im Gegensatz zum statischen harten Echtzeit-Spezialfall macht Soft-Echtzeit nur die minimal erforderlichen anwendungsspezifischen Annahmen über die Aufgaben und das System aus, und es werden Unsicherheiten erwartet. Um Ihr Kind abzuholen, müssen Sie zur Schule fahren, und die Zeit dafür ist dynamisch, abhängig von Wetter, Verkehrsbedingungen usw. Sie könnten versucht sein, Ihr System zu übermäßig zu versorgen (dh, was Sie hoffen, ist das.) im schlimmsten Fall), aber dies ist wiederum Ressourcenverschwendung (Ihre Zeit und die Belegung des Familienfahrzeugs, die möglicherweise die Verwendung durch andere Familienmitglieder ablehnt).

Dieses Beispiel scheint in Bezug auf verschwendete Ressourcen nicht kostspielig zu sein, betrachtet jedoch andere Beispiele. Alle militärischen Kampfsysteme sind weiche Echtzeit. Stellen Sie sich beispielsweise vor, einen Flugzeugangriff auf ein feindliches Bodenfahrzeug durchzuführen, indem Sie eine Rakete mit Aktualisierungen als Zielmanöver verwenden. Die maximale Zufriedenheit bei der Durchführung der Kursaktualisierungsaufgaben wird durch einen direkten zerstörerischen Angriff auf das Ziel erreicht. Der Versuch, die Ressourcen zu überressourcen zu sichern, ist jedoch in der Regel viel zu teuer und möglicherweise sogar unmöglich. In diesem Fall sind Sie möglicherweise weniger zufrieden, wenn die Rakete so nahe an das Ziel fällt, dass sie abgeschaltet werden kann.

Offensichtlich haben Kampfszenarien viele mögliche dynamische Unsicherheiten, die vom Ressourcenmanagement berücksichtigt werden müssen. Soft-Echtzeit-Systeme sind auch in vielen zivilen Systemen, wie z. B. in der industriellen Automatisierung, sehr verbreitet, obwohl militärische Systeme die gefährlichsten und dringendsten sind, um einen akzeptablen zufriedenstellenden Wert zu erzielen.Der Grundpfeiler von Echtzeitsystemen ist "Vorhersagbarkeit". Der harte Echtzeitfall ist nur an einem speziellen Fall von Vorhersagbarkeit interessiert - d. H., Dass alle Aufgaben ihre Fristen einhalten und der maximal mögliche Wert durch dieses Ereignis erreicht wird. Dieser Sonderfall wird als "deterministisch" bezeichnet.

Es gibt ein Spektrum von Vorhersagbarkeit. Deterministisch (Determinismus) ist ein Endpunkt (maximale Vorhersagbarkeit) des Vorhersagbarkeitsspektrums; Der andere Endpunkt ist die Mindestvorhersagbarkeit (maximaler Nicht-Determinismus). Die Metriken und Endpunkte des Spektrums müssen anhand eines gewählten Vorhersagbarkeitsmodells interpretiert werden. Alles zwischen diesen beiden Endpunkten ist Grad der Unvorhersagbarkeit (= Grad des Nicht-Determinismus). 

Die meisten Echtzeitsysteme (nämlich Soft-Systeme) haben eine nicht deterministische Vorhersagbarkeit, z. B. der Ausführungszeiten der Aufgaben und damit der aus diesen Ereignissen gewonnenen Werte. 

Im Allgemeinen (theoretisch) kann die Vorhersagbarkeit und damit ein akzeptabler zufriedenstellender Wert so weit wie nötig an den deterministischen Endpunkt herangezogen werden - jedoch zu einem Preis, der physisch unmöglich oder übermäßig teuer sein kann (wie im Kampf oder vielleicht sogar im Westen) Ihr Kind von der Schule abholen). 

Soft-Echtzeit erfordert eine anwendungsspezifische Auswahl eines Wahrscheinlichkeitsmodells (nicht des Modells für häufige häufige Besucher) und damit des Vorhersagbarkeitsmodells, um über Ereignislatenzen und daraus resultierende Werte nachzudenken.

Unter Bezugnahme auf die obige Liste von Ereignissen, die einen akzeptablen Wert bieten, können wir nun nicht deterministische Fälle hinzufügen, wie z.

  • in einer Raketenabwehranwendung angesichts der Tatsache, dass das Vergehen im Kampf immer einen Vorteil gegenüber der Verteidigung hat, welches dieser beiden Echtzeit-Berechnungsszenarien würden Sie bevorzugen:

  • trotz der verschiedenen Missverständnisse in Bezug auf Soft-Echtzeit in der Echtzeit-Computing-Community ist Soft-Real-Time sehr allgemein und mächtig, auch wenn sie im Vergleich zu Hard-Real-Time möglicherweise komplex ist. Soft-Echtzeit-Systeme, wie sie hier zusammengefasst sind, haben eine lange Erfolgsgeschichte außerhalb der Echtzeit-Community computing.

Um die OP-Frage direkt zu beantworten:.

Ein hartes Echtzeitsystem kann deterministische Garantien bieten. Meistens ist es so, dass alle Aufgaben ihre Termine einhalten, Interrupts oder Reaktionszeiten des Systemaufrufs immer unter x liegen usw. - WENN UND NUR WENN sehr starke Annahmen getroffen werden und dies richtig sind alles, worauf es ankommt, ist statisch und a priori bekannt (im Allgemeinen sind solche Garantien für harte Echtzeitsysteme ein offenes Forschungsproblem, abgesehen von eher einfachen Fällen).

Ein Soft-Echtzeit-System gibt keine deterministischen Garantien ab, sondern soll die bestmögliche analytisch spezifizierte und durchgeführte probabilistische Aktualität und Vorhersagbarkeit der Aktualität bieten, die unter den aktuellen dynamischen Umständen gemäß anwendungsspezifischen Kriterien möglich ist.

Natürlich ist harte Echtzeit ein einfacher Spezialfall von weicher Echtzeit. Offensichtlich können analytische, nicht deterministische Zusicherungen von Soft-Echtzeit sehr komplex sein. Sie sind jedoch in den meisten Echtzeitfällen (einschließlich der gefährlichsten sicherheitskritischen Fälle wie Kampf) zwingend, da die meisten Echtzeitfälle nicht dynamisch sind statisch. 

"Feste Echtzeit" ist ein schlecht definierter Spezialfall von "weicher Echtzeit". Dieser Begriff ist nicht erforderlich, wenn der Begriff "weiche Echtzeit" richtig verstanden und verwendet wird.

Ich habe auf meiner Website real-time.org eine detailliertere, viel genauere Diskussion über Echtzeit, hartes Echtzeit, weiches Echtzeit, Vorhersagbarkeit, Determinismus und verwandte Themen.

I have a more detailed much more precise discussion of real-time, hard real-time, soft real-time, predictability, determinism, and related topics on my web site real-time.org.

5

echtzeit - Bezieht sich auf ein System oder eine Betriebsart, in der die Berechnung während der tatsächlichen Zeit durchgeführt wird, in der ein externer Prozess auftritt, damit die Berechnungsergebnisse dazu verwendet werden können, den externen Prozess rechtzeitig zu steuern, zu überwachen oder darauf zu reagieren Weise. [IEEE-Standard 610.12.1990] 

Ich weiß, dass diese Definition alt ist, sehr alt. Ich kann jedoch keine neuere Definition des IEEE (Institute of Electrical and Electronics Engineers) finden.

2
Mike Jablonski

Stellen Sie sich eine Aufgabe vor, die Daten vom seriellen Port eingibt. Wenn neue Daten eingehen, löst die serielle Schnittstelle ein Ereignis aus. Wenn die Software dieses Ereignis bedient, liest und verarbeitet sie die neuen Daten. Die serielle Schnittstelle verfügt über eine Hardware zum Speichern eingehender Daten (2 beim MSP432, 16 beim TM4C123), sodass die neuen Daten verloren gehen, wenn der Puffer voll ist und mehr Daten ankommen. Ist dieses System hart, fest oder weich in Echtzeit?

Es ist harte Echtzeit , weil bei verspäteter Antwort Daten verloren gehen können.


Stellen Sie sich ein Hörgerät vor, das Töne von einem Mikrofon eingibt, die Tondaten manipuliert und dann an einen Lautsprecher ausgibt. Das System hat normalerweise einen kleinen und begrenzten Jitter, aber gelegentlich führen andere Aufgaben im Hörgerät dazu, dass einige Daten verspätet werden, was zu einem Rauschimpuls auf dem Lautsprecher führt. Ist dieses System hart, fest oder weich in Echtzeit?

Es ist feste Echtzeit , weil es einen Fehler verursacht, der wahrgenommen werden kann, der Effekt jedoch harmlos ist und die Qualität der Erfahrung nicht wesentlich ändert.


Stellen Sie sich eine Aufgabe vor, die Daten an einen Drucker ausgibt. Wenn sich der Drucker im Leerlauf befindet, löst der Drucker ein Ereignis aus. Wenn die Software dieses Ereignis bedient, sendet sie mehr Daten an den Drucker. Ist dieses System hart, fest oder weich in Echtzeit?

Es ist weiche Echtzeit , weil je schneller es reagiert, desto besser, aber der Wert des Systems (Bandbreite ist die Menge der pro Sekunde gedruckten Daten) nimmt mit der Latenzzeit ab.

UTAustinX: UT.RTBN.12.01x Echtzeit-Bluetooth-Netzwerke 

Vielleicht ist die Definition falsch.

Aus meiner Erfahrung würde ich die beiden als abhängig von Hardware und Software trennen.

Wenn Sie 200 ms Zeit haben, um einen hardwaregetriebenen Interrupt zu warten, haben Sie genau das. Sie halten 300ms Code da und das System ist nicht kaputt, es wurde nicht entwickelt. Sie werden ausgeschaltet, bevor Sie fertig sind. Ihr Code funktioniert nicht oder ist nicht für den Zweck geeignet. Viele Systeme haben fest definierte Bearbeitungszeiten. Video, Telekommunikation usw. 

Wenn Sie eine Anwendung schreiben, die in Echtzeit ist, könnte dies als soft betrachtet werden. Wenn Sie keine Zeit mehr haben, könnten Sie beim nächsten Mal weniger Last benötigen, das Betriebssystem anpassen, Speicher hinzufügen oder sogar die Hardware aufrüsten. Sie haben Optionen.

Es ist nicht hilfreich, es aus einer UX-Perspektive zu betrachten. Ein Skoda ist vielleicht nicht kaputt, wenn er stört, aber ein BMW wird sicher sein.

1
Steve

Die Definition wurde im Laufe der Jahre zum Nachteil der Laufzeit ausgeweitet. Was jetzt als "harte" Echtzeit bezeichnet wird, wird früher einfach Echtzeit genannt. Daher sollten Systeme, bei denen fehlende Zeitfenster (anstelle von einseitigen Zeitvorgaben) falsche Daten ergeben würden, oder falsches Verhalten in Echtzeit berücksichtigen. Systeme ohne dieses Merkmal würden als Nicht-Echtzeit betrachtet. 

Das bedeutet nicht, dass die Zeit in Nicht-Echtzeitsystemen nicht von Interesse ist, sondern lediglich, dass die Zeitanforderungen in solchen Systemen nicht zu grundsätzlich falschen Ergebnissen führen.

1
user1671787

Harte Echtzeitsysteme verwenden eine präventive Version der Prioritätsplanung, sodass kritische Tasks sofort geplant werden, wohingegen weiche Echtzeitsysteme eine nicht preemptive Version der Prioritätsplanung verwenden, die es ermöglicht, die aktuelle Task zu beenden, bevor die Steuerung auf die höhere Priorität übertragen wird Aufgabe, was zu zusätzlichen Verzögerungen führt. So werden die Fristen der Aufgaben in harten Echtzeitsystemen kritisch eingehalten, während sie in weichen Echtzeitsystemen nicht so ernst genommen werden.

0
Kishor Bhoyar