Wann sollte man einen bestehenden Echtzeitsimulator um FPGA-Beschleunigung erweitern?

Wichtigste Erkenntnisse

• Fügen Sie FPGA-Beschleunigung nur hinzu, wenn die Timing-Daten einen deterministischen Engpass zeigen, der Ihre erforderlichen Zeitschritte, End-to-End-Latenzzeiten oder Jitter-Grenzwerte blockiert.
• FPGA-Arbeit auf dem kleinsten Hochgeschwindigkeits-Slice ausführen, den Sie nicht zuverlässig auf CPUs planen können, insbesondere enge I/O und wiederholbare Feedback-Pfade mit geringer Latenz.
• Kontrollieren Sie Kosten und Risiken mit einem festen Schnittstellenvertrag, einer CPU-Referenz zur Verifizierung und Abnahmetests, die sowohl die numerische Übereinstimmung als auch ein stabiles Closed-Loop-Timing nachweisen.

Fügen Sie FPGA-Beschleunigung hinzu, wenn Ihr Echtzeit-Simulator die deterministischen Fristen nicht mit der erforderlichen Genauigkeit einhalten kann.

Wenn das Timing nicht stimmt, hört man auf Tests Qualität Tests , und beginnt, Tests dem Zufall Tests . Diese Lücke äußert sich in einem instabilen Closed-Loop-Verhalten, falschen Fehlern und Workarounds wie Dezimierung, die genau die Probleme verbergen, die HIL eigentlich aufdecken soll. Software kosten die US-Wirtschaft schätzungsweise 59,5 Milliarden US-Dollar, was daran erinnert, dass eine späte Entdeckung teuer ist, noch bevor man das Risiko hardware und Laborausfallzeiten hinzurechnet.

„Die praktische Haltung ist einfach: FPGA-Arbeit ist gerechtfertigt, wenn sie einen bestimmten, gemessenen Engpass beseitigt, der den erforderlichen Zeitschritt, die Latenz oder I/O blockiert.“

Wenn Sie den Engpass nicht benennen und mit Zeitdaten belegen können, sind Sie noch nicht bereit für ein Upgrade. Wenn Sie dies können, ist ein FPGA oft der direkteste Weg zu stabilen, wiederholbaren HIL-Ergebnissen, ohne das Modell herabzustufen.

Anzeichen dafür, dass Ihr CPU-basiertes HIL-Modell Deadlines verpasst

CPU-basierte HIL ist nicht mehr einsetzbar, wenn der Simulator seinen festgelegten Zeitschritt verpasst, Timing-Jitter aufweist, der sich auf I/O auswirkt, oder Modellvereinfachungen erzwingt, die die Steuerungsergebnisse verändern. Es kommt zu Überschreitungen, sporadischen Verlangsamungen des Solvers und I/O , die nicht mehr mit dem vorgesehenen Abtasttakt übereinstimmen. Diese Symptome deuten darauf hin, dass der Determinismus bereits beeinträchtigt ist.

Beginnen Sie mit Messungen, nicht mit Bauchgefühl. Überprüfen Sie zunächst den Überlaufzähler und die Worst-Case-Ausführungszeit für das Modell plus I/O . Wenn der Worst Case nahe an der Schrittweite liegt, wird das Labor „gut“ funktionieren, bis eine seltene Scheduling-Spitze die Schleife aus dem Gleichgewicht bringt. In diesem Fall Ingenieur:innen , Pufferverzögerungen hinzuzufügen, die Abtastraten zu senken oder Teile der Anlage abzuschalten, und diese Korrekturen verändern stillschweigend das, was Sie validieren.

Achten Sie auch auf Probleme, die nur unter Closed-Loop-Belastung auftreten. Ein Modell, das ohne hardware läuft, kann dennoch ausfallen, sobald Interrupts, Gerätetreiber und I/O den Regelkreis I/O . Wenn Sie eine deterministische Reaktion benötigen, geht es nicht um die durchschnittliche CPU-Auslastung. Es geht um die Latenz und den Jitter im ungünstigsten Fall an genau den Punkten, an denen der Controller Daten mit der Anlage austauscht.

Workloads, die am meisten von der FPGA-Beschleunigung in der Simulation profitieren

