Modellbasierte Entwicklung für Echtzeitsimulation – Ingenieur:innen

Wichtigste Erkenntnisse

• Modellbasiertes Design funktioniert am besten, wenn die Modelle über die Entwurfsphase, die Codegenerierung und Tests hinweg lauffähig bleiben, Tests nur auf der Konzeptionsphase zu enden.
• Zeitpläne, Schnittstellenvereinbarungen und die Rückverfolgbarkeit der Anforderungen sind wichtiger als Modelldetails, wenn Sie sich auf eine zuverlässige Ausführung auf dem Prüfstand vorbereiten.
• Bei der herkömmlichen Fahrzeugentwicklung werden Integrationsrisiken erst spät erkannt, während eine konsequente Modellaufteilung und eine nachvollziehbare Validierung dazu führen, dass Fehler früher sichtbar werden.

Modellbasiertes Design verringert das Validierungsrisiko, wenn Ihr Simulationsmodell gleichzeitig als Grundlage für die HIL-Ausführung dient.

Teams verlieren Zeit, wenn Modelle in der frühen Entwurfsphase stecken bleiben und nie zu wiederverwendbaren Testobjekten ausgereift werden. Verkehrsunfälle verursachten 20.400 Todesopfer in der Europäischen Union im Jahr 2023, was die Validierung weiterhin mit der öffentlichen Sicherheit verknüpft und nicht mit Prozesspräferenzen. Sie benötigen einen Workflow, der Timing, Schnittstellen und den Nachweis der Anforderungen sichtbar hält, bevor der Code auf den Prüfstand kommt.

Modellbasiertes Design wandelt Simulationsmodelle in ausführbare Testressourcen um

Modellbasiertes Design für die Simulation bedeutet, dass Ihre Anlagen- und Regelungsmodelle zu ausführbaren Testobjekten werden, die vom frühen Entwurfsstadium bis hin zur HIL-Validierung ihren Nutzen behalten. Der Mehrwert ergibt sich aus der disziplinierten Wiederverwendung. Sie erkennen Schnittstellen- und Timing-Fehler früher, da in jeder Phase dasselbe Verhalten getestet wird.

Ein Team für Motorsteuerung bringt diese Struktur schnell auf den Weg. Das Reglermodell beginnt als Regelungskonzept, wird dann zur Regelkreisabstimmung gegen ein Anlagenmodell getestet, dient anschließend als Grundlage für die Codegenerierung und wird später mit Fehlerinjektion auf einem HIL-Rack ausgeführt. Sie müssen die Absicht nicht mehr in jeder Phase neu definieren. Sie verfeinern eine einzige ausführbare Beschreibung des Verhaltens.

Diese Umstellung ist wichtig, da jede Übergabe Interpretationsfehler mit sich bringt. Wenn der Strombegrenzer, die Sensorskalierung und das Timing der Zustandsmaschine bereits im Modell enthalten sind, werden Sie Unstimmigkeiten erkennen, noch bevor hardware . Außerdem werden Sie präzisere Testfälle erstellen, da das Modell normale und abnormale Betriebszustände bereits offenlegt, anstatt sie in separaten Dokumenten versteckt zu lassen.

Das V-Modell verbindet die Regelungsauslegung mit Validierungsnachweisen

Das V-Modell spielt in der Automobilindustrie eine wichtige Rolle, da es jede Designentscheidung mit einer entsprechenden Validierungsmaßnahme verknüpft. Modellbasiertes Design entspricht dieser Struktur, wenn jede Anforderung, jedes Modellelement und jeder Testfall miteinander verbunden bleibt. Durch diese Verknüpfung wird die Validierung von einem späten Kontrollpunkt zu einer nachverfolgbaren Kette von Nachweisen.

