WO2018069192A1 - Intelligente ladekommunikationsumschaltung bei can-basierten ladesystemen - Google Patents

Intelligente ladekommunikationsumschaltung bei can-basierten ladesystemen Download PDF

Info

Publication number
WO2018069192A1
WO2018069192A1 PCT/EP2017/075550 EP2017075550W WO2018069192A1 WO 2018069192 A1 WO2018069192 A1 WO 2018069192A1 EP 2017075550 W EP2017075550 W EP 2017075550W WO 2018069192 A1 WO2018069192 A1 WO 2018069192A1
Authority
WO
WIPO (PCT)
Prior art keywords
communication
charging
chademo
charging system
communication stack
Prior art date
Application number
PCT/EP2017/075550
Other languages
English (en)
French (fr)
Inventor
Axel Ulrich
Original Assignee
Volkswagen Aktiengesellschaft
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Volkswagen Aktiengesellschaft filed Critical Volkswagen Aktiengesellschaft
Priority to CN201780063635.8A priority Critical patent/CN109843637B/zh
Priority to JP2019520106A priority patent/JP2020501479A/ja
Publication of WO2018069192A1 publication Critical patent/WO2018069192A1/de

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/10—Current supply arrangements
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60L—PROPULSION OF ELECTRICALLY-PROPELLED VEHICLES; SUPPLYING ELECTRIC POWER FOR AUXILIARY EQUIPMENT OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRODYNAMIC BRAKE SYSTEMS FOR VEHICLES IN GENERAL; MAGNETIC SUSPENSION OR LEVITATION FOR VEHICLES; MONITORING OPERATING VARIABLES OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRIC SAFETY DEVICES FOR ELECTRICALLY-PROPELLED VEHICLES
    • B60L53/00—Methods of charging batteries, specially adapted for electric vehicles; Charging stations or on-board charging equipment therefor; Exchange of energy storage elements in electric vehicles
    • B60L53/60—Monitoring or controlling charging stations
    • B60L53/66—Data transfer between charging stations and vehicles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40208—Bus networks characterized by the use of a particular bus standard
    • H04L2012/40215—Controller Area Network CAN

