Sie befinden sich hier: Termine » Prüfungsfragen und Altklausuren » Hauptstudiumsprüfungen » Lehrstuhl 4 » EZS   (Übersicht)

EZS

Prüfer / Beisitzer:

  • Peter Ulbrich
  • Florian Schmaus

Note 1.0

Fragen

Einstiegsfrage: Welche Terminverbindlichkeiten gibt es?

Weiche, feste und harte Termine erklärt und wie die das System je damit umgeht.

Zur Ausnahmebehandlung bei harten Terminen - woher kommt denn diese Ausnahmebehandlung?

Betriebssystem signalisiert Terminüberschreitung und Ausnahmeroutine kommt aus der Anwendung.

Was will man als Echtzeitentwickler wissen?

In welchem Kontext ist meine Anwendung. Mit welchen anderen Komponenten interagiere ich. Welche Zeitbeschränkungen sind schon vorgegeben, etc. …

Welche Parameter braucht man?

Periode, Auslösezeit, Ausführungszeit, Termin.

Woher kriegt man die Parameter? V. A. Termine und Perioden

Aus Analysen, aus Hardwarebeschränkungen (wie schnell ist mein Regler), aus Interaktion mit der Umwelt, aus der Physik ('wie lange dauert es, bis mein Kopf bei einem Autounfall vorne aufschlägt?')

Wie kommt man an die Ausführungszeit/WCET?

Messen, mit Timern und Oszi ⇒ liefert aber nur Best/Worst Observed Execution Time. ⇒ Graph mit Ausführungszeit, gemessene Grenzen und Bounds

Was kann denn dazu führen, dass ich nicht an die WCET rankommen mit den Messungen? Es ist schwer die richtigen Parameter zu finden. Plus die Hardware spielt mit rein

Inwiefern spielt die Hardware mit rein?

Auswirkungen von Caches und Pipelining.

Und wie funktioniert dann so eine statische WCET-Analyse?

Kontrollflussgraph erstellen. Man kann aber nicht alle möglichen Pfade aufzeichnen, durchgehen. Daher Abbildung auf Flussproblem. Zeitanalysegraph ⇒ Flussrestriktionen zum ausschliessen von unmöglichen Pfaden und Schleifengrenzen etc. Dann habe ich meine Pfadanalyse und füge dann noch Pipelining- und Cache-Analyse hinzu.

Wie kann man ein Echtzeitsystem implementieren?

Es gibt zwei Möglichkeiten:

Zeitgesteuert - es wird offline ein Ablaufplan erstellt. Führt zu geringen Verwaltungskosten online, aber hohe Kosten, sollten Änderungen nötig sein. Zum Beispiel mitteln Rahmen implementierbar. Vorranggesteuert - es werden statische oder dynamische Prioritäten geben, anhand derer online eingeplant wird. Das geschieht mittels verschiedener Algorithmen. Für feste Prioritäten zum Beispiel RM (Periode=Deadline, je kleiner die Periode, desto höher die Priorität), für dynamische Prioritäten zum Beispiel EDF (je näher die Deadline, desto höher die Priorität)

Zu dem Rahmen: Was ist hier denn der große Vorteil?

Ich teile meine Hyperperiode in fixe Rahmen, in denen 'busy-loop'-Verhalten herrscht. Interrupts (Timer-Interrupts) sind nur an den Rahmengrenzen zugelassen. Dadurch sehr gut vorhersagbares und analysierbares System.

Wie kommt man auf die Rahmenlänge?

Die Rahmenlänge f muss kleiner als alle Perioden sein, damit nicht eine Aufgabe mehrmals pro Rahmen ausgelöst wird. f muss die Hyperperiode ganzzahlig teilen und zwischen Auslösung und Termin muss für jede Aufgabe mindestens ein Rahmen liegen.

Wie bekommt man da jetzt aperiodische Aufgaben rein?

Hintergrundbetrieb und Unterbrechbetrieb erklärt. Man kann auch noch mit Zustellern arbeiten, die als periodische Aufgabe eingeplant werden.

Welche Arten von Zustellern gibt es denn?

polling, deferrable und SPSL sporadic Server.

Wie würde das denn hier jeweils im Rahmen funktionieren?

(Es war schon ein Interrupt-Blitz mitten im Rahmen eingezeichnet.)

Der Polling Server verwirft immer am Anfang seiner Periode sein Budget, falls keine aperiodische Aufgabe in der Warteschlange ist.Daher würde hier die Aufgabe erst im Rahmen darauf ausgeführt werden.

Der Deferrable Server verwirft sein Budget nicht, daher kann die Aufgabe einfach sofort ausgeführt werden, wenn unser System hier eh untätig ist.

Was ist aber das Problem beim Deferrable Server?

Der Double-Hit, dass der Server ggf. zweimal direkt nacheinander ausgeführt wird.

Wie kann man das verhindern?

In der Implementierung weniger Budget geben, oder in der Analyse die doppelte Ausführungszeit einplanen.