„Open-Source-Communities sind außergewöhnlich stark“

Mit wachsender Komplexität softwaredefinierter Fahrzeugprogramme steigt in der Automobilbranche der Druck, flexible Architekturen in robuste Produktionsplattformen zu überführen. Open-Source-Bausteine gewinnen dabei immer mehr an Bedeutung. Gleichzeitig verlangen Serienprogramme (weiterhin) Stabilität, Rückverfolgbarkeit, Safety-Konformität und langfristige Wartbarkeit.

Genau dieses Spannungsfeld thematisiert Paula Herzog, Head of Product Program Management bei Qorix, in ihrem Vortrag auf der Automotive Software Strategies Conference 2026 in München. Auf Basis ihrer Erfahrungen bei Bosch, ZF und ihrem jetzigen Arbeitgeber erläutert sie, wie sicherheitskritische und echtzeitfähige Embedded-Systeme produktionsreif werden können. Im Vorfeld der Veranstaltung haben wir mit ihr dazu ein Interview geführt

Frau Herzog, mit Blick auf die nächsten drei bis fünf Jahre: Was wird die größte Herausforderung dabei sein, offene Softwareplattformen in Serienautomobilprogramme zu bringen?

Der schwierigste Teil wird nicht darin bestehen, offene Softwareplattformen aufzubauen. Der schwierige Teil wird ihre Industrialisierung sein – also vielversprechende Technologie in etwas zu verwandeln, auf das ein Serienautomobilprogramm seinen Zeitplan und seine Safety Case tatsächlich stützen kann. Open-Source-Innovationen bewegen sich schnell. Automobilprogramme brauchen Stabilität, Vorhersehbarkeit und die Einhaltung funktionaler Sicherheitsstandards wie ISO 26262. In der Praxis sehen wir eine wachsende Lücke zwischen dem, was die Upstream-Community liefert, und dem, was OEM-Programme tatsächlich ausrollen können. Diese Lücke zu schließen, ist in erster Linie kein Technologieproblem. Es ist eine Frage von Verantwortung, Governance und Lebenszyklusdisziplin. Die Branche hat die vergangenen Jahre damit verbracht auszuloten, was Open Source leisten kann. In der nächsten Phase geht es darum, dies im großen Maßstab funktionsfähig zu machen – wiederholt, verlässlich und unter realen Programmbedingungen.

Key Facts – Automotive Software Strategies Conference 2026

Was ist die Automotive Software Strategies Conference? Die Automotive Software Strategies Conference ist eine Fachkonferenz mit Fokus auf Software-Defined Vehicles, Automotive-Softwarearchitekturen und neue Entwicklungsparadigmen. Sie bringt OEMs, Zulieferer, Technologieunternehmen und Engineering-Spezialisten zusammen, um die Zukunft der Fahrzeugsoftware zu diskutieren.

Wann findet die Veranstaltung statt? Die Konferenz findet am 19. und 20. Mai 2026 statt.

Wo findet die Veranstaltung statt? Der Veranstaltungsort ist das Hochhaus des Süddeutschen Verlags in München.

Für wen ist die Konferenz gedacht? Die Veranstaltung richtet sich an Softwarearchitekten, Systemingenieure, Plattformentwickler, Engineering Manager sowie Entscheidungsträger, die an Automotive-Softwareplattformen, SDV-Architekturen und digitalen Fahrzeugökosystemen arbeiten.

Welche Themen werden auf der ASSC 2026 behandelt? Softwarearchitekturen und Softwarefabriken, Betriebssysteme und Middleware, die Programmiersprache Rust in Automotive-Systemen, Simulation und Virtualisierung, KI-gestützte Softwareentwicklung, Datennutzung und Datenmanagement sowie softwarebasierte Geschäftsmodelle.

Welche Unternehmen werden vertreten sein? Zu den Sprechern und Teilnehmern zählen Experten von Unternehmen wie Jaguar Land Rover, Mercedes-Benz, BMW, Renesas, Infineon, Microsoft, Google Cloud, AVL, IAV, ZF, Schaeffler und Green Hills Software.

Warum ist die Konferenz für die Branche relevant? Da sich Fahrzeuge zunehmend zu softwaredefinierten Plattformen entwickeln, untersucht die Konferenz, wie neue Softwarearchitekturen, Entwicklungsprozesse und Datenstrategien die Zukunft der automobilen Innovation prägen werden.

Wo gibt es Tickets für die Konferenz? Tickets gibt es auf der offiziellen Event-Page zur ASSC 2026.

