„Wer einen Fehler zu spät findet, hat den Entwicklungszyklus bereits verloren“

CANoe ist seit 30 Jahren in der Entwicklung etabliert und gilt in vielen Bereichen als Branchenstandard für Test, Simulation und Validierung. Gleichzeitig hat sich die Fahrzeugentwicklung in dieser Zeit fundamental verändert. Herr Traub, was ist aus Ihrer Sicht das Prinzip dahinter, dass ein Werkzeug über so lange Zeit relevant bleibt?

Dr. Matthias Traub: Entscheidend ist, dass wir nicht in Beständigkeit verharren, sondern kontinuierlich erneuern. Das gilt für CANoe, aber auch für unsere anderen Produkte und Lösungen. Wir verfolgen seit vielen Jahren eine klare Technologiestrategie: erst CAN, dann LIN, FlexRay und Ethernet, heute Themen wie Virtualisierung, Cloud-Anbindung und KI. Der Schlüssel ist, technologische Entwicklungen früh zu antizipieren und nicht erst zu reagieren, wenn der Markt bereits danach fragt. Zudem ist die Nähe zum Kunden zentral. Wir müssen verstehen, was in der Entwicklung tatsächlich gebraucht wird, wo Prozesse nicht mehr passen und welche Anforderungen in unsere Roadmaps zurückgespielt werden müssen. Aus dieser Verbindung von Technologieführerschaft, Kundendialog und Anpassungsfähigkeit entsteht langfristige Stärke.

Woran erkennen Sie denn konkret, dass sich ein Produkt wie CANoe weiterentwickeln muss?

Dr. Matthias Traub: Hauptsächlich im Dialog mit dem Kunden. Vector ist nicht nur Anbieter von Werkzeugen, sondern Entwicklungspartner. Ein Beispiel ist unsere Zusammenarbeit mit Mercedes-Benz: Dort sind wir Hauptentwicklungspartner für MB.OS und arbeiten in gemischten Teams an der Softwareplattform mit. Werkzeuge wie CANoe kommen dort direkt zum Einsatz. Unsere Mitarbeitenden erleben im Projektalltag gemeinsam mit dem Kunden, was funktioniert, wo Grenzen entstehen und wo wir Dinge anpassen oder beschleunigen müssen. Diese enge Zusammenarbeit prägt die Art, wie wir Produkte entwickeln. Und sie ist wesentlicher Erfolgsfaktor, auch auf dem Weg zu agentischen Workflows – also KI-gestützten Abläufen, die wiederkehrende Engineering-Aufgaben selbstständig ausführen und Entwickler gezielt unterstützen. Ziel ist es, entlang der gesamten DevOps-Kette agentische Workflows bereitzustellen.

Das klingt nach einem permanenten Realitätsabgleich. Ist diese Nähe zum Entwicklungsalltag der eigentliche Erfolgsfaktor?

Dr. Matthias Traub: Ja – aber nicht im Sinne eines reinen Zuhörens. Nähe zum Kunden heißt für uns, gemeinsam an den realen Entwicklungsthemen zu arbeiten und daraus robuste, skalierbare Lösungen abzuleiten. Ich war selbst über zwanzig Jahre bei OEMs tätig und kenne die Erwartung aus dieser Perspektive gut. Man möchte mit Partnern arbeiten, die nicht nur ein Produkt bereitstellen, sondern die Systemzusammenhänge verstehen. Wir entwickeln unsere Lösungen gemeinsam mit den Kunden weiter und passen sie für deren Anforderungen an.

Wenn man diesen Entwicklungsalltag betrachtet, hat sich vor allem die Rolle von Software verändert. Wo liegt aus Ihrer Sicht der grundlegendste Bruch in Entwicklung und Absicherung softwaredefinierter Systeme?

