Prozessinformationsverarbeitung. Echtzeitbetriebssysteme. Professur für Prozessleittechnik Wintersemester 2009/2010

Transkript

1 Fakultät Elektrotechnik und Informationstechnik, Professur für Prozessleittechnik Prozessinformationsverarbeitung (PIV) Echtzeitbetriebssysteme Professur für Prozessleittechnik Wintersemester 2009/2010

2 Lehrinhalte Echtzeitverarbeitung Definition Echtzeitprogrammierung Verfahren zur Zuteilung von Rechenzeit Echtzeitbetriebssysteme Aufgaben Organisation und Klassifikation IEEE POSIX PIV (c) 2009, UR, ZI Folie 2

3 Echtzeitbetriebssysteme (EBS) Fragestellung: Wie muss ein Echtzeitbetriebssystem organisiert sein um Gleichzeitigkeit Rechtzeitigkeit Determiniertheit gewährleisten zu können? PIV (c) 2009, UR, ZI Folie 3

4 Aufgaben von (Echtzeit-) Betriebssystemen

5 Aufgaben von Betriebssystemen Taskverwaltung Zuteilung des Prozessors an die Tasks Synchronisation Zeitliche Koordination der Tasks Betriebsmittelverwaltung Zuteilung der Betriebsmittel (Speicher, E/A-Komponenten) an Tasks PIV (c) 2009, UR, ZI Folie 5

6 Aufgaben von Betriebssystemen Inter-Prozess-Kommunikation Sichere Kommunikation zwischen Tasks Schutzmaßnahmen Schutz der BM vor unberechtigtem Zugriff Bei EBS: Gewährleistung der Echtzeitbedingungen Wahrung der Rechtzeitigkeits-, Gleichzeitigkeits- und Verfügbarkeitsanforderungen PIV (c) 2009, UR, ZI Folie 6

7 Taskverwaltung BS verwaltet mehrere Tasks (Rechenprozesse) und steuert die notwendigen Taskwechsel Zur Einhaltung der Echtzeitanforderungen werden von EBS geeignete Scheduling-Verfahren angeboten Jede Task besitzt einen eigenen Speicherbereich und eigene (zugewiesene) Betriebsmittel (BM) Jede Task besitzt mind. einen Thread, dieser nutzt Speicher und BM und existiert nur innerhalb der Task PIV (c) 2009, UR, ZI Folie 7

8 Synchronisation Problem: Abhängigkeiten zwischen Tasks durch gemeinsam genutzte Betriebsmittel Daten: lesender/schreibender Zugriff Geräte: widersprüchliche Kommandos Programme: z.b. Gerätetreiber Lösungsansätze Sperrsynchronisation: wechselseitiger Ausschluss (Mutual Exclude, Mutex) zu jedem Zeitpunkt greift immer nur ein Task auf ein Betriebsmittel zu Reihenfolgensynchronisation: Kooperation, Reihenfolge der Zugriffe ist exakt definiert TU Dresden, PIV (c) 2009, UR, ZI Folie 8

9 Semaphor Passieren (P) Zähler-- Zählvariable Initialisierung definiert Anzahl der Tasks, die passieren dürfen, bevor gesperrt wird nein Zähler<0? Zustandswechsel blockiert Atomare Operation Passieren (P) Zählvariable wird erniedrigt. Wird dabei ein Wert kleiner 0 erreicht, wird die aufrufende Task blockiert Verlassen (V) Zähler++ Atomare Operation Verlassen (V) Zählvariable wird wieder erhöht. Bei einem Wert kleiner 1 wartet mindestens noch ein Task auf das Passieren einer davon wird aktiviert nein Zähler<1? Blockierte Task bereit machen TU Dresden, PIV (c) 2009, UR, ZI Folie 9

10 P V Synchronisation mit Semaphoren Sperrsynchronisation Reihenfolgesynchronisation Echtzeitsysteme: Die Task, die bei V wieder zur Ausführung gebracht wird, wird durch Priorität, Zeitschranke, Spielraum bestimmt Sperrsynchronisation: Mittels einer Semaphore wird ein Betriebsmittel geschützt Reihenfolgensynchronisation: Zwei Tasks steuern mittels zweier Semaphoren den Ablauf des anderen Task (Initialisierung beachten!) TU Dresden, Task1 P(S1) Zugriff auf geschützte V(S1) S1=1 Task2 P(S1) Freigabe einer blockierten Task Zugriff auf geschützte Betriebsmittel Betriebsmittel V(S1) Task1 P(S1) Aufgabe Task 1 V(S2) P(S1) S1=0, S2=1 PIV (c) 2009, UR, ZI Folie 10 Task2 P(S2) Aufgabe Task2 V(S1) P(S2) Aufgabe Task2 V(S1)

