RTOS oder nicht RTOS ist die Frage

Ich wurde aufgefordert, diesen Artikel durch eine lange Reihe von Kommentaren (leider kann ich dies nicht als Diskussion bezeichnen) zu meinem kürzlich erschienenen Artikel "Die vielfältige Welt eingebetteter Systeme und der Platz von Embox darin" zu schreiben . Ich wurde an mehreren Stellen beschuldigt, RTOS und Embedded OS verwirrt zu haben, was ich LynxOS, QNX und VxWorks nannte, nicht RTOS, obwohl ich es meiner Meinung nach natürlich nicht tat. Ich schlug dem Autor dieser Kommentare mehrmals vor, einen Artikel zu schreiben, in dem er seine Vision des Konzepts des „Echtzeit-Betriebssystems“ darlegte, aber aus irgendeinem Grund lehnte er ab. Nun, ich werde meine Vision dieses Begriffs vorstellen und diskutieren, was RTOS heißen kann und was nicht. Am Ende wird diese Frage oft in Bezug auf Embox gestellt .

Der Begriff OS RV (RTOS) bezieht sich auf den Bereich Marketing!

Ich dachte, ich würde auf wissenschaftliche Weise mit der Einführung von Begriffen beginnen, entschied aber, dass diese provokative These sehr willkommen wäre. Warum argumentiere ich also, dass der Begriff RTOS (Echtzeitbetriebssysteme) sich auf Marketing bezieht, genauer gesagt, ein Marketing- (Werbe-) Slogan ist? Alles ist einfach. Wenn ein Produkt hergestellt wird, muss es verkauft werden. Wenn Sie jedoch versuchen, nur das Betriebssystem zu verkaufen, treten Schwierigkeiten auf. Hier kommt die Marktpositionierung zum Einsatz. Zum Beispiel könnte man sagen: "Wir sind schneller als sie."


Aber Sie können dafür vor Gericht gehen! Und dort müssen Sie Beweise vorlegen. Aber wie kann man beweisen, dass man in allen Fällen schneller ist? Dies ist kein laufender Wettbewerb. Aber natürlich ist ein solcher nicht ganz korrekter Wettbewerb etwas außerhalb der normalen Position auf dem Markt.

Bei der normalen Positionierung wird ein Porträt des Verbrauchers erstellt, die gefragtesten Eigenschaften des Produkts identifiziert und auf diese Eigenschaften konzentriert. Nun, oder Sie bilden diese Bedürfnisse beim Benutzer. Zum Beispiel hat unser Prozessor eine solche Frequenz, das Smartphone hat einen N-Core-Prozessor und so weiter.

Da die Klassiker des Genres bereits formuliert haben, dass Betriebssysteme nicht nur für Benutzersysteme, sondern auch für die Steuerung verschiedener technologischer Prozesse im automatischen Modus benötigt werden, und sogar das Konzept eines Echtzeitbetriebssystems eingeführt haben, ist es eine Sünde, es nicht zu verwenden. Die Klassiker führten das Konzept der Echtzeitsysteme ein und sprachen von einer bestimmten kritischen Zeitschwelle. Das heißt, es unterscheidet sich von herkömmlichen Systemen, bei denen, wenn der Benutzer auf etwas wartet, er warten kann, ein hartes Echtzeitsystem, das beispielsweise eine Turbine steuert, nicht warten kann, andernfalls können Sie auf etwas Schlechtes rollen.

Auf diese Weise können Sie dem Benutzer mitteilen, dass er im Gegensatz zu herkömmlichen Betriebssystemen mit einem System ausgestattet ist, das die Reaktionszeit des Systems garantiert. Je kleiner es ist, desto mehr verschiedene technologische Prozesse kann das System natürlich steuern. Und es erscheinen viele Tabellen, in denen verschiedene Schlüsselparameter von RTOS als Schlüsselparameter angegeben sind.

Wie werden sie empfangen? Dieser Prozess wird ehrlich beschrieben! Hier nehmen wir so und so ein Modellproblem, so und so eine Hardwareplattform und wenden so den Effekt an. Nun, Marketing kann natürlich eine Reaktionszeit von 1 μs vereinfachen und einfach abgeben. Aber wir berücksichtigen dies nicht, wir glauben, dass alles ehrlich beschrieben wird.

Aber entschuldigen Sie, was ist, wenn es eine andere Aufgabe gibt? 10 Aufgaben, 100 Aufgaben? Und wenn ein betrunkener Programmierer Interrupts sperrt? Und wenn der Programmierer im System die Aufgaben nicht richtig priorisiert hat?

