Echtzeitsysteme. Inhaltsverzeichnis. Dieter Zöbel. Universität Koblenz-Landau Fachbereich Informatik, Institut für Softwaretechnik

Transkript

1 Dieter Zöbel Universität Koblenz-Landau Fachbereich Informatik, Institut für Softwaretechnik Inhaltsverzeichnis 1 Einführung Eingrenzung Grundmodell eines Echtzeitsystems Prozesse Zeiten Beispiele Zeiten und Uhren Echtzeit und physikalische Zeit UhrenundWecker Ausführungzeiten von Anweisungen Ableitung von Zeitbedingungen Modellbildung Logiken Algebren Zustandsautomaten Petri-Netze Echtzeitplanung Grundlagen der Echtzeitplanung Planen durch Suchen Planen nach Fristen Planen nach monotonen Raten Planen nach monotonen Fristen Synchronisierung 66 6 Rechnerarchitekturen und Prozessoren 67 7 Betriebssysteme Merkmale von Echtzeitbetriebssystemen Aufbauprinzipien Speicherverwaltung Dateiverwaltung Treiber Unterbrechungen i

2 7.7 Beispiele für Echtzeitbetriebssysteme Solaris QNX POSIX µitron OSEK/VDX Programmiersprachen 80 9 Softwaretechnik Rechnernetze Nachlese 83 ii Kapitel 7 Betriebssysteme Merkmale von Echtzeitbetriebssystemen Aufbauprinzipien Speicherverwaltung Dateiverwaltung Treiber Unterbrechungsbehandlung Beispiele für Echtzeitbetriebssysteme 68

3 7.1. MERKMALE VON ECHTZEITBETRIEBSSYSTEMEN 7.1 Merkmale von Echtzeitbetriebssystemen Allgemeine Zielsetzung: Nutzbarmachung des Rechners ergonomische Benutzeschnittstelle Ausnutzung der Fähigkeiten, insbesondere der Leistungsfähigkeit Anpassung an wechselnde Aufgabenstellungen Betriebssystem + Vorhersagbarkeit + Skalierbarkeit + Zeitverwaltung + :::: Echtzeitbetriebssystem Dieter Zöbel MERKMALE VON ECHTZEITBETRIEBSSYSTEMEN Kategorisierung von Echtzeitbetriebssystemen Echtzeitbetriebssysteme z.b. QNX, psos,... Laufzeitsysteme z.b. RTKernel, Ada runtime system Standardschnittstellen z.b. POSIX, ITRON Dieter Zöbel

4 Merkmale von Echtzeitbetriebssystemen 7.1. MERKMALE VON ECHTZEITBETRIEBSSYSTEMEN Durchreichen von Unterbrechungsanforderungen (prioritätsabhängig) an die Anwendungsprogramme Mehrprogrammbetrieb mit der Möglichkeit der anwendungsspezifischen Zuordnung von Prioritäten Bereitstellung einer effizienten Zeitund Weckverwaltung einstellbare Zeitauflösung (Bezugszeitspanne t G ) Überwachung der Einhaltung von Echtzeitbedingungen Unterbrechbarkeit des Kerns (bzw. von Systemaufrufen) asynchrone E/A-Operationen Verhersagbarkeit der Zugriffsdauer auf Plattendateien durch entsprechende Organisation (z.b. zusammenhängende Folgen von Dateiblöcken) Möglichkeit zur Abschaltung der virtuellen Speicherverwaltung (z.b. zur Vermeidung unvorgesehener Seitenaustausche) Dieter Zöbel Genealogie der Echtzeitbetriebssysteme Kategorisierungsschemata 7.1. MERKMALE VON ECHTZEITBETRIEBSSYSTEMEN Grad der Offenlegung: proprietär (z.b. irmx) offen 1 (z.b. REAL/IX) Herkunft: Eigenentwickeltes Echtzeitbetriebssystem (z.b. QNX) Integration von Echtzeitmerkmalen (z.b. AIX) Weiterentwicklung eines Betriebssystems zu einem Echtzeitbetriebssystem (z.b. LynxOS) Plattformabhängigkeit: aus Betriebssystem-Sicht: Microsoft basiert (z.b. RTXDOS, EUROS) UNIXbasiert (z.b. psos) aus Hardware-Sicht: Bindung an Prozessoren oder an Boards: PC-basiert (z.b. RMOS, QNX) oder Intel-basiert (z.b. irmx) Ausbaustufe: Ausführungssystem für parallele Prozesse (engl.: executive) (z. B. RTKernel) vollständig ausgebautes Betriebssystem (z.b. Solaris) 1 offen in dem Sinne, dass es herstellerunabhängige Standards wie POSIX.4 erfüllt Dieter Zöbel