11 Ablauf einer Sperrsynchronisation Programmablauf? Initialisierung T1 P(S1) Sched: T2 P(S1) Sched: T1 Nutzung Sched: T1 V(S1) Sched: T2 Nutzung T2 V(S1) TU Dresden, Semaphore Prozesszustände S1 Taskqueue T1 T2? -> 1 ablaufwillig ablaufwillig 1 -> 0 laufend ablaufwillig -> ablaufwillig laufend 0 -> -1 T2 ablaufwillig -> blockiert laufend blockiert -1 T2 laufend blockiert laufend blockiert -1 -> 0 T2 laufend -> ablaufwillig ablaufwillig laufend 0 ablaufwillig laufend 0 -> 1 ablaufwillig laufend PIV (c) 2009, UR, ZI Folie 11

12 Verklemmungen bei der Synchronisation mit Semaphoren Deadlock (Blockierung, Deadly Embrace) Mehrere Tasks warten auf die Freigabe von Betriebsmitteln, die sich gegenseitig blockieren Ursachen: Mutexe werden nicht in der gleichen Reihenfolge belegt, Mutexe werden nicht freigegeben Abhilfe: Monitor Livelock (Aushungern, Starvation) Eine Task wird durch Konspiration anderer Tasks ständig an der Ausführung gehindert Ursache: Prioritäreninversion Abhilfe: Prioritätenvererbung TU Dresden, PIV (c) 2009, UR, ZI Folie 12

13 Mailbox/Fifo/Message Queue Aufbau: Nachrichten, die in Form einer verketteten Liste Ablegen von Daten von Prozessen Erhalt der Daten in Message Queue auch nach Beendigung des Erzeugers Priorisierung der Nachrichten (Priorität und Nachricht) mgl. TU Dresden, PIV (c) 2009, UR, ZI Folie 13

14 Mailbox/Fifo/Message Queue Operationen: Nachrichten einfügen (blockiert, wenn voll) Ablegen von Daten von Prozessen zur Kommunikation Erhalt der Daten in Message Queue auch nach Beendigung Erzeuger Priorisierung der Nachrichten (Priorität und Nachricht) möglich Nachrichten abholen (blockiert, wenn leer) erste Nachricht abholen erste Nachricht bestimmter Priorität; erste Nachricht die nicht bestimmte Priorität hat Statusabfragen Informationen, z.b. Größe TU Dresden, PIV (c) 2009, UR, ZI Folie 14

15 Weitere Synchronisationsmittel RW-Locks (Read-Write-Locks) viele lesen, nur einer schreibt (z.b. bei gemeinsamer Speicher) Barrier Punkt als Barriere, die erst überwunden wird, wenn eine bestimmte Menge an Threads an Barriere angelangt sind (vgl. Überwinden einer hohen Mauer) Monitore programmiersprachliches Synchronisationskonzept kritische Ressource durch ein Programmmodul gekapselt steuert implizit die Synchronisation bietet dem Programmierer spezielle Monitor-Operationen TU Dresden, PIV (c) 2009, UR, ZI Folie 15

16 Speicherverwaltung Jede Task besitzt eigenen Speicher kann zur Laufzeit entzogen und in einen Peripheriespeicher ausgelagert werden Dafür existieren Zuteilungsmechanismen und daraus resultierende Adressierungsverfahren Speicherabbildungsfunktion M: bildet eine logische Adresse der Task in eine reale Speicheradresse ab. PIV (c) 2009, UR, ZI Folie 16

17 Speicherverwaltung Speicherzuteilung Statisch: Zuteilung erfolgt, bevor Task ablaufwillig wird Dynamisch: Zuteilung erfolgt zur Laufzeit und kann sich ändern Nicht verdrängend: Speicher wird zur Laufzeit nicht entzogen Verdrängend: Speicher kann zur Laufzeit entzogen und in Peripheriespeicher ausgelagert werden Adressbildung Lineare Adressbildung: geschlossene Abbildung von logischen Blöcken zu physikalischen Nachbaradressen Streuende Adressbildung: Verteilung der logischen Blöcke auf verschiedene Teile des physikalischen Speichers zur besseren Auslastung und einfacheren Zuweisung von freien Blöcken PIV (c) 2009, UR, ZI Folie 17

