Interview mit Dr. Nico Hartmann, CTO Qorix

Die Architektur des Software-Defined Vehicle im Fokus

Aus Open Source soll serienreife Middleware für das Software-Defined Vehicle werden. Auf dem AUTOMOBIL-ELEKTRONIK Kongress in Ludwigsburg zeigt sich, wie daraus eine Plattform für den Serieneinsatz entstehen kann und woran die Umsetzung noch hängt.

3 min
Aufmacherbild zu einem Fachbeitrag über Middleware und Software-Defined Vehicles: Rechts steht ein Mann in dunkelblauem Anzug und weißem Hemd vor unscharfem Industrie- oder Bürogebäude unter bewölktem Himmel. Links ist in großer schwarzer Typografie das Zitat platziert: „Open Source liefert Geschwindigkeit – Industrialisierung liefert Verlässlichkeit.“ Zwei große weiße Anführungszeichen im Hintergrund verstärken den Charakter als zentrales Statement des Beitrags. Die Bildkomposition verbindet Person, Industrieumfeld und Kernaussage des Artikels zu einem visuellen Einstieg in die Diskussion über den Weg von offenem Software-Fundament zur serienreifen Middleware-Plattform für das Software-Defined Vehicle.
Dr. Nico Hartmann, CTO bei Qorix, spricht im Interview über Middleware als Bindeglied zwischen Open Source, Sicherheitsanforderungen und Serienentwicklung im Software-Defined Vehicle.

Der AUTOMOBIL-ELEKTRONIK Kongress in Ludwigsburg gilt seit jeher als das Klassentreffen der Entscheider und Vordenker der Branche. Doch selten war der Fokus so klar definiert wie in diesem Jahr: Der Übergang vom Hardware-zentrierten Fahrzeug zum Software-Defined Vehicle (SDV) ist keine Vision mehr, sondern ein industrieller Kraftakt.

Inmitten dieser Transformation steht die Middleware als das unsichtbares, aber entscheidendes Rückgrat. Hier setzt Qorix an. Als Gründungsmitglied und eine treibende Kraft hinter der Open-Source-Initiative Eclipse S-CORE arbeitet Qorix daran, aus einem offenen Software-Fundament eine industriell nutzbare Middleware-Plattform für SDV zu machen. Der Fokus liegt dabei nicht nur auf der Entwicklung von Code, sondern auf der Industrialisierung: also darauf, wie aus kollaborativen Open-Source-Ansätzen sicherheitskritische, ASIL-D-fähige und serienreife Serienprodukte entstehen.

Im Expertengespräch erläutert Dr. Nico Hartmann, CTO Qorix, wie sein Unternehmen den Spagat zwischen offener Standardisierung und industrieller Exzellenz meistert und warum die Middleware der Schlüssel für die Wettbewerbsfähigkeit der europäischen Automobilindustrie ist.

 Vom „Bauplan“ zum „Gebäude“ – Die Transformation von Open Source

Qorix beschreibt Eclipse S-CORE oft als den ‚Bauplan‘ und die eigene Performance-Distribution als das fertige ‚Gebäude‘. Welche spezifischen ‚Veredelungen‘ muss eine Open-Source-Middleware heute durchlaufen, damit sie für OEMs nicht nur eine technologische Option, sondern eine ASIL-D-konforme und serienreife Lösung für die nächste Generation von High-Performance-Computern (HPCs) darstellt?

