WO2018069192A1

WO2018069192A1 - Intelligente ladekommunikationsumschaltung bei can-basierten ladesystemen

Info

Publication number: WO2018069192A1
Application number: PCT/EP2017/075550
Authority: WO
Inventors: Axel Ulrich
Original assignee: Volkswagen Aktiengesellschaft
Priority date: 2016-10-13
Filing date: 2017-10-06
Publication date: 2018-04-19
Also published as: DE102016219940A1; JP2020501479A; CN109843637A; CN109843637B

Abstract

Verfahren für das Lademanagement eines elektrisch betriebenen Fahrzeugs, bei dem abhängig vom verwendeten Ladesystem ein erster Kommunikationsstack (20a) oder ein zweiter Kommunikationsstack (20b) ausgewählt wird, wobei der erste Kommunikationsstack (20a) eine CAN-Kommunikation auf Basis eines ersten Ladesystems und der zweite Kommunikationsstack (20b) eine CAN-Kommunikation auf Basis eines zweiten Ladesystems über dieselbe physikalische Schnittstelle bereitstellen.

Description

Beschreibung

Intelligente Ladekommunikationsumschaltung bei CAN-basierten Ladesystemen

Die Erfindung betrifft das Gebiet der Ladesysteme- und Schnittstellen für Elektrofahrzeuge.

Weltweit werden unterschiedlichste Ladesysteme- und Schnittstellen eingesetzt, die zueinander nicht kompatibel sind. Neben den verschiedenen Möglichkeiten, ein Elektrofahrzeug mit Wechsel- oder Gleichstrom aufzuladen, existieren weltweit verschiedene Steckernormen für USA, Europa, Japan und China in Varianten für Wechselstrom und Wechselstrom/Gleichstrom, sowie weitere O EM-spezifische Steckerlösungen. Aufgrund verschiedener technischer

Gegebenheiten wie z. B. Spannungslage, fehlender Versorgungsspannung, Protokollverhalten, Komplexität oder Aufwandskosten ist eine Adaption der Systeme nicht einfach möglich.

Aufgrund der Größe der Buchsensysteme bzw. des beschränkten zur Verfügung stehenden Bauraums und der Kostensituation wird von einem parallelen Verbau verschiedener

Ladesystemschnittstellen am Fahrzeug abgesehen. Lösungen gibt es hier teils in für den Kunden unpraktischen externen Adapterbauten.

Das besonders im japanischen Markt vertretene CHAdeMO-Ladesystem basiert auf

Gleichspannung (DC) und unterstützt eine elektrische Ladeleistung von bis zu 62,5 kW. Die CHAdeMO-Ladekommunikation erfolgt über das CAN-Protokoll und über zwei CAN- Busleitungen. Beim CHAdeMO-Protokoll kommuniziert das Ladesystem des Autos mit dem Ladesystem der Schnellladestation mittels Master-Slave-System. Das Ladesystem des Autos (Master) meldet der Ladestation (Slave) Ladeparameter wie den aktuellen Ladestand einer Traktionsbatterie, sowie die Gleichspannung und maximale Stromstärke, mit der die

Traktionsbatterie geladen werden darf. Ferner werden Parameter wie Spannung, Temperatur und andere Parameter der Traktionsbatterie übertragen. Das CHAdeMO-Protokoll ist im

Rahmen der ISO-Normung als Gleichstromladestandard anerkannt und wurde als Normen ISO/IEC 61851 -23 und ISO/IEC 61851-24 aufgenommen. Es kommt ein CAN-basiertes Layerl-Kommunikationsprotokoll nach CHAdeMO-Standard zum Einsatz. Der chinesische GB/T-Standard 20234 sieht ebenfalls ein sowohl für konventionelles Laden am Wechselstromnetz als auch für schnelles Laden mit Gleichstrom geeignetes Ladestecksystem vor, bei dem die Ladekommunikation über das CAN-Protokoll erfolgt. Der GB/T-Standard ermöglicht ein schnelles Gleichstromladen an entsprechenden Schnellladestationen. Es kommt ein CAN-basiertes Layer-1 -Kommunikationsprotokoll nach GB/T-Standard zum Einsatz.

Zwischen der bestehenden CHAdeMO-Norm und den neuen China GB/T ist zwar die physikalische CAN-Schicht (Layer 1 ) die gleiche, jedoch stimmen die standard-individuellen Kommunikationsprotokolle und die Kommunikationsparameter wie Baudraten nicht überein. Beide Standards, CHAdeMO (Japan) und GB/T (China), erfordern eine CAN-Kommunikation zwischen Ladesäule und Fahrzeug, jedoch mit unterschiedlichen Baudraten und

