Kfz-Systeme modellieren Modellbasierte Entwicklung am Beispiel eines Fensterhebers

Obwohl Algorithmen zur Steuerung der Bordelektronik allgemein als eher einfach angesehen werden, hat die Komplexität des elektrischen Gesamtsystems in Fahrzeugen rasant zugenommen.

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

ELMEKO GmbH + Co. KG

Obwohl Algorithmen zur Steuerung der Bordelektronik allgemein als eher einfach angesehen werden, hat die Komplexität des elektrischen Gesamtsystems in Fahrzeugen rasant zugenommen. Die Entwicklung von Regelungssystemen durch den Aufbau und das Testen von Prototypen wird den Anforderungen immer weniger gerecht. Eine vielversprechende Methode bietet das modellbasierte Design.Mit modellbasiertem Design kann ein komplettes System inklusive aller elektromechanischen Komponenten, der Steuerungsalgoritmen und des Kommunikationsnetzwerks modelliert werden. Auf diese Weise lässt sich das Design validieren sowie jede Einzelfunktion auf ihre Anforderungen hin überprüfen und mit Verifikationstests verknüpfen. Dies stellt sicher, dass ein Regelungssystem die gestellten Anforderungen wirklich erfüllt. Zudem ermöglicht modellbasiertes Design, die hardware mithilfe von HIL-Tests zu validieren.Das folgende Beispiel zeigt, wie das Modell einer elektrischen Fensterhebersteuerung verschiedenen Testfällen unter worfen wurde. Mit modellbasiertem Design behalten die Ingenieure dabei automatisch den Entwurf als Ganzes im Hinterkopf. Dies ist hilfreich, um Mehrdeutigkeiten und Widersprüche in den schriftlichen Spezifikationen aufzudecken und zu beheben.Konkret sehen die Anforderungen für die Tippschalter-Funktion zum Hoch-/Herunterfahren des Fensters folgendermaßen aus. Auto-Hoch/Runter-Anforderung: wird der Hoch- oder Runter-Befehl für mindestens 200 ms oder höchstens 1 s gegeben, schaltet der Regler in den automatischen Modus und das Fenster muss vollkommen geöffnet bzw. geschlossen werden.

Die Logik, die die Bewegung des Fensters beschreibt, wurde in Stateflow als endlicher Zustandsautomat formuliert (Bild 1). Der Move-Zustand umfasst zwei parallele Unterzustände, Direction und Mode, die voneinander unabhängig sind, aber trotzdem miteinander in Beziehung stehen. Direction legt fest, ob die Fenster herunter oder herauf fahren. Mode bestimmt, ob die Fenstersteuerung im manuellen oder im automatischen Modus arbeitet. Der Move-Zustand enthält zusätzlich die Funktion obstacles, die ständig ausgewertet wird und überprüft, ob das Fenster auf ein Hindernis trifft.

Ein genauerer Blick auf den Mode–Zustand zeigt, dass der Ausgangszustand, in den der Regler sich begibt, NotSureYet ist. Aus diesem Zustand wechselt er entweder in den Zustand Auto bzw. Manual oder er verlässt den Move-Zustand ganz und begibt sich in den Stop-Zustand. Sämtliche Übergänge werden durch Ereignisse und Bedingungen ausgelöst. Der rot hervorgehobene Übergang steht für die Anforderung der Hoch/Runter-Tippfunktion der Steuerung. Die Steuerung schaltet nur dann in den Auto-Zustand, wenn der Schalter zwischen 200 ms und 1 s nach dem Drücken wieder losgelassen wird und damit das Ereignis NEUTRAL auslöst.

Mit modellbasiertem Design können Anforderungen aus Microsoft Word oder Requirements Management Systemen wie Telelogic DOORs mit Objekten im Modell verknüpft werden. Die Verknüpfungen lassen sich außerdem mit Navigations-Links versehen, die auf einander verweisen. So kann man den Zusammenhang zwischen einer Anforderung und den dazugehörigen Teil des Systementwurfs einfach verfolgen. In unserem Beispiel wurde die in der Auto-Hoch/Runter beschriebene Anforderung für die Hoch/Runter-Tippfunktion mit dem Stateflow-Übergang NEUTRAL [after(_200ms,tick) & before(_1s,tick)] verbunden.

