Windows CE als Echtzeitbetriebssystem

Universität Siegen Fachbereich 12 Praktische Informatik Seminar Sicherheitskritische Systeme SS 2004 Windows CE als Echtzeitbetriebssystem vorgelegt von Henning Peuser 05. August 2004 Betreuer: Dr. Jörg Niere

Zusammenfassung Die Verwendung von Echtzeitbetriebssystemen in eingebetteten System findet eine immer größere Verbreitung. In dieser Ausarbeitung werden die Kennzeichen eines Echtzeitsystems genannt und anschließend untersucht, ob das Produkt Windows CE von Microsoft den Anforderungen eines harten Echtzeitbetriebssystems genügt. Es wir festgestellt, daß dies nur bedingt zutrifft. Für weiche Anwendungen macht es den Einsatz möglich, während es für harte Anwendungen nicht geeignet ist, da wichtige Signale nicht immer verarbeitet werden.

1. Einleitung 1.1. Motivation Ein großer Automobilhersteller rief im Mai 2004 über eine halbe Million Fahrzeuge in seine Werkstätten zurück, um Probleme mit der elektronischen Bremskraftverstärkung zu beseitigen. Die elektronische Bremskraftkontrolle könne sich auf Grund unvorhergesehener Signale abschalten. Ein Mikrocomputer steuert das System während Sensoren das Verhalten von Fahrzeug und Fahrer überwachen. [9] Die Bremsanlage stellt ein sicherheitskritisches System unter Verwendung eines Echtzeitsystemes dar. Die Eigenschaft der Echtzeitfähigkeit stellt damit ein wesentliches Element im Zusammenhang mit sicherheitskritischen Systemen dar. Der Einsatz von Echtzeitbetriebssystemen ermöglicht in verschiedenen Einsatzszenarien Verfügbarkeit, Verläßlichkeit und Sicherheit. Damit nehmen sie einen hohen Stellenwert in der Industrie ein. Es soll daher untersucht werden, ob das Produkt Windows CE diesen Eigenschaften genügt. 1.2. Strukturierung Die vorliegende Arbeit ist in drei Teile gegliedert. Im ersten Teil, den Grundlagen, werden die verschiedenen Begriffe im Kontext definiert, das Produkt Windows CE vorgestellt sowie Anforderungen des Einsatzes erläutert. Im zweiten Teil, der Analyse wird das Produkt Windows CE anhand seiner Eigenschaften auf die Echtzeitfähigkeit hin überprüft. Im letzten Teil widme ich mich einer darstellenden Bewertung der Technik. 2. Grundlagen 2.1. Definitionen Zu Beginn werden die zentralen Begriffe im Kontext von Echtzeitbetriebssystemen definiert. 2.1.1 Eingebettetes System Eingebettete Systeme sind informationsverarbeitende Systeme, die unter Nutzung informationstechnologischer Mittel in ihre Anwendungsumgebungen physisch integriert und deren Eigenschaften durch diese Anwendungsumgebungen bestimmt sind. [11]

Mit dieser Definition wird auf das zentrale Merkmal der Informationsverarbeitung verwiesen und festgestellt, daß Eingebettete Systeme je nach Anwendungsgebiet eine unterschiedliche physische Gestalt annehmen können. 2.1.2 Sicherheitskritisches System Ein System heißt sicherheitskritisch, wenn durch dessen Fehlverhalten Leben und hohe Sachwerte gefährdet sind. Bei der Entwicklung und Unterhaltung eines sicherheitskritischen Systems sollten intensive Anstrengungen unternommen werden, um die hohen Anforderungen an die Sicherheit zu gewährleisten. [12] Bei der Entwicklung sicherheitskritischer Systeme werden Redundanz und formale Methoden als Werkzeuge eingesetzt. 2.1.3 Echtzeitbetriebssystem Ein Echtzeitbetriebssystem oder auch RTOS (real time operating system) ist ein Betriebssystem mit zusätzlichen Echtzeitfunktionen für die Einhaltung von Zeitbedingungen und die Vorhersagbarkeit des Prozeßverhaltens. [7] Ein Echtzeitbetriebssystem ist ein Baustein bei der Erstellung eines Echtzeitsystems. Es wird durch ständige Betriebsbereitschaft charakterisiert und gefordert, rechtzeitig auf externe Ereignisse zu reagieren. Der wesentlichste Punkt für Echtzeitsysteme ist die rechtzeitige Reaktion. Rechtzeitig bedeutet, daß jeder Task 1 eine bestimmt Zeitvorgabe hat. Diese Beschreibung findet die breiteste Zustimmung in der Fachliteratur. Der Unterschied zu einer anderen Definition besteht darin, daß mindestens eine Aktion eines Systems zeitlichen Begrenzungen unterliegt (und nicht alle Aktionen). Bezogen auf oben genannte Bremsanlage bedeutet Echtzeit, daß ein entsprechender Task beendet sein muß. Weitere Merkmale neben der Rechtzeitigkeit sind Kalkulierbarkeit, Robustheit, Fähigkeit für den Dauerbetrieb, Lieferung sicherer Ereignisse sowie eine kontrollierte Fehlerbearbeitung. Das Echtzeitsystem ist außerdem von der Umgebung abgeschottet. Grundsätzlich ist zu fragen, ob ein Echtzeitsystem zwangsläufig ein Betriebssystem benötigt. Im Grunde ist die Abarbeitung eines einzigen oder einiger weniger Programme einfach und es existieren auch Echtzeitsysteme ohne Betriebssystem. Dennoch machen eine steigende Anzahl von Programmen und erforderlicher grundlegender Funktionalität den Aufwand immer größer. Das Betriebssystem bietet Basisfunktionen für alle Anwendungen an und vereinfacht diese damit. [4] 2.1.4 Harte und Weiche Echtzeitsysteme Die Gültigkeitsdauer von Eingangsdaten bzw. Änderungsgeschwindigkeit von externen Ereignissen bestimmen die zeitlichen Deadlines 2 der Echtzeitsysteme. Man unterscheidet in Harte und Weiche Echtzeitsysteme. Der Unterschied zwischen einem harten und einem wei- 1 Ein Task ist ein auf unterster Systemebene (Kernel) laufender Prozeß 2 Jeder Task hat eine bestimmt Zeitvorgabe, die sog. Deadline

