Hardware-in-the-Loop

Hardware-in-the-Loop ist eine Echtzeit-Testmethode, bei der ein realer Controller seine Produktionssoftware weiter ausführt, während die von ihm gesteuerte physische Anlage durch eine hochpräzise Echtzeitsimulation ersetzt wird. Bei Impedyme bauen wir FPGA-basierte Hardware-in-the-Loop-(HIL) und Power- Hardware-in-the-Loop-Plattformen , die die Lücke zwischen Offline-Simulation und Feldeinsatz in der Leistungselektronik schließen. Dieser Leitfaden erklärt, was Hardware-in-the-Loop ist, wie ein HIL-Simulator funktioniert und warum der Simulationszeitschritt für schaltende Umrichter so entscheidend ist.

Was ist Hardware-in-the-Loop?

Hardware-in-the-Loop ist eine Echtzeit-Simulationstechnik, bei der ein realer elektronischer Controller – das zu prüfende Gerät – physisch in der Schleife bleibt, während die von ihm normalerweise gesteuerte Anlage durch ein in Echtzeit laufendes mathematisches Modell ersetzt wird. Der Controller tauscht reale elektrische Signale über reale Ein- und Ausgangskanäle aus und verhält sich daher genau wie im Feld.

Diese Definition hat es in sich, daher wollen wir die beiden Kernideen aufschlüsseln. Das zu prüfende Gerät (DUT) ist das reale, physische Hardwareteil, das Sie validieren möchten. In der Leistungselektronik ist dies fast immer ein Controller – eine Wechselrichter-Steuerplatine, ein Batteriemanagementsystem, ein Netzumrichter-Controller oder ein Motorantrieb – der dieselbe Firmware ausführt wie in der Produktion. Nichts am DUT ist simuliert; es ist das echte Objekt.

"Die Schleife" ist der geschlossene Kreislauf von Ursache und Wirkung zwischen diesem Controller und seiner Umgebung. In der realen Welt liest ein Controller Sensorsignale, entscheidet, was zu tun ist, und steuert Aktoren an; die Aktoren verändern das physische System; die Sensoren melden den neuen Zustand; und der Kreislauf wiederholt sich tausende Male pro Sekunde. In einem Hardware-in-the-Loop-Aufbau öffnen wir diesen Kreislauf und fügen dort, wo sich früher die physische Welt befand, ein Echtzeitmodell ein. Das Modell berechnet, wie die Anlage reagieren würde, speist diese Reaktionen als reale Spannungen, Ströme und digitale Signale an den Controller zurück und liest die Befehle des Controllers ein – alles schnell genug, dass der Controller nicht erkennen kann, dass er mit einer Simulation statt mit Kupfer und Eisen kommuniziert.

Das unterscheidet Hardware-in-the-Loop-(HIL) von der gewöhnlichen Desktop-Simulation. In einem reinen Softwaremodell ist alles virtuell, einschließlich des Controllers. In einer HIL-Hardware-in-the-Loop- Anordnung ist der Controller real und nur seine Umgebung wird modelliert. Dieser Unterschied ist der ganze Punkt: Der Code, den Sie validieren, ist der Code, den Sie ausliefern, das Timing, das Sie messen, ist das Timing, das Sie erhalten, und das Schnittstellenverhalten, das Sie beobachten, ist das Schnittstellenverhalten, das auf dem Prüfstand und im Feld bestehen wird.

Das Hardware-in-the-Loop-Bedeutung lässt sich daher am besten als Position auf einem Spektrum verstehen. Es steht am äußersten, hardwarereichen Ende der modellbasierten Entwicklungsprogression – Model-in-the-Loop, Software-in-the-Loop und Processor-in-the-Loop kommen alle zuerst und fügen jeweils etwas mehr Realismus hinzu – und Hardware-in-the-Loop-(HIL) ist der Punkt, an dem der reale Controller endlich auf eine Echtzeitwelt trifft. Es ist die letzte Validierungsstufe, bevor Sie an reale Leistung anschließen, und für viele Programme die aufschlussreichste. Weil der Controller echt ist und die Schleife in Echtzeit läuft, Hardware-in-the-Loop-Testen bringen Integrationsprobleme ans Licht – Timing-Races, Schnittstellenfehler, fehlerhafte Schutzauslösungen –, die kein Offline-Modell zeigen kann.

Hardware-in-the-Loop-Tests: der HIL-Testablauf Schritt für Schritt

Hardware-in-the-Loop-Testen sind der disziplinierte Prozess, einen realen Controller gegen ein Echtzeit-Anlagenmodell zu betreiben und anhand definierter Kriterien ein Bestehen oder Nichtbestehen festzustellen. Ein gutes HIL-Testprogramm ist kein willkürliches Herumprobieren; es ist ein wiederholbarer Ablauf, der nachvollziehbare Nachweise liefert. So verläuft ein Hardware-in-the-Loop-Test typischerweise von Anfang bis Ende.

Anlagenmodell erstellen oder importieren

Beginnen Sie mit einem Modell des physischen Systems – Motor, Umrichter, Batterie oder Netz –, das die für Sie wichtigen Dynamiken erfasst. Die meisten Teams erstellen dieses in einer Simulink-ähnlichen Modellierungsumgebung und verwenden dasselbe Modell wieder, dem sie bereits aus der Offline-Entwicklung vertrauen.

Modell für die Echtzeitausführung vorbereiten

Konvertieren Sie das Modell so, dass es deterministisch auf dem Echtzeitziel läuft, und wählen Sie Solver und Zeitschritt passend zu den schnellsten Dynamiken im System. Bei einem schaltenden Umrichter wird hier die FPGA-Ausführung unverzichtbar.

Ein- und Ausgänge zuordnen

Weisen Sie die Signale des Modells physischen Kanälen zu – analoge Ausgänge, die Sensoren emulieren, digitale Eingänge, die Gate-Befehle erfassen, Encoder- und Resolver-Emulation, Schutzleitungen und Kommunikationsbusse.

DUT mit der HIL-Schnittstelle verdrahten

 Verbinden Sie den realen Controller über eine Breakout- und Signalkonditionierungsschicht mit dem Simulator, sodass Spannungspegel, Isolation und Erdung auf beiden Seiten korrekt sind.

Die Hardware-in-the-Loop-Testfälle definieren

