Echtzeit Betriebssysteme. VxWorks

Größe: px
Ab Seite anzeigen:

Download "Echtzeit Betriebssysteme. VxWorks"

Transkript

1 Echtzeit Betriebssysteme - VxWorks Kleines Seminar im WS 2003/2004 eingereicht durch Sven Schomaker Gießen, 3. Februar 2004

2 Inhaltsverzeichnis 1 Abstract 1 2 Einführung 1 3 Echtzeit 2 4 Basisdienste von Echtzeitbetriebssystemen Taskmanagement (Scheduling) Speicherverwaltung Synchronisation & Kommunikation Device I/O Supervision VxWorks Scheduling Speicherverwaltung Synchronisation & Kommunikation Device I/O Supervision Epilog 15

3 1 ABSTRACT 1 1 Abstract Die vorliegende Arbeit stellt Problematiken und allgemeine Lösungsansätze von Echtzeitbetriebssystemen vor und geht exemplarisch auf das weit verbreitete Echtzeitbetriebssystem VxWorks des kalifornischen Unternehmens WindRiver ein. Im ersten Teil der Arbeit wird eine Definition des Echtzeitbegriffs vorgenommen und eine allgemeine Einführung in den Bereich der Echtzeitverarbeitung gegeben. Daraufhin wird eine genauere Betrachtung der für die Echtzeitverarbeitung wesentlichen Problematiken sowie Verfahren zu deren Lösung vorgenommen. Der zweite Teil der Arbeit befasst sich im Wesentlichen mit einer Betrachtung des Echtzeitbetriebssystems VxWorks und veranschaulicht exemplarisch einige der im ersten Abschnitt vorgestellten Lösungsansätze. Die vorliegende Arbeit beabsichtigt einen allgemeinen Überblick über die Problematiken von Echtzeitbetriebssystemen zu geben und wird daher keine detailierte Einführung in spezielle programmiertechnische Details im Umgang mit VxWorks geben. Zu diesem Zweck sei auf die sehr detailierten und umfangreichen Programmier-Referenzen und Anleitungen von WindRiver verwiesen [10], [11], [9]. The present work discusses several problem areas of realtime operating systems (RTOS) and introduces some proven solutions on that particular problems areas. Afterwards it gives an introduction to the popular RTOS VxWorks developed and maintained by the californian WindRiver corporation. The first part gives an general introduction to the term of realtime and furthermore will discuss the previously mentioned problem areas one inescapable encounters when regarding RTOS. After conveying the reader to the common realtime issues, the second part of this work will point out, how those problems might be soluted in an realworld RTOS on the basis of VxWorks. Since this work is meant to introduce common concepts of realtime operating systems and not to give an detailed programming reference on VxWorks, there won t be any detailed descriptions of actual system calls or similar to describe programmers issues when dealing with VxWorks. For this purpose the author refers to the pretty detailed and comprehensive programmers manuals provided by WindRiver[10], [11], [9]. 2 Einführung Echtzeitsysteme 1 spielen in der Industrie und Forschung eine große Rolle und werden in unserer heutigen technisierten Gesellschaft in einer großen Anzahl von Anwendungen zum Einsatz gebracht. Als ältestes Einsatzgebiet für Echtzeitsysteme kann zweifellos der Einsatz in der Industrie zur Prozesssteuerung angesehen werden. Die ersten Prozessrechner wurden etwa um 1959 entwickelt und damals wie heute zur Steuerung von Fertigungsprozessen in der Industrie verwendet. Sicherlich sind diese Systeme kaum noch mit den heutigen hoch integrierten Mikrocontrollern vergleichbar, doch wurde man bereits damals darauf aufmerksam, das die Steuerung von zeitkritischen Abläufen entsprechende zeitliche Determinismen 2 in den Steuerungsprozessen benötigen. Seit der Entwicklung der ersten Prozessrechner hat 1 Unter einem Echtzeitsystem versteht man die Menge an Komponenten, die zusammengenommen zur Bearbeitung einer Aufgabe unter Gesichtspunkten des zeitlichen Determinismus benötigt und verwendet werden. 2 Der Begriff der Echtzeit und des zeitlichen Determinismus sei in der Einführung vorweggenommen und wird im Kapitel Echtzeit ausführlich behandelt. Bis dahin bitte ich den Leser nachsichtig zu sein oder das entsprechende Kapitel vorwegzunehmen.

4 3 ECHTZEIT 2 sich das Einsatzgebiet für Echtzeitsysteme stark erweitert, da sich die technischen Fähigkeiten der modernen Industriegesellschaft bis heute stark weiter entwickelt haben. So wurde mit fast jedem der neu für die Technik eröffneten Gebieten, die Anforderung an einen zeitlichen Determinismus der mit dieser neuen Techniken einhergehenden automatisierten Datenverarbeitung neu erkannt. Heutzutage erstreckt sich das Einsatzgebiet von Echtzeitsystemen von der Prozessrechentechnik über die Avionik, Fahrzeug- und Weltraumtechnik, bis hinein in das heimische Wohnzimmer, wo in Multimedialen Systemen ebenfalls zeitkritische Systeme anwendung finden. Die Gestalt der Komponenten eines Echtzeitsystems variert je nach Anwendungsgebiet beträchtlich. In vielen Bereichen wie z.b. der Automobilindustrie werden Hard- und Softwarekomponenten verwendet, die direkt auf die jeweilige Anwendung zugeschnitten sind. Hierbei war (und ist) es nicht selten der Fall, das die spezialisierte Software direkt auf der Hardware operiert, ohne dazu Dienste einer abstrahierenden Softwareschicht in Anspruch zu nehmen wie Sie ein Betriebssystem 3 bereitstellt. In den Vergangenen Jahren wurden jedoch vermehrt Anstrengungen unternommen auch im Bereich der Embedded-Systems Betriebssysteme bereitzustellen, die die immer komplexere Hardware abstrahieren und die Steuerung von Hardware und die Resourcenverwaltung unter Beachtung des erforderlichen zeitlichen Determinismus übernehmen. Ein solches Betriebssystem, dass die von ihm bereitgestellten Dienste innerhalb fest definierter zeitlicher Schranken bereitstellt, nennt man Echtzeitbetriebssystem. Die Beispiele für Echtzeitbetriebssystem sind vielfältig und deren Anzahl doch auch sehr beachtlich, als da wären psos, YARTOS, ARTS, LynxOS, RealtimeLinux, QNX, VxWorks und noch viele weitere. Natürlich werden Echtzeitsysteme auch auf Basis konventioneller Hardware aufgebaut. In einigen Anwendungen, wie z.b. der Prozesssteuerung ist es Hilfreich auf Low-Cost Hardware aufbauend echtzeitfähige Systeme zu erzeugen. Für die Echtzeitfähigkeit eines Systems ist mitnichten spezielle Hardware von Nöten. Eine Anzahl an Echtzeitbetriebssystemen, die für die konventionelle x86 Hardware entwickelt werden, hauchen eben diesen Systemen Echtzeitfähigkeiten ein, auch wenn hierzu einige Dinge spezieller Betrachtung bedürfen 4. 3 Echtzeit Im allgemeinen Sprachverständnis wird der Begriff der Echtzeit häufig mit Kenngrößen des menschlichen Erfahrungsbereiches beschrieben. So tritt häufig eine zeitliches Gefühl von Verarbeitungsgeschwindigkeit, die sich in einem durch den menschenlichen Erfahrungsbereich begrenzten Rahmen befindet, an die Stelle der eigentlichen Definition von Echtzeit und der damit verbundenen Begriffe. So ist Beispielsweise die Verarbeitung von 25 Frames pro Sekunde zur Erzeugung eines flüssigen visuellen Sinneseindrucks für den Menschen bei der Wiedergabe von Bewegtbildern ausreichend, jedoch ist die Verarbeitung von 25 Frames pro Sekunde bei der automatisierten visuellen Erkennung von Fehlerhaften teilen 3 Ein Betriebssystem ist die Menge an Software, welche die Hardwarebetriebsmittel verwaltet und sie in eine für die Anwendung leichter handhabbare Form transformiert. Ein Betriebssystem tritt der Anwendung gegenüber als virtuelle Maschine auf und stellt der Anwendung eine Reihe von Diensten bereit, die sie zur Erfüllung der ihr zugedachten Aufgaben verwenden kann[2]. 4 Auf solcherlei Implikationen, welche die Forderung nach Echtzeitfähigkeit für die Programmierung von System mit sich bringt, wird im Kapitel über Basisdienste von Echtzeitbetriebssystem näher eingegangen.

5 3 ECHTZEIT 3 auf einer Produktionsstraße spätestens dann unzureichend, wenn pro Sekunde 60 Objekte die Kamera passieren. Wie man leicht einsehen kann lässt sich der Begriff der Echtzeit nicht anhand menschlicher Sinneseindrücke festmachen. Der menschliche Erfahrungsbereich ist somit im Sinne der Echtzeitverarbeitung Sinnfällig. Der eigentliche Begriff der Echtzeit beschreibt mitnichten eine sich an den kognitiven Fähigkeiten von Menschen orientierende Verarbeitungsgeschwindigkeit, sondern muss im jeweiligen Anwendungskontext definiert werden. Weiterhin ist auch eine Einschränkung des Echtzeitbegriffes auf die Verarbeitungs- oder Reaktionsgeschwindigkeit von Systemen falsch, da Echtzeit einen weitaus breiteren Definitionsrahmen besitzt, auch wenn diese beiden Faktoren wichtige Kenngrößen für Echtzeitsysteme darstellen. Vielmehr muss ein Echtzeitsystem einen zeitlichen Determinismus aufweisen, der das Zeitverhalten eines Systems vorhersagbar macht und unter allen Bedingungen garantiert ist. Somit kann als Definition von Echtzeit gelten: Ein System agiert genau dann in Echtzeit, wenn die Bearbeitung einer Aufgabe einen unter allen Bedingungen garantierten zeitlichen Determinismus aufweist, der zur korrekten Erfüllung der jeweiligen Aufgabe hinreichend ist. Unter den angestellten Betrachtungen kann man sagen das die korrekte Bearbeitung einer Aufgabe in einem Echtzeitsystem nicht nur von der logischen Korrektheit, sondern auch von der zeitlichen Korrektheit der Erfüllung der Aufgabe abhängt und das Echtzeitsystem somit einen garantierten zeitlichen Determinismus aufweisen muss. Die Forderung nach zeitlicher Korrektheit der Erfüllung einer Aufgabe ist jedoch nicht Absolut, da sich die Auswirkungen bei einem Verfehlen der für eine bestimmte Aufgabe definierten zeitlichen Schranken in ihrer Ernsthaftigkeit für viele Anwendungen unterscheiden. So ist es sicherlich nicht als fataler Systemfehler anzusehen, wenn in einem Videostream bei der Bildwiedergabe am heimischen Computer Rahmen verworfen werden, wobei das Verwerfen von Rahmen in der bereits erwähnten Fertigungsstraße durchaus als kritisch zu betrachten ist. Um den jeweils unterschiedlichen stärken in denen Echtzeit gefordert wird Rechnung zu tragen, werden Aufgaben (nachfolgend als Tasks bezeichnet) je nach Echtzeitanforderung folgendermaßen klassifiziert: Harte Echtzeitanforderung (Hard Realtime) einer Anwendung besteht genau dann, wenn eine Überschreitung der zur Erfüllung einer Aufgabe vorgeschriebenen zeitlichen Schranken einen fatalen Systemfehler zur Folge hat, für den keine geeigneten Maßnahmen zum Failure-recovery zur Verfügung stehen. Ein solcher Fehler wäre Beispielsweise ein Verfehlen der Zeitschranken in einem System zur automatischen Kollisionserkennung in der Avionik. Wenn ein solches System die zeitlichen Schranken für die Meldung einer Kollision oder das selbstständige Eingreifen in die Situation verpasst, führt dies zweifellos zu einem fatalen Systemfehler, für den ausser dem Aufsammeln von Wrackteilen kaum ein geeigntetes Failure-Recovery zur Verfügung stehen dürfte. Weiche Echtzeitanforderung (Soft Realtime) einer Anwendung besteht genau dann, wenn eine Überschreitung der zur Erfüllung einer Aufgabe vorgeschriebenen zeitlichen Schranken einen Systemfehler zur Folge hat, für den entweder geeignete Maßnahmen zum Failure-recovery zur Verfügung stehen oder dessen Auswirkungen als nicht Fatal anzusehen sind. Beispielsweise besitzen die oben erwähnten Multimediaanwendungen weiche Echtzeitanforderungen, da hier der Verlust eines Frames (Framedrop) nicht zu fatalen Fehlern führt, auch wenn ein ruckeliges Bild bei der Wiedergabe von Videostreams sicherlich dem Genuss nicht dienlich ist.