5 7.1. MERKMALE VON ECHTZEITBETRIEBSSYSTEMEN Entwicklungslinien von Echtzeitbetriebssytemen eigenständige Entwicklung angelehnt an UNIX angelehnt an Microsoft integriert in ein universelles Betriebssystem angelehnt an den PC Standard proprietär offen vorwiegend proprietär offen, proprietär eher proprietär Beispiele iirmx OS/9 QNX, REAL/IX EUROS, WindowsCE Solaris, Ada QNX, irmx, WindowsCE Dieter Zöbel MERKMALE VON ECHTZEITBETRIEBSSYSTEMEN Vor und Nachteile einer Anlehnung an ein vorhandenes Betriebssystem Vorteile: größere Akzeptanz bei den Entwicklern Verfügbarkeit von komfortablen Werkzeugen und Schnittstellen (z.b. make, awk oder graphische Benutzeroberflächen) Nachteile: Probleme mit der Größe und der Skalierbarkeit Probleme mit der Rechtzeitigkeit Dieter Zöbel

6 Wie wird UNIX ein Echtzeitbetriebssystem? 7.1. MERKMALE VON ECHTZEITBETRIEBSSYSTEMEN unterbrechbarer, skalierbarer Kern (ist für ein Echtzeitbetriebssystem neu zu entwickeln) Bereitstellung einer hohen Zeitauflösung prioritätsbasierte Prozessausführung Ergänzung um leichtgewichtige Prozesse Verhinderung des Seitenaustausches kalkulierbare Zugriffszeiten auf Plattendateien Erfüllung von Standards, z.b. POSIX und POSIX Dieter Zöbel AUFBAUPRINZIPIEN 7.2 Aufbauprinzipien Begriffseingrenzung: Der Kern ist der Teil des Betriebssystems, der unverzichtbar für dessen Funktionalität ist. Kategorisierung: Makrokern: Wesentliche Funktionalitäten des Betriebssystems sind im Kern zu finden (typischerweise monolithischer Aufbau, z.b. UNIX) Mikrokern: nur die notwendigste Funktionalität zum Betreiben von Betriebssystemkomponenten gehört in den Kern (alle Dienstleistungen, die Dateiverwaltung, Speicherverwaltung und Geräteverwaltung liegen außerhalb des Kerns, z.b. QNX) Umsetzung der Echtzeitanforderung der Unterbrechbarkeit des Kerns (bzw. der Systemaufrufe): bei Makrokernen: durch Sollbruchstellen bei Mikrokernen: durch minimalisierte Dienste des Kerns Dieter Zöbel

7 7.2. AUFBAUPRINZIPIEN Vor- und Nachteile der Mikrokern-Architektur Vorteile: Sichere Kapselung der Komponenten (Prozesse) eines Betriebssystems (durch die Speicherverwaltung) definierte Schnittstelle zum Kern (API), insbesondere zum Zwecke des Interprozesskommunikation (IPC 2 ) klare Trennung von Funktionalitäten zwischen Kern und den Prozessen, bzw. unter den Prozessen (Dienst- wie Anwenderprozesse) Skalierbarkeit, Anpassungsfähigkeit, Erweiterbarkeit und Dynamik (z.b. Nachladen von Betriebssystemprozessen zur Laufzeit) Einfache Anpassung an neue Rechnerplattformen (durch den Austausch von Treibern und ggf. des Kerns) Nachteil: (Noch) hoher Aufwand (vgl. [Lie96]) 2 (engl.: inter-process communication) Dieter Zöbel AUFBAUPRINZIPIEN Interprozesskommunikation (IPC) Paradigma: Ein Betriebssystem und die umgebenden Anwenderprozesse kommuniziern mittels Nachrichten (transparent realisiert durch den Kern) miteinander. Zentrale Aufgabe des Kerns: Abwicklung der Nachrichtenübertragung Vorteile: homogener Systemaufbau: Es gibt nur Prozesse. klare Objektstruktur: Dientleistung und damit Datenmanipulation nur durch Methodenaufrufe an das Dienstleistungsobjekt. Anwenderprozess Dienstprozess Mikrokern Dieter Zöbel