Welche Rolle Middleware im SDV-Zeitalter spielt

Welche heute getroffene Plattformentscheidung wird am stärksten beeinflussen, wie offene Middleware über SDV-Programme hinweg skaliert?

Die folgenreichste Entscheidung ist täuschend einfach: Wird Middleware als gemeinsame, nicht differenzierende Grundlage behandelt oder baut und integriert jedes Programm sie von Grund auf neu? OEMs, die diese Schicht früh standardisieren, gewinnen einen sich verstärkenden Vorteil. Eine stabile Middleware-Basis skaliert über Domänen, Plattformen und Fahrzeuggenerationen hinweg. Wer das nicht tut, zahlt immer wieder dieselbe Integrationssteuer – Programm für Programm. Was wir durchgängig sehen, ist: Der Erfolg hängt von einer sauberen Trennung der Verantwortlichkeiten ab – Hardware, Betriebssystem, Middleware, Applikationen – und davon, sicherzustellen, dass die Middleware-Schicht robust genug ist, nicht nur ein Programm, sondern viele zu tragen. Wenn diese Architektur einmal richtig aufgesetzt ist, zahlt sie sich über Jahre hinweg aus.

Ihre Präsentation auf der ASSC konzentriert sich auf die Bereitstellung von Eclipse S-CORE für sicherheitskritische Systeme. Was braucht es, um ein offenes Projekt produktionsreif zu machen?

Produktionsreife betrifft all das, was im Code nicht sichtbar ist. Abstimmung auf funktionale Sicherheit, Rückverfolgbarkeit, Testabdeckung, Release-Management und langfristige Wartung – nichts davon ist in einem Repository direkt zu sehen, aber genau davon hängt ein Automobilprogramm tatsächlich ab. Hinzu kommt die Integrationsarbeit über SoCs, Betriebssysteme und Echtzeitumgebungen hinweg, und dann wird deutlich, warum „Open Source“ und „produktionsreif“ sehr unterschiedliche Aussagen sind. Bei Qorix begegnen wir dem, indem wir Open-Source-Zusammenarbeit mit einem distributionsbasierten Modell auf Produktionsniveau kombinieren. Das offene Projekt liefert die gemeinsame Basis. Produktionsreife wird durch systematische Härtung, Validierung und jene Supportstrukturen erreicht, auf denen OEM-Programme einen belastbaren Programmplan aufbauen können. Das haben wir auf der CES konkret gezeigt – vier End-to-End-Demonstratoren über unterschiedliche Partner, Plattformen und Anwendungsfälle hinweg, alle auf einer konsistenten Middleware-Basis. Klar wurde dabei: Produktionsreife dreht sich nicht um einzelne Features. Es geht darum, komplexe Systeme mit gemischten Kritikalitätsstufen in realen automobilen Umgebungen verlässlich funktionieren zu lassen.

Ready Ride: Der nächste Schritt zum vernetzten Motorrad

Die Motorradwelt galt lange als digitales Entwicklungsland. Eine neue Plattform für vernetzte Motorräder von Harman kombiniert Telematik, Cloud und Over-the-Air-Updates und könnte Bikes in echte Software-Devices verwandeln.

Welche Rolle spielt ein Distributor, wenn offene Middleware über mehrere OEM-Programme hinweg skaliert wird?

Der Distributor ist der Punkt, an dem Open-Source-Innovation auf Programmverantwortung trifft. Open-Source-Communities sind außergewöhnlich stark in Zusammenarbeit und Feature-Entwicklung. Aber sie sind nicht dafür aufgestellt, die volle Verantwortung für ein Automobilprogramm zu tragen – und das sollten sie auch nicht müssen. Der Distributor schließt diese Lücke, indem er Integration, Validierung, Compliance und Lifecycle-Support über den gesamten Fahrzeuglebenszyklus hinweg verantwortet. Diese Rolle wird im großen Maßstab kritisch. Wenn Middleware gleichzeitig über mehrere OEM-Programme hinweg läuft, sind Konsistenz und Vorhersehbarkeit keine Option, sondern Pflicht. Man braucht einen klaren Verantwortlichen – jemanden, der sich an Programmzeitplänen ausrichten kann, die Komplexität absorbiert und sicherstellt, dass das, was in einem Programm ausgeliefert wird, auch im nächsten gepflegt und aktualisiert werden kann. In diesem Sinne ermöglicht der Distributor nicht nur die Einführung der Technologie. Er ist das, was ihre Einführung nachhaltig macht.

