Real Time Operating Systems

Transkript

1 Real Time Operating Systems Philipp Marschall Student der Medieninformatik an der Universität Ulm Helmholtzstraße 18, Ulm Zusammenfassung Im Folgenden werden Voraussetzungen für Echtzeitbetriebssysteme näher erläutert. Dabei wird auf deren Umsetzung in Bereichen des Betriebssystems eingegangen. Zudem werden die Vor- und Nachteile von Echtzeitbetriebssystemen betrachtet. I. EINLEITUNG Heutzutage haben Eingebettete Systeme eine große Bedeutung und werden in immer mehr Bereichen eingesetzt. Viele dieser Systeme haben dabei zeitkritischen Charakter und müssen die Bedingung der Echtzeitfähigkeit erfüllen. Dies bedeutet, dass Ergebnisse innerhalb eines vorher fest definierten Zeitintervalles garantiert berechnet werden. Daraus ergibt sich die Notwendigkeit von speziell auf diese Anforderungen abgestimmte Betriebssysteme, welche dann beispielsweise in eingebetteten Systemen Verwendung finden. Dabei kann zwischen Bereichen mit so genannten harten bzw. weichen Echtzeitanforderungen unterschieden werden. Sind harte Echtzeitanforderungen erforderlich, so gilt es als Versagen, wenn bestimmte Zeitkriterien nicht erfüllt werden können. Ein Beispiel hierfür ist das Auslösen eines Airbag. Dies muss zuverlässig innerhalb einer gewissen Zeitspanne erfolgen, ansonsten wäre die Funktion unbrauchbar. Anwendungen mit weichen Echtzeitanforderungen gibt es sehr viele, beispielsweise aus den Bereichen Verkehr, Kommunikation, Produktion, Logistik und vielen mehr. Bei diesen Anwendungen muss eine Reaktion nicht unbedingt innerhalb einer bestimmen Zeit erfolgt sein, ihr Mittelwert muss allerdings innerhalb einer gewissen Tolerant liegen. Ansonsten können der Anwendung keine Echtzeiteigenschaften zugeschrieben werden. Viele, bereits seit einiger Zeit in der Wirtschaft eingesetzte Anwendungen sind den meisten Endanwendern jedoch gar nicht bekannt oder nicht bewusst. Durch prominente Anwendungen, wie beispielsweise der Hausautomation, kommt jedoch auch der Anwender selbst mehr und mehr in direkten Kontakt mit solchen Anwendungen. Im folgenden wird nicht zwischen den verschiedenen Qualitäten von speziellen Anwendungen hinsichtlich ihrer Echtzeitanforderungen unterschieden. Vielmehr sollen die einzelnen Aufgabenbereiche von Betriebssystemen unter dem Aspekt der Echtzeiteigenschaften untersucht, und mögliche Lösungen dafür aufgezeigt werden. Je nach Art der Anforderungen, der auf einem Betriebssystem laufenden Anwendungen, kann dann eine Entscheidung hinsichtlich der Ausgestaltung des Systems erfolgen. In Kapitel II werden die Kernaufgaben eines Echtzeitbetriebssystems beschrieben. Anschließend wird in Kapitel III auf die wesentlichen Unterschiede bei der Verwendung eines Mikrokerns im Vergleich zu einem Makrokern eingegangen. Kapitel IV macht deutlich, dass die Taskverwaltung eine wichtige Rolle zur Wahrung von Echtzeiteigenschaften spielt. Hierbei wird auch die Synchronisation von Tasks und die Kommunikation zwischen Tasks erläutert. Im darauf folgenden Kapitel (Kapitel V) werden verschiedene Modelle der Speicherverwaltung vorgestellt, welche außerdem durch ein Beispielmodell verdeutlicht werden. Die insbesondere für interaktive Systeme wichtige Ein- und Ausgabeverwaltung wird in Kapitel VI behandelt. Es folgt ein Schlussteil (Kapitel VII). II. DIE KERNAUFGABEN EINES ECHTZEITBETRIEBSSYSTEMS Eine der Hauptaufgaben eines Betriebssystems ist die Taskverwaltung. Sie besteht nicht nur aus der eigentlichen Verwaltung der Tasks, sondern auch deren Kommunikation untereinander, der sogenannten Interprozesskommunikation. Daneben ist die zeitliche Koordination der Tasks, die sogenannte Synchronisation eine wichtige Aufgabe des Betriebssystems. Diese beiden Teilaufgaben werden im Kapitel IV ausführlicher behandelt. Gerade in Echtzeitsystemen mit meist vielen Sensoren spielt eine weitere Aufgabe eine besondere Rolle. Dies ist die Verwaltung der vorhandenen Betriebsmittel (siehe Kapitel VI). Dank ihr können Daten in Echtzeit mit anderen Geräten oder Sensoren ausgetauscht werden. Dies verlangt jedoch auch die Einhaltung von geeigneten Schutzmaßnahmen, welche die Betriebsmittel vor unberechtigten Zugriffen einzelner Tasks schützen. Die Ausführung dieser Aufgaben stellt in einem zeitkritischen System besondere Herausforderungen an das Betriebssystem dar, da unter dem Aspekt der zeitkritischen Bearbeitung von Daten zwei weitere elementare Aufgaben hinzu kommen. Diese sind die Wahrung der Rechtzeitigkeit und der Gleichzeitigkeit, sowie die Wahrung der Verfügbarkeit [1]. Auf diese Kernaufgaben kann in einem Echtzeitbetriebssystem nicht verzichtet werden. III. DIE AUSGESTALTUNG DES BETRIEBSSYSTEMKERNS Die Einhaltung der Rechtzeitigkeit und Gleichzeitigkeit sowie der Verfügbarkeit stellen die Kernaufgaben eines Real Time Operating System (im folgenden auch RTOS genannt) dar und dominieren somit auch die Aufgaben des Be-