Testfälle im Modell erzeugen

Als nächstes werden Testfälle in das Modell eingebaut, die die Hoch/Runter-Tippfunktion verifizieren. Da für „Hoch“ wie für „Runter“ die gleiche Anforderung gilt und sowohl der Fahrer als auch der Beifahrer diese Funktion aktivieren kann, müssen vier Testfälle erzeugt werden. In Bild 2 wird der Testfall definiert, dass der Fahrer den „Hoch“-Schalter 400 ms lang gedrückt und dann losgelassen hat. Mit dem untersten Signal im Testfall, “do_verification”, können die Verifizierungsblöcke überprüfen, ob sich die Steuerung in den erwarteten Zuständen befindet (Bild 2 - im Fenster oben rechts).

Im aktuellen Testfall sollte der Regler sich im Auto- und Move_UP-Zustand befinden, nicht aber im Manual-, Move-, Down- oder Stop-Zustand. Die mit diesem Testfall verknüpfte Anforderung wird ebenfalls angezeigt (Bild 2 im Fenster unten rechts). Durch einen Doppelklick auf die Anforderung gelangt man direkt zu der Stelle im Anforderungsdokument, an der diese beschrieben wird. Für die drei weiteren Szenarien wurden vergleichbare Tests eingerichtet, die alle auf der Anforderung für die Hoch/Runter-Tippfunktion basieren.

Lässt man diese Tests am Modell durchlaufen, halten sie automatisch an, sobald die Signale der Steuerung von den erwarteten Ergebnissen abweichen. Es erscheint eine Nachricht, die den Anwender direkt zu dem Teil des Entwurfs führt, der sich nicht wie vorgesehen verhalten hat. Läuft der Test vollständig durch, bedeutet dies, dass der Entwurf sich wie erwartet verhält.

Diese Verfahrensweise wirft die Frage auf, ob der Entwurf tatsächlich vollständig getestet ist, wenn sämtliche Tests ohne Fehler durchlaufen wurden. Mit Werkzeugen zur Abdeckungsanalyse lässt sich dies überprüfen. In Bild 3 werden die Ergebnisse einer Abdeckungsanalyse direkt im getesteten Modell dargestellt. Mit Hilfe farbiger Hervorhebungen werden die vollständig abgedeckten logischen Pfade in grün angezeigt, während die nicht vollständig getesteten rot unterlegt sind.

Zusätzlich zur Entwicklung der Regelungsalgorithmen können die Modelle auch eingesetzt werden, um Trade-Off-Analysen auf der Systemebene durchzuführen, zum Beispiel mit Hilfe von Monte-Carlo-Methoden oder Optimierungsroutinen. Typische Ziele wären die Minimierung von Produktionskosten und Stromverbrauch sowie die Maximierung der Lebensdauer der Komponenten und die Einhaltung sämtlicher Entwurfsanforderungen.

Nach Fertigstellung des Systementwurfs kann man aus den Modellen C-Code für die Target-Hardware erzeugen. Die automatische Codegenerierung ist mittlerweile so ausgereift, dass sie in Punkto Effizienz nicht hinter manuell erzeugtem Code zurücksteht. In einem weiteren Schritt können die Ingenieure sämtliche Testfälle, mit denen sie das Systemmodell in der Simulationsumgebung getestet haben, auch für die auf der Target-Hardware laufende Embedded-Anwendung wiederverwenden und so die Implementierung verifizieren. Außerdem können die Tests so erweitert werden, dass sie nicht nur den gesamten Programmcode abdecken, sondern auch mit sämtlichen Kombinationen verschiedener Komponenten wiederholt werden können.

Der Übergang zur Hardware