Warum Sicherheitsanforderungen und Governance zu Gamechangern werden

Wo erzeugen Echtzeit- und Sicherheitsanforderungen die größten Herausforderungen, wenn offene Software in Automotive-Plattformen überführt wird?

Echtzeit- und funktionale Sicherheitsanforderungen ändern die Spielregeln grundlegend. Es reicht nicht mehr aus, dass Software korrekt ist – sie muss unter allen Bedingungen deterministisch korrekt sein, mit strikten Garantien hinsichtlich Timing, Isolation und Datenkonsistenz. Das ist ein anderes Engineering-Problem als das, worauf die meiste Open-Source-Entwicklung optimiert ist, und es wird in frühen Projektphasen häufig unterschätzt. Der schwierigste Teil ist die Laufzeit-Orchestrierung in Umgebungen mit gemischten Kritikalitätsstufen – also dort, wo sicherheitsrelevante und nicht sicherheitsrelevante Funktionen dieselbe Hardwareplattform nutzen. Genau dort wird die Lücke zwischen „funktionierendem offenem Code“ und „automotive-tauglicher Middleware“ am sichtbarsten. Und genau dort zahlt sich gezielte architektonische Investition aus.

„KI verstärkt Chaos im Unternehmen, statt es zu reduzieren“

Künstliche Intelligenz im Software Engineering macht Skalierung zur Prozessfrage. Georg Doll, CTO Automotive & Mobility bei Microsoft, erklärt im Interview, wie Spec-Driven Development und AI-Agents formale Spezifikationen in verifizierten Code überführen.

Wie können OEMs langfristige Wartbarkeit sicherstellen, wenn sie offene Komponenten in komplexe SDV-Stacks integrieren?

Langfristige Wartbarkeit ist weniger eine Feature-Frage als eine Governance-Frage – und sie wird umso schwieriger, je länger sie aufgeschoben wird. Die technischen Grundlagen sind gut verstanden: modulare Architekturen, stabile Schnittstellen, striktes Versioning. Die eigentliche Herausforderung besteht aber darin, Veränderungen über einen Fahrzeuglebenszyklus von 10 bis 15 Jahren hinweg zu beherrschen. Updates, Compliance-Anforderungen, Security-Patches, sich weiterentwickelnde Sicherheitsstandards – all das hört nach SOP nicht auf. Was OEMs tatsächlich brauchen, ist eine klare Zuständigkeit für das Lifecycle-Management: Wer ist für Integrationsstabilität verantwortlich, wem gehört die Update-Strategie, und wer stellt die laufende Übereinstimmung mit den Anforderungen an funktionale Sicherheit und Cybersecurity sicher? Ohne diese Struktur können offene Komponenten, die zu Beginn eines Programms wie ein Asset wirkten, bis zu dessen Ende still und leise zu einer Belastung werden. Die gute Nachricht ist: Gut architektierte Stacks – mit sauberen Schnittstellen und aktiven Upstream-Communities – geben OEMs echte Wahlfreiheit. Wechselkosten gibt es, aber sie sind beherrschbar. Das Risiko ist nicht Open Source. Das Risiko ist, einen Partner zu wählen, der nicht weiß, wie man in einer offenen Welt langfristig spielt.

Abschließend würde uns interessieren, was Sie persönlich von der Automotive Software Strategies Conference in München mitnehmen möchten?

Ehrliche Antwort: weniger Hypothesen und mehr Verbindlichkeit. In der Branche gibt es eine starke Übereinstimmung bei der Idee gemeinsamer, offener Software-Grundlagen wie Eclipse S-CORE. Was ich auf dieser Konferenz anstoßen möchte, ist die nächste Diskussion – nicht „Sollten wir das tun?“, sondern „Wie operationalisieren wir das tatsächlich über Programme, über Partner hinweg, im großen Maßstab?“ Besonders interessieren mich konkrete Gespräche mit OEMs und Tier-1-Unternehmen darüber, wie sich die Lücke zwischen strategischer Absicht und Produktionsumsetzung schließen lässt. Genau diese Diskussion bringt die Branche voran – und München ist genau der richtige Ort dafür.

Das bringt die Automotive Software Strategies Conference 2026

Am 19. und 20. Mai 2026 kehrt die Automotive Software Strategies Conference nach München zurück. Im Fokus der Fachkonferenz stehen SDV-Architekturen, Programmiersprachen wie Rust, KI-Entwicklung und neue softwarebasierte Geschäftsmodelle.