Jan Linnebacher: Absicherung ist heute kein Phasenthema mehr. Das klassische Muster – spezifizieren, implementieren, auf Hardware deployen und anschließend testen – funktioniert bei software-definierten Systemen nicht mehr. Es gibt Kunden, die täglich neue Releases entwickeln. Absicherung wird damit zu einem begleitenden Teil des Entwicklungsprozesses. Und sie endet nicht mit dem SOP. Durch Software-Updates kommen neue Funktionen in kurzen Zyklen ins Fahrzeug und müssen über den gesamten Lebenszyklus hinweg abgesichert werden. Hinzu kommt: Wir testen nicht mehr nur einzelne Funktionen. Durch domänenübergreifende Systeme und kontinuierliche Implementierungen wächst die Komplexität stetig weiter.

Save the date: 31. AUTOMOBIL-ELEKTRONIK Kongress

Am 22. und 23. Juni 2027 findet zum 31. Mal der Internationale AUTOMOBIL-ELEKTRONIK Kongress (AEK) statt. Dieser Netzwerkkongress ist bereits seit vielen Jahren der Treffpunkt für die Top-Entscheider der Elektro-/Elektronik-Branche und bringt die Automotive-Verantwortlichen und die relevanten High-Level-Manager der Tech-Industrie zusammen, um gemeinsam das ganzheitliche Kundenerlebnis zu ermöglichen, das für die Fahrzeuge der Zukunft benötigt wird. Trotz dieser stark zunehmenden Internationalisierung wird der AUTOMOBIL-ELEKTRONIK Kongress von den Teilnehmern immer noch als eine Art "automobiles Familientreffen" bezeichnet.

Sichern Sie sich Ihr(e) Konferenzticket(s) für den 31. Automobil-Elektronik Kongress (AEK) im Jahr 2027! Folgen Sie außerdem dem LinkedIn-Kanal des AEK und #AEK_live. 

Im Channel zum Automobil-Elektronik Kongress finden Sie Rück- und Vorberichterstattungen sowie relevanten Themen rund um die Veranstaltung.

Dr. Matthias Traub: Für mich ist die Veränderung noch grundlegender. Software wird vom Bestandteil zum bestimmenden Faktor der Fahrzeugentwicklung. Das verändert zwangsläufig auch die Rollenmodelle. Früher stand das einzelne Steuergerät im Mittelpunkt. Heute sprechen wir von hochvernetzten Systemen, in denen Software die Hauptrolle übernimmt. Dadurch gehen OEMs stärker in Verantwortung. Der Ansatz „Shift Left“ beschreibt genau diese Verschiebung: Absicherung beginnt früher im Entwicklungsprozess – etwa in Software-in-the-Loop Umgebungen, mit virtuellen Steuergeräten oder direkt am Entwicklerarbeitsplatz. Dadurch lassen sich Fehler früher erkennen, lokaler eingrenzen und die spätere Gesamtintegration wird effizienter und schneller.

Woran erkennt man, dass Shift Left wirklich verstanden wurde und mehr ist als nur früheres Testen?

Dr. Matthias Traub: Daran, ob sich Rollen, Prozesse und Toolchains tatsächlich verändern. In der klassischen Fahrzeugentwicklung war die Arbeit stark am V-Modell orientiert: Spezifikation, Umsetzung, Test, Integration. Diese Aufgaben verschmelzen heute stärker. Ein Software-Applikationsentwickler führt im Hintergrund, teilweise mit KI-Unterstützung, bereits Tests durch und fängt Fehler deutlich früher ab. Ebenso wichtig ist das Plattformverständnis. Früher wurden Fahrzeugprojekte bei OEMs häufig neu gedacht. Heute geht es stärker um Plattformen, ähnlich wie in der Mobilfunkwelt: Man hat ein Betriebssystem, eine Softwareplattform und entwickelt diese kontinuierlich weiter.

Wenn sich diese Entwicklungslogik verändert, verändert sich zwangsläufig auch CANoe. Was lässt sich am aktuellen Stand von CANoe darüber ablesen, was Kunden heute wirklich umtreibt?

