Dieses Essay handelt von Echtzeit-Betriebssystemen, einer Vorstellung dieser und einer Auflistung der gestellten Anforderungen an diese Art der Betriebssysteme. Des Weiteren werden die dort verwendeten Algorithmen aufgelistet und näher betrachtet.
Im ersten Teil der Arbeit wird erläutert, was man unter einem Betriebssystem versteht. Anschließend werden Echtzeit-Betriebssysteme hiervon abgegrenzt und die für die Differenzierung nötigen Eigenschaften näher beschrieben. Die Kategorien Hard Realtime und Soft Realtime werden daraufhin näher beschrieben, ferner die hierfür nötigen Kriterien. Der letzte Teil der Arbeit beschäftigt sich mit den verschiedenen Ansätzen für die Abarbeitung der anstehenden Tasks, den Algorithmen der RTOS.
Inhaltsverzeichnis
Abbildungsverzeichnis
Abkürzungsverzeichnis
1. Einleitung
1.1 Problemstellung
1.2 Vorgehensweise
2. Echtzeit-Betriebssysteme
2.1 Anforderungen
2.2 Subtypen
2.3 Verwendete Algorithmen
3. Fazit
Literaturverzeichnis
Abbildungsverzeichnis
Abbildung 1: Visuelle Darstellung der unterschiedlichen Subtypen der Rechtzeitigkeit. Quelle: Hüning, F. (2019), Embedded Systems für IoT, Springer Berlin Heidelberg, Berlin, Heidelberg
Abkürzungsverzeichnis
RTOS ...Real Time Operating System
HRTOS Hard Realtime Operating System
SRTOS .Soft Realtime Operating System
EDF ..Earliest Deadline First
FIFO .First-In-First-Out
1. Einleitung
Dieses Essay handelt über Echtzeit-Betriebssysteme, eine Vorstellung dieser und eine Auflistung der gestellten Anforderungen an diese Art der Betriebssysteme. Des Weiteren werden die dort verwendeten Algorithmen aufgelistet und näher betrachtet.
1.1 Problemstellung
Die DIN 44.300 definiert ein Betriebssystem wie folgt: „Das Betriebssystem wird gebildet durch die Programme eines digitalen Rechensystems, die zusammen mit den Eigenschaften der Rechenanlage die Grundlage der möglichen Betriebsarten des digitalen Rechensystems bilden und insbesondere die Ausführung von Programmen steuern und überwachen.“1 Manche Szenarien benötigen jedoch Betriebssysteme, welche bestimmte Eigenschaften aufweisen, um zeitnah und in „Echtzeit“ auf bestimmte Ereignisse reagieren zu können. Diese nennt man Echtzeit-Betriebssysteme.
Echtzeitbetriebssysteme (engl.: Real Time Operating Systems; RTOS) sind eine untergeordnete Kategorie der Betriebssysteme, für die andere Anforderungen gelten als für Universal-Betriebssysteme. Oft werden diese Systeme in eingebetteten Systemen verwendet. Diese können Rechner- oder Steuersysteme sein, die Geräten wie Telefone, Waschmaschinen, Fernseher, in Fahrzeugen wie Flugzeugen oder Autos, oder Robotern verbaut sind. Somit sind diese Systeme weitestgehend geschlossen und übernehmen fest definierte Aufgaben. Die Hardware-Ressourcen können hierdurch relativ gering sein, da der Anwendungszweck dieser Systeme bereits vordefiniert ist. Diese Arbeit beschäftigt sich mit der Kategorisierung dieser Systeme, sowie den verwendeten Methoden/Algorithmen, welche hierbei als Lösungsmöglichkeiten verwendet werden.
1.2 Vorgehensweise
Im ersten Teil der Arbeit wird erläutert, was man unter einem Betriebssystem versteht. Anschließend werden Echtzeit-Betriebssysteme hiervon abgegrenzt und die für die Differenzierung nötigen Eigenschaften näher beschrieben. Die Kategorien Hard Realtime und Soft Realtime werden daraufhin näher beschrieben, ferner die hierfür nötigen Kriterien. Der letzte Teil der Arbeit beschäftigt sich mit den verschiedenen Ansätzen für die Abarbeitung der anstehenden Tasks, den Algorithmen der RTOS.
2. Echtzeit-Betriebssysteme
Die Hauptaufgabe eines Echtzeitbetriebssystems besteht in der Koordination Serialisierung von Handlungssträngen, damit diese möglichst viel Prozessorzeit erhalten. Somit hält sich das Betriebssystem, wenn möglich, im Hintergrund, damit die maximal verfügbaren Ressourcen der Hardware für die ausgeführten Programme zur Verfügung stehen.2 Die hierdurch freigelegten Ressourcen werden nun benutzt, um die primären Aufgaben eines RTOS auszuführen. Diese wurden vom deutschen Institut für Normierung wie folgt festgelegt:
„Unter Echtzeit versteht man den Betrieb eines Rechensystems, bei dem Programme zur Verarbeitung anfallender Daten ständig betriebsbereit sind, derart, dass die Verarbeitungsergebnisse innerhalb einer vorgegebenen Zeitspanne verfügbar sind. Die Daten können je nach Anwendungsfall nach einer zeitlich zufälligen Verteilung oder zu vorherbestimmten Zeitpunkten anfallen.“. 3
Die ständige Betriebsbereitschaft wird durch den minimalen Einsatz von eigenen Prozessen unterstützt, damit möglichst keine Threads im Prozessor abgearbeitet werden, wenn die Verarbeitungsergebnisse nötig sind. Somit werden RTOS danach definiert, ob sie die vorgegebenen Reaktionszeiten erfüllen, wenn definierte Ereignisse eintreten und Aufgaben an den Prozessor gestellt werden. Somit muss die Antwortzeit je nach Anwendungsfall individuell bestimmt werden, da die Reaktionszeit bei der Steuerung eines z.B. Flugzeugs oder eines Bremsassistenten eine extrem kurze Latenz voraussetzt, der Temperatursensor für die Steuerung einer SmartHome-Anwendung durchaus ein paar Sekunden im Verzug sein kann, ohne dass merkliche Unterschiede auftreten. Um die weiteren Kriterien eines Echtzeit-Betriebssystems zu definieren, wenden wir uns nun dem Beispiel eines Airbags zu. Dieser muss jederzeit bereit für die Auslösung der Sprengautomatik sein, da hier sonst erhebliche Verletzungen bei den Insassen im Falle einer Verzögerten Reaktion auftreten. Die Ressourcen auf dem Steuergerät der Anwendung werden währenddessen mit anderen Anwendungen geteilt, diese dürfen jedoch in keinem Fall den Prozessor so lange blockieren, dass der Interrupt von der Steuerung des Airbags nicht die nötige Ressourcen erhält, damit dieser die Detonation unter dem Luftkissen in einem akzeptablen Zeitrahmen einleiten kann. Die von der Definition hergeleiteten Anforderungen an ein solches Betriebssystem werden nun im folgenden Kapitel näher erläutert.4
2.1 Anforderungen
Rechtzeitigkeit
Dies ist wohl die primäre Eigenschaft eines Echtzeit-Betriebssystems. Es muss auf Ereignisse in einer vorgegebenen Latenz antworten und die Ergebnisse liefern, da sonst je nach Anwendungsfall unterschiedlich drastische Konsequenzen auftreten. Die Antwortzeit muss somit immer zur Anwendung passen, hierbei dürfen keine Fehler auftreten, oder einzelne Ereignisse verpasst werden. Die Interrupts können hierbei ohne Vorwarnung oder Regel kommen, jedoch ist dies nicht vorausgesetzt. Je nach Anwendungsgebiet kann die Latenz absoluter Natur sein (100ms-Takt), oder ausgerichtet nach den Signalen (100ms nach dem Eingang des Signals). Es gibt des Weiteren verschieden Arten von Rechtzeitigkeit, welche voneinander variieren. Es kann die Bedingung bestehen, dass ein genauer Zeitpunkt für die Aktion des Betriebssystems gefordert ist, dies ist jedoch keine weit verbreitete Praxis. Üblicherweise werden die spätesten Zeitpunkte für die Abarbeitung des Interrupts definiert, wie zum Beispiel bei Fahrassistenzsystemen, welche bei einem Spurwechsel nach einer möglichst kurzen Zeit erkennen müssen, wenn die Spur nicht mehr gehalten wird, um dies noch adäquat ausgleichen zu können. Weiterhin gibt es noch die Methode für den frühesten Reaktionszeitpunkt auf ein Ereignis, oder ein vordefinierter Zeitintervall, in dem sich die Reaktion befinden darf.5
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1: Visuelle Darstellung der unterschiedlichen Subtypen der Rechtzeitigkeit. Quelle: Hüning, F. (2019), Embedded Systems für IoT, Springer Berlin Heidelberg, Berlin, Heidelberg
Verfügbarkeit
Die zweite Kategorie definiert die nächste Grundeigenschaft eines RTOS. Diese setzt voraus, dass das System zu jeder geforderten Zeit erreichbar sein muss. Hardwaretechnisch bedeutet dies, dass die Energieversorgung des Geräts immer sichergestellt sein muss, damit bei eintretenden Ereignissen das System betriebsbereit ist und die volle Kapazität an Leistung zur Verfügung hat. Dies kann zum Problem werden, wenn die Hardware einen nicht berücksichtigten Stromsparmodus besitzt, oder sich gar nach einer definierten Standby Zeit abschaltet. Somit ist hier zu beachten, dass die eingesetzte Software ebenfalls so programmiert wurde, dass die Zeitgrenzen für eine Reaktion sicher eingehalten werden können. Ein ungeplanter Neustart, oder eine Blockade durch rechenintensive Prozesse ist hierbei ein nicht akzeptables Verhalten.6
Gleichzeitigkeit
Eine wirkliche Gleichzeitigkeit ist – wie beim Menschen – bei einer Maschine nicht möglich. Auch hier werden Aufgaben (Threads/Tasks) nacheinander abgearbeitet, absteigend nach Ihrer Wichtigkeit oder Dringlichkeit. Bei einem Echtzeit-Betriebssystem müssen jedoch die geforderten Latenzzeiten unbedingt eingehalten werden, unabhängig davon, ob nun 100 oder 1000 Tasks auf Ihre Abarbeitung warten. Somit müssen diese nach außen hin parallel abgearbeitet werden, während sie im System – je nach Algorithmus – durch eine unterschiedliche Sortierung alle nacheinander beendet werden (Die verwendeten Algorithmen werden später in der Arbeit näher thematisiert). Somit muss der Prozessor in jeder Sekunde prüfen, ob der aktuell laufende Thread durch eine neue Aufgabe mit höherer Dringlichkeit unterbrochen wird, oder ob dieser noch abgearbeitet werden kann. Da im Normalfall bei Betriebssystemen Interrupts für die Meldung von neuen Ereignissen zuständig sind, dürfen die hier auftretenden Zeiten bis zur Abarbeitung eines Threads nicht zu hoch sein, sodass der Prozessor noch auf spontane Ereignisse reagieren kann.7
2.2 Subtypen
Abhängig von der Rechtzeitigkeit können die Betriebssysteme noch in zwei weitere Klassen unterteilt werden: Hard Realtime Systeme (HRTOS) und Soft Realtime Systeme (SRTOS). Die Grenze wird hierbei bei der Verbindlichkeit der Reaktionszeiten gezogen. Bei HRTOS muss die Antwortzeit um jeden Preis garantiert eingehalten werden, ohne Ausnahmen. Geschieht dies nicht, ist das System nicht verlässlich und nicht für den praktischen Gebrauch geeignet. Hierbei kann wieder das Beispiel eines Airbags herangezogen werden: Hat das System bis zu einem bestimmten Zeitpunkt X nicht reagiert, ist die Reaktion vollkommen irrelevant, da die Latenz zu hoch war. Der Fahrer hat zu diesem Zeitpunkt bereits schwere Verletzungen davongetragen, welche nicht durch das Luftkissen verhindert werden konnten. Der weniger drastische Ansatz dazu sind die SRTOS, welche eine gewisse Fehlertoleranz erlauben. Bei diesen müssen die Reaktionen noch korrekt ablaufen, jedoch sind leichte Verfehlungen im Einzelfall erlaubt. Die Grenze zwischen den beiden Systemen wird also von der Tragweite der auftretenden Auswirkungen abhängig gemacht. Ein Szenario für ein weiche Anwendung wäre beispielsweise der Lichtsensor einer Smarthome-Einrichtung. Ist dieser so eingestellt, dass die Rollladen bei Sonnenaufgang/Sonnenuntergang automatisiert hoch-/herunterfahren, ist es nicht dramatisch, wenn in diesem Fall ein paar Lumen Abweichung vorkommen. Die Auswirkungen hierbei wären weitaus geringer als im oben genannten Beispiel.8
2.3 Verwendete Algorithmen
Um die Anforderungen an das Betriebssystem möglichst genau zu erfüllen, und möglichst performant Threads zu koordinieren, werden verschiedene Scheduling-Algorithmen genutzt. Diese verfolgen unterschiedliche Ansätze und versuchen auf unterschiedliche Weisen die gestellten anfallenden Aufgaben abzuarbeiten. Aufgrund des limitierten Umfangs der Arbeit wird nur eine Teilmenge der existierenden Algorithmen behandelt. Die Selektion dieser wurde aufgrund der in der Praxis für RTOS üblichen Algorithmen durchgeführt:
Earliest Deadline First
Die Hauptaufgabe bei Earliest Deadline First (EDF) liegt in der Einhaltung der gesetzten Deadlines – den Zeiten, zu welchen der Prozess in jedem Fall abgeschlossen sein muss. Die Warteschlange aller Prozesse, welche auf „Bereit“ stehen, wird ständig überprüft und derjenige, dessen Deadline als nächstes ansteht, wird ausgewählt. In der Praxis kann EDF verdrängend oder nicht-verdrängend eingesetzt werden. In Bezug auf Echtzeit-Betriebssysteme wird der verdrängende Algorithmus benutzt, welcher während der Bearbeitung eines Threads prüft, ob weitere Threads mit einer näheren Deadline anstehen. Diese werden dann bevorzugt behandelt und „verdrängen“ die aktuelle Aufgabe.9
[...]
1 Deutsches Institut für Normung (1988).
2 Asche (2016).
3 Deutsches Institut für Normung (1988).
4 Hüning (2019).
5 Hüning (2019).
6 Brause (2017).
7 Hüning (2019).
8 Hüning (2019).
9 Baun (2017).
- Citar trabajo
- Marcel Schrauder (Autor), 2020, Echtzeit-Betriebssysteme. Vorstellung und Diskussion von Anforderungen und implementierten Algorithmen, Múnich, GRIN Verlag, https://www.grin.com/document/1011212
-
-
-
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X.