1.5 Betriebssysteme für RT- Anwendungen: Echtzeitbetriebssysteme

Transkript

1 1.5 Betriebssysteme für RT- Anwendungen: Echtzeitbetriebssysteme Warum ein Betriebssystem verwenden? Nutzung eines Betriebssystem hat großen Einfluß auf die Softwarezuverlässigkeit, Produktivität Pflege und Wartung n Temperaturmessung mittels Temperatursensor Digitalisieren der Sensordaten Anzeige der Daten auf einem portablen Display SENSOR ADC CPU DISPLAY n Steuerung der Temperatur in einem Düsentriebwerk eines Flugzeugtriebwerkes (engine jet pipe) Temperaturmessung mittels Sensor resultierendes analoges Signal wird digitalisiert Fehlersignal wird intern in der CPU berechnet Korrektursignal wird zum Treibstoffventil geführt über den DAC Die Einheit hat jedoch weitere Aufgaben zu erfüllen 1. Pilot benötigt Zugriff auf alle Systeminformationen über die Keypad/ Display- Einheit 2. Flugschreiber benötigt dieselben Informationen, die dieser über die serielle Verbindung erhält 1

2 KEYPAD DAC SERIAL I/O SENSOR ADC CPU DISPLAY Lösungen: einfachste Methode: "Single Task"- Methode: Programmierung in einem einzelnen Programmen Komplexität des Real-Time- Computers vom Programmierer abschirmen Detailliertes Wissen über Interrupts, Timer, ADC etc. sind nicht mehr erforderlich Beachte Funktion des Betriebssystems als Ressourcenverwalter. derzeitig kommerziell verfügbare Real-Time- Betriebssysteme verfügen noch nicht über ausreichend Funktionalität, um den Entwickler von Real-Time- Applikationen zu entlasten 1.6 Architektureigenschaften von RTOS 1. Multitasking Strukturierung von Programmen in Tasks Taskimplementierung mit minimaler HW-Kenntnis (Taskimplementierung nicht über Interruptroutinen bzw. TSR- Routinen notwendig) Taskimplementationen als logisch eigenständige Einheiten (Taskabstraktion) 2. Zeitsteuerung Verwendung von Systemressourcen zu vorbestimmten Zeitpunkten Verwendung von Systemressourcen zu zufälligen Zeitpunkten 3. prioritätsbasierte preemptive Ablaufsteuerung 2

3 statische, dynamische Prioritäten online, offline Scheduling 4. Taskkoordinierung Synchronisation und gegenseitiger Ausschluß (Semaphore, Mutex, Condition Variable) Intertaskkommunikation (Mailbox, Shared Memory) 5. Interruptbehandlung, Exceptionbehandlung leistungsfähiges Interruptsystem notwendig Unterstützung durch HW Unterstützung durch SW (BS): ISR, Interrupttasks 6. objektbasierte Architektur Bausteine des BS- Kerns werden Objekte genannt einziger aktiver Objekttyp ist Task (Prozeß, Thread) Beispiele für andere Objekttypen RMX: Job, Task, Semaphor, Mailbox, Segment, Region, Composite, Extension RMOS: Task, Semaphor, Mailbox, Event, Pool, Discretes POSIX: Thread, Mutex, Condition Variables, Semaphore, Signale Beachte: Kriterien für einen guten Schedulingalgorithmus Art wie Maschinen verwendet werden, hat Einfluß auf Entwurf des Betriebssystem bzw. Auswahl des Betriebssystems z.b. Mainframe-Environment ist flüchtig d.h. Anzahl, Komplexität, Größe der bearbeiteten Aufgaben ändert sich ständig und ist zu jedem möglichen Zeitpunkt unbekannt dort steht Durchsatz im Vordergrund z.b. Tasks in Real-Time-Embedded Applikationen sind ziemlich klar gegliedert. Notwendige Effizienz des Betriebssystems (gewisser Grad an Durchsatz ist erforderlich), aber Vorhersagbarkeit der Leistung und Zuverlässigkeit der Operationen entscheidend 3

4 Jet Pipe Temperature Controller Drei Tasks: JPT Steuerung Flugschreibersteuerung Piloteninterface "Quasiparallelität" 3 separate aber abhängige Tasks, daraus resultieren eine Vielzahl von Problemen. Die Lösungen werden durch die Multitaskingsoftware des Betriebssystems geliefert Multitasking Primäre Ziele Ausführung unabhängiger Tasks Ausführung abhängiger Tasks Steuerung der Taskausführung (Reihenfolge, Zeit) Steuerung gemeinsam genutzter Daten Steuerung der Taskausführung (Reihenfolge, Zeit) Steuerung gemeinsam genutzter Daten Unterstützung und Steuerung von Intertaskkommunikation Scheduling Gegenseitiger Ausschluß Scheduling Gegenseitiger Ausschluß Synchronisation u. Datentransfer 1.7 Klassifikation von Echtzeit-(Betriebs)systemen Kriterium: Reaktionszeit: Hard Real-Time Systems Soft Real-Time Systems Kriterium: Standard -Konformität Kombination mit einem Standardbetriebssystem (MS-DOS, UNIX) Einhaltung verabschiedeter internationaler Standards (POSIX, TRON, ORKID) Unterscheidung in offene und proprietäre Echtzeitbetriebssysteme Kriterium: Systemarchitektur zentralisiert verteilt Kriterium: Hardware-Hersteller-Abhängigkeit: Verfügbarkeit des Betriebssystems auf unterschiedlichen Hardware- Plattformen Das Gros der Echtzeitbetriebssysteme sind verfügbar auf Standard-PC- Plattform. 4

5 Kriterium: Trennung zwischen Entwicklungssystem und Zielsystem Host-/Target-Systeme Komplettbetriebssysteme 1.8 Echtzeit-UNIX-Implementationen 1. Hinzufügen von AT& T System V.4 Erweiterungen zu Standard- UNIX 2. Host/ Target- Lösung VxWorks OS Integration eines UNIX- Systems mit einer Echtzeit- Executive VRTX MTOS- UX RTUX CXOS D-NIX REAL/IX 4. Proprietary UNIX AIX LynxOS Regulus 5. Preemption Points RTU HP- UX VENIX 6. Fully preemptive kernel REAL/IX CX/RT SORIX (Wind River Systems) (Microware) (Ready Systems) (IPI) (Emerge System Inc.) (Computer X/Motorola) (Diab Systems) (Modcomp) (IBM) (Lynx Real Time Systems) (SBE) (Concurrent Masscomp) (Hewlett Packard) (Ventur Com) (AEG-MODCOMP) (Harris) (Siemens) 5