6 3 ECHTZEIT 4 Keine Echtzeitanforderung (None Realtime) einer Anwendung besteht genau dann, wenn die Bearbeitung einer Aufgabe keinen zeitlichen Determinismus aufweisen muss, die Korrektheit der Bearbeitung also unabhängig von jeglichen zeitlichen Anforderungen ist und somit nur von der logischen Korrektheit abhängt. Beispielsweise ist ein Editor eine nicht Echtzeitanwendungen bei der zweifellos kein zeitlicher Determinismus vorhanden sein muss (auch wenn es schön ist, wenn der Tastendruck in annehmbarer Zeit auf dem Bildschirm erscheint). Nachdem nun ein allgemeines Verständnis für die Echtzeit und Echtzeitsysteme vorhanden sein sollte, werde ich im nächsten Kapitel ein wenig auf die Basisdienste eingehen, die ein Echtzeitbetriebssystem i.d.r. bereitstellt. Die Betrachtung der Basisdienste erfolgt unter Einbeziehung des in Echtzeitsystemen erforderlichen zeitlichen Determinismus und weist an geeigneter Stelle auf die besonderheiten hin, die diese Forderung für die Konzipierung der Basisdienste eines Echtzeitbetriebssystems und der allgemeinen Programierung von Echtzeitsystemen bedeutet.

7 4 BASISDIENSTE VON ECHTZEITBETRIEBSSYSTEMEN 5 4 Basisdienste von Echtzeitbetriebssystemen Wie bereits erwähnt führt die Forderung nach deterministischen Zeitverhalten in Echtzeitsystemen eine völlig neue Sichtweise bei der Planung von Software und Hardware eines Rechensystems ein. Um ein deterministisches Zeitverhalten bestimmter Anwendungen zu erreichen benötigt man zum einen sehr detailierte Kenntnisse über die hardwareseitigen Abläufe und die Ausführungseigenschaften von Code. Bei der Betrachtung des Quellcodes ist die Anzahl an Taktzyklen, die für die Abarbeitung einer Sequenz von Anweisungen benötigt werden in der Regel durchaus bekannt, jedoch spielen hier latente Verzögerungen die direkt auf die strukturellen Hardwareeigenschaften zurückzuführen sind eine große Rolle. Für gewöhnlich offerieren Echtzeitbetriebssysteme ebenso wie allgemeine Betriebssysteme eine Reihe von Diensten, die von der Anwendungssoftware zur Durchführung ihrer Aufgaben herangezogen werden kann. Diese Dienste müssen allerdings im Gegensatz zu allgemeinen Betriebssystemen garantierte Zusagen über deren Zeitverhalten machen und dies unabhängig von der aktuellen Auslastung des Systems. Eben diese verschärften Voraussetzungen begrenzen den Umfang der von Echtzeitbetriebssystemen für Gewöhnlich bereitgestellten Dienste mit garantiertem Zeitverhalten auf eine Untermenge der Dienste, die ein allgemeines Betriebssystem in der Regel bereitstellen wird. Die von einem Echtzeitbetriebssystem bereitgestellten Kerndienste lassen sich in der folgenden Abbildung veranschaulichen. Abbildung 1: Übersicht über Basisdienste eines Echtzeitbetriebssystems Wie aus der obigen Abbildung entnommen werden kann, zählen zu den Kerndiensten die von einem Echtzeitbetriebssystem bereitgestellt werden meist das Taskmanagement (Scheduling), die Task-Synchronisation und Kommunikation, die Bereitstellung von I/O-Schnittstellen zu Block- und Character Devices, sowie (rudimentäre) Mechanismen zur dynamischen Speicherzuteilung. Darüber hinaus bieten einige Echtzeitbetriebssysteme noch eine Anzahl an Erweiterungen wie dynamische Speicherverwaltung inklusive Paging und Swapping, Netzwerkschnittstellen und andere Dienste an. Im folgenden werde ich noch gesondert auf die einzelnen Basisdienste eingehen und einige Problematiken die mit diesen Diensten in zusammenhang stehen etwas näher erläutern.

8 4 BASISDIENSTE VON ECHTZEITBETRIEBSSYSTEMEN Taskmanagement (Scheduling) In den Vergangenen Jahren sind wie in der Einführung bereits erwähnt wurde große Anstrengungen unternommen worden Echtzeitbetriebssystem zu schaffen, die wie die General-Purpose-Betriebssysteme eine Vielzahl von Diensten den Anwendungen zur Verfügung stellen. Mit einer der wichtigsten Dienste der bereit gestellt wird ist wie bei den allgemeinen Betriebssystemen die Mechanismen zur parallelen Nutzung des Prozessors. Bei der Betrachtung von Echtzeitsystemen fällt auf, dass nahezu alle Systeme eine parallele Bearbeitung von Daten leisten müssen. Diese parallele Bearbeitung kann man sicherlich bis zu einem gewissen Grad durch die Bereitstellung weiterer designierter Mikroprozessoren erreichen, jedoch lässt sich das Konzept nicht beliebig ausdehnen. Hier wird in der Echtzeitdatenverarbeitung das schon aus den allgemeinen Betriebssystemen bekannte Multitasking angewendet, um die quasi parallele Bearbeitung von Tasks zu erreichen. Das wichtigste Konzept hierbei ist das Scheduling, das im folgenden näher betrachtet werden soll. Die Forderung nach quasi paralleler Ausführung einer Anzahl an Tasks benötigt eine Strategie wie lauffähige Prozesse dem Prozessor zugeteilt werden. In allemeinen Betriebssystemen, die meist in interaktiven Dialogbetrieb eingesetzt werden, bestimmt die Wahl der Scheduling-Strategie eine Mischung aus den folgenden 5 Forderungen[2]: 1. Fairness: Jeder Prozeß erhält einen gerechten Anteil der Prozessorzeit. 2. Effizienz: Der Prozessor ist immer vollständig ausgelastet. 3. Antwortzeit: Die Antwortzeit für den interaktiven Benutzer ist minimal. 4. Verweilzeit: Die Wartezeit auf die Ausgabe von Stapelaufträgen wird minimiert. 5. Durchsatz: Die Anzahl der in einem bestimmten Zeitintervall ausgeführten Aufträge wird maximiert. Zu diesen Punkten gesellt sich im Rahmen der Echtzeitbetriebssysteme noch eine weitere, nämlich der nach dem deterministischen Zeitverhalten. Das deterministische Zeitverhalten spielt hierbei die wichtigste Rolle, wobei andere Forderungen in einem Echtzeitsystem nur untergeordnete Priorität haben oder gänzlich ausser acht gelassen werden. Grundsätzlich teilt man die Schedulingstrategien ein in kooperatives Scheduling, verdrängendes Scheduling und nicht-verdrängendes Scheduling[1]. Durch die Forderung nach deterministischen Zeitverhalten kommt von den Scheduling-Strategien im Grunde nur die des verdrängenden (präemtiven) Scheduling für die Anwendung in Echtzeitbetriebssysteme in Frage, da alle anderen Strategien ein schwer bzw. nicht vorhersagbares Moment in das Zeitverhalten eines Systems einbringen. Von den bekannten Verfahren zum Scheduling werden in Echtzeitbetriebssystemen auschließlich prioritätsbasierte Verfahren eingesetzt. Die prioritätsbasierten Verfahren unterscheiden sich i.d.r. darin, auf welche Art die Priorität eines Prozesses bestimmt wird. Allen gemein ist, dass aus der Menge der rechenbereiten Prozesse immer der mit der höchsten Priorität ausgewählt wird. Die Prioritätsbasierten Verfahren lassen sich nach dem Zeitpunt, zu dem die Prioritäten einzelner Prozesse vergeben werden, in statische

9 4 BASISDIENSTE VON ECHTZEITBETRIEBSSYSTEMEN 7 Abbildung 2: Übersicht einige prioritätsbasierten Schedulingverfahren und dynamische Verfahren einteilen. Eine Übersicht über die wichtigsten eingesetzten Verfahren bietet die folgende Grafik. Bei der Betrachtung von Schedulingverfahren im Bereich von Echtzeitbetriebssystemen, wird unterschieden zwischen periodischen und aperiodischen Tasks. Aperiodische Tasks mit einer harten Echtzeitanforderung werden häufig auch als sporadische Tasks bezeichnet. Ein periodischer Task wird periodisch zu vorhersagbaren Zeitpunkten in äquidistanten Intervallen aktiviert, wobei ein sporadischer Task i.d.r. beim Auftreten von externe Ereignisse aktiviert werden muss. In der Regel sind Echtzeitsysteme reaktive Systeme, d.h. beschränken sich nicht nur auf periodische Tasks sondern arbeiten ebenfalls in hohem Maße mit aperiodischen Tasks. Im folgenden soll nur kurz auf die Eigenheiten der drei wichtigsten Schedulingverfahren eingegangen werden. Eine detaillierte Diskussion der einzelnen Verfahren findet sich u.a. in [3] und [1]. Deadline Monotonic Scheduling: Beim Deadline Monotonen Scheduling werden den einzelnen Task vor der Laufzeit statische Prioritäten zugewiesen. Die Priorität eines Tasks ergibt sich hierbei aus der Länge seiner Deadline und wird invers zu dieser vergeben, dh. je Länger die Zeit zur Deadline desto niedriger die Priorität. Ratenmonotones (rate monotonic) Scheduling: Beim ratenmonotonen Scheduling werden den Prozesse ebenfalls vor der Laufzeit statische Prioritäten zugewiesen. Das ratenmonotone Scheduling lässt sich nur auf periodische Tasks anwenden, also solche Tasks, deren aktivierung periodisch zu vorhersagbaren Zeitpunkten in äquidistanten Intervallen geschehen soll. Die Priorisierung geschieht hierbei anhand der Rate, mit der ein Prozess aktiviert werden muss. Solche Prozesse die häufiger (höher frequent) aktiviert werden müssen, bekommen a priori eine höhere Priorität zugewiesen, als solche deren Aktivierung weniger häufig erforderlich ist. Earliest Deadline First: Beim EDF Scheduling wird den einzelnen rechenbereiten Prozessen abhängig von ihrer Zeitschranke dynamisch eine Priorität zugeordnet. Hierbei bekommen solche Prozesse,

