5 Wege, wie die Controller- Hardware -in-the-Loop-Methode und modellbasiertes Engineering Risiken reduzieren

Wichtigste Erkenntnisse

• Die Einbindung des Controllers „ hardware “ in den Regelkreis senkt das Risiko am schnellsten, wenn Sie sich auf Fehler im geschlossenen Regelkreis konzentrieren, die in der Regel erst in einer späten Entwicklungsphase auftreten.
• Modellbasiertes Engineering schafft einen Mehrwert, wenn Anforderungen, Tests und Änderungen am Regler miteinander verknüpft und wiederholbar bleiben.
• Der beste Ausgangspunkt für C-HIL ist eine eng gefasste, wirkungsvolle Kontrollfunktion mit messbaren Bestehenskriterien und stabilen Bedingungen für die Wiederholung.

Die Einbindung des Controllers „ hardware “ in den Regelkreis verringert das Risiko, indem Kontrollfehler aufgedeckt werden, solange deren Behebung noch kostengünstig ist.

Diese Verlagerung ist von Bedeutung, da die kostspieligsten Regelungsprobleme selten erst auf dem Prüfstand auftreten. Sie beginnen viel früher, nämlich bereits dann, wenn Annahmen zum Zeitverhalten, zum Anlagenverhalten und zu Schnittstellendetails noch in Modellen und frühen Versionen von „ software “ enthalten sind. Bei der „Controller- hardware -in-the-Loop“-Methode, oft abgekürzt als C-HIL, wird der eigentliche Regler in einen geschlossenen Regelkreis mit einer simulierten Anlage eingebunden, sodass Sie die Reaktionen testen können, bevor Motoren, Umrichter, Fahrzeuge oder Netzkomponenten bereitstehen. Kombiniert man diesen Ansatz mit modellbasiertem Engineering, verlagert man die risikoreichsten Prüfschritte im V-Modell nach vorne und verhindert so, dass späte Überraschungen zu Terminverzögerungen führen.

Der Controller „ hardware “ im Loop testet die Controller, bevor „ hardware “ existiert.

„Controller- hardware -in-the-Loop“ verbindet einen physischen Regler mit einer simulierten Anlage und lässt diesen Regelkreis unter realistischen Zeitbedingungen laufen. C-HIL reduziert das Risiko, da der Regler glaubwürdige Eingangsgrößen erhält und seine Ausgangsgrößen eine Live-Simulation beeinflussen. Sie erhalten frühzeitig Erkenntnisse über das Verhalten. Sie beheben Fehler, bevor die Prototyp hardware -Phase Kosten und Verzögerungen festschreibt.

Ein Wechselrichter-Regler ist ein anschauliches Beispiel. Sie können die Produktionssteuerplatine an einen simulierten Motor und einen Gleichstrombus anschließen und dann Drehmomentbefehle, Strombegrenzungen und Fehlerzustände bei Beschleunigung, Rekuperation und Unterspannungsereignissen beobachten. Das gleiche Verfahren funktioniert auch bei einem Schutzrelais, einem Flugsteuerungscomputer oder einer Batteriemanagementeinheit. In jedem Fall erhalten Sie frühzeitig Einblicke in das Regelverhalten, weshalb die „In-the-Loop“- hardware -Regler innerhalb modellbasierter Entwicklungsabläufe so wertvoll ist.

„C-HIL verringert das Risiko, da der Regler zuverlässige Eingangsdaten erhält und seine Ausgangssignale Auswirkungen auf eine Live-Simulation haben.“

5 Wege, wie C-HIL im Rahmen des modellbasierten Engineerings Risiken mindert

C-HIL senkt das Risiko am effektivsten, wenn Sie es gezielt auf jene Fehlerarten anwenden, die in der Regel erst spät auftreten und deren Diagnose die höchsten Kosten verursacht. Diese Fehlerarten lassen sich in sechs praktische Gruppen einteilen. Jede davon steht in Zusammenhang mit einem gängigen Kontrollproblem. Die Behebung jedes einzelnen Fehlers wird kostengünstiger, wenn Sie ihn noch vor der Integration auf dem Prüfstand erkennen.

