Modellbasierter Entwurf und Simulation einer Pkw-Schiebedachsteuerung

Transkript

1 1 Modellbasierter Entwurf und Simulation einer Pkw-Schiebedachsteuerung Michael Schulze Gronover, Markus Mühlbrandt, Burkhard Igel, Jörg Kahlert Ingenieurbüro Dr. Kahlert Ludwig-Erhard-Straße Hamm Fachhochschule Dortmund Sonnenstraße Dortmund

2 2 Zusammenfassung: Modellbasierte Entwürfe werden in der Automatisierungstechnik seit langem verwendet. Häufig sind diese jedoch noch ingenieurwissenschaftlich geprägt, während effektive Beschreibungen aus der Informatikwelt fehlen. Anhand einer einfachen Pkw-Schiebedachsteuerung wird gezeigt, dass eine mögliche Zusammenführung beider Welten lohnenswert ist. Die Steuerung wird mit Hilfe eines Zustandsautomaten beschrieben. Der Entwurf des Automaten wird mit Hilfe eines unter Eclipse selbst erstellten Editors durchgeführt. Anschließend wird der Zustandsautomat in die Simulationsoftware WinFACT/BORIS integriert. Hier kann durch eine Simulation die Funktionalität des Automaten geprüft werden. Abstract: Model-based designs are used for a long time in automation control. Often these are still characterized by engineering science, while effective descriptions used in informatics are omitted. On the basis of a sun roof control it is shown that a merge of both approaches is useful. The control system is described with a statemachine. The statemachine diagram is created with an editor implemented in Eclipse. Subsequently the statemachine is integrated into the simulation environment WinFACT/BORIS. A simulation accomplishes the necessary validation for the functionality.

3 3 1 Motivation Durch modellgetriebene Softwareentwicklung sollen komplexe Softwaresysteme beherrschbar werden. Auch bei der Softwareentwicklung für eingebettete Systeme hält dieses Vorgehen seit längerem Einzug. So gibt es verschiedene Werkzeuge zur Codeerzeugung, die unterschiedlich mächtig sind. Einer der bekanntesten und mächtigsten Vertreter ist das Paket bestehend aus MATLAB/Simulink/Stateflow/Realtime Workshop und TargetLink. Leider ist diese Kombination für kleinere Unternehmen nur selten erschwinglich, da die Anschaffungskosten durch notwendige Maßnahmen (Schulung, Support, etc.) noch erhöht werden. Wir hoffen hier einen Lösungsansatz zeigen zu können, der dank teilweiser Nutzung des Open Source Konzeptes preiswerter sein wird. Dieser Ansatz entsteht im Rahmen des Forschungsprojektes Modell Driven Architecture for embedded Systems [MDA4e]. Für den Entwurf der Mikrocontroller-Hardware und -Software sind in kleineren Unternehmen meistens dieselben Ingenieure verantwortlich. Sie arbeiten dabei mit Beschreibungen für dynamisches und statisches Systemverhalten. Auf diese Weise wird eine Berechnungsvorschrift für das zu lösende Problem erstellt und von Hand implementiert. Die Möglichkeiten der Unified Modelling Language (UML) werden dabei selten berücksichtigt. Dabei bieten gerade Zustandsdiagramme eine Beschreibungsform dynamischen Verhaltens an, die leicht verständlich und relativ schnell zugänglich ist. Durch eine anschließende Code-Generierung lässt sich ein nicht unwesentlicher Teil der Arbeit automatisieren Einsparungen von ca. 20% bis 50% sollen hier möglich sein [StC05]. In dem Fall des Pkw-Schiebedachs wollen wir zunächst die Steuerung desselben mit logischen Bausteinen realisieren. Anschließend wird die Steuerung mit Hilfe eines Zustandsdiagramms umgesetzt. Beide Lösungen werden simuliert, um diese verifizieren zu können. Als Werkzeuge wird das Modul BORIS aus den Windows Fuzzy And Control Tools (WinFACT) verwendet [BORIS]. Für das Zustandsdiagramm wurde ein Editor auf basierend auf dem Eclipse Graphical Modeling Framework [GMF] erstellt.

