Leitfaden Hardware vs. software für Ingenieur:innen

Wichtigste Erkenntnisse

• Software sollte die Hauptlast der Logikvalidierung in der frühen Phase tragen, da es eine hohe Testabdeckung gewährleistet, solange noch häufig Designänderungen vorgenommen werden.
• Hardware rechtfertigt seine höheren Kosten, wenn das Timing, I/O elektrischen I/O sowie die Ausführung des Controllers auf hardware zum Hauptrisiko hardware .
• Eine gemeinsame Modellbasis ist wichtiger als die Wahl der Stufe, da eine mangelhafte Modelltreue beide Testpfade verfälscht.

Entscheiden Sie sich zunächst für software und wechseln Sie erst dann zu hardware, wenn das zeitliche Verhalten und das Ein- und Ausgangsverhalten nachgewiesen werden müssen.

Dieser Ablauf reduziert den Aufwand, da software ein schnelles Feedback zu Code und Steuerungslogik liefert, noch bevor Prüfstände, Verkabelung und hardware . In Leichtfahrzeugen kommen üblicherweise 70 bis 100 elektronische Steuergeräte, weshalb eine stufenweise Validierung lange vor der endgültigen Integration wichtig ist. Sie erzielen das beste Ergebnis, wenn jede Teststufe ein bestimmtes Risiko abdeckt, anstatt von einer einzigen Stufe zu erwarten, dass sie alle Fragen beantwortet.

Software überprüfen die Steuerungslogik, bevor hardware Betrieb hardware .“

SIL testet software , ohne dass hardware

Software wird die Steuerungslogik überprüft, bevor hardware Betrieb hardware . Dabei wird kompilierte oder interpretierte software einem simulierten Anlagenmodell ausgeführt. Dadurch lassen sich Fehler in Bezug auf Zustände, Grenzwerte und Ablaufsequenzen am schnellsten erkennen. Elektrische Schnittstellen oder feste Zeitabläufe der endgültigen Steuerung werden dabei jedoch nicht überprüft.

Ein Algorithmus für die Traktionskontrolle ist ein gutes Beispiel. Auf einer Workstation lassen sich Radgeschwindigkeitsdaten, Schlupfschätzungen und Drehmomentanforderungen innerhalb weniger Stunden durch Tausende von Straßen- und Reifenkonstellationen simulieren. So lassen sich fehlerhafte Schwellenwerte, instabile Verstärkungswerte oder falsche Fehlerverriegelungen schnell erkennen. Da software weiterhin in einer sicheren digitalen Umgebung untersucht wird, sind Änderungen kostengünstig und die Testabdeckung steigt rasch an.

Diese Schnelligkeit ist entscheidend, wenn sich Ihr Design noch täglich ändert. Kalibrierungsteams können Grenzwerte anpassen, software können Logik-Patches einspielen und Ingenieur:innen überprüfen, ob das beabsichtigte Regelverhalten weiterhin gegeben ist. Wenn Sie hardware früh auf den Prüfstand bringen, wird das Labor zum Engpass, und jedes Problem bei der Verkabelung oder beim Flashen kostet Zeit, die der eigentlichen Validierung verloren geht. SIL eignet sich am besten als erster Filter für die Zuverlässigkeit der Logik, insbesondere wenn sich die Anforderungen noch festigen.

HIL-Tests prüfen das Regelverhalten über physikalische Ein- und Ausgangskanäle

Hardware wird der Regler über physikalische Ein- und Ausgangskanäle getestet, während die Anlage simuliert bleibt. Als Regler kann entweder das Seriengerät oder eine dem Seriengerät sehr ähnliche Zielplatine dienen. Diese Konfiguration deckt Schwankungen im Scheduler, Signalskalierung und Schnittstellenfehler auf. Sie liefert Antworten auf hardware Fragen, die software nicht zuverlässig beantwortet werden können.

Ein Wechselrichter-Regler macht diesen Unterschied deutlich. Impulsbefehle, analoge Rückmeldungen, diskrete Fehlermeldungen und der Kommunikationsverkehr laufen alle über tatsächliche elektrische Pfade, sodass man sehen kann, wie der Regler auf Zeitabweichungen oder verrauschte Eingänge reagiert. Ein Test auf dem Prüfstand wird zeigen, dass ein Offset des Stromsensors eine Schutzabschaltung auslöst, obwohl software zuvor einwandfrei zu funktionieren schien. Solche Fehler treten häufig auf, wenn bei Tests am Schreibtisch die elektrischen Details verborgen bleiben.

HIL bietet Ihrem Team zudem eine gemeinsame Plattform, um die Fehlerbehandlung zu testen, noch bevor ein Prototypenfahrzeug oder ein Prüfstand bereitsteht. Sie können Sensorausfälle, Busfehler und Werte außerhalb des zulässigen Bereichs simulieren, ohne teure hardware zu gefährden. Laborzeit ist kostspielig, daher geht es nicht allein um das Volumen. Es geht vielmehr um den gezielten Nachweis, dass sich die Steuerung korrekt verhält, sobald reale Signale und hardware Teil des Regelkreises sind.