2 triebssystems in Konfliktfällen. In Konsequenz daraus kommt es beispielsweise in manchen RTOS nur zum rudimentären Einsatz von Schutzmaßnahmen, da sich diese negativ auf die Performanz, vor allem aber negativ auf die Ausführbarkeit der Kernaufgaben auswirkt. Dadurch ist die Wahrung der Rechtzeitigkeit und der Gleichzeitigkeit sowie die Wahrung der Verfügbarkeit noch schwieriger zu garantieren. Daher findet man in RTOS eine unterschiedlich starke Implementierung und Gewichtung der verschiedenen Aufgabenbereiche vor, je nachdem wie zeitkritisch die auszuführenden Anwendungen sind. Da zeitkritische Berechnungen oft in eingebetteten Systemen zum Einsatz kommen, muss das Betriebssystem teilweise besonders ressourcenschonend arbeiten können. Dies kann erreicht werden, in dem man ein Mikrokern-Betriebssystem einsetzt. In diesem führt der Betriebssystemkern nicht alle für ihn typischen Aufgaben aus, sondern nur die wirklich benötigten. Solch ein schlanker Kern führt beispielsweise nur die Interprozesskommunikation, die Synchronisation und weitere elementare Funktionen zur Taskverwaltung aus. Alle anderen Aufgaben können im User Mode durch so genannte Erweiterungsmodule [2] ausgeführt werden. Hierdurch erhält man einen lauffähigen Betriebssystemkern welcher mit minimalen Hardwareanforderungen zurechtkommt und je nach System eine optimale Zusammenstellung von Erweiterungsmodulen enthalten kann. Die dadurch resultierende hochgradige Konfigurierbarkeit unterscheidet ein solches Mikrokern- Betriebssystem von einem Makrokern-Betriebssystem, in dem alle für ein Betriebssystem typischen Aufgaben im Betriebssystemkern ausgeführt werden. Die sich daraus ergebenden Vorteile eines Mikrokern- Betriebssystems sind unter anderem eine exakte Skalierbarkeit durch das Hinzufügen oder Herausnehmen von Erweiterungsmodulen sowie eine gute Anpassbarkeit an neue Situationen durch das Austauschen von Modulen. Hierdurch erreicht man auch eine bessere Portierbarkeit auf Systemen mit unterschiedlicher Hardware und kann die (insbesondere in eingebetteten Systemen) begrenzten Ressourcen optimal nutzen. Ein weiterer großer Vorteil ist die Verbesserung der zeitlichen Vorhersagbarkeit. Diese wichtige Eigenschaft bei Echtzeitsystemen wird dadurch verbessert, dass kritische Bereiche in schlanken Mikrokernen deutlich kürzer gehalten werden können, da sich diese Bereiche auf den Kern selbst beschränken und nicht wie bei Makrokernen auf mehrere Schichten verteilen. Der dadurch geschaffene sogenannte präemptive Kern ist dadurch idealerweise nahezu immer zu unterbrechen und ermöglicht somit eine schnelle Reaktion auf Ereignisse. Nachteile eines solchen Kerns sind vor allem ein geringerer Schutz durch die Ausführung der Erweiterungsmodule im User Mode, sowie ein gewisser Verlust von Performanz durch häufiges Umschalten zwischen den zwei Prozessor- Betriebsarten, auch bei nicht komplexen Prozessen. Abbildung 1 und Abbildung 2 verdeutlichen dies für eine einfache Dateioperation. Diese Kontextwechsel müssen bei einem Mikrokern jedoch zugunsten der Kernaufgaben des RTOS hingenommen werden. Außerdem liegen sie in einem tolerierbaren Bereich. So wurde für L4, einem von Linux abgeleiteten RTOS, ein Geschwindigkeitsverlust von nur ungefähr 5-10 Prozent nachgewiesen. Abbildung 1. Makrokern [1] Abbildung 2. Mikrokern [1] Da die Vorteile jedoch in den meisten Anwendungsbereichen überwiegen (vor allem bei eingebetteten Systemen mit begrenzten Hardware Ressourcen), sind nahezu alle heutigen Echtzeitbetriebssysteme als Mikrokern-Betriebssystem realisiert. IV. DIE TASKVERWALTUNG Innerhalb einer Task können sich mehrere Threads dieselben Betriebsmittel und Variablen teilen. Daher nennt man einen Thread einen sogenannten leichtgewichtigen Prozess [2]. Eine Task hingegen ist ein sogenannter schwergewichtiger Prozess [2], da er einen eigenen Adressraum vom Betriebssystem anfordern muss. Außerdem kann er nur über die Interprozesskommunikation mit anderen Tasks kommunizieren, da er durch Schutzmaßnahmen des Betriebssystems von den anderen Tasks getrennt wird. Da ein Kontextwechsel bei Tasks somit wesentlich mehr Taktzyklen benötigt als ein Wechsel zwischen zwei Threads, werden in vielen Echtzeitanwendungen Threads gegenüber Tasks bevorzugt. Die schnelle und direkte Kommunikation der einzelnen Threads innerhalb einer Task macht es sogar möglich eine extrem hohe Effizienz zu erreichen um damit die Wahrung der Echtzeiteigenschaften besser garantieren zu können. Dies geht selbstverständlich auf Kosten von Schutzmaßnahmen, da sich die einzelnen Threads natürlich untereinander stören können. A. Der Task-Scheduler Auf die Auswahl des Schedulingmodells wirkt sich diese Tatsache allerdings nicht aus. Jedoch gibt es auch hier Unterschiede zwischen einem RTOS und einem gewöhnlichen