8 7.2. AUFBAUPRINZIPIEN Beispiel: Mikrokernarchitektur von QNX Prozess Prozess Prozess Netzanbindung Scheduler Interprozesskommunikation Interrupt Redirector Netzwerkschnittstelle Minimaler Umfang des Kerns für einbettete Anwendungen: 130KByte (nach Angaben von QNX: 64KByte [Qnx97]). Zusätzlich: IDE-Treiber 40KByte, Plattentreiber (fdisk) 130KByte Dieter Zöbel SPEICHERVERWALTUNG 7.3 Speicherverwaltung Adressierungsformen: direkte Adressierung virtuelle Adressierung Lauffähigkeit großer Programme Schutz der Prozesse untereinander Segment- und/oder Seiteverwaltung basierend auf einer MMU (memory management unit) Seitenaustauchverfahren (Dauer Zugriffe auf den Hauptspeicher) Probleme bzgl. Vorhersagbarkeit beim Anlaufen des Programms werden die Daten nach Bedarf nachgeladen beim laufenden Betrieb kommt es zu unverhofften Seitenaustauschen Dieter Zöbel

9 7.3. SPEICHERVERWALTUNG Speicherverwaltung mit vorhersagbaren Ausführungszeiten Vorkehrungen: Laden aller Programmseiten vor dem Programmstart Vorbelegen von Hauptspeicher für die Stapel und Haufen Vermeidung von dynamischen Speicherplatzanforderungen Verbieten von Seitenaustauschen Vermeiden des Kopierens von großen Datenmengen zwischen Prozessen Bsp.: Entsprechende Befehle unter dem Echtzeitbetriebssystem REAL/IX: stkexp() für das Vorbelegen von Speicher für den Stapel plock() für das Verbieten von Seitenaustauschen Dieter Zöbel DATEIVERWALTUNG 7.4 Dateiverwaltung hier: Vorhersagbarkeit beim Zugriff auf die Festplatte: Zeitschranken für einzelne Lese- und Schreibzugriffe Priorisierung von Zugriffsanforderungen periodische oder permanente Anforderungen von großen Datenmengen (hauptsächlich bei Multimedia- Anwendungen) Ursachen mangelnder Vorhersagbarkeit: Form der Auftragsabarbeitung durch den Treiber Suchzeit für die Spur Wartezeit auf den Sektor Fragmentierung der Blöcke einer Datei weniger: Übertragung der Daten zum Controller Abwicklung der Systemaufrufe Dieter Zöbel

10 7.4. DATEIVERWALTUNG Vorhersagbare Zugriffszeiten Klassische Verfahren ohne Vorhersagbarkeit: FCFS (first come, first served) hoher Grad an paralleler Auftragsabwicklung SSTF (shortest seek time first) SCAN (seq. Suchen nach der nächsten Spur) Ziele unter Echtzeitgesichtspunkten: Einhalten der Fristen Vermeiden von Übertragungslücken Beachte: hoher Durchsatz und die Sicherung von Zeitbedingungen sind konträre Ziele Eigenfunktionalität des Plattencontrollers und Topologie der Platte ist (oftmals) für den Treiber nicht offengelegt. Dieter Zöbel DATEIVERWALTUNG Strategie für vorhersagbare Plattenzugriffe SCAN-EDF (z.b. unter AIX) Zuordnung einer Frist für jeden Auftrag Anwendung von EDF bzgl. der Frist der Aufträge Einhaltung der Frist Anwendung des SCAN-Algorithmus für Aufträge mit gleicher Frist hoher Durchsatz Bsp.: SCAN-EDF angewendet auf Aufträge der Form (Frist,Spur): (10, 201) (10, 214) (10, 235) (10, 194) (10, 176) (11, 109) (11, 180) (11, 204) (11, 214) (11, 239) (13, 297) (13, 212) Dieter Zöbel