1. Virtuelle Anlagenmodelle decken instabile Regelungslogik bereits vor der Prototypenphase auf

Mit virtuellen Anlagenmodellen können Sie den eigentlichen Regler schon lange vor der Erstellung eines Prototyps anhand des dynamischen Verhaltens testen. Das ist wichtig, da instabile Verstärkungen, schlechte Zeitplanung und schwache Moduslogik bei der Codeüberprüfung meist verborgen bleiben. Ein Regler für einen Traktionswechselrichter kann beispielsweise in einer Desktop-Simulation korrekt erscheinen, aber zu Schwingungen neigen, wenn die simulierte Motorträgheit, die Buswelligkeit und die Sensorverzögerung im geschlossenen Regelkreis angewendet werden. Es kommt zu Überschwingen, Integrator-Windup oder Grenzzyklen, während die Abhilfe noch in einer Parameteraktualisierung oder einer Änderung der Zustandsmaschine besteht. Diese frühzeitige Einsicht zwingt zudem zu einer besseren Modelldisziplin, da die Annahmen zum Regelkreis explizit genug sein müssen, um einen Test zu unterstützen, dem Sie vertrauen können.

2. Durch Fehlerinjektion lassen sich unsichere Reaktionen unter seltenen Betriebsbedingungen aufdecken

Die Fehlerinjektion zeigt, wie sich der Regler verhält, wenn Eingaben keinen Sinn mehr ergeben oder die Zustände des Regelobjekts außerhalb der Nenngrenzen liegen. Diese Tests verringern das Risiko, da seltene Fehler auf physikalischen hardware nur schwer sicher reproduzierbar sind, dabei jedoch oft die schwächsten Stellen in der Wiederherstellungslogik aufdecken. Ein Batterieregler, der mit einem hängengebliebenen Temperatursensor, einer Unterspannungssituation oder einem ausgefallenen Kommunikationsframe konfrontiert wird, zeigt, ob er die Leistung ordnungsgemäß drosselt, den richtigen Code speichert und in der vorgesehenen Reihenfolge wiederhergestellt wird. Sie überprüfen nicht nur, ob ein Fehler erkannt wird. Sie stellen sicher, dass die Reaktion nach dem Auftreten des ersten Fehlers innerhalb festgelegter Grenzen bleibt, nachvollziehbar ist und für das restliche System keine Gefahr darstellt.

3. Timing-Tests erkennen Latenzschwankungen noch vor der Integration in die Testumgebung

Timing-Fehler sind Steuerungsfehler, und C-HIL macht sie sichtbar, solange das System noch leicht zu überprüfen ist. Die Ausführung im geschlossenen Regelkreis deckt versäumte Fristen, variable Aufgabenlatenzen und Abweichungen bei der „ I/O “ auf, die bei einer statischen Modellprüfung nicht erkennbar wären. Eine Motorsteuereinheit berechnet zwar möglicherweise den richtigen Tastgrad, doch eine verzögerte PWM-Aktualisierung oder ein verrauschter Zeitstempel können die Stromregelung dennoch außerhalb der Toleranzgrenzen bringen. Teams, die OPAL-RT einsetzen, führen diese Tests häufig mit deterministischer Anlagenausführung durch, damit das Timing des Reglers unter wiederholbaren Lastbedingungen gemessen werden kann. Dies ist wichtig, da so Probleme in der Logik der „ software “ von Problemen beim Ausführungszeitpunkt getrennt werden, bevor sie sich zu einem verwirrenden Testfehler vermischen.

„Timing-Fehler sind Steuerungsfehler, und C-HIL macht sie sichtbar, solange das System noch leicht zu überprüfen ist.“

4. Durch modellbasiertes Engineering bleiben die Anforderungen über jede Überarbeitung hinweg nachvollziehbar

