Software-Defined Vehicle: was der Wandel für Engineering-Prozesse bedeutet

Software-Defined Vehicle: was der Wandel für Engineering-Prozesse bedeutet

Das softwaredefinierte Fahrzeug verschiebt Wert und Komplexität in die Software. Damit ändern sich nicht nur Architekturen. Es ändern sich die Engineering-Prozesse selbst. Anforderungen, Tests und Freigaben werden häufiger und verzahnter. Und sie müssen dauerhaft belegbar bleiben.

Mehr Software heißt mehr Prozess. Und mehr Bedarf an beherrschter Capability. Ein Werkzeugkasten reicht dafür nicht. Es braucht eine auditierbare AI-Engineering-Capability, die mit der Taktzahl der Software mithält.

Mehr Software heißt mehr Prozess.

Damit stehen für Sie als Verantwortliche im Engineering konkrete Fragen im Raum:

• Wie halten wir Traceability, wenn Software-Releases die Taktzahl bestimmen?
• Wie skalieren wir Anforderungs- und Testarbeit, ohne Qualität zu verlieren?
• Wie bleibt der Prozess über die ganze Lebensdauer auditierbar?
• Wo wird AI im SDV-Kontext zum Hebel, und wo nicht?

Dieser Beitrag zeigt, wie das SDV die Prozesse verändert. Und wo eine beherrschte AI-Capability den Unterschied macht.

Warum das jetzt ansteht

Der Wandel zum softwaredefinierten Fahrzeug ist keine ferne Vision. Er ist gegenwärtige Realität. Wert und Differenzierung wandern in die Software. Funktionen kommen über die Lebensdauer per Update dazu. Die Grenze zwischen Entwicklung und Betrieb verschwimmt. Das trifft Organisationen an der empfindlichsten Stelle. Es trifft ihre Prozesse. Diese waren für klar abgegrenzte, hardware-getaktete Meilensteine gebaut.

Wer diese Prozesse nicht mitentwickelt, gerät in eine Zange. Auf der einen Seite steht die höhere Taktzahl. Auf der anderen Seite stehen gleichbleibende Nachweispflichten aus ASPICE, ISO 26262 und ISO 21434. Die Frage ist nicht, ob die Prozesse sich ändern. Die Frage ist, ob eine Organisation den Wandel beherrscht oder von ihm getrieben wird.

Was sich im Engineering ändert

Von Meilenstein zu kontinuierlich

Software-Updates und Over-the-Air-Auslieferung verschieben die Entwicklung. Aus dem großen Meilenstein wird kontinuierliche Lieferung. Anforderungen ändern sich häufiger. Tests laufen öfter. Und jede Änderung muss traceable bleiben. Der Druck auf durchgängige, belegbare Prozesse steigt. Mit ihm steigt der Aufwand, wenn diese Prozesse noch von Hand getragen werden.

Gleichzeitig wächst die Vernetzung. Funktionen reichen über Steuergeräte hinweg. Plattformen werden geteilt. Betriebszeiträume werden länger. Was früher mit einem Meilenstein abgeschlossen war, bleibt über die Lebensdauer in Bewegung.

Traceability unter Taktzahl

Je häufiger geliefert wird, desto schneller zerfällt eine Traceability, die von Hand gepflegt wird. Genau hier entscheidet sich die ASPICE-Fähigkeit. Die Kette von Anforderung über Design und Unit bis Test muss auch bei hoher Änderungsfrequenz konsistent bleiben. Sonst wird jede Abnahme zum Kraftakt.

Wo AI zum Hebel wird

Im SDV-Kontext liegt der Wert von AI nicht in einzelnen Tricks. Er liegt in der Fähigkeit, die gestiegene Taktzahl beherrschbar zu halten.

• Anforderungen strukturieren und Konsistenz halten, wenn die Frequenz steigt.
• Testspezifikationen und Testfälle schneller ableiten, deterministisch und diagnosefähig.
• Evidenzketten über Anforderung, Design, Unit und Test konsistent mitführen.

Der rote Faden bleibt gleich. AI assistiert, der Mensch verantwortet. Gerade unter Taktzahl ist diese Trennung kein Bremsklotz. Sie ist die Voraussetzung dafür, dass Geschwindigkeit nicht zulasten der Nachweisbarkeit geht.

Capability statt Werkzeugkasten

Im SDV-Kontext reicht ein Werkzeugkasten nicht. Es braucht eine beherrschte, auditierbare AI-Engineering-Capability. Sie muss mit der Taktzahl der Software mithalten. Plattform, Governance und Engineering-Agenten gehören als System zusammen. Nicht als lose Tools. Wie sensified softwaredefinierte Fahrzeuge begleitet, zeigt die Seite zum Software-Defined Vehicle.

Häufige Fehler im SDV-Wandel

• Werkzeuge statt Capability. Einzelne Tools einkaufen, ohne Plattform und Governance zu verbinden.
• Traceability von Hand. Manuelle Pflege, die unter hoher Taktzahl zerfällt.
• Tempo vor Nachweis. Schneller liefern, aber die Evidenzkette nicht mitführen.

Der Einstieg muss nicht der große Umbau sein. Ein klar abgegrenzter Workflow-Pilot zeigt unter realer Taktzahl, ob die Kette hält. So wird der Wandel zu einer Abfolge belegter Ausbaustufen.

So gehen wir vor: Build, Operate, Transfer

