Der Einsatz bewährter Methoden zum Erstellen großer Simulink -Modelle

Wenn Größe und Komplexität von Systemen zunehmen, stehen Entwicklungsteams vor einer Reihe völlig neuer Herausforderungen, die bei kleineren Maßstäben nicht bestehen.

Fast immer erfordert eine deutliche Maßstabsvergrößerung eine Änderung des Ansatzes – nicht nur des Umfangs, sondern auch der Art. Dieses Prinzip gilt auch für Simulink^®-Modelle bei der Arbeit mit Model-Based Design. Werden bewährte Methoden nicht befolgt, treten bei der Umstellung von einfachen Machbarkeits-Modellen auf groß angelegte Modelle mit Hunderttausenden von Blöcken zahlreiche Probleme auf, darunter Probleme mit der mangelhaften Modellarchitektur, dem Datenmanagement, den Schnittstellen, der Dateiverwaltung und der Simulationsleistung. Die Bausteine dieser großen Modelle können klein sein und werden oft von verschiedenen Einzelpersonen, Teams und sogar Abteilungen entwickelt. Wenn eine Standardisierung erfolgt und bewährte Methoden befolgt werden, können diese Modelle problemlos skaliert werden.

In diesem Artikel wird eine Reihe bewährter Methoden zum Bewältigen der Herausforderungen beschrieben, die bei der Arbeit mit großen, komplexen Modellen in Simulink häufig auftreten. Da das Thema selbst recht umfangreich ist, besteht das Ziel hier nicht darin, detaillierte, verbindliche Anleitungen bereitzustellen, sondern vielmehr die Grundlagen der einzelnen bewährte Methoden zusammen mit Links zu weiteren Ressourcen darzustellen, die für ein tieferes Verständnis der Anwendungsmöglichkeiten erkundet werden können.

Verwenden von Modellreferenz für die Modellkomponentenbildung

Bei unserer Arbeit mit Kunden kommt es häufig vor, dass große Modelle nicht ausreichend in Komponenten zerlegt sind. Die Teams beginnen mit einem einfachen Modell, um Ideen auszuprobieren. Im Laufe der Zeit werden neue Elemente oder Funktionen hinzugefügt und die gesamte Arbeit wird in einer einzigen, monolithischen Modelldatei erledigt, die bald unhandlich wird.

In Simulink gibt es mehrere Möglichkeiten, große Modelle in Komponenten zu zerlegen, und der beste Ansatz hängt vom jeweiligen Anwendungsfall ab. Ein Team, das beispielsweise einfach eine Gruppe von Blöcken oder Komponenten visuell organisieren möchte, kann sich für ein virtuelles Subsystem im Modell entscheiden. Für ein anderes Team, das weit verbreitete Dienstprogramme erstellen möchte, die sich selten ändern, ist ein verknüpftes Subsystem (oder eine Bibliothek) eine bessere Option. Wenn das Ziel darin besteht, eine Komponente als eigenständiges Modell zu entwickeln oder zu simulieren, dann ist die Modellreferenz der beste Ansatz.

Die Modellreferenz ist auch der Schlüssel zur Komponentenbildung bei groß angelegten Modellen. Ein Grund dafür ist, dass die Modellreferenz in Simulink es Teams ermöglicht, Komponenten parallel als unabhängige Modelle zu entwickeln. Jede Komponente ist voll funktionsfähig und simulierbar und wird in einer eigenen SLX-Datei gespeichert, sodass jedes Team unabhängig arbeiten kann, ohne die Arbeit eines anderen Teams zu beeinträchtigen – was nahezu unmöglich ist, wenn das gesamte Design in einer einzigen Datei erfasst ist. Ebenso wichtig ist, dass diese unabhängigen Referenzmodelle zur einfachen Integration in größere Modelle eingefügt werden können (Abbildung 1). Diese Architektur kann die Build-Zeiten durch die Verwendung zwischengespeicherter Instanzen von Referenzmodellen und inkrementellen Builds verkürzen. Es ermöglicht auch die Verwendung der Modi Accelerator und Rapid Accelerator, die weiter unten im Abschnitt zur Leistung ausführlicher behandelt werden.