3 Betriebssystem. So wird ein momentan auf der CPU laufender Prozess in jedem Fall nach einer bestimmten Zeit blockiert, sofern er die Zeitschranke ( deadline ) überschreitet (siehe Abbildung 3). Dies stellt eine wichtige Eigenschaft der Taskverwaltung in Echtzeitsystemen da und kann je nach Klasse der Anwendung in unterschiedlicher Qualität ausgeführt werden ( hart / fest / weich ). Abbildung 3. Wesentliche Zeitparameter einer Echtzeittask [1] Zuständig für die zeitliche Taskverwaltung ist dabei der sogenannte Scheduler, er teilt dem Prozessor mit Hilfe von Schedulingverfahren ablaufwillige Tasks zu. Dies sollte so geschehen, dass alle Zeitbedingungen der einzelnen Tasks (sofern möglich) eingehalten werden. Die Menge der durch den Echzeitscheduler dabei verwalteten Tasks nennt man einen Taskset [1]. Ist es möglich, für einen bestimmten Taskset die Zeitbedingungen aller Tasks einzuhalten, so existiert ein möglicher Schedule. Die Schwierigkeit besteht also darin, erst zu bestimmen ob ein möglicher Schedule existiert und diesen dann in möglichst kurzer Zeit zu bestimmen. Diese Scheduling Analysis oder auch Feasibility Analysis genannte Berechnung wird immer auf der Grundlage eines bestimmten Tasksets sowie eines Schedulingverfahrens durchgeführt. Dabei ist nicht garantiert, dass das zugrundeliegende Schedulingverfahren auch den möglichen Schedule findet, sofern überhaupt einer existiert. Wichtig bei dieser Berechnung ist unter anderem die Prozessorauslastung. Liegt diese insgesamt gesehen über 100 Prozent, kann kein Schedule existieren. Das heißt, das Taskset ist in diesem Fall nicht unter Einhaltung der Zeitbedingungen ausführbar. Liegt die Prozessorauslastung jedoch unter 100 Prozent ist der Taskset ausführbar. Man nennt ein Schedulingverfahren optimal, wenn der Schedule (falls existent) damit gefunden wird. Die meisten RTOS verwenden ein dynamisches Schedulingverfahren. Dort wird im Gegensatz zum statischen Schedulingverfahren erst zur Laufzeit die Zuordnung der Tasks an den Prozessor entschieden. Dies verursacht einen größeren Overhead und verringert die Vorhersagbarkeit, dafür kann allerdings auf aperiodische Ereignisse flexibler reagiert werden. Dies bedeutet für ein prioritätsbasiertes Scheduling, dass die Prioritäten dynamisch bestimmt werden und somit gegebenenfalls während der Laufzeit angepasst werden können. Solch ein Scheduling kann zusätzlich präemptiv [4] sein, dann können laufende Prozesse außerdem durch andere mit höherer Priorität gestoppt und ersetzt werden. Ist das Verfahren jedoch nichtpräemptiv, müssen andere Tasks mit höhere Priorität auf die Beendigung eines laufenden Prozesses warten und können erst dann ausgeführt werden. B. Die Synchronisation von Tasks Sollen mehrere Tasks gleichzeitig auf das selbe Betriebsmittel (wie beispielsweise Daten oder ein Ein- / Ausgabegeräte) zugreifen können, müssen sie synchronisiert werden. Diese notwendigerweise zu synchronisierenden Bereiche in Anwendungen nennt man kritische Bereiche. Um diese zu realisieren gibt es zwei übliche Vorgehensweisen. Die Sperrsynchronisation, auch kurz Mutex ( mutual exclusion ) genannt, ist die einfachere der beiden Möglichkeiten [1]. Dabei wird sichergestellt, dass immer nur eine Task auf das Betriebsmittel zugreifen kann. Die zweite Möglichkeit ist die sogenannte Reihenfolgensynchronisation, auch Kooperation genannt, bei der darüber hinaus die Reihenfolge der Zugriffe geregelt wird. Dies wird durch die Benutzung mehrerer Semaphore realisiert. Hierbei wird es einer Task beispielsweise nur gestattet in einen kritischen Bereich einzutreten, wenn eine Zählvariable positiv ist. Ist sie jedoch Null oder negativ, wird die anfragende Task blockiert und bekommt erst dann Zugriff auf das angefragte Betriebsmittel, wenn andere Tasks den kritischen Bereich verlassen und die Zählvariable gleichzeitig wieder erhöhen. Im Vergleich zu anderen Betriebssystemen ist es für RTOS jedoch außerordentlich wichtig, dass die Echtzeiteigenschaften eingehalten werden. Deshalb muss hier immer die Task mit der höchsten Priorität (beziehungsweise diejenige mit dem engsten Spielraum zur Wahrung der Echtzeiteigenschaften) den nächsten Zutritt erhalten. Um bei der Verwendung von Semaphoren möglicherweise auftretende Verklemmungen zu verhindern, sollten alle Tasks die (möglicherweise mehreren) Betriebsmittel in der gleichen Reihenfolge schützen. Kommt es jedoch trotzdem zu einem so genannten Deadlock (auch Blockierung genannt), wird die betreffende Task nach einer bestimmten Wartezeit ( Timeout ) dazu gebracht, ihre gesamten Betriebsmittel frei zu geben um die Verklemmung zu lösen. Dies ist eine interessante Parallele zur bereits angesprochenen Deadline bei Tasks und verdeutlicht die Wichtigkeit der Wahrung der Rechtzeitigkeit und der Gleichzeitigkeit, sowie die Wahrung der Verfügbarkeit in RTOS. Ohne den Einsatz eines solchen Timeouts würde eine Task gegebenenfalls dauerhaft blockiert werden und könnte somit zeitkritische Anforderungen nicht erfüllen. Eine weitere Art der Verklemmung ist der sogenannte Livelock (auch Aushungern oder Starvation genannt) [1]. Diese Art der Verklemmung kommt vor, wenn eine hochpriore Task von einer niederprioren Task abhängig ist. So wartet beispielsweise eine Task 1 mit hoher Priorität auf die Freigabe eines Mutex / Semaphors durch eine niederpriore Task 2. Diese wiederum ist jedoch selbst durch eine dritte Task 3 mit mittlerer Priorität blockiert. Da die niederpriore Task 2 die