chen Echtzeitsystem besteht aufgrund der Systemanforderungen: Die Bezeichnung hart trifft zu, wenn das System auf keinen Fall eine Deadline verpassen soll und weich, wenn das System eine Deadline verpassen darf. Die Merkmale eines harten Echtzeitsystems sind: - unter keinen Umständen dürfen Verzögerungen akzeptiert werden - Ergebnisse sind nutzlos, wenn sie zu spät erfolgen - katastrophale Störungen, wenn die Deadline nicht eingehalten wird - unendlich hohe Kosten für verpaßte Deadlines Beispiele dazu sind die Steuerung eines Kernreaktors, ein Antiblockiersystem eines Automobils oder Überwachungssysteme auf einer Intensivstation. Ein weiches Echtzeitsystem wird beim verspäteten Eintreffen der Ergebnisse durch niedrige Kosten und Akzeptierung einer geringeren Performanz charakterisiert. Beispiele für weiche Systeme sind eine digitale Telefonanlage, eine Steuerung unkritischer chemischer Prozesse oder ein Verkaufsautomat. [7] 2.2. Abgrenzung Windows CE/ XP Windows CE ist ein Echtzeitbetriebssystem für eingebettete Systeme des Herstellers Microsoft. Bei diesem Hersteller ist es üblich, daß eine gewisse Marktumschließung stattfindet, so daß versucht wurde, eine ganze Produktpalette für eingebettete System zu entwickeln. Somit gibt es nicht nur Windows CE, das für kleine Anwendungen wie PDA und mobile Endgeräte entwickelt wurde, sondern auch Windows XP Embedded für große Systeme. Diese Vorgehensweise setzt einen modularen Aufbau voraus, der nach oben hin skalierbar ist. 2.2.1 Gemeinsamkeiten Das äußere Erscheinungsbild von Windows CE ähnelt dem der gängigen Windows Betriebssysteme. Weiterhin kann man ebenfalls die API (application programming interface) nutzen. Während sich die CE Linie auf den Bereich der Handhelds und PDAs ausdehnt, erkannte Microsoft, daß viele eingebettete Systeme nicht denselben Anforderungen unterworfen waren und ganz im Gegensatz zu diesen kleinen Geräten gerade nicht über nur begrenzten Platz und Speicher verfügten. Es entstand Windows NT Embedded und einige Jahre später der Nachfolger Windows XP Embedded. Diese Betriebssysteme versteiften sich eher auf die PC-ähnlichen eingebetteten Systeme. Also all die Systeme, die auf ein umfangreiches Betriebssystem zurückgreifen konnten, da es keine Unterbringungsprobleme gab. Windows NT Embedded war allerdings mit Vorsicht zu genießen. In einer Fallstudie versuchte man, die Pro und Kontras gegeneinander abzuwiegen und kam zu dem Schluß, daß die Verwendung dieses Systems teilweise umständlich ist und eine hohe Einarbeitung voraussetzt. Zudem muß man sich in Anbetracht der kurzen Produktzyklen immer vor Augen halten, daß die Vorteile, die man gewinnt, auf Dauer nicht unbedingt vorteilhaft sind. [5] Zur MS Embedded Serie gehören Windows CE.NET, Windows XP Embedded und das Windows 2000 Server Appliance Kit.