Skalieren der Datenverwaltung mit Data Dictionaries

Lassen Sie uns dasselbe Szenario noch einmal betrachten, das zu Problemen mit der Komponentenbildung geführt hat: Ein Team beginnt mit einem einfachen Modell als frühem Proof of Concept und arbeitet es dann im Laufe der Zeit weiter aus. Für ein einfaches Modell speichern viele Ingenieure Variablen, Parameter und andere Daten im Basis-Workspace. Dieser Ansatz eignet sich gut für informelle Arbeitsabläufe, schnelle Parameteroptimierung, Rapid Prototyping, Projekte mit einem einzelnen Entwickler oder Anwendungsfälle, die eine universelle Sichtbarkeit der Parameter erfordern. Da Umfang und Komplexität der Modelle jedoch zunehmen, bringt die Abhängigkeit vom Basis-Workspace für die Datenverwaltung einige Nachteile mit sich. Da beispielsweise der Basis-Workspace jedes Mal gelöscht wird, wenn ein Ingenieur seine Sitzung schließt, muss er manuell entweder in MATLAB^® Programmcode (.m) oder eine MATLAB-Datei (.mat) gespeichert werden.

Data Dictionaries eignen sich besser als der Basis-Workspace für die Verwaltung von Daten in Projekten, die große Modelle, verteilte Entwicklung oder Zieldaten beinhalten. Hierfür gibt es mehrere Gründe (siehe Abbildung 2). Das erste ist die Datenpersistenz. Daten werden in einem bestimmten Dateiformat in Data Dictionary-Dateien(.sldd) gespeichert, sodass Teams Daten getrennt vom Modell und dem Basis-Workspace definieren, verwalten und aktualisieren können. Zweitens können Teams Daten in mehrere Data Dictionaries aufteilen, um die Datenorganisation weiter zu verbessern. Drittens eignen sich Data Dictionaries gut für Workflows zur Änderungsverfolgung. So können die Teams sehen, welche Änderungen wann und von wem vorgenommen wurden. Bei Bedarf können sie sogar zu früheren Versionen zurückkehren.

Es ist hier wichtig zu beachten, dass die Wahl zwischen der Verwendung des Basis-Workspace und der Data Dictionaries nicht exklusiv ist. Die beiden Ansätze können nebeneinander bestehen, sodass ein Team im Laufe der Zeit schrittweise vom Basis-Workspace in ein oder mehrere Data Dictionaries migrieren kann.

Vereinfachen von Schnittstellen mit Bussen

Beim Verbinden von Subsystemen in einem komponentenbasierten, hierarchischen Modell kann es zunächst so aussehen, als sei die einfachste Vorgehensweise die Verwendung einer separaten Signalleitung für jedes Element, das von einer Komponente zur anderen weitergegeben wird. Dies funktioniert natürlich bei einfachen Schnittstellen, doch dieser Ansatz kann schnell zu Modellen führen, die komplexer, unübersichtlicher und schwieriger zu verwalten sind als nötig.

In Simulink können Busse Schnittstellen vereinfachen und Unordnung reduzieren, indem eine Reihe von Signalen (oder Elementen) mit einer einzigen Linie dargestellt wird, ähnlich wie mehrere gebündelte Drähte. Der Nutzen lässt sich anhand eines einfachen Beispiels leicht verdeutlichen. Stellen wir uns eine Fehlererkennungskomponente zum Identifizieren anomaler Zustände in einem Batteriesystem vor. Die Komponente verfügt über 11 verschiedene Eingänge, darunter maximale und minimale Zellspannung, maximale und minimale Zelltemperatur, Schützzustände, Packspannung und -strom sowie Stromgrenzen. Zwar ist es durchaus möglich, die Komponente mit 11 einzelnen Eingangsports zu erstellen, es ist jedoch übersichtlicher, die Eingänge in logische Gruppen aufzuteilen und für jede Gruppe einen Bus zu verwenden. Da beispielsweise die Zellspannungs- und Zelltemperatursignale alle von derselben Komponente stammen und alle miteinander in Beziehung stehen, ist es sinnvoll, sie in einem einzigen Bus mit vier Elementen zusammenzufassen (Abbildung 3). Dies ist natürlich ein relativ triviales Beispiel, aber es zeigt, wie Busse verwendet werden können, um nicht nur Komponentenschnittstellen, sondern im weiteren Sinne auch komplexe Modelle zu vereinfachen.