Infografik auf einem sehr hellen, leicht grauvioletten Hintergrund zur Schichtenarchitektur einer softwaredefinierten Fahrzeugplattform. Die Komposition ist horizontal aufgebaut und in drei Ebenen gegliedert, die durch feine waagerechte Linien voneinander getrennt sind. Links stehen jeweils eine violette Line-Icon-Grafik, eine große dunkelgraue Überschrift und ein kurzer erläuternder Satz; rechts ordnen farbige, abgerundete Balken die technischen Ebenen ein. Im oberen Bereich steht links ein Zahnrad-Icon mit drei vertikalen Linien. Daneben die Überschrift „Customer Functions“. Darunter der englische Erklärungstext: „Easing feature integration: Enables shipping new customer functions & apps over-the-air.“ Rechts dazu verläuft ein einzelner, langer Balken mit weichem Farbverlauf von blassem Rosa links zu kräftigem Pink und Violett rechts. Im Balken steht „Applications“, daneben ein kleines weißes Symbol für eine Fahrzeuganwendung. Am äußersten rechten Rand markiert eine vertikale Klammer mit der Beschriftung „(Out Of Scope)“ diesen oberen Bereich als nicht zum eigentlichen Kernbereich gehörend. Im mittleren, größten Abschnitt steht links ein stilisiertes Fahrzeug-Icon mit elektronischen Leiterbahnen. Daneben die Überschrift „Software Platform“. Der Begleittext lautet: „Separation of Concerns via layered architecture & APIs“. Rechts daneben sind sechs horizontale, abgerundete Balken übereinander angeordnet, jeweils mit hellem Verlauf links und kräftigerem Farbton rechts. Von oben nach unten lauten die Ebenen: „App Framework“, „Middleware“, „Programming Environment“, „Containers“, „Operating System“ und „Hypervisors“. Jeder Balken trägt rechts ein kleines weißes Line-Icon, etwa für Framework-Strukturen, Middleware-Vernetzung, API- beziehungsweise Entwicklungsumgebung, Container, Betriebssystem und Virtualisierung. Eine vertikale Klammer am rechten Rand spannt sich über alle sechs Balken und ist mit „(IN Scope)“ beschriftet. Damit wird der mittlere Stack als relevanter Arbeits- oder Produktbereich hervorgehoben. Im unteren Abschnitt steht links ein Chip-Icon mit Code-Symbolen. Daneben die Überschrift „Hardware Platform“. Der Erklärungstext lautet: „Decoupling SW platform from hardware: Enables exchanging hardware whenever necessary.“ Rechts stehen zwei weitere Verlaufbalken mit den Bezeichnungen „Firmware“ und „Chipset“, jeweils mit kleinem weißen Symbol. Eine weitere vertikale Klammer mit „(Out Of Scope)“ kennzeichnet diese unteren, hardwarebezogenen Ebenen als außerhalb des Fokus. Die Grafik vermittelt damit eine klare Hierarchie von Anwendungen über die Softwareplattform bis zur Hardware und grenzt exakt ab, dass der zentrale Wirkbereich in der mittleren Softwareschicht zwischen Hypervisor und App Framework liegt.
Schichtenmodell einer SDV-Plattform: Im Fokus steht die Softwareebene zwischen Hypervisor und App Framework, während Anwendungen sowie Firmware und Chipsatz außerhalb des Scope liegen.

Dr. Nico Hartmann: Streng genommen ist Eclipse S-CORE eher ein Rohbau als ein Bauplan. Der Unterschied ist wichtig: S-CORE liefert bereits realen Code und damit ein belastbares offenes Fundament. Für OEMs reicht ein solcher Rohbau allein jedoch nicht aus. Damit daraus eine serienreife Lösung für High-Performance-Computer wird, braucht es Industrialisierung: deterministisches Systemverhalten, klar definierte Integrationsschnittstellen, funktionale Sicherheit, langfristige Wartbarkeit sowie belastbares Release-, Update- und Lifecycle-Management. Genau an dieser Stelle setzt Qorix an. Wir entwickeln auf Basis von Eclipse S-CORE eine produktionsreife Middleware-Distribution, die OEMs und Tier-1-Zuliferer direkt in ihre SDV-Plattformen integrieren können.

Die grundlegenden Mechanismen – wie deterministische Systemorchestrierung oder effiziente Interprozesskommunikation - sind bereits im S-CORE-Stack vorhanden. Der entscheidende Unterschied liegt jedoch in der Industrialisierung: Qorix überführt diese Komponenten in eine konsistente Plattform, optimiert sie für konkrete Hardwareumgebungen und ergänzt sie um funktionale Garantien sowie langfristigen Support. Das sind Voraussetzungen, die für den Einsatz in Serienprogrammen entscheidend sind.

Save the date: 30. AUTOMOBIL-ELEKTRONIK Kongress

Logo Automobil-Elektronik Kongress (AEK), mit Datum für 2026, eine Veranstaltung von Ultima Media Germany, mit dem dazugehörigen Magazin Automobil-Elektronik

Am 16. und 17. Juni 2026 findet zum 30. 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 nun zusätzlich 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 30. Automobil-Elektronik Kongress (AEK) im Jahr 2026! Folgen Sie außerdem dem LinkedIn-Kanal des AEK und #AEK_live. Hier geht's zur Agenda.

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

In Ludwigsburg wird viel über die Skalierung von Software-Defined Vehicles (SDV) gesprochen. Ein kritischer Flaschenhals ist die Orchestrierung von Applikationen unterschiedlicher Kritikalität (Mixed-Criticality). Wie stellt Qorix bei der Industrialisierung sicher, dass Funktionen wie Zero-Copy-Kommunikation und deterministisches Laufzeitverhalten nicht nur im Labor, sondern unter realer Last in einer zentralisierten Zonen-Architektur stabil funktionieren? 