Jan Linnebacher: CANoe kommt aus einer Zeit, in der die Buskommunikation im Mittelpunkt stand: CAN, später LIN, FlexRay, Ethernet. Kunden mussten nachvollziehen können, was zwischen vernetzten Steuergeräten passiert. War ein Steuergerät noch nicht verfügbar, musste es sich simulieren lassen. Dieser Grundgedanke trägt bis heute. Der eigentliche Wandel zeigt sich jedoch darin, was daraus geworden ist: Wir haben CANoe konsequent vom Simulationswerkzeug zur Validierungsplattform ausgebaut, die sich in die Entwicklungsworkflows unserer Kunden einfügt. Heute fragen Kunden weniger nach einzelnen Features. Sie wollen CANoe als Testing-Plattform und Enabler für ihre Entwicklungsprozesse nutzen. Deshalb setzen wir auf „As code“-Paradigmen: Konfigurationen liegen als Text vor, Teams können gemeinsam daran arbeiten, sie versionieren und in moderne Entwicklungsumgebungen integrieren. CANoe läuft in CI/CT-Umgebungen, in der Cloud, unter Linux und in naher Zukunft auch auf ARM-Architekturen.

Dr. Matthias Traub: Und natürlich spielt heute KI eine zentrale Rolle. Ein wichtiges Feature, das wir mit dem aktuellen CANoe 20 Release ausliefern, ist die MCP-Schnittstelle, also das Model Context Protocol. Damit schaffen wir eine Anbindung, über die KI-Systeme mit CANoe interagieren können. Gleichzeitig führen wir schrittweise eigene KI-Assistenten und Agenten ein. In CANoe sind das beispielsweise ein Assistant für CAPL oder für die automatische Testgenerierung. Diese Funktionen passen genau zu den neuen Rollen, die Jan beschrieben hat.

Die Branche spricht viel über „China Speed“. Entwicklungszyklen werden kürzer, zugleich steigt die technische Komplexität. Woran entscheidet sich, ob Entwicklungsteams mithalten können?

Jan Linnebacher: Maßgeblich ist, wie konsequent abgesichert wird – und wann. Wer einen Fehler sehr spät findet, im schlimmsten Fall im Fahrzeug, hat den Entwicklungszyklus bereits verloren. Shift Left bringt Virtualisierung mit sich. Wer Fehler in einer virtuellen Umgebung, in der vECU oder direkt im Code findet, gewinnt Zeit. Ein Kunde aus dem Bremsregelsystem-Umfeld verlor rund 15 Wochen, weil ein Software-Fehler erst spät am HIL sichtbar wurde. Die anschließende zeitaufwändige Untersuchung zeigte, dass die Ursache in einer fehlerhaften Regelstrecke in der Software lag, die Druckspitzen verursachte. In einer virtuellen Umgebung hätte sich dieser Fehler deutlich früher identifizieren lassen. Genau diese Konsequenz in der Absicherung brauchen wir, um mit den kurzen Entwicklungszyklen asiatischer Wettbewerber mitzuhalten, ohne dabei unseren Qualitätsanspruch aufzugeben.

Vector vereinfacht den Einstieg in die SOVD Fahrzeugdiagnose

Mit einer durchgängigen SOVD-Toolkette unterstützt Vector Automobilhersteller und Zulieferer bei der Einführung der serviceorientierten Fahrzeugdiagnose. Die Lösung beschleunigt Entwicklung, Validierung und Integration in softwaredefinierte Fahrzeugarchitekturen.

Dr. Matthias Traub: Die Diskussion über China Speed wird häufig auf Entwicklungsgeschwindigkeit reduziert. Aus meiner Sicht geht es vielmehr um die Fähigkeit, Geschwindigkeit, Qualität und Skalierbarkeit gleichzeitig zu beherrschen. Genau dort entscheidet sich Wettbewerbsfähigkeit. Es braucht ein passendes organisatorisches Setup mit veränderten Rollen – beim OEM ebenso wie in der Zusammenarbeit mit Partnern. Dazu kommt die technologische Basis: CI/CT, Durchgängigkeit und „as code“ sind zentrale Elemente. Automatisierte Abläufe werden zunehmend über Skripte und agentische Workflows gesteuert. Dadurch verschiebt sich die Rolle des Entwicklers stärker in Richtung Gestaltung und Überwachung. Gleichzeitig bleibt die Abnahme nach dem Vier-Augen-Prinzip wichtig. Viele chinesische und asiatische Hersteller konnten hier auf der grünen Wiese starten und aktuelle Prozessmuster direkt anwenden. Gleichzeitig sehen wir bei Safety- und Security-Standards, die wir in Europa als etabliert betrachten, teilweise Nachholbedarf. Darin liegt auch die Chance, europäische Qualitätsansprüche wieder als Wettbewerbsvorteil auszuspielen.

