Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 1 4.3 Aufbau von Echtzeitbetriebssystemen Aufgaben.

Ähnliche Präsentationen


Präsentation zum Thema: "Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 1 4.3 Aufbau von Echtzeitbetriebssystemen Aufgaben."—  Präsentation transkript:

1 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Aufbau von Echtzeitbetriebssystemen Aufgaben eines Standardbetriebssystems: Taskverwaltung: Steuerung und Organisation der durchzuführenden Verarbeitungsprogramme (Tasks)  Zuteilung des Prozessors an Tasks. Betriebsmittelverwaltung: Zuteilung von Betriebsmittel an Tasks: – Speicherverwaltung: Zuteilung von Speicher – IO-Verwaltung: Zuteilung von IO-Geräten Interprozesskommunikation: Die Kommunikation zwischen den Tasks Synchronisation: Zeitliche Koordination der Tasks Schutzmaßnahmen: Der Schutz der Betriebsmittel vor unberechtigten Zugriffen Zusätzliche Aufgaben eines Echtzeitbetriebssystems: Wahrung der Rechtzeitigkeit und Gleichzeitigkeit Wahrung der Verfügbarkeit

2 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Aufbau von Echtzeitbetriebssystemen Realer Prozessor Schicht 1 Schicht 2 Schicht n-1 Schicht n M0M0 M1M1 M2M2 M n-1 MnMn... Anwendung Funktionalität des Realen Prozessors Abstrakte Maschinen Funktionalität von M n setzt auf Funktionalität (Dienste) von M n-1 auf Ein Schichtenmodell für informationsverarbeitende Systeme

3 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Aufbau von Echtzeitbetriebssystemen Realer Prozessor Gerätetreiber Ein-/Ausgabesteuerung Betriebsmittelverwaltung M0M0 M1M1 M2M2 M4M4 M6M6 Anwendung Speicher- verwaltung Ein-/Ausgabe- verwaltung M3M3 API Kommando- Interpreter Taskverwaltung M5M5 Betriebssystemkern Zuteilung des Prozessors an die Tasks Logische E/A Steuerung API (Application Program Interface) Betriebssystemkern im Kernelmode, Usermode für Anwendung Zuteilung von Ressourcen an die Tasks Schichtenmodell eines Makrokernbetriebssystems

4 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Aufbau von Echtzeitbetriebssystemen Realer Prozessor Gerätetreiber Ein-/Ausgabesteuerung Betriebsmittelverwaltung M 0 M 2 M 3 M 5 M 7 Anwendung Speicher- verwaltung Ein-/Ausgabe- verwaltung M 4 API Kommando- Interpreter Taskverwaltung M 6 Erweiterungsmodule im Usermode Mikrokern M 1 die Interprozesskommunikation die Synchronisation die elementaren Funktionen zur Taskverwaltung, dies sind i.A. -das Einrichten einer Task, -das Beenden einer Task, -das Aktivieren einer Task, und -das Blockieren einer Task Vorteile Mikrokern: sehr gut anpassbar an Aufgabe Hohe Skalierbarkeit durch Erwei- terungsmodule Einfache Portierbarkeit Preemptiver Kern Kurze kritische Bereiche Schichtenmodell eines Mikrokernbetriebssystems

5 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Aufbau von Echtzeitbetriebssystemen API Betriebsmittel- verwaltung Ein-/Ausgabe- verwaltung Gerätetreiber Festplatte Anwendung Usermode Kernelmode API Betriebsmittel- verwaltung Gerätetreiber Festplatte Anwendung Usermode Kernelmode Mikrokern a: Makrokernbetriebsystem b: Mikrokernbetriebsystem „Öffne Datei“ Ein-/Ausgabe- steuerung Ein-/Ausgabe- verwaltung Ein-/Ausgabe- steuerung Usermode- und Kernelmode-Wechsel bei Makro- und Mikrokernbetriebssystem

6 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Aufbau von Echtzeitbetriebssystemen Aus Sicht der Betriebszustände, der Zeitparameter, des Schedulings und der Synchronisation sind Thread und Task gleich. Anwendung Task 1 Thread 1 Thread i... Task n Thread 1 Thread j... Taskverwaltung: Tasks und Threads

7 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Aufbau von Echtzeitbetriebssystemen Task (schwergewichtiger Prozess) eigene Variablen und Betriebsmittel von den anderen Tasks abgeschirmt Eigener Adressraum Kommunikation nur über Interprozesskommunikation Task-Umschaltung bis zu mehrere 1000 Prozessortakte Thread (leichtgewichtiger Prozess) innerhalb einer Task. Benutzt Variablen und Betriebsmittel der Task Gemeinsamer Adressraum aller Threads innerhalb einer Task Kommunikation über beliebige globale Variable. Sehr schnelle Kommunikation und Thread-Umschaltung (wenige Takte). Wenig Schutz zwischen Threads.

8 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Aufbau von Echtzeitbetriebssystemen Ruhend (dormant) Die Task ist im System vorhanden, aber momentan nicht ablaufbereit, da Zeitbedin- gungen oder andere Voraussetzungen (noch) nicht erfüllt sind. Ablaufwillig (runnable) Die Task ist bereit, alle Zeitbedingungen oder andere Voraussetzungen zum Ablauf sind erfüllt, die Betriebsmittel sind zugeteilt, lediglich die Zuteilung des Prozessors durch die Taskverwaltung steht noch aus. Laufend (running) Die Task wird auf dem Prozessor ausgeführt. Bei einem Einprozessorsystem kann nur eine Task in diesem Zustand sein, bei einem Mehrprozessorsystem kann dieser Zustand von mehreren Tasks gleich-zeitig angenommen werden. Blockiert (suspended, blocked) Die Task wartet auf das Eintreffen eines Ereignisses (z.B. einen Eingabewert, eine Interprozesskommunikation) oder das Frei- werden eines Betriebsmittels (Synchronisa- tion). ruhend ablauf- willig laufend blockiert Einrichten der Task Entfernen Taskzustände/Threadzustände

9 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Aufbau von Echtzeitbetriebssystemen T > 2T Kollisionswarnung 6T6T > T < 2T Ruhe Kameradaten- verarbeitung Motor- steuerung 8T8T T 2T2T 3T3T 4T4T 5T5T 7T7T Laserscanner- datenverarbeitung (1. Prior.) Transponder- datenverarbeitung (2. Prior.) Landmarke Periodendauer Kameradatenverarbeitung: T Periodendauer Motorsteuerung: 2T Beispiel: zeitlicher Ablauf der FTS-Steuerung

