Leitfaden Hardware vs. software für Ingenieur:innen

Wichtigste Erkenntnisse

• Software-in-the-Loop eignet sich für die frühzeitige Validierung der Steuerung, da es Logikfehler schnell aufdeckt und umfassende Regressionstests bei geringem Einrichtungsaufwand ermöglicht.
• Hardware„In-the-Loop“ wird notwendig, sobald Timing, „ I/O “ und eingebettete Schnittstellen das Verhalten des Controllers beeinflussen können.
• Teams erzielen den besten Validierungsablauf, wenn SIL, PIL und HIL Modelle, Testziele und Erfolgskriterien über alle Phasen hinweg gemeinsam nutzen.

Entscheiden Sie sich für „ Software-in-the-Loop“, wenn Ihr nächstes Risiko in der Steuerungslogik liegt, und für „ Hardware-in-the-Loop“, wenn Ihr nächstes Risiko in den Bereichen Timing, I/O und Embedded-Integration liegt.

Teams verlieren Zeit, wenn sie über Bezeichnungen diskutieren, anstatt die Testphase auf den Fehler abzustimmen, den sie aufdecken müssen. Eine mangelhafte Qualität der „ software “ kostete die Vereinigten Staaten im Jahr 2020 mindestens 2,08 Billionen US-Dollar im Jahr 2020. Diese Zahl ist hier von Bedeutung, da eine verspätete Fehlerentdeckung in der Regel Nacharbeiten am Prüfstand, Terminverzögerungen und wiederholte Kalibrierungen zur Folge hat. Eine solide Validierung erfolgt in der Reihenfolge von Entwicklungsmodellen ( software ) über kompilierten Code bis hin zur Zeitmessung in der Ausführungsumgebung ( hardware ), um das nächste Risiko mit dem geringsten Aufwand zu beseitigen.

SIL validiert das Regelverhalten, noch bevor die physikalische „ I/O “ vorliegt

Software„In-the-Loop“-Tests überprüfen die Regelungslogik anhand einer simulierten Anlage, bevor ein Zielregler oder eine Leistungsstufe auf Ihren Prüfstand gelangt. Sie führen die Regelung als Modellcode oder Host- software “ aus. Fehler bleiben sichtbar und lassen sich leicht zurückverfolgen. SIL eignet sich für frühe Entwurfs-, Kalibrierungs- und Regressionstests.

Ein Team für Motorsteuerung kann mithilfe von SIL Strombegrenzungen, Drehmomentrampen und Fehlerbehebungstests durchführen, lange bevor die Umrichter hardware en verkabelt sind. Dasselbe gilt für ein Flugsteuerungsgesetz, das Sensorrauschen unterdrücken muss, ohne Schwingungen zu verursachen. Jeder Fehlfall lässt sich auf Gleichungen, Verstärkungsfaktoren oder Zustandslogik zurückführen, die Sie dank uneingeschränkten Signalzugriffs überprüfen können. Diese Transparenz reduziert den Zeitaufwand für das Rätselraten, wo das Verhalten vom Soll abweicht.

Mit SIL lassen sich zudem kostengünstig Wiederholungen durchführen. Man kann über Nacht Tausende von Szenarien durchspielen, einen Parameter ändern und die Ergebnisse noch vor der Mittagspause vergleichen. Diese Geschwindigkeit ist besonders wichtig, wenn sich die Anforderungen noch festigen und sich der Code täglich ändert. Ein Bench hardware us würde diesen Zyklus verlangsamen, da jeder erneute Test das Flashen von Geräten, die Überprüfung der Verkabelung und den Zugang zum Labor erfordert.

HIL validiert eingebettete Schnittstellen unter Echtzeitbedingungen

Hardware-in-the-Loop verbindet den tatsächlichen Regler mit einem Anlagenmodell, das in Echtzeit läuft, sodass Sie das Verhalten von „ software “ unter denselben zeitlichen und I/O Bedingungen überprüfen können, wie sie im Betrieb auftreten werden. Der Fokus verlagert sich von der beabsichtigten Funktionsweise des Algorithmus hin zur tatsächlichen Ausführung. HIL deckt versäumte Fristen, Fehler bei der Signalaufbereitung und Schnittstellenfehler auf.

