SIL- und Tests die Leistungselektronik und wann welche Methode zum Einsatz kommt

Wichtigste Erkenntnisse

• • SIL sollte Ihren Arbeitsablauf bestimmen, solange die Regelungslogik und die Annahmen zur Anlage noch nicht feststehen.

• • HIL macht sich bezahlt, wenn das Timing, die Skalierung und das Schutzverhalten auf physischer Hardware zum Hauptrisiko werden.

• • Einheitliche Modelle, Tests und Grenzwerte sind es, die SIL und HIL zu einem einheitlichen Validierungsansatz machen.

Bei der Entwicklung von Steuerungen für die Leistungselektronik sollte zunächst SIL zum Einsatz kommen, und HIL sollte folgen, sobald das Timing und die Genauigkeit der Ein- und Ausgänge eine Rolle spielen.

In den Vereinigten Staaten werden mehr als 80 % des Stroms durch Leistungselektronik verarbeitet und gesteuert, was verdeutlicht, wie sehr alles von einem stabilen Regelverhalten und fundierten Validierungsentscheidungen abhängt. Sie erzielen bessere Ergebnisse, wenn Sie Software-in-the-Loop als Ort betrachten, an dem die Regelungslogik frühzeitig auf Herz und Nieren geprüft wird, und Hardware-in-the-Loop als Ort, an dem die Implementierungsdetails anhand physikalischer Schnittstellen überprüft werden. Diese Abfolge sorgt dafür, dass Fehler sichtbar bleiben, während Ihre Modelle noch leicht zu bearbeiten sind. Außerdem verringert sie das Risiko späterer Überraschungen, sobald der Code Sensoren, PWM-Ausgänge und Schutzsignale erreicht.

„Der beste Übergang von SIL zu HIL gewährleistet, dass die Testziele, die Grenzwerte und die grundlegenden Annahmen zur Anlage in beiden Phasen unverändert bleiben.“

SIL versus HIL legt die Testgrenzen fest

Der Hauptunterschied zwischen SIL- und Tests liegt in der Anordnung von Regler und Regelobjekt während des Tests. Bei Software-in-the-Loop befinden sich der Reglercode und das Regelobjektmodell innerhalb der Simulation, während Tests die Reglerhardware physisch Tests und das Regelobjekt simuliert bleibt. Diese Abgrenzung entscheidet darüber, welche Fehler das Setup zuverlässig aufdecken kann.

Ein digitaler Stromregelkreis für einen Aufwärtswandler verdeutlicht den Unterschied. SIL zeigt, ob sich PI-Verstärkungen, Grenzwerte und Fehlerzustände über verschiedene Betriebspunkte hinweg korrekt verhalten. HIL zeigt, ob sich die ADC-Skalierung, das PWM-Timing und die Verdrahtung der Fehlerpins weiterhin korrekt verhalten, sobald die Steuerplatine den Code ausführt. Jede Methode beantwortet eine andere Testfrage.

SIL erkennt Fehler in der Steuerungslogik, noch bevor die Hardware vorhanden ist

SIL ist der ideale Ansatz, um eingebettete Steuerungslogik zu validieren, bevor die Hardware verfügbar ist, da es die Steuerungszustände sichtbar macht und deren Test kostengünstig ermöglicht. Sie können den kompilierten Steuerungscode oder eine gleichwertige Software-Darstellung an einem Anlagenmodell ausführen und Fehler erkennen, solange die Kosten für Änderungen noch gering sind.

Ein dreiphasiger Wechselrichter-Controller verdeutlicht, warum dies wichtig ist. Sie können die Stromregelung, die Überwachung des Zwischenkreises, den Anti-Windup-Schutz sowie die Übergangsregeln zwischen Start-, Betriebs- und Fehlerzuständen testen, ohne auf eine Steuerplatine warten zu müssen. Sollte der Modulator während eines Spannungseinbruchs in Sättigung geraten, sehen Sie die Abfolge der Ereignisse, die dazu geführt hat. Diese Klarheit hilft Ihnen dabei, die Logik zu korrigieren, anstatt aufgrund eines fehlgeschlagenen Labortests Vermutungen anzustellen.