Legen Sie Anfangsbedingungen, den anzulegenden Stimulus und die numerische Bestehens-/Nichtbestehens-Regel für jedes Szenario fest, einschließlich Normalbetrieb, Grenzbedingungen und Fehlerinjektion.

Den geschlossenen HIL-Test durchführen

 Führen Sie jeden Fall in Echtzeit aus und lassen Sie Controller und Modell interagieren, während ein Hochgeschwindigkeits-Logging jedes relevante Signal erfasst.

Ergebnisse auswerten und Nachweise protokollieren

 Vergleichen Sie das gemessene Verhalten automatisch mit den Bestehens-/Nichtbestehens-Kriterien und speichern Sie die Ergebnisse mit Konfigurations- und Firmware-Kennungen, sodass jeder Lauf später reproduziert werden kann.

Automatisieren und Regressionstests durchführen

 Nehmen Sie die bestandenen Fälle in eine automatisierte Regressionssuite auf, die bei jeder Firmware-Änderung erneut läuft, sodass eine Korrektur in einem Bereich nicht unbemerkt einen anderen beschädigen kann.

Was Sie mit Hardware-in-the-Loop testen können

Hardware-in-the-Loop validiert Controller, Leistungselektronik, Batterien, Motoren und komplette elektrische Systeme unter realistischen Bedingungen. Durch die Kombination realer Hardware mit Echtzeitsimulation können Ingenieure Normalbetrieb, Transienten, Fehler und Grenzfälle sicher reproduzieren, bevor das Gesamtsystem eingesetzt wird.

EV-Antriebsstränge und Traktionswechselrichter

Ein Traktionswechselrichter ist der Punkt, an dem hoher Strom, schnelles Schalten und sicherheitskritische Steuerung zusammentreffen. Mit Hardware-in-the-Loop-(HIL)lassen wir Motor- und Batteriemodelle auf dem FPGA schnell genug laufen, um SiC-Schaltvorgänge aufzulösen, Resolver- und Encoderposition zu emulieren, CAN- und Automotive-Ethernet-Verkehr auszutauschen und Gate-Befehle in Echtzeit einzulesen. Das lässt Teams Totzeitverzerrungen, Feldschwächungsübergänge, Six-Step- und Übermodulationseintritt sowie Rekuperationsbremsung untersuchen – sicher, wiederholbar und lange bevor eine Prüfstandszelle frei ist. Prüfungen auf Signalebene erfassen die Logik; die Emulation auf Leistungsebene legt echte Last an, sodass Dioden und Schalter unter realen Bedingungen beansprucht werden. Entdecken Sie unseren Ansatz für Automotive-HIL-Tests.

BMS und Batteriepacks

 Ein Batteriemanagementsystem ist schwer zu testen, weil die Fehler, die Sie verifizieren müssen – Zellkurzschluss, Überspannung, thermisches Durchgehen – genau diejenigen sind, die Sie an einem realen Pack nicht sicher inszenieren können. Hardware-in-the-Loop löst dies mit Zellemulation: Der Simulator reproduziert das elektrische Verhalten jeder Zelle, und das BMS liest Spannungen, Ströme und Temperaturen, die es für real hält. Ingenieure injizieren Kurzschlüsse, Drift und Unsymmetrien programmatisch, fahren Lade- und Entladeprofile wochenlang unbeaufsichtigt und validieren die Schätzung von Ladezustand und Alterungszustand gegen eine bekannte Grundwahrheit. Sehen Sie, wie wir die Batteriemanagementsystem -Validierung handhaben.

Motorantriebe und Motorsteuerung

 Die Validierung eines Motorcontrollers ist zum zentralen Prüftor der Antriebsentwicklung geworden, und Hardware-in-the-Loop-Testen macht sie sicher und gründlich. Unser Motoremulator reproduziert PMSM-, Induktions-, BLDC- und IPM-Maschinen mit nichtlinearen Effekten – magnetische Sättigung, Hysterese, Drehmomentwelligkeit – sowie winkelabhängige Fluss- und Drehmomentkennfelder, die alle in Schritten im Nanosekundenbereich aktualisiert werden. Der Controller sieht realistische Gegen-EMK, Positionsrückmeldung und Stromverläufe, sodass Teams Stromregelkreise abstimmen, die Fehlerbehandlung verifizieren und Betriebspunkte abdecken können, die auf einem physischen Dynamometer riskant oder langsam wären.

Solar- und netzgekoppelte Wechselrichter (Netzanschlusskonformität)

 Netzgekoppelte Wechselrichter müssen Spannungs- und Frequenzstörungen durchfahren und das Netz stützen, anstatt abzuschalten und ein Ereignis zu verschärfen. Hardware-in-the-Loop ermöglicht es uns, diese Störungen auf Abruf zu inszenieren – Einbrüche, Überspannungen, Frequenzabweichungen, Rate-of-Change-Ereignisse und niederohmige Fehler – und die Reaktion des Wechselrichters automatisch gegen Netzanschluss- und Interkonnektionsanforderungen zu bestätigen, genau an den Grenzen des zulässigen Bereichs. Wiederholbare, programmierbare Szenarien verwandeln wochenlange Zertifizierungsvorbereitung in eine automatisierte Kampagne. 

Microgrids und erneuerbare Energien

Ein Microgrid ist ein System aus Controllern – Wechselrichter, Speicher, Schutzrelais und ein übergeordneter Controller –, die durch Inselbetrieb, Resynchronisation und Fehlerereignisse zusammenarbeiten müssen. Hardware-in-the-Loop-Testen ermöglicht es uns, die realen Controller gegen ein Echtzeitmodell des Netzes zusammenzuführen und Schutzkoordination und Energiemanagement zu validieren, bevor im Feld etwas unter Spannung gesetzt wird. Da das Modell auf dem FPGA läuft, koexistieren Umrichterverhalten auf Schaltebene und langsamere Netzdynamiken auf einer Plattform. Entdecken Sie HIL-Tests für Microgrids und erneuerbare Energien.

HVDC

 Hochspannungs-Gleichstrom-Umrichterstationen verwenden modulare Multilevel-Umrichter mit tausenden Submodulen, und ihre Steuerungs- und Schutzrepliken müssen vor einer Werksabnahmeprüfung erschöpfend validiert werden. Hardware-in-the-Loop ist die anerkannte Methode: Das Umrichterventil wird auf dem FPGA in Sub-Mikrosekunden-Schritten gelöst, während das umgebende AC-System auf dem Prozessor läuft, und die realen Steuerungsrepliken des Herstellers werden durch Anlauf, AC- und DC-Fehlerdurchfahrt und Notfallmodi geführt. 