4 4 2 Pkw-Schiebedachsteuerung 2.1 Erläuterung des Schiebedachbeispiels Das Schiebedach eines Pkws ist vermutlich jedem hinreichend bekannt (Abbildung 1 zeigt die Visualisierung). Daher wird hier nur das Bedienkonzept erklärt. Durch zwei Taster ( <= und => ) kann das Schiebdach vollständig bedient werden. Im geschlossenen Zustand kann das Schiebedach durch Betätigung des Tasters <= in eine aufgeklappte Abbildung 1: Visualisierung des Schiebedachs Position gefahren werden. Durch Betätigung von => wird wieder die geschlossene Position angefahren. Ein weiteres Drücken desselben veranlasst das Öffnen des Schiebedachs. Während der Bewegung des Schiebedachs führt jede Tasterbetätigung zu einem sofortigen Stoppen. Die nachfolgende Tabelle erklärt die einzelnen Positionen. Position Stellung des Pkw-Schiebedachs 1000 (vollständig) aufgeklappt 800 geschlossen 0 (vollständig) offen

5 5 2.2 Aufbau der Steuerung durch logische Bausteine Die Lösung des Beispiels mit logischen Bausteinen wird in einer konventionellen Schaltung gezeigt. Hierbei ist ersichtlich (Abbildung 2), dass die Beschreibung der Steuerung durch herkömmliche Logikgatter nicht zur gewünschten Transparenz der Funktionalität führt. Dies liegt offensichtlich an der zeitlichen bzw. taktorientierten Arbeitsweise der Bausteine. Abbildung 2: Logiksteuerung des Schiebedachs Das Blockschaltbild kann als Signalfluss gelesen werden (s. [Kah06]). Dabei stellen die von links kommenden Signallinien die von den Tastern stammenden Signale dar. Diese schalten jeweils ein Flip-Flop. Zwischen den Linien befindet sich eine Logikschaltung, um dieselben wieder zurückzusetzen. Als Ausgang der Schaltung dient die Information, ob das Schiebedach bewegt werden soll und in welche Richtung es bewegt werden soll (Signallinie oben rechts). Trotz der übersichtlichen Anordnung innerhalb des Blockschaltbildes ist die Funktionsweise nicht offensichtlich. So ist beispielsweise die sprachliche Beschreibung für das Rücksetzen des oberen RS-Flip-Flops wie folgt: Wenn einer der beiden Taster betätigt wird oder sich das Schiebedach in geschlossener Position befindet und sich gerade noch bewegt hat oder das Schiebedach vollständig aufgeklappt ist dann soll das obere RS-Flip-Flop zurückgesetzt werden.

6 6 Abhilfe schafft der Ersatz der Schaltung durch ein entsprechendes Zustandsdiagramm (vgl. [Har87] und [OMG05]). 2.3 Aufbau mit Hilfe eines Zustandsdiagramms Das Zustandsdiagramm wird durch einen Editor innerhalb der Eclipse- Plattform aufgebaut. Der Editor wurde modellbasiert mit Hilfe des GMF- Frameworks entwickelt. Innerhalb des Editors werden die notwendigen grafischen Elemente auf dem Arbeitsblatt platziert und entsprechend parametrisiert. Abbildung 3: Statechart Editor als Eclipse-Plugin In einem Element Explorer definiert der Anwender Variablen und Ereignisse, die er innerhalb des Zustandsdiagramms verwendet. Ereignisse und Variablen können als Eingänge, Ausgänge oder auch nur als lokale Entität innerhalb des Zustandsdiagrammes deklariert werden. Sie besitzen einen Ganzzahlparameter Port, der später die Nummer der Ein-/Ausgangs darstellt. Zusätzlich wird der aktuelle Zustand der Kommunikation zum Simulationssystem BORIS angezeigt.

