Software in the Loop (SIL)-Tests in Simulink kompilieren ein Modell oder Subsystem über Embedded Coder in produktionsreifen C/C++-Code und führen diesen innerhalb der Simulink-Umgebung unter identischen Testbedingungen aus. Dabei wird die numerische Äquivalenz zwischen dem generierten Code und dem ursprünglichen Modell durch Back-to-Back-Vergleiche mit definierten Toleranzen verifiziert. SIL erkennt Präzisionsfehler durch Datentypen mit fester Breite, compilerspezifische Optimierungen und Diskrepanzen bei der Codegenerierung, noch bevor die Software auf der Hardware eingesetzt wird. Das Verständnis des vollständigen Arbeitsablaufs zeigt, wie SIL in umfassendere Verifikationsstrategien eingebettet ist.
So funktioniert SIL-Testing in Simulink
SIL-Tests in Simulink funktionieren, indem ein Modell – oder ein bestimmtes Subsystem – mithilfe von Embedded Coder in produktionsreifen C/C++-Code kompiliert und dieser generierte Code dann direkt in der Simulink-Umgebung gegen dieselben Testumgebungen und Eingangsstimuli ausgeführt wird, die auch bei der Model-in-the-Loop-(MIL-)Simulation verwendet werden. Dieser Ansatz ermöglicht es Ingenieuren zu verifizieren, dass die Codegenerierung die Modelltreue bewahrt, ohne dass Zielhardware erforderlich ist.
Während der Ausführung kapselt Simulink den kompilierten Code in eine S-Funktion oder eine eigenständige ausführbare Datei und leitet die Signale über identische Ein-/Ausgangsschnittstellen. Die numerischen Ausgaben des SIL-Blocks werden mit den MIL-Referenzwerten verglichen, um Abweichungen in der Simulationsgenauigkeit zu quantifizieren, die durch Codegenerierung, Festkommakonvertierung oder Compileroptimierungen entstehen. Diskrepanzen weisen auf potenzielle Probleme bei der Typumwandlung, der Überlaufbehandlung oder der algorithmischen Übersetzung hin. Ingenieure konfigurieren Back-to-Back-Äquivalenztests über Simulink Test und automatisieren dabei die Bestanden/Nicht-bestanden-Kriterien auf Basis definierter Toleranzen. Dieser Arbeitsablauf isoliert Softwareschicht-Defekte, bevor die Processor-in-the-Loop- oder Hardware-Integrationsphasen beginnen.
Warum SIL Fehler findet, die die Modellsimulation übersieht
SIL-Tests decken Diskrepanzen auf, die eine Simulation auf Modellebene von Natur aus verbirgt, insbesondere Präzisionsfehler auf Codeebene, die entstehen, wenn Gleitkommaoperationen zu Datentypen fester Breite kompiliert werden oder wenn Zwischenberechnungen durch Abschneidung und Rundung im generierten C-Code an Signifikanz verlieren. Unterschiede im Verhalten des Zielcompilers – wie optimierungsabhängige Auswertungsreihenfolge, Struktur-Padding und implementierungsdefinierte Behandlung von Ganzzahlüberläufen – erzeugen Ausführungsergebnisse, die von der idealisierten Ausgabe des Simulink-Solvers abweichen. Diese Defekte bleiben unerkannt, bis der tatsächlich generierte Quellcode innerhalb des SIL-Frameworks ausgeführt wird, was ihn zu einem kritischen Validierungsschritt zwischen Modellverifikation und Hardware-Deployment macht.
Fehler auf Code-Ebene durch mangelnde Präzision
Akkumulationsfehler in iterativen Algorithmen – Filtern, Integratoren, Zustandsautomaten – verstärken sich über Zeitschritte hinweg und können Sicherheitsmargen verletzen. SIL-basierte Fehleridentifikation isoliert spezifische Operationen, bei denen der generierte Code von der Modellabsicht abweicht. Ingenieure verfolgen Fehler bis zu einzelnen Typumwandlungen, Änderungen der Operatorpriorität oder compilerspezifischen Gleitkommaoptimierungen zurück und ermöglichen so gezielte Korrekturen vor der Bereitstellung auf Zielhardware.
Unterschiede im Verhalten des Ziel-Compilers
Über Präzisionsfehler auf Code-Ebene hinaus stammt eine bedeutende Klasse von Defekten nicht vom generierten Code selbst, sondern davon, wie der Ziel-Compiler diesen Code interpretiert und optimiert. Compiler-Optimierungen – wie die Eliminierung toten Codes, Schleifenentrollung oder aggressive Registerzuordnung – können das Ausführungsverhalten auf eine Weise verändern, die das Simulink-Modell niemals vorhersagt. SIL-Tests decken diese Diskrepanzen auf, indem sie den kompilierten C/C++-Code in der Host-Umgebung ausführen und so offenlegen, wo compilerspezifisches Verhalten von der modellierten Absicht abweicht.
Einschränkungen der Zielarchitektur verstärken dieses Risiko zusätzlich. Annahmen zur Ganzzahlbreite, Strukturauffüllung und Byte-Reihenfolge variieren zwischen Compilern und Plattformen. Die SIL-Verifizierung erkennt, wenn Compiler-Optimierungen Operationen umordnen oder scheinbar redundante Berechnungen eliminieren, die der Algorithmus tatsächlich benötigt. Diese Validierungsschicht garantiert die funktionale Äquivalenz zwischen dem Modell und seiner kompilierten Implementierung vor der Bereitstellung.
Entspricht Ihr generierter Code dem Modell?
Die Code-Modell-Äquivalenzverifikation bestimmt, ob der automatisch generierte C/C++-Code Ausgaben erzeugt, die numerisch identisch mit der Verhaltensspezifikation des Simulink-Modells sind. Beim Back-to-Back-Test werden dieselben Testvektoren sowohl gegen das Modell als auch gegen den kompilierten generierten Code ausgeführt, wobei die Ausgaben Signal für Signal verglichen werden, um numerische Abweichungen zu erkennen, die durch Festkomma-Skalierung, Compiler-Optimierungen oder Datentypkonvertierungen entstehen. Die Identifikation dieser Abweichungen während der SIL-Simulation ist entscheidend, um sicherzustellen, dass der bereitgestellte Code das verifizierte Modellverhalten innerhalb akzeptabler Toleranzgrenzen originalgetreu implementiert.
Code-Modell-Äquivalenzverifizierung
Die Überprüfung, dass automatisch generierter Code numerisch identische Ergebnisse wie das Simulink-Modell liefert, aus dem er abgeleitet wurde, stellt das zentrale Ziel der Code-Modell-Äquivalenztests innerhalb eines Software-in-the-Loop-(SIL)-Workflows dar. Dieser Prozess führt den kompilierten Code parallel zu Simulationen auf Modellebene mit identischen Stimuli aus und vergleicht anschließend die Ergebnisse Signal für Signal anhand definierter Toleranzen.
Eine wirksame Äquivalenzverifizierung hängt von drei entscheidenden Faktoren ab:
- Das Testfalldesign muss eine ausreichende Abdeckung über Betriebsbedingungen, Grenzwerte und Randfälle hinweg erreichen, um Abweichungen aufzudecken, die während der Codegenerierung oder Kompilierung eingeführt wurden.
- Die Leistungsoptimierung der SIL-Testausführung ermöglicht eine schnelle Iteration, insbesondere bei großskaligen Modellen, die Tausende von Simulationszyklen erfordern.
- Die Toleranzspezifikation muss zulässige Gleitkommaabweichungen berücksichtigen, die aus dem compilerspezifischen arithmetischen Verhalten im Vergleich zur numerischen Engine von Simulink resultieren.
Erkennung numerischer Abweichungen
Die numerische Übereinstimmung zwischen einem Simulink-Modell und seinem generierten Code kann nicht vorausgesetzt werden – sie muss gemessen werden. SIL-Tests führen den kompilierten C/C++-Code innerhalb der Simulink-Umgebung aus und ermöglichen einen signalbasierten Vergleich mit dem Referenzmodell. Toleranzen – sowohl absolute als auch relative – müssen konfiguriert werden, um Abweichungen zu erkennen, die durch Festkommaskalierung, Compiler-Optimierungen oder Unterschiede in der Gleitkommaarithmetik zwischen verschiedenen Zielarchitekturen entstehen.
Numerische Stabilitätsprobleme treten häufig auf, wenn Rückkopplungsschleifen oder iterative Algorithmen kleine Darstellungsfehler verstärken. Die SIL-Simulation erfasst diese Abweichungen, indem sie Ausgangsverläufe protokolliert und abtastwertbezogene Fehlermetriken berechnet. Die Fehlerfortpflanzung durch kaskadierte Teilsysteme kann vernachlässigbare Abweichungen auf Blockebene in Fehler auf Systemebene verwandeln. Automatisierte Regressions-Frameworks kennzeichnen Signale, die definierte Schwellenwerte überschreiten, und liefern Ingenieuren präzise Diagnosedaten, um Fehlerursachen zu isolieren, bevor die Bereitstellung auf Hardware-Zielplattformen erfolgt.
Back-to-Back-Test
Back-to-Back-Tests formalisieren den Vergleich zwischen den Simulationsausgaben eines Simulink-Modells und den entsprechenden SIL-Ausführungsergebnissen, indem identische Testvektoren durch beide Repräsentationen geleitet und die Ausgangsäquivalenz bewertet wird. Die Testumgebung muss deterministische Ausführungsbedingungen gewährleisten und sicherstellen, dass Eingangsstimuli, Solver-Konfigurationen und Signalprotokollierung in beiden Modi exakt übereinstimmen.
Wesentliche Implementierungsschritte umfassen:
- Toleranzschwellen definieren — akzeptable Leistungskennzahlen für Signalabweichungen festlegen, wobei Unterschiede in der Gleitkommadarstellung zwischen Simulation und kompiliertem Code berücksichtigt werden.
- Testrahmen-Ausführung automatisieren — Simulink Test verwenden, um parallele Modell- und SIL-Durchläufe zu orchestrieren und Zeitreihenergebnisse systematisch zu erfassen.
- Äquivalenzkriterien auswerten — absolute und relative Fehlerprüfungen pro Ausgangssignal anwenden und Abweichungen kennzeichnen, die die festgelegten Grenzen überschreiten.
Fehlschläge weisen auf Codegenerierungseinstellungen, Compiler-Optimierungen oder Festkomma-Skalierungen hin, die einer Korrektur bedürfen.
Welche Code-Coverage-Metriken kann SIL aufdecken?
Beim Ausführen von generiertem Code in einer SIL-Umgebung kann Simulink gleichzeitig strukturelle Code-Coverage-Metriken erfassen, die quantifizieren, wie gründlich Testfälle den kompilierten Quellcode durchlaufen. Zu den unterstützten Metriken gehören Anweisungsabdeckung, Entscheidungsabdeckung, Bedingungsabdeckung und modifizierte Bedingungs-/Entscheidungsabdeckung (MC/DC), die jeweils zunehmenden Strengegraden entsprechen, wie sie in Standards wie DO-178C und ISO 26262 definiert sind.
Diese Leistungsmetriken fließen direkt in Teststrategien ein, indem sie nicht ausgeführte Codepfade, unerreichbare Verzweigungen und unzureichende Variationen logischer Bedingungen identifizieren. Ingenieure können Lücken ermitteln, bei denen zusätzliche Testvektoren erforderlich sind, um die angestrebten Schwellenwerte zu erreichen. Entscheidungs- und MC/DC-Abdeckung sind besonders kritisch für sicherheitskritische Anwendungen, bei denen der Nachweis, dass jeder boolesche Teilausdruck das Ergebnis unabhängig beeinflusst, zwingend erforderlich ist.
SIL vs. PIL in Simulink: Was brauchen Sie?
Wie genau bestimmt die Wahl zwischen Software-in-the-Loop- und Processor-in-the-Loop-Tests, welche Fehlerklassen eine Verifikationskampagne erkennen kann? Die Vorteile von SIL liegen in der Ausführungsgeschwindigkeit und der frühzeitigen algorithmischen Validierung – der generierte Code wird auf dem Host-Rechner ausgeführt, ohne dass Zielhardware erforderlich ist. PIL-Vergleiche zeigen, dass zielplattformspezifische Fehler, einschließlich Compiler-Optimierungsartefakte, Festkomma-Überlaufverhalten und Speicher-Alignment-Fehler, allein mit SIL nicht erkennbar bleiben.
Die Auswahlkriterien lassen sich auf drei entscheidende Faktoren reduzieren:
- Fehlerklassenumfang: SIL validiert die algorithmische Korrektheit und die Logik auf Code-Ebene; PIL deckt compilerbedingte und hardwareabhängige Anomalien auf.
- Infrastrukturanforderungen: SIL erfordert lediglich Simulink und Embedded Coder auf dem Host; PIL erfordert eine physische Zielplattform-Platine oder einen Befehlssatzsimulator mit Integration der Cross-Compiler-Toolchain.
- Ausführungsdurchsatz: SIL erreicht deutlich höhere Simulationsgeschwindigkeiten und ermöglicht so umfassendere Parametervariation und Regressionstestabdeckung innerhalb begrenzter Verifikationszeiträume.
Beide Modi sind komplementär, nicht austauschbar.
Desktop-Only SIL-Tests: Vorteile und Einschränkungen
Da SIL-Tests den generierten Produktionscode vollständig auf dem Host-Entwicklungsrechner ausführen, entfallen sämtliche Abhängigkeiten von der Verfügbarkeit der Zielhardware, Cross-Compilation-Toolchains und physischen Debug-Schnittstellen – sodass Verifikationskampagnen unmittelbar nach der Codegenerierung beginnen können. Das Testen auf dem Desktop bietet erhebliche Debugging-Vorteile durch direkte Speicherinspektion, das Setzen von Haltepunkten und die native Profiler-Integration innerhalb der Simulink-Umgebung. Ingenieure können Leistungskennzahlen wie Ausführungszeiten, Codeabdeckung und numerische Äquivalenz gegenüber Modell-Baselines erfassen, ohne auf eingebettete Zielsysteme deployen zu müssen.
Allerdings weicht die Simulationsgenauigkeit vom Verhalten des Zielsystems ab, wenn sich die Plattformbeschränkungen unterscheiden – Wortbreiten, Byte-Reihenfolge und Gleitkommaimplementierungen auf dem Host stimmen möglicherweise nicht mit dem eingebetteten Prozessor überein. Messungen der Ressourcenauslastung sind nicht repräsentativ für die tatsächliche Belastung des Zielsystems. Integrationsprobleme treten auf, wenn hardwareabhängige Codepfade Stubbing oder Abstraktion erfordern. Trotz dieser Einschränkungen machen die Vorteile hinsichtlich Iterationsgeschwindigkeit und Zugänglichkeit SIL-Tests für Verifikationsabläufe in frühen Phasen unverzichtbar.
Wie SIL mit Simulink DO-178C und ISO 26262 unterstützt
Da sicherheitskritische Entwicklungsstandards strenge Anforderungen an die Rückverfolgbarkeit und Verifikation von generiertem Code stellen, bietet SIL-Testing innerhalb von Simulink ein strukturiertes Framework, das direkt die in DO-178C (Software für luftfahrttechnische Systeme) und ISO 26262 (funktionale Sicherheit im Automobilbereich) definierten Ziele adressiert. Beide Zertifizierungsprozesse erfordern den Nachweis, dass die Softwareverifikation die Modelltreue gegenüber den Systemintegritätsanforderungen durch dokumentierte Testmethoden validiert.
SIL innerhalb von Simulink unterstützt die Einhaltung von DO-178C und die Standards der ISO 26262 durch:
- Automatisierte Rückverfolgbarkeitsverknüpfung — Anforderungen werden direkt auf Testfälle und generierte Code-Artefakte abgebildet, wodurch die regulatorischen Anforderungen an die bidirektionale Rückverfolgbarkeit in sicherheitskritischen Anwendungen erfüllt werden.
- Strukturelle Abdeckungsanalyse — Die Abdeckungstools von Simulink quantifizieren Entscheidungs-, Bedingungs- und MC/DC-Metriken, die für die Risikobewertung auf höheren Sicherheitsstufen unerlässlich sind.
- Back-to-Back-Äquivalenztests — Der automatisierte Vergleich zwischen Modell- und generiertem Code-Ausgaben liefert objektive Verifikationsnachweise, die Zertifizierungsbehörden zum Nachweis der funktionalen Äquivalenz und Code-Korrektheit verlangen.
Wie man seinen ersten SIL-Test in Simulink einrichtet
Simulink Test Manager bietet eine strukturierte Erstellung von Testumgebungen und verknüpft Eingangsstimulusdaten direkt mit den Modellports. Nach der Konfiguration kompiliert die Ausführung der SIL-Simulation den generierten C-Code, führt ihn auf dem Host-Prozessor aus und erzeugt numerisch nachvollziehbare Verifikationsergebnisse.
