Welche Garantien bieten „weiche“ Echtzeitbetriebssysteme tatsächlich?

Ich denke, ich weiß, was ein "hartes" Echtzeit-Betriebssystem ist. Es ist ein Betriebssystem mit einem Scheduler, der einen Vertrag mit dem Anwendungsprogrammierer bereitstellt. Ein Antrag enthält eine Frist für jede Ressourcenzuweisungsanforderung. Wenn die Terminanfragen möglich sind , garantiert der Scheduler, dass jede Ressource der anfragenden Anwendung vor dem Termin zugewiesen wird. Die Garantie reicht aus, damit ein Anwendungsprogrammierer über die maximale Latenz und den minimalen Durchsatz bestimmter Anforderungen nachdenken kann.

Alle Definitionen für "weiche" Echtzeitsysteme scheinen mir leer zu sein. Wikipedia sagt

Die Nützlichkeit eines Ergebnisses verschlechtert sich nach Ablauf der Frist, wodurch sich die Servicequalität des Systems verschlechtert.

Uhhhh. Okay. Nach diesen Kriterien war Windows 95 ein Soft-Real-Time-System, ebenso wie 3BSD und Linux. Wikipedia ist keine gute Quelle, aber die nächsten paar Google-Hits sind nicht viel besser. Zum Beispiel http://users.ece.cmu.edu/~koopman/des_s99/real_time/ sagt

In einem weichen Echtzeitsystem kann ein beeinträchtigter Betrieb bei einer selten auftretenden Spitzenlast toleriert werden.

Das ist kein Vertrag, das ist eine ausgefallene Art, nichts zu sagen.

Was sind Beispiele für echte Echtzeitgarantien / -verträge, die von echten Betriebssystemen angeboten werden?

Ich suche nach Antworten der Form:

In (OS-Name) Wenn der Programmierer das tut (was der Programmierer zu tun hat), dann garantiert das Betriebssystem (was das System garantiert).

Sie haben es richtig gemacht, und Wikipedia ist so informativ wie möglich - weiche Echtzeit ist keine formale Charakterisierung, sondern ein Werturteil. Eine andere Möglichkeit, „weiche Echtzeit“ zu sagen, ist „Ich wünschte, es wäre Echtzeit“ oder genauer gesagt „es sollte Echtzeit sein, aber das ist zu schwierig“.

Wenn Sie wirklich in Form einer Garantie formulieren möchten, ist dies eher eine Garantie für bestmögliche Leistung als eine Garantie für bestimmte Leistungen.

Oder um die Erlang- FAQ zu zitieren (Erlang ist eine Programmiersprache, die ursprünglich für die Verwendung in der Telefonie entwickelt wurde):

Was bedeutet weiche Echtzeit?

Zyniker werden "im Grunde nichts" sagen.

(…) Viele Telekommunikationssysteme haben weniger strenge Anforderungen (als harte Echtzeitanforderungen), beispielsweise erfordern sie möglicherweise eine statistische Garantie, wie sie beispielsweise "eine Datenbanksuche dauert in 97% der Fälle weniger als 20 ms". Mit Soft-Realtime-Systemen wie Erlang können Sie diese Garantie übernehmen.

Und dies liefert eine nützliche Definition. Weiche Echtzeit gibt ein Design an, das für jede einzelne Aufgabe optimiert wird, die nur eine bestimmte Zeit benötigt , und nicht für die Optimierung der Gesamtzeit, die für die Ausführung aller Aufgaben aufgewendet wird. Beispielsweise würde ein Soft-Echtzeitsystem darauf abzielen, 99,9% der Anforderungen in 10 ms zu erledigen und 100 Anforderungen pro Sekunde zu verarbeiten, wobei eine Nicht-Echtzeit möglicherweise darauf abzielt, 200 Anforderungen pro Sekunde zu verarbeiten, aber gelegentliche Anforderungen blockieren zu lassen 50 ms oder mehr. Eine harte Echtzeit garantiert eine Anfrage alle 15 ms, egal was passiert.

Soft-Echtzeit wird für Anwendungen verwendet, bei denen ein versäumter Termin eine Verschlechterung des Dienstes bedeutet, die jedoch nicht leistungskritisch ist. Multimedia und Telefonie sind einige typische Anwendungsfälle. Jedes Audio- oder Videobild muss gerendert oder übersprungen werden. Aber einen Frame zu überspringen ist nicht das Ende der Welt. Die Designer von Erlang hatten ähnliche Ziele in Bezug auf die Zuverlässigkeit in anderen Bereichen: Sie stellten fest, dass es für eine Telefonzentrale besser ist, gelegentlich einen Anruf zu beenden, aber absolut sicher zu sein, dass die Telefonzentrale als Ganzes weiterhin funktioniert, was auch immer kommen mag, als zu Es besteht immer die Gefahr eines katastrophalen Ausfalls, wenn versucht wird, Verbindungen um jeden Preis aufrechtzuerhalten.

Um einen Motor zu steuern, muss die Software dagegen niemals eine Frist verpassen. Dies hat Kosten: Die Gesamtleistung ist in der Regel langsamer und es können nur relativ einfache Verhaltensweisen erzielt werden. Auf der anderen Seite des Spektrums kümmert sich eine Anwendung zum Knacken von Zahlen in der Regel nur um die Gesamtleistung. Entscheidend ist, wie schnell die 1000x1000-Matrizen multipliziert werden und nicht, wie schnell jede Spalte berechnet wird.

Linux mit dem -rt (Echtzeit) -Patchset bietet einen Scheduler, der eine interessante Garantie bietet, die nicht leer zu sein scheint. (Obwohl mir nicht klar ist, wie die Garantie tatsächlich in Anspruch genommen werden kann.)

Die Linux-rt- SCHED_FIFOPlanungsrichtlinie funktioniert wie folgt: Der Benutzer weist jedem Prozess eine Priorität zu. (Die Prioritätsnummern für "Echtzeit" -Prozesse sind 0-99, und die traditionellen Unix- niceWerte -20 bis 19 werden den Prioritäten 100 bis 139 zugeordnet. ("0" ist also die "höchste" Priorität und "139" ist die "niedrigste" "Priorität.)

Die Garantie besteht darin, dass der Scheduler jederzeit die Nausführbaren Jobs mit der höchsten Priorität auf einem NProzessorcomputer plant . Es wurden große Anstrengungen unternommen, um vorrangige Inversionsprobleme innerhalb des Kernels zu vermeiden. Wenn ein Prozess Aausführbar wird und eine höhere Priorität als ein anderer Prozess hat B, Awird er sofort ausgeführt B.

Beachten Sie jedoch, dass keine strengen Zeitgarantien gegeben sind. Die tatsächlich aufgewendete Zeit für die Durchführung der Vorauszahlung könnte theoretisch beliebig lang sein. Es scheint auch einige Möglichkeiten zu geben, wie ein Job mit niedriger Priorität eine Reihe von I / O-Vorgängen mit langer Latenz auslösen kann. Wenn der E / A-Vorgang abgeschlossen ist, können die Interrupt-Handler für den Job mit niedriger Priorität einen Job mit höherer Priorität unterbrechen, was wohl eine Form der Prioritätsumkehr ist.

Die beschränkte Garantie lautet also: Wenn es einen einzelnen Prozess mit der höchsten Priorität gibt, erhält dieser, wann immer er ausführbar ist, alle Prozessorressourcen, die das Betriebssystem realistisch bereitstellen kann. Wenn Sie eine gute Obergrenze für die Menge der Prozessorressourcen haben, die vom Prozess mit der höchsten Priorität verbraucht werden, können Sie eine einigermaßen genaue Schätzung der Ressourcen berechnen, die für den Prozess mit der zweithöchsten Priorität usw. verfügbar sind.

Ein ausführlicher Artikel, der den Linux-Echtzeitplaner beschreibt, ist http://www.linuxjournal.com/magazine/real-time-linux-kernel-scheduler .

Um "weiche Echtzeit" zu definieren, ist es am einfachsten, sie mit "harter Echtzeit" zu vergleichen.

Lässig gesprochen, haben die meisten Menschen implizit ein informelles mentales Modell, das Informationen oder ein Ereignis als "Echtzeit" betrachtet.

• wenn oder in dem Maße, in dem es sich für sie mit einer Verzögerung (Latenz) manifestiert, die mit der wahrgenommenen Währung in Beziehung gesetzt werden kann

• dh in einem Zeitraum, in dem die Informationen oder Ereignisse für sie einen annehmbar zufriedenstellenden Wert haben.

Es gibt zahlreiche verschiedene Ad-hoc-Definitionen für "harte Echtzeit", aber in diesem mentalen Modell wird harte Echtzeit durch den "Wenn" -Begriff dargestellt. Insbesondere unter der Annahme, dass Echtzeitaktionen (wie Aufgaben) Ausführungsfristen haben, ist der akzeptable Wert des Ereignisses, dass alle Aufgaben abgeschlossen sind, auf den Sonderfall beschränkt, dass alle Aufgaben ihre Fristen einhalten.

Harte Echtzeitsysteme gehen stark davon aus, dass alles in Bezug auf die Anwendung und das System sowie die Umgebung statisch ist und von vornherein bekannt ist - z Es gibt keine Ressourcenkonflikte und insgesamt die zeitliche Entwicklung des Systems. In einem Flugsteuerungssystem für Flugzeuge oder in einem Bremssystem für Kraftfahrzeuge und in vielen anderen Fällen können diese Annahmen normalerweise erfüllt werden, so dass alle Fristen eingehalten werden.

Dieses mentale Modell ist bewusst und sehr nützlich allgemein genug, um sowohl harte als auch weiche Echtzeit zu erfassen - weich wird durch die Phrase "in dem Maße, in dem" berücksichtigt. Angenommen, das Ereignis task completions hat einen suboptimalen, aber akzeptablen Wert, 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 ist nicht mehr als 15%
• oder die maximale Verspätung unter allen Aufgaben ist weniger als 10%

All dies sind gebräuchliche Beispiele für Soft-Echtzeit-Fälle in einer Vielzahl von Anwendungen.

Betrachten Sie die Einzelanwendung, Ihr Kind nach der Schule abzuholen. Das hat wahrscheinlich keine tatsächliche Frist, sondern es gibt einen Wert für Sie und Ihr Kind, der davon abhängt, wann dieses Ereignis stattfindet. Eine zu frühe Verschwendung von Ressourcen (wie Ihre Zeit) und eine zu späte Verschwendung haben einen negativen Wert, da Ihr Kind möglicherweise in Ruhe gelassen wird und möglicherweise in Gefahr ist (oder zumindest Unannehmlichkeiten hat).

Im Gegensatz zum statischen Hard-Real-Time-Sonderfall werden bei Soft-Real-Time nur die minimal erforderlichen anwendungsspezifischen Annahmen über die Aufgaben und das System getroffen, und es werden Unsicherheiten erwartet. Um Ihr Kind abzuholen, müssen Sie zur Schule fahren. Die dafür erforderliche Zeit hängt vom Wetter, den Verkehrsbedingungen usw. ab. Sie könnten versucht sein, Ihr System überzubereiten (dh zuzulassen, was Sie sich erhoffen) Worst-Case-Fahrzeit), aber dies ist wiederum eine Verschwendung von Ressourcen (Ihre Zeit und die Belegung des Familienfahrzeugs, möglicherweise die Verweigerung der Nutzung durch andere Familienmitglieder).

Dieses Beispiel scheint in Bezug auf verschwendete Ressourcen nicht kostspielig zu sein, aber betrachten Sie andere Beispiele. Alle militärischen Kampfsysteme arbeiten in Echtzeit. Angenommen, Sie führen einen Flugzeugangriff auf ein feindliches Bodenfahrzeug mit einer Lenkwaffe durch, die mit Aktualisierungen als Zielmanöver geführt wird. Die maximale Zufriedenheit für die Erledigung der Aufgaben zur Aktualisierung des Kurses wird durch einen direkten zerstörerischen Treffer auf das Ziel erreicht. Ein Versuch, Ressourcen übermäßig bereitzustellen, um dieses Ergebnis sicherzustellen, ist jedoch in der Regel viel zu teuer und kann sogar unmöglich sein. In diesem Fall sind Sie möglicherweise weniger, aber ausreichend zufrieden, wenn die Rakete nahe genug an das Ziel heranschlägt, um es zu deaktivieren.

Offensichtlich weisen Kampfszenarien eine Vielzahl möglicher dynamischer Unsicherheiten auf, die vom Ressourcenmanagement berücksichtigt werden müssen. Weiche Echtzeitsysteme sind auch in vielen zivilen Systemen, wie der industriellen Automatisierung, weit verbreitet, obwohl offensichtlich militärische Systeme die gefährlichsten und dringendsten sind, um einen annehmbar zufriedenstellenden Wert zu erzielen.

Der Grundpfeiler von Echtzeitsystemen ist "Berechenbarkeit". Der harte Echtzeitfall interessiert sich nur für einen speziellen Fall der Vorhersehbarkeit - dh, dass alle Aufgaben ihre Fristen einhalten und der maximal mögliche Wert von diesem Ereignis erreicht wird. Dieser Sonderfall heißt "deterministisch".

Es gibt ein Spektrum von Vorhersagbarkeit; Die meisten Echtzeitsysteme (insbesondere weiche Systeme) sind nicht deterministisch vorhersehbar, z. B. hinsichtlich der Ausführungszeiten der Aufgaben und damit der aus diesen Ereignissen gewonnenen Werte. Im Allgemeinen kann die Vorhersehbarkeit und damit der Wert so nahe wie nötig am deterministischen Endpunkt liegen, jedoch zu einem Preis, der physikalisch unmöglich oder übermäßig teuer sein kann (wie im Kampf oder vielleicht sogar bei der Abholung Ihres Kindes von der Schule).

Für die weiche Echtzeit ist die anwendungsspezifische Auswahl eines Wahrscheinlichkeitsmodells (nicht des üblichen Frequenzmodells) und damit eines Vorhersagbarkeitsmodells erforderlich, um über Ereignislatenzen und daraus resultierende Werte nachzudenken.

Unter erneuter Bezugnahme auf die obige Liste von Ereignissen, die einen akzeptablen Wert liefern, können nun nicht deterministische Fälle hinzugefügt werden, z

• Die Wahrscheinlichkeit, dass eine Aufgabe ihre Frist um mehr als 5% verfehlt, ist größer als 0,87.

In einer Raketenabwehranwendung haben Sie angesichts der Tatsache, dass die Offensive im Kampf immer den Vorteil gegenüber der Defensive hat, welches dieser beiden Echtzeitszenarien Sie bevorzugen:

• Da die vollständige Zerstörung aller feindlichen Raketen sehr unwahrscheinlich oder unmöglich ist, weisen Sie Ihre Verteidigungsressourcen so zu, dass die Wahrscheinlichkeit maximiert wird, dass möglichst viele der bedrohlichsten (z. B. auf der Grundlage ihrer Ziele) feindlichen Raketen erfolgreich abgefangen werden kann die feindliche Rakete vom Kurs abbringen);

• Beschweren Sie sich, dass dies kein Echtzeit-Computerproblem ist, da es sich nicht um ein statisches, sondern um ein dynamisches Problem handelt und traditionelle Echtzeitkonzepte und -techniken nicht zur Anwendung kommen.

Trotz der verschiedenen Missverständnisse in Bezug auf weiche Echtzeit in der Community der Echtzeitcomputer (jedoch nicht in anderen Bereichen ohne Computer) ist weiche Echtzeit sehr allgemein und leistungsfähig und im Vergleich zu harter Echtzeit möglicherweise sehr komplex.

So beantworten Sie die OP-Frage direkt:

• Ein hartes Echtzeitsystem kann deterministische Garantien bieten - in der Regel, dass alle Aufgaben ihre Fristen einhalten, die Reaktionszeit von Interrupts oder Systemaufrufen immer kürzer als x usw. -, WENN UND NUR WENN sehr starke Annahmen getroffen wurden und diese richtig sind alles, was zählt, ist statisch und a priori bekannt (im Allgemeinen sind solche Garantien für harte Echtzeitsysteme ein offenes Forschungsproblem, mit Ausnahme von eher einfachen Fällen)

• Ein weiches Echtzeitsystem bietet keine deterministischen Garantien, sondern soll die bestmögliche analytisch festgelegte wahrscheinlichkeitstheoretische Aktualität und Vorhersagbarkeit der Aktualität bieten, die unter den gegenwärtigen dynamischen Umständen nach anwendungsspezifischen Kriterien möglich sind. Offensichtlich ist harte Echtzeit ein einfacher Spezialfall von weicher Echtzeit. Die analytischen nicht deterministischen Zusicherungen von soft real time können sehr komplex sein, sind jedoch in den häufigsten Fällen in Echtzeit (einschließlich der gefährlichsten sicherheitskritischen Fälle wie Kampf) obligatorisch, da die meisten Fälle dynamisch und nicht statisch sind.

Auf meiner Website real-time.org habe ich eine detailliertere und präzisere Diskussion über Echtzeit, harte Echtzeit, weiche Echtzeit, Vorhersagbarkeit, Determinismus und verwandte Themen .