2.2.2 Unterschiede Windows CE besitzt im Gegensatz zur üblichen PC-Version von Windows einen deutlich kleineren Kernel. Da diese hardwaremäßig entsprechend unterschiedlich sind, können die vorhandenen Hardwaretreiber von Windows NT/XP nur unter Umständen verwendet werden. Windows XP Embedded bietet im Gegensatz zur schlanken Version CE verschiedene Funktionen. Dazu gehören Backoffice-Funktionalität, die Erweiterung um Serverkomponenten, eine Mehrbenutzerverwaltung und größere Caching-Eigenschaften. [6] 2.3. Anforderungen des Einsatzes von Echtzeitbetriebssystemen 2.3.1 Aufbau Beim Aufbau eines Echtzeitsystems im Allgemeinen kommt es auf verschiedene Eigenschaften an. Ein Echtzeitsystem besteht aus einem Rechnerteil (Hardware), einem Echtzeitbetriebssystem mit den für die Anwendung angepaßten Bestandteilen, und der Applikationssoftware. Letztere beinhaltet in der Regel die Anwendung, d.h. dort werden die vom Anwender gewünschten Aufgaben ausgeführt. Diese drei Komponenten müssen im Zusammenspiel das entsprechende Antwortverhalten, d.h. den zeitlichen Determinismus garantieren. Dabei gilt, je härter die zeitlichen Anforderungen sind, desto schneller muß die eingesetzte Hardware sein, oder desto simpler muß das eingesetzte Betriebssystem sein. Echtzeitbetriebssysteme besitzen einen Mikrokernel. Dies ist im Prinzip ein hardwareunabhängiger effizienter Scheduler 3 mit präzise definierten Schnittstellen. Das Echtzeitbetriebssystem bildet eine Schale um den Mikrokernel, die von Applikationsprogrammen nicht durchdrungen wird. Der Mikrokernel beinhaltet die Systemuhr, den Scheduler und die Semaphorenverwaltung 4. Er steuert die Rechenprozesse des Rechensystems und realisiert das Ablaufen derselben. Ein Task ist eine organisatorische Einheit, die aus ausführbarem Programmcode, eigenem Speicher und Variablen besteht. Diese besitzt zudem eine Priorität und einen Taskzustand. Man kann einen Task auch als lebendige Einheit bezeichnen, der eine Lebensdauer hat und nach entsprechender Zeit wieder aus dem System genommen wird. Der Task wird mit seiner Priorität in eine Kernelliste eingetragen. Der Kernel verwaltet mehrere Listen und für den richtigen zeitlichen Ablauf wird eine Ready Queue angelegt, die die einzelnen ablaufbereitenden Tasks beinhaltet. Manipuliert der Kernel eine seiner Listen aufgrund bestimmter Ereignisse, so tritt er in den Kernel State. Wenn dieser Zustand verlassen wird, aktiviert sich der Scheduler und arbeitet mit einem bestimmten Algorithmus die Rechenprozesse ab. Der Scheduler prüf anhand der Ready Queue, welchen Task der Mikroprozessor zugeteilt bekommt. In prioritätsgesteuerten Systemen bekommt derjenige Task die Rechenzeit zugeteilt, der ablaufbereit ist und die höchste Priorität besitzt. Die entsprechenden Deadlines können nach oben genannter Definition eines Echtzeitbetriebssystems harte oder weiche Kennzeichen besitzen. Die ausgeführten Tasks sind meistens bekannt und besitzen ebenfalls bekannte Prioritäten. Es wird deutlich, daß es beim Aufbau eines Echtzeitbetriebssystems auf garantierten statt hohen Durchsatz ankommt. Weiterhin bedeutend ist auch die Adaptierbarkeit auf spezielle Probleme. [2] 3 Ein Scheduler ist ein Taskmanager, der den Ablauf von Prozessen steuert 4 Semaphoro ital. Ampel, Zeichenträger