Beginnen Sie mit SIL, wenn noch häufig Designänderungen vorgenommen werden

Beginnen Sie mit software, wenn sich Ihre Reglerarchitektur, Anforderungen oder Kalibrierungen noch häufig ändern. Das Verfahren ermöglicht Änderungen ohne Nacharbeiten am Prüfstand und sorgt dafür, dass Ingenieur:innen auf die Regelungsqualität Ingenieur:innen . Nach jeder Code-Revision können Sie umfassende Regressionstests durchführen. Damit ist es die richtige Einstiegsphase für Phasen mit instabilen Entwürfen.

Eine Drehmoment-Arbitrierungsfunktion für ein Elektrofahrzeug entspricht diesem Muster. Leistungsgrenzen, Fahreranforderungen, Traktionsbeschränkungen und thermische Leistungsreduzierungen ändern sich in frühen Entwicklungsphasen häufig. Sie können das Steuerungsmodell aktualisieren, dieselben Fahrzyklen erneut ausführen und das Verhalten noch am selben Tag vergleichen. Ein hardware würde diesen Regelkreis verlangsamen, da das Flashen, I/O und der Zugang zum Labor den Zeitplan dominieren würden.

In dieser Phase erhalten die Teams zudem klareres Feedback. Wenn ein Test in der SIL-Phase fehlschlägt, lässt sich in der Regel feststellen, dass das Problem in der Logik, der Datenverarbeitung oder den Annahmen zur Anlage liegt und nicht in der Verkabelung, den Schedulern oder der analogen Skalierung. Diese Klarheit hilft Ihren software Steuerungsteams, schneller und ohne unnötige Störfaktoren zu arbeiten. Sie sollten die SIL-Phase erst verlassen, wenn die Logik so stabil erscheint, dass nun hardware und nicht mehr Änderungen am Design die größere Risikoquelle darstellen.

Wechseln Sie zu HIL, wenn das Timing-Risiko zum Problem wird

Der Hauptunterschied zwischen dem Verbleib bei software und dem Übergang zu hardware besteht darin, dass HIL das Verhalten unter den tatsächlichen Zeit- und Schnittstellenbedingungen nachweist. Sobald die Logik stabil erscheint, wird das Ausführungszeitverhalten zum entscheidenden Risikofaktor. HIL zeigt, wie der Regler auf Latenz, Quantisierung und Signalaufbereitung reagiert. An diesem Punkt Tests die Kosten Tests .

Eine elektrische Antriebssteuerung erreicht diesen Zustand oft, nachdem die Drehmoment- und Schutzlogik jede Woche die Bewegung unterbrochen hat. In Leichtfahrzeugen wurden im Jahr 2021 durchschnittlich 949 Halbleiter im Jahr 2021verwendet, sodass Schnittstellentaktung und Signalintegrität nicht lange nur Theorie bleiben werden. Ein HIL-Prüfstand zeigt, dass eine Strombegrenzung eine Abtastung zu spät eintritt oder dass ein Fehlerbit zu langsam zurückgesetzt wird, nachdem sich ein verrauschter Sensor erholt hat. SIL deckt diese Art von Problemen selten mit ausreichender Sicherheit auf.

Sie sollten auch aktiv werden, wenn die Integrationsteams Nachweise dafür benötigen, dass software Elektronik als eine Einheit funktionieren. Kommunikationsverzögerungen, Eingangsfilterung, das Timing der Pulsweitenmodulation und die Interrupt-Auslastung spielen dabei alle eine Rolle. Wenn Sie zu lange warten, stapeln sich die Labortests kurz vor der Veröffentlichung, und teure hardware wird für Logikfehler aufgewendet, die schon früher hätten behoben werden müssen. Durch eine gute Phasenplanung bleibt der Schwerpunkt bei HIL auf dem Timing und I/O , statt auf software .

Die Kosten für HIL steigen mit zunehmendem Umfang der Laborarbeiten

Hardware ist teurer, da jeder sinnvolle Test von hardware, Schnittstellenkarten, dem Aufbau des Prüfstands und der Koordination im Labor. Software beansprucht hauptsächlich Rechenzeit und Modellierungsaufwand. HIL erfordert zusätzliche Investitionsgüter und Zeit für die Einrichtung durch das Personal. Das macht HIL jedoch nicht optional, und Sie sollten es mit klarer Zielsetzung einsetzen.

• hardware für Werkbänke hardware Anschaffungskosten, Wartung und Ersatzteile.
• Die Signalaufbereitung und die Fehlerinjektion erhöhen den Aufwand bei der Einrichtung.
• Das Blinken des Controllers und die Kalibrierung nehmen viel Zeit der Techniker in Anspruch.
• Die Laborplanung begrenzt die Anzahl der Teams, die gleichzeitig Tests durchführen können.
• Die Fehleranalyse erfordert häufig den Einsatz eines Oszilloskops und die Untersuchung von Busablaufdaten.