10 4 BASISDIENSTE VON ECHTZEITBETRIEBSSYSTEMEN 8 deren Zeitschranke am nächsten ablaufen wird, die höchste Priorität zugeordnet und somit als nächstes zur Ausführung gebracht. Least Laxity First: Der LLF Schedulingalgorithmus ist eine Variante des EDF, bei der auch die voraussichtliche Ausführungszeit des Tasks mit zur Berechnung der Priorität herangezogen wird. Bei jedem Schedulingzyklus wird die Zeit berechnet, die ein Task bis zum erreichen seiner Deadline noch übrig haben würde, wenn er von dem Schedulingzeitpunkt bis zu seiner Beendigung den Prozessor zu seiner Verfügung hätte. Diese Zeit wird als Laxity bezeichnet. Den Prozessor bekommt nun derjenige Prozess zugeteilt, der die geringste Laxity zu einem gegebenen Zeitpunkt besitzt. Wie man sicherlich erkannt hat, beschränken sich sämtliche oben aufgeführten Schedulingalgorithmen auf das Scheduling von periodischen Tasks. Dies liegt daran, dass das Scheduling von aperiodische Tasks sehr komplex ist und in einer gemischten Umgebung von periodischen und aperiodischen Tasks meist derart auf das Scheduling von Periodischen Tasks zurückgeführt wird, dass man einen hoch priorisierten periodischen Servertask einführt, der während seiner Ausführungszeit anstehende aperiodische Tasks auf Basis des ihm zustehenden Quantums die CPU benutzen lässt. Diese herangehensweise reduziert das Schedulingproblem aperiodischer Tasks auf das Polling anstehender aperiodischer Tasks und basieren meist auf dem Ratenmonotonen- oder EDF-Schedulingalgorithmus. Beispiele für diese Art von aperiodischen Schedulingalgorithmen sind u.a. der Priority Exchange, Deferrable Server, sowie der Sporadic Server Algorithmus [4]. Ein weiterer Aspekt, der sowohl mit dem Scheduling aber auch mit der Reaktion auf externe Ereignisse zusammenhängt, ist die Art, mit der Dienste des Systemkerns ausgeführt werden. Die meisten allgemeinen Betriebssysteme blockieren während der Ausführung von Systemdiensten im Kernelmode die Interrupts um eine Verdrängung während der Bearbeitung von Serviceanforderungen zu unterbinden. Diese vorgehensweise ist in allgemeinen Betriebssystemen auch gänzlich unproblematisch, ist jedoch in Echtzeitbetriebssystemen nicht anwenbar. Stellt nämlich ein Task zu einem gegebenen Zeitpunkt während seiner Ausführungszeit einen Servicerequest an das Betriebssystem, könnten bei einer nicht unterbrechbarkeit der Systemdienste keinerlei Schedulingaktivitäten oder Reaktionen auf externe Ereignisse vonstatten gehen. Dies wäre der Vorhersagbarkeit des System bzgl. des Zeitverhaltens nicht besonders zuträglich und in dem Fall das ein Task just zu diesem Zeitpunkt eine Prozessorzuteilung benötigt, um seine Deadline einzuhalten wäre eine Fehlersituation vorprogrammiert. Aus diesem Grunde werden die Systemdienste soweit wie möglich so konzipiert, dass eine Verdrängung im Kernelmode möglich ist. Bei der Betrachtung des Zeitverhaltens eines Systems, spielt die Latenzzeit eines Schedulingalgorithmus eine große Rolle. Wie dem Leser sicherlich bekannt ist, muss bei einem Kontextwechsel der aktuelle Prozessorzustand in den Hauptspeicher gerettet werden, was eine gewisse Zeit benötigt. Zu dieser Latenzzeit summiert sich natürlich auch die Zeit, die der jeweilige Schedulingalgorithmus benötigt, um den nächsten zu aktivierenden Prozess aus der Menge der rechenbereiten Prozesse auszuwählen. Hierbei ist natürlich ausschlaggebend, dass ein Algorithmus eine definierte zeitliche Obergrenze für die Ermittlung des nächsten auszuführenden Prozesses, unabhängig von der Anzahl der wartenden Prozesse haben muss, um den zeitlichen Determinismus des Systems nicht zu gefährden.

11 4 BASISDIENSTE VON ECHTZEITBETRIEBSSYSTEMEN Speicherverwaltung Die Speicherverwaltung in Echtzeitsystemen unterscheidet sich meist stark von der in allgemeinen Betriebssystemen eingesetzten Speicherverwaltung. Die gängige konventionelle Hardware enthält eine ganze Reihe von Mechanismen um die Anforderungen der Software zu unterstützen und die Systemperformance zu optimieren. So unterstützen eigentlich alle modernen Architekturen hoch entwickelte Mechanismen wie Caching, virtuellen Speicher mit Paging und Swapping, sowie die Segmentierung des Hauptspeichers. Alle diese Mechanismen dienen in den heutigen Systemen dazu die Anzahl der nebenläufig ausführbaren Programme zu erhöhen, ohne durch den physikalisch vorhandenen Hauptspeicher limitiert zu sein oder die Zugriffsgeschwindigkeit auf den Hauptspeicher zu optimieren. Eben solche Mechanismen lassen jedoch ein sicheres Vorhersagen des Zeitverhaltens nicht zu, weshalb in Echtzeitbetriebssystemen Lösungen gefunden werden müssen um mit den Problematiken die konventionelle Hardware für die Vorhersagbarkeit des Zeitverhaltens mit sich bringt. Weitere Probleme tun sich auf, wenn man die in modernen Betriebssystemen angewendete dynamische Alloziierung von Hauptspeicher anschaut. In Echtzeitbetriebssystemen wird die dynamische Allozierung von Hauptspeicher meist mit sehr einfachen Strategien wie begrenzten Memory-Pools oder First Fit Strategien wie in VxWorks gearbeitet und manche Echtzeitbetriebssysteme wie RTLinux verzichten sogar vollständig auf die dynamische Alloziierung des Hauptspeichers. Vor allem solche Strategien, die eine Externe Fragmentierung des Hauptspeichers verursachen sind in Echtzeitsystemen problematisch.[13] Die Speicherhierarchie in Echtzeitbetriebssystemen ist in der Regel Flach und verzichtet auf Konzepte wie virtuellem Speicher mit Paging und Swapping sowie der Isolierung von einzelnen Prozessen innerhalb des Hauptspeichers. Vor allem das Konzept des auf Swapping und Paging basierenden virtuellen Speichers lässt sich in Echtzeitbetriebssystemen nicht verwenden, da die Ein- und Auslagerung von Speicherseiten in/aus dem Hauptspeicher eine nicht vorhersagbare Latenzzeit in die Bearbeitung von Tasks einbringt. In Echtzeitbetriebssystemen die trotzdem Paging und Swapping unterstützen werden Mechanismen bereitgestellt um Speicherseiten oder ganze Echtzeitprozesse im Hauptspeicher resident zu halten. Weiterhin Problematisch sind auch die Konzepte des Caching und Direkten Hauptspeicherzugriffs, da auch diese Mechanismen eine unvorhersagbare Verzögerung bzw. nichtdeterministisches Zeitverhalten in ein Echtzeitsystem einbringen. Beim DMA können aufgrund des sogenannten Cycle Stealing und den Cache Koheränzen unvorhersagbare Verzögerungen auftreten. Beim Cycle Stealing kann der Prozessor nach gewährter Busanforderung durch den DMA Controller ggf. einen darauffolgenden Buszugriff nur Verzögert durchführen, wenn der DMA Controller noch den Bus belegt, was natürlich nicht vorhersagbar ist. Das Problem mit Caching ist, dass durch Cache Misses eine gewisses Maß an Unvorhersagbarkeit bzgl. des Zeitverhaltens einer Task in das System eingebracht wird. Das Problem wird deutlich, wenn man sich vor Augen führt, dass z.b. bei einem Kontextwechsel der Cacheinhalt in der Regel vollständig oder in Teilen ungültig wird und der Cache bei erneuter Einlagerung mit gültigen Daten schrittweise wieder aufgebaut werden muss und das Maß an tatsächlichen notwendigen Hauptspeicherzugriffen nicht im Voraus bestimmen kann. Um das Problem zu umgehen kann man entweder den Cache in einzelne Partitionen teilen, die einem Task exclusiv zugeteilt werden oder das Caching für bestimmte Speicherbereiche deaktivieren.[3]

12 4 BASISDIENSTE VON ECHTZEITBETRIEBSSYSTEMEN Synchronisation & Kommunikation Ein weiteres Kapitel bei der Betrachtung von Echtzeitbetriebssystemen und echtzeitfähiger Software nimmt die Synchronisation und Kommunikation nebenläufiger Prozesse ein. Synchronisation von Prozessen impliziert in der Regel eine Zeit in der ein Prozess auf die Beendigung einer Tätigkeit eines anderen Prozesses warten muss. Solche Wartezeiten sind natürlich nicht immer Problematisch sondern in vielen Fällen durchaus gewünscht, jedoch muss in einem Echtzeitsystem eben diesen Wartebedingungen eine besondere Aufmerksamkeit gewidmet werden damit die Synchronisation nicht zum Verpassen einer zeitlichen Schranke für die Bearbeitung einer bestimmten Aufgabe führt. Weiterhin muss man auch die Möglichkeiten von Blockierungen erwägen, wenn man bei der Echtzeitprogrammierung mit Prozesssynchronisation und Kommunikation arbeitet. Sicherlich unterscheiden sich echtzeitfähige Programme bzgl. der Blockierungen nicht von konventionellen Programmen, jedoch sind die Auswirkungen von Blockierungen in Echtzeitsystemen in der Regel bedeutend schwerwiegender. Die Mechanismen zur Realisierung von Prozesssynchronisation unterscheiden sich in der Regel nicht von den in allgemeinen Betriebssystemen angewendeten Mechanismen, wie Spinlocks und Semaphoren oder die Sperrung von Interrupts. Zusätzlich zu diesen Möglichkeiten bieten einige Echtzeitbetriebssysteme die Möglichkeit den Scheduler zu deaktivieren, damit zwar die Reaktion auf externe Ereigniss anders als bei der Sperrung von Interrupts noch möglich ist 5, jedoch eine Verdrängung des aktiven Prozesses unabhängig von dessen Priorität unterbunden wird. Ein Problem das bei der Synchronisation von Prozessen mittels einfachen Semaphoren oder Spinlocks auftreten kann, ist das der Prioritäteninversion. Prioritäteninversion bezeichnet das Phänomen, das ein hoch priorisierter Task nicht zur Ausführung gelangt, wenn er auf die Freigabe einer von einem niedriger priorisierten Task akquirierte Resource wartet. Im Normalfall wäre nun die Wartezeit für den hoch priorisierten Task genau die Zeit, die der niedrig priorisierte Task zur Freigabe der Resource benötigt. Nun kann es aber sein das der niedrig priorisierte Task von einem Task mittlerer Priorität verdrängt wird, sodass die Wartezeit für den hoch priorisierten Task unbestimmt wird. Dieses Problem nennt man Prioritäteninversion. Die folgende Abbildung verdeutlicht das Problem anhand eines kleinen Diagramms. Ein schönes Beispiel einer solchen Problematik in der wahren Welt fernab jeglicher theoretischer Annahmen lässt sich in der Pathfinder Mission der NASA im July 1997 finden, in der das Landefahrzeug eine Reihe von zunächst unerklärlicher Soft-Resets erfuhr, die auf das Phänomen der Prioritäteninversion zurückzuführen waren. Der Pathfinder arbeitete mit einer zentral genutzten Resource (ein Bus) die zur Kommunikation von verschiedenen Komponenten des Fahrzeugs genutzt wurde. Die Resource wurde auf Basis eines Mutex zwischen einem niedrig priorisierten Task zur Sammlung metheorologischer Daten und einem hochpriorisierten Busmanagement-Task zur exklusiven Nutzung reserviert. Das System enthielt jedoch auch noch eine Reihe weiterer Tasks, die mit mittlerer Priorität liefen. Die korrekte Arbeit des Busmanagement-Task wurde durch eine Art Watchdog Timer überwacht, der im Fehlerfall die gesamte Landeeinheit Soft-Resetten sollte. Nun kam es in einigen Fällen dazu das der niedrig priorisierte Task von den mittel priorisierten Tasks verdrängt wurde während er den Mutex noch belegt hatte. Nun wurde der hochpriorisierte Task blockiert und nach einer Weile registrierte der Watchdogtimer das der Busmanagement Task seit geraumer Zeit nicht mehr ausgeführt wurde und forcierte in der Annahme 5 Bei der Sperrung von Interrupts wird die Reaktion auf externe Ereignisse unterbunden. Gerade dies ist jedoch in Echtzeitsystemen in den meisten Fällen eher nachteilig.

13 4 BASISDIENSTE VON ECHTZEITBETRIEBSSYSTEMEN 11 Abbildung 3: Exemplarische Timeline für Prioritäteninversion eines fatalen Fehlers ein Reset des Systems. Nach längerem Nachsinnen ließ sich der Fehler auf der Erde reproduzieren, sodass man durch einen Workaround 6 die Mission doch noch ohne weitere Probleme durchführen konnte. [5], [6], [8] Allgemein werden zur Umgehung der Prioritäteninversion zwei Ansätze verfolgt. Beim Priority Ceiling Verfahren wird jeder gemeinsam genutzten Resource eine Priorität zugeordnet, die der Priorität des höchst priorisierten jemals diese Resource verwendeten Prozess entspricht und temporär dem Benutzer zugewiesen wird, der diese Resource im Zugriff hat. Beim Priority Inheritance Verfahren weist man jedem Prozess, der eine Resource im Zugriff hat, auf die ein höher priorisierter Prozess wartet die Priorität des (höher priorisierten) wartenden Prozesses zu. Auf diese Weise vermeidet man das ein Prozess, der eine gemeinsam genutzte Resource im Zugriff hat, auf die ein höher priorisierter Task wartet, von einem Task mittlerer Priorität verdrängt wird.[7] Für die Task-Kommunikation bieten die meisten Echtzeitbetriebssysteme Message Queues, Shared Memory oder Pipes an. Hierin unterscheiden sich die von Echtzeitbetriebssystemen bereitgestellten Mechanismen nicht wesentlich von den Mechanismen, die allgemeine Betriebssysteme bereitstellen. In einigen Fällen, wie z.b. in VxWorks, die auch einen vollständige Netzwerksupport bieten, wird zudem noch die 6 Der Workaround basierte darauf, dass bei dem eingesetzten Echtzeitbetriebssystem VxWorks die Möglichkeit besteht, bei der Erzeugung eines Mutex oder Semaphor zu spezifizieren ob dieser Mutex mit Priority Inheritance arbeiten soll und der Lander im Nachhinein offensichtlich zur Nutzung dieses Features umprogrammiert werden konnte.