Verbessern der Dateiverwaltung mit Projekten

Ein Nebeneffekt der Befolgung der bisher beschriebenen bewährten Methoden ist eine Zunahme der Anzahl der zu verwaltenden Dateien. Wenn sich das gesamte Design in einem einzigen Modell befindet, ist die Menge der Dateien, die ein Team verwalten muss, relativ klein. Sie kann jedoch schnell wachsen, wenn Komponentenbildung und Data Dictionaries aktiv eingesetzt werden. Ohne eine Dateiverwaltungsstrategie kann diese Vervielfältigung von Dateien problematisch werden.

Bei der Arbeit in Simulink können Teams verwenden Projekte um die Automatisierung von Dateiverwaltungsaktivitäten zu unterstützen, sodass mehr Zeit für die Modellierung, Simulation und andere hochwertige Aktivitäten bleibt. Zum Beispiel beim Einrichten eines Projekts, gibt das Team die Ordner im Projektpfad an. Diese Ordner werden beim Öffnen des Projekts zum Suchpfad hinzugefügt (und beim Schließen des Projekts entfernt). Dadurch wird sichergestellt, dass alle Benutzer des Projekts Zugriff auf die darin enthaltenen Dateien haben. Das Team kann auch Startdateien angeben, die das Einrichten der Umgebung für Ihr Projekt automatisieren, und Shutdown-Dateien, die die Umgebung bereinigen, indem sie beispielsweise Einrichtungsschritte rückgängig machen. Darüber hinaus können Projekte so konfiguriert werden, dass beim Start häufig verwendete Dateien geöffnet und Verknüpfungen für häufig verwendete Aufgaben erstellt werden.

Projekte können Teams auch dabei helfen, häufige Fehler zu vermeiden. Beispielsweise ist es bei einer komplexen Modellhierarchie nicht ungewöhnlich, dass zwei Modelldateien mit demselben Namen in unterschiedlichen Verzeichnissen vorhanden sind. Bei der Verwendung eines Projekts wird dem Ingenieur eine Warnung angezeigt, wenn Schattendateien werden erkannt. Darüber hinaus werden Ingenieure beim Schließen eines Projekts dazu aufgefordert, alle nicht gespeicherten Änderungen zu speichern. So wird vermieden, dass erledigte Arbeit verloren geht.

Schließlich helfen Projekte dabei, die Quellcodeverwaltung zu optimieren, wobei gängige Vorgänge wie Aktualisieren, Commit, Push, Pull, Fetch und andere allgemeine Vorgänge direkt über die Benutzeroberfläche zugänglich sind (Abbildung 4).

Optimieren der Simulationsleistung

Die bewährten Methoden, die wir bisher behandelt haben, konzentrierten sich hauptsächlich auf die Struktur großer Modelle und deren zugehörige Daten und Dateien. In Gesprächen mit Kunden, die diese bewährten Methoden implementiert haben, werden wir häufig nach Möglichkeiten zur Verbesserung der Simulationsleistung gefragt: „Jetzt, da wir eine bessere Möglichkeit haben, große Modelle zu bauen, wie können wir sie schneller simulieren? ”

