Echtzeitsysteme: Grundlagen der Planung

eXamen.press

eXamen.press ist eine Reihe, die Theorie und Praxis aus allen Bereichen der Informatik für die Hochschulausbildung vermittelt.

Dieter Zöbel

Echtzeitsysteme Grundlagen der Planung

123

Prof. Dr. Dieter Zöbel Universität Koblenz-Landau Universitätsstraße 1 56070 Koblenz [email protected]

ISBN 978-3-540-76395-6

e-ISBN 978-3-540-76396-3

DOI 10.1007/978-3-540-76396-3 ISSN 1614-5216 Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. © 2008 Springer-Verlag Berlin Heidelberg Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Einbandgestaltung: KünkelLopka Werbeagentur, Heidelberg Gedruckt auf säurefreiem Papier 987654321 springer.com

F¨ ur meine Familie Silvia Volker, Verena, Teresa Edmund, Liesel, Ewald, Agnes

Vorwort Die Zeit, die ist ein sonderbar’ Ding. Wenn man so hinlebt, ist sie rein gar nichts. Aber dann auf einmal, da sp¨ urt man nichts als sie. Hugo von Hofmannsthal Echtzeitsysteme sind dadurch gekennzeichnet, dass rechtzeitig in technische Anwendungen steuernd, regelnd oder u ¨berwachend eingegriffen wird. W¨ ahrend fr¨ uher eher großtechnische Anwendungen aus der Produktions- und Energietechnik im Blickfeld lagen, sind es heute mittlere, kleine und kleinste Anwendungssysteme. Besonders Anwendungen aus dem Bereich der Fahrzeugtechnik, der Flugtechnik und der Kommunikation stellen eine maßgebliche Triebfeder bei der Weiterentwicklung von Methoden und Techniken im Fachgebiet Echtzeitsysteme dar. Es gibt immer mehr Lebensbereiche, die von Echtzeitanwendungen ber¨ uhrt werden. Oft erf¨ ullen solche Anwendungen versteckt und unauff¨allig ihre Aufgaben. Der Benutzer nimmt sie nicht oder nur u urfnissen ¨ber eine den Bed¨ angepasste Benutzerschnittstelle wahr. Zu diesen Anwendungen z¨ahlen beispielsweise Fahrassistenzsysteme, wie das Antiblockiersystem, das die Sicherheit eines Fahrzeugs erh¨ oht, ohne dass es unmittelbar wahrgenommen wird. Gerade das Antiblockiersystem gilt als Musterbeispiel einer Echtzeitanwendung. An ihm wird deutlich, dass es nicht ausreicht, wenn sich dieses System funktional korrekt verh¨ alt. Vielmehr ist es zur Erreichung einer optimalen Bremswirkung unabdingbar, so unmittelbar wie m¨oglich die aktuelle Bewegung der R¨ ader zu messen, um daraufhin den Bewegungszustand des Fahrzeugs einzusch¨ atzen und die Bremszylinder zu den richtigen Zeitpunkten anzusteuern. Echtzeitsysteme sind rechnergesteuert. Ihr Verhalten wird durch die parallele Ausf¨ uhrung rechentechnischer Prozesse bestimmt. Die Disziplin der Echtzeitplanung, auch Real-Time Scheduling genannt, befasst sich damit, wie garantiert werden kann, dass Prozesse rechtzeitig in technische Anwendungen eingreifen. Aufbauend auf einschl¨ agigen Prozessmodellen verf¨ ugt das Fachgebiet Echtzeitsysteme u ¨ber eine Vielzahl von Verfahren der Echtzeitplanung. Die wichtigsten unter diesen Verfahren werden vorgestellt und ihre Bedeutung f¨ ur die Entwicklung von Echtzeitsystemen er¨ ortert. Dieses Buch will somit nicht in die volle Breite des Themengebietes Echtzeitsysteme einf¨ uhren. Statt dessen wird versucht, eine Br¨ ucke von den Grundlagen der Planung zur Anwendung der Planungsverfahren bei der Entwicklung von Echtzeitsystemen zu schlagen. Zu diesem Zweck f¨ uhrt Kapitel 1 in die Merkmale, Strukturen und Anwendungsvielfalt von Echtzeitsystemen

VIII

Vorwort

ein. Danach wird in Kapitel 2 auf diejenigen technischen und methodischen Grundlagen eingegangen, die f¨ ur die Planung bei Echtzeitsystemen entscheidend sind. Erst im Anschluss daran werden in Kapitel 3 die Planungsverfahren vorgestellt, die im Kern des Fachgebietes angsiedelt sind und allen, die sich mit Echtzeitsystemen befassen, gel¨ aufig sein sollten. Es folgt das Kapitel 4, das fortgeschrittene Planungsverfahren pr¨asentiert, wie sie in spezifischen Anwendungskontexten anfallen. Aufbau und Inhalte des Buches wurden im Rahmen meiner Lehrt¨atigkeit im Fach Informatik konzipiert und umgesetzt. Es erhebt den Anspruch, weitgehend selbsterkl¨ arend zu sein. Dies bedeutet, dass die Inhalte im Rahmen eines einschl¨ agigen Studiums ohne Zuhilfenahme weiterer Literatur verstanden werden k¨ onnen. Gleichzeitig richtet es sich an fachlich interessierte Leser außerhalb des Studiums. Ihnen soll das Buch die M¨oglichkeit geben, sich intensiv mit der Disziplin der Echtzeitplanung auseinanderzusetzen, deren Ziele im Kontext des Fachgebietes zu erfassen, die Planungsverfahren zu verstehen, sie auch nachzuvollziehen und eigenst¨ andig anwenden zu k¨onnen. Das Buch hat ein einheitliches Gliederungsschema bestehend aus Kapiteln, Abschnitten und Unterabschnitten. In einem kurzen Vorspann wird zun¨achst skizziert, was von jedem Kapitel und jedem Abschnitt zu erwarten ist. Die Abschnitte sind jeweils in Unterabschnitte gegliedert, die die eigentlichen Inhalte des Buches bilden. Zu Beginn jedes Unterabschnittes wird seine Bedeutung und Stellung im Kontext des Fachgebietes herausgearbeitet. Formale Notationen und Definitionen bilden die Grundlage f¨ ur eine mathematisch fundierte Modellbildung. S¨ atze und Beweise dienen dazu, wichtige Aussagen zu gewinnen, die von den Planungsverfahren ausgenutzt werden. Beispiele f¨ ordern die Nachvollziehbarkeit der Verfahren in konkreten Anwendungsszenarien. Aufgaben mit L¨ osungen dienen dazu, zun¨achst den eigenst¨andigen Umgang mit Verfahren zu u ¨ben, um dann die Korrektheit der Ergebnisse zu u ufen. ¨berpr¨ R¨ uckblickend gilt mein Dank allen, die durch das Erfassen von Teilen des Manuskriptes, durch die Erstellung von Zeichnungen und das Korrekturlesen an der Entstehung des Buches beteiligt waren. Namentlich sind in diesem Zusammenhang Frau Sabine H¨ ulstrunk, Frau Katharina Hupf, Herr Dimitri Papoutsis, Herr Daniel Sch¨ uller, Herr Ralf T¨oppner, Herr Christian Weyand und Herr Volker Z¨ obel zu nennen. Des Weiteren danke ich meiner Familie f¨ ur das Verst¨ andnis, mich mit soviel Zeitaufwand f¨ ur das Gelingen dieses Buches einsetzen zu k¨ onnen. Universit¨ at Koblenz-Landau, November 2007

Prof. Dr. Dieter Z¨ obel

Inhaltsverzeichnis 1 1.1 1.1.1 1.1.2 1.2 1.2.1 1.2.2 1.2.3 1.3 1.3.1 1.3.2 1.4 1.4.1 1.4.2 1.4.3 1.4.4 1.5 1.5.1 1.5.2 1.5.3 1.5.4 1.6

Einf¨ uhrung Merkmale von Echtzeitsystemen .............................. Harte und weiche Echtzeit ..................................... Determiniertheit und Vorhersagbarkeit ...................... Grundmodell eines Echtzeitsystems .......................... Paradigmatische Beispiele ...................................... Aktionen und Akteure .......................................... Eingebettete Systeme ........................................... Prozesse ........................................................... Datenflussdiagramme ........................................... Regelungstechnik ................................................ Echt und Zeit..................................................... Schnelligkeit und Rechtzeitigkeit.............................. Zeit auf dem Rechensystem.................................... Diskretisierung und Drift ....................................... Echtzeit ............................................................ Echtzeitsysteme in der Praxis ................................. Anwendungen f¨ ur die Lehre .................................... Großtechnische Anwendungen ................................. Automotive Anwendungen ..................................... Multimedia und Telematik ..................................... Konventionen und Notationen.................................

2 2.1 2.1.1 2.1.2 2.1.3 2.1.4 2.1.5 2.1.6 2.2 2.2.1 2.2.2 2.2.3 2.2.4 2.2.5 2.3 2.3.1 2.3.2

Methodische und technische Grundlagen ¨ Uberblick u ¨ber die Echtzeitplanung .......................... 43 Prozessmodelle ................................................... 43 Prozessparameter ................................................ 46 Periodische Prozesse ............................................ 48 Der Plan ........................................................... 50 Verfahren der Echtzeitplanung ................................ 51 Kategorisierung der Verfahren zur Echtzeitplanung ....... 54 Zeiten und Uhren ................................................ 60 Betrachtungen zur Zeit ......................................... 60 Die physikalische Zeit ........................................... 61 Die Erfassung der Zeit .......................................... 68 Uhrzeit und Weckzeit ........................................... 76 Kalk¨ ule der Zeit .................................................. 85 Bestimmung der Prozessparameter ........................... 93 Absch¨atzung der Ausf¨ uhrungszeit ............................ 93 Ableitung von Zeitbedingungen ............................... 104

3 4 5 7 7 9 11 14 14 16 18 19 21 24 26 28 28 29 33 35 39

X

Inhaltsverzeichnis

2.4 2.4.1 2.4.2 2.4.3 2.4.4 2.4.5 2.5 2.5.1 2.5.2 2.5.3 2.5.4

Parallelit¨at und Synchronisierung ............................. Parallele Programme und Konsistenz der Daten ........... Elementare Synchronisierungsoperationen .................. H¨ ohere Synchronisierungsoperationen ....................... Parallelit¨at bei Mehrprozessorsystemen ...................... Migration von Prozessen bei Mehrprozessorsystemen..... Verteilte Echtzeitsysteme....................................... Anforderungen an verteilte Echtzeitsysteme ................ Aufbauprinzipen von Rechnernetzen ......................... Zugriffsprotokolle ................................................ Modellbildung bei verteilten Echtzeitsystemen .............

3 3.1 3.1.1 3.1.2 3.2 3.2.1 3.2.2 3.2.3 3.2.4

Grundlegende Planungsverfahren Planen durch Suchen............................................ Planen mittels Tiefensuche .................................... Aufwand des Planens durch Suchen.......................... Planen bei dynamischen Priorit¨aten .......................... Planen nach Fristen ............................................. Planen nach Fristen f¨ ur nicht unterbrechbare Prozesse... Planen nach Fristen f¨ ur unterbrechbare Prozesse.......... Planen nach Fristen f¨ ur periodische unterbrechbare Prozesse ................................................................ Planen nach Spielr¨aumen f¨ ur nicht unterbrechbare Prozesse ................................................................ Planen nach Spielr¨aumen f¨ ur unterbrechbare Prozesse ... Planen bei statischen Priorit¨aten ............................. Planen nach festen Priorit¨aten ................................ Planen nach monotonen Raten................................ Hyperbolische Schranke beim Planen nach monotonen Raten............................................................... Bedarf an Ausf¨ uhrungszeit ..................................... Planen nach monotonen Fristen .............................. Zyklische Planungsverfahren ................................... Struktur der Prozessausf¨ uhrung............................... Freiheitsgrade beim zyklischen Planungsverfahren ........ Bewertung des Ansatzes ........................................ Vergleich der Planungsverfahren .............................. Auslastung ........................................................ Implementierung ................................................. Unterbrechungsbehandlung .................................... Fristverletzung....................................................

3.2.5 3.2.6 3.3 3.3.1 3.3.2 3.3.3 3.3.4 3.3.5 3.4 3.4.1 3.4.2 3.4.3 3.5 3.5.1 3.5.2 3.5.3 3.5.4

117 117 120 124 127 130 133 133 136 140 151

157 157 161 164 164 164 166 168 172 175 178 178 180 187 192 195 200 200 202 204 206 206 207 208 210

Inhaltsverzeichnis

XI

4.2.2 4.2.3 4.3 4.3.1 4.3.2 4.3.3 4.3.4

Fortgeschrittene Planungsverfahren Planung synchronisierter Prozesse ............................ Priorit¨atsumkehr ................................................. Priorit¨atsvererbung .............................................. Priorit¨atsobergrenzen ........................................... Planung bei Mehrprozessorsystemen ......................... Planungsverfahren abh¨angig von der Migration der Prozessen .............................................................. Optimalit¨at proportional fairer Planungsverfahren ........ Arbeitsweise proportional fairer Planungsverfahren ....... Planung in verteilten Systemen ............................... Kriterien der Vergleichbarkeit von Zugriffsprotokollen .... Zeitgesteuerte Zugriffsprotokolle .............................. Arbitrierende Zugriffsprotokolle ............................... Markengesteuerte Zugriffsprotokolle .........................

A A.1 A.2 A.3 A.4

L¨ osungen der Aufgaben L¨ osung der Aufgabe aus Kapitel 1 ........................... L¨ osungen der Aufgaben aus Kapitel 2 ....................... L¨ osungen der Aufgaben aus Kapitel 3 ....................... L¨ osungen der Aufgaben aus Kapitel 4 .......................

275 275 281 294

Literaturverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

305

4 4.1 4.1.1 4.1.2 4.1.3 4.2 4.2.1

215 215 219 227 233 233 236 244 250 250 253 254 262

Sachwortverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317

Kapitel 1 Einf¨ uhrung

1

1

1 1.1 1.1.1 1.1.2 1.2 1.2.1 1.2.2 1.2.3 1.3 1.3.1 1.3.2 1.4 1.4.1 1.4.2 1.4.3 1.4.4 1.5 1.5.1 1.5.2 1.5.3 1.5.4 1.6

Einf¨ uhrung Merkmale von Echtzeitsystemen .............................. Harte und weiche Echtzeit ..................................... Determiniertheit und Vorhersagbarkeit ...................... Grundmodell eines Echtzeitsystems .......................... Paradigmatische Beispiele ...................................... Aktionen und Akteure .......................................... Eingebettete Systeme ........................................... Prozesse ........................................................... Datenflussdiagramme ........................................... Regelungstechnik ................................................ Echt und Zeit..................................................... Schnelligkeit und Rechtzeitigkeit.............................. Zeit auf dem Rechensystem.................................... Diskretisierung und Drift ....................................... Echtzeit ............................................................ Echtzeitsysteme in der Praxis ................................. Anwendungen f¨ ur die Lehre .................................... Großtechnische Anwendungen ................................. Automotive Anwendungen ..................................... Multimedia und Telematik ..................................... Konventionen und Notationen.................................

3 4 5 7 7 9 11 14 14 16 18 19 21 24 26 28 28 29 33 35 39

1 Einfu ¨hrung Die nachfolgende Einf¨ uhrung in das Themengebiet Echtzeitsysteme ist vergleichsweise umfangreich. Sie soll sowohl seine Breite verdeutlichen als auch Abgrenzungen gegen andere Themengebiete herausarbeiten. So geht es zun¨ achst um die entscheidenden Begriffe wie Rechtzeitigkeit, Determiniertheit und Vorhersagbarkeit (siehe Abschnitt 1.1), um dann wesentliche Teilsysteme, die ein Echtzeitsystem bilden, zu identifizieren, zu bezeichnen und zu kennzeichnen (siehe Abschnitt 1.2). Es folgt eine programmiertechnische Sicht, bei der das Abstraktionsobjekt des Prozesses im Mittelpunkt steht (siehe Abschnitt 1.3). Zentral f¨ ur Echtzeitsysteme ist die Zeit sowie der Umgang mit ihr in konzeptueller und programmiertechnischer Hinsicht (siehe Abschnitt 1.4). Danach werden wesentliche Anwendungsfelder vorgestellt, bei denen die Merkmale und Anforderungen von Echtzeitsystemen zu Tage treten und entsprechend zu behandeln sind (siehe Abschnitt 1.5). Abschließend wird auf einige Konventionen und Notationen f¨ ur Zeitpunkte, Zeitspannen und Zeitintervalle sowie f¨ ur den Aufwand, den ein Verfahren verursacht, Bezug genommen (siehe Abschnitt 1.6).

1.1 Merkmale von Echtzeitsystemen Bei eingehender Betrachtung ist jedes Programm, das auf einem Rechner ausgef¨ uhrt wird, in einen zeitlichen Rahmen eingebunden. Auch wenn es sich nur in der Form ¨ außert, dass ein Anwender ungeduldig vor seinem Bildschirm auf die Ausgabe von Rechenergebnissen wartet. Zeitliche Unw¨agbarkeiten k¨ onnen von vielen Komponenten, die im Laufe einer Berechnung eine Rolle spielen, herr¨ uhren. Das gilt insbesondere f¨ ur Zugriffe auf Plattenspeicher, die Speicherverwaltung, die Dienste von Netzwerken, die Interaktionen mit Benutzeroberfl¨ achen, aber auch f¨ ur die Ausf¨ uhrung der eigentlichen Berechnung. Dennoch wird man in diesem Kontext nicht von einem Echtzeitsystem sprechen. Herausragende Eigenschaften von Echtzeitsystemen sind die von den Anwendungen vorgegebenen Zeitbedingungen. Eine Anwendung besteht typischerweise darin, dass ein technischer Vorgang mit Hilfe eines Rechensystems erfasst, behandelt und gesteuert werden muss. Aus der Sicht der Informatik ergibt sich damit eine markante Aufteilung in ein externes System, das die anwendungsspezifischen Zeitbedingungen vorgibt, und ein internes System, das die vorgegebenen Zeitbedingungen zu beachten hat. Diese Art, ein Rechensystem zu betreiben, heißt Echtzeitbetrieb (genau genommen Realzeitbetrieb) und ist nach DIN 44300 genormt [38]:

1.1

4

1. Einf¨ uhrung

Ein Betrieb eines Rechensystems, bei dem Programme zur Verarbeitung anfallender Daten st¨ andig betriebsbereit sind, derart, dass die Verarbeitungsergebnisse innerhalb einer vorgegebenen Zeitspanne verf¨ ugbar sind. Die Daten k¨ onnen je nach Anwendungsfall nach einer zeitlich zuf¨ alligen Verteilung oder zu vorherbestimmten Zeitpunkten anfallen. 1.1.1 Harte und weiche Echtzeit

Sicherlich ist diese Definition bereits etwas antiquiert und versagt unter strenger Betrachtungsweise (vgl. [61]). Dennoch wird auch hier die oben angesprochene Aufteilung in intern ablaufende Programme und von außen vorgegebene Zeitspannen deutlich. Offen bleibt jedoch dabei, in welchem Maße diese Vorgaben verpflichtend sind. Man spricht von weichen Zeitbedingungen, wenn es die Anwendung zul¨ asst, dass es gen¨ ugt, die Zeitbedingungen f¨ ur den u ¨berwiegenden Teil der F¨alle zu erf¨ ullen, oder ¨ sich geringf¨ ugige Uberschreitungen der Zeitbedingungen ergeben. 1.1.1

Beispiel 1.1.1 Eine typische weiche Echtzeitanforderung soll Folgendes leisten: An den Schaltern eines Reiseb¨ uros soll die Buchung eines Sitzplatzes in einem Flugzug in 90% der F¨ alle weniger als 10 Sekunden und in 99% der F¨ alle weniger als 20 Sekunden dauern. Harte Zeitbedingungen zeichnen sich entsprechend dadurch aus, dass es unter keinerlei Umst¨anden zu einer ¨ Uberschreitung von Zeitbedingungen kommen darf.


Dennoch sind auch Echtzeitsysteme nicht in der Lage, das Unm¨ogliche m¨ oglich zu machen. So kann es zum einen zu Ausf¨allen technischer Art, z.B. der Rechenanlage, des Netzwerkes usw. kommen. Maßnahmen zur Fehlertoleranz k¨ onnen diese Problematik nur graduell verbessern. Zum anderen kann es harte Zeitbedingungen geben, deren Erf¨ ullung nur unter gewissen Randbedingungen sinnvoll ist. 1.1.2

Beispiel 1.1.2 Die Einhaltung harter Zeitbedingungen ist bei der Berechnung des optimalen Z¨ undzeitpunktes eines Kraftfahrzeugmotors von herausragender Bedeutung. Doch kann es unter speziellen Randbedingungen wichtiger sein, andere gegebenenfalls auch unter harten Echtzeitbedingungen stehende Berechnungen auszuf¨ uhren. Dies ist dann der Fall, wenn das Antiblockiersystem des Kraftfahrzeuges ausgel¨ ost wird und dadurch kurzfristig andere Aufgaben, wie die Erfassung der Radstellungen und die Regelung der Bremskr¨ afte, vorrangig bearbeitet werden.


1.1

Merkmale von Echtzeitsystemen

5

F¨ ur eine formale Festlegung harter Zeitbedingungen sei r der Zeitpunkt, zu dem eine betrachtete Aufgabe beginnen kann, und d der Zeitpunkt, zu dem sie erledigt sein muss. Die Ausf¨ uhrung der Aufgabe, die eine Zeitspanne ∆e in Anspruch nimmt, muss rechtzeitig beginnen und enden. Diese Forderung wird als Rechtzeitigkeit (engl. timeliness) bezeichnet: A ≡ r + ∆e ≤ d Harte Echtzeitsysteme zeichnen sich dadurch aus, dass die Zeitbedingung A bei g¨ unstiger Randbedingung B unbedingt, d.h. mit einer Wahrscheinlichkeit 1, zu erf¨ ullen ist: P (A | B) = 1 In unmittelbarem Bezug zu der jeweiligen Aufgabenstellung steht B daf¨ ur, dass in der Zeitspanne von r bis d weder technische Ausf¨ alle auftreten, noch wichtigere Aufgaben zu erledigen sind. Die obigen Spiegelpunkte sind sehr unterschiedlich zu bewerten. So ist zum letzteren der beiden zu bemerken, dass eine umfassende Systembetrachtung dazu f¨ uhren sollte, solche konkurrierenden Aufgaben, die eine h¨ohere Wichtigkeit besitzen, zu identifizieren und zum Gegenstand einer erweiterten Zeitbedingung zu machen. Dies ist ein zentrales Anliegen der wissenschaftlichen Auseinandersetzung mit Echtzeitsystemen und kann bildhaft so verstanden werden, dass Teile der Randbedingung B in die Zeitbedingung A aufgenommen werden. Beispiel 1.1.3 In Fortsetzung von Beispiel 1.1.2 sei zun¨ achst r + ∆e ≤ d die Zeitbedingung, der die Berechnung des optimalen Z¨ undzeitpunktes gen¨ ugen muss. Wenn zwischen r und d noch eine Regelung des Antiblockiersystems notwendig wird und Vorrang erhalten soll, so ist die daf¨ ur notwendige Dauer ∆f mit in die Zeitbedingung f¨ ur die Berechnung des optimalen Z¨ undzeitpunktes aufzunehmen:

A ≡ r + ∆e + ∆f ≤ d
1.1.2 Determiniertheit und Vorhersagbarkeit

Technische Ausf¨alle, wie sie im ersten Spiegelpunkt der obigen Auflistung erw¨ ahnt sind, lassen sich nicht durch eine Erweiterung der Zeitbedingung

1.1.3

6

1. Einf¨ uhrung

erfassen. Sie wirken sich unmittelbar auf die Zuverl¨assigkeit des Echtzeitsystems aus. Ziel muss es sein, Ausf¨ alle so weit wie m¨oglich auszuschließen. Methodisch bietet es sich an, auf der Grundlage eines mathematischen Modells die H¨ aufigkeit solcher Ausf¨ alle nach oben abzusch¨atzen. Darauf aufbauend sind geeignete Maßnahmen zu ergreifen, um ein anvisiertes Grenzrisiko zu unterschreiten. Derartige Maßnahmen zur Erh¨ohung der Zuverl¨assigkeit werden in drei Kategorien unterteilt (vgl. [53]): Ausschluss von Fehlern und Ausf¨ allen Verminderung der Wahrscheinlichkeit von Fehlern und Ausf¨allen Beeinflussung der Auswirkung von Fehlern und Ausf¨allen Insbesondere der letzte Spiegelpunkt bezieht sich unmittelbar auf die Gefahren, die von einem Echtzeitsystem ausgehen. Alle Maßnahmen zur Abwehr solcher Gefahren f¨ ur Menschen, andere Lebewesen und Sachen tragen zur Sicherheit eines Systems bei. Ein Echtzeitsystem kann als sicher gelten, wenn das verbleibende Risiko 1 − P (B) unter dem Grenzrisiko liegt und sowohl Rechtzeitigkeit, verk¨ orpert durch die Zeitbedingung A, als auch Korrektheit, d.h. die funktionale Richtigkeit des Rechenergebnisses, nachgewiesen ist. Die Forderung nach Rechtzeitgkeit und Korrektheit stellt einen hohen Anspruch dar und setzt voraus, dass eine fundierte Kenntnis des Verhaltens eines Echtzeitsystems vorhanden ist. Vielfach wird in diesem Zusammenhang vom determinierten Verhalten oder allgemein der Determiniertheit eines Echtzeitsystems gesprochen. Die Eigenschaft bedeutet, dass unter allen ¨außeren Bedingungen das Verhalten des Systems eindeutig im Voraus bestimmt werden kann (vgl. [84]): A system is said to be deterministic if for each possible state, and each set of inputs, a unique set of outputs and next state of the system can be determined. Dies ist jedoch gerade mit Blick auf komplexe Echtzeitsysteme eine zu strenge Anforderung. Sie l¨ asst sich dadurch sinnvoll abschw¨achen, dass die Menge des funktionalen und zeitlichen Verhaltens in ihrer Wirkung absch¨atzbar bleibt. In diesem Zusammenhang werden die synonymen Begriffe Vorhersagbarkeit (engl. predictability) und Vorhersehbarkeit verwendet (vgl. [122], [93] und [54]).

1.2

Grundmodell eines Echtzeitsystems

7

1.2 Grundmodell eines Echtzeitsystems Aus dem Blickwinkel von Forschung und Lehre betrachtet, wird unter dem Begriff Echtzeit vorwiegend der harte Echtzeitbegriff verstanden. Entsprechende Systeme werden als echtzeitf¨ ahig bezeichnet. Ihnen kann ein abstraktes Grundmodell zugrunde gelegt werden. Ein externes technisches System und ein Rechensystem sind mittels Mess- und Stellsystem miteinander verbunden (Abb. 1.1).      
 


 



 

 




∆

Abb. 1.1. Grundmodell eines Echtzeitsystems

Das Rechensystem nimmt die u ¨ber das Messsystem (auch als Sensorik bezeichnet) eingehenden Daten des technischen Systems auf, um daraus Ausgabedaten f¨ ur das Stellsystem (auch als Aktorik bezeichnet) zu berechnen. Dies stellt den Regelfall dar und muss rechtzeitig geschehen, d. h. die Bedingung ∆e ≤ d − r muss erf¨ ullt sein. 1.2.1 Paradigmatische Beispiele

Die Verbindung von technischem System mit der Hard- und Software eines Rechensystems, wie sie das Grundmodell darstellt, setzt Expertenwissen in naturwissenschaftlichen Vorg¨ angen, in ingenieurwissenschaftlichen Entwicklungs- und Konstruktionsprinzipien sowie in der Systematik der Verarbeitung von Information voraus. Dies stellt in seiner Breite eine große Herausforderung dar. Insbesondere f¨ ur die Lehre w¨are es hilfreich, u ¨ber paradigmatische Beispiele zu verf¨ ugen, an denen, reduziert auf das Wesentliche, die maßgeblichen Eigenschaften von Echtzeitsystemen demonstriert werden k¨onnen. Nach Auffassung des Wissenschaftstheoretikers Thomas S. Kuhn (vgl. [80]) zeigt sich die Reife eines Fachgebietes unter anderem darin, wie sehr paradigmatische Beispiele unter den Wissenschaftlern bekannt sind und als Gegenstand der Verdeutlichung von Sachverhalten genutzt werden. Zwar gibt es hierzu zahlreiche Ans¨ atze, anhand derer versucht wird, solche Beispiele in das Fachgebiet Echtzeitsysteme einzuf¨ uhren und zu verbreiten, dennoch hat keines bislang einen zufriedenstellenden Bekanntheitsgrad erreichen k¨onnen.

1.2

8

1. Einf¨ uhrung

Dessen ungeachtet ist es dennoch wichtig, das eine oder andere Beispiel zu benutzen, um abstrakten Modellen konkrete Anwendungen gegen¨ uberzustellen. Dies geschieht im Folgenden mittels eines Systems, das eine Kugel auf einer ebenen Fl¨ ache balancieren soll. Eingeschr¨ankte Systeme, die eine Kugel in einer Rinne balancieren, sind unter dem Stichwort ball on a beam (vgl. [139]) bekannt geworden. Der Versuchsaufbau, der nun zun¨ achst die Analogie zum Grundmodell eines Echtzeitsystems verdeutlichen soll, wird im Folgenden kurz als Wippe bezeichnet.

Abb. 1.2. Wippe: Balancieren einer Kugel auf einer Fl¨ ache. Im Mittelpunkt des

Versuchsaufbaus steht die Kugel, die auf der Fl¨ ache gehalten werden soll. Dazu ist die Fl¨ ache beweglich in einem Rahmen aufgeh¨ angt und kann gezielt um zwei Achsen gedreht werden. Am oberen Ende des Rahmens erfasst eine Digitalkamera Fl¨ ache und Kugel. Ziel ist es, eine bewegte Kugel, die beispielsweise auf diese Fl¨ ache geworfen wird, aufzufangen, deren Bewegung zu verlangsamen und sie in der Mitte der Fl¨ ache zum Stehen zu bringen.

1.2.1

Beispiel 1.2.1 Wippe: Der konkrete Aufbau (siehe Abb. 1.2) wurde realisiert,

um f¨ ur die Ausbildung im Fachgebiet Echtzeitsysteme ein treffendes Beispiel zur Verf¨ ugung zu haben, an dem sich typische Prinzipien und Sachverhalte verdeutlichen lassen. Die Wippe steht auch f¨ ur einen einfachen Aufbau, ¨ der sich f¨ ur praktische Ubungen in Laboren von Hochschulen und anderen Ausbildungseinrichtungen eignet (vgl. [144]). Die Analogie zum Grundmodell ist unmittelbar einsichtig. Das Messsystem besteht aus einer Kamera, die mit einer festen Frequenz von 25Hz u ¨ber eine Graphikkarte das Bild der Fl¨ ache mit 240 × 300 Pixeln in einer 8-Bit Graustufen-Darstellung liefert. Das Stellsystem wird von einer MehrkanalMotorsteuerung gebildet. Diese ist verbunden mit zwei Schrittmotoren, die die Fl¨ ache auf weniger als ein Grad genau entlang von zwei orthogonalen

1.2

Grundmodell eines Echtzeitsystems

9

Achsen x und y neigen k¨ onnen. Jedes beliebige Paar (gx , gy ) von Gradienten ist in weniger als 1, 3s erreichbar. Das technische System besteht aus der Kugel auf der Fl¨ ache. Dabei bestimmen der aktuelle Impuls der Kugel und die Gradienten der Fl¨ ache die Bahn, die die Kugel nehmen wird. Der Versuchsaufbau stellt keine Gefahr dar. Dennoch ist hier ein markantes Kriterium der Sicherheit zu erf¨ ullen, das darin besteht, dass die Kugel die Fl¨ ache niemals verlassen darf. Das Rechensystem soll diese Aufgabe mittels Mess- und Stellsystem erf¨ ullen. Im Einzelnen fallen so dem Rechensystem die folgenden Teilaufgaben zu: Erkennung der Position (x, y) der Kugel auf der Fl¨ache. Aggregation weiterer Kenngr¨ oßen der Kugel, die f¨ ur die Vorhersage und Beeinflussung der Bewegung der Kugel wichtig sein k¨onnen, z.B. die Geschwindigkeit (x, ˙ y) ˙ und die Beschleunigung (¨ x, y¨). Berechnung der Gradienten (gx , gy ) der Fl¨ache, die die Kugel von den R¨ andern fern halten und zur Mitte f¨ uhren sollen. Ansteuerung der Schrittmotoren durch Signale, die die Neigung der Fl¨ache den vorgegebenen Gradienten (gx , gy ) anpassen. Es stellt sich die Frage, welche fachlichen Kompetenzen notwendig sind, um die Wippe zu beherrschen: Kenntnis u ¨ber das physikalische Verhalten der Kugel. Dies wird u ¨beraus schwierig, wenn man die Kugel auf der bewegten Fl¨ache betrachtet. Ansteuerung von Schrittmotoren. Zwischen dem Rechensystem und den Schrittmotoren ist ein geeignetes Kontrollger¨at zu platzieren, das die Signale beider Systeme versteht und ineinander u uhren kann. ¨berf¨ Photogrammatische Analyse des Kamerabildes. Das Kamerabild wird benutzt, um die Kugel zu identifizieren und ihre genau Position auf der Fl¨ ache zu bestimmen. Systematik der Software-Entwicklung. Die notwendigen Funktionen sind so zu kapseln, dass Austauschbarkeit und Erweiterbarkeit gew¨ahrleistet sind. Obwohl die Wippe eine recht u ¨berschaubare Anwendung bildet, sind maßgebliche Eigenschaften von Echtzeitsystemen anzutreffen. Gleichzeitig wird deutlich, dass die umfassende Beherrschung der Wippe eine Herausforderung darstellt.
1.2.2 Aktionen und Akteure

W¨ ahrend die Argumentation im vorangegangenen Beispiel bereits f¨ ur den paradigmatischen Charakter der Wippe spricht, ist ein weiterer Sachverhalt zu erw¨ ahnen, der sich bei der Mehrzahl der Echtzeitanwendungen ergibt: Das

10

1. Einf¨ uhrung

Messsystem erzeugt große Datenmengen und das Stellsystem ben¨otigt große Datenmengen, w¨ ahrend das Rechensystem auf der Grundlage weniger, entscheidungsrelevanter Daten den Zustand des technischen Systems erkennen und entsprechend eingreifen muss. Der Vorgang wird auch als Steuerfunktion oder control action CA (vgl. u.a. [134]) bezeichnet. Sie bildet die zentrale Aufgabe des Rechensystems (siehe Abb. 1.3). Davor findet vielfach die Datenreduktion statt (bei der Wippe: Extraktion der Kugelposition aus dem Pixelbild der Kamera) und anschließend eine Datenexpansion (bei der Wippe: die Erzeugung von Steueranweisungen f¨ ur das Kontrollger¨at der Schrittmotoren ¨ sowie die Uberwachung von deren Ausf¨ uhrung)

Abb. 1.3. Im Zentrum der Datenreduktion und Datenexpansion steht die Steuerfunktion

CA.

Ein Echtzeitsystem kennt u ¨blicherweise unterschiedliche Arten der Benutzung. Das bedeutet, dass das Verhalten eines Echtzeitsystems nicht allein durch die Aktionen der Steuerfunktion festgelegt ist, sondern gezielt durch außere Akteure beeinflusst werden kann. Dabei erfolgt der Zugang nicht im¨ mer u ¨ber die Standardschnittstellen wie Tastatur, Maus oder Bildschirm sondern durch spezielle Ger¨ ate, die an die Einsatzumgebung und die Benutzung des Echtzeitsystems angepasst sind. Eine Darstellung, die die Arten der Benutzung modelliert und visualisiert, wird als Anwendungsfalldiagramm (engl. use case diagram) bezeichnet. Diagramme dieser Art sind Bestandteil der UML1 , einer Sammlung von visuellen Sprachen, die dazu dienen, die Software von Rechensystemen unter unterschiedlichen Gesichtspunkten zu beschreiben. Bei den Anwendungsfalldiagrammen geht es dabei um den Gesichtspunkt der Benutzung oder genauer um die Frage, welche Akteure das System in welcher Rolle benutzen. Auch dies l¨asst sich am Beispiel der Wippe verdeutlichen. 1.2.2

Beispiel 1.2.2 Die vorrangige Absicht, mit der die Wippe entwickelt worden ist, liegt darin, die Kugel autonom zu balancieren. In diesem Falle geht eine Handlung von der Kugel aus. Der gesamte Aufbau der Wippe und insbesondere das Rechensystem hat die Aufgabe, ohne menschliche Eingriffe die Kugel 1

Unified Modeling Language

1.2

Grundmodell eines Echtzeitsystems

11

in der Mitte der Fl¨ ache zu stabilisieren. Im Vergleich dazu ist es reizvoll zu sehen, ob auch der Mensch in der Rolle des Handelnden in der Lage ist, die Kugel auf der Fl¨ ache zu halten. F¨ ur diesen zweiten Anwendungsfall, der mit der Wippe realisiert wird, dient ein Joystick, der die unmittelbare Bewegung der Fl¨ ache in beide Richtungen vorgibt. Anwendungungsfalldiagramme (siehe Abb. 1.4) beschreiben die Betriebsarten eines Systems. Offensichtlich eignet sich die Wippe f¨ ur den autonomen und den manuellen Betrieb. Andere Rollen und damit andere Betriebsarten, die f¨ ur Echtzeitsysteme markant sind, bestehen darin, ein Ger¨at oder eine Anlage in einen betriebsbereiten Zustand zu versetzen und seine Ausf¨ uhrung auf m¨ ogliche Fehler hin zu u ¨berwachen. Diese Rolle f¨allt dem Systembetreiber zu. So ist die Wippe vor dem Betrieb zu initialisieren, was unter anderem bedeutet, den Mittelpunkt der Fl¨ ache als Ziellage der Kugel festzulegen. Außerdem sind die Schrittmotoren so einzustellen, dass die waagerechte Stellung der Fl¨ ache identifiziert werden kann. Alle Vorg¨ange, die eine bekannte und sichere Ausgangssituation herstellen, werden als Konfigurierung bezeichnet. Daneben ist es selbst bei einem System, das keinen Schaden anrichten kann, sinnvoll, dessen Verhalten st¨ andig zu u ufen. Bei der Wippe besteht diese ¨berpr¨ ¨ Uberpr¨ ufung unter anderem darin, das Verhalten der Kugel, so wie es beobachtet wird, mit dem zu vergleichen, wie sie sich auf der Grundlage der u ¨ber die Kugel gesammelten Daten verhalten m¨ usste. Sind deutliche Abweichungen zu erkennen, so liegt offensichtlich ein Fehler vor. Der Diagnose obliegt es, solche Fehler zu erkennen und hinsichtlich ihrer m¨oglichen Ursachen zu analysieren. In der Phase der Entwicklung eines Echtzeitsystems hat die Diagnose ihre herausragende Aufgabe in der Erkennung von Fehlerursachen und in ihrer Beseitigung (vgl. weitergehend hierzu [97]). Im Betrieb dient die Diagnose dazu, zumindest den Betreiber zu warnen. Im Falle der Wippe wird st¨andig u uft, ob nur eine Kugel erkannt wird und ob Form und Gr¨oße ¨berpr¨ plausibel sind. Diese Information steht dem Betreiber zur Verf¨ ugung, der beispielsweise durch die Anpassung von Schwellwertparametern die sichere Erkennung der Kugel erreichen kann. Weit kritischer ist die autonome Betriebsart, bei der ein System sicher arbeiten soll, ohne dass ein Betreiber noch eine Eingriffsm¨ oglichkeit besitzt. Hier ist Diagnose unverzichtbar und immer eingebunden in die Bestimmung von Maßnahmen, die in einem Fehlerfall ergriffen werden sollen.
1.2.3 Eingebettete Systeme

Viele Echtzeitanwendungen, wie auch die Wippe, werden von ihren Benutzern als ein Ger¨ at wahrgenommen. Der interne Aufbau, angelehnt an das Grund-

12

1. Einf¨ uhrung


    

 




 
 


  

 


   


 

 

Abb. 1.4.

Anwendungsfall-

 

diagramm f¨ ur die Wippe.

modell, bleibt weitgehend verborgen. Dies gilt insbesondere f¨ ur das Rechensystem, das dem Benutzer nicht mit seinen Standardschnittstellen Tastatur, Maus und Bildschirm gegen¨ ubertritt. Die Eigenschaft, in einer Anwendungsumgebung aufzugehen, ist ein Kennzeichen von eingebetteten Systemen (engl. embedded system)[44]: Unter einem eingebetteten System versteht man ein Computersystem, das fester Bestandteil eines Ger¨ ates oder einer Anlage ist und f¨ ur das Gesamtsystem bestimmte funktionale und leistungsm¨ aßige Anforderungen erf¨ ullt. Mit einem st¨ arkeren Augenmerk auf die Wahrnehmung durch den Benutzer heißt es bei [99]: Eingebettete Systeme sind informationsverarbeitende Systeme, die in ein gr¨ oßeres Produkt integriert sind, und normalerweise nicht direkt vom Benutzer wahrgenommen wird. Die Fragen, die sich im Zusammenhang mit eingebetteten Systemen stellen, sind teilweise ¨ ahnlich gelagert und betreffen verschiedenste Arten von Echtzeitbedingungen, die Sicherheit und die Zuverl¨ assigkeit, die formalen Modelle zur Systembeschreibung und die Systematik der Programmentwicklung. Daneben gibt es Themen, die aus der Sicht von Echtzeitsystemen eher am Rande liegen, w¨ ahrend sie voll den Fokus der eingebetteten Systeme treffen. Diese gilt f¨ ur die Integration und den Systemtest, den energiegewahren Betrieb, den kooperativen Entwurf von Hard- und Software, die Systematik des Aufbaus von Benutzerschnittstellen und die Allgegenwart von Rechnern, die nicht als solche wahrgenommen werde.

1.2

Grundmodell eines Echtzeitsystems

13

Tendenziell haftet dem Begriff der eingebetteten Systeme eine große N¨ahe zum Fortschritt in der Mikrotechnik (vgl. [126]) an. Dies schließt in den meisten F¨ allen auch die Beachtung von Echtzeitbedingungen mit ein, ohne dass diese im Brennpunkt der Betrachtung stehen [99]: Viele eingebettete Systeme m¨ ussen Echtzeit-Bedingungen einhalten. Das ist bei Echtzeitsystemen deutlich anders. Hier stehen Echtzeitbedingungen und deren Einhaltung im Vordergrund. Gleichzeitig liegen den daf¨ ur entwickelten Methoden tendenziell eher generalisierende Modelle zugrunde als Modelle, die unmittelbar an die technische Entwicklung angelehnt sind. Trotz dieser Argumentation ist im konkreten Fall eine Grenzziehung schwierig. Oftmals werden beide Begriffe f¨ ur dasselbe Ger¨at benutzt. In diesem Sinne ist es sicher nicht falsch, beispielsweise die Wippe sowohl als Echtzeitsystem als auch als eingebettetes System zu bezeichnen. Dennoch sind die Begriffe nicht synonym zu verstehen, was wiederum angewandt auf die Wippe bedeutet, dass zum einen die Rechtzeitigkeit, die notwendig ist, um die Kugel auf der Fl¨ ache zu halten, betont wird. Zum anderen kann man den eingebetteten Charakter der Wippe betonen, der sich in der Schnittstelle f¨ ur die verschiedenen Anwendungsf¨ alle zeigt (siehe Abb. 1.4). Das Grundmodell, das diesen Abschnitt dominiert, verbindet die Forderung nach Rechtzeitigkeit mit einer technisch orientierten Sicht auf Echtzeitanwendungen. Gleichzeitig stellt es eine starke Vereinfachung dar, indem eine einzige zyklische Wirkungskette zugrunde gelegt wird. Gesichtspunkte wie Koordination, Kooperation und Konkurrenz, die bei praktischen Anwendungen zu beachten sind, werden vom Grundmodell nicht mehr erfasst. Deshalb wird im n¨ achsten Abschnitt ein Abstraktionsobjekt eingef¨ uhrt, das einerseits diese Gesichtspunkte angemessen ber¨ ucksichtigt und andererseits eine eher programmiertechnische Sichtweise auf Echtzeitsysteme einf¨ uhrt.

14

1.3

1. Einf¨ uhrung

1.3 Prozesse Ein Prozess ist ein Vorgang in der Zeit. Prozesse k¨onnen Vorg¨ange im technischen System sein, ebenso aber auch Vorg¨ange im Rechensystem. Daneben lassen sich die Schnittstellen zwischen externem und internem System als Prozesse auffassen. Prozesse stellen somit Abstraktionsobjekte dar, um Echtzeitsysteme vorgangsorientiert zerlegen zu k¨onnen. Die Gr¨ oßenordnung dessen, was einen Prozess ausmacht, ist nicht festgelegt. Welche Bestandteile zu einem Prozess geh¨oren und was einen Prozess begrenzt, obliegt der jeweiligen Betrachtungsweise. Grunds¨atzlich gilt, dass starke Wirkzusammenh¨ ange einen Prozess bilden, w¨ahrend schwache Wirkzusammenh¨ ange seine Grenzen aufzeigen. Im Wesentlichen sind die Wirkzusammenh¨ ange r¨ aumlicher, zeitlicher oder urs¨achlicher Natur. Prozesse k¨onnen aus Teilprozessen aufgebaut sein und wiederum zu u ¨bergeordneten Prozessen zusammengef¨ uhrt werden. Dies macht Prozesse zu einem vielseitig nutzbaren Abstraktionsobjekt. Prozesse des Rechensystems heißen Rechenprozesse (vgl. [63]). In den Fachgebieten wie Betriebssysteme und Parallele Programmierung gibt es eine Reihe von Pr¨ azisierungen f¨ ur den Prozessbegriff (vgl. beispielsweise [140], [109], [146]). Gleichwohl, ob es sich um formale oder informelle Pr¨azisierungen handelt, so geht aus ihnen hervor, dass Prozesse starke Wirkzusammenh¨ange innerhalb eines Rechensystems bilden, wobei eine begrenzte Menge von Aktionen ausgef¨ uhrt werden, deren Wirkung auf einen begrenzten Zustandsraum trifft. 1.3.1 Datenflussdiagramme

Gerade im Zusammenhang mit der rechtzeitigen Verarbeitung von Daten treten Prozesse in der Rolle zustandsver¨andernder Funktionen auf. Daten, die andere Prozesse bereitstellen, werden unter Zeitbedingungen zustandsabh¨ angig weiterverarbeitet und anderen Prozessen zur Verf¨ ugung gestellt. Als Darstellung eines solchen Geflechts von Wirkzusammenh¨angen eignen sich Datenflussdiagramme (vgl. [36]). Ausgehend von den Messsystemen, die die Daten bereitstellen, werden Schritt f¨ ur Schritt Transformationen (dargestellt durch Kreise) durchgef¨ uhrt. Die Ergebnisse der Transformationen werden in Speichern (dargestellt durch halboffene Rechtecke) bereitgestellt. Die schwachen Wirkzusammenh¨ ange bilden den Fluss der Daten (dargestellt durch gerichtete Kanten), beginnend bei den Messsystemen und endend bei den Stellsystemen. 1.3.1

Beispiel 1.3.1 Anhand der Wippe (siehe Beispiel 1.2.1) l¨ asst sich deutlich ma-

chen, welche Transformationen von Daten notwendig sind, damit die Kugel

1.3

Prozesse

15

auf der Fl¨ ache balanciert werden kann. Das zugeh¨orige Datenflussdiagramm (siehe Abb. 1.5) hat zwei ¨ außere Transformationen, die Umformung der Daten vom Messsystem und zum Stellsystem durchf¨ uhren. Zwei innere Transformationen dienen dazu, das Verhalten der Kugel und die notwendige Steuerung in Form physikalischer Kenngr¨ oßen zu beschreiben.

Abb. 1.5. Das Datenflussdiagramm gibt die

wesentlichen Schritte der Verarbeitung wieder. Angestoßen wird der Fluss, sobald ein neues Pixelbild vorliegt. In mehreren Teilschritten, die hier in der Transformation Erkennung Kugelposition“ ” zusammengefasst sind, wird die (x, y)-Position der Kugel ermittelt. In der Transformation Aggregation aus ” Kenngr¨ oßen“ wird aus vorangegegangenen Positionen auf die aktuelle Bewegung der Kugel geschlossen. Die physikalischen Bewegungsdaten sind die Argumente der Steuerfunktion“, die daraus die ” vorgegebenen Neigungen gx und gy der Fl¨ ache berechnet. In der letzten Transformation Motorsteuerung“ werden ” die Neigungsvorgaben durch die Motoren eingestellt.


Datenflussdiagramme sind ein wesentlicher Bestandteil von verschiedenen, weit umfassenderen Ans¨ atzen zur Analyse und zum Entwurf von Echtzeitanwendungen. Eine Reihe weiterer Diagramme (z.B. Kontextdiagramme), Beschreibungselemente (z.B. Kanten zur Darstellung des Kontrollflusses) und Verzeichnisse (z.B. Sammlung aller verwendeten Begriffe) wurden eingef¨ uhrt, um den softwaretechnischen Anforderungen von Echtzeitsystemen zu gen¨ ugen (vgl. [138], [58] und [50]). Objektorientierte Analyse- und Entwurfsmethoden sind stark von den Diagrammsprachen von UML gepr¨ agt. Weder Prozesse noch Datenflussdiagramme sind unmittelbarer Bestandteil der UML. Vielmehr gibt es dort einerseits den Begriff des aktiven Objektes, der dazu dient starke Wirkzusammenh¨ange zu kapseln, und andererseits die Kollaborationsdiagramme, die am ehesten den Fluss von Daten zwischen Objekten wiedergeben (vgl. [115], [51] und [137]).

16

1. Einf¨ uhrung

1.3.2 Regelungstechnik

Der Begriff des Prozesses findet auch in der Regelungs- und Automatisierungstechnik Verwendung. Dabei wird ein mathematisches Modell f¨ ur das Verhalten eines technischen Prozesses (auch Strecke genannt) zugrunde ge¨ legt. Dies ist festgelegt durch die Ubertragung von Eingangssignalen auf Ausgangssignale (siehe Abb. 1.6).


 


 





¨ Abb. 1.6. Ubertragungsglieder bilden die elementaren Bausteine von Reglern.

Die Zielsetzung, die dabei verfolgt wird, geht dahin, den technischen Prozess durch ein Stellglied am Eingang so zu beeinflussen, dass am Ausgang das gew¨ unschte Verhalten erzielt wird. Dazu misst ein Regler die Differenz von dem tats¨ achlichen Verhalten (Istwert) und dem gew¨ unschten Verhalten (Sollwert). Durch R¨ uckkopplung des Ausgangs des technischen Prozesses schließt sich der Regelkreis (siehe Abb. 1.7). Als klassisches Beispiel eines solchen Regelungssystems l¨ asst sich die Einhaltung der Drehzahl eines Motors nennen. Ein neueres Beispiel f¨ ur eine regelungstechnische Aufgabe ist die Spurf¨ uhrung von Fahrzeugen im Straßenverkehr.



 




 


 





  

     



   



 









Abb. 1.7. Blockdiagramm eines Reglers, bestehend aus verschalteten ¨ Ubertragungsgliedern.

Trotz der Analogien zwischen dem Grundmodell eines Echtzeitsystems und dem Blockdiagramm eines Regelkreises haben sich die L¨osungsans¨atze recht unabh¨ angig entwickelt. W¨ ahrend Regler klassisch auf mechanischem oder elektronischem Wege, sp¨ ater durch speicherprogrammierbare Steuerungen realisiert wurden, hat sich das Fachgebiet Echtzeitsysteme unmittelbar aus der Datenverarbeitung heraus entwickelt und spezialisiert. Erst in neuerer Zeit sind Anstrengungen zu erkennen, die tradierten Sichten und Vorgehensweisen einander anzun¨ ahern. Insbesondere die Regelungstechnik pflegt noch immer die traditionelle Sicht, dass ein dediziertes Rechensystem zur Verf¨ ugung steht, sich nach deterministischen Regeln verh¨alt und zu a quidistanten Zeitpunkten in den technischen Prozess eingreift (vgl. [112]). ¨ W¨ ahrend diese Sicht vielleicht noch auf die klassiche Drehzahlregelung bei einem Motor zutrifft, versagt sie v¨ ollig bei Rechensystemen, die aufbauend

1.3

Prozesse

17

auf einer komplexen Infrastruktur mehrere Aufgaben gleichzeitig erledigen m¨ ussen. Letzteres ist bei der Regelung der Spurf¨ uhrung eines Fahrzeugs gegeben, wo viele Mess- und Stellsysteme u ¨ber konkurrierende Nachrichten auf den Netzwerken im Fahrzeug und konkurrierende Berechnungen auf dem Rechensystem, das die Regelung ausf¨ uhrt, zusammenarbeiten m¨ ussen und anstelle von Determiniertheit lediglich Vorhersagbarkeit erwartet werden kann. Beispiel 1.3.2 Eine Musteranwendung, die im Fachgebiet Regelungstechnik beheimatet ist und unter dem Namen ball on a beam bekannt ist, kann als Spezialfall der Wippe (siehe Beispiel 1.2.1) gelten. Die Aufgabe des Reglers besteht darin, eine Kugel, die sich in einer Rinne bewegt, zu einer vorgegebenen Position zu rollen. Ein typischer L¨osungsansatz aus regelungstechnischer Sicht basiert auf der ¨ Verschaltung von Ubertragungsgliedern, die zwei verschachtelte Regelkreise enth¨ alt (vgl. [30]). In einem inneren Regelkreis wird der Motor, der die Rinne neigt, auf einen Sollwinkel gsoll (t) geregelt. In einem ¨außeren Regelkreis wird die Kugel in die Sollposition xsoll (t) gebracht (siehe Abb. 1.8).

 



 


  






  




 

Abb. 1.8. Blockschaltbild des Regelkreises f¨ ur das Anwendungsbeispiel ball on a beam.




1.3.2

18

1.4

1. Einf¨ uhrung

1.4 Echt und Zeit Die Redensart ... in Echtzeit ... hat im deutschen Sprachraum einen recht popul¨ aren Anstrich angenommen. So werden beispielsweise Gewinne und Verluste im Aktienhandel in Echtzeit gutgeschrieben, eine Echtzeitdiagnose f¨ ur R¨ ontgenbilder angepriesen, ein echtzeitf¨ahiges Codierungsverfahren f¨ ur Mu¨ sikaufzeichungen im MP3-Format angek¨ undigt und Ahnliches mehr. Gemeint ist dabei in erster Linie, dass eine wie auch auch immer geartete Dienstleistung vor dem Auge des Betrachters erbracht wird und somit authentisch, wirklich und echt ist. Die Verleihung des Merkmals Echtzeit f¨ ur ein Ger¨at, ein System oder ein Verfahren geschieht mit der Absicht seiner Aufwertung. Offensichtlich setzen diejenigen, die auf diese Weise Aufmerksamkeit oder gar Werbewirksamkeit erzeugen wollen, eine positive Belegung des Begriffes Echtzeit voraus. Sicher ist diese auch gegeben, sie lebt jedoch davon, dass der Begriff nicht unberechtigt oder inflation¨ ar verwendet wird. Deshalb sollten die Ger¨ate, Systeme und Verfahren, die mit dem Attribut Echtzeit versehen werden, nach objektiven Maßst¨ aben die Kriterien wie Rechtzeitigkeit, Vorhersagbarkeit, Sicherheit und Zuverl¨ assigkeit erf¨ ullen und dokumentieren. Viele Anwendungen werden erst dadurch sinnvoll und nutzbar, dass sie in Echtzeit erfolgen. Demgegen¨ uber gibt es Anwendungen, die trotz der heute verf¨ ugbaren Rechenleistung nicht in Echtzeit m¨oglich sind. F¨ ur einige wenige, wie beispielsweise Entschl¨ usselungsverfahren, ist es sogar ein Muss, dass sie in absehbarer Zeit keine L¨ osung finden. Bei anderen Anwendungen w¨ unscht man sich hingegen, dass sie in Echtzeit ablaufen. Zahlreiche Beispiele hierf¨ ur finden sich in der Bildverarbeitung. Zwei Parameter sind vorrangig f¨ ur die Dauer der Verfahren entscheidend: die Bildwiederholrate und die Aufl¨osung des Bildes. F¨ ur die Erzeugung von Bildern vor dem Auge des Betrachters, z.B. in Abh¨ angigkeit des von ihm gew¨ ahlten Blickwinkels, besteht eine starke Wechselwirkung zwischen der Bildwiederholrate und der Aufl¨osung. Nur wenn beide Parameter in einer beschr¨ ankten Beziehung zueinander stehen, ist die Bilderzeugung in Echtzeit m¨ oglich (siehe Abb. 1.9). Ist dagegen die Bilderzeugung in Echtzeit nicht m¨oglich, dann kann man sich mit Vorberechungen (engl. precomputation) behelfen. So lassen sich einzelne Bilder mit hoher Aufl¨ osung vorberechnen, zu Szenenfolgen zusammenstellen, um sie dem Betrachter in Echtzeit vorzuf¨ uhren. Vorberechnungen lassen sich dar¨ uber hinaus dazu nutzen, Anwendungen deutlich zu beschleunigen und auf diese Weise echtzeitf¨ ahig zu machen.

1.4.1

Beispiel 1.4.1 Stellvertretend f¨ ur eine Vielzahl von Anwendungen sei die Bild-

erzeugung bei Pflanzen erw¨ ahnt. Basierend auf Erzeugungsregeln (z.B. Lin-

1.4

Echt und Zeit

19

    

Abb. 1.9. Qualitative Darstellung



   

der Wechselwirkung von Bildwiederholrate und Au߬ osung bezogen auf eine Bilderzeugung in Echtzeit.

demayer Systeme, vgl. [37]) und anderen Mechanismen lassen sich hochaufgel¨ oste Bilder von Pflanzen erzeugen, z.B. die Bilder von Nadelb¨aumen [35]. Um einen solchen Baum aus jeder Perspektive in Echtzeit wiedergeben zu k¨ onnen, lassen sich Vorberechungen nutzen. Dazu werden virtuelle Schnitte durch den Baum gelegt und die einzelnen Scheiben (engl. slice) vorberechnet und abgespeichert. Wird aus einer speziellen Position heraus eine Ansicht des Baumes verlangt, dann werden die Schnitte den Sichtbarkeitsregeln entsprechend u uhrung effizienter Interpolationsfunk¨berblendet, was durch die Ausf¨ tionen in Echtzeit m¨ oglich ist und wesentlich weniger Zeit erfordert als diese Bilder auf der Grundlage der Regeln zu erzeugen und darzustellen.
1.4.1 Schnelligkeit und Rechtzeitigkeit

Es wird zwar richtigerweise betont, dass ein Echtzeitsystem nicht durch die schnellstm¨ oglichen Verfahren, die zur Anwendung kommen, charakterisiert wird (vgl. [121]): Rather than being fast (which is a relative term anyway), the most important property of a real-time system should be predictability; ... Aber schnelle Verfahren auf leistungsf¨ ahigen Rechnern und Netzwerken bei erschwinglichen Kosten sind ¨ außerst wichtige Voraussetzungen f¨ ur die Verbreitung von Echtzeitanwendungen in vielen Lebensbereichen (vgl. [121]): Fast computing is helpful in meeting stringent timing specifications, ... Die Entwicklung vieler Echtzeitanwendungen wurde bereits zu Zeiten begonnen, als weder die entsprechenden Verfahren noch die technischen Voraussetzungen gegeben waren, sie in Echtzeit zur Anwendung zu bringen. Dies bedeutet, dass oftmals abzuwarten ist, bis die Zeit daf¨ ur gekommen ist, eine prototypische Echtzeitanwendung in ein marktreifes und marktgerechtes Produkt zu u uhren. Ein Beispiel, das einerseits die zeitliche Entwicklung ¨berf¨ eines Produktes (in Beispiel 1.4.2) und andererseits die zeitlichen Eigenschaf-

20

1. Einf¨ uhrung

ten der Anwendung verdeutlicht, ist die Verkehrszeichenerkennung (in Beispiel 1.4.3). 1.4.2

Beispiel 1.4.2 Schon Anfang der neunziger Jahre wurde unter dem Oberbegriff aktives Sehen im Fahrzeug“ neben anderen Aufgabenstellungen auch ” die Erkennung von Verkehrszeichen (engl. traffic sign recognition oder TSR) betrieben. Ausgehend von einem Kamerabild sind die dort aufgezeichneten Verkehrszeichen zu erkennen. Das stellte sowohl von Seiten der verf¨ ugbaren ¨ Rechen- und Ubertragungsleistung als auch von Seiten der Erkennungsverfahren eine große Herausforderung dar. Sequenzielle Analyseverfahren ben¨ otigten auf einer Workstation einige Sekunden, um etwa 95% der Verkehrszeichen in einem Abstand bis zu 50m zu erkennen, und nur durch den massiven Einsatz von Parallelrechnern war eine Erkennung in weniger als einer Sekunde m¨ oglich (vgl. [107]). Unter diesen Voraussetzungen war es kaum absehbar, wann und in welcher Weise die Verkehrszeichenerkennung einmal f¨ ur Serienfahrzeuge verf¨ ugbar werden w¨ urde. Offensichtlich ist es ein langer Weg von der Existenz eines prototypischen Verfahrens bis hin zu seiner Integration in ein umgebendes System, das als kommerzielles Produkt vertrieben wird. F¨ ur die Verkehrszeichenerkennung bildet das Fahrzeug das umgebende System, in das diese Aufgabenstellung einzubetten ist. Folgende Gesichtspunkte, die am Beispiel der Verkehrszeichenerkennung erl¨ autert werden, sind bei dem Vorgang der Einbettung maßgebend: Die Verkehrszeichenerkennung als eingebettete Aufgabenstellung: Hier geht es darum, die Aufgabenstellung unter funktionalen Gesichtspunkten zu spezifizieren, systematisch in Teilaufgaben zu zerlegen und entsprechende Algorithmen zu entwickeln. Bezogen auf die Verkehrszeichenerkennung werden verschiedene Zerlegungen und unterschiedliche algorithmische Ans¨ atze verfolgt. Bei den Aufgabenzerlegungen hat sich dabei grob eine Trennung in einen Schritt, der das Bild segmeniert, und einen Schritt, der die erkannten Segmente klassifiziert (vgl. [42]), herausgebildet. Algorithmisch kommen neben konventionellen auch neuronale Programmiertechniken zur Anwendung. Gleichzeitig werden kontur- und farbbasierte Segmentierungsverfahren ausprobiert (vgl. [12]). Letztendlich sind objektive G¨ utekriterien n¨otig, um die vielen Verfahren gegeneinander abgleichen zu k¨ onnen. Bei der Verkehrszeichenerkennung bestehen diese vorrangig in der Rate, mit der Verkehrszeichen nicht oder falsch erkannt werden, und in der Dauer, die f¨ ur die spezifizierte Aufgabenstellung ben¨ otigt wird. Die Verkehrszeichenerkennung als eingebettetes System: Hierbei ist die hard- und softwaretechnische Infrastruktur des Fahrzeugs

1.4

Echt und Zeit

21

zugrunde zu legen. So muss es eine Kamera geben, die den Blick aus dem Fahrzeug nach vorne aufnimmt. Diese Vorauskamera kann und wird f¨ ur mehr als f¨ ur die Verkehrszeichenerkennung zur Verf¨ ugung stehen. Es bietet sich an, auch f¨ ur die Spurerkennung und -verfolgung (engl. lane keeping support oder LKS) sowie die Abstandsregelung zum vorausfahrenden Fahrzeug (engl. active cruise control oder ACC) die Bilddaten der Vorauskamera zu nutzen (siehe Abb. 1.10). Diese Aufgabestellungen verfolgen andere Ziele, sind anders zu zerlegen und verlangen andere Algorithmen. Be¨ zogen auf die zur Verf¨ ugung stehende Rechen- und Ubertragungsleistung stehen sie in Konkurrenz zueinander. Dies f¨ uhrt im Weiteren zu der Frage, ob und wie es m¨ oglich ist, einzelne Aufgabenstellungen wie die Verkehrszeichenerkennung rechtzeitig zu erledigen. Die Verkehrszeichenerkennung als Assistenzsystem: Hier geht es darum, wie das eingebettete System mit dem Fahrer2 oder dem Fahrzeug interagiert. Die Assistenz kann darauf abzielen, den Fahrer zu informieren, ihm beispielsweise akustisch und visuell mitzuteilen, dass er sich einem Warnschild mit einer Geschwindigkeitsbegrenzung n¨ahert. In diesem Fall spricht man von einem Fahrerassistenzsystem, das auf der Fahrerseite eine nach ergonomischen Gesichtpunkten aufgebaute MenschMaschine-Schnittstelle (engl. human machine interface oder HMI) besitzt. Die Assistenz kann aber auch auf das Fahrzeug selbst einwirken. Beispielsweise kann die Geschwindigkeit des Fahrzeugs ohne Zutun des Fahrers auf die gerade erkannte Begrenzung heruntergeregelt werden. In diesem Fall spricht man von einem Fahrassistenzsystem. Erst nach fast zwei Jahrzehnten intensiver Entwicklungsarbeit ist f¨ ur die Verkehrszeichenerkennung die Serienreife erreicht. Neben den oben beschriebenen Gesichtspunkten der Einbettung war sicher auch entscheidend, dass es mittlerweile m¨ oglich ist, eine Verkehrszeichenerkennung in weniger als 100ms auszuf¨ uhren und nur etwa 1% der Verkehrszeichen zu verpassen (vgl. [12]).
1.4.2 Zeit auf dem Rechensystem

W¨ ahrend das obige Beispiel 1.4.2 die Zeit f¨ ur die Entwicklung einer produktreifen Anwendung betrachtet, soll das n¨ achste Beispiel 1.4.3 die Zeit sowohl aus physikalisch-technischer Sicht als auch aus rechentechnischer Sicht beleuchten. Als konkrete Anwendung dient wiederum die Verkehrszeichenerkennung. 2

Der Einfachheit halber wird stellvertretend f¨ ur Fahrer und Fahrerin nur die m¨ annliche Form verwendet.

22

1. Einf¨ uhrung

 
  















Abb. 1.10. Ein Kamerabild wird f¨ ur



unterschiedliche Assistenzsysteme genutzt. Die Verarbeitungsschritte zur Verkehrszeichenerkennung stehen in Konkurrenz zur Abstandsregelung sowie zur Spurerkennung

 
 

  



1.4.3

und -verfolgung.

Beispiel 1.4.3 Drei markante Aufgaben sind bei der Verkehrszeichenerken-

nung im Rahmen eines Fahrerassistenzsystems zu bew¨altigen: Die Erkennung und Bestimmung einzelner Verkehrszeichen aus dem Kamerabild heraus, typischerweise zerlegt in die zwei Schritte Erkennung der Gestalt und Klassifizierung innerhalb eines Satzes von bekannten Verkehrszeichen. Die Verfolgung der erkannten Verkehrszeichen und die Bestimmung ihrer Lage im Verh¨ altnis zum Fahrzeug, das sich auf sie zubewegt. Zeitnahe und ergonomische Hinweise an den Fahrer u ¨ber die Ann¨aherung an ein Verkehrszeichen. Das Fahrzeug in Bewegung stellt einen physikalisch-technischen Vorgang dar, der idealisiert so beschrieben werden kann:
t v(τ ) dτ + s0 − spts s(t) = 0

Dabei ist s0 die Startposition des Fahrzeugs zum Zeitpunkt t = 0 und spts die Position des Verkehrszeichens. Die folgende Vektorfunktion beschreibt die Bewegung des Fahrzeugs im Raum: ⎛ ⎞ x(t) ˙ v(t) = ⎝ y(t) ˙ ⎠ z(t) ˙ Im Sinne der klassischen Physik ist der Zeitparameter t kontinuierlich. Dies ist anders, wenn aus rechentechnischer Sicht von der Zeit die Rede ist. Gemeint ist hierbei typischerweise die diskrete Zeit t, die ein Uhrbaustein (bzw. kurz Uhr (engl. clock) genannt) liefert. Ein solcher besteht aus einem Oszil-

1.4

Echt und Zeit

23

lator, der Zeitereignisse erzeugt, und einem Z¨ahler, der diese Zeitereignisse aufzeichnet. Die Zeitspanne von einem Zeitereignis zum n¨achsten ist idealerweise immer gleich lang und wird als Bezugszeitspanne ∆tG bezeichnet. Die Uhrzeit ct ist damit die Summe von k gez¨ ahlten Bezugszeitspannen ab einem diskreten Zeitpunkt ct0 : ct = ct0 + k ∆tG Im Folgenden wird in diesem Zusammenhang von Uhrzeit (engl. clock time) ct gesprochen. Aus dem kontinuierlichen Vorgang wird in der Wahrnehmung durch das Rechensystem ein diskreter Vorgang. So liegen von den Verkehrszeichen zu diskreten Zeitpunkten Kamerabilder vor. Gegebenenfalls kann nicht jedes Kamerabild aufgrund der daf¨ ur notwendigen Ausf¨ uhrungszeit analysiert werden. ¨ Ubrig bleibt f¨ ur ein Verkehrszeichen j, das auf einer Folge von Kamerabildern erkannt wird, seine aus der Gr¨ oße gesch¨atzte Entfernung sj,i und der diskrete Zeitpunkt ti , der dem jeweiligen Kamerabild zugeordnet ist (siehe Abb. 1.11).



   


    

      

 

{

 


 



   


    

Abb. 1.11. Ein kontinuierlicher Vorgang des technischen Systems reduziert sich in der

Wahrnehmung durch das Rechensystem auf einen diskreten Vorgang, der durch geordnete Paare der Form (si , ti ) beschrieben wird.

¨ Die Uberg¨ ange vom technischen zum rechentechnischen System und wieder zur¨ uck zum technischen System, wie es vom Grundmodell eines Echtzeitsystems beschrieben wird, bergen einige grunds¨ atzliche Probleme, auf die noch im Detail eingegangen wird (siehe Unterabschnitt 2.3.2). Drei der gravierendsten seien an dieser Stelle schon einmal erw¨ahnt, weil sie den Blick auf die Schwierigkeiten, die mit Echtzeitanwendungen verkn¨ upft sind, verdeutlichen: Die Position si eines erkannten Verkehrschildes kann aus dem Kamerabild heraus abgesch¨ atzt werden. Dabei ist aufgrund von Ungenauigkeiten der Linse, der CCD-Fl¨ ache der Kamera und des Analyseverfahrens mit deut-

24

1. Einf¨ uhrung

lichen Abweichungen vom tats¨ achlichen physikalisch-technischen Vorgang zu rechnen. F¨ ur die Verkehrszeichenerkennung kann es jedoch hinreichend sein, wenn die Werte si in einem relativ breiten Toleranzbereich bis zu ±20% von der tats¨ achlichen Entfernung abweichen. Wichtig in diesem Zusammenhang ist es, die Grenzen der wertem¨aßigen Ungenauigkeiten zu kennen. Die Uhrzeit ti , die einem Kamerabild zugeordnet wird, unterliegt zwei Arten von Ungenauigkeiten. Die erste besteht in der Diskretisierung der kontinuierlichen Zeit im Raster der Bezugszeitspanne ∆tG . Die zweite Art der Ungenauigkeit h¨ angt damit zusammen, dass die Frequenz des Oszillators einerseits nur mit einer begrenzten Pr¨azision bekannt ist und andereseits der Oszillator durch ¨außere Einfl¨ usse oder Alterungsprozesse seine Frequenz ver¨ andert. Im zweiten Fall spricht man von der Drift der Uhrzeit. Als weiteres Problem neben wertem¨ aßiger Ungenauigkeit, Diskretisierung und Drift kommt mit erheblicher Bedeutung hinzu, dass im Programm die Angaben u ¨ber den physikalisch-technichen Vorgang erst dann vorliegen, wenn eine Reihe von Verarbeitungsschritten, die des Messsystems und die des Rechensystems, bereits abgelaufen sind. In Abb. 1.12 wird ersichtlich, dass die geordneten Paare (si , ti ) erst mit einer zeitlichen Verz¨ogerung zur weiteren Verarbeitung, insbesondere zur Warnung des Fahrers, zur Verf¨ ugung stehen. Hinzu kommt, dass die zu treffenden Maßnahmen selbst auch wieder Verarbeitungsschritte im Rechensystem zu durchlaufen haben und dann u ¨ber eine Mensch-Maschine-Schnittstelle in geeigneter Weise an den Fahrer weitergereicht werden. All dies ist zu ber¨ ucksichtigen, wenn man die Echtzeitf¨ahigkeit einer Anwendung, hier die der Verkehrszeichenerkennung, analysieren will.
1.4.3 Diskretisierung und Drift

Diskretisierung ist immer erforderlich, wenn kontinuierliche physikalische Gr¨ oßen im Rechensystem numerisch verarbeitet werden sollen. Das gilt insbesondere auch f¨ ur die Zeit. Uhrbausteine sind wesentliche Bestandteile von Echtzeitsystemen. Typischerweise besitzen sie einen Oszillator mit einer konstanten Frequenz f . Die Schwingungen des Oszillators werden gez¨ahlt, bis eine gew¨ unschte Bezugszeitspanne ∆tG erreicht ist. Die Uhrzeit wird in Einheiten von ∆tG gemessen und ist in dieser Granularit¨at im Echtzeitsystem verf¨ ugbar. Eine Ursache f¨ ur Abweichungen liegt jedoch bereits in der Bestimmung der Anzahl der Schwingungen nG , bis ∆tG erreicht ist: nG = max{n ∈ N | n/f ≤ ∆tG }

1.4

Echt und Zeit

25

Der Quotient nG /(f ∆tG ) heißt Drift und sollte unter idealen Gegebenheiten den Wert 1 haben, was allein aufgrund der Diskretisierung nicht notwendigerweise zutreffen muss. Die relative Abweichung ρ, mit    nG  ρ = 1 − f ∆tG  liegt zwar u ¨blicherweise bei Werten kleiner als 10−7 . Die absolute Abweichung w¨ achst jedoch proportional mit der physikalischen Zeit t . Beispiel 1.4.4 Bei handels¨ ublichen Oszillatoren mit 32768Hz, wie sie in Arm-

banduhren verwendet werden, liegt die relative Abweichung bei 3, 05 · 10−5 . Die absolute Abweichung w¨ achst proportional mit der Zeit und erreicht bezogen auf einen Tag bis zu 2, 64s.
Die im Rechensystem verf¨ ugbare Uhrzeit ct(t) berechnet sich abh¨angig von der physikalischen Zeit t und einem Startzeitpunkt ct0 :   nG t + ct0 ct(t) = f ∆tG Auf lange Sicht kann die Uhrzeit merklich von der physikalischen Zeit abweichen (siehe Abb. 1.12). 



  


∆


Abb. 1.12. Verlauf der Uhrzeit



ct(t), aufgetragen u ¨ber der physikalischen Zeit t.

Weitere Fehlerquellen f¨ ur eine Drift der Uhrzeit liegen darin, dass Oszillatoren von Altersprozessen, Temperaturen, Spannungen und vielem mehr abh¨angen k¨onnen, so dass die nominelle Frequenz f von der tats¨achlichen Frequenz abweicht.

1.4.4

26

1.4.1

1. Einf¨ uhrung

Aufgabe 1.4.1 (siehe Seite 275) Ein Uhrbaustein ist mit einem 25-MHz-

Oszillator und einer Z¨ ahlervariable nG zu realisieren. (a) Der Uhrbaustein soll Zeiteinheiten der Granularit¨at ∆tG = 10µs erzeugen. Wie groß ist die Z¨ ahlvariable nG zu w¨ahlen? (b)Nach welcher Zeit ist dabei eine Korrektur n¨otig, falls (z.B. aufgrund von Umwelteinfl¨ ussen) die Frequenz 25,001 MHz betr¨agt und eine Toleranz von 1µs erlaubt ist? (c) Wie kann eine sprunghafte Anpassung beim Erreichen der Toleranzgrenze vermieden und wie die Abweichung minimiert werden?
1.4.4 Echtzeit

Neben der physikalischen Zeit und der Uhrzeit soll im Rahmen dieses Abschnitts auch der Begriff Echtzeit er¨ ortert werden. Viele Lehrb¨ ucher im Fachgebiet Echtzeitsysteme gehen auf diesen Begriff nicht explizit ein (vgl. u.a. [78], [26] oder [142]). Andere befassen sich ausdr¨ ucklich mit dem Begriff Echtzeit und setzten ihn mit dem kontinuierlichen Zeitbegriff der klassischen Physik gleich (vgl. [75]) und [118]). Letztere Betrachtungsweise l¨asst sich aus mindestens zwei Gr¨ unden kritisieren: Der Bezug zu klassischen Physik klammert die Erkenntnisse der modernen Physik aus, die sich nun immerhin schon 100 Jahre im Umlauf befinden. Zumindest sollte diskutiert werden, unter welchen Bedingungen die klassische Physik mit ihrem Zeitbegriff noch hinreichend f¨ ur den Einsatz im Fachgebiet Echtzeitsysteme ist. Im Bereich der Verplanung von Prozessen, was den zentralen Kern der wissenschaftlichen Betrachungen des Fachgebietes Echtzeitsysteme bildet, wird Echtzeit vorrangig als diskrete Gr¨oße in z¨ahlbaren Einheiten einer wie auch immer definierten Bezugszeitspanne modelliert. Dies ist Grund genug, Echtzeit als eigenst¨andige Gr¨oße zu betrachten, die den ¨ Erfordernissen des Fachgebietes Echtzeitsysteme angepasst ist. Uber weite Strecken des wissenschaftlichen Diskurses ist es angebracht, Echtzeit durch die Menge der nat¨ urlichen Zahlen zu repr¨asentieren. So wird ein Plan als die Abbildung der nat¨ urlichen Zahlen auf die Prozesse modelliert (siehe Abschnitt 2.1). An anderen Stellen ist es f¨ ur infinitesimale Betrachtungen notwendig, Echtzeit durch reelle Zahlen zu repr¨asentieren. Dies gilt beispielsweise f¨ ur die Bestimmung besonders ung¨ unstiger Planungsvoraussetungen, bei de√ nen die Ausf¨ uhrungszeiten von zwei Prozessen im Verh¨altnis 2 zueinander stehen (siehe Abschnitt 3.3.1). Damit ist Echtzeit als eine eigenst¨andige poly-

1.4

Echt und Zeit

27

morphe Menge zu verstehen, die der jeweils ben¨otigten Abstraktion innerhalb des Fachgebietes Echtzeitsysteme gen¨ ugen muss.

28

1.5

1. Einf¨ uhrung

1.5 Echtzeitsysteme in der Praxis Mit dem Blick auf den praktischen Einsatz von Echtzeitsystemen soll zun¨ achst die Frage gestellt werden, wozu die Beachtung von harten und weichen Zeitbedingungen und die Forderung nach vorhersagbarem oder gar determiniertem Systemverhalten dient. Weithin verbreitet ist die Antwort, dass Echtzeitsysteme in sicherheitsrelevante Bereiche eingreifen und ihr Fehlverhalten mit Schaden verbunden ist (vgl. [61], [79], [123] und [53]). Dabei ist es sinnvoll, eine qualitative Abstufung des Schadens vorzunehmen: Schaden f¨ ur Leib und Leben (z.B. bei St¨orungen in Flug¨ uberwachungssystemen oder Ausf¨allen im Antiblockiersystem von Kraftfahrzeugen) Schaden finanzieller Art (z.B. durch Verz¨ogerungen im Ablauf von Produktionsstraßen oder die Erh¨ ohung des Ausschusses bei einer ungenauen Temperaturregelung eines Brennofens) Schaden in Form von Qualit¨ atseinbußen (z.B. beim zwischenzeitlichen Absinken der Sprachqualit¨ at eines Telefongespr¨aches aufgrund von ¨ Uberlastung) Bezogen auf Echtzeitsysteme geht es vorrangig darum, Schaden aufgrund nicht einzuhaltender Zeitbedingungen zu verhindern. Im Sinne der Definition P (r + ∆e ≤ d | B) = 1 ist daf¨ ur zu sorgen, dass von der Bedingung B alle relevanten Situationen, unter denen das Echtzeitsystem betrieben wird, erfasst sind. Ist das nicht der Fall, so sollte wenigstens ausdr¨ ucklich bekannt sein, unter welchen g¨ unstigen Bedingungen B sich keine Fristverletzungen ergeben werden. Damit spezifiziert B die Betriebsbedingungen des Echtzeitsystems. 1.5.1 Anwendungen f¨ ur die Lehre

Die Betrachtung von Echtzeitsystemen in der Praxis schließt auch die Praxis der Lehre mit ein. In der Ausbildung an Hochschulen sind neben den technischen und theoretischen Grundlagen auch Anwendungen gefragt, die musterhaft die Eigenschaften von Echtzeitsystemen im Kleinen aufzeigen und begreifbar machen. Anwendungen dieser Art werden als paradigmatische Beispiele bezeichnet und sollen kompakt, verst¨andlich und plakativ sein. Gleichzeitig sollen sie jedoch anspruchsvoll genug sein, dass ihre L¨osung eine Herausforderung darstellt. Sind paradigmatische Beispiele zum Gemeingut von Wissenschaftlern geworden, die auf einem Fachgebiet arbeiten, dann ist es m¨ oglich, neue Ans¨ atze, Methoden und Verfahren zum Einsatz zu brin-

1.5

Echtzeitsysteme in der Praxis

29

gen, ihre Vor- und Nachteile nach objektiven Kriterien herauszuarbeiten und Vergleiche mit anderen Ans¨ atzen, Methoden und Verfahren anzustellen. Vor diesem Hintergrund hat das Fachgebiet Echtzeitsysteme noch einen deutlichen Nachholbedarf. Paradigmatische Beispiele haben sich trotz einer Reihe von Bem¨ uhungen noch nicht in aller Breite bei den Wissenschaftlern dieses Fachgebietes etablieren k¨ onnen. Dennoch sind besonders im Rahmen der Lehre Beispiele gefragt, die abstrakte Inhalte in einer konkreten Anwendung widerspiegeln. Als einleitender Versuch hierzu kann man das paradigmatische Beispiel der Wippe (siehe Seite 8) nennen. Es ist in eine Klasse von BalancierBeispielen einzuordnen, die im Fachgebiet der Regelungstechnik unter dem ¨ Namen ball on a beam bekannt geworden sind. Uber seine Musterhaftigkeit f¨ ur das Fachgebiet der Regelungstechnik hinaus (siehe Beispiel 1.3.2) hat die Wippe bereits dazu gedient, die Struktur des Grundmodells eines Echtzeitsystems zu verdeutlichen (siehe Beispiel 1.2.1), die Betriebsformen eines eingebetteten Systems mittels eines Anwendungsfalldiagramms darzustellen (siehe Beispiel 1.2.2) und den Fluss von Daten zwischen funktionalen Einheiten zu beschreiben (siehe Beispiel 1.3.1). Demgem¨aß liegen den paradigmatischen Beispielen auch immer inhaltliche Schwerpunkte zugrunde, die im Kontext des Fachgebietes besonders betont werden sollen. Dies gilt ebenso f¨ ur die Liste der im Folgenden zitierten Beispiele, von denen einzelne sp¨ater noch aufgegriffen werden: F¨ ullstandsregelung: Minimale Anwendung, an der die Systematik zur Ableitung und Einhaltung von Zeitbedingungen z.B. entsprechend der Formel P (r + ∆e ≤ d | B) = 1 demonstriert werden soll (vgl. [43] und [145]). Abstandsregelung: Ausschnitt aus einer automotiven Aufgabenstellung, die sowohl die softwaretechnische Konzeption als auch die systematische Einbettung in einen technischen Kontext betont (vgl. [50], [5] und [41]). Produktionszelle: Ausschnitt aus einer Automatisierungsaufgabe, die sowohl den Transport als auch die Verarbeitung von Werkst¨ ucken betrachtet und auf die Koordination nebenl¨ aufiger Aufgaben abzielt (vgl. [89], [39] und [28]). Bahnschranke: Kausale und zeitliche Modellierung nebenl¨aufiger Prozesse mit dem Ziel, bestimmte Sicherheitseigenschaften formal zu verifizieren (vgl. [4], [59] und [94]), so beispielsweise die Betriebsbedingung B f¨ ur die Bahnschranke explizit zu spezifizieren. 1.5.2 Großtechnische Anwendungen

Das Fachgebiet Echtzeitsysteme hat seinen Anfang in großtechnischen Anwendungen genommen (vgl. [54] aus dem Jahre 1993): Die Echtzeitverarbeitung spielte bisher vor allem in der Automatisierungstechnik eine Rolle.

30

1. Einf¨ uhrung

Vorrangig sind in diesem Zusammenhang Automatisierungsaufgaben im Bereich der Produktions- und Kraftwerkstechnik zu nennen. Sie zeichnen sich durch komplexe Zusammenh¨ ange aus. So bestehen sie aus einer Vielzahl von lokalen Teilaufgaben, die zun¨ achst f¨ ur sich zu l¨osen sind. Dar¨ uber hinaus existieren u bergreifende Gesamtaufgaben, die mit Hilfe von Rechnernetzen kom¨ muniziert und gel¨ ost werden m¨ ussen. Die nachfolgend beschriebene Steuerung einer Papiermaschine steht stellvertretend f¨ ur diese Klasse von Aufgaben. 1.5.1

Beispiel 1.5.1 Eine Papiermaschine stellt mit ihrer Ausdehnung von u ¨ber 100m und ihrem komplexen Aufbau eine großtechnische Anwendung dar. Das Papier entsteht nach einer Folge von deutlich gegeneinander abgrenzbaren Arbeitsvorg¨ angen, deren Wirkung in nachgeordneten Messstellen erfasst wird (siehe Abb. 1.13).











Abb. 1.13. Schema einer Papiermaschine mit den Messtellen M1 bis M4 zwischen den

einzelnen Arbeitsvorg¨ angen Stoffauflauf (SA), Vortrocknung (VT), Leimpresse (LP), Nachtrocknung (NT) und Aufrollen (AR)

Ein Graph, dessen gerichtete Kanten f¨ ur die Beeinflussung von Vorg¨angen stehen, dient als abstrakte Darstellung der Wirkzusammenh¨ange im technischen Prozess (siehe Abb. 1.14). Daran wird sowohl die zeitliche Reihenfolge der Arbeitsvorg¨ ange f¨ ur die Papierherstellung deutlich als auch deren kausalen Abh¨ angigkeiten.







 







Abb. 1.14. Wirkzusammenh¨ ange im technischen Prozess (Abk¨ urzungen entsprechend

Abb. 1.13).

Um den gesamten Produktionsprozess zu regeln, geh¨ort zu jedem Arbeitsvorgang ein entsprechender Rechenprozess. Aber erst mit Hilfe von Rechenprozessen, die die Messwerte aufnehmen, bewerten und die Arbeitsvorg¨ange beeinflussen, l¨ asst sich eine hochwertige Papierqualit¨at erreichen (siehe Abb. 1.15). Auf diese Weise ergeben sich eine Reihe von lokalen Systemen, die den Aufbau entsprechend dem Grundmodell eines Echtzeitsystems besitzen.

1.5

Echtzeitsysteme in der Praxis




31





































Abb. 1.15. Technische- und assoziierte Rechenprozesse (entsprechend mit Px“

”

bezeichnet) der Papiermaschine.

Dabei m¨ ussen die Topologien zwischen dem externen und internen System nicht notwendigerweise symmetrisch sein. Es ist lediglich insoweit eine Zusammenarbeit der Rechensysteme zu fordern, dass die technischen Abh¨ angigkeiten erfasst und beherrscht werden k¨onnen. Bei der bisherigen Struktur der nachgeordneten Messstellen kann man nur auf erkennbare Abweichungen im Nachhinein reagieren. Stattdessen sollte es auch m¨oglich sein, beispielsweise auf einen erh¨ ohten Feuchtigkeitswert bei der Vortrocknung so zu reagieren, dass die Nachtrocknung verst¨ arkt wird, wenn der betroffene Papierstreifen diesen Arbeitsvorgang erreicht. Als eine m¨ogliche L¨osung sei ein uhrt, der aufgrund markanter Messeru ¨bergeordneter Leitprozess PM eingef¨ gebnisse in die Arbeitsvorg¨ ange eingreift (siehe Abb. 1.16).


























Abb. 1.16. Rechenprozesse der Papiermaschine mit u ¨bergeordnetem Leitprozess PM .

Damit der Leitprozess PM seine Aufgabe erf¨ ullen kann, muss er mit den r¨ aumlich entfernten Prozessen, die f¨ ur die einzelnen Arbeitsvorg¨ange zust¨ andig sind, u ¨ber ein Rechnernetz kommunizieren. Ein solches Rechnernetz unterliegt der Auflage, die Nachrichten, die zwischen den Prozessen auszutauschen sind, rechtzeitig bereitzustellen. Die schon erw¨ahnten Konzepte der Datenreduktion und Datenexpansion kommen hier wieder zur Anwendung und dienen dem Ziel, die Menge der Daten, die u ¨ber das Rechnernetz ausgetauscht werden, auf geeignete Kenngr¨ oßen zu reduzieren.

32

1. Einf¨ uhrung

Der Leitprozess ist typischerweise nicht nur zum technischen Prozess hin in ein Rechennetz eingebunden. Auch die Verantwortlichen in der Produktionsleitung haben ein Interesse, geeignete Kenngr¨oßen u ¨ber den laufenden Produktionsprozess abgreifen zu k¨ onnen. Daneben ist der Produktionprozess im Rahmen der Qualit¨ atssicherung zu dokumentieren. Die hierf¨ ur notwendigen Rechnernetze haben zwar auch entsprechende Leistungsmerkmale zu erf¨ ullen, unterliegen jedoch nicht denselben Forderungen nach Rechtzeitigkeit wie die Rechnernetze im Produktionsprozess. Somit zeichnet sich das Bild eines komplexen Geflechts von Aufgaben, die mit Hilfe von Rechnernetzen zu bew¨ altigen sind und unterschiedlich strenge Forderungen nach Rechtzeitigkeit stellen.
Die Modellbildung auf der Grundlage von technischen Prozessen und Rechenprozessen ist allein von der Aufgabenstellung her bestimmt. Dabei l¨asst sich die Topologie des technischen Systems dadurch repr¨asentieren, dass die r¨ aumliche Entfernung als Kriterium herangezogen wird, um Prozesse gegeneinander abzugrenzen (vgl. [19]). Der gesamte Datenfluss kann bei dieser Modellbildung bereits ber¨ ucksichtigt werden. Dazu ist festzustellen, bei welchen technischen Prozessen wann und in welchen Mengen Messwerte anfallen und bei welchen technischen Prozessen unter Einhaltung von Zeitbedingungen entsprechende Stellwerte eintreffen m¨ ussen. F¨ ur die Einhaltung der Zeitbedingungen sind die Rechenprozesse verantwortlich, die zwischen der Aufnahme von Messwerten und der Ausgabe von Stellwerten liegen. Daran beteiligt sind eine Reihe von Prozessen und Nachrichten¨ ubertragungen. Die zeitliche Verz¨ ogerung, mit der ein solches Echtzeitsystem reagiert, wird auch als Ende-zu-Ende-Antwortzeit (engl. end-to-end response) bezeichnet. Gerade die Produktionsautomatisierung, wie sie in Beispiel 2.2.1 anhand der Papiermaschine verdeutlicht wurde, besitzt eine Reihe charakteristischer Eigenschaften, die wiederum Auswirkungen auf die Forderungen nach Rechtzeitigkeit haben. Sie ist chargenorientiert: Automatisierungsanlagen sind immer wieder umzur¨ usten und an die Eigenschaften der zu produzierenden Charge anzupassen. So ist die Laufgeschwindigkeit einer Papiermaschine unmittelbar abh¨ angig von der Art des Papiers, das produziert wird. Mittelbar damit verbunden sind spezifische Zeitbedingungen, die innerhalb des Produktionsprozesses einzuhalten sind. konfigurationsorientiert: Automatisierungsanlagen m¨ ussen einzelne Werkst¨ ucke mit unterschiedlichen Konfigurationen bearbeiten k¨onnen.

1.5

Echtzeitsysteme in der Praxis

33

Als Beispiel kann das Werkst¨ uck Kraftfahrzeug gelten, das aufgrund der Vielfalt von Sonderausstattungen eine hohe Variabilit¨at besitzt. Zeitlich ist der Produktionsprozess deshalb so auszulegen, dass von einzelnen Best¨ uckungsvorg¨ angen keine unkalkulierbaren Verz¨ogerungen ausgehen. produktlinienorientiert: Die Komponenten einer Produktionsanlage, die f¨ ur einzelne Arbeitsvorg¨ ange zust¨ andig sind, m¨ ussen flexibel sein. Typischerweise sind die Komponenten einer st¨andigen Pflege, Versionierung und Spezialisierung unterworfen. Bezogen auf den Neubau von Produktionsanlagen sowie deren Ausr¨ ustung mit neueren Versionen von Komponenten muss klar sein, welche Echtzeiteigenschaften von einer Komponente f¨ ur die gesamte Produktionsanlage ausgehen. 1.5.3 Automotive Anwendungen

W¨ ahrend also fr¨ uher vorwiegend großtechnische Anlagen und damit Investitionsg¨ uter den Anwendungsschwerpunkt f¨ ur Echtzeitsysteme bildeten, wurden in den letzten beiden Jahrzehnten zunehmend Konsumg¨ uter mit rechnergest¨ utzten Systemen ausger¨ ustet, bei denen Rechtzeitigkeit eine herausragende Rolle spielt. Damit verbunden ist eine deutliche Verschiebung von Merkmalen, die die Entwicklung und Ausr¨ ustung der eingebettenen Echtzeitsysteme betreffen. Wurden fr¨ uher dedizierte Exemplare von Echtzeitsystemen entwickelt, so geht es heute immer st¨ arker um Massenprodukte. In diesem Zusammenhang spielen die Kosten f¨ ur die Entwicklung, die Serieneinf¨ uhrung, die Produktion und die Wartung eine fundamentale Rolle. Dies gilt auch f¨ ur den wirtschaftlich bedeutenden Bereich der Transportfahrzeuge, so unter anderem f¨ ur Flugzeuge, Schienenfahrzeuge, Schiffe und, in besonderem Maße, f¨ ur Kraftfahrzeuge.

  







  





  

 

  

Abb. 1.17. Blockdiagramm eines

Steuerger¨ ates, wie es an vielen Stellen in Kraftfahrzeugen verbaut wird.

Der letztgenannte Bereich der Kraftfahrzeuge, auch mit dem Begriff automotiver Bereich belegt, hat in den letzten Jahren herausragend zur Weiterentwicklung von Ans¨ atzen, Methoden und Verfahren im Fachgebiet Echtzeitsysteme beigetragen. So werden in Personenwagen mittlerweile zwischen 30

34

1. Einf¨ uhrung

und 100 Rechensysteme, genannt Steuerger¨ate (engl. elektronic control unit oder ECU), verbaut (schematischer Aufbau eines Steuerger¨ates in Abb. 1.17). Diese sind untereinander durch Rechnernetze verbunden und bilden ein komplexes verteiltes System. Eine Vielzahl von Aufgaben sind im Kraftfahrzeug zu l¨ osen. Typischerweise werden diese aufgrund der Anforderungsstruktur gegliedert in: Antrieb und Fahrwerk Karosserie und Komfort Telematik Diagnose und Wartung Dieser Anforderungsstruktur entspechend baut sich das verteilte System auf, das dedizierte Steuerger¨ ate zu Gruppen zusammenfasst und jeweils mittels eines Busses untereinander verbindet. 1.5.2

Beispiel 1.5.2 Nachfolgend wird ein Ausschnitt aus einem verteilten System

von Steuerger¨ aten wiedergegeben, wie es heute in Personenwagen verbaut ist. Typisch ist ein zentrales Steuerger¨at, das als Grundmodul bezeichnet wird. Es hat unter anderem die Aufgabe, die Schnittstelle zwischen unterschiedlichen Bussystemen zu bilden, die vom Grundmodul aus sternf¨ormig angeordnet sind. Des Weiteren ist in unmittelbarer N¨ahe zum Grundmodul das Diagnosemodul angesiedelt. Es verbindet mittelbar, d.h. u ¨ber entsprechende Schnittstellen, unterschiedliche Busse, die entsprechend der Anforderungsstruktur Gruppen von Steuerger¨ aten unmittelbar miteinander verbinden.


  

 



  

 
 


 

   


  


     
  
  

 
 







 


  
 

Abb. 1.18. Die Steuerger¨ ate, die u ¨ber unterschiedliche Rechnernetze verbunden sind,

bilden ein komplexes verteiltes System.

1.5

Echtzeitsysteme in der Praxis

35

Dementsprechend ist ein eigener Bus f¨ ur Antrieb und Fahrwerk zust¨andig. Die Bewegungsdaten, die ein Drehratengeber f¨ ur jedes Rad aufnimmt, werden u ¨ber diesen Bus an das Grund-Modul weitergegeben und dort zur Feststel¨ lung der Geschwindigkeit des Fahrzeugs herangezogen. Uber einen anderen Bus wird diese Kenngr¨ oße dann an das Steuerger¨at der Armaturentafel weitergegeben und dem Fahrer angezeigt. Die Bewegungsdaten der einzelnen R¨ ader sind jedoch auch f¨ ur die beiden Assistenzsysteme Antiblockiersystem (ABS) und Abstandsregelung (ACC) von Bedeutung. Ein anderer Bus bedient den Karosserie- und Komfortbereich. Unter anderem wird jede einzelne T¨ ur u ¨berwacht und auf dem Weg u ¨ber das Grundmodul auf der Armaturentafel angezeigt. Das Lenks¨ aulenmodul, ebenfalls Bestandteil des Karosserie- und Komfortbereiches, kann Funktionen im Telematikbereich veranlassen, beispielsweise u ¨ber einen Schalter am Lenkrad die Sendersuche im Digitalradio initiieren. Der Telematikbereich verf¨ ugt ebenfalls u ¨ber einen eigenen Bus. Dieser muss in der Lage sein, große Datenmengen, die kontinuierlich anfallen, zu transportieren. Demgegen¨ uber sind die Anforderungen f¨ ur die u ¨brigen Busse derart, dass vergleichsweise kleine Datenmengen, die periodisch oder sporadisch anfallen, m¨ oglichst ohne Verz¨ ogerung u
¨bertragen werden. 1.5.4 Multimedia und Telematik

Der Bereich multimedialer Anwendungen im Kraftfahrzeug ist mit dem Begriff Telematik belegt. Daf¨ ur ist ein eigenes Bussystem notwendig, das Anwendungen wie Mobiltelefon, Navigationssystem, Radio und andere Unterhaltungs- und Informationsdienste miteinander verbindet. Nach außen, aus dem Fahrzeug heraus, sind drahtlose Telekommunikationsdienste erforderlich. Basierend auf dieser Infrastruktur sind viele neuartige Anwendun¨ gen denkbar. Sie reichen von der Ubermittlung zentral gesammelter Verkehrsinformationen bis hin zu dezentralen Netzwerken, die sich unter den Fahrzeugen, die eine gewisse r¨ aumliche N¨ ahe zueinander haben, spontan bilden. Solche so genannten car2car-Netzwerke oder auch VANETs3 lassen sich f¨ ur vielseitige Anwendungen, wie z.B. das kraftstoffsparende Kolonnenfahren (auch platooning genannt) oder (vgl. [55]) die Warnung vor Hindernissen auf un¨ ubersichtlichen Fahrstrecken einsetzen (vgl. [77]). Netzwerke, ob drahtgebunden oder drahtlos, f¨ ur den Telematikbereich oder allgemeiner f¨ ur den Bereich multimedialer Anforderungen, sind oftmals dadurch gekennzeichnet, dass sie die Infrastruktur von Anwendungen mit harten oder weichen Zeitbedingungen bilden. Dabei ist diese Infrastruktur weder konzeptionell noch von ihrer Realisierung auf die Einhaltung von Zeitbedin3

Vehicle Ad hoc NETworks

36

1. Einf¨ uhrung

gungen hin ausgelegt ist. Als ein Beispiel f¨ ur einen solchen Fall kann das Telefonieren u ¨ber Internet gelten. 1.5.3

Beispiel 1.5.3 Nicht zuletzt aus Kostengr¨ unden besteht eine enorme Nach-

frage danach, Telefongespr¨ ache u uhren (engl. voice ¨ber das Internet zu f¨ ¨ over IP oder VoIP). Bei analoger Ubertragungstechnik ist ein kontinuierlicher Strom elektrischer Signale erforderlich, der das Schalten zweier physischer Leitungen zwischen den beiden Endknoten der Verbindung erfor¨ dert. Verschiedene Gr¨ unde, wie das Ubersprechen oder der Verschwendung ¨ von Ubertragungskapazit¨ at, haben l¨ angst eine Digitalisierung auf Teilstrecken der Verbindung bewirkt. Damit einher geht die Aufgabe, mit diskre¨ ter Ubertragungstechnik einen quasi-kontinuierlichen Strom von Nachrichten (engl. streaming) zu realisieren. Dies gilt auch f¨ ur das Telefonieren u ¨ber Internet. Das Internet, genauer das IP-Protokoll, stellt eine Infrastruktur f¨ ur die ¨ Ubertragung von Nachrichtenpaketen bereit. Es legt die Paketgr¨oße fest und ¨ bestimmt eine Reihe von Merkmalen, was die Ubertragung von Nachrichten angeht. So ist zu beachten, dass einzelne Nachrichten gegebenenfalls sehr unterschiedliche Wege durch das Netz nehmen, unterschiedlich lan¨ ge Ubertragungszeiten besitzen und manchmal sogar verloren gehen. Entsprechend ist eine dedizierte Architektur (siehe Abb. 1.19) f¨ ur die Endknoten der Verbindung vorzusehen. Grob besteht sie f¨ ur jede der beiden ¨ Ubertragungsrichtungen aus (vgl. [110]) einer Sendekomponente, bestehend aus einer Abtasteinrichtung, die das analoge Signal digitalisiert, sowie je eines Verfahrens zur Kompression und Formatierung in Nachrichtenpakete, und einer Empfangskomponente, bestehend aus einem Puffer und Einrichtungen zur Dekompression und analogen Wiedergabe der digitalen Signale.


 

 

 

  




 

 









 



  



Abb. 1.19. Architektur der Sende- und Empfangskomponente beim Telefonieren u ¨ber

Internet.

Der Puffer in der Empfangskomponente ist von entscheidender Bedeutung f¨ ur das Telefonieren im Internet. Hier sind die Pakete wieder in die Reihen-

1.5

Echtzeitsysteme in der Praxis

37

folge zu bringen, wie sie abgeschickt wurden, bevor sie dann dekomprimiert und wiedergegeben werden. Die Pakete, die wieder in eine Reihenfolge zu ¨ bringen sind, haben eine unterschiedliche Ubertragungszeit im Internet hinter sich. Man spricht hier auch von der Verz¨ogerungsabweichung oder dem Flattern (engl. jitter). Typischerweise unterliegt die Verz¨ogerung durch die ¨ Ubertragung einer stochastischen Verteilung (siehe Abb. 1.20). Das Weiterreichen der Pakete aus dem Puffer soll wieder ganz ohne Flattern erfolgen, um den Sprachfluss durch die Wiedergabe zu erhalten. Damit ergibt sich f¨ ur den Puffer eine Wechselwirkung zwischen der akzeptierten Verz¨ogerung von Paketen und der Wahrscheinlichkeit, einzelne Pakete, die zu sp¨at kommen, nicht zu ber¨ ucksichtigen. Entsprechend f¨ uhrt eine Verk¨ urzung der Verz¨ogerungen dazu, dass mehrere Pakete nicht wiedergegeben werden. Will man fast alle Pakete wiedergeben, muss man eine deutlich erh¨ohte Verz¨ogerung akzeptieren. 
 
  


  




   


 

  

     

¨ Abb. 1.20. Wahrscheinlichkeitsverteilung f¨ ur die Ubertragungszeit M SG eines Paketes u ¨ber das Internet. Pakete, deren M SG eine bestimmte Zeit u ¨berschreiten, werden nicht mehr f¨ ur die Wiedergabe ber¨ ucksichtigt.

Die Internationale Fernmeldeunion (International Telecommunication Union oder ITU) gibt vor, dass die Verz¨ogerung weltweit in eine ¨ Ubertragungsrichtung nicht mehr als 150ms betragen soll. Dies stellt eine ¨ harte Anforderung dar, wenn man bedenkt, dass eine Ubertragung u ¨ber den halben Erdball, d.h. auf einer L¨ ange von 20000km bereits mit mindestens 67ms zu veranschlagen ist. Rechnet man alle Zeitspannen f¨ ur die Verarbeitungsschritte in der Sende- und Empfangskomponente hinzu, die sich auf etwa 10ms belaufen, so bleiben f¨ ur das Weiterleiten von Paketen auf den Knotenrechnern des Internets, f¨ ur Wege, die aufgrund der gew¨ahlten Route l¨anger als 20000km sind, und f¨ ur die Reihung der Pakete im Puffer der Empfangskomponente nur rund 70ms. Entsprechend der Wahrscheinlichkeitsverteilung ¨ f¨ ur die Ubertragungszeit von einem Endknoten zum anderen ergibt sich die ¨ Verlustrate l der Pakete, die aufgrund ihrer Ubertragungszeit M SG nicht

38

1. Einf¨ uhrung

wiedergegeben werden als: l = P (M SG > 70ms) Eine obere Schranke f¨ ur die Verlustrate l, die unter keinen Umst¨anden u berschritten werden sollte, liegt beim Telefonieren u ¨ ¨ber Internet bei 10% (vgl. [82])
Die ausf¨ uhrlichen Beispiele 2.2.1 bis 2.2.4 spiegeln eine kleine Auswahl von Anwendungen wider, bei denen harte oder weniger harte Zeitbedingungen zu erf¨ ullen sind. Dar¨ uber hinaus sind Fragestellungen, bei denen Rechtzeitigkeit, Sicherheit und Zuverl¨ assigkeit gefordert sind, in einer großen Zahl und enormen Vielfalt bei Investitionsg¨ utern und immer mehr auch bei Konsumg¨ utern zu finden.

1.6

Konventionen und Notationen

39

1.6 Konventionen und Notationen Wie schon in Unterabschnitt 1.4.3 angedeutet, kann Echtzeit als kontinuierliche und als diskrete Gr¨ oße aufgefasst werden. Hier wird die diskrete Modellierung der Echtzeit mit der kontinuierlichen erkl¨art. Dabei wird zun¨achst mit Zeitpunkten t ∈ R wie mit reelen Zahlen gerechnet. Die Differenz zweier Zeitpunkte t1 und t2 wird als Zeitspanne bezeichnet: ∆t12 = t2 − t1 . Ein Zeitintervall [t1 , t2 ) umfasst alle Zeitpunkte t mit t1 ≤ t < t2 . An verschiedenen Stellen werden Intervalle [∆t1 , ∆t2 ) mit Zeitspannen als Argumente verwendet. Gemeint sind dann jedoch Zeitpunkte der Art [0 + ∆t1 , 0 + ∆t2 ), was der Definition der Intervalle entspricht. ¨ F¨ ur den Ubergang zu diskreten Zeitpunkten gibt es die Flurfunktion   und die Deckenfunktion  . F¨ ur ein 0 ≤ t gilt: t = n ∈ N0

mit n ≤ t < n + 1

Des Weiteren ist 0 = 0 und f¨ ur 0 < t gilt: t = n ∈ N0

mit n − 1 < t ≤ n

Zur Bewertung des Aufwands von Planungsverfahren wird allgemein die ONotation verwendet. Zu diesem Zweck wird zun¨achst eine Funktion g : N → R+ eingesetzt, um die notwendigen Elementarschritte, die das Verfahren ben¨ otigt, zu beschreiben. Das Argument dient zur Bestimmung der Gr¨oße der Eingabemenge, im Folgenden oftmals die Anzahl n der Prozesse. Will man Verfahren miteinander vergleichen, dann gen¨ ugt es, gr¨obere Maßst¨ abe anzulegen und Klassen von Verfahren mit gleichem Aufwand zu bilden. Dazu dient eine generalisierende Funktion f : N → R+ , mit der eine Menge von Funktionen g nach oben abgesch¨ atzt werden kann: O(f ) = {g : N → R+ | ∃c∈R+ : ∃n0 ∈N : ∀n≥n0 : g(n) ≤ c f (n)} So geh¨ ort beispielsweise die Aufwandsfunktion g(n) = 4n2 −20n+12 zur Klasse O(n2 ) der Verfahren mit quadratischem Aufwand. Mehr zur O-Notation und den so genannten Landauschen Symbolen findet sich in [64].

1.6

Kapitel 2 Methodische und technische Grundlagen

2

2

2 2.1 2.1.1 2.1.2 2.1.3 2.1.4 2.1.5 2.1.6 2.2 2.2.1 2.2.2 2.2.3 2.2.4 2.2.5 2.3 2.3.1 2.3.2 2.4 2.4.1 2.4.2 2.4.3 2.4.4 2.4.5 2.5 2.5.1 2.5.2 2.5.3 2.5.4

Methodische und technische Grundlagen ¨ Uberblick u ¨ber die Echtzeitplanung .......................... Prozessmodelle ................................................... Prozessparameter ................................................ Periodische Prozesse ............................................ Der Plan ........................................................... Verfahren der Echtzeitplanung ................................ Kategorisierung der Verfahren zur Echtzeitplanung ....... Zeiten und Uhren ................................................ Betrachtungen zur Zeit ......................................... Die physikalische Zeit ........................................... Die Erfassung der Zeit .......................................... Uhrzeit und Weckzeit ........................................... Kalk¨ ule der Zeit .................................................. Bestimmung der Prozessparameter ........................... Absch¨atzung der Ausf¨ uhrungszeit ............................ Ableitung von Zeitbedingungen ............................... Parallelit¨at und Synchronisierung ............................. Parallele Programme und Konsistenz der Daten ........... Elementare Synchronisierungsoperationen .................. H¨ ohere Synchronisierungsoperationen ....................... Parallelit¨at bei Mehrprozessorsystemen ...................... Migration von Prozessen bei Mehrprozessorsystemen..... Verteilte Echtzeitsysteme....................................... Anforderungen an verteilte Echtzeitsysteme ................ Aufbauprinzipen von Rechnernetzen ......................... Zugriffsprotokolle ................................................ Modellbildung bei verteilten Echtzeitsystemen .............

43 43 46 48 50 51 54 60 60 61 68 76 85 93 93 104 117 117 120 124 127 130 133 133 136 140 151

2 Methodische und technische Grundlagen Zweck diese Kapitels ist es, die formalen und technischen Voraussetzungen zu schaffen, damit in den nachfolgenden Kapiteln die Konzepte und Verfahren der Planung bei Echtzeitsystemen in konsistenter und einleuchtender Weise dargestellt werden k¨ onnen. Dazu geht es zun¨achst um Begrifflichkeiten, Notationen und Abl¨ aufe, die mit dem Planen verbunden sind (siehe Abschnitt 2.1). Im Anschluss daran erfolgt eine umfangreiche Besch¨aftigung mit der Zeit und ihrer Erfassung, zun¨ achst aus der Sicht der Physik, dann aus verschieden Sichten, die die Informatik hat (siehe Abschnitt 2.2). Der nachfolgende Abschnitt befasst sich mit zwei f¨ ur die Planung wichigen Prozessparametern: der Ausf¨ uhrungszeit und der Frist (siehe Abschnitt 2.3). Aufbauend auf dem Prozessbegriff wird die Parallelausf¨ uhrung von Prozessen und in der Folge die Notwendigkeit der Beschr¨ ankung der Parallelit¨at thematisiert (siehe Abschnitt 2.4). Schließlich werden vernetzte Rechensysteme betrachtet, die mittels Nachrichten miteinander kommunizieren (siehe Abschnitt 2.5).

¨ 2.1 Uberblick u ¨ber die Echtzeitplanung Die Echtzeitplanung benutzt das bereits fr¨ uher erw¨ahnte Abstraktionsobjekt des Prozesses (siehe Abschnitt 1.3), das hier mit seinen Wesensmerkmalen (siehe Unterabschnitt 2.1.1) und seinen beschreibenden Parametern (siehe Unterabschnitt 2.1.2) eingef¨ uhrt wird. Echtzeitsysteme sind vielfach durch wiederkehrende Aufgabenstellungen gekennzeichnet (siehe Unterabschnitt 2.1.3). Es folgen die formale Definition f¨ ur Pl¨ane (siehe Unterabschnitt 2.1.4) und die Beschreibung der notwendigen Abl¨aufe bei der Anwendung von Planungsverfahren (siehe Unterabschnitt 2.1.5). Abgeschlossen wird dieser Abschnitt mit einer Gegen¨ uberstellung unterschiedlicher Ans¨atze zur Echteitplanung (siehe 2.1.6). 2.1.1 Prozessmodelle

Im Mittelpunkt der Betrachtung stehen Rechensysteme, die u ¨ber eine Ausf¨ uhrungsinstanz verf¨ ugen: Einprozessorsysteme. Nur ein Prozess kann zu einem Zeitpunkt auf einem Prozessor ausgef¨ uhrt werden. Der Prozessor ist ein exklusives Betriebsmittel, um das die Prozesse untereinander konkurrieren. Jeder Prozess ist sequenziell auf dem Prozessor auszuf¨ uhren und endet nach endlich vielen Berechnungsschritten. Man spricht von endlicher Prozessausf¨ uhrung. Unter Echtzeitplanung (engl. real-time scheduling) versteht man unter diesen Voraussetzungen die Aufgabe, den Prozessen den Prozes-

2.1

44

2. Methodische und technische Grundlagen

sor so zuzuteilen, dass die von der Anwendung herr¨ uhrenden Zeitbedingungen w¨ ahrend jeder Prozessausf¨ uhrung eingehalten werden. Abh¨ angig von der Anwendung ist zwischen Prozessen zu unterscheiden, deren Ausf¨ uhrung vom Start und bis zum Ende nicht unterbrochen werden kann (engl. non preemptive), deren Ausf¨ uhrung – es sei denn, es sind weitergehende Einschr¨ankungen zu beachten – nach jeder Anweisung unterbrochen werden kann (engl. preemptive). Bei einer Prozessumschaltung (engl. context switch) wird der Prozessor an einen anderen Prozess vergeben. Bei nicht unterbrechbaren Prozessen findet eine Prozessumschaltung beim Start und beim Ende einer Prozessausf¨ uhrung statt. Andererseits ist bei unterbrechbaren Prozessen grunds¨atzlich, wann immer der Prozessor es zul¨ asst, eine Prozessumschaltung m¨oglich. Eine vielfach im Zusammenhang mit Echtzeitsystemen angewandte Regel ist die, bei der Vergabe des Prozessors strikt die einem Prozess zugeordnete Priorit¨ at als Entscheidungskriterium zugrunde zu legen. Man spricht hier auch von priorit¨ atsbasierter Prozessumschaltung oder priorit¨atsbasierter Prozessausf¨ uhrung. Der Vorgang wird auch als Verdr¨angung (engl. suspension) eines Prozesse durch einen anderen bezeichnet. Grunds¨ atzlich kann ein Prozess jederzeit starten. Man spricht von einem periodischen Prozess, falls es ein wiederkehrendes Zeitfenster gibt, in dem die Ausf¨ uhrung eines Prozesses stattfinden muss. Andernfalls heißt der Prozess aperiodisch. Diese Prozesse k¨ onnen jederzeit starten und sind unter den Gesichtspunkten Vorhersagbarkeit und Rechtzeitigkeit ungeeignet. Von den aperiodischen Prozessen finden im Bereich der Echtzeit lediglich diejenigen Prozesse Beachtung, f¨ ur die gilt, dass zwischen zwei aufeinanderfolgenden Starts eine Mindestzeit vergangen sein muss. Dies ist die Eigenschaft von sporadischen Prozessen.


  







  


Abb. 2.1. Mengenbeziehungen der periodischen, aperiodischen und sporadischen Prozesse

Eine weitere Verfeinerung des Prozessbegriffes wird notwendig, wenn man mit Prozessen Aufgaben identifiziert, die sich zeitlich und ¨ortlich mehrfach stellen (vgl. [146]):

2.1

¨ Uberblick u ¨ber die Echtzeitplanung

45

Prozesstyp: Pprog Darunter ist die in Form eines Programms beschriebene Aufgabe prog des Prozesses zu verstehen. Beispiel: Abfragen eines Temperaturf¨ uhlers und Weiterreichen des kalibrierten Wertes f¨ ur eine graphische Ausgabe. Das Prozessobjekt: Pprog,i Ein Prozesstyp kann mehrfach Anwendung finden. Jede Instanz verf¨ ugt u ¨ber einen eigenen Zustandsraum und damit verbunden u ¨ber eigene Variablen1 und eine anwendungsspezifische Einbettung. Beispiel: Gibt es mehrere Temperaturf¨ uhler, dann verarbeitet Prozessobuhlers i. jekt Pprog,i des Prozesstyps Pprog die Werte des Temperaturf¨ j Die j-te Ausf¨ uhrung eines Prozessobjektes: Pprog,i Ein Prozessobjekt Pprog,i kann nach seinem Ende erneut gestartet werur periodische Prozesse. den.2 Das gilt insbesondere f¨ Beispiel: Typischerweise wird ein Temperaturf¨ uhler i jeweils nach einem festgelegten Zeitintervall abgefragt. Im j-ten Zeitintervall erfolgt die Ausj . f¨ uhrung Pprog,i j ben¨ otigt Zeit. Diese kann im Einzelnen sehr Die Prozessausf¨ uhrung Pprog,i unterschiedlich sein und abh¨ angen von der Effizienz des Programms des Prozesstyps Pprog , von den Instanzvariablen des i-ten Prozessobjektes, von den spezifischen Eingabe- und Ausgabedaten, die in die j-te Ausf¨ uhrung eingehen, von der Leistungsf¨ ahigkeit des Prozessors, vom Rechensystem, das den Prozessor umgibt, von Verz¨ ogerungen, die sich durch die Konkurrenz mit anderen Prozessausf¨ uhrungen auf demselben Prozessor ergeben und 1

Programmiertechnisch ist an dieser Stelle zwischen schwergewichtigen Prozessen und leichtgewichtigen Prozessen zu unterscheiden. Schwergewichtige Prozesse verf¨ ugen u ¨ber einen eigenen Adressraum und damit automatisch u ¨ber Variablen, auf die nur sie Zugriff haben. Demgegen¨ uber teilen sich leichtgewichtige Prozesse (engl. thread) einen gemeinsamen Adressraum. Erst durch eine entsprechende Beschr¨ ankung des Zugriffs auf Variablen wird erreicht, dass auch leichtgewichtige Prozesse einen eigenen Zustandsraum besitzen. 2 In der englischsprachigen Fachliteratur werden in diesem Zusammenhang die Begriffe task und job verwendet. Dabei gibt es jedoch keine Einheitlichkeit im Gebrauch. So wird einerseits task f¨ ur Prozesstyp und job f¨ ur Prozessobjekt (vgl. [92]) und andererseits task f¨ ur Prozessobjekt und job f¨ ur Prozessausf¨ uhrung verwendet (vgl. [26]).

46

2. Methodische und technische Grundlagen

von der Verf¨ ugbarkeit der f¨ ur die Ausf¨ uhrung notwendigen Betriebsmittel, die konkurrierend auch von anderen Prozessobjekten beansprucht werden k¨ onnen. Echtzeitplanung besch¨ aftigt sich damit, diese Einflussgr¨oßen systematisch zu parametrisieren und Vorhersagen u uhrungen zu ¨ber die Prozessausf¨ erm¨ oglichen. Da es im Folgenden meist klar ist, um welchen Prozesstyp prog es sich hanuhrung Pij ohne spedelt, werden das Prozessobjekt Pi und die Prozessausf¨ ziellen Index f¨ ur den Prozesstyp notiert. 2.1.2 Prozessparameter

Einer Prozessausf¨ uhrung Pij werden die folgenden Zeitpunkte bzw. Zeitspannen zugeordnet (im Wesentlichen angelehnt an [62]): Bereitzeit (engl. ready time): rij Dieser Zeitpunkt ist der fr¨ uheste, zu dem die Ausf¨ uhrung Pij auf dem Prozessor beginnen darf. Dies wird auch Aktivierung des Prozessobjektes Pi genannt. Ausf¨ uhrungszeit (engl. execution time): ∆eji Diese Zeitspanne entspricht der reinen Rechenzeit f¨ ur die j-te Ausf¨ uhrung auf dem Prozessor. Unabh¨ angig von der jeweiligen Ausf¨ uhrung bezeichnet angste m¨ ogliche Rechenzeit f¨ ur Prozessobjekt Pi (auch worst case ∆ei die l¨ execution time oder abgek¨ urzt WCET genannt). Frist (engl. deadline): dji Zu diesem Zeitpunkt muss die j-te Ausf¨ uhrung des Prozesses Pi beendet sein. Ordnet man die eingef¨ uhrten Zeitpunkte und bildet den Zeitpunkt des fr¨ uhesten Endes einer Ausf¨ uhrung bzw. des sp¨atesten Anfangs einer Ausf¨ uhrung, so ergibt sich eine Halbordnung (siehe Abb. 2.2). Die eingef¨ uhrten Prozessparameter werden f¨ ur die Echtzeitplanung von periodischen und sporadischen Prozessen ben¨ otigt. Abb. 2.2. Halbordnung zwischen Zeitpunkten, die aus den Prozessparametern Bereitzeit, Ausf¨ uhrungszeit und Frist gebildet sind. Die einer

Kante zugeordnete Ordnungsrelation gilt zwischen den Zeitpunkten, die an den zugeh¨ origen Knoten annotiert sind, und ist in der Art oben ≥ unten zu lesen.

2.1

¨ Uberblick u ¨ber die Echtzeitplanung

47

Weitere Prozessparameter beziehen sich auf Start und Ende der j-ten Ausf¨ uhrung von Pi (siehe dazu Abb. 2.3): Startzeit (engl. starting time): sji Zu diesem Zeitpunkt beginnt der Prozess seine j-te Ausf¨ uhrung durch den Prozessor. Abschlusszeit (engl. completion time): cji Zu diesem Zeitpunkt beendet der Prozess seine j-te Ausf¨ uhrung durch den Prozessor. Ein Prozess wird als rechenbereit bezeichnet, wenn seine Bereitzeit erreicht oder u uhrung noch nicht beendet und damit seine ¨berschritten ist, seine Ausf¨ Abschlusszeit noch nicht erreicht ist. W¨ ahrend die allgemeine Beziehung zwischen Start- und Abschlusszeit durch die Ungleichung sji + ∆eji ≤ cji ausgedr¨ uckt wird (siehe Abb. 2.3), gilt f¨ ur nicht unterbrechbare Prozesse die Beziehung: sji + ∆eji = cji

Abb. 2.3. Halbordnung zwischen Zeitpunkten, die aus den Prozessparametern Bereitzeit, Startzeit, Ausf¨ uhrungszeit,

Abschlusszeit und Frist gebildet sind.

Die Ausf¨ uhrungszeit ∆eji eines unterbrechbaren Prozesses ist u ¨ber das Zeitur unterbrechbare intervall [sji , cji ] verstreut (siehe Abb. 2.4). Gleichermaßen f¨ und nicht unterbrechbare Prozess sind deren (harte Echt-)Zeitbedingungen erf¨ ullt, wenn das Zeitintervall [sji , cji ] Teil des Zeitintervalls [rij , dji ] ist. Als Antwortzeit (engl. response time) oder auch als Reaktionszeit wird bei einem Prozess die Zeitspanne bezeichnet, die zwischen seinem Bereitwerden und dem Abschluss seiner Ausf¨ uhrung vergeht: ∆aji = cji − rij

48

2. Methodische und technische Grundlagen

2.1.3 Periodische Prozesse

F¨ ur periodische Prozesse eignet sich eine leicht modifizierte Beschreibung, denn Bereitzeiten und Fristen werden von der Periode bestimmt. Periode (engl. period): ∆pi Die Zeitspanne ∆pi definiert f¨ ur einen periodischen Prozess den Rahmen j seiner j-ten Ausf¨ uhrung Pi . Ausgehend von seiner ersten Bereitzeit ri1 sind alle folgenden Bereitzeiten festgelegt durch: rij = (j − 1)∆pi + ri1

j≥1

Das Ende einer Periode ist gleichzeitig eine Frist f¨ ur die Prozessausf¨ uhrung (siehe Abb. 2.5). dji = j ∆pi + ri1 =

j≥1

rij+1

Periodische Prozesse spielen bei Echtzeitanwendungen eine bedeutende Rolle. Sie laufen nach dem Muster ab, dass die endliche Prozessausf¨ uhrung beschrieben durch das Prozessobjekt Pi jeweils innerhalb der Zeitspanne ∆pi = periode(i) stattfinden soll. Ein entsprechendes Programmfragment hat folgende Gestalt: P(i):: while(TRUE) { wait_until(t); // Prozesstyp des Prozessobjektes P(i) t=t+periode(i); }

∆
= ∑













Abb. 2.4. Zeitdiagramm einer unterbrochenen Ausf¨ uhrung des Prozesses Pi auf einem

Prozessor.

2.1

¨ Uberblick u ¨ber die Echtzeitplanung

49

j

j+1

Abb. 2.5. Die j-te und (j + 1)-te ununterbrochene Ausf¨ uhrung von Pi und Pi

.

Bei einem periodischen Prozess gibt der Quotient ∆ei /∆pi an, welcher Anteil an der Rechenleistung des Prozessors von diesem Prozess beansprucht wird. Als Auslastung (engl. utilization) wird deshalb die Summe der Anspr¨ uche aller Prozesse i ∈ P bezeichnet: ∆ei U= ∆pi i∈P

Es ist unmittelbar einzusehen, dass ein Prozessor maximal zu 100% ausgelastet sein kann: 0≤U ≤1 Die Bezeichnung periodischer Prozess legt nahe, dass die Abst¨ande zwischen den Prozessausf¨ uhrungen gleichm¨ aßig sind. Das ist jedoch nicht zwingend der Fall. Betrachtet man beispielsweise den Start eines Prozesses, so kann dieser in der Periode j fr¨ uhestens bei rij und in Periode j + 1 sp¨atestens j+1 bei di − ∆ei stattfinden. Zwischen diesen Zeitpunkten liegt eine maximale Zeitspanne von 2 ∆pi − ∆ei . Umgekehrt liegt der kleinste zeitliche Abstand ur die Zeitspanne zwischen zwischen zwei Startzeiten bei ∆ei . Damit gilt f¨ zwei Startzeiten in aufeinander folgenden Perioden: − sji ∈ [∆ei , 2 ∆pi − ∆ei ] sj+1 i Die Schwankungsbreite wird als Flattern (engl. jitter)3 bezeichnet und betr¨ agt im vorliegenden Fall: ∆ji = 2(∆pi − ∆ei ). 3

In der Fachliteratur werden verschiedene Formen und Erscheinungsmuster des Flatterns (vgl. insbesondere [26]) wie release jitter, finishing jitter und execution jitter betrachtet. Von besonderer Bedeutung wird das Flattern im Zusammenhang mit der Ableitung von Zeitbedingungen (siehe Unterabschnitt 2.3.2), mit grundlegenenden Planungsverfahren (siehe Unterabschnitt (siehe Kapitel 3) und mit verteilten Systemen (siehe Abschnitt 4.3).

50

2. Methodische und technische Grundlagen

2.1.4 Der Plan

Die n Prozessobjekte, die auf dem rechentechnischen System ausgef¨ uhrt werden, bilden die Prozessmenge P = {P1 , ..., Pn }, im Weiteren vereinfacht geschrieben als P = {1, ..., n}. F¨ ur eine Menge von Prozessobjekten mit ihren Prozessparametern l¨ asst sich nun definieren, was ein Plan ist und wann er brauchbar ist. 2.1.1

Definition 2.1.1 Ein Plan (engl. schedule) f¨ ur eine Menge P = {1, . . . , n} ist

eine diskrete Abbildung: s : N0 −→ {0} ∪ P Dabei besagt s(j) = i, dass sich der Prozessor w¨ahrend des Intervalls Gj = ur i = 0 [j∆tG , (j + 1) ∆tG ) im Besitz des Prozessobjektes i befindet bzw. f¨ gerade nicht belegt ist.
















































∆  Abb. 2.6. Diagrammdarstellung eines Planes

Die Diagrammdarstellung impliziert, dass jedes Intervall Gj von der L¨ange der Bezugszeitspanne ∆tG mit dem Zeitpunkt seines Beginns indexiert ist. Dies ist unbedingt zu beachten, wenn es um die Veranschaulichung von Fristverletzungen geht. Beispielsweise sei d2 = 7 und c2 = 8. Dies wird durch folgende Abbildung dargestellt:    




























Auf den ersten Blick k¨ onnte die Darstellung auch so gelesen werden, dass Prozess 2 seine Frist 7 einh¨ alt. Die richtige Anwendung der Definition 2.1.1 offenbart jedoch die Fristverletzung. Denn mit s(7) wird dem Prozess 2 auch im Intervall [7 ∆tG , 8 ∆tG ) der Prozessor zugeordnet, obwohl bei d2 = 7 ∆tG die Frist bereits u ¨berschritten ist.

2.1

¨ Uberblick u ¨ber die Echtzeitplanung

51

Definition 2.1.2 Ein Plan s f¨ ur eine Prozessmenge P = {1, . . . , n} heißt brauchbar, falls er alle Zeitbedingungen erf¨ ullt, d.h. bei vorgegebenen Bereitzeiten, Ausf¨ uhrungszeiten und Fristen die Start- und Abschlusszeiten eines jeden einzelnen Prozesses so gew¨ ahlt sind, dass sich keine Ausf¨ uhrungszeiten auf einem Prozessor u ¨berlappen und s¨ amtliche Zeitbedingungen eingehalten werden.

Die Brauchbarkeit (engl. feasibility) einer Prozessmenge P besteht darin, dass f¨ ur sie ein brauchbarer Plan existiert. Mit F ⊂ 2P wird die Menge aller Prozessmengen bezeichnet, die einen brauchbaren Plan besitzen.
Die hier eingef¨ uhrte Notation f¨ ur die Prozessparameter unterscheidet strikt zwischen einem Zeitpunkt x, wie beispielsweise einer Bereitzeit rij , und einer Zeitspanne ∆y, beispielsweise einer Ausf¨ uhrungszeit ∆eji . Dies ist darin begr¨ undet, dass es unter algebraischen, physikalischen oder auch programmiertechnischen Gesichtpunkten sinnvoll ist, diese Unterscheidung durchg¨angig herauszustellen. Mit dieser Festlegung ergibt sich jedoch eine Abweichung von anderweitig u ¨blichen Notationen. Auch diese sind nicht eindeutig, jedoch existiert eine gewisse Konvergenz bez¨ uglich der Periode des i-ten Prouhrungszeit des des i-ten zesses, die mit Ti bezeichnet wird, und der Ausf¨ Prozesses, die mit Ci bezeichnet wird (vgl. [26] und [33]). Daneben wird die Ausf¨ uhrungszeit jedoch mal mit ei (vgl. [78]) oder mal mit ci (vgl. [118]) bezeichnet. 2.1.5 Verfahren der Echtzeitplanung

Die Bereitzeiten, Ausf¨ uhrungszeiten, Fristen und Perioden sind als von der Anwendung vorgegebene Eingabedaten anzusehen (siehe Abb. 2.7). Der Echtzeitplanung obliegt die Festlegung der Start- und Abschlusszeiten und bei unterbrechbaren Prozessen zus¨ atzlich die Folge von Prozessumschaltungen. Dennoch stellt sich die Echtzeitplanung nicht als einf¨ormiges, zusammenh¨ angendes Verfahren dar. Vielmehr sind einzelne Stufen der Planung zu unterscheiden, verschiedene Darstellungen von Pl¨anen zu erw¨agen und die Zeitpunkte der Verf¨ ugbarkeit der Prozessparameter zu ber¨ ucksichtigen. Zun¨ achst werden die beiden letzten Punkte der obigen Aufz¨ahlung etwas n¨ aher betrachtet, bevor die Stufen der Planung im Einzelnen erl¨autert werden. Darstellung von Pl¨ anen: Expliziter und impliziter Plan Im Gegensatz zum abstrakten Plan, der als mathematische Funktion definiert ist, ben¨otigt ein Planungsverfahren konkrete Datenstrukturen. Pragmatische Gesichtspunkte, wie Speicher- und Ausf¨ uhrungseffizienz, spielen eine entscheidende Rolle. So kann ein Plan als vollst¨andiges oder regel-

2.1.2

52

2. Methodische und technische Grundlagen

basiertes Abbild der mathematischen Funktion vorliegen, beispielsweise indem f¨ ur jede Bezugszeitspanne ∆tG festgelegt ist, welcher Prozess gerade auf dem Prozessor ausgef¨ uhrt werden soll. Demgegen¨ uber kann ein Plan auf wenige Regeln reduziert sein. Eine h¨aufig verwendete Regel ist die, einem Prozess eine Priorit¨ at zuzuordnen und die priorit¨atsbasierte Prozessausf¨ uhrung zu praktizieren. Entsprechend spricht man vom expliziten Plan, wenn ein solcher vollst¨ andig vorliegt, und von einem impliziten Plan, wenn er in Form von Regeln dargestellt ist. Zeitpunkte der Verf¨ ugbarkeit der Prozessparameter: Statische und dynamische Echtzeitplanung Die Planungsparameter k¨ onnen einerseits vorweg bekannt sein, andererseits jedoch erst zur Ausf¨ uhrungszeit anfallen. Dies betrifft in erster Linie die Bereitzeit, die insbesondere bei sporadischen Prozessen erst w¨ahrend der Ausf¨ uhrung bekannt wird. So spricht man von statischer Echtzeitplanung, wenn der Plan aufgrund der fr¨ uhzeitig verf¨ ugbaren Prozessparameter erstellt werden kann, und von dynamischer Echtzeitplanung, wenn sich der Plan erst zur Laufzeit fortschreiben l¨asst. Bezogen auf die Echtzeitplanung sind drei wesentliche Phasen zu unterscheiden (vgl. [119]): 1. Einplanbarkeitstest (engl. feasibility check) Sind alle notwendigen Prozessparameter bekannt, so ist im Sinne der statischen Planung zu pr¨ ufen, ob alle Zeitbedingungen eingehalten werden k¨ onnen, d.h., ob ein brauchbarer Plan existiert. Dieser Test arbeitet vorweg und ben¨ otigt keine Zeit w¨ ahrend der Ausf¨ uhrung der Prozesse. Bei sporadischen Prozessen ist jeweils beim Bereitwerden eines solchen Prozesses zu pr¨ ufen, ob dieser zusammen mit den bereits vorhandenen Prozessen so abgearbeitet werden kann, dass keine Zeitbedingungen verletzt werden. Ist dies nicht der Fall, so ist ein solcher Prozess entweder abzuweisen oder es sind anderweitige Maßnahmen zu ergreifen, die die Vorhersagbarkeit des Systemverhaltens sicherstellen. Dies ist typisch f¨ ur einen dynamischen Einplanbarkeitstest. Spezielle Planungsziele im Sinne einer Schadensbegrenzung sind anwendungsspezifisch festzulegen. Im Einzelfall kann das bedeuten, die Summe der Frist¨ uberschreitungen zu minimieren oder die Priorit¨ at von Prozessen neu zu bewerten. 2. Plan(engl. schedule) oder Planerstellung (engl. schedule construction) Aus einem Plan muss hervorgehen, wann ein betrachteter Prozess auf dem Prozessor ausgef¨ uhrt wird. W¨ ahrend der Einplanbarkeitstest lediglich die M¨ oglichkeit einer fristgerechten Planung er¨offnet, sollte ein Plan die

2.1

¨ Uberblick u ¨ber die Echtzeitplanung

53

gesamte Information repr¨ asentieren, die f¨ ur eine Zuordnung von Prozess zu seiner Ausf¨ uhrung auf dem Prozessor notwendig ist. Bei der statischen Planung ist die Phase der Planerstellung nur dann notwendig, wenn in der Phase davor, d.h. beim Einplanbarkeitstest, die Brauchbarkeit nachgewiesen wurde. Bei der dynamischen Planung hingegen kann die Planerstellung entfallen bzw. mit der n¨achsten Phase, der Prozessorzuteilung, zusammenfallen.







 
       

  


  
 

 



Abb. 2.7. Die Echtzeitplanung modelliert im Datenflussdiagramm.

3. Prozessorzuteilung (engl. dispatching) Der Plan ist auszuf¨ uhren. Dazu betont der Begriff der Prozessorzuteilung die Hardware-orientierte Sicht des Vorgangs, w¨ahrend aus Softwaretechnischer Sicht dieser Vorgang mit dem Begriff Prozessumschaltung bezeichnet wird. In der Tat m¨ ussen hier Hard- und Software eines Rechensystems zusammenarbeiten. Dabei ergeben sich unterschiedliche Notwendigkeiten, je nachdem, ob die Prozesse unterbrechbar sind oder nicht. Sind die Prozesse nicht unterbrechbar, dann ist immer nur am Ende eines Prozesses eine Prozessumschaltung erforderlich. Den Angaben aus dem expliziten Plan oder der Strategie des impliziten Planes entsprechend kommt ein n¨ achster Prozess zur Ausf¨ uhrung. Bei unterbrechbaren Prozessen ist es dar¨ uber hinaus so, dass die Prozessumschaltung anderweitig, beispielsweise ausgehend von der Bereitzeit eines anderen Prozesses, veranlasst wird. Insbesondere in diesem zweiten Fall k¨ onnen die insgesamt auflaufenden Zeiten f¨ ur die Prozessumschaltungen aufgrund ihrer H¨ aufigkeit erheblich sein. Deshalb sind gerade hier geeignete Datenstrukturen und Algorithmen gefordert, die die Prozessumschaltung in einer vorhersagbaren, kurzen Zeitspanne erledigen. Die Echtzeitplanung vernachl¨ assigt typischerweise in ihrer Modellbildung die Zeiten, die f¨ ur die Prozessumschaltungen notwendig sind. Dieses Vorgehen tr¨ agt unmittelbar zur Klarheit der Planungsverfahren und zur ¨ Ubersichtlichkeit der beschreibenden Formeln bei. Aus diesem Grunde wird auch in diesem Buch so vorgegangen und erst in einem Nachtrag zu den grundlegenden Planungsverfahren im Unterabschnitt 3.5.3 auf die zus¨ atzlichen Zeiten, die zu ber¨ ucksichtigen sind, eingegangen.

54

2. Methodische und technische Grundlagen

Mit der Existenz eines brauchbaren Planes ist noch kein solcher gefunden. Gesucht sind Verfahren, die in der Lage sind, explizite oder implizite Pl¨ane zu berechnen. 2.1.3

Definition 2.1.3 Ein Verfahren S zur Echtzeitplanung heißt optimal, falls es bei gegebener Prozessmenge P = {1, . . . , n}, f¨ ur die ein brauchbarer Plan existiert, auch einen solchen findet. Sei S eine Menge von Verfahren zur Echtzeitplanung. Dann ist ein Verfahren S ∈ S optimal innerhalb von S, falls S bei gegebener Prozessmenge P = {1, . . . , n}, f¨ ur die in S ein Plan existiert, auch einen solchen findet.


2.1.4

Definition 2.1.4 Mit FS ⊂ 2P wird die Menge aller Prozessmengen bezeichnet,

f¨ ur die mittels des Plnaungsverfahrens S ein brauchbarer Plan s gefunden wird.
Es gilt, dass nicht jede Prozessmenge, die einen brauchbaren Plan besitzt, von einem Planungsverfahren S gefunden wird, d.h., es ist: FS ⊂ F. 2.1.6 Kategorisierung der Verfahren zur Echtzeitplanung

Eine markante Kategorisierung der Echtzeitplanung beruht auf der priorit¨ atsbasierten Prozessausf¨ uhrung (engl. priority based scheduling). Diese Form eines impliziten Plans entspricht der Regel, denjenigen rechenbereiten Prozess auszuf¨ uhren, dem die h¨ ochste Priorit¨at zugewiesen wurde. Anhand des Zeitpunktes, zu dem den Prozessen (genauer: den Prozssobjekten) ihre Priorit¨ aten zugewiesen werden, kann unterschieden werden zwischen: Echtzeitplanung bei statischen Priorit¨aten Im Sinne der impliziten Planung wird einem Prozessobjekt aufgrund seiner Parameter eine feste Priorit¨ at zugeordnet. Echtzeitplanung bei dynamischen Priorit¨aten Jeder einzelnen Ausf¨ uhrung eines Prozessobjektes wird zur Bereitzeit oder sp¨ ater eine Priorit¨ at zugeordnet. Diese Kategorisierung wird bei der Betrachtung grundlegender Planungsverfahren wieder aufgegriffen und bestimmt die Abschnitte 3.2 zu dynamischen Priorit¨ aten und 3.3 zu statischen Priorit¨aten. Das Fortschreiten der Zeit ist die Ursache daf¨ ur, dass ein periodischer Prozess seine Bereitzeit erreicht. Ist der Prozess, genauer der Prozesstyp, so aufgebaut, dass (wie im Programmfragment auf Seite 48) mit dem Aufruf : wait_until(t);

2.1

¨ Uberblick u ¨ber die Echtzeitplanung

55

: auf das Eintreten eines Zeitpunktes gewartet wird, dann spricht man von einer zeitgesteuerten Prozessausf¨ uhrung. Diese Bezugnahme auf das Fortschreiten der Zeit mutet auf den ersten Blick als klares Entwurfskonzept an. Bei genauerem Hinsehen erkennt man, dass sich dahinter eine Reihe von Auslegungsm¨ oglichkeiten verbergen4 , die sich im englichen Sprachraum mit unterschiedlichen Bedeutungen in den Begriffen time-driven und time-triggered wiederfinden. Entscheidend f¨ ur die zeitgesteuerte Prozessausf¨ uhrung ist bezogen auf den angegebenen Zeitpunkt, ob der Prozess ab diesem Zeitpunkt im Besitz des Prozessors (a) sein wird oder (b) sein kann. Fall (a) ist als zeitgesteuert im engeren Sinn zu betrachten und hat den wesentlich h¨ oheren Grad an Determiniertheit. Denn es darf nur einen Prozess geben, der auf den Zeitpunkt t wartet und mit dessen Eintreten in den Besitz des Prozessors gelangt. Der Fall (a) eignet sich deshalb f¨ ur nicht unterbrechbare Prozesse, die nach einem expliziten Plan realisiert durch Prozesse, die gezielt auf Zeitpunkte warten, abgearbeitet werden. Damit ist f¨ ur einen Prozess i seine Bereitzeit auch schon seine Startzeit: ri = si Ist das Eintreten eines Ereignisses zu erfassen, so geschieht dies durch das Anfrage- oder Polling-Prinzip. Das bedeutet, dass das Programm in festgelegten Zyklen aktiv pr¨ uft, ob eine Zustands¨ anderung erfolgt ist. 4

Die Begriffsbildung im Zusammenhang mit der zeitgesteuerten Prozessausf¨ uhrung ist in der Tat verwirrend. So spricht Liu [92] von priority-driven, wenn priorit¨ atsbasierte Prozessausf¨ uhrung gemeint ist und stellt dagegen time-driven als eine Form der Ausf¨ uhrung expliziter Pl¨ ane dar. Bei Cooling [32] ist time-driven oder synonym tick-driven gleichzusetzen mit der priorit¨ atsbasierten Prozessausf¨ uhrung. Sporadische Prozesse, die ebenfalls priorit¨ atsbasiert ausgef¨ uhrt werden, laufen un¨ ter der Bezeichnung interrupt-driven. Ahnlich ist dies bei Buttazzo [26], der anstelle von interrupt-driven von event-driven spricht. Der exponierteste Vertreter des time-triggered approach ist Kopetz [75]. Dies betrifft einerseits die Zeitabh¨ angigkeit der Prozessausf¨ uhrung. Dabei wird jedoch in den Darlegungen nicht klar, ob Prozesse darauf warten, in den Zustand rechenbereit oder in den Zustand rechnend u ¨berzugehen. Andererseits hat Kopetz den Begriff time-triggered konsequent auf Rechnernetze ausgedehnt. So sorgen die time-triggered protocols daf¨ ur, dass der aktuelle Zeitpunkt bestimmt, welcher Prozess eine Nachricht senden darf und welche Prozesse sie empfangen d¨ urfen.

56

2. Methodische und technische Grundlagen

Die Prozessausf¨ uhrung im Fall (b) kann als zeitgesteuert im weiteren Sinn betrachtet werden und ist im Vergleich zu Fall (a) weniger determiniert. Hier ist der Begriff vorhersagbar angebracht. Denn das Erreichen des Zeitpunktes t versetzt einen Prozess i lediglich in die Lage, ausgef¨ uhrt werden zu d¨ urfen, d.h. entspricht seiner Bereitzeit ri . Mehrere Prozesse k¨onnen auf denselben Zeitpunkt warten. Eine Auswahl muss stattfinden. Erfolgt sie nach den Regeln der priorit¨ atsbasierten Prozessausf¨ uhrung, so ist aus der Menge der rechenbereiten Prozesse der zum Zeitpunkt t h¨ochstpriorisierte auszuw¨ahlen. Da Prozesse die ihnen zustehende Ausf¨ uhrungszeit nicht immer vollst¨andig in Anspruch nehmen, k¨ onnen weniger Prozesse rechenbereit sein als m¨oglich. Auf diese Weise ergeben sich unterschiedliche Folgen der Prozessausf¨ uhrung. Dass dennoch von Vorhersagbarkeit gesprochen werden kann, ist darin begr¨ undet, dass bei aller Unterschiedlichkeit klare Aussagen u ¨ber die Einhaltung der Zeitbedingungen jedes einzelnen Prozesses gemacht werden k¨onnen (Gegenstand der Abschnitte 3.2 und 3.3). Zeitgesteuerte Prozessausf¨ uhrung ist immer verbunden mit dem Abwarten von Zeitpunkten, die durch die Prozessparameter gegeben sind und nach dem Muster des Programmfragmentes (siehe Seite 48) gesetzt werden k¨onnen. Periodische Prozesse lassen sich auf diese Weise sehr einfach realisieren. F¨ ur sporadische Prozesse eignet sich dieses Muster hingegen nicht. Solche Prozesse warten darauf, dass ihnen ein Ereignis, das im technischen System oder Rechensystem auftritt, so unmittelbar wie m¨oglich zugetragen wird. Ereignisse werden durch Zustands¨ anderungen hervorgerufen und liefern die Anst¨oße f¨ ur eine ereignisgesteuerte Prozessausf¨ uhrung. Ein entsprechtendes Programmfragment hat folgende Gestalt: P(i):: while(TRUE) { wait_for(e); // Prozesstyp des Prozessobjektes P(i) } Da nicht generell davon ausgegangen werden kann, dass Ereignisse koordiniert auftreten, macht es keinen Sinn, mit dem Eintritt eines Ereignisses die Zuordnung des Prozessors an einen Prozess zu verbinden (Fall (a) von oben). Nur der Fall (b), bei dem mit dem Ereignis die Bereitzeit eines Prozesses verbunden ist, kommt in Betracht. Stammt das Ereignis aus dem technischen System, so wird es mittels Unterbrechungsbehandlung (engl. interrupt service routine oder ISR) erfasst und verarbeitet. Ereignisse k¨onnen auch vom Rechensystem und den dort ausgef¨ uhrten Prozessen selbst ausgehen,

2.1

¨ Uberblick u ¨ber die Echtzeitplanung

57

beispielsweise, wenn ein Prozess einem anderen signalisiert, weiterarbeiten zu d¨ urfen. Beide M¨ oglichkeiten, extern oder intern, f¨ uhren den Prozess, der auf ein Ereignis e wartet, in den Zustand rechenbereit. Bei aller Unsicherheit u ¨ber das Eintreffen der Ereignisse ist Vorhersagbarkeit gegeben, wenn bekannt ist, wie kurzfristig hintereinander dieses Ereignis eintreten kann. Die nachfolgende Tabelle macht noch einmal deutlich, welche Alternativen zeitund ereignisgesteuerter Prozessausf¨ uhrung sich ergeben und ob sie sich auf die Startzeit si oder die Bereitzeit ri eines Prozesses i beziehen:

Startzeit

Bereitzeit

zeitgesteuert ereignisgesteuert nicht unterbrechbare Prozesse expliziter Plan Fall( a) periodische sporadische unterbrechbare Prozesse unterbrechbare Prozesse Fall (b) impliziter Plan

¨ Uber alle Varianten der zeit- und ereignisgesteuerten Prozessausf¨ uhrung l¨asst sich ein Zustandsdiagramm (siehe Abb. 2.8) entwickeln. Es ist davon gepr¨ agt, dass Prozessausf¨ uhrungen endlich sind, und Prozesse zwischen ihrer Abschlusszeit und ihrer n¨ achsten Bereitzeit in den Zustand vor¨ ubergehend beendet u ¨bergehen. Wird mit dem Erreichen prozessspezifischer Zeitpunkte auch immer unmittelbar der Prozessor zugeordnet, dann ist dieser Zeitpunkt auch immer gleich die Startzeit und die Prozesse wechseln immer nur zwischen den Zust¨ anden beendet und rechnend. Dies trifft auf nicht unterbrechbare Prozesse zu, die nach einem expliziten Plan ausgef¨ uhrt werden. Ist mit dem Erreichen von Zeitpunkten oder dem Eintreten von Ereignis¨ sen nur die Bereitzeit eines Prozesses verbunden, so erfolgt ein Ubergang in den Zustand rechenbereit. Bei Anwendung der priorit¨atsbasierten Prozessausf¨ uhrung gelangt der h¨ ochstpriorisierte Prozess in den Zustand rechnend, w¨ahrend sich alle u angt aufhalten. Betrachtet man ¨brigen im Zustand verdr¨ zus¨ atzlich die M¨ oglichkeit, dass Prozesse Betriebsmittel ben¨otigen, diese jedoch vor¨ ubergehend nicht erhalten und dementsprechend nicht weiter ausgef¨ uhrt werden k¨ onnen, dann soll dies mit dem Zustand blockiert beschrieben werden. Zusammenfassend seien noch einmal die relevanten Begriffe genannt, f¨ ur die Prozesse und deren Verplanung unter Echtzeitbedingungen relevant sind. Bezogen auf Prozesse, genauer auf Prozessobjekte, ist zu unterscheiden zwischen: unterbrechbaren oder nicht unterbrechbaren Prozessen

58

2. Methodische und technische Grundlagen

Abb. 2.8. Die Zust¨ ande, in denen sich Prozesse befinden k¨ onnen. Beachte, dass der

Zustands¨ ubergang (a) zweimal vorkommt. F¨ ur nicht unterbrechbare Prozesse, die nach einem expliziten Plan ausgef¨ uhrt werden, sind nur die Zust¨ ande beendet und rechnend ¨ zul¨ assig, und es gen¨ ugen die Uberg¨ ange (a) und (b). Im Falle unterbrechbarer Prozesse und ¨ priorit¨ atsbasierter Prozessausf¨ uhrung f¨ uhrt der Ubergang (a) in den Zustand rechenbereit ¨ und alle u brigen Uberg¨ a nge (b) bis (f) sind m¨ o glich. ¨

periodischen, aperiodischen oder sporadischen Prozessen statischen oder dynamischen Priorit¨ aten zeitgesteuerter oder ereignisgesteuerter Ausf¨ uhrung von Prozessobjekten

Bei den Planungsverfahren ist zu unterscheiden zwischen denen, die explizite oder implizite Pl¨ ane erzeugen. Bei expliziten Pl¨anen steht fest, welcher Prozess zu welchem Zeitpunkt ausgef¨ uhrt werden soll. Dies gilt insbesondere f¨ ur die zeitgesteuerte Prozessausf¨ uhrung in der Variante, dass der Zeitpunkt die Startzeit der Ausf¨ uhrung bestimmt. Mit impliziten Pl¨ anen wird verbunden, dass Prozesse durch das Eintreten von Zeitpunkten oder Ereignissen in den Zustand rechenbereit u ¨bergehen. Die Bestimmung des Prozesses, der gerade ausgef¨ uhrt wird, basiert auf den Priorit¨ aten, die den Prozessen jeweils zugeordnet sind, im Falle statischer Priorit¨ aten eine Eigenschaft des Prozessobjektes und im Falle dynamischer Priorit¨ aten eine Eigenschaft der jeweiligen Prozessausf¨ uhrung Echtzeitsysteme, bei denen die Prozesse auf der Grundlage expliziter Pl¨ane ausgef¨ uhrt werden, sind in ihrem Verhalten festgelegt. Man kann von der Determiniertheit eines solchen Systems sprechen, bei dem abh¨angig vom Zeitpunkt im Voraus bekannt ist, welcher Prozess welchen Zustand einnehmen wird. Implizite Pl¨ ane gehen einher mit der zeit- oder ereignisgesteuerten Prozessausf¨ uhrung, die Prozesse in den Zustand rechenbereit versetzen. Damit verbunden sind eine Unmenge m¨ oglicher Prozessausf¨ uhrungen, und es ist nicht

2.1

¨ Uberblick u ¨ber die Echtzeitplanung

59

realistisch, jede einzelne zu erfassen oder gar zu analysieren. Dennoch ist Vorhersagbarkeit gegeben, wenn nachgewiesen werden kann, dass keine der Prozessausf¨ uhrungen ihre Zeitbedingungen verletzen wird. Grundlage hierf¨ ur ist die priorit¨ atsbasierte Prozessausf¨ uhrung f¨ ur unterbrechbare Prozesse. Anhand des Zeitpunktes der Priorit¨ atszuordnung ist hier zu unterscheiden zwischen Planungsverfahren mit statischen und dynamischen Priorit¨aten. Abbil¨ dung 2.9 gibt eine graphische Ubersicht u ¨ber die wichtigsten Begriffe bei der Echtzeitplanung und ihrer Kombinierbarkeit.


  
 
  
 


   


 


             
   
   

     

      
  


Abb. 2.9. Die Kombinierbarkeit der wesentlichen Begriffe bei Prozessen und

Planungsverfahren.

60

2.2

2. Methodische und technische Grundlagen

2.2 Zeiten und Uhren Im Mittelpunkt dieses Abschnitts steht der Begriff der Echtzeit und seine Operationalisierung unter verschiedenen Gesichtspunkten. Zun¨achst erfolgt eine breit angelegte Ann¨ aherung an den Zeitbegriff (siehe Unterabschnitt 2.2.1) und dann eine von der Physik gepr¨agte Ann¨aherung an den Zeitbegriff ¨ (siehe Unterabschnitt 2.2.2). Es folgen Uberlegungen zur Erfassung der Zeit unter grundlegenden Gesichtspunkten einerseits (siehe Unterabschnitt 2.2.3) und unter technischen Gesichtspunkten, wie sie beispielsweise bei Uhrbausteinen gegeben sind, andererseits (siehe Unterabschnitt 2.2.4). Schließlich geht es darum, wie man mit Zeitpunkten, Zeitspannen und Zeitintervallen rechnet (siehe Unterabschnitt 2.2.5). 2.2.1 Betrachtungen zur Zeit

Zeit ist eine der fundamentalen Gr¨ oßen der Physik. Wie mit jeder dieser fundamentalen Gr¨ oßen wird ihr Wesen und ihre Fassbarkeit um so schwieriger, je tiefer man sich mit ihnen befasst. Zum Gl¨ uck steht im Zusammenhang mit Echtzeitsystemen nicht die physikalische Zeit im Mittelpunkt der Betrachtung, sondern die Erfassung der Zeit auf rechentechnischen Systemen, ¨ die mit der Steuerung und Uberwachung zeitkritischer technischer Prozesse betraut sind. So soll letztendlich ein angewandter Zeitbegriff, der die Anforderungen des Anwendungsfeldes der Echtzeitsysteme erfasst, ausreichen und im Folgenden entwickelt werden. Der Zeitbegriff hat viele Auspr¨ agungen, angefangen von der menschlichen Empfindung von Zeit bis hin zu Pr¨ azisierungsversuchen durch unterschiedliche Wissenschaftsdisziplinen. Einige nicht unmittelbar physikalisch gepr¨agte Zeitbegriffe seien hier erw¨ ahnt, da sie m¨oglicherweise in Anwendungsbereichen von Echtzeitsystemen eine Rolle spielen: Von seinen altgermanischen Wurzeln her wird das althochdeutsche zˆıt als Tageszeit, Jahreszeit und Lebensalter verstanden: Nu ist der k¨ uele winder gar zergangen, diu naht ist kurz, der tac beginnet langen: sich hebet an ein w¨ unneclˆıchiu zˆıt diu al der werlde vreude gˆıht. Baz gesungen nie die vogele ˆe noch sˆıt. aus dem Lied Ougenweyde“ von Neidhart von Reuenthal ” Das sinnliche Empfinden von sch¨ onen oder weniger sch¨onen Augenblicken, die Erkenntnis der Unumkehrbarkeit, die Unm¨oglichkeit, der Vergangenheit zu entgehen:

2.2

Zeiten und Uhren

61

Werd’ ich zum Augenblicke sagen: Verweile doch! Du bist so sch¨on! Dann magst du mich in Fesseln schlagen, Dann will ich gern zugrunde gehen! Johann Wolfgang von Goethe Die seit der Fr¨ uhzeit der Menschheit wahrgenommenen und stetig erforschten Rhythmen der Gestirne, von Sommer und Winter, von Tag und Nacht, von Ebbe und Flut, den Schwingungen einer Saite, dem angeregten Quarz als Oszillator: Eins, zwei, drei im Sauseschritt l¨auft die Zeit - wir laufen mit Wilhelm Busch Die kognitive Erfahrung von Zeit in biologischen Abl¨aufen wie dem Altern, als gesch¨ aftliche Grundlage wie beim Stundenlohn, als Auseinandersetzung mit der Zeit in der Kultur wie die philosohische Frage nach dem Sein: Ohne Sein keine Zeit, ohne Zeit kein Sein Martin Heidegger Im Kontrast dazu das Wegschauen, die Banalisierung und Veralberung der zeitlichen Zw¨ ange und Grenzen: Alles hat ein Ende, nur die Wurst hat zwei Fastnachtsschlager von Stephan Remmler Die methaphysische und religi¨ ose Aufhebung von Zeit und Raum: Alles hat seine Zeit. aus der Bibel, Kohelet 3,1-8 Offensichtlich ist die Ann¨ aherung an den Zeitbegriff aus v¨ollig unterschiedlichen Richtungen m¨ oglich, naturwissenschaftlich, philosophisch, soziologisch, kulturgeschichtlich, religi¨ os. Dabei hat die naturwissenschaftliche Auseinandersetzung mit der Zeit die weitestgehenden Einfl¨ usse auf das Fachgebiet Echtzeitsysteme und soll deshalb n¨ aher betrachtet werden. 2.2.2 Die physikalische Zeit

Der bis ins 20. Jahrhundert g¨ ultige Zeitbegriff steht in der Tradition von Platon und wurde von Isaac Newton naturwissenschaftlich untermauert. Demnach ist die Zeit eine absolute Gr¨ oße, die aus ihrer Natur heraus gleichf¨ormig und von anderen Gr¨ oßen unbeeinflusst abl¨ auft. Neben der Zeit ist f¨ ur die

62

2. Methodische und technische Grundlagen

klassische Physik auch der dreidimensionale Raum eine Grundgr¨oße, w¨ahrend beispielsweise die Geschwindigkeit eine abgeleitete Gr¨oße darstellt. Einen weniger absoluten Zeitbegriff bringt Gottfried Wilhelm Leibniz ins Spiel. In der Tradition von Aristoteles, der formuliert hat Wo nichts geschieht, ist auch keine Zeit. f¨ uhrt er die Auffassung fort, dass die Zeit in der Anordnung beobachtbarer Ereignisse besteht. Zeitwerte zwischen zwei Ereignissen sind abstrakt und werden durch lineare Interpolation angen¨ahert. Anders als ein absoluter Zeitbegriff kommt ein Zeitbegriff, der Zeit in Bezug zu ¨außeren Ereignissen setzt, der modernen Physik in der Pr¨ agung durch Albert Einstein deutlich n¨aher. Bis ins 20. Jahrhundert galt die Geschwindigkeit als eine von den absoluten Gr¨ oßen Raum und Zeit abgeleitete Gr¨ oße. Diese Auffassung traf f¨ ur die Lichtgeschwindigkeit ebenso zu wie beispielsweise f¨ ur die Schallgeschindigkeit. Die Gr¨ oßenordnung der Lichtgeschwindigkeit war bereits seit dem 17. Jahrhundert durch Beobachtungen und Berechnungen von Ole Rømer bekannt. Er hatte festgestellt, dass die Zeitpunkte der Verfinsterung des Jupitermondes Io u ¨ber das Jahr betrachtet zeitliche Abweichungen von mehreren Minuten akkumulieren. Seine Beobachtung konnte er mit der unterschiedlichen Laufzeit des Lichtes vom Mond Io zum erdn¨ achsten und erdfernsten Punkt erkl¨aren, und er berechnete daraus die unvorstellbare Geschwindigkeit von umgerechnet 225000km/s. 2.2.1

Aufgabe 2.2.1 (siehe Seite 275) Bei seiner Berechnung der Lichtgeschwindig-

keit ging Ole Rømer von folgenden Voraussetzungen aus: Der Mond Io dreht sich mit konstanter Umlaufzeit von 42,5 Stunden um den Planeten Jupiter. Die Umlaufzeit von Jupiter ist mit etwa 11,6 Jahren so groß, dass seine Position sich innerhalb eines Jahres von der Erde aus vernachl¨assigbar ver¨ andert hat. Ole Rømer beobachtete nun Gangunterschiede in der Umlaufzeit des Planeten, die sich vom jupitern¨ achsten Punkt der Erde bis zum jupiterfernsten Punkt der Erde auf ∆tR = 1320s akkumulierten. Bekannt war ihm außerdem der Durchmesser der Umlaufbahn der Erde um die Sonne mit einem Wert von ∆dR = 3, 0·1014 m. Aus diesen Angaben schloss er auf die Lichtgeschwingkeit.
Damit hatte die Lichtgeschwindigkeit aufgrund ihrer damals unvorstellbaren H¨ ohe bereits die Aura des Besonderen. Dennoch galt wie beim Schall,

2.2

Zeiten und Uhren

63

dass sich Licht in einem Medium ausbreitet. Mit dem Misslingen des Experiments von Michelson und Morley, dieses Medium explizit nachzuweisen, ergab sich die erstaunliche Erkenntnis, dass kein solches existiert und die Lichtgeschwindigkeit eine absolute Gr¨ oße ist, d.h. gleich bleibt, egal mit welcher Geschwindigkeit sich die Lichtquelle bewegt. Aufgrund dieses Experiments, aber mehr noch auf der Grundlage anderer Inkonsistenzen im damaligen Bild von der Elektrodynamik setzte Albert Einstein im Jahre 1905 in seiner Arbeit Von der Elektrodynamik bewegter K¨ orper“ die Zeit und den Raum als ” relative Gr¨ oßen an und konnte so die Absolutheit der Lichtgeschwindigkeit widerspruchsfrei begr¨ unden. Die spezielle Relativit¨atstheorie war entworfen. Zwei Begriffe und zwei Annahmen bilden die wesentlichen Grundlagen dieser Theorie: A1: Ein Bezugssystem Σ, genauer Inertialsystem, ist ein dreidimensionaler Vektorraum, in dem sich Teilchen mit konstanter Geschwindigkeit bewegen, sofern auf sie keine Kr¨ afte wirken. Licht bewegt sich in unterschiedlichen Bezugssystemen mit der gleichen Geschwindigkeit c. Bekannt ist das Beispiel, bei dem sich das Licht der Scheinwerfer eines Schnellzuges mit derselben Geschwindigkeit bewegt, wie das Licht aus der Taschenlampe eines Beobachters neben den Gleisen. Zug und Beobachter sind unbeweglich in ihren jeweiligen Bezugssystemen Σ1 und Σ2 . Es gibt eine relative Geschwindigkeit v12 zwischen diesen Bezugssystemen und dennoch ist die Geschwindigkeit des Lichtes, egal ob es dem Scheinwerfer oder der Taschenlampe entstammt, immer gleich. A2: Die Beobachtung, dass Licht immer dieselbe konstante Geschwindigkeit besitzt, kann man zu jedem Zeitpunkt und an jedem Ort des Universums machen. Dies wird auch als Homogenit¨at der Zeit und Isotropie des Raumes bezeichnet. Formelm¨ aßig folgt daraus, dass zwischen Bezugssystemen in zeitlicher und r¨ aumlicher Hinsicht nur lineare Abh¨angigkeiten gelten. Alle anderen Formen funktionaler Abh¨angigkeit w¨ urden keine zeitlichen und r¨aumlichen Verschiebungen von Paaren von Bezugssystemen unter Beibehaltung derselben Abh¨ angigkeit zulassen. Ereignisse ben¨ otigen die Angabe von Ort und Zeit, so beispielsweise beim Empfang eines Lichtsignals zum Zeitpunkt t am Ort x. Die Raum-ZeitKoordinaten5 (t, x) beziehen sich dabei auf ein definiertes Bezugssystem. Ein und dasselbe Ereignis kann in verschiedenen Bezugssystemen Σ1 und Σ2 erur fasst und durch die Koordinaten (t1 , x1 ) und (t2 , x2 ) dargestellt werden. F¨ die klassische Physik beschreibt die Galilei-Transformation die Umrechnung 5

Der Einfachheit halber wird nur ein eindimensionaler Raum betrachtet. Dieser gen¨ ugt zur Herleitung der speziellen Relativit¨ atstheorie.

64

2. Methodische und technische Grundlagen

zwischen den Bezugssystemen Σ1 und Σ2 : t2 = t1 x2 = x1 − v12 t1 Dabei ist v12 die Geschwindigkeit, mit der sich Bezugssystem Σ2 von Σ1 entfernt. Weiterhin ist die Zeit so gew¨ ahlt, dass f¨ ur t1 = t2 = 0 beide Bezugssysteme zusammenfallen bzw. koinzidieren (siehe Abb. 2.10). 




 





Abb. 2.10. Bezugssystem Σ2 entfernt sich mit Geschwindigkeit v12 von Bezugssystem Σ1 .

Eine vereinheitlichende Schreibweise, die die Beziehungen zwischen Ereignissen unterschiedlicher Beschreibungssysteme klassisch und relativistisch erfasst, setzt anstelle der Zeit t das Produkt von Zeit und Geschwindigkeit. Damit wird erreicht, dass die Beschreibung nur noch in der Dimension Raum stattfindet. Demnach ist die Galilei-Transformation gegeben als:

ct2 x2



=

1 − vc12

0 1



ct1 x1



Es ist leicht einzusehen, dass die Galileo-Transformation die Absolutheit der Lichtgeschwindigkeit nicht erfasst. 2.2.2

Aufgabe 2.2.2 (siehe Seite 276) Zeigen Sie, dass die Galilei-Transformation

nicht erfasst, dass die Lichtgeschwindigkeit unabh¨angig von der relativen Geschwindigkeit der Bezugssysteme ist.
Um den Zusammenhang zwischen den Koordinaten desselben Ereignisses in unterschiedlichen Bezugssystemen richtig zu erfassen, wird aus Gr¨ unden der Homogenit¨ at der Zeit und der Isotropie des Raumes (siehe Annahme A2 auf Seite 63) eine lineare Transformation ben¨otigt. Ihr allgemeiner Ansatz lautet:

ct2 x2



=

AB CD



ct1 x1



Die freien Parameter A, B, C und D lassen sich Schritt f¨ ur Schritt durch Ausdr¨ ucke ersetzen, in die die Lichtgeschwindigkeit c und die Geschwindigkeit

2.2

Zeiten und Uhren

65

v12 zwischen den Bezugssystemen Σ1 und Σ2 eingehen. Das Ergebnis wird als Lorentz-Transformation bezeichnet. Sei zun¨ achst eine Anwendung der Transformation beschrieben, bei der ein und dasselbe Ereignis in den Bezugssystemen Σ1 und Σ2 betrachtet wird. Bei dem Ereignis handelt es sich um den Empfang eines Lichtsignals, dargestellt uhrt bei Anwendung als Ereignisse (t1 , ct1 ) in Σ1 und (t2 , ct2 ) in Σ2 . Das f¨ der Lorentz-Transformation zu den Gleichungen: ct2 = A ct1 + B ct1 ct2 = C ct1 + D ct1 Betrachtet man ein anderes Ereignis, bei dem das Licht in umgekehrter Richtung unterwegs ist, dann seien die Ereignisse entsprechend mit (t3 , −ct3 ) in Σ1 und (t4 , −ct4 ) in Σ2 bezeichnet, und es gilt: ct4 = A ct3 − B ct3 −ct4 = C ct3 − D ct3 Aus den vier Gleichungen ergeben sich sofort die Beziehungen A = D und B = C. In einem zweiten Schritt geht es wieder um das Ereignis, ein Lichtsignal in unterschiedlichen Bezugssystemen zu beobachten. Zum gleichen Zeitpunkt wird im ruhenden System Σ1 und im mit v12 bewegten System Σ2 ein Lichtsignal gesendet. Dasselbe Ereignis wird an einem Ort, der sich in einer festen Entfernung von der Bewegungsachse befindet, beobachtet. In Σ2 sei diese Strecke ct2 gerade senkrecht zur Bewegungsachse. In Σ1 erreicht das Licht denselben Ort in der Zeit t1 . In dieser Zeit hat sich das System Σ2 um v12 t1 von Σ1 entfernt. Geometrisch ergibt sich so die Beziehung: (ct1 )2 = (v12 t1 )2 + (ct2 )2 F¨ ur das Bezugssystem Σ1 verl¨ auft die Zeit in Σ2 entsprechend der Formel:

v 2 12 t2 = t1 1 − c Kurz und b¨ undig wird dieser Zusammenhang durch den Satz Bewegte Uhren ” gehen langsamer“ erfasst. Man darf dabei nicht vergessen, dass aus Symmeur den Verlauf triegr¨ unden aus der Sicht von System Σ2 eine analoge Formel f¨ der Zeit in Σ1 gelten muss. Verk¨ urzend wird in der Physik mit dem Bezeicher γ Folgendes geschrieben: γ=

1  2 1 − vc12

66

2. Methodische und technische Grundlagen

Zur Bestimmung der verbleibenden Parameter der Transformation wird das Ereignis, dass das Lichtsignal eintrifft, in Σ1 durch (t1 , x1 ) und in Σ2 durch (t2 , 0) beschrieben. Mit t2 = t1 /γ und x1 = v12 t1 ergibt sich die Transformation:

ct1 /γ 0



=

AB B A



ct1 v12 t1



Daraus leitet man sofort die Beziehungen A = γ und B = − vc12 γ ab. Das Ergebnis ist die Lorentz-Transformation, die nur von der Relativgeschwindigkeit der Bezugssysteme und von der Lichtgeschwindigkeit bestimmt ist:

ct2 x2



=

− vc12 γ v12 − c γ γ γ



ct1 x1



Die absolute Gr¨ oße, die in die Lorentz-Transformation eingeht, ist die Lichtgeschwindigkeit, mit c = 299 792 458m/s. Raum- und Zeitmaße sind abgeleitete Gr¨ oßen. So ist ein Meter als die L¨ ange definiert, die das Licht im Vakuum in einem 1/299792458-tel einer Sekunde zur¨ ucklegt. Echtzeitanwendungen, die sich u ¨ber mehrere Bezugssysteme ausdehnen, sind grunds¨ atzlich der Zeitdilatation unterworfen. Das bedeutet, dass die Bezugszeitspanne ∆tG in einem bewegten System verglichen mit einem ruhenden System gedehnt wird: ∆tG2 = γ ∆tG1 Die Abweichung ρSR 6 der Zeit in beiden Bezugssystemen w¨achst proportional mit der Dauer der Beobachtung und ist definiert als: ρSR = 1 − 1/γ Die Abweichungen, die sich so ergeben, sind verschwindend gering, wenn es sich um Bewegungen von Wasser-, Straßen- und Schienenfahrzeugen handelt. Das wird auch in Abbildung 2.11 deutlich, die unter anderem zeigt, dass u ¨bliche Geschwindigkeiten von Fahrzeugen, die unter 102 m/s liegen, Abweichungen von weniger als 10−12 nach sich ziehen. Bei der Geschwindigkeit von Flugzeugen, ist eine pr¨azise Zeitmessung erforderlich, um Abweichungen nachzuweisen. Dies geschah beim ber¨ uhmten Flug von Hafele und Keating im Oktober 1971. Sie transportierten Atomuhren auf entgegengesetzten Flugbahnen um die Erde und konnten auf diese Weise Gangunterschiede zu Atomuhren auf der Erde in der Gr¨oßenordnung von etwa hundert Nanosekunden nachweisen. Satelliten kommen jedoch bereits 6

SR steht f¨ ur spezielle Relativit¨ atstheorie.

2.2

Zeiten und Uhren

67


 










 

















Abb. 2.11. Die Abweichung ρSR aufgetragen u ¨ber der Geschwindigkeit v12 . Die

Darstellung ist doppelt logarithmisch und macht deutlich, dass bei Geschwindigkeiten, die auf der Erde u ¨blich sind, verschwindend geringe Abweichungen auftreten.

auf Geschwindigkeiten, die eine Ber¨ ucksichtigung der Abweichung notwendig machen. Beispiel 2.2.1 Das Global Positioning System (GPS) verf¨ ugt u ¨ber 24 Satelliten, die auf elliptischen Bahnen in einer mittleren H¨ohe von 20200km u ¨ber der Erdoberfl¨ ache kreisen. Bei zwei Erdumkreisungen pro Sterntag, d.h. in 11, 97 Stunden, besitzen sie eine Geschwindigkeit von 3874m/s. Jeder Satellit hat eine pr¨ azise Uhr an Bord, die bezogen auf die Erde einer Zeitdilatation unterworfen ist. Auf die angegebene Geschwindigkeit gerechnet, ergibt sich eine Abweichung von:

ρSR = 0, 836 · 10−10 Diese verlangsamt den Gang der Uhr im Satelliten. Ein weiterer relativistischer Effekt kommt jedoch noch hinzu. Dieser ist in der allgemeinen Relativit¨ atstheorie begr¨ undet und besagt, dass auch Gravitation eine Zeitdilatation bewirkt. Da die Wirkung der Erdgravitation auf die Uhr des Satelliten geringer ist als auf Uhren in der H¨ ohe der Erdoberfl¨ache, vergeht die Zeit im Satelliten schneller. Diese Abweichung ρAR 7 hat einen gr¨oßeren Wert und ein anderes Vorzeichen als ρSR . Beide Wirkungen miteinander verrechnet ergibt, dass der Takt der Uhr des Satelliten um etwa 4, 445 10−10 gedrosselt werden muss. W¨ urden diese Korrekturen nicht durchgef¨ uhrt, so erg¨aben sich nach 7

AR steht f¨ ur allgemeine Relativit¨ atstheorie.

2.2.1

68

2. Methodische und technische Grundlagen

einer Stunde bereits Positionsabweichungen von mehreren hundert Metern.
2.2.3

Aufgabe 2.2.3 (siehe Seite 276) Wie lange muss sich ein Fahrzeug mit kon-

stant 144km/h bewegen, bis eine Uhr an Bord des Fahrzeugs eine Abweichung von 1µs zu einem ruhenden Bezugssystem aufweist?
2.2.4

Aufgabe 2.2.4 (siehe Seite 276) Eine Rakete fliegt mit 3/5 c von der Erde weg. Sie hat eine Atomuhr an Bord. Auch die Bodenstation verf¨ ugt u ¨ber eine Atomuhr. Beide sind beim Start mit der Zeit t = 0 initialisiert. Nach einer Stunde ihrer eigenen Uhr sendet die Rakete mit Lichtgeschwingigkeit ein Signal zur Erde zur¨ uck. Wann wird in der Uhrzeit der Bodenstation das Signal empfangen?


Das Ergebnis von Aufgabe 2.2.3 legt nahe, dass die Zeitdilatation bei m¨aßigen Geschwindigkeiten getrost vernachl¨ assigt werden kann. Bei diesen Echtzeitanwendungen ist es gerechtfertigt, die physikalische Zeit als absolute, kontinuierlich fortschreitende Gr¨ oße, die in allen Bezugssystemen gleichermaßen gilt, aufzufassen. 2.2.3 Die Erfassung der Zeit

An sich ist die Erfassung der Zeit, was sowohl das Messen der Zeit als auch die daf¨ ur notwendigen Normierungen betrifft, eine technische Fragestellung. Sie fußt jedoch auf prinzipiellen Erkenntnissen der modernen Physik. Aus Sicht der Quantenmechanik unterliegt die Messung physikalischer Gr¨oßen einer Wahrscheinlichkeitsverteilung. Nach Heisenberg gilt: Es ist unm¨oglich, Ort und Impuls eines Teilchens zur selben Zeit mit absoluter Genauigkeit zu bestimmen. Die Ungleichung, die als Heisenbergsche Unsch¨arferelation bekannt geworden ist, liefert eine untere Schranke f¨ ur die Genauigkeit des Produktes aus Ortsangabe x eines Teilchens und seinem Impuls p 8 : ∆x ∆p ≥

h 4π

Mit Hilfe der folgenden Beziehungen, die die Masse m des Teilchens miteinbezieht, l¨ asst sich die Unsch¨ arferelation auf die physikalischen Gr¨oßen Energie 8

Plancksches Wirkungsquantum h = 6, 626 · 10−34 kg m/s

2.2

Zeiten und Uhren

69

und Zeit u ¨bertragen: ∆p ∆E = p m m ∆t = ∆x p Entsprechend ergibt sich die Formel: ∆E ∆t ≥

h 4π

Diese Formel, auch als Energie-Zeit-Unsch¨ arfe bekannt, l¨asst sich dahingehend interpretieren, dass die Genauigkeit von Uhren, insbesondere solcher, die Quanteneffekte benutzen, grunds¨ atzlich begrenzt ist (vgl. [21] und [27]). Denn das Prinzip der Zeitmessung setzt voraus, dass Energieniveaus hinreichend weit auseinander liegen m¨ ussen, damit sie sicher unterschieden werden k¨ onnen. Neben dieser speziellen Energie-Zeit-Unsch¨ arfe besitzt die Heisenbergsche Unsch¨ arferelation eine weitere Folgerung. So formuliert Heisenberg die These, die eine exakte Vorhersagbarkeit prinzipiell ausschließt: An der scharfen Formulierung des Kausalgesetzes Wenn wir die Gegen” wart kennen, k¨onnen wir die Zukunft berechnen“ ist nicht der Nachsatz, sondern die Voraussetzung falsch. Wir k¨onnen die Gegenwart in allen Bestimmungsst¨ ucken prinzipiell nicht kennenlernen. Zu Beginn des 2. Jahrtausends sind die Uhren noch weit davon entfernt, dass die physikalischen Grenzen der Zeitmessung relevant werden. Die Unsicherheit liegt bei etwa 10−15 . Damit ist noch einiger Spielraum vorhanden, bis die Grenzen, die durch die Heisenbergsche Unsch¨arferelation gesetzt sind, erreicht werden. F¨ ur die Messung der Zeit ben¨otigt man Oszillatoren, die eine hohe Stabilit¨ at aufweisen. Ein solcher ist durch die Periodendauer des ¨ Ubergangs zwischen zwei Energieniveaus des Caesium-133 Atoms gegeben. Seit 1967 ist die Sekunde als das 9 192 631 770-fache dieser Periodendauer festgelegt. Die so genannten Atomuhren messen und z¨ahlen diese Perioden. Um die G¨ ute von Uhren beurteilen zu k¨ onnen, bedarf es des imagin¨aren Bildes ¨ der perfekten Uhr (engl. perfect clock). F¨ ur sie gilt die Ubereinstimmung mit der physikalischen Zeit: ctp (t) = t Die perfekte Uhr dient als Maßstab f¨ ur reale Uhren, die die Schwingungen eines Oszillators z¨ ahlen. Sei f die nominelle Frequenz des Oszillators, dann ist 1/f die nominelle Periode einer Schwingung. Jede Schwingung verursacht ein Z¨ ahlereignis, auch Tick genannt. Die Zeit bei Echtzeitsystemen

70

2. Methodische und technische Grundlagen

wird in der Granularit¨ at einer Bezugszeitspanne ∆tG gemessen. Daf¨ ur werden u osung (engl. resolution of time) oder der ¨blicherweise die Begriffe der Zeitaufl¨ Granularit¨ at verwendet. Zu diesem Zweck dient das Z¨ahlen der Ticks, wobei eine gewisse Anzahl nG von Ticks die Bezugszeitspanne ∆tG ergeben soll. Idealerweise gilt f¨ ur eine reale Uhr k: nG

1 = ∆tG f = ctk (tickki+nG ) − ctk (tickki )

i≥0

uckt, dass die i-te Schwingung des Osillators vom Mit tickki wird ausgedr¨ Z¨ ahler der Uhr erfasst wird. Damit verk¨orpert die Uhr in sich zwei Granularit¨ aten der Uhrzeit. Die eine misst die Zeit in Ticks: ctk (tickki ) = i

1 f

Die andere legt als Einheit die Bezugszeitspanne ∆tG zugrunde: ctk (tickki )G = j ∆tG Die folgende Beziehung gilt dabei zwischen i und j: i = j nG + z

0 ≤ z < nG

Technisch gesehen entspricht z dem Z¨ ahler der Uhr, der mit jedem Tick inuckgesetzt krementiert und mit dem Erreichen von nG wieder auf null zur¨ wird. Sind mehrere Granularit¨ aten der Zeitmessung vorhanden, dann kann ein Ereignis e in jeder dieser Granularit¨ aten erfasst werden. Es gibt eine Reihe von Untersuchungen dar¨ uber, inwieweit sich zeitliche Beziehungen u ¨ber unterschiedliche Granularit¨ aten hinweg erhalten oder ver¨andern (vgl. u.a. [16]). Einige wesentliche Ergebnisse werden im Folgenden hergeleitet. Dazu sei exemplarisch unterschieden zwischen den Zeitwerten, die die Uhr k f¨ ur ein Ereignis e in der Granularit¨ at der Ticks und der Granularit¨at der Bezugszeitspanne aufzeichnet: 1 ctk (e) = i = Tk (e) f bzw. ctk (e)G = j ∆tG = Tk,G (e) F¨ ur zwei Ereignisse e1 und e2 folgt unmittelbar: Tk (e1 ) = Tk (e2 ) =⇒ Tk,G (e1 ) = Tk,G (e2 )

2.2

Zeiten und Uhren

71

Die Umkehrung gilt nicht, denn f¨ ur Tk,G (e1 ) = Tk,G (e2 ) k¨onnen e1 und e2 zu unterschiedlichen Ticks erfasst werden: 1 1 −(nG − 1) ≤ Tk (e2 ) − Tk (e1 ) ≤ (nG − 1) f f H¨ aufiger Gegenstand der Verarbeitung bei Echtzeitsystemen ist die Messung von Zeitintervallen und deren Vergleich. Gegeben seien die Ereignisse e1 bis e4 und die Beziehung in Einheiten der Bezugszeitspanne ∆tG : [Tk,G (e1 ), Tk,G (e2 )] = [Tk,G (e3 ), Tk,G (e4 )] W¨ ahrend die beiden Zeitintervalle in Einheiten der Bezugszeitspanne gleich sind, k¨ onnen sie sich in Einheiten von Ticks deutlich unterscheiden: −(2 nG − 1)

1 1 ≤ (Tk (e2 ) − Tk (e1 )) − (Tk (e4 ) − Tk (e3 )) ≤ (2 nG − 1) f f

Aufgabe 2.2.5 (siehe Seite 277) Bei einem Sportwettkampf werden die Start-

zeit und die Zielzeit der Athleten von derselben Uhr gemessen. Die ablesbare Granularit¨ at der Uhrzeit betr¨ agt 1ms. Es ergibt sich, dass dem Athleten, der 9987ms gebraucht hat, der erste und dem Athleten, der 9989ms gebraucht hat, der zweite Platz zuerkannt wird. Ist das auch dann noch richtig, wenn der Messung die Granularit¨ at der Ticks zugrunde liegen w¨ urde?
Teilt der Abstand zwischen zwei Ticks die Bezugszeitspanne ∆tG , dann gibt es keine Abweichung durch die Z¨ ahlung, und es gilt: nG = f ∆tG . ¨ Ublicherweise ist es jedoch so, dass die Bezugszeitspanne ∆tG und der Oszillator mit seiner nominellen Freguenz f gegeben sind. Dann ist nicht zu erwarten, dass der Abstand zwischen zwei Ticks die Bezugszeitspanne teilt und es ist zu runden: nG = f ∆tG 

oder

nG = f ∆tG 

Durch die Diskretisierung des Produktes f ∆tG ergibt sich eine absolute Abweichung von bis zu 1/f innerhalb der Bezugszeitspanne ∆tG . Zus¨atzliche Abweichungen werden dadurch verursacht, dass sich die nominelle Frequenz f von der tats¨ achlichen unterscheidet. Hinzu kommen ¨außere Einfl¨ usse, wie die Temperatur oder der Prozess der Alterung eines Oszillators, die weitere Abweichungen bedingen k¨ onnen. Die Drift einer realen Uhr k kann von ihr selbst nicht festgestellt werden, so dass immer gilt: (ctk (tickki+nG ) − ctk (tickki )) =1 ∆tG

i>0

2.2.5

72

2. Methodische und technische Grundlagen

Erst mittels Zeitnahme durch eine perfekte Uhr p l¨asst sich die Drift der realen Uhr k feststellen: δk (i) =

(ctp (tickki+nG ) − ctp (tickki )) ∆tG

i>0

Eine Drift δk (i) = 1 u ¨ber alle i > 0 charakterisiert somit eine perfekte Uhr. 2.2.2

Beispiel 2.2.2 F¨ ur den Oszillator einer Uhr k sei die nominelle Frequenz mit ahler nG soll so bestimmt werden, dass f = 1/3 · 106 Hz angegeben. Der Z¨ sich eine Bezugszeitspanne von ∆tG = 250µs ergibt:   1 6 10 250µs nG = 3s   1000 = 12 = 83

Wendet man anstelle der Flurfunktion die Feldfunktion an, dann errechnet sich: nG = 84. Das Produkt f ∆tG liegt dazwischen: f ∆tG = 83, 3 Unter der Annahme, dass der Oszillator der Uhr k exakt die nominelle Frequenz f einh¨ alt, bel¨ auft sich die Drift f¨ ur alle j > 0 auf: nG δk (j) = f ∆tG 83 · 3s = 6 10 · 250µs 1 = 1− 250 = 0, 996
Als relative Abweichung oder Driftrate wird das Maß verstanden, bei dem der Wert 0 die perfekte Uhr charakterisiert: ρk (i) = |δk (i) − 1|

i>0

bzw. ρk = maxi>0 {ρk (i)}

2.2

Zeiten und Uhren

73

Die Stabilit¨ at σk ist ein Maß daf¨ ur, wie sehr die Zeitmessung einer realen Uhr k von einer Bezugszeitspanne zur n¨ achsten schwanken kann: σk = maxi>1 |δk (i) − δk (i − 1)| Die Zeitgenauigkeit einer Uhr k (engl. accuracy) steht f¨ ur die absolute Abweichung, d.h. f¨ ur die Zeitspanne, um die die reale Uhr k der perfekten Uhr p vor- oder nachlaufen kann:   αk (i) = ctp (tickki ) − ctk (tickki ) i > 0 Sind mehrere Uhren vorhanden, dann sind die Abweichungen untereinander relevant. Die Driftrate zwischen den Uhren k und l entspricht der relativen Abweichung, die sich zwischen beiden w¨ ahrend einer Bezugszeitspanne ergeben kann: ρkl = maxi>0 {|ρk (i) − ρl (i)|} In einem Verbund V von Uhren, mit k, l ∈ V , ist das Maximum der relativen Abweichung maßgebend: ρV = maxk,l∈V {ρkl } Die Pr¨ azision (engl. precision), auch Gleichlauf genannt, ist ein Maß daf¨ ur, wie sehr zwei Uhren oder ein Verbund von Uhren bei gleicher nomineller Frequenz voneinander abweichen k¨ onnen:   i>0 πkl (i) = ctp (tickki ) − ctp (tickli ) bzw. πV (i) = maxk,l∈V {πkl (i)}

i>0

¨ Uberl¨ asst man einen Verbund von Uhren sich selbst, dann ist damit zu rechnen, dass ihre Zeitgenauigkeit und ihre Pr¨ azision langfristig immer mehr nachlassen. Dabei gilt: αk (nG j) ≤ jρk

und πkl (nG j) ≤ 2j ρkl

j>0

Es sind deshalb Maßnahmen zu ergreifen, die verhindern, dass die absoluten Abweichungen eine vorgegebene Schranke u ¨berschreiten: αk = maxi>0 {αk (i)} ≤ k bzw. πkl = maxi>0 {πkl (i)} ≤ kl

74

2. Methodische und technische Grundlagen

und πV = maxk,l∈V {πkl } ≤ V


















 




Abb. 2.12. Aufgetragen sind die Zeiten, die die perfekte Uhr sowie die realen Uhren k und l

messen. Die Zeitgenauigkeit ρk und die Abweichung ρkl vom Gleichlauf der Uhren k und l sind relative Gr¨ oßen und beziehen sich auf die Bezugszeitspanne ∆tG . Beachte, dass in dieser Abbildung die Diskretisierung durch das Z¨ ahlen von Ticks nicht dargestellt ist.

Um dies zu erreichen, gibt es grunds¨ atzlich zwei Vorgehensweisen (vgl. [114]): ¨ (a) Anderung des Zustandes der Uhr: Es wird durch die Addition oder Subtraktion von Schaltzeiten erreicht, dass die Uhr k einen neuen Wert erh¨ alt, der n¨ aher am Zeitwert der perfekten Uhr liegt. ¨ (b) Anderung an der Z¨ ahlrate der Uhr: Typischerweise gilt f¨ ur nG : nG ≤ ∆tG f < nG + 1 = nG Aus diesem Grund wird zwischenzeitlich der Wert nG in der Uhr verwendet, bis die absolute Abweichung wieder zur¨ uckgedr¨angt ist. Auf diese Weise pendelt die Uhr k um die perfekte Uhr. Die Alternative (b) hat grunds¨ atzlich den Vorteil, dass die Uhrzeit ctk (t) keine Spr¨ unge macht. Problem beider Vorgehensweisen ist jedoch, dass die perfekte Uhrzeit nicht verf¨ ugbar ist. Stattdessen ben¨otigt man eine reale Referenzuhr, die die Rolle der perfekten Uhr annimmt. Aber auch eine Referenzuhr unterliegt den Eigenschaften realer Uhren und somit auch der Eigenschaft der Drift. Die Festlegung und Bereitstellung einer Referenzuhr ist ein weltweites Anliegen, das auf eine lange Tradition zur¨ uckblicken kann (vgl. [2]). Faktisch ist eine entsprechende Uhrzeit auch mit der koordinierten Weltzeit (universal time coordinated oder UTC) gegeben. Realisiert wird sie durch eine Vielzahl von weltweit verteilten Uhren mit unterschiedlichen technischen Auf-

2.2

Zeiten und Uhren

75









Abb. 2.13. Zwei Vorgehensweisen zum Anpassen von Uhren an eine Referenzuhr.

bauten. Jede dieser lokalen Uhren k tr¨ agt ihren Zeitwert U T C(k) bei. In einem aufw¨ andigen Verfahren werden die Zeitwerte aller lokalen Uhren gemittelt und wieder an die Betreiber der lokalen Uhren u ¨bermittelt. Einzelne Betreiber garantieren f¨ ur die Pr¨ azision ihrer Uhr k, z.B. in Deutschland9 die Physikalisch Technische Bundesanstalt in Braunschweig (PTB): πU T C,P T B = maxt>0 |ctU T C (t) − ctP T B (t)| ≤ 10−9 s Die UTC ist ein Zeitwert, der sich am Tagesrhythmus orientiert. Dieser Rhythmus ist jedoch nicht fest, sondern wird insbesondere durch Bremseffekte, haupts¨ achlich verursacht von Ebbe und Flut, immer l¨anger, ein Vorgang, der bezogen auf einen Tag gering und leicht schwankend ist. Jedoch schon zwischen den Jahren 1900 und 1996 sind die Tage eines Jahres zusammengenommen um 62 Sekunden l¨ anger geworden. Diese minimale aber stetige Verl¨ angerung wird in der Uhrzeit UT1 mitgef¨ uhrt. Bei der UTC wird stattdessen in unregelm¨ aßigen Abst¨ anden eine Schaltsekunde (engl. leap second) eingef¨ uhrt. Dies geht in der Weise vor sich, dass die Uhrzeit am Ende eines Tages um eine Sekunde zur¨ uckgesetzt wird, was einer Streckung des Tages, an dem dies geschieht, um eine Sekunde entspricht. Seit der Einf¨ uhrung der UTC Anfang des Jahres 1972 wurde bereits 23-mal eine Schaltsekunde eingef¨ uhrt, die bislang letzte am Anfang des Jahres 2006. Eine Uhrzeit, die sich nicht am Tagesrhythmus orientiert, ist die TAI (franz.: temps atomique international). Ihre Messung startete Anfang des Jahres 1958 und basiert mittlerweile allein auf der Definition der Sekunde. Aufgrund dieser Festlegung entfernt sich die 9

¨ Die entsprechenden Zust¨ andigkeiten sind in Osterreich beim Bundesamt f¨ ur Eich- und Vermessungswesen (BEV) und in der Schweiz beim Bundesamt f¨ ur Metrologie (METAS) angesiedelt.

76

2. Methodische und technische Grundlagen

TAI immer mehr von der UTC und der UT1, die sich unstetig oder stetig an der Rotation der Erde orientieren (siehe Abb. 2.14).



 



 

 
  






    Abb. 2.14. Drift der Zeitwerte UTC und UT1 von der TAI als Referenzuhr.

2.2.4 Uhrzeit und Weckzeit

Die Uhrzeit, die im Rechensystem verwendet wird, leidet grunds¨atzlich darunter, dass sie bereits veraltet ist, sobald sie als beobachteter Zeitwert in einer Variablen ot in einer Prozessausf¨ uhrung zur Verf¨ ugung steht, z.B. mittels Systemaufruf: ot=gettime(); Dieser Effekt der Alterung der Uhrzeit ist zus¨atzlich zu den bereits erw¨ahnten Effekten wie Diskretisierung und Drift zu ber¨ ucksichtigen. Dabei setzt sich die Alterung aus zwei aufeinander folgenden Zeitspannen zusammen: der Zeitspanne, bis die Uhrzeit durch einen entsprechenden Systemaufruf in einer Programmvariablen ot, die eine spezielle Datenstruktur besitzt, zur Verf¨ ugung gestellt wird und der Zeitspanne, in der die nachfolgende Prozessausf¨ uhrung auf den Wert der Variablen ot zugreift. Seien A1 , . . . , Ak die Anweisungen, die den Zeitwert OT der Variablen ot verwenden. Bezogen auf eine perfekte Uhr wird beispielsweise Ak zum Zeituhrt (siehe Abb. 2.15). Das bedeutet jedoch, dass anstelle des punkt tk ausgef¨ uhrung das Ereignis Ereignisses (t, Ak ) zum Zeitpunkt t in der Prozessausf¨ (OT, Ak ) bearbeitet wird. 2.2.3

Beispiel 2.2.3 In einem Logbuch soll zu diskreten Zeitpunkten verzeichnet werden, welchen Wert X eine Messgr¨ oße x besitzt. Dazu wird in einer Programmvariablen ot die Uhrzeit aufgezeichnet, zu der die Messgr¨oße u ¨ber eine Systemfunktion get sensor x() erfragt und in eine Programmvariable ox geschrieben wird. Ein entsprechendes Programmfragment m¨oge so aussehen: while(TRUE){

2.2

Zeiten und Uhren

77

       

 
   














 

 

  

 Abb. 2.15. Die Alterung eines Zeitwertes im Verlauf der Prozessausf¨ uhrung.

: ot=gettime(); ox=getsensor(); writelog(ox,ot); : } Das Zeitdiagramm (siehe Abb. 2.16) verdeutlicht m¨ogliche Abweichungen. So wird in gleichm¨ aßigen Abst¨ anden der Wert der Uhrzeit OT und weniger regelm¨ aßig der Wert OX der Messgr¨ oße ver¨andert. Mit gettime() und getsensor() greift die Prozessausf¨ uhrung nacheinander auf t und x zu. Dabei wird schließlich im Logbuch ein Ereignis (OTj , OXi+1 ) aufgezeichnet, das es nie gegeben hat.














   



 

 



 

 



 





 




Abb. 2.16. Die Wertekombination, die mit den Operationen gettime() und getsensor()

aufgenommen werden, hat es zu keinem Zeitpunkt t gegeben.

Bei den Uhren, die Zeitwerte bereitstellen, gibt es zum einen die isolierten Uhrbausteine. Diese besitzen alle wichtigen Bauteile zur Zeitmessung und deren Abfrage:

78

2. Methodische und technische Grundlagen

Mindestens ein Oszillator, f¨ ur den eine Nominalfrequenz f angegeben ist. Die am weitesten verbreitete Oszillatorfrequenz ist 32768 Hz, die sich durch Teilen auf jede Frequenz 2i Hz, 0 ≤ i ≤ 15 herunterbrechen l¨asst. Bei Oszillatoren ist zu bedenken, dass sie Abweichungen von der Nominalfrequenz besitzen. Diese werden typischerweise von Frequenzabweichungen bezogen auf eine Million Schwingungen angegeben, z.B. ±35ppm10 , was einer Abweichung von weniger als ±4sec pro Tag entspricht. Dies gilt jedoch u ur einen bestimmten Temperaturbereich, ¨blicherweise nur f¨ z.B. zwischen −10◦ und 50◦ . Davon abweichende Temperaturbereiche verursachen erhebliche h¨ ohere Abweichungen, die in den Datenbl¨attern zu den Uhrbausteinen angegeben werden. Verschiedene Teiler der Frequenz und zugeh¨orige Z¨ahlregister. Durch die Teiler wird die Frequenz des Oszillators heruntergebrochen und auf unterschiedliche Z¨ ahler, die alle mit einer eigenen Z¨ahlergrenze nG ausgestattet sind, geleitet. Auf diese Weise lassen sich Uhrzeiten in Millisekunden, Sekunden und Minuten und Kalenderzeiten in Tagen, Monaten und Jahren realisieren. Eine Programmierschnittstelle, um den Uhrbaustein so zu konfigurieren, wie es der Anwendung entspricht. Dazu verf¨ ugt der Uhrbaustein u ¨ber Adress- und Datenleitungen, typischerweise im Multiplexbetrieb, mit deren Hilfe die Teiler und Z¨ ahler gesetzt werden k¨onnen und die Uhr schließlich gestartet wird. Eine Ausgabeschnittstelle, da der Uhrbaustein abgesehen von der Konfigurierung allein als Datenquelle von Uhrzeiten dient. Dabei werden diese Daten einerseits aktiv vom Uhrbaustein erzeugt, wie z.B. die Erzeugung von Unterbrechungsanforderungen (engl. interrupt). Andererseits besteht die M¨ oglichkeit, dass von außen auf die Programmierschnittstelle zugegriffen wird, um die einzelnen Uhrzeiten und Kalenderzeiten nacheinander auszulesen. Bei Letzterem ergibt sich das grunds¨atzliche Problem, dass w¨ ahrend des Lesens die Uhr- und Kalenderzeiten vom Uhrbaustein ver¨ andert werden. Um diese Inkonsistenzen zu verhindern, bieten die Uhrbausteine unterschiedliche Vorkehrungen an. Eine verbreitete ist die, dass der Uhrbaustein u ¨ber eine Statusinformation anzeigt, dass die Ver¨ anderung von Uhr- und Kalenderzeiten in einem begrenzten Zeitintervall in der Zukunft nicht stattfindet. Ein typisches Zeitintervall hat die Dauer von 200µs und reicht damit aus, um die notwendigen Adressier- und Leseoperationen auszuf¨ uhren, bevor die n¨achste Ver¨anderung stattfindet. Weitere Komponenten, die man u ¨blicherweise findet, dienen der Energieaufnahme und -abgabe, der temperaturabh¨angigen Korrektur der Uhrzeit sowie der anwendungsspezifischen Programmierung von Uhrbausteinen. 10

parts per million

2.2

Zeiten und Uhren

 


               

79

     
  

  

  

  


   

  

   

  !   

Abb. 2.17. Blockdiagramm mit den wesentlichen funktionalen Komponenten eines

Uhrbausteins.

Neben der Verwendung isolierter Uhrbausteine gibt es verschiedene M¨ oglichkeiten, auf Referenzuhren wie die UTC zuzugreifen. Die verbreitetste bezieht ihre Eingabe u ¨ber Funk. Entsprechend codierte Zeitwerte besitzen eine garantierte Zeitgenauigkeit, die jedoch zun¨achst nur bezogen auf den Ort gilt, an dem der Sender steht. Auf dem Weg zum Empf¨anger altert der ¨ Zeitwert mit der Dauer der Ubertragung. Beispiel 2.2.4 In Deutschland ist die Physikalisch Technische Bundesanstalt (PTB) in Brauschweig mit der Verbreitung der gesetzlichen Zeit betraut. Dazu wird seit 1970 vom Sender Mainflingen bei Frankfurt am Main auf der Langwelle 77, 5kHz ein gepulstes Zeitsignal gesendet. Die Pulse bilden ein digitales Signal, bei dem innerhalb je einer Sekunde ein 200ms-langes Signal einer logischen 1 und ein 100ms-langes Signal einer logischen 0 entspricht. Die Uhrzeit ist in einem Paket von 60 Bit kodiert und enth¨alt unter anderem: Angaben zu Minute, Stunde, Tag, Woche und Jahr, einen Synchronisierungsmechanismus, damit Empf¨anger den Beginn der Bitfolge erkennen k¨ onnen, und Statusangaben f¨ ur Schaltsekunden und den Beginn von Sommer- und Winterzeit sowie eine Folge von Pr¨ ufbits.

Angaben zur Sekunde k¨ onnen nicht kodiert u ¨bertragen werden, sondern werden durch die je 100ms oder 200ms Signale erkannt. Diese so genannten Sekundenmarken bestehen darin, dass die Amplitude der Sendefrequenz auf etwa 25% abgesenkt wird. Diese fallende Flanke ist von den Empf¨angern als Sekundenbeginn aufzufassen. Erfahrungsgem¨aß ergeben sich hierbei jedoch bereits Abweichungen von bis zu ±25µs f¨ ur die Erkennung der Flanke.


2.2.4

80

2. Methodische und technische Grundlagen

Kann ein Prozess auf einen vorhanden Uhrbaustein unmittelbar zugreifen, dann ist die beschriebene Alterung der Uhrzeit am geringsten. In der Mehrzahl der F¨ alle ist es jedoch so, dass keine unmittelbare Zugriffsm¨oglichkeit besteht und die Uhrzeit vom Betriebssystem oder Laufzeitsystem verwaltet wird. Dann kann ein Prozess nur durch einen Systemaufruf, wie bereits mit gettime() bezeichnet, auf die Uhrzeit zugreifen. Die damit verbundene Verz¨ ogerung kann erheblich sein. In einer einfachen Rechnung l¨asst sich eine grobe, aber durchaus wirksame Korrektur des Wertes der Uhrzeit vornehmen, die davon ausgeht, dass der Zeitwert in etwa der Mitte des Systemaufrufs genommen wurde. Der Korrekturwert wird in zwei oder mehreren aufeinanderfolgenden Systemaufrufen ermittelt, beispielsweise so: ot1=gettime(); ot2=gettime(); otkorr=(ot2-ot1)/2; Dieses kurze Programmst¨ uck beschreibt nur das prinzipielle Muster. Aufgrund unterschiedlicher Ursachen, wie Prozessumschaltungen oder Unterbrechungsanforderungen, kann der Wert von otkorr stark streuen. Deshalb ist es sinnvoll, das Minimum der ermittelten Verz¨ogeungswerte im Weiteren zu verwenden. Bei jedem Zugriff auf die Uhrzeit ist die so bestimmte Verz¨ogerung otkorr hinzuzuaddieren: ot=gettime()+otkorr; Unabh¨ angig von den jeweiligen Betriebssystemen und Laufzeitsystemen bietet der Posix-Standard11 eine Reihe von Funktionen, um programmiertechnisch mit der Uhrzeit umzugehen. Charakteristisch ist zun¨achst das Datenformat, bestehend aus zwei positiven ganzen Zahlen, einmal der Uhrzeit in Sekunden und innerhalb dieser Sekunde in Nanosekunden: struct timespec { long tv_sec; long tv_nsec; }; Typische Funktionen, die f¨ ur den Umgang mit der Uhrzeit angeboten werden, sind solche zur Feststellung der Zeitaufl¨osung, d.h. der Bezugszeitspan11

Posix (portable operating system interface) [47] definiert standardisierte Schnittstellen zum Betriebssystem oder Laufzeitsystem. Anwendungsentwickler sollen so ¨ plattformunabh¨ angige Programme entwickeln k¨ onnen, die nach dem Ubersetzen auf Posix-konformen Systemen ausgef¨ uhrt werden k¨ onnen. Der Posix-Standard ist mittlerweile weit verbreitet. Bei der Vermarktung von Betriebssystemen und Laufzeitsystemen spielt die Vorgabe der Posix-Kompatibilit¨ at eine große Rolle. Oft entpuppt sich die tats¨ achlich bereitgestellte Funktionalit¨ at als unvollst¨ andig, fehlend oder gar falsch, so dass entsprechende Systemaufrufe nur nach eingehender Pr¨ ufung verwendet werden sollten.

2.2

Zeiten und Uhren

81

ne, dem Setzen einer Startzeit f¨ ur die Zeitmessung und der Ermittlung der Uhrzeit: int clock_getres(clockid_t clock_id, struct timespec *resolution); int clock_settime(clockid_t clock_id, const struct timespec *current_time); int clock_gettime(clockid_t clock_id, struct timespec *current_time); Beispiel 2.2.5 Unter

mehrfacher Verwendung des Posix-Systemaufrufs clock gettime() wurde auf einem Rechensystem mit einem Pentium 2 GHz-Prozessor unter dem Betriebssystem RT-Linux nach obigem Muster die Verz¨ ogerung otkorr bestimmt. Bei u ¨ber 1000 Zeitmessungungen lagen die Werte OT KORR zwischen 4.5µs und 11, 5µs, wobei die Verteilung FOT KORR (t) der Werte in Abb. 2.18 dargestellt ist. Aus dieser Untersuchung ist abzulesen, dass die genommenen Zeitwerte mindestens ein Alter von 4, 5µs aufweisen und somit getrost auf jeden Zeitwert, der jemals bei der Prozessausf¨ uhrung genommen wird, hinzuaddiert werden k¨onnen. Insgesamt wird auf diese Weise die Verz¨ ogerung durch den Systemaufruf bezogen auf die obigen Messwerte auf die Zeitspanne von 0µs bis 6µs reduziert. Gleichzeitig ist keinerlei Garantie daf¨ ur gegeben, dass es bei einem Systemaufruf einmal zu gr¨ oßeren Verz¨ ogerungen kommt. Eine solche Garantie kann nur von den Entwicklern eines Echzeitbetriebssystems gegeben werden, die aufgrund ihrer Kenntnis des Betriebssystems und des darunterliegenden Rechensystems die maximalen Verz¨ ogerungen durch gewisse Systemaufrufe nach oben absch¨ atzen k¨ onnen.
Eine weitere interessante Funktion im Posix-Standard geht u ¨ber die reine Beschaffung der Uhrzeit hinaus und verz¨ ogert die Ausf¨ uhrung eines Prozesses um eine angegebene Zeitspanne: int nanosleep(const struct timespec *requested_time, struct timespec *remaining); Dabei ist requested time die beabsichtigte Zeitspanne der Verz¨ogerung, wobei nicht garantiert ist, dass sie auch eingehalten wird. Aus diesem Grund wird in der Variablen remaining mitgeteilt, wie viel von der beabsichtigten Verz¨ ogerungsdauer schon verbraucht wurde. Allgemein finden sich in Betriebssytemen und Laufzeitsystemen absolute oder relative Verz¨ ogerungsfunktionen. Gem¨aß dieser Kategorisierung ist nanosleep() eine relative, da der Bezugszeitpunkt die Ausf¨ uhrungszeit des Systemaufrufs ist. Wird die beabsichtigte Zeitspanne der Verz¨ogerung von

2.2.5

82

2. Methodische und technische Grundlagen

Abb. 2.18. Die Verteilungsfunktion der Ausf¨ uhrungezeiten f¨ ur den Posix-Systemaufruf

clock gettime() unter LinuxRT.

einem Zeitpunkt abh¨ angig gemacht, dann spricht man von einer absoluten Verz¨ ogerungsfunktion. Stellvertretend seien die beiden folgenden Funktionen genannt, die jeweils zum Zeitpunkt t0 + j ∆tG aufgerufen werden. Dabei ist t0 die Startzeit der Uhr und j die Anzahl der Bezugszeitspannen, die seitdem vergangen sind. wait for(tw) verz¨ ogert die Prozessausf¨ uhrung, bis der absolute Zeitpunkt tw , die Weckzeit, erreicht ist. Dieser ergibt sich dadurch, dass die Verz¨ ogerung dw Bezugszeitspannen dauert, d.h., dw ist die zu bestimmende Gr¨ oße in der folgenden Formel: t0 + j ∆tG + dw ∆tG = tw delay for(dw) relative Verz¨ ogerung um die Zeitspanne dw ∆tG . Entsprechend ergibt sich die Weckzeit tw , ab der die Verz¨ogerung der Prozessausf¨ uhrung beendet sein soll, ebenfalls gem¨aß der obigen Formel. Die absoluten oder relativen Verz¨ ogerungsfunktionen richten sich an ein Betriebssystem oder ein Laufzeitsystem und l¨osen intern zwei Operationen aus, die im Folgenden mit enq() und deq() bezeichnet sind (siehe auch Abb. 2.19): enq() Auf den Systemaufruf einer Verz¨ ogerungsfunktion durch einen Prozess muss das Betriebssystem oder Laufzeitsystem diesen Prozess aus dem Zustand rechnend (siehe Abb. 2.8) in einen geeigneten Zustand versetzten.

2.2

Zeiten und Uhren

83

Sowohl f¨ ur unterbrechbare als auch f¨ ur nicht unterbrechbare Prozesse ist es angebracht, daf¨ ur den Zustand beendet zu benutzen. Bei Echtzeitsystemen ist dieser Prozesszustand transient und ber¨ ucksichtigt diesen Prozess solange nicht mehr, bis seine Verz¨ ogerung beendet und seine Bereitzeit gekommen ist (siehe auch Programmfragment Seite 48).



 












Abb. 2.19. Ein h¨ oher priorisierter Prozess h und niedriger priorisierter Prozess l tragen mit

der Operation enq(), ausgef¨ uhrt vom Betriebssystem BS, denselben Weckzeitpunkt tw ein. Mit der Operation deq() versetzt das Betriebssystem beide Anwendungsprozesse h un l in den Zustand rechenbereit.

Der Systemaufruf einer Verz¨ ogerungsfunktion erfolgt sporadisch und dementsprechend auch der Aufruf der Operation enq(). Organisatorisch ist der ausl¨ osende Prozess den Prozessen im Zustand beendet zuzuordnen. Als einfachster Datentyp hierf¨ ur eignet sich die Schlange. deq() Ist die Weckzeit tw erreicht, dann ist der Prozess wieder in den Zustand rechenbereit zu u uhren. Dazu ist jeweils nach Ablauf einer Bezugs¨berf¨ zeitspanne zu pr¨ ufen, ob es Prozesse gibt, deren Weckzeit tw mit der aktuellen Zeit u ¨bereinstimmen. Gibt es mehrere Prozesse, die zu demselben Zeitpunkt zu wecken sind, dann ist bei der priorit¨atsbasierten Prozessausf¨ uhrung derjenige in den Zustand rechnend zu versetzen, der von den Prozessen im Zustand rechenbereit die h¨ochste Priorit¨at besitzt. Alle u oren in den Zustand verdr¨ angt. ¨brigen geh¨ Die Operation deq() erfolgt periodisch, beispielsweise in Abst¨anden der Bezugszeitspanne ∆tG . Die geweckten Prozesse sind organisatorisch den Prozessen im Zustand rechenbereit zuzuordnen. Der einfachste Datentyp hierf¨ ur ist ebenfalls die Schlange. Schlangen werden im Rahmen der Verwaltung von Prozessen typischerweise in der Datenstruktur der linearen Listen abgelegt. So gibt es eine Liste der beendeten Prozesse und eine der rechenbereiten Prozesse. Sinnvollerweise existiert auf diesen Listen eine Ordnung. So ist die Liste der rechenbereiten Prozesse nach der Priorit¨ at der Prozesse zu ordnen, damit unter anderem bei der Operation enq() der n¨ achste rechnende Prozess am Anfang der

84

2. Methodische und technische Grundlagen

Liste steht und unmittelbar bestimmt werden kann. Bezogen auf die Liste der beendeten Prozesse (Weckliste) ist das geeignete Ordnungskriterium die n¨ achstliegende Weckzeit tw eines der Prozesse. Die Operationen enq() und deq() sind bei Echtzeitsystemen sehr h¨aufig auszuf¨ uhren und sollten sehr sorgf¨ altig implementiert sein. Betrachtet man den Aufwand bezogen auf die Datenstruktur der linearen Liste, dann ist der Zugriff auf das Listenelement h¨ ochster Ordnung mit einem Aufwand O(1) verbunden. Dagegen ben¨ otigt der Vorgang des Einordnens, z.B. einen Prozess bei der Operation enq() seiner Weckzeit tw entsprechend in die Liste einzuordnen, einen Aufwand von O(nw ), mit nw der mittleren L¨ange der Weckliste. Angesichts der Erfahrung, dass bei mittleren bis großen Echtzeitanwendungen die Wecklisten typischerweise mehr als 10 Eintr¨age besitzen, ist nach anderen Datentypen als der Schlange Ausschau zu halten. Zwei interessante Datentypen sollten f¨ ur diese sensible Aufgabe erw¨ahnt werden: Der Haufen (engl. heap) In der Datenstruktur des Haufens werden die Prozesse in Form eines linksvollst¨ andigen, bin¨ aren Baumes angeordnet. Dabei ist das Ordnungskriterium des Elternknotes h¨ oher als dasjenige seiner beiden Kindknoten. Jedes Einf¨ ugen (Operation enq()) eines Prozesses mit seiner Weckzeit tw an die passende Stelle im Baum ist mit einem Aufwand von O(log2 (nw )) verbunden. Der Prozess mit der n¨ achstliegenden Weckzeit bildet die Wurzel des Haufens. Mit deq() wird dieser Prozess aus dem Haufen entnommen und mit einem Aufwand von O(log2 (nw )) wieder ein entsprechend geordneter Haufen erzeugt. Insgesamt sind in diesem Zusammenhang zwei Haufen sinnvoll. Einer erfasst alle Prozesse, die sich im Zustand beendet befinden und darauf warten geweckt zu werden. F¨ ur diesen Haufen ist die n¨achstliegende Weckzeit das Ordnungskriterium. In einem zweiten Haufen befinden sich alle Prozesse, die sich im Zustand rechenbereit befinden. F¨ ur diesen Haufen ist das Ordnungskriterium die h¨ ochste Priorit¨ at der Prozesse. Das Zeitrad (engl. timing wheel) Das Zeitrad ist besonders geeignet f¨ ur periodische Prozesse. F¨ ur eine Prozessmenge P = {1, . . . , n}, sei ∆pmax die maximale Periode und wmax diejenige ganze Zahl, f¨ ur die gilt: ∆pmax = ∆tG wmax Kern des Zeitrades ist eine Tabelle der L¨ange wmax sowie zwei Indizes, die auf jeweils auf eine Zeile der Tabelle verweisen (siehe auch Abb. 2.20). Der Index tw %wmax zeigt auf die Weckzeit, zu der ein Prozess bei der Ausf¨ uhrung der Operation enq() einzutragen ist. Der Wert wird als ak-

2.2

Zeiten und Uhren

85

tueller Parameter bei absoluten und relativen Verz¨ogerungsoperationen mitgegeben. Der Index j%wmax entspricht dem aktuellen Zeitpunkt t0 + j ∆tG . In der Tabelle sind unter dieser Zeile diejenigen Prozesse zu finden, deren Weckzeit dem aktuellen Zeitpunkt entspricht. F¨ ur jeden einzelnen dieser Prozesse ist die Operation deq() auszuf¨ uhren. In g¨ unstigen F¨ allen liegt der Aufwand, der f¨ ur die beiden Operationen enq() und deq() zu veranschlagen ist, bei O(1). Das h¨angt damit zusammen, dass in einer Zeile der Tabelle meist kein oder nur ein zu weckender Prozess eingetragen ist. In ung¨ unstigen F¨ allen kann es jedoch so sein, dass alle Prozesse dieselbe Zeile belegen. Damit auch noch f¨ ur diesen Fall eine hohe Effizienz m¨ oglich ist, sollten Prozesse innerhalb einer Zeile bei Bedarf wie ein Haufen organisiert sein. Dabei sollte das Ordnungskriterium wiederum die Priorit¨ at das Prozesses sein, um denjenigen sofort zu finden, der von den zum selben Zeitpunkt zu weckenden Prozessen die h¨ochste Priorit¨ at besitzt.





 







Abb. 2.20. Zwei Indizees arbeiten auf dem Zeitrad. Der Index

j%wmax zeigt auf die Prozesse, die zum augenblicklichen Zeitpunkt








t0 + j ∆tG zu wecken sind und der Index tw %wmax dient dazu, einen zum Zeitpunkt tw zu weckenden Prozess in das Zeitrad eizutragen.

Weitergehende Datenstrukturen, wie beispielsweise die calender queue oder der split tagged tree, und generalisierende Fragestellungen, wie beispielsweise das time queue problem, sind in diesem Zusammenhang zu erw¨ahnen und bei der Implementierung von Verz¨ ogerungsfunktionen zu ber¨ ucksichtigen (vgl. unter anderen [23], [113], [135] und [71]). 2.2.5 Kalk¨ ule der Zeit

Das Rechnen mit Zeiten nimmt seinen Ausgang bei den Zeitpunkten. Sei T die Menge der Zeitpunkte und < eine Ordnungsrelation darauf, die ausdr¨ uckt, dass ein Zeitpunkt x vor einem Zeitpunkt y stattfindet: x
86

2. Methodische und technische Grundlagen

Folgende Axiome gelten vern¨ unftigerweise f¨ ur das geordnete Paar (T, <) (vgl. [52]): ∀x : ¬(x < x)

Irreflexivit¨ at:

∀x, y : x < y ∧ y < z =⇒ x < z

Transitivit¨ at:

Aus diesem beiden Axiomen folgt bereits die Asymmetrieeigenschaft: ∀x, y : x < y =⇒ ¬(y < x)

Asymmetrie:

Die Linearit¨ atseigenschaft vervollst¨ andigt die Beziehung zwischen je zwei Zeitpunkten: ∀x, y : x < y ∨ y < x ∨ x = y

Linearit¨ at:

Erg¨ anzt man (T, <) um das Axiom der Dichtheit, dann ist Isomorphie zu den reellen Zahlen R gegeben: ∀x, y : x < y =⇒ ∃z : (x < z ∧ z < y)

Dichtheit:

Anstelle der dichten linearen Ordnung und damit eines kontinuierlichen Zeitbegriffs l¨ asst sich auch ein diskreter Zeitbegriff einf¨ uhren. Dieser ist im Zusammenhang mit Echtzeit und ihrer Erfassung durch eine Uhr von besonderer Bedeutung: Diskretisierung:

∀x, y : x < y =⇒ ∃z : (x < z ∧ ¬∃u(x < u ∧ u < z)) ∀x, y : x < y =⇒ ∃z : (z < y ∧ ¬∃u(z < u ∧ u < y))

Kommt noch ein Anfangszeitpunkt hinzu und hat jeder Zeitpunkt Nachfolger, so ist (T, <) im diskreten Fall isomorph zu den nat¨ urlichen Zahlen N, die die Grundlage der Planung bei Echtzeitsystemen bilden (siehe beispielsweise die Definition eines Planes, Seite 50): Beginn: Nachfolger:

∀x : x = 0 ∨ 0 < x) ∀x : ∃y : x < y

Die Ordnung auf (T, <) ist total und wird als temporale Ordnung bezeichnet. Im Gegensatz dazu ist die kausale Ordnung, die auf kausalen Beziehungen zwischen Ereignissen beruht, partiell. Aufbauend auf Zeitpunkte lassen sich Zeitintervalle und Zeitspannen definieren. So ist ein Zeitintervall, oder kurz Intervall, im kontinuierlichen wie im diskreten Fall eine Menge von Zeitpunkten: [x, y) = {x} ∪ {z ∈ T | x < z < y}

2.2

Zeiten und Uhren

87

Eine Zeitspanne ist im Gegensatz dazu eine skalare Gr¨oße, die im kontinuierlichen wie im diskreten Fall die Differenz zweier Zeitpunkte angibt: ∆z = x − y

f¨ ur x < y oder x = y

Dabei ist ∆z aus der Menge ∆T der Zeitspannen und es gilt, dass ∆T im kontinuierliche Fall isomorph auf R+ 0 und im diskreten Fall auf N0 abbildbar ist. Auch Zeitspannen sind geordnet, und (∆T, <) bildet eine entsprechende temporale Ordnung. Zwischen zwei Zeitpunkten x und y gibt es, wie das Axiom der Linearit¨at postuliert, drei m¨ ogliche Beziehungen: x


 





      

 



   




   



      



          





  

  






       





Abb. 2.21. Die m¨ oglichen Beziehungen zwischen Intervallen.

¨ Durch Anderung an einer Begrenzung des Intervalls [x1 , x2) oder einer Beandert sich m¨oglicherweise die aktuelle grenzung des Intervalls [y1 , y2 ) ver¨ ¨ Beziehung. Dennoch sind nicht Uberg¨ ange unmittelbar m¨oglich, sondern lediglich bestimmte Nachbarschaften zwischen Beziehungen (siehe Abb. 2.22). W¨ ahrend die bislang eingef¨ uhrten Beziehungen vorrangig qualitativer Art sind, spielen bei Echtzeitsystemen quantitative Eigenschaften eine dominante Rolle. Dabei wird ein Zeitpunkt, zu dem ein Ereignis eintritt, durch eine Uhr

88

2. Methodische und technische Grundlagen








 




 







Abb. 2.22. Nachbarschaft innerhalb der Beziehungen zwischen Intervallen.

der Granularit¨ at G auf einen diskreten Wert j ∈ N abgebildet: TG (e) = j Mit j wird dem Ereignis e die gesamte Bezugszeitspanne Gj = [j∆tG , (j + 1)∆tG ) zugeordnet. Entsprechend umfasst ein Intervall basierend auf den Ereignissen e1 und e2 : (TG (e1 ), TG (e2 )) = {n ∈ N | TG (e1 ) = n1 ∧ TG (e2 ) = n2 ∧ n1 ≤ n < n2 } Eine Zeitspanne hingegen steht f¨ ur die Differenz zweier mit einer Uhr der Granularit¨ at G erfasster Ereignisse e1 und e2 : ∆TG (e1 , e2 ) = (TG (e2 ) − TG (e1 ))∆tG

mit e1 vor e2 oder e1 = e2

Sind mehrere Uhren vorhanden, so gibt es h¨aufig Unterschiede hinsichtlich ihrer Granularit¨ at. Selbst eine Uhr kann u ¨ber verschiedene Granularit¨aten ober als die Granularit¨at G, falls gilt verf¨ ugen. Eine Granularit¨ at G+ ist gr¨ ∆tG < ∆tG+ : G < G+ Eine Granularit¨ at ist harmonisch gr¨ ober als eine andere, wenn die zugrundeliegenden Bezugszeitspannen Vielfache voneinander sind. Gilt also g ∆tG = ur ein g ∈ N, dann wird notiert: ∆tG+ f¨ G ≺ G+ Ein Ereignis, das mit einer Granularit¨ at erfasst worden ist, kann auf eine andere Granularit¨ at abgebildet werden. Diese Abbildung ist mengenwertig, da gegebenenfalls mehrere Zeitpunkte zur Auswahl stehen. F¨ ur die Vergr¨oberung eines Zeitpunktes gilt: (TG (e))G+ = {m ∈ N | m ∆tG+ ≤ TG (e)∆tG < (m + 1)∆tG+ }

2.2

Zeiten und Uhren

89

Zum anderen gibt es die Verfeinerung, die mehrere Zeitpunkte umfasst: (TG+ (e))G = {n ∈ N | TG+ (e)∆tG+ ≤ n ∆tG < (TG+ (e) + 1)∆tG+ } Auf der Grundlage dieser Art der Erfassung von Ereignissen durch eine Uhr ist eine markante Anomalie zu beobachten. Sie a¨ußert sich darin, dass f¨ ur + zwei Ereignisse e1 und e2 , die jeweils mit der Granularit¨at G und G erfasst werden, alle m¨ oglichen Beziehungen R, mit R ∈ {<, =, >}, gelten k¨onnen: ∆tG+ R ∆tG Selbst die Einf¨ uhrung einer noch feineren Granularit¨at stabilisiert die Beziehungen nicht. Beispiel 2.2.6 Betrachtet werden drei harmonische Granularit¨ aten G− ≺ G ≺

G+ :

∆tG+ = 3 ∆tG = 9 ∆tG− Gegeben seien zun¨ achst zwei Ereignisse e1 und e2 , die den verschiedenen Granularit¨ aten entsprechend erfasst werden: TG+ (e1 ) = 0

TG+ (e2 ) = 2

TG (e1 ) = 2

TG (e2 ) = 6

TG− (e1 ) = 6

TG− (e2 ) = 20

Vergleicht man die Zeitspannen auf der Basis der feinsten Granularit¨at G− , dann gilt: ∆tG+ (e1 , e2 ) = 2

entspricht 18 ∆tG−

∆tG (e1 , e2 ) = 4

entspricht 12 ∆tG−

∆tG− (e1 , e2 ) = 14

entspricht 14 ∆tG−

Somit gibt es zwischen ∆tG+ (e1 , e2 ), ∆tG (e1 , e2 ) und ∆tG− (e1 , e2 ) eine wechangige Beziehung. selnde, von der Wahl von e1 und e2 abh¨ Es werden nun zwei weitere Ereignisse e3 und e4 sowie deren Zeitpunkte betrachtet (siehe Abb. 2.23): TG+ (e3 ) = 1

TG+ (e4 ) = 2

TG (e3 ) = 3

TG (e4 ) = 8

TG− (e3 ) = 11

TG− (e4 ) = 24

2.2.6

90

2. Methodische und technische Grundlagen

Vergleicht man nun die Zeitdifferenzen bei unterschiedlichen Granularit¨aten, dann wechseln die Beziehungen ganz und gar unkoordiniert: 2 ∆tG+ = ∆tG+ (e1 , e2 ) > ∆tG+ (e3 , e4 ) = 1 ∆tG+ 4 ∆tG = ∆tG (e1 , e2 ) < ∆tG (e3 , e4 ) = 5 ∆tG 14 ∆tG− = ∆tG− (e1 , e2 ) > ∆tG− (e3 , e4 ) = 13 ∆tG−

Abb. 2.23. Im Zeitdiagramm enthalten sind die Zeitpunkte t1 bis t4 f¨ ur die Ereignisse e1

bis e4 .


Zwangsl¨ aufig stellt sich die Frage, um wie viel gr¨oßer eine Zeitspanne gemessen in der Granularit¨ at G+ sein muss, damit sich die Ordnungsrelation in ¨ G erh¨ alt. Das Ergebnis geht zur¨ uck auf Uberlegungen zur Granularit¨at einer Uhr (siehe 71) und besagt: ∆tG+ (e1 , e2 ) > ∆tG+ (e3 , e4 ) + 2 ∆tG+ ⇒ ∆tG (e1 , e2 ) > ∆tG (e3 , e4 ) Umgekehrt stellt sich die Frage, um wie viel gr¨oßer eine Zeitspanne gemessen in der Granularit¨ at G sein muss, damit sich die Ordnungsrelation in G+ erh¨ alt. Hier gilt, wie in der nachfolgenden Aufgabe bewiesen werden soll: ∆tG (e1 , e2 ) > ∆tG (e3 , e4 ) + (2g − 2)∆tG ⇒ ∆tG+ (e1 , e2 ) > ∆tG+ (e3 , e4 ) 2.2.6

Aufgabe 2.2.6 (siehe Seite 278) Die Granularit¨ aten G und G+ , mit denen

die Ereignisse e1 bis e4 erfasst werden, m¨ogen im harmonischen Verh¨altnis ussen Zeitspannen in G um g ∆tG = ∆tG+ , mit g ∈ N, stehen. Dann m¨ oßer sein, um in jedem Fall auch in der gr¨oberen Granularit¨at (2g − 2)∆tG gr¨

2.2

Zeiten und Uhren

91

G+ gr¨ oßer zu sein: ∆tG (e1 , e2 ) > ∆tG (e3 , e4 ) + (2g − 2)∆tG ⇒ ∆tG+ (e1 , e2 ) > ∆tG+ (e3 , e4 )
Das Rechnen mit Zeitpunkten t ∈ T und Zeitspannen ∆t ∈ ∆T hat auch in der Echtzeitprogrammierung eine große Bedeutung. Folgende Operationen sind es, die immer wieder ben¨ otigt werden: +, − :

T × ∆T → T

+ :

∆T × T → T

− :

T × T → ∆T

+, − : ∆T × ∆T → ∆T Beim Programmieren ist streng darauf zu achten, dass Variablen f¨ ur Zeitpunkte und Zeitspannen nur in der oben beschriebenen Weise benutzt werden. Der Posix-Standard (siehe 80) kennt beispielsweise nur den Datentyp des Zeitpunktes und darauf aufbauend den der Bezugszeitspanne. Dar¨ uber hinaus wird nicht gepr¨ uft, ob die Operationen auf den Variablen den Konventionen der Datentypen entsprechen. Erst in Programmiersprachen mit einem strengen Typkonzept lassen sich entsprechende Operationen realisieren. Beispiel 2.2.7 Die Programmiersprache Ada ist eine mit einem ausgesprochen aufw¨ andigen Typkonzept, das die falsche Verwendung von Variablen und ¨ Operationen bereits beim Ubersetzen der Programme sichtbar werden l¨asst. Ein spezielles Paket Ada.Real-Time f¨ uhrt zun¨achst die Datentypen f¨ ur Zeitpunkte Time und f¨ ur Zeitspannen Time Span ein. Des Weiteren besteht es aus den oben abstrakt beschriebenen Operationen auf T und ∆T. Auszugsweise sei dieses Paket hier wiedergegeben (vgl. [130]): package Ada.Real_Time is type Time is private; : type Time_Span is private; : Tick : constant Time_Span; function Clock return Time; function "+" (Left : Time; Right : Time_Span) return Time; function "+" (Left : Time_Span; Right : Time) return Time; function "-" (Left : Time; Right : Time_Span) return Time; function "-" (Left : Time_Span; Right : Time) return Time_Span;

2.2.7

92

2. Methodische und technische Grundlagen

: function "+" (Left,Right : Time_Span) function "+" (Left,Right : Time_Span) : end Ada.Real-Time;

return Time_Span; return Time_Span;




2.3

Bestimmung der Prozessparameter

93

2.3 Bestimmung der Prozessparameter Die Verfahren der Echtzeitplanung setzen voraus, dass die notwendigen Parameter der Prozesse, die verplant werden sollen, bekannt sind. Im Vordergrund stehen dabei zum einen die Ausf¨ uhrungszeit ∆e und zum anderen die Bereitzeit und die Frist. Die beiden letzten Parameter werden bei periodischen Prozessen durch die Periode ∆p ersetzt. Entwickler im Echtzeitbereich wissen, dass es mit erheblichem Aufwand verbunden ist, die relevanten Parameter bei konkreten Anwendungen zu ermitteln. Eine entsprechende wissenschaftliche Forschung fand lange Zeit nicht statt. Dies ist durch die Analyse von Programmen mit dem Ziel der Ermittlung der l¨ angsten Ausf¨ uhrungszeit (worst case execution time oder WCET) anders geworden. Sowohl in der Theorie als auch in der Praxis hat diese Frage einen bedeutenden Stellenwert erlangt. Deutlich weniger entwickelt sind die Antworten auf die Frage nach den Zeitbedingungen, unter denen einzelne Prozesse auszuf¨ uhren sind. Dabei ist klar, dass nur die vollst¨andige Kenntnis der notwendigen Parameter die Anwendung der Planungsverfahren zul¨ asst. In den folgenden beiden Abschnitten wird dementsprechend zun¨achst die Bestimmung der Ausf¨ uhrungszeit betrachtet und dann die Bestimmung der Zeitbedingungen, insbesondere die Bestimmung der Periode. 2.3.1 Absch¨ atzung der Ausf¨ uhrungszeit

In der Echtzeitplanung wird die Kenntnis der Ausf¨ uhrungszeit eines Prozesses mit großer Selbstverst¨ andlichkeit vorausgesetzt. Tats¨achlich ist f¨ ur einen Prozess ein immenser Aufwand zu treiben, damit seine Ausf¨ uhrungszeit ∆e verl¨ asslich angegeben werden kann. Bestimmende Gr¨oßen sind dabei (siehe Abb. 2.24) das Programm, das der Prozessausf¨ uhrung zugrunde liegt, und der Prozessor, auf dem das Programm ausgef¨ uhrt wird.





 

  
  
  
 


 
 

Abb. 2.24. Datenflussdiagramm f¨ ur die Absch¨ atzung der Ausf¨ uhrungszeit.

Die meisten Aussagen der Echtzeitplanung gelten auch dann noch, wenn im konkreten Fall die Ausf¨ uhrungszeit k¨ urzer ist als der nominelle Wert ∆e, der im Planungsverfahren verwendet wird. Deshalb steht ∆e f¨ ur eine Zeitspanne, die eine obere Schranke f¨ ur jede m¨ ogliche Ausf¨ uhrungszeit ∆X darstellt, und

2.3

94

2. Methodische und technische Grundlagen

es wird f¨ ur den Rest des Unterabschnitts gleichgesetzt: ∆eW CET = ∆e Mit Bezug auf Programm und Prozessor wird ∆eW CET so erkl¨art (vgl. [96]): The worst case execution time (WCET) of a program that runs uninterrupted on a processor is defined as being the maximum possible execution time considering all combinations of input data and all possible execution histories of the system before the program is executed. Bei aller Deutlichkeit, die diese Begriffserkl¨arung besitzt, ist ihre Sinnhaftigkeit in zweierlei Hinsicht zu hinterfragen: Eine Ausf¨ uhrungszeit kann es f¨ ur ein Programm nur geben, wenn es terminiert. Somit ist die Absch¨ atzung der Ausf¨ uhrungszeit mit der 12 upft. Im Umgrunds¨ atzlichen Unl¨ osbarkeit des Halteproblems verkn¨ kehrschluss kann deshalb die Absch¨ atzung der Ausf¨ uhrungszeit nur f¨ ur solche Programme erfolgreich sein, f¨ ur die weitergehende Informationen hinsichtlich der Termination des Programms zur Verf¨ ugung stehen. Dass die Programmausf¨ uhrung ununterbrochen stattzufinden hat, ist von vornherein nur f¨ ur nicht unterbrechbare Prozesse gegeben. Bei unterbrechbaren Prozessen ist davon auszugehen, dass die Dauer der Ausf¨ uhrung durch die Anzahl und die Zeitpunkte der Unterbrechungen beeinflusst wird. Um dennoch mit der Annahme der ununterbrochenen Ausf¨ uhrung operieren zu k¨ onnen, sind Methoden erforderlich, die die Wirkung von Unterbrechungen nachtr¨ aglich noch ber¨ ucksichtigen (vgl. [128] sowie die ¨ Uberlegungen auf Seite 208). Die Begriffserkl¨ arung spricht auch die Abh¨angigkeit von den Eingabedaten des Programms an. Obwohl die Ausf¨ uhrungszeit von den Eingabedaten im Einzelfall sehr entscheidend abh¨angen kann, soll die zu ermittelnur de Ausf¨ uhrungszeit ∆eW CET eines Prozesses davon unabh¨angig sein. F¨ ein terminierendes Programm gibt es keine allgemeing¨ ultige Verteilung der Ausf¨ uhrungszeit ∆X. Erfahrungsgem¨ aß gilt jedoch, dass Standardverteilungen nicht anwendbar sind. Dagegen haben strukturelle Eigenschaften der jeweiligen Programme pr¨ agenden Einfluss. So kann es beispielsweise bei Programmen mit Ausnahmebehandlung dazu kommen, dass Ausf¨ uhrungen, bei denen eine Ausnahme ausgel¨ ost wird, zwar selten vorkommen, dann aber wesentlich mehr Rechenzeit ben¨ otigen als die F¨alle, bei denen keine solche 12

Alan Turing hat in den dreißiger Jahren des letzten Jahrhunderts bewiesen, dass es keine Turingmaschine und damit kein Verfahren gibt, das f¨ ur ein gegebenes Programm entscheidet, ob es f¨ ur alle Eingaben h¨ alt.

2.3

Bestimmung der Prozessparameter

95

Behandlung stattfindet (vgl. [73]). Entsprechend kann der Mittelwert der uhrungszeit ∆emax , gegeAusf¨ uhrungszeit ∆X weit von der maximalen Ausf¨ ben durch ∆emax = max{∆X} entfernt sein. Somit ist der Mittelwert ∆X ungeeignet, um auf die onnen (siehe auch Abb. 2.25). Ausf¨ uhrungszeit ∆eW CET schließen zu k¨

Abb. 2.25. Mit ∆X wird die

datenabh¨ angige Ausf¨ uhrungszeit eines Programms bezeichnet. Je nachdem, ob eine Ausnahmebehandlung stattfindet, schwankt dieser Wert erheblich. Der Seltenheit der Ausnahmebehandlung entsprechend liegt der Mittelwert ∆X weit von der maximalen Ausf¨ uhrungszeit ∆emax entfernt.

Bei Echtzeitanwendungen muss jede einzelne Ausf¨ uhrungszeit ∆X den Zeitbedingungen gen¨ ugen. Dies f¨ uhrt zu der Forderung, dass der Wert ∆eW CET sicher sein muss, was bedeutet: ∆emax ≤ ∆eW CET Des Weiteren sollte ∆eW CET m¨ oglichst dicht bei ∆emax liegen. Aufgabe der WCET-Analyse ist es, beiden Forderungen nachzukommen. Analog dazu uhrungszeit gibt es die BCET13 -Analyse, deren Ziel es ist, die minimale Ausf¨ atzen, was bedeutet, ein sicheres und dichtes ∆emin abzusch¨ ∆eBCET ≤ ∆emin zu ermitteln. Beide Schranken sind immer dort von unmittelbarer Bedeutung, wo danach gefragt wird, wie das Flattern der Ausf¨ uhrungszeit ∆X begrenzt werden kann. Es gilt: ∆eBCET ≤ ∆X ≤ ∆eW CET 13

best case execution time

96

2. Methodische und technische Grundlagen

Mittelbar wirkt sich diese Differenz auf das Flattern der Antwortzeit aus, was wiederum auf technischer Seite beispielsweise Folgen f¨ ur die Stabilit¨at eines Reglers haben kann. Im Folgenden wird ausschließlich auf die WCET-Analyse Bezug genommen14 . Zwei grundlegende Methoden der Analyse lassen sich unterscheiden und anschaulich (anhand der Abbildungen 2.24 und 2.25) vgl.n: Statische WCET-Analyse: Eingabedaten der Analyse sind der Code des Programms und die Eigenschaften des Prozessors. In einem mehrstufigen Analyseverfahren wird die uhrung erAusf¨ uhrungszeit ∆eW CET durch symbolische Programmausf¨ mittelt. Dabei ist die G¨ ute des Verfahrens davon abh¨angig, wie dicht das uhrungszeit ∆emax Ergebnis ∆eW CET von oben an die maximale Ausf¨ herankommt. Dynamische WCET-Analyse: Eingabedatum der Analyse ist der Code des Programms, w¨ahrend der Prozessor unmittelbar zur Ausf¨ uhrung des Programms benutzt wird. Unter Anwendung unterschiedlicher Techniken wird in jedem einzelnen Versuch k die Ausf¨ uhrungszeit ∆Xk gemessen. Das Verfahren ist nur dann sicher, wenn es gelingt, die maximale Ausf¨ uhrungszeit mit in die Messreihe zu nehmen. Dann gilt: ∆emax = ∆eW CET = maxk {∆Xk } Vom theoretischen Standpunkt aus betrachtet versuchen sich beide Ans¨atze an unentscheidbaren Problemen, die ¨ aquivalent zum Halteproblem sind. Erst durch Pragmatik werden diese Probleme praktisch l¨osbar und f¨ uhren mit angemessenem Aufwand zu zufriedenstellenden Ergebnissen. Zu dieser Pragmatik sind zu z¨ ahlen: Die Beschr¨ ankung auf vereinfachte Programmstrukturen, so beispielsweise auf Programme ohne Schleifen (vgl. [125]). Die Verf¨ ugbarkeit von auswertbaren Hinweisen zur Programmausf¨ uhrung, so beispielsweise auf Hinweise des Programmierers, die die Vielzahl der m¨ oglichen Ausf¨ uhrungen eingrenzen (vgl. [73]). Bei beiden Ans¨ atzen zur WCET-Analyse wird das Programm als Eingabedatum verwendet, um daraus intern einen Kontrollflussgraphen (engl. control flow graph oder CFG) aufzubauen. Die Pfade in diesem Graphen bilden die Grundlage f¨ ur weitere Analyseschritte: 14

Die Ergebnisse der WCET-Analyse lassen sich durchweg im Analogieschluss auf die BCET-Analyse u ¨bertragen.

2.3

Bestimmung der Prozessparameter

97

Bei der statischen Analyse werden alle m¨oglichen Pfade bei der symbolischen Ausf¨ uhrung des Programms erfasst, um deren Ausf¨ uhrungszeiten so dicht wie m¨ oglich nach oben abzusch¨ atzen. Bei der dynamischen Analyse ist der Pfad mit der l¨angsten Ausf¨ uhrungszeit zu bestimmen, um diesem auf dem Prozessor auszuf¨ uhren und dessen Ausf¨ uhrungszeit zu messen. Die Knoten des Kontrollflussgraphen werden von sequenziell auszuf¨ uhrenden Anweisungen, den so genannten Basisbl¨ ocken, gebildet. Die Kanten sind der Programmausf¨ uhrung entsprechend gerichtet und repr¨asentieren die Alternativen der Berechnung, die sich aufgrund von Verzweigungen, Schleifen und Funktionsaufrufen ergeben k¨ onnen. Beispiel 2.3.1 Gegeben sei das kurze Programmfragment, das in Basisbl¨ ocke

zerlegt werden soll: a=b+c; d=e*f; if (a!=0){ e=d/a; a=0; } else{ e=b+f; b=0; } c=b+c; b=d+c*c; Die Zerlegung ergibt 4 Basisbl¨ ocke, die durch einen Kontrollflussgraphen miteinander zu verbinden sind (siehe Abb. 2.26).
W¨ ahrend der Kontrollflussgraph bei beiden Analyseans¨atzen eine zentrale Rolle spielt, gehen die Ans¨ atze dar¨ uber hinaus eigene Wege. Dabei verf¨ ugt die statische Analyse u ¨ber eine breitere theoretsche Grundlage, die stark vom Compilerbau beeinflusst ist, und greift auf etablierte Methoden der Ingenieurwissenschaften zur¨ uck. Deshalb wird im Folgenden nur die statische Analyse weiter verfolgt. F¨ ur die dynamische Analyse sei auf weiterf¨ uhrende Literatur verwiesen (vgl. [128]).

2.3.1

98

2. Methodische und technische Grundlagen

Abb. 2.26. Typische Struktur eines

Kontrollflussgraphen f¨ ur eine if then else-Anweisung.

Bei der statischen Analyse besteht das zweite Eingabedatum (siehe Abb. 2.24) im Idealfall in einer formalen Spezifikation desjenigen Prozessors, auf den das Programm ausgef¨ uhrt werden soll. Von besonderem Einfluss sind dabei die unterschiedlichen Ebenen der Speicherhierarchie und die parallele Ausf¨ uhrung von Befehlen in einer Pipeline (siehe hierzu in Abb. 2.27 das Blockdiagramm eines Prozessors in Anlehung an [95]).

Abb. 2.27. Blockdiagramm eines

Prozessors, der sowohl u ¨ber eine Hierarchie von Speichern verf¨ ugt, als auch die Abarbeitung der Befehle in einer Pipeline durchf¨ uhrt.

Speicherhierarchie Bei der Abarbeitung eines Programms wird st¨andig auf Variablen zugegriffen, deren Werte entweder im Hauptspeicher, im Daten-Cache oder in Registern zu finden sind. Auch die Maschinenbefehle stehen im Hauptspeicher oder zus¨ atzlich im Befehls-Cache bereit. Die Zugriffszeiten auf Register und Cache unterscheiden sich um etwa den Faktor 3, w¨ahrend sie zwischen Cache und Hauptspeicher grob bei einem Faktor 50 anzusiedeln sind15 . 15

Diese Faktoren sollen lediglich die Gr¨ oßenordung angeben und beziehen sich auf einzelne Zugriffe. Bei blockartigen Zugriffen (engl. burst mode) liegen sie deutlich niedriger.

2.3

Bestimmung der Prozessparameter

99

Bei der Gr¨ oßenordnung der Faktoren ist es unerl¨asslich, die jeweils g¨ unstigste Speicherform bei der WCET-Analyse zu ber¨ ucksichtigen und auf diese Weise eine Ausf¨ uhrungszeit ∆eW CET zu berechnen, die dicht bei der maximalen Ausf¨ uhrungszeit ∆emax liegt. Im einzelnen ist dazu die genaue Kenntnis der Zugriffszeiten sowie der Gr¨oße und der Struktur der Speicher erforderlich. Das gilt in besonderm Maße f¨ ur den Cache, der von zwei Seiten in die Speicherhierarchie eingebunden ist. Ein Cache ist typischeweise in Form von Bl¨ ocken, den so genannten cache ¨ lines, organisiert, z.B. in Einheiten von 32 Byte. Uber die Adresse einer Variablen oder eines Maschinenbefehls wird ein solcher Block oder Teile davon angesprochen. Diese Adressierung kann direkt oder assoziativ erfolgen. Bei den meisten Prozessoren werden die beiden M¨oglichkeiten in einem n-way assocative cache vereinigt, wobei ein Teil der Adresse direkt ein cache set identifiziert und ein Teil der Adresse assozativ den Block im cache set identifiziert. Im Verlauf der Programmausf¨ uhrung wird es immer wieder Zugriffe auf Adressen von Variablen oder Maschinenbefehlen geben, die gerade nicht im Daten- oder Befehls-Cache enthalten sind. Dann ist zun¨achst ein Block im Cache auszuw¨ ahlen, der mit dem adressierten Block im Hauptspeicher zu u ¨berschreiben ist. Dieser Vorgang heißt Nachladen und kann beim ¨ Daten-Cache vor dem Uberschreiben noch ein Zur¨ uckschreiben des alten Cache-Blocks erforderlich machen, sofern dessen Inhalt w¨ahrend des Aufenthaltes im Cache ver¨ andert wurde. F¨ ur die Auswahl des Cache-Blocks, der u ¨berschrieben werden soll, haben sich Verfahren nach dem LRU16 -Prinzip bew¨ahrt. Dazu besitzen die Cache-Bl¨ ocke Schalter, aus denen ersichtlich wird, wie lange kein Zugriff auf diesen Block mehr erfolgt ist. Ein Block, bei dem ein solcher Zugriff ¨ am l¨ angsten zur¨ uckliegt, ist Kandidat f¨ ur das Uberschreiben. Pipelining Das Pipelining ist eine Form der Parallelausf¨ uhrung einzelner Befehle. Die Befehlsausf¨ uhrung teilt sich dabei mindestens in die Phasen: FETCH DECODE EXECUTE WRITE BACK Alle Phasen k¨ onnen auf eine Folge unmittelbar hintereinander auszuf¨ uhrender Maschinenbefehle gleichzeitig angewendet werden. So kann das Ergebnis eines Befehls gerade zur¨ uckgeschrieben werden, w¨ahrend 16

least recently used

100

2. Methodische und technische Grundlagen

der nachfolgende Befehl ausgef¨ uhrt, der Befehl danach erkannt und der n¨ achste Befehl bereits aus dem Speicher geholt wird. Bei unverzweigter Programmausf¨ uhrung kann die Pipeline ihre volle Parallelit¨ at ausnutzen. Dennoch kommt es auch dabei noch zu Turbulenzen, wenn die Phasen nicht dieselbe Dauer haben, was beispielsweise bei der Ausf¨ uhung verschiedener arithmetischer Operationen der Fall ist. Ohne weitere technische Vorkehrungen kommt es dann zum Stau f¨ ur die nachfolgenden Befehle, die bereits im vorderen Teil der Pipeline bearbeitet werden. Um dem zu begegnen, werden Befehle, deren Ausf¨ uhrungsergebnisse nicht voneinander abh¨ angen, soweit gleichzeitig ausgef¨ uhrt, wie Rechenkapazit¨ at zur Verf¨ ugung steht. Dazu sind in der Zentraleinheit Puffer f¨ ur die als n¨ achste abzuarbeitenden Befehle vorzusehen. Des Weiteren werden mehrere funktionale Einheiten ben¨otigt, damit Befehle gleichzeitig ausgef¨ uhrt werden k¨ onnen. So ergibt es sich, dass die Befehlsausf¨ uhrung bis zu einem bestimmten Grad nicht mehr der Reihenfolge entspricht, wie sie im Maschinenprogramm vorgegeben ist. Dies bezeichnet man auch als out of order execution. Durch sie wird eine wesenlich gleichf¨ormigere Auslastung aller Komponenten der Pipeline und damit auch eine h¨ohere Prozessorleistung erreicht. Programmausf¨ uhrungen mit Verzeigungen stellen ein besonderes Problem f¨ ur das Pipelining dar. Bei jeder bedingten Verzweigung ist, bevor das Ergebnis einer Bedingung feststeht, schon zu entscheiden, welcher n¨achste Befehl in die Pipeline geholt werden soll. So werden spekulativ immer wieder Befehle in die Pipeline geholt, d¨ urfen jedoch nicht ausgef¨ uhrt werden, weil die Auswertung der Bedingung ein anderes Ergebnis als das spekulative ergeben hat. Stattdessen sind nachtr¨aglich die richtigen Befehle zu holen, und die vorangegangenen Phasen der Befehlsausf¨ uhrung waren umsonst. Bedingte Verzweigungen kommen h¨ aufig in Programmen vor. Statistisch ist unter 10 Maschinenbefehlen mehr als eine bedingte Verweigung. Eine weitere statistische Erkenntnis besagt, dass jede Verzweigung im Kontext ihres Programms eine ungleichgewichtige Wahrscheinlichkeitsverteilung daf¨ ur besitzt, welches Ergebnis die jeweils n¨achste Auswertung der Bedingung ergibt. Charakteristischerweise ist es so, dass das Ergebnis der letzten Auswertung mit großer Wahrscheinlichkeit mit der n¨achsten Auswertung u ¨bereinstimmt. Aus diesem Grund besitzen Prozessoren einen Puffer von Sprungzielen, in dem die Ergebnisse der zuletzt ausgef¨ uhrten Bedingungen sowie die Adressen der zugeh¨origen Befehle gespeichert sind. uhrung der bedingten VerSpekulativ werden deshalb f¨ ur die n¨ achste Ausf¨ zweigung diejenigen Befehle in die Pipeline geholt, die auch bei der letzten Ausf¨ uhrung zum Zuge gekommen sind.

2.3

Bestimmung der Prozessparameter

101

Beide, Speicherhierarchie und Pipelining, haben Einfluss auf die maximale Ausf¨ uhrungszeit, beeinflussen sich aber auch gegenseitig. Die symbolische Ausf¨ uhrung eines Programms muss deshalb beide Einfl¨ usse und deren Wechselwirkung ber¨ ucksichtigen. Ansatzpunkt f¨ ur die symbolische Ausf¨ uhrung sind die Basisbl¨ocke, die Maschinenbefehl f¨ ur Maschinenbefehl abarbeiten. Dazu dienen zwei Funktionen: nextInst(bb) stellt f¨ ur die Abarbeitung eines Basisblocks bb den n¨achsten Maschinenbefehl x bereit. execSymb(x, c) bearbeitet den Befehl x im Kontext der anderen Befehle symbolisch auf dem Prozessor, wobei c der aktuelle Inhalt des Daten- und Befehls-Cache ist. Das Ergebnis ist das Wertepaar (c , ∆y), bestehend aus dem neuen Cache c und der Dauer ∆y, die der Befehl x beitr¨agt. Verfahren 2.3.1 Symbolische Ausf¨ uhrung eines Basisblocks bb und Berech-

nung von dessen Ausf¨ uhrungszeit ∆eW CET (bb). Zu Beginn des Verfahrens ugung. stehe der Cache INCache (bb) zur Verf¨ wcet(bb):: c = INCache (bb); WHILE x = nextInst(bb) DO BEGIN (c, ∆y) = execSymb(x, c); ∆eW CET (bb) = ∆eW CET (bb) + ∆y; END OU TCache (bb) = c;




Am Ende ist f¨ ur jeden Basisblock bb der Inhalt des Cache, so wie er hinterlassen wird, und die Ausf¨ uhrungszeit ∆eW CET (bb) berechnet. Je gr¨oßer der Inhalt des Cache am Anfang des Basisblocks ist, um so h¨oher ist die Trefferrate daf¨ ur, dass ein Speicherzugriff schon im Cache befriedigt werden kann. Entsprechend niedriger ist die berechnete Ausf¨ uhrungszeit ∆eW CET (bb). Da vor jedem Basisblock bb einer aus einer Menge vom Basisbl¨ocken abgearbeitet worden ist, darf INCache (bb) nur die Cache-Inhalte voraussetzen, die, egal welcher Vorg¨ angerblock aus pred(bb) ausgef¨ uhrt wurde, unbedingt erwartet werden kann. Somit ist die Schnittmenge der Cache-Inhalte der Vorg¨anger bestimmend:  INCache (bb) = OU TCache (b) b∈pred(bb)

Diese Formel erscheint einleuchtend. Aber sie gibt nicht die Strukturen wieder, die auf verschiedenen Pfaden b ∈ pred(bb) im Cache vorzufinden sind. Dies macht das folgende Beispiel deutlich:

2.3.1

102

2.3.2

2. Methodische und technische Grundlagen

Beispiel 2.3.2 In Fortsetzung von Beispiel 2.3.1 werden die Inhalte der CacheBl¨ ocke f¨ ur die verwendeten sechs Variablen berechnet. Geht man davon aus, dass jede dieser Variablen in einem anderen Cache-Block liegt und nur maximal 4 Cache-Bl¨ ocke im Cache verbleiben k¨onnen, dann wird es notwendig, Cache-Bl¨ ocke zu u ¨berschreiben, wenn andere ben¨otigt werden. Ausgehend von INcache (BB1) = ∅ ergibt sich am Ende des ersten Basisblocks, dass nur vier der sechs Variabalen bzw. deren Basisbl¨ocke noch vorhanden sein k¨onnen. Da zuerst die Variablen b und c referiert werden, wird nach dem LRU-Prinzip am Ende von Basisblock BB1 nur die Menge OU Tcache (BB1) = {a, d, e, f } u ¨brig bleiben. Bei der obigen mengenbasierten Beschreibung geht die Rangfolge, die nach dem LRU-Prinzip eine Rolle spielt, verloren. Hier eignet sich die Darstellung des Zustandes als geordnetes Quadrupel besser. Denn aus der Reihenfolge soll hervorgehen, wer als letzter vor den vorangehenden referiert wurde. So ergibt sich nach dem Ende des Basisblocks BB1 die folgende erweiterte Zustandsbeschreibung:

OU TCache (BB1) = (d, e, f, a) In diesem Quadrupel ist der Cache-Block, der die Variable a enth¨alt, derjenige, der bei Bedarf als n¨ achster u ¨berschrieben wird. Die Zustandbeschreibung OU TCache (BB1) ist diejenige, die zur Eingangsbeschreibung der Basisbl¨ocke BB2 und BB3 wird. Am Ende der beiden Basisbl¨ocke BB2 und BB3 ergeben sich folgende Zust¨ ande: OU TCache (BB2) = (a, e, d, f ) OU TCache (BB3) = (b, e, f, d) Im Schnitt beider sind die Cache-Bl¨ ocke der Variablen d, e und f enthalten. Nur diese drei Cache-Bl¨ ocke liegen f¨ ur die weitere Berechnung garantiert im Cache. Wenn nun im Basisblock BB4 der Cache-Block mit der Variablen b ben¨ otigt wird, ist er, je nachdem ob BB2 oder BB3 vorher durchlaufen wurden, im einen Fall nachzuladen und im anderen noch vohanden. Eine Verschmelzung der beiden Pfade, wie sie zur Berechung von INCache (bb) vorgenommen wird, vernachl¨ assigt diese Kenntnis zu dem Preis, dass f¨ ur jeden Fall ein Nachladen einkalkuliert wird. Dies f¨ uhrt letztendlich zu einer pessimistischen Einsch¨ atzung der Ausf¨ uhrungszeit.
Im n¨ achsten Schritt sind die Knoten des Kontrollgraphen mit den ermittelten Ausf¨ uhrungszeiten zu attributieren. Ein Attribut, das jedem Basisblock bb zuzuordnen ist, gibt die Anzahl nbb der Ausf¨ uhrungen des Basisblocks w¨ ahrend einer Programmausf¨ uhrung an. Oft ist die Zahl der Ausf¨ uhrungen

2.3

Bestimmung der Prozessparameter

103

nbb nicht explizit bekannt, sondern steht in impliziter Beziehung mit anderen Basisbl¨ ocken. Schematisch l¨ asst sich dies an einer einfachen if-Anweisung verdeutlichen. BB1; if(BB1) BB2; else BB3; BB4; Die implizite Beziehung der Ausf¨ uhrungen der Basisbl¨ocke 1 bis 4 l¨asst sich in der folgenden linearen Gleichung ausdr¨ ucken: n1 = n2 + n3 = n4 Grunds¨ atzlich sind f¨ ur die Berechnung der Ausf¨ uhrungszeit alle m¨oglichen Pfade zu ber¨ ucksichtigen, was dem Verfahren den Namen implicit path enimeration technique oder IPET eintr¨ agt. Die Zahl der Ausf¨ uhrungen von Basisbl¨ ocken wird dabei durch lineare Gleichungen der folgenden Form erfasst: abb nbb + c = 0 bb∈BB

Gesucht ist unter diesen Randbedingungen nach dem gr¨oßten Wert f¨ ur: nbb ∆eW CET (bb) bb∈BB

Das Ergebnis der Maximierung dieser Zielfunktion ist die gesuchte Ausf¨ uhrungszeit ∆eW CET . Die Techniken, die zur L¨osung dieses Problems notwendig sind, finden sich als etablierte Verfahren der linearen Optimierung. Bei aller ingenieurm¨ aßigen Finesse der statischen WCET-Analyse und der Verf¨ ugbarkeit kommerzieller Werkzeuge (vgl. [20] und [141]) bleibt die sichere und dichte Absch¨ atzung der Ausf¨ uhrungszeit eine Herausforderung. Unter anderem sind folgende Schwachstellen zu bedenken: Die statische Analyse setzt die Modellierung eines realen Prozessors in Form eines softwaretechnisch emulierten Prozessors voraus. Dies stellt ein umfangreiches und aufw¨ andiges Problem dar und wurde weiter oben in der abstrakten Funktion execSymb() versteckt. Tats¨achlich ist als Grundlage daf¨ ur eine formale Spezifikation der Prozessorhardware erforderlich, was in der Regel nicht gegeben ist. Es kommt hinzu, dass es zu Anomalien im Zeitverhalten von Prozessoren kommen kann. So kann die plausible Annahme, dass ein großer Cache-Inhalt zu k¨ urzeren Ausf¨ uhrungszeiten f¨ uhrt, im Einzelfall nicht gehalten werden (vgl. [31] und [90]).

104

2. Methodische und technische Grundlagen

Es ist eine Wechselwirkung zwischen Kosten und Zeit auf der einen und der G¨ ute der ermittelten Ausf¨ uhrungszeit auf der andern Seite festzustellen (vgl. [95]). Ohne sorgf¨ altige Expertise der Programmierer und Entwickler von Programmen f¨ ur Echtzeitanwendungen kommen die Analysen nicht aus. Sie erfordert Zeit und verursacht Kosten. Gleichzeitig sollen die Entwicklungszyklen immer k¨ urzer werden. Daneben sind immer ¨ ofter fremde Softwarekomponenten zu integrieren, und die verwendete Hardware, insbesondere die Prozessoren, werden durch schnellere und vielseitigere ersetzt werden. Trotz aller Beteuerungen (vgl. [141]) haben die verf¨ ugbaren Werkzeuge große Probleme mit dem Stand der Technik Schritt zu halten. ¨ Aus diesen Gr¨ unden soll dieser Unterabschnitt als eine breite Ubersicht verstanden werden, die die grundlegenden Techniken der WCET-Analyse einf¨ uhrt, die Probleme beim praktischen Einsatz der Analsysewerkzeuge aufzeigt und Verweise auf weiterf¨ uhrende Literatur gibt (vgl. [31], [90] und [141]). 2.3.2 Ableitung von Zeitbedingungen

Es gibt sehr unterschiedliche Ans¨ atze, die sich mit der Bestimmung der Prozessparameter Bereitzeit und Frist bzw. Periode auseinandersetzen. Einer der Ans¨ atze stammt aus dem Fachgebiet der Regelungstechnik, wobei digitale Regler betrachtet werden, deren Regelalgorithmen periodisch ausgef¨ uhrt werden. Gesucht wird nach m¨ oglichst kurzen Perioden, die einerseits Qualit¨ atseigenschaften des Reglers verbessern, so beispielsweise zu eine Verringerung des Flatterns f¨ uhren, und andererseits immer noch brauchbare Pl¨ane besitzen (vgl. [30] und [103]). Ein weiterer Ansatz ist in der so genannten Sensitivit¨atsanalyse (engl. sensitivity analysis) zu sehen. Das Anliegen dieser Forschungsrichtung ist weit gefasst. So wird versucht, alle Prozessparameter dahingehend anzupassen, dass gewisse Qualit¨ atsmerkmale erreicht oder verbessert werden. Dies wird an folgendem Zitat deutlich (vgl. [18]): If a task set is not feasible, sensitivity analysis provides a quantitative indication of the actions required to bring the system back into a feasible state. Brauchbarkeit ist nicht das einzige Qualit¨atsmerkmal der Planung. Gleichrangige Ziele sind unter anderen die Verringerung der maximalen Antwortzeit und der Beschr¨ ankung des Flatterns. Dies wurde auch von der Sensitivit¨atsanlyse erkannt. Zwar stand bislang die Modifikation von Ausf¨ uhrungszeiten im Vordergrund (vgl. [14]). Mittlerweile wird jedoch auch die Modifikation der Periode immer ¨ ofter in Betracht gezogen (vgl. [72] und [14]). Alle diese

2.3

Bestimmung der Prozessparameter

105

Ans¨ atze tragen dazu bei, die Qualit¨ atsmerkmale der Planung zu verbessern. Allerdings setzt die Sensitivit¨ atsanlyse bereits die Kenntnis von Prozessparametern voraus, um dann deren gezielte Modifikation zu betreiben. Davor ist jedoch die Frage zu kl¨ aren, auf welcher Grundlage sich insbesondere der Prozessparameter der Periode u ¨berhaupt erst ergibt. Dieser grundlegenden Frage wendet sich der begonnene Abschnitt vorrangig zu. Abgeleitet aus dem Grundmodell eines Echtzeitsystems wird unterschieden zwischen dem technischen System und dem Rechensystem. Letzteres besteht aus Rechenprozessen, die auf der Grundlage der Daten, die das Messsystem bereitstellt, versuchen, den Zustand des technischen Systems zu erfassen, zu bewerten und zu beeinflussen. Die entsprechende Handlung wird durch eine Steuerfunktion (control action oder kurz CA) beschrieben. Sie besteht aus einer Bewertung des aktuellen Zustands auf der Grundlage der Daten, die das Messsystem liefert, und einer entsprechenden Aktion, die sich an das Stellsystem richtet. Programmiertechnisch ist die Steuerfunktion ein Programmfragment mit Variablen, die dazu dienen, den Zustand des technischen Systems zu beschreiben oder zu beeinflussen. In diesem Sinne sei zun¨achst das technische System selbst durch die Wertebereiche V = {V1 , . . . , Vh } erfasst. Die Wertebereiche OV = {OV1 , . . . , OVh } stellen die observierten Werte oder Abbilder des technischen Systems im Rechensystem dar (siehe Abb. 2.28). Jede Gr¨ oße x, x ∈ {1, . . . , h} des technischen Systems, die durch einen Sensor des Messsystems erfasst wird, stellt dem Rechensystem diese Messwerte zur Verf¨ ugung. Im allgemeinsten Fall beschreibt die Sensorrelation die Beziehung zwischen den Werten im technischen System und deren Abbildern im Rechensystem: SRx ⊆ Vx × OVx

     





      Abb. 2.28. Diagramm

Dieser Ansatz schließt ein, dass ein und derselbe Wert der technischen Gr¨oße x durch den Sensor auf unterschiedliche Werte im Rechensystem abgebildet werden kann. Umgekehrt ist es m¨ oglich, dass ein und derselbe Wert im Re-

106

2. Methodische und technische Grundlagen

chensystem von unterschiedlichen Werten, die der Sensor erfasst hat, stammt. Damit wird in der Sensorrelation jedwede wertem¨aßige Abweichung, die von einem Sensor ausgehen kann, darstellbar. In entsprechender Weise verh¨alt es sich mit dem Stellsystem, das f¨ ur eine Gr¨oße y, mit y ∈ {1, . . . , h}, durch die Aktorrelation repr¨ asentiert wird: ARy ⊆ OVy × Vy 2.3.3

Beispiel 2.3.3 Zur Verdeutlichung von Sensor- und Aktorrelationen sei auf das Beispiel 1.2.1 der Wippe zur¨ uckverwiesen. Hier werden eingabeseitig mit Hilfe eines Kamerabildes die Positionsdaten der Kugel erfasst. Ausgabeseitig werden die Motoren so angesteuert, dass die Kugel die Fl¨ache, auf der sie sich bewegt, nicht verl¨ asst. Das Rechensystem besteht aus verschiedenen Prozessen, von denen einer die Steuerfunktion u ¨bernimmt, die aus der Position und anderen Zustandsdaten eine Neigungsvorgabe f¨ ur die Fl¨ache errechnet (siehe auch Abb. 1.5). Die Sensorrelation SRp setzt die Position p der Kugel im technischen System in Beziehung zur Positionsangabe op, wie sie im Prozess, der die Steuerfunktion ausf¨ uhrt, vorliegen. Dabei ist es so, dass aufgrund vielf¨altiger Ursachen, z.B. durch die Vibration des Gest¨ anges, an dem die Kamera montiert ist, eine Position p = (100, 200) auf dem Weg durch das Messsystem einmal als Positionsangabe op = (102, 199) und einmal als Positionsangabe op = (97, 198) im Rechner zur Verf¨ ugung steht. Umgekehrt kann eine im Rechensystem vorliegende Postion op = (102, 199) von der Position p = (100, 200) der Kugel im technischen System stammen. Ebenso ist es m¨oglich, dass andere Positionswerte im technischen System, wie beispielsweise p = (105, 197), vorgelegen haben und auf dem Weg durch das Messsystem im Rechensystem zur beobachteten Postion op = (102, 199) gef¨ uhrt haben. Charakteristisch f¨ ur Sensoren und Aktoren ist das Vorliegen solcher Mehrdeutigkeiten. Bei zuverl¨ assigen Systemen muss jedoch gelten, dass sie nicht unbegrenzt sind. Das m¨ undet in die Forderung nach Garantien, die Hersteller von Sensoren und Aktoren, die Entwickler von Mess- und Stellverfahren sowie die Konstrukteure der Systemarchitektur in der Weise abgeben m¨ ussen, dass gewisse Abweichungen nicht u ¨berschritten werden. Sensor- und Aktorrelationen stellen die formale Beschreibungsebene dar, die diese Garantien verk¨ orpern. Die nachfolgende Tabelle gibt eine schematische Realisierung der Sensorrealtion SRp der Position der Kugel wieder:

2.3

Bestimmung der Prozessparameter

SRp

107

OP

P × × ×

× × ×

× ×

× ×

× ×

× ×

× ×

× ×

× × ×

× ×

× × ×

× × ×

× × ×

× × ×

× × ×

× × ×

× ×

×

Einer Positionsangabe p k¨ onnen in begrenztem Rahmen mehrere observierte Positionsangaben entsprechen. Umgekehrt kann eine observierte Positionsangabe op aus einem begrenzten Bereich von Kegelpositionen auf der bewegten Fl¨ ache stammen.
Die Prozesse des Rechensystems f¨ uhren Programme aus, die Zugriff auf Variablen besitzen, deren Werte lediglich Abbilder des technischen Systems darstellen. F¨ ur einen periodischen Prozess, der auf der Grundlage einer technischen Gr¨ oße x eine andere technische Gr¨ oße y beeinflussen soll, stehen daf¨ ur die Werte der Variablen ovx und ovy zur Verf¨ ugung. Die Steuerfunktion CA wird dadurch realisiert, dass, angestoßen durch einen neuen Messwert, der aktuelle Zustand erfasst und mit der Bedingung C u uft wird. Im positiven Fall ¨berpr¨ erfolgt daraufhin eine Handlung A mit Auswirkung auf das Stellsystem. Ein zeitgesteuerter periodischer Prozess ist demnach grunds¨atzlich so aufgebaut: P(i):: while(TRUE){ wait_until(t); : ovx=sensor_x.get(); if (C(ovx,ovy)) ovy=A(ovx,ovy); actuator_y.set(ovy); : t=t+period(i); } Ist die jeweilige Sensorrelation bekannt, dann lassen sich die Abweichungen, die eine technische Gr¨ oße x durch das Messsystem erf¨ahrt, erfassen und nutzen: F¨ ur die Menge OM ⊂ OVx von Werten, die im Rechensystem vorliegen, bezeichnet dom(SRx , OM ) = {vx ∈ Vx | ovx ∈ OM ∧ (vx , ovx ) ∈ SRx }

108

2. Methodische und technische Grundlagen

die Menge der Werte, die im technischen System vorgelegen haben k¨onnen und auf dem Weg durch das Messsystem nun im Rechensystem als Wert ugung stehen. ovx ∈ OM in der Variablen ovx zur Verf¨ F¨ ur die Menge M ⊂ Vx von Werten im technischen System bezeichnet img(SRx , M ) = {ovx ∈ OVx | vx ∈ M ∧ (vx , ovx ) ∈ SRx } die Menge der Werte, die auf dem Weg durch das Messsystem im Rechenugung stehen system als Wert ovx ∈ OM in der Variablen ovx zur Verf¨ k¨ onnen. In analoger Weise steht auf der Grundlage der Aktorrelation die Abweichung fest, die sich durch das Stellsystem auf eine technische Gr¨oße y ergibt: img(ARy , OM ) = {vy ∈ Vy | ovy ∈ OM ∧ (ovy , vy ) ∈ ARx } dom(ARy , M ) = {ovy ∈ OVy | vy ∈ M ∧ (ovy , vy ) ∈ ARx } Neben den wertem¨ aßigen Abweichungen spielen in Echtzeitanwendungen auch die zeitm¨ aßigen Abweichungen eine bedeutende Rolle. Zu verstehen sind darunter alle zeitlichen Verz¨ ogerungen, die mit dem Messsystem, dem Rechensystem und dem Stellsystem verbunden sind. Ein Wert vx des technischen Systems, der mit einem Sensor erfasst worden ist, unterliegt typischerweise kontinuierlichen und diskreten Ver¨ anderungen. Wenn er als Wert ovx in der Variablen ovx der Steuerfunktion CA zur Verf¨ ugung steht, ist er bereits gealtert. Diese Eigenschaft der technischen Gr¨oßen wird mit dem Begriff der Alterung (etwas abgewandelt auch mit dem Begriff perishable, vgl. [10]) belegt. Zur Quantifizierung des Ph¨ anomens der Alterung ist in der Fachliteratur die Definition der temporalen Konsistenz getreten, begrifflich bewußt angelehnt an die Konsistenzeigenschaft bei Datenbanken. So wird einer Variablen ovx die absolute temporale Konsistenz (engl. absolute temporal consistency) ∆atcx zugeordnet, falls ausgehend vom Zeitpunkt t des Zugriffs auf die Variable irgendwann im Zeitfenster [t − ∆atcx , t] die Werte der Gr¨oße x im technischen System und im Rechensystem einmal u ¨bereingestimmt haben (vgl. [10]), d.h.: vx = ovx Diese Definition wurde mehrfach aufgegriffen (vgl. beispielsweise [78]) und weiterentwickelt (vgl. beispielsweise [75]), greift jedoch jedoch unter verschiedenen Gesichtspunkten zu kurz (vgl. [145]): Die Zeitspanne, die der Sensor und das Rechensystem mindestens ben¨ otigen, bis ein neuer Wert in der Variablen ovx vorliegt, bleibt unber¨ ucksichtigt. Wenn diese Zeitspanne ∆btcx betr¨agt, dann ist

2.3

Bestimmung der Prozessparameter

109

[t − ∆atcx , t − ∆btcx ] das maßgebliche Zeitfenster, in dem es eine ¨ Ubereistimmung von vx und ovx geben soll. Die Angabe eines Zeitpunktes t birgt weitere Probleme. Denn die Variable ovx kann w¨ ahrend der Ausf¨ uhrung der Steuerfunktion CA mehrfach benutzt werden, so bei der Ausf¨ uhrung der Bedingung C als auch bei der Aktion A. Im Extremfall kann die Benutzung der Variablen u ¨ber die gesamte Periode des ausf¨ uhrenden Prozesses verstreut stattfinden. Deshalb sollten anstelle eines Zeitpunktes t alle Zeitpunkte innerhalb der Periode eines Prozesses ber¨ ucksichtigt werden. Letztlich impliziert die Definition der absoluten temporalen Konsistenz die Gleichheit der Wertebereiche Vx und OVx . Dies trifft jedoch in vielen F¨ allen nicht zu, insbesondere dann nicht, wenn es sich, wie oft anzutreffen, bei vx um einen kontinuierlichen und bei ovx um einen diskretisierten Wert handelt. Auf der Grundlage der oben eingef¨ uhrten Sensor- und Aktorrelation, der Periode von Prozessen und dem Verhalten des technischen Systems l¨asst sich eine fortgeschrittenere Betrachtung dessen anstellen, was an werteund zeitm¨ aßigen Abweichungen von Variablenwerten w¨ahrend der Prozessausf¨ uhrung zu erwarten ist. Das beginnt damit, dass festgehalten wird, welche Alterung zwischen den Werten der Variablen ovx und ovy und den entsprechenden Werten im technischen System vorliegen: Das maximale Alter ∆shx bezeichnet die maximale Zeitspanne, die vom Abtasten der technischen Gr¨ oße x durch den Sensor bis zum Beginn der Periode, in der mit der Zuweisung ovx=sensor x.get() die Variable ovx einen neuen Wert erh¨ alt, vergeht. Analog bezeichnet ∆slx das minimale Alter auf Seite des Sensors. Das maximale Alter ∆ahx bezeichnet die maximale Zeitspanne, die vom Ende der Periode, in der mit der Operation actuator y.set(ovy) ein neuer Wert an den Aktor gegeben wird, bis zu dem Zeitpunkt vergeht, zu dem ein ensprechender Wert der technischen Gr¨oße y eingestellt ist. Analog bezeichnet ∆alx das minimale Alter auf Seite des Aktors. Innerhalb der Periode, in der die Steuerfunktion abl¨auft, kann das Lesen des Sensors unter g¨ unstigen Bedingungen ganz am Anfang, unter ung¨ unstigen Bedingungen aber erst ganz am Ende stattfinden. Damit ist 0 eine untere Schranke und ∆p eine obere Schranke f¨ ur die Alterung, die durch die Prozessausf¨ uhrung innerhalb einer Periode m¨ oglich ist. Entsprechende Schranken gelten f¨ ur das Stellen des Aktors innerhalb einer Periode.

110

2.3.4

2. Methodische und technische Grundlagen

Beispiel 2.3.4 Beim Beispiel der Wippe (siehe Seite 8) ist eine Kamera vorhanden, die alle 25 Hz ein Kamerabild aufnimmt und im Hauptspeicher zur Verf¨ ugung stellt. Diese Aufgabe hat absoluten Vorrang und dauert zwischen 2ms und 3ms. Alle u ¨brigen Prozesse sind unterbrechbar und unterliegen der priorit¨ atsbasierten Prozessausf¨ uhrung. Es handelt sich um die Prozesse, die in der folgenden Tabelle enthalten sind (siehe auch Abb. 1.5): Aufgabe des Prozesses Erkennung Kugelposition Aggregation aus Kenngr¨ oßen Steuerfunktion Motorsteuerung

minimale Ausf¨ uhrungzeit 4ms 1ms 1ms 6ms

maximale Ausf¨ uhrungszeit 11ms 2ms 2ms 8ms

Priorit¨ at 6 5 4 3

Die Positionsangabe op wird im Prozess Erkennung der Kugelposition“ er” mittelt. Diese Werte werden im Prozess Aggregation aus Kenngr¨oßen“ wei” terverarbeitet, und es stellt sich die Frage nach deren minimalem und maximalem Alter. F¨ ur das minimale Alter sind die minimalen Ausf¨ uhrungszeiten f¨ ur die Bereitstellung des Kamerabildes und die minimlale Ausf¨ uhrungszeit des Prozesses Aggregation aus Kenngr¨oßen“ anzusetzen. Gleichzeitig wird ” optimistisch davon ausgegangen, dass im Prozess Aggregation aus Kenn” gr¨ oßen“ ohne Zeitverz¨ ogerung die Beschaffung der Positionsangabe erfolgt: slp = 2ms + 4ms = 6ms F¨ ur das maximale Alter sind jeweils die maximalen Ausf¨ uhrungszeiten anzusetzen: shp = 3ms + 11ms = 14ms Nach dieser Rechnung ist eine observierte Positionsangabe op, wie sie im Programm in einer Variablen ovp zur Verf¨ ugung steht, zwischen 6ms und 16ms alt. Dabei kommen die 16ms dadurch zustande, dass bis zum Beginn von Prozess Aggregation aus Kenngr¨ oßen“ maximal 14ms vergehen und ” die Variable sp¨ atestm¨ oglich bei der Ausf¨ uhrung des Prozesses einen neuen Wert erh¨ alt. Wird dieser erneuerte Wert der Variablen ovp von nachfolgenden Prozessen verwendet, so steigt das Alter der Postionsangabe entsprechend weiter.
2.3.1

Aufgabe 2.3.1 (siehe Seite 278) Im Prozesses Aggregation aus Kenngr¨ oßen“

” (siehe Abb. 1.5) werden zus¨ atzlich die Gr¨oßen Geschwindigkeit v und die Beschleunigung a aus aktuellen und vorangegangenen Positionsangaben bestimmt. Es fragt sich, von welchem Alter bei diesen Werten, die in den Varia-

2.3

Bestimmung der Prozessparameter

111

blen ovv und ova vom Prozess Steuerfunktion“ benutzt werden, auszugehen ” ist.
W¨ ahrend der Zeitspanne, in der das Rechensystem den Zustand des technischen Systems erfasst, bewertet und beeinflusst, entwickelt sich das technische System weiter. Bezogen auf eine einzelne technische Gr¨oße x soll die Funktion T Sx beschreiben, wie sich das technische System ausgehend von einer Menge von Ausgangszust¨ anden im n¨ achsten Zeitintervall ∆τ entwickelt: T Sx : 2Vx × ∆T → 2Vx Diese Funktion zusammen mit der Vor¨ uberlegung erm¨oglicht es, pr¨azise anzugeben, in welcher Beziehung Variablenwerte des Rechensystems und entsprechende Werte des technischen Systems stehen. Bezogen auf den Wert ovx der Variablen ovx, der in eine Bedingung C(ovx,ovy) aus dem Programmfragment eingeht, stellen sich zwei Fragen: Von welcher Wertemenge Vx ⊂ Vx kann der Wert ovx aufgrund wertem¨ aßiger Abweichung stammen? Die Antwort lautet: dom(SRx , {ovx }) Wie kann sich ein Wert vx ∈ Vx der technischen Gr¨oße x w¨ahrend einer Zeitspanne ∆τ ver¨ andern? Die Antwort lautet: T Sx ({vx }, ∆τ ) Dazu ist zu bedenken, dass der Sensor die wertem¨aßigen Abweichungen verursacht und ∆τ zwischen dem minimalen und dem maximalen Alter schwanken kann, bis die Bedingung C(ovx,ovy) zur Ausf¨ uhrung kommt. Gleichzeitig hat sich das technische System, w¨ ahrend der abgetastete Wert ovx altert, bereits weiterentwickelt. Dies alles m¨ undet in die folgende Formel:  T Sx (dom(SRx , {ovx }), ∆τ ) ∆τ ∈[∆slx ,∆shx +∆p]

Diese Formel betrifft bislang jedoch nur das Messsystem und das Rechensystem bis zur Auswertung der Bedingung C. Aber auch die Ausf¨ uhrung der Aktion A im Rechensystem und die Zeitspanne, bis das Stellsystem auf das technische System einwirkt, sind zu ber¨ ucksichtigen. Ein Wert vx , der vom Messsystem abgetastet wird und daraufhin im Rechensystem als Wert ovx die Steuerfunktion CA eingeht, entwickelt sich f¨ ur eine gewisse Zeitspanne unabh¨ angig von der Aktion A weiter. Bis der Stellwert ovy der Steuerfunktion im technischen System den Wert vy erzeugt, vergeht eine minimale und

112

2. Methodische und technische Grundlagen

eine maximale Wirkverz¨ ogerung: ∆lxy = ∆slx + ∆aly ∆hxy = ∆shx + 2 ∆pi + ∆ahy Der Summand 2 ∆pi , der in die maximale Wirkverz¨ogerung eingeht, ist da¨ durch begr¨ undet, dass in der vorangegangenen Periode die Anderung des Wertes vx nicht mehr wahrgenommen wurde und erst in der nachfolgenden Periode erfolgt. Die Alterung wird dann extrem, wenn der Aufruf der Opeuh in der vorangegangenen und der Aufruf ration sensor x.get() ganz fr¨ der Operation actuator y.set(ovy) ganz sp¨at in der nachfolgenden Periode stattfindet. Die gesamte Wertemenge IM Vx (OM ), die die technische Gr¨oße x im Laufe der Wirkverz¨ ogerung annehmen kann, w¨ahrend das Rechensystem unabh¨ angig dazu auf dem Messwert ovx ∈ OM arbeitet, ist gegeben als Abbildung:  T Sx (dom(SRx , {ovx }), ∆τ ) IM Vx ({ovx }) = ∆τ ∈[∆lxy ,∆hxy ]

Echtzeitanwendungen oder Teile davon haben spezifische Aufgaben zu erf¨ ullen. Eine einfache M¨ oglichkeit der pr¨azisen Formulierung der Aufgabenstellung legt pr¨ adikatenlogische Formeln zugrunde. Die dabei verwendeten Variablen stammen aus den Wertebereichen V des technischen Systems und beschreiben, was unab¨ anderlich im technischen System gelten soll. Eine Formel IV = {V1 , . . . , Vh } dieser Art heißt deshalb Invariante. Aufgabe des Rechensystems, insbesondere jeder einzelnen Steuerfunktion CA, ist es, daf¨ ur zu sorgen, dass die Gr¨ oßen des technischen Systems dauerhaft die Invariante ullen. IV erf¨ 2.3.5

Beispiel 2.3.5 F¨ ur das Beispiel der Wippe (siehe Seite 8) besteht eine Inva-

riante darin, dass die Kugel auf der bewegten Fl¨ache bleibt. Formuliert in pr¨ adikatenlogischer Form bedeutet dies, dass die erlaubten Positionswerte p der Kugel auf die Fl¨ ache oder auf Teile der Fl¨ache zu beschr¨anken sind, beispielsweise beschr¨ ankt auf einen Kreis mit dem Radius R: IV ≡ (p.x)2 + (p.y)2 < R2 Weitergehende Zielsetzungen, wie das Abbremsen und Stabilisieren der Kugel im Mittelpunkt des Kreises, sind mit den hier vorgestellten Beschreibungsmitteln nicht zu erfassen. Sie sind Gegenstand der Forschung und werden im Weiteren nicht verfolgt.


2.3

Bestimmung der Prozessparameter

113

Entwickler von Echtzeitanwendungen stehen vor der Aufgabe, die SteuerfunktionCA so zu programmieren, dass die Invariante erf¨ ullt ist. Konkret ist ur die die Aktion A durchdazu eine Wertemenge OVx ⊆ OVx zu bestimmen, f¨ gef¨ uhrt wird und das technische System so beeinflusst, dass IV dauerhaft gilt. Die Abbildung IM V liefert dazu nicht die gesuchte Antwort, da ausgehend von einem Wert ovx bestimmt wird, was alles im technischen System m¨oglich ist. Erst die Umkehrung der Abbildung IM V in den nachfolgenden Schritten f¨ uhrt zu einer entsprechenden Bedingung C: ullen: 1. Bestimmung der Menge der Werte aus Vx , die die Invariante IV erf¨ Vx = {vx ∈ Vx | IV (vx )} 2. Zu einem Zeitpunkt t−∆τ , mit ∆τ ∈ [∆lxy , ∆hxy ], wurden die Messwerte aufgenommen. In der Zwischenzeit ∆τ hat sich das technische System urfen jedoch nur diejenigen Werte weiterentwickelt. In die Menge Vx d¨ ullen: aufgenommen werden, die noch nach ∆τ die Invariante IV erf¨  T S({vx }, ∆τ ) ⊆ Vx } Vx = {vx ∈ Vx | ∆τ ∈[∆lxy ,∆hxy ]

3. Jeder Wert vx ∈ Vx unterliegt einer wertem¨aßigen m¨oglichen Abweichung durch den Sensor. Nur solche Werte, die bei jeder Abweichung noch aus ullen die Invariante IV : Vx stammen, erf¨ OVx = {ovx ∈ OVx | dom(SRx , {ovx }) ⊆ Vx } 4. Die Menge der Werte OVx ist einer entsprechenden Bedingung C abzufragen. Beispiel 2.3.6 Zur Klarstellung der einzelnen Schritte, die notwendig sind, um systematisch ein Progammfragment zu entwickeln, das eine Invariante IV erf¨ ullt, sei auf eine m¨ oglichst einfache Echtzeitanwendung verwiesen. Zu diesem Zweck eignet sich das als fuel-level monitoring system (vgl. [43]) bekannt gewordene Beispiel der Regelung des F¨ ullstandes eines Tanks. Die Aufgabe besteht darin, den F¨ ullstand eines Kraftstofftanks nicht unter eine gewisse Schwelle sinken zu lassen. St¨ andig wird von einem Verbrennungsmotor Kraft¨ stoff verbraucht. Uber einen Messstab kann der F¨ ullstand abgefragt werden, um bei Bedarf eine Pumpe anzuschalten, die den Tank wieder bef¨ ullt (siehe Abb. 2.29). Die technische Gr¨ oße x beschreibt den F¨ ullstand. Die Aufgabenstellung, verk¨ orpert durch die Invariante IV , bezieht sich nur auf die Gr¨oße x und besagt, dass jederzeit mindestens 50l Kraftstoff im Tank enthalten sind:

IV ≡ vx ≤ 50l

2.3.6

114

2. Methodische und technische Grundlagen

Pumpe Messstab Zufuhr

Kraftstofftank

50l

Verbrauch

Abb. 2.29. Schematische Zeichnung des

Kraftstofftanks, bei dem ein gewisser F¨ ullstand unter keinen Umst¨ anden unterschritten werden darf.

Eine weitere Gr¨ oße y des technischen Systems beschreibt, ob die Pumpe angeschaltet ist oder nicht. F¨ ur beide Gr¨oßen x und y gibt es im Programmfragment Abbilder in den Variablen ovx und ovy. Gesucht ist die Bedingung C, unter der die Aktion des Anschaltens der Pumpe erfolgen soll: if C(ovx) ovy=TRUE; Bei dieser Anwendung ist eine Reihe von werte- und zeitm¨aßigen Abweichungen zu ber¨ ucksichtigen. Ohne das Wissen u ¨ber diese Abweichungen ist keine Aussage u ber die Erf¨ u llbarkeit der Invarianten m¨oglich. Entsprechend ¨ sei folgendes Wissen verf¨ ugbar: In der Art, wie der Messstab im Tank montiert ist, kann der Hersteller gaullstand rantieren, dass der gemessene Wert ovx nie mehr als ±10% vom F¨ vx abweicht. Der Messstab bildet ein unabh¨ angiges Messger¨at. Außer sich misst der Stab den F¨ ullstand und kann mit dem Aufruf sensor x.get() abgefragt werden. Das Alter des gemessenen F¨ ullstands liegt zwischen 20ms und 50ms. Kraftstoff wird w¨ ahrend des Betriebs st¨andig aus dem Tank entnommen. Der Verbrauch ist sehr unterschiedlich und liegt zwischen 0, 1l/s und 10l/s. Der Prozess i, der die Steuerfunktion ausf¨ uhrt und die Invariante IV sichern soll, ist unterbrechbar und hat eine Periode von ∆pi = 150ms. Die Zufuhr von Kraftstoff u ¨ber die Pumpe liegt bei voller Pumpenleistung bei 18l/s bis 20l/s. Nach dem Anschalten der Pumpe, d.h. vy = T RU E, vergehen mindestens 80ms, bis u ¨berhaupt ein Anlaufen erfolgt, und erst nach 350ms ist die volle Pumpenleistung sicher verf¨ ugbar. Mit diesem Wissen ist es m¨ oglich, die unteren und oberen Schranken f¨ ur die Wirkverz¨ ogerung anzugeben: ∆lxy = 20ms + 80ms = 100ms

2.3

Bestimmung der Prozessparameter

115

∆hxy = 50ms + 2 × 150ms + 350ms = 700ms Den weiter oben erl¨ auterten Schritten 1. bis 4. entsprechend wird nun die Bedingung C abgeleitet: 1. Bestimmt wird die Wertemenge Vx des technischen Systems, die die Invaullt: riante IV erf¨ Vx = {vx ∈ Vx |vx ≥ 50l} 2. Bestimmt wird die Menge Vx , die abgetastet vom Sensor zum Zeitpunkt ullt. Als untere t − ∆τ zum Zeitpunkt t immer noch die Invariante IV erf¨ Schranke der Ver¨ anderung des technischen Systems setzt man die minimale Wirkverz¨ ogerung und den minimalen Verbrauch an: 100ms × 0.1l/s = 0.01l Die obere Schranke der Ver¨ anderung erh¨ alt man, wenn man die maximale Wirkverz¨ ogerung und den maximalen Verbrauch zugrunde legt: 700ms × 10l/s = 7l ullst¨ ande, die bei jeder Art von VerDie Wertemenge Vx umfasst die F¨ brauch und allen Wirkverz¨ ogerungen noch die Invariante erf¨ ullen. Hierzu ist die obere Schranke der m¨ oglichen Ver¨ anderung anzuwenden: Vx = {vx ∈ Vx |vx ≥ 57l} 3. Bestimmt wird die Wertemenge OVx im Rechensystem, die ausschließlich von abgetasteten Werten vx ∈ Vx stammen. Die wertem¨aßige Ver¨ anderung von ±10% durch den Sensor muss dabei ber¨ ucksichtigt werden. Betrachtet wird der Randwert vx = 57l in der Menge Vx . Dieser kann durch den Sensor im Rechensystem als ein Wert aus dem Intervall zwischen 51, 3l und 62, 7l ankommen. In jedem Fall stammt ein Wert ovx ≥ 62, 7l von einem F¨ ullstand vx ∈ Vx , so dass gilt: OVx = {ovx ∈ OVx |ovx ≥ 62, 7l} 4. Die Bestimmung der Bedingung C legt die Wertemenge OVx zugrunde. So ergibt sich folgende Steuerfunktion, die die Erf¨ ullung der Invarianten IV garantiert: if (ovx < 62.7) ovy=TRUE;


116

2. Methodische und technische Grundlagen

Eine F¨ ahigkeit dieser Methode ist die Ableitung der Bedingung C der Steuerfunktion CA. Gegeben in dieser Rechnung ist die Invariante IV und, implizit durch die Verwendung des Zeitfensters ∆hxy , auch zweimal die Periode des Prozesses i, der die Steuerfunktion ausf¨ uhrt. Es ist jedoch genauso m¨oglich, oße zu betrachten und von ihr die Bedingung die Periode ∆pi als variable Gr¨ angig zu machen. C oder die Invariante IV abh¨ 2.3.7

Beispiel 2.3.7 Eine idealisierte Steuerfunktion ben¨ otigt keine Ausf¨ uhrungszeit und ist immer aktiv. Das entspricht einer Periode ∆pi = 0. Entsprechend schrumpft ∆hxy auf 400ms, und es ist:

Vx = {vx ∈ Vx |vx ≥ 54l} uhrt schließlich zur Eine weitere Folgerung erweitert die Menge OVx und f¨ Steuerfunktion: if (ovx < 59.4) ovy=TRUE; N¨ aher darf man unter keinen Umst¨ anden den observierten Wert des F¨ ullstandes sinken lassen, ohne die Pumpe anzuschalten. Da die Beziehungen in diesem Beispiel alle linear sind, f¨ uhrt eine lineare Erh¨ohung der Periode zu einer linearen Erh¨ ohung der Schranke, die in der Bedingung C abgefragt wird. Exakt ergibt sich, dass bei der Erh¨ ohung der Periode um 1ms die Schranke in der Bedingung C um 20ml + 2ml w¨ achst. Der erste der beiden Summanden ist unmittelbar auf die Verl¨ angerung der Wirkverz¨ ogerung zur¨ uckzuf¨ uhren, w¨ahrend der zweite als mittelbar Folge der verl¨ angerten Wirkverz¨ ogerung widerspiegelt, dass auch die wertem¨ aßige Abweichung steigt.


2.4

Parallelit¨ at und Synchronisierung

117

2.4 Parallelit¨ at und Synchronisierung Ein technisches System, das von einem Echtzeitsystem erfasst, u ¨berwacht und gesteuert werden soll, gliedert sich meist in mehrere technische Prozesse. Entsprechende Rechenprozesse, die zusammen ein paralleles Programm aufbauen, stellen ein angemessenes Abbild des technischen Systems dar (siehe Beispiel 2.2.1). Deshalb werden zun¨ achst die wesentlichen Techniken der parallelen Programmierung sowie deren Probleme angesprochen (siehe Unterabschnitt 2.4.1), bevor elementare und h¨ ohere Konzepte der Synchronisierung zur Sprache kommen (siehe Unterabschnitte 2.4.2 und 2.4.3). Abschließend wird darauf eingegangen, welche Leistungssteigerung durch die parallele Ausf¨ uhrung von Prozessen auf Mehrprozessorsystemen zu erwarten ist (siehe 2.4.4). 2.4.1 Parallele Programme und Konsistenz der Daten

Die große Mehrheit der Echtzeitanwendungen werden im Mehrprogrammbeuhrt. Auf trieb17 auf gegebenenfalls vernetzten Einprozessorsystemen ausgef¨ einem Einprozessorsystem laufen u ¨blicherweise mehrere Prozesse, die um den Besitz des Prozessors konkurrieren. In einem solchen Fall spricht man von pseudo-paralleler Prozessausf¨ uhrung. Dabei wird der Programmcode eines Prozesses solange sequenziell ausgef¨ uhrt, bis eine Prozessumschaltung erfolgt. Bei nicht unterbrechbaren Prozessen findet eine solche Umschaltung am Ende der Prozessausf¨ uhrung statt, w¨ ahrend bei einem unterbrechbaren Prozess jederzeit damit gerechnet werden muss. Bei Mehrprozessorsystemen und bei Multicore-Prozessoren18 sind mehrere Ausf¨ uhrungsinstanzen u ¨ber einen Bus mit einem gemeinsamen Hauptspeicher verbunden. Somit k¨ onnen zum gleichen Zeitpunkt mehrere sequenzielle Prozesse ausgef¨ uhrt werden Man spricht in diesem Fall von nebenl¨aufiger Parallelausf¨ uhrung. Typischerweise gibt es auf Mehrprozessorsystemen ein Betriebssystem oder ein Laufzeitsystem, mit dem sich parallele Prozesse erzeugen lassen. Auf deren Grundlage kann es freigestellt sein, wo welcher Prozess ausgef¨ uhrt werden soll, oder es gibt eine festgelegte Zuordnung dar¨ uber, auf welchem Prozessor welcher Prozess ausgef¨ uhrt werden darf. Gleiches gilt grunds¨ atzlich auch f¨ ur Multicore-Prozessoren, wobei letztere unterst¨ utzt durch entsprechende Compiler-Techniken auch solche Formen der Parallelit¨at ausnutzen, die darin bestehen, unabh¨ angige Maschinenbefehle gleichzeitig auf mehreren Prozessoren auszuf¨ uhren. 17

Hierf¨ ur gibt es im Englischen die beiden synonym gebrauchten Begriffe multiprogramming und multitasking (vgl. [120]). 18 Diese werde oft synonym Chip-Multiprozessoren genannt.

2.4

118

2. Methodische und technische Grundlagen

Die Art der Kopplung zwischen Prozessen kann sehr unterschiedlich sein. G¨ angig ist die Unterscheidung, die zwischen drei Kategorien der Kopplung von Prozessen unterscheidet (vgl. [120]): (A): Unabh¨ angige Prozesse, die lediglich um den Prozessor konkurrieren. (B): Prozesse wie aus Katergorie A, die jedoch zus¨atzlich einen gemeinsamen Hauptspeicher besitzen und darauf zugreifen. (C): Prozesse wie aus Kategorie A, die zus¨atzlich Nachrichten (engl. message) senden und empfangen. 2.4.1

Beispiel 2.4.1 Vertreter der Kategorie A sind die schwergerwichtigen Prozesse,

wie sie beispielsweise unter dem Betriebssystem UNIX mit dem Systemaufruf fork() erzeugt werden. In diesem Fall wird eine Kopie der Speicherbelegung des Elternprozesses, der fork() ausf¨ uhrt, angelegt und als unabh¨angiger Kindprozess gestartet. Die Unabh¨angigkeit ist jedoch im speziellen Fall von UNIX nicht vollkommen. So treten Abh¨ angigkeiten auf, wenn ein Elternprozess am Ende seiner Ausf¨ uhrung anlangt und warten muss, bis sein Kindprozess mit join() auch seine Ausf¨ uhrung beendet. Dar¨ uber hinaus ist es m¨oglich, dass Elternund Kindprozesse gemeinsame Betriebsmittel wie einen mit pipe() erzeugten Puffer benutzen. Zur Kategorie B geh¨ oren leichtgewichtige Prozesse (engl. thread), die beispielsweise unter Verwendung der pthread-Schnittstelle von Posix mit dem Systemaufruf pthread create() erzeugt und mit pthread join() beendet werden. Alle Prozesse, die auf diese Weise ausgef¨ uhrt werden, arbeiten auf demselben Hauptspeicher, was zur Inkonsistenz der Daten f¨ uhren kann. Dar¨ uber hinaus sind vergleichbare Abh¨angigkeiten m¨oglich, die bereits f¨ ur die Prozesse der Kategorie A genannt wurden. Zur Kategorie C geh¨ oren Prozesse, die zun¨achst zur Kategorie A zu z¨ahlen sind, aber zus¨ atzlich noch Nachrichten versenden und empfangen. Dabei ist zwischen synchroner und asynchroner Nachrichten¨ ubertragung zu unterschei¨ den. Bei der synchronen Nachrichten¨ ubertragung findet die Ubergabe der Nachricht vom Sender zum Empf¨ anger wie eine gemeinsame Operation statt. Wird die Nachricht fr¨ uher gesendet als der Empf¨anger bereit ist, dann muss der Sender warten. Umgekehrt muss der Empf¨anger warten, wenn der Sender noch nicht bereit ist. Dagegen ist der Sender bei der asynchronen Nachrichten¨ ubertragung frei. Er kann jederzeit eine Nachricht senden, ohne warten zu m¨ ussen, w¨ahrend umgekehrt eine Empfangeoperation nur erfolgreich abgeschlossen werden kann, nachdem die Nachricht des Senders vorliegt.


2.4

Parallelit¨ at und Synchronisierung

119

Das Prozessmodell der Kategorie A ist konform zu dem, was anf¨anglich eingef¨ uhrt wurde (siehe Abschnitt 2.1) und in die grundlegenden Planungsverfahren (siehe Kapitel 3) eingeht. Das Prozessmodell der Kategorie C ist dasjenige, das auch bei den Betrachtungen zu verteilten Systemen zugrunde gelegt wird (siehe Abschnitt 2.5) und in den entsprechenden Planungsverfah¨ ren behandelt wird (siehe Abschnitt 4.3). Ubrig bleibt das Prozessmodell der Kategorie B, das sehr verbreitet ist und die beiden anderen Prozessmodell keineswegs ausschließt: Auf Ein- oder Mehrprozessorsystemen kann es Prozesse der Kategorie A geben, wobei einzelne dieser schwergewichtigen Prozesse aus mehreren leichtgewichtigen Prozessen bestehen. Auf Ein- oder Mehrprozessorsystemen kann es einzelne leichtgewichtige Prozesse geben, die entsprechend der Kategorie C mit anderen leichtgewichtigen Prozessen auf anderen Ein- oder Mehrprozessorsystemen mittels Nachrichten kommunizieren. Somit kann die Beherrschung des Prozessmodells der Kategorie B als Kern und Voraussetzung der Beherrschung anderer Prozessmodelle gelten. Dies betrifft sowohl die Anwendungsebene der Systemprogramme, wie Betriebssysteme und Laufzeitsysteme, wie auch darauf aufbauende Echtzeitanwendungen. Hauptproblem beim Prozessmodell der Kategorie B ist die Konsistenz der Daten. Bereits die parallele Ausf¨ uhrung zweier Prozesse P und Q, die lediglich eine Inkrementanweisung ausf¨ uhren, kann zur Inkonsistenz der Daten f¨ uhren: P:: : x=x+1; :

Q:: : x=x+1; :

Wenn auf Prozessoren Lade- und Speicherbefehle sowie Inkrementbefehle im Akkumulator unteilbar ausgef¨ uhrt werden, nicht jedoch die obigen Inkrementanweisungen x=x+1;, dann kann es zu einer Ausf¨ uhrungsfolge kommen, bei der eine der Inkrementanweisungen nicht wirksam wird (siehe Abb. 2.30). Die Inkonsistenz besteht dabei darin, dass es Ausf¨ uhrungsfolgen gibt, die durch das Hintereinanderausf¨ uhren von P und Q in ihrer Wirkung nicht reproduziert werden k¨ onnen. Die beiden nachfolgenden Unterabschnitte setzen sich damit auseinander, wie Parallelit¨ at so eingeschr¨ ankt werden kann, dass Inkonsistenzen dieser Art ausgeschlossen werden k¨ onnen. Zu diesem Zweck werden zwei grunds¨atzlich unterschiedliche Ans¨ atze zur Synchronisierung vorgestellt.

120

2. Methodische und technische Grundlagen

Abb. 2.30. Die Folge von Laden, Inkrementieren im Akkumulator und Speichern durch

Prozess Q setzt auf dem alten Wert von x auf, so dass am Ende zweimal derselbe x-Wert um 1 erh¨ oht wird.

2.4.2 Elementare Synchronisierungsoperationen

Konsistenz der Daten ließe sich erreichen, indem eine Ausf¨ uhrungsinstanz jede Inkrementanweisung zu einem eigenen Zeitpunkt ausf¨ uhrte. Eine solchermaßen idealisierte Anweisung A wird atomar genannt und notiert als: . Man spricht aber auch dann bereits von atomaren Anweisungen, wenn sie in einer Weise ausgef¨ uhrt werden, die sich auch bei einer Reduktion auf Zeitpunkte ergibt. Das ist insbesondere dann der Fall, wenn f¨ ur einen Ausdruck e oder eine Zuweisung x=e; die so genannte at-most-once-Eigenschaft erf¨ ullt ist. Daf¨ ur muss eine der folgenden Regeln zutreffen (vgl. [8]): 1. Auswertung des Ausdrucks e, der h¨ ochstens eine Variable y enth¨alt, die ein anderer Prozess w¨ ahrend der Ausdrucksauswertung ver¨andern kann. Bei der Auswertung von e darf y nur einmal gelesen werden. 2. Ausf¨ uhrung der Zuweisung x=e;, wobei x w¨ahrend der Ausf¨ uhrung von keinem Prozess gelesen wird und f¨ ur e die 1. Regel zutrifft. 3. Ausf¨ uhrung der Zuweisung x=e;, wobei e keine Variable enth¨alt, die von anderen Prozessen ver¨ andert wird. Das Problem der Inkonsistenz von Daten ist somit gel¨ost, wenn es gelingt, atomare Anweisungen emulieren zu k¨ onnen: P:: : <x=x+1;> :

Q:: : <x=x+1;> :

Es gibt zwar Prozessoren, die derartige Befehle bereits anbieten, aber in der Regel ist nicht davon auszugehen. Stattdessen stehen auf allen Prozessoren atomare Lade- und Speicherbefehle zur Verf¨ ugung. Diese gen¨ ugen bereits, um Atomarit¨ at zu gew¨ ahrleisten. Ein entsprechender L¨osungsansatz ist der von Peterson, der aus zwei Programmfragmenten besteht, eines auszuf¨ uhren am Beginn der atomaren Anweisung, und somit stellvertrend f¨ ur <, sowie

2.4

Parallelit¨ at und Synchronisierung

121

eines am Ende der atomaren Anweisung, und somit stellvertretend f¨ ur > (vgl. [105]). P:: : p=1; m=1; while(m==1 && q==1); x=x+1; p=0; :

Q:: : q=1; m=2; while(m==2 && p==1); x=x+1; q=0; :

Diese L¨ osung ist nur eingeschr¨ ankt praktikabel, da sie nur zwischen einem Paar von Prozessen korrekt arbeitet. Sind mehrere Prozesse vorhanden, dann muss man die Anweisungsfolge entweder kaskadieren oder man ist gezwungen, wesentlich kompliziertere Programmfragmente zu benutzen. Deutlich einfachere L¨ osungen ergeben sich, wenn die Hardware der Prozessoren weitere Befehle zur Synchronisierung bereitstellt. Ein solcher ist der test-and-setBefehl, oder kurz TAS-Befehl, bei dem n Prozesse lediglich eine einzige globale Variable zur Synchronisierung ben¨ otigen. Kern des Befehls ist die unteilbare Ausf¨ uhrung zweier hintereinander ausgef¨ uhrter Speicherzugriffe sowie die Bereitstellung eines Vergleichsergebnisses. Der nachfolgende Pseudocode19 verdeutlicht die Funktionsweise: int TAS(int *a){ int b; return b; } Mit Hilfe des TAS-Befehls lassen sich nun einfache Programmfragmente angeben, die die Klammern atomarer Anweisungen ersetzen: P:: Q:: : : while(!TAS(y)); while(!TAS(y)); x=x+1; x=x+1; y=TRUE; y=TRUE; 19

Die spitzen Klammern umfassen die beiden Speicherzugriffe, die unteilbar ausgef¨ uhrt werden.

122

2. Methodische und technische Grundlagen

:

:

Die Klammern f¨ ur atomare Anweisungen sind anonym. Andererseits wird bei der obigen L¨ osung mit der Variablen y ein Schl¨ ussel benutzt, um die Konkurrenz zwischen verschiedenen Prozessen bez¨ uglich y zu Gunsten eines einzigen Prozesses zu entscheiden. Alle Programmst¨ ucke aller Prozesse, die auf diese Weise gesch¨ utzt sind, formen das kritische Gebiet y (engl. critical section). In einem kritischen Gebiet herrscht gegenseitiger Ausschluss (engl. mutual exclusion), d.h. nur maximal ein Prozess kann darin aktiv sein. Als abstrakte Operationen zum Schutz kritischer Gebiete dienen die Operationen enter() und leave(), die beispielsweise so auf dem TAS-Befehl aufbauen k¨ onnen: void enter(int y){ while(!TAS(y)); } void leave(int y){ y=TRUE; } Ein weiterer wichtiger Befehl, der von vielen Prozessoren zur Synchronisierung zur Verf¨ ugung gestellt wird, ist der compare-and-swap-Befehl oder kurz ¨ CAS-Befehl. Er ist so aufgebaut, dass die Ubergabe eines neuen Wertes nur dann erfolgt, wenn ein vorgegebener alter Wert immer noch vorliegt: int CAS(int *a, int b, int c){ } Der CAS-Befehl eignet sich dazu, dass dynamische Datenstrukturen wie Stapel und Listen von mehreren Prozessen parallel ver¨andert werden, ohne die Konsistenz der Daten zu verletzen. 2.4.1

Aufgabe 2.4.1 (siehe Seite 279) Der Datentyp des Stapels wird in der sys-

temnahen Datenverarbeitung immer wieder ben¨otigt. Die einzelnen Eintr¨age im Stapel heißen Zellen und sollen, angelehnt an die Programmiersprache C, folgenden Aufbau haben:

2.4

Parallelit¨ at und Synchronisierung

struct cell{ int value; struct cell *next; }

123

/* Wert der Zelle */ /* Verweis auf nachfolgende Zelle */

Eine Variable ptr top vom Typ struct cell * verweist auf die oberste Zelle des Stapels. Die Bearbeitung des Datentyps Stapel erfogt u ¨blicherweise mittels zweier Funktionen, zum einen der Funktion void push(cell **ptr_top, cell *new_cell) um eine neue Zelle auf dem Stapel abzulegen, und zum anderen mittels der Funktion cell* pop(cell **ptr_top) um die oberste Zelle vom Stapel zu nehmen und als Funktionsergebnis zur¨ uckzugeben. Schreiben Sie die beiden Funktionen unter Zuhilfenahme des CAS-Befehls in der Weise, dass sie von unterschiedlichen Prozessen gleichzeitig aufgerufen werden k¨ onnen, ohne die Konsistenz des Stapels zu verletzen.
Synchronisierungsoperationen, die auf TAS- oder CAS-Befehle aufbauen, werden auch als sperrenfrei (engl. lock-free) bezeichnet. Unmittelbar bezogen auf die beiden Befehle trifft diese Charakterisierung zu, da jeder von mehreren in Konkurrenz stehenden Prozessen seinen eigenen Befehl schließlich beginnen und zuende f¨ uhren wird. Betrachtet man jedoch die Einbettung der TAS- und CAS-Befehle innerhalb der enter()- und leave()-Funktion sowie der push()- und pop()-Funktion, so ist es prinzipiell m¨oglich, dass Prozesse unbegrenzt lange auf die Beendigung dieser Befehle warten und damit zeitliche Vorhersagbarkeit nicht mehr gegeben ist. Dieser Zustand eines Prozesses, zwar aktiv zu sein, aber dennoch keinen Fortschritt in der Berechnung zu erreichen, wird als Livelock bezeichnet. Tats¨ achlich ist die Feststellung bezogen auf konkrete Anwendungen vielfach eher akademisch, denn permanente Konkurrenzsituationen zwischen Prozessen lassen sich u ¨blicherweise im Einzelfall ausschließen. Unter dieser Voraussetzung stellt die sperrenfreie Synchronisierung eine h¨ochst effiziente Methode der Konsistenzerhaltung dar und kann sowohl auf Ein- als auf Mehrprozessorsysteme angewendet werden. Gleichzeitig ist keinerlei Unterst¨ utzung durch ein Betriebssystem oder ein Laufzeitsystem n¨otig. Letzteres empfiehlt diese

124

2. Methodische und technische Grundlagen

Methoden deshalb f¨ ur die Entwicklung von Betriebssystemen und Laufzeitsystemen. Auch das Sperren von Unterbrechungsanforderungen (engl. interrupt) stellt eine elementare Synchronisierungsmethode dar. Sie teilt dem ausf¨ uhrenden Prozess den Prozessor exklusiv zu, ohne dass eine Unterbrechung m¨oglich ist. Dieser Zustand ¨ andert sich erst dann, wenn der Prozess ausdr¨ ucklich wieder Unterbrechungen zul¨ asst. Anwendbar ist diese Methode allein auf Einprozessorsysteme. 2.4.3 H¨ ohere Synchronisierungsoperationen

Im Gegensatz zu den elementaren Synchronisierungsoperationen zeichnen sich die h¨ oheren dadurch aus, dass sie eine vom Rechensystem weitgehend unabh¨ angige Funktionalit¨ at besitzen. Dazu z¨ahlt, dass sie auf Diensten des Betriebssystems oder Laufzeitsystems aufsetzen, gegebenenfalls in eine Programmiersprache eingebunden sind und verschiedene Zust¨ande der Prozessausf¨ uhrung unterscheiden. Die h¨ oheren Synchronisierungsoperationen zielen vorrangig auf unterbrechbare Prozesse, die die Zust¨ande rechnend, verdr¨ angt, blockiert oder vor¨ ubergehend beendet besitzen (siehe Abb. 2.8). Das klassische Konzept der Synchronisierung, das auch heute noch in verschiedensten Varianten von Betriebssystemen und Laufzeitsystemen zur Verf¨ ugung gestellt wird, ist das der Semaphore, das auf Dijkstra zur¨ uckgeht (vgl. [40]). Semaphore bilden einen abstrakten Datentyp, dem eine Z¨ahlvariable zugrunde liegt, die mit zwei Operationen manipuliert und einer weiteren erzeugt und initialisiert wird. Letzteres geschieht mit Init(s,n), das ein Semaphor s erzeugt und mit n initialisiert. Dabei ist der Wertebereich von s auf N0 beschr¨ ankt. Mit der Operation P(s) wird das Semaphor im Zustand s>0 um 1 verringert. Hat s bereits den Wert 0, so wird der Prozess, der P(s) ausf¨ uhrt in den Zustand wegen s blockiert u uhrt. Wenn umgekehrt V(s) ausgef¨ uhrt ¨berf¨ wird und es Prozesse gibt, die sich im Zustand wegen s blockiert aufhalten, dann wird einer davon wieder in den Zustand verdr¨ angt u uhrt. Ansonsten ¨berf¨ wird mit V(s) der Wert des Semaphors um 1 erh¨oht. 2.4.2

Beispiel 2.4.2 Mit dem Semaphor s, das mit 1 initialisiert ist, l¨ asst sich die

Konsistenz der Daten zwischen den Prozessen P und Q auf einfache Weise sicherstellen: P:: : P(s); x=x+1; V(s);

Q:: : P(s); x=x+1; V(s);

2.4

Parallelit¨ at und Synchronisierung

:

125

:

In dieser Form entspricht die obige P(s)-V(s)-Klammerung den geklammerten Operationen enter(s) und leave(s) f¨ ur kritische Gebiete.
Ein unter programmiertechnischen Gesichtspunkten weitergehendes Konzept der Synchronisierung ist das der Monitore. Kern des Konzeptes, das von Hoare und Brinch Hansen (vgl. [65] und [57]) vorgeschlagen wurde, bildet der gegenseitige Ausschluss f¨ ur ein programmiertechnisch eindeutig gekennzeichnetes Programmst¨ uck, das bei manchen Implementierungen auch den Namen Monitor tr¨ agt. Im Monitor enthalten sind Datenstrukturen und Operationen darauf. Nur ein Prozess kann zu einem Zeitpunkt aktiv im Monitor sein, d.h. Operationen auf den Daten des Monitors ausf¨ uhren. Ist die Situation g¨ unstig, dann schließt der Prozess die Operation ab und verl¨asst den Monitor, damit ein n¨ achster Prozess im Monitor aktiv werden kann. Es kann aber auch sein, dass ein Prozess den Monitor nicht so vorfindet, dass er die Operation abschließen kann. Dann hat er die M¨oglichkeit, mit der Synchronisierungsoperation wait(s) in den Zustand blockiert wegen s u ¨berzugehen. Der Monitor ist damit wieder frei und ein anderer Prozess kann ihn betreten. Jener Prozess kann sich kooperativ verhalten, indem er den blockierten Prozess mit der Synchronisierungsoperation signal(s) anst¨oßt, konkret in den Zustand rechnend u uhrt. Dies impliziert, dass jener Pro¨berf¨ zess, der sich kooperativ verhalten hat, umgehend blockiert wird und erst weiterarbeiten kann, wenn der Monitor wieder frei ist20 . Semaphore und Monitore stellen nur eine kleine Auswahl an Synchronisierungskonzepten dar, die auch bei Echtzeitsystemen eingesetzt werden (weitere Konzepte in [49], [22] und [24]). Beide Konzepte bauen auf der blockierenden Synchronisierung auf. Die Klassifikation ist gekennzeichnet durch die 20

Die vorgestellte Variante ist nur eine von vielen Varianten, wie Monitoren implementiert werden k¨ onnen. Bei der Implementierung spielt die Verwaltung der blockierten Prozesse in unterschiedlichen Schlangen eine bedeutende Rolle. In der oben skizzierten Implementierung wird je eine Schlange f¨ ur jede Art s einer Blockade ben¨ otigt sowie eine weitere Schlange f¨ ur alle die Prozesse, die den Monitor betreten bzw. ihre mit signal(s) unterbrochene Ausf¨ uhrung fortsetzen wollen. Ei¨ ne Ubersicht unterscheidet drei Klassen von Implemtierungen f¨ ur Monitore (vgl. [8]): SW (signal and wait) realisiert in der Programmiersprache Modula-2. SC (signal and continue) realisiert in der Progrmmiersprache Java. SU (signal and urgent wait) realisiert in der Programmiersprache Concurrent Pascal.

126

2. Methodische und technische Grundlagen

Eigenschaft, dass Prozesse aus unterschiedlichen Gr¨ unden in den Zustand blockiert u ¨bergehen und selbst nicht mehr in der Lage sind, an der Ver¨anderung dieses Zustandes mitzuwirken. Es obliegt anderen kooperativen Prozessen, die blockierten Prozesse aus diesem Zustand zu befreien und wieder in einen der rechenbereiten Zust¨ ande rechnend oder verdr¨ angt zu u uhren. Bei systema¨berf¨ tischer Anwendung lassen sich leicht Pr¨azedenzen in der Prozessausf¨ uhrung erreichen. 2.4.3

Beispiel 2.4.3 Gegeben seien die Prozesse P, Q und R, die immer nur in die-

ser Folge ausgef¨ uhrt werden sollen. Seien s und t Semaphore, die mit dem Wert 0 initialisiert sind. Dann ergibt sich die beabsichtigte Pr¨azedenz in der Prozessausf¨ uhrung durch folgende Operationen: P:: : : V(s);

Q:: P(s); : V(t);

R:: P(t); : :


Die fehlerhafte Anwendung blockierender Synchronisierungsoperationen kann zu Verklemmungen, bekannter unter dem Namen Deadlocks, f¨ uhren. Ein solcher Zustand betrifft eine Teilmenge D der Menge P aller Prozesse. Dabei gilt f¨ ur einen Prozess i ∈ D, dass er sich im Zustand blockiert befindet und kein Prozess j ∈ P \ D in der Lage ist, den Prozess i aus seinem Blockadezustand zu befreien. 2.4.4

Beispiel 2.4.4 Die Prozesse P und Q versuchen in unterschiedlicher Reihenfolge die kritischen Gebiete s und t zu betreten.

P:: : enter(s); : enter(t); : leave(t); : leave(s); :

Q:: : enter(t); : enter(s); : leave(s); : leave(t); :

2.4

Parallelit¨ at und Synchronisierung

127

Die Ausf¨ uhrung schreitet solange fort, bis der Fall eintritt, dass P bereits s und Q bereits t betreten hat. Als n¨ achstes fordert P das kritische Gebiet t und Q das kritische Gebiet s. In diesem Fall blockieren sich die beiden Prozesse gegenseitig und k¨ onnen sich aus dieser Blockade nicht selbst wieder befreien.
Deadlocks sind t¨ uckisch. So kann es sein, dass sie nur unter ganz bestimmten Reihenfolgen einzelner Prozessausf¨ uhrungen zustande kommen. In parallelen Programmen, die f¨ ur deadlockfrei gehalten wurden, k¨onnen unverhofft Deadlocks auftreten. Der Nachweis der Deadlockfreiheit auf der Grundlage des Programmcodes f¨ uhrt auf das Halteproblem und ist deshalb unentscheidbar. Aber selbst bei vereinfachenden Annahmen u ¨ber die Struktur und Ausf¨ uhrung von parallelen Programmen bleibt das Problem NP-vollst¨andig (vgl. unter vielen [70] und [132]). Das bedeutet, dass es grunds¨atzlich sehr aufw¨ andig ist, den Nachweis der Deadlockfreiheit zu f¨ uhren. Als Ausweg wird vorgeschlagen, solche Synchronisierungsmuster zu benutzen, die eine leichtere Analyse zulassen oder den Deadlock von vornherein ausschließen. Eine Klasse solcher Verfahren wird bei der Planung synchronisierter Prozesse vorgestellt (siehe Abschnitt 4.1.3). 2.4.4 Parallelit¨ at bei Mehrprozessorsystemen

¨ Im Bereich der Echtzeitsysteme trifft man des Ofteren auf die Vorstellung, dass eine vom technischen System vorgegebene harte Zeitbedingung erf¨ ullt werden kann, wenn nur gen¨ ugend Prozessoren zur Verf¨ ugung stehen. Dabei gibt es neben der Verringerung der Ausf¨ uhrungszeit weitere f¨ ur Echtzeitsysteme vorteilhafte Gr¨ unde, um mehrere Prozessoren zu nutzen: Es er¨ offnet sich die M¨ oglichkeit, den gleichzeitigen Abl¨aufen im technischen System gleichzeitige, d. h. echt parallele“, Ausf¨ uhrungen im Re” chensystem gegen¨ uberzustellen. Die topologischen Zusammenh¨ ange zwischen technischen Prozessen lassen sich nicht nur auf Prozessebene, sondern auch durch die Anordnung von Prozessoren repr¨ asentieren. Die Ausfallsicherheit des Rechensystems l¨asst sich durch Redundanzen beim Aufbau von Mehrprozessorsystemen erh¨ohen. Die am weitesten verbreitete und strukturell einfachste Mehrprozessorarchitektur koppelt mehrere Prozessoren u ¨ber einen externen Bus, beispielsweise einen Ger¨ atebus, an einen gemeinsamen Hauptspeicher und an periphere Ger¨ ate (siehe Abb. 2.31). Jeder Prozessor ist in der Lage, sein eigenes Pro-

128

2. Methodische und technische Grundlagen

gramm auszuf¨ uhren, was diese Architektur nach der Klassifizierung von Flynn (vgl. [45]) bei den MIMD-Architekturen21 einordnet.

Abb. 2.31. Mehrprozessorsystem durch unmittelbare Ankopplung von m Prozessoren an

den Bus.

Der Vorteil dieser Architektur liegt darin, dass sich die Prozessoren einen gemeinsamen physikalischen Adressraum teilen. Zwischen Prozessoren und damit auch zwischen Prozessen k¨ onnen gemeinsame Datenbereiche existieren. Die Konsistenz von gemeinsamen Daten, die in einem Buszyklus ver¨ andert werden kann, beispielsweise Bytes, Halbw¨orter und W¨orter, ist implizit gew¨ ahrleistet. Die Konsistenz gr¨oßerer Datenbereiche ist mit Hilfe von Synchronisierungsoperationen sicherzustellen, beispielsweise mit Hilfe des TAS-Befehls. Trotz dieser deutlichen Vorteile ist dieses Architekturkonzept meist nur f¨ ur wenige Prozessoren sinnvoll, da der externe Bus zu einem engen Flaschenhals f¨ ur die Leistungsf¨ ahigkeit des Mehrprozessorsystems werden kann. Folgende einfache Rechnung zeigt die Beziehung zwischen der Zahl der Prouhrungszeit, zessoren und der verf¨ ugbaren Rechenleistung. Sei ∆es die Ausf¨ die auf einem Einprozessorsystem notwendig ist, um eine gestellte Aufgabe zu l¨ osen. Angenommen, es seien m Prozessoren vorhanden und eine Aufspaltung in m Teilaufgaben m¨ oglich, wobei jede f¨ ur sich genommen die Ausf¨ uhrungszeit ∆ej auf einem Prozessor besitzt. Dabei sei: m

∆ej = ∆es

j=1

Die Ausf¨ uhrungszeit ∆ep auf einem Mehrprozessorsystem mit gemeinsamem Speicher wird dominiert von dem Maximum der Summe aus ∆ej und den aufgesammelten Wartezeiten ∆bj auf den Bus (j ∈ {1, . . . , m}). Setzt man vereinfachend voraus, dass die Teilaufgaben in etwa die gleiche Gr¨oßenordnung 21

multiple instruction, multiple data

2.4

Parallelit¨ at und Synchronisierung

129

haben ∆ej = ∆es /m

j ∈ {1, . . . , m}

und die maximale Wartezeit auf den Bus entscheidend ist ∆b = max{∆bj |j ∈ {1, . . . , m}} dann setzt sich die Ausf¨ uhrungszeit auf einem Mehrprozessorsystem folgendermaßen zusammen: ∆ep = ∆es /m + ∆b Entsprechend liegt die erhoffte Beschleunigung (engl. speedup) nicht beim Faktor m, sondern bei: ∆es ∆es = ∆ep ∆es /m + ∆b m = 1 + m∆b/∆es Selbst wenn man ganz optimistisch von der Annahme ausgeht, dass ∆b bei steigender Anzahl von Prozessoren konstant bleibt, wird die Beschleunigung durch den Faktor ∆es ∆es = lim m→∞ ∆es /m + ∆b ∆b begrenzt. Beispiel 2.4.5 F¨ ur den Faktor ∆es /∆b = 10 wird die Beschleunigung in

Abh¨ angigkeit von der Prozessorzahl aufgetragen. Dabei ist die Beschleunigung zum einen durch die Funktion m und zum anderen durch die Konstante ∆es /∆b nach oben hin begrenzt (siehe Abb. 2.32). Man sieht, dass insbesondere f¨ ur große m die Beschleunigung weit hinter der ¨ Prozessorzahl zur¨ uckbleibt. Ahnliche Absch¨ atzungen von Stone und Amdahl (vgl. [129] und [6]) kommen zu vergleichbaren Ergebnissen.
Daf¨ ur, dass die Beschleunigung so deutlich hinter dem Anstieg der Prozessorzahl zur¨ uckbleibt, ist einzig und allein der Wert ∆b und damit die Wartezeit auf den externen Bus verantwortlich. Dies ist eine grunds¨atzliche Eigenschaft einer MIMD-Architektur. Erst durch architektonische Maßnahmen, die die Wartezeit auf den externen Bus drastisch reduzieren, l¨asst sich dieses Konzept vern¨ unftig auf Systeme mit einer deutlich h¨oheren Anzahl als zwei Prozessoren erweitern. Cache-Speicher in erster und zweiter Hierarchiestufe sind außerordentlich hilfreich, wenn es darum geht, einen niedrigen ∆b-Wert zu

2.4.5

130

2. Methodische und technische Grundlagen

Abb. 2.32. Beschleunigung in Abh¨ angigkeit von der Prozessorzahl.

erreichen. Andererseits wird auch deutlich, dass der Zugriff auf periphere Ger¨ ate in ¨ ahnlicher Weise zu einem Flaschenhals werden kann. Hinzukommen elementare Synchronisierungsoperationen zwischen Prozessen auf unterschiedlichen Prozessoren, wie sie vom TAS- oder CAS-Befehl ausgehen. Sie sperren den gemeinsamen Bus f¨ ur mehr als einen Zyklus. 2.4.5 Migration von Prozessen bei Mehrprozessorsystemen

Unter der Migration wird im Zusammenhang mit Mehrprozessorsystemen der Wechsel der Prozessausf¨ uhrung von einem Prozessor zu einem anderen verstanden. Betriebssysteme f¨ ur Mehrprozessorsysteme stellen vielfach Programmierschnittstellen bereit, mittels derer die Migrationsf¨ahigkeit von Prozessen festgelegt wird. Typischerweise werden drei Grade der Migration von Prozessen unterschieden: (NoM) Ausschluss von Migration: In diesem Fall, der auch Partitionierung heißt, wird einem Prozess eindeutig ein Prozessor zugeordnet, auf dem alle seine Prozessausf¨ uhrungen stattfinden werden. Aus programmiertechnischer Sicht hat jeder der m Prozssoren eine lokale Warteschlange, in der alle Prozesse verwaltet werden, die auf diesem Prozessor ausgef¨ uhrt werden. Somit besteht ein solches System aus m unabh¨ angigen Einprozessorsystemen, auf das alle grundlegenden Planungsverfahren (siehe Kapitel 3) uneingeschr¨ankt angewendet werden d¨ urfen.

2.4

Parallelit¨ at und Synchronisierung

131

Ein wesentliches Problem bei diesem Fall ist die Aufteilung der Prour jede ein zessmenge P in m disjunkte Teilmengen P1 bis Pm , wobei f¨ brauchbarer Plan existiert. Das Entscheidungsproblem, ob f¨ ur eine gegebene Prozessmenge eine solche Aufteilung existiert, ist ¨aquivalent zum bin-packing-problem und damit NP-vollst¨ andig (vgl. [87]). (ExM) Migration von einer Prozessauf¨ uhrung zur n¨ achsten: Vor jeder Ausf¨ uhrung eines Prozesses wird entschieden, auf welchem Prozessor die Ausf¨ uhrung erfolgen soll. Programmiertechnisch gen¨ ugt hierbei eine globale Warteschlange, die die gesamte Prozessmenge P verwaltet. Ist einer Prozessausf¨ uhrung einmal ein Prozessor zugeordnet, dann bleibt diese Bindung bis zum Abschluss der Ausf¨ uhrung erhalten. (PrM) Migration w¨ ahrend der Prozessausf¨ uhrung: Dieser Fall eignet sich nur f¨ ur unterbrechbare Prozesse. Basierend auf einer einzigen globalen Schlange, die die gesamte Prozessmenge P umfasst, kann jede Prozessausf¨ uhrung jederzeit unterbrochen und auf einem anderen Prozessor weitergef¨ uhrt werden. Dabei ist der Mindestabstand zweier hintereinander erfolgender Wechsel des Prozessors auf die Bezugszeitspanankt. ne ∆tG beschr¨ Beispiel 2.4.6 Gegeben sei eine Menge P unterbrechbarer periodischer Prozesse und daraus stellvertretend der Prozess 3 mit seiner Ausf¨ uhrungszeit von ∆e3 = 4 Zeiteinheiten und der Periode von ∆p3 = 6 Zeiteinheiten. Ferner m¨ ogen zwei gleiche Prozessoren zur Verf¨ ugung stehen. Zwei aufeinander folgende Prozessausf¨ uhrungen k¨ onnen im Fall (NoM) so aussehen:

F¨ ur den Fall (ExM) ist Migration von Ausf¨ uhrung zu Ausf¨ uhrung erlaubt.

Im Fall (PrM) kann von einer Bezugszeitspanne zur n¨achsten ein Wechsel der Ausf¨ uhrung von einem Prozessor zu einem anderen erfolgen:

2.4.6

132

2. Methodische und technische Grundlagen


Programmiertechnisch, aber auch unter dem Gesichtspunkt der Vorhersagbarkeit ist offensichtlich die Kategorie (NoM) am einfachsten zu handhaben. Dagegen bieten die Verfahren der Kategorie (ExM) und noch viel mehr die der Kategorie (PrM) weitergehende Freiheiten bei der Plazierung von Prozessen auf Prozessoren. Dies hat jedoch den Preis, dass mit der Migration eines Prozesses auch dessen Daten im Cache-Speicher migririeren m¨ ussen, was zus¨ atzliche Ausf¨ uhrungszeit kostet. Diese Effekte sind bei der Bestimmung der Prozessparameter unbedingt zu ber¨ ucksichtigen. Erst dann k¨onnen Planungsverfahren f¨ ur Mehrprozessorsysteme zuverl¨assig eingesetzt werden (siehe Abschnitt 4.2).

2.5

Verteilte Echtzeitsysteme

133

2.5 Verteilte Echtzeitsysteme 2.5.1 Anforderungen an verteilte Echtzeitsysteme

Echtzeitsysteme m¨ ussen sich vielfach den ¨ ortlichen Gegebenheiten der technischen Systeme, denen sie zugeordnet sind, anpassen. Entsprechend werden Rechensysteme, im Folgenden als Knoten bezeichnet, dezentral aufgestellt und durch Rechnernetze miteinander verbunden. Kennzeichnend f¨ ur verteilte Echtzeitsysteme ist, dass die Prozesse, die auf unterschiedlichen Knoten angesiedelt sind, ausschließlich durch das Senden und Empfangen von Nachrichten miteinander in Verbindung stehen. Zudem sind Zeitbedingungen einzuhalten. Eine solche ist die Ende-zu-Ende-Antwortzeit, die diejenige Zeitspanne bezeichnet, die mit dem Eintreten eines Ereignisses in einem Knoten eine Berechnung beginnt und schließlich in einem anderen Knoten endet. Diese Art von Zeitbedingungen baut auf den Antwortzeiten auf, die f¨ ur eine er¨ folgreiche Ubertragung einer Nachricht von einem Knoten auf einen anderen ben¨ otigt werden. Beide Zeitspannen sind unmittelbar mit dem verwendeten Rechnernetz und dessen Eigenschaften verbunden. An weiteren Kenngr¨oßen, die in diesem Zusammenhang Bedeutung haben, sind das Flattern der Ant¨ wortzeiten, die Ubertragungsleistung und die Auslastung des Rechnernetzes zu nennen. Topologisch wird bei Rechnernetzen im Wesentlichen unterschieden zwischen Bussen, Sternen und Ringen. Dabei stellt der Bus eine Grundform der Vernetzung dar und tritt auch bei Sternen und Ringen wieder auf. Folglich ist ein ¨ Knoten mittels eines Bus-Controllers mit dem Ubertragungsmedium verbun¨ den. Uber eine Empfangskomponente E k¨ onnen die Signale, die auf dem Bus anliegen, abgeh¨ ort werden. Gleichzeitig kann u ¨ber eine Sendekomponente S ¨ ein Signal ausgegeben werden, das sich auf dem Ubertragungsmedium ausbreitet. Beliebige stern- und ringf¨ ormige Topologien lassen sich kanonisch aus Bus-Controllern und einzelnen Bussen aufbauen, was eine vereinheitlichende Sicht auf verteilte Echtzeitsysteme erm¨ oglicht (siehe Abb. 2.33). Geschichtlich betrachtet kamen verteilte Echtzeitsysteme zun¨achst in der Produktions- und Anlagentechnik zur Anwendung. Feldbusse (engl. fieldbus) u ¨bernehmen hier die Aufgabe, in vorhersagbarer Zeit Nachrichten zwischen Knoten zu u ¨bertragen. Auf diese Weise wird es m¨oglich, r¨aumlich verteilte technische Prozesse zu u ¨berwachen, fertigungs- und verfahrenstechnische Abl¨ aufe flexibel zu gestalten, Qualit¨ atskontrolle nahe am technischen Prozess durchzuf¨ uhren und einen hohen Automatisierungsgrad zu erreichen. Mit dem Ziel, Funktionalit¨ aten voneinander zu trennen, aber auch mit der Absicht Leistungsengp¨ asse zu vermeiden, werden in der Produktions- und Anlagentechnik Hierarchien von Bussystemen eingesetzt. Dabei wird der gesamte Fabrikbereich als das Feld (engl. field) betrachtet, gleichzeitig jedoch

2.5

134

2. Methodische und technische Grundlagen



 







 

 



 


  

 

Abb. 2.33. Generalisierendes Aufbauschema f¨ ur unterschiedliche Topologien von

Rechnernetzen.

zwischen Feldbussen und Fabrikbussen unterschieden. Zus¨atzlich gibt es Verbindungen zu den lokalen Netzwerken (local area networks oder LAN), wie sie im B¨ urobereich der Unternehmen eingesetzt werden. Generell gilt dabei, dass die zeitliche Vorhersagbarkeit um so zwingender erforderlich ist, je n¨aher die Bussysteme an den technischen Prozess heranreichen (siehe Abb. 2.34).

 


 


 

    








 








 


Abb. 2.34. Eine Hierarchie von Ebenen kennzeichnet die Rechnernetze von

produzierenden Unternehmen.

Grunds¨ atzlich ¨ ahnlich sind die Rechnernetze, die in Fahrzeugen, Flugzeugen und Schiffen eingesetzt werden. Gerade f¨ ur Fahrzeuge gilt, dass die unterste Ebene der Hierarchie von den Steuerger¨ aten (engl. electronic control unit oder ECU) gebildet wird. Diese werden fortan ebenfalls als Knoten bezeichnet und bestehen aus einem Rechensystem, Sensoren und Aktoren sowie einer oder mehreren Anbindungen an Rechnernetze. Auch hier sind mittlerweile

2.5

Verteilte Echtzeitsysteme

135

Hierarchien von Rechnernetzen u aumlich und funktional getrennte ¨blich, die r¨ Aufgaben im Fahrzeug u ¨bernehmen. Beispiel 2.5.1 Bezogen auf die Vernetzung von Serienfahrzeugen nehmen Lastkraftwagen mit Anh¨ anger eine exponierte Stellung ein. Ihre Steuerger¨ate liegen r¨ aumlich am weitesten voneinander entfernt, und u ¨ber das Rechnernetz an Bord ist eine extreme Breite an Funktionen abzuwickeln. So lautet eine informelle Anforderung, dass alle Fahrtrichtungsanzeiger unmittelbar im Anschluss an die Bet¨ atigung des Warnblinkschalters an der Lenks¨aule in regelm¨ aßigem Takt aufleuchten sollen. Aus Sicht eines anderen Verkehrsteilnehmers soll kein zeitlicher Abstand im Blinken der einzelnen Fahrtrichtungsanzeiger zu erkennen sein. Die Bet¨ atigung des Warnblinkschalters wird zun¨achst vom Lenks¨aulenmodul erfasst und dem Grundmodul22 des Lastwagens u ¨bermittelt (siehe Abb. 2.35). Von da ab steuert das Grundmodul das An- und Abschalten aller Fahrtrichtungsanzeiger sowie die Ausgabe eines optischen und akustischen Signals auf der Armaturentafel. Auf dem Lastwagen sind die Fahrtrichtungsanzeiger die Ausgabeger¨ ate von Lichtmodulen und werden u ¨ber den Karosseriebus erreicht. Zum Lichtmodul im Anh¨ anger f¨ uhrt der Weg u ¨ber ein Grundmodul des Anh¨ angers. Das Bussystem ist hierarchisch gegliedert. Es verf¨ ugt auf oberster Ebene u ¨ber ein Backbone-Rechnernetz, an dem insbesondere das Grundmodul des Lastkraftwagens angebunden ist. Daneben stellt der Karrosseriebus und der Anh¨ angerbus je ein funktional eingegrenztes Teilnetz dar. In diesem Zusammenhang lautet eine typische Forderung, dass die Ende-zuEnde-Antwortzeit von der Erfassung der Bet¨ atigung des Warnblinkschalters bis zum Aufleuchten der Fahrtrichtungsanzeiger weniger als 75ms betragen sollen. Des Weiteren gibt es zeitliche Anforderungen f¨ ur die Fahrtrichtungsanzeiger untereinander. Beispielsweise soll gelten, dass sich die An- und Ausschaltzeitpunkte von je zwei Fahrtrichtungsanzeigern um nicht mehr als 25ms unterschieden sollen.


Feldbusse sind typischerweise drahtgebunden. Mittlerweile gibt es jedoch bereits eine Reihe von drahtlosen Rechnernetzen, die von sich behaupten echtzeitf¨ ahig zu sein. Dieser Anspruch stellt bei drahtlosen Netzen eine weitaus gr¨ oßere Herausforderung dar als bei drahtgebundenen. Wesentlich hierf¨ ur sind die erh¨ ohte St¨ oranf¨ alligkeit und die schwierige r¨aumliche Abgrenzbarkeit. Anderseits gibt es eine erhebliche Nachfrage nach drahtlosen Netzwerken, bei denen unter definierten Voraussetzungen die zeitliche Vorhersag22

¨ Vergleiche Ubereinstimmungen und Unterschiede im Aufbau des Rechnernetzes zwischen einem LKW und einem PKW (siehe Abb. 1.18).

2.5.1

136

2. Methodische und technische Grundlagen

 

  

  

  



  


  


 
 

   
 
 


 

 

Abb. 2.35. Gliederfahrzeuge, wie ein Lastwagen mit seinem Anh¨ anger, verf¨ ugen u ¨ber

komplexe, hierarchisch gegliederte Bussysteme.

barkeit, beispielsweise obere Schranken f¨ ur Ende-zu-Ende-Antwortzeiten, gegeben ist. Eine Unzahl von Forschungs- und Enwicklungsarbeiten f¨ ur sehr ¨ unterschiedliche Anwendungsfelder sind auf den Weg gebracht. Ubersichten zu den verwendetete Konzepten und Strategien sind dagegen eher selten (vgl. [81] und [1]). Da sich aus den oben erw¨ ahnten Forschungs- und Entwicklungsarbeiten noch nicht die wegweisenden herausgebildet haben, und das gesamte Wissensgebiet der drahtlosen Echtzeitnetze somit noch einen ungen¨ ugenden Reifegrad ausweist, wird im Weiteren nur noch auf drahtgebundene Rechnernetze f¨ ur verteilte Echtzeitsysteme Bezug genommen. Im Vordergrund steht als N¨ achstes der grunds¨ atzliche Aufbau solcher Rechnenetze, um im Anschluss daran die eingesetzen Zugriffsprotokolle, die den Zugriff der Knoten auf das ¨ Ubertragungsmedium sichern, zu diskutieren. 2.5.2 Aufbauprinzipen von Rechnernetzen ¨ Ahnlich wie f¨ ur Echtzeitsysteme gilt auch f¨ ur Rechnernetze, dass von ihnen eine ganze Reihe von Themenbereichen ber¨ uhrt wird. Im einzelnen betrifft das beispielsweise ¨ die physikalisch-technischen M¨ oglichkeiten, die ein Ubertragungsmedium bietet, ¨ die Art und Weise, wie von einem Knoten auf das Ubertragungsmedium

zugegriffen werden darf,

2.5

Verteilte Echtzeitsysteme

137

die Festlegung von Formaten f¨ ur Nachrichten, die auf dem Medium u ¨bertragen werden, den Auf- und Abbau von Verbindungen und die programmiertechnischen M¨ oglichkeiten, damit zwei Prozesse in einer gemeinsamen Anwendung miteinander kooperieren k¨onnen. Die aufgelisteten Spiegelpunkte korrespondieren zu unterschiedlichen Ebenen des Aufbaus und der Handhabung von Rechnernetzen. So hat der Entwickler einer verteilten Anwendung vorrangig mit der programmiertechnischen Schnittstelle zum Rechnernetz zu tun. Darunter liegende Ebenen treten unter diesem Blickwinkel in den Hintergrund. Dennoch ist es f¨ ur weitergehende Fragestellungen und zu treffende Entwurfsentscheidungen wichtig, die Breite der betroffenen Themengebiete u ¨berblicken zu k¨onnen. Das gilt in besonderem Maße f¨ ur daraus abgeleitete Eigenschaften wie z.B.: die erlaubten Entfernungen zwischen Knoten, die topologische Struktur, ¨ die zu erwartende Ubertragungsleistung und die zu erwartenden Kosten f¨ ur Installation, Betrieb und Wartung. Konkret mit Bezug auf verteilte Echtzeitsysteme sind spezifische Merkmale durch die einzusetzenden Rechnernetze zu erf¨ ullen. Dabei handelt es sich um: ¨ garantierte Ubertragungsleistungen zwischen kooperierenden Prozessen, maximale und minimale Ende-zu-Ende-Antwortzeiten und geeignete programmiertechnische Operationen zur effektiven Nutzung der F¨ ahigkeiten von Rechnernetzen. Sollen diese vielf¨ altigen Eigenschaften beherrschbar werden, dann ist eine sorgf¨ altige Aufteilung der Aufgaben zweckm¨ aßig. Unabh¨angig von den spezifischen Merkmalen von Echtzeitsystemen ist, mit dem Ziel, eine offene, d. h. herstellerunabh¨ angige, Kommunikation zu erm¨oglichen, das ISO/OSI-Basisreferenzmodell [66] eingef¨ uhrt worden. Dieses eignet sich mit seinem siebenschichtigen Aufbau recht gut, um die von verteilten Echtzeitsystemen an Rechnernetze ausgehenden Anforderungen zu kategorisieren und bez¨ uglich ihrer hervorstechenden Merkmale zu betrachten. Die meisten der unmittelbar oder im weiteren Sinne f¨ ur zeitkritische Anwendungen konzipierten Komponenten von Rechnernetzen beziehen sich bei der Festlegung der von ihnen abgedeckten Aufgabengebiete auf dieses Referenzmodell. Obwohl es in der Fachliteratur sehr breit behandelt wird (vgl. unter anderen [131] und [56]) ist es zum Verst¨ andnis der f¨ ur Echtzeitsysteme relevanten Rechnernetze an¨ gebracht, einen kurzen Uberblick zum Referenzmodell zu geben.

138

2. Methodische und technische Grundlagen

Ausschlaggebend f¨ ur die Definition jeweils einer der sieben Schichten war ein deutlicher Sprung im Grad an Abstraktion. Jede Schicht vermittelt eine eigene Sicht auf das Rechnernetz. Dazu bietet jede Schicht eine Reihe von Diensten an, wie z.B. das Versenden einer Nachricht und den Empfang einer Best¨ atigung (siehe Abb. 2.36). Wie der Dienst im Einzelnen von der jeweiligen Schicht erledigt wird, ist nicht festgelegt. Fest steht nur, dass dazu die Dienste der n¨ achstniedrigeren Schicht benutzt werden k¨onnen. Diese bilden somit auch die Basis f¨ ur die Echtzeiteigenschaften der dar¨ uberliegenden Schichten. Mit dem Ziel, das Rechnernetz f¨ ur die Anwendung transparent zu machen, bleiben die Dienste der darunterliegenden Schichten verborgen. So soll der Eindruck entstehen, direkt nach festgelegten Regeln, dem so genannten Protokoll oder Kommunikationsprotokoll, mit der gleichen Schicht eines entfernten Knotens zu kommunizieren. Einem solchen Protokoll gem¨aß wartet der entfernte Knoten auf eine Nachricht, um im Anschluss daran eine Best¨ atigung zu schicken.






  
 

 




  

 


Abb. 2.36. Die Dienste der Schicht i werden auf die Dienste der n¨ achstniedrigeren Schicht

abgebildet. F¨ ur das abstrakte Verst¨ andnis gen¨ ugt es jedoch, die Abwicklung eines Dienstes durch das Protokoll der Schicht i zu erkl¨ aren.

Das Referenzmodell ist grundlegend durch eine Zweiteilung gepr¨agt (siehe Abb. 2.37): Transportorientierte Schichten: ¨ Unmittelbar aufsetzend auf das Ubertragungsmedium dienen vier Schichten dem Transport von Nachrichten zwischen zwei Knoten. Anwendungsorientierte Schichten: Drei Schichten dienen der anwendungsorientierten Bereitstellung von Diensten, die in komfortabler Weise von den Rechenprozessen entfernter Knoten in Anspruch genommen werden k¨onnen. Die folgenden ausgew¨ ahlten Aufgaben fallen den transportorientierten Schichten zu: 1. Physikalische Schicht: ¨ Ubertragung des Bitstroms auf dem Medium, Interpretation elektrischer Pegel, Normung von Steckern, Festlegung der Datenrate. 2. Verbindungsschicht: ¨ Gruppierung von Bitstr¨ omen zu Rahmen (engl. frame), sichere Uber-

2.5

Verteilte Echtzeitsysteme

139












 




 
 

 





 
 

 



  
 

 



  
 

 


Abb. 2.37. Grundlegende Zweiteilung im Referenzmodell.

tragung von Rahmen zwischen zwei unmittelbar benachbarten Knoten, ¨ Techniken zum Zugriff auf das Ubertragungsmedium, Erkennung und Be¨ handlung von Ubertragungsfehlern. 3. Vermittlungsschicht: ¨ Gruppierung von Rahmen zu Paketen, Ubertragung von Paketen zwischen beliebigen Knoten, Auswahl eines Weges im Netz, Kontrolle des Paketflusses im Netz. 4. Transportschicht ¨ Ubertragung von Nachrichten zwischen beliebigen Knoten, Zerlegung von Nachrichten in Pakete, Zusammenf¨ ugen der Pakete zu Nachrichten, Zuordung einer Nachricht zu einem Prozess eines Knotens, Fehlerbehandlung bei verlorengegangenen Paketen, sicheres Wiederaufsetzen. Die dar¨ uberliegenden anwendungsorientierten Schichten richten sich nach den Erfordernissen der Benutzung: 5. Sitzungsschicht: Auf- und Abbau einer Verbindung zwischen kooperierenden Prozessen, ¨ st¨ andige Uberpr¨ ufung der Verf¨ ugbarkeit des entfernten Knotens. 6. Darstellungsschicht: Verabredung von Datenformaten, Kompression von Daten, Schutz vor unberechtigtem Zugriff durch Verschl¨ usselungstechniken. 7. Anwendungsschicht: Bereitstellung anwendungsspezifischer Transfer- und Dialogdienste, Techniken zur Autorisierung und Authentifizierung, Integration der Dienste in das lokale Betriebssystem sowie Verf¨ ugbarkeit von programmiertechnischen Operationen nach dem Kunde-Bediener-Prinzip (engl. client-serverprinciple) .

140

2. Methodische und technische Grundlagen

Insbesondere im Hinblick auf die zentrale Eigenschaft von Echtzeitsystemen, n¨ amlich die Vorhersagbarkeit ihres zeitlichen Verhaltens, geben Rechnernetze eine schwierige Aufgabe auf. Denn u ur Sorge ¨ber alle Schichten hinweg ist daf¨ zu tragen, dass die f¨ ur Dienstleistungen notwendigen Zeitspannen nach oben hin absch¨ atzbar werden. Gl¨ ucklicherweise ist die geforderte Durchg¨angigkeit f¨ ur viele im Echtzeitbereich eingesetzten Rechnernetze, insbesondere was die Feldbusse betrifft, nicht u ¨ber alle sieben Schichten hinweg sicherzustellen. Vielfach gen¨ ugt eine Betrachtung der Schichten 1, 2 und 7, wobei Schicht 7 in erster Linie in ihrer Rolle des programmiertechnischen Bindegliedes zu den Anwendungsprozessen hin von Bedeutung ist. ¨ Zwar legt die Schicht 1 auf der Basis des eingesetzten Mediums eine Ubertragungsleistung fest. Sie steht jedoch bei den verbreiteten Netzen, bei denen viele Knoten auf dasselbe Medium zugreifen k¨onnen, nicht st¨andig zur Verf¨ ugung. Erst wenn sich ein einzelner Knoten in den Besitz des Mediums gebracht hat, kann er f¨ ur den jeweils zu u ¨bertragenden Rahmen die volle Leistungsf¨ ahigkeit des Mediums veranschlagen. Der Erwerb des Zugriffsrechtes auf das Medium stellt einen Teil der Aufgaben der Schicht 2 dar und wird auch als MAC23 -Zwischenschicht bezeichnet. Zusammen mit der LLC24 Zwischenschicht bilden sie die Verbindungsschicht. ¨ Abh¨ angig vom Medium, der Ubertragungsgeschwindigkeit, der Topologie und dem Anwendungsspektrum haben sich f¨ ur die MAC-Zwischenschicht die unterschiedlichsten Zugriffsprotokolle entwickelt. Sie sind f¨ ur die Echtzeiteigenschaften des Rechnernetzes von maßgeblicher Bedeutung. Denn bereits aufgrund des Zugriffsprotokolls sind einige Rechnernetze außerstande, harte Zeitbedingungen einzuhalten und eignen sich nur noch bedingt f¨ ur den Einsatz in Echtzeitsystemen. 2.5.3 Zugriffsprotokolle

Nachrichten bilden die Einheiten, mit denen die Anwendungsprozesse eines verteilten Echtzeitsystems untereinander kommunizieren und kooperieren. Auf der MAC-Zwischenschicht ist dagegen der Rahmen (engl. frame) die ¨ Ubertragungseinheit. Entsprechend ist es notwendig, verschiedene Nachrichten in einen Rahmen zu packen oder umgekehrt mehrere Rahmen f¨ ur eine Nachricht zu verschicken. W¨ ahrend die Aufgaben h¨ oherer Schichten von der Software eines Knotens abgewickelt werden, ist die MAC-Zwischenschicht u ¨blicherweise in Hardware realisiert. Zu diesem Zweck besitzt ein Knoten einen Bus-Controller, dessen Aufgabe es ist (siehe auch Abb. 2.44), 23 24

medium access, Schicht 2a logical link control, Schicht 2b

2.5

Verteilte Echtzeitsysteme

141

Rahmen, die zu versenden sind, zwischenzuspeichern, um sie zu einem g¨ unstigen Zeitpunkt auf dem Medium zu u ¨bertragen, und Rahmen, die an den Knoten gerichtet sind, als solche zu erkennen, sie zu empfangen, zwischenzuspeichern und zur Abholung bereitzustellen. Zu einem Zeitpunkt kann h¨ ochstens ein Rahmen u ¨bertragen werden. Gleichzeitig k¨ onnen jedoch mehrere Rahmen bei verschiedenen Bus-Controllern zur ¨ Versendung anstehen. Der Bus als Ubertragungsmedium wird somit zu einem knappen Betriebsmittel. Die Bus-Controller, die an einen Feldbus angeschlossen sind, k¨onnen unabh¨ angig von der Anwendung als verteiltes Echtzeitsystem verstanden werden. Jeder Bus-Controller f¨ uhrt dabei seinen Anteil an einem verteilten Algorithmus aus, so dass in seiner Gesamtheit ein Kommunikationsprotokoll abgewickelt wird. Die zentrale Forderung besteht darin, dass der verteilte Algorithmus nach begrenzter Zeit einen eindeutig bestimmten Rahmen u ¨bertr¨agt. Sehr unterschiedliche Kommunikationsprotokolle stehen zur Verf¨ ugung, die dieser Forderung ganz oder gr¨ oßtenteils nachkommen. Einige davon werden ¨ im Folgenden besprochen (f¨ ur eine weitergehende Ubersicht vgl. [124] und [102]): (A) Zentralisierte Verfahren: Protokolle dieser Art fußen auf dem Anfrage- oder Polling-Prinzip. Sie setzen voraus, dass es einen ausgezeichneten Knoten (den Master) gibt, ¨ der die Ubertragung von Rahmen auf den Bus und damit letztendlich auch die Buszugriffe der anderen Knoten (den Slaves) bestimmt. Man spricht deshalb auch von Master/Slave-Protokollen. Alle Rahmen werden per Rundruf (engl. broadcast) verschickt. Dabei enth¨ alt der Rahmen neben Synchronisierungs- und Diagnosebits zun¨achst ein Kennzeichen, das ihn eindeutig identifiziert, gefolgt von den Nutzdaten.






  



     Abb. 2.38. Grobes Schema eines Rahmens beim zentralisierten Verfahren.

Alle Knoten h¨ oren mit, wenn ein Master beginnt, einen Rahmen zu senden. Auf diese Weise kann jeder Knoten das Kennzeichnen erfassen und daran erkennen, ob und welche Aufforderung von dem jeweiligen Rahmen ausgeht. So gibt es f¨ ur jeden Rahmen einen Knoten, der am Kennzeichen erkennt, dass er aufgefordert ist, die Nutzdaten des Rahmens zu senden. Gleichzeitig k¨ onnen beliebig viele Knoten diese Nutzdaten empfangen.

142

2. Methodische und technische Grundlagen

Ein wesentliches Kennzeichen dieser Zugriffsverfahren ist es, dass ein Bit w¨ ahrend des Sendens von allen u ¨brigen Knoten abgeh¨ort werden kann. Damit ergibt sich f¨ ur solche Protokolle eine Wechselwirkung zwischen der ¨ Ubertragungsrate und der m¨ oglichen Ausdehnung des Rechnernetzes (siehe Aufgabe 2.5.1). Beispiel 2.5.2 Besonders in der Automobilindustrie herrscht ein erheblicher Kostendruck und ein dringendes Verlangen nach kosteng¨ unstigen Feldbussen f¨ ur eingeschr¨ ankte Aufgabengebiete. Ein solcher Feldbus ist der LIN25 -Bus, der von einem Firmenkonsortium, an dem deutsche Autohersteller maßgeblich beteiligt waren, initiiert und spezifiziert wurde. Die Ansatzpunkte f¨ ur ein kosteng¨ unstiges Bussystem liegen in folgenden Eigenschaften: ¨ geringe Ubertragungsrate von 20KB/s, ¨ Verwendung einer Eindrahtleitung als Ubertragungsmedium, Verzicht auf einen Quartz-Oszillator als Taktgeber des BusControllers.

2.5.2

In einer Hierarchie von Netzwerken ist der LIN-Bus auf der niedrigsten Stufe angesiedelt. Als typischer Subbus wird ein spezielles Aufgabengebiet abgedeckt, so beispielsweise besondere Dienste aus dem Komfortbereich eines Personenkraftwagens. Dazu z¨ ahlen unter anderem die Steuerger¨ate f¨ ur die Motoren, die die Sitzpositionen von Fahrer und Beifahrer manipulieren, und die Steuerger¨ ate zur Heizungsregelung der Sitze. Ein Master ist f¨ ur den Subbus zust¨ andig und stellt in der Rolle des Gateway die Verbindung zu den u ¨brigen Rechnernetzen im Personenkraftwagen her (siehe Abb. 2.39).

    

   


    


 

     


        

Abb. 2.39. Der LIN-Subbus mit Anbindung an ein Rechnernetz einer h¨ oheren

Hierarchiestufe.

Selbst kleine Subbusse, wie sie beim LIN-Bus auf 16 Knoten und 64 Rahmen beschr¨ ankt sind, lassen sich nur mit Hilfe entsprechender Entwurfs-, 25

Local Interconnect Network, siehe auch www/lin-subbus.org

2.5

Verteilte Echtzeitsysteme

143

Implementierungs- und Installationswerkzeuge effizient handhaben. Dazu existiert als Ausgangspunkt eine zentrale Spezifikation aller Knoten und Rahmen. Dort wird insbesondere festgelegt: die Zuordnung der Kennzeichen und damit verbunden auch der Rahmen zu den Knoten, die die Nutzdaten zu senden haben, und die Zyklen, in denen der Master einzelne Kennzeichen senden wird. Diese Spezifikation bildet die Grundlage f¨ ur Berechnungen zur Auslastung des Subbusses und zur Analyse der Antwortzeiten.
(B) Arbitrationsverfahren: Wie beim vorangegangenen Verfahren dauert das Versenden eines Bits so lange, dass es alle u oren k¨onnen. Unter den Bit-Werten ¨brigen Knoten mith¨ gibt es eine Rangordnung: rezessive und dominante Bits. Ein dominantes Bit D, das von einem Knoten A gesendet wird, verdeckt auf dem Bus ein rezessives Bit R, das von einem Knoten B gesendet wird.

Knoten B

Bus R D

Knoten R R D

A D D D

Die Rangordnung der Bit-Werte bildet die Grundlage des Arbitrationsverfahrens. Diese Rangordnung garantiert, dass im Konfliktfall, wenn meh¨ rere Knoten die Ubertragung eines Rahmens beginnen, nur ein Rahmen gesendet wird. Dazu besitzt jeder Rahmen ein eindeutiges Kennzeichen, das als seine Priorit¨ at aufzufassen ist und nur von genau einem Knoten versendet werden darf. ¨ Ist das Ubertragungsmedium frei, dann beginnen alle Knoten, in deren ¨ Bus-Controller ein Rahmen zur Ubertragung ansteht, damit, nach einem dominanten Startbit ihre Priorit¨ at zu verschicken. Dabei gilt die Regel, dass ein Knoten, den Versuch einen Rahmen zu versenden, aufgibt, wenn er ein rezessives Bit R sendet, auf dem Bus jedoch der dominante Bitwert D zu h¨ oren ist. Wegen der Eindeutigkeit der versendeten Kennzeichen bleibt ein einziger Knoten u ¨brig, der seinen Rahmen verschicken darf (siehe Abb. 2.40). Aufgrund der dezentralen Koordination der Buszugriffe und der Vermeidung von Kollisionen spricht man vom CSMA/CA-Protokoll26 . Alle Knoten sind gleichberechtigte und erst die Priorit¨at der aktuell zu versenden26

Carrier Sense Multiple Access / Collision Avoidance

144

2. Methodische und technische Grundlagen

























Abb. 2.40. Der Vorgang der Arbitration, bei dem schließlich




ein Knoten u ¨brig bleibt und seinen Rahmen versenden darf.

den Rahmen entscheidet u ¨ber die konfliktfreie Vergabe des Busses. Dazu ist vorab eine Absprache dar¨ uber zu treffen, welcher Rahmen welche Priorit¨ at besitzen soll, welcher Knoten welchen Rahmen senden darf und welche Knoten welche Rahmen empfangen, d.h. in ihrem BusController speichern sollen. Beispiel 2.5.3 Der CAN27 -Bus ist der herausragende Vertreter eines Feld-

2.5.3

busses, der nach dem Arbitrationsverfahren arbeitet. Er hat seit seiner Entwicklung, die Mitte der achtziger Jahre bei der Robert Bosch GmbH begann, einen unvergleichlichen Siegeszug angetreten und die Verbreitung der Steuerger¨ ate in Fahrzeugen entscheidend befl¨ ugelt. Bus-Controller f¨ ur CAN wurden 1991 zum ersten Mal bei der Firma Daimler serienm¨aßig in Fahrzeuge eingebaut, und 1994 wurde CAN 2.0 auf der Basis verdrillter Zweidrahtleitungen zum ISO-Standard 11898 erhoben. Die St¨ uckzahlen der Bus-Controller, die j¨ ahrlich produziert und verbaut werden, n¨ahern sich der Milliardengrenze. Die Arbitration erfolgt beim CAN Bus mittels eines 11-Bit (CAN 2.0 A) langen oder eines 29-Bit (CAN 2.0 B) langen Kennzeichens, das die Priorit¨ at des Rahmens verk¨ orpert. Im Rahmen (siehe Abb. 2.41) sind neben den Nutzdaten von bis zu 8Byte auch eine Reihe von Mechanismen integriert, die die Selbstdiagnose durch die Bus-Controller untereinander und eine externe Diagnose auf dem Weg u utzen. ¨ber das Grundmodul unterst¨


 








                      !     "#  $$ %   &    #  

Abb. 2.41. Aufbau eines Rahmens beim CAN-Protokoll. 27

Controller Area Network, siehe auch www.can-cia.org

2.5

Verteilte Echtzeitsysteme

145

Aufgrund des Arbitrationsverfahrens gibt es eine Wechselwirkung zwi¨ schen der Ubertragungsrate und der Ausdehnung von CAN-Bussen. ¨ Gleichzeitig ist die maximale Ubertragungsrate bei verf¨ ugbaren BusControllern auf 1M Bit/s begrenzt. F¨ ur diesen Fall darf aus Gr¨ unden der elektromagnetischen Vertr¨ aglichkeit die Ausdehnung des Bussystems 40m ¨ nicht u sind l¨angere ¨berschreiten. Erst bei niedrigeren Ubertragungsraten Busse erlaubt (siehe Abb. 2.42). Es ist abzusehen, dass die protokollbedingte Wechselwirkung zwischen ¨ der Ubertragungsrate und der Ausdehnung in absehbarer Zeit die Bedeutung des CAN-Busses beschneiden wird. Denn der Bedarf an Daten, die zwischen Steuerger¨ aten ausgetauscht werden, steigt kontinuierlich, was zuk¨ unftig zu einer Verdr¨ angung des CAN-Busses in weiten Bereichen f¨ uhren wird.     
 



 

Abb. 2.42. Protokollbedingte

     







Wechselwirkung zwischen der Ausdehnung des Rechnernetzes ¨ und der Ubertragungsrate beim CAN-Bus .


Aufgabe 2.5.1 (siehe Seite 280) Beim Arbitrationsverfahren haben drei

Zeitspannen eine besondere Bedeutung und m¨ ussen aufeinander abgestimmt sein. Da ist zun¨ achst die Sendedauer eines Bits ∆tBit . Vom Beginn des Sendens an wartet ein Knoten die Zeitspanne ∆tP robe ab, um dann zu horchen, ob der Bitwert, den er gesendet hat, auch der Bitwert ist, der auf dem Bus zu h¨ oren ist. Schließlich gibt es die Signallaufzeit ∆tSig . Es handelt sich um die Zeitspanne, die ein Signal f¨ ur seine Ausbreitung von einem Ende des Busses zu anderen ben¨ otigt. ¨ Uberlegen Sie, in welcher Beziehung die Zeitspannen ∆tBit , ∆tP robe und ∆tSig zueinander stehen m¨ ussen, damit eine eindeutige Arbitrierung gew¨ ahrleistet ist.
(C) Markengesteuerte Verfahren: Ein Knoten darf bei diesem Verfahrenstyp nur dann Rahmen senden, wenn er im Besitz einer Marke (engl. token) ist. Diese Marke, die es nur einmal im Rechnernetz geben darf, wird selbst auch durch das Versenden von

2.5.1

146

2. Methodische und technische Grundlagen

Nachrichten zwischen den Knoten weitergegeben. Unterschieden werden zwei Varianten, die bekannt sind als Token Ring und als Token Bus. Ihrer Bezeichnung entsprechend ist eine ringf¨ormige oder busf¨ormige Topologie der Vernetzung der Knoten vorauszusetzen. Bei der ringf¨ ormigen Vernetzung hat jeder Knoten aus der Topologie des Netzes heraus einen eindeutig bestimmten Nachfolgeknoten. Bei der busf¨ ormigen Vernetzung wird der eindeutige Nachfolgeknoten durch eine vorab zu vergebende Nummerierung der Knoten vorgegeben. Auf diese Weise kommt bei beiden Varianten ein logischer Ring zustande. Einmal im Besitz der Marke kann der Knoten f¨ ur eine beschr¨ankte Zeit¨ spanne Rahmen verschicken. Ublicherweise wird in diesem Zusammenhang unterschieden zwischen: synchronen Rahmen, die ein Knoten, der im Besitz der Marke ist, immer senden darf, asynchronen Rahmen, die ein Knoten nur senden darf, wenn noch gen¨ ugend Zeit zur Verf¨ ugung steht. Beispiel 2.5.4 Der PROFIBUS28 ist ein Feldbus, der in der Produktions-

2.5.4

und Anlagentechnik eingesetzt wird und ein breites Anwendungsspektrum abdecken muss. Er besitzt ein gestuftes Kommunikationsprotokoll, das nebeneinander ein Master/Slave-Protokoll und markengesteuertes Protokoll abwickeln kann. Der PROFIBUS wurde ab 1987 in Deutschland als ein o ordertes Verbundvorhaben von verschiedenen Firmen und In¨ffentlich gef¨ stituten erarbeitet und hat eine starke Marktstellung in seiner Branche erreicht. Die Koordinierung zweier Zugriffsprotokolle wird beim PROFIBUS dadurch erreicht, dass die Knoten in aktive (Master) und passive (Slaves) unterschieden werden. Nur unter den Mastern kommt das markengesteuerte Verfahren zur Anwendung. Jeder Master, der gerade im Besitz der Marke ist, kommuniziert f¨ ur eine beschr¨ankte Zeit mit einem Subsystem von passiven Knoten nach dem Master/Slave-Protokoll (siehe Abb. 2.43).
(D) Zeitmultiplex-Verfahren: Das Erreichen einer Uhrzeit ist der Ausl¨oser f¨ ur das Verschicken eines Rahmens. Dazu muss es einen vorher bestimmten Plan geben, der jedem Bus-Controller mitteilt, zu welchem Zeitpunkt er f¨ ur welche Zeitspanne ¨ senden darf. Die Ubertragungsrate, mit der gesendet wird, ist nur an die 28

siehe www.profibus.com

2.5

Verteilte Echtzeitsysteme

147

 
 
  
 








  
 


 

Abb. 2.43. Die Knoten A, B und C arbeiten nach dem markengesteuerten Verfahren,

w¨ ahrend der Master A mit seinen Slaves V, W und X nach dem zentralisierten Verfahren kommuniziert.

¨ physikalischen Eigenschaften des Ubertragungsmediums und die zu erwartenden St¨ oreinfl¨ usse gebunden und kann deshalb sehr hoch sein. ¨ Die Vergabe des Ubertragungsmediums nach dem Zeitmultiplexverfahren setzt eine aufw¨ andige Vorbereitung voraus. So ist vorab ein expliziter Plan zu erstellen, aus dem hervorgeht, ab welchem Startzeitpunkt ¨ einem Knoten f¨ ur eine festgelegte Zeitspanne das Ubertragungsmedium zur Verf¨ ugung steht. Wegen der vorzunehmenden Zerlegung der Zeitachse und der Zuordnung von Zeitspannen zu Knoten findet auch der Name TDMA29 -Protokoll Verwendung. Kennzeichnendes Merkmal ist ein hoher Grad an Determiniertheit, der systematisch zu organisieren ist. So ist der Plan typischerweise in Runden (engl. rounds) und Zyklen (engl. cycles) zerlegt. Die Runden sind in Schlitze (engl. slots) gegliedert, die mindestens so lange dauern, dass darin ein Rahmen gesendet werden kann. Alle Runden und alle Schlitze beanspruchen jeweils eine gleiche Zeitspanne (siehe Abb. 2.44).


 



 


 

 

Abb. 2.44. Der Verkehr auf dem Bus ist

permanent und teilt sich in Runden, Zyklen und Schlitze.

Das Erwarten des Startzeitpunktes, zu dem ein Knoten einen Rahmen senden darf, obliegt dezentral jedem einzelnen Knoten. Dazu besitzt jeder Knoten einen Uhrbaustein, der idealerweise synchron mit allen Uhren aller anderer Knoten l¨ auft. Technisch wird dies durch Algorithmen zur Uhrsynchronisierung erreicht, die die Abweichung πV vom Gleichlauf begrenzen. Die Uhrsynchronisierung ist ein Teil des Kommunikationsprotokolls.

29

Time Division Multiple Access

148

2. Methodische und technische Grundlagen

Beispiel 2.5.5 Der hohe Grad an Determiniertheit, der mit dem Zeitmultiplexverfahren erreicht werden kann, pr¨adestiniert solche Busse f¨ ur Anwendungen mit hohen und h¨ ochsten Anforderungen an Sicherheit und Zuverl¨ assigkeit. Solche waren im Bereich der Flugzeugtechnik schon immer gegeben, kommen heute aber auch immer st¨arker bei Fahrzeugen zum Tragen. Vorreiter sind dabei die so genannten X-by-wire-Technologien, wie beispielsweise elektronische Bremssysteme und elektronische Lenksysteme. Die bedeutendsten Vertreter des Zeitmultiplexverfahrens sind TTP/C30 und FlexRay31 . Beide zielen sowohl auf zeit- als auch auf sicherheitskriti¨ sche Anwendungen und erlauben hohe Ubertragungsraten von 10M Bit/s und mehr. Als erste grobe Unterscheidung l¨asst sich TTP/C als ein Protokoll charakterisieren, das die obigen Ziele konsequent und kompromisslos verfolgt, w¨ ahrend FlexRay mit einer Reihe pragmatischer Erweiterungen auf ein breites Anwendungsspektrum hin entwickelt wurde. Geschichtlich betrachtet geht TTP/C auf das an der Technischen Universit¨ at Wien durchgef¨ uhrte MARS-Projekt (vgl. [74]) zur¨ uck. Mit Hilfe standardisierter Hardware- und Software-Komponenten sollte der Entwickler verteilte Echtzeitsysteme nach einem kanonischen Muster aufbauen k¨ onnen. Das zeitliche Verhalten der Komponenten war ebenso kalkulierbar wie der Grad an Zuverl¨ assigkeit. In der Folge ist daraus die Time Triggered Architecture oder TTA (vgl. [76]) entstanden, in deren Mittelpunkt das TTP/C32 -Protokoll steht. Bei TTA erfolgt sowohl die Prozessausf¨ uhrung auf den Knoten als auch die Versendung von Rahmen zeitgesteuert. Zu diesem Zweck sind explizite Pl¨ ane, gegeliedert nach Zyklen, Runden und Schlitzen, zu erstellen. Diese sind in die Bus-Controller zu laden und dort auszuf¨ uhren (siehe Abb. 2.45). Den Bus-Controllern kommt bei der TTA eine noch sehr viel weitergehende Funktionalit¨ at zu, die im Communication Network Interface oder CNI beschrieben ist. Sie umfasst unter anderem: die Versendung von identischen Rahmen auf redundanten Bussen, die Synchronisierung der Uhrbausteine der Bus-Controller, die Abschirmung des Rechnernetzes vom zeitlichen Verhalten der Knoten (auch als temporal firewall bekannt), einen Busw¨ achter (bus guardian), der das elektrische Zugriffsverhalten des Bus-Controllers pr¨ uft und den Zugriff abschaltet (auch als fail-

2.5.5

30

Time Triggered Protocol, siehe www.ttpforum.org siehe www.flexray.com 32 Daneben gibt es noch das TTP/A-Protkoll f¨ ur Subsysteme. 31

2.5

Verteilte Echtzeitsysteme

149





 








            Abb. 2.45. Jedem Schlitz ist ein Knoten zugeordnet. Umgekehrt d¨ urfen Knoten innerhalb

einer Runde mehrere Schlitze besitzen.

silence bekannt), wenn Unregelm¨ aßigkeiten, insbesondere fortlaufend st¨ orende Signale (auch als babbling idiot bekannt) festgestellt werden. Das FlexRay-Protokoll u ¨bernimmt eine Reihe von Eigenschaften des TTP/C-Protokolls. Neben technischen Gr¨ unden waren auch marktpoli¨ tische Uberlegungen im Spiel, als ein Konsortium aus Automobilherstellern und Zulieferern ab dem Jahr 2000 FlexRay als ein Bussystem f¨ ur die spezifischen Belange der Autoindustrie zu entwickeln begann. Wie aus dem Namen schon hervorgeht, spielt Flexibilit¨at eine maßgebliche Rolle. Sie dr¨ uckt sich wesentlich dadurch aus, dass einzelnen Knoten eine dem aktuellen Bedarf entsprechende Bandbreite zugewiesen werden kann. Beim FlexRay-Protokoll wird zwischen statischen Rahmen (ST-Slot) und dynamischen Rahmen (DYN-Slot) unterschieden (siehe Abb. 2.46). Dabei entsprechen die ST-Slots weitgehend den Schlitzen aus dem TTP/CProtokoll. Alle ST-Slots zusammen bilden das ST-Segment. Ihm folgt das DYN-Segment, in dem Knoten sporadisch anfallende Rahmen priorit¨ atsabh¨ angig als DYN-Slots u ¨bertragen k¨onnen. Dazu besitzt jeder DYN-Slot eine eindeutige Priorit¨ at.

 

  


  

Abb. 2.46. Ein Zyklus bei FlexRay beinhaltet ein ST-Segement und ein DYN-Segment.

Ein Knoten, der ein DYN-Slot senden d¨ urfte, aber gerade keinen Rahmen zu versenden hat, sendet stattdessen einen so genannten Minislot. Dieser ist gerade so groß, dass alle u ¨brigen Knoten erkennen k¨onnen, dass der entsprechende DYN-Slot nicht gesendet wurde. Ein Knoten, der hingegen einen DYN-Slot, beispielsweise der Priorit¨at p, zu versenden hat, wartet damit, bis folgende Forderungen erf¨ ullt sind:

150

2. Methodische und technische Grundlagen

Wurden im aktuellen DYN-Segment bereits alle DYN-Slots der Priorit¨ at h¨ oher als p oder entsprechende Minislots versendet? Bleibt im aktuellen DYN-Segment noch gen¨ ugend Zeit, um den DYNSlot der Priorit¨ at p zu versenden? Werden beide Forderungen erf¨ ullt, so f¨allt der Knoten dezentral die Entscheidung, unverz¨ uglich mit der Versendung des DYN-Slots zu beginnen (siehe Abb. 2.47).  

 

  





  

 





 


     

      
 


 

 Abb. 2.47. Innerhalb eines DYN-Segmentes werden Minislots versendet, wenn der Knoten

keinen Rahmen (Slot) senden m¨ ochte.

Den Anwendungsfeldern, f¨ ur das die beiden Protokolle, TTP/C und FlexRay, zugeschnitten sind, wird in n¨ achster Zeit eine herausragende Bedeutung zufallen. Tendenziell zeichnet sich ab, dass TTP/C im Bereich der Flugzeuge und FlexRay im Bereich der Fahrzeuge bevorzugt eingesetzt werden wird. Erste Bew¨ ahrungsproben in Großserien, f¨ ur TTP/C beispielsweise ab 2005 beim Airbus A380 und f¨ ur FlexRay ab 2006 beim BMW X5, haben beide Busse bereits erfolgreich hinter sich gebracht.


Bei den vorgestellten Zugriffsprotokollen unterscheidet man zwischen zeitgesteuerten33 , bei denen die Verschickung eines Rahmens an einen Zeitpunkt gebunden ist, und den u ¨brigen, die gemeinhin als ereignisgesteuert bezeichnet werden. Zu den zeitgesteuerten geh¨ort unbedingt das ZeitmultiplexVerfahrten (D). Wann welcher Rahmen auf dem Bus verschickt wird, ist deterministisch in einem Plan vorab festzulegen. Auch das Zentralisierte Verfahren (A) und das Markengesteuerte Verfahren (C) lassen sich grunds¨atzlich zeitgesteuert betreiben, was u ¨blicherweise jedoch nicht mit aller Strenge praktiziert wird. Stattdessen gibt es minimale und maximale Zeitspannen bis ein Knoten, einmal aufgefordert durch den Master (A) oder aufgefordert durch den Besitz der Marke (C), einen Rahmen erneut senden darf. 33

Gemeint ist zeitgesteuert im engeren Sinn.

2.5

Verteilte Echtzeitsysteme

151

Ganz anders im ereignisgesteuerten Fall, bei dem die Rahmen anscheinend ohne jegliche Regel allein auf das Eintreten von Ereignissen hin verschickt werden. Der typische Vertreter ist das Arbitrationsverfahren (B). Dennoch ist es bei entprechenden Voraussetzungen im ereignisgesteuerten Fall m¨ oglich, Vorhersagen u ¨ber die minimalen und maximalen Zeitspannen ¨ f¨ ur die Ubertragung von Rahmen zu treffen. Eine ausf¨ uhrliche Absch¨atzung der daf¨ ur notwendigen Zeitspannen erfolgt in Unterabschnitt 4.3.3. 2.5.4 Modellbildung bei verteilten Echtzeitsystemen

Der Anwendungsbereich verteilter Systeme ist weit gef¨achert und uneinheitlich, was den Aufbau von Rechnernetzen, die verwendeten Kommunikationsprotokolle und die Zielsetzung hinsichtlich der Einhaltung von Zeitbedingungen angeht. Eine eindeutige Notation ist deshalb unerl¨asslich. Sie setzt bei den q Rechnernetzen CN = {CN1 , . . . , CNq } an, die das verteilte Echtzeitsystem bilden. Jedes Rechnernetz CNk , mit k ∈ {1, . . . , q}, besteht aus einer Menge von mk Knoten N Dk = {N Dk,1 , . . . , N Dk,mk }. Jeder Knoten N Dk,j , mit j ∈ {1, . . . , mk }, bildet ein Rechensystem mit der Prozessmenge Pk,j = {Pk,j,1 , . . . , Pk,j,nk,j } bestehend aus nk,j Prozessen. Prinzipiell kann jeder Prozess Pk,j,i mit i ∈ {1, . . . , nk,j }, auch Rahmen versenden. Oft ist es jedoch so, dass auf jedem Knoten wenige ausgezeichnete ¨ Prozesse f¨ ur die Ubertragung aller Rahmen zust¨andig sind, beispielsweise ein Sendeprozess und ein Empfangeprozess. Deshalb ist es sinnvoll, die Rahmen den Knoten und nicht den Prozessen zuzuordnen. Aus dieser Zuordnung folgt, dass ein Knoten N Dk,j , mit k ∈ {1, . . . , q} und j ∈ {1, . . . , mk }, die Anzahl von hk,j verschiedenen Rahmen F Rk,j = {F Rk,j,1 , . . . , F Rk,j,hk,j } verschickt. In diesem Zusammenhang spricht man von holistischer Planung, wenn versucht wird, Prozesse und Rahmen weitestgehend gleich zu behandeln. Viele gemeinsame Eigenschaften sprechen f¨ ur diesen Ansatz: Wie Prozesse besitzen auch Rahmen Typ-, Objekt- und Ausf¨ uhrungseigenschaften (siehe auch Seite 44), wobei mit Ausf¨ uhrung die ¨ Ubertragung eines Rahmens gemeint ist. Prozesse und Rahmen ben¨ otigen exklusiven Zugriff auf Betriebsmittel. Bei der Prozessausf¨ uhrung ist das der Prozessor, w¨ahrend es bei der ¨ ¨ Ubertragung eines Rahmens das Ubertragungsmedium ist. ¨ Wie die Prozessausf¨ uhrung ben¨ otigt die Ubertragung eines Rahmens Zeit und unterliegt der Einhaltung von Zeitbedingungen. ¨ Bei all diesen Gemeinsamkeiten ist zu beachten, dass die Ubertragung von Rahmen typischerweise nicht unterbrechbar ist, bei der Prozessausf¨ uhrung

152

2. Methodische und technische Grundlagen

hingegen sowohl die unterbrechbare als auch die nicht unterbrechbare Variante m¨ oglich ist. ¨ Wie eine einzelne Prozessausf¨ uhrung so kann auch eine einzelne Ubertragung eines Rahmens einer Zeitbedingung unterliegen. Kennzeichnend f¨ ur verteilte Anwendungen sind zeitliche Anforderungen hinsichtlich ihrer Ende-zu-EndeAntwortzeit. Diese Anforderungen, die sich zun¨achst global stellen, f¨ uhren zu zeitlichen Anforderungen f¨ ur die ausf¨ uhrenden Prozesse auf den jeweiligen ¨ Knoten und f¨ ur die Ubertragung der Rahmen, die im Zuge der Kommunikation zwischen den Knoten notwendig werden. 2.5.6

Beispiel 2.5.6 Im Beispiel 2.5.1 werden f¨ ur einen Lastwagen mit Anh¨anger alle die notwendigen Arbeitsschritte durchgespielt, die sich im Anschluss an die Bet¨ atigung des Warnblinkschalters ergeben. Daran beteiligt sind Prozesse, die auf verschiedenen Knoten ablaufen. Dazwischen werden immer wieder Rahmen auf den jeweils zugreifbaren Rechnernetzen versendet. F¨ ur die Ende-zuEnde-Antwortzeit auf das Einschalten des Warnblinkschalters hin besteht eine zeitliche Anforderung von 75ms. Diese Zeitbedingung ist von der l¨angsten ¨ Folge (siehe Abb. 2.48) von Prozessausf¨ uhrungen und Ubertragungen von Rahmen zu gew¨ ahrleisten.



  

     
      





    

  
       


  
 

Abb. 2.48. Eine Reihe von Prozessen auf unterschiedlichen Steuerger¨ aten und Rahmen,

die zwischen den Steuerger¨ aten u ¨bertragen werden, bestimmen die Ende-zu-Ende-Antwortzeit.

In den meisten verteilten Echtzeitsystemen werden verschiedene Anwendungen gleichzeitig bearbeitet. Aus diesem Grund ist es nicht sinnvoll, dass einzelne Anwendungsprozesse das Versenden und Empfangen von Rahmen selbst u ¨bernehmen. Stattdessen sollte es eine entprechende Infrastruktur geben, die den Anwendungesprozessen diese Aufgabe abnimmt. Der grundlegende Aufbau einer solchen Infrastruktur basiert darauf, f¨ ur jedes an einen Knoten

2.5

Verteilte Echtzeitsysteme

153

angeschlossene Rechnernetz jeweils einen Sendeprozess und einen Empfangeprozess vorzusehen (siehe Abb. 2.49). Wesentliche Aufgaben des Sendeprozesses sind die folgenden: Anbieten der Dienstleistung der Versendung einer Nachricht, beispielsweise durch Bereitstellen eines Puffers, in den der Anwendungsprozess seine Nachricht schreibt. Abh¨ angig von der Gr¨ oße von Nachrichten und Rahmen: Zerlegung der Nachricht in Rahmen oder Zusammenstellen von Nachrichten zu Rahmen34 . Beauftragung des Bus-Controllers in vorhersagbarer Weise, beispielsweise durch periodisches oder sporadisches Schreiben von Rahmen in den Sendepuffer.

Abb. 2.49. Datenflussdiagramm, das den grundlegenden Aufbau einer Infrastruktur zum

Versenden und Empfangen von Rahmen beschreibt.

In analoger Weise verh¨ alt es sich mit dem Empfangeprozess. Dabei ist durch diesen Aufbau noch nicht vorgegeben, ob die Ausf¨ uhrung der beteiligten Prozesse zeitgesteuert oder ereignisgesteuert erfolgt. Diese Entscheidung hat jedoch großen Einfluss auf die Dauer einer Nachrichten¨ ubertragung zwischen den Anwendungsprozessen auf verschiedenen Knoten des verteilten Echtzeitsystems und wird ausf¨ uhrlich im Abschnitt 4.3 behandelt. 34

Das Problem, aus einem Nachrichtenaufkommen an einem Knoten, so die Rahmen zu packen, dass einerseits m¨ oglichst wenig u ¨bertragen werden muss und an¨ dererseits Zeitbedingungen der Ubertragung nicht verletzt werden, wird als Rahmenpackungsproblem (engl. frame packing problem) bezeichnet (vgl. auch hierzu [98]).

Kapitel 3 Grundlegende Planungsverfahren

3

3

3 3.1 3.1.1 3.1.2 3.2 3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 3.2.6 3.3 3.3.1 3.3.2 3.3.3 3.3.4 3.3.5 3.4 3.4.1 3.4.2 3.4.3 3.5 3.5.1 3.5.2 3.5.3 3.5.4

Grundlegende Planungsverfahren Planen durch Suchen............................................ Planen mittels Tiefensuche .................................... Aufwand des Planens durch Suchen.......................... Planen bei dynamischen Priorit¨aten .......................... Planen nach Fristen ............................................. Planen nach Fristen f¨ ur nicht unterbrechbare Prozesse... Planen nach Fristen f¨ ur unterbrechbare Prozesse.......... Planen nach Fristen f¨ ur periodische unterbrechbare Prozesse ................................................................ Planen nach Spielr¨aumen f¨ ur nicht unterbrechbare Prozesse ................................................................ Planen nach Spielr¨aumen f¨ ur unterbrechbare Prozesse ... Planen bei statischen Priorit¨aten ............................. Planen nach festen Priorit¨aten ................................ Planen nach monotonen Raten................................ Hyperbolische Schranke beim Planen nach monotonen Raten............................................................... Bedarf an Ausf¨ uhrungszeit ..................................... Planen nach monotonen Fristen .............................. Zyklische Planungsverfahren ................................... Struktur der Prozessausf¨ uhrung............................... Freiheitsgrade beim zyklischen Planungsverfahren ........ Bewertung des Ansatzes ........................................ Vergleich der Planungsverfahren .............................. Auslastung ........................................................ Implementierung ................................................. Unterbrechungsbehandlung .................................... Fristverletzung....................................................

157 157 161 164 164 164 166 168 172 175 178 178 180 187 192 195 200 200 202 204 206 206 207 208 210

3 Grundlegende Planungsverfahren Die Planungsverfahren, die in diesem Kapitel behandelt werden, gehen von Prozessen aus, die unabh¨ angig voneinander ausgef¨ uhrt werden. Entscheidende Aussagen und Verfahren, die f¨ ur das Fachgebiet Echtzeitsysteme zentrale Bedeutung haben, werden hier abgeleitet und entwickelt. Dies beginnt mit der Betrachtung zur Komplexit¨ at des Planens (siehe Abschnitt 3.1). Danach werden die beiden zentralen Ans¨ atze der Echtzeitplanung, zum einen das Planen bei dynamischen Priorit¨ aten siehe Abschnitt 3.2) und zum anderen das Planen bei statischen Priorit¨ aten (siehe Abschnitt 3.3 vorgestellt. W¨ahrend diese beiden Planungsverfahren auf ein Betriebssystem oder Laufzeitsystem angewiesen sind, l¨ asst sich das dann folgende zyklische Planungsverfahren (siehe Abschnitt 3.4) unmittelbar in Programme integrieren. Zum Abschluss werden die Planungsverfahren anhand einer Reihe von Kriteren miteinander verglichen (siehe Kapitel 3.5).

3.1

3.1 Planen durch Suchen Vorrangiges Ziel dieses Abschnittes soll es nicht sein, ein effizientes Planungs¨ verfahren zu entwickeln. Vielmehr stehen grunds¨atzliche Uberlegungen zum Aufwand des Planens im Vordergrund. 3.1.1 Planen mittels Tiefensuche

Betrachtet wird der Fall, dass f¨ ur die Menge P von nicht unterbrechbaren Prozessen, mit |P | = n, die zugeh¨ origen Prozessparameter, also Bereit-, Ausf¨ uhrungs- und Abschlusszeiten, gegeben sind. Ein statisches Planungsverfahren soll pr¨ ufen, ob ein brauchbarer Plan existiert und, falls das so ist, einen solchen Plan erzeugen. Als Darstellung eines Planes eignet sich die Folge P L von Tupeln (i, si ), bestehend aus der Angabe des Prozesses i und seiner Startzeit (siehe Abb. 3.1). Durch Tupel (i, si ) ist mit ∆ei auch die Abschlusszeit ci von Prozess i festgelegt.






Abb. 3.1. Bildliche Darstellung des Tupels (2, 4) bei einer Ausf¨ uhrungszeit ∆e2 = 5 f¨ ur

Prozess 2.

Als einfachstes Planungsverfahren ohne Beachtung von Strategien und Heuristiken bietet sich das vollst¨ andige Durchsuchen des L¨osungsraumes an. F¨ ur das erste Planungsverfahren werden Bereitzeiten und Fristen außer Acht ge-

158

3. Grundlegende Planungsverfahren

lassen. Damit ist jede Anordnung nacheinander ausgef¨ uhrter Prozesse ein Plan. Insgesamt gibt es n! verschiedene Pl¨ane, die sich leicht durch rekursive Tiefensuche aufz¨ ahlen lassen. Zusammen mit den Zwischenergebnissen ergibt sich ein vollst¨ andiger Baum der Tiefe n. 3.1.1

Beispiel 3.1.1 Betrachtet wird die Prozessmenge P = {1, 2, 3}, wobei lediglich

die Ausf¨ uhrungszeiten vorgegeben sind (gemessen in Einheiten der Bezugszeitspanne ∆tG ): P 1 2 3

∆e 4 5 3

Bei der Planung ergibt sich ein vollst¨ andiger Baum der Tiefe 3 (siehe Abb. 3.2).




















































































































 




















































 
































































 





Abb. 3.2. Die Bl¨ atter des Baumes repr¨ asentieren alle Reihenfolgen, um drei nicht

unterbrechbare Prozesse auszuf¨ uhren.


Jeder Knoten im Baum markiert einen bestimmten Stand des Planungsverfahrens. Die Wurzel, repr¨ asentiert durch den leeren Plan ∅, steht daf¨ ur, dass noch keiner der n Prozesse in einen Plan aufgenommen wurde. Jeder Knoten im Inneren des Baumes hat eine Tiefe, die von der Wurzel her kommend der Anzahl der Planungsentscheidungen, die bis zu diesem Knoten gefallen sind,

3.1

Planen durch Suchen

159

entspricht. F¨ ur einen solchen Ast von der Wurzel zum Knoten der L¨ange k gilt: Ein Plan P Lk f¨ ur k Prozesse wurde erstellt. In P Lk wurden bereits Xk ⊂ P Prozesse eingeplant. Da zun¨ achst weder Bereitzeiten noch Fristen Ber¨ ucksichtigung finden, wird in einen Plan P Lk mit der Funktion extendPL ein neuer Prozess i aufgenommen, indem die Startzeit si von Prozess i mit der Abschlusszeit des letzten in P Lk aufgenommenen Prozesses gleichgesetzt wird. P Lk+1 ist das Ergebnis von angert P Lk um die Ausf¨ uhrungzeit ∆ei . extendPL (P Lk , i) und verl¨ Verfahren 3.1.1 Planen ohne Ber¨ ucksichtigung von Bereitzeiten und Fristen.

schedule(P Lk , Xk ):: FORALL i ∈ P \Xk DO schedule(extendP L(P Lk , i), Xk ∪ {i})




Setzt man den Aufwand, um einen Prozess in den bestehenden Plan zu integrieren, als konstant an, dann ergibt sich f¨ ur das gesamte Verfahren ein Aufwand von O(n!), was einem exponentiellen Aufwand gleichzusetzen ist1 . Viele der erzeugten Permutationen sind jedoch von vornherein auszuschließen, wenn man Prozesse entsprechend ihrer Bereitzeiten und Fristen in den Plan einordnet. Eine einleuchtende Heuristik lautet, einen Prozess so fr¨ uh wie m¨ oglich einzuplanen. Das bedeutet, dass, angefangen bei der Bereitzeit, die fr¨ uheste L¨ ucke, in die der Prozess mit seiner Ausf¨ uhrungszeit passt, zugeordnet wird. Findet sich keine solche L¨ ucke, dann verletzt der Prozess Pi bei der gegebenen Startzeit seine Frist. Auf der Basis der bisher getroffenen Planungsentscheidungen wird sich kein brauchbarer Plan ergeben. Damit ist eine Fortsetzung der Suche auf diesem Ast des Baumes sinnlos geworden. F¨ ur das zugeh¨ orige Verfahren sind zwei Funktionen n¨otig: Die boolesche Funktion f easible P L(P Lk , i) testet, ob Prozess i brauchbar in den bisherigen Plan P Lk integriert werden kann, d.h., ob u ¨berhaupt noch eine einplanbare L¨ ucke f¨ ur Prozess i existiert. Die Funktion earliest P L(P Lk , i) setzt den Prozess i mit seiner Ausf¨ uhrungszeit in die durch die eigene Bereitzeit und den existierenden uhestm¨ ogliche L¨ ucke und erzeugt somit den Plan Plan P Lk bedingte fr¨ P Lk+1 . 1

Nach der Stirlingschen Formel gilt folgende N¨ aherung: n! ≈

` n ´n √ · 2πn. e

3.1.1

160

3.1.2

3. Grundlegende Planungsverfahren

Verfahren 3.1.2 Unter Ber¨ ucksichtigung der Bereitzeiten und Fristen wird ei-

nem Prozess die fr¨ uheste L¨ ucke zugeordnet. schedule(P Lk , Xk ):: FORALL (i ∈ P \Xk ) AND f easibleP L(P Lk , i) DO schedule(earliest P L(P Lk , i), Xk ∪ {i}) 3.1.2




Beispiel 3.1.2 Betrachtet werden die Prozesse P = {1, 2, 3} mit den Prozess-

parametern: P 1 2 3

r 1 4 0

∆e 4 5 3

d 7 12 14

¨ Auf der Grundlage des Verfahrens 3.1.2 werden die Aste des Baumes nicht mehr weitergef¨ uhrt, wenn sich eine Frist¨ uberschreitung ergeben w¨ urde (siehe Abb. 3.3). 


































































 




























































Abb. 3.3. Der Baum wird nur soweit aufgebaut, wie noch eine M¨ oglichkeit existiert, noch

einen brauchbaren Plan zu finden.

Insgesamt werden zwei brauchbare Pl¨ ane gefunden.




Im Hinblick auf die eingef¨ uhrten G¨ utekriterien f¨ ur Planungsverfahren stellt sich die Frage nach der Optimalit¨ at des Verfahrens 3.1.2. Sicherlich ist der durch den Aufruf schedule(∅, ∅) erzeugte Plan, der alle n Prozesse umfasst, auch brauchbar. Dies garantiert die Funktion f easibleP L(P Lk , i). Dennoch lassen sich brauchbare Pl¨ ane finden, die nicht durch Verfahren 3.1.2 erzeugt werden (siehe Abb. 3.4).

3.1

Planen durch Suchen

161




































Abb. 3.4. Ein brauchbarer Plan, den Verfahren 3.1.2 nicht findet.

Zum Nachweis der Optimalit¨ at ist die Frage zu kl¨aren, ob kein brauchbarer Plan existiert, wenn Verfahren 3.1.2 keinen brauchbaren Plan liefert. Der nachfolgende Satz kl¨ art die aufgeworfene Frage. Satz 3.1.1 Gegeben seien die nicht unterbrechbaren Prozesse P = {1, . . . , n}. Das Verfahren 3.1.2 ist optimal, d.h., wenn es brauchbare Pl¨ane f¨ ur diese Prozesse gibt, dann wird ein solcher durch Verfahren 3.1.2 gefunden. Beweis: Angenommen, es existiert ein brauchbarer Plan P L. Es wird gezeigt,
dass es zu P L einen brauchbaren Plan P L gibt, der mit Verfahren 3.1.2 erzeugt wird. Ohne Beschr¨ ankung der Allgemeinheit sei Π = (1, . . . , n) die
Permutation, die der Reihenfolge der Prozesse in P L entspricht2 . P L1 ist der Plan, der aus P L entsteht, indem die Startzeit s1 von Prozess 1 auf r1

vorgezogen wird. P L1 ist brauchbar. Sei als Induktionsvoraussetzung P Lk ein
brauchbarer Plan f¨ ur die Prozesse {1, . . . , k}. Dann entsteht P Lk+1 , indem die Startzeit sk+1 von Prozess k + 1 auf das Maximum von Bereitzeit rk+1 von Prozess k + 1 und Abschlusszeit ck von Prozess k vorgezogen wird. Das
uhesten Zeitpunkte. Der so sind die f¨ ur einen brauchbaren Plan P Lk+1 fr¨

entstehende Plan P Ln = P L ist identisch mit dem, der bezogen auf die Prozessmenge P durch Verfahren 3.1.2 erzeugt wird.


3.1.1

3.1.2 Aufwand des Planens durch Suchen

Durch die bislang vorgestellten Verfahren beim Planen durch Suchen entsteht der Eindruck, dass es sehr rechenaufw¨ andig ist, einen optimalen Plan zu erzeugen. Dass es sich dabei nicht nur um einen Eindruck handelt, sondern dass das Problem als solches den Aufwand zwingend nach sich zieht, soll im Folgenden nachgewiesen werden. Dazu wird gezeigt, dass die Einplanung nicht unterbrechbarer Prozesse NP-vollst¨ andig ist. Und das bedeutet soviel, dass die praktischen Planungsverfahren in Abh¨ angigkeit von der Anzahl n der Prozesse einen exponentiellen Aufwand, d.h. einen Aufwand von der Ordnung O(2n ), haben. Satz 3.1.2 Gegeben seien die nicht unterbrechbaren Prozesse P = {1, . . . , n}. Die Entscheidungsfrage lautet, ob es einen Plan von Tupeln (i, si ) gibt, so uhrungszeiten ∆ei , mit 1 ≤ i ≤ n, dass f¨ ur Bereitzeiten ri , Fristen di und Ausf¨ ein brauchbarer Plan existiert: 2

Dies ist durch Umnummerierung der Prozessindizes zu erreichen.

3.1.2

162

(a) (b) (c) (d)

3. Grundlegende Planungsverfahren

(i, si ) ∈ P L si ≥ ri si + ∆ei ≤ di i = j ⇒ entweder si + ∆ei ≤ sj oder sj + ∆ej ≤ si

Dieses Problem wird in der Komplexit¨atstheorie als SEQUENZIERUNG VON INTERVALLEN bezeichnet (vgl. [48]) und ist NP-vollst¨andig. Beweis: Wie beim Nachweis der NP-Vollst¨ andigkeit u ¨blich, werden zwei Eigenschaften gezeigt: 1. Das Problem liegt in NP. 2. Es gibt eine polynomielle Transformation auf ein Referenzproblem, das bekanntermaßen NP-vollst¨ andig ist. Diese Transformation heißt Reduktion. Bei ihr wird gezeigt, dass eine L¨osung des Problems der SEQUENZIERUNG VON INTERVALLEN das bekanntermaßen NP-vollst¨andige 3-PARTITION-Problem l¨ ost. Eigenschaft (1.) ist leicht einzusehen, denn es gen¨ ugt, dass von jeder geratenen L¨ osung des Problems der SEQUENZIERUNG VON INTERVALLEN uft werden kann, ob ein brauchbarer Plan mit polynomiellem Aufwand3 gepr¨ vorliegt. Zum Nachweis von Eigenschaft (2.) ist zun¨achst das 3-PARTITION-Problem zu erl¨ autern. Eine Instanz des 3-PARTITION-Problems besteht aus einer 3melementigen Menge A = {1, . . . , 3m}, mit m ∈ N, einer Schranke b ∈ N und einer Funktion g : A → N, die allen Elementen von A einen Wert zuordnet. Weiterhin sei f¨ ur ein i ∈ A: 1. b/4 < g(i) < b/2  2. i∈A g(i) = mb Das Entscheidungsproblem lautet: Kann man A so in disjunkte dreielemenur alle 1 ≤ j ≤ m gilt: tige Teilmengen G1 , . . . , Gm zerlegen, dass f¨ g(i) = b i∈Gj

Das 3-PARTITION-Problem ist f¨ ur die Reduktion als Problem der SEQUENZIERUNG VON INTERVALLEN zu formulieren, wobei jedem Element aus A ein Prozess aus P zugeordnet wird. Zus¨atzlich enth¨alt P noch die Prozessmenge M = {3m + j | 1 ≤ j ≤ m − 1}, die f¨ ur die Partitionierung von A ben¨ otigt wird: P = A ∪ M Die nachfolgende Konstruktion erzeugt aus einem 3-PARTITION-Problem die Prozessparameter (Bereitzeiten, Fristen und Ausf¨ uhrungszeiten) f¨ ur ein 3

O(nc ) mit n Anzahl der Prozesse und c konstant

3.1

Planen durch Suchen

163

Problem der SEQUENZIERUNG VON INTERVALLEN:  1 , f¨ ur i = 3m + j ∈ M ∆ei = g(i) , f¨ ur i ∈ A  jb + j − 1 , f¨ ur i = 3m + j ∈ M ri = 0 , f¨ ur i ∈ A  jb + j , f¨ ur i = 3m + j ∈ M di = mb + m − 1 , f¨ ur i ∈ A Die Konstruktion eines Problems der SEQUENZIERUNG VON INTERVALLEN erfordert lediglich polynomiellen Aufwand. Es bleibt zu zeigen, dass jeder einzelne f¨ ur P brauchbare Plan einer L¨osung des 3-PARTITION-Problems entspricht. Dazu wird ein beliebiger Ausschnitt des brauchbaren Planes betrachtet:


 

 














Ein brauchbarer Plan f¨ ur P muss die Summe der Ausf¨ uhrungszeiten in das Zeitintervall [0, mb + m − 1] einplanen. Diese Summe berechnet sich so: ∆ei + ∆ei = mb + m − 1 i∈A

i∈M

Somit hat ein brauchbarer Plan keine L¨ ucken. F¨ ur ein Intervall [jb + j, (j + 1)b + j], 0 ≤ j ≤ m − 1 folgt, dass die Prozessmenge Pj+1 ⊂ A, bestehend aus drei Prozessen, das ganze Intervall ausf¨ ullt. Ebenso sind die Prozesse j ∈ M und j + 1 ∈ M brauchbar eingeplant. Setzt man Gj+1 = Pj+1 , dann  ullt die Anforderungen des 3-PARTITIONgilt: i∈Gj+1 g(i) = b. Dies erf¨ Problems.  Umgekehrt entspricht die Menge Gj+1 mit i∈Gj+1 g(i) = b einer Prozessullt. Auf menge Pj+1 , die das Intervall [jb + j, (j + 1)b + j] brauchbar ausf¨ diese Weise l¨ asst sich aus einer L¨ osung des 3-PARTITION-Problems wieder ein brauchbarer Plan konstruieren.


164

3.2

3. Grundlegende Planungsverfahren

3.2 Planen bei dynamischen Priorit¨ aten Die Planungsverfahren, die in diesem Abschnitt behandelt werden, lassen zu, dass ein Prozessobjekt i einmal von einem Prozessojekt j verdr¨angt wird und ein andermal umgekehrt. Betrachtet man dies vor dem Hintergrund priorit¨ atbasierter Prozessausf¨ uhrung, so kann dieses Verhalten nur erreicht werden, wenn den Prozessen zur Laufzeit, d.h. dynamisch, eine Priorit¨at zugeordnet werden. Zwei herausragende Verfahren werden im Weiteren vorgestellt, zum einen das Planen nach Fristen (siehe Unterabschnitte 3.2.1 bis 3.2.4), zum anderen das Planen nach Spielr¨ aumen (siehe Unterabschnitte 3.2.5 und 3.2.6). 3.2.1 Planen nach Fristen

Das Planen nach Fristen (earliest deadline first oder EDF) ist eine der verbreitetsten Planungsstrategien. Das r¨ uhrt weniger aus der im Einzelfall erreichten G¨ ute eines Planes her, als vielmehr aus der Breite der Einsetzbarkeit der Strategie. Planen nach Fristen l¨ asst sich anwenden auf unterbrechbare und nicht unterbrechbare Prozesse und in statischen und dynamischen Planungsverfahren. Die Planungsstrategie besagt: Teile den Prozessor jeweils demjenigen rechenbereiten Prozess i zu, dessen Frist di den kleinsten Wert hat. Wenn es keinen rechenbereiten Prozess gibt, dann bleibt der Prozessor unt¨atig (engl. idle). Die Strategie l¨ asst sich bei unterbrechbaren Prozessen jederzeit, d.h. entsprechend der Granularit¨ at ∆tG , anwenden. Bei nicht unterbrechbaren Prozessen ist jeweils der Abschluss einer Prozessausf¨ uhrung abzuwarten. 3.2.2 Planen nach Fristen f¨ ur nicht unterbrechbare Prozesse

Ein bekanntes Verfahren zum Planen nach Fristen ordnet zun¨achst die Prozesse nach aufsteigenden Fristen, um sie dann einen nach dem anderen so fr¨ uh wie m¨ oglich einzuplanen. Dazu wird wiederum die Funktion earliest P L(P Lk , i) (siehe Seite 159) benutzt. 3.2.1

Verfahren 3.2.1 Die Prozesse P = {1, . . . , n} seien bereits ihren Fristen nach

geordnet: 1 ≤ i ≤ j ≤ n ⇒ di ≤ dj : schedule(P L, P ):: P L = <>; i = 1; WHILE (i ≤ n) AND f easible P L(P L, i) DO BEGIN P L = earliest P L(P L, i);

3.2

Planen bei dynamischen Priorit¨ aten

165

i = i+1; END




Offensichtlich ist jeder Plan, den Verfahren 3.2.1 erzeugt, brauchbar. Einschließlich der Sortierung der Prozesse bez¨ uglich ihrer Frist entsteht ein Aufwand von O(n log n). Damit arbeitet es deutlich effizienter als Verfahren 3.1.2. Nach Satz 3.1.2 ist das Problem jedoch NP-vollst¨andig, was bedeutet, dass es Prozessmengen mit Prozessparametern geben muss, die von Verfahren 3.2.1 nicht brauchbar verplant werden, obwohl es einen brauchbaren Plan gibt. Aufgabe 3.2.1 (siehe Seite 281) Finden Sie eine zweielementige Prozessmenge,

3.2.1

die brauchbar verplant werden kann, z.B. mit Verfahren 3.1.2, w¨ahrend die Anwendung von Verfahren 3.2.1 zu einer Fristverletzung f¨ uhrt.
Optimal ist Verfahren 3.2.1 f¨ ur Prozesse mit gleichen Bereitzeiten (siehe hierzu Aufgabe 3.2.2). Dies l¨ asst sich an dem folgenden Beispiel veranschaulichen. Beispiel 3.2.1 Planung nach Fristen f¨ ur vier nicht unterbrechbare Prozesse mit folgenden Prozessparametern:

P 1 2 3 4

r 0 0 0 0

∆e 4 1 2 5

3.2.1

d 5 7 7 13

Wenn mehrere Prozesse gleiche Fristen besitzen, ist es gleichg¨ ultig, in welcher Reihenfolge diese Prozesse in den Plan aufgenommen werden. Erzeugt wird hier beispielsweise der Plan: 





































Aufgabe 3.2.2 (siehe Seite 282)

Sei P = {1, . . . , n} eine Menge nicht unterbrechbarer Prozesse, deren Fristen so geordnet sind: 1 ≤ i ≤ j ≤ n ⇒ di ≤ dj . Außerdem seien die Bereitzeiten aller Prozesse gleich. Zeigen Sie, dass Verfahren 3.2.1 angewandt auf solche Prozessmengen optimal ist.


3.2.2

166

3. Grundlegende Planungsverfahren

3.2.3 Planen nach Fristen f¨ ur unterbrechbare Prozesse

Die Planung nach Fristen l¨ asst sich auf unterbrechbare Prozesse ausdehnen. F¨ ur einen Plan P L ist die Darstellung als Folge von Tupeln der Form uhrungszeit eines Prozesses i ist im Plan P L (i, ui,j , ∆ui,j ) geeignet. Die Ausf¨ in mi Zeitintervalle zerlegt. Ein Intervall beginnt bei ui,j und dauert ∆ui,j Zeiteinheiten. F¨ ur einen brauchbaren Plan gelten folgende Randbedingungen: mi

∆ui,j = ∆ei

j=1

und ri ≤ si = ui,1 ≤ ui,mi + ∆ui,mi = ci ≤ di Die Strategie der Planung nach Fristen kann zu einem Zeitpunkt t nur auf diejenigen Prozesse angewendet werden, die rechenbereit sind, d.h. wenn t zwischen Bereitzeit und Frist liegt, und der Prozess noch nicht vollst¨andig ausgef¨ uhrt ist: Ready(t) = {i | ri ≤ t < di ∧ rest(i, t) > 0} Dabei umfasst rest(i, t) alle Ausf¨ uhrungszeiten von Prozess i, die in den bis zum Zeitpunkt t ausgebauten Plan P L noch nicht aufgenommen wurden: ⎧ 0 , ui,mi + ∆ui,mi ≤ t ⎪ ⎪ k ⎪ ⎪ ⎪ , ui,k + ∆ui,k ≤ t < ui,k+1 ∆ei − j=1 ∆ui,j ⎪ ⎪ ⎨ und k ∈ {1, . . . , mi − 1} k rest(i, t) = ⎪ ∆ei − j=1 ∆ui,j − t + ui,k+1 , ui,k+1 ≤ t < ui,k+1 + ∆ui,k+1 ⎪ ⎪ ⎪ ⎪ und k ∈ {1, . . . , mi − 1} ⎪ ⎪ ⎩ , t < ui,1 ∆ei Zum Zeitpunkt t soll derjenige Prozess aus Ready(t) rechnen, dessen Frist die k¨ urzeste ist (engl. earliest deadline first). Mit der Funktion edf (Ready(t)) wird ein solcher Prozess bestimmt. Es bleibt zu kl¨aren, welches Zeitintervall dem Prozess ab t zugeordnet werden kann. Zum einen kann es nicht mehr sein, als er noch Ausf¨ uhrungszeit hat: rest(i, t). Zum anderen kann es vom Zeitpunkt t aus gesehen einen n¨ achsten Zeitpunkt geben, zu dem weitere, bislang unber¨ ucksichtigte Prozesse bereit werden und mit ihren jeweiligen Fristen betrachtet werden m¨ ussen. Der n¨achste planungsrelevante Zeitpunkt berechnet sich so:   ,j∈P rj | rj > t nextdispatch(t) = min t + rest(i, t) , i rechnender Prozess

3.2

Planen bei dynamischen Priorit¨ aten

167

Das Planungsverfahren endet, wenn zu einem Zeitpunkt t die Ausf¨ uhrungszeiten aller Prozesse in den Plan P L aufgenommen werden oder eine Fristverletzung stattgefunden hat. Zu diesem Zweck liefert die boolesche Funktion allinP L(t) genau dann den Wert wahr, wenn gilt: rest(i, t) = 0 i∈P

Verfahren 3.2.2 Planen

nach Fristen bei unterbrechbaren schedule(P L, P ):: P L =<>; t = min{ri | ri ∈ P }; WHILE ¬allinP L(t) DO IF Ready(t) = ∅ THEN t = nextdispatch(t); ELSE BEGIN i = edf (Ready(t)); IF t + rest(i, t) > di THEN BREAK; ∆u = nextdispatch(t) − t; P L = P L∧ (i, t, ∆u); t = t + ∆u; END

Prozessen

3.2.2


Satz 3.2.1 Das Verfahren 3.2.2 ist optimal f¨ ur die Menge P = {1, . . . , n} unterbrechbarer Prozesse. Beweis: Sei P L ein beliebig erzeugter brauchbarer Plan. Sei weiterhin P Lt0 , ur die Konmit t0 = min{ri | i ∈ P } identisch mit P L und Ausgangspunkt f¨  struktion. Unter der Induktionsvoraussetzung, dass P Lt , t ≤ t0 , ein bis zum Zeitpunkt t brauchbarer Plan ist, der von Verfahren 3.2.2 erzeugbar ist, wird im Induktionsschritt P Lt+1 konstruiert. Dazu wird in P Lt nach einem Proange der Bezugszeitspanne ∆tG zess i und einem Intervall Gt+k von der L¨ gesucht, das die folgenden Eigenschaften erf¨ ullt: In P Lt kleinstes k > 0 mit s(t + k) = i. F¨ ur Prozess i gilt ri ≤ t und rest(i, t) > 0. Es gilt di ≤ dj f¨ ur alle j ∈ P , die ebenfalls die obigen Bedingungen erf¨ ullen.

3.2.1

168

3. Grundlegende Planungsverfahren

Der ausgew¨ ahlte Prozess i wird auch in Verfahren 3.2.2 von der Funktion edf (Ready(t)) ausgew¨ ahlt. Der Plan P Lt+1 wird aus P Lt durch Vertauschung der Prozesse j und i in den Intervallen Gt und Gt+k erzeugt (siehe Abb. 3.5).

Abb. 3.5. Vertauschung der Prozesse in den Intervallen Gt und Gt+k .

Offensichtlich entspricht P Lt+1 bis zum Zeitpunkt t + 1 einem von Verfahren 3.2.2 erzeugbaren Plan. So bleibt noch zu zeigen, dass P Lt+1 bis zu diesem Zeitpunkt brauchbar ist. Dies ist insbesondere f¨ ur Prozess j im Intervall Gt +k nachzuweisen. Aus dem alten Plan folgen bereits die Beziehungen rj ≤ t und t + k + 1 ≤ di . Mit di ≤ dj folgt unmittelbar, dass j auch in P Lt+1 eingeplant ist. Die schrittweise Anwendung der Vertauschung der Intervalle f¨ uhrt schließlich  ur alle Prozesse zu einem von Verfahren 3.2.2 erzeugbaren Plan P Lt , bei dem f¨ j ∈ P gilt rest(j, t) = 0.
3.2.3

Aufgabe 3.2.3 Gegeben sei die Menge P = {1, . . . , 4} sporadischer unter-

brechbarer Prozesse mit folgenden Prozessparametern: P 1 2 3

r 0 1 7

∆e 2 4 2

d 5 11 10

Der folgende brauchbare Plan ist nach Konstruktion aus dem Beweis von Satz 3.2.1 umzuformen in einen Plan, der mit Verfahren 3.2.2 erzeugt werden kann.



  




















 

 




















3.2.4 Planen nach Fristen f¨ ur periodische unterbrechbare Prozesse

Der Nachweis der Existenz eines brauchbaren Planes wird f¨ ur periodische unterbrechbare Prozesse sehr einfach. Denn die Pr¨ ufung, ob f¨ ur die Auslas-

3.2

Planen bei dynamischen Priorit¨ aten

169

tung gilt U ≤ 1, ist ein notwendiges und hinreichendes Kriterium f¨ ur die Brauchbarkeit eines Planes. Dieser Nachweis stammt von Liu und Layland (vgl. [91]) und geh¨ ort zu den grundlegenden Ergebnissen der Echtzeitplanung. Zum Beweis der Aussage ist vorweg Folgendes zu zeigen: Satz 3.2.2 Gegeben seien die periodischen unterbrechbaren Prozesse P =

{1, . . . , n}. Kommt es bei diesen Prozessen beim Planen nach Fristen zu einer Frist¨ uberschreitung, dann kann davor keine zeitliche L¨ ucke existieren, zu der der Prozessor nicht zugeteilt ist. Beweis: Sei t0 = 0 der Zeitpunkt, zu dem die Perioden aller Prozesse beginnen. Folgende Annahme wird zum Widerspruch gef¨ uhrt: Die erste Frist¨ uberucke, schreitung ergibt sich zum Zeitpunkt t3 , und davor liegt eine Planungsl¨ die dem Zeitintervall [t1 , t2 ] entspricht (siehe Abb. 3.6). 






































Abb. 3.6. Die Zeitpunkte t0 , t1 , t2 und t3 , bezogen auf den Plan f¨ ur Prozess i.

Zun¨ achst einmal ist festzustellen, dass zwischen t1 und t2 keine Bereitzeit irgendeines Prozesses liegen kann, da das Planen nach Fristen ab diesem Zeitpunkt den Prozessor zuteilen w¨ urde. Bezogen auf einen Prozess i gilt f¨ ur seine k-te Bereitzeit: rik−1 ≤ t1 < t2 ≤ rik Es wird nun derjenige Plan betrachtet, der sich ergeben w¨ urde, wenn die k-te Bereitzeit von Prozess i bereits bei t2 beginnt. Damit verschieben sich alle Fristen von Prozess i um rik − t2 nach vorne. Gleichzeitig bleibt die gesamte Ausf¨ uhrungszeit aller Prozesse l¨ uckenlos erhalten, und es kommt uher. Schritt f¨ ur Schritt kann so zu einer Frist¨ uberschreitung bei t3 oder fr¨ ucken, womit die Situation jeder Prozess mit seiner Bereitzeit auf t2 vorr¨ mit der zum Zeitpunkt t0 u ¨bereinstimmt. Die Annahme, dass nach t0 ohne vorherige Frist¨ uberschreitung eine Planungsl¨ ucke m¨oglich ist, wird durch den
l¨ uckenlosen Plan ab t2 widerlegt. Aus dem obigen Beweis ist ersichtlich, dass die Erstellung eines brauchbaren Planes dann am schwierigsten wird, wenn alle Bereitzeiten zusammenfallen. Der fr¨ uheste Zeitpunkt einer Frist¨ uberschreitung wird sich im Anschluss an diese gemeinsame Bereitzeit ergeben.

3.2.2

170

3.2.3

3. Grundlegende Planungsverfahren

Satz 3.2.3 Periodische Prozesse werden beim Planen nach Fristen brauchbar eingeplant, wenn gilt:

U ≤1 Beweis: Es wird gezeigt, dass aus einer Frist¨ uberschreitung beim Planen nach Fristen folgt:

U >1 uberschreitung bzw. ∆t02 das ZeitinterSei t2 der Zeitpunkt der ersten Frist¨ vall vom Beginn der Planerstellung t0 bis zu ihrem Ende t2 . Die Menge der Prozesse wird partitioniert in die Menge PA derjenigen Prozesse, die eine Frist allt, und der Menge PB der u besitzen, die mit t2 zusammenf¨ ¨brigen Prozesse. Eine Frist¨ uberschreitung kann nur von einem Prozess aus PA verursacht werden. Damit ist PA nicht leer. 







 



























Abb. 3.7. Ausf¨ uhrungszeiten zum Fall 1.

Bezogen auf ein Zeitintervall, z.B. ∆t02 , wird der Bedarf eines Prozesses an Ausf¨ uhrungszeit durch die Anzahl der Perioden bestimmt, die in diesem Intervall liegen: F¨ ur i ∈ PA liegen zwischen t0 und t2 genau ∆t02 /∆pi Perioden, was f¨ ur ur Prozess i einen brauchbaren Plan einem Bedarf von (∆t02 /∆pi )∆ei f¨ entspricht. F¨ ur i ∈ PB liegt t2 zwischen zwei Fristen: dki < t2 < dk+1 i Deshalb sind bis zum Zeitpunkt t2 bereits ∆t02 /∆pi  Perioden brauchbar einzuplanen, was einem Bedarf von ∆t02 /∆pi ∆ei entspricht. ur die gilt: F¨ ur alle Prozesse i ∈ P seien lri die letzten Bereitzeiten, f¨ lri < t2 Mit Blick auf die Prozesse in PB werden zwei F¨alle unterschieden: 1. Beim Planen nach Fristen erh¨ alt kein Prozess i ∈ PB nach dem Zeitpunkt uhrungszeit zugeteilt. Der Bedarf an Ausf¨ uhrungszeit f¨ ur das lri noch Ausf¨

3.2

Planen bei dynamischen Priorit¨ aten

171

Intervall ∆t02 ist gegeben als:

∆t02  ∆t02  ∆ei ∆ei + ∆pi ∆pi

i∈PA

i∈PB

Da nach Satz 3.2.2 vor Frist¨ uberschreitungen keine L¨ ucken existieren, ist es allein dieser Bedarf, der die Frist¨ uberschreitung verursacht ∆t02  ∆t02  ∆ei > ∆t02 ∆ei + ∆pi ∆pi i∈PA

i∈PB

und es kann gefolgert werden: ∆ei >1 ∆pi i∈P

2. Es gibt noch Prozesse i ∈ PB , denen nach lri noch Ausf¨ uhrungszeit zugeordnet wird. Sei t1 mit t1 ≤ t2 der Zeitpunkt, ab dem das nicht mehr geuhrungszeit, die einem Prozess i ∈ PB schieht. Bei t1 endet die letzte Ausf¨ nach seiner letzten Bereitzeit lri , aber vor t2 zugeordnet wird (siehe Abb. 3.8). Der Bedarf an Ausf¨ uhrungszeit f¨ ur einen Prozess j ∈ PB im Intervall ankt durch: ∆t12 /∆pj ∆ej . ∆t12 ist nach oben hin beschr¨ t1

t2 't12

lri

'p j

'p j

lrj Abb. 3.8. Ausf¨ uhrungszeiten zum Fall 2.

Aus der Wahl von t1 folgt f¨ ur alle Prozesse, die eine Periode besitzen, die vor t1 beginnt und zwischen t1 und t2 bzw. bei t2 endet, dass die gesamte Ausf¨ uhrungszeit ∆ei bereits bis t1 aufgenommen wurde. Dementsprechend wird keinem Prozess j ∈ PB von lrj bis t2 Ausfuhrungszeit zugeordnet. Der gesamte Bedarf an Ausf¨ uhrungszeit im Intervall ∆t12 ist kleiner oder gleich:  ∆t12  ∆ei ∆pi i∈P

Dieser Bedarf geht allein von Prozessen aus, deren Periode nicht gr¨oßer als uckenlos eingeplant, so ∆t12 ist. Das Intervall ∆t12 wird nach Satz 3.2.2 l¨

172

3. Grundlegende Planungsverfahren

dass die Frist¨ uberschreitung nur durch obigen Bedarf erzeugt wird, d. h.:  ∆t12  ∆ei > ∆t12 ∆pi i∈P

und daraus folgt im Widerspruch zur Annahme: ∆ei >1 ∆pi i∈P


Die unmittelbare Schlussfolgerung aus dem vorangegangen Satz 3.2.3 ist, dass EDF f¨ ur periodische unterbrechbare Prozesse ein optimales Planungsverfahren darstellt. 3.2.4

Aufgabe 3.2.4 Zu einer Menge von periodischen Prozessen P = {1, 2, . . . , n}

ur 1 ≤ i ≤ n soll der zugeh¨orige mit identischen ersten Bereitzeiten ri1 = 0 f¨ Plan nach Fristen explizit erstellt werden. Bis zu welchem Zeitpunkt wird dabei sp¨ atestens die erste Frist¨ uberschreitung auftreten, falls u ¨berhaupt eine vorkommt?
3.2.5 Planen nach Spielr¨ aumen f¨ ur nicht unterbrechbare Prozesse

Als Spielraum(engl. laxity) wird die Zeitspanne bezeichnet, die ein Prozess innerhalb des Zeitintervalls aus Bereitzeit und Frist abz¨ uglich seiner Ausf¨ uhrungszeit ungenutzt l¨ asst: ∆li = di − ri − ∆ei Entsprechend spricht man vom Planen nach Spielr¨aumen (engl. least laxity first oder LLF). Betrachtet man nicht unterbrechbare Prozesse, dann kann man diese gem¨ aß ihren Spielr¨ aumen anordnen. 3.2.2

Beispiel 3.2.2 Gegeben sei die Prozessmenge P = {1, . . . , 4} mit ihren Prozessparametern, wobei bereits eine Anordnung der Prozesse ihren Spielr¨ aumen entsprechend getroffen ist:

P 1 2 3 4

r 0 0 0 0

∆e 1 7 2 4

d 6 13 9 14

∆l 5 6 7 8


3.2

Planen bei dynamischen Priorit¨ aten

173

In Analogie zu Verfahren 3.2.1 kann man ein leicht modifiziertes Verfahren entwickeln, das die Prozesse anstatt nach aufsteigenden Fristen nach aufsteigenden Spielr¨ aumen vergibt. Wegen Satz 3.1.2 ist ein solches Verfahren nicht optimal. Dennoch l¨ asst sich in Analogie zu Satz 3.1.1 die Frage stellen, ob eine Anordnung der Prozesse nach aufsteigenden Spielr¨aumen wenigstens f¨ ur die eingeschr¨ ankte Prozessmenge mit gleichen Bereitzeiten optimal ist. Jedoch ist nicht einmal dies der Fall, wie das nachfolgende Beispiel belegt. Beispiel 3.2.3 Die Prozessmenge aus Beispiel 3.2.2 f¨ uhrt zu einer Fristverlet-

3.2.3

zung, wenn die Prozesse entsprechend ihrer Spielr¨aume anordnet werden:    































Vergibt man jedoch wie in Verfahren 3.2.1 den Prozessor nach aufsteigenden Fristen, dann ergibt sich f¨ ur dieselbe Prozessmenge ein brauchbarer Plan: 






























Damit steht fest, dass Spielr¨ aume bei nicht unterbrechbaren Prozessen ein schw¨ acheres Planungskriterium darstellen als Fristen. Dennoch ist die Betrachtung von Zeitspannen, die nicht oder noch nicht f¨ ur die Ausf¨ uhrung eines Prozesses vergeben wurden, durchaus lohnend. Verfolgt man die Erstellung eines Planes, z.B. f¨ ur nicht unterbrechbare Prozesse mit gleichen Bereitzeiten nach Verfahren 3.2.1, dann l¨asst sich ein Spielraum auch darin erkennen, inwieweit f¨ ur einen Prozess i die verbleibende Zeitspanne ∆li = di − ci vom Abschluss der Ausf¨ uhrung bis zur Frist ungenutzt bleibt. Satz 3.2.4 Sei P = {1, . . . , n} eine Menge nicht unterbrechbarer Prozesse mit

gleichen Bereitzeiten. Geordnet seien die Prozesse nach aufsteigenden Fristen. Verfahren 3.2.1 angewandt auf P f¨ uhrt zum gr¨oßtm¨oglichen minimalen

3.2.4

174

3. Grundlegende Planungsverfahren

Spielraum. Das bedeutet, dass min{di − ci | i ∈ P } nach Verfahren 3.2.1 mindestens so groß ist wie der minimale Spielraum bei jedem anderen Verfahren.4 Beweis: Sei P L ein Plan, der nicht mit Verfahren 3.2.1 erzeugt wurde, und ∆lP L der minimale Spielraum. Ist dieser Plan anders als ein mit Verfahren 3.2.1 erzeugbarer Plan, dann gibt es mindestens eine Fehlstelle in P L, wo ein Prozess j gegebenenfalls gefolgt von einer L¨ ucke vor einem Prozess i angeordnet ist, und es gilt: cj ≤ ri ≤ ci

und di < dj

Bezogen auf die Prozesse i und j ist der minimale Spielraum: ∆l{i,j} = di − ci Aus P L wird ein Plan P L erzeugt, indem die Startzeit von Prozess i auf die von Prozess j vorgezogen wird und Prozess j so weit nach hinten verschoben wird, bis er ohne L¨ ucke an Prozess i anschließt (siehe Abb. 3.9). 






 










Abb. 3.9. Vorziehen des Prozesses i und Verschieben von Prozess j und einer

gegebenenfalls vorhandenen L¨ ucke nach hinten.

Der neue minimale Spielraum ist: ∆l{i,j} = min{di − ci , dj − cj }  = dj − cj . Es ist cj ≤ ci und dj ≥ di , (a) Aus di − ci ≥ dj − cj folgt ∆l{i,j}  woraus wiederum folgt ∆l{i,j} ≥ ∆l{i,j} .  = di − ci . Wegen ci ≤ ci folgt (b) Aus di − ci ≤ dj − cj folgt ∆l{i,j}  unmittelbar ∆l{i,j} ≥ ∆l{i,j} .

Damit wird der Spielraum von P L zu P L gr¨oßer oder er bleibt gleich. Den gr¨ oßtm¨ oglichen Spielraum erzielt man, wenn alle Fehlstellen eliminiert sind, was der Anwendung von Verfahren 3.2.1 auf P entspricht.
4

In einer einfacheren Form ist dieser Satz auch als Satz von Jackson [67] in der Fachliteratur bekannt geworden.

3.2

Planen bei dynamischen Priorit¨ aten

175

Jedes Mal, wenn ein Plan P L mit min{di − ci | i ∈ P } ≥ 0 erzeugt wird, findet keine Fristverletzung statt und der Plan ist brauchbar. Dar¨ uber hinaus gibt der Wert min{di − ci | i ∈ P } an, um wie viele Zeiteinheiten die Fristen schrumpfen oder die Ausf¨ uhrungszeiten wachsen k¨onnen, ohne dass die Brauchbarkeit eines Planes verloren geht. 3.2.6 Planen nach Spielr¨ aumen f¨ ur unterbrechbare Prozesse

Bei unterbrechbaren Prozessen sind die Spielr¨aume abh¨angig von der Ausf¨ uhrungszeit der Prozesse. Zum Zeitpunkt t engt der verbleibende Rest rest(i, t) (siehe Seite 166) an Ausf¨ uhrungszeit den Spielraum ein: ∆li = di − t − rest(i, t) Unter den zum Zeitpunkt t rechenbereiten Prozessen Ready(t) wird mit der Funktion llf (Ready(t)) einer bestimmt werden, dessen Spielraum gerade minimal ist. Spielr¨aume a uhrungszeit von Prozessen. F¨ ur ¨ndern sich zur Ausf¨ unterbrechbare Prozesse ist somit die Dynamik bei LLF eine weitergehende als die bei EDF. Beispiel 3.2.4 Gegeben sei die Prozessmenge P = {1, 2} unterbrechbarer Prozesse mit den Prozessparametern:

P 1 2

r 0 0

∆e 5 3

d 9 8

Das Planen nach Spielr¨ aumen erfordert eine st¨andige Suche nach dem Prozess, der in der n¨ achsten Bezugszeitspanne ∆tG den Prozessor erhalten soll. Zum Zeitpunkt 0 berechnen sich folgende Spielr¨aume: ∆l1 (0) = 9 − 0 − 5 = 4 ∆l2 (0) = 8 − 0 − 3 = 5 Damit hat Prozess 1 den niedrigsten Spielraum und wird ausgef¨ uhrt. Bis zum Zeitpunkt 1 ¨ andert sich nur der Spielraum des Prozesses 2: ∆l2 (1) = 8 − 1 − 3 = 4 Damit besitzen beide Prozesse den gleichen Spielraum. Willk¨ urlich bleibt die Wahl bei Prozess 1, Solange Prozess 1 ausgef¨ uhrt wird, ¨andert sich sein Spielraum nicht: ∆l1 (0) = ∆l1 (1) = ∆l1 (2)

3.2.4

176

3. Grundlegende Planungsverfahren

Anders ist das f¨ ur Prozess 2, dessen Spielraum sich bis zu Zeitpunkt 2 weiter eingeengt hat: ∆l2 (2) = 8 − 2 − 3 = 3 Nun hat Prozess 2 den niedrigsten Spielraum und erh¨alt den Prozessor. Insgesamt ergibt sich beispielsweise folgender Plan: d 2 d1 0

1

2

3

4

5

6

7

1 1 2 2 1 1 2 1

Es wird erkennbar, dass es sp¨ atestens nach 2 ∆tG zu einer Prozessumschaltung kommt. Dies geschieht ab dem Zeitpunkt, zu dem mehrere Prozesse den gleichen Spielraum besitzen. Ein solcher Zeitpunkt wird auch laxity tie (vgl. [111]) genannt. Solche h¨ aufigen Prozessumschaltungen sind weder effizient noch n¨otig. Denn f¨ ur Prozesse mit gleichen Spielr¨ aumen macht es keinen Unterschied, ob man die Rechenzeit blockweise einzelnen Prozessen zuordnet oder in Einheiten der Bezugszeitspanne ∆tG . Dabei ist jedoch darauf zu achten, dass von den Prozessen mit gleichen Spielr¨ aumen jeweils der Prozess mit der k¨ urzesten Frist zuerst bedacht wird. So ergibt sich ein Plan mit deutlich weniger Prozessumschaltungen: d 2 d1 0

1

5

1 1 1 1 1 2 2 2


Das am Ende von Beispiel 3.2.4 exerzierte Verfahren der blockweisen Vergabe von Ausf¨ uhrungszeit an Prozesse wird als modifiziertes Planen nach Spielr¨ aumen bezeichnet (modified least laxity first oder MLLF). Das zugeh¨ orige Verfahren (vgl. [104]) unterscheidet sich von Verfahren 3.2.2 nur darin, dass anstelle von edf (Ready(t)) zwei Aufrufe notwendig sind: 3.2.3

Verfahren 3.2.3 Planen nach Spielr¨ aumen bei unterbrechbaren Prozessen

schedule(P L, P ):: P L =<>; t = min{ri | ri ∈ P }; WHILE ¬allinP L(t) DO IF Ready(t) = ∅ THEN t = nextdispatch(t);

3.2

Planen bei dynamischen Priorit¨ aten

177

ELSE BEGIN X = mllf (Ready(t)); i = selectOne(X); IF t + rest(i, t) > di THEN BREAK; ∆u = nextdispatch(t) − t; P L = P L∧ (i, t, ∆u); t = t + ∆u; END
Dabei berechnet die Funktion mllf angewandt auf eine Prozessmenge Y diejenige Menge X von Prozessen mit kleinstem Spielraum: mllf (Y ) = {i ∈ Y | ∆li ≤ ∆lj mit j ∈ Y } Bezogen auf den Gesichtspunkt der Brauchbarkeit sind die Verfahren EDF, LLF und MLLF gleichwertig. Mit einfachen Konstruktionen lassen sich brauchbare Pl¨ ane nach einem Verfahren in brauchbare Pl¨ane eines andeuber ren Verfahrens umformen (vgl. [100]). Somit gilt: FEDF = FLLF . Dar¨ hinaus lassen sich die Ergebnisse auf periodische unterbrechbare Prozesse u ¨bertragen. Aufgabe 3.2.5 (siehe Seite 284) Gegeben sei die Prozessmenge P = {1, 2, 3}

unterbrechbarer Prozesse mit den Prozessparametern: P 1 2 3

r 0 0 2

∆e 3 6 2

d 10 11 8

Konstruieren Sie Pl¨ ane, die nach den Verfahren EDF, LLF und MLLF entstehen k¨ onnen.


3.2.5

178

3.3

3. Grundlegende Planungsverfahren

3.3 Planen bei statischen Priorit¨ aten Die Planungsverfahren, die in diesem Abschnitt behandelt werden, sind eingeschr¨ ankt auf periodische unterbrechbare Prozesse. Gleichzeitig wird jedem Prozessobjekt eine feste Priorit¨ at zugeordnet, so dass eindeutig festgelegt ist, welcher Prozess welchen anderen verdr¨ angen kann. Zun¨achst werden allgemeine Aussagen zum Planen nach festen Priorit¨aten abgeleitet (siehe Unterabschnitt 3.3.1). Im Anschluss daran wird das wichtigste Planungsverfahren, das Planen nach monotonen Raten behandelt (siehe Unterabschnitte 3.3.2) bis 3.3.4), gefolgt vom Planen nach monotonen Fristen (siehe Unterabschnitt 3.3.5). 3.3.1 Planen nach festen Priorit¨ aten

Das Planen nach festen Priorit¨ aten (engl. fixed priority scheduling) geh¨ort zur Klasse der impliziten Planungsverfahren. Es wird kein expliziter Plan erzeugt. Stattdessen existiert durch Vergabe von Priorit¨aten an Prozesse ein impliziter Plan, repr¨ asentiert durch eine Priorit¨atszuordnung: prio : P −→ N Diese Priorit¨ at wird einem Prozess, genauer einem Prozessobjekt, einmalig zugeordnet. Vorrangig findet das Planen nach festen Priorit¨aten Anwendung auf periodische unterbrechbare Prozesse. Dabei f¨ ullt ein Prozess die L¨ ucken, die die Prozesse h¨ oherer Priorit¨ at u ¨brig lassen. Umgekehrt nimmt dieser Prozess keinerlei Notiz von den Prozessen niedrigerer Priorit¨at. Bei periodischen unterbrechbaren Prozessen wiederholt sich ein Plan sp¨atestens nach dem kleinsten gemeinsamen Vielfachen aller Perioden von Prozessen aus P : kgV ({∆pi | i ∈ P }) Diese Zeitspanne wird auch Planungszyklus oder einfach Zyklus genannt. Innerhalb eines Zyklus ist die Antwortzeit eines Prozesses nicht gleichm¨aßig verteilt. 3.3.1

Definition 3.3.1 Unter dem kritischen Zeitpunkt eines Prozesses i versteht angig von den Bereitzeiten aller u man diejenige Bereitzeit rik , die abh¨ ¨brigen Prozesse die Abschlusszeit cki maximal werden l¨asst. Entsprechend heißt
[rik , cki ] kritisches Intervall.

3.3.1

Satz 3.3.1 [91] F¨ ur einen Prozess i ∈ P ist ein kritischer Zeitpunkt rik immer

dann gegeben, wenn die Bereitzeiten aller h¨oher priorisierten Prozesse auf rik fallen.

3.3

Planen bei statischen Priorit¨ aten

179

Beweis: Man betrachte den Prozess i, der zum Zeitpunkt rik bereit wird und uhrung abschließt. Zwischenzeitlich wird Prozess zum Zeitpunkt cki seine Ausf¨ i gegebenenfalls durch Prozess j, mit i < j, verdr¨angt.


 















Der Bedarf an Ausf¨ uhrungszeit, den der h¨ oher priorisierte Prozess j im Ink k alt, wird durch die Anzahl angefangener Perioden tervall [ri , ci ] hat und erh¨ l bestimmt. Sei rjj die erste Bereitzeit von Prozess j ab rik . Verschiebt man den l Zeitpunkt rjj nach vorne bis auf den Zeitpunkt rik , dann kann es sein, dass eine weitere Periode von Prozess j vor cki beginnt und sich die Abschlusszeit von Prozess i um mindestens ∆ej nach hinten verschiebt. Diese Argumentation gilt aus der Sicht von Prozess i f¨ ur alle h¨oher priorisierten Prozesse, w¨ ahrend alle niedriger priorisierten Prozesse keine Wirkung auf Prozess i ur alle j > i haben. Damit wird das Intervall [rik , cki ] dann maximal, wenn f¨ gilt: rjk = rik
Mit diesem Beweis wird gleichzeitig ein Weg gewiesen, um zu zeigen, ob bei den gegebenen Priorit¨ aten ein brauchbarer Plan existiert oder nicht. Denn dazu ist f¨ ur einen Prozess i die Konstruktion aus dem Beweis, angefangen bei Prozess Pn bis Pi , durchzuf¨ uhren. Kann man nun nachzuweisen, dass das kritische Intervall [rik , cki ] in eine Periode ∆pi passt, dann ist Prozess i brauchbar einplanbar (vgl. [85]). Bei n Prozessen gibt es n! M¨ oglichkeiten der Zuordnung einer Priorit¨at. Da liegt die Idee nahe, denjenigen Prozessen die h¨ochste Priorit¨at zuzuordnen, die als besonders wichtig erachtet werden. Das n¨achste Beispiel macht deutlich, dass auf diese Weise kein brauchbarer Plan zustande kommt, obwohl die Auslastung deutlich unter 1 liegt. Beispiel 3.3.1 Gegeben sei die Prozessmenge P = {1, 2} periodischer unterbrechbarer Prozesse mit folgenden Prozessparametern:

P 1 2

∆e 5 3

∆p 11 7

3.3.1

180

3. Grundlegende Planungsverfahren

Dabei m¨ oge der Prozess 1 als besonders wichtig erachtet werden. Deshalb erh¨ alt er eine h¨ ohere Priorit¨ at als Prozess 2. Aufgrund der priorit¨atsbasierten Prozessausf¨ uhrung wird Prozess 1 unbeeinflusst von der Existenz anderer Prozesse vorrangig verplant. Obwohl die Auslastung U nur bei etwa 0.883 liegt, gibt es bei der ersten Ausf¨ uhrung von Prozess 2 bereits eine Fristverletzung:     























Damit steht bereits fest, dass das Planen nach festen Priorit¨aten nicht die Auslastung erreicht, die beispielsweise mit dem Planen nach Fristen zu erreichen ist. Schlimmer noch: Zu jeder Auslastung U > 0 findet man Prozessparameter und feste Priorit¨ aten, die zu einem unbrauchbaren Plan f¨ uhren. 3.3.1

Aufgabe 3.3.1 (siehe Seite 285) Zeigen Sie, dass beim Planen nach festen Prio-

rit¨ aten zu jeder Auslastung 0 < U < 1 eine Prozessmenge P existiert, die nicht brauchbar eingeplant werden kann.
Nach diesen negativen Ergebnissen stellt sich die Frage, welche Zuordnung von Priorit¨ aten die optimale ist oder genauer, welches Verfahren S innerhalb der Klasse der Verfahren mit festen Priorit¨aten FF IX optimal ist (siehe Definition 2.1.3). Eine Antwort liefert der n¨achste Abschnitt. 3.3.2 Planen nach monotonen Raten

Das Planen nach Raten (engl. rate monotonic scheduling oder RMS) geh¨ort zu einer Klasse FF IX von Planungsverfahren mit festen Priorit¨aten. Dabei bezeichnet die Rate eines Prozesses i die Anzahl seiner Perioden bezogen auf eine Bezugszeitspanne. Entsprechend dieser Raten werden den Prozessen dann Priorit¨ aten zugeordnet. F¨ ur die nachfolgenden Betrachtungen wird von Prozessmengen P mit paarweise verschiedenen Raten ausgegangen. Die spezielle Priorit¨atszuordnung rms ist festgelegt durch: rms(i) < rms(j) ⇐⇒

1 1 < ∆pi ∆pj

3.3

Planen bei statischen Priorit¨ aten

181

Unter diesen Voraussetzungen spricht man vom Planen nach monotonen Raten (engl. rate monotonic scheduling). Es ist damit ein spezielles Verfahren innerhalb der Klasse der Planungsverfahren mit festen Priorit¨aten. Im Weiteren seien die Prozesse entsprechend ihrer Priorit¨at nummeriert: i < j ⇐⇒ rms(i) < rms(j) Obwohl sich erweisen wird, dass auch das Planen nach monotonen Raten nicht die gleiche Auslastung erzielt wie das Planen nach Fristen, hat es im Anwendungsbereich der Echtzeitsysteme neben dem Planen nach Fristen herausragende Bedeutung. Zum einen wird sich zeigen, dass das Planen nach monotonen Raten innerhalb der Verfahren mit festen Priorit¨aten optimal ist. Das nachfolgende Beispiel 3.3.2 belegt diese Aussage. Zum anderen liegt seine Anziehungskraft in der einfachen Handhabung, die darin besteht, dass f¨ ur die Entscheidung u ¨ber die Prozessorzuteilung bei der Prozessumschaltung lediglich zwei Priorit¨ atswerte verglichen werden m¨ ussen, n¨amlich die des rechnenden Prozesses und die des Prozesses, der gerade bereit wird. Damit verbunden ist festzustellen, dass die programmiertechnischen Voraussetzungen zur Durchf¨ uhrung dieses Planungsverfahrens bei den meisten kommerziellen Echtzeitbetriebssystemen bereits unterst¨ utzt werden. Beispiel 3.3.2 Planen nach monotonen Raten angewandt auf die Prozessmenge aus Beispiel 3.3.1 gibt Prozess 2 die h¨ ochste Priorit¨at und liefert einen brauchbaren Plan:












































Es wird außerdem deutlich, dass jede Erh¨ ohung der Ausf¨ uhrungszeit, z.B. von Prozess 1 um eine Zeiteinheit, zu einer Fristverletzung f¨ uhren w¨ urde. Gleichzeitig liegt in dem Fall die Auslastung U bei etwa 0.974 und damit immer noch niedriger als 1. Das bedeutet, auch beim Planen nach Fristen h¨ atte man einen brauchbaren Plan gefunden: 






























































































3.3.2

182

3.3.2

3. Grundlegende Planungsverfahren

Satz 3.3.2 [91] Sei P eine Prozessmenge periodischer unterbrechbarer Prozesse. Das Planungsverfahren nach monotonen Raten ist optimal innerhalb der Klasse FF IX der Planungsverfahren nach festen Priorit¨aten, oder anders ausgedr¨ uckt, f¨ ur die eine gefundene Priorit¨atszuordnung bereits einen brauchbaren Plan liefert. Dann wird auch die Priorit¨atszuordung nach monotonen Raten einen brauchbaren Plan liefern. Beweis: Gegeben sei eine beliebige Zuordnung fester Priorit¨ aten, die einen brauchbaren Plan liefert. Gezeigt wird, dass auch dann eine Priorit¨ atszuordnung nach monotonen Raten einen brauchbaren Plan liefert. Seien dazu die Prozesse i und j so gew¨ ahlt, dass gilt: 1. ∆pi < ∆pj

2. Die gefundenen Priorit¨ aten von Prozess i und Prozess j folgen unmittelbar aufeinander, d.h.,j ist der niedrigstpriorisierte Prozess, der i unterbrechen kann. Es wird eine Zeitachse betrachtet, in der alle Ausf¨ uhrungszeiten von Prozessen mit h¨ oheren Priorit¨ aten ausgeblendet sind und Prozess i von Prozess j unterbrochen wird: 













 

Wegen der Perioden von i und j folgt aus ri < rj auch di < dj . Vertauscht man die Priorit¨ aten entsprechend der monotonen Raten der beiden Prozesse, dann ergibt sich wieder ein brauchbarer Plan:

Dabei werden nur Ausf¨ uhrungszeiten zwischen Prozess i und Prozess j vertauscht. Durch jede Anwendung dieser Konstruktion n¨ahert sich die gefundene Priorisierung an die der monotonen Raten an.
Dennoch sind auch Priorit¨ aten nach monotonen Raten nicht optimal bezogen auf die Menge aller Planungsverfahren (siehe Beispiel 3.3.2). Dass sich bereits f¨ ur zwei Prozesse erhebliche Auslastungsdefizite ergeben k¨onnen, zeigt das folgende Beispiel. Bevorzugt wird der zum aktuellen Zeitpunkt h¨ochstpriorisierte Prozess, obwohl durch seine Verz¨ ogerung die n¨ aherliegenden Fristen anderer Prozesse noch gehalten werden k¨ onnten.

3.3

Planen bei statischen Priorit¨ aten

183

Beispiel 3.3.3 Gegeben sei die Prozessmenge P = {1, 2} mit den Prozesspa-

3.3.3

rametern: P 1 2

∆e 3 2

∆p 7 5

In diesem Fall existiert ein brauchbarer Plan, da das kritische Intervall in eine Periode passt (siehe Satz 3.3.2): 


















Die Auslastung betr¨ agt unter diesen Voraussetzungen lediglich U = 3/7 + 2/5  0, 828. Jede Erh¨ ohung von Ausf¨ uhrungszeiten f¨ uhrt jedoch zur Frist¨ uberschreitung, so z.B. ∆e1 = 4. An diesem Beispiel ist bereits zu sehen, dass jede auch noch so kleine Erh¨ ohung der Ausf¨ uhrungzeit zu einer Fristverletzung f¨ uhrt. Zur Veranschaulichung wird von Vielfachen der Werte der Prozessparameter ausgegangen und dann auf die Ausf¨ uhrungszeit des Prozesses 1 noch eine Zeiteinheit aufaddiert: P 1 2

∆e 301 200

∆p 700 500

Das Planen nach monotonen Raten findet keinen brauchbaren Plan. Gleichzeitig liegt die Auslastung mit U = 0.829 unwesentlich u ¨ber der obigen, die noch brauchbar eingeplant werden konnte.
Wenn schon nicht in jedem Falle volle Prozessorauslastung zu erreichen ist, so stellt sich die Frage, bis zu welcher Auslastung beim Planen nach monotonen Raten immer noch ein brauchbarer Plan gefunden wird. Gleichwertig ist die Frage nach der niedrigsten Auslastung Umin , zu der zwar noch ein brauchbarer Plan existiert, bei der jedoch schon die geringste Erh¨ohung von Ausf¨ uhrungszeiten eine Frist¨ uberschreitung nach sich zieht. Der Wert von angt allein von der Zahl der Prozesse ab und wird im Folgenden f¨ ur Umin h¨ zwei Prozesse bestimmt. Satz 3.3.3 [91] Gegeben seien die beiden Prozesse P1 und P2 , die nach monotonen Raten eingeplant werden. Dann gilt: √ Umin = 2( 2 − 1)

3.3.3

184

3. Grundlegende Planungsverfahren

Beweis: Sei ∆p1 > ∆p2 , was bedeutet: P2 ist h¨ oher priorisiert als P1 . Ausgehend vom kritischen Zeitpunkt von P1 gibt es im Intervall ∆p1 genau ur P2 . F¨ ur den BeV = ∆p1 /∆p2 , mit V ≥ 2, beginnende Perioden f¨ oßert, dass der Prozessor im Intervall [r11 , d11 ] voll weis wird ∆e1 soweit vergr¨ ausgelastet ist. Zwei F¨ alle sind zu unterscheiden: 1 uhrt worden. 1. Fall: Vor d1 ist Prozess P2 bereits V -mal vollst¨andig ausgef¨ Das ist der Fall, wenn: 0 ≤ ∆e2 ≤ ∆p1 − (V − 1)∆p2  

 










 

Dann ist die Ausf¨ uhrungszeit von P1 maximal f¨ ur: ∆e1 = ∆p1 − V ∆e2 Entsprechend ist die Auslastung: ∆e2 ∆p1 − V ∆e2 + ∆p1 ∆p2

 1 V = 1 + ∆e2 − ∆p2 ∆p1

U =

Wegen V ∆p2 ≥ ∆p1 gilt V 1 − ≤0 ∆p2 ∆p1 so dass die Auslastung U mit steigenden Werten von ∆e2 minimiert wird. uhrt. 2. Fall: Bei der Frist d11 wird Prozess P2 gerade zum V -ten mal ausgef¨ Das ist der Fall f¨ ur: ∆p1 − (V − 1)∆p2 < ∆e2 ≤ ∆p2





 


















Dann ist die Ausf¨ uhrungszeit von P1 maximal f¨ ur: ∆e1 = (V − 1)(∆p2 − ∆e2 )

3.3

Planen bei statischen Priorit¨ aten

185

Entsprechend ist die Auslastung: (V − 1)(∆p2 − ∆e2 ) ∆e2 + ∆p1 ∆p2

 1 (V − 1)∆p2 V −1 = + ∆e2 − ∆p1 ∆p2 ∆p1

U =

Wegen (V − 1)∆p2 < ∆p1 gilt V −1 1 − >0 ∆p2 ∆p1 so dass die Auslastung U mit fallenden Werten von ∆e2 minimiert wird (siehe Abb. 3.10).




 










 



 




Abb. 3.10. Die Auslastung U bei beliebigen Perioden in Abh¨ angigkeit von ∆e2 .

F¨ ur ∆e2 = ∆p1 − (V − 1)∆p2 wird U minimal und besitzt links- wie rechtsseitig den Grenzwert: 

1 V − Umin = 1 + (∆p1 − (V − 1)∆p2 ) ∆p2 ∆p1 Sei w der Anteil an der Periode ∆p2 , der noch in ∆p1 passt: w=

∆p1 − (V − 1) ∆p2

Abh¨ angig von den Perioden von P1 und P2 gilt: 0≤w<1 Durch Einsetzen in die Formel f¨ ur die Auslastung Umin ergibt sich:

 1 V − Umin = 1 + w∆p2 ∆p ∆p1

2  ∆p2 ∆p1 = 1+w − (V − 1) − 1 ∆p1 ∆p2 ∆p2 (w − 1) = 1+w ∆p1

186

3. Grundlegende Planungsverfahren

Mit dem Ersetzen von ∆p2 /∆p1 durch 1/(w + V − 1) wird Umin allein von w und V abh¨ angig: Umin = 1 −

w(1 − w) w+V −1

F¨ ur V = 2 wird der Nenner und damit auch Umin minimal. Der Anteil w wird nun als kontinuierliche Gr¨ oße betrachtet, nach der zur Minimierung von Umin abgeleitet wird:


Umin (w) = −

(1 − 2w)(1 + w) − w(1 − w) (1 + w)2

Gesucht wird w mit: (1 − 2w)(1 + w) − w(1 − w) = 0 Durch Zusammenfassen ergibt sich: (w + 1)2 = 2 Es existiert nur eine L¨ osung im Bereich 0 ≤ w < 1 : √ w = 2−1 Der in der Wahl der Ausf¨ uhrungszeiten und der Wahl der Perioden kleinste Wert der Auslastung, bei dem jede weitere Erh¨ohung der Ausf¨ uhrungszeit eine Frist¨ uberschreitung nach sich zieht, liegt bei: √ √ ( 2 − 1)(1 − ( 2 − 1)) √ Umin = 1 − 2−1+1 √ √ ( 2 − 1)(2 − 2) √ = 1− 2 √ √ = 1 − ( 2 − 1)( 2 − 1) √ = 2 2−2 √ = 2( 2 − 1) ≈ 0, 828
In ¨ ahnlicher Weise l¨ asst sich bei n Prozessen argumentieren. Dabei liegt die niedrigste Auslastung bei (vgl. [91]):

√  n 2−1 n≥2 Umin (n) = n

3.3

Planen bei statischen Priorit¨ aten

187

Aufgabe 3.3.2 (siehe Seite 286) Beweisen Sie, dass bei n Prozessen, die nach √  ur n ≥ 2. monotonen Raten eingeplant werden, gilt: Umin (n) = n n 2 − 1 , f¨


3.3.2

Die Funktion Umin (n) ist monoton fallend in n und approximiert den Wert: lim Umin (n) = ln(2) ≈ 0, 693

n→∞

Aufgabe 3.3.3 (siehe Seite 290) Zeigen Sie, dass gilt:

lim n

n→∞

√ n

3.3.3



2 − 1 = ln(2)


Im so genannten LL-Test5 soll anhand der Auslastung UP einer beliebigen Prozessmenge P = {1, . . . , n} gepr¨ uft werden, ob Brauchbarkeit gegeben ist. Diese ist der Fall, wenn gilt: UP ≤ Umin (n) Der Test ist hinreichend, aber nicht notwendig f¨ ur den Nachweis der Brauchbarkeit. Ist also der Test nicht erfolgreich, so sind weitere Pr¨ ufungen der Brauchbarkeit notwendig. Einige werden in den folgenden Abschnitten n¨aher erl¨ autert. Dabei wird deutlich, dass die Prozessparameter und ihr Verh¨altnis zueinander großen Einfluss auf die Brauchbarkeit haben. Im positiven Sinne ¨ außert sich dies bei Prozessmengen mit harmonischen Perioden. Hier ist beim Planen nach monotonen Raten selbst bei einer Auslastung von 1 noch Brauchbarkeit gegeben, wie die folgende Aufgabe deutlich macht. Aufgabe 3.3.4 (siehe Seite 290) Sei PH = {1, . . . , n} eine Menge periodischer unterbrechbarer Prozesse mit der Eigenschaft, dass ihre Perioden harmonisch sind. D.h., f¨ ur je zwei Prozesse i und j, mit 1 ≤ i ≤ j ≤ n, gilt: ∆pj teilt ∆pi . Zeigen Sie, dass die Prozessmenge PH genau dann brauchbar verplant
werden kann, wenn gilt UPH ≤ 1.

3.3.3 Hyperbolische Schranke beim Planen nach monotonen Raten 5

Der Name LL-Test geht auf die Autoren Liu und Layland zur¨ uck, die in ihrem wegweisenden Artikel [91] grundlegende Ergebnisse zum Planen nach monotonen Raten und zum Planen nach Fristen hervorgebracht haben.

3.3.4

188

3. Grundlegende Planungsverfahren

Die Beweisf¨ uhrung bei Satz 3.3.3 wie auch bei seiner Verallgemeinerung im Beweis von Aufgabe 3.3.2 konstruiert eine Prozessmenge P mit Prozessparametern, die den Rand der Brauchbarkeit markieren. Diese werden als Randmenge (engl. boundary set) bezeichnet. Anschaulich kann man sich diese Menge wie einen Topf (siehe Abb. 3.11) vorstellen, an dessen tiefstem Punkt die ur die Prozessparameter gelten f¨ ur diesen Auslastung Umin (n) erreicht wird. F¨ Fall ganz spezielle Beziehungen, zun¨ achst f¨ ur die Periode: √ n , i ∈ {2, . . . , n} ∆pi−1 = 2 ∆pi HB-Test

U

Randmenge

1 (3) (2)

nicht brauchbar nach RMS

LL-Test

(4)

brauchbar nach EDF

U min (n) (1)

Abb. 3.11. In Abh¨ angigkeit von der Auslastung U werden insgesamt vier Klassen von

Prozessmengen unterschieden: (1) Die Prozessmengen, die den LL-Test bestehen. (2) Die Prozessmengen, die zus¨ atzlich den HB-Test bestehen. (3) Dar¨ uber hinaus gibt es Prozessmengen, die sowohl beim LL-Test als auch beim HB-Test versagen und dennoch brauchbar sind. (4) Die Prozessmengen, die nicht brauchbar verplant werden k¨ onnen.

Die Ausf¨ uhrungszeiten stehen in einer festen Beziehung zur Periode:

√  n 2 − 1 ∆pi , i ∈ {1, . . . , n} ∆ei = Prozesse mit Prozessparametern, die die Randmenge bilden, sind weniger restriktiv. Dennoch gelten auch hier eine Reihe von Beziehungen. Eine besagt, dass die Perioden nur sehr begrenzt variieren: ∆pn < ∆pi < 2 ∆pn

, i ∈ {2, . . . , n}

Die Differenzen zwischen nebeneinander liegenden Perioden werden folgendermaßen durch Ausf¨ uhrungszeiten gef¨ ullt: ∆ei = ∆pi−1 − ∆pi

, i ∈ {2, . . . , n}

3.3

Planen bei statischen Priorit¨ aten

189

Schließlich passen alle Ausf¨ uhrungszeiten in die Perioden des h¨ochstpriorisierten Prozesses n: n

∆ei = ∆pn

i=1

Aus den beiden letzten Gleichungen l¨ asst sich folgern: ∆e1 = 2 ∆pn − ∆p1 Diese Gleichung ist die Grundlage f¨ ur die Herleitung einer so genannten hyperbolischen Schranke6 zum Nachweis der Brauchbarkeit einer Prozessmenge P. Satz 3.3.4 [17] Sei P = {1, . . . , n} eine Prozessmenge unterbrechbarer peri-

odischer Prozesse. Ein Plan nach monotonen Raten f¨ ur die Prozessmenge P ist brauchbar, wenn gilt:  n

 ∆ei +1 ≤2 ∆pi i=1 Beweis: Grundlage der Beweisf¨ uhrung sind die Beziehungen f¨ ur Prozesse der Randmenge, wobei Brauchbarkeit gegeben ist, wenn die Ungleichung

∆e1 ≤ 2 ∆pn − ∆p1 bzw. deren Umformung ∆e1 +1≤ ∆p1

2 ∆p1 ∆pn

erf¨ ullt ist. Des Weiteren gilt die Beziehung: ∆pi−1 ∆ei +1= ∆pi ∆pi Daraus folgt:

n

 ∆ei i=2

6

, i ∈ {2, . . . , n}

 ∆p1 +1 = ∆pi ∆pn

Dabei ist keine hyperbolische Funktion der Art x2 − y 2 = 1 im Spiel. Vielmehr ist diese Bezeichnung der Autoren (vgl. [17]) als Anspielung auf die Form der Randmenge zu verstehen, die der Form einer hyperbolischen Kurve gleicht.

3.3.4

190

3. Grundlegende Planungsverfahren

Durch Einsetzen in die Ungleichung f¨ ur die Brauchbarkeit ergibt sich die Behauptung:  n

 ∆ei +1 ≤2 ∆pi i=1
Der Test mit der hyperbolischen Schranke wird HB-Test genannt. Der HBTest ist weniger pessimistisch als der LL-Test. Die folgende Aufgabe zeigt, dass dies grunds¨ atzlich gilt. 3.3.5

Aufgabe 3.3.5 (siehe Seite 291) Beweisen Sie, dass aus der G¨ ultigkeit des LL-

Tests UP ≤ n

√  n 2−1

f¨ ur eine Prozessmenge P periodischer unterbrechbarer Prozesse folgt, dass auch die Bedingung  n

 ∆ei +1 ≤2 ∆pi i=1 des HB-Tests erf¨ ullt ist. 3.3.4




Beispiel 3.3.4 Sei P = {1, 2} eine Prozessmenge bestehend aus zwei periodi-

schen unterbrechbaren Prozessen mit den Prozessparametern: ∆e 9 1

P 1 2

∆p 12 5

Die Auslastung betr¨ agt U = 0, 925. Damit ist mit dem LL-Test kein Nachweis der Brauchbarkeit zu f¨ uhren. F¨ ur den HB-Test ist zu pr¨ ufen, ob gilt: 



1 9 +1 +1 ≤2 12 5 Auch dies ist nicht erf¨ ullt. Der Aufbau eines Anfangsst¨ ucks eines expliziten Plans zeigt jedoch, dass ein brauchbarer Plan nach monotonen Raten existiert (siehe Satz 3.3.1). 0

1

5

6

10 11

2 1 1 1 1 2 1 1 1 1 2 1

Somit ist der HB-Test ebensowenig ein notwendiges Kriterium f¨ ur die Brauchbarkeit wie der LL-Test.

3.3

Planen bei statischen Priorit¨ aten

191

Durch die Verringerung der Ausf¨ uhrungszeit von Prozess 1 l¨asst sich nun leicht ein Fall konstruieren, bei dem der HB-Test Brauchbarkeit nachweist, der LL-Test jedoch nicht. P 1 2

∆e 8 1

∆p 12 5

Der HB-Test liefert nun exakt den Wert 2 und ist damit erf¨ ullt, w¨ahrend die Auslastung noch immer bei etwa 0, 867 liegt und der LL-Test versagt.
Im Gegensatz zum LL-Test gehen beim HB-Test die Anteile der Auslastung, die jeder einzelne Prozess beitr¨ agt, mit ein. Liefert der HB-Test f¨ ur eine Prozessmenge P genau den Wert 2, dann l¨ asst sich eine andere Prozessmenge P  erzeugen, bei der jeder einzelne Prozess dieselbe Auslastung wie zuvor beitr¨ agt und Teil der Randmenge ist. In diesem Sinne pr¨ uft der HB-Test, ob die Prozessmenge zur Randmenge geh¨ ort oder außerhalb des Topfes liegt (siehe Abb. 3.11). Satz 3.3.5 Sei P = {1, . . . , n} eine Prozessmenge periodischer unterbrechbarer Prozesse mit  n

 ∆ei +1 =2 ∆pi i=1

Dann existiert dazu eine Prozessmenge P  mit ∆ei /∆pi = ∆ei /∆pi und P  ist eine Randmenge. Beweis: In folgender Weise wird aus P die neue Prozessmenge P  . F¨ ur Prozess na ndert sich nichts: ¨ ∆ei = ∆ei

∆pi = ∆pi

Alle u achst in ihrer Periode so angepasst, dass ¨brigen Prozesse i werden zun¨ jede Erh¨ ohung der Ausf¨ uhrungszeit zu einer Fristverletzung f¨ uhren w¨ urde: ∆pi−1 = ∆pi + ∆ei

, i ∈ {2, . . . , n}

Diese Eigenschaft sichert gleichzeitig die Brauchbarkeit von Prozess i − 1. Dann wird die Ausf¨ uhrungszeit soweit angepasst, dass die Auslastung unver¨ andert bleibt: ∆ei = ∆pi

∆ei ∆pi

, i ∈ {1, . . . , n − 1}

Offensichtlich entsteht auf diese Weise eine brauchbare Randmenge P  .




3.3.5

192

3.3.6

3. Grundlegende Planungsverfahren

Aufgabe 3.3.6 (siehe Seite 292) Formen Sie die Prozessmenge P = {1, 2} aus

Beispiel 3.3.4 nach Konstruktion des Beweises aus Satz 3.3.5 um. Dabei soll
deutlich werden, dass P  ein Element der Randmenge ist. 3.3.4 Bedarf an Ausf¨ uhrungszeit

Das Planen nach monotonen Raten liefert bis zur Auslastung von etwa 69% immer einen brauchbaren Plan. Geht die Auslastung dar¨ uber hinaus, so kann Brauchbarkeit gegebenfalls mit dem LL-Test oder dem HB-Test nachgewiesen werden. Versagen auch diese Tests, dann kann es immer noch einen brauchbaren Plan geben. Untersuchungen zeigen, dass es sich lohnt weitere Pr¨ ufungen anzuschließen, ob ein brauchbarer Plan nach monotonen Ra¨ ten zustande kommt (vgl. [85]). Neben der Uberpr¨ ufung der kritischen Intervalle gibt es verfeinerte Kriterien zum Nachweis der Brauchbarkeit und zur weiteren Erh¨ ohung der Auslastung. Betrachtet man den relativen Bedarf uhrungszeit, der von den Prozessen i bis n innerhalb einer relreqi (∆t) an Ausf¨ Zeitspanne ∆t ausgeht, dann ist: 

  n ∆t ∆ej j=i ∆pj relreqi (∆t) = ∆t Dabei gibt der Term ∆t/∆pj  an, wie viel mal Ausf¨ uhrungszeiten des Prozesses j in der Zeitspanne ∆t begonnen haben. Bezogen auf die erste Ant(1) wortzeit ∆ai von Prozess i gilt: (1)

relreqi (∆ai ) = 1 (1)

Und f¨ ur alle 0 < ∆t < ∆ai

ist: relreqi (∆t) > 1

Aufgrund der Sprunghaftigkeit des Faktors ∆t/∆pj  ist relreqi (∆t) nur zwischen den Vielfachen der Perioden der Prozesse stetig, und zwar fallend. Die Minima f¨ ur Pi liegen dementsprechend zu den Zeitpunkten:    ∆pi Mi = k ∆pj | i ≤ j ≤ n, 1 ≤ k ≤ ∆pj Seien Pi+1 bis Pn bereits nach monotonen Raten brauchbar einzuplanen, dann ist das auch f¨ ur Pi gegeben, wenn gilt: min{relreqi (∆t) | ∆t ∈ Mi } ≤ 1

3.3

Planen bei statischen Priorit¨ aten

193

Denn dann liegt die Abschlusszeit ci vor di . Damit kann ein entsprechendes Verfahren bereits dann Brauchbarkeit attestieren, wenn eine Zeitspanne ∆t ∈ ullt. Mi gefunden ist, die die Ungleichung erf¨ Beispiel 3.3.5 Gegeben sei die Prozessmenge P = {1, 2, 3} mit ∆p1 = 19,

∆p2 = 9 und ∆p3 = 4 sowie ∆e1 = 3, ∆e2 = 2 und ∆e3 = 2. Die Auslastung ur durch P2 und P3 ist mit U ≈ 0, 722 weit unter Umin (2) ≈ 0, 828. Erst f¨ alle drei Prozesse liegt die Auslastung bei U ≈ 0, 880, was die Schranke ¨ uckliche Uberpr¨ ufung Umin (3) ≈ 0, 779 deutlich u ¨berschreitet und eine ausdr¨ der Brauchbarkeit notwendig macht. Folgende Zeitpunkte sind zu betrachten: M1 = {4, 8, 9, 12, 16, 18, 19} Systematisch wird nach einer erf¨ ullten Ungleichung gesucht (siehe Abb. 3.12): 7 = ∆e1 + ∆e2 + ∆e3 ≤ ∆p3 = 4 9 = ∆e1 + ∆e2 + 2∆e3 ≤ 2∆p3 = 8 11 = ∆e1 + 2∆e2 + 2∆e3 ≤ ∆p2 = 9 13 = ∆e1 + 2∆e2 + 3∆e3 ≤ 3∆p3 = 12 15 = ∆e1 + 2∆e2 + 4∆e3 ≤ 4∆p3 = 16 relreq

2.5 2 1.5 1 0.5 5

10

15

20

t

Abb. 3.12. Diagramm der Funktion relreq1 (∆t).

¨ Die Uberpr¨ ufung kann enden, denn die Brauchbarkeit ist erwiesen. Dar¨ uber hinaus ist zu sehen, dass die Ausf¨ uhrungszeit von Prozess 1 um eine Zeiteinheit aufgestockt werden k¨ onnte, ohne die Brauchbarkeit zu gef¨ahrden. Al¨ ternativ dazu k¨ onnte ohne weitere Uberpr¨ ufung ein neuer Prozess mit einer Ausf¨ uhrungszeit von eins und einer Periode von mindestens 4∆p3 ohne Gefahr einer Fristverletzung hinzukommen. Kommt statt dessen ein Prozess 0 mit ∆p0 = 25 und ∆e0 = 2 hinzu, dann erreicht die Auslastung den Wert

3.3.5

194

3. Grundlegende Planungsverfahren

U = 0.96. Nach der Bestimmung von M0 = {4, 8, 9, 12, 16, 18, 19, 20, 24, 25} ¨ wird die Uberpr¨ ufung bei der letzten Gleichung fortgesetzt: 17 = ∆e0 + ∆e1 + 2∆e2 + 4∆e3 ≤ 4∆p3 = 16 19 = ∆e0 + ∆e1 + 2∆e2 + 5∆e3 ≤ 2∆p2 = 18 21 = ∆e0 + ∆e1 + 3∆e2 + 5∆e3 ≤ ∆p1 = 19 24 = ∆e0 + 2∆e1 + 3∆e2 + 5∆e3 ≤ 5∆p3 = 20 26 = ∆e0 + 2∆e1 + 3∆e2 + 6∆e3 ≤ 6∆p3 = 24 28 = ∆e0 + 2∆e1 + 3∆e2 + 7∆e3 ≤ ∆p0 = 25 Auch wenn der so gegebene Prozess 0 nicht mehr brauchbar eingeplant werden kann, wird sichtbar, dass Prozess 0 gerade um eine Zeiteinheit zu lang ist, um nach monotonen Raten eingeplant werden zu k¨onnen.
3.3.7

Aufgabe 3.3.7 (siehe Seite 292) Gegeben sei die Prozessmenge P = {1, 2}

uhrungszeiten mit den Perioden ∆p1 = 22 und ∆p2 = 12 sowie den Ausf¨ uhrungszeiten f¨ ur den ∆e1 = 14 und ∆e2 = 7. Wie bisher sollen diese Ausf¨ schlechtesten Fall gelten. Zus¨ atzlich sind nun auch die durchschnittlichen Ausf¨ uhrungszeiten bekannt mit ∆e1 = 10 und ∆e2 = 4. Die Prozessmenge soll nach festen Priorit¨aten eingeplant werden. Dabei soll garantiert werden, dass im Falle durchschnittlicher Ausf¨ uhrungszeiten beide Prozesse, 1 und 2, im schlechtesten Fall aber zumindest Prozess 1 die Frist einh¨ alt.
3.3.8

Aufgabe 3.3.8 (siehe Seite 293)

Gegeben sei die Prozessmenge P = {P1 , . . . , Pn }, die nach festen Priorit¨aten eingeplant werden soll. Es gelte rms(i) < rms(j) f¨ ur 1 ≤ i < j ≤ n. Der schlechteste Fall f¨ ur die Antwortzeit ∆ai eines Prozesses Pi ist rekursiv durch folgende Gleichung bestimmt (vgl. [69] und [9]):   n (k) ∆ai (k+1) ∆ej = ∆ei + ∆ai ∆pj j=i+1 n Iteriert man diese Gleichung mit einem Startwert ∆a0i = j=i ∆ej , so wird (k) (k) die L¨ osung im k-ten Schritt durch ∆ai approximiert. Dabei gilt ∆ai ≤ (k+1) ∆ai und die Iteration konvergiert, falls die Prozessorauslastung U unter (k) 1 liegt. Die Iteration kann abgebrochen werden, falls f¨ ur ein k gilt ∆ai ≥ d1i , also eine Fristverletzung vorliegt. Testen Sie mit diesem Kriterium, ob die Prozessmenge aus Beispiel 3.3.5 (Seite 193) brauchbar eingeplant werden kann.


3.3

Planen bei statischen Priorit¨ aten

195

3.3.5 Planen nach monotonen Fristen

Das Planen nach monotonen Fristen (engl. deadline monotonic scheduling oder DMS) stellt eine Verallgemeinerung des Planens nach monotonen Raten dar. Eine weitere Zwangsbedingung f¨ ur die Ausf¨ uhrung von Prozessen kennzeichnet dieses Planungsverfahren: Die relative Frist ∆di ist eine Zeitur die j-te Ausf¨ uhrung von Prozess i spanne k¨ urzer7 als die Periode, wobei f¨ gilt: rij ≤ sji ≤ cji ≤ rij + ∆di ≤ rij + ∆pi Analog zum Planen nach monotonen Raten werden beim Planen nach monotonen Fristen die Priorit¨ aten abh¨ angig von den relativen Fristen vergeben. dms(i) < dms(j) ⇐⇒

1 1 < ∆di ∆dj

Entsprechend gelte hier die Vereinbarung: i < j ⇐⇒ dms(i) < dms(j) ¨ Es ist unmittelbar einsichtig, dass f¨ ur die Uberpr¨ ufung der Brauchbarkeit die Fristen anstelle von Perioden ausschlaggebend sind. Dies gilt insbesondere f¨ ur den abgewandelten LL-Test, des Weiteren als LLD-Test bezeichnet: Satz 3.3.6 Gegeben sei die Prozessmenge P = {1, . . . , n} periodischer unterbrechbarer Prozesse. Diese Prozessmenge ist brauchbar verplanbar, wenn gilt: n √ ∆ei n ≤ n( 2 − 1) ∆d i i=1

Beweis: Analog zur L¨ osung von Aufgabe 3.3.2.




Die Bedeutung des Planens nach monotonen Fristen liegt in den anwendungsspezifischen M¨ oglichkeiten, die sich durch die relative Frist bietet. So l¨asst sich durch geeignete Wahl der relativen Frist das Flattern von 2(∆pi − ∆ei ) auf 7

Es gibt auch Ans¨ atze, die relative Fristen zulassen, die gr¨ oßer sind als die Periode des Prozesses (vgl. [86]). Dies hat zur Folge, dass zu einem Zeitpunkt mehr als eine Ausf¨ uhrung desselben Prozessobjektes m¨ oglich ist. Bei aller Flexibilit¨ at, die dieser Ansatz bietet, tritt das Problem auf, dass zwei oder mehr Prozessausf¨ uhrungen auf denselben Variablen stattfinden und die Konsistenz der Berechnung gef¨ ahrden k¨ onnen.

3.3.6

196

3. Grundlegende Planungsverfahren

2(∆di − ∆ei ) reduzieren. Daneben ist es m¨oglich, insbesondere bei Prozessen gleicher Periode, Reihenfolgen zu erzwingen, die beispielsweise aus Gr¨ unden des Datenflusses notwendig sind. 3.3.6

Beispiel 3.3.6 Bei der Wippe (siehe Beispiel 1.3.1) sind eine Reihe von Transformationen, denen man einen Prozess zuordnen kann, nacheinander durchzuf¨ uhren. Dies l¨ asst sich durch eine entsprechende Vergabe von Fristen, und damit auch von Perioden darstellen:

Transformation Erkennung Aggregation Steuerfunktion Motorsteuerung

P 4 3 2 1

∆e 15 2 3 15

∆d 20 25 30 40

∆p 40 40 40 40

Die Zeitangaben sind in Millisekunden zu verstehen, wobei die Periode von 40ms den 25Hz der Bildfrequenz der Kamera entspricht. Offensichtlich kommt es bei diesen Prozessparametern nicht zu einer Fristverletzung. Dennoch l¨ asst sich u ¨ber den LLD-Test keine Brauchbarkeit nachweisen. Gleichzeitig wird deutlich, dass der LLD-Test deutlich pessimistischer ausf¨ allt als der LL-Test, ja sogar linksseitig Werte u ¨ber 1 liefern kann: n 5 3 10 15 ∆ei + + + >1 = ∆d 20 25 30 40 i i=1


Ein wirksames Verfahren zum Nachweis der Brauchbarkeit muss die Prozessparameter der einzelnen Prozesse ber¨ ucksichtigen und fragt danach, ob die maximale Antwortzeit eines Prozesses seine Frist u ¨berschreitet oder nicht (vgl. [11]). Das Verfahren ist iterativ und setzt die Antwortzeit von Prozess i im Schritt (0) auf. n (0) ∆ai = ∆ei + ∆ej j=i+1

Dies entspricht der priorit¨ atsbasierten Prozessausf¨ uhrung, bei der alle h¨oher priorisierten Prozesse zum kritischen Zeitpunkt j mindestens einmal vor Pro(0) ucksichtigt nicht, dass zess i ausgef¨ uhrt werden. Die Kalkulation von ∆ai ber¨ in dieser Zeitspanne h¨ oher priorisierte Prozesse mehrfach bereit werden und damit Prozess i noch weiter nach hinten verdr¨angen. Dies dr¨ uckt sich erst

3.3

Planen bei statischen Priorit¨ aten

197

durch folgende Rekursionsformel aus: (k+1) ∆ai

= ∆ei +



n j=i+1

(k)

∆ai ∆pj

 ∆ej

Offensichtlich sind die so berechneten Antwortzeiten monoton wachsend. (k) Wird ein Wert ∆ai > ∆pi erreicht, so ist es nach Satz 3.3.1 unm¨oglich, Prozess i brauchbar einzuplanen. Gibt es jedoch ein k derart, dass die Antwortzeiten gegen einen Wert ∆ai konvergieren, (k+1)

∆ai = ∆ai

(k)

= ∆ai

dann endet die Ausf¨ uhrung von Prozess i und aller h¨oher priorisierten Prozesse vor seiner Periode ∆pi . Damit ist im Sinne des Planens nach monotonen Raten die Brauchbarkeit nachgewiesen. Im Gegensatz dazu ist beim Planen nach monotonen Fristen nicht die Periode, sondern die relative Frist entscheidend. Somit kann ein Prozess i genau dann brauchbar eingeplant werden, wenn gilt: ∆ai ≤ ∆di Weil der Bedarf an Ausf¨ uhrungszeit f¨ ur alle Prozesse j ≥ i gesichert ist, heißt dieser Test auch response time test oder kurz RT-Test. Beispiel 3.3.7 In Fortsetzung von Beispiel 3.3.6 m¨ oge noch ein weiterer Prozess vorhanden sein, der mit einer Frequenz von 40Hz den Controller der Motoren bedienen muss und unbedingte Synchronit¨at wahren soll. Dieser Prozess mit dem Index 5 erh¨ alt deshalb die k¨ urzeste Frist von 10.

Transformation Controller

P 5

∆e 2

∆d 10

∆p 25

Schritt f¨ ur Schritt werden nun die maximalen Antwortzeiten aller Prozesse ermittelt. Sp¨ atestens nach zwei Schritten ist f¨ ur alle Prozesse Konvergenz erreicht und keine der Fristen wird verletzt. Transformation Controller Erkennung Aggregation Steuerfunktion Motorsteuerung

P 5 4 3 2 1

∆e 2 15 2 3 15

∆d 10 20 25 30 40

∆p 25 40 40 40 40

∆a(0) 2 17 19 22 37

∆a(1) 2 17 19 22 39

∆a(2) 2 17 19 22 39


3.3.7

198

3. Grundlegende Planungsverfahren

Es ist jedoch nicht unbedingt n¨ otig, nach der obigen Rekursionsformel die Brauchbarkeit einer Prozessmenge zu pr¨ ufen. Ebenso notwendig wie hinreichend ist der Test, der f¨ ur jeden Prozess i ∈ P explizit pr¨ uft, ob er nicht uhrungen beendet hat. sp¨ atestens bis zu seiner relativen Frist ∆di alle Ausf¨ Dazu sind alle m¨ oglichen Verdr¨ angungen durch h¨oher priorisierte Prozesse ucksichtigen. im Intervall ∆di zu ber¨ ! n ∆di ∆ei + ∆ej ≤ ∆di ∆pj j=i+1 Eine Prozessmenge P ist genau dann nach monotonen Fristen brauchbar verplanbar, wenn jeder Prozess i ∈ P die Forderung aus der obigen Formel erf¨ ullt. Dies ist der deadline monotonic test oder kurz DM-Test. Er setzt voraus, dass die relativen Fristen der einzelnen Prozesse bereits bekannt sind. Dies ist beim RT-Test anders. Dort wird mit der maximalen Antwortzeit ein Extremwert f¨ ur den Bedarf an Ausf¨ uhrungszeit ermittelt, der unabh¨angig von Fristen ist. Besteht beim Entwurf eines Echtzeitsystems noch die Freiheit Fristen festzulegen, dann gen¨ ugt es, diese auf die errechneten Werte f¨ ur die maximale Antwortzeit festzusetzen. In diesem Sinne ist der RT-Test weitergehend als der DM-Test. 3.3.8

Beispiel 3.3.8 Mit Bezug auf Beispiel 3.3.7 kann man u ufen, ob die er¨berpr¨ rechneten maximalen Antwortzeiten aus dem RT-Test tats¨achlich gen¨ ugen, um einen Prozess im Sinne des DM-Tests brauchbar einzuplanen. Zur Demonstration wird der Prozess 2 herangezogen. Seine maximale Antwortzeit liegt bei 22 Zeiteinheiten, die als relative Frist festgesetzt wird:

∆d2 = 22 Nach dem DM-Test wird die G¨ ultigkeit der folgenden Ungleichung gepr¨ uft: ! ! ! ∆d2 ∆d2 ∆d2 ∆e5 + ∆e4 + ∆e3 ≤ ∆d2 ∆e2 + ∆p5 ∆p4 ∆p3 Eingesetzt ergibt sich die G¨ ultigkeit der Ungleichung: 3 + 2 + 15 + 2 ≤ 22
Ein Spezialfall des DM-Tests ist der rate monotonic test oder kurz RM-Test. Dabei sind die Fristen identisch mit den Perioden, was zur Ersetzung aller uhrt. In Anlehnung an die urspr¨ ungliche Formel zur Rechtzei∆di durch ∆pi f¨

3.3

Planen bei statischen Priorit¨ aten

199

tigkeit (siehe Seite 5) ist der RM-Test f¨ ur einen Prozess i ∈ P so formuliert: ! n ∆pi ri + ∆ei + ∆ej ≤ di ∆pj j=i+1

200

3.4

3. Grundlegende Planungsverfahren

3.4 Zyklische Planungsverfahren In diesem Abschnitt wird ein Planungsverfahren vorgestellt, das einfach und ohne Unterst¨ utzung durch eine Infrastruktur auskommt. Dazu wird zun¨achst ein Programmschema vorgestellt (siehe Unterabschnitt 3.4.1). Danach werden die Feiheitsgrade des Planungsverfahrens er¨ortert (siehe Unterabschnitt 3.4.2), um schließlich eine Bewertung des Ansatzes vorzunehmen (siehe Unterabschnitt 3.4.3). 3.4.1 Struktur der Prozessausf¨ uhrung

Eines der ersten Progammschemata, die in der Echtzeitprogrmmierung zum Einsatz kamen, basiert auf dem zyklischen Planungsverfahren (engl. cyclic scheduling). Seine Anziehungskraft, die trotz aller Kritik bis heute besteht, verdankt es wesentlich seinem klaren Programmaufbau. Dieser besteht aus einer zyklischen Prozessausf¨ uhrung (engl. cyclic executive), die einen expliziten Plan abarbeitet. Geeignet ist das Verfahren f¨ ur eine Menge P = {1, ..., n} periodischer Prozesse, die bei der Prozessausf¨ uhrung nicht unterbrochen werden. Der Prozessausf¨ uhrung liegt ein brauchbarer Plan zugrunde, der sich sp¨ atestens nach ∆mjct = kgV (∆p1 , ..., ∆pn ) wiederholt, was als ¨ außerer Zyklus (engl. major cycle) bezeichnet wird. Ein solcher Plan wird jedoch nicht am St¨ uck ausgef¨ uhrt. Vielmehr wird er in innere Zyklen (engl. minor cycle) zerlegt, die zeitgesteuert nacheinander aus¨ gef¨ uhrt werden und auf diese Weise eine zeitnahe Uberwachung der Prozesse ¨ erlauben. Ublicherweise daueren alle inneren Zyklen gleich lang und teilen die Zeitspanne f¨ ur den ¨ außeren Zyklus: rnd ∆mict = ∆mjct

rnd ∈ N

Dabei steht rnd f¨ ur die Zahl der Runden an inneren Zyklen, die einen ¨außeren Zyklus bilden. Das nachfolgende Programmschema arbeitet die rnd inneren Zyklen ab und pr¨ uft im Anschluss an jede Runde, ob es eine Fristverletzung (engl. time overrun) gegeben hat. cnt=0; t=gettime(); while (TRUE){ wait_until(t); case (cnt) { :

3.4

Zyklische Planungsverfahren

201

j: "execute minor cycle cnt" : } cnt=cnt(cnt+1)%rnd; t=t+dmict; if(gettime()>t) "handle time overrun" } Beispiel 3.4.1 Gegeben sei die Prozessmenge P = {1, 2, 3} mit den folgenden Ausf¨ uhrungszeiten und Perioden:

P 1 2 3

∆e 1 1 2

∆p 3 6 9

Der ¨ außere Zyklus ist ∆mjct = 18 Zeiteinheiten lang und der innere wird willk¨ urlich auf ∆mict = 3 Zeiteinheiten festgelegt. So l¨asst sich der folgende Plan entwickeln: 



































Dieser Plan wird unmittelbar in das folgende Programm mit rnd = 6 inneren Zyklen u uhrt: ¨berf¨ cnt=0; t=gettime(); while (TRUE){ wait_until(t); case (cnt) { 0: P1;P2; 1: P1;P3; 2: P1;P2; 3: P1;P3; 4: P1;P2; 5: P1; } cnt=cnt(cnt+1)%rnd; t=t+dmict; if(gettime()>t) "handle time overrun" }


3.4.1

202

3. Grundlegende Planungsverfahren

3.4.2 Freiheitsgrade beim zyklischen Planungsverfahren

Bei dem einfachen Aufbau der Programme f¨ ur das zyklische Planungverfahren gibt es lediglich zwei Freiheitsgrade, die festzulegen sind: die Zeitspanne ∆mict f¨ ur alle inneren Zyklen und der Plan, der in jedem inneren Zyklus ablaufen soll. Geht man allgemein davon aus, dass ein Prozess i mit den Paramentern ∆pi , ∆ei und ∆di , mit ∆di ≤ ∆pi , gegeben ist, dann wird vorgeschlagen, die Zeitspanne ∆mict in folgender Weise zu bestimmen (vgl. [13] und [118]): 1. 2. 3. 4.

∆mict ≤ ∆di i ∈ {1, ..., n} i ∈ {1, ..., n} ∆mict ≥ ∆ei rnd ∆mict = ∆mjct rnd ∈ N 2 ∆mict − ggT (∆pi , ∆mict) ≤ ∆di

i ∈ {1, ..., n}

Alle Forderungen bis auf die letzte sind trivial. Forderung 4. besagt, dass ein innerer Zyklus unbedingt in die Zeitspanne einer relativen Frist ∆di passen muss. Beginnt der Plan zu einem Zeitpunkt, zu dem alle Bereitzeiten zusammenfallen, so sind alle ∆mict/ggT (∆pi , ∆mict) m¨oglichen Phasenverschiebungen f¨ ur den Beginn einer Periode in einem inneren Zyklus zu ber¨ ucksichtigen. Eine solche Phasenverschiebung ist die, bei der die Peater als der innere Zyklus beginnt riode ggT (∆pi , ∆mict) Zeiteinheiten sp¨ (siehe Abb. 3.13). Diese Situation stellt die ung¨ unstigte dar, unter der ein vollst¨ andiger innerer Zyklus sp¨ atestens mit der relativen Frist endet. F¨ ur einen brauchbaren Plan ist es hinreichend, eine Ausf¨ uhrungszeit ∆ei in den ersten inneren Zyklus zu legen, der sich nicht mit dem Beginn einer Periode schneidet.












  Abb. 3.13. Die relative Frist ∆di sollte so groß sein, dass der nachfolgende innere Zyklus

noch hinein passt.

Aber auch Forderung 2. kann Probleme bereiten, wenn die Ausf¨ uhrungszeiten einzelner Prozesse gr¨ oßer sind als die Zeitdauer des inneren Zyklus. Damit das zyklische Planungsverfahren nicht versagt, bietet sich die Zerlegung der

3.4

Zyklische Planungsverfahren

203

Prozesse in kleinere, hintereinander ausf¨ uhrbare Abschnitte an. Typische Abschnitte leiten sich aus den Stukturen der Programme ab und bestehen beispielsweise aus Unterprogrammaufrufen. So wird ein Prozess Pi in die sequenziellen Abschnitte Pi (A), Pi (B), ... zerlegt. Beispiel 3.4.2 Als Fortsetzung von Beispiel 3.4.1 sei angenommen, dass Prozess 3 anstelle von 2 Zeiteinheiten die Ausf¨ uhrungszeit von 4 Zeiteinheiten ben¨ otigt. Bei einem inneren Zyklus der Dauer von ∆mict = 3 Zeiteinheiten ist Prozess 3 nicht ohne Fristverletzung ausf¨ uhrbar. L¨asst sich jedoch die Ausf¨ uhrung von Prozess 3 in die Abschnitte

∆e3 (A) = 1 ∆e3 (B) = 2 ∆e3 (C) = 1 aufteilen, dann gibt es einen brauchbaren Plan: 




































Entsprechend dazu ist folgendes Programm auszuf¨ uhren: cnt=0; t=gettime(); while (TRUE){ wait_until(t); case (cnt) { 0: P1;P2;P3A; 1: P1;P3B; 2: P1;P2;P3C; 3: P1;P3A; 4: P1;P2;P3B; 5: P1;P3C; } cnt=cnt(cnt+1)%rnd; t=t+dmict; if(gettime()>t) "handle time overrun" }


3.4.2

204

3.4.1

3. Grundlegende Planungsverfahren

Aufgabe 3.4.1 (siehe Seite 294) Pr¨ ufen Sie, ob sich ¨ahnlich wie in Beispiel 3.4.2 ein brauchbarer Plan ergibt, wenn nur folgende Abschnitte f¨ ur den Prozess 3 m¨ oglich sind:

∆e3 (A) = 2 ∆e3 (B) = 2
3.4.3 Bewertung des Ansatzes

Wie an den Beispielen deutlich wird, kann das Einplanen von nicht unterbrechbaren Prozessen oder nicht unterbrechbaren Abschnitten von Prozessen sehr aufw¨ andig sein. Die Ergebnisse von Unterabschnitt 3.1.2 sind unmittelbar anwendbar und besagen, dass das Planungsverfahren NP-vollst¨andig ist. In der Praxis wird deshalb eher mit suboptimalen Planungsverfahren gearbeitet, vorrangig mit EDF (vgl. [13]) oder mit auf EDF aufbauenden Verfahren (vgl. [92]). Neben den Planungseigenschaften spielen weitere Kriterien bei der Bewertung der zyklischen Prozessausf¨ uhrung eine Rolle. Unter anderen spricht folgendes f¨ ur den Ansatz: Das Planungsverfahren ist statisch und erzeugt einen expliziten Plan. Die Prozessausf¨ uhrung ist gekennzeichnet durch einen hohen Grad an Determinismus, der darin besteht, dass der Zeitpunkt des Beginns eines inneren Zyklus und die Folge der darin abgearbeiteten Prozesse feststeht. Das einzig m¨ ogliche Flattern passiert innerhalb eines inneren Zyklus und wird durch die im einzelnen unterschiedlich lange dauernden Prozessausf¨ uhrungen verursacht. Das Programm kann ohne Betriebssystem ausgef¨ uhrt werden und eignet sich deshalb insbesondere f¨ ur einfache Anwendungen mit beschr¨ankten Betriebsmitteln. Lediglich das Anstoßen der inneren Zyklen zum richtigen Zeitpunkt muss gew¨ ahrleistet sein. Es gibt keine unvorhersehbaren Prozessumschaltungen. Die Ausf¨ uhrung von Prozessen oder Abschnitten von Prozessen wird f¨ ur die Dauer eines inneren Zyklus nicht unterbrochen. Damit hat ein Prozess immer auch exklusiven Zugriff auf Betriebsmittel, was die Programmierung deutlich erleichtert. Die zyklische Prozessausf¨ uhrung eignet sich f¨ ur Kommunikation u ¨ber Netzwerke, die zeitgesteuerte Zugriffsprotokolle (siehe ZeitmultiplexVerfahren auf Seite 146) benutzen. Die Prozesse sind derart phasenverschoben auszuf¨ uhren, dass das Versenden und Empfangen von Rahmen synchron zu den Zeitvorgaben der Protokolle erfolgt (vgl. [106]).

3.4

Zyklische Planungsverfahren

205

Leider besitzt die zyklische Prozessausf¨ uhrung auch eine Reihe von zum Teil schwerwiegenden Nachteilen: Die zyklische Prozessausf¨ uhrung ist nicht robust hinsichlich von ¨ ¨ Anderungen der Prozessparameter, die sich durch die Uberarbeitungen von Programmen oder aufgrund unterschiedlicher Programmvarianten ergeben. Kleine Abweichungen k¨ onnen zu v¨ollig unterschiedlichen Pl¨anen ¨ f¨ uhren und eine aufw¨ andige Uberpr¨ ufung der Brauchbarkeit erfordern. Um das Auffinden brauchbarer Pl¨ ane zu erleichtern, ist eine Zerlegung der Prozesse in Abschnitte vorteilhaft. Dies erfordert jedoch eine tiefgehende Kenntnis der zugrunde liegenden Programmstruktur. Prinzipiell ließen sich ¨ ahnliche Methoden, wie sie bei der Absch¨atzung der Ausf¨ uhrungszeit benutzt werden (siehe Seite 93), zur Anwendung bringen. Im praktischen Einsatz des Planungsverfahrens ist heute immer noch die manuelle Zerlegung die Regel. Die Integration von sporadischen Ereignissen und deren Verarbeitung ist schwierig. Dazu z¨ ahlt insbesondere die Behandlung von Unterbrechungsanforderungen. Die einfachste Art, um dieses Problem zu umgehen, ist die Anwendung des Anfrage- oder Polling-Prinzip, also die programmgesteuerte Anfrage des Ger¨ atezustandes. Zusammenfassend ist festzuhalten, dass die zyklische Planung f¨ ur kleinere Anwendungen und die Entwicklung prototypischer L¨osungen nach wie vor attraktiv ist. F¨ ur gr¨ oßere Anwendungen, die einer fortlaufenden Weiterentwicklung unterliegen, fehlen geeignete Methoden und Werkzeuge. Dennoch wird der verst¨ arkte Einsatz von Netzwerken mit zeitgesteuerten Zugriffsprotokollen diesen Ansatz befl¨ ugeln und seine Weiterentwicklung vorantreiben.

206

3.5

3. Grundlegende Planungsverfahren

3.5 Vergleich der Planungsverfahren In den vorangegangenen Abschnitten wurden im Wesentlichen drei Planungsverfahren f¨ ur nicht unterbrechbare Prozesse vorgestellt: EDF-Planungsverfahren (siehe Unterabschnitt 3.2.2) LLF-Planungsverfahren (siehe Unterabschnitt 3.2.5) Zyklisches Planungsverfahren (siehe Abschnitt 3.4) Alle diese Verfahren liefern grundlegende Erkenntnisse, die bei der Bewertung und Entwicklung von Echtzeitanwendungen praktische Relevanz gewinnen. Dennoch herrscht f¨ ur nicht unterbrechbare Prozesse ein Mangel an ausgereiften Methoden und es fehlt weitgehend an programmiertechnischer Unterst¨ utzung durch Betriebssysteme oder Laufzeitsysteme. Deutlich weiter fortgeschritten, sowohl was den wissenschaftlichen Hintergrund als auch die ingenieurm¨ aßige Handhabung betrifft, sind diejenigen Planungsverfahren, die unterbrechbare Prozesse, insbesondere periodische unterbrechbare Prozesse, zum Gegenstand haben. Im Kontext dieser Klasse von Prozessen sind zwei herausragende Ans¨ atze zu nennen, die sich aufgrund ihres Umgangs mit den Priorit¨ aten von Prozessen unterscheiden und stellvertretend durch ein herausragendes Planungsverfahren einzuordnen sind: EDF als Vertreter der Planungsverfahren mit dynamischen Priorit¨aten (siehe Abschnitt 3.2) RMS als Vertreter der Planungsverfahren mit statischen Priorit¨aten (siehe Abschnitt 3.3) Ihrem Stellvertreter-Charakter entsprechend werden diese beiden Verfahren im Folgenden unter Gesichtspunkten, wie der Auslastung (siehe Unterabschnitt 3.5.1), der Implementierung (siehe Unterabschnitt 3.5.2), der Unterbrechungsbehandlung (siehe Unterabschnitt 3.5.3) und der Fristverletzung (siehe Unterabschnitt 3.5.4) diskutiert und gegen¨ ubergestellt. Dazu steuert die Gegen¨ uberstellung von Buttazzo (vgl. [25]) einiges an Inhalten bei, ohne jedoch als alleinige Quelle zu dienen. 3.5.1 Auslastung

Als zentrales Vergleichskriterium wird u ¨blicherweise die Auslastung herangezogen. Bei einer Prozessmenge P unterbrechbarer periodischer Prozesse sind die Perioden und die Ausf¨ uhrungszeiten die maßgeblichen Prozessparameter, die gegebenenfalls m¨ uhsam (siehe Unterabschnitte 2.3.1 und 2.3.2) beschafft werden m¨ ussen. Gefragt wird bei einer gegebenen Auslastung U , ob diese Kenntnis bereits ausreicht, um eine Aussage u ¨ber die Brauchbarkeit der Prozessmenge zu gewinnen.

3.5

Vergleich der Planungsverfahren

207

Bei den Planungsverfahren wurde nach einer niedrigsten Auslastung Umin gesucht, zu der zwar noch ein brauchbarer Plan existiert, bei der jedoch schon die geringste Erh¨ ohung von Ausf¨ uhrungszeiten zu einer Fristverletzung f¨ uhrt. (n) = 1 eine konstante Funktion, w¨ a hrend F¨ ur n Prozesse ist bei EDF U min √ bei RMS Umin (n) = n( n 2 − 1) eine mit n monoton fallende Funktion ist, die gegen ln(2) konvergiert (siehe Abb. 3.14).

Abb. 3.14. Die Schanken der Auslastung U bei RMS und EDF, zu denen eine Menge von n

Prozessen immer brauchbar verplant werden kann.

Somit kann beim Planen nach monotonen Raten bis zu 31% der Prozessorleistung ungenutzt bleiben. Ist f¨ ur eine Prozessmenge keine Brauchbarkeit gegeben, dann muss nach Auswegen gesucht werden. Die als Sensitivit¨atsanalyse bezeichnete Forschungsrichtung versucht, die Prozessparameter zu erkennen, die einen herausragenden Anteil an der Fristverletzung haben, und fragt, welche Maßnahmen hinreichend sind, um die Brauchbarkeit wiederherstellen zu k¨ onnen. In der Fachliteratur werden dabei besonders die Ausf¨ uhrungszeiten (vgl. [136], [108] und [14]) und weniger die Perioden der Prozesse in Betracht gezogen. (vgl. [149]). 3.5.2 Implementierung

Bei Echtzeitsystemen setzt die Prozessausf¨ uhrung in der u ¨berwiegenden Zahl auf einem Betriebssystem oder Laufzeitsystem auf. In der großen Mehrheit stellen diese jedoch nur M¨ oglichkeiten bereit, Prozessen feste Priorit¨aten

208

3. Grundlegende Planungsverfahren

zuzuordnen und so auf unmittelbare Weise die priorit¨atsbasierte Prozessausf¨ uhrung zu erm¨ oglichen. Damit l¨ asst sich das Planen nach festen Priorit¨ aten und speziell das Planen nach monotonen Raten (RMS) unmittelbar realisieren. Im Gegensatz dazu unterst¨ utzen nur ganz wenige Betriebssysteme oder Laufzeitsysteme das Planen nach Fristen (EDF). Dabei ist, im Gegensatz zu der vorherrschenden Meinung, die Implementierung dynamischer Priorit¨aten nicht wesentlich aufw¨ andiger als die f¨ ur statische Priorit¨aten. Betrachtet man die notwendigen Schritte bei der Prozessorzuteilung (engl. dispatching) genauer, so l¨ asst sich RMS und EDF in v¨ ollig analoger Weise in den folgenden Schritten abwickeln: Nach jeweils ∆tG Zeiteinheiten wird die Prozessorzuteilung aktiviert. Diese pr¨ uft, ob in der aktuellen Zeile j des Zeitrades (siehe Seite 84) Prozesse zum Wecken eingetragen sind. Jeder dieser Prozesse war bislang vor¨ ubergehend beendet und ist nun in den Zustand rechenbereit zu versetzen. RMS und EDF unterscheiden sich bez¨ uglich des Kriteriums, nach dem die Menge der rechenbereiten Prozesse zu ordnen ist. Bei RMS ist es die maximale Priorit¨ at und bei EDF die minimale Frist. F¨ ur beide F¨alle bietet sich der Haufen (siehe Seite 84) als effiziente Datenstrukturen, die sowohl das Einordnen als auch das Entnehmen mit einem Aufwand O(ln(k)), mit k der Anzahl der rechnerbereiten Prozesse, erledigt. Im letzten Schritt ist, unabh¨ angig von RMS oder EDF, der jeweils oberste Prozess im Haufen in den Zustand rechnend zu versetzen. Endet ein Prozess, so wechselt er wieder in den Zustand vor¨ ubergehend beendet und seine n¨ achste Weckzeit berechnet sich so: tw = (tw + ∆pi )%wmax Entsprechend ist dieser Prozess in der Zeile tw des Zeitrades einzutragen. 3.5.3 Unterbrechungsbehandlung

Unterbrechungsanforderungen (engl. interrupt) sind in den klar strukturierten Modellen, die den Planungsverfahren zugrunde liegen, nicht vorgesehen. Dennoch darf ihr Einfluss nicht vernachl¨assigt werden, weil die Auswirkungen der Unterbrechungsbehandlung vielf¨altig sind und unter quantitativen Gesichtspunkten unbedingt zu bedenken sind: Es ist oft schwierig, eine Aussage u ¨ber die zeitliche Verteilung von Unterbrechungsanforderungen zu erhalten. Grunds¨atzlich gibt es periodische und aperiodische Unterbrechungsanforderungen. Gerade die ereignisgesteuerte Prozessausf¨ uhrung erhebt die Unterbrechungsbehandlung dazu,

3.5

Vergleich der Planungsverfahren

209

einen Prozess in den Zustand rechenbereit zu versetzen und suggeriert auf diese Weise die jederzeitige Bereitschaft, Prozessorleistung zur Verf¨ ugung zu stellen. Die Unterbrechungsanforderung kann abh¨ angig vom vorliegenden Ereignis oder Zustand unterschiedlich lange dauern. Beispielsweise hat die Prozessorzuteilung, die alle ∆tG Zeiteinheiten aufgerufen wird, meist keine oder nur wenige Prozesse zu wecken. Beim kritischen Zeitpunkt sind jedoch alle n Prozesse zu wecken, was einen deutlich h¨oheren Aufwand nach sich zieht. Die Unterbrechungsbehandlung beeinflusst die Ausf¨ uhrungszeit des unterbrochenen Prozesses. Verantwortlich daf¨ ur ist die Hardware des Rechensystems, besonders die Einfl¨ usse durch das Pipelining des Prozessors und die Speicherhierarchie. Bei letzterem spielen die Cache-Speicher eine bedeutende Rolle, weil sie am Ende der Unterbrechungsbehandlung andere Inhalte haben als vorher. In der Regel verl¨angern sich durch eine Unterbrechung die Zugriffszeiten des unterbrochenen Prozesses. Pragmatik ist angesagt, um den skizzierten Problemen zu begegnen. Will man die Eigenschaft der Vorhersagbarkeit erhalten, dann ist es unabdingbar, gewisse Forderungen an die Unterbrechungsbehandlung zu stellen. Eine essenzielle lautet, dass die zeitlichen Abst¨ ande zwischen zwei aufeinanderfolgenden Unterbrechungsanforderungen nach unten begrenzt sein m¨ ussen. Diese Forderung ist ¨ ahnlich der f¨ ur sporadische Prozesse. Des Weiteren ist die Unterbrechungsbehandlung so kurz wie m¨oglich zu halten. Insbesondere ist eine eindeutige Begrenzung der Ausf¨ uhrungszeit nachzuweisen. Damit sind bereits einige Voraussetzungen erf¨ ullt, um die Unterbrechungsbehandlung in diejenigen Modelle zu integrieren, die den Planungsverfahren zugrunde liegen. Aufgrund der Priorit¨aten, die bei der Unterbrechungsbehandlung durch den Prozessor oder periphere Bausteine unterst¨ utzt werden, eignen sich bevorzugt Planungsverfahren mit statischen Priorit¨aten, wie beispielsweise RMS. Die h¨ aufigste Unterbrechungsanforderung geht typischerweise von einem Uhrbaustein aus und betrifft die Prozessorzuteilung, die in der Regel alle ∆tG Zeiteinheiten aufgerufen wird. Sie l¨ asst sich leicht als Prozess hoher oder h¨ ochster Priorit¨ at modellieren. Da jedoch nicht jede Prozessorzuteilung eine Prozessumschaltung bewirkt und letztere deutlich mehr Ausf¨ uhrungszeit ben¨ otigt, stellt sich die Frage, wie diese am g¨ unstigsten modelliert werden kann. So gibt es den Vorschlag, allen Prozessen außer dem h¨ochst priorisierur eine Prozessumschaltung zur eigentliten, zweimal die Zeitspanne ∆tps f¨ chen Ausf¨ uhrungszeit hinzuzurechnen (vgl. [68]). Zus¨atzlich zur Zeitspanne

210

3. Grundlegende Planungsverfahren

∆tps lassen sich noch diejenigen Zeiten hinzurechnen, die durch die Hardware des Rechensystems verursacht werden. Die gesamte Argumentation macht deutlich, dass die Prozessumschaltungen einen besonderen Stellenwert bei der Erhaltung der Vorhersagbarkeit besitzen. So wird insbesondere die Frage nach der Anzahl der Prozessumschaltungen relevant. Diese ist bei RMS f¨ ur eine Ausf¨ uhrung des Prozesses mit der Priorit¨ at i beschr¨ ankt durch: ! n ∆pi 2 ∆pj j=i+1 Bei EDF liegt die Schranke bei: 2

j∈P \{i}

∆pi ∆pj

!

Die beiden Schranken leiten sich aus Extrembeispielen ab, die nicht auf u ¨bliche Prozessmengen zutreffen. Simulationen mit zuf¨allig gew¨ahlten Prozessmengen zeigen (vgl. [25]), dass sich RMS und EDF bezogen auf die mittlere Anzahl von Prozessumschaltungen v¨ollig unterschiedlich verhalten. Zun¨ achst ben¨ otigt EDF tendenziell weniger Umschaltungen als RMS. Hinzu kommt, dass die Anzahl der Umschaltungen bei RMS mit steigender Auslastung ebenfalls steigt, w¨ ahrend sie bei EDF ab einer Auslastung zwischen 80% und 90% wieder zu fallen beginnt. Dies geht einher mit der Beobachtung, dass bei EDF die Verl¨ angerung einer Ausf¨ uhrungszeit ein Sinken der Anzahl der Prozessumschaltungen bewirken kann. 3.5.4 Fristverletzung

Die Ausf¨ uhrungszeit ∆ei eines Prozesses i stellt eine obere Schranke f¨ ur die Zeitspanne dar, die bei der j-ten Ausf¨ uhrung des Prozesses tats¨achlich aufgenommen werden darf: ∆eji ≤ ∆ei Wurde die Brauchbarkeit der Prozessmenge festgestellt, dann ist f¨ ur viele, die sich mit Echtzeitplanung befassen, das Problem gel¨ost. Hierzu bemerken Stewart und Khosla (vgl. [127]): High-assurance software systems are implemented with the dangerous assumption that timing errors will never occur. So kann es zu einer Fristverletzung kommen, wenn die Ausf¨ uhrung eines Prozesses fehlerhafterweise l¨ anger dauert als erwartet: ∆eji > ∆ei

3.5

Vergleich der Planungsverfahren

211

Diese Bedingung ist notwendig aber nicht hinreichend f¨ ur eine Fristverletzung, da es meist noch Spielr¨ aume gibt und andere Prozesse die ihnen zur Verf¨ ugung stehende Ausf¨ uhrungszeit nicht voll ausnutzen. Fristverletzungen wirken sich bei EDF und RMS v¨ollig unterschiedlich aus. So bemerkt bei RMS ein Prozess i nichts von den Fristverletzungen eines Prozesses j niedrigerer Priorit¨ at. Ein Prozess i > j wird deshalb seine Frist einhalten. Dies ist bei EDF v¨ ollig anders. Ein Prozess i wird seine gegebenfalls zu lange Ausf¨ uhrungszeit ∆eji erhalten, sofern seine Frist die n¨achstliegende ist. Er wird damit alle anderen rechenbereiten Prozesse verdr¨angen, so dass auch jene m¨ oglicherweise ihre Fristen verletzen werden. Von Interesse ist die Frage, wie und wann eine Fristverletzung erkannt werden kann. Grunds¨ atzlich gibt es zwei Ebenen, auf denen eine Erkennung stattfinden kann: Die Ebene der Betriebssysteme und Laufzeitsysteme, auf der die Prozes¨ sorzuteilung eine Uberwachungsfunktion aus¨ uben kann. Die Ebene der Anwendungsprozesse, die eine Selbstkontrolle aus¨ uben. Betrachtet man letztere Alternative, so kann ein periodischer Prozess durch wenige zus¨ atzliche Instrumentierungsoperationen feststellen, ob er rechtzeitig vor der Frist fertig geworden ist. Das Programmfragment f¨ ur periodische Prozesse (siehe Seite 48) ist folgendermaßen zu erweitern: P(i):: while(TRUE) { wait_until(t); : t=t+periode(i); now=gettime(); if(t<now){ // Behandlung der Fristverletzung } } Auf diese Weise wird eine Fristverletzung im Nachhinein erkannt. Dieser Zeitpunkt h¨ angt von der fehlerhaften Ausf¨ uhrungszeit ∆eji ab und ist nicht zeitnah zur Frist, die u ¨berschritten wurde. Deshalb eignet sich diese Instrumentierung bestenfalls f¨ ur die fr¨ uhen Phasen der Anwendungsentwicklung, nicht jedoch f¨ ur den Betrieb eines Echtzeitsystems. Auf die Verletzung harter Zeitbedingungen muss zeitnah reagiert werden k¨ onnen, d.h. unmittelbar zum Zeitpunkt der Verletzung. Eine L¨osung, die in dem experimentellen Betriebssystem Chimera (vgl. [127]) implementiert

212

3. Grundlegende Planungsverfahren

wurde, delegiert die Erkennung der Fristverletzung an die Prozessorzuteilung. Dort wird jeder Ausf¨ uhrung eines Prozesses ein Z¨ahler zugeordnet, der mit der Ausf¨ uhrungszeit ∆ei initialisiert wird und bei jeder Unterbrechung durch die Uhr heruntergez¨ ahlt wird. Sollte die Zeit verbraucht sein, dann ist gerade die Frist u berschritten worden und sofort k¨onnen Maßnahmen zur Be¨ handlung der Fristverletzung ergriffen werden. Die Behandlung selbst wird dabei jedoch nicht vom Betriebssystem u ¨bernommen, sondern an benutzerspezifische Funktionen delegiert.

Kapitel 4 Fortgeschrittene Planungsverfahren

4

4

4 4.1 4.1.1 4.1.2 4.1.3 4.2 4.2.1 4.2.2 4.2.3 4.3 4.3.1 4.3.2 4.3.3 4.3.4

Fortgeschrittene Planungsverfahren Planung synchronisierter Prozesse ............................ Priorit¨atsumkehr ................................................. Priorit¨atsvererbung .............................................. Priorit¨atsobergrenzen ........................................... Planung bei Mehrprozessorsystemen ......................... Planungsverfahren abh¨angig von der Migration der Prozessen .............................................................. Optimalit¨at proportional fairer Planungsverfahren ........ Arbeitsweise proportional fairer Planungsverfahren ....... Planung in verteilten Systemen ............................... Kriterien der Vergleichbarkeit von Zugriffsprotokollen .... Zeitgesteuerte Zugriffsprotokolle .............................. Arbitrierende Zugriffsprotokolle ............................... Markengesteuerte Zugriffsprotokolle .........................

215 215 219 227 233 233 236 244 250 250 253 254 262

4 Fortgeschrittene Planungsverfahren In diesem Kapitel werden Planungsstrategien und -verfahren vorgestellt, die teilweise auf den Grundlagen der Planung (siehe Kapitel 3) aufbauen, zus¨ atzlich jedoch durch verschiedene Anwendungskontexte beeinflusst sind. Im Einzelnen handelt es sich um die Planung bei Prozessen, die Synchronisierungsoperationen verwenden (siehe Abschnitt 4.1), die auf Mehrprozessorsystemen ausgef¨ uhrt werden (siehe Abschnitt 4.2) und in verteilten Systemen u ber Rechnernetze miteinander kommunizieren (siehe Abschnitt 4.3). ¨

4.1 Planung synchronisierter Prozesse W¨ ahrend im vorangegangenen Kapitel 3 ein Prozessmodell zugrundegelegt wurde, bei dem Prozesse unabh¨ angig voneinander ausgef¨ uhrt werden, befasst sich dieser Abschnitt damit, wie die Beziehungen, die durch die Synchronisierungsoperationen (siehe Abschnitt 2.4) entstehen, systematisch Eingang in die Planung finden. Dabei tritt zun¨ achst zutage, dass das Aufeinandertreffen von priorit¨ atsbasierter Prozessausf¨ uhrung und konsistenzerhaltender Synchronisierung zu dem unerw¨ unschten Ph¨ anomen der Priorit¨atsumkehr (siehe Unterabschnitt 4.1.1) f¨ uhrt. Zwei protokollartig strukturierte Methoden begegnen der Priorit¨ atsumkehr in unterschiedlicher Weise, eines bekannt als Protokoll der Priorit¨ atsvererbung (siehe Unterabschnitt 4.1.2) und ein weiteres als Protokoll der Priorit¨ atsobergrenze (siehe Unterabschnitt 4.1.3). 4.1.1 Priorit¨ atsumkehr

Zur Erhaltung der Konsistenz der Daten in parallelen Programmen spielen kritische Gebiete eine herausragende Rolle. Die einfachsten Synchronisierungsoperationen, die solche Gebiete kennzeichnen und sperren, werden im Folgenden zugrunde gelegt: enter(s): Betreten des kritischen Gebietes css leave(s): Verlassen des kritischen Gebietes css Dabei sei CS die Menge der kritischen Gebiete, auf die die Prozessmenge P Zugriff hat. Setzt man ein Prozessmodell mit periodischen unterbrechbaren Prozessen voraus, die statische Priorit¨ aten besitzen, und wendet die priorit¨ atsbasierte Prozessausf¨ uhrung an, so wird einerseits erwartet, dass die Priorit¨ at entscheidend f¨ ur die Vergabe des Prozessors ist. Andererseits soll ein Prozess unabh¨ angig von seiner Priorit¨ at sein kritisches Gebiet abarbeiten k¨ onnen, w¨ ahrend andere Prozesse solange blockiert werden. Die beiden Sichtweisen stehen im Konflikt miteinander.

4.1

216

4.1.1

4. Fortgeschrittene Planungsverfahren

Beispiel 4.1.1 Ein Prozess l ∈ P mit niedriger Priorit¨ at wird bereit und

beginnt seine Ausf¨ uhrung. Er fordert mit enter(s) das kritische Gebiet css ∈ CS an und darf es betreten. Noch bevor Prozess l das kritische Gebiet asst, wird Prozess h ∈ P mit hoher Priorit¨at bereit css mit leave(s) verl¨ und verdr¨ angt Prozess l. Schließlich fordert auch Prozess h mit enter(s) Zugang zum kritischen Gebiet css . Je nach Gewichtung von Priorit¨at und Synchonisierung sind zwei Arten der Fortsetzung der Ausf¨ uhrung denkbar: (a) Die Priorit¨ at hat h¨ ochstes Gewicht und Prozess h erh¨alt Zutritt zum kritischen Gebiet. Um die Konsistenz der Daten zu erhalten, muss die Ausf¨ uhrung von Prozess l r¨ uckg¨ angig gemacht, bzw. auf eine Kopie des Zustandes vor dem Betreten des kritischen Gebietes zur¨ uckgesetzt werden (siehe Abb. 4.1).

Abb. 4.1. Vorrang der Priorit¨ at vor der Synchronisierung.

(b) Die Synchronisierung zur Bewahrung der Konsistenz der Daten hat h¨ ochstes Gewicht. Aus diesem Grund wird Prozess h bei der Ausf¨ uhrung der Operation enter(s) blockiert. Erst wenn Prozess l das kritische Gebiet s mit leave(s) verl¨ asst, kann Prozess h die begonnene Operation enter(s) zu Ende f¨ uhren und als h¨ochstpriorisierter Prozess das kritische Gebiet betreten (siehe Abb. 4.2).
Bis auf wenige Anwendungsfelder gilt die Alternative (a) aus Beispiel 4.1.1 als zu aufw¨ andig1 . Statt dessen wird der Alternativen (b) und damit der Synchronisierung vor der Priorit¨ at Vorrang einger¨aumt. Dazu muss in Kauf 1

Bei Datenbanken gibt es zur L¨ osung von Konflikten bei der Synchronisierung die Strategie, Prozesse, in dem Fall Transitionen genannt, auf vordefinierte Zust¨ ande zur¨ uckzusetzen.

4.1

Planung synchronisierter Prozesse

217

Abb. 4.2. Vorrang der Synchronisierung vor der Priorit¨ at.

genommen werden, dass der Prozess h f¨ ur die Dauer des Aufenthalts von Prozess l im kritischen Gebiet blockiert wird. Die Blockadezeit ∆bi ist die Zeitspanne, die ein Prozess i blockiert werden kann. Sie muss bei der Pr¨ ufung, ob ein Plan brauchbar ist, mit ber¨ ucksichtigt werden. Deshalb ist beispielsweise der RM-Test folgendermaßen zu erg¨anzen: ! n ∆pi ∆ej + ∆bi ≤ di ri + ∆ei + ∆pj j=i+1 Dabei muss die Blockadezeit ∆bi alle Ausf¨ uhrungszeiten umfassen, die Prozesse niedrigerer Priorit¨ at in kritischen Gebieten, die den Prozess i direkt oder indirekt blockieren k¨ onnen, verbringen. In den nachfolgenden Unterabschnitten wird ausdr¨ ucklich darauf eingegangen, wie sich ∆bi berechnet. uck bezeichnet, das Prozess i mit Mit csis wird das Programmst¨ P(i):: : enter(s); : leave(s); : betritt und wieder verl¨ asst. Besitzt ein Prozess mehrere Programmst¨ ucke, die auf diese Weise betreten und verlassen werden, dann sind diese der Reihe i(1) i(2) nach durchzunummerieren: css , css , ... . Im Weiteren wird der Einfachheit halber nur von einem Programmst¨ uck ausgegangen und die Notation csis benutzt. Die unstrukturierte Verwendung der Synchronisierungsoperationen f¨ uhrt leicht zu un¨ ubersichtlichen und fehlerhaften parallelen Programmen. Eine Form der strukturierten Synchonisierung eignet sich in besonderem Maße f¨ ur

218

4. Fortgeschrittene Planungsverfahren

kritische Gebiete und ordnet die enter()- und leave()-Operationen a¨hnlich wie ein Klammergebirge. So aufgebaute kritische Gebiete heißen kanonisch verschachtelt. F¨ ur jeden Prozess i und je zwei kritische Gebiete csis und csit muss gelten: csis ⊂ csit ∨ csit ⊂ csis ∨ csis ∩ csit = ∅ Im Folgenden werden nur kanonisch geschachtelte kritische Gebiete betrachtet und behandelt. uhrungszeit eines Prozesses i im kritischen GeMit ∆e(csis ) wird die Ausf¨ biet bezeichnet. Diese Zeitspanne ist f¨ ur die Ermittlung der Blockadezeit ∆bi wichtig. Dabei spielen die Maxima u ¨ber alle Prozesse i ∈ P oder u ¨ber alle kritischen Gebiete css ∈ CS eine Rolle: ∆emax (css ) = maxi∈P {∆e(csis )} ∆emax (csi ) = maxcss ∈CS {∆e(csis )} 4.1.1

Aufgabe 4.1.1 (siehe Seite 294) Indirekte Blockade entsteht durch verschach-

telte kritische Gebiete. Konstruieren Sie eine Blockadesituation f¨ ur drei Prozesse, wobei Prozess 3 direkt von Prozess 2 wegen des kritischen Gebietes css und von Prozess 1 indirekt wegen des kritischen Gebietes cst blockiert wird.
Nachdem nun festgesetzt ist, dass die Synchronisierung Vorrang vor der Priorit¨ at erh¨ alt, ergibt sich ein weiteres Problem, das von Lampson und Redell (vgl. [83]) als Priorit¨ atsumkehr (engl. priority inversion) bezeichnet wurde und den erweiteten RM-Test kippt. Angenommen, ein hoch priorisierter Prozess h wird von einem niedriger priorisierten Prozess l blockiert. Dann kann ein Prozess m mittlerer Priorit¨at den Prozess l f¨ ur die Dauer seiner Ausf¨ uhrungszeit verdr¨angen. Das ist im erweiterten RM-Test bereits enthalten. Nicht enthalten ist jedoch, dass Prozess m auch indirekt die Blockade, die Prozess h durch Prozess l erf¨ahrt, auf seine gesamte Ausf¨ uhrungszeit ausdehnen kann (siehe Abb. 4.3). Dies setzt die Wirkung, die Priorit¨ aten haben sollen, v¨ollig außer Kraft und f¨ uhrt letztendlich zu unn¨ otig pessimistischen Einsch¨atzungen, was die Abschlusszeiten gerade der h¨ oher priorisierten Prozesse betrifft. Ziel der beiden folgenden Unterabschnitte ist es deshalb, Methoden zu beschreiben, mit deren Hilfe die Priorit¨ atsumkehr ausgeschlossen und der erweiterte RM-Test angewendet werden kann. Das Grundprinzip, das beiden Methoden innewohnt, besteht in der Weitergabe der Priorit¨at des blockierten Prozesses an den blockierenden Prozess mit dem Ziel, auf diese Weise

4.1

Planung synchronisierter Prozesse

219

Abb. 4.3. Vorrang der Synchronisierung vor der Priorit¨ at.

dem blockierenden Prozess zu helfen2 , das kritische Gebiet zu beenden, ohne zwischenzeitlich von Prozessen mittlerer Priorit¨at unterbrochen zu werden. Diese unmittelbare Hilfe f¨ ur den blockierenden Prozess stellt eine mittelbare Hilfe f¨ ur den blockierten Prozess dar. Es suggeriert sogar, dass der blockierte ur ihn arbeitet. Prozess nicht warten muss3 , sondern ein anderer Prozess f¨ Beide Methoden fußen auf einer programmiertechnischen Voraussetzung. Betriebssysteme oder Laufzeitsysteme m¨ ussen zulassen, dass Prozesse ihre Priorit¨ at zur Laufzeit a ndern k¨ o nnen bzw. dies in die Ausf¨ uhrung der Operationen ¨ enter(s) und leave(s) integrieren. Somit besitzt jeder Prozess i eine Basispriorit¨ at i und eine gegebenfalls h¨ ohere aktuelle Priorit¨at ap(i). Die priorit¨ atsbasierte Prozessausf¨ uhrung legt f¨ ur die Entscheidung, den Prozessor zu vergeben, die aktuelle Priorit¨ at zugrunde. 4.1.2 Priorit¨ atsvererbung

Das Protokoll der Priorit¨ atsvererbung (engl. priority inheritance protocol oder kurz PIP) geht auf Sha, Rajkumar und Lehoczky (vgl. [117]) zur¨ uck, wobei das einfache Prinzip zugrunde liegt, die eigene Priorit¨at kurzfristig zu vererben. Zwei partielle Funktionen dienen dazu, die Beziehungen, die zwischen Prozessen und kritischen Gebieten bei der Prozessausf¨ uhrung entstehen, wiederzugeben. Die erste der beiden zeigt an, welcher Prozess gerade im Besitz 2

Im englischen Sprachraum wird in diesem Zusammenhang h¨ aufig der Begriff helping verwendet. 3 Man mag dieses Bild als unpassend empfinden. Aber im englischen Sprachraum hat sich f¨ ur diese Art der Synchronisierung der Begriff wait-free synchronization verbreitet.

220

4. Fortgeschrittene Planungsverfahren

eines kritischen Gebietes ist: ownedBy : CS → P Es gilt: ownedBy(css ) = i, gdw. Prozess i die Operation enter(s) erfolgreich ausgef¨ uhrt und das kritische Gebiet css betreten, aber noch nicht verlassen hat. Befindet sich kein Prozess im kritischen Gebiet, dann ist ownedBy(css ) undefiniert. Die zweite Funktion dient dazu anzuzeigen, dass ein Prozess beim Betreten eines kritischen Gebietes blockiert worden ist: blockedBy : P → CS Es gilt: blockedBy(i) = css , gdw. Prozess i begonnen hat, die Operation enter(s) auszuf¨ uhren, diese jedoch nicht zu Ende ausgef¨ uhrt werden konnte, weil ein anderer Prozess im Besitz des kritischen Gebietes css ist. Andernfalls ist blockedBy(i) undefiniert. Beide Funktionen zusammen beschreiben eine Relation, die anzeigt, ob ein Prozess einen anderen blockiert: blocks : P × P Es gilt: (i, j) ∈ blocks, gdw. zwei Prozesse i und j und ein css ∈ CS existiert mit ownedBy(css ) = i und blockedBy(j) = css . In diesem Fall wird Prozess j wegen genau eines kritischen Gebietes von Prozess i blockiert. Die Relation blocks steht f¨ ur die direkte Blockade zwischen zwei Prozessen. Prozesse k¨ onnen, wie die L¨ osung zur Aufgabe 4.1.1 zeigt, aber auch indirekt blockiert sein. Dies wird durch den irreflexiven und transitiven Abschschluss uckt. Auf der Grundlage von blocks+ blocks+ der Relation blocks ausgedr¨ wird die aktuelle Priorit¨ at von Prozessen berechnet. Nimmt man die Indizes der Prozesse als deren Basispriorit¨ at, dann ist die aktuelle Priorit¨at folgende Abbildung: ap : P → P Es gilt: ap(i) = max{j ∈ P | mit (i, j) ∈ (blocks+ ∪ {(i, i)})} Somit wird die aktuelle Priorit¨ at entlang der Kette blockierter Prozesse weitergereicht. Wird Prozess i nicht blockiert, dann ist die aktuelle Piorit¨at identisch mit der Basispriorit¨ at.

4.1

Planung synchronisierter Prozesse

221

Beispiel 4.1.2 Gegeben sei die Ausf¨ uhrung der Prozesse P = {1, 2, 3, 4}, die

die kritischen Gebiete css und cst benutzen. Betrachtet wird der Zustand zum Zeitpunkt t0 (siehe Abb. 4.4). Dann ist: ownedBy(css ) = 2 ownedBy(cst ) = 1 blockedBy(2) = cst blockedBy(3) = css Weiterhin gibt es folgende Blockadebeziehungen zwischen Prozessen: (i, j) ∈ blocks 1 2 3

1

2 ×

3 ×

Neben den zwei direkten Blockaden gibt es eine indirekte, die in der Relation block + wiedergegeben ist: (i, j) ∈ blocks+ 1 2 3

1

2 ×

3 × ×

Abb. 4.4. Ausf¨ uhrung von drei Prozessen, deren aktuelle Priorit¨ aten immer dann

angegeben sind, wenn sie sich ¨ andern.


Die Priorit¨ atsvererbung wird u uhrung ¨blicherweise als Protokoll bei der Ausf¨ der Synchronisierungsoperationen abgearbeitet. In den meisten Quellen wird informell beschrieben, wie sich die Prozesse verhalten und ihre aktuelle Prio-

4.1.2

222

4. Fortgeschrittene Planungsverfahren

rit¨ at zustande kommt. Diese Vorgehensweise hat zu gravierenden Fehlern bei den Protokollen selbst (nachgewiesen in [101] und [148]) aber auch bei den Implementierungen des PIP in Betriebssystemen (vgl. [147]) gef¨ uhrt. Aus diesem Grund ist es angebracht, eine Definition des PIP auf der Grundlage der eingef¨ uhrten Beschreibungsgr¨ oßen zu geben. Deren Ver¨anderung geht von der Ausf¨ uhrung der Operationen enter() und leave() aus, die jeweils bei zwei Zust¨ anden betrachtet werden. Die beiden ersten F¨alle sind einfach: (e1): Prozess i f¨ uhrt enter(s) aus und css ist frei. D.h., es gibt bislang kein j ∈ P mit css → j ∈ ownedBy: ownedBy = ownedBy ∪ {css → i} (l1): Prozess i f¨ uhrt leave(s) aus und kein Prozess ist blockiert beim Betreten von css . D.h., es gibt kein j ∈ P , i = j, mit j → css ∈ blockedBy: ownedBy = ownedBy \ {css → i} Die beiden anderen Zust¨ ande, zu denen das Protokoll ausgef¨ uhrt werden kann, sind komplexer und erfordern zun¨achst die Bestimmung der Prozessmenge, aus der bei der Prozessorzuteilung ausgew¨ahlt werden darf. Dazu z¨ ahlen zun¨ achst alle Prozesse im Zustand rechenbereit. Zus¨atzlich sind aber noch solche Prozesse zu ber¨ ucksichtigen, die zwar im Zustand blockiert sind, wobei das kritische Gebiet, auf das sie warten, mittlerweile frei geworden ist. Der letztere Zustand ist so zu beschreiben: blockedBy(i) = css und es gibt kein j ∈ P mit ownedBy(css ) = j Zusammen mit den Prozessen im Zustand rechenbereit bilden sie die Menge Ready. Aus der Menge Ready wird bei einer Prozessumschaltung derjenige Prozess next in den Zustand rechnend versetzt, f¨ ur den gilt: ap(next) ≥ ap(i)

, i ∈ Ready

Nun k¨ onnen die beiden Operationen enter() und leave() unter den verbleibenden Zust¨ anden beschrieben werden: (e2): Prozess i f¨ uhrt enter(s) aus und es gibt einen Prozess j mit ownedBy(css ) → j: blockedBy = blockedBy ∪ {i → css } Ready = Ready \ {i}

4.1

Planung synchronisierter Prozesse

223

Entsprechend erh¨ ohen sich nun die aktuellen Priorit¨aten der Prozesse, die Prozess i direkt oder indirekt blockieren. Entsprechend ist der Prozess next neu zu bestimmen. Bei next kann es sich um einen Prozess handeln, der zwar im Zustand blockiert ist, dessen kritisches Gebiet cst , auf das er wartet, mittlerweile frei geworden ist. Somit gilt: blockedBy(next) = cst und es gibt keinen Prozess j ∈ P mit cst → j ∈ ownedBy. Dann ist Folgendes zu tun: blockedBy = blockedBy \ {next → cst } ownedBy = ownedBy ∪ {cst → next} Ready = Ready \ {j ∈ P | blockedBy(j) = cst } (l2): Prozess i f¨ uhrt leave(s) aus, und es gibt eine nicht leere Prozessochte. Entsprechend ist f¨ ur jeden von diesen menge, die css betreten m¨ Prozessen j, mit blockedBy(j) = css , folgendes zu tun: ownedBy = ownedBy \ {css → i} Ready = Ready ∪ {j ∈ P | blockedBy(j) = css } Die Menge Ready vergr¨ oßert sich, und es kann sein, dass sich die aktuelle Priorit¨ at von Prozess i verringert. Entsprechend ist der Prozess next neu zu bestimmen. Es gibt zwei F¨ alle: (a): Ist next = i, dann beh¨ alt Prozess i seine aktuelle Priorit¨at und nichts ist zu tun. (b): Ist next = i, dann ist blockedBy(next) = css und Folgendes zu tun: blockedBy = blockedBy \ {next → css } ownedBy = ownedBy ∪ {css → next} Ready = Ready \ {j ∈ P | blockedBy(j) = css } Dieser Fall entspricht der Fortsetzung einer begonnenen enter(s)Operation durch Prozess next. Damit ist das PIP komplexer, als die Idee der Priorit¨atsvererbung anf¨anglich vermuten ließ. Insbesondere die Prozessorzuteilung birgt die Merkw¨ urdigkeit, dass next ein blockierter Prozess sein kann, sofern das von ihm beanspruchte kritische Gebiet frei ist. Diese Variante wird auch PIP mit verz¨ogerter Zuteilung oder kurz PIPd genannt4 . Andere Versionen des PIP, die ein freiwer4

PIPd (vgl. [147]), der Buchstabe d steht f¨ ur delayed. Im Weiteren ist mit PIP immer die oben formal eingef¨ uhrte Variante PIPd gemeint.

224

4. Fortgeschrittene Planungsverfahren

dendes kritisches Gebiet sofort an den h¨ochstpriorisierten Prozess zuordnen, erf¨ ullen den zentralen Satz 4.1.1 zum PIP nicht (siehe Aufgabe 4.1.2). Das PIP ist nur f¨ ur solche Programme sinnvoll einsetzbar, die deadlockfrei sind. Der nachfolgende Satz zum PIP gilt unter dieser Voraussetzung. 4.1.1

Satz 4.1.1 Sei Prozess j derjenige mit maximaler Basispriorit¨ at, der nicht

im Zustand beendet ist. Dann ist j entweder im Zustand rechnend oder im Zustand blockiert. Im letzteren Fall gibt es genau einen Prozess i mit ap(i) = j, der im Zustand rechnend ist. Beweis: Die Behauptung ist insbesondere anf¨ anglich f¨ ur einen Prozess h¨ ochster Basispriorit¨ at erf¨ ullt, sofern er kein kritisches Gebiet betreten hat. Die Operationen (e1) und (l1) ¨ andern daran nichts. Erst die beiden anderen Operationen sind genauer zu betrachten: (e2): Prozess j wird direkt durch Prozess k niedrigerer Priorit¨at blockiert. Dieselbe Behauptung muss auf Prozess k zu einem fr¨ uheren Zeitpunkt zugetroffen haben. Mit dieser induktiven Argumentation gibt es einen Prozess i, f¨ ur den vormals ap(i) = k galt und f¨ ur den mit (e2) nun gilt: ap(i) = j. (l2): Prozess i verl¨ asst das kritische Gebiet css . Hier gibt es zwei F¨alle: (a) Der Prozess i beh¨ alt seine Priorit¨at, weil i noch ein weiteres kritisches Gebiet cst besitzt und damit den Prozess j direkt oder indirekt blockiert. Dann ist i = next und die Behauptung trifft in identischer Weise weiterhin zu. (b) Prozess i verl¨ asst css und blockiert Prozess j nicht mehr. Dann sinkt die aktuelle Priorit¨ at von Prozess i und es gibt einen Prozess next = i mit blockedBy(next) = css , so dass entweder next = j oder (next, j) ∈ ullt die Behauptung. blocks+ ist. Jede Alternative erf¨
Als Folgerungen aus dem Satz lassen sich zwei wesentliche Aussagen ableiten: Ein Prozess i kann nur ein einziges Mal wegen eines kritischen Gebietes blockiert werden, das ein Prozess j mit niedrigere Basispriort¨at besitzt. Dies geht aus der Beweisf¨ uhrung zu (l2) hervor, bei der sich die Kette der blockierenden Prozesse schrittweise reduziert. Somit ergibt sich: ∆bi ≤

i−1

∆emax (csj )

j=1

Ein Prozess i kann nur ein einziges Mal wegen eines kritischen Gebietes css blockiert werden. Diese Aussage ist schwieriger einzusehen. Wird

4.1

Planung synchronisierter Prozesse

225

ein Prozess zum ersten Mal wegen css blockiert, dann wird der Prozess, der dieses kritische Gebiet besitzt, es schließlich wieder freigeben. Dieses Gebiet kann nur dann nochmals an einen anderen Prozess k vergeben werden, wenn dieser den Prozess i wegen eines weiteren kritischen Gebietes cst bereits blockiert und es gilt: csks ⊂ cskt . In einem solchen Fall kommt in der nachfolgenden Absch¨ atzung der Wert ∆emax (cst ) zur Anrechnung. Somit ergibt sich: ∆emax (css ) ∆bi ≤ css ∈CS

Beispiel 4.1.3 Die Prozessmenge P = {1, 2, 3, 4} habe Zugriff auf die kritischen Gebiete CS = {css , cst }. Dabei werden (siehe Abb. 4.5) bis zu dem Zeitpunkt, unmittelbar bevor Prozess 1 das kritische Gebiet css verl¨asst, die folgenden Beziehungen aufgebaut:

Abb. 4.5. Vier Prozesse operieren auf 2 kritischen Gebieten. Dabei wird die PIP-Variante

mit verz¨ ogerter Zuteilung angewendet.

ownedBy(s) = 1 ownedBy(t) = 3 blockedBy(2) = s blockedBy(3) = s blockedBy(4) = t

4.1.3

226

4. Fortgeschrittene Planungsverfahren

Die blocks-Relation lautet: (i, j) ∈ blocks 1 2 3 2

1

2 ×

3 ×

4

×

Bis zu diesem Zeitpunkt war Prozess 4 zum ersten Mal wegen css blockiert und muss die Zeitspanne ∆emax (css ) einkalkulieren. Wenn nun Prozess 1 asst, darf es anschließend der Prozess 3 betreten. das kritische Gebiet css verl¨ Danach gibt es Prozess 3 wieder frei und es stellt sich die Frage, ob css bereits dem Prozess 2, der es betreten m¨ ochte, zugeordnet werden soll. Die PIPVariante mit verz¨ ogerter Zuteilung verneint dies. Sie bel¨asst den Prozess 2 im Zustand blockedBy(2) = css , wenngleich css frei ist5 . Das hat zur Folge, dass Prozess 4, wenn er etwas sp¨ ater das kritische Gebiet css betreten will, diesen Zustand noch so vorfindet. Er wird kein zweites Mal wegen css blockiert und darf css betreten. Dies entspricht der zweiten Folgerung aus dem Satz 4.1.1.
4.1.2

Aufgabe 4.1.2 (siehe Seite 295) In einem zentralen Artikel zum PIP steht der

folgende Satz (vgl. [117], Seite 1177): When a job J exits its critical section, the binary semaphore associated with the critical section will be unlocked, and the highest priority job, if any, blocked by J will be awakened. Dies wird gemeinhin so interpretiert, dass ein freiwerdendes kritisches Gebiet sofort an einen Prozess vergeben werden kann, der darauf wartet, es zu betreten. Nehmen Sie diese Regel als Entscheidungsgrundlage und f¨ uhren Sie damit Beispiel 4.1.3 ab dem Zeitpunkt, zu dem Prozess 3 das kritische Geasst, weiter. Pr¨ ufen Sie, ob die Folgerungen aus dem Satz 4.1.1 biet css verl¨ erhalten bleiben.
Das PIP mit verz¨ ogerter Zuteilung ist das einzige bekannte Verfahren, das beide Folgerungen aus dem obigen Satz erf¨ ullt. 5

Stellvertretend f¨ ur viele Ver¨ offentlichungen sei hier Buttazzo (vgl. [26], Seite 208) referiert, der ein kritisches Gebiet css (bei Buttazzo ein Semaphor) sofort wieder vergibt, wenn es mit leave(s) verlassen wurde, und es einen Prozess gibt, der es betreten m¨ ochte. Bezogen auf das obige Beispiel hat dies zur Folge, dass etwas sp¨ ater Prozess 4 ein zweites Mal wegen css blockiert werden wird (siehe auch Aufgabe 4.1.2).

4.1

Planung synchronisierter Prozesse

227

4.1.3 Priorit¨ atsobergrenzen

Das Protokoll auf der Basis von Priorit¨ atsobergrenzen (engl. priority ceiling protocol oder kurz PCP, vgl. [117]) zielt darauf, zwei Schwachstellen des PIP zu beseitigen: Das PCP schließt das Auftreten von Deadlocks, verursacht durch kritische Gebiete, aus. Das PCP verhindert, dass Ketten von indirekten Blockaden m¨oglich werden, was letztendlich zu weniger pessimistischen Absch¨atzungen beim erweiterten RM-Test f¨ uhrt. Der Preis f¨ ur die beiden positiven Eigenschaften des PCP ist, dass mehr Kenntnisse u ¨ber Prozesse und kritische Gebiete ben¨otigt werden. So muss vorweg bekannt sein, welcher Prozess welches kritische Gebiet betreten will. Dazu dient die Relation uses: uses : P × CS Es gilt: (i, css ) ∈ uses, gdw. der Prozess i jemals das kritische Gebiet css betreten will. Diese Information kann beispielweise ein Compiler liefern, was die Integration des PCP in Programmiersprachen, z.B. Ada95 (vgl. [130]), begr¨ undet. Auf der Basis der uses-Relation kann jedem kritischen Gebiet eine Priorit¨ atsobergrenze zugeordnet werden: ceiling : CS → P Es gilt: ceiling(css ) = max{i ∈ P | (i, css ) ∈ uses}. Damit gibt ceiling(css ) die h¨ ochste Priorit¨ at eines Prozesses an, der das kritische Gebiet css jemals betreten m¨ ochte. Daneben soll die Abbildung ownedBy (siehe Seite 220) auch f¨ ur das PCP anzeigen, welcher Prozess sich gerade in einem gegebenen kritischen Gebiet aufh¨ alt. Beim PCP h¨ angt die Erlaubnis, ein kritisches Gebiet betreten zu d¨ urfen, nicht allein davon ab, dass es gerade frei ist. Vielmehr hat ein Prozess weitergehende Bedingungen zu erf¨ ullen. Dazu wird zun¨achst der Wunsch, gerade ein kritisches Gebiet betreten zu wollen, mit der Abbildung wants beschrieben: wants : P → CS Es gilt: i → css ∈ wants, gdw. Prozess i beim Betreten des kritischen Gebieur diesen Zweck ben¨ otigt das PCP eine eigene blockstes css blockiert wird. F¨ Relation, in der die Priorit¨ atsobergrenze eine entscheidende Rolle spielt: blocks : P × P

228

4. Fortgeschrittene Planungsverfahren

Es gilt: (i, j) ∈ blocks, gdw. gilt i = j und es css und cst aus CS gibt, so dass erf¨ ullt ist: css → i ∈ ownedBy ∧ j → cst ∈ wants ∧ ap(j) ≤ ceiling(css ) Damit ist ein Prozess j bereits dann blockiert, wenn es einen Prozess i gibt, der ein kritisches Gebiet css besitzt, das grunds¨atzlich auch solche Prozesse betreten wollen, die eine h¨ ohere Priorit¨ at als Prozess j besitzen. Die Grenze, die Prozess i u ¨berschreiten muss, um ein kritisches Gebiet betreten zu d¨ urfen, h¨ angt von den aktuellen Besitzverh¨altnissen kritischer Gebiete ab. Dies l¨ asst sich in die arithmetische Bedingung ap(i) > ac(i) fassen, wobei ac eine Funktion ist, die jedem Prozess seine aktuelle Obergrenze zuordnet: ac : P → P Es gilt: ac(i) = max{ceiling(css ) | css ∈ CS und ∃j ∈ P, j = i, mit css → j ∈ ownedBy} Beachte, dass ac(i) von den Besitzverh¨ altnissen aller Prozesse außer dem Prozess i bestimmt wird. ¨ Ahnlich wie beim PIP sind bezogen auf das PCP die beiden Operationen enter() und leave() unter jeweils zwei Zust¨anden zu betrachten: (e1): Prozess i f¨ uhrt enter(s) aus und es ist ap(i) > ac(i). Dann darf Prozess das kritische Gebiet css betreten: ownedBy = ownedBy ∪ {css → i} (e2): Prozess i f¨ uhrt enter(s) aus und es ist ap(i) ≤ ac(i). Dann wird der Wunsch von Prozess i vermerkt: wants = wants ∪ {i → css } Prozess i geht implizit in den Zustand blockiert u ¨ber, denn es gibt einen Prozess next ∈ P , next = i, mit (next, i) ∈ blocks. In der Folge steigt die aktuelle Priorit¨ at von next auf den Wert i und next geht in den Zustand rechnend u ¨ber. (l1): Prozess i f¨ uhrt leave(s) aus und es gibt keinen Prozess j ∈ P , mit (i, j) ∈ blocks. Dann wird lediglich vermerkt: ownedBy = ownedBy \ {css → i}

4.1

Planung synchronisierter Prozesse

229

(l2): Prozess i f¨ uhrt leave(s) aus und es gibt Prozesse j ∈ P , mit (i, j) ∈ blocks. Dann wird zun¨ achst vermerkt: ownedBy = ownedBy \ {css → i} Hiermit ver¨ andert sich die blocks-Relation, die aktuelle Priorit¨at und die aktuelle Priorit¨ atsobergrenze. Deshalb ist es sinnvoll, nach demjenigen rechenbereiten Prozess next zu suchen, der die h¨ochste aktuelle Priorit¨at besitzt und f¨ ur den gilt: ap(next) > ac(next) Ist das ein Prozess next = i mit next → cst ∈ wants, dann ist Folgendes zu tun: wants = wants \ {next → cst } ownedBy = ownedBy ∪ {cst → next} Dieser Fall entspricht der Fortsetzung einer begonnenen enter(t)Operation durch Prozess next. Beispiel 4.1.4 Gegeben seien die Prozessmenge P = {1, 2, 3, 4} und die kriti-

schen Gebiete CS = {css , cst , csu }. Die folgenden Programmfragmente beschreiben, wie die Prozesse die kritischen Gebiete betreten wollen: P(1):: : enter(s); : enter(t); : leave(t); : leave(s); :

P(2):: : enter(u); : enter(t); : leave(t); : leave(u); :

P(3):: : enter(s); : leave(s); :

P(4):: : enter(u); : leave(u); :

Daraus berechnen sich die Priorit¨ atsobergrenzen der kritischen Gebiete: ceiling(s) = 3 ceiling(t) = 2 ceiling(u) = 4

4.1.4

230

4. Fortgeschrittene Planungsverfahren

Prozess 1 kann nacheinander die kritischen Gebiete css und cst betreten. Er wird dann durch den Start von Prozess 2 verdr¨angt, der seinerseits das kritische Gebiet csu betreten will. Zu diesem Zeitpunkt ist seine aktuelle Priorit¨ at ap(2) identisch mit seiner Basispriorit¨at. Dagegen ist die aktuelle Priorit¨ atsobergrenze durch die beiden kritischen Gebiete, die Prozess 1 belegt, bei ac(2) = 3. Damit ist 2 = ap(2) ≤ ac(2) = 3 und Prozess 3 blockiert wegen Prozess 1: (1, 2) ∈ blocks Dabei vererbt er seine Priorit¨ at an Prozess 2. In gleicher Weise geschieht dies mit Prozess 3, der sp¨ ater startet. Auch er wird wegen 1 blockiert und gibt seine Priort¨ at weiter an Prozess 1. Prozess 4, der noch sp¨ ater startet, will das kritische Gebiet csu betreten. Dies wird gestattet, da gilt: 4 = ap(4) > ac(4) = 3 Interessant wird es, wenn Prozess 4 endet und Prozess 1 in den Zustand rechnend u asst Prozess 1 das kritische Gebiet cst , so bleibt er ¨bergeht. Verl¨ der einzige, der fortfahren kann. Erst wenn er auch das kritische Gebiet css verl¨ asst, endet die Blockade von Prozess 2 und 3.

Abb. 4.6. Vier Prozesse operieren auf 2 kritischen Gebieten.


Die nachfolgenden S¨ atze spiegeln wesentliche Eigenschaften des PCP wider :

4.1

Planung synchronisierter Prozesse

231

Satz 4.1.2 Ein Prozess i, der ein kritisches Gebiet css besitzt, wird nicht blockiert. Beweis: Im Widerspruch zur Behauptung wird angenommen, dass Prozess i beim Betreten eines kritischen Gebietes cst blockiert wird. Beim Eintreat, die gr¨oßer war als die Prioten in css hatte Prozess i noch eine Priorit¨ rit¨ atsobergrenze: ap(i) > ac(i). Wenn Prozess i nun nicht ins kritische Gebiet cst gelangt, muss es einen anderen Prozess j geben, der zwischenzeitlich ein kritisches Gebiet mit h¨ oherer Priorit¨ atsobergrenze betreten hat. Deshalb gilt ap(j) > ceiling(css ). Wegen (i, css ) ∈ uses ist ceiling(css ) ≥ ap(i) und es folgt: ap(j) > ap(i). Trotz seiner h¨ oheren Priorit¨at ist j zum jetzigen Zeitpunkt nicht rechenbereit. Also muss j beim Betreten eines kritischen Gebietes blockiert sein. Somit befindet sich j in einer analogen Situation, wie sie zu Anfang des Beweises f¨ ur Prozess i angenommen wurde. Wegen der Endlichkeit der Prozessmenge P l¨ asst sich die Argumentation von oben nur endlich oft anwenden, bis sie schließlich versagt. Dies liefert den gesuchten Widerspruch zur Annahme.


4.1.2

Satz 4.1.3 Das PCP verhindert die Bildung von Ketten von blockierten Prozessen. Beweis: Angenommen, es existiert die Blockadekette (i, j) ∈ blocks und (j, k) ∈ blocks. Mit der Definition von blocks ist f¨ ur ein kritisches Gebiet ur ein cst ∈ CS die css die Abbildung j → css ∈ wants und gleichzeitig f¨ Abbildung cst → j ∈ ownedBy. Es gilt jedoch mit Satz 4.1.3, dass Prozess j, der ein kritisches Gebiet betreten hat, nicht mehr blockiert wird.


4.1.3

Aus dem obigen Satz folgt, dass ein Prozess h¨ ochstens f¨ ur die Ausf¨ uhrungszeit eines einzigen kritischen Gebietes eines niedriger priorisierten Prozesses blockiert werden kann. Damit verk¨ urzt sich die Blockadezeit f¨ ur einen Prozess i beim PCP im Verh¨ altnis zum PIP drastisch: ∆bi ≤ max1≤j≤i−1 {∆emax (csj )} Es ist immer m¨ oglich, dass sich ein Prozess durch sich selbst blockiert und so in einen Deadlock ger¨ at: P:: : enter(s); : enter(s); :

232

4. Fortgeschrittene Planungsverfahren

leave(s); : leave(s); : Dies soll als ein fehlerhaftes Programm aufgefasst und nicht weiter ber¨ ucksichtigt werden. Dagegen werden Deadlocks, an denen mehrere Prozesse beteiligt sind, durch das PCP verhindert. 4.1.4

Satz 4.1.4 Das PCP verhindert Deadlocks. Beweis: Die Behauptung ergibt sich unmittelbar aus Satz 4.1.3, der Ketten-

bildung der L¨ ange 2 und mehr ausschließt.




4.2

Planung bei Mehrprozessorsystemen

233

4.2 Planung bei Mehrprozessorsystemen Mehrprozessorsysteme werden f¨ ur Echtzeitanwendungen immer wichtiger. Es ist deshalb folgerichtig, nach angemessenen Planungsverfahren Ausschau zu halten. So wird zun¨ achst der Versuch gestartet, Erkenntnisse, die bei den Grundlagen der Planung genwonnen wurden (siehe Kapitel 3), mit verschiedenen Formen der Prozessausf¨ uhrung zu verbinden (siehe Unterabschnitt 4.2.1). Danach geht es konkret um eine bedeutende Planungsstrategie, die hinsichtlich ihrer Eigenschaften (siehe Unterabschnitt 4.2.2) und geeigneter Planungsverfahren untersucht (siehe Unterabschnitt 4.2.3) wird. 4.2.1 Planungsverfahren abh¨ angig von der Migration der Prozessen

F¨ ur die Planung bei Mehrprozessorsystemen stellt sich die Frage, inwiefern sich hierf¨ ur die grundlegenden Planungsverfahren (siehe Kapitel 3) eignen. Wegen der Dominanz der periodischen unterbrechbaren Prozesse stehen die Planungsverfahren RMS, EDF und LLF bei einer solche Betrachtung im Vordergrund. Alle diese Verfahren basieren auf Priorit¨aten, unterscheiden sich dabei aber in den Zeitpunkten, zu denen die Priorit¨aten vergeben oder ver¨ andert werden. (RM S) Die Priorit¨ atenzuordnung ist statisch. D.h., sie ist f¨ ur alle Prozessausf¨ uhrungen gleich. (EDF ) Die Priorit¨ atszuordnung ist dynamisch. D.h., sie wird bei jeder Startzeit f¨ ur die n¨ achste Prozessausf¨ uhrung festgelegt. (LLF ) Die Priorit¨ atszuordnung ist dynamisch. D.h., sie kann, im Gegesatz zu EDF, w¨ ahrend der Prozessausf¨ uhrung ver¨andert werden. Im Folgenden ¨ ist der Mindestabstand zwischen zwei Anderungen der Priorit¨at auf die Bezugszeitspanne ∆tG festgesetzt. Ein anderes Kriterium, das bei der Planung von Mehrprozesssystemen zu ber¨ ucksichtigen ist, betrifft die F¨ ahigkeit der Prozesse, von Prozessor zu Prozessor migrieren zu k¨ onnen (siehe Unterabschnitt 2.4.5): (N oM ) Ausschluss von Migration. (ExM ) Migration von einer Prozessausf¨ uhrung zur n¨achsten. (P rT ) Migration w¨ ahrend der Prozessausf¨ uhrung. Beide Kriterien, Auswahl des Planungsverfahrens und F¨ahigkeit zur Migration, sind orthogonal zueinander. Somit kann ein spezielles Planungsverfahren A bei einem Mehrprozessorsystem, das einen speziellen Grad B der Migration von Prozessen zul¨ asst, angewendet werden. Auf diese Weise ergeben sich bereits (3 × 3) M¨ oglichkeiten der Kombinationen von Planungsverfahren. Um ur die Menge der Prozessmendiese vergleichen zu k¨ onnen, soll FA,B ⊂ 2P f¨

4.2

234

4. Fortgeschrittene Planungsverfahren

gen stehen, die unter einer Kombination (A, B) einen brauchbaren Plan s besitzen. 4.2.1

Beispiel 4.2.1 Die Kombination (RM S, ExM ) steht f¨ ur ein Planungsverfah-

ren nach monotonen Raten, wobei die Prozessausf¨ uhrung auf wechselnden Prozessoren stattfinden kann. Gegeben sei die Prozessmenge P = {1, 2, 3, 4} bei m = 2 Prozessoren und den Prozessparametern: P 1 2 3 4

∆e 2 3 1 2

∆p 6 5 4 3

Die Zuordnung des Prozessors erfolgt zur fr¨ uhstm¨oglichen Startzeit des Prozesses und bleibt dann f¨ ur die gesamte Zeitspanne dieser Prozessausf¨ uhrung bestehen. Betrachtet man Prozess 1, dann wird er in seiner ersten Periode ab dem Zeitpunkt 2 auf den Prozessor 2 ausgef¨ uhrt. In der n¨achsten Periode ist es der Zeitpunkt 8, ab dem Prozess 1 auf Prozessor 1 ausgef¨ uhrt wird.


W¨ ahrend f¨ ur Einprozessorsysteme FRM S ⊂ FEDF = FLLF gilt, sind die brauchbaren Prozessmengen bei den Verfahren EDF und LLF angewandt auf Mehrprozessorsystemen unterschiedlich. Dies macht das folgende Beispiel deutlich: 4.2.2

Beispiel 4.2.2 Betrachtet werden die Kombinationen (LLF, P RM ) und (EDF, P rM ). Gegeben sei die Prozessmenge P = {1, 2, 3} bei m = 2 Prozessoren und den Prozessparametern:

P 1 2 3 Es gilt unmittelbar: P ∈ FLLF,P rM

∆e 2 2 2

∆p 3 3 3

4.2

Planung bei Mehrprozessorsystemen

235

Nach jeweils ∆tG erfolgt eine neue Berechnung der Priorit¨aten, um die jeweils beiden h¨ ochstpriorisierten Prozesse auf den vorhandenen Prozessoren auszuf¨ uhren. Eine vergleichbare Auswahl der Prozesse findet zwar auch bei der Kombination (EDF, P rM ) statt, gilt dann jedoch f¨ ur die gesamte Ausf¨ uhrung. So ergibt sich, dass einer der drei Prozesse fr¨ uhestens zum Zeitpunkt 2 starten
kann und seine Frist verletzt. Also gilt: P ∈ FEDF,P rM Von RMS u ur Ein- und ¨ber EDF bis hin zu LLF unterliegt die Planung f¨ Mehrprozessorsysteme immer weniger Einschr¨ankungen. Bezogen auf einen festen Grad der Migration von Prozessen herrscht deshalb eine einfache und einsichtige Inklusionsbeziehung (vgl. [29]): FRM S,X ⊂ FEDF,X ⊂ FLLF,X

X ∈ {N oM, ExM, P rM }

Betrachtet man hingegen mehrere Grade der Migration von Prozessen, dann findet sich keine gleichermaßen einfache Inklusionsbeziehung. So kann es sein, dass bei einem Planungsverfahren A und zwei Graden B1 und B2 der Miullt ist. gration weder FA,B1 ⊂ FA,B2 noch FA,B2 ⊂ FA,B1 erf¨ Beispiel 4.2.3 Zwei Prozessmengen P und Q werden miteinander verglichen.

Zun¨ achst wird die Prozessmenge P = {1, 2, 3} bei m = 2 Prozessoren und den folgenden Prozessparametern betrachtet: P 1 2 3

∆e 3 3 6

∆p 6 6 7

Unter der Kombination (RM S, N oM ) l¨ asst sich die Prozessmenge so partitionieren, dass die Prozesse 1 und 2 auf dem Prozessor 2 und Prozess 3 auf dem Prozessor 1 ausgef¨ uhrt wird. Es gibt keine Fristverletzung:

4.2.3

236

4. Fortgeschrittene Planungsverfahren

Unter der Kombination (RM S, ExM ) sind die beiden Prozesse 1 und 2 zum Zeitpunkt 6 bereit und erhalten die Prozessoren 2 und 1. Prozess 3 wird deshalb seine Frist verletzen. Somit gilt: P ∈ FRM S,N oM und P ∈ FRM S,ExM F¨ ur eine andere Prozessmenge Q = {1, 2, 3} wird sich die umgekehrte Beziehung ergeben: Q ∈ FRM S,N oM und Q ∈ FRM S,ExM . Sei m = 2 und Q haben die Prozessparameter: P 1 2 3

∆e 1 2 2

∆p 2 3 3

Bei der Kombination (RM S, ExM ) ergibt sich ein brauchbarer Plan:

Ein solcher Plan kommt nur deshalb zustande, weil Prozess 1 einmal auf dem Prozessor 2 und dann zweimal auf dem Prozessor 1 ausgef¨ uhrt wird. W¨ urde man die Prozesse partitionieren, wie es die Kombination (RM S, N oM ) verlangt, dann g¨ abe es immer ein Paar von Prozessen, das auf einem Prozessor ausgef¨ uhrt wird und dessen Auslastung U gr¨oßer als 1 wird.
Eine Betrachtung aller Beziehungen von Kombinationen (A, B) ist sehr aufw¨ andig und l¨ asst nur wenige generalisierende Aussagen zu. Eine davon ist jedoch besonders wichtig. Sie besagt, dass die Kombination (LLF, P rM ) die gr¨ oßte Menge von Prozessmengen brauchbar einplant: FA,B ⊂ FLLF,P rM

A ∈ {RM S, EDF, LLF }, B ∈ {N oM, ExM, P rM }

Aus diesem Grunde wird die Kombination (LLF, P rM ) in den folgenden Unterabschnitten weiter verfolgt. 4.2.2 Optimalit¨ at proportional fairer Planungsverfahren

¨ Die nachfolgenden Uberlegungen gehen davon aus, dass f¨ ur jeden Prozess i eiullt ist, und die Ausner Prozessmenge P die Bedingung 0 < ∆pi /∆ei ≤ 1 erf¨ lastung die Zahl der Prozessoren nicht u ¨bersteigt: U ≤ m. Unter diesen Voraussetzungen besitzt die Prozessmenge P in der Kombination (LLF, P rM ) einen brauchbaren Plan s. Die Existenz des Planes s wird in diesem Unterabschnitt auf konstruktivem Wege bewiesen. Die Konstruktion beschreibt eine

4.2

Planung bei Mehrprozessorsystemen

237

Klasse FP F AIR von Planungsverfahren, die als proportional faire Planungsverfahren bezeichnet werden. Definition 4.2.1 Ein Plan s f¨ ur ein Mehrprozessorsystem ist eine Abbildung,

4.2.1

die aussagt, ob ein Prozess in einem Intervall der L¨ange der Bezugszeitspanne ∆tG rechnet oder nicht: s : P × N → {0, 1} Es gilt: s(i, j) = 1, gdw. Prozess i im j-ten Intervall [j ∆tG , (j + 1)∆tG ) auf einem Prozessor ausgef¨ uhrt wird.
Somit ist s nur dann brauchbar, wenn f¨ ur alle Intervalle j gilt: s(i, j) ≤ m i∈P

Der Gedanke der proportionalen Fairness, oder kurz P-Fairness, wurde entscheidend von Baruah (vgl. [15]) gepr¨ agt. Die P-Fairness zielt darauf ab, die Ausf¨ uhrungszeit ∆ei so gleichm¨ aßig wie m¨ oglich u ¨ber die Periode ∆pi aufzuteilen. F¨ ur die Aufteilung wird die Bezugszeitspanne ∆tG als kleinstm¨ogliche Einheit zugrunde gelegt. Definition 4.2.2 Ein Plan s heißt P-fair, wenn f¨ ur alle i ∈ P und alle j ∈ N0

4.2.2

gilt: −1 < lag(s, i, j) < 1

mit lag(s, i, j) =

∆ei (j + 1) − ∆pi



s(i, k)

k∈{0,...,j}


Beispiel 4.2.4 Gegeben sei ein Prozess i mit der Auslastung ∆ei /∆pi = 5/9.

Gesucht sind m¨ ogliche Anfangsst¨ ucke eines Plans s, in den Prozess i P-fair eingeplant ist. Betrachtet wird zun¨ achst das Intervall j = 0. Beide Alternativen sind P-fair: sa (i, 0) = 0 sb (i, 0) = 1 Bei Alternative sa ist lag(sa , i, 0) = 5/9 − 0 = 5/9 und bei Alternative sb ist lag(sb , i, 0) = 5/9 − 1 = −4/9.

4.2.4

238

4. Fortgeschrittene Planungsverfahren

Verl¨ angert man den Plan um das Intervall j = 1, dann hat man jeweils wieder zwei Alternativen, also insgesamt vier. Diese sind: saa (i, 1) = 0

lag(saa , i, 1) = 10/9 − 0 = 10/9

sab (i, 1) = 1

lag(sab , i, 1) = 10/9 − 1 = 1/9

sba (i, 1) = 0

lag(sba , i, 1) = 10/9 − 1 = 1/9

sbb (i, 1) = 1

lag(sbb , i, 1) = 10/9 − 2 = −8/9

Nur die Alternative saa , bei der der Prozess i in den ersten beiden Bezugszeitspannen nicht eingeplant wird, erf¨ ullt die Kriterien der P-Fairness nicht. Umgekehrt darf der Prozess i in Plan sbb zweimal hintereinander eingeplant werden und der Plan ist noch P-fair.
Da die Ausf¨ uhrungszeit eines Prozesses i in Einheiten der Bezugszeitspanne gemessen wird, ist es naheliegend, den Prozess in li = ∆ei /∆tG Schlitze (engl. slot) aufzuteilen. Jeder Schlitz l ∈ {1, . . . , li } ist bei der Planung wie ein selbstst¨ andiger Prozess, im Weiteren auch Pseudoprozess genannt, zu beugt. trachten, der u ¨ber eine eigene Bereitzeit ri,l und eine eigene Frist di,l verf¨ Aus der Bedingung der P-Fainess l¨ asst sich auf die Anzahl l der Schlitze schließen, die f¨ ur einen Prozess i, angefangen vom 0-ten bis einschließlich zum j-ten Intervall einer Periode ∆pi , bereits zugeordnet sind6 : s(i, k) l= k∈{0,...,j}

Es gilt nach Definition: −1 <

∆ei (j + 1) − l < 1 ∆pi

Umgeformt ergibt das:

!   ∆ei ∆ei (j + 1) ≥ l ≥ (j + 1) ∆pi ∆pi

Somit kann die Anzahl der bis zum Intervall j verplanten Ausf¨ uhrungen des Prozesses i nur um 1 schwanken. 6

Betrachtet man die Ausf¨ uhrung von Zeitpunkt 0 an, dann liegt das j-te Intervall in der c-ten Periode des Prozesses i: ric ≤ j < ric+1 . Daraus folgt die verallgemeinerte Beziehung: (c − 1)

∆ei +l = ∆tG

X k∈{0,...,j}

s(i, k)

4.2

Planung bei Mehrprozessorsystemen

239

Vom Standpunkt der Planung aus ist es wichtig, die Prozessparameter der ur den Pseudoprozesse zu kennen, konkret die Bereitzeit ri,l und die Frist di,l f¨ l-ten Schlitz des Prozesses i. Bezogen auf die Bereitzeit ri,l ist der Beginn des fr¨ uhesten Intervalls [j ∆tG , (j + 1)∆tG ) gesucht, in das der l-te Schlitz nach den Regeln der P-Fairness schon eingeplant werden darf: ∆ei (j + 1) > l} ∆pi ∆pi = min{j | j > (l − 1) − 1} ∆ei   ∆pi (l − 1) = ∆ei

ri,l = min{j | 1 +

Bezogen auf die Frist di,l ist das Ende des sp¨atesten Intervalls [j ∆tG , (j + 1)∆tG ) gesucht, in das der l-te Schlitz nach den Regeln der P-Fairness noch eingeplant werden darf. Dies korrespondiert zum maximalen j, bis zu dem es m¨ oglich ist, nur l − 1 Schlitze einzuplanen. di,l − 1 = max{j | l − 1 > −1 +

∆ei j} ∆pi

∆pi = max{j | j < l} ∆ei ! ∆pi l −1 = ∆ei Beispiel 4.2.5 In Fortsetzung von Beispiel 4.2.4 besitzt Prozess i die

4.2.5

uhren. DieAusf¨ uhrungszeit ∆ei = 5. D.h., es sind li = 5 Schlitze auszuf¨ se entsprechen 5 Pseudoprozessen, die u ¨ber eigene Bereitzeiten und Fristen verf¨ ugen, wie die folgende Tabelle und die Abb. 4.7 zeigen. l 1 2 3 4 5

∆pi ∆ei l

9/5 18/5 27/5 36/5 45/5

ri,l 0 1 3 5 7

di,l 2 4 6 8 9


Aufgabe 4.2.1 (siehe Seite 295) In Beispiel 4.2.6 wird der Prozess 3 mit den

Prozessparametern ∆e2 = 4 und ∆p2 = 11 vorkommen. Ermitteln Sie die Pseudoprozesse des Prozesses 2, sowie deren Bereitzeiten und Fristen. Geben

4.2.1

240

4. Fortgeschrittene Planungsverfahren

Abb. 4.7. Prozess i ist aufgespalten in li = 5

Pseudoprozesse mit eigenen Bereitzeiten und Fristen.

Sie einen der m¨ oglichen P-fairen Pl¨ ane f¨ ur den Prozess 2 im Intervall [0, 11) an.
Wie aus dem Beispiel 4.2.5 hervorgeht, wird jedem Schlitz l ein eigenes Zeitfenster zugeordnet. Dabei ist zu beachten, dass sich benachbarte Zeitfenster h¨ ochstens f¨ ur die Dauer einer Bezugszeitspanne ∆tG u ¨berlappen k¨onnen. In solchen F¨ allen gilt: di,l−1 − ri,l = 1

mit i ∈ P und 1 ≤ l ≤ li

¨ Diejenigen l, f¨ ur die eine solche Uberlappung gegeben ist, sind dadurch bestimmt, dass ∆pi l nicht ganzzahlig durch ∆ei teilbar ist. Es ist nun zu zeigen, dass f¨ ur eine Prozessmenge P periodischer unterbrechbarer Prozesse auf einem Mehrprozessorsystem mit m Prozessoren genau dann ein brauchbarer Plan existiert, wenn U ≤ m. Die Notwendigkeit der Aussage ist offensichtlich. Bleibt zu zeigen, dass sie auch hinreichend ist. Ohne Beschr¨ ankung der Allgemienheit wird der Beweis f¨ ur ein Anfangsst¨ uck der uhrt, indem L¨ ange L = kgV {∆p1 , . . . , ∆pn } bei einer Auslastung U = m gef¨ konstruktiv ein P-fairer Plan erzeugt wird. Bei der Beweisf¨ uhrung zum Satz 4.2.1 bedient man sich des aus der Graphentheorie bekannten Problems des maximalen Flusses. Ein Graph G = (V, E) mit gewichteten Kanten besitzt einen Fluss m L genau dann, wenn P mit U = m einen brauchbaren P-fairen Plan s besitzt. Zu diesem Zweck wird abh¨ angig von der Prozessmenge P ein korrespondierender Graph G = (V, E) konstruiert. Die Knotenmenge V besteht aus sechs disjunkten Teilmengen V = V0 ∪ . . . ∪ V5 , wobei V0 = {source} die Quelle und V5 = {sink} die Senke des Flusses bilden. Die weiteren Knotenmengen sind: V1 = {(1, i) | i ∈ P } V2 = {(2, i, l) | i ∈ P und l ∈ {1, . . . , Ri } V3 = {(3, i, j) | i ∈ P und j ∈ {0, . . . , L − 1} V4 = {(4, j) | j ∈ {0, . . . , L − 1}

4.2

Planung bei Mehrprozessorsystemen

241

In diesem Zusammenhang entspricht Ri dem Bedarf an Schlitzen, den Prozess i im Intervall [0, L) hat: Ri =

∆ei L ∆pi

¨ Uber alle Prozesse gilt:

Ri = m L

i∈P

Die Kanten E ⊂ V × V × N0 des Graphen teilen sich in disjunkte Mengen: Ek,k+1 ⊂ Vk × Vk+1 × N0

k ∈ {0, . . . , 4}

Der ganzzahlige Wert im obigen Tripel gibt die Kapazit¨at der jeweiligen Kante an. E0,1 = {(source, (1, i), Ri ) | i ∈ P } E1,2 = {((1, i), (2, i, l), 1) | i ∈ P und l ∈ {1, . . . , Ri }} E2,3 = {((2, i, l), (3, i, j), 1) | i ∈ P und l ∈ {1, . . . , Ri } und j ∈ {ri,l , . . . , di,l − 1}} E3,4 = {((3, i, j), (4, j), 1) | i ∈ P und j ∈ {0, . . . , L − 1}} E4,5 = {((4, j), sink, m) | j ∈ {0, . . . , L − 1}} Man spricht von einem integralen Fluss, wenn auf einer Kante nur ganzzahlige Fl¨ usse stattfinden. Insbesondere eine Kante der Kapazit¨at 1 hat dann ¨ entweder den Fluss 1 oder den Fluss 0. Ubertragen auf Planungsentscheidungen wird eine 1 bezogen auf ein Intervall j so verstanden, dass ein Prozess i uhrt wird. Entspechend steht die 0 f¨ ur im Intervall [j ∆tG , (j + 1)∆tG ) ausgef¨ die gegenteilige Planungsentscheidung. Satz 4.2.1 Wenn Graph G einen integralen Fluss von m L besitzt, dann be-

sitzt die Prozessmenge P einen brauchbaren P-fairen Plan s. Beweis: Die Argumentation folgt Schritt f¨ ur Schritt den Kanten des Graphen G. E0,1 : Der gesamten Fluss m L an der Quelle teilt sich in einen Fluss Ri zu jedem Knoten (1, i), was dem Bedarf an Ausf¨ uhrungszeit des Prozesses i im Intervall [0, L − 1) entspricht. E1,2 : Der Fluss Ri wird u ¨ber die Ri Kanten ((1, i), (2, i, l)) an die Knoten (2, i, l) gef¨ uhrt. Der Fluss von jeweils 1 entspricht der Kapazit¨at der Kanten und damit der Aufteilung der Ausf¨ uhrungszeit von Prozess i in Schlitze der Bezugszeitspanne ∆tG .

4.2.1

242

4. Fortgeschrittene Planungsverfahren

E2,3 : Von den Knoten (2, i, l) geht ein Fluss von 1 aus, der u ¨ber eine der ¨ j ∈ {ri,l , . . . , di,l − 1} Kanten ((2, i, l), (3, i, j)) weitergeleitet wird. Uber jeden der L Knoten (3, i, j) des Prozesses i geht entweder ein Fluss von 1 oder von 0, insgesamt u ¨ber alle j ∈ L ein Fluss von Ri . Ein Knoten (3, i, j) mit einem Fluss von 1 entspricht einer Eintragung s(i, j) = 1 im Plan s. Entsprechendes gilt f¨ ur den Fluss von 0. ¨ Zu beachten ist in diesem Schritt, dass es an den Stellen einer Uberlappung zwei eingehende Kanten in den Knoten (3, i, j) gibt. Das bedeutet, dass h¨ ochstens eine der eingehenden Kanten einen Fluss von 1 beitragen kann. Auf diese Weise wird entschieden, ob ein Schlitz in das Intervall allt und, wenn das der Fall ist, es der Schlitz l − 1 [j ∆tG , (j + 1)∆tG ) f¨ oder l ist. E3,4 und E4,5 : Von der Senke aus betrachtet steht die Leistung m L der m Prozessoren u ¨ber das Intervall [0, L − 1) bereit. Dies entspricht dem Fluss m, der von den L Knoten (4, j) u ¨ber je eine Kante der Kapazit¨at m fließt. Dieser Fluss stammt von den |P | > m Eingangskanten ((3, i, j), (4, j)), die im Einzelnen entweder den Fluss 1 oder 0 besitzen. Dies korrespondiert zur Planungsentscheidung s(i, j). Der so entstandene Plan s ist P-fair und ber¨ ucksichtigt alle Bereitzeiten und Fristen der Prozessmenge P .
Im vorangehenden Satz 4.2.1 wird die Existenz eines integralen Flusses von m L vorausgesetzt. Dass ein solcher Fluss f¨ ur eine Prozessmenge P bei m Prozessoren und U = m existiert, ist ein Bestandteil des Beweises zum folgenden Satz 4.2.2. Dieser Satz birgt die zentrale Aussage zur P-Fairness. 4.2.2

Satz 4.2.2 Zu einer Prozessmenge P existiert bei m Prozessoren genau dann ein brauchbarer P-fairer Plan s, wenn gilt: U ≤ m Beweis: Es ist offensichtlich, dass U ≤ m eine notwendige Bedingung f¨ ur die Existenz eines brauchbaren P-fairen Planes darstellt. Es bleibt der Nachweis zu erbringen, ob diese Bedingung auch hinreichend ist. Dies geschieht in zwei Schritten: (1): F¨ ur eine gegebene Prozessmenge P bei m Prozessoren und U = m wird ein Graph G mit einem reellen Fluss von m L konstruiert. In diesem Zusammenhang bedeutet reeller Fluss, dass f¨ ur jede Kante ein reellwertiger Fluss zwischen 0 und der angegebenen Kapazit¨at erlaubt ist. (2): F¨ ur den gegebenen Graphen G ist der reelle Fluss von m L in einen integralen Fluss zu u uhren. ¨berf¨

4.2

Planung bei Mehrprozessorsystemen

243

Hinsichtlich des Schrittes (2) ist auf einen Satz von Ford und Fulkerson zu verweisen. Dieser besagt, dass bei integralen Kapazit¨aten aus der Existenz eines reellen Flusses die Existenz eines integralen Flusses folgt (vgl. [46]). Entspechend bleibt Schritt (1), der ohne Beschr¨ankung der Allgemeinheit f¨ ur die Auslastung U = m durchgef¨ uhrt wird. Es liegt der Gedanke zugrunde, jedem Prozess i in jedem Intervall j eine Ausf¨ uhrungszeit ∆ei /∆pi zuzuord¨ nen. Ubertr¨ agt man dies auf die Kanten des Graphen G, dann k¨onnen die Kanten E0,1 , E1,2 und E4,5 dieselbe Bewertung u ¨bernehmen wie im integralen Fall, n¨ amlich ihre Kapazit¨ at. Die Kanten E2,3 und E3,4 sind besonders zu betrachten. ¨ Uber einen Knoten (2, i, l) ∈ V2 geht ein Fluss von 1, der sich auf die Kanten ((2, i, l), (3, i, j)), mit j ∈ {ri,l , . . . , di,l − 1}, aufteilen muss. Hierbei ist nun zu unterscheiden, ob ein Zielknoten (3, i, j) zwei (1a) oder einen (1b) Vorg¨ angerknoten hat: ¨ (1a): Es liegt eine Uberlappung vor, d.h., es gilt: ri,l <

∆pi l < di,l−1 ∆ei

In diesem Fall hat Knoten (3, i, j) die Vorg¨angerknoten (2, i, l − 1)) und (2, i, l), die Anteile des Flusses beitragen. Diese Anteile werden davon bestimmt, wo der Quotient (∆pi l)/∆ei das j-te Intervall teilt. Ein Fluss fupper wird der Kante ((2, i, l), (3, i, j)) und ein Fluss flower der Kante ((2, i, l − 1), (3, i, j)) zugeordnet. Die Fl¨ usse errechnen sich so:

!  ∆pi ∆pi ∆ei l − l fupper = ∆ei ∆ei ∆pi

  ∆pi ∆pi ∆ei flower = l− l ∆ei ∆ei ∆pi ¨ (1b): Es liegt keine Uberlappung vor und der Fluss ∆ei /∆pi kann voll der Kante ((2, i, l), (3, i, j)) zugeordnet werden. Auf diese Weise geht u ¨ber jeden Konten (3, i, j) ein Fluss von ∆pi /∆ei . Dies entspricht dem Fluss, mit dem jede Kante ((3, i, j), (4, j)) ∈ E3,4 zu bewerten ist. Summiert man diese Fl¨ usse f¨ ur ein j ∈ {0, . . . , L − 1} u ¨ber alle i ∈ P , so kommt in jedem Intervall j eine volle Auslastung U = m zustande. Die Schritte (1) und (2) schaffen die Voraussetzung, den Satz 4.2.1 anzuwenden, was den Beweis abschließt.
Betrachtet man die Konstruktion basierend auf den reellen und integralen Fl¨ ussen als Verfahren, dann ist der Klasse der P-fairen Planungsverfahren FP F AIR Optimalit¨ at zu bescheinigen. Von praktischem Interesse ist diese

244

4. Fortgeschrittene Planungsverfahren

Konstruktion jedoch nicht, da der Graph G, der zugrunde gelegt wird, O(2n ) Knoten hat und damit kaum zu handhaben ist. Aus diesem Grund ist es sinnvoll, nach effizienteren Verfahren Ausschau zu halten. 4.2.3 Arbeitsweise proportional fairer Planungsverfahren

Allen P-fairen Planungsverfahren ist gemeinsam, dass jeder Prozess i ∈ P in ∆ei /∆tG = li Pseudoprozesse zerlegt wird. Innerhalb der Periode ∆pi des Prozesses i sind l Pseudoprozesse, mit l ∈ {1, . . . , li }, der Reihe nach einzuplanen. Betrachtet man ein beliebiges Intervall [j ∆tG , (j+1)∆tG ), dann liegt dieses in der c-ten Periode des Prozesses i (siehe auch Seite 48): ric ≤ j < ric+1 Entscheidend f¨ ur ein P-faires Planungsverfahren ist die Menge der Pseudoprozesse, die im j-ten Intervall ausgef¨ uhrt werden k¨onnen, d.h. die Menge Ready(j): Ready(j) = {l | mit l bestimmt durch j ∈ {ri,l , . . . , di,l − 1} mit i ∈ P und ∆ei s(i, k) < (c − 1) + l mit ric ≤ j < ric+1 ∆tG

k∈{0,...,j−1}

} Damit enth¨ alt Ready(j) die Schlitze, die im zugeh¨origen Zeitfenster einzuplanen sind, bislang jedoch noch nicht eingeplant wurden. Es ist zu beachten, ¨ dass bei einer Uberlappung auch zwei Schlitze eines Prozesses zur Menge Ready(j) geh¨ oren k¨ onnen. Eingeplant werden darf dann jeweils nur der erste der beiden. Die effizienten Planungsverfahren f¨ ur P-faire Pl¨ane betrachten nacheinander jedes einzelne Intervall j und vergeben f¨ ur jeden Pseudoprozess in Ready(j) eine dynamische Priorit¨ at. Dabei wird so vorgegangen, dass f¨ ur je zwei Pseudoprozesse a, b ∈ Ready(j) die Verh¨ altnisse ihrer Priorit¨aten ermittelt werden: prio(a) > prio(b) oder prio(a) = prio(b) oder prio(a) < prio(b) Die jeweils m h¨ ochstpriorisierten Prozesse werden im Intervall [j ∆tG , (j + ¨ zum EDF-Verfahren wurde 1)∆tG ) eingeplant7 . Aufgrund der Ahnlichkeit f¨ ur diese Art der Planung der Name earliest pseudo deadline first oder EPDF 7

Dies gilt nur mit der Einschr¨ ankung, dass nicht zwei Pseudoprozesse a1 und a2 desselben Prozesses ia in einem Intervall eingeplant werden d¨ urfen.

4.2

Planung bei Mehrprozessorsystemen

245

gepr¨ agt. Die einzelnen Planungsverfahren dieser Klasse von Verfahren unterscheiden sich aufgrund der Kriterien, nach denen die Priorit¨aten vergeben werden. Das bekannteste dieser Planungsverfahren ist das PF-Verfahren, das stellvertretend n¨aher erl¨ autert wird. Die Kriterien, nach denen beim PF-Verfahren aus der Menge Ready(j) die m Prozesse h¨ ochster Priorit¨ at bestimmt werden, gen¨ ugen verschiedenen nacheinander zu pr¨ ufenden Bedingungen. F¨ ur zwei Pseudoprozesse a, b ∈ Ready(j) gilt prio(a) > prio(b), wenn eine der drei Bedingungen (a), (b) oder (c) zutrifft: (a): Die Frist des Pseudoprozesses a ist k¨ urzer als die von Pseudoprozess b: dia ,a < dib ,b Dabei ist a ein Pseudoprozess des Prozesses ia ∈ P und b ein Pseudoprozess von Prozess ib ∈ P . (b): Ist dia ,a = dib ,b , dann wird es entscheidend, ob am Ende des Zeitfens¨ ters f¨ ur Schlitz a eine Uberlappung vorliegt. Ist das der Fall, dann steht Schlitz a in Konkurrenz zu seinem nachfolgenden Pseudoprozess. Entsprechend ist seine Priorit¨ at h¨ oher zu bewerten. Diese Bewertung geschieht mithilfe der Funktion overlap: overlap : N → {0, 1} Es gilt overlap(l) = 1, gdw. der Quotient (∆pi l)/∆ei einen ganzzahligen Wert ergibt. Basierend darauf lautet die Bedingung: dia ,a = dib ,b und overlap(a) > overlap(b) (c): Statt der Bedingung (b) kann Folgendes gelten: dia ,a = dib ,b und overlap(a) = 1 und overlap(b) = 1 Dann greift ein Kriterium, das die jeweils n¨achsten Schlitze von a und b betrachtet. Weil die Funktion overlap beide Male den Wert 1 liefert, gibt es sowohl f¨ ur a als auch f¨ ur b ein Zeitfenster f¨ ur den n¨achsten Schlitz, der noch in derselben Periode der Prozesse ia und ib liegt. Sei nextslot(l) die partielle Funktion, die f¨ ur l ≤ li den jeweils n¨achsten Schlitz liefert. Dann lautet die zu pr¨ ufende Bedingung: dia ,a = dib ,b und overlap(a) = 1 und overlap(b) = 1 und prio(nextslot(a)) > prio(nextslot(b))

246

4. Fortgeschrittene Planungsverfahren

Die Bedingung (c) ist rekursiv, aber endlich, da sie maximal solange anwendbar ist, wie noch Schlitze in einer Periode vorhanden sind. Ist keine der Bedingungen (a) bis (c) anwendbar, dann werden die Priorit¨aten gleichgesetzt: prio(a) = prio(b) Auf diese Weise sind die Priorit¨ aten zwischen Pseudoprozessen eindeutig festgelegt und k¨ onnen f¨ ur das PF-Verfahren herangezogen werden. 4.2.1

Verfahren 4.2.1 Die Funktion M axP rio w¨ ahlt nach den Bedingungen (a) bis

(c) bis zu m Prozesse h¨ ochster Priorit¨ at aus. Darauf aufbauend arbeitet das PF-Verfahren in einer Schleife: schedule(P L, P, m):: P L = <>; j = 0; WHILE j < L DO BEGIN P L = P L∧ M axP rio(Ready(j), m); j = j + 1; END
4.2.6

Beispiel 4.2.6 Das PF-Verfahren wird nun auf 4 periodische unterbrechbare Prozesse P = 1, 2, 3, 4 bei 2 Prozessoren angewandt. Gegeben seien die Prozessparameter:

P 1 2 3 4

∆ei 3 4 4 3

∆pi 17 11 6 4

Die Auslastung ist mit U = 3/17 + 4/11 + 4/6 + 3/4 ≈ 1, 956 bei weniger als 2. Damit gibt es einen brauchbaren P-fairen Plan. Zun¨ achst werden alle Pseudoprozesse mit ihren Zeitfenstern, in die die Schlitze unterzubringen sind, bestimmt: l 1 2 3 4

r1,l 0 5 11 -

d1,l 6 12 17 -

r2,l 0 2 5 8

d2,l 3 6 9 11

r3,l 0 1 2 4

d3,l 2 3 5 6

r4,l 0 1 2 -

d4,l 2 3 4 -

4.2

Planung bei Mehrprozessorsystemen

247

Insgesamt sind damit 14 Pseudoprozesse zu verplanen. Mit 23 ist beispielsweise der Pseudoprozess des Prozesses 2 gemeint, der seinen Schlitz l = 3 innerhalb der Periode der L¨ ange 11 im Zeitfenster [5, 9) unterbringen muss. Das bedeutet, dass die Ausf¨ uhrung des Schlitzes in einem der Intervalle j = 5, j = 6, j = 7 oder j = 8 stattfinden muss. Die Erstellung eines P-fairen Planes startet bei j = 0 und beginnt mit der Berechnung von Ready(0) = {11 , 21 , 31 , 41 }. Diese vier Pseudoprozesse sind ihren Priorit¨ aten gem¨ aß zu ordnen, wobei zwischen 11 und 41 die Bedingung (a) bereits gen¨ ugt, um festzustellen, dass gilt: prio(41 ) > prio(11 ). Zwischen den Pseudoprozessen 41 und 31 ist die Bedingung (a) jedoch nicht mehr hinreichend. Hier greift rekursiv zweimal die Bedingung (c) und dann die Bedingung (a). Denn es gilt: d4,43 < d3,33 Daraus wird gefolgert: prio(41 ) > prio(31 ). Insgesamt ergibt sich f¨ ur die Pseudoprozesse, die das 0-te Intervall belegen k¨ onnen, folgende Priorit¨atenfolge: prio(41 ) > prio(31 ) > prio(21 ) > prio(11 ) Aus diesem Grunde werden von der Funktion M axP rio die Pseudoprozesse 41 und 31 in den Plan aufgenommen. F¨ ur j = 1 berechnet sich die Menge ready(1) = {11 , 21 , 42 , 32 }. Dabei ergeben sich die Priorit¨ aten: prio(42 ) > prio(32 ) > prio(21 ) > prio(11 ) Somit werden wieder Pseudoprozesse der Prozesse 4 und 3, n¨amlich 42 und 32 , in den Plan aufgenommen. Im Weiteren ergeben sich folgende Mengen Ready(j) und entsprechende Folgen von Priorit¨aten: Ready(2) = {11 , 21 , 43 , 33 , 22 } prio(21 ) > prio(43 ) > prio(33 ) > prio(22 ) > prio(11 ) Ready(3) = {11 , 33 , 22 } prio(33 ) > prio(22 ) > prio(11 ) Ready(4) = {11 , 41 , 34 } prio(41 ) > prio(11 ) > prio(34 ) In der obigen Priorit¨ atsberechnung greift zum ersten Mal die Regel (b). Pseudeoprozesse 11 und 34 haben dieselbe Frist. Dennoch wird 11 vorge¨ zogen, weil er eine Uberlappung mit dem nachfolgenden Pseudoprozess 12

248

4. Fortgeschrittene Planungsverfahren

hat: overlap(11 ) = 1 und overlap(34 ) = 0. Ready(5) = {34 , 42 , 23 , 12 } prio(34 ) > prio(42 ) > prio(23 ) > prio(12 ) Ready(6) = {23 , 12 , 43 , 31 } prio(31 ) > prio(43 ) > prio(23 ) > prio(12 ) Ready(7) = {23 , 12 , 32 } prio(32 ) > prio(23 ) > prio(12 ) Ready(8) = {12 , 41 , 33 , 24 } prio(41 ) > prio(33 ) > prio(24 ) > prio(12 ) Ready(9) = {24 , 12 , 42 } prio(42 ) > prio(24 ) > prio(12 ) Ready(10) = {12 , 43 , 34 } prio(12 ) > prio(43 ) = prio(34 ) In der obigen Priorit¨ atsberechnung greift zwischen 43 und 34 keine der Regeln (a), (b) oder (c), was dazu f¨ uhrt, deren Priorit¨aten gleichzusetzen. Entsprechend kann entweder 43 oder 34 in den Plan aufgenommen werden (siehe Abb. 4.8).

Abb. 4.8. Bis zum Beginn des 11-ten Intervalls entsteht mit dem PF-Verfahren ein Plan,

der die beiden Prozessoren voll auslastet. Dabei sind nur noch die Prozesse vermerkt, nicht mehr die Pseudoprozesse, wie sie f¨ ur die Konstruktion des Planes notwendig sind.


4.2.3

Satz 4.2.3 Das PF-Verfahren ist optimal. Beweis: Aus dem Satz 4.2.2 geht hervor, dass f¨ ur eine Prozessmenge P bei m

Prozessoren und U ≤ m ein brauchbarer P-fairer Plan existiert. Es bleibt zu zeigen, dass jeder brauchbare P-faire Plan in einen Plan umgeformt werden kann, der vom PF-Verfahren erzeugt wird. Gegeben sei also ein brauchbarer P-fairer Plan s, der nicht so aufgebaut ist, wie das PF-Verfahren Pl¨ ane erzeugt. Somit gibt es ein Intervall ur zwei Pseudoprozesse a, b ∈ Ready(j) die Be[j ∆tG , (j + 1)∆tG ), zu dem f¨ dingung prio(a) > prio(b) erf¨ ullt ist, b jedoch im Intervall j und a im Intervall  j > j eingeplant ist. Ein solche Fehlstelle wird durch Vertauschung beseitigt,

4.2

Planung bei Mehrprozessorsystemen

249

indem a ins Intervall j und b ins Intervall j  wechselt. Der so gewonnene Plan s ist bezogen auf diese Fehlstelle konform mit dem PF-Verfahren. Es bleibt nachzuweisen, dass er auch brauchbar und P-fair ist. Dies ist f¨ ur jede der Bedingungen (a) bis (c), aufgrund derer prio(a) > prio(b) erf¨ ullt sein kann, nachzuweisen. Dazu sei ohne Beschr¨ ankung der Allgemeinheit das Intervall j das gr¨ oßte mit einer Fehlstelle. Zu (a): Es gilt dia ,a < dib ,b und a war in s fristgerecht eingeplant. Somit wird b in s fristgerecht eingeplant sein, denn b liegt vor dia ,a und erst recht vor dib ,b . Zu (b): Es gilt dia ,a = dib ,b . Wie in (a) ist auch b in s fristgerecht eingeplant. Wegen overlap(b) = 0 k¨ onnen im Intervall j  nicht zwei Pseudoprozesse des gleichen Prozesses ib eingeplant sein. Zu (c): Es gilt wie bei (b), dass b in s fristgerecht eingeplant wird. Es kann jedoch wegen overlap(b) = 1 sein, dass nextslot(b) auch im selben Intervall j  eingeplant ist. Entsprechend war a in s im Intervall j  eingeplant. Es sind zwei M¨ oglichkeiten zu bedenken: (c1): Auch nextslot(a) ist im Intervall j  . Dies widerspricht der PFairness von s. (c2): nextslot(a) ist im Intervall j  > j  eingeplant. So existiert im ur j angenommen wurde. j  -ten Intervall eine Fehlstelle, wie sie schon f¨ Dies widerspricht der Annahme, dass j die gr¨oßte Fehlstelle ist. Das bedeutet, dass es kein j  > j mit einer Fehlstelle gibt.

Es ist zu beachten, dass durch die Vertauschung a an eine Position gelangen kann, wo sich zwei Zeitfenster von Pseudoprozessen u ¨berlappen. Ist an dieser Position bereits sein Vorg¨ anger eingeplant, dann ist a mit einem Schlitz im Intervall j + 1 zu vertauschen, wie es durch das PF-Verfahren auch geschehen w¨ urde. So wird eine Fehlstelle nach der anderen beseitigt, bis ein Plan entsteht, der vom PF-Verfahren erzeugt sein kann.
Der Aufwand des PF-Verfahrens ist nicht unerheblich und bei geeigneter Implementiertung pro Intervall von der Ordnung O(mlogn) (vgl. [7]). Zu bem¨ angeln ist, dass die Zahl der Prozessumschaltungen und der Migration von Prozessen sehr hoch ist. Von einer Bezugszeitspanne zur n¨achsten kann es zu einer Prozessumschaltung und zu einer Migration von Prozessen kommen. Weiterentwicklungen des PF-Verfahrens ber¨ ucksichtigen die genannten M¨ angel (vgl. [7]).

250

4.3

4. Fortgeschrittene Planungsverfahren

4.3 Planung in verteilten Systemen Im Unterabschnitt 2.5.4 wurden die technischen Eigenschaften von verteilten Systemen auf der Grundlage der eingesetzten Rechnernetze behandelt. Dabei sind die Zugriffsprotokolle als herausragendstes Kriterium zur Unterscheidung ihrer zeitlichen Vorhersagbarkeit erkannt worden. Entsprechend wird in diesem Abschnitt zun¨ achst versucht, einheitliche Bedingungen zur Bewertung verschiedener Kategorien von Zugriffsprotokollen zu schaffen (siehe Unterabschnitt 4.3.1), um diese dann eingehend zu analysieren (siehe Unterabschnitte 4.3.2, 4.3.3 und 4.3.4). 4.3.1 Kriterien der Vergleichbarkeit von Zugriffsprotokollen

Die Modellbildung f¨ ur verteilte Systeme (siehe Unterabschnitt 2.5.4) geht davon aus, dass f¨ ur einen Knoten N Dk,j im Rechnernetz CNk ein Prozess Sk,j f¨ ur die Versendung aller hk,j Rahmen zust¨andig ist. Ein einzelner Rahmen alt Informationen, die den aktuellen ZuF Rk,j,h , mit h ∈ {1, ..., hk,j }, enth¨ uberg¨ange im Knoten N Dk,j stand des Knotens N Dk,j reflektieren. Zustands¨ kommen folgendermaßen zustande: unmittelbare Zustands¨ uberg¨ ange des Knotens N Dk,j , beispielsweise bei der Erfassung des technischen Systems durch das Messsystem, mittelbare Zustands¨ uberg¨ ange durch den Empfang eines Rahmens, den ein anderer Knoten des Rechnernetzes CNk gesendet hat. In beiden F¨ allen interessiert die Zeitspanne, die vergeht, bis ein Zustands¨ ubergang, der bei einem Knoten aufgetreten ist, einem anderen Knoten angezeigt wird. Auf der Grundlage des Aufbaues eines verteilten Systems (siehe Abb. 4.9) sind folgende Schritte zur¨ uckzulegen: 1. Ein Zustands¨ ubergang findet statt. Ein Anwendungsprozess Pk,j,i nimmt den Zustand¨ ubergang wahr und gibt eine Beauftragung zu einer entspre¨ chenden Ubertragung eines Rahmens, der diesen Zustands¨ ubergang widerspiegelt, an den Sendeprozess Sk,j . 2. Der Sendeprozess Sk,j , der alle Rahmen, die Knoten N Dk,j versendet, aufbaut und verwaltet, u ¨bergibt den (oder die) jeweils n¨achsten Rahmen an den Bus-Controller. 3. Der Bus-Controller f¨ uhrt das Zugriffsprotokoll aus und versendet die Rahmen, die gegebenenfalls in verschiedenen Empfangspuffern unterschiedlicher Knoten ankommen werden und den jeweiligen Empfangsprozessen zur weiteren Verarbeitung bereitstehen. Auf einen Zustands¨ ubergang hin wird die Folge der Schritte 1., 2. und 3. als Antwortzeit eines Rahmens verstanden (vgl. [34]). Die Ende-zu-EndeAnwortzeit u ¨ber verschiedene Rechnetze hinweg baut sich aus den Antwort-

4.3

Planung in verteilten Systemen

251

Abb. 4.9. Schematischer Aufbau eines verteilten Systems bestehend aus mehreren

Rechnernetzen.

zeiten f¨ ur einzelne Rahmen auf. Letztere soll zur vergleichenden Bewertung unterschiedlicher Rechnernetze herangezogen werden. Dies ist aufgrund ¨ der Tatsache, dass vor der Ubertragung des Rahmens noch verschiedene Prozesse im Senderknoten ablaufen m¨ ussen, ohne weitere Annahmen u ¨ber die Ausf¨ uhrung dieser Prozesse nicht durchf¨ uhrbar. Gleichzeitig gilt, dass bestimmte Zugriffsprotokoll eine korrespondierende Steuerung der Prozessausf¨ uhrung nahelegen. Dies wird nun in Abh¨ angigkeit von den Zugriffsprotokollen diskutiert. Die vier Klassen von Zugriffsprotokollen (A), (B), (C) und (D) werden nun hinsichtlich der Schritte 1., 2. und 3. bewertet und eingeordnet. Dabei weisen die Protokolle (A) und (D) trotz v¨ ollig unterschiedlicher Anwendungsfelder strukturelle Gemeinsamkeiten auf. W¨ ahrend bei (D) das Zugriffsprotokoll im engeren Sinn zeitgesteuert ist, ist dies bei (A) nicht von vorn herein gegeben, l¨asst sich jedoch erreichen, indem der Masterknoten in festen Zyklen seine Slaveknoten zum Versenden von Rahmen auffordert. Entsprechend sind alle Anwendungsprozesse sowie der Sende- und der Empfangeprozess einer zeitgesteuerten Prozessausf¨ uhrung zu unterziehen, wie sie beispielsweise durch die zyklische Prozessausf¨ uhrung gegeben ist. Das Zugriffsprotokoll der Klasse (B) vereinigt den ereignisgesteuerten Zugriff des Bus-Controllers mit der priorit¨ atsbasierten Vergabe des Busses an einen Rahmen fester Priorit¨ at. Im Sinne der holistischen Planung entspricht ¨ die Ubertragung eines Rahmens der Ausf¨ uhrung eines sporadischen, nicht unterbrechbaren Prozesses fester Priorit¨ at. Dies f¨ ugt sich nahtlos zu einem atsbasierter Prozessausf¨ uhrung, wobei der SendeKnoten N Dk,j mit priorit¨ prozess Sk,j und der Empfangeprozess Rk,j eine h¨ohere Priorit¨at aufweisen als alle Anwendungsprozesse.

252

4. Fortgeschrittene Planungsverfahren

Schließlich umfasst Klasse (C) alle markengesteuerten Zugriffsprotokolle. Bei ¨ ihnen m¨ ussen f¨ ur die Ubertragung eines Rahmens zwei Ereignisse zusammentreffen: das Eintreten eines Zustands¨ ubergangs und damit verbunden die Bereitschaft des Knotens, einen Rahmen versenden zu wollen und das Eintreffen einer Marke, die die Berechtigung zum Zugriff auf den Bus darstellt. W¨ urde dabei die Marke von den Knoten nach festen Zeitabst¨anden weitergereicht, dann fiele das Zugriffsprotokoll (C) mit der Klasse bestehend aus (A) und (D) zusammen. Umgekehrt verl¨ ore dieses Zugriffsprotokoll jede Vorhersagbarkeit, wenn keine Frist f¨ ur den Besitz einer Marke vorgegeben w¨are. In den folgenden Unterabschnitten werden f¨ ur die Klassen (A)+(D), f¨ ur (B) und f¨ ur (C) die Antwortzeiten f¨ ur Rahmen berechnet. Dabei ist die ¨ Ubertragungszeit des Rahmens auf dem Medium (entspricht dem letzten Teil von Schritt 3.) immer nach dem gleichen Muster aufgebaut und wird bestimmt durch: ∆tSig Signallaufzeit, d.h. die Zeitspanne f¨ ur die Ausbreitung des Signals auf dem Bus. ¨ ∆tBit Sendedauer eines Bits, die sich aus dem Kehrwert der Ubertragungsrate multipliziert mit einem Bit errechnet. Bitsh Anzahl der Bitstellen, die f¨ ur einen Rahmen h verschickt werden. ¨ Damit ergibt sich f¨ ur die Ubertragung des Rahmens h eine Ausf¨ uhrungszeit: ∆eh = Bitsh ∆tBit + ∆tSig ¨ Bei Rechnernetzen mit Ausdehnungen im Meterbereich und Ubertragungsraten von bis zu einem M Bit/s ist die Signallaufzeit unter der Sendedauer eines Bits und kann vernachl¨ assigt werden. Dies gilt nicht mehr ¨ f¨ ur hohe Ubertragungsraten und Rechnernetze mit einer gr¨oßeren Aus¨ dehnung. So sind bei einer Ubertragungsrate von einem GBit/s auf je¨ dem Meter des Ubertragungsmediums etwa 3 Bits unterwegs, so dass das ¨ Ubertragungsmedium auch einen Datenspeicher bildet. ¨ Die Ubertragungszeit ist immer Bestandteil des Schrittes 3., aber nicht ausschließlich. Hinzukommt davor eine Zeitspanne ∆wh , die der Bus-Controller ¨ ben¨ otigt, um in den Besitz des Busses zu kommen und die Ubertragung des Rahmens h beginnen zu d¨ urfen. Diese wird auch als Wartezeit auf den BusController bezeichnet. Schließlich wird mit ∆t12h die Zeitspanne bezeichnet, die der Anwenur die Erfassung der Zudungsprozess Pk,j,i und der Sendeprozess Sk,j f¨ stands¨ anderung und die Aufbereitung des Rahmens f¨ ur den Bus-Controller

4.3

Planung in verteilten Systemen

253

ben¨ otigen. Dies entspricht den Schritten 1. und 2., die zusammen mit 3. die Antwortzeit eines Rahmens h ergeben: ∆ah = ∆t12h + ∆wh + ∆eh Hierbei ist zu beachten, dass Zugriffsprotokolle der Klassen (A) und (D) einen Rahmen sofort u onnen, wenn der Sendeprozess den Rahmen ¨bertragen k¨ zeitnah bereitstellt. Dies bedeutet bezogen auf obige Formel, dass gilt: ∆wh = 0 Bei den anderen Zugriffsprotokollen ist ∆wh eine Gr¨oße, die erheblichen Schwankungen unterliegen kann. Dies gilt ebenso f¨ ur die Zeitspanne ∆t12h , die vom Zeitpunkt der Zustands¨ anderung bis zum Ende der Schritte 1. und 2. dauert. Die Zeitspanne, um die ∆t12h variieren kann, wird als Flattern bei der Bereitstellung des Rahmens h bezeichnet und als ∆jh notiert (sp¨ater in Abb. 4.11 dargestellt als Differenz ∆t12h,max und ∆t12h,min ). 4.3.2 Zeitgesteuerte Zugriffsprotokolle

In diesem Unterabschnitt werden die Zugriffsprotokolle nach dem zentralisierten Verfahren (A) und dem Zeitmultiplex-Verfahren (D) zusammengefasst. Letzteres ist durch die zeitliche Gliederung in Zyklen, Runden und Schlitze gekennzeichnet (siehe Seite 146). Diesen Gr¨ oßen sind Zeitspannen zugeordnet, f¨ ur die gilt: ∆tslot ≤ ∆trnd ≤ ∆tcyc Auch f¨ ur die Zugriffsprotokolle der Klasse (A) l¨asst sich durch eine entsprechende zeitgesteuerte Prozessausf¨ uhrung eine Gliederung in Zyklen, Runden und Schlitze erreichen. Auf diesem Weg k¨onnen beide Klassen von Zugriffsprotokollen in gleicher Weise analysiert werden. ¨ Die Schlitze sind so zu bemessen, dass ihre Dauer f¨ ur die Ubertragung eines Rahmens ausreicht. Konkret bedeutet dies f¨ ur einen Rahmen F Rk,j,h , der von Knoten N Dk,j im Rechnernetz CNk gesendet wird: ∆eh ≤ ∆tslot Ein Rahmen, h wird u ¨blicherweise mit einer bestimmten Periode ∆ph verschickt. Dabei gilt, dass die Runde ∆trnd die Periode ∆ph teilt und die Periode ∆ph den Zyklus ∆tcyc teilt: vh wh ∆trnd = wh ∆ph = ∆tcyc

vh , wh ∈ N

Damit bezeichnet vh ∆trnd einen Teilzyklus, in dem genau einmal ein Rahmen h gesendet wird. Gesucht wird f¨ ur einen solchen Teilzyklus die minimale

254

4. Fortgeschrittene Planungsverfahren

und die maximale Antwortzeit auf eine Zustands¨anderung, die von Rahmen h erfasst worden ist und verbreitet werden soll. Dabei erfolgt die Erfassung der Zustands¨ anderung in den Schritten 1. und 2. (siehe Seite 250) und ben¨otigt die Ausf¨ uhrung eines entsprechenden Anwendungsprozesses i und des Sendeprozesses s, was jeweils ∆ei und ∆es dauert. Aufgrund der zeitgesteuerten Ausf¨ uhrung k¨ onnen beide Prozesse zeitlich fest angeordnet werden. G¨ unstig ¨ ist eine Ausf¨ uhrung von Sendeprozess s unmittelbar vor der Ubertragung des Rahmens durch den Bus-Controller. Des Weiteren ist es zweckm¨aßig, den Anwendungsprozess i zeitnah vor s auszuf¨ uhren. Eine Zustands¨ anderung kann selbst periodischer Natur sein, beispielsweise das Abtasten eines Videosignals. Liegt die Zustands¨anderung unmittelbar vor der Erfassung durch Prozess i und folgt dicht darauf der Sendeprozess s ¨ und die Ubertragung des Rahmens, dann ergibt sich so die minimal m¨ogliche Antwortzeit von: ∆ah = ∆ei + ∆es + ∆eh Wesentlich h¨ oher wird die Antwortzeit, wenn die Zustands¨anderung jederzeit stattfinden kann. Der ung¨ unstigte Fall ergibt sich, wenn der Prozess i gerade angelaufen ist und den alten Zustand aufgezeichnet hat, wenn die Zustands¨ anderung eintritt. Dann vergeht die Zeitspanne vh ∆trnd , bis Prozess i erneut anl¨ auft und die Zustands¨ anderung erfasst. Ist Prozess i im Teilzyklus ung¨ unstig platziert, dann kann es noch einmal bis zu vh ∆trnd dauern, bis ¨ der Sendeprozess s endet und die Ubertragung des Rahmens beginnt. Somit ist die maximale Antwortzeit: ∆ah = 2 vh ∆trnd + ∆eh Dies suggeriert ein Flattern in der Gr¨ oßenordung der Differenz der maximalen und der minimalen Antwortzeit. Gl¨ ucklicherweise trifft das jedoch nicht zu, wenn die Anordnung der Prozesse innerhalb von Teilzyklen immer gleich ist (siehe Abb. 4.10). In diesem Fall reduziert sich das Flattern auf: ∆jh = vh ∆trnd 4.3.3 Arbitrierende Zugriffsprotokolle

Sind in einem Rechnernetz CNk mehrere Rahmen gleichzeitig zu verschicken, dann bevorzugt ein arbitrierendes Zugriffsprotokoll den Rahmen mit der h¨ ochsten Priorit¨ at. Entsprechend bezeichnet hpk (h) diejenige Menge von ohere Priorit¨at wie Rahmen h haben: Rahmen im Rechnernetz CNk , die eine h¨  F Rk,j | prio(h ) > prio(h)} hpk (h) = {h ∈ j∈{1,...,mk }

4.3

Planung in verteilten Systemen

255

¨ Abb. 4.10. Zeitgesteuerte Ausf¨ uhrung der Prozesse und zeitgesteuerte Ubertragung von Rahmen. Je nachdem, ob eine Zustands¨ anderung kurz vor oder kurz nach Beginn der Ausf¨ uhrung von Prozess i stattfindet, bedingt das Ausmaß das Flatterns der Gr¨ oße vh ∆trnd .

Die folgenden Ausf¨ uhrungen beziehen sich auf das Rechnernetz CNk , so dass der Index k weggelassen und nur noch hp(h) geschrieben wird. Ausl¨ oser f¨ ur das Versenden eines Rahmens durch Knoten N Dk , j sind Zustands¨ uberg¨ ange, die vorhersagbar oder unverhofft eintreten. Dabei soll gelten, dass der Mindestabstand zwischen zwei Zustands¨anderungen ∆ph ist. Im Anschluss daran sollen bis zur Bereitstellung des Rahmens zur Versendung durch den Bus-Controller (siehe Schritte 1. und 2., Seite 250) abh¨angig von der Auslastung des Knotens ∆t12h,min bis ∆t12h,max Zeiteinheiten vergehen. Das bedeutet, dass folgendes Flattern m¨ oglich ist: ∆jk = ∆t12h,max − ∆t12h,min Somit unterliegt die Beauftragung des Bus-Controllers der Periodizit¨at ∆ph , kann aber aufgrund des Flatterns auf den Mindestabstand ∆ph − ∆jh schrumpfen (siehe Abb. 4.11).

Abb. 4.11. Maximale Schwankung des Abstandes zwischen zwei Versuchen des

Bus-Controllers, einen Rahmen h zu u ¨ bertragen.

256

4. Fortgeschrittene Planungsverfahren

¨ F¨ ur die Definition der Brauchbarkeit eines Planes zur Ubertragung von Rahmen spielt die Periode ∆ph eine entscheidende Rolle. So ist Rahmen h brauchbar einplanbar, wenn es gelingt, ihn in jeder Periode ∆ph zu versenden. Im Sinne der holistischen Planung sollte ein ¨ahnliches Verfahren wie bei der Verplanung von Prozessen (siehe Unterabschnitt 3.3.1) mit festen Priorit¨aten praktikabel sein. Entsprechend spielt auch hier der kritische Zeitpunkt, bei dem alle Beginnzeitpunkte aller Rahmen zusammenfallen, eine herausragende Rolle. Entsprechend wurde geschlossen, dass es zum Nachweis der Brauchbarkeit hinreichend ist, den Rahmen h in seiner ersten Periode ohne Fristverletzung senden zu k¨ onnen (vgl. [133] und [60]). Dieser Ansatz zum Nachweis der Brauchbarkeit wurde mehr als ein Jahrzehnt praktiziert, ohne einen grundlegenden Fehler zu bemerken. Ein solcher kann sich jedoch unter gewissen Umst¨ anden ergeben. Die Ursache des Fehlers liegt darin, dass die etablierte Methode der Verplanung nach festen Priorit¨ aten zugrunde gelegt wurde, obwohl diese nur f¨ ur un¨ terbrechbare Prozesse gilt. Ein Rahmen ist jedoch, sobald seine Ubertragung begonnen hat, nicht mehr unterbrechbar. So kann es sein, dass w¨ahrend des Sendens eines Rahmens h h¨ oher priorisierte Rahmen zum Senden bereitgestellt werden. Diese werden von Rahmen h blockiert. Erst wenn Rahmen h versendet wurde, k¨ onnen jene gesendet werden und verengen so die nachfolgende Periode f¨ ur Rahmen h (vgl. [34]). 4.3.1

Beispiel 4.3.1 Die lange praktizierte Brauchbarkeitspr¨ ufung folgt der rekursi-

ven Formel: (l+1) ∆wh



= ∆bh +

i∈hp(h)



(l)

∆wh + ∆ji ∆pi

 ∆ei

Dabei ist ∆bh die Blockadezeit, die Rahmen h erfahren kann, weil gerade ein Rahmen niedrigerer Priorit¨ at gesendet wird. Die Rekursion wird beispielsweise mit (0) ∆wh = ∆bh + ∆ei i∈hp(h) (l)

begonnen und bricht mit ∆wh = ∆wh ab, wenn f¨ ur ein l gilt: (l+1)

∆wh

(l)

= ∆wh

Das Verfahren terminiert nicht, falls einmal gilt: ∆jh + ∆wh + ∆eh ≥ ∆ph . Zur exemplarischen Anwendung dieser Methode wird ein Rechnernetz mit drei Rahmen zugrunde gelegt:

4.3

Planung in verteilten Systemen

P 1 2 3

∆e 4 3 5

257

∆p 14 16 10

∆j 0 0 0

Die Auslastung betr¨ agt: 5/10 + 3/16 + 4/14 = 0, 973. F¨ ur den Rahmen 1 mit niedrigster Priorit¨ at ergibt sich ∆b1 = 0, da der Rahmen niedrigster Priorit¨ at nicht blockiert, sondern lediglich verdr¨angt werden kann. (0)

∆w1

= 0 + ∆e2 + ∆e3 =8

(1) ∆w1

! ! 8 8 3+ 5 = 0+ 16 10 =8

Daraus folgt, dass der Bus-Controller sp¨ atestens nach 8 Zeiteinheiten beginnen kann, den Rahmen 1 zu senden. Beim Flattern ∆j3 = 0 und bei der ¨ Ubertragungszeit von ∆e1 = 4 ist der Rahmen 1 nach insgesamt 12 Zeiteinheiten u ¨bertragen. Es gilt: ∆j1 + ∆w1 + ∆e1 = 12 ≤ 14 = ∆p1 Diese Pr¨ ufung bescheinigt Brauchbarkeit, die jedoch nicht gegeben ist, wie die nachfolgenden Ausf¨ uhrungen (siehe insbesondere Beispiel 4.3.3) zeigen werden.
F¨ ur einen Rahmen h und dessen brauchbare Einplanung ist diejenige Zeitspanne entscheidend, in der dieser Rahmen gegebenenfalls mehrfach gesendet wurde und keinerlei Sendeanspr¨ uche h¨ oher priorisierter Rahmen mehr vorliegen (siehe Abb. 4.12). Diese Zeitspanne wird Besch¨aftigungsphase (engl. busy period8 ) ∆bph genannt. In die Berechnung der Besch¨ aftigungsphase ∆bph geht zun¨achst die Blockadezeit ∆bh ein, weil zum Zeitpunkt der Beauftragung eines Bus-Controllers mit dem Rahmen h gerade ein niedriger priorisierter Rahmen gesendet und nicht unterbrochen werden kann. Damit ist die Blockadezeit vorzusehen als: ∆bh = max{∆ei | i < h}

h>1

∆b1 = 0 8

Der englische Begriff ist irref¨ uhrend, da die Zeitspanne nicht mit der Periode ∆ph oder einem Vielfachen davon zusammenfallen muss.

258

4. Fortgeschrittene Planungsverfahren


   

    
   


     ∆

∆






∆







∆


∆


   
 
Abb. 4.12. W¨ ahrend des Versendes von Rahmen h k¨ onnen bereits wieder Anspr¨ uche h¨ oher

priorisierter Rahmen auflaufen, die erst dann gesendet werden k¨ onnen, wenn das Senden von Rahmen h abgeschossen ist. Die Besch¨ aftigungsphase f¨ ur einen Rahmen h entspricht gerade die Zeitspanne, zu der beim Senden des letzten Rahmens unter ung¨ unstigsten Bedingungen keine Anspr¨ uche h¨ oherer Prozesse mehr vorliegen.

Des Weiteren umfasst die Besch¨ aftigungsphase ∆bph noch mindestens die ¨ Ubertragungszeit des Rahmens h, so dass die Summe ∆bh + ∆eh eine vorl¨ aufige Besch¨ aftigungsphase bildet. Die Besch¨ aftigungsphase ist noch nicht endg¨ ultigt berechnet, sofern sich ¨ ¨ w¨ ahrend der Ubertragungszeit von Rahmen h weitere Ubertragungsanspr¨ uche durch Rahmen i ∈ ({h} ∪ hp(h)) eintreffen. Umgekehrt ist ein ultig, wenn jeder Rahmen i in ∆bph genau berechneter Wert ∆bph dann endg¨ ! ∆bph + ∆ji ∆pi mal gesendet wurde und zum Ende der Zeitspanne ∆bph keine weiteren ¨ Ubertragungsanspr¨ uche bestehen. Entsprechend lautet die rekursive Formel:   (l) ∆bph + ∆ji (l+1) ∆ei = ∆bh + ∆bph ∆pi i∈({h}∪hp(h))

Der Anfangswert f¨ ur ∆bph ist dadurch bestimmt, dass Rahmen h mindestens einmal u ¨bertragen werden muss: (0)

∆bph = ∆bh + ∆eh (l)

Das Verfahren terminiert mit der Besch¨ aftigungsphase ∆bph = ∆bph , sobald f¨ ur ein l gilt: (l+1)

∆bph

(l)

= ∆bph

4.3

Planung in verteilten Systemen

259

Ein hinreichendes Kriterium f¨ ur die Termination des Verfahrens stellt die Bedingung Uh < 1 basierend auf der Auslastung dar: ∆ei Uh = ∆pi i∈({h}∪hp(h))

Beispiel 4.3.2 Auf den Angaben aus dem vorangegangenen Beispiel 4.3.1 wird die Besch¨ aftigungsphase f¨ ur den Rahmen 1 berechnet. Das Verfahren wird konvergieren, da die Auslastung mit U1 = 0, 973 unter 1 liegt. Mit ∆b1 = 0 berechnet sich der Anfangswert: (0)

∆bp1 = 0 + 4 =4 Des Weiteren ist: (1)

∆bp1 = 0 +

! ! ! 4+0 4+0 4+0 4+ 3+ 5 14 16 10

= 12 In analoger Weise errechnen sich die Werte: (2)

∆bp1 = 17 (3)

∆bp1 = 24 (4)

∆bp1 = 29 (5)

∆bp1 = 33 (6)

∆bp1 = 41 (7)

∆bp1 = 46 (8)

∆bp1 = 50 (9)

∆bp1 = 53 (10)

∆bp1

(11) ∆bp1 (12) ∆bp1 (13) ∆bp1

(13)

(14)

= 58 = 62 = 67 = 70

= ∆bp1 konvergiert das Verfahren mit der Erst bei ∆bp1
Besch¨ aftigungsphase ∆bp1 = 70 Zeiteinheiten.

4.3.2

260

4. Fortgeschrittene Planungsverfahren

Die Berechnung der Besch¨ aftigungsphase dient als Grundlage des Nachweises der Brauchbarkeit. In der Beschaftigungsphase ∆bph finden ! ∆bph Vh = ∆ph ¨ Ubertragungen des Rahmens h statt. Jeder Rahmen v ∈ {1, . . . , Vh } muss vor seiner Frist, also innerhalb der Zeitspanne v ∆ph , u ¨bertragen worden sein. ¨ des v-ten Rahmens Die Berechnung der Wartezeit ∆wh , bis die Ubertragung h beginnen kann, erfolgt ebenfalls rekursiv. Der Anfangswert besteht aus der ¨ Blockadezeit und den v − 1 vorangegangenen Ubertragungen des Rahmens: (0)

∆wh (v) = ∆bh + (v − 1) ∆eh (l+1)

F¨ ur die Aufstellung der Rekursionsformel f¨ ur ∆wh (v) ist der Fall zu bedenken, dass die Periode ∆pi eines Rahmens i ∈ hp(h) die Zeitspanne (l)

∆wh (v) + ∆ji teilt und das Ergebnis q ∈ N ist. Dann muss der Rahmen i genau q mal ¨ u erfolgt noch vor der ¨bertragen worden sein und die q + 1-te Ubertragung ¨ v-ten Ubertragung des Rahmens h. Dieser Zusammenhang bestimmt den ¨ Faktor, mit dem die Ubertragungszeit ∆ei zu multiplizieren ist: "# $ % (l) ∆wh (v) + ∆ji (l+1) + 1 ∆ei (v) = ∆bh + (v − 1) ∆eh + ∆wh ∆pi i∈hp(h)

(l)

F¨ ur ein v ∈ {1, . . . , Vh } terminiert das Verfahren mit ∆wh (v) = ∆wh (v), sobald f¨ ur ein l gilt: (l+1)

∆wh (l+1)

Andernfalls w¨ achst ∆wh

(l)

(v) = ∆wh (v)

(v) u ¨ber eine Schranke v ∆ph − ∆eh − ∆jh

und verletzt die Brauchbarkeit. Dieses Argument f¨ uhrt schließlich auf das ¨ Verfahren zur vollst¨ andigen Uberpr¨ ufung der Brauchbarkeit. So muss f¨ ur jeden Rahmen h und f¨ ur jedes v ∈ {1, . . . , Vh } gelten: ∆jh + ∆wh (v) + ∆eh ≤ v ∆ph 4.3.3

Beispiel 4.3.3 Als Fortsetzung von Beispiel 4.3.2 wird nun die Brauchbarkeit

u uft. Dies muss f¨ ur jeden Rahmen h ∈ {1, 2, 3} geschehen. Es wird sich ¨berpr¨ jedoch zeigen, dass Rahmen 1 nicht fristgerecht eingeplant werden kann, so

4.3

Planung in verteilten Systemen

261

dass es gen¨ ugt, auf die Besch¨ aftigungsphase ∆bp1 = 70 zur¨ uckzugreifen. Mit ! ∆bp1 V1 = ∆ph =5 passen f¨ unf Rahmen in diese Besch¨ aftigungsphase und jeder einzelne Rahmen v ∈ {1, . . . , 5} ist hinsichtlich einer Fristverletzung zu u ufen. ¨berpr¨ Begonnen wird mit v = 1 und der Berechnung von w1 (1): (0)

∆w1 (1) = 0 + (1 − 1) 4 =0 (1) ∆w1 (1)



= 0 + (1 − 1) 4 +

 

   0 0 +1 3+ +1 5 16 10

=8 (2)

(1)

Wegen ∆w1 (1) = ∆w1 (1) ist ∆w1 (1) = 8 und es wird gepr¨ uft: 0 + 8 + 4 = ∆j1 + ∆w1 (1) + ∆e1 ≤ 1 ∆p1 = 14 Damit ist Rahmen 1 zum ersten Mal brauchbar einplanbar. Sei nun v = 2, was bedeutet, dass die zweite Versendung von Rahmen 1 auf Brauchbarkeit zu u ufen ist. Hier gilt: ¨berpr¨ (0)

∆w1 (2) = 0 + (2 − 1) 4 =4 (l)

Eine Reihe weiterer Werte ∆w1 (2) ist zu berechnen: 

  

  4 4 (1) +1 3+ +1 5 ∆w1 (2) = 0 + (2 − 1) 4 + 16 10 = 12 (2)

∆w1 (2) = 17 (3)

∆w1 (2) = 20 (4)

∆w1 (2) = 25 (5)

(4)

uft: Wegen ∆w1 (2) = ∆w1 (2) ist ∆w1 (2) = 25 und es wird gepr¨ 0 + 25 + 4 = ∆j1 + ∆w1 (2) + ∆e1 ≤ 2 ∆p1 = 28 Damit verletzt der Rahmen 1 bei seiner zweiten Versendung die Frist (siehe Abb. 4.13), und die Menge der drei Rahmen ist nicht brauchbar einplanbar. Hieran wird deutlich, dass es nicht gen¨ ugt, den jeweils ersten Rahmen ¨ brauchbar einplanen zu k¨ onnen. Aufgrund der Uberlagerung mit ande¨ ren Rahmen findet die zweite Ubertragung des Rahmens unter beengteren

262

4. Fortgeschrittene Planungsverfahren

Verh¨ altnissen statt als die erste. Dieser Sachverhalt wurde von den a¨lteren Verfahren (vgl. [133] und [60]) noch nicht erkannt und erst in einem neueren Pr¨ ufungsverfahren (vgl. [34]) mit erfasst. 





















    









   







    Abb. 4.13. Das Zeitdiagramm zeigt, bei welcher Folge von Rahmen eine Fristverletzung

entsteht.


4.3.1

Aufgabe 4.3.1 (siehe Seite 296) Gegeben sei ein Bus mit einem arbitrierenden

Zugriffsprotokoll, u ¨ber das 4 verschiedene Rahmen versendet werden sollen. ¨ Folgende Angaben zur Periode, Ubertragungszeit und zum Flattern seien gegeben: P 1 2 3 4

∆e 1 4 2 4

∆p 36 12 15 10

∆j 3 1 3 1

Pr¨ ufen Sie f¨ ur die angegebenen Rahmen, ob sie brauchbar verplant werden k¨ onnen.
4.3.4 Markengesteuerte Zugriffsprotokolle

Nach einer Initialisierungsphase besitzt ein Rechnernetz genau eine Marke. Ein Knoten j darf erst dann einen Rahmen versenden, wenn er im Besitz dieser Marke ist. Gleichzeitig ist der Besitz der Marke auf eine Aufenthaltszeit (token holding time oder THT) beschr¨ ankt. Diese Aufenthaltszeit ∆tF (c, j) kann vom jeweiligen Umlauf c der Marke und dem Knoten j abh¨angig sein. Anschließend ist die Marke an einen eindeutig bestimmten Nachfolgekno¨ ten weiterzuleiten. Ublicherweise sind alle m Knoten eines Rechnernetzes ringf¨ ormig angeordnet. Bei j ∈ {1, . . . , m} errechnet sich der Nachfolgeknoten nach der Formel: nj = j%m + 1

4.3

Planung in verteilten Systemen

263

Auf diese Weise durchl¨ auft die Marke alle Knoten des Rechnernetzes, wobei ¨ die Aufenthaltszeit in einem Knoten von der Ubertragungszeit der Marke von einem Knoten j zum n¨ achsten Knoten nj (token passing time oder TPT) zu unterscheiden ist. Die Zeitspanne ∆T P T (j) spaltet sich in die Zeit, die notwendig ist f¨ ur das Senden der einzelnen Bits und die Siganallaufzeit zu Knoten nj (siehe Abb. 4.14): ∆T P T (j) = BitsT oken ∆tBit + ∆tSig (j, nj) Diese Zeitspanne ist unabh¨ angig vom jeweiligen Umlauf der Marke, variiert jedoch entsprechend des r¨ aumlichen Abstandes zwischen Knoten j und Knoten nj.

  







 



 
  



 ¨ Abb. 4.14. Die Ubertragungszeit der Marke teilt sich in die Zeitspanne f¨ ur das Senden der Marke (a) und die Signallaufzeit zum jeweils n¨ achsten Knoten (b).

Ein markenbasiertes Zugriffsprotokoll l¨ asst sich grunds¨atzlich mit einem hohen Grad an Determiniertheit betreiben. Dazu gen¨ ugt es, die Aufenthaltszeit ∆tF (c, j) fest vorzugeben. Dann ist die Dauer eines Umlaufs, auch Rotationszeit (token rotation time oder TRT) genannt, f¨ ur ein Rechnernetz festgelegt:

∆tT RT =

m

(∆tF (c, j) + ∆T P T (j, nj))

j=1

Dieser Ansatz ist jedoch nicht sehr effizient, da Marken auch dann noch in einem Knoten festgehalten werden, wenn dieser keinen Bedarf mehr hat, ¨ Rahmen zu u gilt deshalb die Regel, nach der Mar¨bertragen. Ublicherweise ken bereits dann weiterzuleiten sind, wenn ein Knoten keine Rahmen mehr zu u ¨bertragen hat. Umgekehrt soll es ihm nicht gestattet sein, unbedingt ¨ alle Rahmen, die zur Ubertragung anstehen, auch zu u ¨bertragen. Nur die synchronen Rahmen d¨ urfen bedingungslos gesendet werden, w¨ahrend die ¨ Ubertragung asynchroner Rahmen nur bedingt zul¨assig ist. Maßgeblich ist in

264

4. Fortgeschrittene Planungsverfahren

diesem Zusammenhang die Rotationszielzeit (target token rotation time oder TTRT). Anhand letzterer wird entschieden, ob und wie viel ein Knoten an asynchronen Rahmen senden darf. Insgesamt sind folgende Vorgaben zu einem so betriebenen Rechnernetz zu machen9 : ∆T T RT Rotationszielzeit der Marke im Rechnernetz. ¨ ∆SF (j) Zeitspanne der Ubertragung der synchronen Rahmen durch Knoten j. ¨ ∆AF (j) Zeitspanne der Ubertragung der aynchronen Rahmen durch Knoten j. Besitzt ein Knoten die Marke, so steht ihm garantiert die Zeitspanne ∆SF (j) zur Verf¨ ugung, um synchrone Rahmen zu senden. Aber auch die Marke ist immer von Knoten zu Knoten zu senden. Damit ist der Umfang dessen, was ein Knoten j in jedem Umlauf beitragen darf, begrenzt durch: ∆SF (j) + ∆T P T (j)

j ∈ {1, . . . , m}

Hinter den synchronen Rahmen verbergen sich die zeitkritischen Kommuni¨ kationsauftr¨ age, f¨ ur die sichergestellt werden soll, dass eine Ubertragung nach einer begrenzten Zeitspanne erledigt wird. Vor diesem Hintergrund stellt die Rotationszielzeit eine Zielvorgabe f¨ ur die Wiederkehr der Marke dar und ist sinnvollerweise so zu w¨ ahlen, dass zumindest alle synchonen Rahmen aller Knoten sowie das Weiterleiten der Marke durch das gesamte Rechnernetz gew¨ ahrleistet ist: ∆T T RT ≥

m

(∆SF (j) + ∆T P T (j))

j=1

Tats¨ achlich werden beim Eintreffen der Marke nur die synchronen Rahmen ur u ur die gerade der Bedarf besteht. Sei ∆tSF die Zeitspanne f¨ ¨bertragen, f¨ ¨ die Ubertragung der synchronen Rahmen des Knotens j im Umlauf c, dann gilt: 0 ≤ ∆tSF (c, j) ≤ ∆SF (j) ¨ f¨ ur asynchrone Rahmen. Damit Analog ist ∆tAF (c, j) die Ubertragungszeit bel¨ auft sich der Aufenthalt der Marke im Knoten j im Umlauf c auf: ∆tF (c, j) = ∆tSF (c, j) + ∆tAF (c, j) 9

Beachte, dass alle Zeitspannen die vorab zu bestimmen sind, in der Weise ∆X notiert sind, w¨ ahrend alle Zeitspannen, die sich bei der Ausf¨ uhrung des Protokolls ur Zeitpunkte. ergeben, der Schreibweise ∆tX folgen. Analoges gilt f¨

4.3

Planung in verteilten Systemen

265

Die Zeitspanne f¨ ur den c-ten Umlauf der Marke, gemessen bei der Ankunft im Knoten j, ergibt sich nun als: ∆tCY C (c, j − 1) =

m

∆T P T (j)

j=1

+∆tF (c − 1, j) + . . . + ∆tF (c − 1, m) +∆tF (c, 1) + . . . + ∆tF (c, j − 1) = ∆tT RT (c, j) ¨ Der markengesteuerte Zugriff des Knotens j auf das Ubertragungsmedium erfolgt nach einem Protokoll, das unbedingt die synchronen Rahmen u ¨bertr¨agt. Die Entscheidung dar¨ uber, ob auch asynchrone Rahmen u ¨bertragen werden, h¨ angt davon ab, ob die Marke fr¨ uh (engl. early) eintrifft. Im folgenen Verfahren f¨ ur Knoten j ist early eine boolesche Variable, die im c-ten Umlauf den Wert TRUE besitzt, wenn gilt: ∆T T RT − ∆tT RT (c, j) > 0 Insgesamt arbeitet das markengesteuerte Zugriffsprotokoll nach folgendem Verfahren: while(TRUE){ wait_for(token); now=gettime(); trt= now-last; // token rotation time last=now; tht=ttrt-trt; // token holding time early=tht>0; send(SF); if (early) sendlimited(AF,tht); send(token); } Dabei entspricht trt der Rotationszeit ∆tT RT (c, j) und ttrt der Rotationszielzeit ∆T T RT . Mit send(SF) werden die synchronen Rahmen f¨ ur uh ist, werdie Zeitspanne ∆tSF (c, j) gesendet. Nur wenn die Marke fr¨ den mit sendlimited(AF,tht) f¨ ur eine begrenzte Zeitspanne ∆tAF (c, j) ≤ ∆tT HT (c, j) auch asynchrone Rahmen versendet. Beispiel 4.3.4 Gegeben sei ein Rechnernetz mit 4 Knoten und folgenden Anspr¨ uchen zur Versendung synchroner und asynchroner Rahmen:

4.3.4

266

4. Fortgeschrittene Planungsverfahren

ND 1 2 3 4

∆SF (j) 2 3 1 2

∆AF (j) 6 1 5 1

¨ Der Einfachheit halber sei die Zeitspanne zur Ubertragung der Marke zu vernachl¨ assigen: ∆T P T (j) = 0 f¨ ur j ∈ {1, . . . , 4}. Entsprechend muss die Rotationszielzeit ∆T T RT mindestens 8 Zeiteinheiten lang sein. Sie sei im Einvernehmen aller Knoten auf ∆T T RT = 12 Zeiteinheiten festgesetzt. F¨ahrt man im ersten Umlauf nur mit einer Last von je einer Zeiteinheit an synchronen ¨ Rahmen, dann kann sich das Ubertragungsbeispiel (siehe Abb. 4.15) f¨ ur die nachfolgenden Uml¨ aufe ergeben.

Abb. 4.15. Zeitdiagramm der Versendung synchroner (S) und asynchroner (A) Rahmen

durch die Knoten 1 bis 4.

Im zweiten Umlauf empf¨ angt Knoten 1 die Marke fr¨ uh. Die Zeitspanne ur zwei Zeit∆tT HT (2, 1) ist mit 8 Zeiteinheiten so lang, dass Knoten 1 f¨ einheiten synchrone und f¨ ur sechs Zeiteinheiten asynchrone Rahmen sendet. Damit sch¨ opft er den Zeitrahmen, der ihm zum Senden zusteht, voll aus. Bei Knoten 2 kommt die Marke ebenfalls fr¨ uh an. Aber die Zeitspanne, um asynchrone Rahmen zu senden, ist bereits auf ∆tT HT (t)(2, 2) = 1 Zeiteinheiten geschrumpft. Die n¨ achsten Knoten 3,4,1 erhalten die Marke nicht mehr fr¨ uh und d¨ urfen nur noch synchrone Rahmen senden. Erst bei Knoten 2 kommt die Marke wieder fr¨ uh an, und es d¨ urfen wieder begrenzt asynchrone Rahmen gesendet werden.
Zur Absch¨ atzung des zeitlichen Verhaltens des markengesteuerten Zugriffsprotokolls wird eine Sollvorgabe f¨ ur den Umlauf der Marke definiert, die mit ∆tP ACE (in Anlehnung an [116]) bezeichnet wird. Darin wird die

4.3

Planung in verteilten Systemen

267

¨ ¨ Ubertragungslast zusammengefasst, die auf Dauer durch die Ubertragung der synchronen Rahmen und der Marke anfallen kann: % " j 1 j ∈ {1, . . . , m} fk ∆tP ACE (c, j) = ∆T T RT c − 1 + F k=1

Dabei sind die beiden Gr¨ oßen fk , mit k ∈ {1, . . . , m}, und F folgendermaßen bestimmt: ∆SF (k) + ∆T P T (k) m ∆T T RT (∆SF (k) + ∆T P T (k)) F = k=1 ∆T T RT

fk =

Aufgrund dieser Definition gilt: 0 ≤ F ≤ 1. M¨ oge nun das Rechnernetz im ersten und zweiten Umlauf so hochfahren, dass die folgenen Eigeschaften erf¨ ullt sind, mit u ∈ {1, 2}: ∆tCY C (u, m) = ≤

m

(∆tSF (u, k) + ∆T P T (k))

k=1 m

(∆SF (k) + ∆T P T (k))

k−1

Sei weiterhin ∆tDIF F die Differenz zwischen der Sollvorgabe f¨ ur den Umlauf einer Marke und der tats¨ achlichen Umlaufzeit: ∆tDIF F (c, j) = ∆tP ACE (c, j) −

c,j

(∆tF (u, k) + ∆T P T (k))

(u,k)=(1,1)

Dann gilt die folgende Beziehung: Satz 4.3.1 Die Sollvorgabe f¨ ur den Umlauf einer Marke ist gr¨oßer als die tats¨ achliche Umlaufzeit:

∆tDIF F (c, j) ≥ 0

c > 0, j ∈ {1, . . . , m}

Beweis: F¨ ur die ersten zwei Uml¨ aufe des Protokolls ist die Aussage richtig:

∆tDIF F (1, j) =

j 1 (∆SF (k) + ∆T P T (k)) F k=1

− ≥0

j k=1

(∆tSF (1, k) + ∆T P T (k))

4.3.1

268

4. Fortgeschrittene Planungsverfahren

∆tDIF F (2, j) = ∆T T RT +

j 1 (∆SF (k) + ∆T P T (k)) F k=1

− ≥0

m

(∆tSF (1, k) + ∆T P T (k)) −

k=1

j

(∆tSF (2, k) + ∆T P T (k))

k=1

Die Aussage ∆tDIF F (2, j) ≥ 0 dient im Weiteren als Induktionsvoraussetzung f¨ ur beide F¨ alle der nachfolgenden Fallunterscheidung bezogen auf Knoten j im c-ten Umlauf: uhrt zur Gleichung: Fall (a): ∆tSF (c, j) + ∆tAF (c, j) ≤ ∆SF (j). Dies f¨ ∆tDIF F (c, j) = ∆tDIF F (c, j − 1) ∆SF (j) + ∆T P T (j) + F −(∆tSF (c, j) + ∆tAF (c, j) + ∆T P T (j)) Wegen 0 ≤ F ≤ 1 folgt unmittelbar ∆tDIF F (c, j) ≥ ∆tDIF F (c, j − 1) und mittelbar wegen der Induktionsvoraussetzung ∆tDIF F (c, j) ≥ 0. Fall (b): ∆tSF (c, j) + ∆tAF (c, j) > ∆SF (j). Wegen ∆tSF (c, j) ≤ ∆SF (j) m¨ ussen in diesem Fall asynchrone Rahmen versendet worden sein: ∆tAF (c, j) > 0. Gleichzeitig ist der Anteil asynchroner Rahmen durch das Protokoll begrenzt: ∆tAF (c, j) ≤ ∆T T RT − ∆tT RT (c, j) = ∆T T RT − ∆tCY C (c, j − 1) Betrachtet wird nun der vorhergehende Umlauf und der nachfolgende Aufenthalt im Knoten j: ∆tDIF F (c, j) = ∆tDIF F (c − 1, j − 1) ∆SF (j) + ∆T P T (j) +∆T T RT + F −(∆tCY C (c, j − 1) + ∆tSF (c, j) + ∆tAF (c, j) + ∆T P T (j)) = ∆tDIF F (c − 1, j − 1) + (∆T T RT − ∆tCY C (c, j − 1) − ∆tAF (c, j))

 ∆SF (j) + ∆T P T (j) − ∆tSF (c, j) − ∆T P T (j) + F

4.3

Planung in verteilten Systemen

269

In der letzten Formal sind auf der rechten Seite nur noch Terme mit nicht negativen Werten enthalten, was unmittelbar zeigt, dass gilt: ∆tDIF F (c, j) ≥ ∆tDIF F (c − 1, j − 1) Daraus folgt mittelbar: ∆tDIF F (c, j) ≥ 0.




¨ F¨ ur weitere Uberlegungen zum markengesteuertern Zugriffsprotokoll ist festzuhalten, dass ein nicht fr¨ uhes Eintreffen der Marke nicht beliebig oft hintereinander geschehen kann. Dies h¨ angt damit zusammen, dass ein nicht fr¨ uhes Eintreffen der Marke auch immer bedeutet, dass kein asynchroner Rahmen versendet werden darf, was in diesem Fall f¨ ur Knoten j im Umlauf c bedeutet: ∆tF (c, j) = ∆tSF (c, j) ≤ ∆SF (j) Sp¨ atestens nach der m-ten Weitergabe der Marke durch Knoten, die die Marke nicht fr¨ uh empfangen haben, gilt, dass die Marke wieder fr¨ uh eintrifft: ∆tT RT (c, j) = ∆tcyc (c, j − 1) m (∆SF (k) + ∆T P T (k)) ≤ k=1

≤ ∆T T RT Satz 4.3.2 Die Dauer des Umlaufs einer Marke ist begrenzt auf:

∆tT RT (c, j) ≤ 2 ∆T T RT

c > 0, j ∈ {1, . . . , m}

Beweis: Die Rotationszeit ∆tT RT (c, j) kann nur dann die Rotationszielzeit ∆T T RT u uh eintrifft, das heißt: ¨berschreiten, wenn die Marke nicht fr¨

∆T T RT − ∆tT RT (c, j) < 0 Wie bereits bemerkt, kann es vor dem (c, j)-ten Besuch der Marke h¨ochstens m − 1 Knoten geben, bei denen die Marke zuvor ebenfalls nicht fr¨ uh eingetroffen ist. Somit existiert ein Knoten k, der im Umlauf d seine Marke als letzter fr¨ uh erhalten hat. Betrachtet man die Zeitpunkte des Eintreffens der Marke, dann herrscht folgende zeitliche Ordnung: t(c, j) > t(d, k) ≥ t(c − 1, j) > t(d − 1, k) Dabei gilt f¨ ur Knoten k im d-ten Umlauf: t(d, k) − t(d − 1, k) = ∆tT RT (d, k)

4.3.2

270

4. Fortgeschrittene Planungsverfahren

≤ ∆T T RT − ∆tAF (d, k) Damit darf Knoten k, weil die Marke fr¨ uh eintrifft, f¨ ur die Zeitspanne ∆tAF (d, k) asynchrone Rahmen schicken. Des Weiteren besteht folgende Beziehung zwischen den Zeitpunkten t(c, j) und t(d, k) (siehe auch Abb. 4.16): (c,j−1)



t(c, j) − t(d, k) ≤

(∆tSF (x, y) + ∆T P T (y))

(x,y)=(d,k+1)

+∆tSF (d, k) + ∆tAF (d, k) + ∆T P T (k) (c,j)



≤

(∆tSF (x, y) + ∆T P T (y))

(x,y)=(d,k)

+∆tAF (d, k) ≤ ∆T T RT + ∆tAF (d, k) So l¨ asst sich schließlich die Behauptung auch f¨ ur einen beliebigen Knoten j, bei dem die Marke nicht fr¨ uh eintrifft, folgern: ∆tT RT (c, j) = t(c, j) − t(c − 1, j) ≤ t(c, j) − t(d − 1, k) = (t(c, j) − t(d, k)) + (t(d, k) − t(d − 1, k)) ≤ 2 ∆T T RT











 





















 

Abb. 4.16. Schema zweier Uml¨ aufe der Marke im Rechnernetz.

   



4.3

Planung in verteilten Systemen

271

Aufgabe 4.3.2 (siehe Seite 302) Konstruieren Sie ein Fallbeispiel, bei dem die

oglichst nahe an die Schranke 2 ∆T T RT herankommt. Rotationszeit ∆tT RT m¨ ¨ Benutzen Sie dazu die Vereinfachung, dass die Ubertragungszeit der Marke
vernachl¨ assigt werden kann: ∆tT P T (j) = 0, mit j ∈ {1, . . . , n}. Dieses Zugriffsprotokoll kann als ein Musterbeispiel daf¨ ur gelten, wie eine lokale Vorschrift angewendet in jedem einzelnen Knoten bewirkt, dass eine globale Eigenschaft f¨ ur ein ganzes Rechnernetzes gilt. Die Besch¨ankung der Zeitdauer f¨ ur das Senden asynchroner Rahmen hat zur Folge, dass sp¨atestens nach 2 ∆T T RT wieder eine Marke eintreffen wird. Somit sichert das Zugriffsprotokoll die Eigenschaft der Verhersagbarkeit. Weitere interessante Fragestellungen ranken sich um die Bestimmung der Parameter des Zugriffsprotokolls. So geht es bei der Bestimmung der synchronen Bandbreite (synchronous bandwidth allocation oder SBA) um die Opti¨ mierung der Zeitspannen f¨ ur die Ubertragung der synchronen Rahmen und damit verbunden auch immer um die Rotationszielzeit (vgl. stellvertretend [143]). Als einfache Regel l¨ asst sich dabei ableiten, dass die Periode ∆pi , mit der ein Anwendungsprozess i eines Knotes Rahmen erzeugt, in der folgenden Beziehung zur Rotationszielzeit stehen sollte: ! ∆pi ≥2 ∆T T RT

4.3.2

A

A A.1 A.2 A.3 A.4

L¨ osungen der Aufgaben L¨ osung der Aufgabe aus Kapitel 1 ........................... L¨ osungen der Aufgaben aus Kapitel 2 ....................... L¨ osungen der Aufgaben aus Kapitel 3 ....................... L¨ osungen der Aufgaben aus Kapitel 4 .......................

275 275 281 294

A Lo ¨sungen der Aufgaben A.1 L¨ osung der Aufgabe aus Kapitel 1

A.1

L¨ osung zu Aufgabe: 1.4.1 (siehe Seite 26) Um einen Uhrbaustein ist mit einem 25-MHz-Oszillator zu realisieren, ist ein Grenzwert nG festzulegen (a), eine Zeitspanne bis zu einer Korrektur der Uhr zu bestimmen (b) und eine Strategie zur Minimierung von Abweichungen zu skizzieren (c). (a) Gesucht ist der Wert f¨ ur nG = max{n ∈ N | n/f ≤ ∆tG } mit f = 25M Hz und ∆tG = 10µs. Es ist nG = 10µs · 25M Hz = 250. (b) Mit nG = 250 und f = 25, 001M Hz ist die Bezugszeitspanne ∆tG ungef¨ ahr 0, 4 ns zu kurz. Die Toleranzgrenze ist nach dem 2500maligen Ablauf der Bezugszeitspanne ∆tG erreicht. (c) W¨ urde man nG auf den Wert 251 festsetzen, dann w¨are die Bezugszeitspanne immer um 39,6 ns zu lang. Diese Zeit¨ uberschreitung entspricht 99 Zeitunterschreitungen, die sich f¨ ur die Bezugszeitspanne bei na = 250 ergeben. Deshalb werden nach genau 99 Abl¨aufen, bei denen sich die Bezugszeitspanne ∆tG aus 250 Schwingungen des Oszillators berechnet, jeweils eine Bezugszeitspanne ∆tG durch 251 Schwingungen des Oszillators gebildet, um die Uhrzeit m¨ oglichst eng nachzuf¨ uhren“. ”

A.2 L¨ osungen der Aufgaben aus Kapitel 2

L¨ osung zu Aufgabe: 2.2.1 (siehe Seite 62) Richtigerweise setzte Ole Rømer den akkumulierten Gangunterschied mit der Zeit gleich die das Licht f¨ ur den Weg vom jupitern¨achsten bis zum jupiterfernsten Punkt der Erdumlaufbahn ben¨ otigt. Somit gilt der Ansatz:

∆dR ∆tR 3, 01014 m = 1320s = 2, 273 · 1011 m/s

cR =

A.2

276

A. L¨osungen der Aufgaben

Der große Abstand zur uns bekannten Lichtgeschwindigkeit kam dadurch zustande, dass der von Ole Rømer beobachtete Gangunterschied von 1320s stark vom tats¨ achlichen Wert 997s abweicht und entscheidend f¨ ur den Abstand ist.

L¨ osung zu Aufgabe: 2.2.2 (siehe Seite 64) Betrachtet wird zun¨ achst das Bezugssystem Σ1 . Das beobachtete Ereignis sei ein im Punkt x1 eintreffender Lichtstrahl, der zum Zeitpunkt 0 ausgesendet wurde. F¨ ur den Zeitpunkt t des Eintreffens gilt:

t=

x1 c

Bei Anwendung der Galilei-Transformation hat derselbe Punkt im Bezugssystem Σ2 die Koordinate: x2 = x1 − v12 t Mit x1 = c t errechnet sich weiter: x2 = (c − v12 )t Dies bedeutet, dass sich Licht im Bezugssystem Σ2 mit der Geschwindigkeit c − v12 ausbreitet. Dies steht im Widerspruch zur Annahme A1 (siehe Seite 63), dass die Lichtgeschwindigkeit unabh¨angig von der relativen Geschwindigkeit der Bezugssysteme ist.

L¨ osung zu Aufgabe: 2.2.3 (siehe Seite 68) Gesucht ist die Zeitdauer t1 im Bezugssystem Σ1 , bis die Zeit t2 im bewegten Bezugssystem Σ2 die Differenz von 1µs aufweist:

1µs = t1 − t2 = t1 − t1

1−

v 2 12

c

Daraus errechnet sich die Zeitdauer t1 = 1, 1259 108 s, was etwas mehr als dreieinhalb Jahren entspricht.

L¨ osung zu Aufgabe: 2.2.4 (siehe Seite 68) Das Bezugssystem Σ2 (Rakete) entfernt sich mit der Geschwindigkeit v12 = 3/5c vom Bezugssystem Σ1 . Das Ereignis, dass in der Atomuhr von Σ2 eine

A.2

L¨ osungen der Aufgaben aus Kapitel 2

277

Stunde vergangen ist, wird beschrieben durch:  

ch ct2 = a2 0 Im Bezugssystem Σ1 findet dasselbe Ereignis zum Zeitpunkt t1 in einer Entfernung a1 statt. Die Lorentz-Transformation beschreibt den Zusammenhang:

ch 0



=

γ

−v12 c γ

−v12 c γ

γ



ct1 a1



Die beiden Unbekannten ergeben sich durch Aufl¨osung der zwei linearen Gleichungen: t1 = γh a1 = v12 γh Das Signal, das in Σ2 nach einer Stunde ausgesendet wird, muss in Σ1 die ucklegen, was die Zeitspanne a1 /c erfordert. Damit ergibt sich Strecke a1 zur¨ die Gesamtzeit: v12 γh t1 + a1 /c = γh + c 

v12 = hγ 1 + c F¨ ur v12 = 3/5 c ist γ = 5/4. Damit wird das Signal nach 2h bei der Bodenstation eintreffen. W¨ are die Geschwindigkeit jedoch bereits v12 = 4/5 c, dann ist γ = 5/3 und das Signal tr¨ afe erst nach 3h bei der Bodenstation ein.

L¨ osung zu Aufgabe: 2.2.5 (siehe Seite 71) F¨ ur die Start- und Zielzeiten der beiden Athleten ergibt sich bei der Granularit¨ at G der ablesbaren Uhrzeit die Beziehung:

[Tk,G (e3 ), Tk,G (e4 )] = [Tk,G (e1 ), Tk,G (e2 )] + 2 ∆tG Daraus folgt, dass gilt: 0 < (Tk (e4 ) − Tk (e3 )) − (Tk (e2 ) − Tk (e1 )) Damit ist auch bei der Messung die Granularit¨at der Ticks der erste Athlet immer schneller als der zweite. Ist jedoch der erste nur um 1ms, gemessen in der Granularit¨ at der Bezugszeitspanne, schneller als der zweite, ist es m¨oglich, dass der vermeinlich langsamere in der Granularit¨at der Ticks der schnellere

278

A. L¨osungen der Aufgaben

ist. Das nachfolgende Diagramm (Abb. A.1) zeigt f¨ ur nG = 10 einen solchen Fall. e1 z j

e3

e2

e4

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 2 0 1

Abb. A.1. Zeitmessung der Ereignisse e1 bis e4 in der Granularit¨ at der Ticks z und der

Granulart¨ at der Bezugszeitspanne j.

L¨ osung zu Aufgabe: 2.2.6 (siehe Seite 90) Der Beweis wird zun¨ achst exemplarisch auf drei zusammenh¨angenden Interuhrt und dann verallgemeinert. vallen der L¨ ange ∆tG+ gef¨ Gesucht wird in den beiden ersten Intervallen nach dem kleinsten Abstand oberen Granularit¨at einen Abstand ∆tG+ (e3 , e4 ) = 1 ∆tG (e3 , e4 ), der in der gr¨ besitzt. Ein solcher Abstand ∆tG (e3 , e4 ) = 1 ergibt sich, wenn e3 und e4 sowohl bezogen auf G als auch G+ in aufeinander folgenden Bezugszeitspannen liegen (siehe Abb. 2.23). Soll der Abstand ∆tG+ (e1 , e2 ) = 2 und daussen e1 und e2 einen Abstand von mit gr¨ oßer als ∆tG+ (e3 , e4 ) sein, dann m¨ ∆tG (e1 , e2 ) = 2g ∆tG besitzen (siehe ebenfalls Abb. 2.23). Damit ist:

∆tG (e1 , e2 ) − ∆tG (e3 , e4 ) = (2g − 1)∆tG > (2g − 2)∆tG Da sich die Verh¨ altnisse bei Parallelverschiebung der Zeitabst¨ande der gemessenen Ereignisse nicht ¨ andern, gilt die Behauptung grunds¨atzlich.

L¨ osung zu Aufgabe: 2.3.1 (siehe Seite 110) Die Berechnung der aktuellen Geschwindigkeit ovv im Prozess Aggregation ” aus Kenngr¨ oßen“ ben¨ otigt mindestens die beiden letzten Positionsangaben. Die minimalen und maximalen Zeitverz¨ ogerungen, die sich f¨ ur die Berechnung der Geschwindigkeit zwangsl¨ aufig ergeben, werden dominiert von der Periode 40ms f¨ ur die Erneuerung der Kamerabildes. Alle u ¨brigen Verz¨ogerungszeiten sind wie bei der Bestimmung der Position:

slv = 40ms + 2ms + 4ms = 46ms shv = 40ms + 3ms + 11ms = 54ms

A.2

L¨ osungen der Aufgaben aus Kapitel 2

279

Entsprechend sind f¨ ur die aktuelle Beschleunigung ova mindestens die letzten drei Postionsangaben erforderlich: sla = 2 × 40ms + 2ms + 4ms = 86ms sha = 2 × 40ms + 3ms + 11ms = 94ms

L¨ osung zu Aufgabe: 2.4.1 (siehe Seite 122) Anhand der einfacheren push()-Funktion l¨ asst sich verdeutlichen, in welcher Weise der CAS-Befehl hilft, die Konsistenz des Stapels zu bewahren. In einer Schleife wird mit

new_cell->next=*ptr_top; solange der Verweis auf den alten Stapel in die neue Top-Zelle eingetragen, bis es gelingt, denselben Wert auch in die Variable ptr top einzutragen: void push(cell **ptr_top,cell *new_cell){ for(;;){ new_cell->next=*ptr_top; if(CAS(ptr_top,new_cell->next,new_cell)) break; } } Bei der pop()-Funktion ist zun¨ achst noch zu beachten, dass der Stapel leer sein kann. In diesem Fall ist das Ergebnis der leere Verweis. Andernfalls wird der Verweis auf die Top-Zelle zur¨ uckgegeben, sofern er immer noch mit dem Verweis in der obersten Zelle u ¨bereinstimmt: void pop(cell **ptr_top){ cell *h,*n; for(;;){ h=*ptr_top; if(h==NULL)return h; n=h->next; if(CAS(ptr_top,h,n)) break; } return h;

280

A. L¨osungen der Aufgaben

}

L¨ osung zu Aufgabe: 2.5.1 (siehe Seite 145) Ein Knoten A beginnt nur dann damit, einen Rahmen zu senden, wenn er den Bus f¨ ur eine bestimmte Zeitspanne in freiem, d.h. in rezessivem Zustand, vorgefunden hat. Sei tA der Zeitpunkt, zu dem Knoten A beginnt, das Startbit zu senden. Ebenso verh¨ alt sich Knoten B, der sein Signal ab dem Zeitpunkt tB sendet. Da kein Knoten vom anderen wußte, gilt:

tb ∈ [tA − ∆tSig , tA + ∆tSig ] Dies zeigt, dass der Beginn eines Bits zwischen zwei Knoten um bis zu ∆tSig auseinander liegen kann. Die Ankunft eines Signals, das Knoten B zum Zeitpunkt tB ausgesendet hat, kann bis zum Zeitpunkt tA + 2 ∆tSig dauern. Erst dann darf es abgetastet werden. Gleichzeitig muss der Knoten A noch dabei sein, das aktuelle Bit zu senden. Deshalb lautet die notwendige Bedingung: 2 ∆tSig ≤ ∆tP robe ≤ ∆tBit Aus einer Reihe von technischen Gr¨ unden haben die implementierten Protokolle zum Teil deutliche Abst¨ ande zwischen den Operanden der obigen Formel. Erst dann liegen die Signale stabil auf dem Bus und k¨onnen sicher abgegriffen werden. Eine entsprechende Belegung legt genau eine Zeiteinheit zwischen die obigen Operanden (siehe auch Abb. A.2): ∆tSig = 3

∆tP robe = 7

∆tBit = 8

Abb. A.2. Genau 7 Zeiteinheiten nach dem Beginn des Bits pr¨ uft ein Knoten, ob das

Signal, das er sendet, mit dem u ort. Beim dritten Bit ¨bereinstimmt, das er auf dem Bus h¨ erkennt Knoten A, dass er ein rezessives Bit sendet, aber ein dominantes Bit h¨ ort.

A.3

L¨ osungen der Aufgaben aus Kapitel 3

281

A.3 L¨ osungen der Aufgaben aus Kapitel 3

L¨ osung zu Aufgabe: 3.2.1 (siehe Seite 165) F¨ ur die Prozessmenge P = {1, 2} mit d1 ≤ d2 sind Prozessparameter derart zu finden, dass Verfahren 3.2.1 versagt und Verfahren 3.1.2 einen brauchbaren Plan liefert.

Systematisch sollen nun die daf¨ ur notwendigen Prozessparameter bestimmt werden. Zun¨ achst muss f¨ ur jeden der beiden Prozesse i ∈ P gelten: ri + ∆ei ≤ di

i ∈ {1, 2}

Das Verfahren 3.2.1 plant zuerst Prozess 1, dann Prozess 2. Dass es keinen brauchbaren Plan findet, hat zwei Gr¨ unde, die beide zutreffen m¨ ussen: 1. Prozess 2 passt nicht hinter Prozess 1: r1 + ∆e1 + ∆e2 > d2 2. Umgekehrt passt Prozess 2 auch nicht vor den schon eingeplanten Prozess 1: r2 + ∆e2 > r1 Daraus schließt man unmittelbar: r1 − r2 < ∆e2 Gibt es einen brauchbaren Plan f¨ ur die Prozessmenge, so ist dieser durch eine umgekehrte Reihenfolge zu erreichen: r2 + ∆e2 + ∆e1 ≤ d1 Beide Bedingungen sind in der folgenden Ungleichung enthalten: d2 − r1 < ∆e1 + ∆e2 ≤ d1 − r2 Mit d2 − d1 ≥ 0 schließt man r1 − r2 > 0. Konkrete Prozessparameter, die diese Bedingungen erf¨ ullen, sind nun leicht zu finden: P 1 2

r 3 1

∆e 1 3

d 5 6

Verfahren 3.2.1 erzeugt eine Fristverletzung:

A.3

282

A. L¨osungen der Aufgaben r1

r2

d1 d 2

1

2

3

4

5

6

0

0

1

2

2

2

Verfahren 3.1.2 findet den brauchbaren Plan: r1

r2

d1 d 2

1

2

3

4

5

6

2

2

2

1

0

0

L¨ osung zu Aufgabe: 3.2.2 (siehe Seite 165) Die Prozesse P = {P1 , · · · , Pn } seien entsprechend ihrer Frist geordnet. Es wird gezeigt, dass jedem brauchbaren Plan P L ein brauchbarer Plan P L zugeordnet werden kann, der mit Verfahren 3.2.2 erzeugt wird. Diese Erzeugung

erfolgt Prozess f¨ ur Prozess, iteriert u ¨ber P Lk . Angefangen bei P L0 = P L,
sei bereits P Lk , 0 ≤ k ≤ n erzeugt. Es gelte: i ≤ j ⇒ d i ≤ dj 1 ≤ i ≤ j ≤ k und 1≤i≤k−1 ci = si+1
Als n¨ achster Prozess wird Pk+1 aus P Lk neu eingeordnet:

L P

P L

P1

Pk

P1

Pk

ro P zes

X

Pk  1

k

k 1




Pk  1

rPeszo

X

Aufgrund der Konstruktion von P Lk+1 sind in der Prozessmenge X nur
solche enthalten, deren Frist gr¨ oßer oder gleich dk+1 ist, so dass auch P Lk+1


wieder brauchbar ist. Setze P Ln mit P L gleich. P L ist brauchbar und wird von Verfahren 3.2.1 erzeugt.

A.3

L¨ osungen der Aufgaben aus Kapitel 3

283

L¨ osung zu Aufgabe: 3.2.3 (siehe Seite 168) Schritt f¨ ur Schritt (siehe Abb. A.3) wird der Plan aus der Aufgabenstellung in einen mit Verfahren 3.2.2 erzeugbaren Plan umgeformt.

0

1

r3

d1

r2 r1 2

3

4

5

6

7

d3 d2 8

9 10

0 2 1 2 1 0 2 0 3 3 2 2 0 1 2 1 0 2 0 3 3 2 2 1 0 2 1 0 2 0 3 3 2 2 1 1 2 0 0 2 0 3 3 2 2 1 1 2 0 0 2 0 3 3 2 2 1 1 2 2 0 0 0 3 3 2 2 1 1 2 2 2 0 0 3 3 0 2 1 1 2 2 2 0 0 3 3 0

Abb. A.3. In Einheiten der Bezugszeitspanne ∆tG

2 1 1 2 2 2 0 3 0 3 0

wird ein beliebiger Plan Schritt f¨ ur Schritt so

2 1 1 2 2 2 0 3 3 0 0

umgeformt, wie er beim Planen nach Fristen entstehen w¨ urde.

L¨ osung zu Aufgabe: 3.2.4 (siehe Seite 172) Falls eine Frist¨ uberschreitung im Plan vorkommt, so wird diese beginnend beim Zeitpunkt 0 sp¨ atestens zum Zeitpunkt tkgV des kleinsten gemeinsamen Vielfachen aller Perioden auftreten, d. h. [0, tkgV ] = kgV {∆pi | 1 ≤ i ≤ n}. Um dies zu zeigen, wird die Situation gesucht, bei der die Antwortzeit eines beliebigen Prozesses i das Maximum annimmt. Dies ist der Fall, wenn die Anzahl der Fristen der anderen Prozesse j mit 1 ≤ j ≤ n und i = j im Intervall (rik , dki ] maximal ist. Alle Prozesse mit Fristen in diesem Intervall werden bei der Planung dem Prozess i vorgezogen. Da die Fristenplanung offenl¨asst, welcher Prozess im Falle von identischen Fristen dki = dlj vorgezogen wird, sei hier unterstellt, dass die Entscheidung zugunsten von Prozess j ausf¨allt. Weiterhin sei unterstellt, dass diese Entscheidung zwischen zwei Prozessen immer gleich ausf¨ allt. Offensichtlich tritt der schlechteste Fall f¨ ur Prozeß i ein, wenn dessen Frist dki mit einer Frist dlj von Prozeß j zusammenf¨ allt. Dieses Argument gilt f¨ ur alle Prozesse j mit 1 ≤ j ≤ n und i = j bei beliebigem Prozess i. Die gesuchte kritische Situation liegt vor, wenn alle Fristen aufeinander treffen, was zum Zeitpunkt tkgV zum ersten Mal der Fall sein wird. Im vorliegenden Fall kann dazu einfacher Satz 3.2.3 verwendet werden. Wenn die obige Problemstellung allerdings derart ausgeweitet wird, dass die Fristen der periodischen Prozesse nicht mehr mit dem entsprechenden Periodenende

284

A. L¨osungen der Aufgaben

zusammenfallen m¨ ussen, sondern jeweils bereits δxi Zeiteinheiten nach der jeweiligen Bereitzeit liegen, dann stellt Satz 3.2.3 nur noch ein notwendiges Kriterium dar. Ein hinreichendes – aber sehr strenges – Kriterium ist gegeben durch: n ∆ei ≤1 ∆x i i=1 Alternativ kann hier die Einplanbarkeit durch explizite Planerstellung bis zum Zeitpunkt tkgV festgestellt werden. Wenn außerdem die ersten Bereitzeiten der Prozesse nicht mehr identisch sein m¨ ussen, wird der Test auf die Existenz eines brauchbaren Planes weiter erschwert. Bisher war mit dem Zusammentreffen aller Fristen eine ausgezeichnete Planungssituation gegeben, die den Startpunkt der zyklischen Wiederholungen markierte. Bei versetzten ersten Bereitzeiten ist dies eventuell niemals der Fall. Statt dessen kann der Zustand CP L (P, t), in dem sich die Planung einer Prozessmenge P zu einem bestimmten Zeitpunkt t befindet, durch die Angabe der verbleibenden Ausf¨ uhrungszeit rest(i, t) jedes einzelnen Prozesses i beschrieben werden. Nun kann auch hier das Prinzip der Aufgabenstellung genutzt werden (siehe [88]). A.3.1

Satz A.3.1 Sei P L ein Plan nach Fristen f¨ ur eine Prozessmenge P

= | 1 ≤ i ≤ n} die sp¨ateste erste Bereitzeit {1, 2, . . . , n} und r = der Prozesse aus P . Ferner sei ∆tkgV = kgV {∆pi | 1 ≤ i ≤ n}. Beweis: Die Prozessmenge P kann genau dann brauchbar eingeplant werden, wenn 1. alle Fristen im Intervall [0, r + 2∆tkgV ] eingehalten werden und 2. die Planungssituation zu den Zeitpunkten r + ∆tkgV und r + 2∆tkgV u ¨bereinstimmt, d. h. CP L (P, r + ∆tkgV ) = CP L (P, r + 2∆tkgV ).
max{ri1

Bei der expliziten Planerstellung f¨ ur periodische Prozesse besteht generell das Problem, dass ∆tkgV sehr groß wird, wenn die Perioden teilerfremd sind. Tats¨ achlich ist die Problemstellung aus Satz A.3.1 sogar NP-vollst¨andig (siehe [88]). Die obigen Ergebnisse sind wohl nur praktisch verwendbar, wenn die Aufgabenstellung erlaubt, dass prime Periodenl¨angen gerade gebogen werden!

L¨ osung zu Aufgabe: 3.2.5 (siehe Seite 177) In der folgenden Tabelle ist f¨ ur eine Bezugszeitspanne ∆tG festgehalten, welcher Prozess nach den jeweiligen Verfahren EDF, LLF und MLLF den Pro-

A.3

L¨ osungen der Aufgaben aus Kapitel 3

285

zessor erh¨ alt. Zus¨ atzlich ist f¨ ur die Verfahren LLF und MLLF angegeben, wann und wie sich die Spielr¨ aume berechnen. ∆tG EDF ∆l1 ∆l2 ∆l3 LLF ∆l1 ∆l2 ∆l2 MLLF

0 1 7 5

1 1 6 5

2 7 5

2

2

2

2 3 5 5 4 3 5 5 4 3

3 3 4 4 4 3

3

4 1 3 3

5 2 3 2

6 2 2 2

7 2 1 2

8 2 1 1

9 2 1 1

10 2

1 3 3

2

2

1

1

2

2

1

1

2

2

2

1

0 1

2

L¨ osung zu Aufgabe: 3.3.1 (siehe Seite 180) Der Nachweis der Behauptung l¨ asst sich bereits f¨ ur zwei Prozesse f¨ uhren. Sei ohne Beschr¨ ankung der Allgemeinheit ∆p1 < ∆p2 und Prozess 2 habe die h¨ ohere Priorit¨ at. Konstruiert werden Prozessparameter derart, dass ein brauchbarer Plan existiert, jedoch jede Erh¨ ohung der Ausf¨ uhrungszeiten ∆e1 oder ∆e2 zu einer Fristverletzung innerhalb der Periode ∆p1 f¨ uhren w¨ urde. Dies ergibt sich f¨ ur (siehe Abb. A.4):

∆p1 = ∆e1 + ∆e2

Abb. A.4. Wegen seiner h¨ oheren Priorit¨ at wird Prozess 2 zuerst ausgef¨ uhrt.

Des Weiteren wird die Periode von Prozess 2 auf den folgenden Wert gesetzt: ∆p2 =

∆e2 (∆e1 + ∆e2 ) ∆e1

Eingesetzt berechnet sich die gesamte Auslastung als: 2∆e1 ∆e1 + ∆e2 Bei gegebener Ausf¨ uhrungzeit ∆e2 findet sich immer eine Ausf¨ uhrungszeit ∆e1 , die die Auslastung beliebig klein werden l¨asst. W¨ahrend eine so getroffene Wahl der Parameter noch einen brauchbaren Plan ergibt, verliert man

286

A. L¨osungen der Aufgaben

die Brauchbarkeit, wenn die Ausf¨ uhrungszeit f¨ ur Prozess 1 so um > 0 erh¨oht wird, dass gilt: U=

2(∆e1 + ) ∆e1 + + ∆e2

L¨ osung zu Aufgabe: 3.3.2 (siehe Seite 187) Analog zur Idee im Beweis von Satz 3.3.3 wird f¨ ur die Prozessmenge P = {1, . . . , n} ein Plan gesucht: bei dem die geringste Erh¨ ohung von Ausf¨ uhrungszeiten zu einer Frist¨ uberschreitung f¨ uhrt und die Auslastung U minimal werden l¨ asst.

ur i < j, d. h., Pj ist h¨oher priorisiert als Pi . Es gelte ∆pi > ∆pj f¨ Der Beweis wird in folgenden Teilschritten gef¨ uhrt: (1) Es wird gezeigt, dass die Auslastung U dann minimal wird, wenn f¨ ur je zwei Prozesse gilt: ∆pi /∆pj  ≤ 1 (2) Es wird gezeigt, dass die Auslastung U minimal wird, wenn f¨ ur die Ausf¨ uhrungszeit ∆ei eines Prozesses i ∈ {2, . . . , n} gilt: ∆ei = ∆pi−1 − ∆pi (3) Es wird nach demjenigen Verh¨ altnis ai = ∆p1 /∆pi , i ∈ {2, . . . , n} gesucht, das die Auslastung U minimal werden l¨asst. (4) Aus den berechneten Werten wird die minimale Auslastung Umin berechnet. zu (1): Gegeben sei ein Plan, bei dem die geringste Erh¨ohung von Ausf¨ uhrungszeiten zu einer Frist¨ uberschreitung f¨ uhrt. Angenommen f¨ ur einen Prozess j ∈ {2, . . . , n} gelte: ∆p1 = a ∆pj + ∆g

a∈N

mit a > 1 und ∆g ≥ 0. Durch Substitution der Prozesse 1 und j durch die


asst sich eine neue Prozessmenge P konstruieren (Abb. Prozesse 1 und j l¨ A.5), mit &
'
∆p1 /∆pj = 1

A.3

L¨ osungen der Aufgaben aus Kapitel 3

287

und


U ≤U Dazu sei


∆pj = a ∆pj


∆ej = ∆ej und, damit nach wie vor jede Erh¨ ohung von Ausf¨ uhrungszeiten zu einer Fristu uhrt, sei weiterhin: ¨berschreitung f¨


∆p1 = ∆p1


∆e1 = ∆e1 + (a − 1)∆ej Fur ¨ P

'p j

'p j 'p1

'p j

'e j

'e j

'e j t

Fur ¨ P’

'p’j

'p’1

'e j

'e j

t


Abb. A.5. Ausf¨ uhrungszeiten und Perioden von P und P .

Betrachtet wird die Differenz der Auslastungen:


U −U =

∆ei ∆e
i −
∆pi ∆p i
i∈P i∈P




= = = ≥




∆ej ∆e1 ∆ej ∆e1 + −
−
∆p1 ∆pj ∆p1 ∆pj ∆e1 ∆ej ∆e1 + (a − 1)∆ej ∆ej + − − ∆p1 ∆pj ∆p1 a∆pj (a − 1)∆ej (a − 1)∆ej − a∆pj ∆p1 0

Diese Konstruktion ist nacheinander auf jeden Prozess i ∈ {2, . . . , n} anzuwenden. Damit wird U minimal, wenn f¨ ur je zwei Prozesse gilt: ∆pi /∆pj  ≤ 1

288

A. L¨osungen der Aufgaben

zu (2): Im Beweis zu Satz 3.3.3 wurde bereits gezeigt, dass U minimal wird, wenn zwischen den Prozessen P1 und P2 gilt: ∆p1 − ∆p2 = ∆e2 Die dortige Argumentation l¨ asst sich unmittelbar auf die beiden h¨ochstpriorisierten Prozesse Pn−1 und Pn u ¨bertragen, da kein anderer Prozess deren Einplanung beeinflussen kann. Andererseits gilt, nachdem die Prozesse Pn bis Pi+1 bereits eingeplant sind, das obige Verh¨altnis auch zwischen Prozess i und Prozess i − 1, also: ∆pi−1 − ∆pi = ∆ei

i ∈ {2, . . . , n}

Damit sind bei einer minimalen Auslastung U bereits alle Ausf¨ uhrungszeiten angig: außer ∆e1 von der Periodendauer abh¨ ∆pi−1 − ∆pi ∆e1 U= + ∆pi ∆p1 i∈{2,...,n}

Da in einem brauchbaren Plan im Intervall [r11 , d11 ) alle Prozesse i ∈ {2, . . . , n} zweimal vollst¨ andig zur Ausf¨ uhrung kommen (Abb. A.6) und eine Erh¨ohung uberschreitung f¨ uhrt, muss gelten: von ∆e1 zu einer Frist¨ ∆pi−1 − ∆pi ∆e1 = ∆p1 − 2 i∈{2,...,n}

= 2∆pn − ∆p1 'p 3 'p 2 'p1 'e 3

'e 2

'e1

'e 3

'e 2

t Abb. A.6. Einbettung der Ausf¨ uhrungszeit von Prozess 1 in die L¨ ucken, die die Prozesse 2

und 3 lassen.

zu (3): altnis der Periode von Prozess 1 zu der von Sei ai ∈ R definiert als das Verh¨ Prozess i: ai = ∆p1 /∆pi

i ∈ {1, . . . , n}

Damit ist f¨ ur die Prozesse i ∈ {2, . . . , m}

A.3

L¨ osungen der Aufgaben aus Kapitel 3

289

∆ei = ∆pi−1 − ∆pi = ∆p1 /ai−1 − ∆p1 /ai und f¨ ur Prozess 1: ∆e1 = 2∆pn − ∆p1 = 2∆p1 /an − ∆p1 Damit berechnet sich die Auslastung U in Abh¨ angigkeit von ai , i ∈ {1, . . . , n}, wie folgt: ∆ei U = ∆pi i∈P ∆p1 /ai−1 − ∆p1 /ai 2∆p1 /an − ∆p1 = + ∆pi ∆p1 i∈{2,...,n}



 ai 2 = −1 + −1 ai−1 an i∈{2,...,n}

Durch die Festsetzung an+1 = 2 l¨ asst sich der gewonnene Ausdruck vereinheitlichen:  ai+1 = −1 ai i∈{1,...,n}

Zur Minimierung von U werden die Ableitungen betrachtet: (ai+1 /ai + ai /ai−1 ) δU =δ δai δai −ai+1 1 = + a2i ai−1 F¨ ur δU/δai = 0, i ∈ {2, . . . , n}, ergibt sich: ai+1 ai = ai−1 ai Daraus folgt f¨ ur i ∈ {1, . . . , n} ai+1 =c ai

c∈R

bzw. ai+1 = ci a1

, i ∈ {2, . . . , n}

290

A. L¨osungen der Aufgaben

Weiterhin gelten die Randbedingungen a1 = 1 und an+1 = 2, so dass aus an+1 = cn a1 folgt: c=

√ n 2

zu (4): Durch Einsetzen der ai , i ∈ {1, . . . , n} berechnet sich Umin :  ai+1 −1 Umin = ai i∈{1,...,n} (c − 1) = i∈{1,...,n}

=n

√ n

2−1



L¨ osung zu Aufgabe: 3.3.3 (siehe Seite 187) Nach l’Hˆ opital gilt: 1

lim

2n − 1

n→∞ 1

1 n

=

(2 n − 1) = n→∞ ( n1 ) lim 1

2 n ln(2)(− n12 ) = ln(2) lim n→∞ − n12

L¨ osung zu Aufgabe: 3.3.4 (siehe Seite 187) Es ist klar, dass bei UPH > 1 keine Brauchbarkeit m¨oglich ist. So ist lediglich f¨ ur UPH ≤ 1 nachzuweisen, dass ein brauchbarer Plan nach monotonen Raten existiert, bzw. ohne Beschr¨ ankung der Allgemeinheit der Prozess 1 seine Frist einh¨ alt. Aufgrund der harmonischen Perioden gibt es eine Folge nat¨ urlicher Zahlen (k2 , . . . , kn ) mit:

∆pi = ki+1 ∆pi+1

, i ∈ {1, . . . , n − 1}

A.3

L¨ osungen der Aufgaben aus Kapitel 3

291

Insbesondere die Periode von Prozess 1 ist ein Vielfaches von jeder anderen Periode i ∈ PH : ⎞ ⎛ i  ∆p1 = ⎝ kj ⎠ ∆pi j=2

(i Beachte, dass der Faktor j=2 kj angibt, wie oft Prozess i w¨ahrend einer Periode von Prozess 1 bereit wird und Prozess 1 verdr¨angt. F¨ ur die Auslastung gilt: 1 ≥ UP H n ∆ei = ∆pi i=1 =

∆e1 ∆p1

=

∆e1 ∆p1

 kj ∆ei

(  + i ∆pi k i=2 j j=2 ⎛ ⎞ n i  1 ⎝ + kj ⎠ ∆ei ∆pi i=2 j=2 n

(

i j=2

Daraus folgt, dass ∆p1 hinreichend groß ist, um die Ausf¨ uhrungszeit ∆e1, sowie die aller u ¨brigen Prozesse i > 1 aufzunehmen.

L¨ osung zu Aufgabe: 3.3.5 (siehe Seite 190) Erf¨ ullt sei die Bedingung aus dem LL-Test: n

√  ∆ei n ≤n 2−1 UP = ∆pi i=1

Daraus folgt unmittelbar: " n

∆ei i=1

∆pi

%n +1 ≤ nn 2

In einer Nebenrechnung werden nun zun¨ achst f¨ ur zwei reelle Zahlen a und b schrittweise folgende Eigenschaften festgehalten: 4 ab ≤ (a + b)2 Als n¨ achster Schritt der Verallgemeinerung ist festzuhalten: 2n ab ≤ (a + b)n

292

A. L¨osungen der Aufgaben

Noch allgemeiner gilt f¨ ur reelle Zahlen ai mit i ∈ {1, . . . , n}: %n " n n  ai ≤ ai nn i=1

i=1

¨ Ubertragen auf Ausf¨ uhrungszeiten und Perioden gilt entsprechend:  " %n n

n

 ∆ei ∆ei n +1 ≤ +1 n ∆pi ∆pi i=1 i=1 Daraus folgt nun unmittelbar: n

 ∆ei

∆pi

i=1

 +1 ≤2

L¨ osung zu Aufgabe: 3.3.6 (siehe Seite 192) Nach Konstruktion im Beweis von Satz 3.3.5 ¨andert sich f¨ ur Prozess 2 nichts:

∆e1 = 1

∆p1 = 5

Prozess 2 f¨ ullt die L¨ ucken bis zum Ende der zweiten Ausf¨ uhrung von Prozess 1: ∆p1 = ∆p2 + ∆e2 = 6 ∆e1 ∆e1 = ∆p1 =4 ∆p1 Der explizite Plan f¨ ur P  sieht folgendermaßen aus: 'p’ 1 'p’ 2 0

1

5

2 1 1 1 1 2

Offensichtlich handelt es sich um eine Randmenge, da es bereits bei der kleinsten Erh¨ ohung einer Ausf¨ uhrungszeit zu einer Fristverletztung kommen wird. F¨ ur den HB-Test ist die Prozessmenge P nicht von der Prozessmenge P  zu unterscheiden.

L¨ osung zu Aufgabe: 3.3.7 (siehe Seite 194) Die Prozessorauslastung der beiden Prozesse liegt f¨ ur P bei U = 1, 22 und, wenn man die durchschnittlichen Ausf¨ uhrungszeiten zugrunde legt, bei U = 0, 79. Wird nach monotonen Raten eingeplant, so wird zwar im durch-

A.3

L¨ osungen der Aufgaben aus Kapitel 3

293

schnittlichen Fall keine Frist verletzt, bei hoher Auslastung aber die Frist von Prozess 1. Die Idee besteht nun darin, die Periode des wichtigeren Prozesses 1 so zu transformieren, dass er nach der Strategie der monotonen Ratenplanung die h¨ ochste Priorit¨ at erh¨ alt. So kann die Arbeit, die Prozess 1 verrichtet, auch durch einen Prozess 3 geleistet werden, dessen Periode und Ausf¨ uhrungszeit jeweils halb so groß ist wie die von Prozess 1, also ∆p3 = 11, ∆e3 = 7 und ∆e3 = 5. Mit dem Ziel, Prozess 1 zu ersetzen, muss Prozess 3 im Wechsel die erste und die zweite H¨ alfte des Programms ausf¨ uhren, das als Ganzes von Prozess 1 ausgef¨ uhrt wurde. Auf diesem Weg ergibt sich die neue Prozessmenge P  : P 2 3

∆e 7 7

∆e 4 5

∆p 12 11

Damit werden die Anforderungen f¨ ur eine Priorit¨atszuordnung nach monotonen Raten erf¨ ullt.

L¨ osung zu Aufgabe: 3.3.8 (siehe Seite 194) Es muss nur noch gezeigt werden, dass Prozess 1 seine Frist einh¨alt. Die Approximation beginnt mit dem Startwert c11 = ∆e1 = 3: ! ! 3 3 1 2+ 2 c1 = 3 + 9 4 =7 ! ! 7 7 2 c1 = 3 + 2+ 2 9 4 =9 ! ! 9 9 3 c1 = 3 + 2+ 2 9 4 = 11 ! ! 11 11 4 c1 = 3 + 2+ 2 9 4 = 13 ! ! 13 13 5 c1 = 3 + 2+ 2 9 4 = 15 ! ! 15 15 6 c1 = 3 + 2+ 2 9 4 = 15

294

A. L¨osungen der Aufgaben

Ab c51 bleibt der Wert der Abschlusszeit bei 15. Dieser ist kleiner als die Frist ∆p1 = 19. Damit kann die Prozessmenge P = {1, 2, 3} nach monotonen Raten eingeplant werden.

L¨ osung zu Aufgabe: 3.4.1 (siehe Seite 204) Zun¨ achst gilt, dass in jedem inneren Zyklus einmal der Prozess 1 mit einer Zeiteinheit vorkommen muss. Des Weiteren kann der Prozess 2 und irgendein Abschnitt des Prozesses 3 nicht gleichzeitig in einem inneren Zyklus untergebracht werden. Bei diesen Bedingungen gibt es bis zum Zeitpunkt 12 genau zwei alternative Pl¨ ane:






















































F¨ ur beide Alternativen gibt es die M¨ oglichkeit, in den beiden verbleibenden inneren Zyklen eine Zeiteinheit des Prozesses 2 und zweimal zwei Zeiteinheiten des Prozesses 3 unterzubringen. Beides f¨ uhrt zu einer Frist¨ uberschreitung. Somit existiert bei dieser Zerlegung von Prozess 3 in Abschnitte keinen brauchbaren Plan.

A.4

A.4 L¨ osungen der Aufgaben aus Kapitel 4

L¨ osung zu Aufgabe: 4.1.1 (siehe Seite 218) Der Prozess 3 hat die h¨ ochste Priorit¨ at und wird nie verdr¨angt. Er kann jedoch durch einen Prozess niedrigerer Priorit¨at blockiert werden. Eine solche Blockade wird durch Prozess 2 verursacht, der sich im kritischen Gebiet css aufh¨ alt, das Prozess 3 betreten m¨ ochte. Prozess 2 seinerseits kann von Prozess 3 verdr¨ angt und von Prozess 1 blockiert werden. Letzteres geschieht dann, wenn sich Prozess 1 bereits im kritischen Gebiet cst aufh¨alt, das Prozess 2 betreten m¨ ochte. Auf diese Weise wird Prozess 3 indirekt von Prozess 1 blockiert (siehe Abb. A.7) F¨ ur die Frist, vor der Prozess 3 rechtzeitig enden muss, gilt:

r3 + ∆e3 + ∆b3 ≤ d3 Dabei entspricht ∆b3 der Summe der Zeitspannen, die sich Prozess 2 im kritischen Gebiet css und Prozess 1 im kritischen Gebiet cst aufhalten.

A.4

L¨ osungen der Aufgaben aus Kapitel 4

295

Abb. A.7. Indirekte Blockade bei der Synchronisierung mit zwei kritischen Gebieten.

L¨ osung zu Aufgabe: 4.1.2 (siehe Seite 226) Betrachtet wird das PIP unter der Regel, dass freiwerdende kritische Gebiete sofort an Prozesse vergeben werden, die darauf warten. Angewendet auf das Beispiel 4.1.3 ist die Prozessausf¨ uhrung identisch bis zu dem Zeitpunkt, zu asst. Hier (siehe Abb. A.8) wird dem Prozess 3 sein kritisches Gebiet css verl¨ nun dem Prozess 2, der das kritische Gebiet css betreten m¨ochte, dieses bereits zugeteilt. Er wechselt vom Zustand blockiert in den Zustand verdr¨ angt. Wenn dann sp¨ ater Prozess 4 das kritische Gebiet css betreten m¨ochte, ist es bereits vergeben. Deshalb erbt Prozess 2 die Priorit¨at 4 und f¨ uhrt seinen Aufenthalt im kritischen Gebiet css zu Ende. Zusammenfassend gilt: 1. Prozess 4 muss bis zu ∆e(cs1s ) auf css warten. 2. Prozess 4 muss bis zu ∆e(cs3t ) auf cst warten. In cst enthalten ist css . Wegen ∆e(cs3s ) < ∆e(cs3t ) geht jedoch nur ∆e(cs3t ) in den erweiterten RM-Test ein. 3. Prozess 4 muss bis zu ∆e(cs2s ) auf css warten.

Aus den Punkten 1. und 3. geht hervor, dass Prozess 4 bei dieser Version des PIP zweimal wegen des kritischen Gebietes css blockiert wird, und somit die zweite Folgerung aus Satz 4.1.1 nicht erf¨ ullt wird.

L¨ osung zu Aufgabe: 4.2.1 (siehe Seite 239) Prozess 2 besitzt die Ausf¨ uhrungszeit ∆e2 = 4, d.h. es sind l2 = 4 Schlitze auszuf¨ uhren. Diese entsprechen 4 Pseudoprozessen, die u ¨ber eigene Bereitzeiten und Fristen verf¨ ugen, wie die Tabelle und die Abb. A.9 zeigen.

296

A. L¨osungen der Aufgaben

Abb. A.8. Prozessausf¨ uhrung nach der Variante des PIP, die ein freiwerdendes kritisches

Gebiet sofort an einen Prozess vergibt, der darauf wartet.

l 1 2 3 4

∆p2 ∆e2 l

11/4 22/4 33/4 44/4

r2,l 0 2 5 8

d2,l 3 6 9 11

Abb. A.9. Prozess 2 ist aufgespalten in l2 = 4 Pseudoprozesse mit eigenen Bereitzeiten und Fristen. Eine m¨ ogliche

Ausf¨ uhrungsfolge der vier Pseudoprozesse ohne R¨ ucksicht auf andere Prozesse ist vermerkt.

L¨ osung zu Aufgabe: 4.3.1 (siehe Seite 262) Es ist f¨ ur jeden der Rahmen h ∈ {1, . . . , 4} zu pr¨ ufen, ob er immer fristgerecht   h zu verschickt werden kann. Somit ist zuerst ∆bph und dann Vh = ∆bp ∆ph bestimmen. Des Weiteren ist f¨ ur jedes v ∈ {1, . . . , Vh } die Wartezeit ∆wh (v) zu berechnen, bevor die eigentliche Brauchbarkeitspr¨ ufung erfolgen kann, die lautet:

∆jh + ∆wh (v) + ∆eh ≤ v ∆ph

A.4

L¨ osungen der Aufgaben aus Kapitel 4

297

Begonnen wird mit der Besch¨ aftigungsphase von Rahmen 4. Der Anfangswert lautet: (0)

∆bp4 = ∆b4 + ∆e4 = 4+4 =8 (1)

Die Reihe konvergiert bereits f¨ ur ∆bp4 : (1) ∆bp4

! 8+1 4 = 4+ 10 =8

Da damit V4 den Wert 1 bekommt, ist nur ∆w4 (1) zu berechnen. Der Anfangswert ist gegeben als: (0)

∆w4 (1) = ∆b4 + (1 − 1)∆e4 =4 (1)

Auch hier konvergiert die Reihe bereits f¨ ur ∆w4 (1): (1)

∆w4 (1) = 4 + (1 − 1) 4 =4 ufung zeigt, dass Rahmen 4 Damit ist ∆w4 (1) = 4 und die Brauchbarkeitspr¨ immer brauchbar u ¨bertragen werden kann: ∆j4 + ∆w4 (1) + ∆e4 = 1 + 4 + 4 ≤ 10 = ∆p4 Weiter geht es nun mit dem Rahmen 3 und der Berechnung seiner Besch¨ aftigungsphase. Der Anfangswert lautet: (0)

∆bp3 = ∆b3 + ∆e3 = 4+2 =6 Des Weiteren ergeben sich die Werte f¨ ur die Besch¨aftigungsphase bezogen auf Rahmen 3: ! ! 6+1 6+3 (1) 2+ 4 ∆bp3 = 4 + 15 10 = 4+2+4 = 10

(2) ∆bp3

! ! 10 + 1 10 + 3 2+ 4 = 4+ 15 10

298

A. L¨osungen der Aufgaben

= 4+2+8 = 14 (3) ∆bp3

! ! 14 + 1 14 + 3 2+ 4 = 4+ 15 10 = 4+4+8 = 16

(4) ∆bp3

! ! 16 + 1 16 + 3 2+ 4 = 4+ 15 10 = 4+4+8 = 16

Damit konvergiert die Berechnung. Die Besch¨aftigungsphase dauert bp3 = 16 Zeiteinheiten, was ein V3 = 2 ergibt. Aus diesem Grund sind die beiden Warufen. Es wird begonnen tezeiten w3 (1) und w3 (2) zu berechnen und zu u ¨berpr¨ (0) mit w3 (1), bzw. genauer mit dem Anfangswert w3 (1): (0)

∆w3 (1) = ∆b3 + (1 − 1)∆e3 =4 (1)

(2)

Es ergeben sich nur noch die Werte w3 (1) und w3 (1), bis die Reihe der Wartezeiten konvergiert:  

 4+1 (1) +1 4 ∆w3 (1) = 4 + (1 − 1) 2 + 10 =8  

 8+1 (2) ∆w3 (1) = 4 + (1 − 1) 2 + +1 4 10 =8 Damit ist ∆w3 (1) = 8 und die Brauchbarkeitspr¨ ufung zeigt, dass der erste Rahmen 3 immer brauchbar u ¨bertragen werden kann: ∆j3 + ∆w3 (1) + ∆e3 = 3 + 8 + 2 ≤ 15 = ∆p3 F¨ ur den jeweils zweiten Rahmen 3, der zu u ¨bertragen ist, findet man den Anfangswert: (0)

∆w3 (2) = ∆b3 + (2 − 1)∆e3 =6

A.4

L¨ osungen der Aufgaben aus Kapitel 4

299 (1)

(2)

(3)

Auch hier ergeben sich nur die Werte w3 (2), w3 (2) und w3 (2), bis die Reihe der Wartezeiten konvergiert:  

 6+1 (1) +1 4 ∆w3 (2) = 4 + (2 − 1) 2 + 10 = 10  

 10 + 1 (2) ∆w3 (2) = 4 + (2 − 1) 2 + +1 4 10 = 14  

 14 + 1 (3) ∆w3 (2) = 4 + (2 − 1) 2 + +1 4 10 = 14 Damit ist ∆w3 (2) = 14 und die Brauchbarkeitspr¨ ufung zeigt, dass der zweite Rahmen 3 immer brauchbar u bertragen werden kann: ¨ ∆j3 + ∆w3 (2) + ∆e3 = 3 + 14 + 2 ≤ 30 = 2 ∆p3 Mit der positiven Pr¨ ufung der F¨ alle v = 1 und v = 2 ist sichergestellt, dass Rahmen 3 immer brauchbar u ¨bertragen werden kann. In der Systematik der Brauchbarkeitspr¨ ufung geht es als n¨achstes um Rahmen 2. Der Anfangswert f¨ ur seine Besch¨ aftigungsphase lautet: (0)

∆bp2 = ∆b2 + ∆e2 = 1+4 =5 Des Weiteren ergeben sich die Werte f¨ ur die Besch¨aftigungsphase bezogen auf Rahmen 2: ! ! ! 5+3 5+1 5+1 (1) 4+ 2+ 4 ∆bp2 = 1 + 12 15 10 = 1+4+2+4 = 11

(2) ∆bp2

! ! ! 11 + 3 11 + 1 11 + 1 4+ 2+ 4 = 1+ 12 15 10 = 1+4+2+8 = 15

(3) ∆bp2

! ! ! 15 + 3 15 + 1 15 + 1 4+ 2+ 4 = 1+ 12 15 10 = 1+8+4+8 = 21

(4) ∆bp2

! ! ! 21 + 3 21 + 1 21 + 1 4+ 2+ 4 = 1+ 12 15 10

300

A. L¨osungen der Aufgaben

= 1 + 8 + 4 + 12 = 25

(5) ∆bp2

! ! ! 25 + 3 25 + 1 25 + 1 4+ 2+ 4 = 1+ 12 15 10 = 1 + 12 + 4 + 12 = 29

(6) ∆bp2

! ! ! 29 + 3 29 + 1 29 + 1 4+ 2+ 4 = 1+ 12 15 10 = 1 + 12 + 6 + 12 = 31

(7) ∆bp2

! ! ! 31 + 3 31 + 1 31 + 1 4+ 2+ 4 = 1+ 12 15 10 = 1 + 12 + 4 + 16 = 35

(8) ∆bp2

! ! ! 35 + 3 35 + 1 35 + 1 4+ 2+ 4 = 1+ 12 15 10 = 1 + 12 + 4 + 16 = 35

Damit konvergiert die Berechnung. Die Besch¨aftigungsphase dauert bp2 = 35 Zeiteinheiten, was ein V2 = 3 ergibt. Aus diesem Grund sind die drei ufen. Es Wartezeiten w2 (1), w2 (2) und w2 (3) zu berechnen und zu u ¨berpr¨ wird begonnen mit der Wartezeit w2 (1), bzw. genauer mit dem Anfangswert (0) w2 (1): (0)

∆w2 (1) = ∆b2 + (1 − 1)∆e2 =1 (1)

(2)

Es ergeben sich nur noch die Werte w2 (1) und w2 (1), bis die Reihe der Wartezeiten konvergiert:  

  

 1+1 1+3 (1) +1 2+ +1 4 ∆w2 (1) = 1 + (1 − 1) 2 + 15 10 =7  

  

 7+1 7+3 (2) ∆w3 (1) = 4 + (1 − 1) 2 + +1 4+ +1 4 15 10 =7 Damit ist ∆w2 (1) = 7 und die Brauchbarkeitspr¨ ufung zeigt, dass der erste Rahmen 2 immer brauchbar u ¨bertragen werden kann: ∆j2 + ∆w2 (1) + ∆e2 = 1 + 7 + 4 ≤ 12 = ∆p2

A.4

L¨ osungen der Aufgaben aus Kapitel 4

301

F¨ ur den jeweils zweiten Rahmen 2, der zu u ¨bertragen ist, findet man den Anfangswert: (0)

∆w2 (2) = ∆b2 + (2 − 1)∆e2 =5 (1)

(4)

Hernach ergeben sich die Werte von w2 (2) bis w2 (2), bis die Reihe der Wartezeiten konvergiert:  

  

 5+1 5+3 (1) +1 2+ +1 4 ∆w2 (2) = 1 + (2 − 1) 4 + 15 10 = 1+4+2+4 = 11 (2) ∆w2 (2)



 

   11 + 1 11 + 3 +1 2+ +1 4 15 10



 

   15 + 1 15 + 3 +1 2+ +1 4 15 10



 

   17 + 1 17 + 3 +1 2+ +1 4 15 10

= 1 + (2 − 1) 4 + = 1+4+2+8 = 15

(3) ∆w2 (2)

= 1 + (2 − 1) 4 + = 1+4+4+8 = 17

(4) ∆w2 (2)

= 1 + (2 − 1) 4 + = 1+4+4+8 = 17

Damit ist ∆w2 (2) = 17 und die Brauchbarkeitspr¨ ufung zeigt, dass der zweite Rahmen 2 immer brauchbar u ¨bertragen werden kann: ∆j2 + ∆w2 (2) + ∆e2 = 1 + 17 + 4 ≤ 24 = 2 ∆p2 F¨ ur den jeweils dritten Rahmen 2, der zu u ¨bertragen ist, findet man den Anfangswert: (0)

∆w2 (3) = ∆b3 + (3 − 1)∆e3 =9 (1)

(3)

Hernach ergeben sich die Werte von w2 (3) bis w2 (3), bis die Reihe der Wartezeiten konvergiert:  

  

 9+1 9+3 (1) +1 2+ +1 4 ∆w2 (3) = 1 + (3 − 1) 4 + 15 10 = 1+8+2+8 = 19

302

A. L¨osungen der Aufgaben (2) ∆w2 (3)



 

   19 + 1 19 + 3 +1 2+ +1 4 15 10



 

   25 + 1 25 + 3 +1 2+ +1 4 15 10

= 1 + (3 − 1) 4 + = 1 + 8 + 4 + 12 = 25

(3) ∆w2 (3)

= 1 + (3 − 1) 4 + = 1 + 8 + 4 + 12 = 25

Damit ist ∆w2 (3) = 25 und die Brauchbarkeitspr¨ ufung zeigt, dass der dritte Rahmen 2 immer brauchbar u ¨bertragen werden kann: ∆j2 + ∆w2 (3) + ∆e2 = 1 + 25 + 4 ≤ 36 = 3 ∆p2 Mit der positiven Pr¨ ufung der F¨ alle v = 1, v = 2 und v = 3 ist sichergestellt, dass Rahmen 2 immer brauchbar u ¨bertragen werden kann. In der Systematik der Brauchbarkeitspr¨ ufung w¨are nun der Rahmen 1 an der Reihe. Aufgrund der L¨ ange des Verfahrens wird auf diese Pr¨ ufung, die auch Brauchbarkeit ergeben w¨ urde, verzichtet.

L¨ osung zu Aufgabe: 4.3.2 (siehe Seite 271) Gegeben sei ein Rechnernetz mit 4 Knoten und folgenden Anspr¨ uchen an synchronen und asynchronen Rahmen:

ND 1 2 3 4

∆SF (j) 0 7 2 3

∆AF (j) 12 1 5 1

¨ Der Einfachheit halber wird die Zeitspanne zur Ubertragung der Marke vernachl¨ assigt: ∆T P T (j) = 0 f¨ ur j ∈ {1, . . . , 4}. Entsprechend muss die Rotationszielzeit ∆T T RT mindestens 12 Zeiteinheiten lang sein und sei auch so festgesetzt: ∆T T RT = 12 Zeiteinheiten festgesetzt. F¨ahrt man im ersten Umlauf ohne Last, also mit ∆tSF (1, j) = 0, dann kommt nach einem ganzen Umlauf die Marke bei Knoten 1 fr¨ uh an. Entsprechend darf Knoten 1 f¨ ur 12 Zeiteinheiten asynchrone Nachrichten senden. Danach ist die Marke in den nachfolgenden Knoten 2,3 und 4 nicht mehr fr¨ uh. Hier d¨ urfen nur noch die synchronen Rahmen gesendet werden. Die drei Knoten sch¨opfen den zur Verf¨ ugung stehenden Zeitrahmen mit ∆tSF (2, 2) = 7

A.4

L¨ osungen der Aufgaben aus Kapitel 4

303

∆tSF (2, 3) = 2 ∆tSF (2, 2) = 3 vollst¨ andig aus. Folglich trifft die Marke bei Knoten 1 erst wieder nach ∆tT RT = 24 Zeiteinheiten ein (siehe auch Abb. A.4).



  








Literaturverzeichnis [1] Ian F. Akyildiz, Tommaso Melodia, and Kaushik R. Chowdhury. A survey on wireless multimedia sensor networks. Computer Networks, Elsevier, 51(4):921–960, March 2007. [2] David W. Allan, Neil Ashby, and Clifford C. Hodge. The science of timekeeping. Application note 1289, Hewlett Packard, 1997. [3] James F. Allen. Maintaining knowledge about temporal intervals. Communications of the ACM, 26(11):832–843, 1983. [4] Rajeev Alur. Techniques for Automatic Verification of Real-Time Systems. PhD thesis, Stanford University, California, 1991. [5] Anouck R. Girard amd Stephen C. Spry and J. Karl Hedrick. Real-time embedded hybrid control software for intelligent cruise control. IEEE Roborics and Automation Magazine, 12(5):22–28, March 2005. [6] G. Amdahl. Validity of the single-processor approach to achieving large scale capabilities. In AFIPS Conference Proceedings, volume 30, pages 483–485, Atlantic City, NJ, April 1967. [7] James Anderson, Philip Holman, and Anand Srinivasan. Fair scheduling of real-time tasks on multiprocessors. In Joseph Y.-T. Leung, editor, Handbook of Scheduling - Algorithms, Models, and Performance Analysis, pages 31(1)–31(21). Chapman and Hall, Boca Raton, 2004. [8] G. R. Andrews. Concurrent Programming. The Benjamin/Cummings Publishing Company, 1991. [9] N. Audsley. Deadline monotonic scheduling. Technical report, Department of Computer Science, University of York, September 1990. [10] N. Audsley, A. Burns, M. Richardson, K. Tindell, and A. Wellings. Absolute and relative temporal constraints in hard real-time databases. In Proc. of IEEE Euromicro Workshop on Real Time Systems, February 1992. [11] N. Audsley, A. Burns, M. Richardson, K. Tindell, and A. Wellings. Applying new scheduling theory to static priority pre-emptive scheduling. Software Engineering Journal, 8(5):284–292, September 1993. [12] Claus Bahlmann, Ying Zhu, Visvanathan Ramesh, Martin Pellkofer, and Thorsten Kohler. A system for traffic sign detection, tracking, and recognition using color, shape and motion information. In IEEE Intelligent Vehicles Symposium, pages 199–204, Washington, June 2005. [13] T. P. Baker and A. Shaw. The cyclic executiv model and Ada. Journal of Real-Time Systems, 1(1), 1989.

306

Literaturverzeichnis

[14] Patricia Balbastre, Ismael Ripoll, and Alfons Crespo. Optimal deadline assignment for periodic real-time tasks in dynamic priority systems. In 18th Euromicro Conference on Real-Time Systems, pages 65–74, Dresden, Germany, July 2006. IEEE. [15] Sanjoy K. Baruah, N. K. Cohen, C. Greg Plaxton, and Donald A. Varvel. Proportionate progress: A notion of fairness in resource allocation. Algorithmica, 15(6):600–625, 1996. [16] Claudio Bettini, Xiaoyang Sean Wang, and Sushil Jajodia. A general framework and time granularity and its application to temporal reasoning. Annals of Mathematics and Artificial Intelligence, 22(1-2):29–58, 1998. [17] Enrico Bini, Giorgio Buttazzo, and Giuseppe Buttazzo. Rate monotonic scheduling: The hyperbolic bound. IEEE Transactions on Computers, 52(7):933–942, July 2003. [18] Enrico Bini, Marco Di Natale, and Giorgio Buttazzo. Sensitivity analysis for fixed-priority real-time systems. In 18th Euromicro Conference on Real-Time Systems (ECRTS), pages 13–22, Dresden, Germany, July 2006. IEEE Computer Society. [19] Gunter Bolch and Martina-Maria Vollath. Prozeßautomatisierung: Aufgabenstellung, Realisierung und Anwendungsbeispiele. Leitf¨ aden der angewandten Informatik. Teubner-Verlag, Stuttgart, 1991. [20] Bruno Bouyssounouse and Joseph Sifakis. Tools for Verification and Validation. Springer Verlag, Berlin, LNCS 3436 edition, January 2005. [21] Samuel L. Braunstein and Carlton N. Caves. Statistical distance and the geometry of quantum states. Physical Review Letters, 72(22):3439–3443, May 1994. [22] Peter Brich, Gerhard Hinsken, and Karl-Heinz Krause. Echtzeitprogrammierung in Java. Publicis MCD Verlag, 2000. [23] Randy Brown. Calender queues: A fast O(1) priority queue implementation. Communications of the ACM, 31(10):1220–1227, October 1988. [24] Alan Burns and Andy J. Wellings. Real-Time Systems and Programming Languages. Addison Wesley, 2001. [25] Giorgio C. Buttazzo. Rate Monotonic vs. EDF: Judgement day. In Rajeev Alur and Insup Lee, editors, Third International Conference on Embedded Software (EMSOFT 2003), volume 2855 of LNCS, pages 67–83, Philadelphia, USA, October 2003. Springer-Verlag. [26] Giorgio C. Buttazzo. Hard Real-Time Computing Systems: Predictable Scheduling, Algorithms and Applications. Kluwer Academic Publishers, 2005.

Literaturverzeichnis

307

[27] Vladimir Bu˘zek, Radoslav Derka, and Serge Massar. Optimal quantum clocks. Physical Review Letters, 82(10):2207–2210, March 1999. [28] Manuel I. Capel and Juan A. Holgado. A formal system specification to derive a simulink model for a real-time hybrid study case using CSP+T. In VIII Jornadas de Tiempo Real, pages 100–116, Bilbao, February 2005. [29] John Carpenter, Shelby Funk, Anand Srinivasan, James Anderson, and Sanjoy Baruah. A categorization of real-time multiprocessor scheduling problems and algorithms. In Joseph Y.-T. Leung, editor, Handbook of Scheduling Algorithms, Models, and Performance Analysis, pages 30(1)–30(19). Chapman and Hall, Boca Raton, 2004. [30] Anton Cervin and Johan Eker. Control-scheduling codesign of real-time systems: The control server approach. Journal of Embedded Computing, 1(2):209–224, 2005. [31] Antione Colin, Isabelle Puaut, Christine Rochange, and Pascal Sainrat. Calcul de majorants de pire temps d’ex´ecution: ´etat de l’art. Technical report, Institut de Recherche en Informatique et Syst`eme Al´eatoires (IRISA), Rennes, France, May 2002. [32] Jim Cooling. Software Engineering for Real-Time Systems. Addison Wesley, Harlow, England, 2003. [33] Francis Cottet, Jo¨elle Delacroix, Claude Kaiser, and Zoubir Mammeri. Scheduling in Real-Time Systems. John Wiley and Sons, Chichester, 2002. [34] Robert I. Davis, Alan Burns, Reinder J. Bril, and Johan J. Lukkien. Controller area network (CAN) schedulability analysis: Refuted, revisited and revised. Rael-Time Systems, 35(0):239–272, January 2007. [35] P. Decaudin and F. Neyret. Rendering forest scenes in real-time. In Rendering Techniques, Eurographics Symposium on Rendering, pages 93–102, June 2004. [36] T. DeMarco. Structured Analysis and System Specification. Prentice Hall, Eaglewood Cliffs, NJ, 1978. [37] O. Deussen. Computergenerierte Pflanzen. Springer-Verlag, Berlin, 2003. [38] Deutsches Institut f¨ ur Normung. Informationsverarbeitung – Begriffe, DIN 43000. Beuth-Verlag, Berlin, K¨ oln, 1985. [39] Henning Dierks. The production cell: A verified real-time system. In Bengt Jonsson and Joachim Parrow, editors, Formal Techniques for Real-Time and Fault-Tolerant Systems, LNCS 1135, pages 208–227, 1996. [40] E. W. Dijkstra. Cooperating sequential processes. In F. Genuys, editor, Programming Languages, pages 43–112. Academic Press, New York, 1968.

308

Literaturverzeichnis

[41] Jad El-khoury. A Model Management and Integration Platform for Mechatronics Product Development. Doctoral thesis, School of Industrial Engineering and Management, Dept. of Machine Design, Stockholm, Sweden, January 2006. [42] C.-Y. Fang, S.-W. Chen, and C.-S. Fuh. Road-sign detection and tracking. IEEE Transactions on Vehicular Technology, 52(5):1329–1341, September 2003. [43] Stuart Faulk, John Brackett, Paul Ward, and James Kirby. The core method for real-time requirements. IEEE Software, 9:22–33, September 1992. [44] Hugo Fierz. Eingebettete Systeme als Architektur mechanistischer Modelle. urcher Hochschule Winterthur. www.ciptool.ch/data/cip mech.pdf, Z¨ [45] M. Flynn. Very high speed computing systems. Proc. of the IEEE, 54(9):1901–1909, 1966. [46] L.R. Ford and D.R. Fulkerson. Flows in Networks. Princeton University Press, Princeton, New Jersey, 1957. [47] B. O. Gallmeister. POSIX.4: Programming for the Real World. O’Reilly and Associates, Inc., Sebastopol, California, 1995. [48] Michael R. Garey and David S. Johnson. Computers and Intractability. A Guide to the Theory of NP-Completeness. W. H. Freeman and Company, New York, San Francisco, 1979. [49] Ataeddin Ghassemi-Tabrizi. Realzeit-Progrmmierung. Springer Verlag, 2000. [50] Hassan Gomaa. Software Design Methods for Concurrent and Real-Time Systems. The SEI Series in Software Engineering. Addison-Wesley, Reading, Mass., 1993. [51] Hassan Gomaa. Designing Concurrent, Distributed, and Real-Time Applications with UML. Addison-Wesley, Boston, 2000. [52] El˙zbieta Hajnicz. Time Structures - Formal Description and Algorithmic Representation. LNAI 1047. Springer-Verlag, Berlin, 1996. [53] W. A. Halang and R. Konakovsky. Sicherheitsgerichtete Echtzeitsysteme. Oldenbourg-Verlag, M¨ unchen, 1999. [54] W.A. Halang, G. Hommel, and R. Lauber. Perspektiven der Informatik in der Echtzeitverarbeitung. Informatik Spektrum, 16(6):357–362, 1993. [55] S. Hall´e, J. Laumonier, and B. Chaib-draa. A decentralized approach to collaborative driving coordination. In IEEE Conference on Intelligent Transportation Systems, Washington, D.C., October 2004. [56] Fred Halsall. Data communications, computer networks, and open systems. Addison-Wesley, third edition, 1992.

Literaturverzeichnis

309

[57] P. Brinch Hansen. Concurrent programming concepts. ACM Computing Surveys, 5(5):223–245, December 1973. [58] Derek J. Hatley and Imtiaz A. Pirbhai. Strategies for Real-Time System Specification. Dorset House Publishing, New York, 1987. [59] C. Heitmeyer and N. Lynch. The generalized railroad crossing: A case studie in formal verification of real-time systems. In Proc. of the IEEE Real-Time Systems Symposium, pages 120–131. IEEE Computer Society Press, 1994. [60] William Henderson, David Kendall, and Adrian Robson. Improving the accuracy of scheduling analysis applied to distributed systems. International Journal of Time-Critical Computing Systems, 20:5–25, 2001. [61] R. G. Herrtwich. Echtzeit. Informatik Spektrum, 14:93–96, 1989. [62] R. G. Herrtwich. Betriebsmittelvergabe unter Echtzeitgesichtspunkten. Informatik-Spektrum, 14(2):123–136, 1991. [63] R. G. Herrtwich and G. Hommel. Kooperation und Konkurrenz. Nebenl¨ aufige, verteilte und echtzeitabh¨ angige Programmsysteme. Springer-Verlag, Berlin, 1989. [64] Volker Heun. Grundlegende Algorithmen. Vieweg, Braunschweig, Wiesbaden, 2000. [65] C. A. R. Hoare. Towards a theory of parallel programming. In C. A. R. Hoare and R. H. Perrot, editors, Operating System Techniques, pages 61–71. Academic Press, London, 1972. [66] International Standard Organization. Basic Reference Model for Open Systems Interconnection, 1984. [67] J. R. Jackson. Scheduling a production line to minimize maximum tardiness. Technical report, Mgt. Sci. Res. Project, Res. Rept. 43, UCLA, January 1955. [68] Kevin Jeffay and Donald L. Stone. Accounting for interrupt handling costs in dynamic priority task systems. In Proceedings of the IEEE Real-Time Symposium, pages 212–221, Los Angeles, USA, December 1993. [69] M. Joseph and P. Pandya. Finding response times in a real-time system. The Computer Journal (British Computer Society), 29(5):390–395, October 1986. [70] Tiko Kameda. Testing deadlock-freedom of computer systems. Journal of the Association for Computing Machinery, 27(2):270–280, 1980. [71] Johan Karlsson. On Data Structures and Memory Models. Doctoral thesis, Lule˚ a University of Technology, Sweden, May 2006. [72] Taewoong Kim, Heonshik Shin, and Naehyuck Chang. Deadline assignment to reduce output jitter of real-time tasks. In 16th IFAC Workshop on Distributed Computer Control Systems, pages 67–72, Sidney, Australia, November 2000.

310

Literaturverzeichnis

[73] Raimund Kirner. Extending Optimising Compilation to support Worst -Case Execution Time Analysis. PhD thesis, Technische Universit¨ at Wien, May 2003. [74] H. Kopetz, A. Damm, C. Koza, M. Mulazzani, W. Schwabl, C. Senft, J. Reisinger, and R. Zainlinger. Distributed fault-tolerant real-time systems: The MARS approach. IEEE Micro, 9(1):25–40, February 1989. [75] Hermann Kopetz. Real-Time Systems - Design Principles for Distributed Embedded Applications. Kluwer Academic Publishers, Boston, 1997. [76] Hermann Kopetz. Software engineering for real-time: A roadmap. In IEEE Software Engineering Conference (ICSE) - Future of SE track, pages 2001–211, Limmerick, Ireland, 2000. [77] Timo Kosch. Local danger warning based on vehicle ad-hoc networks. In Proceedings of the 1st International Workshop on Intelligent Transportation (WIT’2005), Hamburg, Germany, March 2004. IEEE Communications Society Germany. [78] C. M. Krishna and Kang G. Shin. Real-Time Systems. McGraw-Hill Companies, New York, 1997. [79] C.M. Krishna and Y.H. Lee. Real-time systems. IEEE Computer, 24(5):10–11, May 1991. [80] Th. S. Kuhn. Die Struktur der wissenschaftlichen Revolutionen. Suhrkamp Verlag, Frankfurt, 1969. [81] Sunil Kumar, Vineet S. Raghavan, and Jing Deng. Medium access control protocols for ad hoc wireless networks: A survey. Ad Hoc Networks, Elsevier, 4:326–358, 2006. [82] Anshul Kundaje, Geetali Bhatia, Mangesh Dalvi, Meghna Haridas, and Sumeru Nandi. Voice over IP. Technical report, Electronical Engineering Department, University of Bombay, 2001. [83] B. W. Lampson and D. D. Redell. Experiences with processes and monitors in mesa. Communications of the ACM, 23(2):105–117, February 1980. [84] Phil Laplante. Real-Time Systems Design and Analysis: An Engineer’s Handbook. IEEE Press, New York, 1993. [85] J. P. Lehoczky, L. Sha, and Y. Ding. The rate monotonic scheduling algorithm: Exact characterization and average case behavior. In Proceedings of the 10th IEEE Symposium on Real-Time Systems, pages 166–171, December 1989. [86] John P. Lehoczky. Fixed priority scheduling of task sets with arbitrary deadlines. In Proc. of the IEEE Real-Time Systems Symposium, pages 201–209, December 1990.

Literaturverzeichnis

311

[87] J. Y-T. Leung and J. Whitehead. On the complexity of fixed-priority scheduling of periodic, real-time tasks. Perform. Eval., 2(4):237–250, 1982. [88] Joseph Y-T. Leung and M. L. Merrill. A note on preemptive scheduling of periodic real-time tasks. Information Processing Letters, 11(3):115–118, November 1980. [89] Claus Lewerentz and Thomas Lindner. Formal Development of Reactive Systems - Case Study Production Cell. LNCS 891. Springer Verlag, Berlin, January 1995. [90] Xianfeng Li, Abhik Roychoudhury, and Tulika Mitra. Modeling out-of-order processors for WCET analysis. Real-Time Systems, 34:195–227, 2006. [91] C. L. Liu and James W. Layland. Scheduling algorithms for multiprogramming in a hard-real-time environment. Journal of the ACM, 20(1):46–61, January 73. [92] Jane S. W. Liu. Real-Time Systems. Prentice Hall, New Jersey, 2000. [93] C. Douglass Locke. Software architecture for hard real-time applications: Cyclic executives vs. fixed priority executives. Journal of Real-Time Systems, 4(1):37–53, March 1992. [94] G. Logothetis and K. Schneider. Abstraction from counters: An application on real-time systems. In Design, Automation, and Test in Europe (DATE’2000), pages 486–493, Paris, France, March 2000. [95] Lars Lundberg. Utilization based schedulability bounds for age constraint process sets in real-time systems. Real-Time Systems, Kluwer Academic Publishers, 23:273–295, 2002. [96] Thomas Lundqvist. A WCET Analysis Method for Pipelined Microprocessors with Cache Memories. Phd thesis, Chalmers University of Technology, G¨ oteborg, Sweden, 2002. [97] Jan Lunze. Automatisierungstechnik. Oldenbourg Verlag, M¨ unchen, 2003. [98] Ricardo Santor Marques. M´ethodologie d´ eveloppement des services de communication temps-r´ eel d’un intergiciel embarqu´e dans l’automobile. Thesis, Laboratoire Lorrain de Recherche en Informatique et ses Applications (LORIA), Institut National Polytechnique de Lorraine, Nancy, Septembre 2006. [99] Peter Marwedel. Eingebettete Systeme. Springer-Verlag, Berlin, 2007. [100] A. K. Mok. Fundamental design problems of distributed systems for the hard-real-time environment. PhD thesis, Massachusetts Institute of Technology, 1983. [101] P. J. Moylan, R.E. Betz, and R.H. Middleton. The priority disinheritance problem. Technical Report EE9345, University of Newcastle, 1993.

312

Literaturverzeichnis

[102] Nicolas Navet, Yeqiong Song, Fran¸coise Simonot-Lion, and C´ederic Wilwert. Trends in automotive communication systems. Proceedings of the IEEE, special issue on Industrial Communications Systems, 93(6):1204–1223, June 2005. [103] Rosa Casta n´e, Pau Mart´ı, Manel Valesco, Anton Cervin, and Dan Henriksson. Resource management for control tasks based on the transient dynamics of closed-loop systems. In 18th Euromicro Conference on Real-Time Systems (ECRTS), pages 171–180, Dresden, Germany, July 2006. IEEE Computer Society. [104] S.-H. Oh and S.-M. Yang. A modified least laxity scheduling algorithm. In Proceedings of the 5th International Conference on Real-Time Systems and Applications, pages 31–36, Hiroshima, Japan, October 1998. [105] G. L. Peterson. Myths about the mutual exclusion problem. Information Processing Letters, 12(3):115–116, June 1981. [106] Traian Pop, Petru Eles, and Zebo Peng. Schedulability analysis for distributed heterogeneous time/event triggered real-time systems. In Europeen Conference on Real-Time Systems (ECRTS), pages 257–266, 2003. [107] L. Priese, J. Klieber, R. Lakmann, V. Rehrmann, and R. Schian. New results on traffic sign recognition. In IEEE Intelligent Vehicles Symposium, pages 249–254, Paris, October 1994. [108] Sasikumar Punnekkat, Rob Davis, and Alan Burns. Sensitivity analysis of real-time task sets. In Third Asian Computer Science Conference (ASIAN), LNCS 1345, pages 72–82, Kathmandu, Nepal, 1997. Springer Verlag. [109] Lutz Richter. Betriebssysteme. Teubner-Verlag, Stuttgart, 1985. [110] Sebastian Rieger. Streaming-Media und Multicasting in drahtlosen Netzwerken. Technical Report Nr. 61, Gesellschaft f¨ ur wissenschaftliche Datenverarbeitung mbH G¨ ottingen, 2003. [111] Vahid Salmani, Sama T. Zargar, and Mahmoud Naghibzadeh. A modified maximum urgency first scheduling algorithm for real-time tasks. Transactions on Engineering, Computing and Technology, ISSN 1305-5313, pages 19–23, November 2005. [112] Ricardo Sanz and Karl-Erik ˚ Arz`en. Trends in software and control. IEEE Control Systems Magazine, 23(3):12–15, June 2003. [113] Stefan Savage and Hideyuki Tokuda. Real-time Mach timers: Exporting time to the user. In USENIX-MACH III Symposium, pages 111–118, Santa Fe, New Mexico, April 1993. [114] U. Schmid. Orthogonal accuracy clock synchronization. Projektbericht Nr. 183/1-77, Technische Universit¨ at Wien, Institut f¨ ur Automation, March 1997.

Literaturverzeichnis

313

[115] Bran Selic, Garth Gullekson, and Paul T. Ward. Real-Time Object-Oriented Modelling. John Wiley & Sons, 1994. [116] Kenneth C. Sevcik and Marjory J. Johnson. Cyclic time properties of the FDDI token ring protocol. IEEE Transactions on Software Engineering, 13(3):376–385, March 1987. [117] Lui Sha, Ragunathan Rajkumar, and John P. Lehoczky. Priority inheritance protocols: An approach to real-time synchronisation. IEEE Transactions on Computers, 39(9):1175–1185, September 1990. [118] Alan C. Shaw. Real-Time Systems and Software. John Wiley and Sons, New York, 2001. [119] Chia Shen, Krithi Ramamritham, and John A. Stankovic. Resource reclaiming in multiprocessor real-time systems. IEEE Transactions on Parallel and Distributed Systems, 4(4):382–397, April 1993. [120] William Stallings. Operating Systems - Internals and Design Principles. Addison-Wesley, Reading, Mass., 2001. [121] John A. Stankovic. Misconceptions about real-time computing: A serious problem for next generation systems. IEEE Transactions on Computers, 21(10):10–19, 1988. [122] John A. Stankovic. On the reflective nature of the Spring kernel. In G. Hommel, editor, Prozeßrechnersysteme ’91, Informatik Fachberichte 269, pages 2–18, Berlin, February 1991. GI, Springer-Verlag. [123] John A. Stankovic. Real-time computing. BYTE, pages 155–160, August 1992. [124] John A. Stankovic, Tarek. F. Abdelzaher, Chenyang Lu, Lui Sha, and Jennifer C. Hou. Real-time communication and coordination in embedded sensor networks. Proceedings of the IEEE, 91(7):1002–1022, July 2003. [125] Friedhelm Stappert and Peter Altenbernd. Complete worst-case execution time analysis of straight-line hard real-time programs. Journal of Systems Architecture, 46(4):339–355, January 2000. [126] Hartwig Steusloff. Verteilte Echtzeitsysteme und Eingebettete Systeme. In Birgit Vogel-Heuser, editor, Verteilte Echtzeitsysteme, Informatik aktuell, pages 1–12, Berlin, November 2003. Echtzeitprogrammierung und PEARL, Springer-Verlag. [127] D. B. Stewart and P. K. Khosla. Mechanisms for detecting and handling timing errors. Communications of the ACM, 40(1):87–93, 1997. [128] David B. Stewart. Measuring execution time and real-time performance. In Embedded Systems, pages 1–15, Embedded Systems Conference, Boston, September 2006.

314

Literaturverzeichnis

[129] Harold S. Stone. High-Performance Computer Architecture. Addison-Wesley, 1987. [130] S. Tucker Taft, Robert A. Duff, Randall L., Erhard Ploedereder, and Pascal Leroy. Ada 2005 Reference Manual. Language and Standard Libraries. Number 4348 in LNCS. Springer-Verlag, New York, 2005. [131] A. S. Tanenbaum. Computer Networks. Prentice-Hall International Editions, Englewood Cliffs, NJ, second edition, 1988. [132] Richard N. Taylor. Complexity of analyzing the synchronization structure of concurrent programs. Acta Informatica, 19:57–84, 1983. [133] Ken Tindell and Alan Burns. Guaranteed message latencies for distributed safety-critical hard real-time control networks. Technical report, Department of Computer Science, University of York, May 1994. [134] Martin T¨ orngren. Fundamentals of implementing real-time control applications in distributed computer systems. Real-Time Systems, 14:219–250, 1998. [135] George Varghese and Anthony Lauck. Hashed and hierarchical timing wheels. IEEE/ACM Transactions on Networking, 5(6):824–834, December 1997. [136] Steve Vestal. Fixed priority sensitivity analysis for linear compute time models. IEEE Transactions on Software Engineering, 20(4):308–317, April 1994. [137] Birgit Vogel-Heuser. Systems Software Engineering. Oldenbourg Verlag, M¨ unchen, 2003. [138] Paul T. Ward and Stephen J. Mellor. Structured Development for Real-Time Systems, volume 1-3. Yourdon Press, New York, 1985. [139] P. E. Wellstead, V. Chrimes, P. R. Fletcher, R. Moody, and A.J. Robin. The ball and beam control experiment. International Journal of Electrical Engineering Education, 15:1978, 1978. [140] Dieter Werner. Theorie der Betriebssysteme: Eine Einf¨ uhrung in die Koordinierung paralleler Prozesse. Hanser Verlag, M¨ unchen, Wien, 1992. [141] Reinhard Wilhelm and alii. The worst case execution time problem overview of methods and survey of tools. ACM Transactions on Programming Languages and Systems, (to appear):1–47, 2007. [142] Heinz W¨ orn and Uwe Brinkschulte. Echtzeitsysteme. Springer-Verlag, Berlin, 2005. [143] Sijing Zhang, Alan Burns, Jing Chen, and E. Stuart Lee. Hard real-time communication with the timed token protocol: Current state and challanging problems. Real-Time Systems, 21:271–295, 2004.

Literaturverzeichnis

315

[144] Dieter Z¨ obel. A versatile real-time experiment: Balancing a ball on a flat board. In Janusz Zalewski, editor, Third IEEE Real-Time Systems Education Workshop (RTEW’98), pages 98–105, Poznan, Poland, November 1998. [145] Dieter Z¨ obel. Canonical approach to derive and enforce real-time conditions. In 1st International ECRTS Workshop on Real-Time and Control (RTC 2005), Palma de Mallorca, July 2005. Euromicro. [146] Dieter Z¨ obel and Horst Hogenkamp. Konzepte der parallelen Programmierung. Teubner-Verlag, Stuttgart, 1988. [147] Dieter Z¨ obel and David Polock. Priority inheritance revisited. Technique et Science Informatiques (TSI), 24(8):939–961, December 2006. [148] Dieter Z¨ obel, David Polock, and Andreas van Arkel. Testing the conformance of real-time protocols implemented by operating systems. Electronic Notes in Theoretical Computer Science (Elsevier), 133:315–332, May 2005. [149] Dieter Z¨ obel and Christian Weyand. Augmenting sensivity analysis for embedded applications by program level derivation of process parameters. In IEEE Second International Symposium on Industrial Embedded Systems (SIES’07), pages 17–24, Lisboa, Portugal, July 2007.

Sachwortverzeichnis Abbild des technischen Systems, 105 Abschlusszeit, 47, 57 absolute temporale Konsistenz, 108 Abstandsregelung, 21, 35 Abweichung absolute, 73 relative, 72 wertm¨ aßige, 106 zeitm¨ aßige, 108 ACC active cruise control, 21 accuracy, 73 Aktivierung, 46 Aktorik, 7 Aktorrelation, 106 aktuelle Priorit¨ at, 219, 220 Algorithmus verteilter, 141 Alterung, 108 der Uhrzeit, 76 Alterung der Uhrzeit, 80 Anfrageprinzip, 55, 141, 205 Anomalie im Zeitverhalten, 103 Antiblockiersystem, 35 Antwortzeit, 47, 96, 133, 192 maximale, 196, 198 Antwortzeit eines Rahmens, 250 Anwendungsfalldiagramm, 10 Anwendungsschicht, 139 at-most-once-Eigenschaft, 120 atomar, 120 Atomuhr, 69 Aufenthaltszeit einer Marke, 262 Ausf¨ uhrungszeit, 46, 93, 206, 210, 218 Bedarf an, 192 dichte, 103 l¨ angste, 93 sichere, 103 Auslastung, 49, 133, 206, 259 Automatisierungstechnik, 16

ball on a beam, 17, 29 Basisblock, 97 Basispriorit¨ at, 219, 220 BCET best case execution time, 95 BCET-Analyse, 95 Bereitzeit, 46, 54, 57 Besch¨ aftigungsphase, 257 Betriebsbedingung, 28 Betriebsmittel, 43, 141 Betriebssystem, 80 Bezugssystem, 63 Bezugszeitspanne, 24, 66, 80, 237 bib:Leun80, 284 bin-packing-problem, 131 Bitstrom, 138 Blockadezeit, 217, 218, 231, 257 blockiert, 126, 257 brauchbar, 51, 217 Brauchbarkeit, 51, 104, 205, 206, 256, 260 broadcast, 141 Bus, 133 Bus-Controller, 133, 140 busy period, 257 CA control action, 10, 105 Cache-Speicher, 129 car2car-Netzwerk, 35 CAS compare-and-swap, 122 CFG control flow graph, 96 Chip-Multiprozessoren, 117 client-server-principle, 139 clock perfect, 69 CNI communication network interface, 148 critical section, 122

318

Sachwortverzeichnis

CSMA/CA carrier sense multiple access / collision avoidance, 143 cycle, 147 cyclic executive, 200 cyclic scheduling, 200 Darstellungsschicht, 139 Datenexpansion, 10, 31 Datenflussdiagramm, 14 Datenreduktion, 10, 31 Deadlock, 126, 227, 232 Determiniertheit, 6, 17, 28, 55, 58, 147, 150, 263 Diagnose, 11 Diskretisierung, 24, 71, 76 dispatching, 208 DM-Test deadline monotonic test, 198 DMS deadline monotonic scheduling, 195 Drift, 24, 25, 71, 76 Driftrate, 72 echt, 18 Echtzeit, 18, 26, 86 Echtzeitbedingung harte, 47 Echtzeitbetrieb, 3 echtzeitf¨ ahig, 135 Echtzeitf¨ ahigkeit, 7 Echtzeitplanung, 43, 46 bei dynamischen Priorit¨ aten, 54, 164 bei statischen Priorit¨ aten, 54 dynamische, 52 implizite, 178 statische, 52 Echtzeitsystem, 3 verteiltes, 133 ECU electronic control unit, 34, 134 EDF earliest deadline first, 164 eingebettetes System, 12, 20 Einplanbarkeitstest, 52

Einprozessorsystem, 43, 117 Ende-zu-Ende Antwortzeit, 136 Ende-zu-Ende-Antwortzeit, 32, 133, 152, 250 Energie-Zeit-Unsch¨ arfe, 69 EPDF earliest pseudo deadline first, 244 Ereignis, 56 ereignisgesteuert, 56, 151, 153 Fahrassistenzsystem, 21 Fahrerassistenzsystem, 21 feasibility, 51 feld, 133 Feldbus, 133, 140 field, 133 fieldbus, 133 fixed priority scheduling, 178 Flattern, 37, 49, 95, 104, 133, 195, 204, 253, 255 Fluss integraler, 241 maximaler, 240 Fluss:reeller, 242 frame, 138, 140 Frist, 46 relative, 195 Fristverletzung, 28, 50, 200, 210 Galilei-Transformation, 63 gegenseitiger Ausschluss, 122 Gleichlauf von Uhren, 73, 147 GPS global positioning system, 67 Granularit¨ at, 70, 88 gr¨ obere, 88 Granularitat, 24 Graphentheorie, 240 Grenzrisiko, 6 Grundmodell eines Echtzeitsystems, 7, 23, 29, 30, 105 Grundmodul, 144 Halteproblem, 94, 96, 127

Sachwortverzeichnis

Haufen, 84, 208 Hauptpeicher gemeinsamer, 118 HB-Test, 190 heap, 84 Heisenbergsche Unsch¨ arferelation, 68 helping, 219 HMI human machine interface, 21 Homogenit¨ at der Zeit, 63 Inertialsystem, 63 interrupt, 78, 124, 208 Intervall, 86 Invariante, 112 IPET implicit path enumeration technique, 103 ISO/OSI-Referenzmodell, 137 Isotropie des Raumes, 63 ISR interrupt service routine, 56 Istwert, 16 jitter, 37, 49 Kalenderzeit, 78 Knoten, 133 Kommunikation offene, 137 Kommunikationsprotokoll, 138, 141 Konfigurierung, 11 Konkurrenz, 13, 21, 43 Konsistenz absolute temporale, 108 der Daten, 119 Kontrollflussgraph, 96 Kooperation, 13 Koordination, 13 koordinierte Weltzeit, 74 Korrektheit, 6 kritischer Zeitpunkt, 178 kritisches Gebiet, 122, 125, 215 kanonisch verschachteltes, 218 kritisches Intervall, 178

319

Kunde-Bediener-Prinzip, 139 Laufzeitsystem, 80 laxity, 172 leap second, 75 Livelock, 123 LKS lane keeping support, 21 LL-Test, 187, 190 LLC logical link control, 140 LLD-Test, 195 LLF least laxity first, 172 lock-free synchronization, 123 Lorentz-Transformation, 65, 66 LRU least recently used, 99 MAC medium access sublayer, 140 MAC-Zwischenschicht, 140 major cycle, 200 Marke, 145, 262 Master, 141 Master/Slave-Protokoll, 141 Mehrprogrammbetrieb, 117 Mehrprozessorsysteme, 117 Mensch-Maschine-Schnittstelle, 21 message, 118 Messsystem, 7 Migration von Prozessen, 130 MIMD multiple instruction, multiple data, 128 minor cycle, 200 MLLF modified least laxity first, 176 Monitor, 125 Multicore-Prozessor, 117 multiprogramming, 117 multitasking, 117 mutual exclusion, 122 Nachladen, 99

320

Sachwortverzeichnis

Nachricht, 118, 133, 139, 140, 151 Nachrichten¨ ubertragung asynchrone, 118 synchrone, 118 NP-vollst¨ andig, 127, 131, 204 NP-vollstandig, 162 O-Notation, 39 optimal, 54 Optimierung lineare, 103 Oszillator, 69 out of order execution, 100 P-fair, 237 P-Fairness, 237 Paket, 139 paradigmatisches Beispiel, 7, 28 Parallelausf¨ uhrung nebenl¨ aufige, 117 paralleles Programm, 117, 127, 215 Partitionierung, 130 PCP priority ceiling protocol, 227 Periode, 48, 93, 206 perishable, 108 PF-Verfahren, 245 physikalische Schicht, 138 PIP mit verz¨ ogerter Zuteilung, 223 priority inheritance protocol, 219 Pipeline, 98 Pipelining, 99 Plan, 50, 52 brauchbarer, 51 expliziter, 52, 58, 147, 148, 200 f¨ ur ein Mehrprozessorsystem, 237 impliziter, 52, 58, 178 Plancksches Wirkungsquantum, 68 Planen bei dynamischen Priorit¨ aten, 54, 164 bei statischen Priorit¨ aten, 54 durch Suchen, 157 nach festen Priorit¨ aten, 178, 208 nach Fristen, 164, 180, 208

nach monotonen Fristen, 195 nach monotonen Raten, 181, 195, 208 nach Raten, 180 nach Spielr¨ aumen, 172 nach Spielr¨ aumen, modifiziertes, 176 Planerstellung, 52 Planung holistische, 151, 251, 256 Planungsverfahren optimales, 54, 172 proportional faires, 237 zyklisches, 200 Planungszyklus, 178 Polling-Prinzip, 55, 141, 205 Posix, 91, 118 portable operating system interface, 80 Pr¨ azision einer Uhr, 73 precision, 73 precomputation, 18 Priorit¨ at, 180 aktuelle, 219 dynamische, 58, 164, 244 statische, 58, 178 Priorit¨ atsobergrenze, 227 Priorit¨ atsumkehr, 218 Priorit¨ atsvererbung, 219 priority inversion, 218 proportional faires Planungsverfahren, 237 Proramm paralleles, 117 Protokoll, 138 Protokoll der Priorit¨ atsobergrenzen, 227 Protokoll der Priorit¨ atsvererbung, 219 Prozess, 14, 151 aperiodischer, 44, 58 leichtgewichtiger, 45, 118 nicht unterbrechbarer, 44, 57, 117, 206 periodischer, 44, 56, 58

Sachwortverzeichnis

rechenbereiter, 47, 166 schwergewichtiger, 45, 118 sequenzieller, 117 sporadischer, 44, 56, 58, 209, 251 technischer, 16, 30, 117 unterbrechbarer, 44, 57, 117, 124, 206 Prozessausf¨ uhrung, 45, 58, 117, 130, 148 endliche, 43, 57 ereignisgesteuerte, 56, 58, 209 Pr¨ azedenzen in der, 126 priorit¨ atsbasierte, 44, 52, 54, 56, 57, 59, 83, 110, 164, 180, 196, 215, 219 pseudo-parallele, 117 zeitgesteuerte, 55, 58, 251 Zustand der, 124 zyklische, 200, 251 Prozessobjekt, 45, 57, 178 Prozessorzuteilung, 53, 208, 209, 222 Prozesstyp, 45, 54 Prozessumschaltung, 44, 53, 117, 209 priorit¨ atsbasierte, 44 Prozessumschaltungen, 80, 204 Pseudoprozess, 238 Rahmen, 138, 140, 151, 204 asynchroner, 146 synchroner, 146, 263 Rahmenpackungsproblem, 153 Randmenge, 188 Reaktionszeit, 47 Rechenprozess, 14, 30, 117 Rechensystem, 7, 56, 151 rechnend, 126 Rechnernetz, 31, 136 Rechtzeitigkeit, 5, 13, 18, 31–33, 44, 199 Reduktion, 162 Referenzuhr, 74, 79 Regelkreis, 16 Regelungssystem, 16 Regelungstechnik, 16, 104 Regler, 16 resolution of time, 70

321

Ring, 133 RM-Test, 217 erweiterter, 217, 227 rate monotonic test, 198 RMS rate monotonic scheduling, 180 Rotationszeit, 263 Rotationszielzeit, 264, 271 round, 147 RT-Test response time test, 197, 198 Runde, 147, 148, 253 Rundruf, 141 SBA synchronous bandwidth allocation, 271 Schadensvermeidung, 28 Schaltsekunde, 75, 79 Schaltzeit, 74 schedule, 50, 52 scheduling dynamic priority, 54 real-time, 43 static priority, 54 Schlitz, 147, 148, 238, 253 Semaphor, 124 Sensitivit¨ atsanalyse, 104, 207 sensitivity analysis, 104 Sensorik, 7 Sensorrelation, 105 Sicherheit, 6, 18, 28, 29, 148 Signallaufzeit, 252 Sitzungsschicht, 139 Slave, 141 slot, 147, 238 Sollwert, 16 Speicherhierarchie, 98 spezielle Relativit¨ atstheorie, 63 Spielraum, 172 Spurerkennung, 21 Spurverfolgung, 21 Stabilit¨ at einer Uhr, 73 Startzeit, 47

322

Sachwortverzeichnis

Stellglied, 16 Stellsystem, 7 Stern, 133 Steuerfunktion, 10, 105 Steuerger¨ at, 34, 134 Strecke, 16 Subbus, 142 Synchronisierung blockierende, 125 sperrenfreie, 123 synchronization lock-free, 123, 219 System eingebettetes, 12, 20 externes, 3 internes, 3 technisches, 7, 56, 117 Systemaufruf, 118 TAS test-and-set, 121 TDMA time division multiple access, 147 Telefonieren u ¨ber Internet, 36 Telematik, 35 temporale Ordnung, 86 thread, 45, 118 THT token holding time, 262 Tick, 69 Tiefensuche, 158 time overrun, 200 time-driven, 55 time-triggered, 55 timing wheel, 84 token, 145 token bus, 146 token ring, 146 Transportschicht, 139 TRT token rotation time, 263 TSR traffic sign recognition, 20 TTA time triggered architecture, 148

¨ Uberlappung, 240 ¨ Ubertragungsleistung, 133 Uhr, 22, 86 perfekte, 69, 74 reale, 69 Uhrbaustein, 22, 77, 147 Uhrsynchronisierung, 147 Uhrzeit, 23–25, 78 Ungenauigkeit, 24 Unterbrechungsanforderung, 78, 80, 124, 205, 208 Unterbrechungsbehandlung, 56, 208 use case diagram, 10 UTC universal time coordinated, 74 Verbindungsschicht, 138 verdr¨ angt, 126, 257 Verdr¨ angung eines Prozesses, 44 Verhersagbarkeit, 271 Verkehrszeichenerkennung, 20 Verklemmung, 126 Vermittlungsschicht, 139 verteiltes System, 34 Verz¨ ogerungsfunktion absolute, 81 relative, 81 VoIP voice over IP, 36 Vorberechnung, 18 Vorhersagbarkeit, 6, 17, 18, 28, 44, 56, 57, 59, 123, 132, 135, 151, 209, 250 Vorhersehbarkeit, 6 wait-free synchronization, 219 Wartezeit auf den Bus-Controlller, 252 WCET worst case execution time, 93 WCET-Analyse, 95 Weckzeit, 82 Wippe, 29 Wirkverz¨ ogerung, 112, 114 Wirkzusammenhang, 14, 30 X-by-wire Technologien, 148

Sachwortverzeichnis

Zeit, 21, 24 Zeitau߬ osung, 70, 80 Zeitbedingung harte, 4, 28, 127 weiche, 4, 28 Zeitereignisse, 23 Zeitgenauigkeit, 79 einer Uhr, 73 zeitgesteuert, 55, 148, 153, 200 im engeren Sinn, 55, 150 im weiteren Sinn, 56 Zeitintervall, 39, 86 Zeitpunkt, 5, 39, 46, 51, 85 kritischer, 196, 209, 256

323

Zeitrad, 84, 208 Zeitspanne, 39, 46, 51, 86 Zeitwert, 76 Zugriffsprotokoll, 136, 140 Zustand der Prozessausf¨ uhrung, 124 beendet, 57 blockiert, 57 rechenbereit, 57 rechnend, 57 verdr¨ angt, 57 Zuverl¨ assigkeit, 6, 18, 148 Zyklus, 147, 148, 178, 253 außerer, 200 ¨ innerer, 200