unterschiedlichen Kommunikationsabläufen. Hier besteht folglich innerhalb der technischen Umsetzung die Herausforderung, eine Lösung umzusetzen, die den Fahrzeugeinsatz gemäß der im jeweiligen Markt vorhandenen Ladenorm ermöglicht. In der Kommunikation mit den Ladesäulen trifft die Automobilindustrie auf außerhalb des Fahrzeugs und somit nicht in der Hand des Fahrzeugherstellers befindlichen externe Kommunikationspartner, mit abweichenden Anforderungen an die CAN-Kommunikation.

Bei der Unterstützung der beiden Ladesysteme gemäß CHAdeMO und GB/T-Normierung gilt es insbesondere, die unterschiedlichen Anforderungen an die Kommunikation zu adaptieren. Beide Standards unterscheiden sich vom logischen Botschafts-Handling, den

Kommunikationsabläufen und vor allem der CAN-Konfiguration. Eine CAN-Kommunikation die innerhalb der Automobilindustrie in erster Linie für die fahrzeuginterne Kommunikation ausgelegt ist, ist statisch festgelegt und unterliegt genauen vom Hersteller festgelegten Regeln. Somit unterstützen vorhandene Software-Module und Implementierungen von automobilen Steuergeräten nur diese spezielle Art der fahrzeuginternen CAN-Kommunikation mit

festgelegter Baudrate.

Vor diesem Hintergrund ist es bekannt, unterschiedliche, speziell für die jeweilige Ladenorm (CHAdeMO oder GB/T) entwickelte Steuergeräte oder Software-Varianten vorzusehen. Dies hat allerdings den Nachteil, dass solche alternativen Steuergeräte oder Software-Varianten separat in der Produktion berücksichtigt werden müssen. Es ist auch bekannt, zwei separate CAN- Kommunikationsschnittstellen mit individueller Verkabelung im Fahrzeug für die

unterschiedlichen Märkte China (GB/T) und Japan (CHAdeMO) zu nutzen. Solche individuellen Verkabelungen im Fahrzeug sind allerdings unökonomisch, da sie einen höheren Aufwand an beispielsweise Raum erfordern, kostenintensiv sind und einen erhöhten Steuerungsaufwand mit sich bringen.

Aufgabe der vorliegenden Erfindung ist es, ein Ladesystem bereitzustellen, das die oben genannten Nachteile wenigstens teilweise überwindet. Diese Aufgabe wird durch das erfindungsgemäße Verfahren nach Anspruch 1 , eine entsprechende Betriebssoftware und ein entsprechendes Steuergerät gelöst. Weitere vorteilhafte Ausgestaltungen der Erfindung ergeben sich aus den Unteransprüchen und der folgenden Beschreibung bevorzugter

Ausführungsbeispiele der vorliegenden Erfindung.

Die vorliegende Erfindung betrifft ein Verfahren für die Ladekommunikation eines elektrisch betriebenen Fahrzeugs, bei dem abhängig vom verwendeten Ladesystem in einem

elektronischen Steuergerät ein erster Kommunikationsstack oder ein zweiter

Kommunikationsstack ausgewählt wird, wobei der erste Kommunikationsstack eine CAN- Kommunikation auf Basis eines ersten Ladesystems und der zweite Kommunikationsstack eine CAN-Kommunikation auf Basis eines zweiten Ladesystems über dieselbe physikalische Schnittstelle mit unterschiedlicher Konfiguration bereitstellen.

Das Verfahren hat den Vorteil, dass beispielsweise eine Applikation entweder mittels des ersten Kommunikationsstacks oder mittels des zweiten Kommunikationsstacks über dieselbe physikalische CAN-Schnittstelle kommunizieren kann. Damit kann ein und dieselbe Software zwei oder mehrere länder- oder marktspezifische Ladenormen über ein und dieselbe

physikalische CAN-Kommunikationsstrecke abdecken. Bei der Applikation kann es sich beispielsweise um ein Programm oder ein Programmmodul in einer AUTOSAR-Architektur, oder auch um eine Softwarekomponente auf einer Applikationsschicht handeln.

Ein Kommunikationsstack kann beispielsweise ein oder mehrere Software-Module umfassen, die über Schnittstellen von der Applikationsschicht getrennt sind, und somit als logisch und funktionell von der Applikationsschicht getrennt angesehen werden können. Das Vorsehen von Kommunikationsstacks bzw. Modulen, die logisch und funktionell von der Applikationsschicht getrennt sind, hat den Vorteil, die Austauschbarkeit von Modulen einfach zu ermöglichen. Eine Applikation auf der Applikationsschicht kann beispielsweise über Programmierschnittstellen (APIs) auf Funktionalitäten des Kommunikationsstacks zugreifen. Bei den Modulen des

Kommunikationsstacks kann es sich beispielsweise um Treiber, Schnittstellen, oder dergleichen handeln. Gemäß einer bevorzugten Ausführungsform der Erfindung stellt der erste Kommunikationsstack eine CAN-Kommunikation auf Basis des CHAdeMO-Protokolls bereit und der zweite