4 dritte Task mit einer höheren Priorität nun nicht verdrängen kann, ist es für Task 2 auch nicht möglich die von Task 1 angeforderte Ressource frei zu geben. Dieses Szenario wird Prioritätsinversion genannt und kann beispielsweise durch den Einsatz von Prioritätenvererbung [6] verhindert werden. Dabei erhält, auf obiges Beispiel bezogen, Task 2 kurzzeitig die Priorität von Task 1. Somit ist es für Task 2 nun möglich, Task 3 zu verdrängen und sofort die von Task 1 angeforderte Ressource freizugeben. Ist dies geschehen, erhält Task 2 nun wieder ihre ursprüngliche Priorität. Es ist jedoch wichtig, zwischen begrenzter und unbegrenzter Prioritätsinversion zu unterscheiden. Liegt nur eine begrenzte Prioritätsinversion vor, kann dies meistens toleriert werden. Grund ist, dass zwar ein geschützter Bereich von einer Task mit niedrigerer Priorität belegt wird, es jedoch zeitlich absehbar ist, wann der geschützte Bereich von der aktuell laufenden Task wieder freigegeben wird. Bei einer unbegrenzten Prioritätsinversion dagegen kann ein Prozess wie in obigem Beispiel auf unbestimmte Dauer blockiert bleiben. C. Die Kommunikation zwischen Tasks Wie bereits erwähnt kommen in RTOS häufig Threads zum Einsatz, da diese sehr schnell und direkt miteinander kommunizieren können. Die direkte Kommunikation zweier Tasks untereinander ist in RTOS jedoch auch optimiert. So kann die Kommunikation zweier Tasks üblicherweise auf zweierlei Arten geschehen. Entweder über einen durch Semaphore geschützten gemeinsamen Speicherbereich, auf den beide Tasks zugreifen können. Dies ist die schnellere der beiden Varianten und wird deshalb gerne in RTOS eingesetzt. Oder sie geschieht über den Austausch von Nachrichten, was oft bei räumlich verteilten Systemen eingesetzt wird, da sich hier die Tasks meist keinen gemeinsamen Speicher teilen können. Ein besonderes Merkmal von RTOS in diesem Zusammenhang spielt dabei die Wahrung der Ende-zu-Ende-Prioritäten [2]. Diese kann durch das Merkmal der prioritätsbasierten Kommunikation erreicht werden. Dies bedeutet im Klartext, dass auch bei der Kommunikation der Tasks die Priorität der einzelnen Tasks berücksichtigt wird und somit eine Nachricht höherer Priorität eine Nachricht mit niedriger Priorität überholen kann. Ein weiteres wichtiges Merkmal der Interprozesskommunikation in RTOS ist dessen Asynchronität, damit wird das Blockieren von Tasks vermieden. Dabei müssen Tasks nicht wie bei der synchronen Kommunikation blockiert werden um Nachrichten entgegen nehmen zu können, sondern können jederzeit einen Puffer auf eventuell eingegangene Nachrichten überprüfen. V. DIE SPEICHERVERWALTUNG Auch bei der Speicherverwaltung gibt es Unterschiede zwischen Standard- und Echtzeitbetriebssystemen. Interessant hinsichtlich der Echtzeiteigenschaften sind vor allem die Zuteilung des Hauptspeichers an die Tasks (worauf im nächsten Kapitel ausführlich eingegangen wird), die Einrichtung gemeinsamer Speicherbereiche, die Abgrenzung einzelner Tasks gegeneinander, sowie die Verschiebefunktion von Speicherbereichen. A. Speicherzuteilung, Adressierung und Adressbildung Bei den verschiedenen Modellen der Speicherverwaltung kommen unterschiedliche Ansätze der Speicherzuteilung, Adressierung und Adressbildung zum Einsatz. 1) Speicherzuteilung: Die Speicherzuteilung kann statisch oder dynamisch erfolgen [1]. Bei der dynamischen Speicherzuteilung wird einer Task erst während der Laufzeit Speicher zugeteilt wobei sich dieser während der Laufzeit noch ändern kann. Bei der statischen Zuteilung wird eine Task erst ablauffähig, wenn sie bereits einen Adressraum zugeteilt bekommen hat und dieser ändert sich während der Laufzeit nicht. Außerdem unterscheidet man bei der Speicherzuteilung zwischen der nicht verdrängenden Speicherzuteilung und der verdrängenden Speicherzuteilung. Bei Letztgenannter kann einer Task ihr zugeteilter Adressraum während der Laufzeit wieder entzogen werden, wobei die dort abgelegten Daten auf den Peripheriespeicher ausgelagert werden. 2) Adressierung: Bei der Adressierung unterscheidet man zwischen der reellen Adressierung und der virtuellen Adressierung [1]. Wird eine reelle Adressierung verwendet, ist der physikalische Adressraum mindestens so groß wie der logische Adressraum. Somit können alle Tasks mit zugeteiltem Adressraum gleichzeitig in den Hauptspeicher geladen werden. In den allermeisten Betriebssystemen werden heutzutage allerdings virtuelle Speicheradressen verwendet. Dabei werden die virtuellen logischen Adressen auf physikalische, tatsächlich existente Adressen abgebildet. Für die Tasks sind allerdings nur die logischen Adressen sichtbar und somit auch einzige Referenz. Diese werden dann vom Betriebssystem auf physikalische Adressen abgebildet und somit dem real existierenden Speicher zugeteilt. Da der Adressraum des physikalischen Speichers wie bereits erwähnt auf die tatsächliche Größe beschränkt ist, der logische Adressraum jedoch größer gewählt werden kann, bleibt den Tasks (und damit auch den Anwendungen) die Endlichkeit das Hauptspeichers verborgen. Wird jedoch insgesamt ein größerer logischer Adressraum an die Tasks vergeben als im physikalischen Speicher tatsächlich vorhanden, können nicht alle Tasks gleichzeitig im Hauptspeicher laufen, dies führt dann zwangsläufig zu einer Verdrängungsstrategie (siehe Auslagerung in Abbildung 4). 3) Adressbildung: Bei der Adressbildung unterscheidet man zwischen linearer und streuender Adressbildung [1]. Dies ist ein wichtiges Merkmal zur Klassifizierung von RTOS. Sind zwei Adressräume innerhalb des logischen Adressraums benachbart, dann liegen die so genannten Segmente [3] bei Verwendung der linearen Adressbildung auch im physikalischen Speicher nebeneinander (siehe Abbildung 4). Bei der linearen Adressbildung ist es jedoch nicht zwingend vorgeschrieben, für jede Task nur ein Segment zu verwenden. So macht es für RTOS durchaus Sinn, einer Task mehrere Segmente zuzuweisen. So kann es beispielsweise je ein Segment für den Programm Code, für die Daten, den Stapel und die Halde geben. Bei einer Task mit dynamischer Größe

