Software für Steuergeräte Co-Simulation: Anforderungen und Chancen

Die Simulation, Modellierung und die dazugehörige Visualisierung sind typischerweise eine geschlossene Einheit. Durch diese geschlossene Einheit ist die Anbindung weiterer Simulatoren oder auch von realer Hardware immer mit Kompromissen verbunden. Eine Co-Simulationsbackplane zur Anbindung diverser Simulatoren respective Modellierungssprachen versucht, diese Lücke zu schließen. Für den zielgerichteten Einsatz einer solchen sind entsprechende Anforderungen zu erfüllen, sodass die Co-Simulation den gesamten Entwicklungsprozess unterstützt und die unterschiedlichen Sprachen in einer integrierten Entwicklungsumgebung zusammenfasst.

Die modellbasierte Entwicklungsmethodik hat sich im Entwicklungsprozess von Software für Steuergeräte etabliert. Neben der grafischen »Programmierung« ergibt sich ein weiterer wesentlicher Vorteil der modellbasierten Entwicklung:

Auf dieselbe einfache Weise, wie der regelungstechnische Code geschrieben wird, lässt sich auch die Regelstrecke modellieren. Auf Basis der Regelstrecke und des Reglers kann damit eine geschlossene Simulation durchgeführt werden (siehe Bild 1), es ist also einfach möglich, den zu entwerfenden Regler frühzeitig gegen die Regelstrecke abzusichern.

Jede Aufgabenstellung bedingt, abhängig vom Entwicklungsschritt, ihre eigene Modellierungssprache. Nicht jede Sprache ist für alle Anwendungsfälle geeignet. Der sich ändernde Detaillierungsgrad mit Fortschreiten des Entwicklungsprozesses fordert ebenfalls einen Wechsel der Modellierungssprache für Regler und Regelstrecke.

In diesem Sinne bietet sich ein Co-Simulator als ideales Werkzeug zur Abdeckung aller Anforderungen als integrierte Entwicklungsumgebung an. Dies schafft die Möglichkeit, sonst nicht gekoppelte Welten miteinander zu verbinden.

Kopplungsvarianten

Im Rahmen der modellbasierten Entwicklung erfolgt die erste Modellierung des Problems häufig mit UML oder SysML. Innerhalb dieser Sprachen können über diverse Diagrammarten (Anwendungs-, Sequenzdiagramm) die Anforderungen an das System beschrieben, aber auch erste ausführbare Codes mithilfe von Zustands- und Klassendiagrammen modelliert werden.

Zum Testen dieser »Spezifikation« sind entsprechende Regelstrecken notwendig (siehe Bild 2). Zwar lässt sich das zu entwerfende System mit Hilfe gängiger UML/SysML-Tools spezifizieren, doch liegt die Schwäche dieser Tools in der fehlenden Kopplung mit anderen Modellierungssprachen.


Zur Darstellung des physikalischen Verhaltens der Regelstrecke beschreibt der Entwickler das physikalische Problem oftmals mathematisch und setzt es mit »Simulink« simulatorisch um. Einen eleganteren Lösungsansatz stellen Physik-Engines dar (Bild 3).

Anstatt der Beschreibung über Differentialgleichungen erfolgt hier die Modellierung über 3D-Primitiven. Physik-Engines sind optimiert für den Einsatz in Spielen.

Eine Kopplung zu anderen Programmen ist erst einmal nicht vorgesehen. Die Nutzung von Physik-Engines oder auch anderen nicht typischen Modellierungssprachen bedingt den Einsatz einer Simulator-Kopplung.

Vor dem Portieren der Software auf die Zielhardware erfolgt oftmals eine erste Erprobung des Reglers auf einer Prototypenelektronik beziehungsweise einem HIL-System (Hardware in the Loop).

Diese stellen analoge und digitale Ein-/Ausgabesignale über eine eigene API zur Verfügung. Den Übergang in diesen Schritt erschwert zumeist die spezielle Softwarearchitektur der Prototypensteuerungsgeräte. Idealerweise sollte jedoch auf dem Prototypensteuergerät dieselbe Softwarestruktur wie auf einem Simulationsrechner laufen.

Eine Kopplung von Simulatoren hört sich für die an Matlab/Simulink gewöhnten Anwender zunächst abschreckend an, bietet aber weitaus mehr Vorteile, als nur weitere Simulatoren einzubinden:

  • Einbindung weiterer (der Aufgabenstellung gerechten) Simulationssprachen und damit Abdeckung eines größeren Einsatzbereiches im Entwicklungsprozess.
  • Austausch von einzelnen Simulationsblöcken gegen detailliertere Blöcke entsprechend dem Entwicklungsfortschritt.
  • Weniger Dokumentationsaufwand aufgrund der Nutzung einer integrierten Entwicklungsumgebung und dem damit wegfallenden Neuaufsetzen der Simulationsumgebung.
  • Durch »erzwungene« Trennung der Modelle (z.B. in Regler und Regelung) bessere Widerverwendbarkeit der Blöcke.
  • Versionierung der Modelle, der Testfälle und Responses.
  • Höhere Simulationsperformance durch mögliche Verteilung der Simulatoren auf ein verteiltes Rechensystem.
  • Werkzeugunabhängige Einbindung von Hardware (DAQ-Karten) und keine Abhängigkeit von spezifischer Hardware.
  • Integration von vom Kunden vorgegebenen Modellen in die eigene Entwurfsmethodik.

Der Ansatz, für jeden Entwicklungsschritt ein eigenes Tool zu verwenden, hat zwar durchaus seine Verdienste, doch bietet eine Co-Simulation die Chance, den gesamten Entwicklungsprozess beginnend von der Spezifikation über die Implementierung bis hin zum abschließenden Test mit einer tatsächlich »integrierten Entwicklungsumgebung« abzudecken.

Damit einhergehend ergeben sich die Chancen, die Übergänge zwischen den einzelnen Entwicklungsschritten mit weniger Aufwand darzustellen, einmal erstellte Testspezifikationen während des gesamten Entwicklungsprozesses nutzen zu können und den Dokumentationsaufwand entsprechend gering zu halten.

X-in-the-Loop
Im Rahmen des Forschungsvorhabens X-IN-THE-LOOP (XIL) der Ostfalia Hochschule für angewandte Wissenschaft wird eine verteilte Co-Simulationsplattform entwickelt, welche die Kopplung diverser Simulatoren ermöglicht (www.Ostfalia.de/ivs/xil). Ein wesentlicher Aspekt dieser Co-Simulationsbackplane ist die Echtzeitfähigkeit, d. h. die schritthaltende Simulation. Von der direkten Ansteuerung vor analogen/digitalen Ein-/Ausgabekarten über Simulink, ASCET, C-Code oder Blender bis hin zur Anbindung von Modellierungssprachen wie SysML sind diverse Adapter vorhanden.