10 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Aufbau von Echtzeitbetriebssystemen Kollisionswarnung 6T6T ruhend ablaufwillig laufend 8T8T T 2T2T 3T3T 4T4T 5T5T 7T7T blockiert Landmarke Zustände der Task Kameradatenverarbeitung

11 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Aufbau von Echtzeitbetriebssystemen riri sisi cici aiai didi pipi ruhend lili eiei jiji t er i ablaufwillig laufend blockiert Task i a i : Ankunftszeit (Arrival Time) r i : Anforderungszeit (Request Time) s i : Startzeit (Start Time) j i : Reaktionszeit (Reaction Time, Release Jitter) e i : Ausführungszeit (Execution Time) er i : Restausführungszeit (Remaining Execution Time) c i : Beendigungszeit (Completion Time) d i : Zeitschranke (Deadline) p i : Periode (Period) l i : Spielraum (Laxity, l i = d i – (t + er i ) ) t: aktueller Zeitpunkt Wesentliche Zeitparameter einer Echtzeittask

12 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Echtzeitscheduling Aufgabe eines Echtzeitschedulers Aufteilung des Prozessors zwischen allen ablaufwilligen Tasks derart, dass – sofern möglich – alle Zeitbedingungen eingehalten werden. Fragen zur Beurteilung eines Echtzeitschedulingverfahrens Existiert für ein gegebenes Taskset überhaupt ein Schedule, das alle Zeitbedingungen einhält? Findet das verwendete Schedulingverfahren diesen Schedule? Kann dieser Schedule in endlicher Zeit berechnet werden? Ein Schedulingverfahren heißt optimal, wenn es einen Schedule findet, sofern dieser existiert

13 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Echtzeitscheduling Prozessorauslastung (Processor Demand). Prozessorauslastung auf einem Einprozessorsystem für ein Taskset aus n periodischen Tasks mit Zeitschranke = Periode: Analyse des Echtzeitverhaltens (Scheduling Analysis, Feasibility Analysis) H > 100%: kein Schedule H ≤ 100%: Schedule existiert (wird jedoch je nach verwendetem Echtzeitschedulingverfahren nicht unbedingt gefunden)

14 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Echtzeitscheduling Scheduling-Verfahren Statisches SchedulingDynamisches Scheduling Nicht-preemptives Scheduling Preemptives Scheduling Nicht-preemptives Scheduling Preemptives Scheduling Statische Prioritäten Dynamische Prioritäten Nicht prioritäts- basiert Statische Prioritäten Dynamische Prioritäten Nicht prioritäts- basiert Klassifizierungsmerkmale von Scheduling-Verfahren

15 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Echtzeitscheduling Task 2 (weniger wichtig) Task 1 (wichtig) Ereignis für Task 1 Ruhe Ereignis für Task 2 Preemption Task 1 fertig Ereignis für Task 1 Task 1 fertig Ereignis für Task 2 a) Preemptives Scheduling b) Nicht-preemptives Scheduling Preemptives und nicht-preemptives Scheduling

16 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Echtzeitscheduling Task 2 Task 1 Ereignis für Task 2 Ruhe Ereignis für Task 1 Erste Ausführung Task 2 fertig msec Ereignis für Task 2 Zeitschranke für erste Ausführung von Task 2 verpasst FIFO-Scheduling First In First Out Prinzip: wer zuerst kommt, erhält zuerst den Prozessor Dynamisch, nichtpreemptiv, ohne Prioriäten Wenig geeignet für Echtzeit, da keinerlei Zeitbedingungen eingehen Beispiel.: Task 1: Periode p 1 = 150 msec Task 2: Periode p 2 = 10 msec Ausführungszeit e 1 = 15 msec Ausführungszeit e 2 = 1 msec H = 15 msec / 150 msec + 1 msec / 10 msec = 0,2 = 20%

17 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Echtzeitscheduling Fixed-Priority-Scheduling Jede Task erhält eine feste Priorität Dynamisches Scheduling, statische Prioritäten 2 Varianten: Fixed-Priority-Preemptive-Scheduling (FPP) Fixed Priority-Non-Preemptive Scheduling (FPN) Zuordnung der Prioritäten zu den Tasks ist entscheidend für das Echtzeitverhalten

18 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Echtzeitscheduling Rate-Monotonic-Scheduling (RMS) Gibt eine Regel der Prioritätenzuordnung für periodische Tasks an: Es werden den periodisch auszuführenden Tasks Prioritäten umgekehrt proportional zu ihren Periodendauern zugewiesen: PR i ~ 1 / p i mit p i : Periodendauer der Task i, PR i : Priorität der Task i es wird preemptives Scheduling verwendet, die Periodendauer p i ist konstant, die Zeitschranke d i ist gleich der Periodendauer p i, die Ausführungszeit e i ist konstant und bekannt, und die Tasks sind voneinander unabhängig, d.h. sie blockieren sich nicht gegenseitig z.B. durch Synchronisation Als Deadlines werden die Periodendauer angenommen

19 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Echtzeitscheduling Task 2 Task 1 Ereignis für Task 2 Ruhe Ereignis für Task 1 Preemption msec Ereignis für Task 2 Preemption Fixed-Priority-Preemptive-Scheduling und Prioritätenverteilung gemäß dem Rate-Monotonic-Prinzip Task 1:Periode p 1 = 150 msec => niedere Priorität Ausführungszeit e 1 = 15 msec Task 2:Periode p 2 = 10 msec => hohe Priorität Ausführungszeit e 2 = 1 msec Deadlines sind die Periodendauern, H = 20% Beispiel: RMS bei nicht gleichzeitigem Auftreten der Ereignisse

20 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Echtzeitscheduling Task 2 Task 1 Ereignis für Task 2 Ruhe Ereignis für Task 1 und msec Ereignis für Task 2 Task 1:p 1 = 150 msec, e 1 = 15 msec => niedere Priorität Task 2:p 2 = 10 msec, e 2 = 1 msec => hohe Priorität Zuteilung der Prioritäten gemäß dem Rate-Monotonic-Prinzip sind essentiell. Würde man keine Preemption zulassen oder die Prioritäten anders herum verteilen, so würde im obigen Beispiel Task 2 ihre Zeitschranken verletzen. Beispiel: RMS bei gleichzeitigem Auftreten der Ereignisse

21 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Echtzeitscheduling Behauptung: Rate-Monotonic-Scheduling liefert bei festen Prioritäten und Preemption für periodische Tasks, bei denen die Zeitschranke identisch zur Periode ist, eine optimale Prioritätenverteilung. RMS = Optimale Prioritätenverteilung?