Modellbasiertes Engineering verringert das Risiko, wenn jede Steuerungsanforderung mit dem Modellelement, dem Testfall und dem beobachteten Ergebnis verknüpft bleibt. Diese Rückverfolgbarkeit ist wichtig, sobald sich die Überarbeitungen häufen und niemand mehr weiß, welche Annahme sich zuerst geändert hat. Eine Anforderung an einen Geschwindigkeitsbegrenzer sollte beispielsweise mit der Zustandslogik, den Schwellenwerten und dem C-HIL-Test verknüpft bleiben, der nachweist, dass der Begrenzer innerhalb der zulässigen Zeit anspricht. Wenn sich der Schwellenwert nach einer Sicherheitsüberprüfung verschiebt, können Sie den verknüpften Test erneut ausführen und die Auswirkung sofort überprüfen. Sie müssen nicht raten, welche Tabelle, welches Skript oder welcher „ software “-Zweig noch die aktuelle Steuerungsabsicht widerspiegelt.

5. Regressions Tests -Flagge „ software -Drift“ nach jeder Regleraktualisierung

Regressions Tests en senken das Risiko, da die Steuer software e selten an offensichtlichen Stellen ausfallen. Geringfügige Änderungen an Filtern, der Anti-Windup-Logik, Kalibrierungstabellen oder der Startabfolge können das Verhalten weit entfernt von dem geänderten Code-Block verändern. Eine Aktualisierung der Strombegrenzung bei einem elektrischen Antrieb kann beispielsweise die Fehlerbehebungszeit oder die Drehmomentantwort während eines Spannungsabfalls verändern, selbst wenn der neue Code einen Smoke-Test auf dem Prüfstand besteht. C-HIL bietet Ihnen wiederholbare Closed-Loop-Szenarien, die nach jedem Build ausgeführt werden können, sodass Abweichungen bei der „ software “ als messbare Abweichung erkannt werden und nicht erst als kostspielige Überraschung auftreten. Diese Vorgehensweise hilft Teams zudem dabei, Revisionen unter denselben Anlagenbedingungen und anhand derselben Erfolgskriterien zu vergleichen.

Wo sollte man mit C-HIL beginnen, um das Risiko am stärksten zu senken?

Beginnen Sie mit der Reglerfunktion, deren Ausfall die größten Auswirkungen auf Sicherheit, Leistung oder Zeitplan hat. Sie benötigen nicht unbedingt zunächst ein perfektes Anlagenmodell. Sie benötigen einen zuverlässigen Regelkreis um die Funktion herum, die am ehesten zu Nacharbeiten führen kann. Das ist der schnellste Weg zu einer sinnvollen Risikominderung.

Ein guter Ausgangspunkt ist die minimalistische Konfiguration, mit der sich ein Fehler reproduzieren lässt, den man auf keinen Fall übersehen darf – beispielsweise die Stromregelung bei einem Wechselrichter, die Fehlerbehebung bei einem Relais oder die Drehmomentverteilung in einem Fahrzeugregler. Teams, die mit OPAL-RT arbeiten, erzielen oft bessere Ergebnisse, wenn sie C-HIL als Teil der modellbasierten Entwicklungsdisziplin betrachten und nicht als eine erst spät im Labor durchgeführte Aufgabe. Der Nutzen ergibt sich aus der Wahl strenger Bestehenskriterien, der Gewährleistung der Wiederholbarkeit der Tests und der Erweiterung des Umfangs erst dann, wenn die erste Schleife stabil ist.

• Wählen Sie einen Regelkreis aus, der deutliche Auswirkungen auf das Projekt hat.
• Legen Sie frühzeitig messbare Schwellenwerte für „bestanden“ und „nicht bestanden“ fest.
• Modellieren Sie nur die Anlagendynamiken, die diesen Regelkreis beeinflussen.
• Automatisiere die Wiederholung nach jeder Änderung an „ software “.
• Bewährte Tests unverändert in spätere Laborphasen übernehmen.