DC-Schnellladen

 Ein Schnellladegerät ist zugleich ein Leistungsumrichter und ein kommunizierender Knoten, daher muss es an beiden Fronten validiert werden. Mit Hardware-in-the-Loop emulieren wir die Fahrzeugseite – Batterieverhalten und die Lade-Zustandsmaschine – während wir die übergeordnete Kommunikation des Ladegeräts, Control-Pilot- und Proximity-Signalisierung sowie seine Leistungsumwandlung unter realistischen und fehlerbehafteten Bedingungen beanspruchen. Das belegt Interoperabilität und sichere Sequenzierung, bevor je ein echtes Fahrzeug eingesteckt wird. Entdecken Sie DC-Schnelllade- und EV-Tests.

eVTOL und Elektroflugzeuge

 Elektrifizierte Flugzeuge rücken Hochspannungs-Gleichstrom, leistungsdichte Wechselrichter und verteilten Antrieb ins Zentrum des Fahrzeugs, wo jeder Fehlermodus interagiert und die Zertifizierung unerbittlich ist. Hardware-in-the-Loop unterstützt die anforderungsbasierte Verifikation, die diese Programme erfordern, und lässt Ingenieure flugkritische Leistungselektronik und Antriebscontroller gegen Fehlerszenarien validieren, deren Inszenierung im Flug katastrophal wäre. Dieselbe Plattform skaliert von einer einzelnen Antriebseinheit bis zu einem vollständigen Prüfstand auf Systemebene. 

Schiffs- und Marinestromversorgung

 Moderne Schiffe betreiben zonale Mittelspannungsnetze, die Microgrids ähneln und Erzeugung, Umwandlung, Speicherung und Antriebslasten auf einem gemeinsamen Bus mischen. Power-Hardware-in-the-Loop bietet Konstrukteuren im Marine- und Handelsbereich eine sichere, flexible Möglichkeit, Fehlermanagement, Energiemanagement und Stabilität in diesen Architekturen zu untersuchen, bevor Stahl verbaut wird. Controller und Schutzgeräte werden gegen ein Echtzeitmodell der elektrischen Anlage des Schiffs validiert. Sehen Sie, wie wir Schifffahrt und Schiffsstromversorgungssysteme unterstützen.

Robotercontroller und Rechenzentrumsstromversorgung

 Roboter- und Servocontroller können gegen ein Echtzeitmodell des Manipulators und seiner Antriebe validiert werden, wobei Encoder-Emulation und Drehmomentverhalten getreu reproduziert werden, sodass die Steuerlogik ohne Risiko für einen physischen Arm beansprucht wird. Die Rechenzentrumsstromversorgung ist die schnell wachsende Grenze: USV-Controller, Batteriesysteme, Generatorsteuerungen und Energiemanagementsysteme müssen KI-getriebene Lastschwankungen und Netzstörungen mit null Ausfallzeit überstehen, und Hardware-in-the-Loop validiert die gesamte Leistungskette in einer kontrollierten, wiederholbaren Schleife. Entdecken Sie Stabilitätstests der Rechenzentrumsstromversorgung.

Wie funktioniert ein Hardware-in-the-Loop-Simulator?

Ein Hardware-in-the-Loop-Simulationstechnologie funktioniert, indem ein Anlagenmodell in Echtzeit gelöst und der Zustand dieses Modells über eine physische Ein- und Ausgangsschicht mit einem realen Controller ausgetauscht wird – schnell und deterministisch genug, dass der Controller reagiert, als wäre er mit dem realen System verbunden. Drei Dinge müssen stimmen, damit ein HIL-Simulator glaubwürdig ist: das Modell, die I/O und das Timing. Stimmt eines davon nicht, hört der Hardware-in-the-Loop-Simulation stillschweigend auf, die Realität abzubilden.

 

Das Echtzeit-Anlagenmodell und der Kompromiss zwischen Genauigkeit und Geschwindigkeit

Das Herzstück jedes Hardware-in-the-Loop-Simulation ist das Anlagenmodell. Es muss detailliert genug sein, um das maßgebliche Verhalten zu reproduzieren – Schaltwelligkeit, Drehmomentwelligkeit, Fehlertransienten –, aber zugleich schlank genug, um innerhalb des Zeitbudgets eines einzelnen Simulationsschritts gelöst zu werden. Dies ist der Kompromiss zwischen Genauigkeit und Geschwindigkeit, und er ist unvermeidlich. Ein reicheres Modell mit mehr Zuständen und feinerer Bauteilphysik ist getreuer, braucht aber länger zur Berechnung; ein gröberes, gemitteltes Modell rechnet schneller, kann aber genau den Grenzfall verbergen, den Sie suchen. Die Kunst der HIL-Simulation besteht darin, ein Modell zu wählen, das die benötigte Physik bewahrt und zugleich in einen Schritt passt, der klein genug ist, um echtzeitfähig zu bleiben.

Die Ein- und Ausgangsschicht bei Hardware-in-the-Loop 

Die I/O-Schicht ist der Ort, an dem das Modell auf die Hardware trifft. Ein leistungsfähiger Hardware-in-the-Loop-Simulationstechnologie bietet analoge Ein- und Ausgänge, um Sensorsignale zu emulieren und Referenzen einzulesen, digitale I/O zum Austausch von Befehlen auf Logikpegel, PWM-Erfassung, um die Gate-Signale des Controllers hochauflösend auszulesen, sowie Encoder- oder Resolver-Emulation, damit ein Motorcontroller realistische Positionsrückmeldung erhält. Es stellt außerdem Schutzsignale bereit – die Auslöse- und Freigabeleitungen, auf die die Sicherheitslogik angewiesen ist – sowie Kommunikationsschnittstellen wie CAN, CAN FD, EtherCAT, Modbus und Lichtwellenleiter- oder SFP-Optikverbindungen. Diese Glasfaserverbindungen sind besonders bei Leistung wichtig, wo eine schnelle, latenzarme digitale Verbindung zwischen Simulator und Leistungsschnittstelle die Schleife eng hält. Unsere Power-HIL-Module bieten mehrkanalige analoge I/O mit hohen Abtastraten und 16-Bit-Auflösung, Hochgeschwindigkeits-Wellenform-Logging und mehrere optische Ports pro Modul für deterministische Synchronisation über Einheiten hinweg, sodass ein Prüfstand auf hunderte Kanäle skalieren kann und dabei ein Timing im Nanosekundenbereich einhält. 

