Unterschiede zwischen PHIL und CHIL bei Echtzeit-Validierungsabläufen

Wichtigste Erkenntnisse

• CHIL sollte zum Einsatz kommen, wenn der Controller noch weitgehend unbekannt ist und Sie einen sicheren, wiederholbaren Nachweis der Logik und des Timings benötigen.
• PHIL ist die richtige Methode, sobald das Verhalten der physikalischen Leistung, die Messung, Verluste oder der Zeitpunkt der Schutzauslösung das Validierungsergebnis beeinflussen können.
• Die Schnittstellenstabilität und elektrische Risiken setzen PHIL praktische Grenzen, weshalb eine schrittweise Umsetzung einer auf Akronymen basierenden Auswahl vorzuziehen ist.

Entscheiden Sie sich für hardware , wenn Sie die Regelungslogik nachweisen müssen, und für hardware , wenn die physikalische Leistungsstufe selbst das Ergebnis beeinflussen kann.

Der Absatz von Elektroautos überstieg im Jahr 2024 die 17-Millionen-Marke, was bedeutet, dass immer mehr Wandler, Batteriesysteme und Leistungssteuerungen in Testlabore gelangen, wobei kaum noch Spielraum für späte Überraschungen bleibt. Dieses Wachstum erhöht den Druck auf Validierungsabläufe, software frühzeitig von hardware zu unterscheiden. Teams, die PHIL und CHIL als austauschbar betrachten, verlieren später meist Zeit. Sie erhalten klarere Antworten, wenn Sie die Methode auf den Teil des Systems abstimmen, der Sie noch überraschen kann.

CHIL ist für die meisten Regelungsaufgaben der richtige erste Schritt, da es sicherer, kostengünstiger und leichter zu wiederholen ist. PHIL lohnt sich erst dann trotz des zusätzlichen Aufwands, wenn hardware, Sensorik, Verluste oder das Verhalten der Schutzvorrichtungen das Ergebnis beeinflussen können. Diese Reihenfolge ist wichtiger als das Akronym. Ein disziplinierter Arbeitsablauf führt vom Nachweis der Reglerfunktion zum Nachweis der Wechselwirkung mit der Leistungsversorgung, wobei jede Phase eine andere Validierungsfrage beantwortet.

In vielen Testlabors wird „Controller HIL“ üblicherweise als „CHIL“ bezeichnet

hardware bedeutet in der Regel, dass der Regler physisch vorhanden ist, während das Anlagenmodell in einem Echtzeit-Simulator läuft. Diese Konfiguration wird als CHIL bezeichnet. Man verbindet die I/O des Reglers I/O einem simulierten Motor-, Umrichter-, Batterie- oder Netzmodell und überprüft Logik, Timing, Grenzwerte und Fehlerbehandlung, ohne hardware physische hardware mit Strom zu versorgen.

Ein Team für Antriebsumrichter veranschaulicht das Muster anschaulich. Die Steuerplatine erhält vom Simulator Resolver-Rückmeldungen, Strombegrenzungen und Schwankungen des Gleichstrombusses, während Umrichter, Motor und Batterie als digitale Modelle dargestellt werden. Sie können in jedem Testzyklus Überstrom, Sensorausfälle oder Netzstörungen simulieren und überprüfen, ob der Code im richtigen Moment reagiert. Die Rücksetzzeit bleibt kurz, sodass die Fehlersuche zielgerichtet bleibt.

Genau diese Wiederholbarkeit ist der Grund, warum CHIL bereits in einer frühen Phase der Validierung zum Einsatz kommen sollte. So lassen sich Abstimmungsfehler, Fehler in der Zustandsmaschine und Probleme I/O erkennen, noch bevor der Leistungsstapel fertiggestellt ist. Außerdem können Sie Fehler des Reglers von Unsicherheiten im Regelkreis unterscheiden, was die Ermittlung der Grundursache erheblich beschleunigt. Da CHIL keine Erwärmung, Schaltunvollkommenheiten oder Komponententoleranzen anzeigt, ist sein Nutzen sehr spezifisch und äußerst groß.

