Echtzeit-HIL- und SIL-Leitfaden für elektrifizierte Steuerungssysteme

Wichtigste Erkenntnisse

• Verwenden Sie SIL, um die Steuerungslogik und Schnittstellen zu stabilisieren, und verwenden Sie dann HIL, um das Timing, I/O und die sichere Fehlerbehandlung unter deterministischer Ausführung zu überprüfen.
• Legen Sie frühzeitig die Genauigkeit, Schrittweite und Risikoziele fest, da elektrifizierte Systeme späte Änderungen an Modelldetails,I/O und Sicherheitsverriegelungen bestrafen.
• Schaffen Sie Vertrauen durch Automatisierung und Wiederholbarkeit mit versionierten Modellen, kontrollierter Fehlerinjektion und konsistenten Ergebnisüberprüfungen, die Regressionen schnell aufdecken.

Nur wenn SIL- und HIL-Tests diszipliniert und wiederholbar durchgeführt werden, können Sie sich auf die Freigabefähigkeit elektrifizierter Steuerungen verlassen.

Der Absatz von Elektroautos erreichte im Jahr 2023 fast 14 Millionen im Jahr 2023, und dieses Volumen erhöht die Kosten für Fehler in der Steuerungslogik. Elektrifizierte Systeme kombinieren schnell schaltende Leistungselektronik mit Sicherheitslogik, Sensoraufbereitung und Netzwerkverkehr, und das alles unter hohem Zeitdruck. Diese Kombination führt häufig zu Überraschungen bei der späten Integration, wenn Teams Tests einen einzigen Meilenstein betrachten. Ein stufenweiser Plan, der mit software beginnt und sich bis zu hardware hocharbeitet, verhindert den Großteil dieser Probleme.

Die praktische Haltung ist einfach: Behandeln Sie Tests eine Kette von Nachweisen und nicht Tests eine einzelne Werkzeugwahl.

Software testet Algorithmen und Schnittstellen kostengünstig, während hardware Timing, I/O und Fehlerbehandlung unter deterministischer Ausführung testet. Sie erzielen bessere Ergebnisse, wenn Sie frühzeitig Genauigkeitsziele festlegen, Modelle für die Ausführung mit festen Schritten vorbereiten und die Läufe automatisieren, damit die Ergebnisse über Wochen und Teams hinweg vergleichbar bleiben.

SIL vs. HIL für elektrifizierte Steuerungssysteme und Testziele

Der Hauptunterschied zwischen SIL und HIL besteht darin, was den Regelkreis schließt und welches Risiko Sie ausschalten. SIL führt Ihre Steuerungslogik auf einem simulierten System auf einem Standard-Rechner aus, sodass Sie schnell iterieren und viele Fälle abdecken können. HIL führt die Steuerung auf der vorgesehenen hardware aus hardware schließt den Regelkreis über physische I/O, sodass das Timing und die elektrischen Schnittstellen überprüft werden. Die Testziele sollten die Reihenfolge vorgeben.

SIL eignet sich am besten, wenn Sie noch dabei sind, das Steuerungsverhalten, die Kalibrierungen und die Fehlerlogik zu gestalten, da die Bauzeiten und Test-Resets gering bleiben. HIL wird unverzichtbar, sobald Sie sich mit samplegenauen Triggern, Bus-Timing, Sensorskalierung, PWM-Erfassung oder Schutzsequenzen im Zusammenhang mit hardware befassen. Elektrifizierte Systeme verstärken diesen Bedarf, da Regelkreise oft in Schritten von weniger als einer Millisekunde laufen, während die Anlagendynamik ein starres Schaltverhalten beinhalten kann. Der sauberste Weg besteht darin, SIL zur Beseitigung von Logikfehlern zu verwenden und anschließend HIL zum Nachweis der Determiniertheit und der Korrektheit der Schnittstellen.

Wählen Sie vor dem Bau der Anlagen die gewünschten Zeit- und Kostenziele aus.

