Dieter Zöbel Universität Koblenz-Landau Fachbereich Informatik, Institut für Softwaretechnik
Inhaltsverzeichnis 1 Einführung 1 1.1 Merkmale von Echtzeitsystemen........ 2 1.1.1 Harte und weiche Echtzeitbedingungen 5 1.1.2 Determiniertheit und Vorhersagbarkeit. 10 1.1.3 Sicherheit und Zuverlässigkeit..... 11 1.2 Das Grundmodell eines Echtzeitsystems.... 15 1.2.1 Paradigmatische Beispiele....... 16 1.2.2 Aktionen und Akteure.......... 19 1.2.3 Eingebettete Systeme.......... 20 1.3 Prozesse..................... 25 1.3.1 Rechenprozesse............. 26 1.3.2 Regelungstechnik............ 30 1.4 Echt und Zeit................... 32 1.4.1 Schnelligkeit und Rechtzeitigkeit.... 33 1.4.2 Zeit auf dem Rechensystem....... 36 1.4.3 Echtzeit.................. 39 1.5 Beispiele..................... 40 2 Echtzeitplanung 44 2.1 Grundlagen der Echtzeitplanung........ 45 2.1.1 Prozessmodelle............. 46 2.1.2 Prozessparameter............ 53 2.1.3 Echtzeitplanung............. 59 2.2 Planen durch Suchen.............. 67 2.3 Planen nach Fristen............... 72 2.4 Planen nach Spielräumen............ 82 2.5 Planen nach festen Prioritäten......... 85 2.6 Planen nach monotonen Raten......... 87 2.7 Planen nach monotonen Fristen........ 96 2.8 Zyklische Planungsverfahren.......... 100 2.9 Vergleich der Planungsverfahren........ 102 3 Betriebssysteme 106 3.1 Merkmale von Echtzeitbetriebssystemen.... 107 3.2 Aufbauprinzipien................. 115 3.3 Speicherverwaltung............... 120 3.4 Datei und Geräteverwaltung........... 124 i
3.5 Treiber....................... 128 3.6 Unterbrechungen................. 132 3.7 Beispiele für Echtzeitbetriebssysteme..... 135 3.7.1 Solaris................... 136 3.7.2 VxWorks................. 137 3.7.3 QNX.................... 139 3.7.4 POSIX................... 142 3.7.5 µitron.................. 147 3.7.6 OSEK/VDX................ 0 4 Synchronisierung 2 4.1 Grundlagen.................... 3 4.2 Prioritätsumkehr................. 13 4.3 Prioritätsvererbung................ 17 4.4 Prioritätsobergrenzen.............. 21 4.5 Übersicht zur Prioritätsinversion........ 24 5 Rechnernetze 26 5.1 Grundlagen.................... 27 5.1.1 Formale Strukturen von Rechnernetzen 28 5.1.2 Aufbau von Rechnernetzen....... 30 5.1.3 Drahtgebundene und drahtlose Rechnernetze................. 38 5.2 Zugriffsprotokolle................. 39 5.2.1 Zentralisierte Verfahren......... 40 5.2.2 Arbitrationsverfahren........... 41 5.2.3 Markengesteuerte Verfahren...... 43 5.2.4 Zeitmultiplex-Verfahren......... 44 5.2.5 Modifikation nicht echtzeitfähiger Zugriffsprotokolle.............. 45 5.3 Abschätzung der Echtzeiteigenschaften.... 50 5.3.1 Prozesse und Zugriffsprotokolle.... 51 5.3.2 Zeitgesteuerte Zugriffsprotokolle.... 57 5.3.3 Arbitrierende Zugriffsprotokolle..... 61 5.3.4 Markengesteuerte Zugriffsprotokolle.. 71 6 Modellbildung 76 6.1 Entwurfsmuster.................. 77 6.2 Modellierungssprachen und Zustandsautomaten 81 6.3 Logiken und Algebren.............. 82 6.4 Petri-Netze.................... 83 7 Zeiten und Uhren 84 7.1 Echtzeit und physikalische Zeit......... 85 7.2 Uhren und Wecker................ 90 7.3 Uhrsynchronisierung............... 97 7.4 Ausführungzeiten von Anweisungen...... 103 7.5 Ableitung von Zeitbedingungen......... 104 ii
8 Rechnerarchitekturen und Prozessoren 105 9 Programmiersprachen 106 10 Softwaretechnik 107 11 Nachlese 108 iii
Kapitel 3 Betriebssysteme Merkmale von Echtzeitbetriebssystemen Aufbauprinzipien Speicherverwaltung Datei- und Geräteverwaltung Treiber Unterbrechungsbehandlung Beispiele für Echtzeitbetriebssysteme 106
3.1. MERKMALE VON ECHTZEITBETRIEBSSYSTEMEN 3.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 3.1.0-1 2
Kategorisierung von Echtzeitbetriebssystemen 3.1. MERKMALE VON ECHTZEITBETRIEBSSYSTEMEN Echtzeitbetriebssysteme z.b. QNX, psos, irmx, REAL/IX, LynxOS, AIX, Solaris, VxWorks, RT-Linux(e) 1, WindowsCE, OSEK,... Laufzeitsysteme z.b. RTKernel, C Executive, Ada runtime system, real-time JVM (Java Virtual Machine), rtos-uh Pearl Standardschnittstellen z.b. POSIX, ITRON 1 RT-Linux vonfinite State Machine Labs., Kurt-Linux, RTAI, Embedix Dieter Zöbel 3.1.0-2 3
Merkmale von Echtzeitbetriebssystemen 3.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 3.1.0-3 4
Folgerungen aus dem Mehrprogrammbetrieb 3.1. MERKMALE VON ECHTZEITBETRIEBSSYSTEMEN Bereitstellung von Synchronisierungsoperationen (und entsprechenden Konzepten) auf Anwendungsebene Abschottung der (schwergewichtigen) Prozesse gegeneinander Anwendungsspezifische Vergabe von (statischen oder dynamischen) Prioritäten Bereitstellung von Operationen (und Konzepten) gegen die Prioritätsumkehr Dieter Zöbel 3.1.0-4 5
Genealogie der Echtzeitbetriebssysteme Kategorisierungsschemata 3.1. MERKMALE VON ECHTZEITBETRIEBSSYSTEMEN Grad der Offenlegung: proprietär (z.b. irmx) offen 2 (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) 2 offen in dem Sinne, dass es herstellerunabhängige Standards wie POSIX.4 erfüllt Dieter Zöbel 3.1.0-5 6
Entwicklungslinien von Echtzeitbetriebssytemen 3.1. MERKMALE VON ECHTZEITBETRIEBSSYSTEMEN 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 3.1.0-6 7
3.1. 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 3.1.0-7 8
Wie wird UNIX ein Echtzeitbetriebssystem? 3.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 1003.1 und POSIX 1003.4 Dieter Zöbel 3.1.0-8 9
3.2. AUFBAUPRINZIPIEN 3.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 3.2.0-1 10
3.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 3 ) 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. [27]) 3 (engl.: inter-process communication) Dieter Zöbel 3.2.0-2 11
Interprozesskommunikation (IPC) Paradigma: Ein Betriebssystem und die umgebenden Anwenderprozesse kommuniziern mittels Nachrichten (transparent realisiert durch den Kern) miteinander. 3.2. AUFBAUPRINZIPIEN Zentrale Aufgabe des Kerns: Abwicklung der Nachrichtenübertragung Anwenderprozess...... Dienstprozess Vorteile: homogener Systemaufbau: Es gibt nur Prozesse. Mikrokern klare Objektstruktur: Dientleistung und damit Datenmanipulation nur durch Methodenaufrufe an das Dienstleistungsobjekt. Dieter Zöbel 3.2.0-3 12
Beispiel: Mikrokernarchitektur von QNX 3.2. AUFBAUPRINZIPIEN Prozess Prozess Prozess Netzanbindung Scheduler Interprozesskommunikation Interrupt Redirector Netzwerkschnittstelle Minimaler Umfang des Kerns für einbettete Anwendungen: 130KByte (nach Angaben von QNX: 64KByte [1]). Zusätzlich: IDE-Treiber 40KByte, Plattentreiber (fdisk) 130KByte Dieter Zöbel 3.2.0-4 13
Virtualisierung von Betriebssystemen 3.2. AUFBAUPRINZIPIEN Unter der Virtualisierung eines Betriebssystems versteht man die Bereitstellung einer Hardwareumgebung (Prozessor, Peripherie) die in Wirklichkeit ein unterlegtes Betriebssystem ist. Implementierung: Virtual Machine Monitor schaltet die Hardwareumgebung zwischen den Betriebssystemen um. Dieter Zöbel 3.2.0-5 14
3.3. SPEICHERVERWALTUNG 3.3 Speicherverwaltung Die Speicherverwaltung ist eine zentrale Aufgabe von Betriebssystemen, die bei Echtzeitsystemen oft auf wenige Grundfunktionen reduziert ist. Sei #S der zur Verfügung stehende Hauptspeicher und #P der Speicher, der von der Summe aller Prozesse und vom Betriebssystem beansprucht wird. Adressierungsformen: direkte Adressierung (keine Abschottung der Arbeitsspeicher der Prozesse untereinander, es muss gelten #S > #P ) Swapping bei Prozessumschaltung (es kann gelten #S < #P ) MMU 4 -basierte Seitenverwaltung (vom Betriebssystem zu unterstützende Abschottung der Arbeitsspeicher der Prozesse bzw. des Betriebssystems, es muss gelten #S > #P ) virtuelle Adressierung (es kann gelten #S < #P ) 4 Memory Management Unit Dieter Zöbel 3.3.0-1 15
Virtuelle Adressierung Echtzeitsysteme 3.3. SPEICHERVERWALTUNG Große Teile des virtuelle Adressraums eines Prozesses sind auf Hintergrundspeicher (Platte) ausgelagert. Lauffähigkeit großer Programme Schutz der Prozesse untereinander Segment- und/oder Seitenverwaltung basierend auf einer MMU (memory management unit) Seitenaustauchverfahren (Dauer 200.000 Zugriffe auf den Hauptspeicher) Probleme bzgl. Vorhersagbarkeit Beim Anlaufen des Programms werden die Daten nach Bedarf nachgeladen. Beim laufenden Betrieb kommt es zu unverhofften und nicht reproduzierbaren Seitenaustauschen. Nach eine Prozessumschaltung sind die benötigten Seiten durch zwischenzeitliche Auslagerung vom Hintergrundspeicher nachzuladen. Dieter Zöbel 3.3.0-2 16
3.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 (z.b. gezielt Markierung von Seiten, die nicht ausgelagert werden dürfen 5 ) Vermeiden des Kopierens von großen Datenmengen zwischen Prozessen 5 pinning Dieter Zöbel 3.3.0-3 17
Beispiele für eine vorhersagbare Speicherverwaltung 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 Bsp.: Entsprechende Befehle unter POSIX 1003.1b: mlock() Verbieten des Austauschs einer Seite (pinning) munlock() Aufheben des Verbots mlockall() Verbieten des Austauschs aller Seiten eines Prozesse munlockall() Aufheben des Verbots 3.3. SPEICHERVERWALTUNG Dieter Zöbel 3.3.0-4 18
3.4. DATEI UND GERÄTEVERWALTUNG 3.4 Datei und Geräteverwaltung 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 3.4.0-1 19
3.4. DATEI UND GERÄTEVERWALTUNG Vorhersagbare Zugriffszeiten Klassische Verfahren ohne Vorhersagbarkeit: FCFS (first come, first served) SSTF (shortest seek time first) SCAN (seq. Suchen nach der nächsten Spur) Ziele unter Echtzeitgesichtspunkten: Einhalten der Fristen Vermeiden von Übertragungslücken hoher Grad an paralleler Auftragsabwicklung 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 3.4.0-2 20
3.4. DATEI UND GERÄTEVERWALTUNG 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 3.4.0-3 21
3.4. DATEI UND GERÄTEVERWALTUNG Strategie für Plattengeräte mit eigener Auftragsschlange Häufige Situation: eine vom Betriebssystem verwaltete Schlange A, deren Strategie beeinflusst werden kann, und ein Plattengerät 6, das eine vom Hersteller optimiertes Verfahren mit eigener Schlange B besitzt. Das Verfahren des Herstellers ist üblicherweise weder bekannt noch direkt beeinflussbar. Einzige Möglichkeit ist die Zugrangskontrolle von Schlange A nach Schlange B. Strategie [38]: Echtzeiteigenschaften durch das Prinzip der gezielten Austrocknung (draining out), d.h. die Schlange B besitz nur eine begrenzte Anzahl von Plätzen und ein zeitkritischer Auftrag geht sofort von A nach B, wobei kein weiterer Auftrag nachrücken darf, bis der zeitkritische bedient wurde. 6 typisch im Bereich der customer of the shelf (COTS)-Produkte Dieter Zöbel 3.4.0-4 22
3.5. TREIBER 3.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 3.5.0-1 23
3.5. TREIBER Anstoßen des Treibers Man unterscheidet (vgl. [32]) 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 3.5.0-2 24
Auswirkungen der Mikrokern-Architektur 3.5. TREIBER Entwicklungsprinzipien 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 3.5.0-3 25
Übertragung von Nutzdaten vom Hauptspeicher zum Gerät 3.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 3.5.0-4 26
3.6. UNTERBRECHUNGEN 3.6 Unterbrechungen Grundsätzliche Zielsetzung: Unterbrechung des normalen Ablaufs durch eine vorrangige Verarbeitung. Klassen von Unterbrechungen Asynchron (interrupts) z.b.: Timerinterrupt Meldung eines Spannungsausfalls Abschluss des Plattenzugriffs Abschluss des Sendens einer Nachricht Synchron (traps) z.b.: arithmetische Fehler Seitenfehler Verletzung des Speicherschutzes Systemaufrufe Dieter Zöbel 3.6.0-1 27
Schritte bei der Unterbrechungsbehandlung Ablauf 3.6. UNTERBRECHUNGEN 1. Der Prozessor beendet die Ausführung des letzten Befehls (Unterbrechung 7 des aktuellen Prozesses). 4. Durch einen speziellen Befehl wird die Rückkehr vom Unterbrechungsprozess zum aktuellen Prozess durchgeführt. 2. Die Ausführung des Prozessors wird auf den Unterbrechungsprozess umgeschaltet. Treiber ISR Betriebssystem 3. Der Unterbrechungsprozess (ISR 8 ) wird ausgeführt. Ein-/Ausgabegerät Hardware Der Unterbrechungsprozess kann aus programmiertechnischer Sicht als eine Komponente der Hardware aufgefasst werden 7 Man unterscheidet asynchrone Unterbrechungen (engl.: interrupt) von synchronen Unterbrechungen (engl.: traps) 8 (engl.: interrupt service routine) Dieter Zöbel 3.6.0-2 28
3.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 VxWorks auf eienem 300 MHz PowerPC 604: 25.2µs Bsp.: unter RTLinux auf eienem 300 MHz PowerPC 604: 196.8µs Bsp.: unter QNX auf einem 33MHz Intel 386: 15µs Bsp.: unter QNX auf einem 133MHz Intel Pentium: 4.3µs Bsp.: unter WindowsCE auf einem 59MHz Odo SH3: 1300 7500µs Strategie: Abarbeitung der ISR als Prozess des Echtzeitbetriebssystems Verzögerung für einen höher priorisierten Prozess: die Unterbrechungslatenz Dieter Zöbel 3.6.0-2 29
3.7. BEISPIELE FÜR ECHTZEITBETRIEBSSYSTEME 3.7 Beispiele für Echtzeitbetriebssysteme Hier wird exemplarisch auf bedeutende Echtzeitbetriebssysteme und Betriebssystem- Schnittstellen Bezug genommen: Solaris VxWorks QNX POSIX µitron OSEK/VDX Dieter Zöbel 3.7.0-1 30
3.7. BEISPIELE FÜR ECHTZEITBETRIEBSSYSTEME 3.7.1 Solaris Merkmale: Universalbetriebssystem unterbrechbarer Kern Threadkonzept klassenspezifische Prioritäten Mehrprozessorfähigkeit Synchronisierungsobjekte: mutex, r/w-lock, counting semaphor, condition variable Prioritätsvererbung 159 99 59 0 Interrupt Threads Realtime Threads System Threads Timescliced Threads fixed priorities dynamic priorities Prozessklassen von Solaris Dieter Zöbel 3.7.1-1 31
3.7. BEISPIELE FÜR ECHTZEITBETRIEBSSYSTEME 3.7.2 VxWorks Merkmale von VxWorks AE1.1: Prozesskonzept: Threads mit kritischen Gebieten Prioritätsebenen: 256 Verplanung: Round Robin oder prioritätsbasierte Prozessumschaltung Speicherverwaltung: Unterstützt eine MMU-basierte Seitenverwaltung ohne Seitenaustausche (demand paging) Speicherschutz: Voller Schutz im Sinne der virtuellen Adressierung (in vorangegangen Versionen gab es noch keinen Schutz) Unterbrechungen: Systemweiter Stapel für Unterbrechungsverwaltung Treiber: spezielle Behandlung der Treiber außerhalb der Prozessverwaltung Synchrinisierung: Semaphore, Nachrichten, Puffer und Signale Dieter Zöbel 3.7.2-1 32
VxWorks als typisches Host-Target System 3.7. BEISPIELE FÜR ECHTZEITBETRIEBSSYSTEME Tornado heißt die integrierte Entwicklungsumgebung für die Cross- Entwicklung. Sie besteht aus: VxWorks, dem Echtzeitbertiebssystem für das Zielsystem, z.b. eine MVME147e-Board mit einem MC68030-Prozessor eigene Bibliothek von Systemaufrufen, beispielsweise für die Erzeugung paralleler Prozesse pid=taskspawn(...,procedure(),...); einer Kommunikationsverbindung vom Wirtssystem zum Zielsystem, z.b. via Ethernet und TCP/IP Einer Entwicklungsumgebung auf dem Wirtssystem mit Editor, Compiler Lader und Debugger Weitere Testwerkzeuge wie ein Logik- Analysator Dieter Zöbel 3.7.2-2 33
3.7. BEISPIELE FÜR ECHTZEITBETRIEBSSYSTEME 3.7.3 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 3.7.3-1 34
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. 3.7. BEISPIELE FÜR ECHTZEITBETRIEBSSYSTEME Logdaten Laserdaten Steuerung 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 Fahrdaten Antrieb, Lenkung Funktionale Zerlegung von EZauto Dieter Zöbel 3.7.3-2 35
Entwurf mit Briefkästen Echtzeitsysteme 3.7. BEISPIELE FÜR ECHTZEITBETRIEBSSYSTEME 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 3.7.3-3 36
3.7. BEISPIELE FÜR ECHTZEITBETRIEBSSYSTEME 3.7.4 POSIX Ziel: Schaffung von Kompatibilitäten, was die Portabilität von Code Programmen Daten (im Rahmen von Kommunikation) angeht. Wichtigster Standard für Echtzeitsysteme: POSIX 9 Zielsetzung der IEEE: Definition einer anwendungsspezifischen Programmierschnittstelle (API 10 ) zum Betriebssystem (nicht notwendigerweise UNIX) 9 (engl.: portable operating system interface for computer environments) 10 (engl.: application programmers interface) Dieter Zöbel 3.7.4-1 37
Wichtige POSIX-Standards Echtzeitsysteme 3.7. BEISPIELE FÜR ECHTZEITBETRIEBSSYSTEME 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.1...... 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 3.7.4-2 38
POSIX.1b Echtzeitsysteme Real-time extensions (IEEE Std 1003.1b-1993) Priority Scheduling Real-Time Signals Clocks and Timers Semaphores Message Passing Shared Memory Asynch and Synch I/O Memory Locking Interface 3.7. BEISPIELE FÜR ECHTZEITBETRIEBSSYSTEME Dieter Zöbel 3.7.4-3 39
POSIX.4 Echtzeitsysteme Threads extensions (IEEE Std 1003.1c-1995) Thread 11 -Konzept prioritätsbasierte Prozessausführung Semaphore hauptspeicherresidente Prozesse gemeinsamer Hauptspeicher für Prozesse Echtzeituhren asynchrone Ein/Ausgabe 3.7. BEISPIELE FÜR ECHTZEITBETRIEBSSYSTEME 11 dt. Faden Dieter Zöbel 3.7.4-4 40
Vergleich von Prozessen mit Threads 3.7. BEISPIELE FÜR ECHTZEITBETRIEBSSYSTEME 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 3.7.4-5 41
3.7. BEISPIELE FÜR ECHTZEITBETRIEBSSYSTEME 3.7.5 µitron Ansatz: Offener Standard für die Entwicklung kleiner und kleinster engebetteter Systeme (Japan seit 1984, z.zt. Version 3.0 [34]) TRON 12 -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 12 Acronym aus: The Real-time Operating system Nucleus Dieter Zöbel 3.7.5-1 42
TRON-Prinzipien: vorrangig Vorrangige Ziele: Echtzeitsysteme 3.7. BEISPIELE FÜR ECHTZEITBETRIEBSSYSTEME 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 3.7.5-2 43
TRON-Prinzipien: nachrangig Echtzeitsysteme Nachrangiges Ziel: Portabilität von Software 3.7. BEISPIELE FÜR ECHTZEITBETRIEBSSYSTEME Typische Rechnerplattformen 13 : 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 13 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 3.7.5-3 44
TRON Standards Echtzeitsysteme 3.7. BEISPIELE FÜR ECHTZEITBETRIEBSSYSTEME Bereiche: Scheduling, Synchonisierung, Fehler-Codes, Terminologie Bsp.: Aufrufe nach dem Schema xxx yyy Prozessverwaltung Mailboxen Semaphore dyn. Speicherverwaltung Ereignissignalisierung cre tsk Erzeugen eines Prozesses wup tsk Wecken eines Prozesses Prozessverwaltung Anpassung an den Prozessor Semaphore dyn. Speicherverwaltung Ereignissignalisierung wai sem P-Operation auf ein Semaphor Prozessverwaltung Reduktion auf die Erfordernisse der Anwendung Semaphore Ereignissignalisierung dis int Sperren von Interrupts set tim Setzen eines Weckers Anpassung der µitron-spezifikation an den Prozessor und die Anwendung Dieter Zöbel 3.7.5-4 45
3.7. BEISPIELE FÜR ECHTZEITBETRIEBSSYSTEME 3.7.6 OSEK/VDX Ziele von OSEK 14 /VDX 15 : 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 14 Akronym für Offene Syteme und deren Schnittstelle zur Elektronik im Kraftfahrzeug 15 Akronym für Vehicle Distributed Executive Dieter Zöbel 3.7.6-4 46
3.7. BEISPIELE FÜR ECHTZEITBETRIEBSSYSTEME 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 3.7.6-5 47
[7] Enrico Bini, Giorgio Buttazzo, and Giuseppe Buttazzo. Rate monotonic scheduling: The hyperbolic bound. IEEE Transactions on Computers, 52(7):933 942, July 2003. Literaturverzeichnis [1] QNX Operating System. QNX Software Systems Ltd., Kanata, Ontario, Canada, 1997. [2] G. R. Andrews. Concurrent Programming. The Benjamin/Cummings Publishing Company, 1991. [3] N. Audsley, A. Burns, M. Richardson, K. Tindell, and A. Wellings. Absolute and relative temporal constraints in hard realtime databases. In Proc. of IEEE Euromicro Workshop on Real Time Systems, February 1992. [4] N. C. Audsley, A. Burns, M. F. Richardson, and A. J. Wellings. Hard real-time scheduling: The deadline monotonic approach. In Proc. 8th IEEE Workshop on Real-Time Operating Systems and Software, Atlanta, May 1991. [5] Algirdas Avizienis, Jean-Claude Laprie, Brian Randell, and Carl E. Landwehr. Basic concepts and taxonomy of dependable and secure computing. IEEE Trans. Dependable Sec. Comput., 1(1):11 33, 2004. [6] Arnold Berger. Embedded Systems Design. CMP Books, Lawrence, Kansas 66046, 2002. [8] Giorgio C. Buttazzo. Hard Real-Time Computing Systems: Predictable Scheduling, Algorithms and Applications. Kluwer Academic Publishers, 1997. [9] Anton Cervin and Johan Eker. Control-scheduling codesign of real-time systems: The control server approach. Journal of Embedded Computing, 1(2):209 224, 2005. [10] Robert I. Davis, Alan Burns, Reinder J. Bril, and Johan J. Lukkien. Controller area network (CAN) schedulability analysis: Refuted, revisited and revised. Rael-Time Systems, 35(0):239 272, January 2007. [11] Michael L. Dertouzos. Control robotics: The procedural control of physical processes. IFIP Congress, pages 807 813, 1974. [12] Deutsches Institut für Normung. Informationsverarbeitung Begriffe, DIN 43000. Beuth-Verlag, Berlin, Köln, 1985. [13] Deutsches Institut für Normung. Funktionale Sicherheit sicherheitsbezogener elektrischer/elektronischer/programmierbarer elektronischer Systeme, DIN 61508-5. VDE-Verlag, Berlin, 1998. [14] Stuart Faulk, John Brackett, Paul Ward, and James Kirby. The core method for real-time requirements. IEEE Software, 9:22 33, September 1992. [15] Hugo Fierz. Eingebettete Systeme als Architektur mechanistischer Modelle. www.ciptool.ch/data/cip mech.pdf, Zürcher Hochschule Winterthur.
LITERATURVERZEICHNIS [16] 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, 1991. [17] 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, 1979. [18] W. A. Halang and R. Konakovsky. Sicherheitsgerichtete Echtzeitsysteme. Oldenbourg-Verlag, München, 1999. [19] Fred Halsall. Data communications, computer networks, and open systems. Addison-Wesley, third edition, 1992. [20] R. G. Herrtwich. Betriebsmittelvergabe unter Echtzeitgesichtspunkten. Informatik-Spektrum, 14(2):123 136, 1991. [21] R. G. Herrtwich and G. Hommel. Kooperation und Konkurrenz. Nebenläufige, verteilte und echtzeitabhängige Programmsysteme. Springer-Verlag, Berlin, 1989. [22] W. A. Horn. Some simple scheduling algorithms. Naval Research Logistics Quaterly, 21:177 185, 1974. [23] Hermann Kopetz. Real-Time Systems - Design Principles for Distributed Embedded Applications. Kluwer Academic Publishers, Boston, 1997. [24] Th. S. Kuhn. Die Struktur der wissenschaftlichen Revolutionen. Suhrkamp Verlag, Frankfurt, 1969. [25] Phil Laplante. Real-Time Systems Design and Analysis: An Engineer s Handbook. IEEE Press, New York, 1993. [26] J. P. Lehoczky, L. Sha, and Y. Ding. The rate monotonic scheduling algorithm: Exact characterization and average case behavior. In Proceedings of the 10th IEEE Symposium on Real- Time Systems, pages 166 171, December 1989. [27] Jochen Liedtke. Toward real microkernels. Communications of the ACM, 39(9):70 77, September 1996. [28] 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. [29] Peter Marwedel. Eingebettete Systeme. Springer-Verlag, Berlin, 2007. [30] A. K. Mok. Fundamental design problems of distributed systems for the hard-real-time environment. PhD thesis, Massachusetts Institute of Technology, 1983. [31] Philipp Nenninger. Vernetzung verteilter sicherheitsrelevanter Systeme im Kraftfahrzeug. Dissertation, Universität Karlsruhe, 2007. Dieter Zöbel 11.0.0-1 1
LITERATURVERZEICHNIS [32] Ulrich Rembold and Paul Levi. Realzeitsysteme zur Prozeßautomatisierung. Hanser Verlag, München, 1994. [33] Sebastian Rieger. Streaming-Media und Multicasting in drahtlosen Netzwerken. Technical Report Nr. 61, Gesellschaft für wissenschaftliche Datenverarbeitung mbh Göttingen, 2003. [34] Ken Sakamura. µitron 3.0 An open and portable real-time operation system for embedded systems. Los Alamitos, California, USA, ieee computer society press edition, 1998. [35] Kenneth C. Sevcik and Marjory J. Johnson. Cyclic time properties of the FDDI token ring protocol. IEEE Transactions on Software Engineering, 13(3):376 385, March 1987. [36] Lui Sha, Ragunathan Rajkumar, and John P. Lehoczky. Priority inheritance protocols: An approach to real-time synchronisation. IEEE Transactions on Computers, 39(9):1175 1185, September 1990. [37] John A. Stankovic. Misconceptions about real-time computing: A serious problem for next generation systems. IEEE Transactions on Computers, 21(10):10 19, 1988. [38] Mark J. Stanovich, Theodore P. Baker, and An-I Andy Wang. Throtteling on-disk schedulers to meet soft-real-time requirements. In Real-Time and Embedded Technology and Application (RTAS 08), pages 331 341, St. Louis, Missouri, April 2008. IEEE Computer Society. [39] A. S. Tanenbaum. Computer Networks. Prentice-Hall International Editions, Englewood Cliffs, NJ, second edition, 1988. [40] Martin Törngren. Fundamentals of implementing real-time control applications in distributed computer systems. Real- Time Systems, 14:219 250, 1998. [41] 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 6-9 1998. [42] Dieter Zöbel. Echtzeitsysteme - Grundlagen der Planung. examen.press. Springer-Verlag, Berlin, 2008. [43] Dieter Zöbel and Wolfgang Albrecht. Echtzeitsysteme - Grundlagen und Techniken. Lehrbuch. International Thomson Publishing Company, Bonn, Albany, 1995. [44] Dieter Zöbel and Horst Hogenkamp. Konzepte der parallelen Programmierung. Teubner-Verlag, Stuttgart, 1988. Dieter Zöbel 11.0.0-1 1