22 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Echtzeitscheduling Task 2 Task 1 p1p1 Ruhe 0 e2e2 e1e1... p2p2 Task 2 Task 1 Ruhe e2e2 e1e1 p1p1 0 p2p2... Prinzip des Beweises am Beispiel zweier Tasks, p 2 > p 1 : Prioritätenverteilung 1 (entgegen RMS) Taskset ausführbar, wenn gilt: e 1 + e 2 ≤ p 1 Anderenfalls verpasst Task T 1 ihre Zeitschranke Prioritätenverteilung 2 (gemäß RMS) Aus e 1 + e 2 ≤ p 1 folgt: T 1 wie auch T 2 terminiert vor oder spätestens zum Zeitpunkt p 1 Daraus folgt:Task 1 hält ihre Zeitschranke Aus p 2 > p 1 folgt: Task 2 terminiert vor p 2 Daraus folgt:Task 2 hält ihre Zeitschranke

23 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Echtzeitscheduling Dies gilt auch für alle späteren Aufrufe, da beim ersten Aufruf durch gleichzeitige Aktivierung von Task 1 und Task 2 der schlimmste Fall bereits abgedeckt ist. Schlussfolgerung: ist Taskset mit 2 Tasks unter einer Prioritätenverteilung entgegen dem Rate-Monotonic-Prinzip (Variante 1) ausführbar, so ist es immer auch mit dem Rate-Monotonic-Prinzip (Variante 2) ausführbar. Für 2 Tasks ist Rate-Monotonic-Scheduling also eine optimale Prioritäten- zuteilung für feste Prioritäten. Die Beweisführung lässt sich leicht von zwei auf eine beliebige Anzahl Tasks erweitern ([Liu Layland 1973])

24 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Echtzeitscheduling Laserscanner- Datenverarbeitung Kamera- Datenverarbeitung Transponder- Erkennung Funk- Kommunikation Motorsteuerung und -regelung FTS FTS Beispiel mit drei Aufgaben

25 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Echtzeitscheduling Prod 1 Prod 2 FTS Lager T1: Kameradatenverarbeitung, p 1 = d 1 = 10 msec, e 1 = 1 msec T2: Motorsteuerung, p 2 = d 2 = 10 msec, e 2 = 5 msec T3: Transpondererkennung, d 3 = 1 cm : 0,65 m/sec = 15,4 msec, e 3 = 5,5 msec Fahrgeschwindigkeit: 0,65 m/sec, Positionsgenauigkeit 1 cm Daten aus industriellem FTS mit aufgeklebter Fahrspur und Landmarken

26 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Echtzeitscheduling Prioritätenvergabe gemäß RMS: T1 (Kameradatenverarbeitung): hohe Priorität T2 (Motorsteuerung): mittlere Priorität. T3 (Transpondererkennung):niedrige Priorität oder: T1 (Kameradatenverarbeitung): mittlere Priorität. T2 (Motorsteuerung): hohe Priorität T3 (Transponderdatenerkennung): niedrige Priorität H = e 1 / p 1 + e 2 / p 2 + e 3 / p 3 = = 1 msec/10 msec + 5 msec/10 msec + 5,5 msec/15,4 msec = = 95,71% (aperiodisches Transponderereignis als schlimmster Fall mit seiner Zeitschranke periodisiert) Prozessorauslastung

27 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Echtzeitscheduling Motorsteuerung (T2) Kameradaten verarbeitung (T1) Ereignis für T 1 und T 2 Ruhe Ereignis für T 1, T 2 und T 3 Preemption msec Zeitschranke T 3 Transponder- Erkennung (T3) 1 msec 5 msec 4 msec 1 msec 5 msec 1,5 msec Zeitschranke T 1 &T 2 um 2,1 msec verpasst Ablauf des FTS Beispiels mit Priorität T1 > T2 > T3

28 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Echtzeitscheduling Motorsteuerung (T2)(T2) Kameradaten- verarbeitung (T 1 ) Ereignis für T 1 und T 2 Ruhe Ereignis für T 1, T 2 und T 3 Preemption msec Zeitschranke T 3 Transponder- Erkennung (T 3 ) 1 msec 5 msec 4 msec 1 msec 5 msec 1,5 msec Zeitschranke T 1 & T 2 um 2,1 msec verpasst Ablauf des FTS Beispiels mit Priorität T2 > T1 > T3

29 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Echtzeitscheduling Daraus folgt: Feste Prioritäten mit Preemption ist kein optimales Schedulingverfahren. Obergrenze der Prozessorauslastung ist mathematisch ermittelbar, bis zu der immer ein ausführbarer Schedule für Rate-Monotonic-Scheduling mit Preemption gefunden wird. H max = n(2 1/n – 1), n = Anzahl der Tasks Bsp.: H max = 3 (2 1/3 -1) = 0,78 = 78%

30 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Echtzeitscheduling EDF-Scheduling Bei Earliest-Deadline-First-Scheduling (EDF) erhält diejenige Task den Prozessor zugeteilt, die am nächsten an ihrer Zeitschranke (Deadline) ist. => Prioritäten ergeben sich automatisch und dynamisch aus den Zeitschranken. Dynamisches Scheduling, dynamische Prioritäten, preemptiv oder nicht-preemptiv Preemptives EDF-Scheduling auf Einprozessorsystemen liefert optimales Scheduling H max = 100%  EDF findet für periodische Tasks mit d i = p i einen Schedule, wenn gilt: e i / p i ≤ 1

31 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Echtzeitscheduling Motorsteuerung (T 2 ) Kameradaten- verarbeitung (T 1 ) Ereignis für T 1 und T 2 Ruhe Ereignis für T 1, T 2 und T msec Zeitschranke T 3 Transponder- Erkennung (T 3 ) 1 msec 5 msec 5,5 msec 1 msec 5 msec Zeitschranke T 1 &T 2 Ereignis für T 1 und T 2 Ablauf des FTS-Beispiels mit EDF-Scheduling

32 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Echtzeitscheduling LLF-Scheduling Bei Least-Laxity-First-Scheduling (LLF) erhält diejenige Task den Prozessor zugeteilt, die den geringsten Spielraum (Laxity) hat. Dynamisches Scheduling, dynamische Prioritäten, preemptiv oder nicht-preemptiv Preemptives LLF ist wie EDF ein optimales Schedulingverfahren auf Einprozessorsystemen, H max = 100%. Für den Spielraum gilt l i = d i – (t + er i )  LLF erzeugt eine drastisch höhere Anzahl an Taskwechseln als EDF Aber besseres Verhalten als EDF bei Überlast

33 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Echtzeitscheduling Ablauf des FTS Beispiels mit LLF-Scheduling