Klare Ziele hinsichtlich Genauigkeit, Zeitplan und Budget verhindern, dass HIL zu einem teuren wissenschaftlichen Projekt wird. Entscheiden Sie, welche Signale zyklusgenau sein müssen, welche in ihrer Frequenz begrenzt werden können und welche ohne Beeinträchtigung der Entscheidungen abstrahiert werden können. Verbinden Sie diese Entscheidungen mit dem Release-Risiko und nicht mit persönlichen Vorlieben für Details. Dieser Planungsschritt legt auch die Erwartungen hinsichtlich Rechenleistung, I/O und Personalbedarf fest.

Elektrifizierte Programme scheitern hier oft, weil Teams davon ausgehen, dass „höhere Genauigkeit“ automatisch „mehr Wahrheit“ bedeutet. Höhere Genauigkeit kann auch kleinere Schrittweiten, eine höhere Steifigkeit des Solvers und schwerer reproduzierbare Läufe bedeuten, insbesondere wenn Modellwechsel und Netzwerkverkehr kollidieren. Elektroautos machten 18 % der weltweiten Autoverkäufe im Jahr 2023, daher sind Validierungsdurchsatz und Wiederholbarkeit ebenso wichtig wie Spitzenpräzision. Sie möchten das Modell mit der geringsten Genauigkeit, das dennoch die gleichen technischen Entscheidungen trifft.

• Definieren Sie den schnellsten Regelkreis-Schritt, der deterministisch sein muss.
• Listen Sie die fünf häufigsten Fehlermodi auf, die Sie bei Bedarf reproduzieren müssen.
• Legen Sie eine akzeptable Latenz von I/O Steuerausgabe fest.
• Entscheiden Sie, welche Pflanzenteile im Detail ausgetauscht werden müssen und welche im Durchschnitt.
• Cap-Rig-Umfang mit einem zeitlich begrenzten Plan zum Hinzufügen von Kanälen

Vorbereitung von Anlagen- und Reglermodellen für Tests

Modelle werden erst dann zu Testressourcen, wenn sie deterministisch in festen Schritten laufen und klare Schnittstellen aufweisen. Ihr Anlagenmodell sollte numerische Stabilität, begrenzte Ausgänge und messbare Zustände priorisieren, auch wenn dies eine Vereinfachung einiger physikalischer Aspekte bedeutet. Ihr Reglermodell sollte die Algorithmuslogik von I/O trennen, damit Signale sauber ausgetauscht werden können. Diese Entscheidungen reduzieren den Nachbearbeitungsaufwand beim Wechsel von SIL zu HIL.

Elektrifizierte Anlagen kombinieren häufig kontinuierliche Dynamiken mit diskreten Ereignissen wie Schaltvorgängen, Schützzuständen und Fehlerverriegelungen. Diese Mischung macht variable Schrittweiten, versteckte algebraische Schleifen und Ad-hoc-Einheiten zunichte. Eine gute Vorbereitungsphase sperrt Einheiten, dokumentiert Abtastraten und fügt explizite Ratenübergänge ein, sodass das Timing jedes Subsystems beabsichtigt ist. Außerdem benötigen Sie Signalgrenzen und Sensormodelle, die realistisch gesättigt sind, da viele Controller-Fehler nur auftreten, wenn Messungen abgeschnitten werden oder einfrieren.

Die Schnittstellendisziplin ist genauso wichtig wie die Mathematik. Behandeln Sie jeden Bus, jeden Sensor und jeden Aktuator als einen Vertrag mit einem definierten Bereich, einem Standardwert und einer Fehlerdarstellung. Trennen Sie die „Anlagenwahrheit“ von dem, was der Controller „misst“, und protokollieren Sie dann beides, damit ein fehlgeschlagener Test ohne Spekulationen diagnostiziert werden kann. Wenn Sie späterhardware hinzufügen, wird derselbe Vertrag zur Verkabelungs-Checkliste.

Vertrauen entsteht durch beständige Beweise, und beständige Beweise entstehen durch die Kontrolle der Details, die Sie kontrollieren können.

Richten Sie SIL-Läufe und Automatisierung mithilfe von RT-LAB-Workflows ein.