„Der Hauptunterschied zwischen PHIL und CHIL liegt in der Anordnung der Leistungsstufe.“

Bei PHIL gegen CHIL kommt es darauf an, wer körperlich die Oberhand behält

Der Hauptunterschied zwischen PHIL und CHIL liegt in der Anordnung der Leistungsstufe. Bei CHIL verbleibt die Anlage im Simulator, und I/O Regler werden lediglich I/O mit geringer Leistung I/O . Bei PHIL wird hardware eigentliche hardware eine Leistungsschnittstelle eingebunden, sodass Spannung, Strom und hardware Teil des Regelkreises werden.

Ein Ladeprogramm macht die Unterscheidung leicht erkennbar. Wenn nur die Platine des digitalen Signalprozessors an den Simulator angeschlossen ist, arbeiten Sie im CHIL-Modus. Wenn der eigentliche Umrichter über einen Leistungsverstärker und eine gemessene elektrische Rückkopplung eingebunden ist, arbeiten Sie im PHIL-Modus, da die Verluste, Grenzwerte und Schutzzeiten des Umrichters physikalisch erhalten bleiben.

CHIL-Anpassung zur Validierung der Steuerung, bevor hardware einsatzbereit hardware

CHIL eignet sich am besten, wenn der Regler noch unbekannt ist und die hardware noch nicht fertiggestellt, zu teuer oder zu unsicher für die Stromzufuhr hardware . Damit können Sie das Regelzeitverhalten, die Überwachungslogik und die Kommunikation anhand eines hochpräzisen Anlagenmodells validieren, lange bevor der vollständige Prüfstand aufgebaut ist.

Ein typisches Beispiel hierfür ist microgrid . Die Schaltlogik, die Reihenfolge der Leistungsschalter und die Spannungsregelung können bereits Monate vor der Lieferung des Schaltschranks anhand eines digitalen Netzteilmodells überprüft werden. So hat das Steuerungsteam Zeit, die Startreihenfolge, die Begrenzung der Prozessabläufe und das Timing der Meldungen zu optimieren, während die mechanischen Arbeiten und die Beschaffung weiterlaufen. Der Projektfortschritt bleibt auch dann erhalten, wenn sich hardware verzögern.

Diese Reihenfolge bietet mehr Vorteile als der Zeitplan. CHIL sorgt dafür, dass software produktiv bleiben, ohne das Labor zu früh einem hohen Spannungsrisiko auszusetzen. Außerdem erhalten Sie klarere „Bestanden“- oder „Nicht bestanden“-Signale. Wenn ein Regelkreis in CHIL instabil wird, liegt das Problem beim Reglerdesign, sodass Sie nicht zwischen Codefehlern und hardware hin- und hergerissen sind.

PHIL erfasst hardware , die CHIL nicht darstellen kann

PHIL spielt eine Rolle, wenn das Anlagenmodell nicht mehr der begrenzende Faktor ist und die hardware das Ergebnis beeinflussen kann. Physikalische Schaltvorgänge, Sensor-Offset, Totzeit, magnetische Sättigung und Schutzzeitabläufe prägen das Verhalten auf eine Weise, die durch die Einstellung des Reglers allein verdeckt oder geglättet wird.

Ein Batterie-Wechselrichter verdeutlicht dies. Stromwelligkeit, Schaltvorgänge, Messverzögerungen und Bauteil-Toleranzen können die vom Regler wahrgenommene Reaktion verändern, selbst wenn der Regelcode stabil ist. Da erneuerbare Energien bis 2027 voraussichtlich mehr als 95 % des weltweiten Strombedarfswachstums decken werden, müssen netzgebundene Anlagen nun einer Validierung unterzogen werden, die das tatsächliche Leistungsverhalten unter Last einbezieht.

