Was bedeutet software(SIL)?

Wichtigste Erkenntnisse

• Tests Software Tests der praktische Prüfpunkt, an dem der ausführbare Code nachweist, dass er weiterhin der Systemabsicht entspricht, bevor hardware den Testablauf hardware .
• SIL senkt die Validierungskosten, wenn Sie damit software frühzeitig isolieren, Regressionstests automatisieren und den Schwerpunkt von HIL auf hardware Fragen legen.
• Zuverlässige SIL-Ergebnisse hängen von einer realistischen Zeit- und Schnittstellenmodellierung sowie von realistischen numerischen Annahmen ab, da eine zu vereinfachte Simulationskonfiguration falsches Vertrauen weckt, anstatt aussagekräftige Erkenntnisse zu liefern.

Tests Sie eingebettete software , kostengünstiger und mit einer präziseren Fehlerisolierung validieren, als wenn Sie auf hardware warten müssten.

Das ist von Bedeutung, da software in modernen Steuerungssystemen mit der zunehmenden Verbreitung elektrischer und automatisierter Plattformen stetig wächst. Der weltweite Absatz von Elektroautos lag im Jahr 2023 bei über 14 Millionen, wodurch sich der Gesamtbestand auf etwa 40 Millionen. Immer mehr Programme sind mittlerweile auf Steuerungscode, Anlagenmodelle und Tests angewiesen Tests mit software häufigen software Schritt halten können. SIL eignet sich am besten als Brücke zwischen Modellverifikation und hardware , da es Logikfehler, Schnittstellenfehler und Anforderungslücken aufdeckt, bevor hardware das Team hardware .

Bei Software -Loop“ wird Produktionscode in einer Simulation ausgeführt

Software bedeutet, dass ausführbare software nicht auf physischer hardware, sondern anhand Sensor-und Datenfusion simulierten Sensor-und Datenfusion, von Aktoren und dem Verhalten des Regelkreises software . Sie testen den implementierten Code und nicht nur das Regelmodell. Somit liefert SIL den ersten eindeutigen Nachweis dafür, dass software auch nach der Kompilierung und Integration noch mit der beabsichtigten Systemfunktion übereinstimmt.

Ein Motorregler bietet hierfür ein einfaches Beispiel. Der Steuerungscode liest simulierte Werte für Kurbelwinkel, Drosselklappenstellung und Temperatur aus und schreibt anschließend Einspritz- und Zündbefehle zurück in das Anlagenmodell. Wenn sich Drehmomentbegrenzungen, die Kraftstoffabschaltlogik oder Diagnoseflags ungewöhnlich verhalten, können Sie die genauen Signale und den Zeitablauf überprüfen, ohne einen Prüfstandregler oder den Fahrzeugkabelbaum anzufassen. Dadurch lassen sich software viel einfacher eingrenzen, als dies später in einer gemeinsam genutzten Laborumgebung der Fall wäre.

SIL ist nützlich, da Codegenerierung, Compiler-Einstellungen, Datentypen und Modulschnittstellen Verhaltensweisen hervorrufen, die ein Blockdiagramm allein verbergen kann. Ein Modell kann übersichtlich aussehen, während der generierte Code einen Wert abschneidet, einen Skalierungsfaktor falsch interpretiert oder eine Aufgabe in der falschen Reihenfolge aufruft. SIL erkennt diese Implementierungsprobleme an dem Punkt, an dem Korrekturen noch schnell und nachvollziehbar sind. Dies ist der Punkt, an dem software einem testbaren technischen Nachweis software und nicht mehr nur eine Entwurfsannahme ist.

Bei SIL erfolgt die Modellverifizierung vor der HIL-Validierung

SIL findet nach der Modellverifizierung und vor hardware statt. Sobald sich die Steuerungslogik auf Modellebene korrekt verhält, überprüft SIL den generierten oder manuell geschriebenen Code anhand derselben funktionalen Vorgaben. Diese Abfolge verhindert, dass Codefehler spätere hardware beeinträchtigen und Testzeit verschwenden.