18 Speicherverwaltung Adressierung Reelle Adressierung: Größe Logischer Adressraum <= Größe physikalischer Adressraum Virtuelle Adressierung: Größe Logischer Adressraum > Größe physikalischer Adressraum Bei virtueller Adressierung wird der physik. Speicher in Bereiche (Seiten) unterteilt, deren Startadresse in einer Seitentabelle gespeichert wird. Eine logische Adresse enthält dann die Seitennummer und die logische Adresse innerhalb der Seite. Damit kann der darstellbare Adressraum erheblich vergrößert werden. Seitenverzeichnisadresse Seitenadresse Offsetadresse PIV (c) 2009, UR, ZI Folie 18

19 Ein-/Ausgabeverwaltung Ein-/Ausgabeverwaltung hat zwei Aufgaben Zuteilen und Freigeben von Geräten bezügl. der Tasks Benutzen von Geräten durch die Tasks Daher Aufteilung in eine mehrschichtige Architektur Gerätetreiber als hardwareabhängige Schicht Ein-/Ausgabesteuerung als hardwareunabhängige Schicht Tasks Ein-/Ausgabesteuerung Gerätetreiber Ein-/Ausgabeverwaltung Gerät PIV (c) 2009, UR, ZI Folie 19

20 Funktionen der Ein-/Ausgabesteuerungsschicht Darstellung verschiedener Geräte durch eine einfache, einheitliche und transparente Schnittstelle Symbolische Namensgebung Annahme von E/A-Anforderungen Vergabe und Zuteilung von Geräten Synchronisation Schutz der Geräte Kommunikation mit anderen Gerätetreibern Pufferung Einheitliches Datenformat PIV (c) 2009, UR, ZI Folie 20

21 Inter-Prozess-Kommunikation Jede Task besitzt einen eigenen Speicherbereich => Direkte Kommunikation (über Variablen) nicht möglich Deshalb Verwendung von Nachrichten und geteiltem Speicher (Shared Memory) In EBS: prioritätsbasierte Kommunikation Nachrichten werden mit Prioritäten, Zeitschranken etc. versehen Dadurch ist die Einhaltung der Prioritätenkette und die Wahrung der End-zu-End-Prioritäten möglich Task 1, Priorität n Kommunikation Priorität n Task 2, Priorität n PIV (c) 2009, UR, ZI Folie 21

22 Zeitliche Koordination der Kommunikation Synchron Task 1 Task 2 Warte_auf_ Nachricht Asynchron Task 1 Task 2 Prüfe_auf _Nachricht Task 2 blockiert Task 2 arbeitet Sende_ Nachricht hole Nachricht Sende_ Nachricht Prüfe_auf _Nachricht hole Nachricht PIV (c) 2009, UR, ZI Folie 22

23 Organisation von (Echtzeit-) Betriebssystemen

24 Schichtenmodelle in BS Anwendung API Kommandointerp. Taskverwaltung Betriebsmittelverwaltung Speicherverwalt. E/A Verwaltung Ein-/Ausgabesteuerung Gerätetreiber Realer Prozessor M 6 M 5 M 4 M 3 M 2 M 1 M 0 Zugriff mit Programm o. aus Shell dito dito Allokation/De- Speicher Überprüfung Zuteilung Geräte logische Steuerung Abstraktion HW; HW unabhängige Schnittstelle nach oben PIV (c) 2009, UR, ZI Folie 24

25 Organisationsformen von Betriebssystemen Unterteilung der Funktionalität in User-Mode und Kernel-Mode mit privilegierten Ausführungsrechten Makrokernbetriebssystem: Kernel erstreckt sich auf mehrere Schichten Monolitische Architektur mit großen Funktionsumfang Ein Großteil der BS-Funktionen wird im Kernel-Mode ausgeführt Mikrokernbetriebssystem: Kernel besteht aus einer einzigen Schicht Modulare Architektur mit hoher Adaptierbarkeit Nur elementare Funktionen werden im Kernel-Mode ausgeführt, ansonsten findet ein Moduswechsel in den User-Mode statt PIV (c) 2009, UR, ZI Folie 25