Es gab einen Fall, in dem Embox Tests in Echtzeit bestanden hat. Wir saßen da und überlegten, wie wir beweisen können, dass dies ein Echtzeitbetriebssystem ist. Es gibt ein Labor, es gibt einen Kunden, der dies wünscht. Wir stellen fest, dass für den Kunden Echtzeit bedeutet, dass die Reaktionszeit des Systems 1 μs beträgt. Ich frage, ob das folgende Experiment ein Beweis sein wird:

• Wir nehmen eine bestimmte Hardwareplattform
• Legen Sie ein Signal an einen der GPIO-Eingänge an
• Programmgesteuert ein Ereignis erfassen
• Am Ausgang des GPIO signalisieren wir programmgesteuert
• Die Messungen werden mit einem Oszilloskop durchgeführt. Die Reaktionszeit ist die Differenz zwischen der Eingangs- und der Ausgangsfront.

Der Kunde bestätigt, dass genau dies erforderlich ist. Ich stelle eine klärende Frage, und wir entwerfen ein Modellsystem und starten es möglicherweise nicht mit anderen Aufgaben (laden es nicht). Das heißt, es ist normal, dass das System nur eine so einfache Testaufgabe ausführt. Der Kunde sagte, dass dies Testaufgaben erfordert. Wahrscheinlich verstehen Sie selbst, dass das System die Tests bestanden hat! Natürlich wurde mit der Bestätigung der Eigenschaften, dh der Auswirkung, der Aufprall wiederholt.

Dieser Abschnitt ist keinesfalls geschrieben, um Betriebssysteme oder Entwickler herabzusetzen. Aber nur um die ganze Unvollständigkeit des Bildes zu zeigen. Ich habe nicht behauptet, dass die Eigenschaften einiger Betriebssysteme es nicht erlauben, sie dem RTOS zuzuordnen, aber nur dieser Begriff wird von Vermarktern verwendet. Ich habe andere Tests gesehen, als ich die Auswahl des Betriebssystems eines unabhängigen Labors basierend auf den Anforderungen der Aufgabe bestellt habe. Es gab eine komplexe Reihe von Modellaufgaben, und die Netzwerkinteraktion wurde berücksichtigt, wie sich die Parameter ändern, wenn das System geladen ist, und das Verhalten in verschiedenen Notfallsituationen.

Definition des Begriffs "Echtzeit-Betriebssystem"

Jetzt werde ich den Begriff "Echtzeit-Betriebssystem" einführen. Nein, werde ich nicht. Tatsache ist, dass es viele Definitionen dieses Begriffs gibt. Nehmen Sie mindestens die Kommentare zum Originalartikel:

In Echtzeitsystemen ist eine Person im Allgemeinen überflüssig, und dementsprechend sollte die Geschwindigkeit eines Echtzeitsystems mit den Prozessen verglichen werden, die es steuert, sei es ein autonomes Auto oder ein Prozesssteuerungssystem in einer Fabrik.

SRV / RTOS - Dies ist lediglich eine Rangfolge zur Vorhersagbarkeit der Reaktion auf kritische Ereignisse.

RTOS ist ein solches Betriebssystem, in dem die Richtigkeit einer Aufgabe nicht nur durch logische Korrektheit gekennzeichnet ist, sondern auch durch die Zeit, die zur Ausführung dieser Aufgabe benötigt wird.

Stellen Sie das Kriterium für das Umschalten des Kontexts einer Aufgabe auf 1 μs pro 100-MHz-Prozessor mit einem Gleitkomma-Coprozessor mit einer Bestimmung von 0,1 μs ein, und alles passt zusammen.
Sie werden deutlich sehen, wo RTOS und wo nicht.

Nun, ich kann die Meinung, über die ich in einem Artikel gesprochen habe, der auf einer der OSDAY-Konferenzen geäußert wurde, nicht ignorieren:

Ein System kann als hartes Echtzeitsystem betrachtet werden, wenn es keine Stellen gibt, an denen es bei gesperrten Unterbrechungen Zyklen mit einer unbekannten Anzahl von Iterationen gibt.

Aber vielleicht ist alles nur etwas Besonderes, und wie in den Kommentaren vorgeschlagen , müssen Sie nur die Klassiker verwenden und dürfen sich keine Fahrräder einfallen lassen. Ich werde den angegebenen Klassiker zitieren (Andrew Tanenbaum, wenn jemand nicht geraten hat):