Ein Bremsregler veranschaulicht den Ablauf anschaulich. Die Modellverifizierung bestätigt, dass die Schlupfregelung, die Druckanforderungen und die Ausweichzustände in der Simulation korrekt funktionieren. Im Rahmen von SIL wird anschließend die tatsächliche software anhand derselben Anlagenfälle getestet, um sicherzustellen, dass die Implementierung diese Regeln weiterhin einhält. Danach folgt HIL, wenn überprüft werden muss, wie der Regler mit I/O , dem Netzwerkverkehr und den Einschränkungen hardware umgeht – Aspekte, die bei einer software Ausführung nicht vollständig nachgebildet werden können.

Teams überspringen Schritte, wenn der Zeitplan eng wird, doch diese Abkürzung geht meist nach hinten los. Wenn man direkt von der Modellierung zum HIL übergeht, können Fehler im Labor auf software , die Codegenerierung, die Konfiguration des Schedulers oder I/O zurückzuführen sein – und das Labor gibt keinen Aufschluss darüber, welcher dieser Faktoren zuerst versagt hat. SIL grenzt den Suchraum ein, bevor hardware Spiel hardware . Es ersetzt HIL nicht, und das muss es auch nicht. Es bereitet HIL so vor, dass hardware Antworten hardware liefern.

Verwenden Sie SIL, wenn software hardware überholen

SIL ist der richtige nächste Schritt, wenn die Geschwindigkeit software höher ist als hardware . Es bietet Ihnen eine stabile Umgebung, um tägliche Builds auszuführen, Fehlerpfade zu testen und Schnittstellenvereinbarungen zu überprüfen, während Teststände, Prototypen oder Zielsteuerungen noch nicht verfügbar, gemeinsam genutzt oder unvollständig sind.

Mehrere Anzeichen deuten darauf hin, dass SIL vor weiteren Laborarbeiten durchgeführt werden sollte:

• Ihr hardware hinkt dem Rhythmus Ihrer software hinterher.
• Ihr Anlagenmodell bildet bereits die für Sie relevanten Betriebszustände ab.
• Ihr Team benötigt nach dem Zusammenführen von Code tägliche Regressionstests.
• Die Fehlerinjektion ist in der Simulation sicherer als an Laborgeräten.
• Die Schnittstellenvereinbarungen zwischen den Modulen ändern sich weiterhin von Woche zu Woche.

Ein Team für Antriebsstrangentwicklung im Automobilbereich sieht sich oft genau mit dieser Situation konfrontiert. Die software für den Wechselrichter software , doch die nächste Controller-Version und der nächste Termin für den Prüfstand stehen erst in einigen Wochen an. SIL sorgt dafür, dass die Validierung weiter voranschreitet, da der Code weiterhin anhand von Drehzahlrampen, Drehmomentsprüngen, Notlaufmodi und Sensorfehlern getestet werden kann. Dieses Tempo ist entscheidend, wenn man versucht, software mit einem aktiven Entwicklungsplan in Einklang zu halten, anstatt darauf zu warten, dass hardware beseitigt werden.

Software bedeutet, dass ausführbare software anstelle von physischer hardware mit simulierten Sensor-und Datenfusion, Aktoren und dem Verhalten des Regelobjekts software .“

SIL senkt die Validierungskosten durch frühzeitigere Fehlererkennung

SIL senkt die Entwicklungskosten, da software bereits erkannt werden, bevor Prototypenteile, Labortermine und Labortechniker ins Spiel kommen. Sie können über Nacht umfassende Regressionstests durchführen, Fehler bis auf bestimmte Signale zurückverfolgen und diese beheben, solange die Codeänderung noch kostengünstig ist und die verantwortlichen Ingenieur:innen sich Ingenieur:innen an die Änderung erinnern.