14 5 VXWORKS 12 Kommunikation über Sockets bereitgestellt. 4.4 Device I/O Supervision Die I/O Schnittstellen in Echtzeitbetriebssystemen stellen in der Regel Kommunikationsmöglichkeiten für eine Vielfalt an Geräten bereit. In der Regel umfassen Echtzeitbetriebssysteme unterstützung für Block- und Zeichenorientierte Geräte wie Festplatten, Standard Ein- und Ausgabe, periphere Interfaces über serielle und parallele Schnittstellen und mittlerweile auch relativ häufig ebenfalls für Netzwerkinterfaces. Die Kommunikation mit I/O Geräten in Echtzeitbetriebssystemen bedarf wie die Prozesssynchronisation ebenfalls einer besonderen Aufmerksamkeit seitens des Echtzeitprogrammierers, da die typischen I/O Operationen, insbesondere auf blockorientierten Geräten wie Festplatten, zu schwer vorhersagbaren zeitlichen Verzögerungen führen können. Im allgemeinen sollten I/O Operationen nur unter sorgfältiger Erwägung des Zeitverhaltens der I/O Operationen erfolgen, wenn möglich ausserhalb von Tasks die Echtzeitanforderungen haben. In einigen Fällen stellen Echtzeitbetriebssysteme auch Schnittstellen für asynchrones I/O bereit. Asynchrones I/O unterscheidet sich von synchronem I/O dadurch, dass der Aufrufende Task bei asynchronem I/O nicht blockiert wird, bis die I/O Operation beendet ist. Dies macht natürlich nicht in allen Fällen Sinn, z.b. nicht beim Einlesen von Dateien oder dem Lesen von Daten eines Netzerkinterfaces. 5 VxWorks Nachdem nun im ersten Teil der Arbeit ein Überblick über Besonderheiten die beim Design von Echtzeitbetriebssystemen und echtzeitfähigen Programmen beachtet werden müssen, werden ich nachfolgend exemplarisch auf das Echtzeitbetriebssystem VxWorks eingehen. VxWorks ist das zur Zeit am häufigsten in Produktivumgebungen eingesetzte Echtzeitbetriebssystem auf dem Markt und wird von dem Kalifornischen Unternehmen WindRiver seit 1981 als Produkt angeboten. Das System besteht aus dem Wind Echtzeitkernel und einer Anzahl an optionalen Erweiterungspaketen u.a. zur Unterstützung von erweiterten Speicherschutzmechanismen auf Basis der in den meisten Prozessoren Einsatz findenden MMU. Der Kernel bietet auch die nach IEEE b Spezifizierten POSIX realtime extension API an, die eine leichte Portierbarkeit von Applikationen von/auf andere Betriebssysteme ermöglicht. Die Entwicklung auf VxWorks erfolgt in der Regel Crossplatform, d.h. man entwickelt ein Echtzeitsystem auf Basis von VxWorks nicht direkt auf der Zielmaschine sonder nutzt eine Art Emulator, der auf diversen Hostplattformen (z.b. Unix, Solaris, Windows) läuft. Zur Unterstützung des Entwicklungsprozesses stellt WindRiver eine integrierte Entwicklungsumgebung namens Tornado in der Version 2.0 bereit. VxWorks unterstützt eine ganze Reihe an Prozessorarchitekturen wie Intel x86, Intel XScale (hat glaub ich auch einen ARM Core?), ARM, Intel i960, MIPS, PowerPC, SH, Sparc, Motorola MC680x0, uvm. Bestes und wohl auch prominentestes Beispiel für den (wenn auch nicht ganz reibungslosen) Einsatz ist sowohl die Pathfinder Mission, die im July 1997 von der NASA zur Exploration des MARS mit einer Landefähre unternommen wurde[5], als auch der jüngste Einsatz von VxWorks in der NASA/JPL Mission des Mars Exploration Rover im Januar 2004[15].

15 5 VXWORKS 13 Im weiteren werde ich kurz auf architektonische Merkmale des Kernels eingehen und die Eigenschaften des Kernels im Hinblick auf Scheduling, Speicherverwaltung, Synchronisation & Kommunikation und Device I/O beleuchten. 5.1 Scheduling Das Scheduling in VxWorks wird durch einen prioritätenbasierten präemtiven Schedulingalgorithmus vorgenommen. Die Prioritätenvergabe erfolgt statisch und bietet die Möglichkeiten 256 Prioritätsstufen an die Prozesse zu vergeben. Die Prioritäten laufen hierbei von 0 (höchste Priorität) bis 255 (niedrigste Priorität). Der Scheduler bietet die Möglichkeit für Tasks gleicher Priorität einen Round Robin Mode einzusetzen der eine gerechte Prozessorzuteilung an die konkurrierenden Prozesse einer Prioritätsstufe mit konfigurierbaren Zeitscheiben ermöglicht. Ohne die Aktivierung des Round Robin Scheduling findet keine Verdrängung eines Prozesses durch Prozesse gleicher Prioritätsstufe statt. Tasks laufen bei VxWorks gemeinsam mit dem Kernel immer auf der höchsten Privilegierungsstufe, und teilen sich mit diesem einen linearen Adressraum (s.u.). Trotz der statischen Prioritätenvergabe lassen sich die Prioritäten zur Laufzeit anpassen, was unter anderem vom System genutz wird Semaphoren mit dem Priority Inheritance Verfahren gegen Prioritäteninversion zu schützen(s.u).[10], [14] 5.2 Speicherverwaltung VxWorks arbeitet mit einem gemeinsammen linearen Adressraum für Kernel und Tasks, sodass ein Task (da er ja auch im Kernelmode läuft) vollen Zugriff auf den gesamten Speicherbereich hat. Diese Tatsache gibt den Task zwar zum einen ein höchstes Maß an Perforance und Vorhersagbarkeit bzgl. ihres Zeitverhaltens, birgt aber auch die Gefahr bei den immer komplexer werdenden Systemen durch Programmierfehler die Stabilität des Gesamtsystems zu gefährden. Aus diesem Grund gibt es für VxWorks einen grundlegenden und einen erweiterten 7 Support für MMUs, über den Speicherschutzmechanismen wie das Sperren von Speicherseiten für den Zugriff von anderen Tasks zu realisieren. Bdingt durch die Tatsache das kein Virtueller Speicher unterstützt wird, ist natürlich auch der Speicherbedarf von Anwendungen durch den physikalischen Speicherausbau begrenzt.[10], [12] Um dem Problemen für die Vorhersagbarkeit des Zeitverhaltens von Operationen durch Caching entgegenzuwirken unterstützt VxWorks das partielle und vollständige Deaktivieren des Cachings.[10] Die dynamische Allokation von Hauptspeicher geschieht nach (nicht einfach validierbaren) Aussagen in diversen Online Manuals durch einen einfache First-Fit Algorithmus, der eine externe Fragmentierung des Hauptspeichers verursacht. Aus diesem Grund gilt es als Best Practice die Anzahl der dynamischen Speicherallokationen minimal zu halten.[14] 7 Windriver bietet für den erweiterten MMU Support eine Erweiterung für VxWorks namens VxVMI als eigenständiges Produkt an, d.h. dieses ist wohl bei Bedarf explizit zu erwerben. Mittels VxVMI lassen sich dann u.a. automatisch alle Codeseiten im Hauptspeicher mit Schreibschutz versehen, Pufferüberläufe oder das Überschreiben der Interruptvektorentabelle durch Fehlerhafte NULL-Pointer Derefferenzierungen entdecken bzw. unterbinden.

16 5 VXWORKS Synchronisation & Kommunikation In VxWorks werden zur Synchronisation von Prozessen vor allem Semaphoren eingesetzt, die bei ihrer Erzeugung für die Verwendung des Priority Inheritance Verfahrens zum Schutz vor Prioritäteninversionen konfiguriert werden können. Weiterhin stellt der Kernel Mechanismen zur Temporären Deaktivierung des Schedulers oder der Interrupts bereit, um die Verdrängung des aktiven Prozess zu unterbinden. Hierbei ist jedoch besondere Vorsicht geboten, da die Sperrung von Interrupts sämtliche Reaktion auf externe Erreignisse unterbindet. Die Sperrung des Schedulers ermöglicht zwar weiterhin die Reaktion auf Interrupts, verhindert aber auch das solche Prozesse den Prozessor zugeteilt bekommen, deren Deadline herannaht, was durchaus zu einem verpassen der selbigen führen kann. Wie bereits in der allgemeinen Diskussion der Konzepte in Echtzeitbetriebssystemen angesprochen ist bei der Verwendung von Synchronisationmechanismen in Echtzeitsystemen eine besondere Vorsicht geboten, um die zeitlichen Beschränkungen, die einem solchen System auferliegen nicht zu gefährden.[10], [14] Die Kommunikation zwischen Tasks wird i.d.r. durch Message Queues, Pipes, Shared Memory oder Sockets durchgeführt. Der Primäre Kommunikationsmechanismus sind Message Queues, die jedoch ohne eine durch VxVM bereitgestellte Erweiterung nicht für den Einsatz in SMP Systemen vorgesehen sind. Message Queues sind unidirektional und können eine variable Anzahl an ebenso variabel Langen Messages enthalten. Aufgrund der Tatsache dass Message Queues unidirektional sind, erfordert die Vollduplex Kommunikation zweier Tasks auch die Aquisition zweier Message Queues. Das Schreiben und Lesen in bzw. aus der Message Queue kann optional in nicht blockierend geschehen, sodass der Versuch in eine volle Queue zu schreiben bzw. aus einer leeren Queue zu lesen einen Fehlercode zurückgibt anstatt den Task zu blockieren.[10] 5.4 Device I/O Supervision Das Device I/O System von VxWorks stellt eine Reihe von Funktionen zur Durchführung von I/O Aufgaben bereit. Zu den Mechanismen die VxWorks für die Arbeit mit Devices bereitstellt gehören Routinen für synchrones und asynchrones I/O. Der Unterschied zwischen synchronem und asynchronem I/O besteht darin, dass bei asynchronen I/O Operationen der Aufrufer nicht bis zur Beendigung der Operation seitens des Betriebssystems blockiert wird, und somit keine Verzögerungen in das System eingebracht werden. Wie leicht ersichtlich immer ist das Arbeiten mit asynchronem I/O natürlich nur in solchen Fällen Sinnvoll und Möglich, in denen ein Prozess nicht zwingend auf das Ergebnis einer I/O Operation warten muss, wie dies beim Einlesen von Dateien der Fall ist. Zur Operation auf Blockdevices stellt VxWorks eine Reihe von Dateisystemtreibern bereit und unterstützt unter anderem die Dateisysteme RT11, FAT12/16, ISO9660, sowie ein Raw Filesystem, dass das Vorhandene Blockdevice als eine große Datei behandelt und keine Strukturierung in Verzeichnisse unterstütz. Weiterhin stellt VxWorks eine umfangreiche Netzwerkimplementierung bereit, die Unterstützung für SLIP, PPP, TCP/IP und darauf aufbauende Dienste gibt. Für den Umgang mit den verschiedene Hardware Devices stellt VxWorks mit den sogenannten Board Support Packages eine umfangreiche Bibliothek von Geräte-Treibern bereit.