34 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Echtzeitscheduling Task 1, ablaufwillig, Zeitscheibe 1 Task 2, nicht ablaufwillig, Zeitscheibe 2 Task 3, ablaufwillig, Zeitscheibe 3 Task n, ablaufwillig, Zeitscheibe n Time-Slice-Scheduling Time-Slice-Scheduling (Zeitscheibenverfahren) ordnet jeder Task eine feste Zeitscheibe (Time Slice) zu. Die Reihenfolge der Taskausführung entspricht hierbei der Reihenfolge der ablaufwilligen Tasks in der Taskverwaltungsliste des Betriebssystems. Die Dauer der Zeitscheibe für eine Task kann individuell festgelegt werden. Preemptives dynamisches Scheduling ohne Prioritäten. Einfaches Verfahren, bei feinkörnigen Zeitscheiben nahe an der Optimalität, aber Periodendauer abhängig von der Anzahl der Tasks

35 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Echtzeitscheduling T 1 : H 1 = e 1 / p 1 = 1 msec / 10 msec = 10% T 2 : H 2 = e 2 / p 2 = 5 msec / 10 msec = 50% T 3 : H 3 = e 3 / p 3 = 5,5 msec / 15,4 msec = 36% (35,714%) Die Zeitscheiben wurden auf der Proportionalitätsbasis 1% ≡ 0,05 msec wie folgt gewählt: T 1 : Zeitscheibe 0,5 msec (~ 10%) T 2 : Zeitscheibe 2,5 msec (~ 50%) T 3 : Zeitscheibe 1,8 msec (~ 36%) Ablauf des FTS-Beispiels mit Time-Slice-Scheduling

36 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Echtzeitscheduling Guaranteed Percentage Scheduling Guaranteed Percentage Scheduling (GP) ordnet jeder Task einen festen Prozentsatz der verfügbaren Prozessorleistung innerhalb einer Periode zu (virtueller Prozessor pro Task) Preemptives dynamisches Schedulingverfahren ohne Prioritäten Periodendauer unabhängig von der Anzahl der Tasks Auf Einprozessorsystemen ein optimales Schedulingverfahren: H max = 100% Bei periodischen Tasks werden die Zeitschranken erfüllt, wenn gilt: e i / p i ≤ 1 Viele Taskwechsel wie bei LLF Für mehrfädige Prozessoren geeignet.

37 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Echtzeitscheduling Thread A, 30% Thread B, 20% Thread C, 40% Thread A 30 Taktzyklen Thread B 20 Taktzyklen Thread C 40 Taktzyklen Thread A 30 Taktzyklen Thread B 20 Taktzyklen Thread C 40 Taktzyklen Taktzyklen Beispiel Komodo-Mikrocontroller, GP Periode 100 Taktzyklen (vgl. Abschnitt 2.6)

38 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Echtzeitscheduling Motorsteuerung (T 2 ) Kameradaten- verarbeitung (T 1 ) Ereignis für T 1 und T 2 Ruhe Ereignis für T 1, T 2 und T msec Zeitschranke T 3 Transponder- erkennung (T 3 ) Zeitschranke T 1 &T 2 Ereignis für T 1 und T 2 fertig T 3 fertig T 1 und T 2 fertig T 1 und T 2 T 1 : H 1 = e 1 / p 1 = 1 msec / 10 msec = 10% T 2 : H 2 = e 2 / p 2 = 5 msec / 10 msec = 50% T 3 : H 3 = e 3 / p 3 = 5,5 msec / 15,4 msec = 36% (35,714 %) Hierdurch ergibt sich für jede Task eine Ausführungszeit, die ihrer Periode und damit ihrer Zeitschranke entspricht: T 1 : Ausführungszeit: 1 msec in 10 msec (10%) T 2 : Ausführungszeit: 5 msec in 10 msec (50% ) T 3 : Ausführungszeit: 5,5 msec in 15,3 msec (36%) Ablauf des FTS-Beispiels mit Guaranteed Percentage Scheduling

39 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Synchronisation und Kommunikation Temperatur- Sensoren auslesen Temperatur- Verteilung in Temperatur- Tabelle ablegen Temperatur- Tabelle lesen Temperatur- Verteilung ausdrucken Konkurrierender Zugriff Task 1 Task 2 Gemeinsame Betriebsmittel Daten Geräte Programme Beispiel: gemeinsam genutzte „Temperatur- Tabelle“ Synchronisation gemeinsamer Betriebsmittel

40 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Synchronisation und Kommunikation Synchronisation – Variante 1 Die Sperrsynchronisation Temperatur Sensoren auslesen Temperatur- Tabelle ablegen Temperatur Tabelle lesen Temperatur- Verteilung ausdrucken Task 1Task 2 Mutex für Temperatur- Tabelle belegen Mutex für Temperatur Tabelle belegen Mutex für Temperatur- Tabelle freigeben Mutex für Temperatur- Tabelle freigeben Sperr- synchronisation kritischer Bereich

41 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Synchronisation und Kommunikation Temperatur- Sensoren auslesen Temperatur- Verteilung in Temperatur- Tabelle ablegen Temperatur- Tabelle lesen Temperatur- Verteilung ausdrucken Task 1Task 2 Reihenfolgen- synchronisation Task blockiert Task blockiert Synchronisation – Variante 2 Die Reihenfolgensynchronisation

42 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Synchronisation und Kommunikation Ein Semaphore besteht aus: q einer Zählvariablen q zwei nicht unterbrechbaren Operationen P (Passieren) und V (Verlassen) eine blockierte Task bereit machen Zähler := Zähler + 1 Zähler<1 ? V Task blockieren Zähler := Zähler - 1 Zähler<0 ? P ja nein ja nein Bei Standardbetriebssystemen: Bereitmachen einer beliebigen wartenden Task bei V Bei Echtzeitbetriebssystemen: Bereitmachen der höchstprioren wartenden Task bei V

43 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Synchronisation und Kommunikation Initialisiere Semaphore S 1 = 1 Passiere(S 1 ) Verlasse(S 1 ) Zugriff auf geschützte Betriebsmittel Passiere(S 1 ) Verlasse(S 1 ) Task 1 Task 2 blockiert Task 2 freigegeben Zugriff auf geschützte Betriebsmittel Sperrsynchronisation mit einem Semaphore Diese Form des Semaphore-Einsatzes heißt auch Mutex (Mutual Exclude)

44 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Synchronisation und Kommunikation Initialisiere Semaphore S 1 =0 Task 1 Task 2 Task 1 blockiert Task 1 freigegeben Aktivität Task 2 Aktivität Task 1 Aktivität Task 2 Task 2 blockiert Task 1 blockiert Task 2 freigegeben Task 1 freigegeben Initialisiere Semaphore S 2 =1 Passiere(S 1 ) Passiere(S 2 ) Verlasse(S 1 ) Verlasse(S 2 ) Passiere(S 2 ) Passiere(S 1 ) Verlasse(S 1 ) Reihenfolgen- synchronisation mit zwei Semaphoren