Ein Batteriemanagement-Team spürt dies schnell. Die erneute Ausführung einer software in SIL dauert nur wenige Minuten, während dieselbe Änderung auf einem Prüfstand Stunden in Anspruch nehmen kann, wenn Kanalzuordnung, Sicherheitsprüfungen und Datenerfassung mit einbezogen werden. Dieser Aufwand ist noch gerechtfertigt, wenn es um hardware geht. Verschwendung entsteht erst dann, wenn Teams HIL nutzen, um frühe Fragen zur Logik zu klären, die eine Workstation schneller und kostengünstiger beantwortet hätte.

Eine Modell-Baseline sorgt dafür, dass beide Testphasen aufeinander abgestimmt bleiben

Eine gemeinsame Basis für das Anlagenmodell verhindert, dass sich software und hardware voneinander entfernen. Es ist wichtig, dass dieselben Annahmen, Schnittstellen und Fehlerdefinitionen von der Desktop-Prüfung bis zur Ausführung auf dem Prüfstand gelten. Diese Kontinuität erleichtert die Interpretation von Fehlern. Außerdem verhindert sie, Ingenieur:innen darüber streiten, welche Konfiguration die richtige ist.

Ein Team für die Motorsteuerung kann dasselbe System für Regressionstests auf dem Desktop kompilieren und es anschließend auf ein Echtzeit-Zielsystem übertragen, um dort Reglerversuche durchzuführen, sobald das Timing eine Rolle spielt. Solange die Modellgleichungen, Signalbezeichnungen und Fehlerfälle konsistent bleiben, bleibt auch die Testabsicht konsistent. So können Sie einen erfolgreichen Durchlauf in SIL mit einem fehlgeschlagenen Durchlauf in HIL vergleichen und schnell feststellen, ob die Diskrepanz I/O hardware oder I/O elektrischen I/O . OPAL-RT eignet sich für diesen Arbeitsablauf, wenn Teams in beiden Phasen dieselbe Modellstruktur benötigen.

Sie sollten die Modellverwaltung als Teil der Teststrategie betrachten und nicht als Nacharbeit. Versionskontrolle, Schnittstellenvereinbarungen und wiederholbare Testvektoren sorgen für einen reibungslosen Übergang. Ohne diese Disziplin werden SIL und HIL zu separaten Projekten mit unterschiedlichen Standards. Ein kombinierter Arbeitsablauf funktioniert nur dann gut, wenn beide Phasen von Anfang an dieselbe technische Sprache sprechen.

Software sollte für die Zuverlässigkeit der Logik sorgen, hardware für hardware , und beide sollten auf einem Anlagenmodell basieren, dem Sie vertrauen.“

Eine mangelhafte Planentreue führt dazu, dass beide Testphasen irreführend sind

Eine mangelhafte Modellgenauigkeit führt sowohl bei software als auch bei hardware in die Irre. Ein ungenaues Modell kann eine instabile Regelung als stabil erscheinen lassen oder einen einwandfrei funktionierenden Regler als defekt darstellen. Auch saubere Diagramme helfen nichts, wenn die physikalischen Eigenschaften des Systems falsch sind. Das Vertrauen in den Arbeitsablauf beginnt mit dem Vertrauen in das Modell.

Ein Simulationsmodell, das Totzeiten, Sensorrauschen oder Sättigung außer Acht lässt, ist eine häufige Falle. Bei der SIL-Simulation wird eine gleichmäßige Stromregelung angezeigt, da das Regelobjekt zu ideal dargestellt wird. Auch die HIL-Simulation kann ein trügerisches Gefühl der Sicherheit vermitteln, wenn dasselbe schwache Regelobjekt über perfekte Kanäle in den Regler eingespeist wird. Am Ende validiert man den Regler anhand einer fiktiven Situation und verbringt dann in der späten Projektphase Zeit damit, zu erklären, warum die Ergebnisse der Laborversuche nicht mit dem tatsächlichen Systemverhalten übereinstimmen.

Die grundlegende Erkenntnis ist einfach: Software sollte für die Logikverantwortung sorgen, hardware für hardware , und beide sollten auf einem Anlagenmodell basieren, dem Sie vertrauen. Teams, die diese Disziplin einhalten, verschwenden weniger Zeit im Labor und verbrauchen weniger Energie damit, fehlgeschlagene Tests zu diskutieren. OPAL-RT eignet sich am besten für Bereiche, in denen diese Konsistenz entscheidend ist, denn die Ausführungskette bleibt nur dann glaubwürdig, wenn die Modellqualität als Teil der Validierung betrachtet wird und nicht erst im Nachhinein berücksichtigt wird.