Ladecontroller in der Zonenarchitektur Ladekommunikation meets SDV

Effiziente Ladekommunikation ist die Basis für zentrale Funktionen moderner Elektrofahrzeuge. Mit dem Aufkommen des Software-definierten Fahrzeugs stellt sich die Frage: Wie lässt sich Ladekommunikation zuverlässig in komplexe E/E-Architekturen integrieren?

Das Fahrzeug-seitige Ladekommunikationssteuergerät (Electric Vehicle Communication Controller, EVCC) ist häufig zentraler Bestandteil eines Mikrocontroller-basierten Onboard-Ladegeräts. Dieses übernimmt neben der Ladekommunikation auch die Steuerung und Überwachung elektrischer Schaltkreise. Dazu zählen unter anderem die Signalleitungen, zum Beispiel Control Pilot und der Verriegelungsmotor der Ladedose des Combined Charging System (CCS). Die für diese Aufgaben vorgesehenen Software-Anteile eines EVCC werden nach Vorgaben der ISO 26262 für funktionale Sicherheit entwickelt. In CCS-basierten Ladesystemen spielt außerdem die Cybersicherheit eine wichtige Rolle. Weil die Ladekommunikation eine Schnittstelle zur Außenwelt darstellt, kann sie von Angreifern als potenzielles Einfallstor genutzt werden, um sich Zugriff auf das fahrzeuginterne Netzwerk zu verschaffen. Als führender Standard für die Ladekommunikation spezifiziert die ISO 15118 daher wichtige Sicherheitsvorkehrungen für Authentizität, Integrität und Vertraulichkeit. Dazu zählen die Verschlüsselung der Ladekommunikation mittels Transport Layer Security (TLS) sowie die Nutzung von Public Key Infrastructure (PKI) zur Authentifizierung und Autorisierung von Fahrzeug und Ladestation. Diese Sicherheitsmechanismen bringen aufgrund von kryptographischen Operationen sowie der Zertifikatsverwaltung einen zusätzlichen Ressourcenbedarf mit sich. Dabei kann sich insbesondere die erhöhte Laufzeit negativ auf das Nutzererlebnis auswirken, da es vom Start der Ladekommunikation bis zum eigentlichen Energietransfer zu Wartezeiten kommen kann. Die schnelle Durchführung der kryptographischen Operationen in der Software stellt für herkömmliche Mikrocontroller aufgrund der Verwendung moderner elliptischer Kurven allerdings eine große Herausforderung dar.

Neue Möglichkeiten durch das SDV

Der Trend zum Software-definierten Fahrzeug (Software-defined Vehicle, SDV) zeigt sich u.a. durch die Struktur moderner E/E-Architekturen. Diese sind häufig als Zonenarchitektur aufgebaut. Das Fahrzeug ist dabei in geographische Zonen unterteilt. Neben den Mikrocontroller-basierten Zonen- und Sensor/Aktuator-Steuergeräten sind die zentralen High-Performance Computer (HPC) fester Bestandteil im SDV. Sie werden häufig als System-on-Chip (SoC) mit leistungsstarken Prozessoren und POSIX-basierten Betriebssystemen ausgeführt. Für die Realisierung eines EVCC in der Zonenarchitektur ergeben sich verschiedene Ansätze. Eine Möglichkeit ist das bereits genannte Onboard-Ladegerät. Es wird als separates Bauteil in eine Zone der E/E-Architektur integriert (Bild 1, 1). Eine weitere Variante ist die Integration des EVCC in einem Zonensteuergerät (Bild 2). Dafür bietet sich ein Zonensteuergerät an, das in der Nähe der CCS-Ladedose installiert wird, um die Distanz für die Powerline Communication (PLC) möglichst gering zu halten. Der dritte Ansatz ist die Umsetzung des EVCC als verteiltes System, wobei die einzelnen Software-Funktionen in Abhängigkeit der Eigenschaften vorhandener Steuergeräte verteilt werden (Bild 1, 3).

Lösung eines verteilten EVCC