Kommunikationsstack stellt eine CAN-Kommunikation auf Basis des GB/T-Protokolls bereit. Dies hat den Vorteil, dass mit ein und derselben Software eine CAN-Kommunikation entweder nach dem CHAdeMO-Protokoll oder nach dem GB/T-Protokoll über ein und dieselbe physikalische CAN-Kommunikationsstrecke abgedeckt werden kann.

Kennzeichnend für die Kommunikation gemäß CHAdeMO Standard ist, dass alle definierten CAN-Botschaften zeitgleich zyklisch auf den Bus gelegt und die Parameter der Botschaften während des Ablaufs aktualisiert werden. Dies ähnelt hinsichtlich dem eigentlichen

Kommunikationsablauf der fahrzeuginternen Kommunikation mit einer festgelegten Baudrate von 500kBit/s, was dazu führt, dass gemäß eines bevorzugten Ausführungsbeispiels eine der fahrzeuginternen Kommunikation ähnliche CAN-Konfigurationen über Standardsoftwaremodule genutzt wird.

Beispielsweise wird zur Durchführung der ladesystemspezifischen Kommunikation ein Treiber der CAN-Schicht entsprechend der Ländervariante konfiguriert. Dies hat den Vorteil, dass ein bereits bestehender Treiber der CAN-Schicht genutzt werden kann, der lediglich durch

Konfiguration an die ladesystemspezifische Kommunikation angepasst wird.

Gemäß GB/T (China) werden die definierten Botschaften zwar auch zyklisch auf den Bus gelegt, jedoch wie bei einem Frage-Antwort-Ablauf jeweils nur eine Botschaft, so lange bis von der Gegenstelle die Antwort wieder zyklisch auf den Bus gelegt wird. Für segmentierte

Botschaften setzt GB/T (China) zusätzlich auf das SAE J1939 Protokoll aus der

Nutzfahrzeugindustrie. Die Kommunikation erfolgt abweichend mit Baudraten von 50kBit/s, 125kBit/s bzw. 250kBit/s.

Gemäß einer weiteren bevorzugten Ausführungsform der Erfindung umfasst das

erfindungsgemäße Verfahren ein Auswählen und Konfigurieren des jeweiligen

Kommunikationsstack anhand der Erkennung der jeweiligen Ländervariante, mit

Berücksichtigung der entsprechenden CAN-Treiberkonfiguration für das jeweilige Ladesystem. Dies hat den Vorteil, dass sich eine entsprechende Betriebssoftware des Lademanagement- Steuergeräts auf die jeweilige Ländervariante einstellen und somit mit verschiedenen

Ladesystemen mit unterschiedlichen Kommunikationsabläufen und Baudraten der CAN- Kommunikation zusammenarbeiten kann. Die Erkennung oder Konfiguration kann statisch über eine Parametrierung oder Codierung während der Produktion festgelegt werden oder dynamisch aufgrund einer

Ladesystemerkennung anhand der verbauten Ladedosen oder anliegender elektrischer Signale (z.B. Start-Stopl (CSS1 ) bei CHAdeMO oder CC1 beim GB/T Standard).

Die statische Lösung hat den Vorteil schnell in der Aufstartzeit zu sein. Hierzu wird ein

Software-Flag aus dem Speicher während der Initialisierung des Steuergerätes ausgewertet. Eine dynamische Ladesystemerkennung kann auch durch eine komplexere Lösung erfolgen, z.B. mittels einer Erkennung der verbauten Ladedose anhand von anliegenden

Spannungswerten an den ladesystemspezifischen Signaleingängen des Steuergerätes oder anhand Widerstandskodierungen der verbauten Ladedosen an definierten Leitungen des Steuergerätes.

Eine weitere Möglichkeit der Erkennung besteht in der alternierenden Baudratenumschaltung um zu erfassen, ob eine Kommunikation gemäß eines der beiden Standards mit der Ladesäule möglich ist. Bei der alternierenden Baudratenumschaltung werden unter Berücksichtigung der jeweils nötigen Baudrate zunächst Botschaften gemäß des einen Ladekommunikationsprotokolls und bei Nichtbeantwortung, bzw. einer vorliegenden Bus-Fehlererkennung folgend Botschaften des zweiten Protokolls abgeschickt. Dieses Verfahren ist speziell dann sinnvoll, wenn eine Adaption des Kabelbaums bzw. der Anbindung an die jeweilige Ladesäule z.B. mittels Adapterbox erfolgt, so dass sowohl der CHAdeMO-spezifische, als auch der GB/T spezifische Stecker mit den entsprechenden Signalen mit dem Fahrzeug verbunden werden können, welches ggf. weitere Maßnahmen der Hardware-Änderung erfordert.

Gemäß einer weiteren bevorzugten Ausführungsform der Erfindung wird im Falle der

