Model-Based Systems Engineering kombiniert mit Model-Based Design beschleunigt die Entwicklung elektrischer Antriebsstränge

In der gesamten Elektrofahrzeug- (EV) und E-Mobilitätsbranche stehen die für die Entwicklung elektrischer Antriebsstränge verantwortlichen Ingenieurteams vor einer Reihe gemeinsamer Herausforderungen. Hierzu zählt nicht nur eine erhöhte Produktkomplexität, sondern auch die Notwendigkeit, qualitativ hochwertige Produkte schneller zu liefern und gleichzeitig die Kosten zu begrenzen und die Prozesskonformität mit ASPICE, ISO^® 26262 und anderen Standards sicherzustellen.

Um diese Herausforderungen anzugehen, bekamen wir bei eMoveUs die seltene Gelegenheit, die umfangreiche Erfahrung unserer Mitarbeitenden im Bereich E-Mobilität mit dem Aufbau eines neuen Unternehmens auf der grünen Wiese zu verbinden. Wir haben einen schlanken Entwicklungsprozess mit einer konsistenten Toolchain etabliert, wodurch die Nachteile behoben werden, die wir bei früheren Ansätzen festgestellt haben.

Nach einer gründlichen Bewertung der verfügbaren Optionen haben wir einen Workflow übernommen, der Model-based Systems Engineering (MBSE) und Model-Based Design unter Verwendung von MATLAB^®- und Simulink^®-Produkten zusammen mit der Polarion™ Application Lifecycle Management (ALM) Software kombiniert. Der System-Engineering-Prozess nach ASPICE ist in Abbildung 1 zu sehen. Dieser Workflow hat bereits in mehreren Bereichen nachweisliche Vorteile. Er ermöglicht uns, mit einer einzigen zuverlässigen Quelle zu arbeiten und eine umfassende Wiederverwendung von Arbeitsprodukten über Disziplinen und Projekte hinweg zu erreichen. Darüber hinaus können sich unsere Ingenieure auf die Funktionsentwicklung statt auf die Prozesskonformität konzentrieren und gleichzeitig die Rückverfolgbarkeit von den Anforderungen zu Architekturen, Modellen, Code und Tests herstellen. Wichtig ist auch, dass wir dadurch das „Shift-Left“-Paradigma auf das System Engineering anwenden können. So wird es möglich, das dynamische Systemverhalten auf Systemebene zu analysieren und insbesondere Spezifikationsfehler frühzeitig im Gesamtprozess zu identifizieren.

Modellierung der Systemarchitektur mit System Composer

In klassischen Produktentwicklungsprozessen werden Fehler in der Systemspezifikation häufig erst dann erkannt, wenn Prototypen verfügbar sind und diese anhand der Systemspezifikation getestet werden. Dies verursacht in der Regel hohe Fehlerkorrekturkosten und führt teilweise zu kritischen Verzögerungen im Projekt. Um diese zusätzlichen und unvorhersehbaren Kosten aufgrund von Spezifikationsfehlern auf Systemebene zu vermeiden, ist es unser Ziel, die Korrektheit der Spezifikation so früh wie möglich im Prozess zu überprüfen. In unserem Workflow verwenden wir System Composer™, um simulierbare Systemarchitekturen zu definieren, die es uns ermöglichen, Test- und Validierungsaktivitäten nach vorn zu verlagern und mit CI-Pipelines zu automatisieren, wie auch in Abbildung 1 dargestellt.

Darüber hinaus halten wir eine eindeutige Zuordnung zwischen Systemkomponenten und deren entsprechenden Softwarearchitekturkomponenten in System Composer und Simulink aufrecht, wodurch es möglich wird, das dynamische Verhalten auf Systemebene zu analysieren. So können Verhaltensmodelle auf Systemebene von Softwareingenieuren als Entwurf verwendet werden, die dabei nicht nur die Schnittstellen, sondern auch die in der Systemarchitektur definierten Verhaltensmodelle als Ausgangspunkt für die Entwicklung detaillierter Entwürfe für die Softwareproduktion in Simulink wiederverwenden. Darüber hinaus besteht eine hohe Wiederverwendung von Simulationsmodellen und -umgebungen, die abteilungsübergreifend genutzt werden. Beispielsweise wird dasselbe Anlagenmodell für geschlossene Regelkreissimulationen und -tests in der System-, Hardware- und Softwareabteilung verwendet und kann außerdem direkt in Echtzeit auf unserem Speedgoat^®-HIL-System ausgeführt werden. Eine schematische Darstellung der Abhängigkeiten ist in Abbildung 2 skizziert.

Zusätzlich verwenden wir die Requirements Toolbox™ und den Polarion Connector for Simulink, um die in Polarion verwalteten Anforderungen mit den in den System Composer-Modellen definierten Architekturelementen zu verknüpfen. Wir verknüpfen außerdem die detaillierten Designelemente innerhalb der Simulink-Modelle der Software-Implementierungen mithilfe dieses Connectors. Mit dieser Einrichtung wird eine bidirektionale Rückverfolgbarkeit zwischen Spezifikation und Implementierung ohne manuelle Synchronisierung ermöglicht. Dies erleichtert die Zusammenarbeit zwischen multidisziplinären Teams und trägt dazu bei, Konsistenz im gesamten Entwicklungszyklus sicherzustellen.

Physikalische Modellierung mit Simscape