Ein Beispiel hierfür ist eine Anforderung an das Batteriemanagement. Eine Regel zur Leistungsreduzierung bei Temperaturanstieg beginnt auf der linken Seite des V als Systemanforderung, taucht dann als Logik im Reglermodell auf und kehrt schließlich auf der rechten Seite als MIL-, SIL- und HIL-Tests mit festgelegten Bestehngrenzen zurück. Ingenieur:innen raten, was ein Test nachweist, da der Weg durchgängig sichtbar bleibt.

„Modellbasiertes Design für die Simulation bedeutet, dass Ihre Anlagen- und Regelungsmodelle zu ausführbaren Testobjekten werden, die vom frühen Entwurfsstadium bis hin zur HIL-Validierung ihren Nutzen behalten.“

Das V-Modell allein kann schlechte Modellierungsgewohnheiten nicht beheben. Es erweist sich als nützlich, wenn Ihre Modelle konkret genug sind, um bei der Entwurfsprüfung als Nachweis zu dienen. Deshalb Ingenieur:innen Ingenieur:innen ebenso viel Ingenieur:innen auf Rückverfolgbarkeit wie Ingenieur:innen die Regelungsleistung.

Beginnen Sie mit Anwendungsfällen im geschlossenen Regelkreis, bevor Sie das Modell verfeinern

Anwendungsfälle mit geschlossenem Regelkreis sollten vor der Modellverfeinerung stehen, da sie Aufschluss darüber geben, welche Verhaltensweisen unter Zeitdruck korrekt ablaufen müssen. Ein detailliertes Modell ohne Testziel ist reine Zeitverschwendung. Sie werden Wochen damit verbringen, Dynamiken zu verfeinern, die für die Validierungsfrage, die Sie tatsächlich klären müssen, keine Rolle spielen.

Ein Programm für eine elektrische Servolenkung veranschaulicht den Ablauf gut. Beginnen Sie mit Einparkhilfe, Spurhalteassistent, Drehmomentüberlagerung und Fehlerbehebung bei Sensoren. Diese Anwendungsfälle definieren die Drehmomentbandbreite, die Dynamik der Zahnstange und die Fehlerbedingungen, die das Modell unterstützen muss. Das System benötigt nur so viele Details, dass das Verhalten des Reglers unter diesen Bedingungen sichtbar wird.

Dieser Ansatz sorgt dafür, dass das Modell für Tests geeignet bleibt. Wenn das nächste Benchmark-Ziel eine Fehlerbehebung innerhalb von 20 Millisekunden ist, Verfeinern Sie Verfeinern Teile, die das Zeitverhalten der Fehlerbehebung beeinflussen, und verschieben die weniger wichtigen Details auf später. Sie legen den Umfang der zu erledigenden Regelaufgabe fest, wodurch die Ausführungsaufwände unter Kontrolle bleiben und die Validierungsergebnisse an vertrauenswürdiger werden.

HIL-Workflows beginnen mit Zeitbudgets statt mit Blockdiagrammen

HIL-Workflows sollten mit Timing-Budgets beginnen, da die Echtzeitausführung weitaus eher aufgrund von Latenzzeiten scheitert als aufgrund der visuellen Modellstruktur. Ihr Blockdiagramm kann übersichtlich aussehen und dennoch die Zeitvorgaben verfehlen. Timing-Budgets zwingen Sie dazu, Abtastzeiten, I/O und Rechengrenzen festzulegen, bevor das Modell das Ziel erreicht.

Ein Traktionsumrichter-Prüfstand macht das Problem deutlich. Der Regelkreis läuft mit einer Taktzeit von 50 Mikrosekunden, der Anlagen-Sprungtest mit 1 Mikrosekunde und die I/O in einem weiteren festen Intervall. Wenn Signalaufbereitung, Kommunikation und Protokollierung zu viel von diesem Zeitbudget beanspruchen, kann man dem Testergebnis nicht trauen, selbst wenn die Regelungslogik korrekt ist.