26 Makro/Mikrokernel als Schichtenmodelle Makrokernel (grau) Mikrokernel (grau) Anwendung Anwendung API API Kommandointerp. M 6 M 7 API Kommandointerp. M 7 Taskverwaltung M 5 M 6 Taskverwaltung M 6 Betriebsmittelverwaltung M 4 M 5 Betriebsmittelverwaltung M 5 Speicherverwalt. E/A E/A Verwaltung M 3 M 4 Speicherverwalt. E/A Verwaltung M 4 Ein-/Ausgabesteuerung M 2 M 3 Ein-/Ausgabesteuerung M 3 Gerätetreiber M 1 M 2 Gerätetreiber M 2 Realer Mikrokern Prozessor M 0 M 1 Mikrokern M 1 Realer Prozessor M 0 Realer Prozessor M 0 PIV (c) 2009, UR, ZI Folie 26

27 Vergleich Makro/Mikrokernel (Wikipedia 2009, OS-structure.de.svg) PIV (c) 2009, UR, ZI Folie 27

28 Abarbeitung von BS-Aufrufen Makrokern-BS: API Usermode BM- Verwaltung E/A- Verwaltung E/A- Steuerung Gerätetreiber Kernelmode HW Mikrokern-BS: HW API BM- Verwaltung E/A- Verwaltung E/A- Steuerung Gerätetreiber Usermode Microkern Kernelmode PIV (c) 2009, UR, ZI Folie 28

29 Bewertung von Mikrokernelsystemen + Separierte Komponenten => besser skalierbar, konfigurierbar und portierbar + Nur wenige kritische Bereiche => geringe Abhängigkeit vom BS-Kern (Trusted Computing Base) => nahezu immer unterbrechbar (=> besser zeitl. determiniert) => Treiber laufen im Benutzermodus höhere Leistungsanforderungen => viele Kontextwechsel notwendig => hoher Synchronisationsaufwand Hardware-Zugriff im User-Mode nicht immer möglich PIV (c) 2009, UR, ZI Folie 29

30 Klassifizierung von Echtzeitbetriebssystemen

31 Grundtypen von EBS Minimales Echtzeitbetriebssystem (MEBS): BS als Bibliothek, die zum Progamm hinzugefügt wird Einfache E/A-Mechanismen ohne Speicherverwaltung nur physikalische Adressierung mit einem Adressraum Elementare Taskverwaltung für Threads Controller System (CS): E/A-Verwaltung erweitert um ein Dateisystem, sonst wie MEBS Umfangreichere Fehlerbehandlung Dediziertes System (DS): Wie CS, erweitert um Speicherverwaltung Mehrere geschützte Adressräume, virtuelle Adressierung PIV (c) 2009, UR, ZI Folie 31

32 Grundtypen von EBS Betriebssystemaufsatz (BA): Erweiterung eines Standard-BS (Echtzeitaufsatz) Nur Teile der Funktionalität echtzeitfähig Standard-BS für Nichtechtzeitaufgaben Allgemeines Echtzeitbetriebssystem (EBS): gleiche Funktionalität wie Standard-BS vollständig auf Echtzeiteinsatz ausgelegt Volle Funktionalität für Echtzeit- und Nichtechtzeitaufgaben PIV (c) 2009, UR, ZI Folie 32

33 Auswahlkriterien für EBS Entwicklungs- und Zielumgebung: Gewünschte Programmiersprache und HW-Plattform Entwicklung im Zielsystem oder Cross-Entwicklungsplattform Debugmöglichkeiten (insb. Quellcode-Debugging) Ein oder mehrere Werkzeuganbieter Modularität und Kerngröße: Konfigurierbarkeit und Ressourcenbedarf Anpassbarkeit: Anpassbarkeit an die gewünschte Rechnerarchitektur Anpassungsaufwand Verfügbarkeit von E/A-Schnittstellen (Feldbus, Netzwerk) PIV (c) 2009, UR, ZI Folie 33

