Zu der vorausgehenden Aufgabenstellung muss man dann ein System konstruieren, das dieser Aufgabe gerecht wird. Startpunkt bildet die allgemeine Form eines (reaktiven) Input-Output Systems als 'IO-System' bezeichnet oder einfach 'S':
![]() |
![]() |
![]() |
(2.12) |
![]() |
![]() |
![]() |
(2.13) |
![]() |
![]() |
![]() |
(2.14) |
![]() |
![]() |
![]() |
(2.15) |
![]() |
![]() |
![]() |
(2.16) |
Eine offene Frage ist, ob es denkbar ist, dass Realzeitsysteme auch adaptive Systeme sein könnten mit der Verhaltensfunktion
. Aufgrund der Sicherheitsanforderungen ist dies zur Zeit nicht zu sehen2.1
Im Falle eines Realzeitsystems besteht der Input aus der Menge der aktuellen Ereignisse, also und der Output besteht aus den erwarteten Reaktionen, also
. Man würde also schreiben:
![]() |
![]() |
![]() |
(2.17) |
![]() |
![]() |
![]() |
(2.18) |
![]() |
![]() |
![]() |
(2.19) |
![]() |
![]() |
![]() |
(2.20) |
![]() |
![]() |
![]() |
(2.21) |
Es bleibt die Frage, wie die internen Zustände weiter zu bestimmen sind. Dies wird hier mit Hilfe von drei Teilfunktionen beschrieben.
Wir gehen davon aus, dass man die globale Verhaltensfunktion in mindestens drei Teilfunktionen zerlegen kann:
![]() |
![]() |
![]() |
(2.22) |
![]() |
![]() |
![]() |
(2.23) |
![]() |
![]() |
![]() |
(2.24) |
![]() |
![]() |
![]() |
(2.25) |
![]() |
![]() |
![]() |
(2.26) |
![]() |
![]() |
![]() |
(2.27) |
![]() |
![]() |
![]() |
(2.28) |
![]() |
![]() |
![]() |
(2.29) |
![]() |
![]() |
![]() |
(2.30) |
![]() |
![]() |
![]() |
(2.31) |
![]() |
![]() |
![]() |
(2.32) |
Die Inputfunktion nimmt aktuelle Ereignisse
, ordnet diese mit Hilfe der Tabelle
den entsprechenden Tasks aus der Taskmenge
zu und tut diese in die Menge der aktuell auszuführenden Tasks
. Dabei wird jedem neuen Task eine Zeitmarke
zugeordnet die markiert, ab wann dieser Task auf seine Abarbeitung wartet. Außerdem müssen die bislang noch nicht vollständig abgearbeiteten Tasks aus der 'alten' Menge
weiter in
behalten werden. Dabei kann überprüft werden, ob (i) ein Task 'zu Ende' ist bzw. (ii) ob bei einem Task die Deadline überschritten wurde. Bei einem unabgeschlossenen Task wäre das Kriterium für Deadline-Überschreitung aktueller Zeitpunkt t muss kleiner sein als Auftretenszeitpunkt
,
.Für diese Berechnung muss angenommen werden, dass die Angaben
aus der Aufgabenstellung in die Beschreibung eines jeden Tasks
übernommen wurde. Ferner sollte die Taskbeschreibung einen 'Pointer' enthalten, an welcher Stelle des Tasks die Abarbeitung durch die CPU möglicherweise unterbrochen wurde, also
mit
als der Angabe des 'Breakpoints' (z.B.
).
Die Schedulingfunktion muss die Menge der aktiven Tasks
mit Hilfe der Prioritätsregeln
und unter Berücksichtigung der Benutzung möglicher kritischer Ressourcen
entlang der daraus resultierenden Prioritäten ordnen. Dazu muss u.U. auch auf die aktuelle Systemzeit zurückgegriffen werden, z.B. wenn mit der absoluten Deadline
gerechnet werden muss.
Schließlich übernimmt die Ausführungsfunktion die geordnete Menge
, holt sich den Task mit der höchsten Priorität und führt diesen Task unter Berücksichtigung der möglichen Nutzung von kritischen Ressourcen
aus. Die Berechnung beginnt bei dem aktuellen Breakpoint
. Es wird angenommen, dass ein Elementarkommando
genau eine Zeiteinheit der Systemzeit benötigt. Nach vollständiger Abarbeitung eines Tasks
sollte die erwartete Reaktion
nach außen 'erscheinen'.
Aus diesen ersten Überlegungen ergibt sich für die Struktur der Menge der Internen Zustände folgender Sachverhalt:
![]() |
![]() |
![]() |
(2.33) |
![]() |
![]() |
![]() |
(2.34) |
![]() |
![]() |
![]() |
(2.35) |