Definitions

  • the invention relates to the field of charging systems and interfaces for electric vehicles.
  • the CHAdeMO charging system which is especially represented in the Japanese market, is based on
  • the CHAdeMO charging communication takes place via the CAN protocol and via two CAN bus lines.
  • the car's charging system communicates with the charging system of the fast charging station using a master-slave system.
  • the charging system of the car master
  • reports charging station (slave) charging parameters such as the current charge level of a traction battery, as well as the DC voltage and maximum current with which the
  • Traction battery may be charged. Furthermore, parameters such as voltage, temperature and other parameters of the traction battery are transmitted.
  • the CHAdeMO protocol is in the
  • ISO standardization as a DC charging standard and was included as standards ISO / IEC 61851-23 and ISO / IEC 61851-24.
  • a CAN-based layerl communication protocol according to CHAdeMO standard is used.
  • the Chinese GB / T 20234 standard also provides a charging plug system suitable for both conventional AC charging and DC charging, in which charge communication is via the CAN protocol.
  • the GB / T standard allows fast DC charging at appropriate fast charging stations.
  • a CAN-based Layer 1 communication protocol according to GB / T standard is used.
  • Layer 1 the physical CAN layer (Layer 1) is the same between the existing CHAdeMO standard and the new China GB / T, the standard individual communication protocols and communication parameters such as baud rates do not match. Both standards, CHAdeMO (Japan) and GB / T (China), require CAN communication between the charging station and the vehicle, but at different baud rates and rates
  • CAN communication which is primarily designed for in-vehicle communication within the automotive industry, is static and subject to precise manufacturer-defined rules. Thus, existing software modules and implementations of automotive controllers only support this particular type of in-vehicle CAN communication
  • the object of the present invention is to provide a charging system which at least partially overcomes the above-mentioned disadvantages. This object is achieved by the method according to claim 1, a corresponding operating software and a corresponding control unit. Further advantageous embodiments of the invention will become apparent from the dependent claims and the following description
  • the present invention relates to a method for the charging communication of an electrically operated vehicle, in which depending on the charging system used in a
  • Communication stack is selected, wherein the first communication stack provide a CAN communication based on a first charging system and the second communication stack a CAN communication based on a second charging system via the same physical interface with different configuration.
  • the method has the advantage that, for example, an application can communicate via the same physical CAN interface either by means of the first communication stack or by means of the second communication stack.
  • an application can communicate via the same physical CAN interface either by means of the first communication stack or by means of the second communication stack.
  • one and the same software can have two or more country or market specific load standards over one and the same
  • the application can be, for example, a program or a program module in an AUTOSAR architecture, or even a software component on an application layer.
  • a communication stack may include, for example, one or more software modules which are separated from the application layer via interfaces, and thus can be regarded as logically and functionally separate from the application layer.
  • the provision of communication stacks or modules which are logically and functionally separated from the application layer has the advantage of facilitating the interchangeability of modules.
  • an application on the application layer can access functionalities of the communication stack via programming interfaces (APIs).
  • APIs programming interfaces
  • Communication stacks may be, for example, drivers, interfaces, or the like.
  • the first communication stack provides a CAN communication based on the CHAdeMO protocol and the second one
  • Communication Stack provides CAN communication based on the GB / T protocol. This has the advantage that with one and the same software a CAN communication can be covered either by the CHAdeMO protocol or by the GB / T protocol over the same physical CAN communication link.
  • Characteristic of the communication according to the CHAdeMO standard is that all defined CAN messages are cyclically placed on the bus at the same time and the parameters of the messages are updated during the process. This is similar in terms of the actual
  • a driver of the CAN layer is configured according to the country variant for carrying out the charging system-specific communication. This has the advantage that an existing driver of the CAN layer can be used, which only by
  • Configuration is adapted to the charging system-specific communication.
  • the defined messages are also placed cyclically on the bus, but as with a question and answer procedure only one message at a time, until the answer is again cyclically placed on the bus by the remote station.
  • the communication is different with baudrates of 50kBit / s, 125kBit / s resp. 250kBit / s.
  • the method according to the invention comprises selecting and configuring the respective one
  • Charging systems with different communication processes and baud rates of CAN communication can work together.
  • the detection or configuration can be determined statically via a parameterization or coding during production or dynamically due to a
  • Charging system detection based on the built-in charging sockets or electrical signals applied (eg start-stop (CSS1) for CHAdeMO or CC1 for GB / T standard).
  • start-stop (CSS1) for CHAdeMO
  • CC1 for GB / T standard
  • the static solution has the advantage of being fast in the startup time. This is a
  • Dynamic charging system recognition can also be accomplished by a more complex solution, e.g. by means of a detection of the built-in charging socket on the basis of adjacent
  • Another possibility of detection consists in the alternating Baudratenumscrien to detect whether a communication according to one of the two standards with the charging station is possible.
  • messages are sent in accordance with the one baud rate and, in the event of non-response, or a present bus error detection message messages of the second protocol, taking into account the respectively required baud rate.
  • This method is particularly useful when an adaptation of the wiring harness or the connection to the respective charging station, for. by means of adapter box, so that both the CHAdeMO-specific, as well as the GB / T specific connector can be connected to the corresponding signals to the vehicle, which may require further measures of the hardware change.
  • a communication stack with a CAN driver configuration is selected and / or configured for the GB / T charging system, and in the case of Japan country variant detection, a communication stack is selected and / or configured with a CAN driver configuration for the CHAdeMO charging system , This has the advantage that, for example, both DC charging to GB / T (China) and after
  • CHAdeMO (Japan) can be supported with one and the same ECU or the same ECU software.
  • an intelligent baud rate change is made depending on the country variant, depending on the one to be used
  • an operating software can change the baud rate of the CAN Adapt communication to the respective charging system.
  • 500kBit / s are specified, on the GB / T standard 50Kbit / s, 125Kbit / s or 250Kbit / s.
  • the method described here can be used, for example, as operating software for a
  • Charge management control unit to be implemented.
  • the method or the operating software is implemented on an AUTOSAR environment.
  • AUTOSAR ensures a standardization of communication stacks and corresponding modules and thus the operating software according to the invention can be easily used as a software module in vehicles of different manufacturers and the electronic components of various suppliers. Especially the
  • the invention also relates to the possibility of using the method or the operating software in other existing control devices of the vehicle, such as e.g. a charger or a battery management.
  • the invention further relates to an electric vehicle with such a charge management control device according to the invention.
  • the electric vehicle may be any type of electric vehicle, e.g. having a traction battery for the drive.
  • the charging manager according to the invention or the software for a charging manager according to the invention can also be used for example in a hybrid electric vehicle.
  • Fig. 1 shows schematically an electric vehicle on a CHAdeMO charging station according to the CHAdeMO charging technique
  • Fig. 2 shows schematically an embodiment of the pin layout of a charging plug after the CHAdeMO charging plug system
  • Fig. 3 shows schematically an embodiment of the pin layout of a charging connector after the GB / T charging connector system.
  • Fig. 4 shows a schematic representation of the layered structure of the AUTOSAR architecture;
  • Fig. 5 shows an embodiment of a software architecture with a CHAdeMO-specific communication stack and with a GB / T-specific communication stack;
  • Fig. 6 shows an alternative embodiment for a software architecture with a CHAdeMO specific communication stack and with a GB / T specific communication stack;
  • FIG. 7 shows a further alternative embodiment for a software architecture with a CHAdeMO-specific communication stack and with a GB / T-specific one
  • Fig. 8 shows a schematic flow diagram relating to an exemplary inventive software application which may serve as operating software for a load manager.
  • the following embodiments describe an operating software for a load manager according to the invention, which is based on a software architecture that includes an application that provides the functionality of a load manager, and a first and a second communication stack, the first communication stack a CAN communication based on a first charging protocol provides and the second
  • the CHAdeMO charging station 2 shows an electric vehicle 1 on a CHAdeMO charging station 2 according to the CHAdeMO charging technology.
  • the CHAdeMO charging station 2 has a CHAdeMO plug 3, which is inserted into a CHAdeMO socket 4 of the electric vehicle 1.
  • the electric vehicle 1 is further with a
  • Electric vehicle 1 is in communication.
  • the charge management controller 5 is designed in this case to operate according to the CHAdeMO protocol.
  • the communication between charging station 2 and electric vehicle 1 is performed by a combination of
  • FIG. 2 shows schematically an embodiment of the pin layout of a charging connector after the CHAdeMO charging connector system.
  • Pin PE is the earth wire used as reference and protection.
  • Pins CSS1 (Charger Start / Stop 1) and CSS2 (Charger Start / Stop 1) are used to control an EV relay.
  • Pin N is not assigned.
  • Pin CED Charging Enable / Disable
  • Pin DC- serves as a negative conductor of energy transfer.
  • Pin DC + serves as a positive conductor of the energy transfer.
  • Pin COC Connection Check
  • Pin CAN-H serves as a positive line for data communication.
  • Pin CAN-L serves as minus lead of the
  • Pin PE is the earth wire used as reference and protection.
  • Pins CC1 and CC2 (“Charging Connection Confirmation") are used to control the charging process.
  • Pin DC- serves as a negative line of the power supply.
  • Pin DC + serves as a positive line for the power supply.
  • Pin S + (CAN-H) serves as a positive line for data communication.
  • Pin S- (CAN-L) serves as a minus line for data communication.
  • Pin A + serves as positive lead of an auxiliary power supply for low voltage charging and pin A- serves as negative lead of one
  • AUTOSAR is a three-layered software architecture.
  • basic software 14 standardized software modules are described for describing an infrastructure whose
  • a run-time environment (RTE) 12 is a middleware that is used by the network topology for data interchange of inter- and intra-ECUs (Electronic Control Units) between application software components and between the base software and Applications abstracted.
  • As the application layer 13 are components of the application software that interacts with the runtime environment 12.
  • the application module 21 provides an example of such a software component of
  • Application layer 13 By standardizing interfaces with regard to their physical and temporal representation, integration compatibility is achieved.
  • the hardware accesses occur via the base layer.
  • AUTOSAR thus defines a software architecture for ECUs, which decouples the software from the hardware of the device.
  • Services layer 1 1 provides system services such as diagnostic protocols, NVRAM, flash and memory management.
  • the microcontroller Abstraction Layer (MCAL) 8 accesses directly to external peripheral ICs, such as a microcontroller for the CAN communication (CAN-MCU) 16.
  • the microcontroller Abstraction Layer 8 includes, for example, communication driver, such as a CAN driver 15.
  • the Can driver 15 in cooperation with the CAN MCU 16 on the microcontroller layer 7 causes CAN
  • the ECU abstraction layer 10 provides interfaces to the drivers of the
  • Microcontroller Abstraction Layer 8 ready, e.g. an interface to the CAN driver 15.
  • the basic software 14 of AUTOSAR is divided into vertical areas, the so-called stacks.
  • the stacks and the layers overlap and form so-called
  • a communication stack in AUTOSAR is a set of modules, such as the COM module (services layer), PDU router (service layer), CAN SM (service layer), bus-specific interface modules (ECU abstraction layer) such as Canlf, Linlf, Frlf, etc., external bus drivers, such as the CAN interface (ECU abstraction layer) and internal bus drivers, such as the CAN driver (MCAL layer).
  • modules such as the COM module (services layer), PDU router (service layer), CAN SM (service layer), bus-specific interface modules (ECU abstraction layer) such as Canlf, Linlf, Frlf, etc.
  • ECU abstraction layer such as Canlf, Linlf, Frlf, etc.
  • external bus drivers such as the CAN interface (ECU abstraction layer)
  • internal bus drivers such as the CAN driver (MCAL layer).
  • FIG. 5 shows an exemplary embodiment of a software architecture with a CHAdeMO-specific communication stack 20a and a GB / T-specific communication stack 20b.
  • the first communication stack 20a is provided for CAN communication via the CHAdeMO protocol.
  • the second communication stack 20b is provided for CAN communication over the GB / T protocol.
  • the communication stack 20a for CAN / CHAdeMO comprises four basic software modules, namely a CAN / CHAdeMO driver 15a in FIG. 5
  • the communication layer 20b for CAN / GB / T comprises four basic software modules, namely a CAN / GB / T driver 15b in the function block "Communications Drivers" of the MCAL layer 8, a CAN / GB / T interface 17a in the "Communications Hardware Abstractions" functional block of the ECU abstraction layer 10, as well as a GB / T / PDU router 18b and a GB / T / COM module with SAE J1939 support 19b in the Services Layer 1 "Communications Services" functional block 1.
  • the CHAdeMO or GB / T-specific COM modules 19a and 19b are, inter alia, for providing the
  • the interfaces 17a and 17b provide functions for accessing the
  • the drivers 15a and 15b provide functions for starting transmission or call-back functions and for configuring the bus behavior. These modules are set up in the manner known to the person skilled in the art for communication by means of CAN / CHAdeMO or CAN / GB / T. Both
  • Communication stacks 20a, 20b use the same CAN MCU of microcontroller layer 7, i. they provide CAN communication over the same physical interface.
  • two charging system-specific communication stacks 20a, b are provided which are located in the CAN-Ts 15a, 15b, the CAN interfaces 17a, 17b, the PDU routers 18a, 18b and the COM modules 19a, 19b differ.
  • the communication stacks may differ only in one of these components, e.g. only in the COM modules 19a, 19b and the resulting CAN driver configuration or, alternatively, e.g. only in the CAN drivers 15a, 15b.
  • Fig. 6 shows such an embodiment in which the communication stacks differ only in the charging system-specific COM modules 19a, 19b.
  • Communication stack 20a is characterized by a standard COM module configured in accordance with the CHAdeMO standard and is similar in terms of the actual transmit and
  • GB / T-specific COM implementation including an SAE J1939 component above the AUTOSAR CAN interface module or the PDU router is provided according to this embodiment.
  • the standard AUTOSAR COM module is not used in the communication stack 20b due to the GB / T-specific CAN communication behavior of the messages, which deviates greatly from an in-vehicle CAN communication behavior.
  • a GB / T specific implementation of a COM module is provided by the
  • the interface specification of the AUTOSAR COM module is implemented in order to maximize the independence of the application from the communication stack according to the GB / T standard create.
  • the China GB / T communication stack 20b is realized as a GB / T-specific COM module.
  • the GB / T-specific COM module is for the
  • the CAN driver 15 is reconfigured by the operating software charging system-specific at runtime or in the initiation phase at the startup time.
  • Fig. 7 shows a further alternative embodiment in which the
  • FIG. 8 shows a schematic flowchart with respect to an example
  • inventive software application that can serve as operating software for a load manager.
  • the software application can be provided, for example, as an AUTOSAR application module (see application layer 13 of FIG.
  • the software application has program instructions which are designed to select and configure the respective communication stack based on the recognition of the respective country variant with consideration of the corresponding driver configuration for the respective charging system.
  • a country variant LV is queried.
  • it is checked if the
  • step 605 is continued.
  • a communication stack having a driver configuration for the CHAdeMO charging system is selected and configured.
  • the charging communication may then be executed according to the selected and configured communication stack, i. according to
  • MCAL Microcontroller Abstraction Layer
  • CDD Complex Device Drivers

Landscapes

  • Engineering & Computer Science (AREA)
  • Power Engineering (AREA)
  • Transportation (AREA)
  • Mechanical Engineering (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Charge And Discharge Circuits For Batteries Or The Like (AREA)
  • Electric Propulsion And Braking For Vehicles (AREA)
  • Communication Control (AREA)

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.
PCT/EP2017/075550 2016-10-13 2017-10-06 Intelligente ladekommunikationsumschaltung bei can-basierten ladesystemen WO2018069192A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN201780063635.8A CN109843637B (zh) 2016-10-13 2017-10-06 基于can的充电***中的智能充电通信切换
JP2019520106A JP2020501479A (ja) 2016-10-13 2017-10-06 Ｃａｎベースの充電システムにおけるインテリジェント充電通信切り替え装置

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102016219940.4A DE102016219940A1 (de) 2016-10-13 2016-10-13 Intelligente Ladekommunikationsumschaltung bei CAN-basierten Ladesystemen
DE102016219940.4 2016-10-13

Publications (1)

Publication Number Publication Date
WO2018069192A1 true WO2018069192A1 (de) 2018-04-19

Family

ID=60153275

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2017/075550 WO2018069192A1 (de) 2016-10-13 2017-10-06 Intelligente ladekommunikationsumschaltung bei can-basierten ladesystemen

Country Status (4)

Country Link
JP (1) JP2020501479A (de)
CN (1) CN109843637B (de)
DE (1) DE102016219940A1 (de)
WO (1) WO2018069192A1 (de)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102018222455A1 (de) 2018-12-20 2020-06-25 Audi Ag Fahrzeugbatterie mit mehreren Batteriemodulen zum Speichern von Energie und mit einem Batteriemanagementsystem
KR20200096732A (ko) * 2019-02-05 2020-08-13 도요타 지도샤（주） 차량의 제어 장치 및 그것을 구비한 차량 그리고 차량의 제어 방법
EP4056412A1 (de) 2021-03-11 2022-09-14 Toyota Jidosha Kabushiki Kaisha Verfahren und vorrichtung zur steuerung des ladevorgangs eines fahrzeugs
CN115503532A (zh) * 2022-08-29 2022-12-23 赛力斯集团股份有限公司 一种应用于电动汽车的充电控制装置和方法
JP7478081B2 (ja) 2019-11-14 2024-05-02 ノイトリーク・アクティエンゲゼルシャフト 電気プラグコネクタ用のコンタクトキャリア及びそのプラグコネクタ

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110602177A (zh) * 2019-08-26 2019-12-20 深圳移航通信技术有限公司 电动自行车通讯的方法、装置及***
CN111762054B (zh) * 2020-08-07 2021-10-01 中国华电科工集团有限公司 一种充电站的管理方法及管理***

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2628630A2 (de) * 2012-02-20 2013-08-21 Eaton Corporation Mehrfachstandardkompatibles EV-Ladegerät
US20140266042A1 (en) * 2013-03-15 2014-09-18 Contour Hardening, Inc. Quick charge system for electric vehicles
JP2016073146A (ja) * 2014-10-01 2016-05-09 株式会社東光高岳 電気移動体用充電装置

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011221803A (ja) * 2010-04-09 2011-11-04 Toyota Motor Corp テストツール、テスト方法
US9071074B2 (en) * 2012-02-20 2015-06-30 Eaton Corporation Multi-standard, alternating current or direct current compatible electric vehicle supply equipment
EP2869075A1 (de) * 2013-11-04 2015-05-06 ABB Technology AG System und Verfahren zur Detektion einer Leckage von Stromkabeln eines Gleichstrombuses nach Masse
CN112026552B (zh) * 2014-09-02 2021-10-01 葛炽昌 电动车的电力维持方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2628630A2 (de) * 2012-02-20 2013-08-21 Eaton Corporation Mehrfachstandardkompatibles EV-Ladegerät
US20140266042A1 (en) * 2013-03-15 2014-09-18 Contour Hardening, Inc. Quick charge system for electric vehicles
JP2016073146A (ja) * 2014-10-01 2016-05-09 株式会社東光高岳 電気移動体用充電装置

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102018222455A1 (de) 2018-12-20 2020-06-25 Audi Ag Fahrzeugbatterie mit mehreren Batteriemodulen zum Speichern von Energie und mit einem Batteriemanagementsystem
KR102628571B1 (ko) * 2019-02-05 2024-01-23 도요타 지도샤（주） 차량의 제어 장치 및 그것을 구비한 차량 그리고 차량의 제어 방법
JP2020127295A (ja) * 2019-02-05 2020-08-20 トヨタ自動車株式会社 車両の制御装置およびそれを備えた車両ならびに車両の制御方法
US11351883B2 (en) 2019-02-05 2022-06-07 Toyota Jidosha Kabushiki Kaisha Control device for vehicle, vehicle, and control method of vehicle
KR102416657B1 (ko) * 2019-02-05 2022-07-04 도요타 지도샤（주） 차량의 제어 장치 및 그것을 구비한 차량 그리고 차량의 제어 방법
KR20220093071A (ko) * 2019-02-05 2022-07-05 도요타 지도샤（주） 차량의 제어 장치 및 그것을 구비한 차량 그리고 차량의 제어 방법
JP7172676B2 (ja) 2019-02-05 2022-11-16 トヨタ自動車株式会社 車両の制御装置およびそれを備えた車両ならびに車両の制御方法
KR20200096732A (ko) * 2019-02-05 2020-08-13 도요타 지도샤（주） 차량의 제어 장치 및 그것을 구비한 차량 그리고 차량의 제어 방법
US11912152B2 (en) 2019-02-05 2024-02-27 Toyota Jidosha Kabushiki Kaisha Control device for vehicle, vehicle, and control method of vehicle
JP7478081B2 (ja) 2019-11-14 2024-05-02 ノイトリーク・アクティエンゲゼルシャフト 電気プラグコネクタ用のコンタクトキャリア及びそのプラグコネクタ
EP4056412A1 (de) 2021-03-11 2022-09-14 Toyota Jidosha Kabushiki Kaisha Verfahren und vorrichtung zur steuerung des ladevorgangs eines fahrzeugs
CN115503532A (zh) * 2022-08-29 2022-12-23 赛力斯集团股份有限公司 一种应用于电动汽车的充电控制装置和方法
CN115503532B (zh) * 2022-08-29 2024-04-12 赛力斯集团股份有限公司 一种应用于电动汽车的充电控制装置和方法

Also Published As

Publication number Publication date
DE102016219940A1 (de) 2018-04-19
CN109843637B (zh) 2022-08-26
JP2020501479A (ja) 2020-01-16
CN109843637A (zh) 2019-06-04

Similar Documents

Publication Publication Date Title
WO2018069192A1 (de) Intelligente ladekommunikationsumschaltung bei can-basierten ladesystemen
DE112017003140B4 (de) Fahrzeugstromkreiskörper
DE112009001289B4 (de) Kommunikationsvorrichtung, Kommunikationssystem und Kommunikationsverfahren
EP2789106B1 (de) Netzwerk-komponente für ein fahrzeug-netzwerk und entsprechendes fahrzeug-netzwerk
DE102018103187A1 (de) Erweitertes zentrales Gateway zur Fahrzeugvernetzung
DE102016211335A1 (de) Elektrisches Aufladen von Elektrofahrzeugen mittels Adapter zur Signalwandlung
DE102013223704A1 (de) Fahrzeug mit einem Ethernet-Bussystem und Verfahren zum Betreiben eines solchen Bussystems
DE102014226875A1 (de) Netzwerksystem für Fahrzeug und Datenübertragungsverfahren heterogener Kommunikationscontroller in dem gleichen System
DE102015214915B4 (de) Flexibles Scheduling-Verfahren und Scheduling-Vorrichtung bei einer LIN-Kommunikation
DE112017006750T5 (de) Schaltvorrichtung, Kommunikationssteuerverfahren und Kommunikationssteuerprogramm
CN203911981U (zh) 一种汽车控制器局域网络的网关设备的***电路及汽车
EP3616977A1 (de) Ladekabel für ein elektrofahrzeug
DE102019209218A1 (de) Verfahren und Vorrichtung zur Synchronisation von Kommunikationsknoten unter Verwendung mehrerer Bereiche in einem Fahrzeugnetzwerk
DE102012223530B4 (de) Dynamische Leitungsterminierung von Kommunikationsbussen in Überwachungsschaltungen für Batteriemodule sowie ein Verfahren zur Durchführung der Leitungsterminierung bei der Initialisierung des Überwachungssystems
DE102017127284A1 (de) Betriebsverfahren eines Kommunikationsknotens zur Zeitsynchronisation im Fahrzeugnetzwerk
DE102023107659A1 (de) Unleugbarer verlauf von fahrzeugänderungen
DE102013221580A1 (de) Kopplungsvorrichtung und Verfahren zum Betreiben einer Kopplungsvorrichtung
DE112018006313T5 (de) Fahrzeuginterne relaisvorrichtung
DE102016217065A1 (de) Konformität-testgerät und -verfahren für einen kommunikationsknoten
BE1029123B1 (de) Ladedose mit fahrzeuginternem Datenbusanschluss
DE102019004206A1 (de) Ladesystem fur ein elektrisch betreibbares Fahrzeug
EP1163778B1 (de) Schaltungsanordnung und verfahren zur konfiguration einer schnittstelle von einer steuerungs- oder regelungseinrichtung
EP2824003A2 (de) Verfahren zum Ausrüsten eines Fahrzeugs mit einem Steuergerät
DE102021103839A1 (de) Ladedose mit fahrzeuginternem Datenbusanschluss
DE102017115775A1 (de) Fahrzeug-Bord-Steuervorrichtung

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17787357

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2019520106

Country of ref document: JP

Kind code of ref document: A

122 Ep: pct application non-entry in european phase

Ref document number: 17787357

Country of ref document: EP

Kind code of ref document: A1