Orchestrierung ist ein Teil der Herausforderung. Die eigentliche Komplexität liegt jedoch in der Integration. In modernen SDV-Architekturen stammen Applikationen und Software-Komponenten häufig aus unterschiedlichen Quellen. Die zentrale Aufgabe besteht darin, diese so zusammenzuführen, dass sie deterministisch zusammenarbeiten, sich nicht gegenseitig blockieren und auch unter realer Systemlast stabil bleiben. 

Mechanismen wie Zero-Copy-Kommunikation und deterministische Orchestrierung sind dabei wichtige Bausteine, lösen jedoch nur einen Teil des Problems. Der entscheidende Beitrag liegt in der industriellen Integration: Qorix führt diese Komponenten zu einer konsistenten Plattform zusammen, optimiert sie für konkrete Hardwareumgebungen und stellt ein kontrolliertes, vorhersagbares Systemverhalten über alle Domänen hinweg sicher – auch unter realen Betriebsbedingungen.

Effizienz und „Time-to-Market“ für OEMs

Der Zeitdruck bei SDV-Programmen ist enorm. S-CORE verspricht, den nicht-differenzierenden Teil des Software-Stacks zu standardisieren. Wenn wir auf die industrielle Integration blicken: Inwieweit verkürzt der Einsatz eines vorintegrierten Qorix-Stacks inklusive KI-gestützter Developer-Tools die Entwicklungszyklen für Fahrzeughersteller, und wo genau gewinnen die Ingenieure dadurch den Freiraum für echte Innovationen?

Der größte Zeitverlust in SDV-Programmen entsteht heute nicht durch fehlende Funktionalität, sondern durch den hohen Aufwand, komplexe Software-Stacks zu integrieren.

Eclipse S-CORE stellt ein leistungsfähiges und gleichzeitig komplexes Software-Fundament dar. Eine industrielle Distribution macht diese Komplexität beherrschbar, indem sie vorintegrierte, getestete und auf konkrete Plattformen abgestimmte Komponenten bereitstellt. Dadurch wird aus einem offenen Software-Stack eine handhabbare und einsetzbare Lösung.

Technisches Ablaufdiagramm auf hellgrauem Hintergrund zur Verarbeitung von Kamera- und Lidar-Daten in einer Wahrnehmungs- und Sensorfusionskette. Oben links befindet sich eine kleine Legende mit zwei unterschiedlich codierten Pfeilarten. Eine blau-violette gepunktete Linie mit Pfeilspitze ist mit „Data flow“ beschriftet und markiert den Datenfluss. Darunter steht eine schwarze gepunktete Linie mit Pfeilspitze und der Bezeichnung „Control flow“, die den Kontrollfluss darstellt. Links oben beginnt die obere Prozesskette mit einem stilisierten Kamerasymbol. Von der Kamera führt ein blau-violetter gepunkteter Pfeil nach rechts in ein kräftig violettes Rechteck mit weißer Beschriftung „Camera Driver“. Unterhalb dieses Blocks zeigt ein schwarzer gepunkteter Pfeil senkrecht nach oben; daneben steht „30ms“. Das deutet auf einen zeitlich getakteten Kontroll- oder Triggermechanismus hin. Vom „Camera Driver“ aus verzweigt der Datenfluss in mehrere Verarbeitungspfade. Ein durchgehender blau-violetter gepunkteter Pfeil läuft waagerecht nach rechts direkt in das Rechteck „Lane Detection“. Aus derselben Hauptlinie führt ein Abzweig nach oben und dann nach rechts in den Block „Traffic-Signal Detection“. Ein weiterer Abzweig führt nach unten und nach rechts in den Block „Object Detection“. Parallel dazu verlaufen schwarze gepunktete Kontrollflusslinien von der Kamerakette zu einzelnen Verarbeitungsstufen. Zwischen dem „Camera Driver“ und „Lane Detection“ ist unter dem Datenpfeil ein schwarzer gepunkteter Kontrollpfeil eingezeichnet. Auch zum Block „Object Detection“ führt ein schwarzer Kontrollpfeil. Im oberen rechten Bereich vor „Traffic-Signal Detection“ verläuft ein weiterer schwarzer gepunkteter Pfeil; daneben steht „250ms“, was auf eine gesonderte Taktung oder Kontrollrate hindeutet. Die drei Analyseblöcke „Traffic-Signal Detection“, „Lane Detection“ und „Object Detection“ sind als violette Rechtecke mit weißer Typografie gestaltet. „Traffic-Signal Detection“ gibt den Datenstrom mit einem blau-violetten gepunkteten Pfeil nach rechts aus dem Diagramm weiter. Gleiches gilt für „Lane Detection“. „Object Detection“ leitet seine Ergebnisse nach rechts an den Block „Sensor Fusion“ weiter; zusätzlich ist auch hier ein schwarzer Kontrollpfeil parallel eingezeichnet. Im unteren linken Bereich startet eine zweite Sensorkette mit einem Lidar- oder Distanzsensor-Symbol auf einem Sockel, flankiert von kleinen Funkwellen. Von dort führt ein blau-violetter gepunkteter Pfeil in den Block „Lidar Driver“. Unterhalb des Blocks zeigt erneut ein schwarzer gepunkteter Pfeil nach oben, hier mit der Zeitangabe „100ms“. Vom „Lidar Driver“ verläuft der Datenfluss nach rechts in „Ground Filter“, anschließend weiter nach rechts in „Cluster Detector“. Zwischen diesen Blöcken liegen jeweils parallel schwarze gepunktete Kontrollflusslinien. Vom „Cluster Detector“ aus führt ein blau-violetter gepunkteter Pfeil zunächst nach rechts und dann senkrecht nach oben in den Block „Sensor Fusion“. Dieser befindet sich mittig rechts und bildet den Zusammenführungspunkt der oberen Kamera-Verarbeitungskette und der unteren Lidar-Kette. Aus „Sensor Fusion“ verlässt ein weiterer blau-violetter gepunkteter Pfeil das Diagramm nach rechts. Sämtliche Funktionsblöcke sind in kräftigem Violett gehalten und kontrastieren mit dem neutralen Hintergrund. Das Diagramm macht deutlich, dass mehrere sensorische Eingaben über getrennte Verarbeitungsschritte mit jeweils eigenem Daten- und Kontrollfluss in einer zentralen Sensorfusion zusammenlaufen.
Mehrere Erkennungs- und Verarbeitungsstufen führen Kamera- und Lidar-Signale in der Sensorfusion zu einem gemeinsamen Ergebnis zusammen.