11 7.5. TREIBER 7.5 Treiber Abstrakte Schnittstelle zu einem Gerät: Aus Anwendersicht ist der Treiber ein Teil der Hardware, wie aus Treibersicht der Unterbrechungprozess ein Teil der Hardware ist. Zuordnung der Treiber bei Mikrokernen: als ein Prozess (oder mehrere), mit einer speziellen Priorität und einer standardisierten Schnittstelle, kann dynamisch zum Betriebssystem hinzugefügt werden Treiberschnittstelle bei Makrokernen: Teil des Kerns Treiber Zugriff auf das Gerät Ein-/Ausgabegerät Anstöße Unterbrechungsbehandlung Betriebssystem Hardware Dieter Zöbel TREIBER Anstoßen des Treibers Man unterscheidet (vgl. [RL93]) Initiator: nimmt den Auftrag an das ihm zugeordnete Gerät an, prüft die Auftragsparameter und reiht den Auftrag in die Warteschlage ein. Kontinuator: arbeitet den nächsten Auftrag aus der Warteschlange ab, sobald das Gerät über eine Unterbrechungsanforderung die Fertigmeldung für den letzten Auftrag gegeben hat. Programmschema für einen Treiber, der über Nachrichten von Seiten der Anwendung beauftragt und von Seiten des Gerätes Fertigmeldungen erhält: DO OD wait for(msg,sender) // verarbeite msg von sender Dieter Zöbel

