Simulation Wie sich exakte, realistische Modelle erzeugen lassen
Ein exaktes Systemmodell ist ein Modell, das sich genau wie erwartet verhält und die erwünschten Resultate liefert. Dient es beispielsweise ausschließlich für Simulationen oder soll daraus auch C-Code generiert werden? Nur mit einem klar definierten Modellierungsziel lässt sich eine hohe Modellierungsgenauigkeit erreichen.
Anbieter zum Thema
Mit Simulink ist sowohl die System Level-Modellierung (top–down) als auch einen Detail für Detail (bottom–up) durchgeführten Modellierungsansatz möglich. Der gewählte Ansatz entscheidet, wie das Modell organisiert ist. In einem System-Level-Modell werden zunächst die Schnittstellen zwischen den einzelnen Systemkomponenten definiert und dann schrittweise ausgearbeitet. Bei einem Detail-für-Detail-Ansatz, wächst das Modell organisch – mit steigender Komplexität.
Bei beiden Arbeitsweisen können Modellkomponenten mit domänen-spezifischen Modellierungs-Werkzeugen, wie SimMechanics, SimHydraulics und SimPowerSystems implementiert werden, um Design-Spezifikationen in schematischer Form abzubilden. Die Tools leiten die auf physikalischen Grundgesetzen basierenden Gleichungen des System automatisch daraus ab. System Level-Modelle lassen sich zusätzlich mithilfe bekannter Daten eines physikalischen Systems implementieren. Dieser Ansatz wird oft gewählt, wenn Testdaten verfügbar sind oder wenn komplizierte dynamische Gleichungen vereinfacht werden sollen.
Für genaues Modell sind optimal konfigurierte Simulationsparameter nötig
Ein möglichst exaktes Modell setzt optimal konfigurierte Simulationsparameter voraus. Dazu nutzt man beispielsweise Solver mit variabler Schrittweite, deren Toleranzen so gesetzt werden, dass der beste Trade-Off zwischen der Modell-Leistung und der Genauigkeit aller Zustandsberechnungen erzielt wird. Dies gelingt nur, wenn die Dynamik des jeweiligen physikalischen Systems genau verstanden wurde.
Hat dieses System vielen Komponenten, wird seine Dynamik oft erst verständlich, wenn alle Komponenten verbunden sind und das Gesamtsystem simulierbar wird. Jede Einzelkomponente muss darum bereits vorher in einer eigenen Testumgebung überprüft werden, deren Schnittstelle dann für die weitere Entwicklung erhalten bleibt.
Ein System zu kennen, bedeutet, seine Dynamik zu verstehen und damit die Simulationsparameter so wählen zu können, dass sie das Systemverhalten korrekt wiedergeben. Der Frequenzgang eines Systems lässt sich beispielsweise durch Linearisierung mit Simulink und Simulink Control Design ermitteln. Das Verhalten der so gewonnenen Darstellung ist aber auf bestimmte Eingabe- und Zustandswerte beschränkt. Die Gesamtdynamik dagegen lässt sich nur mithilfe von Solvern mit variabler Schrittweite erfassen.
Simulation wird überwacht und überprüft
Simulink enthält eine Bibliothek mit Blöcken zur Überwachung von Simulationsergebnissen. Damit werden Signalwerte beobachtet, statische oder dynamische Grenzen dieser Werte gesetzt und Assertions - so genannte Zusicherungen - für den Fall einer Werteverletzung festgelegt.

Hält die Simulation alle Erwartungswerte ein, ist das noch keine Garantie für gute Ergebnisse. Es gilt auch zu beachten, welche Art von Signal man überwacht. Integratoren und Übertragungsfunktionen glätten oft deren Ausgaben. Dieser Filtereffekt kann unrealistische Dynamikanteile im System verschleiern. So kann eine stark schwankende Beschleunigung trotzdem ein akzeptables Orts- und Geschwindigkeitssignal erzeugen.
In Simulationen lassen sich gemachte Grundannahmen überprüfen
Bis hierher wurde gezeigt, wie die Wahl der Implementierungsmethode die Genauigkeit eines Modells bestimmt und welche „Best Practices“ es zur Verwendung von Assertions und zur Verifikation der Simulationsergebnisse gibt. Hohe Genauigkeit ist aber nur erreichbar, wenn alle Annahmen, wie etwa für Aktuatoren erlaubte Maximalströme, zusammen mit dem Modell gespeichert werden. Das Modell wird dadurch zu einer ausführbaren Spezifikation und somit zu der zentralen Quelle für alle Informationen zum Systemverhalten.
In Simulationen können die Entwickler nun Schritt für Schritt alle implizit und explizit gemachten Grundannahmen überprüfen. Hierbei ist es nicht nur wichtig, fehlerhafte Annahmen aufzuspüren, sondern auch solche, die unbewusst in das Modell eingeflossen sind und zu unerwartetem Verhalten oder Fehlern führen können. Alle Komponenten eines Systems werden nun für sich simuliert und ihr korrektes Verhalten wird so verifiziert.
Verletzungen des Normverhaltens lassen sich in Simulink durch den grafischen Charakter und die freie Erweiterbarkeit des Systementwurfs schnell aufspüren. Die Entwickler können dann unmittelbar entscheiden, ob eine Parameteränderung, eine zusätzliche Assertion, eine Heuristik oder der Ersatz eines Designelements durch Alternativen – etwa einen anderen Solver – das Problem behebt und das Ergebnis sofort wieder simulieren.
Systemmodell wächst Stück für Stück zur Implementierungsreife
Mit Verständnis für die Systemdynamik kann der Entwickler die richtige Ausgangskonfiguration für sein System finden und die entscheidenden Stellen für den Einbau von Überwachungselementen erkennen. Das Modell muss sämtliche Design-Annahmen enthalten. Voraussetzung für eine Modellierung mit hoher Genauigkeit sind separate Tests aller beteiligten Komponenten sowie ein klares Verständnis des zu modellierenden Systems auf Seiten des Entwicklers.
Ein so entwickeltes Systemmodell wächst Stück für Stück zur Implementierungsreife, während die Ingenieure zu jedem Zeitpunkt einen exakten Eindruck von seinem Aufbau, seinem Verhalten und allen darin gemachten Annahmen behalten. Durch diese Transparenz und die Möglichkeit, es als „Goldene Referenz“ zu verwenden, gegen die das fertige Produkt verifiziert wird, wird das Modell auch höchsten Ansprüchen gerecht, wie sie beispielsweise an sicherheitskritische Systeme in Fahrzeugen oder Flugzeugen gestellt werden. Das fertige Modell kann nun sowohl als Quelle für die Hardware-Implementierung als auch zur Codegenerierung dienen. Ergebnis einer solchen Entwicklung ist ein schneller entwickeltes Produkt mit weniger Fehlern bei hoher Wiederverwendbarkeit des Modells.
* Seth Popinchalk, The MathWorks
(ID:276532)