Ein Bremsregler ist ein anschauliches Beispiel dafür. Das Anlagenmodell übermittelt Radgeschwindigkeit, Pedaleingabe und Hydraulikzustände an das Steuergerät und erhält im Gegenzug Ventilbefehle mit strengen Taktzeiten zurück. Bei Verkehrsunfällen kamen im Jahr Vereinigten Staaten im Jahr 2022. Sicherheitsfunktionen müssen auf dem Prüfstand validiert werden, um Zeitablauf- und Schnittstellenfehler zu erkennen, bevor der Fahrzeug- oder Strecken Tests us beginnt.

HIL spielt dann eine Rolle, wenn Ihre größte Unbekannte an der Grenze zwischen software und hardware liegt. ADC-Skalierung, PWM-Latenz, CAN-Nachrichtenverarbeitung und Reaktionen auf Fehlerpins sehen in einem Desktop-Modell oft einwandfrei aus, versagen jedoch im Labor. Diese Diskrepanz ist der Grund, warum Teams HIL als Integrationsfilter betrachten und nicht nur als einen besseren Simulator. Es liefert Ihnen den Nachweis, dass sich der Regler auch dann noch korrekt verhält, wenn die Taktvorgaben streng sind und die Signale physikalisch vorliegen.

Die Zeitgenauigkeit bildet die Grenze zwischen SIL und HIL

„Der Hauptunterschied zwischen ‚ Software-in-the-Loop‘ und ‚ Hardware-in-the-Loop‘ besteht in der deterministischen Zeitsteuerung sowie der elektrischen Wechselwirkung.“

SIL prüft die Logik anhand der Ausführung von „ Flexibel “ auf einem Host-Rechner. HIL prüft die Ausführung unter festen Abtastzeiten und physikalischen Schnittstellen. Diese Grenze bestimmt, welche Fehler erkannt werden und welche übersehen werden.

Ein Batteriemanagement-Controller verdeutlicht dies anschaulich. Die Logik zum Zellausgleich mag im SIL-Test perfekt erscheinen, doch kann es dennoch vorkommen, dass das eingebettete Gerät während des HIL-Tests das Interrupt-Timing oder die Skalierung des analogen Frontends falsch handhabt. Deshalb ist die zeitliche Genauigkeit der entscheidende Faktor – nicht der Modellname oder die Präferenz des Teams. Sobald die Taktgenauigkeit und die physikalischen Schnittstellen über Bestehen oder Nichtbestehen entscheiden, haben Sie den Bereich des HIL-Tests betreten.

SIL funktioniert am besten, wenn Codeänderungen schneller voranschreiten als der Zugriff auf „ hardware “

SIL ist die richtige erste Anlaufstelle, wenn die Revisions von „ software “ schneller eintreffen, als Ihr Teststand sie verarbeiten kann. Sie können die funktionale Absicht validieren, Parameter optimieren und die Regressionsabdeckung erweitern, ohne auf Platinen, Kabelbäume oder Laborplätze warten zu müssen. Das macht SIL zur praktischen Wahl während aktiver Designänderungen. So können sich „ Ingenieur:innen “ auf die Logik konzentrieren, statt sich mit dem Aufwand für die Einrichtung zu beschäftigen.

Ein Team für die Steuerung von Energiespeichern kann Ladegrenzen, thermische Schwellenwerte und Moduswechsel anhand eines Anlagenmodells testen, das den Akku und den Wechselrichter abbildet. Ein neuer Steuerungszweig kann noch am selben Tag überprüft werden, an dem er in die Versionsverwaltung aufgenommen wird. Testfälle können zudem mit Anforderungen verknüpft werden, sodass ein fehlgeschlagenes Update direkt auf den betroffenen Logikpfad hinweist. Ein solcher Zyklus lässt sich nur schwer aufrechterhalten, sobald ein gemeinsamer „ hardware “-Test in den Zeitplan aufgenommen wird.