Wenn Entwicklungszyklen schneller werden und Absicherung früher ansetzen muss, liegt der Blick auf KI nahe. Wo sehen Sie heute schon konkrete Anwendungen in Simulation, Test und Validierung – und wie verändert das die Rolle des Testingenieurs?

Jan Linnebacher: Vor allem bei Aufgaben, die für Entwickler und Testingenieure sehr zeitaufwendig sind. Ein Beispiel ist die Ableitung von Testfällen aus Requirements. Das ist für KI-Ansätze bereits gut möglich, schnell und zunehmend präzise. Ein weiteres Feld ist die Logfile-Analyse. Wir sprechen hier über die stundenlange Auswertung von Log- und Messdaten, in denen Muster erkannt und Zusammenhänge bewertet werden müssen. KI kann solche Daten deutlich schneller strukturieren, Auffälligkeiten markieren und Hypothesen vorbereiten. Bewertung und Freigabe der Ergebnisse bleiben jedoch weiterhin beim Menschen. Aber bei zeitraubenden Testing-Aufgaben liegt schon heute ein großer Hebel.

Dr. Matthias Traub: Für mich ist entscheidend, KI nicht als isoliertes Feature zu betrachten. Der eigentliche Hebel entsteht, wenn KI in die gesamte DevOps-Loop eingebettet wird und wiederkehrende Aufgaben automatisiert unterstützt. Dadurch entsteht nicht nur ein Geschwindigkeits-, sondern auch ein Robustheitsgewinn. Fehler werden früher gefunden und lokal eingegrenzt, sodass sich Teams in der Gesamtsystemintegration auf die wesentlichen Themen konzentrieren können. Viele Aufgaben, die bisher ein Testingenieur übernommen hat, werden künftig in automatisierten CI/CT-Chains im Hintergrund ablaufen und von Agenten unterstützt. Dennoch bleibt Human-in-the-Loop zentral. KI kann den Menschen im Entwicklungsalltag entlasten und Prozesse beschleunigen, aber Verantwortung, Einordnung und Freigabe bleiben beim Menschen.

Bis hierhin ging es stark um Geschwindigkeit. Aber kontinuierliche Absicherung ist nicht nur eine Frage kürzerer Entwicklungszyklen. Warum wird die Fähigkeit, Software skalierbar abzusichern, auch jenseits von Geschwindigkeit zu einem Differenzierungsfaktor?

Dr. Matthias Traub: Es geht um Wartbarkeit und Robustheit. Aus Endkundensicht zählt am Ende, dass ein System, das ich im Fahrzeug nutze oder per OTA-Update erhalte, zuverlässig funktioniert und keine Fehler erzeugt. Der erste Wert ist Geschwindigkeit: neue Funktionen oder Bugfixes schnell bereitzustellen, wie man es aus der Smartphone-Welt kennt. Der zweite Wert ist Verlässlichkeit. Gerade für die deutsche Automobilindustrie kommt es darauf an, den hohen Qualitätsanspruch der Kunden auch in einer schnelleren Softwarewelt zu erfüllen und diese Verlässlichkeit im Idealfall sogar zu erhöhen.

Wie Software 2026 Systeme, Fahrzeuge und Sicherheit prägt

2026 verschieben sich die Grundlagen der Elektronikindustrie: Software definiert Systeme, Fahrzeuge werden zu Softwareplattformen, RISC-V und Rust verändern Toolchains und Cybersecurity wird durch neue Regularien zum Pflichtbestandteil jeder Entwicklung.

