CPU- versus FPGA-Simulation für Hochgeschwindigkeits Tests

Wichtigste Erkenntnisse

• Wählen Sie die CPU-Simulation, wenn Ihre HIL-Ziele größere feste Schritte und konsistente I/O tolerieren und Ihre Passkriterien sich auf die Steuerungslogik und das durchschnittliche elektrische Verhalten konzentrieren.
• FPGA-Simulation ist erforderlich, wenn Ihre Tests von Schaltflanken, Mikrosekunden-Timing und deterministischen Schutzreaktionen abhängen, die eine CPU unter Worst-Case-Lastbedingungen nicht garantieren kann.
• Legen Sie Ihre Wahl anhand messbarer Akzeptanzkriterien für Schrittweite, Überlaufmarge und I/O fest und passen Sie dann die Modellgenauigkeit an die Fehler an, die Sie genehmigen müssen.

Wählen Sie die CPU-Simulation, bis Mikrosekunden-Timing zu einer zwingenden Testanforderung wird.

Hochgeschwindigkeitsmotorantrieb Tests , wenn Ihr Simulator genau die Ereignisse glättet, die den Schutz auslösen, den Strom sättigen Sensor-und Datenfusion oder eine schnelle Stromschleife destabilisieren. Elektromotoren machen etwa aus, daher ist es weit über ein einzelnes Steuerungsprojekt hinaus wichtig, das Antriebsverhalten richtig zu gestalten.

CPU- vs. FPGA-Simulation ist kein Wettstreit um technische Daten.

Der praktische Separator ist die zeitliche Genauigkeit in der von Ihnen benötigten Schrittweite sowie I/O vorhersehbare I/O , wenn die Schleife durch hardware (HIL) geschlossen wird. Beginnen Sie mit Ihren Testzielen, formulieren Sie Akzeptanzkriterien und wählen Sie die einfachste Berechnung, mit der diese jedes Mal erfüllt werden.

Wählen Sie CPU oder FPGA basierend auf den Zielen des Motorantriebs-HIL.

Der Hauptunterschied zwischen CPU- und FPGA-Simulation besteht darin, wie sie Zeit und Parallelität bei der Echtzeitausführung handhaben. Eine CPU führt sequenziellen Code sehr schnell aus, hat jedoch weiterhin mit Scheduling-Jitter und Schrittgrößenbeschränkungen zu kämpfen. Ein FPGA führt viele Operationen parallel mit deterministischem Timing aus, was wichtig ist, wenn Ihr Test vom Subzyklus-Umschaltverhalten abhängt.

CPU-basierte HIL eignet sich am besten für die Validierung von Steuerungslogik, Startsequenzen, Fehlerzustandsmaschinen und Überwachungsfunktionen, die auf gemitteltem elektrischem Verhalten basieren. FPGA-basierte HIL eignet sich am besten, wenn Sie Schaltflanken, Totzeiteffekte und schnelle Schutzpfade darstellen müssen, ohne sie in einem großen Zeitschritt zu verbergen. Ein gemischter Ansatz funktioniert auch gut, wenn nur die Leistungsstufe eine Auflösung im Mikrosekundenbereich benötigt.

Kennen Sie die zeitlichen Grenzen, die CPU-basierte Simulationen beeinträchtigen.

Die CPU-Simulation bricht zusammen, wenn der erforderliche feste Zeitschritt so klein wird, dass die Solver- und I/O nicht vor dem nächsten Tick abgeschlossen werden können. Verpasste Fristen führen zu Überschreitungen, Jitter oder erzwungenen Erhöhungen der Schrittweite, und diese Artefakte verfälschen genau die Messungen, anhand derer Sie die Qualität des Controllers beurteilen.

Das Timing-Risiko steigt, wenn Sie Switching-Modelle, Sensorfilterung und Schnittstellenverwaltung in derselben Schleife stapeln. Eine schnellere CPU hilft zwar, aber der Determinismus hängt weiterhin von der Worst-Case-Ausführungszeit ab, nicht von der durchschnittlichen Leistung. Multi-Core-Konfigurationen können Sie ebenfalls überraschen, wenn Threads um Speicher konkurrieren oder wenn I/O im falschen Moment Zyklen stiehlt.