Mangelhafte Softwarequalität hat die US-Wirtschaft im Jahr 2022 mindestens 2,41 Billionen Dollar gekostet. Diese Zahl umfasst zwar weit mehr als nur die Leistungselektronik, doch die Erkenntnis gilt dennoch. Spät auftretende Fehler sind kostspielig, da sie Softwarefehler mit Hardware-Unsicherheiten vermischen. SIL trennt diese Probleme frühzeitig voneinander, sodass Sie keine Zeit damit verschwenden müssen, einem Steuerungsfehler anhand einer Oszilloskopkurve nachzugehen.

HIL überprüft das Zeitverhalten anhand physikalischer Schnittstellen

HIL ist wichtig, wenn Sie nachweisen müssen, dass sich der implementierte Controller unter Berücksichtigung der tatsächlichen Hardware-Timings und der tatsächlichen E/A-Pfade korrekt verhält. Es deckt Probleme auf, die durch Simulation allein nicht eindeutig erkennbar sind, wie beispielsweise Abtastjitter, Interrupt-Latenz, ADC-Quantisierungseffekte, PWM-Aktualisierungszeiten und die Behandlung von Hardwarefehlern an den Eingängen.

Ein bidirektionaler DC/DC-Wandler ist ein typisches Beispiel. Das Regelverfahren mag in der SIL-Simulation perfekt aussehen, doch der physikalische Regler könnte den Strom zu nahe an einer Schaltflanke abtasten und verrauschte Werte in den Regelkreis einspeisen. Dieses Problem äußert sich in Form von Grenzwertschwankungen, instabilen Tastgradbefehlen oder Fehlauslösungen. Bei HIL wird die Reglerplatine selbst getestet, sodass diese Schnittstellendetails nicht länger verborgen bleiben.

Sie sollten HIL als Nachweis für das Verhaltensverhalten betrachten und nicht als Ersatz für eine fundierte Anlagenmodellierung. Ein unzureichendes Anlagenmodell führt Sie nach wie vor in die Irre, und selbst ein guter Regler kann versagen, wenn Skalierung, Zeitablauf oder Schutzlogik nur geringfügig abweichen. HIL hat dann seine Berechtigung, wenn die verbleibenden Risiken in den physikalischen Ausführungsdetails liegen.

Setzen Sie SIL zunächst ein, solange das Risiko für die Anlage noch hoch ist

Setzen Sie SIL zunächst ein, wenn Sie noch dabei sind, Annahmen zu den Anlagenkomponenten, Betriebsmodi und der Reglerstruktur festzulegen. Bei den ersten Arbeiten an der Leistungselektronik bestehen in der Regel große Unsicherheiten hinsichtlich parasitärer Effekte, Betriebsgrenzen und Fehlerszenarien, sodass eine flexible simulierte Schnittstelle Ihnen mehr Nutzen bringt als eine sofortige Hardwareanbindung.

Ein netzgekoppelter Wechselrichter mit LCL-Filter ist ein gutes Beispiel. Filterresonanz, Schwankungen der Netzimpedanz, PLL-Abstimmung und das Verhalten des Strombegrenzers müssen alle berücksichtigt werden, bevor das Hardware-Timing zum Hauptanliegen wird. In SIL können Sie Netzbedingungen, Zwischenkreispegel und Fehlerfälle schnell durchspielen. So lässt sich erkennen, welche Regelungsoptionen robust sind und welche nur unter engen Annahmen funktionieren.

