Ein Fahrzeug

Im Folgenden wird noch ein Beispiel aus [BKKU99b] betrachtet. Es handelt sich um ein computergesteuertes Fahrzeug, das mit drei Echtzeittasks arbeitet, die in Tabelle 3.8 zusammen mit ihrer Deadline, ihrer Laufzeit und dem Anteil, den sie unter Guaranteed Percentage Scheduling bekommen, aufgeführt sind. Dazu kommt auch hier noch ein nicht echtzeitfähiger Thread, der die verbleibenden 5% der Rechenleistung nutzen kann. Dieser wird im Folgenden auch als System-Thread bezeichnet.

Tabelle 3.8: Die Threads des Fahrzeuges

Aufgabe	Deadline	Laufzeit	Anteil
Steuerung	10 ms	5 ms	50%
Kamera	10 ms	1 ms	10%
Transponder	15,4 ms	5,5 ms	35%

Die Deadline des Transponder-Thread hängt von der Geschwindigkeit ab, mit der das Fahrzeug an einem Transponder vorbeifährt. Um wie in [BKKU99b] die maximale Geschwindigkeit des Fahrzeugs zu bestimmen, wird nun die Deadline des Transponder-Thread schrittweise solange verringert, wie sie noch eingehalten werden kann. Aus der benötigten Zeit wird die Geschwindigkeit errechnet, mit der das Fahrzeug an dem Transponder vorbeifahren darf, der nur mit einem Abstand kleiner als ein Zentimeter ausgelesen werden kann:

$$maximale~Geschwindigkeit=\frac{0.01 m}{minimale~Laufzeit}$$

Die Ergebnisse sind in Abbildung 3.16 zu sehen.

Bei diesem Beispiel zeigt sich auch, daß man mit festen Prioritäten nicht die Leistung der anderen Verfahren erreicht.

Abbildung 3.16: Erreichbare Fahrgeschwindigkeiten

Die gute Leistung des Least Laxity First liegt in der guten Verteilung der Bytecode-Befehle verschiedener Threads über die Zeit begründet. So können die Latenzen optimal genutzt werden, um dem Transponder zusätzliche Rechenzeit zu geben.

Abbildung: Lastverteilung für das Fahrzeug

Abbildung 3.17 zeigt, warum Least Laxity First in diesem Fall besser abschneidet. Auch hier liegt der Grund in der deutlich besseren Durchmischung der Echtzeit-Threads gegenüber den anderen Verfahren, bei denen die Latenzzeiten nur von dem nicht echtzeitfähigen System-Thread genutzt werden können.