34 Auswahlkriterien für EBS Konformität zu Standards (z.b. POSIX) Leistungsdaten Anzahl möglicher Tasks und verfügbarer Prioritätsebenen Art des Scheduling (kooperativ, präemptiv, präemtibel) Verfügbare Scheduling-Strategien Latenz- und Taskwechselzeiten Allgemeine Eigenschaften Art und Qualität der Bedienoberfläche Unterstützung der Entwicklung durch graphische Hilfsmittel Anzahl und Qualität verfügbarer Bibliotheken Verfügbarkeit weiterer Werkzeuge (z.b. Versionsverwaltung) PIV (c) 2009, UR, ZI Folie 34

35 Beispiele industrieller Echtzeitbetriebssysteme

36 POSIX [DIN/EN/ISO/IEC 9945] POSIX (Portable Operating System Interface): Standards für BS-Schnittstelle zu Anwenderprogrammen Ziel: Portabilität auf Quellcode-Ebene (keine Binärcode-Komp.) => weitgehend C-Code-spezifisch Active Standards: : POSIX Base Specifications, Issue : Test methods for measuring conformance to POSIX : ADA Laguage Interfaces : POSIX Realtime and Embedded Application Support POSIX Device Control API PIV (c) 2009, UR, ZI Folie 36

37 POSIX [DIN/EN/ISO/IEC 9945] : POSIX Base Specifications, Issue 7 Definiert eine standardisierte BS-Schnittstelle und BS-Umgebung Besteht aus vier Teilen Vol. 1: Base Definitions Vol. 2: System Interfaces Vol. 3: Shell and Utilities Vol. 4: Rationale Beschreibt die äußeren Eigenschaften und Möglichkeiten, die für Anwendungsentwickler wichtig sind (keine interne Struktur!) PIV (c) 2009, UR, ZI Folie 37

38 POSIX [DIN/EN/ISO/IEC 9945] : POSIX Realtime and Embedded Application Support Definiert vier Klassen von generischen Echtzeitumgebungen => Minimal Realtime System Profile PSE 51 ( MEPS) => Realtime Controller System Profile PSE52 ( CS) => Dedicated Realtime System Profile PSE53 ( DS) => Multi-Purpose Realtime System Profile PSE 54 ( EBS) Definiert eine Vielzahl von Echtzeitkomponenten (Threads, Scheduling, Zeitgeber, E/A, Echtzeitsignale usw.) für diese Klassen PIV (c) 2009, UR, ZI Folie 38

39 QNX Eigenschaften: POSIX-konforme (PSE52 zertifiziert) Mikrokernel-Architektur Vollständig überwachter Mikrokernel Multicore und verteiltes Rechnen möglich Integrierte Micro-GUI, 3D-Support Full MMU-Support (Memory Management Unit) Unterstützt ARM, x86, PPC, SH-4, MIPS u.a. Präemptiver Scheduler (mehrere Verfahren verfügbar) Integrierte Java runtime (alternativ C, C++) Große Anzahl verfügbarer Gerätetreiber PIV (c) 2009, UR, ZI Folie 39

40 QNX Architektur (QNX 2009, project_brief_june09) PIV (c) 2009, UR, ZI Folie 40

41 VxWorks Eigenschaften: POSIX-konforme (PSE52 zertifiziert) Mikrokernel-Architektur Vollständig überwachter Mikrokernel Multicore und verteiltes Rechnen möglich Eclipse-basierte IDE mit VxSim Simulator und umfangreichem System-Viewer Full MMU-Support Unterstützt ARM, x86, PPC, SH-4, MIPS, XScale u.a. Präemptiver Scheduler (mehrere Verfahren verfügbar) Integrierte Java runtime (alternativ Ada, C, C++) Große Anzahl verfügbarer Gerätetreiber PIV (c) 2009, UR, ZI Folie 41

42 Literatur Grundlagen zu Echtzeitsystemen Liu, J. (2000) Real-Time Systems. London: Pearson Echtzeitsysteme in der Automatisierungstechnik Lauber, R. & Göhner, P. (1999, 3.Aufl.) Prozessautomatisierung 1. Berlin: Springer Wörn, H. & Brinkschulte, U. (2005) Echtzeitsysteme. Berlin: Springer Programmierung von Echtzeitsystemen Barr, M. (1999) Programming Embedded Systems in C and C+ +. Sebastopol: O'Reilly Douglass, B.P. (2003) Real-Time Design Patterns. Robust Scalable Architecture for Real-Time Systems. Boston: Addison Wesley. TU Dresden, PIV (c) 2009, UR, ZI Folie 42