PHIL ist speziell für diese Phase des Arbeitsablaufs konzipiert. Sie schließen den eigentlichen Umrichter oder das zu prüfende Gerät über eine Leistungsschnittstelle an und beobachten, wie hardware die hardware unter simulierten Netz- oder Anlagenbedingungen hardware . Auf diese Weise können Sie vor der Inbetriebnahme Fehlauslösungen, instabile Dämpfung oder Eigenheiten in der Messkette erkennen. PHIL wird erst dann komplexer, wenn die physikalische Leistungsstufe Teil der Fragestellung wird, die Sie klären müssen.

Die Stabilität der Schnittstelle bestimmt die Obergrenze für die PHIL-Wiedergabetreue

Die Genauigkeit der PH-Simulation wird durch die Qualität der Schnittstelle zwischen dem Simulator und der hardware begrenzt. Verzögerungen, die Bandbreite der Verstärker, die Latenz der Sensoren, Skalierungsfehler und die Wahl der Kompensationsverfahren beeinflussen das Regelverhalten. Ist diese Schnittstelle schlecht abgestimmt, verursacht der Prüfstand Probleme, die bei der hardware nicht auftreten.

Ein DC/DC-Wandler-Regelkreis kann perfekt erscheinen, bis eine Verzögerung von 150 Mikrosekunden zwischen der simulierten Quellenimpedanz und der gemessenen Stromrückkopplung auftritt. Kommt dann noch ein langsamer Verstärker oder ein aggressiver Schnittstellenalgorithmus hinzu, schwingt der Regelkreis in Schwingungen, obwohl die Wandlersteuerung einwandfrei funktioniert. Die PHIL-Genauigkeit steht immer hinter dem Schnittstellendesign. Diese eine Tatsache erklärt viele fehlgeschlagene erste Versuche.

Sie müssen die Bandbreite des Verstärkers, die Latenz des Sensors, die Skalierung und die Kompensation als Teil der Methode selbst beurteilen. Ein stabiler Aufbau beginnt oft mit einem vereinfachten Netzwerk, reduzierter Fehlerenergie und sorgfältig abgestimmten Schnittstellenverstärkungen. Teams, die diesen Schritt überspringen, geben häufig dem Prototyp die Schuld für Probleme, die durch den Prüfstand verursacht wurden. CHIL hat diese Belastung nicht, weshalb es der einfachere erste Schritt bleibt.

Oftmals bestimmt das elektrische Risiko die Methode noch vor dem Budget

Elektrotechnische Risiken entscheiden in der Regel schon vor den Kostenkalkulationen darüber, ob PHIL oder CHIL zum Einsatz kommt. Bei CHIL verbleibt der Großteil der Ausfallenergie innerhalb des Simulators, während PHIL mit Strom versorgte hardware einbezieht, hardware innerhalb von Millisekunden ausfallen kann. Sind die Sicherheitsvorkehrungen noch nicht ausgereift, ist die technisch elegante Lösung dennoch die falsche Wahl.

„Die Klangtreue steht beim Design von Benutzeroberflächen immer im Vordergrund.“

Eine Überprüfung eines Schutzrelais in CHIL hat kaum physische Folgen, wenn die Auslöse-Logik fehlerhaft ist. Wendet man dieselbe Logik in PHIL mit einem unter Spannung stehenden Umrichter an, kann der Fehler Fehlerstrom in einen Prototyp leiten, bevor jemand eingreifen kann. Oftmals entscheidet die Sicherheitsplanung früher über die Vorgehensweise als die Budgetprüfung. Teams, die diese Reihenfolge ignorieren, zahlen dafür meist mit Wiederholungsprüfungen und beschädigter hardware.

• Fehlerenergie kann einen Prototyp innerhalb von Millisekunden beschädigen.
• Durch Isolationslücken sind die Bereiche, in denen Sie sicher messen können, eingeschränkt.
• Die Schutzkoordination bestimmt, welche Tests durchgeführt werden können.
• Der Zugang für das Bedienpersonal wird eingeschränkt, sobald die Anlage unter Spannung steht.
• Das Zurücksetzen der Zeit nach einer Auslösung verlangsamt die Iteration erheblich.