Zeitschritt, Latenz und Determinismus – und warum ein Overrun ein Ergebnis ungültig macht

Jeder Echtzeitsimulator schreitet sein Modell in festen Inkrementen voran, die als Zeitschritt bezeichnet werden. Bei jedem Schritt muss er Eingänge lesen, das Modell lösen und Ausgänge schreiben, bevor die Uhr zum nächsten Schritt tickt. Wenn er einen Schritt in weniger realer Zeit berechnet als das Intervall, das dieser Schritt darstellt, bleibt die Schleife ehrlich. Dauert er jemals länger – ein Overrun –, zerbricht die Illusion und der Test ist ungültig, denn die simulierte Welt ist hinter den realen Controller zurückgefallen, der mit ihr spricht. Deshalb zählt Determinismus mehr als reiner Durchsatz: Ein Simulator, der im Mittel schnell ist, aber gelegentlich einen Overrun hat, lässt die Fehlerlogik zufällig erscheinen und untergräbt das Vertrauen in jedes Ergebnis. Ein Hardware-in-the-Loop-(HIL) Ergebnis ist nur dann vertrauenswürdig, wenn jeder einzelne Schritt seine Frist eingehalten hat. 

Konkrete Schrittweitenklassen erzählen die Geschichte besser als der Ausdruck „Echtzeit“. Für Energiesystem- und Netzmodelle reicht ein Zeitschritt im Bereich von 50 Mikrosekunden im Allgemeinen aus, um elektrische Netzelemente getreu zu simulieren, während eine genaue leistungselektronische Simulation mit einer PWM-Steuerstrategie im Allgemeinen unter einer Mikrosekunde laufen sollte. Leistungselektronische Umrichter leben in einer viel schnelleren Welt. CPU-basierte Simulatoren arbeiten typischerweise mit festen Schritten irgendwo zwischen etwa 10 und 100 Mikrosekunden, und das ist für pulsweitenmodulierte Umrichter schlicht zu grob: Bei einer Schaltfrequenz von 100 kHz beträgt die gesamte Schaltperiode nur 10 Mikrosekunden, sodass ein 10-Mikrosekunden-Schritt kaum eine Modellaktualisierung pro Schaltperiode liefert und schwere PWM-Quantisierungsfehler, verzerrte Tastverhältnismessungen und künstliche numerische Instabilitäten erzeugt. Schlimmer noch: Mehrere Schaltereignisse können in einen einzigen groben Zeitschritt fallen, sodass der Simulator sie nie sieht.

Warum FPGA-basiertes Lösen bei hohen Schaltfrequenzen wichtig ist

Der Ausweg aus dieser Falle ist, das Modell auf einem Field-Programmable Gate Array zu lösen. Eine CPU führt Modellgleichungen mehr oder weniger sequenziell aus, teilt ihre Zyklen auf Aufgaben auf und führt Jitter ein. Ein FPGA löst das Modell in massiv paralleler Logik, berechnet viele Teile der Schaltung gleichzeitig und integriert Verarbeitung und I/O auf demselben Chip. Das Ergebnis ist eine deterministische, jitterfreie Ausführung bei Zeitschritten, die eine CPU nicht erreichen kann.

Diese Schritte sind es, die einen Hardware-in-the-Loop-Simulationstechnologie überhaupt einen Umrichter mit hoher Schaltfrequenz darstellen lassen. Veröffentlichte FPGA-Implementierungen berichten von einem Schritt von etwa 240 Nanosekunden für einen zweistufigen Wechselrichter, der von 20-kHz-PWM angetrieben wird (mit einem 80-Nanosekunden-Schritt für eine gekoppelte Permanentmagnetmaschine), von Schritten in der Größenordnung von 100 Nanosekunden zum Auflösen von Strom- und Spannungswelligkeit auf Schaltfrequenz und von Schritten bis hinunter zu 25 Nanosekunden, um die Genauigkeit bei einer Schaltfrequenz von 200 kHz zu halten. Genau das ist der Bereich, in dem die FPGA-Ausführung nicht mehr optional, sondern notwendig wird. Unser CHP-Serie lässt Anlagenmodelle auf FPGA-Fabric mit Zeitschritten von nur 90 Nanosekunden laufen – in der Größenordnung von elf Millionen Modellaktualisierungen pro Sekunde – und deckt dabei auf einer einzigen Plattform Sub-Mikrosekunden-Schalttransienten bis hin zum langsameren elektromechanischen Verhalten des umgebenden Netzes ab.

Wide-Bandgap-Bauelemente machen dies unverzichtbar. Siliziumkarbid- (SiC) und Galliumnitrid- (GaN) Transistoren schalten weit schneller und bei höheren Frequenzen als herkömmliches Silizium; SiC-Bauelemente schalten in zehn bis hunderten Nanosekunden ein, und GaN-Bauelemente können in unter 10 Nanosekunden schalten. Um ein PWM-Signal sauber zu erfassen, müssen Sie es viele Male schneller abtasten, als es schaltet, was den erforderlichen Simulationsschritt in den Sub-Mikrosekunden- und Nanosekundenbereich drückt – Echtzeitstudien auf Bauelementebene von Elektrofahrzeug-Umrichtern, die bis zu 100 kHz schalten, haben detaillierte Schaltverläufe in Sub-Mikrosekunden-Schritten mit Nanosekunden-Auflösung aufgelöst. Nur ein FPGA-basierter Hardware-in-the-Loop-Simulationstechnologie kann dieses Timing halten und zugleich die Schleife mit einem realen Controller geschlossen halten. Ohne Ausführung in FPGA-Klasse können Sie einen modernen Umrichter mit hoher Schaltfrequenz schlicht nicht in Echtzeit abbilden – der Test wäre ungültig, bevor er begonnen hat. Deshalb ist die richtige HIL-Simulator -Architektur für leistungselektronische Hochgeschwindigkeitstests entscheidend, während ein deterministischer HIL-Simulator unverzichtbar ist, wenn jeder Simulationsschritt seine Frist einhalten muss.