2.3.2 Speicherverwaltung Die Speicherverwaltung beeinflußt die Effizienz eines Echtzeitbetriebssystems sehr stark. Man kann die Speicherverwaltung dabei in drei Arten unterscheiden. Die erste betrifft das Kompilieren und statische Binden der Programme. Sie ist Aufgabe des Compilers und Linkers und unterscheidet das Echtzeitbetriebssystem prinzipiell nicht von herkömmlichen Betriebssystemen. Die zweite Speicherverwaltung findet beim dynamischen Binden (Dynamic Linker) statt. Diese beschränkt sich nur auf Echtzeitbetriebssysteme. Hierzu sind eine Reihe von speziellen Listen und Mechanismen notwendig, um den im System vorhandenen Arbeitsspeicher zur Laufzeit mit Programmcode zu füllen. Die letzte Speicherverwaltung gewinnt vor allem für die Programmiersprache C an Bedeutung. Dort sollen entsprechende Routinen so geschrieben sein, daß sie zur Laufzeit allokierte, d.h. belegte oder reservierte Speicher, nach Beendigung der Aufgabe wieder freigeben. Hier liegt die Hauptaufgabe des Betriebssystems, den gesamten Speicher zu verwalten. Eine virtuelle Speicherverwaltung ist nicht zwingend erforderlich oder sogar störend, weil sie Performanzeinbußen nach sich tragen kann. 2.3.3 Fehlerbehandlung Echtzeitsysteme zeichnen Sprachmittel zur Reaktion und Nutzung von sogenannten asynchronen Ereignissen aus, z.b. Interrupts, Signale, spezielle Elemente zur zeitlichen Steuerung und Behandlung von Ausnahmen. Der Hauptunterschied zu gewöhnlichen Betriebssystemen liegt in der gezielten Nutzung dieser Sprachmittel. Der reguläre Programmablauf kann von externen (Interrupts) oder internen Ereignissen (Signale) unterbrochen werden. Interrupts sind elektrische Signale, die direkt oder über Interrupt Controller an den Mikroprozessor gemeldet werden. Echtzeitsysteme sind für kürzeste Reaktionszeiten konstruiert, so daß jeder externe Interrupt in der Lage sein muß, den aktuell ablaufenden Task zu unterbrechen. Die Zeit, die vom Anlegen des Interrupts bis zum Start der entsprechenden Interrupt Service Routine vergeht, nennt man Interrupt Latenzzeit. Sie wird oftmals zum Vergleich der verschiedenen Echtzeitsysteme herangezogen (s.u.). Typische Interruptlatenzzeiten liegen bei heutigen Echtzeitbetriebssystemen im Bereich um die 10 Mikrosekunden. Sie hängen neben der Effizienz des Betriebssystems wesentlich vom eingesetzten Mikroprozessor ab. Ein Betriebssystem sollte in der Lage sein, den Großteil aller Softwarefehler, die sich direkt auf das Gesamtsystem auswirken, so abzufangen, daß zumindest noch eine Meldung über den Grund des Fehlers am Bildschirm erscheint. Es sollte also auch noch nach einem Windows Blue Screen zuverlässig weiterarbeiten können. [2] 2.3.4 Synchronisation Echtzeitsysteme sind meistens Multitasking-Systeme. Dort fordert der zu steuernde Prozeß in zahlreichen Fällen die parallele Bearbeitung von Rechenprozessen. Daher kann bei einem preemptiven Multitasking jeder Prozeß mehrere Threads starten. Für den Mikroprozessor gibt

es allerdings nur die sequentielle Bearbeitung von Rechenprozessen. Dazu gibt es drei Möglichkeiten Prozesse zu synchronisieren. Ein erster Ansatz besteht in der Synchronisation der Rechenprozesse im Mikroprozessor zu äußeren Abläufen im zu steuernden Prozeß. Diese Synchronisation stimmt den Ablauf der Rechenprozesse mit ihren zeitlichen und logischen Anforderungen mit dem Ablauf des technischen Prozesses ab. So wird z.b. ein Rechenprozeß für das Einlesen von Daten blockiert bis alle Daten eingelesen sind. Würde man den Einleseprozeß nicht warten lassen, bis die Daten vollständig sind, so würde die weitere Verarbeitung mit einem unvollständigen Satz Daten arbeiten, was mit Sicherheit zu Fehlern führen würde. Ein weiterer Ansatz besteht in der Synchronisation der Rechenprozesse untereinander zur gemeinsamen Verwendung von Betriebsmitteln. Diese Synchronisierung bedeutet einfach ausgedrückt, daß ein Rechenprozeß so lange blockiert wird, bis ein zweiter Rechenprozeß mittels eines entsprechenden Signals meldet, daß er am Synchronisationspunkt angekommen ist. Synchronisation bedeutet auch hier das Einfügen von Wartebedingungen. Synchronisation heißt für das Echtzeitsystem immer ein Verlust an Performanz, da sich ständig einer oder mehrere Rechenprozesse in einem Wartezustand befinden. Für das Systemdesign folgt daraus, daß die Anzahl der Synchronisierungspunkte innerhalb eines Echtzeitsystems möglichst klein zu halten ist. Die Umsetzung der Synchronisation geschieht durch Sprachmittel des Echtzeitbetriebssystems. Je nach Ausstattung besitzt ein Echtzeitbetriebssystem eine Reihe von Konstrukten, die es erlauben, eine beliebige Anzahl von Rechenprozessen während des Ablaufs zu synchronisieren. Effiziente Echtzeitbetriebssysteme zeichnen sich durch sehr wenige zusätzliche Verwaltungssoftware aus. Das bekannteste Sprachmittel zur Synchronisation von Rechenprozessen sind die sogenannten Semaphoren (s.o.). Dabei funktionieren Semaphoren ähnlich wie Ampeln. Stellt man sich eine Kreuzung als gemeinsame Ressource mehrerer Fahrzeuge vor, so müssen diejenigen Fahrzeuge, die abbiegen wollen, an der roten Ampel warten, bis der Geradeausverkehr durchgefahren ist. Entsprechendes gilt bei der umgekehrten Ampelschaltung. Genauso verhält es sich mit Semaphoren. Ein Rechenprozeß A muß warten bis die Semaphore grünes Licht anzeigt. Da Rechenprozesse keine Signalleuchten verstehen, hat man sich auf folgende Semaphorenoperationen und Definitionen zur Synchronisation von Rechenprozessen geeinigt. 1. Semaphorvariablen (SV) sind Ganzzahlen aus dem Bereich von null bis unendlich. Auf die Menge der Semaphoren werden zwei mathematische Operationen definiert. 2. Inkrementieren um 1, auch mit V(SV) bezeichnet; je nach Definition der SV kann sie nur die Werte 0 und 1 annehmen (Binäre Semaphore). In diesem Fall hätte das Inkrementieren einer auf 1 gesetzten Semaphore keinen Effekt. Daneben gibt es noch sogenannte Counting Semaphoren, die beliebig oft inkrementiert werden können. 3. Dekrementieren um 1 und Überprüfung, auch mit P(SV) bezeichnet; ist der Wert von SV nach erfolgter Operation positiv, so wird SV um eins erniedrigt. Würde der Wert -1 werden so wird die Operation nicht ausgeführt. Genau für diesen Fall würde der Rechenprozeß, der die Dekrementierung vornehmen wollte, blockiert werden.

