EchtzeitDV 2006 1 - DHBW Stuttgartrie/RZS/Vorlesung/EchtzeitDV... · 2013. 12. 2. · Echtzeitdatenverarbeitung ManabendraNarayanGupta manabendra.gupta@etas.de Dirk Böndel dirk.boendel@etas.de.
Post on 01-Feb-2021
1 Views
Preview:
Transcript
05.08.20081 © Copyright 2004, ETAS GmbH – LiveDevices Ltd. – Vetronix Corp. All rights reserved.
The names and designations used in this document are trademarks or brands belonging to the respective owners.
Echtzeitdatenverarbeitung
Manabendra Narayan Gupta
manabendra.gupta@etas.de
Dirk Böndel
dirk.boendel@etas.de
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
2
EchtzeitsystemeLernziele
• Folgende Fragen werden behandelt:– Was sind Echtzeitsysteme?– Wo werden Echtzeitsysteme eingesetzt?– Wodurch sind Echtzeitsysteme gekennzeichnet?– Aus welchen Komponenten bestehen Echtzeitsysteme?– Wie werden Echtzeitsysteme entwickelt?– Wie werden Echtzeitsysteme getestet (Echtzeitnachweis)?
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
3
EchtzeitsystemeLernziele
• Es werden die in der “Echtzeitwelt” gebräuchlichen Begriffe erläutert:– Hard- und Soft realtime– Scheduling– Task / Prozess / Thread– Critical Sections– Latency-Times– Laufzeitsystem– Preemption– Embedded Systems
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
4
• ProzeßUmformung und/oder Transport von Materie, Energie und/oder Information (deterministisch oder stochastisch).
• Technischer ProzeßProzeß, dessen Zustandsgrößen mit technischen Mitteln gemessen, gesteuert und/oder geregelt werden können.
⇐ Anmerkung: Prozeß in der Informatik ist
üblicherweise der Ablauf eines Programms, wenn
dieser Ablauf Verwaltungseinheit des Betriebssystems
ist.
EchtzeitsystemeGrundlegende Definitionen
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
5
EchtzeitsystemeGrundlegende Definitionen
• ProzeßführungErreichen eines vorgegebenen Ziels aus Kenntnis der Istwerte unter Berücksichtigung der Kapazitäten; flexible Anpassung an kleine Störungen; Anzeige in Prozeßwarten.
• SteuerungEinwirkung mittels Stellgrößen in eine gewünschte vorausgeplante Richtung.
� Pausenklingel um 9:45 einschalten• Regelung
Überwachung und Minimierung der Abweichung zwischen Ist- und Sollwerten nach gegebenen Kriterien.
� Kesseltemperatur auf 42 Grad halten
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
6
Echtzeitsysteme
Warum überhaupt Echtzeitsysteme?
• Geräte des täglichen Bedarfs (Mikrowelle,Video Recorder... )
• Fertigungsmaschinen (Werkzeugmaschinen,Roboter)
• Verkehrsmittel (Flugzeug, Pkw -> ABS und ESP, Magnetbahn)
• Militärische Geräte (Radarsystem, Lenksysteme..)
Komplexer
• Steuerung von Fertigungsanlagen (Walzwerke..etc.)
• Kontrolle und Überwachung von Kraftwerksanlagen etc.
• X-by-wire (Verteilte Systeme)
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
7
EchtzeitsystemeAllgemeine Ziele der Automatisierung
• Monotone oder gefährliche Arbeiten konstant gut ausführen (z.B. lackieren, schweißen, füllen, prüfen)
• stets ein hohes Maß an Präzision und Geschwindigkeit einhalten, trotzdem schnelle Reaktion auf Fehler
• Bewältigung und Verwaltung einer großer Datenflut, insbesondere bei Störfällen.
• Viele (oft kleine) Regelkreise überwachen.
• Komplexe Steuerungsvorgänge durchführen
• Wirtschaftlichkeit steigern, Termine halten und verkürzen (flexibel, schnell, billig)
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
8
EchtzeitsystemeAufgaben
• Datenerfassung, DatenprimärverarbeitungDatenerfassung, Übertragung, Plausibilitätskontrolle, Kalibrieren, Linearisieren, Fehlerkorrektur.
• ProzessüberwachungMesswertverarbeitung analoger und digitaler Signale Bedienung, Anzeige, Protokollierung
• Prozessstabilisierung, Prozessführung,Sollwertführung,Digitale Regelung (DDC Digital Direct Control)
• Prozessoptimierung
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
9
EchtzeitsystemeHistorie
• Bis 1960 Automatisierung einzelner Regelstrecken (Relaistechnik, Transistorschaltungen, Analogrechner)
• Ab ca. 1960 Einsatz von DigitalrechnernBegriff „Prozessrechner“ für damalige Eigenentwicklungen. (Kurzwortmaschinen 8-12 Bit-Worte)
• Ab ca. 1976 Massenproduktion von Mikrocomputern, insbesondere auch für „Embedded Systems“ - auch „klassische Prozessrechner“wie PDP11, LSI11, VAX
• Führung selbst kleinster technischer Prozesse durch Rechner (Tisch-PC;kundenspezifische Chips (ASIC, application specified IC) in Geräten und Maschinen, embedded systems
• globale Regelungs- und Überwachungsstrategien
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
10
EchtzeitsystemeHistorie
• Seit Anfang der 90er Standardrechner (Workstation und PC) mit ECHTZEIT-Betriebssystemen
• Bussysteme und Rechnernetze
• CIM (computer integrated manufacturing)
• Expertensysteme zur Prozessführung
• Moderne Entwicklungen
• Zentraler Prozessrechner durch vernetzte Rechensysteme ersetzt
• lokale Prozessrechner bei den einzelnen Komponenten des Prozesses
• heutige Kosten der Rechner erlaubt Regelung durch Rechner (nicht nur der „PID“ Regler)
• Punkt-zu-Punkt-Verbindungen zu den Ein-/Ausgabeeinheiten durch Feldbusse (Netze) ersetzt
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
11
EchtzeitsystemeEntwicklung in der Automobilelektronik
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
12
EchtzeitsystemeWie definiert man Echtzeitsysteme ?
• DIN 44300 (1985)
Echtzeitbetrieb ist ein Betrieb eines Rechensystems, bei dem Programme zur Verarbeitung anfallender Daten ständig betriebsbereit sind derart, dass die Verarbeitungsergebnisse innerhalb einer vorgegebenen Zeitspanne verfügbar sind.
Die Daten können je nach Anwendung nach einer zeitlich zufälligen Verteilung oder zu vorbestimmten Zeitpunkten anfallen.
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
13
EchtzeitsystemeWie definiert man Echtzeitsysteme ?
• J.Stankovic, K.Ramamritham (1990) What is predictability for Real-Time Systems?
Real-Time systems are those systems in which the correctness of the system depends not only on the logical result of computations, but also on the time at which the results are produced.
Echtzeitsysteme sind Informationsverarbeitungssysteme, an deren Korrektheit nicht nur logische, sondern auch zeitlicheBedingungen gestellt werden.
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
14
EchtzeitsystemeWie definiert man Echtzeitsysteme ?
Eingangsdaten AusgangsdatenFester Algorithmus
Rege
lung
Rechnersystem
Maus ScannerTastatur
t
Umwelt
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
15
EchtzeitsystemePhysikalische Zeit
• Lineare, monoton wachsende Funktion
• Uhr: Zähler + Schwingungsmechanismus der periodische Ereignisse auslöst
• mechanisch (Pendel)
• elektrisch (Schwingkreis, Quarz)
• physikalische Zeit im Rechner
• Timerbausteine (Zähler)
• Ereignis(Microtick) inkrementiert Zähler
• Auflösung(Granularity): Zeitspanne zwischen zwei Microticks
� diskrete Annäherung an „echte Zeit“
� Quantisierungsfehler
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
16
EchtzeitsystemePhysikalische Zeit
• Synchronisation
• externe Zeitquelle
Referenzuhr
• sehr hohe und hochkonstante Microtick-Rate(z.B.Atomuhr 9 192 631 770 Hz (108 ps))
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
17
EchtzeitsystemePhysikalische Zeit
t
t
Referenz-uhr
Zu messende Uhr
�
�
�
�
�
�
�
�
innerhalb der
zugesicherten
Gangabweichung
Verlassen der
zugesicherten
Gangabweichung
Zustandsfehler !
Sprung im Zählerwert
Stehenbleiben der Uhr
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
18
EchtzeitsystemeZeitstandards TAI
Internationale Atomzeit TAI
• Temps Atomique International „Atomzeit“
• basiert auf Emission des Isotops Cs133
• 1 Sekunde := 9 192 631 770 Perioden der Strahlung
• unter Laborbedingungen generierbar
• chronoskopisch (keine Diskontinuitäten)
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
19
EchtzeitsystemeZeitstandards UTC
Koordinierte Weltzeit UTC
• Universal Time Coordinated
• abgeleitet aus Rotation der Erde um die Sonne
• modiziert durch 24 Zeitzonen,
• Sommer-/Winterzeit-Festlegungen
• Basis der gesetzlichen Zeit
• ziemlich ungenau (1 Tag der Erdrotation = 86400.002 Sekunden), variiert -> ungeeignet als Zeitbasis
• zyklisch mit TAI synchronisiert durch Einfügen sog. „leap seconds“in UTC
• UTC nicht chronoskopisch
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
20
EchtzeitsystemeZeitbedingungen
Angabe eines genauen Zeitpunktes
t2t1 t3 t4
t1 t2
t1
1
0 t
1
0 t
1
0 t
1
0 t
t1
Zeitintervall für eine Aktion
Spätester Zeitpunkt für eine Aktion
Frühester Zeitpunkt für eine Aktion
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
21
EchtzeitsystemeZeitbedingungen
• DeadlineDer Zeitpunkt an dem das Echtzeitsystem ein Ergebnis liefern muss!!!
Deadlines, Zeitbedingungen allgemein, werden meist von den Umgebungsbedingungen des technischen Prozess bestimmt
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
22
EchtzeitsystemeHartes Echtzeitsystem
• Wenn es im Falle der Mißachtung der Deadline zu einer „Katastrophe“ kommt spricht man von harten Echtzeitsystemen �meist resultierend aus physikalischen Randbedingungen �Hard Deadline
• keine „Zeitfehler“- oder Fehlertoleranzmechanismen
0 t
Rechtzeitigkeit(Timeliness)
Deadline
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
23
EchtzeitsystemeWeiches Echtzeitsystem
• feste Echtzeitbedingungen � Firm Deadlinebewirken bei Überschreiten einen Abbruch der Aktion
• weiche Echtzeitbedingungen � Soft Deadlinekönnen in gewissen Grenzen überschritten werden, ohne zu fatalen Systemzuständen zu führen
0 t
Rechtzeitigkeit(Timeliness)
Deadline Deadline
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
24
EchtzeitsystemeVorrangige Anforderungen
• Rechtzeitigkeit (Stellgröße des Systems muss rechtzeitig zur Verfügung stehen, der Prozessor muss schnell genug sein)
• Gleichzeitigkeit (echt parallel, oder quasi-parallel -> mehrere Rechenprozesse-> Scheduling) Struktur des Systems
• Zuverlässigkeit, Sicherheit
• Vorhersagbarkeit (zeitlich)um die Einhaltung der Zeitbedingungen zu garantieren
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
25
EchtzeitsystemeAnforderungen
• Anschluss vielfältigster Peripherie (Sensorik, Aktorik)
• Modellierung der technischen Prozesse
• Mensch Maschine Schnittstelle
• Systemmanagementfunktionen
• TÜV - Abnahme
• Kostenminimierung
• Qualitätsmanagement
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
26
EchtzeitsystemeTime Triggered (TT) , Event Triggered (ET)
Ein Echtzeitsystem ist Time Triggered (TT) wenn Steuersignale, wie für das
• Senden und Empfangen von Botschaften
• Erkennen von Änderungen der Umgebungsbedingungen
alleine und nur von der fortschreitenden Zeit abhängen.
• Einzige Interrupts sind periodische Zeitgeber
• jeweils einige Sensoren werden abgefragt und Aktuatoren angesteuert
(Polling)
• im Notfall � keine Interruptlasterhöhung
• Probleme bei der Wahl des Pollingintervalls
• kurze Signale müssen gepuffert werden, um sie nicht zu verlieren
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
27
EchtzeitsystemeTime Triggered (TT) , Event Triggered (ET)
Ein Echtzeitsystem is Event Triggered (ET) wenn die Steuersignale alleine und nur vom Auftreten bestimmter Ereignisse, wie
• Beendigung einer Task
• Empfang einer Nachricht
• externer Interrupt.
• Interruptgesteuert: Ereignis � Sensor � Interrupt
• kurze Antwortzeiten
• anfällig bei hoher Last -> im Notfall
• Abläufe im System schwer plan- und nachvollziehbar
���� Umschaltung von ET auf TT bei hoher Interruptlast
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
28
Echtzeitsysteme
Wenn die Komplexität des betrachteten Systems mit der Größe zunimmt, gibt es eine Grenze des menschlichen Verstehens
Mental Effort
(Complexity)
Size
Human Mental
Capability
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
29
EchtzeitsystemeKomplexität und Größe
• Komplexe Systeme können nur realisiert werden, wenn es gelingt die Anstrengungen, welche man zum Verständnis des Systems (Komplexität) benötigt, beherrschbar zu machen.
• Der Aufwand um eine Systemfunktion begreifbar zu machen sollte konstant bleiben und unabhängig von der Größe des Systems sein
• Ein großes System beinhaltet viel mehr unterschiedliche Funktionen als ein kleines System
• Der Aufwand zum Verständnis aller Systemfunktionen wächst mit der Systemgröße
� Verteilte Systeme
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
30
EchtzeitsystemeNever touch a running System
Nehmen wir ein System an, welches ohne dokumentierte technische Architektur von Experten entwickelt wurde
• Das System ist in der Lage ein hohes Maß an Funktionalität innerhalb einer kurzen Zeit zu erreichen, da in den Köpfen der Experten ein Systemmodell existiert
• Sobald die ursprünglichen Entwickler „nicht mehr da“ sind, versteht niemand so recht wie das System genau funktioniert.
• Das System ist schwer zu warten -- Nobody wants to touch the running System
Das Herz des US Luftfahrtleitsystems ist ein IBM 360/65 Rechner der vor über 30 Jahren installiert wurde
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
31
EchtzeitsystemeVerfahren zur Echtzeit-Programmierung
Zwei grundlegende Verfahren
• synchrone Programmierung(TT - zeitgesteuerte Systeme)
• asynchrone Programmierung(ereignisgesteuert)
���� Zeitscheibenprogrammierung
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
32
EchtzeitsystemeSynchrone Programmierung
Das zeitliche Verhalten zyklisch auszuführender Teilprogramme wird vor ihrer Ausführung geplant
• Die zyklisch auszuführenden Teilprogramme werden mit einem Zeitraster synchronisiert (� synchrone Programmierung)
• Dieses Zeitraster wird mit einer Echtzeituhr gewonnen die in bestimmten Zeitabständen Unterbrechungssignale zum Aufruf der Teilprogramme erzeugt (� zeitgesteuertes System)
• Die Reihenfolge des Ablaufs der Teilprogramme wird vorgegeben
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
33
EchtzeitsystemeSynchrone Programmierung
Beispiel: Heizungsregelung
3 Regelstrecken:
• Heizkreis WohnungRegelgröße Raumtemperatur
• Heizkreis BüroRegelgröße Raumtemperatur
• HeizkesselRegelgröße Vorlauftemperatur
Abtastzeiten für die drei Regelstrecken:
T1 = T; T2 = 2T; T3 = 5T
Regelstrecke 1
„Heizkreis Wohnung“
Regelstrecke 2
„Heizkreis Büro“
Regelstrecke 3
„Heizkessel“
Analog-Ausgang Analog-Eingabe
Prozess-Signal-Ein/Ausgabe
Automatisierungs
computer
Echtzeit-
uhr
Bedien-
terminal
u1(t)
u2(t)
u3(t)
y1(t)
y3(t)
y2(t)
Raumtemperatur
Wohnung
Raumtemperatur
Büro
Vorlauf-
temperatur
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
34
EchtzeitsystemeSynchrone Programmierung
Teilprogramm Bezeichner
(Name)
Abtastzeit
(Zykluszeit)
Temperatur-Regelung für
die Regelstrecke
„Heizkreis Wohnung“
Temperatur-Regelung für
die Regelstrecke
„Heizkreis Büro“
Temperatur-Regelung für
die Regelstrecke
„Heizkessel“
Regelung 1
Regelung 2
Regelung 3
T1 = T
T2 = 2T
T3 = 5T
ANFANG
Alle T1 = T
REGELUNG 1
aufrufen
Alle T2 = 2T
REGELUNG 2
aufrufen
Alle T3 = 5T
REGELUNG 3
aufrufen
Warteschleife
Unterbrechungs
signal Von der
Echtzeituhr mit T
Grobplanung der Ausführung:
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
35
EchtzeitsystemeSynchrone Programmierung
ANFANG
Definition der
Zählvariablen Z2 und
Z3
REGELUNG1
abarbeiten
Z2:=1
Z3:=1
REGELUNG2
abarbeiten
REGELUNG3
abarbeiten
Z2:=1
Z3:=1
Z2:=2
?
Z2:=Z2 + 1
nein
ja
Z3:=Z3 + 1
Z3:=5
?
nein
ja
Warteschleife
Zeitabstand T
aufeinanderfolgende
Unterbrechungssignaleb
ewirken START an
dieser Stelle
Feinplanung
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
36
EchtzeitsystemeSynchrone Programmierung
Zeitlicher Ablauf
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
37
EchtzeitsystemeSynchrone Programmierung
• Festes, vorhersagbares Zeitverhalten
• einfache Analyse und Test des Systems
• bei richtiger Planung können Rechtzeitigkeit und Gleichzeitigkeit garantiert werden
• dadurch geeignet für sicherheitsrelevante Aufgaben
• sehr gut für zyklische Abläufe geeignet
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
38
EchtzeitsystemeSynchrone Programmierung
• Reaktion auf asynchrone Ereignisse ist nicht vorgesehen
Soll z.B. zusätzlich zu den drei Regelkreisen ein asynchrones Signal „Brennerstörung“ berücksichtigt werden: dies muss auch zyklisch überprüft werden-> schlechte Reaktionszeit, Verlängerung der Gesamtzykluszeit
• Nur geringe Flexibilität gegenüber Änderungen der Aufgabenstellung
Ändert sich die Aufgabenstellung, muss i.A. die gesamte Programmstruktur geändert werden.
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
39
EchtzeitsystemeAsynchrone Programmierung
• Hier wird der Ablauf der Teilprogramme nicht im voraus, sondernwährend des Programmablaufs geplant
• Dies erfolgt durch ein Organisationsprogramm(Echtzeit-Betriebssystem)
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
40
EchtzeitsystemeAsynchrone Programmierung
Aufgaben des Organisationsprogramms:
• Überwachung von Ereignissen, welche Aktion durch das System erfordern (-> ET ereignisgesteuertes System)Diese Ereignisse können sowohl zyklisch wie asynchron sein (-> asynchrone Programmierung)
• Entgegennahme von Informationen über einzuhaltende Zeitbedingungen für eingetretene Ereignisse bzw. zugehörige Aktionen
• Ermittlung einer Ablaufreihenfolge von Teilprogrammen zur Behandlung der eingetretenen Ereignisse
• Aktivierung eines Teilprogramms gemäß der Ablaufreihenfolge
Die Erfüllung dieser vier Teilaufgaben heißt Scheduling
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
41
EchtzeitsystemeAsynchrone Programmierung
Regelstrecke 1
„Heizkreis Wohnung“
Regelstrecke 2
„Heizkreis Büro“
Regelstrecke 3
„Heizkessel“
Analog-Ausgang Analog-Eingabe
Prozess-Signal-Ein/Ausgabe
Automatisierungs
computer
Echtzeit-
uhr
Bedien-
terminal
u1(t)
u2(t)
u3(t)
y1(t)
y3(t)
y2(t)
Digital-
Ausgabe
Digital-
Eingabe
Warn-
lampe
Brenner
Störungs-
signal
Beispiel: Heizungsregelung mit asynchroner Brennerstörung
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
42
EchtzeitsystemeAsynchrone Programmierung
Hierzu soll eine einfache Real-Time-Scheduling-Strategie verwendet werden:
• Jedes Ereignis erhält eine feste Priorität
• Die Reihenfolge der Ausführung erfolgt nach dieser Priorität
• Ereignisse höherer Priorität unterbrechen Ereignisse niederer Priorität
� Fixed-Priority-Preemptive-Strategy
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
43
EchtzeitsystemeAsynchrone Programmierung
Ereignisse sind hierbei im Beispiel:• asynchrones Ereignis „Brennerstörung“ (Auslöser: Sensor)
• zyklisches Ereignis „Regelung Heizkeis 1“ (Auslöser: Uhr)
• zyklisches Ereignis „Regelung Heizkeis 2“ (Auslöser: Uhr)
• zyklisches Ereignis „Regelung Heizkessel“ (Auslöser: Uhr)
Zuordnungder Prioritäten:
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
44
EchtzeitsystemeAsynchrone Programmierung
Soll- und Ist-Verlauf der Ausführung der vier Teilprogramme:
• Die Rechtzeitigkeit wird hier nur
näherungsweise erfüllt
• Die Zykluszeiten variieren
• Je höher die Priorität, desto
besser werden die
Zeitbedingungen eingehalten -
Zeitablauf und Aufeinanderfolgen
der Programme stellen sich
dynamisch ein
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
45
Eigenschaften der asynchronen Programmierung:
• Flexibler Programmablauf und Programmstruktur
• Reaktion auf zyklische wie asynchrone Ereignisse möglich
• Die Rechtzeitigkeit kann jedoch nicht in jedem Fall im Voraus garantiert werden
• Je nach verwendeter Scheduling-Strategie ist es aber möglich, Rechtzeitigkeit zu garantieren, wenn zur Laufzeit bestimmte Bedingungen eingehalten werden
• Schwierige Systemanalyse und -test
• Wird heute wegen großer Flexibilität verstärkt verwendet
EchtzeitsystemeAsynchrone Programmierung
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
46
EchtzeitsystemeAufgaben eines Betriebssystems
• Prozessverwaltung: Steuerung und Organisation der ablaufenden Teilprogramme ���� Zuteilung des Prozessors an die Rechenprozesse oder Tasks
• Synchronisation: Zeitliche Koordinierung der Rechenprozesse
• Interprozesskommunikation: Kommunikation zwischen Rechenprozessen
• Betriebsmittelverwaltung: Zuteilung von Betriebsmittel an Rechenprozesse. Dies beinhaltet im wesentlichen:
• Speicherverwaltung: Zuteilung von Speicher
• IO-Verwaltung: Zuteilung von IO Geräten
• Schutzmaßnahmen: Schutz der Betriebsmittel vor unberechtigten Zugriffen durch Rechenprozesse
Zusätzliche Aufgaben eines Echtzeitbetriebssystems
• Wahrung der RechtzeitigkeitRechtzeitigkeit und GleichzeitigkeitGleichzeitigkeit
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
47
EchtzeitsystemeProzessverwaltung
• TASK:ablaufendes Programm zusammen mit allen zugehörigen Variablen und Betriebsmitteln
• Eine Task ist ein vom Betriebssystem gesteuerter Vorgang der Abarbeitung eines sequentiellen Programms.
• Hierbei können mehrere Tasks quasi-parallel vom Betriebssytembearbeitet werden, der tatsächliche Wechsel zwischen den einzelnen Tasks wird vom Betriebssystem gesteuert.
• Da sie von einer Task zu bewältigenden Aufgaben oft sehr komplex sind:���� Einführung von THREADs (Prozesse)
Hierarchie von parallel bzw. quasiparallelausführbaren Objekten
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
48
EchtzeitsystemeProzessverwaltung
P1 P2Task A P4
t
Threads
(Processes)
P3
Task: schwergewichtiger schwergewichtiger ProzeProzeßß mit Variablen und Betriebsmitteln
Thread: leichtgewichtiger leichtgewichtiger ProzeProzeßß innerhalb einer Task, benutzt die Variablen und Betriebsmittel der Task
PROCESS
TASK
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
49
EchtzeitsystemeProzessverwaltung
TASK PROCESS
Besitzer von Betriebsmitteln Kann außer dem Prozessor selbst
keine Betriebsmittel besitzen,
verfügt über alle Betriebsmittel
der Task, der er angehört
Eigener Adressraum Adressraum der Task, der er
angehört
Enthält einen oder mehrere
Processes
Element einer Task
Kommunikation über die
Taskgrenzen hinaus, bevorzugt
über Botschaften
Kommunikation zwischen den
Processes, bevorzugt über
globale Daten
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
50
EchtzeitsystemeProzessverwaltung
0 - 2T: Task muss nicht ausgeführt werden (ruhend)2T - 4T: Task muss ausgeführt werden (ablaufwillig), wird jedoch zwischenzeitlich
von höherprioren Tasks daran gehindert
Nur wenn keine höherprioren Task ablaufwillig ist, kann die Task ausgeführt werden (ablaufend)
• Beim zeitlichen Ablauf einer Task können mehrere Zustände
unterschieden werden. Beispiel:
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
51
EchtzeitsystemeProzessverwaltung
Heute üblich: Modell mit 4 Taskzuständen ruhend (dormant):die Task ist nicht ablaufbereit, weil Zeitbedingungen oder andere Voraussetzung nicht erfüllt sindbereit, ablaufwillig (runnable):die Task ist bereit, alle Zeitbedingungen sind erfüllt und Betriebsmittel zugeteilt, es fehlt lediglich die Zuteilung des Prozessorslaufend (running):die Task wird auf dem Prozessor ausgeführtblockiert (suspended):die Task wartet auf das Eintreten eines Ereignisses (z.B. einen IO-Wert, Komm.,Sync)
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
52
EchtzeitsystemeEchtzeitbetriebssysteme
• Unter Betriebssystem versteht man alle Programme eines digitalenRechensystems, die zusammen mit den Eigenschaften der Rechenanlage die Grundlage der möglichen Betriebsarten des digitalen Rechnersystems bilden und insbesondere die Abwicklung von Programmen steuern und überwachen.
• Ein Betriebssystem ist ein Kontrollprogramm, das die vorhandenenBetriebsmittel (Ressourcen) den konkurrierenden Rechen-TASKS zuteilt
• Ein Echtzeitbetriebssystem muss in der Lage sein, die Betriebsmittel und die darauf aufsetzenden Rechenprozesse so zu verwalten, dassdas Echtzeitsystem als Ganzes in den geforderten Toleranzen deterministisch arbeitet
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
53
EchtzeitsystemeEchtzeitbetriebssystem Anforderungen
• Garantie der geforderten Rechtzeitigkeit und Gleichzeitigkeit
• I/O Management und Hardwaresteuerung (Gerätetreiberverwaltung)
• Sicherstellung der Unterbrechungsfähigkeit (Interruptverwaltung)
• Sichere Verwaltung der Rechenprozesse und des Systemspeichers (Taskverwaltung)
• Definierte Reaktion auf Fehlerzustände (Fehlerverwaltung und -behandlung)
• Bereitstellung der Ressourcen zur Taskkommunikation und Synchronisation
• Bereitstellung von Ressourcen zur Steuerung zeitlicher Abläufe
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
54
Konfi
guri
erbar
e
Tei
leZ
usätze v
on
Drittan
bietern
Memory
Management
Interrupt
Intertask
Communication
Timer
Hardware Gerätetreiber und Initialisierungsroutinen
Applikation Rechnerprozesse
EchtzeitsystemeEchtzeitbetriebssystem Aufbau
KERNKERNKERN
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
55
EchtzeitsystemeTaskverwaltung
• Scheduling-Verfahren:Strategien zur Zuteilung des Prozessors an ablaufwillige Tasks
���� Dies wird vom Scheduler durchgeführt
• Aufgabe eines Echtzeit-Schedulers:
• Aufteilung des Prozessors zwischen allen quasi-parallel ablaufwilligen Tasks derart, daß alle Zeitbedingungen eingehalten werden
• Menge aller verwalteten Tasks: Taskset
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
56
EchtzeitsystemeTaskverwaltung
• Randbedingungen:
• gibt es für ein Taskset überhaupt ein ScheduleSchedule, welches alle Zeitbedingungen gerecht wird (scheduling test)?
• Ist dieses Schedule (so es existiert) in endlicher Zeit zu berechnen?
• Findet das verwendete Scheduling-Verfahren ein Schedule, wenn dieses existiert und in endlicher Zeit zu berechnen ist (optimales Scheduling)
• Nach diesen Randbedingungen können Scheduling-Verfahrenbewertet werden
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
57
EchtzeitsystemeTaskverwaltung
Klassifizierung von Scheduling-Verfahren
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
58
EchtzeitsystemeTaskverwaltung
Statisch: synchrone Programmierung
• das Scheduling-Verfahren berechnet vor der Ausführung der Tasks eine Tabelle
���� dispatching table/time table TT
• Dort sind die Startzeiten der einzelnen Tasks vermerkt
• Hierbei können umfangreiche Analysen durchgeführt werden, z.B. über Deadlines, Ausführungszeiten, Abhängigkeiten, Reihenfolgenbeziehungen und Ressourcen
• Die Zuteilung erfolgt zur Laufzeit nach dieser Tabelle durch einen Dispatcher
minimaler Overhead, da zur Laufzeit keine Entscheidungen mehr getroffen werden müssen, aber Nachteile der synchronen Programmierung
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
59
EchtzeitsystemeTaskverwaltung
Dynamisch: asynchrone Programmierung
• das Scheduling-Verfahren berechnet die Ausführung der Tasks während der Laufzeit
• Auch hierbei werden je nach Verfahren Analysen über Deadlines, Ausführungszeiten und Abhängigkeiten durchgeführt
• Dies kann zu erheblichem Laufzeit-Overhead führen
höherer Overhead, verringerter Determinismus, aber Vorteile der asynchronen Programmierungen
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
60
EchtzeitsystemeTasks
Weiteres Unterscheidungsmerkmal:
•• preemptivepreemptive:eine Task höherer Priorität kann eine Task niederer Priorität zur Laufzeit verdrängen. Die höchstpriore bereite Task kommt sofort zur Ausführung.
•• cooperativecooperative (~ nicht preemptiv):eine laufende Task kann nicht unterbrochen werden erst wenn eineTask sich selbst „aufgibt“, kommt die höchstpriore bereite Task zur Ausführung.
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
61
EchtzeitsystemeCooperative and preemptive multitasking
cooperative
preemptive
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
62
EchtzeitsystemePreemptive Task
• Diese ist zu jeder Zeit unterbrechbar mit der Granularität einer
Maschinenspracheoperation. Die Unterbrechung kann durch
• eine andere preemptive Task
• mit einer höheren Priorität, oder durch eine Interrupt Service Routine
erfolgen.
Zeit
Priorität
hoch
nieder
Betriebssystem
Ereignisse
t1 (preemptive)
runningp1 p2
running p2
suspended
t2 (preemptive)
runningp1 pmp2 ...
pn...
Zeit
Priorität
hoch
nieder
Betriebssystem
Ereignisse
t1 (preemptive)
runningp1 p2
running p2
suspended
isr
pn...
BMW AG
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
63
EchtzeitsystemePreemptive Task
• Eine Unterbrechung durch eine cooperative Task, auch solch einer
mit höherer Priorität, ist nicht möglich!
Zeit
Priorität
hoch
nieder
Betriebssystem
Ereignisse
t2 (cooperative)
runningp1 pmp2 ...
ready
t1 (preemptive)
runningp1 pnp2 ...
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
64
EchtzeitsystemeCooperative Task
• Dieser Tasktyp, der nicht in OSEK (www.osek-vdx.org) spezifiziert
ist, kann jeweils an seinen Prozessgrenzen durch
• eine andere cooperative Task mit einer höheren Priorität unterbrochen
werden.
Zeit
Priorität
hoch
nieder
Betriebssystem
Ereignisse
p1 p2
running
t2 (cooperative)
runningp1 pmp2 ...
pn...t1 (cooperative)
running p1 p2
suspended p3
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
65
EchtzeitsystemeCooperative Task
• Er kann mit der Granularität einer Maschinenspracheoperation von
einer
• preemptive Task mit einer höheren Priorität
• sowie einer preemptive Task mit einer niedrigeren Priorität oder ....
Zeit
Priorität
hoch
nieder
Betriebssystem
Ereignisse
t2 (preemptive)
runningp1 pmp2 ...
t1 (cooperative)
runningp1 p2
running p2
suspended pn...
Zeit
Priorität
hoch
nieder
Betriebssystem
Ereignisse
t2 (preemptive)
runningp1 pmp2 ...
t1 (cooperative)
runningp1 p2
running p2
suspended pn...
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
66
EchtzeitsystemeCooperative Task
• ... eine Interrupt Service Routine unterbrochen werden.
Zeit
Priorität
hoch
nieder
Betriebssystem
Ereignisse
t1 (cooperative)
runningp1 p2
running p2
suspended
isr
pn...
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
67
EchtzeitsystemeNonpreemptive Task
• Diese ist nicht durch andere Tasks unterbrechbar, sie läuft bis zu
ihrer Terminierung.
• Ihre Unterbrechung ist nur durch eine Interrupt Service Routine möglich.
Zeit
Priorität
hoch
nieder
Betriebssystem
Ereignisse
t2 (preemptive)
runningready
t1 (nonpreemptive)
running
Zeit
Priorität
hoch
nieder
Betriebssystem
Ereignisse
t1 (nonpreemptive)
running runningsuspended
isr
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
68
Schedulingfunktion
Real Time Operating Systems, Prof. Dr. Franz J. Rammig, Universität Paderborn, SS 2003
σ(t) ……….. Integer-Schrittfunktion
σ(t) = k ….. Task k wird zum Zeitpunkt t ausgeführt.
σ(t) = 0 …… Zum Zeitpunkt t wird keine Task ausgeführt.
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
69
Zeitdefinitionen
• Arrival time ai: Zeitpunkt des Eintreffens der Taskanforderung
• Computation time ci: Berechnungszeit der Task(~Worst Case Execution Time)
• Deadline di: Zeitpunkt zum dem die Task beendet sein muss
• Start time si: Tatsächlicher Startzeitpunkt
• Finishing time fi: Tatsächliches Berechnungsende
Real Time Operating Systems, Prof. Dr. Franz J. Rammig, Universität Paderborn, SS 2003
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
70
Metriken zur Beurteilung des Scheduling
• Durchschnittl. Anwortzeit:
• Gesamtausführungszeit:
• Maximale Verspätung:
• Anzahl verspäteter Tasks:
mit
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
71
Prozessorauslastung durch Scheduling
• Prozessorauslastung:(U… utilizaton factor)
• U kann beeinflusst werden durch:
• Rechenzeiten der einzelnen Tasks
• Wiederholdauer der einzelnen Tasks („Gesamtwiederholdauer“ des Scheduling)
• Durch Erhöhung von ci und Verringerung von ti kann U bis an die Grenze der Nichtrealiserbarkeit erhöht werden.
• Optimale Ausnutzung des Prozessors bei U = 1
• U = 1 in der Realität nur für statisches Scheduling möglich
< N (21/N-1) - Grenzwert -> 0.693 [69.3 %]
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
72
EchtzeitsystemeScheduling Verfahren
• FIFO (First in First out)
• Zeitscheibenverfahren (Round Robin)
• Verfahren der kleinsten Restantwortzeit (Earliest Deadline First EDF)
• Verfahren des kleinsten Spielraumes (Least Laxity)
• Feste Prioritäten (Fixed Priority)
• Dynamische Prioritäten
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
73
EchtzeitsystemeFIFO Scheduling
• Es werden die Tasks in der Reihenfolge abgearbeitet, in der sie den Zustand „bereit“ eingenommen haben -> diejenige Task, die am längsten auf Ausführung wartet, erhält den Prozessor zugeteilt
• Eine laufende Task wird hierbei nicht unterbrochen -nichtpreemptives Verfahren
• Vorteile: einfacher Algorithmus, geringe Rechenzeit des Schedulers
• Nachteil: für Echtzeitanwendungen im Vergleich zu den zuvor gennannten Verfahren am wenigsten geeignet, da Zeitbedingungen der einzelnen Tasks überhaupt nicht in das Scheduling eingehen-> keinerlei Garantie der RECHTZEITIGKEIT
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
74
EchtzeitsystemeTime-Slice-Scheduling (Zeitscheibenverfahren)
• Jede Task erhält abwechselnd für eine feste Zeit den Prozessor zugeteilt
• Die Reihenfolge entspricht hierbei der Reihenfolge der Tasks in der Taskverwaltungsliste des Betriebssystems
• Die Zeitdauer kann individuell festgelegt werden
• Vorteile:
• ebenfalls einfaches Verfahren
• jede Task erhält Rechenzeit (kein Aushungern)
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
75
EchtzeitsystemeTime-Slice-Scheduling (Zeitscheibenverfahren)
• Nachteile
• die Periodendauer, in der eine Task aufgerufen wird, hängt von der Gesamtzahl der Tasks ab
• die Reaktionszeit auf ein Ereignis kann recht lang sein, wenn eine Task gerade ihre Zeitscheibe verbraucht hat
Für Echtzeitsysteme nur bedingt geeignet(wird aber in vielen Echtzeitbetriebssystemen verwendet)
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
76
EchtzeitsystemeRound Robin (spezielles Time-Slice-Sched.)
• Jede Task erhält gleichberechtigten Zugang zum Prozessor.
• n Tasks -> jede Task erhält innerhalb eines Zeitintervalls T, den Prozessor für t=T/n zugeteilt
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
77
EchtzeitsystemeEarliest Deadline First Scheduling
• Diejenige Task mit der frühesten Deadline, bekommt den Prozessor zugeteilt-> kleinste Restantwortzeit
• Wird zur Laufzeit festgestellt, dass eine andere Task mit geringerer Restantwortzeit in Zustand „bereit“ gelangt, so wird die laufende Task unterbrochen-> preemptives Verfahren
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
78
EchtzeitsystemeEarliest Deadline First Scheduling
• Vorteile:
• erlaubt eine Prozessorauslastung von 100%
• zumindest für zyklische Tasks kann gezeigt werden: Wenn es einen ausführbaren Schedule gibt, so liefert ihn EDF
• Nachteile:
• relativ hoher Rechenaufwand, da ständig verbleibende Restantwortzeiten ermittelt werden müssen.
• EDF ist nicht optimal, wenn Datenraten garantiert werden müssen
EDF ist sehr gut für TASKS mit harten Deadlines geeignet
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
79
EchtzeitsystemeLeast Laxity Scheduling
• Diejenige Task erhält den Prozessor zugeteilt, welche den geringsten Spielraum besitzt
• Spielraum: Differenz zwischen Deadline und tatsächlicher Ausführungszeit
• Wird zur Laufzeit festgestellt, dass eine andere Task mit geringerem Spielraum in den Zustand „bereit“ gelangt, so wird die laufende Task unterbrochen -> preemptives Verfahren
• Im Gegensatz zu EDF wird hier auch die reale Ausführungszeit einer Task berücksichtigt
• Vorteile: liefert noch bessere Schedules für Tasksets als EDF
• Nachteil: noch höherer Rechenaufwand als bei EDF
• LL ist für die Einhaltung harter Deadlines das beste, aber auch aufwendigste Verfahren.
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
80
EchtzeitsystemeFixed Priority Scheduling
• Jeder Task wird hier eine feste Priorität zugeordnet
• Von den sich im Zustand „bereit“ befindenden Tasks wird diejenige mit der höchsten Priorität ausgewählt
• Dieses Verfahren kann preemptiv oder nicht preemptiv verwendet werden ->
• Fixed-Priority-Preemptive Scheduling
• Fixed-Priority-Nonpreemptive Scheduling
• einfaches Verfahren
• insbesondere Fixed-Priority-Preemptive kann die Einhaltung von Zeitbedingungen garantieren-> z.B. ......
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
81
EchtzeitsystemeFixed Priority Scheduling
Beispiel: Rate-Monotonic-Scheduling
• Hierbei werden periodisch auszuführenden Tasks eine Priorität umgekehrt zu ihrer Periodendauer zugewiesen. -> Je kürzer die Periodendauer desto höher die Priorität.
Pi~1/Timit Ti : Periodendauer der Task i, Pi : Priorität der Task i
Unter den Voraussetzungen:
• konstante Periodendauer
• Deadline = Periodendauer
• konstante, bekannte Ausführungszeit einer Task
• voneinander unabhängige Tasks
es kann vorab geprüft werden, ob alle Deadlines eingehalten werden
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
82
EchtzeitsystemeFixed Priority Scheduling
BEISPIEL: Steuerung eines fahrerlosen Transportsystems (FTS)
• Spurführung: Reflexband am Boden, beobachtet durch CCD-Zeilenkamera
• Positionserkennung:Transpondergestützte Landmarken
aus Echtzeitsysteme Prof. Dr.-Ing. Wörn
Institut für Prozessrechentechnik, Automation und Robotik (IPR) Karlsruhe
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
83
EchtzeitsystemeFixed Priority Scheduling
• 3 TasksTask 1: CCD-Kamera auslesenTask 2: SpurregelungTask 3: Landmarkenerkennung
Verhältnis Ausführungszeit /Maximalzeit (Deadline)
Es sollte ein ausführbares Schedule existieren !!!
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
84
EchtzeitsystemeFixed Priority Scheduling
• 1. Zu erfüllende Prioritätsbedingung:PrioritätSpurregelungs Task > PrioritätLandmarken Task
denn andernfalls kann die Deadline der Spurregelungs Task verpaßtwerden (ganz unabhängig von der Kamera Task)
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
85
EchtzeitsystemeFixed Priority Scheduling
• 2. Zu erfüllende Prioritätsbedingung:PrioritätKamera Task darf nicht die geringste Priorität sein
Denn andernfalls kann die Deadline der Kamera Task verpaßtwerden:
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
86
EchtzeitsystemeFixed Priority Scheduling
Unter diesen Bedingungen bleiben nur zwei mögliche Prioritätsverteilungen übrig:
1. PSpurregelungs Task > PKamera Task > PLandmarken Task 2. PKamera Task > PSpurregelungs Task > PLandmarken Task
Aber auch diese Prioritätsverteilungen können das Einhalten der Zeitbedingungen nicht garantieren
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
87
SojournerWas passierte …
• Rover landet Juli 1997 auf der Marsoberfläche
• Zunächst erfolgreicher Missionsverlauf• Nach einigen Tagen:
• Systemresets
• Datenverlust
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
88
SojournerAufbau des Betriebssystems (VxWorks)
• Datenaustausch zur Erde über „Information Bus“
• Zugriff auf „Information Bus“ erfolgt über Mutex (mutual exclusionlocks)
• Preämptives Scheduling mit festen Prioritäten
• Hochpriore, schnell wiederholende Task zur Verwaltung der Mutex
• Mittelpriore Tasks zur allgemeinen Kommunikation über „Information Bus“
• Niederpriore Task zur Sammlung von meteorologischen Daten und deren Versendung über „Information Bus“
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
89
SojournerEintreten des Deadlocks
• Niederpriore Task zur Versendung der meteorologischen Daten kann über Mutex den „Information Bus“ blockieren.
• Alle anderen Tasks zur Versendung von Daten müssen in diesem Fall die Freigabe des Mutex abwarten.
• Höherpriore, langlaufende Tasks können unterbrechen während Mutex noch nicht wieder freigegeben ist.
• Priority Inversion
• Dadurch Verzögerung in allen Tasks, die auf „Information Bus“ über Mutex zugreifen.
• Zeitgesteuerter Watchdog löst kompletten Systemreset aus, der zu Datenverlust führt
• Priority Inheritence wurde aus Laufzeitgründen für die HochprioreBus-Verwaltungstask ausgeschaltet.
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
90
Priority Ceiling Protocol
Ohne PCP
Delay of Task C
because of Task B
(priority
inversion)
prio
B
C
A R R R
R
tt0 t1 t2t3
No Delay of Task C because of
Task Bprio
B
C (A‘)
A
t
RR
t0 t1 t2
Mit PCP
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
91
EchtzeitsystemeKooperation
• Tasks (Prozesse) erledigen i.allg. bestimmte Teilaufgaben im Rahmen der vorgegebenen Gesamtaufgabe. Das gemeinsame Ziel wird durch Kooperation erreicht. Es gibt zwei elementare Formen der Kooperation (paralleler) Tasks(Prozesse)
• Das Produzenten/Konsumenten-System (Erzeuger/Verbraucher-System)
• Das Auftraggeber/Auftragnehmer-System (client/server -System)
Produzent
Konsument
Auftraggeber
Auftrag-nehmer
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
92
EchtzeitsystemeKonkurrenz
• Abhängigkeiten zwischen Tasks (Prozessen) können sich aus einer KonkurrenzKonkurrenz ergeben.Sie entsteht, wenn die Aktivitäten eines Prozesses die eines anderen zu behindern drohen.
• Zwei Autos konkurrieren um die Benutzung einer nur einspurig zu befahrenden Brücke
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
93
EchtzeitsystemeSynchronisation
• Die Koordination der Kooperation und Konkurrenz zwischen Tasks (Prozessen) nennt man SynchronisationSynchronisation. Sie bringt die Aktivitäten verschiedener (paralleler) Tasks (Prozesse) in eine Reihenfolge.
• Den Informationsaustausch über Taskgrenzen hinweg nennt man KommunikationKommunikation.
•• KommunikationKommunikation und SynchronisationSynchronisation bedingen sich gegenseitigZum Abstimmen zweier Aktivitäten können Tasks (Prozesse)
Informationen austauschen. Zum Zweck des Austauschs müssen sie
die Aktivitäten der Informationsabgabe und -aufnahme aufeinander
abstimmen.
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
94
EchtzeitsystemeInterprozesskommunikation
Auf die Variablen/Daten kannvon mehr als einem Prozess
zugegriffen werden
Gemeinsame Variablen/Daten(shared variables)
Prozesse senden underhalten Botschaften
Botschaften-Austausch(message passing)
Interprozesskommunkation
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
95
EchtzeitsystemeSynchronisations-Mechanismen
AKTIVES WARTEN
(busy waiting)
SEMAPHORE
Stellt sicher, daß kein Zugriff
erfolgt, wenn die gemeinsame
Variable in einem Zustand ist der
für einen Zugriff ungeeignet ist
Bedingungssynchronisation(condition synchronisation)
MONITORE
Stellt sicher, daß eine
Anweisungssequenz als un-
teilbare Operation behandelt wird
(kritischer Abschnitt, critical section)
Wechselseitiger Ausschluß(mutual exclusion)
Kommunikation übergemeinsame Variablen/Daten
Sender wird beim Senden
nicht verzögert:
-Puffer für Kanal nötig
-Botschaften z.T. veraltet
asynchron
Sender und Empfänger müssen
zum Informationsaustausch
bereit sein
synchron
Kommunikation durchBotschaften-Austausch
Synchronisationsmechanismen
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
96
EchtzeitsystemeBedingungssynchronisation
Eine Synchronisation zweier Aktivitäten A1 und A2, die zu verschiedenen Prozessen gehören und in der Relation A1 -> A2 (A1 geschieht vor A2) stehen, beeinflußt nur die Ausführung der Aktivität A2
Sie verzögert A2 so lange, bis A1 zum Abschluß gekommen ist. Ist A1 bereits abgeschlossen, tritt keine Verzögerung ein. Die Synchronisation wirkt sich in keinem Fall auf A1 aus, deshalb heißt sie auch einseitig.
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
97
EchtzeitsystemeWechselseitiger Ausschluß
Stehen zwei Aktivitäten A1 und A2, die zu verschiedenen Tasks (Prozessen) gehören, zueinander in der Relation A1 A2 (A1 nicht zusammen mit A2), dann kann es vorkommen, daß eine der beiden Aktivitäten A1 oder A2 verzögert werden muß. Soll A2 begonnen werden, während A1 durchgeführt wird, verzögert sich ihr Start so lange, bis A1 zum Abschluß gekommen ist. Analog gilt dies für A1, wenn A2 bereits begonnen wurde.
-> mehrseitig
Anweisungen, deren Ausführung einen gegenseitigen Ausschlußerfordert, heißen kritische Gebietekritische Gebiete.
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
98
EchtzeitsystemeKommunikation über Botschaften
• Eine Kommunikation über Botschaften ist immer dann erforderlich, wenn Tasks(Prozesse) keine gemeinsamen Speicherbereiche besitzen
• Der Transfer der Informationen von einem Datenbereich in den anderen geschieht über Botschaften Botschaften ((messagesmessages))
• send Botschaft to Empfänger -> Empfänger.send(Botschaft)
• receive Botschaft from Sender-> Sender.receive(Botschaft)
Prozess 1 Prozess2Botschaft
Kommunikationskanal
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
99
EchtzeitsystemeKommunikationskanäle
•• Direkte AdressierungDirekte Adressierung (direct naming)Versendung unter Angabe des Namens des Empfänger-Prozesses.
• Für eine Kommunikation führt der Sender-Prozess send Botschaft to Empfänger-Prozess
und der Empfänger-Prozess die Anweisungreceive Botschaft from Sender-Prozess
aus.
• Keinen Namen für den Kommunikationskanal
• implizite Einrichtung des Kanals ->Pipeline, pipe
• Sehr gut geeignet für Produzenten/Konsumenten Systeme
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
100
EchtzeitsystemeKommunikationskanäle
•• PortPort (port)
• Alle Senderprozesse können auf einen gemeinsamen globalen Speicherplatz, PORT genannt, zugreifen. Der Name des Ports ist den Senderprozessen bekannt.
send Botschaft to port..receive Botschaft from port
Kunde 1
Kunde 2
Kunde 3
Port Server
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
101
EchtzeitsystemeKommunikationskanäle
•• Globale AdressierungGlobale Adressierung (global naming, mail boxes)
• Alle Prozesse versenden ihre Botschaften an einen BriefkastenBriefkasten(mailbox)
send Botschaft to Briefkasten..receive Botschaft from Briefkasten
Druckklient 1
Druckklient 2
Druckklient 3
Mailbox
Drucker 1
Drucker 2
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
102
EchtzeitsystemeSynchrone Kommunikation
• Jeder Prozess der eine Sende- oder Empfangsanweisung durchführt wird solange blockiert, bis der Kommunikationspartner die entgegengesetzte Empfangs- oder Sendeanweisung ausführt.
• blockierende Kommunikation /synchrone Kommunikation
sendsendreceive
receive
blockiertblockiert
P1 P1P2 P2
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
103
Virtuelle Gleichzeitgkeit
aus P.Feisthammel: Verteilte Systeme, 2001
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
104
Virtuelle Gleichzeitigkeit
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
105
Virtuelle Gleichzeitigkeit
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
106
EchtzeitsystemeRemote Procedure Call RPC
• Keine einseitige Kommunikation
der Sendeprozess sendet eine Botschaft an einen Empfängerprozess. Dieser verarbeitet die Daten und sendet die Ergebnisse an den Sendeprozess zurück....send Botschaft1 to prozess2receive Botschaft2 from prozess2...receive Botschaft1 from prozess1send Botschaft2 to prozess1
Prozess 1 Prozess2
Botschaft 1
Botschaft 2
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
107
EchtzeitsystemeRemote Procedure Call RPC
task Auftraggeber iseingeben: e-typ;ausgeben:a-typ;
beginloop ....
send eingeben to Auftragnehmer;receive ausgeben from Auftragnehmer;....
end loop;end Auftraggeber;task Auftragnehmer is
eingeben: e-typ;ausgeben:a-typ;procedure Auftrag (ein: in e-typ; aus: out a-typ) is--Auftrag bearbeitenend Auftrag;
beginloop ....
receive eingeben from Auftraggeber;Auftrag (eingeben,ausgeben);send ausgeben to Auftraggeber;....
end loop;end Auftragnehmer;
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
108
EchtzeitsystemeRemote Procedure Call RPC
• Hin- und Rückkommunikation werden in einem Prozeduraufruf zusammengefasst -> Prozedurfernaufruf(remote procedure call)
task Auftraggeber is
eingeben: e-typ;
ausgeben:a-typ;
begin
loop ....
Auftragnehmer.Auftrag(eingaben, ausgaben);
....
end loop;
end Auftraggeber;
task Auftragnehmer is
procedure Auftrag (ein: in e-typ; aus: out a-typ) is
--Auftrag bearbeiten
end Auftrag;
end Auftragnehmer;
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
109
EchtzeitsystemeAsynchrone Kommunikation
• Kommunikationspartner sind nicht gleichzeitig an der Kommunikation beteiligt.
• Botschaften werden gepuffert (Speicher!!!?)
• blockiert, wenn Puffer voll
• Alter der Informationen
send
receive
P1 P2
puffern
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
110
EchtzeitsystemeSynchronisations-Mechanismen
AKTIVES WARTEN
(busy waiting)
SEMAPHORE
Stellt sicher, daß kein Zugriff
erfolgt, wenn die gemeinsame
Variable in einem Zustand ist der
für einen Zugriff ungeeignet ist
Bedingungssynchronisation(condition synchronisation)
MONITORE
Stellt sicher, daß eine
Anweisungssequenz als un-
teilbare Operation behandelt wird
(kritischer Abschnitt, critical section)
Wechselseitiger Ausschluß(mutual exclusion)
Kommunikation übergemeinsame Variablen/Daten
Sender wird beim Senden
nicht verzögert:
-Puffer für Kanal nötig
-Botschaften z.T. veraltet
asynchron
Sender und Empfänger müssen
zum Informationsaustausch
bereit sein
synchron
Kommunikation durchBotschaften-Austausch
Synchronisationsmechanismen
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
111
EchtzeitsystemeAktives Warten (busy waiting)
• Der Prozess wartet auf das Eintreten einer Bedingung und belegt während dieser Zeit den Prozessor ohne sinnvolle Arbeiten zu tun
loop
exit when Bedingung;
--nix tun
end loop;
Bedingungssynchronisation
Prozess
Oel
Prozess
Temp
ALARMProzess
Anzeige
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
112
EchtzeitsystemeAktives Warten (busy waiting)
Wechselseitiger Ausschluß
Beide Prozesse müssen ihre Zugriffe auf den Speicher synchronisieren
• Synchronisations mittels SchloßvariableDie kritischen Bereiche werden mit einem „Schloß“ versehen, welches von den Prozessen aufgesperrt und verriegelt werden kann.
Tastatur-
prozessVerarbeitungs
prozessPufferspeicher
Produzent Konsument
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
113
EchtzeitsystemeAktives Warten (busy waiting)
Will ein Prozess ein kritisches Gebiet betreten
• Warten bis das zugehörige „Schloß“ offen ist
• Betreten des kritischen Bereichs
• Schloß von innen verschließen (lock)
• ...• Schloß wieder aufschließen (unlock)
S: lockvar;process P is ...
...S.lock--kritischer Bereich
S.unlock...
end process;
• Findet ein Prozess das „Schloß“ verriegelt vor, dann testet er solange bis es frei wird. (aktives Warten)
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
114
EchtzeitsystemeAktives Warten (busy waiting)
Tastatur-
prozess
Verarbeitungs
prozessPufferspeicher
...
loop
exit when Frei;
--nix tun
end loop;
Frei:=false;
...
Pufferzustand
Frei
declare b:boolean...loop
b:=false;exchange (b,Frei);exit when b
end loop;...
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
115
EchtzeitsystemeSemaphore
Eine der grundlegensten Synchronisations-mechanismen ist der SEMAPHORESEMAPHORE (Dijkstra)
• Zählvariablen s
• Warteschlange für Prozesse
• zwei nicht unterbrechbaren Operationen
• P (Passieren, Request, passeeren)
• V (Verlassen, Release, vrijgeven)
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
116
EchtzeitsystemeSemaphore (einwertige)
• s.P:if s>=1 then
der diese P-Operation aufrufende
Prozess setzt seinen Ablauf fort
else
der diese P-Operation aufrufende
Prozess wird blockiert, in den
Wartezustand versetzt und in eine Warteschlange
eingeordnet
end if;
s:=s-1;
• s.V:if s
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
117
EchtzeitsystemeSemaphore
• Ein positiver Zpositiver Zäählwerthlwert gibt hierbei die Anzahl der Tasks an, die in den durch den Semaphore geschützten kritischen Bereich gleichzeitig eintreten dürfen
• Ein negativer Znegativer Zäählwerthlwert gibt diejenige Anzahl der Tasks an, denen der Eintritt bisher verwehrt wurde
Ein Semaphore kann beide Synchronisationsarten
• Bedingungssynchronisation
• Wechselseitiger Ausschluß
realisieren
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
118
EchtzeitsystemeSemaphore
Bedingungssynchronisation
process P2 is
...
s.P; --Ereignis abwarten
...
end P2;
s:Semaphor:=0;
process P1 is
...
s.V; --Ereignis signalisieren
...
end P1;
Wechselseitiger Ausschluß
s:Semaphor:=1;
process P1 is
...
s.P;
...--kritischer Bereich
s.V.
...
end P1;
process P2 is
...
s.P;
...--kritischer Bereich
s.V.
...
end P2;
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
119
EchtzeitsystemeSemaphore
• Semaphore S1 schützt einen Bereich (z.B. eine gemeinsame Datenstruktur)
• Nur eine Task (Initialwert des Semaphores S1=1) darf den Bereich betreten-> wechselseitiger Ausschluß
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
120
EchtzeitsystemeSemaphore
• Durch wechselseitiges Belegen zweier Semaphore wird eine genaue Reihenfolge des Tasksablaufs festgelegt
• Task A kann nur laufen, wenn S1=1 ist
• Task B kann nur laufen, wenn S2=1 ist
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
121
EchtzeitsystemeMonitore
...s.P;
s.V;...
--Zugriffs-funktion f1
Prozess P1
...s.P;
s.V;...
--Zugriffs-funktion f2
Prozess P2
P V
sSemaphor
Gemeinsame Daten
...
...M.f1(...);......
...
Prozess P1
...
...M.f2(...);......
Prozess P2
Zugriffs-funktion
f1
Monitor M
Gemeinsame Daten
Zugriffs-funktion
f2
Pro
zessw
arte
schla
nge
Pro
zessw
arte
schla
nge
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
122
EchtzeitsystemeMonitore
• Die Zugriffsanweisungen auf kritische Bereiche werden aus den Prozessen herausgelöst und als Zugriffsfunktionen in eine Datenabstraktion, dem Monitor verlagert
• Die Prozesse rufen nur noch diese Zugriffsfunktionen auf
• Über Warteschlange FIFO werden die Monitorfunktionen an aufrufende Prozesse verteilt
• Durch das Monitorkonzept wird nur der wechselseitige Ausschlußrealisiert
• Nachbildung der Bedingungssynchronisatíon mittels wechselseitigem Ausschluss
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
123
EchtzeitsystemeVerklemmungen
• Bei der Synchronisation von Tasks kann es zu Verklemmungen kommen, d.h. Fortführung einer oder mehrerer Tasks wird auf Dauer blockiert
• Beispiel: Verklemmung an einer Kreuzung mit rechts vor links undvier Fahrzeugen
• Bei Verklemmungenkann man zweiTypen unterscheiden
•• DeadlocksDeadlocks
•• LivelocksLivelocks
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
124
EchtzeitsystemeDeadlocks
• Mehrere Tasks warten auf die Freigabe von Betriebsmitteln, die sie sich gegenseitig blockieren-> Stillstand der Tasks, da auf Ereignisse gewartet wird, die nicht mehr eintreten können
• Laufen beide Tasks gleichzeitiglos, so belegen sie kreuz-weise die vom anderenbenötigten Betriebs-mittel-> Stillstand
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
125
EchtzeitsystemeDeadlocks
• Die Freiheit von Deadlocks ist eine wichtige Synchronisationseigenschaft
• Sie muss durch vorab durchgeführte Abhängigkeitsanalysen gewährleistet werden
• Wesentliches Entwurfskriterium!
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
126
EchtzeitsystemeLivelocks
• Durch Konspiration anderer Tasks wird eine Task ständig an der Ausführung gehindert
• Beispiel: Durch Aktivitäten hochpriorer Tasks erhält eine niederpriore Task nie den Prozessor zugeteilt -> Verhungern
• Prioritäten-Inversion (priority inversion):Eine niederpriore Task belegt ein Betriebsmittel, welches eine Task hoher Priorität benötigt⇒eine hochpriore Task wird von einer niederprioren Task blockiert
⇒ im schlimmsten Fall: Livelock für die hochpriore Tasks, wenn die niederpriore Task aufgrund ihrer niedrigen Priorität keine Rechenzeit erhält-> Pathfinder- Marsfahrzeug Sojouner
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
127
EchtzeitsystemeLivelocks
• Abhilfe: Prioritäten-Vererbung (priority inheritance, priority-ceiling-protocol):Für die Dauer der Blockierung erhält die niederpriore Task die Priorität der blockierten hochprioren Task
Starvationof Task
C because of Task Bprio
B
C
A S S
tt0 t1 t2t3
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
128
EchtzeitsystemeBasic Inheritance Protocol (BIP)
• Diejenige Task TH mit höchster Priorität ist am Zug
• Bei Betreten des kritischen Bereichs wird eine Semaphore S gesetzt
• Bei Verlassen des Bereichs wird sie wieder zurück gesetzt
• Wenn Semaphore bereits von Task TN mit niedriger Prio gesperrt� TH vererbt Prio für die Dauer von (S==true) an TN
• Nach verlassen von S wird die Prio von TN wiederhergestellt und THgeweckt.
• Bei einer Verschachtelung kritischer Bereiche besteht die Gefahr von Deadlocks
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
129
EchtzeitsystemeSemaphores versus priority ceiling protocol
No Delay of Task C because of
Task Bprio
B
C (A‘)
A
t
SS
t0 t1 t2
Delay of Task C
because of Task B
(priority
inversion)
prio
B
C
A S S S
S
tt0 t1 t2t3 t0 : Task A accesses resource
t1 : Activation of Task C
t2 : Activation of Task B
t3 : Task C tries to access resource
Semaphores
Priority ceiling
protocol
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
130
EchtzeitsystemeRendezvous
• Leichte Abwandlung des RPC Konzepts
• Bidirektionale Kommunikation
• Der Prozess, der ferne Prozeduren zum Aufruf anbietet, kann selbst bestimmen welche Prozedur er ausführen möchte.
• Wenn beide Prozesse bereit zu einem Rendezvous sind, dann treffen sie sich zur Ausführung einer Prozedur.
• Rendezvous ist üblicherweise ein synchroner Kommunikationsvorgang.
• Blockierung des Aufrufers, solange ferne Prozedur noch nicht bereit.
• Blockierung des Empfängers des Aufrufs, wenn er eine Prozedur anbietet, aber keiner das Angebot wahrnimmt.
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
131
EchtzeitsystemeRendezvous
• Rendezvouskommunikation
• Beantragen des Rendezvous requestrequest
• Anbieten des R. offeroffer
• Annehmen des R. acceptaccept
• Ausführen des R. executionexecution
• Zu jedem Rendezvous gehört eine Warteschlange an Prozessen, die dieses Rendezvous beantragt haben.
• Mit einer accept Anweisung wird der erste Prozess aus der Warteschlange als Kommunikationspartner ausgewählt.
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
132
EchtzeitsystemeRendezvous
Realisierung in ADA
• Zu jedem Prozess können Prozeduren - in ADA Eingänge (entries) genannt - angegeben werden, die anderen Prozessen als R. angeboten werden.
tasktask Auftragnehmer isis
entryentry Auftrag (ein: inin e-typ; aus: outout a-typ);
- Anbieten eines Rendezvous
endend;
....
Auftragnehmer.Auftrag(eingaben, ausgaben); --Entry Aufruf
....
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
133
EchtzeitsystemeRendezvous
......
tasktask Auftragnehmer isis
entryentry Auftrag (ein: inin e_typ; aus: outout a_typ);
- Anbieten eines Rendezvous
end end Auftragnehmer;
tasktask bodybody Auftragnehmer isis
beginbegin
looploop
accept Auftrag (ein: in e_typ; aus: outout a_typ) do
put_line („Auftrag bearbeiten“);
aus := ein +100;
endend Auftrag;
end end looploop;
endend Auftragnehmer;
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
134
EchtzeitsystemeRendezvous
tasktask Auftraggeber;
tasktask bodybody Auftraggeber is
eingaben: e_typ;
ausgaben: a_typ;
beginbegin
looploop
put_lineput_line(„Eingabe: „); getget(eingaben); new_linenew_line;
Auftragnehmer.Auftrag(eingaben, ausgaben); --Entry Aufruf
putput („Ausgabe: „); putput(ausgaben); new_linenew_line;
exitexit whenwhen eingaben < 0;
end end looploop;
endend Auftraggeber;
....
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
135
EchtzeitsystemeRendezvous
• Selektives Ausführen eines Rendezvous
•• selectselect-Anweisung:
withwith ada_ioada_io; ; useuse ada_ioada_io; ;
procedureprocedure Motorueberwachung isis
Max_Druck: constantconstant float float := 4.0;;
Max_Tmp: constantconstant float float := 100.0;;
tasktask Alarm_Anzeigen isis
entryentry Oeldruck_zu_hoch;
entryentry Tmp_zu_hoch;
end end Alarm_Anzeigen;
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
136
EchtzeitsystemeRendezvous
tasktask bodybody Alarm_Anzeigen isis
beginbegin
looploop
selectselect ---------------------------------
acceptaccept Oeldruck_zu_hoch dodo
put_lineput_line („Oeldruck zu hoch“);
endend Oeldruck_zu_hoch;
oror ----------------------------------
acceptaccept Tmp_zu_hoch dodo
put_lineput_line („Temperatur zu hoch“);
endend Tmp_zu_hoch;
end end selectselect; --------------------------
end end looploop;
endend Alarm_Anzeigen;
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
137
EchtzeitsystemeRendezvous
tasktask Oel_Ueberwachung;------------------------------------------------------
tasktask bodybody Oel_Ueberwachung isis
Druck: float;
beginbegin
looploop put_lineput_line(„Druck:“);getget(Druck);
exitexit whenwhen Druck < 0.0;
ifif Druck > Max_Druck then
Alarm_Anzeigen.Oeldruck_zu_hoch; --Entry Aufruf
end end ifif;
end end looploop;
end end Oel_Ueberwachung;
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
138
EchtzeitsystemeRendezvous
tasktask Tmp_Ueberwachung;------------------------------------------------------
tasktask bodybody Tmp_Ueberwachung isis
Tmp: floatfloat;
beginbegin
looploop put_lineput_line(„Temperatur:“);getget(Tmp);
exitexit whenwhen Tmp < 0.0;
ifif Tmp > Max_Tmp thenthen
Alarm_Anzeigen.Tmp_zu_hoch; --Entry Aufruf
end end ifif;
end end looploop;
endend Tmp_Ueberwachung;
beginbegin --Hauptprogramm
put_lineput_line(„Motorueberwachung durch Rendezvous“);
endend Motorueberwachung;
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
139
EchtzeitsystemeRendezvous
• Die selectselect-Anweisung akzeptiert entweder den Aufruf des Eingangs Oeldruck_zu_hoch oder den Aufruf des Eingangs Tmp_zu-hoch.
• Steht der Prozess am Anfang der selectselect-Anweisung, können drei Fälle eintreten
1)Keiner der beiden Eingänge wurde aufgerufen. Der Prozess Alarm_Anzeige wartet an der selectselect-Anweisung, bis ein Rendezvous beantragt wird.
2)Es liegt ein Antrag für genau einen Eingang vor. Dann findet ein Rendezvous statt, indem die zugehörige acceptaccept-Anweisung ausgeführt wird.
3) Für beide Eingänge liegen Anträge vor. Dann wird nach dem Zufall eine der beiden Anträge angenommen und ausgeführt.
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
140
EchtzeitsystemeRendezvous
• Bedingtes Ausführen eines Rendezvous (guarded selectselect)
....
selectselect ---------------------------------
whenwhen Bedingung => => --Wächter
acceptaccept Oeldruck_zu_hoch dodo
put_lineput_line („Oeldruck zu hoch“);
endend Oeldruck_zu_hoch;
oror ----------------------------------
acceptaccept Tmp_zu_hoch dodo
put_lineput_line („Temperatur zu hoch“);
endend Tmp_zu_hoch;
end end selectselect; --------------------------
....
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
141
EchtzeitsystemeKonjunktion mit Semaphoren
• Zwei Tasks (A,B) greifen auf zwei Betriebsmittel zu (X,Y)A: Task;
…
request X;
…
request Y;
…
release Y;
release X;
…
end;
• Deadlock möglich
B: Task;…request Y;…request X;…release X;release Y;…end;
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
142
EchtzeitsystemeKonjunktion mit Semaphoren
• Feste Reihenfolge im Aufruf der Betriebsmittel(Gerichtete Betriebsmittel)
A: Task;
…
request X;
…
request Y;
…
release Y;
release X;
…
end;
• Kein Deadlock möglich
B: Task;…request X;request Y;……release X;release Y;…end;
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
143
EchtzeitsystemeKonjunktion mit Semaphoren
• Hierarchische Ordnung der Betriebsmittel
• Einführung einer übergeordneten Semaphore (XY)
A: Task…request XY;request X;…request Y;…release Y;release X;release XY;…end;
• Wenn eine Task beide Ressourcen benötigt, wird zunächst Semaphore XY reserviert.
• Wird nur eine Ressource benötigt, genügt es weiterhin, nur die dazugehörige Semaphore zu reservieren.
• Kein Deadlock möglich
B: Task;…request XY;request Y;…request X;…release X;release Y;release XY;…end;
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
144
EchtzeitsystemeBedingungssynchronisation mit Semaphoren
• Anfordern eines Betriebsmittels aus mehreren (1 aus n)
A: Task;…request P1;…MerkerP1 := true;release FERTIG;…end;
• Über MerkerP1 und MerkerP2 wird signalisiert, welche Task die Semaphore FERTIG freigegeben hat.
C: Task;…request FERTIG;if MerkerP1 then begin
…MerkerP1 := false;release P1;…
end;
B: Task;…request P2;…MerkerP2 := true;release FERTIG;…end;
else begin…MerkerP2 := false;release P2;…
end;end;
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
145
EchtzeitsystemeVerteilte Systeme
J. Schäuffele, T. Zurawka: Automotive Software Engineering, Vieweg, 2003
• Autonom arbeitende Einzelsysteme -> Vernetzung
• Bsp: ASR-Steuergerät ist mit ABS und Motorsteuerung verknüpft
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
146
EchtzeitsystemeVerteilte Systeme
J. Schäuffele, T. Zurawka: Automotive Software Engineering, Vieweg, 2003
• Echt parallele Tasks
• Örtlich verteilte Ausführung
• Tasks interagieren mittels eines Kommunikationsnetzwerk
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
147
EchtzeitsystemeVerteilte Systeme
• Vorteile vernetzter Systeme gegenüber Zentralen Systemen
• Systeme arbeiten an ihrem Bestimmungsort
• Geringer Verkabelungsaufwand
• Erweiterbarkeit / Skalierbarkeit
• Wiederverwertbarkeit von Einzelsystemen
• Baukastenstrategie
• Übergeordnete Funktionalität (Bsp. Adaptive Cruise Control)
• Ausfalltolerante Systemauslegung
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
148
EchtzeitsystemeVerteilte Systeme
• Logische und technische Systemarchitektur
J. Schäuffele, T. Zurawka: Automotive Software Engineering, Vieweg, 2003
• Logische Struktur lässt sich nicht auf technische Struktur direkt abbilden
• Logische Kommunikationbeziehungen ≠ technische Kommunikationsverbindungen
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
149
EchtzeitsystemeVerteilte Systeme
Network of ECU’s
Bus
ECU 1 ECU 2
ECU 3Sensor 1
Actuator 1
f: Function
m: Module
m6
Network of Functions
m1 m3
m2
m7
m4
m5
f1
f2 f3
m6
Logical vs. Technical architecture
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
150
EchtzeitsystemeVerteilte Systeme
• Gemeinsames Kommunikationsmedium (Bus)
• Konflikte müssen vermieden werden
• Zu jedem Zeitpunkt darf nur ein Netzknoten senden
• Strategien zur Zuteilung des Buszugriffs
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
151
EchtzeitsystemeVerteilte Systeme
• Logische Kommunikationsbeziehungen
• Client-Server-Modell
J. Schäuffele, T. Zurawka: Automotive Software Engineering, Vieweg, 2003
• Producer-Consumer-Model
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
152
EchtzeitsystemeVerteilte Systeme
• Technische Netzwerktopologie
J. Schäuffele, T. Zurawka: Automotive Software Engineering, Vieweg, 2003
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
153
EchtzeitsystemeVerteilte Systeme
• Sterntopologie
• Zentraler Netzknoten
• n-1 Schnittstellen bei n Netzknoten
• Ausfall des Zentralen Netzknoten => Ausfall des Gesamtsystems
• Ringtopologie
• Netzwerke großer räumlicher Ausbreitung
• Regeneration und Weiterleitung von Botschaften
• Ausfall eines Netzknoten kann zu Ausfall des Gesamtsystems führen
• Linientopologie
• Passive Ankopplung alle Knoten an gemeinsames Medium
• Ausfall eines Netzknoten hat keinen Einfluss auf andere Knoten
• Beliebige logische Kommunikationsbeziehungen
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
154
EchtzeitsystemeVerteilte Systeme
• Festlegung von Nachrichten
• Nachrichtenrahmen
• Nutzdaten und Signale
J. Schäuffele, T. Zurawka: Automotive Software Engineering, Vieweg, 2003
• Teilnehmer- oder Nachrichtenadressierung
• Nachrichten-ID
• Empfänger-ID
• Leere Nachrichten zur Synchronisation
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
155
EchtzeitsystemeVerteilte Systeme
• Kommunikationsmatrix
J. Schäuffele, T. Zurawka: Automotive Software Engineering, Vieweg, 2003
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
156
EchtzeitsystemeVerteilte Systeme
• Kommunikation nach OSEK-COM
• Unqueued Messages
• SendMessage(); -> Überschreibend
• ReceiveMessage(); -> Nicht löschend
• Queued Messages
• SendMessage(); -> FIFO-Prinzip, nicht überschreibend
• ReceiveMessage(); -> älteste Message wird löschend gelesen
• Event Messages
• Ereignisse dürfen nicht verloren gehen (Bsp. Inkrementalgeber)
• State Messages
• Der jeweils aktuellste Wert – die letzte Message ist relevant (Bsp.
Temperaturerfassung)
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
157
EchtzeitsystemeVerteilte Systeme
• Netzwerkmanagement nach OSEK-NM
• Teilnehmerüberwachung
• Betriebsmodi-Umschaltung (Bsp. Sleep-Mode)
• Fehlerüberwachung
• Token-Übergabe (logischer Ring)
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
158
EchtzeitsystemeVerteilte Systeme
• Strategien zur Buszuteilung
J. Schäuffele, T. Zurawka: Automotive Software Engineering, Vieweg, 2003
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
159
EchtzeitsystemeVerteilte Systeme
• Master-Slave-Architektur
• Einfach zu realisieren
• Zentraler Realisierung
• Gesteuerte Strategie
• Multi-Master-Architektur
• Komplexer zu realisieren
• Ausschalten/Ausfallen eines Netzknotens beeinflusst nicht das Gesamtsystem
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
160
EchtzeitsystemeVerteilte Systeme
• Ungesteuerte Strategie
• Carrier-Sense-Multiple-Access (CSMA)
• Mehrere Sender greifen auf den Bus zu, sobald dieser frei ist
• Nicht kollisionsfrei
• Kollisionen von Messages treten auf, aber werden erkannt
• Kollisionsfrei mit Vermeidungsstrategien
• z.B. Arbitrierungsphase vor Versenden der Nutzdaten
• z.B. zeitgesteuert
• z.B. durch Weitergabe eines Tokens
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
161
EchtzeitsystemeVerteilte Systeme
• Ereignis- und zeitgesteuerte Strategien
• Latenzzeit in ereignisgesteuerten Netzwerken können nur für höchstpriore Nachrichten angegeben werden.
• Daher auch Vorhersagbarkeit des Zeitverhaltens für eine Task auf einem Netzknoten eingeschränkt
• Vollständig zeitgesteuerte System im Zeitverhalten vorhersagbar
• Prozessorübergreifende zeitgesteuerte Multi-Master-System müssen die lokalen Systemzeiten synchronisieren. (OSEK-Time)
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
162
EchtzeitsystemeSpeicherverwaltung
Aufgabe der Speicherverwaltung:
• Verwaltung der Speicherhierarchie
• Cache - Arbeitsspeicher - Peripheriespeicher
• Zuteilung von Speicher an Tasks
• Koordinierung des Zugriffs auf gemeinsame Speicherbereiche
• Abgrenzung der Speicherbereiche einzelner Tasks gegeneinanderDie Speicherverwaltung teilt verfügbaren Speicher mittels einer Speicherabbildungsfunktion zu:
M: logische Adresse -> physikalische Adresse
• logische Adresse: Speicheradresse innerhalb einer Task
• physikalische Adresse: Adresse des Arbeitsspeichers
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
163
EchtzeitsystemeSpeicherverwaltung
Diese mathematische Form der Speicherzuteilung ist eng mit betriebssystemspezifischen und prozessorspezifischen Punkten verknüpft:
• Statische oder dynamische Speicherzuteilung
• Verdrängende oder nicht verdrängende Speicherzuteilung
• Reelle oder virtuelle Adressierung
• Lineare oder streuende Adressbildung
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
164
EchtzeitsystemeSpeicherverwaltung
• Statische Speicherzuteilung: Die Zuteilung von Speicher an eine Task erfolgt, bevor die Task in den Zustand bereit versetzt wird
• Dynamische Speicherzuteilung: Die Zuteilung von Speicher an eine Task erfolgt zur Laufzeit
• Verdrängende Speicherzuteilung: Zugeteilter Speicher darf einer Task zur Laufzeit wieder entzogen werden, der Speicherinhalt wird in den Peripheriespeicher ausgelagert
• Nichtverdrängende Speicherzuteilung: Zugeteilter Speicher darf einer Task zur Laufzeit nicht wieder entzogen werden
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
165
EchtzeitsystemeSpeicherverwaltung
• Reelle Adressierung: ein kleiner logischer Adressraum wird auf einen größeren physikalischen Adressraum abgebildet => der gesamte logische Adressraum einer Task kann auf den physikalischvorhandenen Speicher abgebildet werden
• Virtuelle Adressierung: ein größerer logischer Adressraum wird auf einen kleineren physikalischen Adressraum abgebildet => es müssen Verdrängungen stattfinden
• Lineare Adressbildung: Die Speicherabbildungsfunktion bildet einen Block sequentieller Speicheradressen geschlossen wieder ineinen solchen Block ab
• Streuende Adressbildung: Die Speicherabbildungsfunktion kann einen Block sequentieller Speicheradressen in eine beliebige Reihenfolge überführen
8/5/2008
Manabendra Narayan Gupta, Dirk Böndel - ETAS GmbH
166
EchtzeitsystemeSpeicherverwaltung
Verfahren für lineare Adressbildung
• Bei linearer Adressbildung wird der Speicher in Segmente unterteilt
• Einfachster Fall:statische
top related