Device Under Test (DUT) Desktop-Simulation Hardware-in-the-Loop Power-HIL-Tests
EV-Antriebsstrang
Kartenbild 1
Embedded Controller
EV-Antriebsstrang-Modellierung in Matlab Simulink
Kartenbild 2
Modellbasierte Entwicklung
Impedyme-Prüfstand als digitaler Zwilling des Anlagen-Controllers
Kartenbild 3
Controller unter Test (Signalebene)
Elektrischer Antriebsstrang
Kartenbild 4
Wechselrichter + Controller unter Test (Leistungsebene)
Pfeil

Impedyme-HIL-System

Unser Hardware-in-the-Loop-System ist als eine integrierte Architektur aufgebaut und nicht als Sammlung lose verbundener Boxen. Das Entwurfsziel ist einfach: ein einziges Modell vom Desktop bis zur vollständigen Leistungsvalidierung tragen, ohne es je neu zu schreiben, und die gesamte Kampagne von einem Arbeitsplatz aus steuern.

Im Zentrum steht die FPGA-basierte Echtzeit-Engine, die das Anlagenmodell löst, umgeben von der I/O, Signalkonditionierung und den Kommunikationsschnittstellen, die sie mit dem DUT verbinden. Über dieser Hardware läuft eine Softwareschicht, die das System konfiguriert, das Modell bereitstellt, die Tests sequenziert, die Daten erfasst und die Berichte erzeugt. Weil diese Elemente gemeinsam entworfen sind, verhält sich das Hardware-in-the-Loop-System als kohärentes Ganzes: im Modell definierte Signale erscheinen direkt auf physischen Kanälen, und auf diesen Kanälen erfasste Ergebnisse fließen direkt in die Modellierungsumgebung zurück.

Der Modellimportpfad ist bewusst reibungslos gestaltet. Ingenieure erstellen ihre Anlagen- und Controllermodelle in einer Simulink-ähnlichen Umgebung und bringen sie über unser dediziertes Blockset auf das Echtzeitziel, sodass ein Modell ohne manuelles Neuschreiben zu einem Echtzeitziel wird. Das ist die praktische Bedeutung eines Hardware-in-the-Loop-Simulink- Workflows: dasselbe Blockdiagramm, das Sie offline simuliert haben, wird zu dem, was in Echtzeit gegen Ihren Controller ausgeführt wird, mit im laufenden Betrieb abstimmbaren Parametern und live in der Modellierungsumgebung angezeigten Messungen.

Unser Hardware-in-the-Loop-Tools decken den gesamten Workflow ab. Konfigurations- und Automatisierungstools richten das System ein und skripten ganze Kampagnen; domänenspezifische Studios liefern fertige Modelle für Motoren, Batterien, Netze und Drohnen; ein integriertes hochauflösendes Oszilloskop erfasst Wellenformen direkt aus dem FPGA-Signalpfad; und eine Rapid-Control-Prototyping-Option lässt Sie Controller-Algorithmen gegen ein hochpräzises Modell entwickeln, bevor eine Leistungsstufe existiert. Zusammen verwandeln diese Hardware-in-the-Loop-Tools ein nacktes Echtzeitziel in einen vollständigen, softwaregesteuerten Prüfstand, den Ingenieure, die mit modellbasierter Entwicklung vertraut sind, ohne handgeschriebene FPGA-Firmware bedienen können.

 

 

 

Von Signal zu Leistung: Ein vollständiger Test-Workflow

Die Validierung von Leistungselektronik erfolgt typischerweise in drei zentralen Stufen:

Symbol Signalebene

Signal-Level-Testing

Simulation des gesamten Systems zur Validierung der Steuerungselektronik in einer geschlossenen Regelkreisschleife.

Symbol Leistungsebene

Power-Level-Testing

Integration eines Motor-Emulators zur Bewertung sowohl der Regelungslogik als auch der Leistungshardware.

Symbol mechanische Prüfung

Mechanisches/Dynamometer-Testing

Abschließende Systemvalidierung unter realen mechanischen Lastbedingungen.

 
 

Was sind HIL-Branchen?

Hardware-in-the-Loop (HIL) -Tests werden branchenübergreifend eingesetzt, wo eingebettete Controller, Leistungselektronik und Steuersoftware unter realistischen Betriebsbedingungen validiert werden müssen. Durch das Verbinden realer Hardware mit einer Echtzeitsimulation können Ingenieure Hardware-in-the-Loop-Test -Szenarien durchführen, ohne sich vollständig auf physische Prototypen zu verlassen. Ein Hardware-in-the-Loop-Simulationstechnologie liefert die Echtzeitumgebung, die zur Reproduktion komplexer Betriebsbedingungen und Fehler nötig ist.


HIL auf Signalebene vs. Power-Hardware-in-the-Loop (PHIL)

Dies ist die Unterscheidung, die bestimmt, was Ihre Validierung tatsächlich beweist, und sie verdient volles Gewicht. Das Wort „HIL“ umfasst zwei grundlegend verschiedene Anordnungen, und sie zu verwechseln ist einer der teuersten Fehler, die ein leistungselektronisches Programm machen kann. Zu verstehen, wie Hardware-in-the-Loop-(HIL) auf Signal- und Leistungsebene funktioniert, ist entscheidend für die Wahl des richtigen Validierungsansatzes.

Controller-Hardware-in-the-Loop (C-HIL): nur Niederspannungssignale

Bei Controller-Hardware-in-the-Loop tauschen Simulator und DUT nur Signale geringer Leistung aus. Das Echtzeitmodell speist dem Controller analoge Spannungen und Ströme auf Messebene ein, die das darstellen, was seine Sensoren sehen würden, und liest die Gate-Befehle, Sollwerte und digitalen Ausgänge des Controllers zurück. Es fließt niemals reale Leistung. C-HIL ist hervorragend in dem, was es tut: Es validiert Steuerlogik, Zustandsmaschinen, Kommunikation, Schutzsequenzierung und die Qualität der Controller-Schnittstellen – und das sicher und kostengünstig. Was es nicht kann, ist beweisen, wie sich die Leistungsstufe verhält. Weil der Controller nie realen Strom treibt, sagt C-HIL nichts über thermisches Verhalten, Durchlass- und Schaltverluste, elektromagnetische Störungen oder die Art und Weise aus, wie ein realer Umrichter mit einer realen Quellen- und Lastimpedanz interagiert. Es beweist das Gehirn, nicht die Muskeln.

Power-Hardware-in-the-Loop (PHIL): realer Strom und reale Spannung durch das DUT