Da Rechenprozesse unter den genannten Umständen auf eine Semaphore blockieren, muß die Verwendung von Semaphoren sehr sorgfältig geplant werden. Insbesondere im Verlauf der Programmentwicklung können sich unvorhergesehene Zustände einstellen, die dazu führen, daß Rechenprozesse ungewollt blockieren. Daraus kann sich für das Gesamtsystem ein Fehlerzustand ergeben, aus dem das System ohne Hilfe nicht mehr heraus kommt. Man bezeichnet derartige Zustände als Dead Locks (dt. Verklemmungen). Aufgrund der Möglichkeit, daß Semaphoren Verklemmungen hervorrufen können, dürfen z.b. innerhalb von Interrupt Service Routinen (ISR) innerhalb von Systemen wie VxWorks 5 keine Dekrementierungsoperationen P(S) vorgenommen werden. Damit ist sichergestellt, daß eine ISR nicht blockieren kann. Dies ist notwendig, da eine ISR aufgrund ihrer hohen Priorität (höher als alle anderen Rechenprozesse) bei einer Verklemmung mit Sicherheit einen fatalen Systemzustand provozieren würde. Es gibt also neue Probleme, die es in gewöhnlichen Betriebssystemen nicht gibt. Dies ist die Prioritäteninvertierung durch Blockade infolge der Nutzung von Ressourcen. Die Invertierung bezieht sich auf eine Situation, bei der ein Thread niedrigerer Priorität die Ausführung eines Threads höherer Priorität verhindert, indem er eine Ressource blockiert, während beide um die selben Ressourcen konkurrieren. Um diese Situation zu korrigieren und um den Thread höherer Priorität zu befreien, erlaubt man dem Thread niedrigerer Priorität, sich vor den Thread höherer Priorität zu stellen, bis er die Ressource nicht mehr benötigt. Als Lösung dazu gibt es die Priority Inheritance (Vererben) und das Priority Ceiling (Obergrenze), was auch im Folgenden analysiert wird. Priority Inheritance bedeutet, daß die Antwortzeiten verbessert werden, weil durch das Blocken von Threads niedriger Priorität diese automatisch höhere Priorität übernehmen. [2] 3. Analyse 3.1. Kennzeichen von Windows CE Ursprünglich wurde Windows CE Anfang der 1990er Jahre als Betriebssystem für tragbare Rechner unterhalb eines Notebooks konzipiert. Daraufhin gab es verschiedene Entwicklungen, z.b. ein webpad-ähnliches Gerät mir Schrifterkennung. Allerdings kam es in dieser Form nie über Prototypen hinaus. Am Rande dieser Entwicklungen entwickelte ein Microsoftteam einen Kernel von Grund auf neu. Dieser Kernel hat sich durchgesetzt und wurde 1996 durch Windows CE 1.0 auf den Markt gebracht. Seit 2002 ist das Betriebssystem in das Microsoft-eigene Framework.NET eingefügt. Dieses Framework ist eine strategische Plattform zur Softwareentwicklung, die aber prinzipiell offen und betriebssystemunabhängig ist. Es steht als Sammelbezeichnung für alle möglichen Programmiersprachen wie C#.NET, VB.NET, C++.NET, ASP.NET, JScript.NET, ADO.NET und XML.NET. Ziel dabei ist, unterschiedliche Denkweisen, Schnittstellen und Datenaustauschmechanismen zu vereinheitlichen. Die aktuelle Version 5.0 von Windows CE wurde von Microsoft im Juli 2004 veröffentlicht. 5 VxWorks ist ein Echtzeitbetriebssystem von Wind River Systems, das z.b. bei der Pathfinder-Mission zum Mars eingesetzt wurde