„Eine andere Art von Betriebssystem ist das Echtzeitsystem. Diese Systeme zeichnen sich durch Zeit als Schlüsselparameter aus. In industriellen Prozessleitsystemen müssen beispielsweise Echtzeitcomputer Daten über den Produktionsprozess sammeln und zur Steuerung von Maschinen im Werk verwenden. Oft gibt es harte Fristen, die eingehalten werden müssen. Wenn sich beispielsweise ein Auto am Fließband bewegt, müssen bestimmte Aktionen zu bestimmten Zeitpunkten ausgeführt werden. Wenn ein Schweißroboter zu früh oder zu spät schweißt, wird das Auto ruiniert. Wenn die Aktion unbedingt zu einem bestimmten Zeitpunkt (oder in einem bestimmten Bereich) stattfinden muss, haben wir ein hartes Echtzeitsystem. Viele davon finden sich in industriellen Prozesssteuerungs-, Avionik-, Militär- und ähnlichen Anwendungsbereichen. Diese Systeme müssen absolute Garantien dafür bieten, dass eine bestimmte Aktion zu einem bestimmten Zeitpunkt ausgeführt wird.

Eine andere Art von Echtzeitsystem ist ein weiches Echtzeitsystem, bei dem das Fehlen einer gelegentlichen Frist zwar nicht wünschenswert, aber akzeptabel ist und keinen dauerhaften Schaden verursacht. Digitale Audio- oder Multimedia-Systeme fallen in diese Kategorie. Digitale Telefone sind auch weiche Echtzeitsysteme.

Da die Einhaltung strenger Fristen in Echtzeitsystemen von entscheidender Bedeutung ist, ist das Betriebssystem manchmal einfach eine Bibliothek, die mit den Anwendungsprogrammen verbunden ist, wobei alles eng miteinander verbunden ist und kein Schutz zwischen Teilen des Systems besteht. Ein Beispiel für diese Art von Echtzeitsystem ist e-Cos.

Die Kategorien Handhelds, eingebettete Systeme und Echtzeitsysteme überschneiden sich erheblich. Fast alle von ihnen haben zumindest einige weiche Echtzeitaspekte. Auf den eingebetteten Systemen und Echtzeitsystemen wird nur Software ausgeführt, die von den Systementwicklern eingegeben wurde. Benutzer können keine eigene Software hinzufügen, was den Schutz erleichtert. Die Handhelds und eingebetteten Systeme sind für Verbraucher gedacht, während Echtzeitsysteme eher für den industriellen Einsatz bestimmt sind. Trotzdem haben sie eine gewisse Menge gemeinsam. “

Aus dieser Beschreibung folgt jedoch nur, dass Systeme in Systemen verwendet werden können, in denen das Fehlen einer Reaktion innerhalb eines bestimmten Zeitraums zu katastrophalen Folgen führen kann. Nun, um einen Schlüsselparameter zu erreichen (der die Reaktionszeit nicht überschreitet), kann das Betriebssystem eine Bibliothek sein, ein Beispiel für eCos.

So erzielen Sie Echtzeitmerkmale

Ich konnte keine strenge Definition geben (wenn jemand bereit ist zu geben, schreibe in die Kommentare). In allen obigen Definitionen sind jedoch einige Eigenschaften sichtbar (diesmal und Vorhersagbarkeit). Wenn Sie die Zeit in die Vorhersagbarkeitsoption übersetzen (das Gewicht des Bogens beim Übergang von einem Zustand in einen anderen), bleibt nur die Vorhersagbarkeit übrig!

Lassen Sie uns darüber nachdenken, wie dies erreicht werden kann.

Es liegt auf der Hand, alles Unnötige aus dem kritischen System zu entfernen. Es ist unwahrscheinlich, dass ein universelles System stabil ist. Sogar Genosse Tanenbaum hat darüber gesprochen, ich meine, als er über eCos sprach.

Ein weiterer von Tanenbaum vorgeschlagener Ansatz, der die Vorhersagbarkeit des Systems erhöht, ist die Verwendung spezieller (einfacher) Algorithmen für die Ressourcenplanung, vor allem der Prozessorzeit, dh spezieller Taskplaner. Er schlug verschiedene Planungsansätze vor, aber ich möchte mich zuerst auf die statische tabellengesteuerte Tabelle konzentrieren.

