Vom Pilotprojekt zur Plattform
Software-in-the-Loop wird zur Plattform für das SDV
Software-in-the-Loop soll Fehler früher finden, Tests skalieren und Entwicklungszyklen verkürzen. In einem Webinar des Hauses der Technik diskutierten dSpace und Vector, warum SIL dafür vom Pilotprojekt zum festen Bestandteil der Fahrzeugentwicklung werden muss.
Im Webinar des Hauses der Technik diskutieren dSpace und Vector, wie Software-in-the-Loop Fehler früher aufdecken, HIL-Prüfstände entlasten und virtuelle Tests im SDV skalierbar machen kann.
KI generiert
Software-in-the-Loop, kurz SIL, ist keineswegs neu. Mit komplexeren E/E-Architekturen, Software-defined Vehicles und kürzeren Entwicklungszyklen verändert sich jedoch seine Rolle. Aus einer zusätzlichen Testmethode soll zunehmend ein fester Bestandteil der Softwareentwicklung und -absicherung werden. Darüber diskutierten Dr. Karsten Krügel von dSpace und Dr.-Ing. Christian Köllner von Vector im Webinar „From Pilot to Platform: dSpace and Vector on the Next Era of Software-in-the-Loop“ beim Haus der Technik (HDT). Beide sind zugleich Chairs der Software-in-the-Loop Conference, die am 2. und 3. Dezember 2026 in München stattfindet.
Das Webinar diente damit auch als Auftakt für zentrale Fragen der Konferenz: Wie lässt sich SIL skalieren, wie fügt es sich in bestehende Entwicklungsprozesse ein und wo bleiben reale Hardware und HIL unverzichtbar? Im Kern lässt sich SIL einfach beschreiben: Produktionssoftware wird in einer simulierten Umgebung ausgeführt und getestet, bevor reale Hardware zur Verfügung steht. Entwickler erhalten dadurch früh Rückmeldung zu Änderungen am Code. Für Köllner liegt genau darin der entscheidende Vorteil: „SIL ermöglicht die schnellen Feedback-Zyklen, die Softwareentwickler brauchen. Sie bekommen direkt Rückmeldung zu ihren Commits – und genau das beschleunigt den Entwicklungsprozess insgesamt.“ Vor allem in DevOps- und Continuous-Integration-Prozessen ist diese schnelle Rückkopplung relevant. Tests können bei Änderungen am Softwarestand automatisiert angestoßen werden, Fehler werden damit früher im Entwicklungsprozess sichtbar.
SIL gewinnt mit dem Software-defined Vehicle an Bedeutung
Treiber ist vor allem die steigende Softwarekomplexität. Viele aktuelle Fahrzeugarchitekturen basieren weiterhin auf gewachsenen Softwarestrukturen, während Funktionsumfang und Zahl der Softwarestände steigen. Köllner erwartet deshalb einen Punkt, an dem sich die Entwicklung mit klassischen Methoden kaum noch skalieren lässt. Bei Projekten mit tausenden Softwareentwicklern seien virtuelle Validierungsmethoden erforderlich, um die Komplexität zu beherrschen.
Besonders deutlich zeigt sich dies beim automatisierten Fahren. Krügel hält Software-in-the-Loop hier für einen wesentlichen Zwischenschritt, bevor Software auf reale Hardware und später ins Fahrzeug gelangt. Vergleichbare Anforderungen sieht er auch außerhalb des Automobils, etwa bei Landmaschinen oder Robotik.
Hinzu kommen kontinuierliche Software-Updates. Jeder neue Softwarestand muss überprüft werden, bevor er ins Fahrzeug gelangt. Der Shift-Left-Ansatz verlagert diese Absicherung deshalb zunehmend an den Entwicklerarbeitsplatz, in virtuelle Steuergeräte und SIL-Umgebungen. Dort lassen sich Tests automatisiert in Entwicklungs- und Integrationsprozesse einbinden.
Viele Fehler lassen sich vor dem HIL finden
Welchen Anteil der Absicherung SIL übernehmen kann, hängt vom jeweiligen System und Testziel ab. Als Beispiel nannte Krügel im Webinar ein aktuelles SDV-Projekt, in dem 86 Prozent der Fehler bereits bei frühen SIL-Tests gefunden worden seien. dSpace nennt diese Kennzahl auch für die Virtual Engineering Workbench von Stellantis: Dort würden 86 Prozent der Softwarefehler im SIL identifiziert und 80 Prozent der Systemintegrationstests per SIL durchgeführt.
Die Zahlen zeigen das Potenzial virtueller Absicherung, lassen sich allerdings nur eingeschränkt verallgemeinern. dSpace veröffentlicht weder die absolute Zahl der betrachteten Fehler noch deren Kategorien, den Messzeitraum oder die genaue Berechnungsmethode. Die 86 Prozent sind damit eine projektbezogene Angabe und kein Benchmark für die typische Fehlerabdeckung von SIL.
Das kann HIL-Prüfstände entlasten. Dort bleibt mehr Zeit für Tests, bei denen reale Hardware tatsächlich relevant ist. SIL, HIL und Fahrzeugtest bilden damit unterschiedliche Ebenen der Absicherung. Eine möglichst durchgängige Kette zwischen SIL und HIL gewinnt entsprechend an Bedeutung. Die virtuelle Welt hat zugleich Grenzen. Hardwareintegration, reale elektrische Effekte oder bestimmte Timing-Eigenschaften lassen sich je nach Modellierungsgrad nicht vollständig abbilden. Die Ergebnisse aus SIL müssen daher mit weiteren Testebenen zusammengeführt werden.
Virtuelle Steuergeräte werden zum Schlüssel
Eine zentrale Rolle spielen dabei virtuelle Steuergeräte, also vECUs. Ihre Erstellung kann allerdings aufwendig werden, wenn Software eng mit einer bestimmten Hardware verzahnt ist oder Komponenten aus verschiedenen Abteilungen und Unternehmen benötigt werden. Köllner sieht die Ursache deshalb teilweise schon in der Softwarearchitektur. Hardware-Abstraktion und eine saubere Entkopplung sollten möglichst früh berücksichtigt werden. Wird die Virtualisierung erst nachträglich auf einen bestehenden Codebestand aufgesetzt, steigt der Aufwand. Ziel müsse sein, virtuelle Steuergeräte ähnlich selbstverständlich erzeugen zu können wie ihre realen Gegenstücke.
Damit berührt SIL eine grundsätzlichere Entwicklung: Software und Hardware werden zeitlich stärker voneinander entkoppelt. Ausführbare Softwaremodelle erlauben es, Funktionen zu entwickeln und zu testen, bevor die endgültige Zielhardware bereitsteht. Das Prinzip der Entwicklung vor verfügbarer Hardware verschiebt damit auch Abläufe innerhalb der Fahrzeugentwicklung. KI könnte einige der damit verbundenen Aufwände weiter reduzieren. Krügel verweist unter anderem auf KI-Unterstützung bei der Erstellung virtueller ECUs. Köllner sieht ebenfalls Potenzial entlang des Prozesses, beispielsweise bei Integration und Testfallgenerierung.
Entwicklung und Test rücken enger zusammen
Damit wird aus einer technischen auch eine organisatorische Frage. SIL lässt sich nach Einschätzung der beiden Experten kaum skalieren, wenn Virtualisierung als isolierte Aufgabe eines einzelnen Teams behandelt wird. Entwickler, Tester und Systemarchitekten müssen enger zusammenarbeiten. „Wir müssen diese Silos aufbrechen. Wir müssen Systemarchitektur, Entwickler und Tester in einen Prozess bringen“, sagt Krügel.
Die klassische Trennung zwischen Entwicklung und nachgelagertem Test verliert dadurch an Bedeutung. Im DevOps-Ansatz übernimmt auch der Softwareentwickler Verantwortung für die Verifikation seines Codes. Nach einem Commit können automatisierte virtuelle Tests unmittelbar zeigen, ob Änderungen Auswirkungen auf andere Komponenten oder das Gesamtsystem haben.
Damit wachsen Continuous Integration und Continuous Testing zusammen. Gerade bei SDVs mit zahlreichen Softwareständen reicht es kaum aus, einzelne Testumgebungen zu automatisieren. Entscheidend wird die übergreifende Orchestrierung von CI/CD und Continuous Testing.
SIL wird zur Managementaufgabe
Spätestens beim Übergang vom Pilotprojekt zur unternehmensweiten Plattform reicht eine technische Lösung allein nicht mehr aus. OEMs, Zulieferer, Engineering-Dienstleister und Toolanbieter müssen Entwicklungsartefakte, Testumgebungen und Prozesse aufeinander abstimmen. Für Köllner ist die Verantwortlichkeit deshalb klar: „Das gehört definitiv auf die Management-Ebene.“
Gerade über Unternehmensgrenzen hinweg entstehen neue Fragen. Der Aufwand für Virtualisierung kann an einer anderen Stelle anfallen als der daraus resultierende Nutzen. Gleichzeitig müssen Software, Modelle und Testartefakte zwischen mehreren Partnern verfügbar sein. Bleiben Verantwortlichkeiten und Investitionen ungeklärt, greifen Unternehmen laut Köllner häufig auf bekannte Entwicklungsverfahren zurück.
Standards können dabei helfen. Autosar schafft bereits Grundlagen für die Entwicklung von Steuergerätesoftware, weitere Standards adressieren den Austausch von Modellen und die Interoperabilität unterschiedlicher Werkzeugketten. Nach Ansicht Köllners reicht Standardisierung allein allerdings nicht aus. Prozesse und Workflows müssen ebenfalls auf virtuelle Entwicklung ausgerichtet werden.
Skalierung in der Cloud hat ihren Preis
Einer der größten Vorteile virtueller Tests ist ihre Skalierbarkeit. Tests lassen sich parallel ausführen und bei Bedarf auf Cloud-Ressourcen verteilen. Genau daraus kann allerdings ein neuer Kostenfaktor entstehen. Köllner warnt jedoch davor, einfach tausende Instanzen besonders detaillierter Simulationen parallel auszuführen. Cloud-Ressourcen seien zwar prinzipiell verfügbar, verursachten aber entsprechende Kosten. Entscheidend sei deshalb, wann skaliert wird und welche Simulationsgenauigkeit für einen bestimmten Test tatsächlich erforderlich ist. Auch die Performance der Simulatoren spielt dabei eine wichtige Rolle. Je schneller ein Test ausgeführt wird, desto weniger Rechenzeit muss bezahlt werden. Krügel sieht darin einen wichtigen Ansatzpunkt für Werkzeuganbieter: Die Ausführungsgeschwindigkeit virtueller Modelle beeinflusst direkt die Wirtschaftlichkeit groß skalierter SIL-Infrastrukturen.
GPUs und NPUs setzen der vollständigen Simulation Grenzen
Zusätzliche Herausforderungen entstehen durch spezialisierte Recheneinheiten. Aktuelle Fahrzeugrechner kombinieren CPUs zunehmend mit GPUs, NPUs und DSPs. Eine vollständige Simulation solcher Beschleuniger kann sehr rechenintensiv werden. Köllner hält es deshalb – je nach Testziel – für sinnvoll, spezialisierte Hardware aus der virtuellen Umgebung herauszulösen und real in ein ansonsten virtuelles System einzubinden. Entscheidend bleibt die Frage, welche Eigenschaften für einen konkreten Test tatsächlich benötigt werden.
Somit gewinnen auch Mischformen aus SIL und HIL an Bedeutung. Beide Experten erwarten, dass die Übergänge zwischen den Testwelten möglichst nahtlos werden müssen. Bei einer Kopplung bleiben technische Hürden, insbesondere wenn Teile der SIL-Simulation nicht echtzeitfähig sind. Hybride Szenarien könnten deshalb auch langfristig Bestandteil der Entwicklungslandschaft bleiben.
Faktor zehn als Ziel für virtuelle Entwicklung
Wie groß der Geschwindigkeitsvorteil tatsächlich ausfallen kann, ist eine der zentralen Fragen der Software-in-the-Loop Conference. Ihr Motto lautet „Factor 10 – Myth or Feasible?“. Köllner sieht einen Faktor zehn insbesondere dort als denkbar an, wo der klassische Ablauf aus Software schreiben, auf Hardware flashen, Messmittel anschließen und testen durch die direkte Ausführung in einer simulierten Umgebung ersetzt wird. Krügel verweist zusätzlich auf die erheblich größere Zahl automatisiert ausführbarer Tests.
Am 2. und 3. Dezember 2026 soll diese Diskussion in München fortgeführt werden. Die vom Haus der Technik gemeinsam mit dSpace und Vector vorangetriebene Software-in-the-Loop Conference bringt dafür Anwender, Fahrzeughersteller, Zulieferer und Werkzeuganbieter zusammen. Im Mittelpunkt steht der Schritt, den auch das Webinar bereits umrissen hat: vom einzelnen SIL-Pilotprojekt hin zu skalierbaren virtuellen Entwicklungs- und Testprozessen.
