Fahrzeugelektronik

Wie läuft Embedded-Entwicklung für Automobilzulieferer bei uns ab?

Bei der Embedded-Entwicklung für Automobilzulieferer bauen wir die Embedded- und Kommunikationsebenen in der Fahrzeugelektronik.

Unsere Kunden sind Entwicklungsteams von Tier-1- und Tier-2-Zulieferern. Komponente und Beziehung zum OEM bleiben bei Ihnen; wir übernehmen die Teile, die dauerhaftes Spezialwissen brauchen:

• CAN und CAN FD, LIN, FlexRay und Single-Pair Automotive Ethernet, auf Knotenebene in Ihr Gerät und seinen Chip integriert
• Arbeit an den Plattformen AUTOSAR Classic und Adaptive, einschließlich Kommunikations- und Diagnosestacks
• eigene Steuergeräteknoten und Fahrzeug-Gateways, entwickelt von der Inbetriebnahme des Chips und der Portierung des Stacks an
• UDS-Diagnosedienste, über CAN oder über DoIP, wenn der Backbone auf IP umgestellt ist
• Kapazität für Validierung und die CI-Pipeline, die Bus-, Diagnose- und Zeitprüfungen bei jedem Build ausführt
• die Prozessnachweise, die neben der Software entstehen müssen und nicht nachträglich zusammengetragen werden

Das meiste davon ist Komponentenentwicklung nach Ihrer eigenen Spezifikation, geliefert als Ihr Entwicklungspartner. Die Seite zur Zusammenarbeit beschreibt die Formen der Zusammenarbeit und wie sie abgerechnet werden.

Warum hat der Plattformwechsel verändert, was ausgelagert wird?

Der schwierige Teil hat sich verschoben, von der Verkabelung zur Softwarearchitektur.

Fahrzeuge wechseln von einer Domänenarchitektur, in der jede Funktion ihr Steuergerät hatte, zu einer zonalen, in der die Rechenleistung gebündelt ist und Funktionen zu Diensten werden, die über ein Netz erreicht werden. Aus einer Verkabelungsentscheidung wird so eine Entscheidung über die Softwarearchitektur, und ein Kommunikations- und Middleware-Problem rückt ins Zentrum von Programmen, in denen es früher um Steuerungslogik ging. Die Spezialgebiete, die ein solches Projekt jetzt braucht, sind die Inbetriebnahme von Single-Pair Ethernet, dienstorientierte Kommunikation und DoIP. Sie fallen zeitweise und in Kombination an, und genau dieses Profil lässt sich schwer dauerhaft besetzen.

Bei welchen Teilen der Arbeit können Sie unterstützen?

Bei jeder Ebene der Komponente: dem Bus, der Middleware, dem Diagnosestack, der Kapazität, sie zu validieren.

• Ein unbekannter Bus. Ihr Team hat ihn noch nie ausgeliefert. CAN FD auf einem Teil, das bisher klassisches CAN nutzte, oder ein erster Single-Pair-Ethernet-Knoten, von der Inbetriebnahme des Chips bis zu einem Gerät, das sich unter echter Buslast korrekt verhält. Es geht auch umgekehrt: ein FlexRay-Knoten auf einer Plattform, die noch in Serie ist, wo dieses Spezialwissen immer schwerer zu besetzen ist.
• Ein fremdes Netz. Eine Komponente, die in einer Architektur korrekt mitarbeiten muss, die Sie nicht bestimmen, einschließlich der Gateway-Fälle, in denen sie zwei solcher Architekturen verbindet.
• Ein zonaler Backbone. Die Middleware-Schicht, auf der eine Adaptive-Plattform läuft, und das zeitgesteuerte Netz darunter, von den Normdokumenten bis zu etwas, das unter echtem Verkehr hält.
• Ein Diagnosestack, der den Transport wechselt. UDS, das über CAN funktionierte und jetzt über DoIP antworten muss, mit Adressierung, Discovery und Sitzungsverwaltung, die sich mit ändern.
• Kapazität für die AUTOSAR-Integration. Konfiguration und Integration auf Classic oder Adaptive, neben Ihrem eigenen Plattformteam.
• Kapazität für Validierung und CI. Ingenieure für Ihr Validierungsteam oder die Pipeline, die Regressions- und Zeitprüfungen je Build ausführt.
• Ihre eigenen Ingenieure. Werden eingearbeitet: Schulung auf dem Bus, der Plattform oder dem Diagnosestack, dann gemeinsamer Aufbau der ersten Implementierung mit Ihrem Team. Danach übernehmen wir den Third-Level-Support, während Ihr Team den First-Level-Support leistet.
• Eine ganze Komponente. Nach Ihrer Spezifikation gebaut, und die Beziehung zum OEM bleibt bei Ihnen.

Was gehört zur Busintegration auf Knotenebene?

Sie bringt ein Protokoll auf einem bestimmten Gerät und seinem Chip korrekt zum Laufen.