In dieser Phase erhalten Sie zudem ein besseres Modell des Regelobjekts. Totzeit, Sensorverzögerung, Sättigung und Schaltwelligkeit können schrittweise und nicht auf einmal hinzugefügt werden. Durch diesen schrittweisen Ansatz bleiben Ursache und Wirkung übersichtlich. Sobald das Risiko des Regelobjekts sinkt und sich die Regelalgorithmuslogik nicht mehr wöchentlich ändert, ist HIL der nächste sinnvolle Schritt.

Wechseln Sie zu HIL, wenn das Timing der Ein- und Ausgänge kritisch wird

Wechseln Sie zu HIL, sobald die verbleibenden Fragen den Ausführungszeitpunkt, die I/O-Genauigkeit und das Fehlerverhalten auf der eigentlichen Steuerungshardware betreffen. Dieser Zeitpunkt ist erreicht, sobald sich die Steuerungslogik so weit stabilisiert hat, dass neue Fehler eher auf Implementierungsdetails zurückzuführen sind als auf fehlende Gleichungen oder eine mangelhafte Zustandslogik.

Es gibt in der Regel einige Anzeichen dafür, dass Sie bereit für diesen Schritt sind:

• • Das Regelgesetz ändert sich nicht mehr alle paar Tage.

• • Ob man besteht oder durchfällt, hängt nun vom Timing der Unterbrechung ab.

• • Die Schutzschaltungen müssen durch physische Stifte überprüft werden.

• • Fehler bei der Sensorskalierung können die Regelkreisstabilität beeinträchtigen.

• • Die Abfolge der Start- und Abschaltvorgänge muss hardwareseitig nachgewiesen werden.

Eine Motorsteuerung erreicht diesen Punkt oft, nachdem sich die grundlegenden Drehzahl- und Stromregelkreise im SIL-Modus stabilisiert haben. Die Abfolge der Einschaltschütze, die Verarbeitung von Entsättigungssignalen und das Timing der Encoder-Erfassung stellen dann die größten Herausforderungen dar. HIL bietet Ihnen eine sichere Möglichkeit, diese Abläufe zu testen, ohne eine Vollleistungsstufe zu gefährden. Genau dann zahlt sich dieser Schritt aus.

Ein stufenweiser Arbeitsablauf verknüpft SIL-Ergebnisse mit HIL-Ergebnissen

Der beste Übergang von SIL zu HIL besteht darin, die Testziele, die Grenzwerte für das Bestehen der Tests und die grundlegenden Annahmen zur Anlage in beiden Phasen beizubehalten. Sie sollten HIL nicht als Neuanfang betrachten. Am besten funktioniert es, wenn die Szenarien übernommen werden, die sich bereits in SIL bewährt haben, und diese dann durch Implementierungsprüfungen ergänzt werden.

Ein praktischer Arbeitsablauf für einen Laderegler beginnt mit der Anlagenvalidierung und der Regelungsoptimierung im SIL-Umfeld. Derselbe Testablauf wird anschließend mit festgelegten Grenzwerten für Überschwingen, Einschwingzeit, Fehlerbehebung und Moduswechsel fortgesetzt. Im HIL-Umfeld kommen Prüfungen der ADC-Zuordnung, des Zeitablaufs der diskreten Eingänge, der PWM-Skalierung und der Watchdog-Verarbeitung hinzu. Diese Kontinuität erleichtert den Vergleich der Ergebnisse erheblich.

Teams verlieren Zeit, wenn sich Namen, Signale oder Testschwellenwerte zwischen den einzelnen Phasen ändern. Es ist wünschenswert, dass dieselben Betriebszustände, dieselben Fehlerfälle und dieselben erwarteten Reaktionen durch den gesamten Arbeitsablauf hindurch beibehalten werden. Wenn ein bestandener Test in der SIL-Phase zu einem Fehlschlag in der HIL-Phase führt, lässt sich die Ursache für die Abweichung viel leichter ausfindig machen. Auf diese Weise spart ein stufenweiser Arbeitsablauf Aufwand, anstatt den Prozess unnötig zu verkomplizieren.