Der Entwickler muss sicherstellen, dass alle Aufgaben ihre Zeitscheibe erfolgreich abschließen. Zu diesem Zweck wird vorgeschlagen, die kritische Aufgabe statisch zu analysieren und ihre Schwellenwerte zu bestimmen. Dieser Ansatz ist im ARINC-653-Standard festgelegt. Der Standard für Bordsysteme, und Sie selbst verstehen, wenn etwas plötzlich keine Zeit mehr hat, im Flugzeug zu arbeiten, kann eine Katastrophe eintreten.

Der nächste Ansatz ist ein statischer Zeitplan, der jedoch auf Prioritäten basiert. Das heißt, der Entwickler muss erneut alle Situationen analysieren und nach Zuweisung aller Aufgaben in den Systemprioritäten sicherstellen, dass kritische Aufgaben zu einem bestimmten Zeitpunkt ausgeführt werden.

Ich möchte nicht weitermachen, weil es ein Original gibt! Es ist natürlich besser geschrieben, als ich es kann, und außerdem kann ihnen erneut vorgeworfen werden, die Fakten verfälscht zu haben. Ich habe genau diese Ansätze zitiert, um zu zeigen, dass der Entwickler des endgültigen Systems in jedem Fall die Verantwortung hat, die Eigenschaften des Systems sicherzustellen. Und das Betriebssystem sollte nur die entsprechenden Funktionen bereitstellen.

Ich möchte die Diskussion über Methoden zur Verbesserung der Vorhersagbarkeit fortsetzen und einen weiteren Kommentar abgeben

"Mit einer Himbeere kann man Echtzeit erreichen, aber nicht mit RTOS, sondern mit einer kleinen Zustandsmaschine, die in den Cache einbricht."

Hier möchte ich auf folgende Punkte achten:

• Erhöhte Vorhersagbarkeit (Echtzeit-Eigenschaften) aufgrund des Ausschlusses von RTOS aus dem System
• Darstellung eines Programms durch eine Zustandsmaschine
• Nun, die Abhängigkeit von Echtzeitsystemen nicht nur von den Eigenschaften von Software, sondern auch von Hardware.

Ich denke, alle sind sich einig, dass die Unvorhersehbarkeit bei einer Verringerung der Anzahl der Codezeilen abnimmt. Ich stimme zwar wie immer nicht zu, aber dazu später mehr.

Welchen Einfluss die Hardware hat, ist höchstwahrscheinlich auch nicht zu bezweifeln. Insbesondere als gesagt wurde, dass es im Zustand gesperrter Interrupts keine Schleifen mit einer beliebigen Anzahl von Iterationen gab, klang es, dass auf einem Cortex-m im beschriebenen RTOS überhaupt keine Unterbrechung der Interrupts auftrat. Dies ist ein wenig gerissen, da dort der Interrupt-Controller Interrupts mit gleicher oder niedrigerer Priorität unabhängig voneinander deaktiviert, aber die Tatsache des Einflusses ist offensichtlich. Und natürlich trägt das Vorhandensein von Cache, Adressübersetzung (oder eher Fehlstellen auf Seiten) zur Unsicherheit bei. Insbesondere wollte ich darauf aufmerksam machen, dass tatsächlich niemand eine hundertprozentig einwandfreie Funktionsfähigkeit der Geräte garantieren kann. Nun, die Postings fielen von Ihnen ab. Wie wird das Vorhandensein eines RTOS dazu beitragen, einen katastrophalen Ausgang von Ereignissen zu vermeiden?

Darstellung des Programms als Zustandsmaschine möchte ich vorschlagen, es von einer nicht offensichtlichen Seite zu betrachten. Das heißt, dass ein Vorhersagbarkeitsprogramm analysiert werden kann. Und da es sich um alle Bedingungen handelt, sollte diese statisch für alle möglichen Situationen analysiert werden. Nun, da funktionale Programmiersprachen für statische Analysen viel besser geeignet sind, ist es möglich, ein Programm in einer bestimmten Sprache zu entwickeln oder die Verwendung spezieller Programmiersprachen hinzuzufügen. Der erste Ansatz wird beispielsweise im verifizierten seL4- Kernel verwendet. Ein Beispiel für den zweiten Ansatz ist derselbe ARINC-653- Standard mit seiner obligatorischen Bildung von Anforderungen in XML.

