Porsche Engineering will die datengetriebene Fahrzeugentwicklung stärker industrialisieren und setzt dafür auf eine modulare Tool-Landschaft über den gesamten Entwicklungszyklus. Die Tochtergesellschaft positioniert das Paket nicht nur als interne Methode, sondern als lizenzierbares Angebot für Industriekunden. Dahinter steht ein Trend, der die Branche seit Jahren prägt: Wer schneller aus Felddaten lernt, verkürzt Iterationen und verschiebt Wettbewerb von Hardware zu Software.
Porsche Engineering beschreibt die eigene Porsche Engineering Tool-Kette als Antwort auf ein alltägliches Problem moderner Fahrzeugprojekte: Funktionen entstehen nicht mehr in klar getrennten Phasen, sondern werden über Monate nachgeschärft, während Testflotten und Vorserienfahrzeuge ständig neue Daten liefern. Gerade bei Fahrerassistenzsystemen, also ADAS, entstünden große Datenmengen, die ohne systematische Auswertung kaum noch handhabbar seien. In dieser Logik sind ADAS Datenanalyse Tools weniger ein Zusatz, sondern eine Voraussetzung, um Fehlerbilder zu finden, Änderungen zu bewerten und Entscheidungen zu begründen, bevor die Serie festgezurrt ist.
Dass ein Entwicklungsdienstleister diesen Prozess als Produkt verpackt, ist auch ein Signal an den Markt: Datenkompetenz soll nicht nur im OEM-Haus stattfinden, sondern entlang der Lieferkette skalierbar werden. Die modulare Idee deutet darauf hin, dass Porsche Engineering nicht mit einem monolithischen System rechnet, sondern mit heterogenen IT-Landschaften bei Kunden, die einzelne Bausteine integrieren wollen, ohne ihre gesamte Tool-Welt auszutauschen. Gleichzeitig steckt in der Ankündigung ein Anspruch, den viele Anbieter derzeit formulieren, aber selten konsequent einlösen: eine durchgängige Kette vom Fahrzeug bis in die Cloud und zurück, die nicht bei der Analyse endet, sondern auch den Rollout neuer Softwarestände organisiert.
Wer eine Tool-Kette anbietet, verkauft nicht nur Software, sondern auch Prozessmacht
In der Darstellung von Porsche Engineering ist die Tool-Kette vor allem ein Mittel, um die Rückkopplung zwischen Erprobung, Entwicklung und Auslieferung zu verkürzen. Entscheidend sei weniger das einzelne Werkzeug, sondern die abgestimmte Abfolge, die Daten erfasse, transportiere, speichere, auswerte und schließlich wieder ins Fahrzeug zurückbringe. Der Leiter der Fachdisziplin Software Engineering, Dr. Hagen Stübing, fasst den Anspruch so zusammen: „Die Vorteile der datengetriebenen Entwicklung sind in vollem Umfang nutzbar, wenn man entlang der gesamten Entwicklungskette über die nötigen Werkzeuge verfügt“. Hinter diesem Satz steckt ein industriepolitisch interessanter Punkt: Wer die Kette kontrolliert, definiert Standards, Schnittstellen und damit auch, wie schnell Teams arbeiten können und welche Daten in welcher Qualität überhaupt entstehen.
Für Industriekunden kann das attraktiv sein, weil viele Entwicklungsorganisationen an Übergaben scheitern. Daten liegen im Fahrzeug, Logfiles werden manuell gesichert, Analysen laufen in getrennten Systemen, Ergebnisse werden in Tickets übertragen, Updates müssen wieder auf Testträger gespielt werden. Porsche Engineering stellt dem ein Baukastenprinzip gegenüber und ordnet es explizit als Angebot für Externe ein, inklusive Lizenzmodell, also Software as a Product. Das ist mehr als ein zusätzlicher Umsatzkanal. Es ist eine strategische Wette darauf, dass Prozess-Know-how und Tooling künftig ähnlich wichtig werden wie klassische Ingenieursdienstleistungen. Gleichzeitig erhöht ein solches Paket die Bindung, denn wer seine Abläufe auf ein Tool-Ökosystem ausrichtet, wechselt nicht mehr so leicht.
Edge-Analyse und Flottenlogging verschieben das Testen näher an den Alltag
Technisch setzt Porsche Engineering an zwei Stellen an, die in der Praxis oft Zeit kosten: beim Erkennen relevanter Fahrsituationen und beim Einsammeln der passenden Daten. Für frühe Phasen nennt das Unternehmen AMDA V2, ein Werkzeug zur automatisierten Messdatenauswertung direkt im Versuchsfahrzeug. Die Idee dahinter ist nachvollziehbar: Wenn die Auswertung schon während der Fahrt erkennt, ob ein Szenario relevant war und wie sich die Funktion verhalten hat, sinkt der Aufwand für nachträgliche Sortierung. Porsche Engineering verweist dabei auf objektive Bewertungsmaßstäbe über KPIs, etwa um Reaktionen eines Regelsystems in wiederkehrenden Situationen zu vergleichen, ohne dass jedes Mal ein Team im Nachgang manuell suchen muss. Für die datengetriebene Fahrzeugentwicklung ist das ein klassischer Hebel, weil sich Feedback nicht erst Tage später, sondern unmittelbar nach einer Messfahrt in Entscheidungen übersetzen lässt.
In späteren Phasen soll der Porsche Engineering Data Gatherer, kurz PEDG, das Prinzip in die Serie verlängern. Er sei so konzipiert, dass er in ein vorhandenes Steuergerät eingebettet werden könne und damit nicht mehr auf zusätzliche Rechner im Fahrzeug angewiesen sei. Damit wird ein Szenario adressiert, das für viele Hersteller und Zulieferer zunehmend wichtig ist: Erkenntnisse nicht nur aus Prototypen, sondern aus Serienfahrzeugen und daraus abgeleiteten Testflotten zu gewinnen. Porsche Engineering argumentiert, dass sich in Seriennähe Vorgänge automatisch erkennen und Daten gezielt zurückspielen ließen, ohne dass Fahrzeuge physisch in die Werkstatt müssten. Im Kern geht es um Skalierung, denn mit Serienflotten wächst die statistische Basis, aber auch der organisatorische Aufwand. Hier sollen die ADAS Datenanalyse Tools helfen, Daten nicht nur zu sammeln, sondern auch handhabbar zu machen, ohne jedes Fahrzeug einzeln anfassen zu müssen.
Eine eigene LLM-Plattform zeigt, wie sehr Softwareorganisationen nach Produktivität suchen
Auffällig ist, dass Porsche Engineering die Tool-Kette nicht auf Datenerfassung und Infrastruktur begrenzt, sondern auch Entwicklerarbeit im engeren Sinn adressiert. Mit SALLY beschreibt das Unternehmen eine LLM-Service-Plattform, die als digitaler Assistent in der Softwareentwicklung dienen soll. Anders als allgemein bekannte Angebote wie ChatGPT oder Deep Seek solle SALLY Zugriff auf Domänenwissen aus der Entwicklung fortschrittlicher Fahrerassistenzsysteme haben. Für Laien lässt sich das so übersetzen: Ein Sprachmodell soll nicht nur allgemein formulieren, sondern innerhalb eines Projekts mit spezifischen Anforderungen, Tickets und Begrifflichkeiten arbeiten, also dort helfen, wo Entwicklungsorganisationen häufig Zeit verlieren. Porsche Engineering betont, dass sich über natürliche Sprache Informationen abrufen und Aufgaben wie Code-Erstellung, Korrekturen oder Dokumentation unterstützen ließen, zudem über eine API auch weitere Anwendungen andocken könnten.
Das Unternehmen koppelt diese Ebene an eine klassische Datenplattform: Der Porsche Engineering Data Hub soll als zentraler Speicher in der Cloud dienen und Daten in einer Ordnerstruktur ablegen, ergänzt durch Cloud-Indexierung der Metadaten, damit Teams Dateien schneller finden und filtern können. Ergänzend nennt Porsche Engineering eine Edge-Plattform, die Geräte im Fahrzeug mit der Cloud verbindet und auch Updates verteilen kann, bis hin zur Fernverwaltung von Messtechnik über 5G. Dass dabei Docker-Container für die Paketierung von Software genutzt werden, passt zur allgemeinen Entwicklung in Richtung standardisierter Deployment-Prozesse in Fahrzeugprojekten. In Summe entsteht ein Bild, das über einzelne Werkzeuge hinausgeht: Porsche Engineering versucht, eine durchgängige Produktlogik aufzubauen, die Infrastruktur, Datenmanagement und Entwicklerproduktivität verknüpft. Für den Wettbewerb ist das relevant, weil Entwicklungsdienstleister damit näher an das rücken, was früher ausschließlich interne Plattformteams großer Hersteller war. Und für die Politik und Regulierung stellt sich zwangsläufig die Frage, wie Datenflüsse, Zugriffsrechte und Datenschutz in solchen End-to-End-Ketten organisiert werden, wenn mehr Akteure Zugriff auf hochgranulare Fahrzeugdaten bekommen und die Grenzen zwischen Entwicklung und Betrieb weiter verschwimmen.
Quellenhinweis:
Der Artikel basiert auf einer Pressemitteilung von Porsche, die von unserer Redaktion um weitere Informationen ergänzt wurde.
