Seminarthema: Realzeitbetriebssysteme. Projektgruppe: Airbag

Transkript

1 Seminarthema: Realzeitbetriebssysteme Projektgruppe: Airbag

2 Gliederung: Was bedeutet Realzeit? / Was ist ein Betriebssystem? Wie ist ein Realzeitbetriebssystem charakterisiert? Wie ist ein Betriebssystem aufgebaut? Wie funktionieren die einzelnen Teile eines Betriebssystems? Was ist OSEK/VDX? Beispiele für OSEK/VDX konforme Realzeitbetriebssysteme. Marktübersicht und abschließende Bemerkungen zu Realzeitbetriebssystemen. Projektgruppe: Airbag, Semiarvortrag: Realzeitbetriebssysteme, Autor: Nils Grunwald, Oktober

3 DIN Definitionen: Realzeitbetrieb: Ein Betrieb eines Rechnersystems, bei dem Programme zur Verarbeitung anfallender Daten ständig betriebsbereit sind, derart, daß die Verarbeitungsergebnisse innerhalb einer vorgegebenen Zeitspanne verfügbar sind. Die Daten können je nach Anwendungsfall nach einer zeitlich zufälligen Verteilung oder zu vorbestimmten Zeitpunkten anfallen. Betriebssystem: Die Programme eines digitalen Rechensystems, die zusammen mit den Eigenschaften der Rechenanlage die Grundlage der möglichen Betriebsarten des digitalen Rechensystems bilden und insbesondere die Abwicklung von Programmen steuern und überwachen. OSEK-Definition Realzeitbetriebssystem: Ein Betriebssystem, das die Ausführung eines Programmteils in einer definierten Zeit, die hauptsächlich durch externe Geschehnisse bestimmt wird, sicherstellt. Projektgruppe: Airbag, Semiarvortrag: Realzeitbetriebssysteme, Autor: Nils Grunwald, Oktober

4 Schichtenmodell eines Betriebssystems: Bestandteile eines Betriebssystems: Anwendungstasks Kommandointerpreter/ Laufzeitsystem Programmallokation/ Dateiverwaltung: E/A-Steuerung: Betriebssystemkern: Zielhardware Arbeitsspeicherverwaltung (memory manager) I/O-Handling Geräteverwaltung Taskkonzept/Scheduler Gerätetreiber M 5..n T 5..n M 4 T 4 M 3 T 3 M 2 T 2 M 1 P 1 M 0 Projektgruppe: Airbag, Semiarvortrag: Realzeitbetriebssysteme, Autor: Nils Grunwald, Oktober

5 Charakterisierung von Realzeitbetriebssystemen: Direkte Kopplung mit mindestens einem Prozeß an der Eingabeseite. Verarbeitung der Prozeßsignale schritthaltend mit ihrer Entstehung. Gleichzeitige Auswertung von Prozeßsignalen oder Meßwerten. Möglichkeit als Antwort auf Eingaben gleichzeitig mehrere Stellglieder zu bedienen. Ein Maß für die Gleichzeitigkeit und Rechtzeitigkeit ist die Systemantwort. Unterscheidung zwischen harten und weichen Echtzeitbedingungen. Fazit: Hauptunterschied zu Standardbetriebssystemen: optimierten Anpassung an die Umgebungsanforderungen. Projektgruppe: Airbag, Semiarvortrag: Realzeitbetriebssysteme, Autor: Nils Grunwald, Oktober