5 Abbildung 5. Lineare Adressbildung mit Kompaktifizierung [1] Abbildung 4. Lineare Adressbildung mit virtueller Adressierung und Verdrängungsstrategie [3] muss dann z.b. nur das Halde Segment vergrößert oder verkleinert werden, die anderen Segmenten müssen jedoch nicht verändert werden. Außerdem kann es durchaus Sinn machen, die Fehlerbehandlung in ein extra Segment auf einem Peripheriegerät zu lagern, da die Fehlerbehandlung bei den meisten Echtzeitanwendungen nur im Falle eines Fehlers und dem dadurch resultierenden Beenden der Task zum Einsatz kommt. Der dadurch gesparte Platz im Hauptspeicher kann dann für andere Tasks verwendet werden. Ein Problem der linearen Adressbildung ist jedoch die externe Fragmentierung. Sie entsteht nach mehreren Ein- / Auslagerungsvorgängen ohne Kompaktifizierung zwangsläufig, kann jedoch durch eine Speicherbereinigung (wie in Abbildung 5 dargestellt) behoben werden. Dies kostet allerdings Rechenzeit während der Ausführung. Da RTOS zwingend keine Reorganisationsprozessen haben dürfen, verzichten die meisten deshalb auf eine Speicherbereinigung. Es gibt allerdings auch Ausnahmen. So ist in der Sprache Java eine echtzeitfähige Speicherbereinigung implementiert. Durch die Aufteilung des Vorgangs in mehrere kleine Schritte werden zeitkritische Tasks nur unwesentlich behindert. Außerdem bleiben die Daten nach jedem der Schritte konsistent. Wird jedoch die streuende Adressbildung verwendet, kann ein Block im logischen Adressraum diffus auf den physikalischen Adressraum abgebildet werden (dann heißen die Adressräume im logischen Adressraum Seiten und im physikalischen Kacheln ). Somit müssen logisch benachbarte Adressen nicht mehr nebeneinander liegen, sondern können im physikalischen Speicher weit voneinander entfernt sein (siehe Abbildung 6). Abbildung 6. Die streuende Adressbildung [3] Die Seiten bzw. Kacheln sind im Allgemeinen wesentlich kleiner als Segmente (beispielsweise 2 Kilo Byte) und haben eine feste Größe. Somit können die Seiten sehr einfach in Kacheln der gleichen Größe eingelagert werden. Eine Task bekommt nun so viele Seiten zugeteilt wie sie benötigt. Diese werden dann einfach in die nächste freie Kachel abgelegt. Damit muss in Kauf genommen werden, dass die Daten nun nicht mehr unter Beachtung der sequenziellen Reihenfolge im Hauptspeicher abgelegt werden. Allerdings kann so auch auf eine Speicherbereinigung verzichtet werden, da eine frei werdende Kachel einfach wieder durch die als nächstes einzulagernde Seite benutzt werden kann. Ein weiterer Vorteil ist eine feineren Granularität durch die geringe Größe der Seiten / Kacheln. Es entsteht bei der streuenden Adressbildung also keine externe Fragmentierung, wohl aber eine interne [3]. Die interne Fragmentierung entsteht dadurch, dass die Seite und damit auch Kacheln eventuell nicht vollständig gefüllt sind (die feste Größe der Seiten / Kacheln also nicht vollständig ausgenutzt werden kann). Diese Tatsache kommt besonders dann zum