7 7 Die nachfolgende Grafik zeigt den fertigen Zustandsautomaten für die Steuerung des Pkw-Schiebedachs. Abbildung 4: Das fertige Zustandsdiagramm der Pkw- Schiebedachsteuerung Das Zustandsdiagramm verwendet die in der UML durch die OMG festgelegte Notation [OMG06]. Es gibt dem Anwender durch Unterteilung der Steuerung in einzelne Zustände die notwendige Übersicht über die funktionale Struktur zurück. Die Überprüfung der semantischen Richtigkeit des Diagramms und des dahinter liegenden Modells erfolgt zunächst durch eine Echtzeit-Fehlerüberprüfung direkt innerhalb des Editors (Live- Validierung) mittels openarchitctureware [OAW]. Durch eine anschließende Simulation kann das Modell auf logische Fehler verifiziert werden.

8 8 3 Simulation des Zustandsdiagramms 3.1 Einbindung des Zustandsdiagramms in BORIS Ein spezieller Block stellt innerhalb von WinFACT/BORIS den Zustandsautomaten dar. Als Parameter des Blockes wird das soeben modellierte Zustandsdiagramm angegeben. Anschließend konfiguriert sich der Block mit den entsprechenden Ein- und Ausgängen, die nun mit dem Rest des Systems verbunden werden können. Abbildung 5: Ein-/Ausgänge des Statechart-Blocks Das System aus Abbildung 2 reduziert sich auf den Statechart-Block wie in Abbildung 6 zu sehen ist. Abbildung 6: Der Statechart-Block in BORIS Durch eine Visualisierung, wie sie in Abbildung 1 zu sehen ist, wird das System anschaulich animiert.

9 9 3.2 Simulationsdurchführung Zur Simulation kommuniziert BORIS über eine TCP/IP-Schnittstelle mit dem Statechart-Editor und ermöglicht so die Verfolgung der jeweils aktiven Zustände. Abbildung 7: Statechart-Editor während der Simulation Die oben stehende Abbildung zeigt den Editor während der Simulation. Der gerade aktive Zustand wird farblich hervorgehoben. Die Transition, die den Zustandswechsel eingeleitet hat, wird dabei für eine einstellbare Zeit markiert. Dieses erleichtert dem Benutzer die Verfolgung des Ablaufs.

10 10 4 Fazit Zustandsdiagramme sind zur Beschreibung des Systemverhaltens gut geeignet. Sie geben dem Anwender die nötige Übersicht, dieser kann sich somit wesentlich auf die Lösung des eigentlichen Problems konzentrieren. Eine Simulation des Modells, geeignete Verifikationsmethoden und die Code-Generierung sind wesentliche Komponenten, die eine effizientere Arbeitsweise ermöglichen. 5 Ausblick Die Codegenerierung ist ein wesentlicher Bestandteil des Forschungsprojektes. Hier werden wir genauso wie bei den Verifikationsmethoden oaw einsetzen. Die Gültigkeit des Generats kann mit Hilfe eines Back-To- Back Tests erfolgen. Hierbei wird sichergestellt, dass die Funktionsweise von Modell und generiertem Code hinreichend genau übereinstimmen. Ein ebenfalls hilfreiches Mittel zur Unterstützung der Entwicklung von Zustandsautomaten ist ein gut ausgestatteter Debugger. Zu den wesentlichen Funktionen zählen wir: Haltepunkte Variablenüberwachung (Watchpoints) Einzelschrittausführung (step over- und step into)

11 11 Literatur [Har87] David Harel, Statecharts, A visual formalism for complex systems, Science of Computer Programming 8 Pg , 1987 [Kah06] Ingenieurbüro Dr. Kahlert, WinFACT-Benutzerhandbuch, 2006 [OMG05] OMG, Unified Modelling Language: Superstructure version 2.0, August 2005 [HIT05] Martin Hitz, Gerti Kappel, UML@Work, Dpunkt Verlag 2005 [StC05] Ingo Stürmer und Mirko Conrad, Ein Testverfahren für optimierende Codegeneratoren, Informatik - Forschung und Entwicklung, Volume 19, Number 4 / Juli 2005 Referenzen [MDA4e] [BORIS] [OAW] [GMF]