Um dieses Verhaltensmodell zu bedienen, benötigt man das Modell eines Systems, das das geforderte Verhalten bedienen kann. Dazu wählen wir als Einstieg zwei Darstellungsweisen: (i) Grafische Darstellungen der Systemkomponenten und (ii) eine formale (mathematische) Darstellung der Struktur. Die Struktur wird dann weiter konkretisiert.
Die Grundelemente eines Realzeitsystems für diese Aufgabe kann man der grafischen Darstellung 2.6 entnehmen:
mit
![]() |
![]() |
![]() |
(2.3) |
![]() |
![]() |
![]() |
(2.4) |
Auf der Inputseite kann das System RTS registrieren, zu welchem Zeitpunkt
welche Ereignisse
aus der Umgebung auftreten. Zugleich verfügt es über eine Technische Tabelle
, anhand deren eine Zuordnung von Ereignissen zu Tasks
stattfinden kann. Hier wird angenommen, daß auch wetere wichtige Informationen sowohl zu den Ereignissen
-also Auftretenszeit
, Deadline
und Periode
- wie auch zu den einzelnen Tasks -hier vor allem die Gesamtausführungszeit ('computation time')
- festgehalten sind. Ferner gibt es eine Menge von Prioritätsregeln
, anhand deren sich die Prioritäten für aktuelle Tasks berechnen lassen. Aus der Menge der aktuellen Ereignisse
und der Menge der noch wartenden Tasks aus den vorausgehenden Zeitpunkten
wird die Menge
jeweils neu gebildet. Treten kritische Ressourcen
auf, so müssen diese zusätzlich verwaltet werden. Bezüglich der Ressourcen
kann man weitere Unterscheidungen treffen. Neben den kritischen Resssourcen gibt es eine interne Uhr
und mindestens einen Prozessor ('central processing unit')
. Es ist Aufgabe des Scheduling-Algorithmus
aus allen diesen Daten den Task
zu ermitteln, der aktuell ausgeführt werden soll, geschrieben
(mit
als die Menge der aktuell auszuführenden Tasks.
Scheduling Algorithmus: Die Grundstruktur eines Schedulingalgorithmus für Realzeitsysteme läßt sich durch folgendes einfaches Schema beschreiben:
Der Schedulingalgorithmus beginnt mit der Nullsetzung der Parameter
.
ist die aktuelle Zeit,
ist die Menge der aktuell auszuführenden Tasks und
ist die vereinigte Menge der neuen
und der noch nicht vollendeten Tasks. Die aktive Schleife des Algorithmus beginnt mit der Überprüfung, ob die zuletzt ausgeführten Tasks aus der Menge X schon vollständig abgearbeitet sind. Falls 'JA', dann werden sie aus der Menge Q entfernt: if(checkX(X) == FINISHED) then Q = Q - X. Anschließend wird die Menge X auf jeden Fall auf Null gesetzt, da für den neuen Zyklus alle Tasks -auch die noch in Verarbeitung befindlichen- bezüglich ihrer Prioritäten neu überprüft werden müssen. X =
. Danach werden alle Tasks ermittelt, die aufgrund neuer Ereignisse zu Q hinzukommen müssen:
. Nachdem die Menge
neu gebildet wurde, muss
mittels der gewünschten Prioritätsregeln
als Menge
neu nach Prioritäten geordnet werden. Nachdem geklärt wurde, in welcher Reihenfolge die Tasks ausgeführt werden müssen, kann man überprüfen, ob einer dieser Tasks
aus
seine relative Deadline
überschritten hat. Falls dies der Fall ist, also checkD(
) == true), dann stoppt der Algorithmus mit einer Fehlermeldung; das Scheduling hat dann versagt. Wurde keine Deadline gebrochen, dann wird das erste Element aus
ausgewählt und in die Menge
eingefügt
.
Man kann leicht erkennen, dass dieser Algorithmus entweder nach endlichen vielen Schritten terminiert, wenn eine Deadline nicht bedient werden konnte, oder aber er läuft beliebig lange weiter, indem immer genau der Task mit der höchsten Priorität bearbeitet und ausgeführt wird.
Implementierung: Es gibt vielfältige Möglichkeiten, dieses Modell eines RTS mit einem Scheduler wie zu implementieren (siehe Übungsaufgaben).
Validierung: Nachdem ein Modell implementiert wurde, soll es getestet werden. Dies geschieht hier mit den Daten des Verhaltensmodells. Dazu nehmen wir an, dass die Prioritätsregel anhand der Rate Monotonic (RM)-Regel definiert sein soll. Die RM-Regel lautet:
mit der zusätzlichen Annahme, dass , d.h. wenn die Periode
des i-ten Ereignisses
kleiner ist als die Periode
des j-ten Ereignisses
, dann ist die Priorität
des i-ten Ereignisses
grßßer als die Priorität
des j-ten Ereignisses
.
Eine Möglichkeit der Validierung besteht darin, das System anhand eines Zeitdiagramms zu überprüfen (vgl. Schaubild 2.7).
Gerd Doeben-Henisch 2013-01-16