45 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Synchronisation und Kommunikation Initialisiere Semaphore Leerungen = n Passiere(Leerungen) Task "Erzeuger"Task "Verbraucher" Erzeuge Objekt Verlasse(Füllungen) Initialisiere Semaphore Füllungen = 0 Passiere(Füllungen) Verbrauche Objekt Verlasse(Leerungen) Leerungen: Freie Plätze für Objekte des Erzeugers, Füllungen: erzeugte Objekte für Verbraucher Erzeuger-/Verbraucher- Synchronisation mit zwei Semaphoren

46 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Synchronisation und Kommunikation Temperatur- und Druck- Sensoren auslesen Temperatur- Verteilung in Temperatur- Tabelle ablegen Task 1 Task 2 Mutex für Temperatur- Tabelle belegen Mutex für Temperatur- Tabelle freigeben kreuzweise Betriebsmittel- belegung Mutex für Druck- Tabelle belegen Druck-Verteilung In Druck-Tabelle ablegen Mutex für Druck- Tabelle freigeben Mutex für Temperatur- Tabelle belegen Mutex für Druck- Tabelle belegen Temperatur- Tabelle lesen Druck- Tabelle lesen Mutex für Druck- Tabelle freigeben Mutex für Temperatur- Tabelle freigeben Temperatur- und Druck- Verteilung ausdrucken Verklemmungen Deadlock (Blockierung, Deadly Embrace): mehrere Tasks warten auf die Freigabe von Betriebsmitteln, die sich gegenseitig blockieren. Beispiel: kreuzweise Betriebsmittelbelegung Gegenmaßnahmen: Abhängigkeitsanalyse Vergabe der Betriebsmittel in gleicher Reihenfolge Timeout

47 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Synchronisation und Kommunikation Initialisiere Semaphore S 1 = 1 Zugriff auf geschützte Betriebsmittel Task 1Task 2 Passiere(S 1 ) Verlasse(S 1 ) Passiere(S 1 ) Zugriff auf geschützte Betriebsmittel Ein Deadlock durch Programmierfehler Gegenmaßnahme: höhere Synchronisationskonstrukte (z.B. Monitore)

48 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Synchronisation und Kommunikation Verklemmungen Livelock (Starvation, Aushungern): eine Task wird durch andere Tasks ständig an der Ausführung gehindert. Beispiel: eine hochpriore Task verhindert ständig die Ausführung einer niederprioren Task Auch hochpriore Tasks können „Opfer“ von Livelocks werden, Problem Prioritäteninversion

49 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Synchronisation und Kommunikation Task 1 hohe Priorität Task 2 niedere Priorität Mutex Task 2 Task 1 Ereignis für Task 1 Ruhe Ereignis für Task 2 Zeit Task 2 belegt Mutex Task 1 versucht, Mutex zu belegen, wird blockiert Task 2 gibt Mutex frei Prioritäteninversion

50 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Synchronisation und Kommunikation Task 2 Task 1 Ereignis für Task 1 Ruhe Ereignis für Task 2 Zeit Livelock, Task 1 ist längerfristig blockiert Task 3 Ereignis für Task 3 Task 2 belegt Mutex Task 1 versucht, Mutex zu belegen, wird blockiert Mutex Task 1 hohe Priorität Task 2 niedere Priorität Task 3 mittlere Priorität Ein Livelock durch Prioritäten- inversion

51 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Synchronisation und Kommunikation Task 2 Task 1 Ereignis für Task 1 Ruhe Ereignis für Task 2 Zeit Prioritätenvererbung, Task 2 erhält die Priorität von Task 1 (daher keine Unter- brechung durch Task 3) Task 3 Ereignis für Task 3 Task 1 ist fertig Task 2 belegt Mutex Task 1 versucht, Mutex zu belegen, wird blockiert Task 2 gibt Mutex frei Mutex mit Prioritäten- vererbung Task 1 hohe Priorität Task 2 niedere Priorität Task 3 mittlere Priorität Vermeidung des Livelocks durch einen Mutex mit Prioritäten- vererbung

52 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Synchronisation und Kommunikation Zwei grundlegende Varianten der Task-Kommunikation: Gemeinsamer Speicher (schneller) Nachrichten Task 1, Priorität n Task 2, Priorität n Kommunikation Priorität n Bei Echtzeitbetriebssystemen: Wahrung der End-zu-End-Prioritäten durch prioritäts-basierte Kommunikation (hochprioreNachrichten überholen niederpriore,keine Bockierung) Task-Kommunikation

53 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Synchronisation und Kommunikation Weiteres Unterscheidungsmerkmal zeitliche Koordination - Synchrone Kommunikation - Asynchrone Kommunikation Task 1 Sende_Nachricht Warte_auf_Nachricht Task 2 blockiert Task 2 Task 1 Sende_Nachricht Prüfe_ob_Nachricht _vorhanden Task 2 Prüfe_ob_Nachricht _vorhanden Hole_Nachricht a) synchrone Kommunikation b) asynchrone Kommunikation Hole_Nachricht

54 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Synchronisation und Kommunikation Für asynchrone Kommunikation: der Kommunikationskanal muss Botschaften puffern Konzepte: Briefkasten: individuelle Botschaftenwarteschlange zwischen Sender und Empfänger Port: spezielle Form des Briefkastens, bei der mehrere Sender Daten mit einem Empfänger austauschen können Empfange(Verbrau- cher, Port, Priorität, Leerbotschaft) Task "Erzeuger" Task "Verbraucher" Erzeuge Objekt  Vollbotschaft for i:= 1 to n do Sende(Erzeuger, Port, Priorität, Leerbotschaft) Sende(Verbraucher, Port, Priorität, Vollbotschaft) Empfange(Erzeuger, Port, Priorität, Vollbotschaft) Vollbotschaft  Verbrauche Objekt Sende(Erzeuger, Port, Priorität, Leerbotschaft) Beispiel nachrichtenbasierter Kommunikation: Botschaftenaustausch

55 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Synchronisation und Kommunikation Ausgangsrechner Task Stellvertreter (Stub) 1 6 Zielrechner Prozedur Stellvertreter (Skeleton) 3 4 Netzwerk, Feldbus, (1), (3), (4), (6) - Prozeduraufrufe (2), (5), - Botschaftentransfer Entfernter Prozeduraufruf mittels Botschaftenaustausch