6 Tragen, wenn viele kleine Tasks parallel im Hauptspeicher liegen. Wird der physikalische Speicher jedoch nur von wenigen, größeren Tasks verwendet, ist die interne Fragmentierung eher zu tolerieren. Durch die Tatsache, dass Seiten wesentlich kleiner sind als Segmente, steigt selbstverständlich auch deren Verwaltungsaufwand. Dies kann für RTOS problematisch werden, sobald eine Tabelle für die Zuweisungen der eingelagerten Seiten nicht mehr ausreicht. In diesem Fall ist es üblich, die Seitentabelle auf mehrere Tabellen aufzuteilen und dies in einem so genannten Seitentabellenverzeichnis festzuhalten (siehe Abbildung 7). Durch die damit geschaffene zweistufige Ebene benötigt man dementsprechend mehr Zeit für die Zuteilung, was zu einem Problem werden kann. Abbildung 7. Übersetzung einer virtuellen Adresse mit einer zweistufigen Seitentabelle [4] Unter Verwendung der Verdrängungsstrategie geht mit der feineren Granularität allerdings auch ein öfter auftretender Datentransfer zwischen Hauptspeicher und Peripheriegeräten einher (jedoch mit kleinerer zu übertragender Datenmenge). Soll ein bestimmter Adressraum verriegelt werden, d.h. vom Auslagern geschützt werden, ist die Granularität wiederum als Vorteil zu sehen, da dadurch nicht ein ganzes Segment geschützt werden muss, es können auch einzelne Kacheln geschützt werden. Insgesamt kann man also sagen, dass die streuende Adressbildung Vorteile gegenüber der linearen Adressbildung hinsichtlich Dynamik einzelner Tasks sowie Dynamik der Anzahl der Tasks insgesamt hat. B. Ein Beispielmodell Durch die Kombination dieser Kriterien kann man nun, unter Abwägung der damit verbundenen Vor- und Nachteile, ein bestimmtes Modell zur Speicherverwaltung ableiten. Ein mögliches, relativ einfach zu realisierendes Modell, ist die Kombination aus linearer Adressbildung mit einer statischen Speicherzuteilung, keiner Verdrängung und reeller Adressierung. Einige Vorteile eines solchen Modells sind die einfache Verschiebefunktion einer Task innerhalb des Adressraums aufgrund der linearen Adressbildung. Außerdem besteht ein guter Schutz der Tasks durch die Einrichtung von gemeinsam genutzten Segmenten. Des weiteren erreicht man eine gute Vorhersagbarkeit des Zeitverhaltens aufgrund der nichtpräemptiven Verwaltung. Die durch statische Zuordnung ohne Verdrängung fehlende Dynamik wirkt sich zwar positiv auf die Vorhersagbarkeit aus, bringt allerdings auch Nachteile bei der Variabilität. Variiert beispielsweise der Speicherbedarf einer Task sehr stark, muss trotzdem von Anfang an der maximal benötigte Bedarf reserviert werden. Darüber hinaus muss in diesem Modell Speicher für jede Task reserviert werden, wobei sich zwei (niemals gleichzeitig ablaufende) Tasks nicht einen gemeinsamen Adressraum teilen können. Dadurch entsteht eine starke externe Fragmentierung und es muss jederzeit mindestens so viel physikalischer Speicher bereitgestellt werden können, wie logischer Adressraum reserviert ist. Sofern es die Echtzeiteigenschaften zu lassen, ist es daher trotz eines größeren Zuteilungsaufwands sinnvoll, die dynamische Zuteilung zu wählen. Dies ermöglicht zumindest, dass physikalischer Speicher nicht nur von einer Task verwendet werden kann, löst allerdings nicht das Problem der externen Fragmentierung. Intensive Überlegungen hinsichtlich der Systemanforderungen und des Einsatzzwecks sind also unerlässlich um ein optimales Modell für die Speicherverwaltung bereitstellen zu können. Außerdem haben einige Prozessoren hardwareseitig bereits eine Unterstützung implementiert, die teilweise sogar die lineare und streuende Adressbildung kombinieren. Dies bringt hohe Stabilität und Sicherheit bei der Speicherverwaltung. VI. DIE EIN- UND AUSGABEVERWALTUNG Neben der Taskverwaltung und der Speicherverwaltung ist die Ein- und Ausgabeverwaltung eine durchaus wichtige Aufgabe des Betriebssystems. Sie wird in die Bereiche der Ein- / Ausgabesteuerung und den Gerätetreiber untergliedert. Dies ist sinnvoll, da der Gerätetreiber hierbei die direkte Kommunikation mit der Hardware übernimmt und an jedes Gerät angepasst wird. Dadurch kann die nächst höher liegende Schicht von dieser sehr individuellen Kommunikation abstrahiert werden und somit eine einheitliche und transparente Schnittstelle zur Verfügung stellen. Wird ein Gerät durch ein anderes ersetzt, muss nur der Gerätetreiber ausgetauscht werden, die Steuerung jedoch kann unverändert bleiben. Um diese Abstraktion zu erreichen, übernimmt die Ein- / Ausgabesteuerung die Datenverwaltung und den Datentransport. Dabei muss sie die gegebenenfalls durch die Kommunikation mit den Geräten entstehenden Daten umformatieren und zwischenspeichern. Sie ist jedoch nicht für die Fehlerbehandlung der Geräte zuständig, sondern nimmt nur deren Meldungen (wie Fertig bzw... Fehler ) entgegen [1]. Ein Beispiel einer solchen Abstraktion ist die Verwendung von Blocknummern bei Festplatten. Beim Lesen beziehungsweise Schreiben übergibt das Betriebssystem der Festplatte eine Angabe in Form von Blocknummern, die Festplatte (oder besser gesagt ihr Gerätetreiber) rechnet diese in die von ihr benötigten Angaben wie Kopf, Zylinder und Sektoren um. Die einzelnen Teilaufgaben der Ein- / Ausgabesteuerungsschicht sind folgende: Symbolische Namensgebung: Die Einrichtung symbolischer Adressen um die Hardware geräteunabhängig an-