Nach den simulationsgestützten Tests ohne reale Komponenten ist es wichtig, Hardware zu integrieren, an der überprüft werden kann, wie sich die Steuerung im Realbetrieb verhält. Die Hardwaretests können bereits durchgeführt werden, wenn noch nicht sämtliche Teile verfügbar sind. Die noch fehlenden Geräte werden emuliert. Bei den HIL-Tests lassen sich die bestehenden Testroutinen verwenden, um zu verifizieren, dass auch im Echtzeitbetrieb keine unentdeckten Entwicklungsfehler auftreten.

Die Hardwaretests konzentrieren sich darauf, die Umsetzung des Entwurfs auf der Zielhardware zu testen. Im Mittelpunkt stehen typischerweise Netzwerk-Timing und physisches Timing, Stromverbrauch, RAM- und ROM-Bedarf, die Auslastung des Hauptprozessors, Anforderungen an die Umgebung wie zum Beispiel Aufheizung und physische Belastbarkeit sowie der letzte Feinschliff der Algorithmen. Die Genauigkeit der Simulation ebenso wie die der HIL-Tests hängt empfindlich von der Detailtreue der im Verlauf des Modellbasierten Designs verwendeten Anlagenmodelle ab.

Aus diesem Grund werden die Anlagenmodelle im HIL-System sobald wie möglich sukzessive durch Prototypen der Komponenten oder die fertigen Serienkomponenten, wie etwa den Fenstermotor, den Hebemechanismus und das Fenster selber, ausgetauscht. Model-Based Design verzichtet also keinesfalls auf Prototypenhardware, die Menge der benötigten Hardware jedoch wird erheblich verringert,

Vorteile der modellbasierten Entwicklung

Beim konventionellen Entwurf von Regelungen werden Spezifikationen schriftlich festgehalten, und dann die Algorithmen in C oder C++ geschrieben. Software-Algorithmen können aber nicht ohne Hardware verifiziert werden. Um ein Netzwerk und die Wechselwirkungen zwischen seinen Modulen zu verifizieren, muss die gesamte Hardware inklusive aller Module und Anlagen vorliegen. Bei Änderungen in späten Entwicklungsstadien muss dazu in der Regel ein Teil oder sogar das gesamte Design mehrfach neu verifiziert werden.

Oft können die Ingenieure aus Zeitmangel nicht feststellen, ob die Anforderungen für sämtliche in der Fertigung möglichen Modulkombinationen wirklich erfüllt sind. Als Ergebnis dieser enormen Komplexität bleiben viele mögliche Kombinationen ungetestet, bis sie in die Produktion gehen. Überdies sind Modifikationen spät im Entwicklungsprozess in der Regel um Größenordnungen teurer, als wenn der gleiche Fehler früher erkannt worden wäre.

Modellbasiertes Design erlaubt es, diesen Problemen zu begegnen, da der Design-Prozess hierarchisch angegangen werden kann. Dabei wird das System zunächst auf einer sehr hohen Abstraktionsebene definiert, bevor Schritt für Schritt weitere Details in Form von Funktionsblöcken hinzugefügt werden. Das Modell einer in der Entwicklung befindlichen Komponente wird so zu einer ausführbaren Spezifikation, die Entwickler rasch modifizieren und evaluieren können, indem sie sie in einem umfassenderen Systemmodell simulieren.

Der Ingenieur kann dadurch in kurzer Zeit und ohne reale Hardware die Leistung eines breiten Spektrums unterschiedlicher Entwurfskonzepte bestimmen und viele verschiedene Ideen ausprobieren. Einige dieser Ideen sind unter Umständen so riskant, dass man sie im Rahmen einer konventionellen Arbeitsweise gar nicht erst in Betracht gezogen hätte. Sämtliche Tests lassen sich automatisieren und ohne zusätzlichen manuellen Aufwand jederzeit wiederholen, wenn der Systementwurf verändert wurde, oder um mögliche Modul-Kombinationen zu verifizieren. Mit diesem Ansatz können Entwickler einen Systementwurf weit über das mit konventionellen Methoden mögliche Maß hinaus optimieren.

The MathWorks, Tel. +49(0)89 9959010

*Dr. Jason Ghidella ist Senior Team Leader Technisches Marketing für Simulink- und Stateflow und Jon Friedman ist Automotive Industry Marketing Manager bei The MathWorks.

(ID:183100)