Die praktische Akzeptanz beginnt mit einem strengen Zeitbudget: Lösungszeit der Anlage plus I/O , plus etwaige Protokollierung, plus Sicherheitsmarge. Wenn Ihre Tests Schritte im einstelligen Mikrosekundenbereich und einen engen Regelkreis zu physischen Steuerungen erfordern, wird ein rein CPU-basierter Ansatz zu einem ständigen Kampf um die Marge. Wenn der erforderliche Schritt weniger streng ist, bleibt die CPU-Simulation produktiv und lässt sich leichter iterieren.

Verwenden Sie FPGA-Simulation für die Genauigkeit der Leistungselektronik auf Schaltebene.

Eine FPGA-Simulation ist erforderlich, wenn es um die Genauigkeit der Schaltpegel geht und nicht um Details, die man durch Mittelwertbildung ausgleichen kann. Durch deterministische parallele Ausführung können Sie das Verhalten auf Geräteebene, das PWM-Timing und schnelle Schutzpfade in sehr kleinen Zeitschritten darstellen. Diese Genauigkeit sorgt dafür, dass Fehler, Welligkeit und Kommutierungseffekte für die Steuerung sichtbar bleiben.

Höhere Schaltfrequenzen erfordern diesen Ansatz, da sich das elektrische System innerhalb jedes Regelungszeitraums stärker verändert. Halbleiter mit großer Bandlücke können Schaltfrequenzen von bis zu 10-mal höher als Siliziumbauelemente unterstützen, was die Timing-Anforderungen für alle Tests verschärft, bei denen es um Stromwelligkeit, dv/dt-bezogene Effekte oder Zyklus-für-Zyklus-Schutz geht.

Die Arbeit mit FPGAs bringt gewisse Einschränkungen mit sich. Bei der Modellentwicklung kommen häufig Festkommaarithmetik, sorgfältige Skalierung und eine explizite Aufteilung zwischen Prozessen, die im Mikrosekundenbereich ablaufen müssen, und solchen, die langsamer ausgeführt werden können, zum Einsatz. Plattformen wie OPAL-RT werden häufig verwendet, um CPU- und FPGA-Workloads sauber aufzuteilen, sodass Sie ein schnelles, deterministisches Power-Stage-Timing beibehalten und gleichzeitig die Überwachungslogik und den größeren Systemkontext auf der CPU belassen können.

Passen Sie die Schrittweite des Lösers an die PWM-Frequenz und die Regelkreise an.

Die Auswahl der Schrittgröße sollte bei dem schnellsten Phänomen beginnen, das Ihr Test beobachten muss, und dann rückwärts zu dem arbeiten, was der Regler mit diesen Informationen tun wird. Wenn Sie nur eine durchschnittliche Drehmoment- und Drehzahlreaktion benötigen, können Sie größere Schritte ausführen und das Schalten vereinfachen. Wenn Sie ein zyklusgenaues Verhalten benötigen, muss die Schrittgröße klein genug sein, um dies zu gewährleisten.

Eine konkrete Überprüfung hilft: Eine 20-kHz-PWM-Periode beträgt 50 µs, und eine Stromschleife kann zusätzlich mit mehreren kHz laufen. Bei Verwendung eines 25-µs-Anlagenschritts bleiben Ihnen nur zwei Punkte pro Schaltperiode, was die Schaltwelligkeit verschmiert und den Spitzenstrom, der den Schutz auslöst, verdecken kann. Ein Schritt von 1 µs bis 2 µs löst einen weitaus größeren Teil der Schaltperiode auf und hält das Spitzenverhalten sowohl für software für hardware sichtbar.

Die Wahl des Solvers und die Aufteilung sind ebenso wichtig wie die reine Schrittweite. Durchschnittliche Wechselrichtermodelle können für die Steuerungsoptimierung und Effizienzstudien geeignet sein, aber sie validieren weder das Gate-Timing, die Totzeitkompensation noch zyklusgenaue Entsättigungspfade. Bei Schaltmodellen müssen Sie außerdem die Abtastung, Quantisierung und Verzögerung als wichtige Bestandteile des Tests behandeln und nicht als Nebensache betrachten.