56 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Speicher- und IO-Verwaltung Speicherverwaltung Die Speicherverwaltung teilt den verfügbaren Speicher mittels einer Speicherabbildungsfunktion M zu: M: logische Adresse → physikalische Adresse Logische Adresse:Speicheradresse innerhalb einer Task Physikalische Adresse: wirkliche Arbeitsspeicheradresse Modelle der Speicherverwaltung: Speicherzuteilung: Statische Speicherzuteilung Dynamische Speicherzuteilung Nichtverdrängende Speicherzuteilung Verdrängende Speicherzuteilung Adressbildung und Adressierung: Reelle Adressierung Virtuelle Adressierung Lineare Adressbildung Streuende Adressbildung

57 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Speicher- und IO-Verwaltung Segment 1 (log. Adressraum Task 1) Segment 2 (log. Adressraum Task 2) Segment 3 (log. Adressraum Task 3) unbenutzt physikalischer Adressraum Vorteile: Tasks im Speicher verschiebbar Tasks gegeneinander geschützt Zeitverhalten sehr gut vorhersagbar Nachteile: Speicherschema starr, nicht online änderbar Für jede Task maximaler Speicher Bei variierender Anzahl von Tasks muss für alle Tasks Speicher reserviert werden, kein Teilen von Speicher zwischen Tasks Lineare Adressbildung durch Segmente, statische Zuteilung, reelle Adressierung, keine Verdrängung Bevorzugte Lösung für eingebettete Systeme mit einfachen Mikrocontrollern

58 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Speicher- und IO-Verwaltung Tasks können sich phys. Speicher teilen, so lange keine Verdrängung ist die Zugriffszeit konstant. Speicherbereinigung wegen löchrigem Speicher. Lineare Adressbildung durch Segmente, dynamische Zuteilung, reelle Adressierung, keine Verdrängung

59 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Speicher- und IO-Verwaltung physikalischer Adressraum Task 5 32 kBytes wird ablaufwillig Segment 1 Task 1 32 kBytes Segment 4 Task 4 20 kBytes Segment 3 Task 3 30 kBytes unbenutzt 18 kBytes unbenutzt 18 kBytes Segment 1 Task 1 32 kBytes Segment 4 Task 4 20 kBytes Segment 3 Task 3 30 kBytes unbenutzt 36 kBytes Segment 1 Task 1 32 kBytes Segment 4 Task 4 20 kBytes Segment 3 Task 3 30 kBytes 4 kBytes Segment 5 Task 5 32 kBytes kompaktifizieren Wegen Segmentverschiebungen für Echtzeit problematisch. Lineare Adressbildung mit Speicherbereinigung

60 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Speicher- und IO-Verwaltung physikalischer Adressraum Segment 1 Segment 4 unbenutzt logischer Adressraum Segment 1 Segment 4 Segment 2 Segment 3 Peripherie- speicher ausgelagert (verdrängt) eingelagert Task 1 Task 2 Task 3 Task 4 Verdrängungsstrategien (auslagern): FIFO (First In First Out), am längsten im Sp. LRU (Least Recently Used), a. l. nicht mehr ben. LFU (Least Frequently Used), am seltensten ben. LRD (Least Reference Density), ger. Zugriffsdichte Zuteilungsstrategien (einlagern, wohin): First Fit (erstes) Best Fit (kleinstes) Worst Fit (größtes) Nachschubstrategien (wann einlagern): Verlangend (Demand Fetch) Vorausschauend (Anticipatory Fetch) Echtzeitbetriebsysteme: Verriegeln von einzelnen Tasks, d.h. keine Verdrängung Lineare Adressbildung mit virtueller Adressierung und Verdrängung

61 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Speicher- und IO-Verwaltung ruhendlaufend blockiert Einrichten der Task Entfernen ablauf- willig, verdrängt ablauf- willig, eingelagert Taskzustände bei verdrängender Speicherverwaltung

62 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Speicher- und IO-Verwaltung m Bit SegmentadresseOffsetadresse + in der Segmentdeskriptor- Tabelle im Arbeitsspeicher virtuelle Adresse physikalische Adresse v Bit p Bit m Bit n Bit Segmentdeskriptor Segmenttyp physikalische Segment- Startadresse Segmentlänge Zugriffsrechte Segment verdrängt... phys. Deskriptor- Tabellen-Startadresse + m Bit Realisierung der linearen Adressbildung mit Segmenten

63 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Speicher- und IO-Verwaltung Task 1 unbenutzt Task 1 Seite 1 Seite 2 Seite 3 Task 1 Seite 4 Seite 5 Seite 6 Task 1 Seite 7 Seite 8 Seite 9 Task 1 Seite 10 Seite 11 Seite 12 Task 2 Task 3 Streuende Adressbildung: Aufteilung der Tasks auf Seiten

64 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Speicher- und IO-Verwaltung Task 1 unbenutzt Task 1 Seite 1 Seite 2 Seite 3 Task 1 Seite 4 Seite 5 Seite 6 Task 1 Seite 7 Seite 8 Seite 9 Task 1 Seite 10 Seite 11 Seite 12 Task 2 Task 3 Task 1 unbenutzt Kachel 1 Kachel 2 Kachel 3 Task 1 Kachel 4 Kachel 5 Kachel 6 Task 1 Kachel 7 Kachel 8 Kachel 9 Task 1 Kachel 10 Kachel 11 Kachel 12 unbenutzt Kachel 13 Kachel 14 Task 1 Kachel 15 Kachel 16 Kachel 17 unbenutzt Kachel 18 Kachel 19 Task 1 Kachel 20 Kachel 21 Kachel 22 logischer Adressraum Physik. Adressraum... Die Zuordnung von Seiten zu Kacheln erfolgt in der Regel ohne Beachtung der sequentiellen Reihenfolge der Seiten Vorteile: einfache Zuweisung, keine Zuteilungsstrategie dynamische Taskgrößenänd. einfacher und zeitlich besser vorhersagbar keine Speicherbereinigung Virtuelle Adressierung benötigt nur Verdrängung- und Nachschubsstrategie Nachteile: letzte Seite nur teilweise voll höherer Seitenverwaltungsaufwand durch kleine Seiten mehr Datentransfers zwischen Haupt- und Peripheriespeicher Streuende Adressbildung: Zuordnung von Seiten zu Kacheln

65 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Speicher- und IO-Verwaltung Seitentabelle im Arbeitsspeicher Seitenadresse Offsetadresse k logische Adresse physikalische Adresse v Bit p Bit m Bitm-p Bit n Bit Startadresse der phys. Seitentabelle + m Bit k = Konkatenation m Bit Kachelnummer der Seite Realisierung der streuenden Adressbildung mit Seiten