Eine SDV-taugliche AI-Engineering-Capability bauen wir nicht als Folienkonzept. Wir bauen es als produktive Fähigkeit. Das folgt dem Prinzip Build, Operate, Transfer. Unsere Beteiligung nimmt über die Phasen ab. Ihre Capability wächst ins eigene Haus. Der Wissenstransfer ist vertragliches Erfolgskriterium, kein Zusatz. Sonst entsteht genau der Lock-in, den wir vermeiden wollen.

1. Build. Setup, Guardrails und erste Workflows entlang Ihres realen Prozesses.
2. Operate. Betrieb mit KPI-Verantwortung auf Wertstrom-Ebene. Nie auf Personen-Telemetrie.
3. Transfer. Dokumentierte Übergabe. Ihr Team übernimmt Tooling, Wissen und Betrieb.

Getragen wird das von drei Modulen. Erstens ein Strategic Engineering Lead. Das ist ein Senior-Embedded-Architekt zusammen mit einem Strategic AI Lead. Zweitens die auditierbare Tooling-Plane sensified AI-OS. Drittens die Automotive-Playbooks. Sie beschreiben die Methodik für AI in Embedded-, ASIL-, ASPICE- und AUTOSAR-Kontexten. Die Leitplanke, was AI nicht entscheidet, ist darin fest verankert.

Die vier Mandat-Typen sind kombinierbar. Sie passen sich Ihrem Reifegrad an. Es gibt den Strategic Engineering Lead für den breiten Aufbau. Es gibt die BOT Engineering-Capability als Programm-Paket je Domäne. Es gibt den ASPICE- oder ASIL-Workflow-Pilot zur Validierung vor dem Mandat. Und es gibt das Modul Tooling, MCP und AI-Governance mit Schlüssel-Isolation und Kosten-Transparenz. Der Einstieg ist bewusst risikoarm. Zuerst ein Qualifying-Call zum Fit-Check. Dann NDA und Discovery-Workshop. Danach der Workflow-Pilot. Erst dann das BOT-Mandat mit Governance-Plane. Kommerzielle Details klären wir im Discovery-Workshop, nicht über öffentliche Preislisten.

Gemessen wird auf Wertstrom-Ebene, nie an Personen. Wir messen Kosten je Wertstrom, den Produktivitäts-Zuwachs und die reale Nutzung. So bleibt jederzeit belegbar, ob sich die Fähigkeit rechnet. Das entscheidet über den nächsten Ausbauschritt. Der Betrieb erzeugt keine Chat-Historie als Ergebnis. Er erzeugt prüfbare Artefakte, die in Ihren Prozess passen. Dazu gehören Reports, Traceability-Matrizen und ausführbare Testsuiten.

Der Pilot ist bewusst klein gehalten. Er dauert wenige Wochen. Er nimmt sich einen realen Ausschnitt Ihres Prozesses vor, nicht ein Laborbeispiel. Am Ende steht ein belastbarer Beleg. Sie sehen, ob die Kette hält und ob sich der Aufwand lohnt. Erst auf dieser Basis entscheiden wir gemeinsam über das volle Mandat. So bleibt jedes Investment an ein sichtbares Ergebnis gebunden.

Was der SDV-Wandel für die Bewertung einzelner Tätigkeiten bedeutet, zeigt das Wertbeitrags-Prinzip im Automotive Software Engineering. Die Plattform-Konsequenz beschreibt der Beitrag zur Abstraktionsschicht ohne Vendor-Lock-in.

Fazit

Es gibt einen Unterschied zwischen zwei Sätzen. Der erste lautet: Wir nutzen AI-Tools. Der zweite lautet: Wir besitzen eine beherrschte, auditierbare AI-Engineering-Capability. Dieser Unterschied entscheidet, ob AI im Serienprogramm trägt oder im Pilot versandet. Genau diese Entscheidungen hat sensified für den eigenen Betrieb getroffen. Sie sind in einem realen ASPICE-Serienprogramm gebaut. Deshalb kommt sensified mit einer Position, nicht mit Fragen.

Drei Dinge unterscheiden diesen Ansatz. Es gibt einen klaren Plan, belegt durch eigenes, produktives IP. Wir bauen es mit, bis es ASPICE-konform in Produktion läuft. Und es gibt keinen Vendor-Lock-in, abgesichert durch modell-agnostische Architektur und Transfer als Erfolgskriterium. Zwei Tiefen treffen dabei in einem Partner zusammen. Das ist etabliertes Automotive- und SDV-Wissen. Und es ist AI-Engineering-Tiefe aus eigener Plattform.

Wie dieser Baustein in eine beherrschte Gesamt-Capability passt, zeigt unsere Seite zur AI-Transformation im Automotive-Engineering. Den strategischen Rahmen erklärt der Beitrag AI im Engineering ist ein Capability-Thema, kein Tool-Thema. Der nächste Schritt ist ein Discovery-Workshop. Dort ordnen wir Ihren Prozess, Ihre Compliance-Lage und den ersten sinnvollen Use-Case gemeinsam ein.

Das Wichtigste in Kürze

• SDV verschiebt Wert in die Software. Prozesse werden häufiger und verzahnter.
• Unter hoher Taktzahl zerfällt handgepflegte Traceability. Konsistenz wird kritisch.
• AI hält Anforderungen, Tests und Evidenzketten beherrschbar. Assistierend, nicht entscheidend.
• Es braucht eine Capability als System, keinen Werkzeugkasten.