7 sprechen zu können. Annahme von Ein- / Ausgabeanforderungen: Alle Aufträge werden in Warteschlangen abgelegt. Ähnlich wie bei der Taskverwaltung werden auch hier häufig Prioritäten vergeben um Aufträge mit hoher Dringlichkeit schneller abarbeiten zu können. Vergabe und Zuteilung von Geräten: Die Zuteilung kann auch hier statisch oder dynamisch erfolgen. Bei der dynamischen Zuordnung kommen sehr ähnliche Strategien wie bei der Taskverwaltung zum Einsatz. Da viele Operationen allerdings nicht unterbrechbar sind, kommen hier häufiger nicht-präemptive Verfahren zum Einsatz. Synchronisation: Hier arbeitet die Ein- / Ausgabeverwaltung eng mit der Taskverwaltung zusammen. So müssen beispielsweise bereits wartende Tasks wieder aktiviert werden sobald für Sie eine Rückmeldung einer Ein- / Ausgabeoperation empfangen wird. Schutz der Geräte: Wie bereits erwähnt unterliegt die Hardware in RTOS einem geringeren Schutz als in normalen Betriebssystem, da dies stark zu Lasten der Echtzeiteigenschaften geht. Wichtig ist jedoch auch der Schutz vor Verklemmungen. Ist dieser nicht ausreichend durch die Tasksynchronisation implementiert, kann sie durch Rücktritt und Rücksetzen von Aufträgen nach einer bestimmten Wartezeit realisiert werden (vgl. Timeout, Kapitel IV-B). Dies ist in Echtzeitbetriebssystem wichtig, da diese typischerweise viele Ein- / Ausgabeoperationen durchführen und neben Standardgeräten oft mit vielen weiteren Sensoren und Aktoren interagieren. Kommunikation mit den Gerätetreibern: Weiterleiten der Anforderung an die Gerätetreiber und Entgegennehmen (jedoch nicht das Behandeln) von Status- / Fehlermeldungen. Pufferung: Da die Ausführungsgeschwindigkeit zwischen Tasks und den von ihnen angesprochen Ein- / Ausgabeoperationen meist sehr unterschiedlich ist, müssen Daten gepuffert werden und an Geräte oder die Task weitergeleitet werden. Einheitliches Datenformat: Abstraktion des Datenformat auf einheitliche Informationsströme mit denen unterschiedlichste Geräte angesprochen werden können. A. Die Synchronisation von Ein- / Ausgabeoperationen Eine der einfachsten zu realisierenden Synchronisations- Mechanismen ist das sogenannte Polling [1]. Dabei fragt eine Task zyklisch ein bestimmtes Statusregister ab, ob das Gerät bereits das zu übertragende Datum in das Datenregister abgelegt hat. Ist dies bereits der Fall, kann das Datenregister ausgelesen werden und das Datum verarbeitet werden. Ist das zuständige Bit im Statusregister jedoch noch nicht gesetzt, fragt die Task das Statusregister zyklisch ab und verbraucht somit unnötig Rechenzeit. Daher ist dieses Verfahren für RTOS nicht sehr geeignet. Es wird jedoch trotzdem verwendet, wenn eine hohe Übertragungsleistung erreicht werden muss und dies durch den Einsatz eines DMA-Transfers nicht möglich ist. Normalerweise wird in Echtzeitbetriebssystemen die Synchronisation durch Unterbrechung verwendet. Dabei löst der Schnittstellenbaustein eine Unterbrechung beim Prozessor aus sobald das involvierte Peripheriegerät bereit ist. Nach einer entsprechenden Unterbrechungsbehandlung kann der Prozessor nun den Datentransfer erledigen. Durch die Unterbrechung entsteht zwar ein gewisser Overhead, es wird jedoch nicht unnötig Rechenzeit verschenkt um auf das Peripheriegerät zu warten. In dem eher ungewöhnlichen Fall, dass ein Peripheriegerät die Daten schneller liefert als sie die Task entgegen nehmen kann, wird in die Synchronisation zusätzlich ein Handshake integriert. Dabei meldet sich das Gerät, sobald das Datenregister zum Lesen bereit ist. Außerdem bestätigt die Task dem Peripheriegerät das Datum erhalten zu haben um sicherzustellen, dass keine Daten verloren gegangen sind. 1) Die Unterbrechungsbehandlung: Die Unterbrechungsbehandlung selbst kann dabei auf zwei unterschiedliche Arten geschehen [1]. Entweder wird sie vom Prozessor selbst ausgeführt, was aufgrund der Hardwareunterstützung sehr schnell geschehen kann. Trotz dieses Vorteils wird diese Art der Unterbrechungsbehandlung jedoch meist nur bei relativ schwacher Leistungsfähigkeit des Systems oder harten Echtzeitanforderungen verwendet, da sie auch Nachteile mit sich bringt. Ein erheblicher Nachteil für RTOS ist sicherlich die unabdingbare Unterbrechung der zu dieser Zeit sich auf der CPU befindlichen Task. Auch wenn diese zeitkritisch ist wird sie in jedem Fall durch den Interrupt unterbrochen und kann erst nach Beendigung der Unterbrechungsbehandlung und dem Ausführen der Ein- / Ausgabeoperation fortgesetzt werden. Dies kann verhindert werden in dem die Unterbrechungsbehandlung nicht hardwareseitig vom Prozessor behandelt wird, sondern dieser nur eine Task startet. Die Task ihrerseits startet wiederum die Unterbrechungsbehandlung dann sofwareseitig. Somit ist die Task und damit auch die Unterbrechungsbehandlung ganz normal in das verwendete Schedulingverfahren integriert. Besitzt die Task nun beispielsweise eine niedrigere Priorität als die aktuell auf dem Prozessor laufende, muss sie warten bis sie durch das Schedulingverfahren Rechenzeit zugeteilt bekommt. Dies hat natürlich zur Folge, dass die Reaktionszeit auf Ereignisse wegen der in Software realisierten Unterbrechungsbehandlung verlangsamt wird. Da die Interrupt-Latenzzeit (also die Zeit, die vom Anlegen des Interrupts bis zum Start der entsprechenden Interrupt-Serviceroutine vergeht) als ein wichtiger Gradmesser für die Echtzeiteigenschaften eines RTOS gilt [5], muss hier allerdings mit Bedacht justiert werden. Gerade hinsichtlich einer eventuell sehr wichtigen, zu dieser Zeit auf der CPU laufenden Task ist dieses Konzept für RTOS jedoch sehr interessant. Außerdem koexistieren somit nicht zwei unterschiedliche Scheduler, die Unterbrechungsbehandlung kann in den vom Betriebssystem bereitgestellten Scheduler integriert werden. VII. CONCLUSION Wie in dieser Arbeit zu sehen, gibt es eine Vielzahl an Möglichkeiten, ein Betriebssystem für die Ausführung von