Überprüfen Sie I/O und die Schnittstellenanforderungen für Tests.

I/O ist Teil der Anlage, wenn Sie den Regelkreis über HIL schließen. Der Regler reagiert auf gemessene Ströme, Spannungen und Positionen und erwartet, dass diese Signale mit einer stabilen Verzögerung eintreffen. Wenn diese Verzögerung schwankt, werden die Abstimmungsergebnisse nicht übertragen und die Schutzvalidierung verliert an Glaubwürdigkeit.

Beginnen Sie mit den Schnittstellen, die Ihr Controller tatsächlich verwendet: PWM-Ausgänge, Gate-Befehle, Stromrückmeldung, DC-Link-Erkennung, Encoder- oder Resolver-Position und Fehlerleitungen. Jeder Signalpfad verursacht zusätzliche Konvertierungszeit, Pufferung und Planungsaufwand, und die Gesamtsumme muss innerhalb Ihres Schleifenbudgets bleiben. Deterministische Latenz ist oft wichtiger als minimale Latenz, da eine konsistente Verzögerung kompensiert werden kann, während Jitter zu Phasenrauschen führt.

Hardware ist ein Timing-Tool, nicht nur ein Rechenwerkzeug. Schnelle I/O und -Generierung lassen sich natürlich mit FPGA-Ausführung kombinieren, wenn Sie eine wiederholbare Reaktion im Mikrosekundenbereich benötigen. Die CPU-Ausführung eignet sich, wenn Ihre Schnittstellen langsamer sind, Ihre Steuerungsperioden länger sind oder Ihr Hauptziel eher das funktionale Verhalten als das Timing Vorteil ist.

Vermeiden Sie häufige Fehler bei der Auswahl und legen Sie klare Akzeptanzkriterien fest.

Der häufigste Fehler besteht darin, zuerst die Rechenleistung und erst danach die Testabsicht zu wählen. Reine CPU-Konfigurationen scheitern, wenn Teams davon ausgehen, dass durchschnittliche Leistung gleichbedeutend mit deterministischer Leistung ist, oder wenn sie ein großes Anlagenmodell in Mikrosekunden-Schritten ausführen wollen. Reine FPGA-Konfigurationen scheitern, wenn Teams Zeit für Details aufwenden, die im Testplan nie verwendet werden.

Schreiben Sie Akzeptanzkriterien, die während der Inbetriebnahme messbar sind, und halten Sie sich dann an diese Kriterien. Beziehen Sie die Kriterien auf die tatsächlichen Abtast- und Schutzpfade Ihrer Steuerung und nicht auf allgemeine Leistungsangaben des Simulators. Passen Sie die Modelldetails an die Fehlerfälle an, die Sie abnehmen müssen, und reduzieren Sie alles andere auf das, was diese Fälle unterstützt.

• Ihr fester Zeitschritt bleibt auch unter ungünstigsten Fehlerszenarien stabil.
• I/O End-to-End I/O ist innerhalb Ihres Schleifenbudgets wiederholbar.
• Die Umschaltdetails werden nur angezeigt, wenn Ihr Test dies erfordert.
• Überschreitungen und Jitter werden protokolliert und als Testfehler behandelt.
• Der Umfang des Modells entspricht den Signoff-Fragen und nicht den Präferenzen des Teams.

Die Debatte um CPU- vs. FPGA-Simulationen ist beendet, wenn Sie Timing und Latenz als technische Anforderungen betrachten.

Wählen Sie CPU, wenn diese die Schrittweite und I/O erfüllt, die Sie während der HIL-Prüfung nachweisen können, und wählen Sie FPGA, wenn Schaltpegel-Dynamik und deterministische Reaktion Teil der Passkriterien sind. Teams, die diese Disziplin auf OPAL-RT-Plattformen ausführen, kommen im Labor tendenziell schneller voran, da die Wahl des Simulators auf messbarem Verhalten und nicht auf Annahmen basiert.