Windows CE ist ein hartes Echtzeitbetriebssystem mit der Unterstützung von verschiedenen Prozessorfamilien (z.b. Intel, MIPS, Alpha). Weiterhin werden mehrere Prozessortypen unterstützt. Dies sind zum einen Intels 386, 486 und Pentium, zum anderen aber auch Power PC 403, 601 usw. Neuerdings konzentriert sich Microsoft auf Intel StrongARM Prozessoren, speziell SA1110 und SA1111 mit 206 MHz Taktfrequenz, einer 32-bit Architektur und einem 100 MHz Bussystem. Das Kernbetriebssystem besteht aus mehreren großen Softwaremodulen. Ein Teil verwaltet Prozesse, Speicher und Ressourcen, ein weiteres Modul ist für das Dateisystem mit permanenter Speicherung von Informationen zuständig. Das GWE (Graphics, Windowing, Event Subsystem) steuert die Grafikausgabe und fensterbezogene Features. Als viertes Modul gibt es eine Kommunikationsschnittstelle für den Informationsaustausch mit anderen Geräten. Zusätzlich wird die Verwaltung von installierbaren Gerätetreibern (Hardwareanbindung) und die Komponentenanbindung COM bzw. OLE unterstützt. Windows CE bietet ab Version 3.0 256 Prioritätsstufen, acht davon für Applikationen. Ein critical process manager erkennt Abstürze und läßt das System auch nach diesem Blue Screen zuverlässig weiterarbeiten. Die Prioritätsstufen des früheren Windows CE kann man in drei Bereiche teilen. Die ersten beiden Level 0 und 1 sind für Echtzeitprozesse und Gerätetreiber bereitgestellt, die drei weiteren Level 2 bis 4 sind für die Kernelprozesse und normale Applikationen gedacht, und die letzten beiden Stufen sind Anwendungen zugeordnet, die jederzeit unterbrochen werden können. Windows CE ist ein preemptives Multitasking Betriebssystem. Daher kann jeder Prozeß mehrere Threads starten. Maximal können 32 Prozesse laufen, meist sind acht vom System reserviert. Ein weiteres Kennzeichen ist, daß Dienste und APIs 6 zum Teil kompontenenbasiert sind. Eine Untermenge der von herkömmlichen Windows-Systemen bekannten Win32-API wird unterstützt und bietet mehr als 1000 Funktionen. [6] Des weiteren läßt sich ein Betriebssystemkernel mit einem Speicherbedarf von 200kB in einem ROM 7 realisieren, was sehr gut ist. Windows CE bietet geschachtelte Interruptbehandlung, um verzögerte hochpriorisierte Interrupts zu vermeiden (Interrupt-Priorisierung). Damit ist das o.g. Priority Ceiling erreicht. Die normale Interruptbehandlung besteht aus zwei Teilen. Zuerst führt der Systemkern eine Interruptanfrage aus, um zu entscheiden, welche Interrupt Service Routine (ISR) für die Quelle verantwortlich ist. In dieser Routine wird der entsprechende Interrupt Service Thread (IST) benachrichtigt. Danach entscheidet der Scheduler, welcher Prozeß (Thread) als nächstes abzuarbeiten ist. Falls der IST der Prozeß mit der höchsten Priorität ist, wird dieser ausgeführt. In diesem Prozeß wird dann die notwendige Unterbrechnung (Interrupt) behandelt. Einer der signifikanten Aspekte der Echtzeit ist die Fähigkeit, eine Unterbrechung in einer bestimmten Zeit auszuführen. Dabei spielen die entsprechenden ISR- und IST-Latenzen eine Rolle. Diese wurden unter 2.3.4 erläutert (s.a. 3.3.). Ein wichtiger Aspekt besteht auch in dem Verfahren des XIP, dem execution in place. Dabei wird nicht der übliche Datenpfad einer Rechnerarchitektur verwendet, sondern die Befehle aus dem ROM direkt ausgeführt. Nur bei Bedarf wird in den Programmspeicher umkopiert. [10] 6 API: Application Programming Interface; Anwendungsschnittstelle 7 ROM: Read Only Memory; Speicher, der auch nach Wegnahme der elektrischen Spannung den Zustand behält