66 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Speicher- und IO-Verwaltung Seitenverzeichnis- adresse SeitenadresseOffsetadresse Seiten- tabellen- verzeichnis Seiten- tabelle k k logische Adresse physikalische Adresse Hierarchischer Aufbau der Seitentabellen

67 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Speicher- und IO-Verwaltung SegmentadresseSeitenadresseOffsetadresse logische Adresse Kombination der Vorteile Kombination von linearer und streuender Adressbildung

68 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Speicher- und IO-Verwaltung IO-Verwaltung Aufgaben der IO-Verwaltung: q Zuteilen und Freigeben von Geräten q Benutzen von Geräten Die angeschlossenen Geräte unterscheiden sich hierbei stark in Geschwindigkeit und Datenformat => das Betriebssystem muss dem Anwender- programm die Schwierigkeiten der Kommunikation abnehmen und einfache, transparente Schnittstellen zur Verfügung stellen Tasks Ein- /Ausgabesteuerung Gerätetreiber (hardwareabhängig) Hardware (Geräte) Ein- /Ausgabe- verwaltung Architektur der Ein-/Ausgabeverwaltung

69 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Speicher- und IO-Verwaltung Die wichtigsten Teilfunktionen der Ein/Ausgabe- steuerungsschicht sind: Symbolische Namensgebung Annahme von Ein-/Ausgabeanforderungen Vergabe und Zuteilung von Geräten Synchronisation Schutz der Geräte Kommunikation mit den Gerätetreibern Pufferung Einheitliches Datenformat

70 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Speicher- und IO-Verwaltung Eingaberegister Adressbus Datenregister Steuerregister Statusregister Schnittstellenbaustein Prozessor, Bus Gerät Ein/Ausgabe- Daten Steuer- Signale Steuerung Datenbus Steuerbus Synchronisationsmechanismen

71 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Speicher- und IO-Verwaltung Statusregister lesen Gerät bereit ? Datenregister lesen Datum verarbeiten Gerät initialisieren: Steuerregister schreiben Datum ins Datenregister übertragen Gerät nimmt Tätigkeit auf TaskSchnittstellenbausteinGerät nein ja bereit Einfach, hohe Übertragungsleistung bei einem Gerät Prozessor ständig aktiv, keine Nebenaktivitäten Synchronisation durch Polling

72 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Speicher- und IO-Verwaltung Gerät 1 bereit ? Gerät 1 behandeln Gerät 2 bereit ? Gerät 2 behandeln Gerät n bereit ? Gerät n behandeln... ja nein Verlangsamte Reaktionszeit bei mehreren Geräten Polling von mehreren Geräten innerhalb einer Task

73 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Speicher- und IO-Verwaltung Statusregister lesen Gerät bereit ? Datenregister lesen Datum verarbeiten Gerät initialisieren: Steuerregister schreiben Datum ins Datenregister übertragen Gerät nimmt Tätigkeit auf TaskSchnittstellenbausteinGerät nein ja Kurze Aktivität durchführen bereit Nebenaktivitäten möglich Verlangsamte Reaktionszeit, Nebenaktivität muss in kleine Teilschritte aufgeteilt werden Synchronisation durch Busy Waiting

74 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Speicher- und IO-Verwaltung Datenregister lesen Datum verarbeiten Gerät initialisieren: Steuerregister schreiben Datum ins Datenregister übertragen Gerät nimmt Tätigkeit auf TaskSchnittstellenbausteinGerät Unterbrechungs- behandlung Rückkehr zur Unterbrochenen Task... Unterbrechung Beliebige Nebenaktivitäten, schnelle Reaktionszeit Verringerte Übertragungsraten Synchronisation durch Unterbrechung

75 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Speicher- und IO-Verwaltung TaskSchnittstellenbausteinGerät nein ja Warte auf Bestätigung Handshake Gerät initialisieren: Steuerregister schreiben Datum ins Datenregister übertragen Gerät nimmt Tätigkeit auf Statusregister lesen Gerät bereit ? Datenregister lesen Datum verarbeiten Bestätigung bereit Wenn Gerät Daten schneller liefert als die Task sie entgegennehmen kann Synchronisation durch Polling mit Handshake

76 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Speicher- und IO-Verwaltung TaskSchnittstellenbausteinGerät Unterbrechungs- behandlung Rückkehr zur unterbrochenen Task... Handshake Warte auf Bestätigung Gerät initialisieren: Steuerregister schreiben Datum ins Datenregister übertragen Gerät nimmt Tätigkeit auf Datenregister lesen Datum verarbeiten Unterbrechung Bestätigung Wenn Gerät Daten schneller liefert als die Task sie entgegennehmen kann Synchronisation durch Unterbrechung mit Handshake

77 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Speicher- und IO-Verwaltung Task 2 Task 1 Unterbrechung Unterbrechungs- Behandlungs- programm Zeit Task 3 Task-Scheduler des Echtzeitbetriebs- system Unterbrechungs- system des Prozessors Task 2 Task 1 Unterbrechung Unterbrechungs- Behandlungs- programm - - Zeit Task 3 Task 4 (Unterbrechungs- behandlung) a) Unterbrechung der Taskverarbeitung b) Integration der Unterbrechung in die Taskverarbeitung Task-Scheduler des Echtzeitbetriebs- system Unterbrechungs- system des Prozessors Unterbrechungsbehandlung in Echtzeitbetriebssystemen

78 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Klassifizierung und Beispiele von Echtzeitbetriebssystemen ThreadsTasksSemaphoreKomm.über DPRAM,FIFO NachrichtenSchedulerSpeicherverwaltungPhysikal. Adr.SpeicherverwaltungVirtuelle Adr.Ein/Ausgabe Verw.Einfache E/A TreiberKomfortable E/A Treiber,NetzwerkeFilesystem Minimales Echtzeitbetriebssystem (MEBS) xxxxxx Controller System (CS) xxxxxxx Dediziertes System (DS) xxxxxxx Betriebssystemaufsatz (BA) xxxxxxxxx Allgemeines Echtzeitbetriebssystem (EBS) xxxxxxxxx

79 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Klassifizierung und Beispiele von Echtzeitbetriebssystemen 1. Entwicklungs- und Zielumgebung Programmiersprache Zielsystem (ZE)- Crossentwicklungsumgebung (CE) - Ladezeiten bei Crossentwicklung - Debug-Möglichkeiten (CE): Quellcode-Debugging (C, C++, Java), Zeitverfälschung bei CE-Debugging - EBS und EU vom selben Hersteller 2.Modularität und Kerngröße Konfigurierbarkeit auf Anwendung Minimaler Mikrokern für eingebettete Systeme Auswahlkriterien für Echtzeitbetriebssysteme