SIL liefert einen Mehrwert, wenn die Ausführungen automatisiert, vergleichbar und über verschiedene Builds hinweg leicht reproduzierbar sind. Ein konsistenter Workflow kompiliert Modelle zu deterministischen ausführbaren Dateien, lädt Testvektoren und sammelt die Ergebnisse in einem einzigen Format, dem Ihr Team vertraut. RT-LAB wird häufig zur Verwaltung dieses Ausführungslebenszyklus verwendet, einschließlich Parameter-Sweeps und Datenprotokollierung. Durch die Automatisierung wird „funktioniert auf meinem Rechner“ aus der Validierung herausgehalten.

Eine solide Einrichtung beginnt mit versionierten Modellen, versionierten Testfällen und einem klaren Benennungsschema für die Ergebnisse. Die Testautomatisierung sollte die Ausgangsbedingungen jedes Mal auf die gleiche Weise zurücksetzen und dann die Pass/Fail-Kriterien überprüfen, die Ihrer technischen Absicht entsprechen. Die Protokollierung sollte sowohl den Stimulus als auch die Reaktion des Controllers sowie Zeitstempel erfassen, damit Regressionen offensichtlich sind. Außerdem benötigen Sie eine einfache Möglichkeit, einen fehlgeschlagenen Fall lokal erneut auszuführen, ohne den gesamten Teststand neu aufbauen zu müssen.

Hier kommt es auf den Ausführungskontext an, nicht auf die Behauptungen der Anbieter. Teams, die RT-LAB innerhalb von OPAL-RT-Setups verwenden, standardisieren in der Regel Kompilierungsziele, Abtastzeiten und Protokollvorlagen, damit sich Ingenieur:innen auf die Steuerungsabsicht statt auf die Laufmechanik konzentrieren Ingenieur:innen . Diese Art der Standardisierung zahlt sich aus, wenn ein später Bug auftritt und Sie nachweisen müssen, wann er eingeführt wurde. Das Ziel ist eine lückenlose Dokumentation der Ergebnisse, die über Wochen hinweg konsistent bleibt, und keine heroischen Debugging-Sitzungen.

Konfigurieren Sie die HIL hardware I/O und Sicherheitsverriegelungen.

Tests , wenn I/O wie ein Produkt konstruiert und nicht wie ein Prototyp verdrahtet I/O . Ordnen Sie jeder Ein- und Ausgabe Bereiche, Skalierungen und Zeitvorgaben zu und überprüfen Sie dann, ob der Simulator, I/O und der Controller übereinstimmen. Fügen Sie eine Signalaufbereitung hinzu, damit Ihr Controller realistische Spannungen, Ströme und Encoder-Muster erkennt. Sicherheitsverriegelungen müssen immer Vorrang vor der Testkomfortabilität haben.

Eine praktische Konfiguration könnte einen Wechselrichter-Controller mit analoger Stromrückmeldung, Resolver-Eingängen, diskreten Gate-Disable-Leitungen und einer CAN-Befehlsschnittstelle kombinieren und diese dann durch geeignete Isolierung und Skalierung leiten, damit Fehlerzustände begrenzt bleiben. Diese einzelne Anlage zwingt Sie dazu, Details zu validieren, die SIL nicht validieren kann, z. B. was passiert, wenn ein analoger Kanal gesättigt ist, eine diskrete Leitung flackert oder eine Busnachricht zu spät eintrifft. Außerdem muss klar festgelegt werden, wer Ausgänge aktivieren, wer Fehler beheben kann und was nach einem Stopp der sichere Zustand ist. Das sind technische Entscheidungen, keine trivialen Fragen der Verkabelung.

Verriegelungen sollten mehrschichtig sein. Hardware , Watchdogs und Ausgangs-Sperrlogik sollten auch dann funktionieren, wenn der Host-PC abstürzt, und Ihre Testskripte sollten niemals die einzige Sicherheitsvorkehrung sein. Behandeln Sie jede Änderung an Anschlüssen und Pinbelegungen als Konfigurationselement, da versehentliche Fehlskalierungen wie ein Steuerungsfehler aussehen können. Der schnellste Weg zu zuverlässigen Ergebnissen ist I/O strenge I/O und ein Sicherheitsplan, der sich niemals auf Hoffnung verlässt.

Optimieren Sie die Echtzeitleistung mit Solver-Schrittweite und FPGA.