Modellbasiertes Design schafft Vertrauen durch übereinstimmende Annahmen

SIL und HIL eignen sich nur dann für den modellbasierten Entwurf, wenn die Annahmen über Anlage, Regler und Testlogik hinweg übereinstimmen. Wenn sich die Modellgenauigkeit, die Signalskalierung oder die Schnittstellendefinitionen zwischen den einzelnen Phasen verschieben, sinkt das Vertrauen schnell, da sich die Ergebnisse der einzelnen Durchläufe auf ein unterschiedliches Systembild beziehen.

Ein transparenter Modellierungsansatz ist hier hilfreich. SPS SOFTWARE eignet sich für diese Aufgabe, wenn Sie Anlagenmodelle benötigen, die Ingenieure einsehen, bearbeiten und in einen Validierungsablauf für Steuerungen einbinden können, ohne dass die Gleichungen verborgen bleiben. Eine Konvertierungsstudie in einem akademischen Labor oder einem F&E-Team kann dieselbe Anlagenstruktur für frühe SIL-Läufe und die spätere HIL-Vorbereitung nutzen. Diese Kontinuität sorgt dafür, dass sich die technischen Diskussionen auf das Verhalten konzentrieren, anstatt auf die Undurchsichtigkeit der Werkzeuge.

Übereinstimmende Annahmen bedeuten nicht, dass Modelle unveränderlich sind. Sie sollten Verlustterme, Sensorgrenzen und Schaltdetails verfeinern, sobald sich die Erkenntnisse verbessern. Entscheidend ist, dass jede Verfeinerung nachvollziehbar bleibt und für das Team sichtbar ist. Modellbasiertes Design schafft Vertrauen, wenn die Modellherkunft klar ist und die Testgrenzen bewusst festgelegt bleiben.

 „Bei Software-in-the-Loop verbleiben der Reglercode und das Anlagenmodell in der Simulation, während Tests Hardware-in-the-Loop Tests die Reglerhardware physisch Tests und die Anlage simuliert bleibt.“

Unzureichende Testgrenzen führen zu irreführenden Ergebnissen

Testergebnisse können irreführend sein, wenn die gewählte Testgrenze den Fehlermechanismus verdeckt, den man eigentlich aufdecken möchte. Bei SIL kann das System einwandfrei erscheinen, obwohl das physikalische Timing nicht stimmt, und bei HIL kann das System stabil wirken, obwohl das Anlagenmodell zu einfach ist, um den Regler angemessen zu belasten. Eine gute Validierung entsteht dadurch, dass die Testgrenze auf das tatsächliche Risiko abgestimmt wird.

Ein Umrichter, der alle SIL-Tests besteht, kann dennoch an der Hardware ausfallen, wenn der Überstromsignal ein paar Mikrosekunden später eintrifft, als von der Logik angenommen. Ein Regler, der den HIL-Test besteht, kann dennoch an der Leistungsstufe versagen, wenn die simulierte Anlage Sättigung oder Resonanz ignoriert hat, die den Betrieb dominieren. Das sind keine kleinen Fehler. Sie entstehen dadurch, dass man die falsche Konfiguration bittet, die falsche Frage zu beantworten.

Sie entwickeln ein sichereres technisches Urteilsvermögen, wenn jede Phase einen klar abgegrenzten Aufgabenbereich und eine eindeutige Übergabe umfasst. Bei SIL sollte die Logik frühzeitig validiert werden. Bei HIL sollten die Ausführungsdetails vor der vollständigen Systemintegration überprüft werden. Diese Vorgehensweise ist sinnvoller als die Suche nach einem einzigen Prüfstand, und genau diese Denkweise unterstützt SPS SOFTWARE, wenn Teams physikbasierte Modelle benötigen, die vom ersten Konzept bis zur abschließenden Validierung nachvollziehbar bleiben.