Power-Hardware-in-the-Loop schließt diese verbleibende Lücke, indem es reale Leistung in die Schleife bringt. Ein bidirektionaler Vierquadranten-Leistungsverstärker sitzt zwischen dem Echtzeitsimulator und dem DUT, nimmt die Niederpegelsignale des Modells und reproduziert sie als reale Spannung und realen Strom auf den Pegeln, auf denen das Gerät tatsächlich arbeitet – und, entscheidend, speist und senkt Energie, sodass das DUT echte elektrische Belastung und Rückspeisung erfährt. Nun wird das zu prüfende Gerät so beansprucht, wie es im Betrieb beansprucht wird. Nur bei Leistung sehen Sie die thermischen Effekte realer Durchlass- und Schaltverluste, die elektromagnetischen Störungen, die reale Schaltflanken erzeugen, und die Impedanzwechselwirkungen zwischen einem realen Umrichter und seiner Umgebung. Der Verstärker befindet sich nun innerhalb des Regelkreises, was PHIL zugleich leistungsstark und anspruchsvoll macht: Schleifenverzögerung, Verstärkerbandbreite und die Stabilität der Leistungsschnittstelle werden allesamt zu technischen Belangen, die mit sorgfältigen Schnittstellenalgorithmen und latenzarmen Glasfaserverbindungen beherrscht werden müssen. Hardware-in-the-Loop-(HIL) und Power-HIL-Architektur vereint Tests auf Signalebene und bei voller Leistung mit Rückspeisung auf einer einzigen FPGA-basierten Plattform, genau damit Teams nicht wählen müssen.

 

Welches brauchen Sie?

Die ehrliche Antwort ist, dass die meisten ernsthaften Programme beides brauchen, in Folge: zuerst C-HIL, um die Logik auszuarbeiten, dann PHIL, um die Integration bei Leistung zu beweisen. Die folgende Tabelle ordnet die Wahl DUT-Typ und Entwicklungsstufe zu.

DUT-Typ / StufeFrühe EntwicklungIntegration / Vorzertifizierung
Wechselrichter- oder Umrichter-ControllerC-HIL zur Validierung von Steuerlogik, PWM, SchutzsequenzierungPHIL, um thermische, EMI- und Impedanzwechselwirkungseffekte bei Nennleistung aufzudecken
BatteriemanagementsystemC-HIL mit Zellemulation für Logik und DiagnosePower-HIL, um reale Packströme anzulegen und den Leistungspfad zu beanspruchen
MotorantriebC-HIL zur Stromregelkreis-Abstimmung und FehlerbehandlungPHIL mit Motoremulation mit Rückspeisung für echte Last und Rekuperation
Netzgekoppelter / Smart InverterC-HIL für Netzanschluss-Zustandsmaschinen und KommunikationPHIL, um Durchfahrt und Stabilität gegen einen realen Verstärker zu beweisen
Schutzrelais / Microgrid-ControllerC-HIL für KoordinationslogikPHIL, wo reale Leistungsinteraktion zählt

Fehlerinjektion, Grenzfälle und Testautomatisierung

Das Wertvollste, das Hardware-in-the-Loop-(HIL) Ihnen gibt, ist die Möglichkeit, einen Fehler – einen wirklich zerstörerischen – so oft Sie wollen, identisch und ohne Risiko auszuführen. Das ist das Argument für HIL-Fehlerinjektion in einem Satz, und alles andere folgt daraus.

Betrachten Sie die Fehler, die in der Leistungselektronik zählen: ein Kurzschluss über einen Umrichterzweig, eine offene Phase in einem Motorantrieb, Sensordrift, die einen Regelkreis langsam verfälscht, ein Kommunikationsausfall auf einem kritischen Bus, ein Netzfehler, der Durchfahrt verlangt, oder ein thermisches Durchgehen in einer Batteriezelle. Jeder davon ist teuer, gefährlich oder unmöglich wiederholt an realer Hardware zu inszenieren. In einer Hardware-in-the-Loop-Umgebung sind sie nur Parameter. Sie injizieren einen Kurzschluss, indem Sie einen modellierten Schalter umlegen, driften einen Sensor durch Hinzufügen eines Offsets in Software, lassen eine Nachricht fallen, indem Sie einen Busknoten deaktivieren, oder inszenieren einen Netzfehler, indem Sie das Modell befehligen – und das tun Sie, ohne dass der Controller etwas merkt, denn für den Controller ist der Fehler vollständig real.

Wiederholbarkeit ist der Kern des Arguments. Ein Fehler, den Sie einmal ausführen können, sagt Ihnen, was dieses eine Mal geschah. Ein Fehler, den Sie 500 Mal identisch ausführen können, sagt Ihnen, ob Ihr Schutz zuverlässig ist, lässt Sie genau eingrenzen, welche Firmware-Änderung ihn zerbrach, und gibt Ihnen das statistische Vertrauen, das ein Sicherheitsnachweis verlangt. Physisches Fehlertesten kann selten auch nur ein paar Mal wiederholt werden, bevor etwas beschädigt wird; HIL-Tests wiederholen es unbegrenzt und deterministisch.

Dieser Determinismus macht Automatisierung lohnenswert. Sobald ein Fehlerszenario als Testfall mit festem Anfangszustand, definiertem Stimulus und numerischer Bestehens-/Nichtbestehens-Regel definiert ist, kann es einer Regressionssuite beitreten, die bei jeder Codeänderung automatisch erneut läuft. Jeder Firmware-Commit kann eine vollständige Testkampagne mit geschlossener Schleife auslösen – Sweeps über Betriebspunkte, Grenzfälle und die gesamte Bibliothek injizierter Fehler – mit automatisierten Bestehens-/Nichtbestehens-Kriterien, konfigurierbaren Sicherheitsgrenzen, kontrolliertem Abschalten und hochauflösender Wellenformerfassung, die einen versionierten, nachvollziehbaren Datensatz erzeugt. Das ist die Grundlage einer Continuous-Integration-Pipeline für Leistungselektronik: Monate der Entwicklung, und jedes Ergebnis ist noch mit dem ersten vergleichbar.

Was in einem Hardware-in-the-Loop-Prüfstand steckt