17 6 EPILOG 15 6 Epilog Wie bereits im Abstract erwähnt stellt die vorliegende Arbeit weder eine vollständige Diskussion der gesamten theoretischen Aspekte der Echtzeitprogrammierung und Konzeption von Echtzeitbetriebssystemen, noch eine detailierte Anleitung für die Programmierung von Systemen auf Basis von VxWorks dar, sondern soll eine kurze Einführung in die Thematik bieten. Wenn seitens des Lesers weiterführendes Interresse an diesem Thema besteht, steht es Ihm frei, sich Anhand der nachstehenden Bibliographie mit der Thematik der Echtzeitprogrammierung weiter zu befassen. Weiterhin übernimmt der Author keinerlei Haftung für Schäden die durch Verwendung der in dieser Arbeit dargelegten Informationen entstehen oder für die letztgültige Richtigkeit der gemachten Aussagen über interne Aspekte von VxWorks. Sollten bezüglich des Inhalts konstruktive Korrekturen seitens des Lesers beizusteuern sein, bin ich für eine Benachrichtigung mit einer Auflistung der Beanstandeten Dokumentbestandteile immer Dankbar. Weiterhin gwährt der Author dem Leser hiermit das Recht der Verwendung des vorliegenden Dokuments für private sowie wissenschaftliche und nicht kommerzielle Zwecke, sofern eine gültige Quellenangabe erfolgt. As previously mentioned the present work does neither claim to be a complete discussion of the entire and pretty comprehensive theoretical aspects of programming realtime systems or the design of realtime operating systems nor an detailed instructions to the vxworks based realtime system programming, but is intended to be a brief introduction to the topic of realtime systems. If there is supposed to be some interrest in further reading, one is free to get more comprehensive knowledge to the subject matter by consultating the bibliography given below. The author does even take any reasponsibility for any harm that might result of the use of information provided by the present document or for the completeness or final correctness of the information provided in regard to internal details to VxWorks. Are there supposed to be any corrections to be made on the part of the reader, the author is grateful for any correction proposals. Furtheron the author permits any private, scientific and non-commercial use of the present document, as long as this document is mentioned in the list of references.

18 LITERATUR 16 Literatur [1] Plagge, Frank. Ambrosia - Ein Echtzeit-Betriebssystem für Automoboilsteuergeräte <ftp://ftp-bvs.informatik.uni-oldenburg.de/pub/reports/diss plagge.ps>. [2] Tanenbaum, Andrew S. Moderne Betriebssysteme. 2te, erw. u. akt. Auflage München, Germany: Hanser Verlag, 1995 [3] Ghosh, Kaushik. Mukherjee, Bodhisattwa. Schwan, Karsten. A Survey of Real-Time Operating Systems - Draft. February 15, Georgia Institute of Technology. <http://citeseer.nj.nec.com/compress/0/papers/cs/3051/http:zszzszrtlab.kaist.ac.krzsz sikangzszsurveyzszgms94.ps.gz/ghosh94survey.ps>. [4] Sprunt, Brinkley Aperiodic Task Scheduling for Real-Time Systems. August Department of Electrical and Computer Engineering Carnegie Mellon University. <http://www.eg.bucknell.edu/ bsprunt/publications/phd thesis/aperiodic task scheduling thesis.pdf>. [5] Jones, Mike. What really happened on Mars. Sunday, December 07, :47 PM. Microsoft Research. <http://research.microsoft.com/ mbj/mars Pathfinder/Mars Pathfinder.html>. [6] Kalinsky, David. Barr, Michael. Introduction to Priority Inversion. August CMP Media, LLC. <http://www.time-rover.com/priority.html>. [7] Locke, Doug. Priority Inheritance: The Real Story. July 16, Linuxdevices.com. <http://www.linuxdevices.com/articles/at html>. [8] Priority Inversion and the Mars Pathfinder. Copyright c Time-Rover Corp. <http://www.time-rover.com/priority.html>. [9] WindRiver. VxWorks Reference Manual v5.4. Copyright Wind River Systems, Inc. <http://www.syrics.com/tiki-download file.php?fileid=11>(cached copy of original file). [10] WindRiver. VxWorks Programmer s Guide v5.4. Copyright Wind River Systems, Inc. <http://www.syrics.com/tiki-download file.php?fileid=12>(cached copy of original file). [11] WindRiver. VxWorks Network Programmer s Guide v5.4. Copyright Wind River Systems, Inc. <http://www.syrics.com/tiki-download file.php?fileid=10>(cached copy of original file). [12] WindRiver. Implementing Basic Memory Protection in VxWorks: A Best Practices Guide. Copyright Wind River Systems, Inc. <http://www.windriver.com/whitepapers/wp vxworks vxvmi.pdf>. [13] Dankwardt, Kevin. Basic concepts of real-time operating systems. November 18, <http://www.linuxdevices.com/articles/at html>. [14] Gordon, John. VxWorks Cookbook. April 15, Bluedonkey.org. <http://www.bluedonkey.org/cgi-bin/twiki/bin/view/books/vxworkscookbook>.

19 LITERATUR 17 [15] WindRiver. Wind River and NASA? Embedded Development for the Extreme Demands of Space Exploration. Copyright Wind River Systems, Inc. <http://www.windriver.com/marsrover/extreme-demands.html>.

Echtzeitfähige Ereignisgetriebene Scheduling-Strategien

Echtzeitfähige Ereignisgetriebene Scheduling-Strategien Friedrich-Alexander-Universität Erlangen-Nürnberg Ausgewählte Kapitel eingebetteter Systeme Echtzeitfähige Ereignisgetriebene Scheduling-Strategien Sven Kerschbaum 1. Einführung Bei einem eingebetteten

Mehr

Scheduling in Echtzeitbetriebssystemen. Prof. Dr. Margarita Esponda Freie Universität Berlin

Scheduling in Echtzeitbetriebssystemen. Prof. Dr. Margarita Esponda Freie Universität Berlin Scheduling in Echtzeitbetriebssystemen Prof. Dr. Margarita Esponda Freie Universität Berlin Echtzeitsysteme Korrekte Ergebnisse zum richtigen Zeitpunkt Hart Echtzeitsysteme Eine verspätete Antwort ist

Mehr

(Prüfungs-)Aufgaben zum Thema Scheduling

(Prüfungs-)Aufgaben zum Thema Scheduling (Prüfungs-)Aufgaben zum Thema Scheduling 1) Geben Sie die beiden wichtigsten Kriterien bei der Wahl der Größe des Quantums beim Round-Robin-Scheduling an. 2) In welchen Situationen und von welchen (Betriebssystem-)Routinen

Mehr

Systeme 1. Kapitel 5. Scheduling

Systeme 1. Kapitel 5. Scheduling Systeme 1 Kapitel 5 Scheduling Scheduling Verteilung und Zuweisung von begrenzten Ressourcen an konkurrierende Prozesse Beispiel: -> Zeitablaufsteuerung Zwei Prozesse zur gleichen Zeit rechenbereit auf

Mehr

CPU-Scheduling - Grundkonzepte

CPU-Scheduling - Grundkonzepte CPU-Scheduling - Grundkonzepte Sommersemester 2015 Seite 1 Gesamtüberblick 1. Einführung in Computersysteme 2. Entwicklung von Betriebssystemen 3. Architekturansätze 4. Interruptverarbeitung in Betriebssystemen

Mehr

Rechnernutzung in der Physik. Betriebssysteme

Rechnernutzung in der Physik. Betriebssysteme Rechnernutzung in der Physik Betriebssysteme 1 Betriebssysteme Anwendungsprogramme Betriebssystem Treiber BIOS Direkter Zugriff von Anwenderprogrammen auf Hardware nur in Ausnahmefällen sinnvoll / möglich:

Mehr

Systeme I: Betriebssysteme Kapitel 7 Scheduling. Maren Bennewitz

Systeme I: Betriebssysteme Kapitel 7 Scheduling. Maren Bennewitz Systeme I: Betriebssysteme Kapitel 7 Scheduling Maren Bennewitz Version 23.01.2013 1 Inhalt Vorlesung Aufbau einfacher Rechner Überblick: Aufgabe, Historische Entwicklung, unterschiedliche Arten von Betriebssystemen

Mehr

RTEMS- Echtzeitbetriebssystem

RTEMS- Echtzeitbetriebssystem RTEMS- Echtzeitbetriebssystem Name: Hussein Hammoud Matrikel- Nr.: 230768 Studiengang: Technische Informatik Fach: Projekt Eingebettete Kommunikation Technische Universität Berlin Sommersemester 2006 RTEMS-

Mehr

A Kompilieren des Kernels... 247. B Lineare Listen in Linux... 251. C Glossar... 257. Interessante WWW-Adressen... 277. Literaturverzeichnis...

A Kompilieren des Kernels... 247. B Lineare Listen in Linux... 251. C Glossar... 257. Interessante WWW-Adressen... 277. Literaturverzeichnis... 1 Einführung................................................ 1 1.1 Was ist ein Betriebssystem?............................... 1 1.1.1 Betriebssystemkern................................ 2 1.1.2 Systemmodule....................................

Mehr

POSIX Echtzeit: Kernel 2.6 und Preempt-RT

POSIX Echtzeit: Kernel 2.6 und Preempt-RT POSIX Echtzeit: Kernel 2.6 und Preempt-RT Slide 1 - http://www.pengutronix.de - 21.01.2007 Echtzeit-Systemplanung Wenn das zeitliche Verhalten spezifiziert ist, kann auch spezifiziert werden, welche Applikationsteile

Mehr

Betriebssysteme. 4y Springer. Eine kompakte Einführung mit Linux. Albrecht Achilles. Mit 31 Abbildungen

Betriebssysteme. 4y Springer. Eine kompakte Einführung mit Linux. Albrecht Achilles. Mit 31 Abbildungen Albrecht Achilles 2008 AGI-Information Management Consultants May be used for personal purporses only or by libraries associated to dandelon.com network. Betriebssysteme Eine kompakte Einführung mit Linux

Mehr

Ausarbeitung im Rahmen der PG Autolab zum Thema: OSEK 1 -OS. geschrieben von Oliver Botschkowski

Ausarbeitung im Rahmen der PG Autolab zum Thema: OSEK 1 -OS. geschrieben von Oliver Botschkowski Ausarbeitung im Rahmen der PG Autolab zum Thema: OSEK 1 -OS geschrieben von Oliver Botschkowski 1 Offene Systeme und deren Schnittstelle für die Elektronik im Kraftfahrzeug 1 Oliver Botschkowski - OSEK-OS

Mehr

2 Echtzeitbetriebssysteme

2 Echtzeitbetriebssysteme 35 2 Echtzeitbetriebssysteme In den letzten Jahren hat sich die Automobilindustrie zu einem der wesentlichen Anwender von Echtzeitbetriebssystemen für eingebettete Systeme entwickelt. Relativ zeitig erkannten

Mehr

Schedulingalgorithmen Rechenzeitverteilung auf Betriebssystemebene. Andi Drebes Fachbereich Informatik Universität Hamburg

Schedulingalgorithmen Rechenzeitverteilung auf Betriebssystemebene. Andi Drebes Fachbereich Informatik Universität Hamburg Schedulingalgorithmen Rechenzeitverteilung auf Betriebssystemebene Andi Drebes Fachbereich Informatik Universität Hamburg Gliederung Notwendigkeit des Schedulings Einführung: Begriff des Multitaskings

Mehr

Real Time Operating Systems (RTOS) = Echtzeit-Betriebssysteme. Eine Einführung. Klaus Kusche, Okt. 2011

Real Time Operating Systems (RTOS) = Echtzeit-Betriebssysteme. Eine Einführung. Klaus Kusche, Okt. 2011 Real Time Operating Systems (RTOS) = Echtzeit-Betriebssysteme Eine Einführung Klaus Kusche, Okt. 2011 Ziele des Vortrags Überblick über das Thema Praktisches Verständnis von Anforderungen Problembereichen

Mehr

Echtzeitbetriebssysteme

Echtzeitbetriebssysteme Echtzeitbetriebssysteme QNX 409 Geschichte: Einführung 1980 entwickeln Gordon Bell und Dan Dodge ein eigenes Echtzeitbetriebssystem mit Mikrokernel. QNX orientiert sich nicht an Desktopsystemen und breitet

Mehr

Vorbereitung zur Prüfung Echtzeitbetriebssysteme

Vorbereitung zur Prüfung Echtzeitbetriebssysteme Vorbereitung zur Prüfung Echtzeitbetriebssysteme Zugelassene Hilfsmittel: Taschenrechner Bitte verwenden Sie keinen roten Farbstift! 1. Echtzeitbetriebssysteme - Allgemein (15 Punkte) 1.1. Warum setzen