FPGA-Beschleunigung zahlt sich aus, wenn der Engpass in parallelen, zeitkritischen Aufgaben liegt, die eine CPU nicht deterministisch mit Ihrer Zielrate planen kann. Dazu gehören enge I/O , Zeitstempelung unterhalb eines Zyklus und mathematische Berechnungen, die als parallele Pipelines ausgeführt werden können. Wenn sich die Aufgabe bei jedem Schritt wiederholt und rechtzeitig abgeschlossen werden muss, ist ein FPGA die richtige Wahl.

Die Leistung von Single-Thread-CPUs verbesserte sich von 2011 bis 2018 nur um 2,9 % pro Jahr verbessert, sodass das Warten auf den „Prozessor des nächsten Jahres“ ein überlastetes Fixed-Step-Modell nicht retten wird. Das ist für HIL von Bedeutung, da Ihre schwierigsten Fälle nicht nur rechenintensiv sind, sondern auch innerhalb einer festen Frist in jedem Zyklus mit jeweils derselben Latenz abgeschlossen werden müssen.

Ein konkretes Beispiel ist ein HIL-Prüfstand für EV-Traktionsumrichter, bei dem mehrere PWM-Signale erfasst, das schaltbezogene Anlagenverhalten in wenigen Mikrosekunden berechnet und Strom- und Spannungsrückmeldungen schnell genug zurückgegeben werden müssen, um einen Controller mit hoher Bandbreite stabil zu halten. Eine CPU kann einen Großteil der Anlage lösen, aber die PWM-Erfassung, die Handhabung der Totzeit und der Rückkopplungspfad mit extrem geringer Latenz werden oft zum Geschwindigkeitsbegrenzer. Die FPGA-Logik kann diesen deterministischen Teil übernehmen, während die CPU die langsamere Dynamik und die Überwachungslogik intakt hält.

Latenz-, I/O und Jitter-Ziele, die FPGA rechtfertigen

Der Einsatz von FPGAs ist dann sinnvoll, wenn Ihr Latenzbudget knapper ist, als eine CPU und ihr I/O garantieren können, selbst wenn die durchschnittliche Leistung in Ordnung zu sein scheint. Der deutlichste Auslöser ist, wenn Sie den erforderlichen festen Zeitschritt nicht mit Spielraum einhalten können oder wenn Jitter die vom Controller erkannte effektive Abtastzeit verändert. Das führt dazu, dass wiederholbare Tests zu inkonsistenten Tests werden.

Legen Sie Ziele anhand des Regelkreises fest, den Sie validieren, und nicht anhand eines allgemeinen Ziels wie „schnell ist gut“. Wenn ein Regler alle 50 Mikrosekunden Feedback erwartet, ist eine konsistente End-to-End-Latenz genauso wichtig wie die reine Schrittweite. Ein Jitter, der einen kleinen Teil der Zyklen verzögert, kann schlimmer sein als ein etwas langsamerer, aber stabiler Regelkreis, da er Timing-Rauschen in den Regelalgorithmus einbringt und Schutzvorrichtungen auslösen kann.

Wie man Aufwand, Kosten und Risiken vor einem Upgrade abschätzt

„Der Sieg ist ein stabiles HIL-Verhalten, auf das Sie sich Lauf für Lauf verlassen können.“

Der Aufwand und die Kosten hängen weniger von hardware ab als vielmehr davon, wie sauber Sie das isolieren können, was deterministisch sein muss. Eine gute Schätzung beginnt mit einem Zeitbudget, einer klaren Partitionsgrenze und einem Verifizierungsplan, der belegt, dass der FPGA-Pfad mit dem CPU-Modell übereinstimmt, wo er sollte. Das Risiko steigt, wenn die Anforderungen vage sind oder wenn der FPGA-Umfang immer weiter wächst.

Sammeln Sie zunächst einige Fakten, bevor Sie Entwicklungszeit investieren. Diese Informationen helfen Ihnen dabei, ehrlich zu bleiben, was Sie tatsächlich verbessern und was Sie lediglich verschieben.

• Ihr erforderlicher fester Zeitschritt und das minimale stabile Latenzbudget
• Die gemessene Worst-Case-Ausführungszeit und Überschreitungshäufigkeit unter Last
• I/O , Aktualisierungsraten und Zeitstempelgenauigkeit, die Sie einhalten müssen
• Die Teilmenge der Modellgleichungen, die ohne Jitter in jedem Zyklus ausgeführt werden muss
• Die Validierungsmethode, die numerische und zeitliche Abweichungen erkennt