6 Betriebssystemkern: Der Kern besteht aus den drei Hauptkomponenten: Gerätetreiber, Unterbrechungsverarbeitung und dem Dispatcher oder Scheduler. Der Kern ist prozedural und meist in einer Maschinensprache (monolithisch) geschrieben, da seine Bestandteile sehr zeitkritisch sind (Effizienzforderung). Durch diese optimierte Anpassung an die Zielhardware ist das Betriebssystem meist nicht portabel. Heutiger Trend: immer mehr Teile des Systems von der M 1 -Schale in höhere Schalen verlagern. Der Kern besteht zu etwa 70% aus Gerätetreibern. Das Unterbrechungswerk muß die Möglichkeit haben, einzelne Tasks abzubrechen, zwischen ihnen zu wechseln und auf kurzfristig anzuhalten, um auf Unterbrechungen umgehend reagieren zu können. Die Aufgabe des Dispatchers ist es zu entscheiden, wann ein Taskwechsel durchgeführt werden soll. Dabei wird eine prioritätsgestütze Strategie verwendet. Beispiele für diese Strategien sind: Rate Monotonic Algorithmen (RM), Earliest Deadline First (EDF), Minimum Laxity First (MLF), Maximum Urgency First (MUF) oder das einfache Round Robin Verfahren. Der Dispatcher organisiert die Tasks meist in nach Priorität sortierten Warteschlangen. Projektgruppe: Airbag, Semiarvortrag: Realzeitbetriebssysteme, Autor: Nils Grunwald, Oktober

7 Aufgaben: Gerätetreiber: Kontrolle der Ein-/Ausgabe-Geräte. Verwaltung der Kommunikation zwischen diesen Hardwaregeräten und dem Betriebssystem. Anbieten einer homogenen, geräteunabhängigen Schnittstelle für die Datenein-/ausgabe-Operationen. Umsetzung abstrakter, geräteunabhängiger E/A-Anforderungen in gerätespezifische Kommandos. Senden dieser Kommandos an die Steuereinheiten der Geräte. Überwachen der Ausführung der E/A-Operationen an einem Gerät. Zurückliefern der Ergebnisse und der Status-Informationen der E/A- Operationen an die geräteunabhängige Software der E/A-Verwaltung. Projektgruppe: Airbag, Semiarvortrag: Realzeitbetriebssysteme, Autor: Nils Grunwald, Oktober

8 Taskkonzept: Eine Task ist ein ausführbares oder laufendes Programm zusammen mit den dazugehörenden aktuellen Werten des Programmzählers, der Register, der Variablen und den zugehörigen Betriebsmitteln. Projektgruppe: Airbag, Semiarvortrag: Realzeitbetriebssysteme, Autor: Nils Grunwald, Oktober

9 Tasksynchronisation: Da die meisten Betriebsmittel nur exklusiv benutzt werden können, müssen die Zugriffe der verschiedenene Tasks synchronisiert werden. Außerdem arbeiten Tasks häufig zusammen an einer Aufgabe und kooperieren dabei in einer bestimmten Reihenfolge. Man unterscheidet zwischen lokaler und Intertaskkommunikation: Lokale Synchronisationsfunktionen: Wechselseitiger Ausschluß oder Sperrsynchronisation. Kooperation oder Reihenfolgesynchronisation Die Tasksynchronisation wird heute hauptsächlich durch Semaphore (ein Semaphor setzt sich aus einem einfachen Zähler und einer Warteschlange zusammen) und Monitore (sämtliche kritischen Bereiche bezüglich identischer Semaphore werden zusammenfaßt und zentral verwaltet) implementiert. Intertaskkommunikation: Hierfür stellt der Betriebssystemkern üblicherweise zwei Grundoperationen zur Verfügung: SEND (in: Empfängertask-Identifikation, Botschaft) RECEIVE (out: Sendertask-Identifikation, Botschaft) In einem Botschaftensytem sind sowohl die Sendertaks als auch die Empfängertasks autonom. Üblicherweise puffert ein Briefkasten oder ein Port die Botschaften. Projektgruppe: Airbag, Semiarvortrag: Realzeitbetriebssysteme, Autor: Nils Grunwald, Oktober