Das Kostenargument geht über das Budget eines einzelnen Labors hinaus. software schlechte software kostete die US-Wirtschaft im Jahr 2022 mindestens 2,41 Billionen US-Dollar im Jahr 2022. SIL wird dieses Problem zwar nicht beseitigen, bekämpft jedoch eine seiner Hauptursachen: zu spät entdeckte Fehler in Umgebungen, in denen jeder Ausfall teure Personalressourcen, hardware und Zeitpuffer verschlingt.

Eine Regressionssuite für die Traktionskontrolle verdeutlicht dies. Sie können Testfälle für trockenen Asphalt, festgefahrenen Schnee, Sensorabweichungen und Watchdog-Resets in einem automatisierten Batch ausführen und die Ergebnisse anschließend mit dem erwarteten Verhalten vergleichen, bevor der nächste Build bereitgestellt wird. Wenn nach einer Code-Zusammenführung ein Radgeschwindigkeitsfilter ausfällt, erkennt das Team dies schnell und behebt den Fehler, bevor dieser Defekt Zeit auf dem Leistungsprüfstand kostet oder eine verwirrende HIL-Untersuchung auslöst. Durch die frühzeitige Isolierung werden Tests einem Engpass zu einem Filter.

SIL ist auf die zeitliche Genauigkeit an software angewiesen

SIL liefert nur dann aussagekräftige Ergebnisse, wenn das Timing der Schnittstellen, die Abtastung, die Quantisierung und die Aufgabenplanung software entsprechen. Sind diese Details nicht genau festgelegt, kann der Code in der Simulation zwar korrekt erscheinen, versagen aber dennoch, sobald strengere I/O , eine hohe Interrupt-Last oder asynchrone Interaktionen zwischen Aufgaben auftreten.

Ein Drehmomentregler kann zwar alle Nennwerttests bestehen, dennoch jedoch ausfallen, wenn die software veraltete Stromrückmeldungen software oder ihren Befehl eine Task zu spät schreibt. Solche Probleme treten auf, wenn Abtastzeiten, Pufferaktualisierungen und Übergänge zwischen Drehzahlen nicht korrekt dargestellt werden. Auch die Festkommaskalierung spielt eine Rolle. Ein Modell, das Gleitkommaarithmetik verwendet, kann Überläufe, Sättigungen oder Auflösungsverluste verbergen, auf die die eingesetzte software unmittelbar stoßen software .

Teams, die OPAL-RT oder ein vergleichbares Simulationssystem verwenden, müssen diese Schnittstellenannahmen dennoch sorgfältig definieren, da die Rechengeschwindigkeit allein einen schwachen Timing-Vertrag nicht ausgleichen kann. Im Test-Harness müssen das Verhalten des Schedulers, die Signallatenz und numerische Einschränkungen explizit berücksichtigt werden. Wenn SIL den software genau genug widerspiegelt, sind Fehler aussagekräftig. Ist dies nicht der Fall, können bestandene Tests ein falsches Vertrauen wecken, das Sie später teuer zu stehen kommt.

Software vs. hardware

Der Hauptunterschied zwischen software ) und hardware ( HIL ) liegt in dem zu testenden Objekt. Bei SIL wird software simulierten Ein- und Ausgängen getestet, während bei HIL der Regler an physische I/O hardware angeschlossen wird. SIL liefert früher Antworten auf Fragen zur Logik und software , während HIL Fragen hardware erst kurz vor der Inbetriebnahme beantwortet.

Ein Batteriemanagement-Team nutzt häufig beide Testzyklen in dieser Reihenfolge. SIL deckt Fehler in der Ausgleichslogik, Vorteil , in denen der Schätzwert Vorteil , sowie Fehlerschwellenwerte frühzeitig auf, während HIL vor der Freigabe I/O , Netzwerkmeldungen und hardware überprüft. Wenn Sie HIL beide Aufgaben übertragen, verbringen Sie mehr Zeit damit, software an der Stelle zu diagnostizieren, an der deren Aufdeckung am teuersten ist.