3.2. Schwachpunkte Bei Windows CE gibt es derzeit keine dynamischen Prioritäten. Weiterhin kann es zu einem möglichen Verlust von Interrupts durch zweistufige Bearbeitung kommen. Daher gibt es stark variierende Reaktionszeiten, was einer rechtzeitigen Reaktion entgegensteht. Allerdings ist dies stark von der Systemauslastung abhängig. Dieser Zusammenhang kann den Einsatz von Windows CE unmöglich machen, weil das System unter Umständen versagt. 3.3. Möglichkeiten des Einsatzes Anforderungen an die Echtzeitfähigkeit bestehen in der Unterstützung von Threadprioritäten und der Vermeidung von Prioritäteninvertierungen. Die vorgenannte Synchronisation muß vorhersagbar sein. Im Zusammenhang mit einem vorhersagbaren zeitlichen Verhalten des Betriebssystems müssen dazu folgende Elemente bekannt sein: - maximale Zeit der Sperrung von Interrupts - maximale Zeit, die die Behandlung eines Interrupts dauert - maximale Interrupt Latenz sowie - maximale Ausführungszeit von Systemrufen. Die Preemption basiert auf Threadpriorität. Das heißt, daß Threads mit hoher Priorität zuerst laufen. Threads niedriger Priorität laufen nicht, bevor alle mit höherer Priorität fertig sind (oder blockieren). Eine Ausnahme stellen die Threads auf Level 0 dar, die nicht preemptiv laufen, da das Betriebssystem sonst versagen würde. Windows CE erlaubt Memory Mapping. Es können also mehrere Prozesse den gleichen physikalischen Speicher benutzen. Daraus folgen schnelle Datentransfers zwischen Prozessen und eine Erhöhung der Echtzeitperformanz. [8] 3.4. Bedrohungen Das zu betrachtende System besitzt eine Timerauflösung von 1ms (im Grunde 2ms Zeitscheiben für Tasks), was den Anforderungen für Echtzeitsysteme eher nicht genügt. Windows CE beinhaltet auch ein virtuelles Speichermanagement, was für Echtzeitbetriebssysteme auch nicht unbedingt geeignet ist. Bis zur Version 3.0 gab es 32 MByte Speicherkapazität pro Prozeß, was für manche Anwendungen zu wenig ist. Daher wird ein Memory Mapping (s.o.) verwendet, um Speicherbereiche auszutauschen. Das XIP führt dazu, daß sich Ladebereiche von Speicherbibliotheken verschiedener Anwendungen beeinflussen. Dies bedeutet, daß Lücken oft nicht nutzbar sind und offene Applikationen die Vorhersagbarkeit erschweren (letzteres ist ein wichtiges Kriterium für Echtzeitsysteme). Für eingebettete Systeme ergibt sich der Vorschlag, möglichst wenige XIP-Bereiche zu benutzen und diese dann so dicht wie möglich zu packen. Echtzeit im Sinne der Speicherverwaltung kann nur garantiert werden, wenn Prozesse festgeschrieben im Speicher laufen, und nicht durch Paging (Austauschen von Speicherseiten vom Cache in den Arbeitsspeicher) beeinflußt werden. [8] Es gibt sicher noch einige Lösungen, die an anderer Stelle untersucht werden können.

4. Technik 4.1. Benutzersicht Da das Microsoft-eigene.NET Compact Framework mitgeliefert wird, ist es recht einfach, Anwendungen für dieses Echtzeitbetriebssystem zu schreiben. Die Entwicklungsumgebung nennt sich Platform Builder und bietet Funktionen, die bislang nur über die Kommandozeile zugänglich waren. Sie verkürzt die Zeit des Kompilierens durch ein vereinheitlichtes inkrementelles Build-System, das auch mit manuell veränderten Dateien klarkommt. In der neuesten Version 5.0 sollen von der Microsoft Visual-Familie bekannte Bestandteile die Programmierung weiter erleichtern, z.b. automatisch eingeblendete Hilfetexte zur Syntax von Funktionsaufrufen. Mit vorhandenem, portierten Programmcode auf Basis der Win32-API lassen sich sehr effizient Anwendungen für Echtzeitsysteme erstellen. Dabei hilft die Verfügbarkeit von Gerätetreibern. Dadurch kann man die Echtzeiteigenschaften als sehr gut bezeichnen, allerdings findet sich auch eine mangelhafte Dokumentation vor. [3] 4.2. Implementierung Der Compiler des.net Frameworks erzeugt ähnlich wie die Programmiersprache Java aus den verschiedenen Sprachen wie C#.NET oder VB.NET einen byte code, die sogenannte MSIL (Microsoft Intermediate Language). Dies nennt man auch managed code, weil durch eine Garbage Collection eine gewisse Speicherverwaltung stattfindet. Außerdem werden Sicherheitsrichtlinien erzwungen. Dies macht es dem Benutzer leicht, mit dem Visual Studio.NET (Microsoft Entwicklungsumgebung) Programme zu erstellen. Für echtzeitfähige Programme gibt es weiterhin das Hilfsmittel embedded Visual C++. [6] Die Quelltexte der Module und des Systemkerns sind teilweise einsehbar, aber kaum kommentiert. Die verwendeten Quellsprachen sind C und C++ (bzw. neuerdings die.net- Versionen). Microsoft arbeitet bei Windows CE mit einer sogenannten Shared Source License. Früher wurde die kommerzielle Nutzung der Quelltexte in diesem Rahmen verboten und auch von der Heranziehung für Schadensersatzklagen wurde sich distanziert. Heutzutage dürfen Softwarefirmen basierend auf den zugänglichen Quellen allerdings eigene Windows CE- Derivate entwickeln und vertreiben. Dazu hat Microsoft die Anzahl der im Rahmen einer Shared Source Lizenz zugänglichen Quelltextzeilen um 500.000 auf insgesamt 2,5 Millionen erhöht. Jede einzelnde Runtimelizenz von Windows CE 5.0 kostet inklusive Browser und Mediaplayer 15 US-Dollar pro Gerät. Ohne die grafische Oberfläche, den Browser und den Mediaplayer kostet die Lizenz drei US-Dollar. [3] Als Beispiel in der Industrie kann man sich für eine Robotersteuerung zwei Lösungsszenarien vorstellen. Eine Möglichkeit besteht in der ausschließlichen Nutzung von Windows CE.NET. Dieses ist in beschriebener Weise echtzeitfähig, skalierbar und kostengünstig. Die Herkunft aus der Windowsfamilie garantiert eine gute Treiberverfügbarkeit für angeschlossene Geräte.