Es gibt andere Methoden, die die Vorhersagbarkeit erhöhen oder, wenn Sie möchten, Faktoren, die die Vorhersagbarkeit des Systems beeinflussen. Ich habe auf einer der OSDay- Konferenzen über dieses Thema berichtet . Insbesondere habe ich zusätzlich zu den bereits aufgeführten einen architektonischen Ansatz hervorgehoben. Schließlich ist bekannt, dass beispielsweise die Mikrokernel-Architektur die Vorhersagbarkeit des Systems verbessern kann. Aber auch im selben Bericht wurde ein etwas nicht offensichtlicher organisatorischer Ansatz hervorgehoben. Dies ist ungefähr der Punkt, an dem ich nicht einverstanden war, dass das Fehlen von RTOS zu einer erhöhten Vorhersagbarkeit führt. Wenn Sie darüber nachdenken, hat das Konzept eines Betriebssystems im Allgemeinen die Anzahl der Fehler aufgrund der Wiederverwendung von Code erheblich reduziert. Das heißt, wenn Sie keinen Code haben, der wirklich in einen Schalter / Fall passt, ist es besser, vorgefertigte Module zu verwenden. Schließlich wurde der Parameter „Anzahl der Fehler pro 1000 Codezeilen“ nicht gelöscht, und unabhängig davon, wie debuggt Ihr neuer Code ist, gibt es Fehler.

Gibt es RTOS überhaupt?

Nachdem ich mich auf die Aussage im vorherigen Abschnitt festgelegt habe, dass jeder Code Fehler enthält, möchte ich noch eine provokative These aufstellen. Gibt es RTOS überhaupt?

Lass es uns herausfinden. Als wir mit einem Freund über Echtzeitsysteme diskutierten, waren wir uns einig, dass ein Echtzeitbetriebssystem (wir sprechen von harten Echtzeitsystemen) kaum existieren kann. Er schlug vor, das gesamte System als Zustandsmaschine oder Diagramm mit einer Beschreibung der maximalen Übergangszeit von einem Zustand in einen anderen darzustellen. Darüber hinaus kann das System als stabil angesehen werden, wenn nachgewiesen wird, dass für alle Eingangs- und internen Zustände ein Lichtbogen zu einem bestimmten Zustand mit einer zeitlichen Begrenzung führt. Sie verstehen, dass dies nur für ein sehr kleines System möglich ist, genau für die im Kommentar erwähnte Zustandsmaschine, aber in der modernen Welt brauchen nur wenige Menschen ein solches System.

Wir haben jedoch keinen Zweifel daran, dass Echtzeitsysteme existieren. Und natürlich auch RTOS. Wenn dies nicht so wäre, würde der erste fliegende Specht die Zivilisation zerstören, dann würde es keine Avionik, Astronautik, Robotik, ACS-TP und vieles mehr geben.

Wie man aus der Situation herauskommt. Es ist sehr einfach, obwohl das Problem im Allgemeinen höchstwahrscheinlich unlösbar ist, aber für ein bestimmtes Problem ist es möglich, Einschränkungen einzuführen, die es lösbar machen, mit einer Art bedeutungsvoller Fehlerwahrscheinlichkeit.

Beispielsweise werden Standards eingeführt: Echtzeit-POSIX , ARINC-653 , ITRON . Diese Standards unterscheiden in der Tat eine Klasse von Aufgaben, die gelöst werden können, wenn Sie diesen Standard einhalten. Oder es werden Studien von unabhängigen Labors durchgeführt, die untersuchen, ob die Eigenschaften eines bestimmten Betriebssystems zur Lösung des Zielproblems geeignet sind.

Also Embox RTOS oder nicht RTOS?

Um eine ähnliche Frage sowohl für Embox als auch für jedes andere Betriebssystem zu beantworten, können Sie meiner Meinung nach nur fragen: "Was meinen Sie?". Genauer gesagt: „Was meinst du mit dem Konzept der Echtzeit?“. Das heißt, wenn die Interrupt-Verarbeitungszeit von Interesse ist und es möglich ist, den Interrupt-Handler direkt aufzurufen, ist dies eine Sache, wenn Sie die Zuverlässigkeit der Arbeit erhöhen müssen, wenn auch langsam, aber es ist sicherlich viel weniger wahrscheinlich, dass dies fehlschlägt. Dies ist eine andere, die Einhaltung eines Standards ist die dritte. Überprüfung ist die vierte. Es ist kein Zufall, dass der große Klassiker Andrei Tanenbaum, obwohl er Methoden zur Erhöhung der Vorhersagbarkeit vorschlug, das Konzept eines Echtzeitsystems verwendete, jedoch keine strengen Definitionen verwendete.

PS Zum Zeitpunkt dieses Schreibens war kein einziges RTOS betroffen.