12 Auswirkungen der Mikrokern-Architektur 7.5. TREIBER Entwicklungstendenzen Die Unterbrechungsbehandlung so kurz wie möglich (somit Verkürzung der Zeitdauer, die nicht vom Kern aus, d.h. der Prozessverwaltung aus, steuerbar ist. Einheitliche Anstoßmechanismen für Treiber wie für andere Prozesse, insbesondere was die Unterbrechungsanforderungen angeht. xx_open xx_close xx_read xx_write gemeinsamer Speicherbereich xx_intr Die Prozesse, die bei Solaris einen Treiber aufbauen Dieter Zöbel Übertragung von Nutzdaten vom Hauptspeicher zum Gerät 7.5. TREIBER I/O-mapped Getrennter Adressraum für Geräte und Zugriff über eigene Befehle (z.b. IN und OUT). Synchrone Auftragsabwicklung und Fertigmeldung des Gerätes via Interrupt memory mapped Der Speicher des Gerätes ist Teil des physikalischen Adressraumes, ggf. direkter Zugriff des Prozessors des peripheren Gerätes in den Hauptspeicher (z.b. geschützt durch spin locks) DMA (direct memory access) Ein DMA-Controller ist über einen eigenen Bus mit dem Hauptspeicher verbunden. Autonome Abwicklung des Auftrags und Fertigmeldung durch Interrupt. Dieter Zöbel

13 7.6. UNTERBRECHUNGEN 7.6 Unterbrechungen Grundsätzliche Zielsetzung: Unterbrechung des normalen Ablaufs durch eine vorrangige Verarbeitung. Klassen von Unterbrechungen Nachricht Asynchron (interrupts) z.b.: Timerinterrupt Meldung eines Spannungsausfalls Abschluss des Plattenzugriffs Abschluss des Sendens einer Synchron (traps) z.b.: arithmetische Fehler Seitenfehler Verletzung des Speicherschutzes Systemaufrufe Dieter Zöbel Schritte bei der Unterbrechungsbehandlung Ablauf 1. Der Prozessor beendet die Ausführung des letzten Befehls (Unterbrechung 3 des aktuellen Prozesses). 4. Durch einen speziellen Befehl wird die Rückkehr vom Unterbrechungsprozess zum aktuellen Prozess durchgeführt UNTERBRECHUNGEN 2. Die Ausführung des Prozessors wird auf den Unterbrechungsprozess umgeschaltet. Treiber ISR Betriebssystem 3. Der Unterbrechungsprozess (ISR 4 ) wird ausgeführt. Ein-/Ausgabegerät Hardware Der Unterbrechungsprozess kann aus programmiertechnischer Sicht als eine Komponente der Hardware aufgefasst werden 3 Man unterscheidet asynchrone Unterbrechungen (engl.: interrupt) von synchronen Unterbrechungen (engl.: traps) 4 (engl.: interrupt service routine) Dieter Zöbel

14 7.6. UNTERBRECHUNGEN Latenzen bei der Unterbrechungsbehandlung Die Unterbrechungslatenz (engl.: interrupt latency) umfasst alle Zeitspannen vom Zeitpunkt der Auslösung der Unterbrechung bis zum Beginn der Ausführung des Unterbrechungsprozesses (Schritte 1. und 2.) Bsp.: unter LynxOS auf einem 33MHz Intel 386: 75µs Bsp.: unter QNX auf einem 33MHz Intel 386: 15µs Bsp.: unter QNX auf einem 133MHz Intel Pentium: 4.3µs Strategie: Abarbeitung der ISR als Prozess des Echtzeitbetriebssystems Verzögerung für einen höher priorisierten Prozess: die Unterbrechungslatenz Dieter Zöbel Beispiele für Echtzeitbetriebssysteme Hier wird exemplarisch auf bedeutende Echtzeitbetriebssysteme und Betriebssystem- Schnittstellen Bezug genommen: Solaris µitron QNX POSIX OSEK/VDX Dieter Zöbel

15 7.7.1 Solaris Merkmale: Universalbetriebssystem unterbrechbarer Kern Threadkonzept klassenspezifische Prioritäten Mehrprozessorfähigkeit Synchronisierungsobjekte: mutex, r/w-lock, counting semaphor, condition variable Prioritätsvererbung Interrupt Threads Realtime Threads System Threads Timescliced Threads fixed priorities dynamic priorities Prozessklassen von Solaris Dieter Zöbel QNX Merkmale: Mikrokern-Betriebssystem Skalierbarkeit extern: Dateiverwaltung, Netzwerkverwaltung, graphische Oberfläche Interprozesskommunikation mittels synchroner Nachrichtenübertragung (send(), receive(), reply()) Netzwerktransparenz (TCP/IP-basiert: WAN, LAN, CAN, serielle Schnittstelle) prioritätsbasierte Prozessausführung Prioritätsvererbung einstellbare Zeitauflösung PC-Plattform Dieter Zöbel

16 synchrone Nachrichtenübertragung Prinzip der synchronen Nachrichtenübertragung: Das Senden und Empfangen von Nachrichten ist eine gemeinsame Operation von Sender und Empänger, d.h. keiner kann dem anderen vorauslaufen. Logdaten Laserdaten Laserscanner Synchrone Nachrichtenübertragung heißt auch: beide Prozesse müssen gleichzeitig zur Nachrichtenübertragung bereit sein. Das ist unmöglich, wenn Prozesse ereignisgesteuert sind oder unterschiedlich Perioden besitzen (hohe Wartezeiten, Gefahr von Deadlock). Eingreifdaten Funkmodem Steuerung Fahrdaten Antrieb, Lenkung Funktionale Zerlegung von EZauto Dieter Zöbel Entwurf mit Briefkästen Zur Vermeidung von Deadlocks dienen Breifkästen (engl.: mailbox), die eine asynchrone Nachrichtenübertragung zwichen Prozessen realisieren. Log daten Fahrdaten Laserdaten Timer Funkmodem Steuerung Laserscanner Eingreifdaten Timer Timer Timer Antrieb, Lenkung Entwurf von EZauto mit den 4 ursprünglichen Prozessen, 4 Briefkästen und 4 Timern Dieter Zöbel

17 7.7.3 POSIX Ziel: Schaffung von Kompatibilitäten, was die Portabilität von Code Programmen Daten (im Rahmen von Kommunikation) angeht. Wichtigster Standard für : POSIX 5 Zielsetzung der IEEE: Definition einer anwendungsspezifischen Programmierschnittstelle (API 6 ) zum Betriebssystem (nicht notwendigerweise UNIX) 5 (engl.: portable operating system interface for computer environments) 6 (engl.: application programmers interface) Dieter Zöbel Wichtige POSIX-Standards Working Groups Charter POSIX.0 Open-system architecture POSIX.1 Posix application interface POSIX.2 Shell and command utilities POSIX.3 Testing and verification methods POSIX.4 Real-time extensions to POSIX POSIX.5 Ada binding to POSIX POSIX.13 Realtime application environment profiles POSIX.14 Multiprocessing application environment profiles POSIX.20 Ada binding to POSIX.4 POSIX.21 Distributed real-time Dieter Zöbel

18 POSIX.4 Merkmale Thread 7 -Konzept prioritätsbasierte Prozessausführung Semaphore hauptspeicherresidente Prozesse gemeinsamer Hauptspeicher für Prozesse Echtzeituhren asynchrone Ein/Ausgabe 7 dt. Faden Dieter Zöbel Vergleich von Prozessen mit Threads Prozess (oft auch Task genannt) kann mehrere Threads enthalten eigener Adressraum besitzt Betriebsmittel z.b. offene Dateien Kommunikation mit anderen Prozessen über Pipes oder Nachrichten Thread ist einem Prozess zugeordnet gemeinsamer Adressraum teilt Betriebsmittel mit den anderen Threads des Prozesses Kommunikation mit anderen Threads über den gemeinsam Speicher Dieter Zöbel

19 7.7.4 µitron Ansatz: Offener Standard für die Entwicklung kleiner und kleinster engebetteter Systeme (Japan seit 1984, z.zt. Version 3.0 [Sak98]) TRON 8 -Philosophie: Intelligent Objekte werden uns bald umgeben und unsere alltäglichen Helfer sein. Anwendungsbereiche (nach eigenen Angaben nur zivile Nutzung): Audio/Video-Elektronik: Fernseher, Videokameras, Digitalkameras Telekommunikation: Anrufbeantworter, Handies, ATM-Switches Datenverarbeitung: Infrarot-Druckerschnittstelle, Scanner Automotive: Navigationssysteme, Einspritzung, Komfortfunktionen Weiße Ware: Mikrowelle, Waschmaschine, Reis-Kocher Spielzeug: Tamagoshi, sprechende Puppen, funkgesteuertes Spielzeug 8 Acronym aus: The Real-time Operating system Nucleus Dieter Zöbel TRON-Prinzipien: vorrangig Vorrangige Ziele: höchstmögliche Leistung des zugrundeliegenden Mikroprozessor- oder Mikrocomputersystems Anpassungsfähikeit an spezielle (integrierte) Peripherie hohe Software-Produktivität durch ein spezielles (Lern- und) Beschreibungskonzept der Systemaufrufe Kostenminimierung im Hardware- Bereich (Größenordnung: wenige Euros) Amortisierung der Entwicklungskosten durch hohe Stückzahlen Dieter Zöbel

20 TRON-Prinzipien: nachrangig Nachrangiges Ziel: Portabilität von Software Typische Rechnerplattformen 9 : Mikrocontroller MCU (micro controller units): Prozessor, RAM, ROM, A/D-Wandler, weitere Peripherie auf dem Chip (z.b. 32KByte ROM und 1KByte RAM) Mikroprozessoren MPU (micro processor units) Unterstützte Bitbreiten: 4, 8, 16, 32 9 Beobachtung: Die Anzahl der verbauten MCUs ist etwa 10-mal so hoch wie die Zahl der verbauten MPUs (letztere z.b. in PCs) Dieter Zöbel TRON Standards Bereiche: Scheduling, Synchonisierung, Fehler-Codes, Terminologie Bsp.: Aufrufe nach dem Schema xxx yyy cre tsk Erzeugen eines Prozesses wup tsk Wecken eines Prozesses Mailboxen Semaphore Anpassung an den Prozessor Semaphore dyn. Speicherverwaltung dis int Sperren von Interrupts set tim Setzen eines Weckers wai sem P-Operation auf ein Semaphor Prozessverwaltung Prozessverwaltung Prozessverwaltung Reduktion auf die Erfordernisse der Anwendung Semaphore dyn. Speicherverwaltung Ereignissignalisierung Ereignissignalisierung Ereignissignalisierung Anpassung der µitron-spezifikation an den Prozessor und die Anwendung Dieter Zöbel

21 7.7.5 OSEK/VDX Ziele von OSEK 10 /VDX: Portabilität und Wiederverwendbarkeit (gezielt für Software-Anwendungen in Kraftfahrzeugen) Spezifikation abstrakter Schnittstellen bzgl. Echtzeitanforderungen, Kommunikation und Netzwerkmanagement Spezifikation abstrakter Schnittstellen zur Hardware Skalierbarkeit der Implementierung auf das von der Anwendung aus Notwendige Verifikation der Funktionalität Partner (u.a.): Autoindustrie: BMW, Opel, Mercedes, Volkswagen, Renault, Fiat, Volvo Elektroindustrie und Zulieferer: Siemens, Philips, SGS Thomson, Hella, Lucas, Bosch EDV: Windriver Systems, Integrated Systems Wissenschaft: Universität Karlsruhe 10 Akronym für ooffene Syteme und deren Schnittstelle zur Elektronik im Kraftfahrzeug Dieter Zöbel automotive Merkmale vollkommene Statik des Betriebssystems (z.b. alle Betriebsmittel und Synchronisierungsobjekte vorab bekannt) statische Prioritätsvergabe und Prioritätsobergrenzen (PIP) präzises Modell für die Prozessausführung und Unterbrechungsbehandlung (3 Kategorien von Unterbrechungsroutinen) generative Erzeugung der Laufzeitumgebung Reduzierbarkeit auf RAM/ROM- Anwendungen Anpassbarkeit an kleinste Prozessoren ( 8 Bit) hoch feste Prioritaet niedrig Untrebrechungsbehandlung Systemfunktionen Bereich der Anwendungsprozesse Prozessmodell unter OSEK/VDX Dieter Zöbel

22 Literaturverzeichnis [ABRW91] N. C. Audsley, A. Burns, M. F. Richardson, and A. J. Wellings. Hard realtime scheduling: The deadline monotonic approach. In Proc. 8th IEEE Workshop on Real-Time Operating Systems and Software, Atlanta, May [Ber02] [But97] [Der74] Arnold Berger. Embedded Systems Design. CMP Books, Lawrence, Kansas 66046, G. C. Buttazzo. Hard Real-Time Computing Systems: Predictable Scheduling, Algorithms and Applications. Kluwer Academic Publishers, Michael L. Dertouzos. Control robotics: The procedural control of physical processes. IFIP Congress, pages , LITERATURVERZEICHNIS [DIfN85] Deutsches Institut für Normung. Informationsverarbeitung Begriffe, DIN Beuth-Verlag, Berlin, Köln, [FGG + 91] Borko Furht, Dan Grostick, David Gluch, Guy Rabbat, John Parker, and Meg McRoberts. Real-Time UNIX Systems: Design and Application Guide. Kluwer Academic Publishers, Boston, [GJ79] Michael R. Garey and David S. Johnson. Computers and Intractability. A Guide to the Theory of NP-Completeness. W. H. Freeman and Company, New York, San Francisco, [Her91] R. G. Herrtwich. Betriebsmittelvergabe unter Echtzeitgesichtspunkten. Informatik-Spektrum, 14(2): , [Hor74] W. A. Horn. Some simple scheduling algorithms. Naval Research Logistics Quaterly, 21: , Dieter Zöbel

23 LITERATURVERZEICHNIS [Jac55] [Kop97] J. R. Jackson. Scheduling a production line to minimize maximum tardiness. Technical report, Mgt. Sci. Res. Project, Resch. Rept. 43, UCLA, January Hermann Kopetz. Real-Time Systems - Design Principles for Distributed Embedded Applications. Kluwer Academic Publishers, Boston, [Lap93] Phil Laplante. Real-Time Systems Design and Analysis: An Engineer s Handbook. IEEE Press, New York, [Lie96] [LL73] Jochen Liedtke. Toward real microkernels. Communications of the ACM, 39(9):70 77, September C. L. Liu and James W. Layland. Scheduling algorithms for multiprogramming in a hard-real-time environment. Journal of the ACM, 20(1):46 61, January 73. [LSD89] J. P. Lehoczky, L. Sha, and Y. Ding. The rate monotonic scheduling algorithm: Exact characterization and average case behavior exact charac- Dieter Zöbel LITERATURVERZEICHNIS terization and average case behavior. In Proceedings of thetenth IEEE Symposium on Real-Time Systems, pages , December [Qnx97] QNX Operating System. QNX Software Systems Ltd., Kanata, Ontario, Canada, [RL93] Ulrich Rembold and Paul Levi. Realzeitsysteme zur Prozeßautomatisierung. Hanser Verlag, München, [Sak98] [Var98] Ken Sakamura. muitron 3.0 An open and portable real-time operation system for embedded systems. Los Alamitos, California, USA, ieee computer society press edition, Victor Varshavsky. Time, timing and clock in massively parallel computing systems. In Third International Conference on Massively Parallel Computing Systems (PCS98), Colorado Springs, Colorado, April Dieter Zöbel

24 LITERATURVERZEICHNIS [ZA95] [ZH88] Dieter Zöbel and Wolfgang Albrecht. - Grundlagen und Techniken. Lehrbuch. International Thomson Publishing Company, Bonn, Albany, Dieter Zöbel and Horst Hogenkamp. Konzepte der parallelen Programmierung. Teubner-Verlag, Stuttgart, Dieter Zöbel