10 E/A-Verwaltung: Tasks, die Daten über ein Gerät einlesen oder ausgeben möchten, rufen mit einer E/A- Anweisung die E/A-Steuerung auf. Im einzelnen muß die E/A-Steuerung die folgenden Funktionen erfüllen: Symbolsiche Namensgebung, die geräteunabhängig ist, Annahme von E/A-Aufrufen und Rückmeldungen, Vergabe und Freigabe von exklusiv genutzten Geräten, Schutz der Geräte, Abgabe von Transportaufträgen an die Gerätetreiber und Empfang der Treiberrückmeldungen, Pufferung, Geräteunabhängige Blockgröße. Synchronisiert werden können die E/A-Aufträge auf mehrere Arten, wobei die Verfahren des Busy-Waitings, der Programmunterbrechung und des Handshakings am gebräuchlichsten sind. Ein zusätzliches Problem Tritt auf, wenn mehrere Geräte gleichzeitig bedient werden müssen. Projektgruppe: Airbag, Semiarvortrag: Realzeitbetriebssysteme, Autor: Nils Grunwald, Oktober

11 Arbeitsspeicherverwaltung: Koordination sämtliche Zugriffe auf den Arbeitsspeicher. Kontrolle der freien und belegten Teile des Arbeitsspeichers. Zuteilung von Speicherbereichen (Partitionen, Kacheln). Verdrängen anderer Tasks, wenn der Speicher bereits belegt. Wiederfreigeben des Speichers nach Beendigung der Task. Es gibt diverse Verfahren des Speichersverwalters: starre Segmentierung und reeller Adressierung (statisch oder dynamisch), variable Segmentierung mit Verdrängung und virtueller Adressierung. Vorraussetzungen für den Mehrprogrammbetrieb: 1. Verschiebbarkeit (Relokierbarkeit). 2. Auslagerung (Swapping). 3. Schutzmaßnahmen. Der Speicherverwalter ist sehr zeitkritisch. Hohe Komplexität mancher Adressierungsarten erfordert massive Hardwareunterstützung. Schlechte Vorhersagbarkeit des Eigenzeitverhalten des Betriebssystems. Durch die Hardwarenähe ergibt sich eine schlechte Portabilität des Systems. Projektgruppe: Airbag, Semiarvortrag: Realzeitbetriebssysteme, Autor: Nils Grunwald, Oktober

12 OSEK/VDX: (Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug / Vehicle Distributed executive) Motivation zur Entwicklung von OSEK: Hohe, immer wiederkehrende Ausgaben für die Entwicklung und Verwaltung von Teilen der Steuerungssoftware, die nicht im direkten Zusammenhang mit der geplanten Applikation stehen. Inkompatibilität der Kontrolleinheiten aufgrund verschiedener Hersteller mit verschiedenen Protokollen und Schnittstellen. Ziel: Leichtere Portabilität und Wiederverwendung von Applikationssoftware durch: Spezifikation von Schnittstellen, die so applikationsunabhängig wie möglich sein sollen. Spezifikation einer Benutzerschnittstelle, die unabhängig von der Hardware und dem Netzwerk sein soll. Effizientes Design der Architektur: Die Funktionalität soll konfigurierbar und skalierbar sein. Vorteile: Klare Reduktion von Kosten und Entwicklungszeit. Gesteigerte Qualität der Software / Standardisierte Schnittstellen. Ermöglicht unabhängige, individuelle Implementierungen, da die Spezifikation keine Implementationsaspekte vorschreibt. Projektgruppe: Airbag, Semiarvortrag: Realzeitbetriebssysteme, Autor: Nils Grunwald, Oktober

13 Kriterien: Vergleich: OSEK/VDX / konventielle Software Fazit: Bessere Austauschbarkeit, Portierbarkeit und Wiederverwendbarkeit. Bedarf an leistungsfähigeren Mikrocontrollern und Mikroprozessoren mit mehr ROM und RAM (zusätzliche Kosten). Einsatz bei komplexeren Systeme möglich. OSEK Betriebssystem: Zeitscheibenverfahren: Herstellerübergreifende Austauschbarkeit der Software + - Portierbarkeit, Wiederverwendbarkeit + - Echtzeitverhalten, Reaktionszeiten + / - + / - Zuverlässigkeit der Software + + Entwicklungszeit: a) Entwurf und Codierung + - Entwicklungszeit: b) Test und Verifikation - *) + / - Mikrocontroller Ressourcen - + Einsatz von Software Entwurfs- und Codiertools (Automatische Codegenerierung, Systemgenerierung, Simulation) + - Beherrschbarkeit von komplexen Systemen + - * Verbesserung durch Tools möglich Projektgruppe: Airbag, Semiarvortrag: Realzeitbetriebssysteme, Autor: Nils Grunwald, Oktober