Mehr

Übung zu Grundlagen der Betriebssysteme. 7. Übung 27.11.2012

Übung zu Grundlagen der Betriebssysteme. 7. Übung 27.11.2012 Übung zu Grundlagen der Betriebssysteme 7. Übung 27.11.2012 Threads Thread (Faden des (Kontrollflusses)): ist ein sequentieller Abarbeitungsablauf (Kontrollfluss) innerhalb eines Prozesses. Umfasst ein

Mehr

B.4. B.4 Betriebssysteme. 2002 Prof. Dr. Rainer Manthey Informatik II 1

B.4. B.4 Betriebssysteme. 2002 Prof. Dr. Rainer Manthey Informatik II 1 Betriebssysteme Betriebssysteme 2002 Prof. Dr. Rainer Manthey Informatik II 1 Bekannte Betriebssysteme Windows 2000 CMS UNIX MS-DOS OS/2 VM/SP BS 2000 MVS Windows NT Solaris Linux 2002 Prof. Dr. Rainer

Mehr

Adeos & Xenomai. Echtzeitbetriebssysteme / SS09. Alexander Behringer. Georg-Simon-Ohm-Hochschule Nürnberg. 24. Juni 2009

Adeos & Xenomai. Echtzeitbetriebssysteme / SS09. Alexander Behringer. Georg-Simon-Ohm-Hochschule Nürnberg. 24. Juni 2009 Adeos & Xenomai Echtzeitbetriebssysteme / SS09 Alexander Behringer Georg-Simon-Ohm-Hochschule Nürnberg 24. Juni 2009 Alexander Behringer (GSO Nbg) Adeos & Xenomai 24. Juni 2009 1 / 39 Übersicht Einführung

Mehr

*DE102007042999A120090312*

*DE102007042999A120090312* *DE102007042999A120090312* (19) Bundesrepublik Deutschland Deutsches Patent- und Markenamt (10) DE 10 2007 042 999 A1 2009.03.12 (12) Offenlegungsschrift (21) Aktenzeichen: 10 2007 042 999.3 (22) Anmeldetag:

Mehr

Task A Zündung. Task B Einspritzung. Task C Erfassung Pedalwert. J. Schäuffele, Th. Zurawka: Automotive Software Engineering, Vieweg, 2003

Task A Zündung. Task B Einspritzung. Task C Erfassung Pedalwert. J. Schäuffele, Th. Zurawka: Automotive Software Engineering, Vieweg, 2003 Task! evt. parallel zu bearbeitende Ausführungseinheit! Beispiel: Task A Zündung Task B Einspritzung Task C Erfassung Pedalwert Zeit t J. Schäuffele, Th. Zurawka:, Vieweg, 2003 Echtzeitbetriebssysteme

Mehr

Embedded Linux. Embedded Linux. Daniel Buchheim daniel.buchheim@informatik.tu-cottbus.de. Seminar "Eingebettete drahtlose Systeme"

Embedded Linux. Embedded Linux. Daniel Buchheim daniel.buchheim@informatik.tu-cottbus.de. Seminar Eingebettete drahtlose Systeme Daniel Buchheim daniel.buchheim@informatik.tu-cottbus.de Embedded Linux 30.01.2009 Daniel Buchheim Inhalt: Was ist Embedded Linux? Hardwareunterstützung in Eingebetteten Systemen Open Source Aspekte Aufbau

Mehr

Echtzeit mit Linux. Erweiterungen und deren Anwendung. Martin Krohn. 2. Februar 2006

Echtzeit mit Linux. Erweiterungen und deren Anwendung. Martin Krohn. 2. Februar 2006 Erweiterungen und deren Anwendung 2. Februar 2006 1 Einleitung Anwendungsgebiete 2 Linux als Echtzeitbetriebssystem Eignung von Linux 3 Erweiterungen für Linux RT-Linux RTAI- Real-Time Application Interface

Mehr

Sowohl RTX64 als auch RTX bieten harten Echtzeitdeterminismus und symmetrische Multiprocessing- Fähigkeiten (SMP).

Sowohl RTX64 als auch RTX bieten harten Echtzeitdeterminismus und symmetrische Multiprocessing- Fähigkeiten (SMP). Produktbeschreibung Februar 2014 RTX RTOS-Plattform Mit der RTX-Echtzeitsoftware von IntervalZero wird aus Microsoft Windows ein Echtzeitbetriebssystem (RTOS). RTX64 von IntervalZero unterstützt 64-Bit-Betriebssysteme

Mehr

Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008

Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008 Name: Matrikel-Nr: Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008 Bitte schreiben Sie leserlich und antworten Sie kurz und präzise. 1. Zeichnen Sie das Schichten-Modell eines Computersystems und markieren

Mehr

Echtzeitanforderung und Linux

Echtzeitanforderung und Linux Echtzeitanforderung und Linux Slide 1 - http://www.pengutronix.de - 21.01.2007 Definition Harte Echtzeit I Was zeichnet ein Echtzeitsystem aus? Zeitverhalten ist Teil der System-Spezifikation! Bei Embedded-Systemen

Mehr

Betriebssystembau (BSB)

Betriebssystembau (BSB) Betriebssystembau (BSB) 6. Übung http://ess.cs.tu-.de/de/teaching/ws2013/bsb/ Olaf Spinczyk olaf.spinczyk@tu-.de http://ess.cs.tu-.de/~os AG Eingebettete System Informatik 12, TU Dortmund Agenda Vorstellung

Mehr

Scheduling. Prozess-Ablaufplanung. Prof. Dr. Margarita Esponda Freie Universität Berlin WS 2011/2012

Scheduling. Prozess-Ablaufplanung. Prof. Dr. Margarita Esponda Freie Universität Berlin WS 2011/2012 Scheduling Prozess-Ablaufplanung Prof. Dr. Margarita Esponda Freie Universität Berlin WS 2011/2012 Scheduler Der Scheduler ist ein besonders wichtiges Programmteil jedes Betriebssystems. Prozesse P 1 P

Mehr

Performance Messungen von FreeRTOS und

Performance Messungen von FreeRTOS und Performance Messungen von FreeRTOS und µc/os-iii auf ARM-Architekturen Tim Wacher (wht4@bfh.ch) Master of Science in Engineering MRU Production Technology 16. August 2011/ CH-3400 Burgdorf Outline 1 Ziel

Mehr

Projekt für Systemprogrammierung WS 06/07

Projekt für Systemprogrammierung WS 06/07 Dienstag 30.01.2007 Projekt für Systemprogrammierung WS 06/07 Von: Hassan Bellamin E-Mail: h_bellamin@web.de Gliederung: 1. Geschichte und Definition 2. Was ist Virtualisierung? 3. Welche Virtualisierungssoftware

Mehr

5) Realzeitscheduling

5) Realzeitscheduling Inhalte Anforderungen Klassifizierungen Verschiedene Verfahren: FIFO, Round Robin, Least Laxity, EDF, fixed/dyn. Prio. Beispiele und Aufgaben Seite 1 Motivation Gegeben: Ein Einprozessorsystem, das Multiprogrammierung

Mehr

Betriebssysteme (BTS)

Betriebssysteme (BTS) 9.Vorlesung Betriebssysteme (BTS) Christian Baun cray@unix-ag.uni-kl.de Hochschule Mannheim Fakultät für Informatik Institut für Betriebssysteme 10.5.2007 Exkursion Die Exkursion wird am Freitag, den 18.5.2007

Mehr

Betriebssysteme I WS 2013/2014. Betriebssysteme / verteilte Systeme rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404

Betriebssysteme I WS 2013/2014. Betriebssysteme / verteilte Systeme rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404 Betriebssysteme I WS 2013/2014 Betriebssysteme / verteilte Systeme rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404 Stand: 16. Januar 2014 Betriebssysteme / verteilte Systeme Betriebssysteme

Mehr

Zeit- und ereignisgesteuerte Echtzeitsysteme

Zeit- und ereignisgesteuerte Echtzeitsysteme Zeit- und ereignisgesteuerte Echtzeitsysteme Stephan Braun Stephan.Braun.Hagen@t-online.de PG Seminarwochenende 21.-23. Oktober 2007 1 Überblick Echtzeitsystemmodell Einführung Ereignis- und zeitgesteuerte

Mehr

Slothful Linux: An Efficient Hybrid Real-Time System by Hardware-Based Task Dispatching. Rainer Müller

Slothful Linux: An Efficient Hybrid Real-Time System by Hardware-Based Task Dispatching. Rainer Müller Slothful Linux: An Efficient Hybrid Real-Time System by Hardware-Based Task Dispatching Rainer Müller 21. November 2013 Spezialisierung von Betriebssystemen Vielzweckbetriebssysteme (General Purpose OS,

Mehr

20 Eingebettete Software

20 Eingebettete Software 20 Eingebettete Software 20.0 Einführung Lernziele Echtzeitsysteme Eingebettete Systeme 20.1 Entwurf eingebetteter Systeme Modellierung von Echtzeitsystemen Programmierung von Echtzeitsystemen 20.2 Architekturmuster

Mehr

White Paper. Embedded Treiberframework. Einführung

White Paper. Embedded Treiberframework. Einführung Embedded Treiberframework Einführung White Paper Dieses White Paper beschreibt die Architektur einer Laufzeitumgebung für Gerätetreiber im embedded Umfeld. Dieses Treiberframework ist dabei auf jede embedded

Mehr

Embedded OS für ARM Cortex Microcontroller

Embedded OS für ARM Cortex Microcontroller Embedded OS für ARM Cortex Microcontroller RTOS Design, Timinganalyse und Test mit Core Simulation und Hardware Debugger Entscheidende Fragen für oder gegen RTOS Lohnt sich der Einsatz eines RTOS auch

Mehr

User Level Device Driver am Beispiel von TCP

User Level Device Driver am Beispiel von TCP September 17, 2004 Einleitung Motivation für Userlevel Device Driver Probleme von Userlevel Device Driver Motivation für Userlevel Device Driver Modularität, leichterer Austausch/Erneuerung von Komponenten.

Mehr

Technische Informatik II

Technische Informatik II Institut für Technische Informatik und Kommunikationsnetze Technische Informatik II Übung 1: Prozesse und Threads Aufgabe 1: Prozesse und Threads a) Wie verhält sich eine Applikation die aus mehreren Prozessen

Mehr

Grundkurs Betriebssysteme

Grundkurs Betriebssysteme Grundkurs Betriebssysteme Architekturen, Betriebsmittelverwaltung, Synchronisation, Prozesskommunikation von Peter Mandl 3., akt. und erw. Aufl. 2013 Springer Vieweg Wiesbaden 2012 Verlag C.H. Beck im

Mehr

VxWorks - Aufbau und Programmierung

VxWorks - Aufbau und Programmierung VxWorks - Aufbau und Programmierung Dominik Meyer AG Echtzeitsysteme / Eingebettete Systeme Institut für Informatik Christian-Albrechts-Universität zu Kiel Zusammenfassung

Mehr

Einführung in die Echtzeitbetriebssysteme

Einführung in die Echtzeitbetriebssysteme Einführung in die Echtzeitbetriebssysteme Hauptseminararbeit in dem Studiengang B.Sc. Informatik von Maximilian von Piechowski Technische Hochschule Mittelhessen Inhaltsverzeichnis 1 Was versteht man unter

Mehr

Echtzeitbetriebssysteme (am Beispiel QNX) Dr. Stefan Enderle HS Esslingen

Echtzeitbetriebssysteme (am Beispiel QNX) Dr. Stefan Enderle HS Esslingen Echtzeitbetriebssysteme (am Beispiel QNX) Dr. Stefan Enderle HS Esslingen 1. Einführung 1.1 Embedded Systeme Embedded Systeme besitzen / benutzen einen Mikrocontroller Embedded Systeme erfüllen meist eine

Mehr

Dämon-Prozesse ( deamon )

Dämon-Prozesse ( deamon ) Prozesse unter UNIX - Prozessarten Interaktive Prozesse Shell-Prozesse arbeiten mit stdin ( Tastatur ) und stdout ( Bildschirm ) Dämon-Prozesse ( deamon ) arbeiten im Hintergrund ohne stdin und stdout

Mehr

Prozesse und Scheduling