Deshalb planen starke HIL-Teams die Zeit wie eine hardware ein. Man teilt Aufgaben frühzeitig auf, reduziert unnötige Protokollierung und trennt langsame Überwachungslogik von schnellen Regelkreisen. Wenn man diese Entscheidungen erst in einer späten Integrationsphase trifft, wirken Zeitüberschreitungen willkürlich, und das Debugging wird zu einer langwierigen Suche über Tools, hardware und Modellstruktur hinweg.

Simulink-Modelle benötigen explizite Schnittstellen, bevor sie in Echtzeit eingesetzt werden können

Simulink-Modelle lassen sich problemlos auf Echtzeit-Zielsysteme übertragen, wenn die Schnittstellen vor Beginn der Ausführung eindeutig, fest definiert und überprüfbar sind. Die Konsistenz der Schnittstellen ist wichtiger als die Modellgröße. Sind Ihre I/O, Einheiten, Startzustände und Fehlerflags mehrdeutig, wird das Modell zwar kompiliert, scheitert jedoch bei der ersten sinnvollen HIL-Sitzung.

Ein gängiges Beispiel ist ein Bremsregler. Die Logik mag bei einer Simulation auf dem Desktop einwandfrei erscheinen, doch bei der Implementierung treten Fehler auf, wenn die Skalierung der Radgeschwindigkeit von der I/O abweicht oder wenn der Startzustand einen Sensorwert voraussetzt, der im Labor nie vorliegt. Teams, die OPAL-RT verwenden, lösen dieses Problem in der Regel frühzeitig, indem sie den Schnittstellenvertrag sichtbar machen, bevor das Modell für das Zielsystem kompiliert wird.

• Legen Sie die Abtastraten für jeden Ein- und Ausgangspfad fest.
• Sperreinheiten, Skalierung und Datentypen vor der Codegenerierung.
• Legen Sie die Startzustände für Anlagen- und Reglerblöcke fest.
• Fehlerflags als testbare Eingaben statt als verborgene Logik offenlegen.
• I/O von Dokument I/O , bei der Modellnamen mit Bench-Signalen übereinstimmen.

Diese Checkliste ist zwar kurz, verhindert aber viele späte Überraschungen. Sie bereiten das Modell so vor, dass es sich eher wie eine Laborumgebung als wie eine Desktop-Simulation verhält. Sobald diese Schnittstellen stabil sind, wird die Bereitstellung zu einem Validierungsschritt statt zu einem Debugging-Marathon.

„Der Hauptunterschied zwischen modellbasiertem Design und herkömmlicher dokumentengesteuerter Entwicklung besteht darin, wann Integrationsrisiken sichtbar werden.“

Modellbasiertes System-Engineering gewährleistet die Rückverfolgbarkeit der Anforderungen während Tests

Modellbasiertes System-Engineering sorgt für Tests , da es die Verbindung zwischen Anforderungsabsicht, Modellverhalten und Testnachweis aufrechterhält. Ingenieur:innen diese Kette, um zu erklären, warum ein Ergebnis bestanden oder nicht bestanden wurde. Ohne sie liefert die Testausführung zwar Protokolle, aber keine stichhaltigen Nachweise.

Ein Beispiel hierfür ist eine Anforderung an die Ladesteuerung. Die Anforderung legt einen Strombegrenzungspegel während der thermischen Leistungsreduzierung fest, das Systemmodell verknüpft diesen Grenzwert mit Signalen und Betriebsmodi, und der HIL-Test überprüft sowohl den Grenzwert als auch die Übergangszeit nach einem Temperaturfehler. Wenn der Test fehlschlägt, kann man das Problem auf die Logik, die Kalibrierung oder den Wortlaut der Anforderung zurückführen, anstatt über die Zuständigkeit zu diskutieren.

Hier treffen modellbasiertes Design und modellbasiertes System-Engineering aufeinander. Das eine liefert Ihnen ausführbares Verhalten. Das andere sorgt dafür, dass dieses Verhalten stets mit der Systemabsicht verknüpft bleibt. Wenn Sie als Ingenieur:innen tätig sind, sparen Sie durch diese Kombination Zeit bei der Überprüfung, da jeder fehlgeschlagene Test bereits mit Kontext, Annahmen und Akzeptanzgrenzen verknüpft ist.