Erkennung der Ländervariante China ein Kommunikationsstack mit einer CAN- Treiberkonfiguration für das GB/T- Ladesystem ausgewählt und/oder konfiguriert, und im Falle der Erkennung der Ländervariante Japan wird ein Kommunikationsstack mit einer CAN- Treiberkonfiguration für das CHAdeMO-Ladesystem ausgewählt und/oder konfiguriert. Dies hat den Vorteil, dass beispielsweise sowohl DC-Laden nach GB/T (China) als auch nach

CHAdeMO (Japan) mit ein und demselben Steuergerät bzw. ein und derselben Steuergeräte- Software unterstützt werden kann.

Gemäß einer weiteren bevorzugten Ausführungsform der Erfindung wird je nach Ländervariante eine intelligente Baudratenumstellung vorgenommen, abhängig vom zu verwendenden

Ladesystem. Somit kann beispielsweise eine Betriebssoftware die Baudrate der CAN- Kommunikation an das jeweilige Ladesystem anpassen. Seitens des CHAdeMO-Standards sind hier 500kBit/s spezifiziert, seitens GB/T-Standard 50Kbit/s, 125Kbit/s bzw. 250Kbit/s.

Das hier beschriebene Verfahren kann beispielsweise als Betriebssoftware für ein

Lademanagement-Steuergerät umgesetzt werden. Gemäß einer bevorzugten Ausführungsform wird das Verfahren bzw. die Betriebssoftware auf einer AUTOSAR-Umgebung umgesetzt. Dies hat den Vorteil, dass AUTOSAR eine Standardisierung von Kommunikationsstacks und entsprechenden Modulen gewährleistet und somit die erfindungsgemäße Betriebssoftware leicht als Softwaremodul in Fahrzeugen unterschiedlicher Hersteller und den Elektronik- Komponenten verschiedener Zulieferer zum Einsatz kommen kann. Speziell die

Ladekommunikation der CHAdeMO-Spezifikation kann unter Verwendung der Standard

AUTOSAR-Module für die CAN-Kommunikation umgesetzt werden.

Die Erfindung betrifft auch die Möglichkeit das Verfahren bzw. die Betriebssoftware in anderen vorhandenen Steuergeräten des Fahrzeugs einzusetzen, wie z.B. einem Ladegerät oder einem Batteriemanagement.

Die Erfindung betrifft ferner auch ein Elektrofahrzeug mit einem solchen erfindungsgemäßen Lademanagement-Steuergerät. Bei dem Elektrofahrzeug kann es sich um eine beliebige Art von Elektrofahrzeug handeln, das z.B. eine Traktionsbatterie für den Antrieb aufweist. Der erfindungsgemäße Lademanager bzw. die erfindungsgemäße Software für einen Lademanager kann beispielsweise auch in einem Hybridelektrofahrzeug eingesetzt werden.

Ausführungsbeispiele der Erfindung werden nun beispielhaft und unter Bezugnahme auf die beigefügten Zeichnungen beschrieben, in denen:

Fig. 1 schematisch ein Elektrofahrzeug an einer CHAdeMO-Ladesäule gemäß der CHAdeMO- Ladetechnik zeigt;

Fig. 2 schematisch ein Ausführungsbeispiel des Pin-Layouts eines Ladesteckers nach dem CHAdeMO-Ladestecksystem zeigt;

Fig. 3 schematisch ein Ausführungsbeispiel des Pin-Layouts eines Ladesteckers nach dem GB/T-Ladestecksystem zeigt. Fig. 4 eine schematische Darstellung der geschichteten Struktur der AUTOSAR-Architektur zeigt;

Fig. 5 ein Ausführungsbeispiel für eine Software-Architektur mit einem CHAdeMO-spezifischen Kommunikationsstack und mit einem GB/T-spezifi sehen Kommunikationsstack zeigt;

Fig. 6 ein alternatives Ausführungsbeispiel für eine Software-Architektur mit einem CHAdeMO- spezifischen Kommunikationsstack und mit einem GB/T-spezifischen Kommunikationsstack zeigt;

Fig. 7 ein weiteres alternatives Ausführungsbeispiel für eine Software-Architektur mit einem CHAdeMO-spezifischen Kommunikationsstack und mit einem GB/T-spezifischen

Kommunikationsstack zeigt; und

Fig. 8 ein schematisches Flussdiagramm bezüglich einer beispielhaften erfindungsgemäßen Softwareapplikation zeigt, die als Betriebssoftware für einen Lademanager dienen kann.

Die folgenden Ausführungsbeispiele beschreiben eine erfindungsgemäße Betriebssoftware für einen Lademanager, die auf einer Softwarearchitektur beruht, die eine Applikation umfasst, welche die Funktionalität eines Lademanagers bereitstellt, sowie einen ersten und einen zweiten Kommunikationsstack, wobei der erste Kommunikationsstack eine CAN- Kommunikation auf Basis eines ersten Ladeprotokolls bereitstellt und der zweite