Dieser dritte Ansatz wurde im Rahmen eines Vorentwicklungsprojekts bei Vector untersucht. Dabei erfolgt die Verteilung der Software vorwiegend gemäß den Anforderungen der funktionalen Sicherheit und der Cybersicherheit. Die EVCC-Software wird dabei auf zwei Steuergeräte aufgeteilt. Die sicherheitsrelevanten Applikationen zur Steuerung elektrischer Schaltkreise werden in einem Mikrocontroller-basierten Gateway mit der Vector Basissoftware Microsar Classic ausgeführt, um von der Echtzeitfähigkeit zu profitieren. Das Gateway kann innerhalb eines Zonensteuergerätes (Bild 1,2) oder als eigenständiges Sensor-/Aktuator-Steuergerät umgesetzt werden. Im Gegensatz dazu wird die Ladekommunikation mit den Ressourcen-intensiven Software-Anteilen für die Cybersicherheit weitestgehend auf einem HPC ausgeführt. Mit leistungsstarker Prozessoren können so kürzere Laufzeiten für kryptographische Operationen erzielt werden. Der HPC wird mit Android Automotive OS (AAOS) betrieben (Bild 2).

Das Gateway übernimmt die Kommunikation mit der Ladestation via Powerline Communication und mit dem Batterie-Management-System (BMS) über das interne Fahrzeugnetzwerk. Es integriert den PLC-Chip und steuert die Hardware-I/Os der Ladedose. Die ersten Schritte der Ladesequenz, wie Signal-Level Attenuation Characterization (SLAC) und SECC Discovery Protocol (SDP), laufen ebenfalls dort ab. Das Gateway leitet zudem Nachrichten von der Ladestation an das Android-System im HPC weiter. Das erfolgt über einen Network-Address-Translation-ähnlichen (NAT-ähnlich) Router innerhalb des Gateways, der nur Nachrichten des Ladeprotokolls in das Fahrzeugnetz durchlässt. Unerwünschte oder unbekannte Nachrichten werden herausgefiltert. Der NAT-ähnliche Router schützt das interne Netz und die nach außen gerichtete PLC-Schnittstelle. Er unterstützt dabei die Anforderungen aus ISO 21434. Das Gateway und der HPC sind per Ethernet über zwei Kanäle verbunden. Einer dient dem Ladeprotokoll, der andere der Synchronisierung der Zustände zwischen dem Android-System und dem Gateway. Weil das Gateway schneller startet, können einzelne Ladeschritte bereits vor der Verfügbarkeit des HPC initiiert werden. SLAC und SDP laufen ohne Eingaben des Android-Systems an, was die Zeit bis zum tatsächlichen Ladebeginn verkürzt. Im Android Automotive OS des HPC wird ein Großteil der Ladekommunikation verarbeitet. Zudem werden kryptographische Operationen ausgeführt und benötigte Zertifikate sowie Schlüssel verwaltet, was unter anderem für Plug & Charge essenziell ist. Die Ladekommunikation wird in AAOS als Charge-Service umgesetzt. Er basiert auf der bekannten Ladekommunikationssoftware Microsar Charge von Vector und enthält die protokollspezifische Implementierung inklusive der Zustandsmaschinen, den Efficient-XML-Interchange-Encoder/Decoder (EXI) sowie XML-Security für die Applikationsnachrichten. Die Architektur ist modular aufgebaut. Externe Komponenten wie die Crypto-Bibliothek oder die Zertifikats- und Schlüsselverwaltung lassen sich austauschbar integrieren. Der Charge-Service wird als nativer Service in das Android-Framework integriert. Dadurch werden ein schneller Start sowie die Überwachung durch den Service-Manager sichergestellt. Letzterer startet den Dienst, überwacht ihn und startet ihn bei Bedarf neu. Zudem kann der Charge-Service mit Hilfe des Vendor Native Development Kit (VNDK) entwickelt und gepflegt werden. Die Allokation des Charge-Services innerhalb von AAOS ist wichtig, weil Android-Systeme über mehrere Partitionen mit unterschiedlichen Zwecken und Berechtigungen verfügen (Bild 3). Die System-Partition mit den Komponenten des Android-Kernsystems besitzt die höchsten Privilegien und uneingeschränkten API-Zugriff. Sie ist jedoch nicht für nutzerspezifische Erweiterungen vorgesehen. Der Charge-Service wird in der Vendor-Partition gehalten, da diese den Zugriff auf alle notwendigen System-APIs besitzt und Schutzmechanismen gegen unbefugte Änderungen der Daten bietet.