Bei der herkömmlichen Entwicklung werden Integrationsrisiken bis zu Tests späten Tests im Automobilbereich verborgen

Der Hauptunterschied zwischen modellbasiertem Design und herkömmlicher, dokumentengesteuerter Entwicklung liegt darin, wann Integrationsrisiken sichtbar werden. Beim modellbasierten Design werden Probleme hinsichtlich Verhalten, Timing und Schnittstellen bereits erkannt, solange das Modell noch schnell erneut ausgeführt werden kann. Bei herkömmlichen Abläufen werden viele dieser Erkenntnisse erst in Prüfstand- und Tests aufgedeckt, wo jede Korrektur mehr Zeit kostet.

Ein herkömmlicher Übergabeprozess verdeutlicht das Muster: Die Anforderungen befinden sich in einem Tool, die Steuerungslogik in einem anderen, und das HIL-Team erhält kompilierte software nur begrenztem Einblick in die zugrunde liegenden Annahmen. Wenn ein Fehler bei der Drehmomentverteilung auftritt, muss das Team gleichzeitig Dokumente, Code und die Prüfstandskonfiguration überprüfen. software mangelhafte software kostete die Vereinigten Staaten im Jahr 2022 mindestens 2,41 Billionen US-Dollar im Jahr 2022, was zeigt, wie teuer die späte Fehlerentdeckung wird, wenn das Integrationsfeedback erst nach der Designübergabe eintrifft.

Sie müssen sich nicht zwischen Dokumentation und Modellen entscheiden. Sie benötigen nach wie vor beides. Die bessere Vorgehensweise besteht darin, das Modell mit ausführbaren Absichten zu versehen und die Dokumentation dazu zu nutzen, Anforderungen, Annahmen und Nachweise für die Freigabe zu formulieren. Durch diese Vorgehensweise Tests in der Automobilbranche Tests den Nachweis statt auf die Rekonstruktion.

Eine unzureichende Modellpartitionierung beeinträchtigt den Determinismus bei Echtzeitanwendungen

Eine unzureichende Modellaufteilung untergräbt den Determinismus, da sich schnelle und langsame Aufgaben gegenseitig stören, sobald sie denselben Ausführungspfad nutzen. Echtzeitanwendungen erfordern eine klare Trennung zwischen Anlagen-Details, Regelkreisen, Kommunikation und Protokollierung. Ist diese Trennung unzureichend, verbergen sich Überschreitungen in der normalen Testaktivität, und Ihre Ergebnisse sind nicht mehr zuverlässig.

Ein Leistungselektronik-Prüfstand macht dies oft als Erstes deutlich. Das Schaltmodell gehört auf einen schnellen Ausführungsweg, während die Überwachungssteuerung, die Benutzerinteraktion und die Protokollierung auf langsamere Wege gehören. Wenn man alle diese Komponenten in einer Partition unterbringt, kann eine harmlose Änderung an der Protokollierung die Latenz so stark verschieben, dass das Ergebnis einer Stromschleife verfälscht wird. Ingenieur:innen jagen Ingenieur:innen einem Steuerungsproblem hinterher, das in Wirklichkeit ein Scheduling-Problem ist.

Gutes modellbasiertes Design endet mit einer konsequenten Aufteilung, da Determinismus Teil der Validierungsnachweise ist und keine technische Randnotiz. Teams, die diese Disziplin wahren, ziehen in der Regel einen größeren Nutzen aus OPAL-RT, da dem Simulator von Anfang an eine Modellstruktur zugeführt wird, die Timing, Schnittstellen und Testabsicht berücksichtigt. Genau das schafft Vertrauen in die Ergebnisse der Testumgebung, sobald die Fehlerbehebung abgeschlossen ist.