Echtzeit-Systemdesign mit Hilfe der AUTOSAR-Methodik
Echtzeitfähigkeit ist alles
Fortsetzung des Artikels von Teil 2
Tasks und Runnables
Jobangebote+ passend zum Thema
Angenommen, ein System habe sechs Runnables, jeweils mit einer WCET von 100 ms (Bild 6). Runnable 1 und Runnable 2 befinden sich in Task A, während Runnable 3 und 4 zu Task B gehören und Runnable 5 und 6 zu Task C. Damit haben alle drei Tasks eine WCET von jeweils 200 ms.
Ferner sei angenommen, der freie Slot einer ECU habe nur eine Dauer von 500 ms. Ein Algorithmus kommt also problemlos zu dem Schluss, dass es für diese Situation keinen gültigen Schedule gibt. Dieser Feststellung liegt die Annahme zugrunde, dass die WCET einer Task gleich der Summe der WCETs aller in ihr enthalten Runnables ist. Modelliert werden hier ausschließlich die Runnables und ihre WCETs sowie die Beziehungen zwischen Runnable und Task.
Ein kluger Systemarchitekt jedoch kann zu dem Schluss kommen, dass ein funktionsfähiges Scheduling möglich ist, denn er besitzt Wissen über die Funktionen und weiß beispielsweise, dass die Runnables 1 und 3 zur Funktion „Parkdistanzkontrolle“ gehören, die nur bei Geschwindigkeiten unter 10 km/h aktiv ist, während die Runnables 2 und 4 Bestandteil einer hypothetischen Funktion sind, die erst bei einem Tempo von mehr als 100 km/h aktiviert wird. Ist eine der Funktionen inaktiv, geht die WCET der betreffenden Runnable Entity jedoch von 100 ms auf beispielsweise 2 ms zurück. Gestützt auf seine Kenntnisse kann der Systemarchitekt die WCET der Tasks präziser, d.h. weniger pessimistisch, berechnen. Für Task A errechnet sich eine WCET, die nicht mehr 200 ms, sondern nurmehr 102 ms beträgt. Gleiches gilt für Task B. Da es keine Zusatzinformationen über die Runnables 5 und 6 gibt, muss die WCET von Task C nach wie vor mit 200 ms angesetzt werden.
Mit Hilfe des Wissens über die Funktionen reduziert sich die Summe der WCETs aller Tasks von 600 ms auf 404 ms, was eine Verteilung auf den 500 ms langen Zeitschlitz möglich macht.
Dieses Beispiel veranschaulicht, wie präzisere Informationen den Pessimismus reduzieren. Damit dieses Zusatzwissen einem Algorithmus zugänglich gemacht werden kann, ist das Metamodell so zu erweitern, dass es Abhängigkeiten zwischen Runnables (z.B. gegenseitigen Ausschluss) erfassen kann. Ebenso können bestimmte Fahrzeugzustände definiert werden, mit denen die Funktionen in einander ausschließende Gruppen unterteilt werden können. Der Algorithmus kann in diesem Fall das gleiche Wissen nutzen, über das auch der Systemarchitekt verfügt.
- Das Finden eines Kompromisses
Unsere Vorgehensweise besteht darin, das System und seine Anforderungen auf einer eher abstrakten Ebene zu modellieren und dies als Basis für eine bedarfsweise Verfeinerung des Modells zu verwenden.
Beginnt man auf einer hohen Abstraktionsebene, so ist die Wahrscheinlichkeit relativ groß, dass die benötigten Informationen verfügbar sind und das Modell nicht übermäßig kompliziert wird. Nachteil dieses Ansatzes: je höher der Abstraktionsgrad, umso pessimistischer wird die Berechnung ausfallen. Dennoch heißt dies nicht unbedingt, dass der Algorithmus falsch ist. Ein guter Algorithmus kann mit besseren Eingangsdaten zu besseren Lösungen gelangen. Im vorangegangenen Beispiel würde der Algorithmus eine Lösung finden, wenn der Zeitschlitz nur breit genug wäre (über 600 ms). Ein Verfeinern des Metamodells durch eine intelligentere Berechnung der WCET würde dagegen sofort zu besseren Resultaten führen.
Es ist zu bezweifeln, ob all dieses implizite Wissen über ein System so formuliert werden kann, dass es sich in ein Modell aufnehmen lässt. Die Herausforderung besteht darin, das Modell einerseits mit so vielen Informationen zu versehen, dass es nützlich ist, und den Informationsumfang andererseits so gering zu halten, dass er sich noch erfassen und beherrschen lässt.
Eine Abschätzung dazu, ob der gewählte Abstraktionsgrad passt, lässt sich anstellen, indem man die berechneten Schedules mit jenen bereits implementierter ECUs vergleicht. Dabei geht man von der Prämisse aus, dass ein Algorithmus in der Lage sein sollte, eine Lösung zu finden, wenn auch der Mensch mit den ihm zur Verfügung stehenden Informationen zu einem Resultat kommt.
- Echtzeitfähigkeit ist alles
- Literatur:
- Tasks und Runnables
- Bewältigung der Herausforderungen
- Es bleiben Fragen offen
- Timing-Chains
- Der AUTOSAR-RTE-Generator