Ein SIL-Workflow im Automobilbereich verknüpft Anforderungen mit ausführbaren Tests

Ein effektiver SIL-Workflow im Automobilbereich beginnt mit den Anforderungen und endet mit automatisierten „Bestanden“- oder „Nicht bestanden“-Ergebnissen, die mit einem software verknüpft sind. Der Workflow ist einfach aufgebaut: Man wählt die Anforderung aus, definiert das Szenario, führt den ausführbaren Code auf dem Anlagenmodell aus und vergleicht die Ergebnisse mit messbaren Abnahmeregeln.

Ein Spurhalteassistent verdeutlicht das Muster. Eine Anforderung besagt, dass der Assistent das Lenkmoment bei einem Sensorausfall begrenzen und gleichzeitig einen sicheren Ausweichzustand gewährleisten muss. Das Team wandelt diese Aussage in einen Testfall um, der eine simulierte Straße, ein Fahrzeugmodell, ein Ausfallereignis und software erwartete software umfasst. Die software wird in SIL ausgeführt, das Test-Harness zeichnet interne Zustände und Ausgänge auf, und das Ergebnis wird mit der ursprünglichen Anforderung verknüpft, sodass auf den Fehler reagiert werden kann.

Dieser Arbeitsablauf funktioniert, weil er die Nachweiskette aufrechterhält. Sie überprüfen nicht nur, ob der Code läuft. Sie überprüfen, ob eine benannte Anforderung auch nach Code-Integration, Kalibrierungsaktualisierungen und Schnittstellenänderungen weiterhin erfüllt ist. Diese Rückverfolgbarkeit ist in Automobilprojekten von entscheidender Bedeutung, wo Sicherheitsprüfungen, software und die Freigabe von Kalibrierungen alle von wiederholbaren Nachweisen abhängen. Wenn SIL Teil der kontinuierlichen Regression wird, erfüllt jede Codeänderung denselben ausführbaren Standard, anstatt sich auf das Gedächtnis und manuelle Arbeitsgewohnheiten zu verlassen.

SIL versagt, wenn zeitliche Annahmen Integrationsfehler verschleiern

SIL versagt, wenn Teams davon ausgehen, dass funktionale Korrektheit ausreicht, und dabei Timing, numerische Genauigkeit oder das Verhalten der Schnittstellen außer Acht lassen. Selbst eine erfolgreich absolvierte Testsuite kann übersehene Interrupts, Skalierungsfehler, Scheduler-Konflikte und asynchrone Fehler verbergen, die später auf dem Prüfstand oder im Fahrzeug auftreten.

Ein Team, das sich mit Motorsteuerung befasst, kann Tests mit Nenn-Drehmoment und -Drehzahl erfolgreich bestehen, stößt dann aber auf Probleme, sobald eine Diagnoseaufgabe den Regelkreis im falschen Moment unterbricht. Ein anderes Team modelliert Sensordaten möglicherweise als rauschfrei und synchron und übersieht dadurch einen Fehler, der erst bei verzögerten Meldungen und veralteten Werten auftritt. Diese Versäumnisse treten nicht auf, weil SIL unzureichend ist. Sie treten auf, weil der Simulationsumfang für die zu testenden software zu gering war.

„Ein diszipliniertes SIL sorgt dafür, dass HIL gezieltere Fragen stellt und die Laborzeit sinnvoll nutzt.“

Aus diesem Grund drehen sich die Diskussionen bei OPAL-RT mit den Ingenieurteams oft um die Genauigkeit der Solver, das Timing der Schnittstellen und wiederholbare Automatisierung, bevor überhaupt vom Durchsatz die Rede ist. Gute SIL-Praxis schafft im Laufe der Zeit Vertrauen, da sie annahmenlastige Tests nachprüfbare Belege ersetzt, die man auch bei engen Zeitplänen verteidigen kann.