14 oscan und ProOSEK: oscan: ProOSEK: Hersteller: Vector Informatik 3Soft Standard: OSEK/VDX 2.0 OSEK/VDX 2.0 Größe des Kerns: Unterstütze Plattformen: Lieferumfang: Byte ROM Byte RAM 7 Prozessoren: (Nec, Siemens, Mitsubishi, Fujitsu) Betriebssystemkern Kommunikationsmodul Netzwerkmodul CAN-Treiber Graphischer Konfigurator CAN-Datenbankeditor 1,5 15 KB ROM 6 Prozessoren: (Intel, Siemens, Motorola, ARM, Hitachi + Simulatoren) Betriebssystemkern Graphischer Konfigurator OIL-Schnittstelle Konsistenzprüfung Statische Analyse Projektgruppe: Airbag, Semiarvortrag: Realzeitbetriebssysteme, Autor: Nils Grunwald, Oktober

15 ERCOS: ERCOS (Embedded Real-Time Control Operation System) von der Firma ETAS ist entwickelt worden, um die größten Nachteile der meisten anderen Realzeitbetriebssysteme durch eigene Konzepte auszugleichen. Als Nachteile der meisten Betriebssysteme werden dabei genannt: Programmierung des Systems über ein API. Damit reduziert sich aber die Unterstützung der Programmentwicklung durch das Betriebssystem auf die Laufzeitphase. Einsatz der Sprache C (keine Unterstützung echtzeitfähiger Programmierung, keine Sprachmittel zur Strukturierung und Modularisierung). ERCOS will diese Nachteile durch folgende Konzepte ausgleichen: Verwendung einer Beschreibungssprache, die notwendige Sprachmittel zur Entwicklung von echtzeitfähigen Programmen bereitstellt. Die Beschreibungssprache ermöglicht die Integration einzelner Zielprojekte zu einem komplexen Gesamtsystem. Trennung von funktionaler Entwicklung und Laufzeit-Konfiguration. Sicht auf das gesamte Projekt: Möglichkeit einer globalen Optimierung der verwendeten Ressourcen sowie der Kernelkonfiguration. Projektgruppe: Airbag, Semiarvortrag: Realzeitbetriebssysteme, Autor: Nils Grunwald, Oktober

16 Markübersicht / Fazit: Realzeitbetriebssysteme können im Moment in drei Klassen eingeteilt werden: 1. Nicht-Kommerzielle Realzeitbetriebssysteme. Einsatz bei kleinen Embedded Systemen, freie Verfügbarkeit, schlechter Support. 2. Real-Zeit Erweiterungen für NT. Zwei Betriebssysteme auf der gleichen Plattform. 3. Kommerzielle Realzeitbetriebssysteme (psosystem, VxWorks und QNX Neutrino). Aufteilung in Betriebssysteme für kleine Embedded Systeme und für komplexe Realzeitapplikationen. Die Vielzahl von Betriebssystemen liegt hauptsächlich in folgenden Punkten begründet: 1. Viele verschiedene Prozessoren, für die jeweils eine eigene Version des Betriebssystem mit den dazugehörigen Enwicklungstools geschrieben werden muß. 2. Optimierung für Systeme unterschiedlicher Größen. 3. Sehr unterschiedliche Anforderungen an die implementierten Betriebssystemfunktionen. Unterschiedliche Anzahl von Servicefunktionen. Fazit: Ein einziges Realzeitbetriebssystem kann niemals eine optimale Lösung für alle möglichen Realzeitapplikationen bieten. Projektgruppe: Airbag, Semiarvortrag: Realzeitbetriebssysteme, Autor: Nils Grunwald, Oktober