SIL eignet sich auch für Fehlerkampagnen, deren Durchführung an physischen Geräten umständlich oder unsicher wäre. Man kann unrealistische Sensorspitzen, fehlerhafte Zustandsschätzungen oder extreme Lastwechsel simulieren, ohne eine Beschädigung durch „ hardware “ zu riskieren. Diese Fälle schärfen den Regler, bevor die Arbeit an der Schnittstelle beginnt. Teams, die diese Phase überspringen, verschieben grundlegende Logikfehler meist in spätere Testphasen, wo deren Isolierung mehr Zeit in Anspruch nimmt.

HIL zahlt sich aus, wenn sich das Integrationsrisiko auf die Schnittstellen verlagert

HIL bewährt sich, wenn sich der Schwerpunkt Ihrer Unsicherheit von der „ software “-Logik hin zu Timing, Verdrahtung, Busse und eingebetteter I/O verlagert. Der Test auf dem Prüfstand zeigt, ob sich der Controller noch korrekt verhält, wenn Scheduler, Interrupts, Wandler und Kommunikation gleichzeitig aktiv sind. Damit wird eine andere Frage als bei SIL beantwortet. Hier wird die Ausführung unter Belastung getestet.

Ein Regler für die Leistungselektronik veranschaulicht dies sehr gut. Gate-Befehle, Auslösesignale und Stromrückführung können in einem Host-Modell zwar einwandfrei aussehen, doch im Labortest können beschnittene Messbereiche, verspätete Abtastung oder eine fehlerhafte Dead-Time-Behandlung zutage treten. Durch die Sensor-Emulation lassen sich zudem Leitungsfehler, fehlende Impulse oder verrauschte Messwerte simulieren, ohne dabei eine Hochleistungsanlage zu gefährden. Diese Tests sind wichtig, da Schnittstellenfehler oft erst dann sichtbar werden, wenn der Regler auf die physikalischen Signalwege trifft.

HIL unterstützt zudem Abnahmegespräche besser als eine reine Schreibtischsimulation. Sie können genaue Reaktionszeiten, Busauslastungen und die Fehlerbehebung an den Controller-Pins veranschaulichen. Diese Erkenntnisse helfen technischen Leitern bei der Entscheidung, ob ein System bereit für den Einsatz auf dem Prüfstand, im Testlabor oder im Feld ist. Die Methode ist zwar teurer als SIL, macht sich aber bezahlt, wenn Integrationsprobleme die Hauptursache für Verzögerungen sind.

PIL überprüft den kompilierten Code vor der vollständigen Integration in „ hardware “

„Processor-in-the-Loop“ (PIL) liegt zwischen „ software “-Modellen und vollständigen „ hardware “-Testumgebungen. Dabei wird kompilierter Reglercode auf dem Zielprozessor oder einer den Prozessor repräsentierenden Platine ausgeführt, während die Anlage im „ software “ verbleibt. Dadurch werden Probleme bei der Codegenerierung, numerische Abweichungen und grundlegende Timing-Effekte sichtbar. PIL gibt Aufschluss darüber, ob der kompilierte Code noch der Modellabsicht entspricht.

Ein typisches Beispiel ist eine Festkomma-Regelungsroutine. Das Modell kann sich im Gleitkomma-Modus einwandfrei verhalten, zeigt jedoch Überlauf, Quantisierungsfehler oder Scheduler-Jitter, sobald der kompilierte Code auf dem Prozessor ausgeführt wird. PIL erkennt diese Abweichung, bevor Sie Zeit damit verbringen, einen kompletten HIL-Prüfstand aufzubauen. Dies ist besonders hilfreich bei automatisch generierten Reglern, bei denen das Modell zwar korrekt erscheint, die generierte Implementierung jedoch noch überprüft werden muss.

PIL wird HIL nicht ersetzen, da es weder das gesamte elektrische I/O noch das Schnittstellenverhalten auf der Prüfstandsebene abdeckt. Es beseitigt jedoch eine kostspielige mittlere Unsicherheitsschicht. Teams, die PIL sinnvoll einsetzen, gelangen mit weniger Überraschungen bei der Codegenerierung und saubereren Timing-Baselines zum HIL. Dadurch wird die spätere Integrationsarbeit überschaubarer und die Fehlersuche einfacher.