Kommunikationsstack eine CAN-Kommunikation auf Basis eines zweiten

Kommunikationsstacks bereitstellt.

Fig. 1 zeigt ein Elektrofahrzeug 1 an einer CHAdeMO-Ladesäule 2 gemäß der CHAdeMO- Ladetechnik. Zur Verbindung des Elektrofahrzeugs 1 mit der CHAdeMO-Ladesäule 2 verfügt die CHAdeMO-Ladesäule 2 über einen CHAdeMO-Stecker 3, der in eine CHAdeMO-Buchse 4 des Elektrofahrzeugs 1 eingeführt wird. Das Elektrofahrzeug 1 ist ferner mit einem

Lademanagement-Steuergerät 5 ausgerüstet, das mit dem Energiemanagement 6 des

Elektrofahrzeugs 1 in Verbindung steht. Das Lademanagement-Steuergerät 5 ist in diesem Fall dazu ausgelegt, nach dem CHAdeMO-Protokoll zu arbeiten. Die Kommunikation zwischen Ladesäule 2 und Elektrofahrzeug 1 erfolgt durch eine Kombination aus

Zustandssignalisierungen und einer 2-Draht-CAN-Kommunikation. Fig. 2 zeigt schematisch ein Ausführungsbeispiel des Pin-Layouts eines Ladesteckers nach dem CHAdeMO-Ladestecksystem. Pin PE ist die als Referenz und Schutz dienende Erdleitung. Pins CSS1 (Charger Start/Stop 1 ) und CSS2 (Charger Start/Stop 1 ) dienen zur Steuerung eines EV-Relays. Pin N ist nicht zugewiesen. Pin CED ("Charging Enable/Disable") dient für die Anzeige der Bereitschaft für die Ladesteuerung ("Ready to Charge"). Pin DC- dient als negative Leitung der Energieübertragung. Pin DC+ dient als positive Leitung der Energieübertragung. Pin COC ("Connection Check") dient für die Signale eines Näherungsdetektors. Pin CAN-H dient als Plusleitung einer Datenkommunikation. Pin CAN-L dient als Minusleitung der

Datenkommunikation.

Fig. 3 zeigt schematisch ein Ausführungsbeispiel des Pin-Layouts eines Ladesteckers nach dem GB/T-Ladestecksystem. Pin PE ist die als Referenz und Schutz dienende Erdleitung. Pins CC1 und CC2 ("Charging Connection Confirmation") dienen zur Steuerung des Ladevorgangs. Pin DC- dient als negative Leitung der Stromversorgung. Pin DC+ dient als positive Leitung der Stromversorgung. Pin S+ (CAN-H) dient als Plusleitung einer Datenkommunikation. Pin S- (CAN-L) dient als Minusleitung der Datenkommunikation. Pin A+ dient als positive Leitung einer Hilfsstromversorgung für Niedervoltladen und Pin A- dient als negative Leitung einer

Hilfsstromversorgung für Niedervoltladen.