80 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Klassifizierung und Beispiele von Echtzeitbetriebssystemen 3.Anpassbarkeit an verschiedene Zielumgebungen Ist EBS an Mikrocontroller/Signalprozessor mit spezieller Peripherie anpassbar? ROM-Fähigkeit für Code mit RAM für Daten Feldbusse verfügbar 4.Allgemeine Eigenschaften Bedieneroberfläche (Grafik, Kommandos, keine) Bibliotheken (Mathem., Graph., Textverarbeitung, …) Werkzeug für GUI-Echtzeitanwendungen Werkzeuge zur Versionsverwaltung, Datenhaltung oder zur Programmentwicklung

81 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Klassifizierung und Beispiele von Echtzeitbetriebssystemen 5.Leistungsdaten maximale Taskanzahl (Tasks, Threads) Welche Scheduling-Strategien Anzahl unterschiedlicher Prioritätsebenen (64-256) Taskwechselzeiten (Threads schneller als Tasks) Latenzzeiten bei Unterbrechungen Behandlung von Unterbrechungen (direkt – indirekt) EBS-Klasse für harte, feste, weiche Echtzeitanwendungen

82 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Klassifizierung und Beispiele von Echtzeitbetriebssystemen Industrielle Echtzeit- betriebssysteme

83 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Klassifizierung und Beispiele von Echtzeitbetriebssystemen Inter- Taskkom- munikation Netzwerk- Schnittstelle Unterbre- chungs- behandlung Scheduler Mikrokern Netzwerk- Manager Prozess- Manager Geräte- Manager Dateisystem- Manager weitere Systemtasks Prozessor, Speicher, Geräte Hardware Unter- brechungen Anwendertasks Task 1 Task n... Task 2 QNX QNX Architektur von QNX

84 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Klassifizierung und Beispiele von Echtzeitbetriebssystemen Posix POSIX- Standards

85 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Klassifizierung und Beispiele von Echtzeitbetriebssystemen POSIX.4: Echtzeit- erweiterungen

86 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Klassifizierung und Beispiele von Echtzeitbetriebssystemen Echtzeitkern Hardware Unterbrechungen Linux- Kern Echtzeit- Task 1... Linuxtask 1 m... Echtzeit-FIFO Kommunikation Echtzeit- Task n RTLinux Architektur von RTLinux

87 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Klassifizierung und Beispiele von Echtzeitbetriebssystemen Anwendung Nicht-Echtzeittasks Benutzerschnittstelle Grafik Datenhaltung, Datenaufbereitung,.... Echtzeittasks (Module) Aufgaben mit harten Echtzeitanforderungen Aufteilung der eingebetteten Anwendung in Nicht-Echtzeit und Echtzeittasks

88 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Klassifizierung und Beispiele von Echtzeitbetriebssystemen q Bei RT-Linux wird eine Task als Prozess bezeichnet q Ein Prozess enthält einem Thread und kann weitere zur Laufzeit erzeugen q Ein RT-Prozess wird über ein Kernel-Modul definiert: insmod "Prozessname" q Der Linux-Befehl insmod lädt das Kernel-Modul "Prozessname" und startet die Funktion init_module zur Initialisierung. q Innerhalb init_module können weitere Threads angelegt werden RT-Prozesse unter RTLinux

89 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Klassifizierung und Beispiele von Echtzeitbetriebssystemen q Erzeugen eines RT-Threads: int pthread_create(pthread_t *thread, pthread_attr_t *attr, void *(*start_routine)(void *), void *arg); Erzeugt einen Thread thread mit den Attributen attr (z.B. Stack-Größe) und startet ihn durch Aufruf der Funktion start_routine(arg ). start_routine(arg) ist die Funktion, welche die Thread- Aufgaben realisiert. q Beenden eines RT-Threads: int pthread_delete_np(pthread_t thread); q RT-Thread periodisch definieren: int pthread_make_periodic_np(pthread_t thread, hrtime_t start_time, hrtime_t period); Der Thread thread wird zum Zeitpunkt start_time gestartet und in durch period (in Nanosekunden) gegebenen Intervallen aufgerufen Funktionen zur Verwaltung von RT-Prozessen

90 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Klassifizierung und Beispiele von Echtzeitbetriebssystemen q Suspendieren eines RT-Threads: int pthread_suspend_np(pthread_t thread); Thread wird angehalten. Entspricht Blockiert-Zustand. q Aufwecken eines RT-Threads: int pthread_wakeup_np(pthread_t thread); Thread kann fortgesetzt werden. Entspricht Zustandsübergang Blockiert nach Bereit. q Periodischen Thread bis zur nächsten Periode suspendieren: int pthread_wait_np(void); Thread gibt Kontrolle an Scheduler bis zum nächsten periodischen Aufruf ab.

91 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Klassifizierung und Beispiele von Echtzeitbetriebssystemen pthread_t thread;/* Datenstruktur für Threads */ int init_module(void)/* wird beim Laden des RT-Moduls aufgerufen */ { /* Erzeugen eines Threads mit Funktion start_routine */ return pthread_create (&thread, NULL, start_routine, 0); } void cleanup_module(void) /* wird beim Entfernen des RT-Moduls aufgerufen */ { pthread_delete_np (thread); /* Entfernen (Löschen) des Threads */ } Beispiel: RT-Modul

92 Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte Klassifizierung und Beispiele von Echtzeitbetriebssystemen void *start_routine(void *arg)/* Implementierung der Thread-Funktion */ { struct sched_param p;/* Datenstruktur für Thread-Eigenschaften */ p. sched_priority = 1;/* Thread-Priorität in Datenstruktur eintragen */ /* Funktion zum Setzen der Thread-Parameter aufrufen */ /* SCHED_RR: Round Robin Scheduling (auch möglich: SCHED_FIFO) */ pthread_setschedparam (pthread_self(), SCHED_RR, &p); /* Periodischer Aufruf des Threads: Periode ist 0,5 sec, starte sofort */ pthread_make_periodic_np (pthread_self(), gethrtime(), ); while (1) { pthread_wait_np ();/* bis zur nächsten Periode warten */ rtl_printf("Hello, I'm here!\n");/* Thread-Funktion: Text-Ausgabe */ } return 0; }


Herunterladen ppt "Goethe-Universität Frankfurt am Main – Lehrstuhl für Eingebettete Systeme - Prof. Dr. U. Brinkschulte 1 4.3 Aufbau von Echtzeitbetriebssystemen Aufgaben."

Ähnliche Präsentationen


Google-Anzeigen