Budget für Verifizierung und Wartung, nicht nur für die Entwicklung. FPGA-Mathematik verwendet häufig Festkomma- oder eingeschränkte Genauigkeit, und die größten Kostenüberraschungen entstehen durch die Suche nach kleinen numerischen Unterschieden, die nur in Randfällen auftreten. Ein kontrollierter Umfang, klare Abnahmetests und ein Rollback-Plan verhindern, dass das Upgrade zu einer endlosen Neuprogrammierung wird.

Praktischer Migrationspfad vom CPU-Löser zu FPGA-Kerneln

Der zuverlässigste Upgrade-Pfad behält Ihr CPU-Modell unverändert bei und verlagert nur den zeitkritischen Teil auf FPGA-Kerne. Dieser Ansatz schützt Ihre bestehenden Anlagen und Testressourcen und bietet Ihnen gleichzeitig deterministische I/O Berechnungen mit geringer Latenz, wo es darauf ankommt. Behandeln Sie den FPGA als Co-Prozessor mit einem strengen Vertrag und nicht als Ersatz für Ihren vollständigen Solver.

Beginnen Sie mit einer Partition mit klaren Grenzen: Eingaben kommen an, eine begrenzte Anzahl von Berechnungen wird ausgeführt, Ausgaben werden zurückgegeben – alles innerhalb eines bekannten Zeitrahmens. Frieren Sie Schnittstellen frühzeitig ein, einschließlich Skalierung, Einheiten und Aktualisierungsraten, und erstellen Sie dann einen bitgenauen Testrahmen, der die FPGA-Ausgaben mit der CPU-Referenz über repräsentative Stimuli hinweg vergleicht. Sobald der Kernel übereinstimmt, straffen Sie das Timing und führen Sie dann erneut Closed-Loop-Tests durch, um zu bestätigen, dass die Stabilitätsverbesserungen auf Determinismus und nicht auf veränderte Dynamik zurückzuführen sind.

Die Ausführung ist einfacher, wenn Ihre Toolchain gemischte CPU- und FPGA-Workflows mit konsistenter Zeitmessung unterstützt. Teams, die OPAL-RT-Plattformen verwenden, behalten das Hauptmodell häufig auf der CPU und ordnen bestimmte I/O Rechenkerne den FPGA-Ressourcen zu, damit das Labor die Fristen einhalten kann, ohne die Genauigkeit der Anlage zu beeinträchtigen.

Häufige Fallstricke beim Hinzufügen eines FPGA zu einem bestehenden Simulator

Der häufigste Fehler besteht darin, die FPGA-Beschleunigung als Geschwindigkeitssteigerung statt als Verbesserung der Determiniertheit zu betrachten. Die Verlagerung großer Teile eines Modells auf FPGA ohne strenge Timing-Vorgaben führt zu neuem Integrationsaufwand, neuen numerischen Verhaltensweisen und neuen Debugging-Problemen. Der Erfolg hängt davon ab, den gemessenen Engpass zu isolieren und nur diesen zu beheben.

Scope Creep ist der stille Killer. Eine kleine Entlastung, die eigentlich dazu dienen sollte, I/O zu beheben, kann zu einer vollständigen Neuimplementierung führen, sobald Teams nach Leistungsreserven suchen, ohne zu überprüfen, ob der Controller diese tatsächlich benötigt. Eine weitere häufige Falle ist das Überspringen der End-to-End-Timing-Validierung, wodurch Sie zwar schnelle Kernel erhalten, aber inkonsistente Schleifenlatenzen, sobald Signale zwischen CPU- und FPGA-Domänen übertragen werden.

Gutes technisches Urteilsvermögen erscheint hier langweilig. Legen Sie die Frist fest, messen Sie die Abweichung, entlasten Sie den kleinsten deterministischen Teil, der die Abweichung beseitigt, und sichern Sie ihn dann mit wiederholbaren Tests und dokumentierter Skalierung. Diese Disziplin ist auch das, worauf wir bei OPAL-RT drängen, wenn Teams nach FPGA-Beschleunigung fragen, denn der Gewinn liegt nicht in der reinen Geschwindigkeit. Der Gewinn ist ein stabiles HIL-Verhalten, auf das Sie sich Lauf für Lauf verlassen können.