Ein vollständiger Hardware-in-the-Loop-(HIL) -Prüfstand ist ein Stapel klar definierter Bausteine. Nutzen Sie dies als Checkliste, wenn Sie einen spezifizieren. Ein Hardware-in-the-Loop-Simulationstechnologie bringt diese Elemente zusammen, um eine vollständige Testumgebung zu schaffen. 

  • Echtzeitsimulator. Die FPGA-basierte (und für langsamere Dynamiken CPU-basierte) Engine, die das Anlagenmodell deterministisch bei dem Zeitschritt löst, den Ihre schnellsten Dynamiken verlangen. Für schaltende Umrichter muss dies in den Sub-Mikrosekunden- und Nanosekundenbereich reichen.
  • I/O und Signalkonditionierung. Analoge Ein- und Ausgänge, digitale I/O, PWM-Erfassung, Encoder- und Resolver-Emulation sowie Schutzleitungen – mit einer Konditionierung, die Spannungspegel, Isolation und Erdung auf beiden Seiten korrekt macht.
  • Breakout und DUT-Schnittstelle. Die physische Verbindungsschicht, die Signale sauber zum Controller führt, geschirmt und geerdet, um Störungen durch Schaltflanken zu überstehen.
  • Leistungsverstärkung (für PHIL). Ein bidirektionaler Vierquadranten-Verstärker, dimensioniert, um die reale Spannung und den realen Strom des DUT zu speisen und zu senken, über latenzarme Glasfaser mit dem Simulator verbunden.
  • Modellerstellung und Importpfad. Eine Simulink-ähnliche Modellierungsumgebung plus ein Blockset, das Modelle ohne Neuschreiben auf das Echtzeitziel bringt.
  • Testautomatisierung und Protokollierung. Skripting für Sweeps, Sequenzen und bedingte Logik; automatisierte Bestehens-/Nichtbestehens-Regeln; und Hochgeschwindigkeits-Datenlogging mit Konfigurations- und Firmware-Kennungen zur Reproduzierbarkeit.
  • Überwachung. Ein hochauflösendes Oszilloskop, eingebettet in den FPGA-Signalpfad, plus Live-Signalsichtbarkeit, sodass Transienten ohne externe Instrumente erfasst werden.

Dimensionierungshinweis – zählen Sie Ihre Kanäle, bevor Sie kaufen. Der häufigste Beschaffungsfehler ist das Unterschätzen der I/O. Bevor Sie einen Prüfstand spezifizieren, zählen Sie jedes Signal, das das DUT austauscht: analoge Sensoremulationen hinaus, Referenzen und Messungen hinein, jede PWM- oder Gate-Leitung zum Erfassen, Encoder- und Resolverkanäle, jede Schutz- und Freigabeleitung und jeden Kommunikationsbus. Fügen Sie die Fehlerinjektionspunkte hinzu, die Sie nutzen wollen. Fügen Sie dann Reserve hinzu – der Validierungsumfang wächst stets – und gleichen Sie die Zahl mit der Kanalkapazität pro Modul des Simulators ab, wobei Sie bedenken, dass Module parallelgeschaltet und über Glasfaser synchronisiert werden können, um hunderte Kanäle zu erreichen. Für PHIL dimensionieren Sie den Verstärker auf die reale Leistungsnennung des DUT mit Reserve für Transientenstrom, nicht nur für den stationären Zustand. Kanalzahl und Leistungsnennung von vornherein richtig zu treffen, unterscheidet einen Prüfstand, der mit Ihrem Programm wächst, von einem, den Sie in einem Jahr überwachsen.

Einheitliche Plattform: Impedyme RT + Simulation Toolkit

Die Impedyme-Hardware-in-the-Loop-Plattform

Unsere Plattform ist so konzipiert, dass jede Fähigkeit eine Architektur, eine Zeitdomäne und einen Arbeitsplatz teilt. So fügen sich die Teile zusammen. Hardware-in-the-Loop-Testen kann sich dann von der Modellentwicklung über die Controller-Validierung bis hin zu Tests bei voller Leistung bewegen, ohne die Kernarchitektur zu ändern. 

CHP-Serie. Die CHP Series ist unsere kombinierte HIL- und Power-HIL-Hardwareplattform – eine FPGA-basierte, rückspeisefähige Architektur, die Echtzeitsimulation, Leistungsverstärkung, Messung und Steuerung in einem System vereint. Sie lässt Anlagenmodelle auf FPGA-Fabric mit Zeitschritten von nur 90 Nanosekunden laufen und bietet mehrkanalige analoge und digitale I/O plus Hochgeschwindigkeits-Glasfaser, erhältlich als CHP 150 im Halbschrank und CHP 300 im Vollschrank, sodass ein Programm vom Tischgerät bis zur Rack-Ebene skalieren kann. Entdecken Sie die CHP Series.

PowerHIL Studio. Dies ist die Orchestrierungs- und Automatisierungsschicht, die die Hardware in einen softwaregesteuerten Prüfstand verwandelt. Sie konfiguriert das System, stellt Modelle bereit, sequenziert und skriptet ganze Testkampagnen, koordiniert Aufbauten mit mehreren Emulatoren und erzeugt nachvollziehbare Berichte aus einem in die Modellierungsumgebung integrierten Arbeitsplatz. Siehe PowerHIL Studio.

BatterySim Studio. Unsere Batterieemulationsumgebung vereint Impedanzmessung, Modellanpassung, Echtzeit-HIL- und Power-HIL-Zellemulation sowie Live-Fehlerdiagnose – skalierend von einer einzelnen Tischzelle bis zu einem Megawatt-Traktionspack. So trifft ein BMS auf einen realistischen digitalen Batteriezwilling. Entdecken Sie BatterySim Studio.

GridSim Studio. Dies übernimmt Netzemulation und Konformitätsprofile und lässt Ingenieure Durchfahrtsereignisse, Fehler, Oberschwingungen und Impedanzbedingungen inszenieren und automatisierte Netzanschluss-Konformitätskampagnen gegen netzgekoppelte Geräte durchführen. Siehe GridSim Studio.

MotorSim Studio. Unsere hochpräzise Motor- und Antriebsumgebung bietet Modellbibliotheken für PMSM-, Induktions-, BLDC- und IPM-Maschinen mit nichtlinearen Effekten und winkelabhängigen Fluss- und Drehmomentkennfeldern, die alle die Aktualisierungsrate der Plattform im Nanosekundenbereich nutzen. Entdecken Sie MotorSim Studio.

DroneSim Studio. Dies erweitert dieselbe Echtzeitarchitektur auf elektrischen Antrieb und Drohnen-Antriebsstränge und lässt Teams mehrere gekoppelte Antriebsmotoren für die Validierung von Antriebscontrollern emulieren. Siehe DroneSim Studio.