Echtzeitleistung ist die Fähigkeit, jeden Simulationsschritt jedes Mal pünktlich abzuschließen und dabei das numerische Verhalten stabil zu halten. Die Wahl der Schrittweite legt die Obergrenze dafür fest, welche Dynamiken Sie darstellen und wie genau Sie das Timing emulieren können. Die Auswahl des Solvers, die Modellaufteilung und I/O entscheiden darüber, ob Sie Termine ohne Verzögerungen einhalten können. FPGA-Ressourcen sind wichtig, wenn Determinismus im Submillisekundenbereich und hohe I/O erforderlich I/O .

Beginnen Sie mit den Anforderungen an den Regelkreis und arbeiten Sie sich dann rückwärts zur erforderlichen Anlagenpräzision vor, um dieselbe Regelungsentscheidung zu treffen. Wenn das Anlagenmodell einen kleineren Schritt erfordert, als Ihr Rechenziel unterstützen kann, reduzieren Sie die Steifigkeit, vereinfachen Sie die Schaltdetails oder verlagern Sie die engsten Teile auf FPGA. Behalten Sie den gesamten Regelkreis im Auge, da schnelle analoge I/O, Encoder-Decodierung und Bus-Stacks alle um Zeit konkurrieren. Determinismus ist die entscheidende Kennzahl, da gelegentliche Überschreitungen die Fehlerlogik zufällig erscheinen lassen.

Die Leistungsoptimierung sollte transparent bleiben. Verfolgen Sie die Ausführungszeit der Schritte, Jitter und verlorene Frames als erstklassige Testergebnisse und nicht als versteckte Diagnosedaten. Partitionierungsentscheidungen sollten dokumentiert werden, damit bei einer späteren Modellaktualisierung nicht unbemerkt Arbeit auf die CPU verlagert wird und das Timing gestört wird. Sobald das Timing stabil ist, sperren Sie die Schlüsseleinstellungen und behandeln Sie Änderungen als kontrollierte Experimente mit messbaren Auswirkungen.

Erstellen Sie wiederholbare Testfälle für die Fehlerinjektion und Ergebnisüberprüfungen.

Wiederholbare Testfälle machen HIL und SIL von Demos zu Validierungsnachweisen. Jeder Fall sollte Ausgangsbedingungen, Eingangsstimuli, erwartete Ergebnisse und explizite Toleranzen festlegen und anschließend die Ergebnisse speichern, damit Vergleiche zwischen verschiedenen Builds aussagekräftig sind. Die Fehlerinjektion gehört hierher, da elektrifizierte Steuerungen stark danach beurteilt werden, wie sie ausfallen. Die Ergebnisüberprüfungen sollten sich auf Trends und Regressionen konzentrieren, nicht auf einmalige Plots.

Eine gute Fehlerinjektion ist spezifisch und begrenzt. Injizieren Sie Sensor-Bias, Stuck-at-Werte, Bus-Timeouts und Aktuator-Deaktivierungsereignisse zu genau festgelegten Zeitpunkten und überprüfen Sie anschließend, ob der Controller ohne unsichere Ausgaben die erwarteten Zustände durchläuft. Kombinieren Sie diese Überprüfungen mit klaren Akzeptanzregeln, damit sich die Teams nicht mehr darüber streiten müssen, was „sieht gut aus“ bedeutet. Speichern Sie die genaue Modellversion und den Parametersatz für jeden Durchlauf, da Kalibrierungsabweichungen als Logikabweichungen getarnt sein können.

Disziplin ist das Unterscheidungsmerkmal im Laufe der Zeit. Teams, die Tests wie Code behandeln, Änderungen überprüfen und Baselines sauber halten, werden weniger späte Überraschungen erleben als Teams, die Ad-hoc-Fehler verfolgen. OPAL-RT eignet sich am besten, wenn es diese Disziplin durch wiederholbare Ausführung und nachvollziehbare Ergebnisse unterstützt, und nicht, wenn es als einmalige Laboranschaffung behandelt wird. Vertrauen entsteht durch konsistente Beweise, und konsistente Beweise entstehen durch die Kontrolle der Details, die Sie kontrollieren können.