Ergänzend unterstützen Werkzeuge wie Qorix Developer Entwickler*innen mit KI-gestützten Konfigurations- und Validierungsworkflows, die Systemkonfigurationen vereinfachen, Fehler frühzeitig sichtbar machen und konsistente Systemzustände sicherstellen. Gemeinsam mit begleitenden Leistungen wie Service, Support und Training entsteht so ein industrielles Gesamtpaket, das die Komplexität beherrschbar macht.

Dadurch verschiebt sich der Fokus der Entwickler*innen: weg von der technischen Grundarbeit hin zu Funktionen, die für OEMs tatsächlich den Unterschied im Wettbewerb machen. So gewinnen Ingenieurteams wieder Zeit für die eigentliche Wertschöpfung, also für Funktionen, die das Fahrerlebnis und die Wettbewerbsfähigkeit der Hersteller bestimmen.

Letztlich entscheidet nicht allein der Code über die Zukunft des Software-Defined Vehicle, sondern die Fähigkeit, offene Software-Fundamente zuverlässig, beherrschbar und skalierbar in industrielle Plattformen zu überführen.

Die Zukunft des Autos zum Anfassen in Ludwigsburg

Die Industrialisierung der Middleware ist kein abstraktes IT-Thema mehr – sie ist das Fundament, auf dem die digitale Souveränität der Automobilhersteller steht. Mit Eclipse S-CORE und den darauf aufbauenden Performance-Distributionen zeigt Qorix, wie aus Open-Source-Innovation eine industrielle Middleware-Plattform für Software-definierte Fahrzeuge entstehen kann.

Wer erleben möchte, wie diese Architektur in der Praxis die CPU-Last senkt und Entwicklungsprozesse beschleunigt, sollte den Austausch vor Ort suchen. Die Experten von Qorix stehen während des gesamten AUTOMOBIL-ELEKTRONIK Kongresses in Ludwigsburg am 16. und 17. Juni für vertiefende Gespräche und Live-Einblicke in die nächste Generation der SDV-Software-Stacks zur Verfügung.

Wir freuen uns darauf, die Diskussionen über die Mobilität von morgen gemeinsam mit Ihnen im Forum am Schlosspark fortzusetzen.

automobil-elektronik kongress veranstaltungen-automobil-elektronik-kongress eclipse s-core software-defined vehicle middleware qorix

Auch interessant