Prozesse und Scheduling Betriebssysteme für Wirtschaftsinformatiker SS04 KLAUSUR Vorbereitung mit Lösungen / Blatt 1 Prozesse und Scheduling Aufgabe 1 : Scheduling Gegeben seien die folgenden Prozesse und die Längen des jeweiligen

Mehr

^ Springer Vi eweg. Grundkurs Betriebssysteme. Synchronisation, Prozesskommunikation, Virtualisierung. Architekturen, Betriebsmittelverwaltung,

^ Springer Vi eweg. Grundkurs Betriebssysteme. Synchronisation, Prozesskommunikation, Virtualisierung. Architekturen, Betriebsmittelverwaltung, Peter Mandl Grundkurs Betriebssysteme Architekturen, Betriebsmittelverwaltung, Synchronisation, Prozesskommunikation, Virtualisierung 4. Auflage ^ Springer Vi eweg 1 Einführung 1 1.1 Computersysteme 1

Mehr

Quantitative Methoden. Betriebssysteme

Quantitative Methoden. Betriebssysteme Quantitative Methoden Betriebssysteme Problem und Gegenstand Problem Erfüllen von QoS-Anforderungen mit zeit- bzw. größenbeschränkten Ressourcen Gegenstand Scheduling basierend auf deterministischen Modellen

Mehr

Inhaltsverzeichnis XII

Inhaltsverzeichnis XII 1 Einführung... 1 1.1 Computersysteme... 1 1.1.1 Einführung... 2 1.1.2 Aufgabe von Betriebssystemen... 3 1.1.3 Grundlegende Hardwaremodelle... 3 1.1.4 CPU-Registersatz... 7 1.1.5 Multicore-Prozessoren

Mehr

Kapitel 2 Betriebssysteme. Für den Rechnerbetrieb notwendige Basissoftware

Kapitel 2 Betriebssysteme. Für den Rechnerbetrieb notwendige Basissoftware Für den Rechnerbetrieb notwendige Basissoftware 1 1. Einleitung 2. Prozessverwaltung 3. Dateiverwaltung 2 1. Einleitung Was ist ein Betriebssystem? Wikipedia: Ein Betriebssystem (engl. Operating System

Mehr

Military Air Systems

Military Air Systems Trennung von Applikationen unterschiedlicher Kritikalität in der Luftfahrt durch Software en am Beispiel des Real-time Operating Systems PikeOS Dr. Bert Feldmann DGLR Workshop Garching, 09.10.2007 Seite

Mehr

LINUX und Echtzeit. Eine Übersicht prinzipieller Lösungsansätze. Your partner for industrial, embedded Linux

LINUX und Echtzeit. Eine Übersicht prinzipieller Lösungsansätze. Your partner for industrial, embedded Linux LINUX und Echtzeit Eine Übersicht prinzipieller Lösungsansätze Controlling a laser with Linux is crazy, but everyone in this room is crazy in his own way. So if you want to use Linux to control an industrial

Mehr

Begriff: Scheduling Planung, Schedule Plan. Verplanung der CPU-Zeit an die Threads (bzw. Prozesse)

Begriff: Scheduling Planung, Schedule Plan. Verplanung der CPU-Zeit an die Threads (bzw. Prozesse) 5 CPU-Scheduling Im folgenden wird von Threads gesprochen. Bei Systemen, die keine Threads unterstützen, ist der einzige "Thread" eines Prozesses gemeint. Früher wurde dieser Thread synonym mit dem Begriff

Mehr

Inhaltsverzeichnis. 2.4 Thread-Systeme. 2.1 Was ist ein Prozess? 2.2 Scheduling. 2.3 Interprozesskommunikation

Inhaltsverzeichnis. 2.4 Thread-Systeme. 2.1 Was ist ein Prozess? 2.2 Scheduling. 2.3 Interprozesskommunikation Inhaltsverzeichnis Systemprogrammierung - Kapitel 2 Prozessverwaltung 1/21 2.1 Was ist ein Prozess? Definition Prozesszustände Prozesskontrollblöcke 2.4 Thread-Systeme Sinn und Zweck Thread-Arten Thread-Management

Mehr

Dipl.-Inf. J. Richling Wintersemester 2003/2004. Weiche Echtzeit

Dipl.-Inf. J. Richling Wintersemester 2003/2004. Weiche Echtzeit Dipl.-Inf. J. Richling Wintersemester 2003/2004 Weiche Echtzeit Wiederholung - Resultat/Wert-Funktion "harte" Echtzeit Wert Zeit Wert Zeit Wert Deadline Zeit "weiche" Echtzeit Wert Deadline Zeit Deadline

Mehr

Grundlagen der Rechnerarchitektur

Grundlagen der Rechnerarchitektur Grundlagen der Rechnerarchitektur Ein und Ausgabe Übersicht Grundbegriffe Hard Disks und Flash RAM Zugriff auf IO Geräte RAID Systeme SS 2012 Grundlagen der Rechnerarchitektur Ein und Ausgabe 2 Grundbegriffe

Mehr

Virtualisierung im Echtzeitbereich. Andreas Hollmann FH Landshut EADS Military Air Systems

Virtualisierung im Echtzeitbereich. Andreas Hollmann FH Landshut EADS Military Air Systems Virtualisierung im Echtzeitbereich Andreas Hollmann FH Landshut EADS Military Air Systems 2 Überblick Hintergrund und Motivation Vorstellung von Lösungsansätzen Auswahl und Evaluierung Einschränkungen

Mehr

Echtzeitverhalten. Einleitung. Was bedeutet Echtzeit? Beispiele. Andere Faktoren. Echtzeitsystem und Echtzeitkomponenten

Echtzeitverhalten. Einleitung. Was bedeutet Echtzeit? Beispiele. Andere Faktoren. Echtzeitsystem und Echtzeitkomponenten Echtzeitverhalten Einleitung Was bedeutet Echtzeit? Die Interaktion mit der Außenwelt stellt in einem System den Zeitbezug her. Normalerweise will man ein korrektes Ergebnis so schnell wie möglich bekommen.

Mehr

Echtzeit-Betriebssysteme und -Bussysteme

Echtzeit-Betriebssysteme und -Bussysteme Echtzeit-Betriebssysteme und -Bussysteme Seminar im Wintersemester 2006/07 Steffen H. Prochnow Reinhard von Hanxleden Echtzeitsysteme und Eingebettete Systeme Institut für Informatik und Praktische Mathematik

Mehr

5.6 Realzeitarchitektur auf Multicore-Basis

5.6 Realzeitarchitektur auf Multicore-Basis 5.6 Realzeitarchitektur auf Multicore-Basis 63 VxWorks Vertreter eines klassischen Realzeitbetriebssystems mit einer starken Marktdurchdringung ist VxWorks der Firma Wind River. Ursprünglich als Realzeitbetriebssystem

Mehr

EEX Kundeninformation 2007-09-05

EEX Kundeninformation 2007-09-05 EEX Eurex Release 10.0: Dokumentation Windows Server 2003 auf Workstations; Windows Server 2003 Service Pack 2: Information bezüglich Support Sehr geehrte Handelsteilnehmer, Im Rahmen von Eurex Release

Mehr

Die L4-Mikrokern. Mikrokern-Familie. Hauptseminar Ansätze für Betriebssysteme der Zukunft. Michael Steil. Michael Steil 18.04.2002

Die L4-Mikrokern. Mikrokern-Familie. Hauptseminar Ansätze für Betriebssysteme der Zukunft. Michael Steil. Michael Steil 18.04.2002 Die L4-Mikrokern Mikrokern-Familie Hauptseminar Ansätze für Betriebssysteme der Zukunft 18.04.2002 Folie 1 Aufbau des Vortrags 1. Mikrokerne: Idee und Geschichte 2. L4: ein schneller Mikrokern 3. L4Linux:

Mehr

Embedded-Linux-Seminare. Linux als Betriebssystem

Embedded-Linux-Seminare. Linux als Betriebssystem Embedded-Linux-Seminare Linux als Betriebssystem http://www.embedded-linux-seminare.de Diplom-Physiker Peter Börner Spandauer Weg 4 37085 Göttingen Tel.: 0551-7703465 Mail: info@embedded-linux-seminare.de

Mehr

Übersicht der 10 relevanten Realtime Betriebssysteme. Urs Böhm/31.August 2010

Übersicht der 10 relevanten Realtime Betriebssysteme. Urs Böhm/31.August 2010 Übersicht der 10 relevanten Realtime Betriebssysteme Urs Böhm/31.August 2010 Übersicht Wann ist ein Betriebssystem Echtzeitfähig -und wann nicht? Warum gibt es so viele RTOS? Verschiedene Einsatzgebiete

Mehr

Prozessinformationsverarbeitung. Echtzeitbetriebssysteme. Professur für Prozessleittechnik Wintersemester 2009/2010

Prozessinformationsverarbeitung. Echtzeitbetriebssysteme. Professur für Prozessleittechnik Wintersemester 2009/2010 Fakultät Elektrotechnik und Informationstechnik, Professur für Prozessleittechnik Prozessinformationsverarbeitung (PIV) Echtzeitbetriebssysteme Professur für Prozessleittechnik Wintersemester 2009/2010

Mehr

Fragenkatalog Echtzeitsysteme/Realzeitsysteme. Jürgen Quade

Fragenkatalog Echtzeitsysteme/Realzeitsysteme. Jürgen Quade Fragenkatalog Echtzeitsysteme/Realzeitsysteme Jürgen Quade Fragenkatalog Echtzeitsysteme/Realzeitsysteme von Jürgen Quade V1.4, 31. Januar 2008 Versionsgeschichte Version $Revision: 1.1 $ $Date: 2005/01/25

Mehr

Redwood Cronacle und REALTECH theguard! Integration

Redwood Cronacle und REALTECH theguard! Integration Redwood Cronacle und REALTECH theguard! Integration Einleitung Redwood Software und REALTECH haben gemeinsam eine Lösung entwickelt, die die Systemverfügbarkeit von SAP und mysap Systemen signifikant erhöht.

Mehr

Die Linux Kernel Virtual Machine - Wo steht der Linux Hypervisor? 2. März 2008

Die Linux Kernel Virtual Machine - Wo steht der Linux Hypervisor? 2. März 2008 Die Linux Kernel Virtual Machine - Wo steht der Linux Hypervisor? 2. März 2008 Jörg Rödel Virtualization - Whats out there? Virtualisierung hat bereits längere Geschichte auf x86 Startete mit VMware Setzte

Mehr

BESCHAFFUNG UND LIZENZIERUNG MIT DEM VEREINFACHTEN ORACLE LIZENZMODELL

BESCHAFFUNG UND LIZENZIERUNG MIT DEM VEREINFACHTEN ORACLE LIZENZMODELL BESCHAFFUNG UND LIZENZIERUNG MIT DEM VEREINFACHTEN ORACLE LIZENZMODELL DIESER LEITFADEN IST FÜR FOLGENDE ORACLE SOFTWARE PROGRAMME GÜLTIG Oracle Database 11g Standard Edition One Die passende Datenbank-Lösung

Mehr

Dynamische Skalierbarkeit

Dynamische Skalierbarkeit Alexander Eichhorn Verteilte Systeme und Betriebssysteme Technische Universität Ilmenau Frühjahrstreffen der GI Fachgruppe Betriebssysteme 30. Juni 2005 Koblenz Vortragsüberblick Teil 1 Teil 2 Teil 3 Begriffsbestimmungen

Mehr

Rechnerarchitektur und Betriebssysteme (CS201): Semaphor, Monitor, Deadlocks, Re-Entrance

Rechnerarchitektur und Betriebssysteme (CS201): Semaphor, Monitor, Deadlocks, Re-Entrance Rechnerarchitektur und Betriebssysteme (CS201): Semaphor, Monitor, Deadlocks, Re-Entrance 5. November 2013 Prof. Dr. Christian Tschudin Departement Mathematik und Informatik, Universität Basel Repetition

Mehr

Welche der folgenden Aussagen gelten? a) Im allgemeinen gilt: ein Deadlock tritt auf gdw. der Resource-Allocation Graph einen Zykel

Welche der folgenden Aussagen gelten? a) Im allgemeinen gilt: ein Deadlock tritt auf gdw. der Resource-Allocation Graph einen Zykel Aufgabe 1 (5 Punkte) (Multiple Choice) Beantworten Sie folgende Fragen durch Ankreuzen der richtigen Antwort. Für jede falsche Antwort wird ein Punkt abgezogen (es werden minimal 0 Punkte vergeben). Welche