Software entsteht heute in vernetzten Umgebungen: über Abteilungen, Unternehmensgrenzen und Toolchains hinweg. Was entscheidet, ob solche Ökosysteme funktionieren oder scheitern?

Jan Linnebacher: Offenheit. Offene Tools sind ein zentraler Erfolgsfaktor. Die Realität im SDV-Kontext besteht aus Partnerschaften: zwischen OEMs, Tier-1s, Softwarefirmen und Technologiepartnern. Dafür braucht es offene, skalierbare Produkte, die schnell einsatzbereit und einfach integrierbar sind. Ebenso braucht es Modelle für Zusammenarbeit, die wir als Vector mit unseren Kunden vorantreiben. Jeder muss sich als Brückenbauer verstehen. Wer nur den eigenen Teil optimiert und nicht nach links oder rechts schaut, wird in solchen Strukturen scheitern.

Dr. Matthias Traub: Offenheit bedeutet für mich nicht, dass ein Anbieter alles selbst abdecken muss. Offenheit bedeutet, die besten
Fähigkeiten unterschiedlicher Partner so zusammenzubringen, dass daraus ein funktionierender Gesamtansatz entsteht. Deshalb arbeiten wir mit Technologiepartnern wie Synopsys bei der Virtualisierung oder QNX bei der Software-Plattform zusammen. Mit Blick auf die Automobilindustrie scheitert Zusammenarbeit oft an unterschiedlichen Wissensständen. Man gründet große Softwareorganisationen und merkt dann, dass viele Mitarbeitende bisher vor allem spezifiziert haben, aber noch nicht die notwendige Softwarekompetenz mitbringen. Deshalb muss man stark auf Skills achten. Und es braucht Augenhöhe: Früher waren die Rollen zwischen OEMs und Partnern stärker hierarchisiert. Heute müssen Teams über Unternehmensgrenzen hinweg gemeinsam Lösungen erarbeiten.

Wenn man all diese Entwicklungen zusammennimmt, woran wird sich in den nächsten fünf Jahren entscheiden, welche Unternehmen bestehen können?

Jan Linnebacher: Daran, wie konsequent Unternehmen sich auf Software ausrichten. Wer Software und KI-gestützte Workflows nicht ernst nimmt und in der Organisation verankert, wird sich schwertun. Die beste Toolchain hilft nicht, wenn Virtualisierung, Testautomatisierung und KI-Unterstützung nur punktuell zum Einsatz kommen statt durchgängig im Entwicklungsprozess. Offenheit, Kollaboration und Transparenz über Domänen- und Partnergrenzen hinweg werden zentrale Voraussetzungen. Wir sehen schon heute, wie rasant die Entwicklung in den vergangenen drei, vier Jahren war. Ich glaube nicht, dass diese Entwicklung linear weitergeht. Sie wird wahrscheinlich noch steiler.

Dr. Matthias Traub: Aus meiner Sicht kommt es jetzt darauf an, die richtigen Rahmenbedingungen zu schaffen. Wir tragen dazu bei, kollaborative Arbeitsmodelle zu etablieren – in Projekt-Setups ebenso wie an den technologischen Schnittstellen. Eine Leitplanke dabei ist Modularität: Unsere Lösungen müssen sich mit unserem Portfolio, aber auch mit Third-Party-Lösungen kombinieren lassen. Hinzu kommen agentische Workflows. Hier wollen wir mit unserem Domänen-Know-how und unserem Ökosystem eine robuste Foundation bereitstellen, auf die sich Kunden verlassen können. Für Vector ist es wichtig, zum Technologiestandort Deutschland beizutragen: mit Geschwindigkeit, Robustheit und Technologie-Know-how im globalen Wettbewerb.

RTI und Vector testen DDS-basierende Anwendungen

RTI kombiniert die eigene DDS-Plattform Connext mit dem Simulations,- Analyse- und Testwerkzeug CANoe.DDS von Vector und schafft damit eine vollständige Simulations- und Testumgebung für alle DDS-Funktionen.