Eine andere Möglichkeit besteht in der Nutzung einer Kombination aus Windows XP und Windows CE. Dabei wird Windows XP als Startsystem benutzt und Windows CE anschließend in den Speicher geladen. Das heißt, daß einige wenige Echtzeittasks auf Windows CE laufen. Trotzdem arbeitet das System auch nach einem Absturz des großen XP-Systems ordentlich weiter. Ein zusätzlicher Pluspunkt in dieser Variante ist ebenfalls die große Gerätetreiberverfügbarkeit. Die Kommunikation erfolgt über das Netzwerkprotokoll TCP/IP als Shared Memory Netzwerk. Die Kosten betragen dabei in etwa genau so viel wie ein anderes kommerzielles Echtzeitbetriebssystem. [4] 5. Zusammenfassung Die Nutzung eines Standard-Echtzeitbetriebssystems wird für einige Segmente auf dem Markt für eingebettete Systeme immer wichtiger. Heutzutage wird eine große Anzahl der Fähigkeiten durch die Software selbst geliefert. Wir stellen fest, daß das Windows CE Kernel Design die Mindestanforderungen an ein Echtzeitbetriebssystem erfüllt. Die Interrupt Latenz ist bedingt vorhersagbar und begrenzt. Des weiteren sind die Ausführungszeiten für Systemrufe vorhersagbar und unabhängig von der Systemlast. Das vorgestellte Echtzeitbetriebssystem Windows CE (inkl..net) läßt sich für Anwendungen wie Set-top-Boxen, Multimediaspieler und Handhelds einsetzen. Sogar für medizinische Geräte und die industrielle Automatisierungstechnik gibt es Einsatzszenarien. Auch Anforderungen im Automobilbereich sollte es genügen. Den Anforderungen echter sicherheitskritischer Anwendungen genügt es allerdings nicht. Auch wenn Microsoft den Markt der eingebetteten Systeme erobern möchte, so kann man festhalten, daß auf diesem Markt kein Echtzeitbetriebssystem verfügbar ist, das für jede mögliche Applikation die optimale Lösung darstellt. Wichtig ist daher, aus der Projektspezifikation für die geplante Applikation einen Anforderungskatalog abzuleiten, der mit den Möglichkeiten der einzelnen Produkte verglichen wird. Diese Auswahl führt bei einer systematischen Durchführung zu einem Echtzeitbetriebssystem, dessen Eigenschaften es am besten für die entsprechenden Anforderungen geeignet erscheinen lassen.

6. Literaturverzeichnis [1] Giese, H.: Vorlesung Safety-Critical Computer Systems WS 02/03 Universität Paderborn, 2002 [2] Hardwareecke <http://www.hardwareecke.de/berichte/grundlagen/rtos.php> (14. Juli 2004) [3] Heise Online, <http://www.heise.de/newsticker/meldung/48645> (05. Juli 2004) [4] Himmler, P.: Is Windows CE.NET usable for embedded real-time systems? < http://www.3soft.de/_content/presse/_pdf/artikel_windowscenet.pdf > (26. Juli 2004) [5] Mangold, K.: Gates oder Geht s nicht? Erfahrungen mit Windows NT embedded in: Holleczek, P./ Vogel-Heuser, B. (Hrsg.): Echtzeitkommunikation und Ethernet/Internet PEARL 2001, Springer Verlag, Heidelberg, 2001, S.128-137 [6] Microsoft Windows Developer Network <http://msdn.microsoft.com/embedded/> (03. August 2004) [7] netlexikon, akademie.de asp GmbH <http://www.lexikon-definition.de/echtzeit.html> (03. August 2004) <http://www.lexikon-definition.de/echtzeitbetriebssystem.html> (03. August 2004) [8] Richling, J.: Vorlesung Betriebssysteme WS 03/04 Humboldt-Universität Berlin, 2003 [9] Spiegel Online: DaimlerChrysler ruft 680.000 Mercedes SL und E zurück <http://www.spiegel.de/auto/werkstatt/0,1518,299464,00.html> (12. Mai 2004) [10] Staab, H.: Echtzeitsteuerungen mit Windows CE.NET < http://wwwiaim.ira.uka.de/germrob/vdi-vde-gma- 4.13/35Sitzung/6_Staab_WinCe-Robot.pdf > (26. Juli 2004) [11] Steusloff, H.: Verteilte Echtzeitsysteme und Eingebettete Systeme in: Holleczek, P./ Vogel-Heuser, B. (Hrsg.): Verteilte Echtzeitsysteme PEARL 2003 Springer Verlag, Heidelberg, 2003 [12] Storey, N.: Safety-Critical Computer Systems Addison-Wesley, 1996