Diese Aufgabe ist enger und anspruchsvoller, als sie klingt. Der Stack muss auf das Teil passen, das Timing muss unter echter Buslast halten, die Diagnose muss so antworten, wie der Tester es erwartet, und das Ganze muss sich in einem ausgelasteten Netz ebenso verhalten wie auf dem Labortisch. Dieselbe Disziplin wenden wir auf der Industrieseite an, wo unser Team Kommunikationsstacks auf mehreren Chipfamilien durch Konformitätstests gebracht hat. Ein CAN- oder LIN-Knoten im Fahrzeug und ein Feldbusknoten an einer Maschine sind verschiedene Netze mit derselben Grundfrage: Verhält sich dieses Gerät als Teilnehmer korrekt, unter Last, im Netz eines anderen?

Wie kommt dienstorientierte Kommunikation auf die Leitung?

Eine Middleware-Schicht überträgt sie, über ein Netz, das sich auf Vorhersagbarkeit festlegt.

Die Middleware entscheidet, welcher Dienst mit welchem spricht. Beide Hälften sind inzwischen öffentliche Normen und keine Entwurfsentscheidungen einzelner Programme mehr. AUTOSAR Adaptive spezifiziert für die Middleware-Hälfte eine DDS-Anbindung. IEEE 802.1 Time-Sensitive Networking deckt die andere Hälfte auf der Sicherungsschicht ab, und die OMG hat im April 2023 DDS-TSN 1.0 veröffentlicht, im Mai 2024 als Beta2 überarbeitet, mit der Festlegung, wie das eine auf das andere abgebildet wird.

Die Entwicklungsarbeit steckt in dieser Abbildung. Ein Topic trägt QoS-Einstellungen (Reliability, Durability, Deadline, Liveliness), der Backbone einen sich wiederholenden Zeitplan aus Fenstern. Welche Topics ein geschütztes Fenster bekommen, welche sich den Rest teilen und was das System tut, wenn ein Abonnent seine Deadline verpasst, ist eine Entwurfsaufgabe und keine Konfigurationsdatei. Ist sie falsch gelöst, verhält sich das Ergebnis auf dem Labortisch korrekt und lässt unter Last auf eine Weise nach, die wie ein Fehler der Anwendung aussieht, obwohl es einer des Netzes ist. Für einen Zulieferer ist die praktische Frage meist enger als die Architekturdebatte. Die Plattform ist schon gewählt, und die Integration von DDS auf AUTOSAR Adaptive muss auf einem bestimmten Gerät funktionieren, an einem Backbone, den Sie nicht bestimmen, neben Verkehr von Teams, die Sie nicht führen. Das ist die Frage nach dem Knoten aus dem vorigen Abschnitt, gestellt an eine neuere Ebene.

Wo liegt die Diagnose heute?

UDS tut dasselbe wie bisher, läuft aber immer seltener über CAN.

Mit dem Wechsel des Fahrzeug-Backbones zu IP werden dieselben Diagnosedienste über DoIP übertragen, und der Transportwechsel hat mehr Folgen, als es zunächst scheint. Adressierung, Discovery, Sitzungsverwaltung und Sicherheit verhalten sich alle anders. Arbeit, die von CAN als Transport ausgeht, muss meist neu durchdacht werden; eine Portierung reicht nicht.

Wie entstehen die Prozessnachweise, die ein OEM-Audit erwartet?

Neben der Software, denn auf einer Tier-1-Plattform entscheidet der Nachweis über den Zugang zur Arbeit.

Drei Bewertungen lesen dieselbe Nachweiskette:

• Automotive SPICE, nach dem Zulieferer bewertet werden.
• ISO 26262, die funktionale Sicherheit mit eigenen Erwartungen an Artefakte mitbringt.
• ISO/SAE 21434, die Cybersecurity-Engineering auf dieselbe Liste gesetzt hat.

Nichts davon ist ungewöhnlich oder unangemessen. So steuert die Branche Risiken über eine Lieferkette, die sie nicht direkt prüfen kann. In der Praxis heißt das: Die Rückverfolgbarkeit von der Anforderung bis zum Testergebnis entsteht mit der Arbeit, in Ihrem Prozess und in Ihrer Werkzeugkette. Was zur Bewertung kommt, ist Ihre Nachweiskette mit unserer Arbeit darin.

Ist das dasselbe Team wie bei Ihrer Industriearbeit?

Ja, und das ist Absicht.

Fahrzeugelektronik und industrielle Automatisierung sind bei denselben Aufgaben angekommen: deterministisches Ethernet, Zeitsynchronisation, dienstorientierte Kommunikation sowie Pflichten zu funktionaler Sicherheit und Cybersecurity, die gemeinsam kommen. Die Namen der Busse unterscheiden sich. Die Technik darunter lässt sich übertragen, und deshalb umfasst unsere Arbeit zu Embedded-Systemen und Echtzeit-Ethernet beides.