echtzeitdv 2006 1 - dhbw stuttgartrie/rzs/vorlesung/echtzeitdv... · 2013. 12. 2. ·...

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

[email protected]

Dirk Böndel

[email protected]

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


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


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


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


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


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


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


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


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


11

EchtzeitsystemeEntwicklung in der Automobilelektronik

8/5/2008


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


13


• 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


14


Eingangsdaten AusgangsdatenFester Algorithmus

Rege

lung

Rechnersystem

Maus ScannerTastatur

t

Umwelt

8/5/2008


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


16


• Synchronisation

• externe Zeitquelle

Referenzuhr

• sehr hohe und hochkonstante Microtick-Rate(z.B.Atomuhr 9 192 631 770 Hz (108 ps))

8/5/2008


17


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


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


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


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


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


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


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


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


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


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


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


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


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


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


31

EchtzeitsystemeVerfahren zur Echtzeit-Programmierung

Zwei grundlegende Verfahren

• synchrone Programmierung(TT - zeitgesteuerte Systeme)

• asynchrone Programmierung(ereignisgesteuert)

�� Zeitscheibenprogrammierung

8/5/2008


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


33


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


34


Teilprogramm Bezeichner

(Name)

Abtastzeit

(Zykluszeit)

Temperatur-Regelung für

die Regelstrecke



die Regelstrecke



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


35


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


36


Zeitlicher Ablauf

8/5/2008


37


• 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


38


• 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


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


40


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


41


Regelstrecke 1


Regelstrecke 2


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


42


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


43


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


44


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


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


8/5/2008


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


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


48


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


49


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


50


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


51


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


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


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


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


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


56


• 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


57


Klassifizierung von Scheduling-Verfahren

8/5/2008


58


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


59


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


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


61

EchtzeitsystemeCooperative and preemptive multitasking

cooperative

preemptive

8/5/2008


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


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


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


65


• 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


66


• ... 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


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


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


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


70

Metriken zur Beurteilung des Scheduling

• Durchschnittl. Anwortzeit:

• Gesamtausführungszeit:

• Maximale Verspätung:

• Anzahl verspäteter Tasks:

mit

8/5/2008


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


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


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


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


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


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


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


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


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


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


81


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


82


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


83


• 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


84


• 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


85


• 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


86


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


87

SojournerWas passierte …

• Rover landet Juli 1997 auf der Marsoberfläche

• Zunächst erfolgreicher Missionsverlauf• Nach einigen Tagen:

• Systemresets

• Datenverlust

8/5/2008


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


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


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


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


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


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


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


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


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


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


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


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


100


•• 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


101


•• 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


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


103

Virtuelle Gleichzeitgkeit

aus P.Feisthammel: Verteilte Systeme, 2001

8/5/2008


104

Virtuelle Gleichzeitigkeit

8/5/2008


105

Virtuelle Gleichzeitigkeit

8/5/2008


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


107


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


108


• 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


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


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


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


112


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


113


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


114


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


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


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


117


• 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


118


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


119


• 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


120


• 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


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


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


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


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


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


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


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


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


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


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


131


• 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


132


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


133


......

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


134


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


135


• 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


136


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


137


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


138


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


139


• 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


140


• 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


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


142


• 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


143


• 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


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


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


146



• Echt parallele Tasks

• Örtlich verteilte Ausführung

• Tasks interagieren mittels eines Kommunikationsnetzwerk

8/5/2008


147


• 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


148


• Logische und technische Systemarchitektur


• Logische Struktur lässt sich nicht auf technische Struktur direkt abbilden

• Logische Kommunikationbeziehungen ≠ technische Kommunikationsverbindungen

8/5/2008


149


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


150


• Gemeinsames Kommunikationsmedium (Bus)

• Konflikte müssen vermieden werden

• Zu jedem Zeitpunkt darf nur ein Netzknoten senden

• Strategien zur Zuteilung des Buszugriffs

8/5/2008


151


• Logische Kommunikationsbeziehungen

• Client-Server-Modell


• Producer-Consumer-Model

8/5/2008


152


• Technische Netzwerktopologie


8/5/2008


153


• 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


154


• Festlegung von Nachrichten

• Nachrichtenrahmen

• Nutzdaten und Signale


• Teilnehmer- oder Nachrichtenadressierung

• Nachrichten-ID

• Empfänger-ID

• Leere Nachrichten zur Synchronisation

8/5/2008


155


• Kommunikationsmatrix


8/5/2008


156


• 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


157


• Netzwerkmanagement nach OSEK-NM

• Teilnehmerüberwachung

• Betriebsmodi-Umschaltung (Bsp. Sleep-Mode)

• Fehlerüberwachung

• Token-Übergabe (logischer Ring)

8/5/2008


158


• Strategien zur Buszuteilung


8/5/2008


159


• 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


160


• 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


161


• 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


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


163


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


164


• 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


165


• 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


166


Verfahren für lineare Adressbildung

• Bei linearer Adressbildung wird der Speicher in Segmente unterteilt

• Einfachster Fall:statische

echtzeitdv 2006 1 - dhbw stuttgartrie/rzs/vorlesung/echtzeitdv... · 2013. 12. 2. ·...

Documents