Zur Verbesserung der Simulationsleistung stehen verschiedene Tools zur Verfügung. Als ersten Schritt empfehlen wir Performance Advisor, das eine Reihe von Prüfungen durchführt, um Konfigurationseinstellungen zu identifizieren, die Simulationen möglicherweise verlangsamen. Als nächstes kann man für jedes Modell, das MATLAB-Code zur Initialisierung enthält (zum Beispiel in einem Rückruf), die MATLAB Profiler-App ausführen, um zu ermitteln, wo MATLAB die meiste Zeit verbringt. Simulink Profiler bewertet die Modellausführungszeit und identifiziert Probleme, die möglicherweise zu einer schlechten Simulationsleistung beitragen. Schließlich empfehlen wir Teams, die einen Solver mit variabler Schrittweite verwenden, den Solver Profiler auszuführen, der das Solver-Verhalten analysiert, potenzielle Probleme (wie Solver-Resets oder außergewöhnlich kleine Zeitschritte) identifiziert und Empfehlungen zu deren Lösung bereitstellt. Anleitungen zu jedem dieser Tools, einschließlich wie und wann sie zu verwenden sind, finden Sie in der Anleitung Fehlerbehebung und Beschleunigung der Simulationsleistung (siehe Tabelle).

Teams, die ihr großes Modell in Komponenten zerlegt haben, können Simulationen durch den Accelerator-Modus or Rapid Accelerator-Modus beschleunigen, die den normalerweise in Simulink-Simulationen verwendeten interpretierten Code durch generierten Code ersetzen. Während der Modellinitialisierung überprüft Simulink einen Cache auf Komponenten, für die bereits Code generiert wurde. Dieser inkrementelle Erstellungsprozess reduziert die Initialisierungszeit für große Modelle mit vielen Komponenten erheblich, da nur die Komponenten neu erstellt (und dem Cache hinzugefügt) werden müssen, die sich seit der letzten Simulation geändert haben.

Eine weitere Möglichkeit, die Initialisierungszeit zu verkürzen – insbesondere bei der iterativen Simulation eines Modells – ist mit dem fast restart (schneller Neustart). Wenn ein Team mehrere Simulationsläufe durchführt, ohne strukturelle Änderungen am Modell vorzunehmen, kann ein schneller Neustart den Prozess beschleunigen, indem die Simulationen durchgeführt werden, ohne das Modell jedes Mal kompilieren und die Simulation beenden zu müssen. Stattdessen wird das Modell bei der ersten Simulation kompiliert und initialisiert und anschließend für jede nachfolgende Simulation ein Schnappschuss des Betriebspunkts des Modells erfasst (Abbildung 5).

Zusammenfassend lässt sich sagen, dass die Einhaltung bewährter Methoden für Entwicklungsteams bei der Bewältigung der Komplexität der Skalierung von Simulink-Modellen von entscheidender Bedeutung ist. In diesem Artikel wurden wichtige Strategien zur Modellkomponentenbildung, Datenverwaltung und Leistungsoptimierung beschrieben und die Bedeutung eines strukturierten Ansatzes für die Modellentwicklung hervorgehoben. Durch den Einsatz von Tools wie Performance Advisor, MATLAB Profiler und Solver Profiler können Teams die Simulationsleistung verbessern und die Produktivität steigern. Diese Vorgehensweisen stellen sicher, dass Großmodelle handhabbar, effizient und anpassungsfähig bleiben. Während sich die Landschaft des Model-Based Design ständig weiterentwickelt, werden diese Richtlinien den Teams dabei helfen, robuste Modelle zu erstellen, die den Anforderungen zunehmend komplexer technischer Herausforderungen gerecht werden. Zur weiteren Erkundung werden die Leser ermutigt, die zusätzlichen Ressourcen und Schulungsmöglichkeiten zu nutzen, die in diesem Dokument hervorgehoben werden.

Der Inhalt dieses Artikels basiert auf einem Vortrag mit dem Titel „Bewährte Methoden zum Erstellen großer Modelle von Komponenten bis hin zu komplexen Systemen“ (diesen Vortrag sowie weitere Webinare und Schulungen finden Sie unter „Weitere Informationen“), den wir auf der MathWorks Automotive Conference gehalten haben. Wie wir eingangs angemerkt haben, handelt es sich hierbei um ein umfangreiches Thema, das nicht in einem einzigen Artikel oder Vortrag erschöpfend behandelt werden kann.