FPGA Scope. Integrierte Signalvisualisierung im Sub-Mikrosekundenbereich mit mehreren Kanälen und triggerbasierter Erfassung, direkt in den FPGA-Signalpfad eingebettet, sodass Transienten ohne externe Instrumente erfasst werden. Entdecken Sie FPGA Scope.

HIL/RCP-Box. Eine kompakte Rapid-Control-Prototyping-Plattform zur Entwicklung und Validierung von Controller-Algorithmen gegen ein hochpräzises Echtzeitmodell, bevor eine Leistungsstufe existiert – der schnelle Weg von der Steuerungsidee zum experimentellen Nachweis. Siehe RCP-Box.

Impedyme-RT. Unsere Echtzeit-Ausführungs-Engine untermauert die Plattform und bietet den konfigurationsgesteuerten Workflow mit wiederverwendbaren Assets, der Testassets von der Offline-Simulation über HIL auf Signalebene bis zur vollständigen Hardware ohne Nacharbeit trägt. Dies unterstützt Hardware-in-the-Loop-Simulation über dieselbe wiederverwendbare Plattform hinweg. 

Impedyme Simulink-Blockset. Das Blockset ist die Brücke zwischen modellbasierter Entwicklung und realer Hardware: Es bringt Anlagen- und Controllermodelle ohne Neuschreiben von der Desktop-Simulation zur Echtzeitausführung, stellt Hardware-Peripherie als Blöcke dar und ermöglicht Live-Parameterabstimmung und -messung innerhalb der Modellierungsumgebung. Das macht Hardware-in-the-Loop-Testen leichter in bestehende modellbasierte Workflows integrierbar.

Fazit

Hardware-in-the-Loop ist zur entscheidenden Validierungsstufe für moderne Leistungselektronik geworden, denn es ist der eine Ort, an dem der Code, den Sie ausliefern, das Timing, das Sie erhalten, und die Fehler, die Sie fürchten, alle in einer kontrollierten, wiederholbaren Schleife zusammenkommen. HIL auf Signalebene beweist die Steuerlogik; Power-Hardware-in-the-Loop beweist die Integration bei realem Strom und realer Spannung; und FPGA-basiertes Lösen – mit Zeitschritten bis in den Nanosekundenbereich – macht es möglich, die heutigen schnellschaltenden SiC- und GaN-Umrichter getreu statt nur näherungsweise abzubilden. Die Programme, die erfolgreich sind, sind diejenigen, die die Validierungslücke als erstrangiges Risiko behandeln und sie bewusst schließen, vom Desktop-Modell bis zum Prüfstand bei voller Leistung. Genau das bauen wir. Wenn Sie abwägen, wo Hardware-in-the-Loop-(HIL) in Ihren Entwicklungsablauf passt, ist der richtige nächste Schritt, Ihre DUTs und Entwicklungsstufen den obigen C-HIL- und PHIL-Optionen zuzuordnen, Ihre Kanäle und Leistungsnennungen ehrlich zu zählen und mit uns darüber zu sprechen, ein Modell von der Simulation bis zur Validierung auf Leistungsebene zu tragen.

Häufig gestellte Fragen

Welchen Simulationszeitschritt braucht HIL?
Es hängt von den schnellsten Dynamiken ab. Netz- und Energiesystemmodelle sind oft nahe 50 Mikrosekunden in Ordnung, aber schaltende Leistungsumrichter brauchen weit kleinere Schritte: Ein grober Schritt verpasst Schaltereignisse vollständig. Hochfrequenzumrichter erfordern typischerweise Schritte von einigen hundert Nanosekunden bis hinunter zu zehn Nanosekunden, weshalb FPGA-basiertes Lösen – mit Schritten von nur 90 Nanosekunden auf unserer Plattform – unverzichtbar ist.
Warum wird für die HIL-Simulation ein FPGA verwendet?
Ein FPGA löst das Anlagenmodell in massiv paralleler Logik mit Verarbeitung und I/O auf einem Chip und liefert deterministische, jitterfreie Ausführung bei Zeitschritten, die eine CPU nicht erreichen kann. Das ist wichtig, weil Leistungsumrichter schneller schalten, als eine CPU folgen kann; nur ein Timing in FPGA-Klasse kann einen SiC- oder GaN-Umrichter mit hoher Schaltfrequenz in Echtzeit abbilden, ohne Overruns, die das Ergebnis ungültig machen würden.
Welche Arten von Systemen können mit einem HIL-System getestet werden?
Nahezu jeder Controller, der elektrische Leistung oder Bewegung steuert: EV-Traktionswechselrichter, Batteriemanagementsysteme, Motorantriebe, Solar- und netzgekoppelte Wechselrichter, Microgrids, HVDC-Steuerungsrepliken, DC-Schnellladegeräte, eVTOL- und Flugzeugstromversorgung, Schiffsstromversorgung, Robotercontroller und Rechenzentrums-Stromversorgungsinfrastruktur. Überall dort, wo ein realer Controller sicherheitskritische Software ausführt, kann ein HIL-System ihn validieren.
Ersetzen Hardware-in-the-Loop-Tests physische Prototypen?
Nein – sie reduzieren sie und mindern ihr Risiko. Hardware-in-the-Loop ersetzt den Großteil des gefährlichen, teuren und repetitiven Testens, erkennt Fehler früh und deckt Fehler ab, die kein physischer Prüfstand sicher inszenieren könnte. Aber eine abschließende physische Validierung bleibt wichtig, und ein HIL-Ergebnis ist nur so gut wie sein Modell. HIL macht physisches Testen kürzer, sicherer und gezielter, statt es zu eliminieren.
Was bestimmt Kosten und Umfang eines HIL-Prüfstands?
Der Umfang wird hauptsächlich von drei Dingen bestimmt: Kanalzahl (wie viele analoge, digitale, PWM-, Encoder-, Schutz- und Kommunikationssignale das DUT austauscht), Leistungsnennung (ob Sie nur HIL auf Signalebene oder einen auf realen DUT-Strom und -Spannung dimensionierten Leistungsverstärker für PHIL brauchen) und Automatisierungstiefe (das Ausmaß skriptgesteuerter Kampagnen, Fehlerbibliotheken und Regressionssuiten). Kanäle und Leistungsbedarf von vornherein ehrlich zu zählen, ist der Schlüssel zur richtigen Dimensionierung.

Produkte