Systemdesign / Echtzeitbenchmarks Zeitanalyse komplexer eingebetteter Systeme

Jenseits von einfachen Mikrocontrollern gestaltet sich die Laufzeitanalyse von Programmen anspruchsvoll. Statische WCET-Analyse ist eine formale Methode zur Ermittlung einer Worst-Case-Laufzeit (WCET), welche im Gegensatz zu messbasierten Methoden korrekte Ergebnisse garantiert.

Einige der eingebetteten Systeme, welche uns im täglichen Leben begleiten, sei es im Auto, im Zug, im Flugzeug oder in Fertigungsanalagen, sind zeitkritisch, d.h. sie müssen auf eine Eingabe innerhalb festgelegter Fristen (Deadlines) reagieren. Diese Fristen sind von der Physik diktiert; der Controller eines Airbags sollte diesen im Falle eines Auffahrunfalls so zeitig zünden, dass der Fahrer in den aufgeblasenen Airbag und nicht auf den Lenker prallt. Beim frontalen Auffahrunfall hat der Controller dafür zwischen 10 und 40 Millisekunden Zeit. Einige kurbelwellensynchrone Tasks im Auto haben sogar Fristen im Mikrosekundenbereich. Die Flatterkontrolle an den Flügeln eines Flugzeugs muss aus den Sensordaten, welche die Auslenkung der Flügel zeigen, sehr schnell die Eingaben für die Stellmotoren zum Gegensteuern berechnen. Sonst könnten die Flügel in ihrer Resonanzfrequenz schwingen und abbrechen. Beim Airbus A380 stehen für diese Berechnung etwa 5 ms zur Verfügung.

Als Passagier eines Fahrzeuge sollte man sich sicher sein, dass diese Fristen eingehalten werden. Sofern die betroffene Industrie ihre Produkte zum Zertifizieren vorführen muss, schreiben internationale Standards wie DO-178 für die Flugzeugindustrie und ISO 26262 für Straßenfahrzeuge den Nachweis der Pünktlichkeit vor. „Best Practice“ in der Industrie war lange Zeit das Messen von Programmlaufzeiten; man maß so lange, bis man das Gefühl hatte, länger werden die Zeiten nicht mehr, und nahm an, dass dies im realen Betrieb auch so sei. Natürlich hatte man keine Garantie dafür. Es konnten sich im Betrieb längere Laufzeiten mit eventuell katastrophalen Konsequenzen ergeben.

Ausgangspunkt für messbasierte Methoden war die Analogie zum Testen der funktionalen Korrektheit. Für den Nachweis der Pünktlichkeit sind diese Methoden leider unbrauchbar. Zum Testen auf funktionale Korrektheit wurden Überdeckungskriterien entwickelt; jede Anweisung soll mindestens einmal ausgeführt werden, jede bedingte Verzweigung mindestens einmal in jede Richtung usw. Damit sollten mit großer Wahrscheinlichkeit Fehler beim Testen entdeckt werden.

Diese Überdeckungskriterien bedeuten für den Nachweis der Echtzeiteigenschaften leider gar nichts! Um eine obere Schranke für die Ausführungszeit zu berechnen, reicht es nicht, alle Anweisungen in einer Schleife einmal auszuführen. Man muss sie i.A. so oft ausführen, wie es in der Programmausführung im schlechtesten Fall möglich ist.

Messbasierte Methoden haben weitere Probleme. Man kennt i.A. nicht die Eingabedaten, welche den schlechtesten Fall, also die längste Ausführungszeit verursachen. Selbst unter Kenntnis dieser Daten wäre das Problem nicht gelöst; denn bei den heute in eingebetteten Systemen verwendeten leistungsorientierten Prozessoren hängt die Ausführungszeit, wie wir später sehen werden, vom initialen Ausführungszustand der Architektur ab. Mögliche initiale Ausführungszustände gibt es leider zu viele. Den schlechtesten initialen Zustand zu identifizieren ist in der Praxis unmöglich, zumindest hat dafür noch niemand eine Methode entwickelt.

Halten wir fest: Mit dem Messen von Ausführungszeiten lässt sich i.A. keine garantierte Ausführungszeit im schlechtesten Fall bestimmen!

Diese Schlussfolgerung könnte Entwickler von eingebetteten Systemen mit harten Echtzeitanforderungen in Verzweiflung stürzen. Dazu besteht kein Anlass; es gibt für die Praxis verwendbare Methoden und Werkzeuge, die sowohl korrekt, effizient als auch benutzbar sind.