8 Echtzeitanwendungen zu optimieren. Hinsichtlich der Variabilität ist sicherlich die Verwendung eines Mikrokerns eine sehr gute Möglichkeit. Wichtig dabei ist, zu keiner Zeit die tatsächlichen Anforderungen an das System aus den Augen zu verlieren. So ist auch der erste Schritt bei einer Systemoptimierung hinsichtlich der Echtzeiteigenschaften mit entscheidend. Dieser Schritt sollte eine sehr genaue Evaluation der tatsächlichen Anforderungen an ein Echtzeitbetriebssystem darstellen, mit möglichst genauen Vorstellungen der auf dem System laufenden Prozesse. Dies ist wichtig, da nahezu jede Optimierung auch Einschränkungen bzw. Nachteile mit sich bringt. Also gilt es, nicht nur vordergründig neue Vorteile zu schaffen, sondern auch weitsichtig neue Probleme zu vermeiden. Dies gilt vor allem bei dynamischen, sich eventuell in Zukunft noch verändernden Systemen. Ist diese Arbeit jedoch erfolgreich erledigt, kann das System durch explizite und feingranulare Veränderungen weiterhin gut optimiert werden. Dies bringt einen hohen Gewinn für das betroffene und alle daran angeschlossenen Systeme. LITERATUR [1] Heinz Wörn, Uwe Brinkschulte, Buchtitel: Echtzeitsysteme (Grundlagen, Funktionsweisen, Anwendungen ), Seite 344, 349, 354, 356, 382, 390, 396, 397, 400, 413, 414, 419 Berlin / Heidelberg, Deutschland: Springer, 2005 ISBN: [2] Uwe Brinkschulte, Kapitel: 4.5 Synchronisation und Kommunikation, Seite 4, 7, ppt Stand: [3] DHBW Stuttgart, Studiengang Elektrotechnik, Vorlesungsmaterial: Realzeitsysteme, Seite 6, 13, 22, 28 rie/rzs/vorlesung/ RealzeitVorlesungKap9.pdf, Stand: [4] Djamshid Tavangarian, Daniel Versick, Buchtitel: Basiswissen Rechnerstrukturen und Betriebssysteme ), Seite 137, 152 Witten, W3L, 2008 [5] Thimo Kling, Dipl.-Wirt.Ing. (FH), Kapitel: Interrupt (Fehlerbehandlung), Stand: [6] Technische Universität München, Fakultät für Informatik, Vorlesungsmaterial WS 2010/2011: Echtzeitsysteme, Kapitel: Prioritätsvererbung (priority inheritance), echtzeit pdf, Stand: