Ich meine, wie und warum sind Echtzeit-Betriebssysteme in der Lage, Fristen einzuhalten, ohne sie jemals zu verpassen? Oder ist das nur ein Mythos (dass sie keine Fristen verpassen)? Wie unterscheiden sie sich von einem normalen Betriebssystem und was hindert ein normales Betriebssystem daran, ein RTOS zu sein?
"Im Grunde muss man jede "Aufgabe" im RTOS so kodieren, dass sie in einer endlichen Zeit beendet wird."
Dies ist tatsächlich richtig. Das RTOS hat einen durch die Architektur definierten Systemtakt, z. B. 10 Millisekunden, wobei alle Aufgaben (Threads) so konzipiert und gemessen werden, dass sie innerhalb bestimmter Zeiten abgeschlossen werden. Bei der Verarbeitung von Echtzeit-Audiodaten mit einer Abtastrate von 48 kHz gibt es beispielsweise eine bekannte Zeitspanne (in Millisekunden), in der der Vorpuffer für jede nachgelagerte Aufgabe, die die Daten verarbeitet, leer wird. Die Verwendung des RTOS erfordert daher eine korrekte Dimensionierung der Puffer, die Abschätzung und Messung der dafür benötigten Zeit und die Messung der Latenzen zwischen allen Softwareschichten im System. Dann können die Fristen eingehalten werden. Andernfalls werden die Anwendungen die Fristen nicht einhalten können. Dies erfordert eine Analyse der Worst-Case-Datenverarbeitung im gesamten Stack, und sobald der Worst-Case bekannt ist, kann das System für, sagen wir, 95 % Verarbeitungszeit bei 5 % Leerlaufzeit ausgelegt werden (diese Verarbeitung wird in der realen Nutzung möglicherweise nie eintreten, da die Worst-Case-Datenverarbeitung zu keinem Zeitpunkt ein zulässiger Zustand innerhalb aller Schichten sein kann).
Beispielhafte Timing-Diagramme für den Entwurf einer Echtzeit-Betriebssystem-Netzwerkanwendung finden Sie in diesem Artikel der EE Times, PRODUCT HOW-TO: Verbesserung der Echtzeit-Sprachqualität in einem VoIP-basierten Telefonie-Design http://www.eetimes.com/design/embedded/4007619/PRODUCT-HOW-TO-Improving-real-time-voice-quality-in-a-VoIP-based-telephony-design
Wichtig sind Echtzeitanwendungen, nicht Echtzeitbetriebssysteme. In der Regel sind Echtzeitanwendungen vorhersehbar: Es wurden viele Tests, Inspektionen, WCET-Analysen, Nachweise usw. durchgeführt, die zeigen, dass die Fristen in allen vorgegebenen Situationen eingehalten werden.
Es kommt vor, dass RTOSs bei dieser Arbeit helfen (Erstellung der Anwendung und Überprüfung ihrer RT-Einschränkungen). Ich habe aber auch schon Echtzeitanwendungen gesehen, die auf einem Standard-Linux laufen und sich mehr auf die Leistung der Hardware als auf das Design des Betriebssystems verlassen.
Ein RTOS bietet sehr strenge Garantien für wichtige Dinge wie Unterbrechungszeiten, Latenzzeiten beim Taskwechsel usw. Echtzeitanwendungen sind ohne ein geeignetes RTOS NICHT möglich.
Ich habe noch nie ein RTOS benutzt, aber ich glaube, dass sie so funktionieren.
Es gibt einen Unterschied zwischen "harter Echtzeit" und "weicher Echtzeit". Sie können Echtzeitanwendungen auf einem Nicht-RTOS wie Windows schreiben, aber sie sind "weiche" Echtzeit:
Als Anwendung könnte ich einen Thread oder Timer haben, den ich vom Betriebssystem 10 Mal pro Sekunde ausführen lasse ... und vielleicht wird das Betriebssystem das tun, meistens, aber es gibt keine Garantie, dass es immer dazu in der Lage sein wird ... dieser Mangel an Garantie ist der Grund, warum es "soft" genannt wird. Der Grund, warum das Betriebssystem dazu nicht in der Lage ist, ist, dass ein anderer Thread das System mit etwas anderem beschäftigt. Als Anwendung kann ich meine Thread-Priorität zum Beispiel auf HIGH_PRIORITY_CLASS aber selbst wenn ich das tue, hat das Betriebssystem immer noch keine API, die ich verwenden kann, um eine Garantie dass ich zu bestimmten Zeiten laufen werde.
Ein "hartes" Echtzeitbetriebssystem verfügt (so vermute ich) über APIs, mit denen ich garantierte Ausführungsslices anfordern kann. Der Grund, warum das RTOS solche Garantien geben kann, ist, dass es bereit ist, Threads abzubrechen, die mehr Zeit als erwartet / als erlaubt benötigen.
Es geht nicht nur um die Zeitplanung - das Betriebssystem muss sicherstellen, dass keine zufälligen Dinge wie Garbage Collection oder Defragmentierung des Speicheradressraums eintreten, so dass Sie sicher sein können, dass malloc() immer ohne Verzögerung zurückkehrt, damit (zum Beispiel) das Flugzeug, das der Autopilot steuert, nicht abstürzt.
... na ja ...
Ein Echtzeit-Betriebssystem versucht, deterministisch zu sein und Fristen einzuhalten, aber es hängt alles davon ab, wie Sie Ihre Anwendung schreiben. Man kann ein RTOS sehr unrealistisch machen, wenn man nicht weiß, wie man "richtigen" Code schreibt.
Selbst wenn Sie wissen, wie man richtigen Code schreibt: Es geht mehr darum, deterministisch als schnell zu sein.
Wenn wir über Determinismus sprechen, ist es
1) Ereignis-Determinismus
Für jeden Satz von Eingaben sind die nächsten Zustände und Ausgaben eines Systems bekannt
2) zeitlicher Determinismus
auch die Reaktionszeit für jeden Satz von Ausgängen bekannt ist
Das bedeutet, dass Ihr System bei asynchronen Ereignissen wie Interrupts streng genommen nicht mehr zeitlich deterministisch ist. (und die meisten Systeme verwenden Interrupts)
Wenn Sie wirklich deterministisch sein wollen, fragen Sie alles ab.
... aber vielleicht ist es nicht notwendig, 100% deterministisch zu sein
"Wenn man wirklich deterministisch sein will, muss man alles abfragen." - Was ist, wenn Sie zwischen den Abfragezyklen ein Ereignis mit höherer Priorität verpassen? Reagiert das Betriebssystem dann nicht nicht in Echtzeit auf diese Ereignisse?
Natürlich wird es das, aber Sie haben Ihre Analyse durchgeführt und sichergestellt, dass alle Ereignisse außerhalb des Betriebssystems innerhalb bestimmter Zeitgrenzen eintreffen (so etwas wie ein sporadischer Server für Ihre Eingaben). In einem Fehlerfall (Kabelbruch) sollten Sie die Ereignisse ohnehin verwerfen. Durch Polling und den Verzicht auf Interrupts stellen Sie sicher, dass die Verwendung von Interrupts den Determinismus nicht weiter beeinträchtigt.
Wollen Sie damit sagen, dass dies ein Kompromiss zwischen Latenz und Determinismus ist? IMO versagt das Modell "Ereignisse an genau definierten Grenzen", wenn es eine Ereignishierarchie gibt (d.h. priorisierte Ereignisse). Es gibt keinen Grund, warum ein völlig unverbundenes Ereignis die zeitlichen Grenzen eines Ereignisses/einer Aufgabe mit niedriger Priorität (LP) respektieren sollte. Die LP-Aufgabe muss auch dann vorgezogen werden, wenn das HP-Ereignis zum Zeitpunkt t0+dt eintritt. Dabei ist dt eine unendlich kleine Zeitspanne und t0 der Zeitpunkt, zu dem die LP-Aufgabe begonnen hat.
Die Lehrbuch-/Interview-Antwort lautet "deterministische Präemption". Das System garantiert die Übergabe der Kontrolle innerhalb eines bestimmten Zeitraums, wenn ein Prozess mit höherer Priorität bereit ist (in der Bereitschaftswarteschlange) oder ein Interrupt ausgelöst wird (typischerweise ein Eingang von außerhalb der CPU/MCU).
CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.
1 Stimmen
Es ist auch wichtig, den Unterschied zwischen einem "weichen" Echtzeitsystem und einem "harten" Echtzeitsystem zu beachten.