Die Kontinuität des Arbeitsablaufs ist wichtiger als jede einzelne Testphase

Ein fehlerhafter Übergang zwischen SIL, PIL und HIL kostet mehr Zeit als ein schwaches Ergebnis in einer einzelnen Phase. Sie benötigen konsistente Modelle, wiederholbare Testfälle und vergleichbare Bestehenskriterien, damit jede Phase neue Erkenntnisse liefert, anstatt Nacharbeiten zu erfordern. Die besten Arbeitsabläufe bewahren die Intention von der Desktop-Simulation bis zur Ausführung auf dem Prüfstand. Aus dieser Kontinuität ergibt sich die Einhaltung des Zeitplans.

Ein Kontrollteam kann über alle Phasen hinweg ein Anlagenmodell, eine Szenariobibliothek und ein Namensschema beibehalten. Ein Drehmomentbegrenzungstest, der in SIL fehlschlägt, sollte auch in PIL und HIL erkennbar sein, ohne dass die Abnahmelogik neu geschrieben werden muss. OPAL-RT erfüllt diese Anforderungen, da Teams Simulationsarbeiten aus der modellbasierten Validierung in Echtzeit-Testumgebungen übertragen können, ohne den gesamten Workflow jedes Mal neu aufbauen zu müssen. Diese Kontinuität verkürzt die Debugging-Zyklen und sorgt für konsistente Fehlernachweise über alle Tools und Labore hinweg.

Sie sichern zudem das Vertrauen in die Technik, wenn die Kette intakt bleibt. Wenn in jeder Phase unterschiedliche Annahmen zugrunde gelegt werden, verbringt das Team die Zeit für die Überprüfung damit, über die Rahmenbedingungen statt über das Verhalten zu diskutieren. Eine klare Kontinuität vereinfacht die Eskalation, da jeder Fehler eine nachvollziehbare Historie hat. Das ist wichtig für Laborleiter und technische Leiter, die Beweise benötigen und nicht nur Testaktivitäten.

Wählen Sie die Prüfmethode aus, mit der das nächste Risiko beseitigt wird

„Die Methode, der Sie Ihre nächste Stunde widmen sollten, ist diejenige, die mit dem geringsten Vorbereitungsaufwand den nächsten Fehler aufdeckt.“

Die richtige Entscheidung ist ganz einfach: Verwenden Sie SIL für Logik und Kalibrierung, PIL für die Überprüfung des kompilierten Codes und HIL für die Überprüfung des Timings sowie der Schnittstellen. Teams erzielen bessere Ergebnisse, wenn sie die nächste Stufe anhand des Fehlermodus und nicht aus Gewohnheit auswählen. Dieser Ansatz sorgt dafür, dass Kosten, Laborzeit und Debugging-Aufwand aufeinander abgestimmt sind.

• Entscheiden Sie sich für SIL, wenn der Zugriff auf das Modell und das Szenario-Volumen von entscheidender Bedeutung sind.
• Wählen Sie PIL, wenn der generierte Code einen Nachweis auf Prozessorebene erfordert.
• Wählen Sie HIL, wenn die Abtastzeit und die physikalische „ I/O “ das Ergebnis beeinflussen können.
• Gehen Sie erst dann weiter, wenn die aktuelle Phase ihre größte Ungewissheit beseitigt hat.
• Achten Sie darauf, dass die Testabsicht über alle Phasen hinweg einheitlich bleibt, damit die Ergebnisse vergleichbar bleiben.

Ein gut durchdachter Validierungsplan mag auf dem Papier schlicht aussehen, spart in der Praxis jedoch am meisten Zeit. Man gewinnt nicht dadurch, dass man jeden Test zu früh auf einen „ hardware “-Teststand setzt, und man gewinnt auch nicht dadurch, dass man bei „ software “ verweilt, nachdem die Zeit das Hauptrisiko geworden ist. OPAL-RT ist in diesem Zusammenhang sinnvoll, da manche Teams beide Wege innerhalb eines Ausführungsablaufs benötigen – von frühen Modellprüfungen bis hin zu strengen Echtzeit-Testständen.