Bewertung

Eine verteilte EVCC-Lösung wirkt sich besonders positiv auf das Laufzeitverhalten aus. In realen Testszenarien konnte die Laufzeit eines TLS 1.3-Handshakes mit Client- und Server-Authentifizierung gemäß ISO 15118-20 um den Faktor 8-10 im Vergleich zu einem Mikrocontroller-basierten System verbessert werden. Zudem wurden alle im Standard geforderten Zeitlimits während der gesamten Ladesequenz eingehalten.

Der Speicherbedarf für die Zertifikatsketten fällt weniger stark ins Gewicht, weil SoC-Plattformen über deutlich größere Speicherressourcen als herkömmliche Mikrocontroller verfügen. Zudem kann der Mikrocontroller zur Ansteuerung der Ladedose wesentlich kleiner ausgelegt werden, da die Ladekommunikation in den HPC verlagert wird. Das führt zu einer signifikanten Kostenersparnis. Des Weiteren sind die Update-Fähigkeit und Aufstartzeit wichtige Eigenschaften eines EVCC. Die Update-Strategie ist häufig herstellerspezifisch und hängt von den technischen Eigenschaften eines Steuergeräts ab. Die oben aufgeführte Software-Verteilung bietet die Möglichkeit, das Ladeprotokoll zentral im HPC zu aktualisieren, was insbesondere bei der Verwendung mehrerer Ladedosen vorteilhaft ist. Ein Beispiel hierfür sind elektrisch betriebene LKW mit mehreren Ladedosen für das Combined Charging System (CCS) und Megawatt Charging System (MCS). Darüber hinaus lässt sich das Variantenmanagement durch dynamisches Konfigurieren von Funktionen im Charge-Service vereinfachen.

Eine schnelle Aufstartzeit führt durch eine kurze Wartezeit beim Ladevorgang zu einem positiven Nutzererlebnis. Mikrocontroller-basierte Systeme ermöglichen Aufstartzeiten im Millisekunden-Bereich, wohingegen HPCs oft mehrere Sekunden benötigen. Bei einer verteilten EVCC-Lösung muss das Aufstartverhalten so gestaltet sein, dass die Ladekommunikation unmittelbar beginnen kann, sobald das Ladekabel eingesteckt wird. Daher führt der Mikrocontroller die ersten Schritte der Ladesequenz aus. Neben den positiven Aspekten führt die verteilte EVCC-Lösung jedoch zu erhöhter Komplexität. So nimmt die Anzahl der Kommunikationspfade innerhalb des Fahrzeugs zu. In den Ladeablauf sind außerdem unterschiedliche Hardware-Plattformen und Software-Ökosysteme involviert. Dadurch erhöht sich der Aufwand für den Test des Gesamtsystems, da der Testaufbau durch die Beteiligung mehrerer Steuergeräte komplexer wird und die Anzahl der Testfälle steigt.

Schlussfolgerungen

Das Vorentwicklungsprojekt von Vector verdeutlicht die Vor- und Nachteile verschiedener Integrationsansätze eines EVCC. Die Auswahl des Ansatzes sollte sich an der verfügbaren Hardware und der Software-Verteilung innerhalb der Zonenarchitektur orientieren. Zudem können sich durch zukünftige Hardware-Plattformen mit leistungsfähigeren Prozessoren und Hardware-Beschleunigern neue Integrationsszenarien ergeben. Eine geeignete Ladekommunikations-Software muss dafür jedoch flexibel und portierbar sein. Im SDV sind mehr denn je ökonomische und projektspezifische Faktoren der Steuergeräteentwicklung zu berücksichtigen. Aus technischer Sicht steht der Umsetzung einer effizienten Ladekommunikation im SDV jedenfalls nichts mehr im Wege. (se)

Zukünftige Mobilität

Über CASE hinaus: Die SDV-Revolution

Software-definierte Fahrzeuge

Wie Software die Zukunft der Mobilität gestaltet

* Tobias Schneider ist Projektleiter in der Vorentwicklung bei Vector Informatik. Michael Vick ist Solution Manager für die Ladekommunikations-Software MICROSAR Charge bei Vector Informatik.

(ID:50760271)