Mehr

Programme werden durch den Ablauf eines oder mehrerer Prozesse (engl.: process, task) von einem Rechner abgearbeitet.

Programme werden durch den Ablauf eines oder mehrerer Prozesse (engl.: process, task) von einem Rechner abgearbeitet. Prozessverwaltung Prozesse Programme werden durch den Ablauf eines oder mehrerer Prozesse (engl.: process, task) von einem Rechner abgearbeitet. Prozesse sind Abfolgen von Aktionen, die unter Kontrolle

Mehr

opensm2 Enterprise Performance Monitoring Copyright 2010 FUJITSU TECHNOLOGY SOLUTIONS

opensm2 Enterprise Performance Monitoring Copyright 2010 FUJITSU TECHNOLOGY SOLUTIONS opensm2 Enterprise Performance Monitoring Copyright 2010 FUJITSU TECHNOLOGY SOLUTIONS Agenda opensm2 Überblick INSPECTOR ANALYZER 1 opensm2 bietet eine einheitliche Lösung für das unternehmensweite Performance

Mehr

OSEKtime - Time-Triggered OSEK/OS

OSEKtime - Time-Triggered OSEK/OS OSEKtime - Time-Triggered OSEK/OS Gregor Kaleta gregor.kaleta@udo.edu PG Seminarwochenende 21.-23. Oktober 2007 1 Überblick Einleitung OSEKtime Task-Zustandsmodell, Scheduling-Verfahren Interrupt-Verarbeitung

Mehr

Embedded Software Engeneering mit dem Raspberry Pi

Embedded Software Engeneering mit dem Raspberry Pi Embedded Software Engeneering mit dem Raspberry Pi Übersicht Rasperry Pi Betriebssystem Hardware ARM Μ-Controller vs. Μ-Prozessor vs. SoC Embedded Software Engineering vs. Software Engineering Fazit Raspberry

Mehr

Universität Koblenz-Landau. Fachbereich 4: Informatik. Prof. Dr. Dieter Zöbel. Seminararbeit OSEK/VDX. Seminar Echtzeitsysteme.

Universität Koblenz-Landau. Fachbereich 4: Informatik. Prof. Dr. Dieter Zöbel. Seminararbeit OSEK/VDX. Seminar Echtzeitsysteme. Universität Koblenz-Landau Fachbereich 4: Informatik Prof. Dr. Dieter Zöbel Seminararbeit Seminar Echtzeitsysteme Thema 4 Wintersemester 1999/2000 Von Thorsten Schaub (thorsten@schaub-home.de) 17.12.1999

Mehr

Oracle VM Support und Lizensierung. best Open Systems Day April 2010. Unterföhring. Marco Kühn best Systeme GmbH marco.kuehn@best.

Oracle VM Support und Lizensierung. best Open Systems Day April 2010. Unterföhring. Marco Kühn best Systeme GmbH marco.kuehn@best. Oracle VM Support und Lizensierung best Open Systems Day April 2010 Unterföhring Marco Kühn best Systeme GmbH marco.kuehn@best.de Agenda Oracle VM 2.2 Oracle VM 3.0 Oracle DB in virtualisierten Umgebungen

Mehr

VMware. Rainer Sennwitz.

VMware. Rainer Sennwitz. <Rainer.Sennwitz@andariel.informatik.uni-erlangen.de> VMware Rainer Sennwitz Lehrstuhl für Informatik IV Friedrich-Alexander-Universität Erlangen-Nürnberg 4. Juli 2007 Rainer Sennwitz VMware Inhalt Inhalt

Mehr

8. Vorlesung Betriebssysteme

8. Vorlesung Betriebssysteme Dr. Christian Baun 8. Vorlesung Betriebssysteme Hochschule Mannheim WS1213 1/69 8. Vorlesung Betriebssysteme Dr. Christian Baun Hochschule Mannheim Fakultät für Informatik wolkenrechnen@gmail.com Dr. Christian

Mehr

Für die Software-Entwicklung von

Für die Software-Entwicklung von Betriebssysteme Embedded Design Für die Software-Entwicklung von Embedded- und Echtzeit-Systemen stehen unterschiedliche Arten von Task-Schedulern zur Auswahl. Sie reichen von einfacher, periodischer Ausführung

Mehr

Betriebssysteme Kap A: Grundlagen

Betriebssysteme Kap A: Grundlagen Betriebssysteme Kap A: Grundlagen 1 Betriebssystem Definition DIN 44300 Die Programme eines digitalen Rechensystems, die zusammen mit den Eigenschaften dieser Rechenanlage die Basis der möglichen Betriebsarten

Mehr

Betriebssysteme WS 2012/13 Peter Klingebiel, DVZ. Zusammenfassung Kapitel 4 - Datenträger/Dateiverwaltung

Betriebssysteme WS 2012/13 Peter Klingebiel, DVZ. Zusammenfassung Kapitel 4 - Datenträger/Dateiverwaltung Betriebssysteme WS 2012/13 Peter Klingebiel, DVZ Zusammenfassung Kapitel 4 - Datenträger/Dateiverwaltung Zusammenfassung Kapitel 4 Dateiverwaltung 1 Datei logisch zusammengehörende Daten i.d.r. permanent

Mehr

BESCHAFFUNG UND LIZENZIERUNG

BESCHAFFUNG UND LIZENZIERUNG BESCHAFFUNG UND LIZENZIERUNG MIT DEM VEREINFACHTEN ORACLE LIZENZMODELL DIESER LEITFADEN IST FÜR FOLGENDE ORACLE SOFTWARE PROGRAMME GÜLTIG: ORACLE LIZENZIERUNG Fragen Sie uns! Oracle Database 12c Standard

Mehr

Einblick in die VMware Infrastruktur

Einblick in die VMware Infrastruktur Einblick in die VMware Infrastruktur Rainer Sennwitz Lehrstuhl für Informatik IV Friedrich-Alexander-Universität Erlangen-Nürnberg 4. Juli 2007 Rainer

Mehr

5 CPU Scheduling. FH Regensburg BT/SS04 Betriebssysteme Wirtschaftsinformatik. 5.1 Grundlagen - 54 - 5.1.1 CPU Burst / I/O Burst

5 CPU Scheduling. FH Regensburg BT/SS04 Betriebssysteme Wirtschaftsinformatik. 5.1 Grundlagen - 54 - 5.1.1 CPU Burst / I/O Burst FH Regensburg BT/SS04 5 CPU Scheduling 5.1 Grundlagen 5.1.1 CPU Burst / I/O Burst Beobachtung: Programme rechnen typischerweise etwas, dann tätigen sie Ein/Ausgabe: CPU-Burst: das Programm rechnet eine

Mehr

OS/2 System- und Netzwerkprogrammierung

OS/2 System- und Netzwerkprogrammierung Hans Joachim Müschenborn OS/2 System- und Netzwerkprogrammierung Multitasking Interprozeßkommunikation Multithreading DB/2-lntegration tewi Verlag sverzeichnis / I Inhaltsverzeichnis 5 In eigener Sache

Mehr

William Stallings. Betriebssysteme. Prinzipien und Umsetzung. 4., überarbeitete Auflage. Pearson Studium

William Stallings. Betriebssysteme. Prinzipien und Umsetzung. 4., überarbeitete Auflage. Pearson Studium William Stallings Betriebssysteme Prinzipien und Umsetzung 4., überarbeitete Auflage Pearson Studium ein Imprint der Pearson Education Deutschland GmbH Inhaltsverzeichnis Vorwort Leitfaden für den Leser

Mehr

Entwicklung eines Mac OS X Treibers für eine PCI-VME Interface Karte

Entwicklung eines Mac OS X Treibers für eine PCI-VME Interface Karte Entwicklung eines Mac OS X Treibers für eine PCI-VME Interface Karte Matthias Lange Informatikstudent, TU-Dresden 27. September 2005 http://www.matze-lange.de Warum entwickelt jemand einen Treiber für

Mehr

Messdaten auswerten und visualisieren 5 Tipps, die passende Darstellungstechnik für ein Messsystem zu finden

Messdaten auswerten und visualisieren 5 Tipps, die passende Darstellungstechnik für ein Messsystem zu finden Messdaten auswerten und visualisieren 5 Tipps, die passende Darstellungstechnik für ein Messsystem zu finden 27.05.13 Autor / Redakteur: Nach Unterlagen von National Instruments / Hendrik Härter Messdaten

Mehr

Embedded Linux. Arthur Baran

Embedded Linux. Arthur Baran Arthur Baran Inhalt Embedded System Aufbau von Embedded Linux Systemen Echtzeit Einige Beispiele Arthur Baran 2 Was ist Embedded System? klein verborgen im Gerät soll eine bestimmte Aufgabe erledigen Arthur

Mehr

Rapid I/O Toolkit. http://projects.spamt.net/riot. Alexander Bernauer alex@copton.net 08.12.08

Rapid I/O Toolkit. http://projects.spamt.net/riot. Alexander Bernauer alex@copton.net 08.12.08 Rapid I/O Toolkit http://projects.spamt.net/riot Alexander Bernauer alex@copton.net 08.12.08 Inhalt Motivation Architektur Beispiel I/O Features Ausblick Motivation Problemstellung Vorgaben Datenverarbeitung

Mehr

Jens Peter Lindemann Lehrstuhl Neurobiologie. 13. Januar 2009

Jens Peter Lindemann Lehrstuhl Neurobiologie. 13. Januar 2009 Real-Time Linux Jens Peter Lindemann Lehrstuhl Neurobiologie 13. Januar 2009 Was ist ein RTOS? Linux-basierte RT-Lösungen RT-Erweiterungen des Mainline-Kernels What's good for RT is good for the Kernel

Mehr

Bitte verwenden Sie nur dokumentenechtes Schreibmaterial!

Bitte verwenden Sie nur dokumentenechtes Schreibmaterial! VO 182.711 Prüfung Betriebssysteme 8. November 2013 KNr. MNr. Zuname, Vorname Ges.)(100) 1.)(35) 2.)(20) 3.)(45) Zusatzblätter: Bitte verwenden Sie nur dokumentenechtes Schreibmaterial! 1 Synchronisation

Mehr

Zeitgesteuerte Scheduling-Strategien in Echtzeitsystemen

Zeitgesteuerte Scheduling-Strategien in Echtzeitsystemen Wanja Hofer Hauptseminar Ausgewählte Kapitel eingebetteter Systeme 01.06.2005 Lehrstuhl 4 Betriebsysteme und Verteilte Systeme Zeitgesteuerte Scheduling-Strategien in Echtzeitsystemen Inhaltsverzeichnis

Mehr

Cluster Operating Systems

Cluster Operating Systems Lehrstuhl für Rechnerarchitektur, Professor Brüning Cluster Operating Systems Seminarvortrag im Wintersemester 2003/04 von Frank Ueltzhöffer 1. Einführung und Motivation 2. Charakterisierung 3. Herausforderungen

Mehr

Architektur Verteilter Systeme Teil 6: Interprozess-Kommunikation

Architektur Verteilter Systeme Teil 6: Interprozess-Kommunikation Architektur Verteilter Systeme Teil 6: Interprozess-Kommunikation 09.05.15 1 Literatur [6-1] http://php.net/manual/de/book.sockets.php [6-2] http://de.wikipedia.org/wiki/socket_(software) [6-3] http://php.net/manual/de/book.network.php

Mehr

Disaster Recovery mit BESR. Karsten Scheibel, Business Development Manager

Disaster Recovery mit BESR. Karsten Scheibel, Business Development Manager Disaster Recovery mit BESR Karsten Scheibel, Business Development Manager Erweiterung des Enterprise-Portfolios $5,93 Mrd. $5,25 Mrd. $2,6 Mrd. Peter Norton Computing $53 Mio. $530 Mio. $750 Mio. $1,07

Mehr

Institut für Verteilte Systeme

Institut für Verteilte Systeme Institut für Verteilte Systeme Prof. Dr. Franz Hauck Seminar: Multimedia- und Internetsysteme, Wintersemester 2010/11 Betreuer: Jörg Domaschka Bericht zur Seminarssitzung am 2011-01-31 Bearbeitet von :

Mehr