Sollten einige dieser Punkte noch ungeklärt sein, verbleibt das Projekt länger in der CHIL-Phase. Der Übergang zur PHIL-Phase lohnt sich nur dann, wenn die unbekannten Faktoren in hardware aktiven hardware liegen und das Labor die Risiken kontrollieren kann. Diese Vorgehensweise verhindert, dass Teams Wochen mit Reparaturen, erneuten Tests und Verzögerungen bei der Freigabe verschwenden. Außerdem schützt sie knappe Prototypen, die nicht schnell ersetzt werden können.

Ein stufenweiser Arbeitsablauf führt die Teams von CHIL nach PHIL

Ein stufenweiser Arbeitsablauf verläuft vom software über den Controller-Test bis hin zum Test der Interaktion unter Last. CHIL sollte zunächst die Regelstabilität, das Timing und die Logik überprüfen. PHIL sollte erst dann beginnen, wenn sich die offenen Fragen auf die unter Last stehende hardware, deren Sensorkette oder deren Interaktion mit der simulierten Anlage konzentrieren.

Ein Motorantriebsprogramm beginnt häufig mit der reinen Modellsteuerung, geht dann über zu CHIL für I/O , die Fehlerlogik und den Überwachungscode und erreicht schließlich PHIL, sobald die Umrichter- oder hardware ausgereift genug hardware , um sicher getestet zu werden. OPAL-RT steht oft in der Mitte dieser Abfolge als Echtzeit-Ausführungsschicht, die Modelle, Schnittstellen und Testskripte aufeinander abstimmt. Diese Art der schrittweisen Umsetzung bietet jedem Team einen klaren Übergabepunkt.

Jeder Übergang erfordert eine Ausstiegsregel. CHIL sollte geschlossen werden, wenn das Steuerungsverhalten sowohl im Normal- als auch im Fehlerfall reproduzierbar ist. PHIL sollte geöffnet werden, wenn offene Fragen sich auf Leistungsverluste, Schutzgrenzen, Erfassungsverzögerungen oder das Zusammenspiel von Komponenten beziehen. Diese stufenweise Vorgehensweise verhindert, dass Teams PHIL als vorzeitige Debugging-Hilfe nutzen, und reserviert den komplexeren Prüfstand für Fragen, die nur dort beantwortet werden können.

Häufige Fehler bei der Auswahl führen zu nachträglichen Nachbesserungen

Späte Nachbesserungen beginnen meist mit einem einfachen Fehler: Teams entscheiden sich aus Gewohnheit für eine Methode, anstatt sich auf das Unbekannte zu konzentrieren, das sie noch beseitigen müssen. CHIL wird Sie enttäuschen, wenn Sie erwarten, dass es die Physik des Wandlers aufdeckt. PHIL wird Zeit verschwenden, wenn die grundlegende Steuerlogik unter sauberen simulierten Fehlern immer noch versagt.

Ein Entwicklerteam, das direkt zu PHIL springt, verbringt oft Wochen damit, Fehler zu beheben, die durch unvollständigen Steuerungscode verursacht werden. Ein Steuerungsteam, das zu lange in CHIL verweilt, kommt an den Leistungsprüfstand in der Überzeugung, dass das Design stabil ist, und stellt dann fest, dass Sensorverzögerungen oder Schutzzeitpunkte unter Last alles durcheinanderbringen. Beide Wege führen zu Nacharbeiten, weil die Validierungsfrage falsch formuliert war. Die Lösung liegt in einer disziplinierten Abfolge der Schritte, nicht in noch mehr Komplexität im Labor.

Es ist besser, sich zu fragen, was physikalisch bleibt, was risikobehaftet bleibt und was unbewiesen bleibt. So lässt sich erkennen, wo CHIL aufhört und PHIL beginnt. Labore, die diese Disziplin wahren und OPAL-RT oder einen anderen offenen Echtzeit-Simulator nutzen, bauen Schritt für Schritt Vertrauen auf, anstatt darauf zu hoffen, dass ein einziger Versuch alle Fragen beantwortet. Diese Einschätzung spart mehr Zeit als jedes Akronym es jemals könnte.