Produktreife entsteht im Code
Warum die Bedeutung von Software-in-the-Loop wächst
Validierung am Ende der Kette skaliert nicht mehr mit der Geschwindigkeit moderner Softwareentwicklung. Wer Reife früher entstehen lässt, beschleunigt Feedback, entlastet knappe HIL-Ressourcen und macht den Prüfstand wieder zu dem, wofür er gedacht ist: zur finalen Absicherung.
Die öffentliche Debatte um Software-Defined Vehicles (SDV) dreht sich meist um zonale E/E-Architekturen, zentrale High-Performance-Computer (HPC) (Bild 1) oder Over-the-Air-Updates (OTA). In der Engineering-Realität entscheidet jedoch eine andere Frage über Liefertreue, Qualität und Time-to-Market: Wie lässt sich Software in der nötigen Geschwindigkeit validieren, ohne dass HIL- und Prüfstandsressourcen zum limitierenden Faktor werden?
Funktionen entstehen heute nicht mehr isoliert auf einzelnen ECUs, sondern im Zusammenspiel verteilter Software-Stacks, Kommunikationsschichten und Plattformsoftware – über unterschiedliche Architekturen, Betriebssysteme und Plattformkonzepte hinweg. Jede Änderung kann Rückwirkungen über Domänengrenzen auslösen. Gleichzeitig steigen Variantenzahl, Release-Frequenz und OTA-Erwartungen über den Lifecycle. Validierung wird damit zur Skalierungsfrage der Branche und in vielen Entwicklungsorganisationen zum operativen Engpass.
Das V-Modell hat seinen Takt verloren
Das klassische V-Modell setzt voraus, dass Hardware, Software und Fahrzeugprojekt in vergleichbarer Geschwindigkeit reifen. In der SDV-Entwicklung gilt diese Voraussetzung kaum noch. Software iteriert in schnellen Sprint-Zyklen, während Hardware-Muster, Integrationsumgebungen und HIL-Aufbauten längeren Bereitstellungszyklen folgen. Diese Entwicklung lässt sich wirtschaftlich nicht mehr allein durch zusätzliche Validierungsschichten oder mehr HIL-Kapazität auffangen.
Die Folgen prägen komplexe Fahrzeugprojekte. Fehler werden spät sichtbar, häufig erst im integrierten System oder im Fahrversuch. Die Ursachenanalyse führt quer durch den Software-Stack, von der Applikationslogik über die Basissoftware bis zur Kommunikation zwischen Steuergeräten. Was als technischer Einzelfall erscheint, ist meist Symptom einer strukturellen Ursache: Validierung hält mit dem Tempo der Softwareentwicklung nicht mehr Schritt.
Für Engineering, Test und Projektmanagement bedeutet das: Es geht nicht darum, mehr zu testen, sondern Validierung früher, skalierbarer und wirtschaftlicher einzubetten. So, dass Softwarereife früher entsteht und HIL- sowie Prüfstandsressourcen nicht durch Befunde gebunden werden, die virtuell hätten abgefangen werden können.
Bild 1: Zentrale Rechner und zonale E/E-Architekturen verändern die Validierungslogik im SDV.
Software-in-the-Loop: Validierung folgt der Entwicklung
An genau dieser Stelle entfaltet Software-in-the-Loop (SIL) seine Wirkung. Statt auf verfügbare Steuergeräte oder Prüfstandskapazitäten zu warten, wird die zu prüfende Software virtuell ausgeführt, eingebunden in simulierte Schnittstellen, Kommunikationsmodelle und virtuelle Steuergeräte (vECUs). Funktionen lassen sich damit deutlich früher ausführen, beobachten und automatisiert bewerten, bereits dann, wenn neue Softwarestände entstehen.
Der Effekt ist strukturell: Befunde erreichen die Verantwortlichen früher, in automatisierten Pipelines oft kurz nach dem neuen Softwarestand. Regressionen werden sichtbar, solange der Kontext der Änderung noch präsent ist. Gleichzeitig sinkt der Aufwand für Ursachenanalyse, weil zwischen Auslöser und Symptom weniger Zeit und Integrationstiefe liegen.
Hinzu kommt ein Skalierungsvorteil. Virtuelle Testumgebungen laufen parallel auf Entwicklerrechnern, in der Build-Infrastruktur, im Rechenzentrum oder in der Cloud. Damit entkoppelt sich der Testdurchsatz von der Verfügbarkeit physischer Hardware. Für Organisationen mit vielen Teams, Plattformen und Produktlinien ist das der Hebel, um Validierung in der Breite zu skalieren.
Wichtig bleibt: SIL macht Hardwarevalidierung nicht überflüssig. Reale Elektronik, elektrische Fehlerbilder, Timingeffekte und physikalische Peripherie bleiben Domäne des HIL-Testings und letztlich des Fahrzeugs. SIL macht HIL nicht weniger relevant, sondern wertvoller und wirtschaftlicher.
Arbeitsteilung statt Ersatz
Die Frage »SIL oder HIL?« führt in die Irre. Die eigentliche Frage lautet: Welche Validierungsaufgabe gehört auf welche Stufe und an welchem Punkt der Pipeline?
Bild 2: SIL baut Softwarereife früher auf und reduziert späte Integrationsrisiken vor der HIL-Phase.
SIL spielt seine Stärken in den frühen, häufigen und stark wiederholten Prüfungen aus: Applikationslogik, Kommunikationsverhalten, ECU-Konfiguration und Integration über Stack-Grenzen hinweg. HIL hingegen bleibt unverzichtbar, wo reale Elektronik, Echtzeitanforderungen und elektrische Effekte nicht hinreichend modelliert werden können. Wer SIL ernsthaft etabliert, entlastet HIL nicht nur quantitativ, sondern qualitativ. Prüfstände werden für genau die Aufgaben frei, für die sie gedacht sind (Bild 2). Eine öffentlich dokumentierte Fallstudie von Mercedes-Benz macht deutlich, welches Effizienzpotenzial in einem serverbasierten, automatisierten Testansatz steckt: Rund 95 Prozent der Fehler wurden bereits im Software-in-the-Loop erkannt, bevor sie spätere Validierungsstufen erreichten [1].
Für das Management verändert sich damit die Investitionslogik. Statt weiter linear in physische Prüfkapazität zu skalieren, lässt sich ein wachsender Teil des Validierungsbedarfs über virtuelle Stufen abfangen, bei besserer Skalierbarkeit pro investiertem Euro.
Stufenweise validieren statt maximal simulieren
Virtuelle Steuergeräte werden üblicherweise nach ihrem Integrationsgrad von Level 0 bis Level 4 klassifiziert (Bild 3). Für Entscheider ist weniger die Taxonomie relevant als die ökonomische Logik dahinter: Nicht der höchste Simulationsgrad ist automatisch der beste, sondern der wirtschaftlich passende. Jede zusätzliche Realitätsnähe kostet Aufbau- und Pflegeaufwand sowie Ausführungszeit. Wer das ignoriert, verlagert lediglich den Engpass.
Bild 3: Die Integrationslevel virtueller Steuergeräte.
In der Praxis tragen vor allem zwei virtuelle Stufen den Großteil der Wirkung. Level 1, in dem die Applikationssoftware isoliert läuft, eignet sich für schnelle Funktionsprüfungen, frühes Debugging und Regressionstests direkt im Entwicklungsfluss – ohne Abhängigkeit von Basissoftware oder Zielhardware. Level 3 bezieht Basissoftware, ECU-Konfiguration und Kommunikationsverhalten ein. Diese Stufe beantwortet die teuren Fragen früh: Passt die Konfiguration zur Applikation? Verhält sich die Kommunikation wie spezifiziert? Lässt sich der Software-Stack im Verbund integrieren?
HIL schließt dort an, wo Modelle an Grenzen stoßen. Die strategische Logik ist eindeutig: Softwarereife wird gestuft aufgebaut, nicht in einer späten Abnahme erzwungen.
DevOps ohne SIL endet beim Build
Continuous Integration (CI) und Continuous Delivery (CD) sind in vielen Entwicklungsorganisationen etabliert. Continuous Testing (CT) für eingebettete Fahrzeugsoftware ist dagegen seltener durchgängig umgesetzt. Dafür braucht es Testumgebungen, die jederzeit ausführbar, automatisierbar und reproduzierbar sind, unabhängig von verfügbarer Hardware. Genau darin liegt der strategische Beitrag von SIL.
Eingebettet in Build- und Integrationspipelines wird SIL zum ausführbaren Quality Gate. Nach jeder Änderung lassen sich definierte Testumfänge automatisch starten, Ergebnisse bewerten und Freigabeentscheidungen vorbereiten. Entscheidend ist dabei nicht die Virtualisierung selbst, sondern die Prozessintegration: Die Verbindung von Anforderungen, Softwareständen, Varianten, Testdaten und Reports zu einer nachvollziehbaren Kette.
Erst diese Verbindung beantwortet die Fragen, die Entwicklungsorganisationen tatsächlich umtreiben: Welcher Stand hat welche Tests bestanden? Welche Befunde sind neu? Welcher Reifegrad ist für die nächste Stufe ausreichend? SIL wird damit zu einem Element des Operating Models, nicht als zusätzliche Testdisziplin, sondern als Steuerungsinstrument für Softwarereife.
Komplexität beherrscht man nur im Zusammenspiel
Eine der größten Herausforderungen moderner SDV-Entwicklung ist die Heterogenität der Plattformen. Vom Mikrocontroller bis zur High-Performance-CPU, von sicherheitsrelevanten Echtzeitumgebungen bis zu POSIX-basierten Systemen und Cloud-Ressourcen reicht heute die Spannweite der eingesetzten Technologien. Damit wachsen auch die Unterschiede bei Werkzeugketten, Development Kits, Bibliotheken, Betriebssystemen und Prozessorarchitekturen. Dazu kommen unterschiedliche Lieferantenstrukturen. Das gelingt nicht mit isolierten Tool-Silos. Notwendig ist eine integrierte Validierungsplattform, die virtuelle und physische Validierungsstufen verbindet, Testartefakte wiederverwendbar macht und Transparenz über Reifegrad, Qualität und Integrationsfähigkeit schafft (Bild 4).
Bild 4: Integrierte Validierungslösung als Verbindung von virtuellen und physischen Teststufen.
Konkret heißt das: vECUs in unterschiedlichen Integrationsgraden, eine einheitliche Simulations- und Ausführungsumgebung über SIL- und HIL-Kontexte hinweg, strukturiertes Testdesign mit wiederverwendbaren Testabläufen, belastbare CI/CT-Anbindung sowie Reporting und Traceability, die Ergebnisse mit Anforderungen und Varianten verknüpfen. Vor allem aber braucht es die Fähigkeit, Testlogik zwischen SIL und HIL wiederzuverwenden, statt parallele Testwelten zu pflegen.
Genau hier setzt die Lösung von Vector an: vVIRTUALtarget erstellt virtuelle Steuergeräte (vECUs), CANoe verbindet Simulation und reale Hardware für Tests in SIL- und HIL-Umgebungen, SIL Kit vernetzt verschiedene Simulationsteilnehmer, und vTESTstudio ermöglicht wiederverwendbare Testabläufe. Der eigentliche Wert liegt im Zusammenspiel: Testartefakte bleiben über Stufen hinweg nutzbar, Validierungsergebnisse werden vergleichbar, und Softwarereife lässt sich konsistenter bewerten.
Eine Tooleinführung optimiert lokale Abläufe. Eine Plattform schafft Skalierung, erhöht den Engineeringdurchsatz und macht Softwarereife transparenter.
Virtuelle Validierung gehört auf die Management-Agenda
SIL ist weniger eine Frage der technischen Machbarkeit als der organisatorischen Umsetzung. Der Nutzen entsteht nur, wenn virtuelle Validierung früh eingeplant, mit klaren Zielen eingeführt und in Entwicklung, Integration und Validierung gemeinsam verankert wird. Wird SIL als reines Validierungsthema behandelt, entstehen punktuelle Effizienzgewinne, aber kein struktureller Durchsatzgewinn.
Für die Einführung von SIL sind vier Leitfragen entscheidend: Welche Fehlerklassen wollen wir früh virtuell erkennen? Wann ist ein Softwarestand reif genug für HIL- und Prüfstandsressourcen? Welche Testartefakte, Konfigurationen, Varianten und Reports müssen über SIL und HIL hinweg konsistent bleiben? Und wie fließen Validierungsergebnisse in Reifegrad-, Freigabe- und Priorisierungsentscheidungen ein?
Damit rückt SIL auf die Management-Agenda. Entscheidend sind klare Verantwortlichkeiten, Investitionen in Automatisierung und eine wirtschaftliche Aufteilung zwischen virtueller und physischer Validierung. Im Kern steht die Frage, ob Validierung weiterhin punktuell über einzelne Werkzeuge organisiert wird – oder als durchgängige Plattformfähigkeit der Entwicklungsorganisation.
Fazit: Softwarereife entsteht früher – oder zu spät
Die wachsende Bedeutung von Software-in-the-Loop (SIL) bedeutet nicht, dass Hardwaretests an Relevanz verlieren. Im Gegenteil: Sie werden gezielter gebraucht. Der Punkt ist ein anderer: SDV-Entwicklung benötigt ein Validierungsmodell, das mit der Geschwindigkeit der Software Schritt hält. Änderungen erfolgen häufiger, Integrationsabhängigkeiten werden komplexer, und physische Testinfrastrukturen lassen sich nicht im gleichen Tempo skalieren.
SIL verschiebt Validierung dorthin, wo Software entsteht: früher im Prozess, näher an der Änderung und mit deutlich kürzeren Feedbackzyklen. Dadurch steigt der Testdurchsatz, während HIL-Ressourcen gezielter für die Absicherung reifer Softwarestände eingesetzt werden können. Entscheidend ist die Einbettung in eine durchgängige Validierungsplattform, methodisch, technisch und organisatorisch. Erst dann entsteht eine neue Validierungsökonomie: Softwarereife wird früher aufgebaut, späte Integrationsschleifen werden reduziert, knappe Ressourcen effizienter genutzt und Qualität sowie Releasefähigkeit transparenter steuerbar.
Damit wird SIL für Entscheider zu mehr als einer Testmethode. Es wird zu einem Hebel für Engineeringperformance. Wer virtuelle Validierung strukturiert aufbaut, erweitert nicht nur den Werkzeugkasten der Testorganisation, sondern schafft die Voraussetzung für skalierbare Softwareentwicklung im Software-Defined Vehicle.
Literatur
[1] Vector Informatik GmbH: Enabling SDV Innovation Through Server-Based Automated Testing. Success Story Mercedes-Benz, 2025. Online verfügbar unter: https://www.vector.com/int/en/products/products-a-z/software/canoe-server-editions/success-story-mercedes-benz-vtesting/
Die Autoren
Dr.-Ing. Christian Köllner, Vector Informatik.
Dr.-Ing. Christian Köllner
begann 2013 seine Karriere bei Vector Informatik und übernahm seither Rollen in Softwareentwicklung und Produktmanagement mit Schwerpunkt Virtualisierung. Aktuell verantwortet er als Vice President das Thema SIL und Virtualisierungstools.
Christian Bluthardt, Vector Informatik.
Christian Bluthardt
ist seit 2026 bei Vector Informatik im Business Development tätig und fokussiert sich auf SIL-Plattformen, Validierung und DevOps. Dabei begleitet er Kunden bei der Einführung skalierbarer Software-in-the-Loop-Ansätze und der Verbindung virtueller Validierung mit bestehenden HIL-Prozessen.