Geschlossene Regelkreissimulationen auf System-, Software- oder Hardwareebene erfordern ein physikalisches Modell des Antriebsstrangs eines Elektrofahrzeugs. Wir haben dieses Modell in Simscape™ und Simscape Electrical™ erstellt. Eine Übersicht ist in Abbildung 3 zu sehen. Dieses Multidomänenmodell umfasst modulare Komponenten für die Batterie des Antriebsstrangs, das Gleichstromkabel, den Filter für elektromagnetische Interferenzen (EMI), den Wechselrichter, die Wechselstrom-Sammelschiene, elektrische Antriebe, Lastmodelle und die Kühlung. In diesem Modell können wir auch Modelle reduzierter Ordnung für thermische und elektromagnetische Effekte aus CAE-Tools wie Ansys Maxwell integrieren, um die beabsichtigten Simulationszeiten einzuhalten.

Damit unsere Ingenieure den Genauigkeitsgrad für jede Komponente des aktuellen Simulationsfalls auswählen können, haben wir ein Variantenmanagementsystem mit Modellvarianten implementiert. Beispielsweise könnte ein Team mit dem Variant Manager for Simulink einfache Simulationen mit einem Variantenblock durchführen, der die Batterie als einfache konstante Spannungsquelle modelliert. Später wechseln sie möglicherweise zu den RC- oder RL-Schaltungsvarianten der Batterie, um das kapazitive Verhalten bei niedriger Frequenz bzw. das induktive Verhalten bei hoher Frequenz zu untersuchen. Ebenso könnten unsere Ingenieure eine einfache Variante mit gesteuerter Spannungsquelle für den Wechselrichter verwenden, um die Simulation zu beschleunigen. Oder sie wählen eine Variante mit höherer Genauigkeit und realistischem Schaltverhalten, um PWM-Effekte zu beurteilen. Ein Beispiel für die Handhabung dieser Varianten im Variant Manager ist in Abbildung 4 dargestellt.

Closed-Loop-Simulation, Codegenerierung und Echtzeit-HIL-Tests

Mit der in System Composer dargestellten Systemarchitektur und dem detaillierten Anlagenmodell haben wir die Möglichkeit, geschlossene Regelkreissimulationen auf mehreren Ebenen mit Systemverhaltensmodellen, Softwarearchitekturmodellen oder detaillierten Designmodellen in Simulink durchzuführen, wie in Abbildung 5 gezeigt.

Es ermöglicht uns, unsere Validierungsaktivitäten, die bereits auf Systemebene stattfinden, nach links zu verlagern und so Spezifikationsfehler bei komplexen Antriebssystemfunktionen zu minimieren.

In dieser Umgebung können wir das Verhalten des Produkts auf Systemebene mithilfe von MATLAB sowie dem Data Inspector analysieren, um Signale, Leistungsmetriken und Zeitbeziehungen zu visualisieren. Ein Beispiel für die Ergebnisse der geschlossenen Regelkreissimulations unserer Systemarchitektur zur Analyse des Stromregelverhaltens eines feldorientierten Reglers ist in Abbildung 6 zu sehen. Automatisierte Tests können in diesem Closed-Loop-Setup auf Systemebene oder für spezielle Architekturkomponenten unter Verwendung von Simulink Test™ ausgeführt werden. Darüber hinaus werden diese Testergebnisse automatisch zurück an Polarion synchronisiert, um eine aktuelle Projektverfolgung und ein Berichtswesen entsprechend der Testfallspezifikation zu ermöglichen.

Dieser konsequente Entwicklungsansatz macht nicht an den Domänengrenzen halt, sondern geht darüber hinaus. Wenn wir uns in den Domänen des V-Zyklus vorwärts bewegen, von der Systemspezifikation zur Softwarespezifikation, Architektur, Model-Based Design und Implementierung, umfasst die nächste Phase unseres Workflow die Codegenerierung sowie MIL-, PIL- und HIL-Tests. Hier verwenden wir Embedded Coder^®, um Code aus unseren Softwarearchitektur- oder detaillierten Designmodellen in Simulink zu generieren, ihn in einen AUTOSAR^®-Stack zu integrieren und ihn auf einen Infineon^® AURIX™ TC3xx Mikrocontroller bereitzustellen. Das bereits vorgestellte Anlagenmodell wird anschließend mithilfe von HDL Coder™ und Simulink Real-Time™ auf einem FPGA auf einer Speedgoat-Echtzeit-Zielmaschine implementiert. Mit diesem Setup kann das korrekte Softwareverhalten des Endprodukts auf einem HIL überprüft werden. Um Synergien zu nutzen und die Geräte- und Entwicklungskosten zu senken, wird außerdem dieselbe HIL-Plattform verwendet, um Systemintegrations- und Verifizierungstests durchzuführen, bevor die endgültigen Tests auf einem Prüfstand durchgeführt werden.

Realisierte Vorteile und laufende Integrationsverbesserungen

Der Workflow und der Toolchain-Ansatz wurden während unserer Entwicklung eines Siliziumkarbid-basierten 800-Volt-Wechselrichters validiert, der in der Lage ist, eine Spitzenleistung von bis zu 600 Kilowatt für automobile Traktionsanwendungen zu liefern. Die Teilnahme am MathWorks Startup-Programm hat uns geholfen, die Markteinführungszeit für dieses Produkt zu verkürzen und gleichzeitig die Kosten niedrig zu halten, was für praktisch alle Startups unerlässlich ist.

Wir erweitern und verbessern weiterhin unseren Workflow. Beispielsweise verwenden wir CI bereits mit Jenkins^® und Bitbucket^®, um kontinuierlich Softwaremodul-, Integrations- und Verifizierungstests durchzuführen. Wir arbeiten außerdem daran, diesen CI-basierten Automatisierungs-Workflow im V-Zyklus weiter nach oben zu erweitern, um eine automatisierte CI-basierte Verifikation unserer Systemarchitekturen zu ermöglichen.