Im Folgenden wird die vorliegende Erfindung beispielhaft im Rahmen der Systemarchitektur AUTOSAR (AUTomotive Open System ARchitecture) beschrieben. Die vorliegende Erfindung ist jedoch nicht auf diese spezielle Systemarchitektur beschränkt. Das Konzept kann auch auf andere Systemarchitekturen übertragen werden. Eine Einführung in die Systemarchitektur AUTOSAR ist beispielsweise in der Veröffentlichung "AUTOSAR - Eine Einführung" von Robert Neue, TU Dortmund (https://ess.cs.tu-dortmund.de/ Teaching/PGs/autolab/

ausarbeitungen/Neue-AUTOSAR-Ausarbeitung.pdf) oder in der Veröffentlichung "Die Software- Architektur von AUTOSAR" von Oliver Busch, Universität Koblenz-Landau (https://www.uni- koblenz-landau.de/de/koblenz/fb4/ist/AGZoebel/Lehre/ss2012/seminar/oBusch) gegeben.

Fig. 4 zeigt eine schematische Darstellung der geschichteten Struktur der AUTOSAR- Architektur. AUTOSAR ist eine dreischichtige Softwarearchitektur. Als Basissoftware 14 werden standardisierte Softwaremodule zur Beschreibung einer Infrastruktur bezeichnet, deren

Vorhandensein notwendig ist, um den funktionellen Teil der oberen Software-Ebene zu betreiben. Eine Laufzeitumgebung (Run-Time Environment, RTE) 12 stellt eine Middleware dar, die von der Netzwerk-Topologie für den Datenaustausch von Inter- und Intra-ECUs (Electronic Control Units, Steuergeräte) zwischen Applikations-Software-Komponenten und zwischen der Basissoftware und Applikationen abstrahiert. Als Anwendungsschicht 13 werden Komponenten der Applikations-Software bezeichnet, die mit der Laufzeitumgebung 12 interagieren. Das Applikationsmodul 21 stellt ein Beispiel für solch eine Softwarekomponente der

Anwendungsschicht 13 dar. Durch eine Standardisierung von Schnittstellen hinsichtlich ihrer physikalischen und zeitlichen Repräsentation wird eine Kompatibilität bei der Integration erreicht. Über die Basisschicht erfolgen die Hardwarezugriffe. AUTOSAR definiert somit eine Softwarearchitektur für Steuergeräte, welche die Software von der Hardware des Gerätes entkoppelt. Die Services-Schicht 1 1 stellt Systemdienste wie zum Beispiel Diagnose-Protokolle, NVRAM, Flash- und Speicher-Management bereit. Der Microcontroller Abstraction Layer (MCAL) 8 greift direkt auf externe Peripherie-ICs zu, wie beispielsweise einen Microcontroller für die CAN-Kommunikation (CAN-MCU) 16. Der Microcontroller Abstraction Layer 8 umfasst beispielsweise Kommunikationstreiber, wie einen CAN-Treiber 15. Der Can-Treiber 15 in Zusammenwirken mit der CAN-MCU 16 auf der Microcontroller-Schicht 7 bewirkt CAN

Input/Output. Die ECU Abstraktionsschicht 10 stellt Schnittstellen zu den Treibern der

Microcontroller Abstraction Layer 8 bereit, z.B. eine Schnittstelle zum CAN-Treiber 15.

Die Basissoftware 14 von AUTOSAR wird in vertikale Bereiche, die sogenannten Stacks aufgeteilt. Die Stacks und die Layer überschneiden sich und bilden sogenannte

Funktionsblöcke. Innerhalb der Funktionsblöcke definiert der AUTOSAR-Standard sogenannte Module. Als Kommunikationsstack wird in AUTOSAR ein Satz von Modulen bezeichnet, wie beispielsweise das COM-Modul (Services-Schicht), PDU Router (Services-Schicht), CAN SM (Services-Schicht), busspezifische Schnittstellenmodule (ECU Abstraktionsschicht) wie Canlf, Linlf, Frlf, etc., externe Bustreiber, wie das CAN-Interface (ECU Abstraktionsschicht) und interne Bustreiber, wie der CAN-Treiber (MCAL Schicht).

Fig. 5 zeigt ein Ausführungsbeispiel für eine Software-Architektur mit einem CHAdeMO- spezifischen Kommunikationsstack 20a und einem GB/T-spezifischen Kommunikationsstack 20b. Der erste Kommunikationsstack 20a ist für die CAN-Kommunikation über das CHAdeMO- Protokoll vorgesehen. Der zweite Kommunikationsstack 20b ist für die CAN-Kommunikation über das GB/T-Protokoll vorgesehen. Der Kommunikationsstack 20a für CAN/CHAdeMO umfasst vier Basissoftwaremodule, nämlich einen CAN/CHAdeMO-Treiber 15a im

Funktionsblock "Communications Drivers" der MCAL-Schicht 8, ein CAN/CHAdeMO-Interface 17a im Funktionsblock "Communications Hardware Abstractions" der ECU Abstraktionsschicht 10, sowie einen CHAdeMO/PDU-Router 18a und ein CHAdeMO/COM-Modul 19a im

Funktionsblock "Communications Services" der Services-Schicht 1 1. Der Kommunikationsstack 20b für CAN/GB/T umfasst vier Basissoftwaremodule, nämlich einen CAN/GB/T-Treiber 15b im Funktionsblock "Communications Drivers" der MCAL-Schicht 8, ein CAN/GB/T-Interface 17a im Funktionsblock "Communications Hardware Abstractions" der ECU Abstraktionsschicht 10, sowie einen GB/T/PDU-Router 18b und ein GB/T/COM-Modul mit SAE J1939-Unterstützung 19b im Funktionsblock "Communications Services" der Services-Schicht 1 1. Die CHAdeMO- bzw. GB/T-spezifischen COM-Module 19a und 19b sind u.a. für das Bereitstellen der

Transportprotokolle, das Handling und das Timing der Botschaften für das Bussystem CAN zuständig. Die Schnittstellen 17a bzw. 17b stellen Funktionen für den Zugriff auf die

verfügbaren Kanäle des CAN-Bussystems zur Verfügung. Die Treiber 15a bzw. 15b bieten Funktionen zum Start von Übertragungen oder Call-Back Funktionen und zur Konfiguration des Busverhaltens zur Verfügung. Diese Module werden auf die dem Fachmann bekannte Weise für die Kommunikation mittels CAN/CHAdeMO oder CAN/GB/T eingerichtet. Beide

Kommunikationsstacks 20a, 20b nutzen dieselbe CAN-MCU der Microcontroller-Schicht 7, d.h. sie stellen eine CAN-Kommunikation über dieselbe physikalische Schnittstelle bereit.

Im Ausführungsbeispiel der Fig. 5 sind zwei ladesystemspezifische Kommunikationsstacks 20a, b vorgesehen, die sich in den CAN-T reibern 15a, 15b, den CAN-Interfaces 17a, 17b, den PDU- Routern 18a, 18b und den COM-Modulen 19a, 19b unterscheiden. Dem Fachmann ist jedoch ersichtlich, dass in alternativen Implementierungsvarianten die Kommunikationsstacks sich lediglich in einer dieser Komponenten unterscheiden können, z.B. nur in den COM-Modulen 19a, 19b und der resultierenden CAN-Treiber-Konfiguration oder, alternativ, z.B. nur in den CAN-Treibern 15a, 15b.

Fig. 6 zeigt solch ein Ausführungsbeispiel in dem sich die Kommunikationsstacks lediglich in den Ladesystem-spezifischen COM-Modulen 19a, 19b unterscheiden. Der

Kommunikationsstack 20a ist durch ein gemäß der CHAdeMO-Norm konfiguriertes Standard- COM-Modul gekennzeichnet und ähnelt hinsichtlich dem eigentlichen Sende- und

Empfangsverhalten von zyklischen CAN-Botschaften der fahrzeuginternen Kommunikation. Für die Umsetzung der Kommunikation gemäß GB/T-Standard in Kommunikationsstack 20b wird gemäß dieser Ausführungsform eine GB/T-spezifische COM-Implementierung inkl. einer SAE J1939 Komponente oberhalb des AUTOSAR CAN-Interface-Moduls bzw. des PDU- Routers vorgesehen. Das Standard AUTOSAR-COM-Modul wird aufgrund des GB/T- spezifischen CAN-Kommunikationsverhaltens der Botschaften, welches stark von einem fahrzeuginternen CAN-Kommunikationsverhalten abweicht, im Kommunikationsstack 20b nicht verwendet. Eine GB/T spezifische Implementierung eines COM-Moduls wird von der

Schnittstelle zu den höheren Schichten, also zur Applikation, gemäß der

Schnittstellenspezifikation des AUTOSAR-COM-Moduls implementiert, um so eine möglichst große Unabhängigkeit der Applikation vom Kommunikationsstack gemäß GB/T-Standard zu schaffen. Bei dieser Ausführungsform wird der China-GB/T-Kommunikationsstack 20b als GB/T-spezifisches COM-Modul realisiert. Das GB/T-spezifische COM-Modul ist für die

Einhaltung der definierten Botschaftsbehandlung bzgl. Zeitverhalten und versenden und verarbeiten der zyklischen Botschaften im Frage-Antwort Kommunikationsablauf gemäß GB/T- Standard zuständig. Der CAN-Treiber 15 wird in diesem Ausführungsbeispiel zur Laufzeit oder in der Initphase zum Aufstartzeitpunkt durch die Betriebssoftware Ladesystemspezifisch umkonfiguriert. Somit wird eine paralelle Implementierung von auf CAN basierenden

Ladekommunikationsprotokollen über ein und dieselbe physikalische CAN-Schnittstelle innerhalb ein und derselben Steuergerätesoftware ermöglicht.

Fig. 7 zeigt ein weiteres alternatives Ausführungsbeispiel in dem sich die

Kommunikationsstacks lediglich in den Ladesystem-spezifischen CAN-T reibern 15a, 15b unterscheiden.

Fig.8 zeigt ein schematisches Flussdiagramm bezüglich einer beispielhaften

erfindungsgemäßen Softwareapplikation, die als Betriebssoftware für einen Lademanager dienen kann. Die Softwareapplikation kann beispielsweise als ein AUTOSAR-Applikationsmodul (vgl. Anwendungsschicht 13 der Fig. 4) vorgesehen werden. Die Softwareapplikation weist Programminstruktionen auf, die dazu ausgelegt sind, anhand der Erkennung der jeweiligen Ländervariante den jeweiligen Kommunikationsstack mit Berücksichtigung der entsprechenden Treiberkonfiguration für das jeweilige Ladesystem auszuwählen und zu konfigurieren. Bei Schritt 601 wird eine Ländervariante LV abgefragt. Bei Schritt 602 wird überprüft, ob die

Ländervariante CN = China vorliegt. Ist dies der Fall, so wird mit Schritt 603 fortgesetzt. Bei Schritt 603 wird ein Kommunikationsstack mit einer Treiberkonfiguration für das GB/T- Ladesystem ausgewählt und konfiguriert. Wird bei Schritt 602, die Ländervariante CN = China nicht erkannt, so wird mit Schritt 604 fortgefahren. Bei Schritt 604 wird überprüft, ob die

Ländervariante JP = Japan vorliegt. Ist dies der Fall, so wird mit Schritt 605 fortgefahren. Bei Schritt 605 wird ein Kommunikationsstack mit einer Treiberkonfiguration für das CHAdeMO - Ladesystem ausgewählt und konfiguriert. Die Ladekommunikation kann daraufhin gemäß dem ausgewählten und konfigurierten Kommunikationsstack ausgeführt werden, d.h. gemäß

CHAdeMO/CAN im Falle der Ländervariante Japan bzw. GB/T/CAN im Falle der Ländervariante China. Bezugszeichenliste

1 Elektrofahrzeug

CHAdeMO-Ladesäule

CHAdeMO-Stecker der Ladesäule

CHAdeMO-Buchse des Elektrofahrzeugs

Lademanagement-Steuergerät

Energiemanagement

Microcontroller (Hardware)

Microcontroller Abstraction Layer (MCAL)

komplexe Gerätetreiber (CDD = Complex Device Drivers)

10 ECU Abstraktionsschicht

1 1 Services-Schicht

12 Runtime Environment (RTE)

13 Anwendungsschicht

14 Basissoftware

15 CAN-Treiber

15a CAN/CHAdeMO-Treiber

15b CAN/GB/T-Treiber

16 CAN-MCU

17 CAN -Interface

17a CAN/CHAdeMO-Interface

17b GB/T/CHAdeMO-Interface

18a PDU-Router

18a CHAdeMO/PDU-Router

18b GB/T/PDU-Router

19 COM-Modul

19a CHAdeMO/COM-Modul

19b GB/T/COM-Modul

20a CAN/CHAdeMO-Kommunikationsstack

20b CAN/GB/T-Kommunikationsstack

21 Applikationsmodul

DC+ Energieübertragung + DC- Energieübertragung -

CAN-H digitale Kommunikation +

CAN-L digitale Kommunikation -

CSS1 Charger Start/Stop 1

CSS2 Charger Start/Stop 2

CED Charging Enabled/Disabied

PE Protective Earth ("funktionale" Schutzerde)

PP Proximity Pilot ("Steckererkennung")

CED Charging Enable/Disable

LV Ländervariante

CN Ländervariante China

JP Ländervariante Japan

Claims

Patentansprüche

1. Verfahren für das Lademanagement eines elektrisch betriebenen Fahrzeugs, bei dem abhängig vom verwendeten Ladesystem ein erster Kommunikationsstack (20a) oder ein zweiter Kommunikationsstack (20b) ausgewählt wird, wobei der erste

Kommunikationsstack (20a) eine CAN-Kommunikation auf Basis eines ersten

Ladesystems und der zweite Kommunikationsstack (20b) eine CAN-Kommunikation auf Basis eines zweiten Ladesystems über dieselbe physikalische Schnittstelle bereitstellen.

2. Verfahren nach Anspruch 1 , wobei der erste Kommunikationsstack (20a) eine CAN- Kommunikation auf Basis des CHAdeMO-Protokolls bereitstellt und wobei der zweite Kommunikationsstack (20b) eine CAN-Kommunikation auf Basis des GB/T-Protokolls bereitstellt.

3. Verfahren nach Anspruch 1 oder, bei dem zur Durchführung der ladesystemspezifischen Kommunikation ein Treiber der CAN-Schicht des ersten und/oder des zweiten

Kommunikationsstacks entsprechend der jeweiligen Ländervariante konfiguriert wird.

4. Verfahren nach einem der Ansprüche 1 bis 3, bei dem anhand der Erkennung der

jeweiligen Ländervariante der jeweiligen Kommunikationsstack (20a, 20b) mit

Berücksichtigung der entsprechenden Treiberkonfiguration für das jeweilige Ladesystem ausgewählt und/oder konfiguriert wird.

5. Verfahren nach Anspruch 4, bei dem im Falle der Erkennung der Ländervariante China ein Kommunikationsstack mit einer Treiberkonfiguration für das GB/T-Ladesystem ausgewählt und/oder konfiguriert wird, und bei dem im Falle der Erkennung der

Ländervariante Japan ein Kommunikationsstack mit einer Treiberkonfiguration für das CHAdeMO-Ladesystem ausgewählt und/oder konfiguriert wird.

6. Verfahren nach einem der vorstehenden Ansprüche, bei dem je nach Ländervariante eine intelligente Baudratenumstellung vorgenommen wird.

7. Verfahren nach einem der vorstehenden Ansprüche, bei dem eine paralelle

Implementierung von auf CAN basierenden Ladekommunikationsprotokollen über ein und dieselbe physikalische CAN-Schnittstelle innerhalb ein und derselben

Steuergerätesoftware realisiert wird.

8. Betriebssoftware, die dazu ausgelegt ist, das Verfahren nach einem der Ansprüche 1 bis 7 auszuführen.

9. Betriebssoftware nach Anspruch 8, die auf einer AUTOSAR-Umgebung umgesetzt ist.

10. Steuergerät mit einem Prozessor, der so konfiguriert ist, dass er das Verfahren nach einem der Ansprüche 1 bis 7 ausführt.