EP3921203A1 - Ladesystem zum laden von elektrofahrzeugen - Google Patents

Ladesystem zum laden von elektrofahrzeugen

Info

Publication number
EP3921203A1
EP3921203A1 EP20702627.9A EP20702627A EP3921203A1 EP 3921203 A1 EP3921203 A1 EP 3921203A1 EP 20702627 A EP20702627 A EP 20702627A EP 3921203 A1 EP3921203 A1 EP 3921203A1
Authority
EP
European Patent Office
Prior art keywords
charging
microservice
service
charging system
implemented
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP20702627.9A
Other languages
English (en)
French (fr)
Inventor
Stephan CATER
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
CCS Abwicklungs AG
Original Assignee
Innogy SE
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 Innogy SE filed Critical Innogy SE
Publication of EP3921203A1 publication Critical patent/EP3921203A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • 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
    • 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/30—Constructional details of charging stations
    • B60L53/305—Communication interfaces
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02T—CLIMATE CHANGE MITIGATION TECHNOLOGIES RELATED TO TRANSPORTATION
    • Y02T10/00—Road transport of goods or passengers
    • Y02T10/60—Other road transportation technologies with climate change mitigation effect
    • Y02T10/70—Energy storage systems for electromobility, e.g. batteries
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02T—CLIMATE CHANGE MITIGATION TECHNOLOGIES RELATED TO TRANSPORTATION
    • Y02T10/00—Road transport of goods or passengers
    • Y02T10/60—Other road transportation technologies with climate change mitigation effect
    • Y02T10/7072—Electromobility specific charging systems or methods for batteries, ultracapacitors, supercapacitors or double-layer capacitors
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02T—CLIMATE CHANGE MITIGATION TECHNOLOGIES RELATED TO TRANSPORTATION
    • Y02T90/00—Enabling technologies or technologies with a potential or indirect contribution to GHG emissions mitigation
    • Y02T90/10—Technologies relating to charging of electric vehicles
    • Y02T90/12—Electric charging stations
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02T—CLIMATE CHANGE MITIGATION TECHNOLOGIES RELATED TO TRANSPORTATION
    • Y02T90/00—Enabling technologies or technologies with a potential or indirect contribution to GHG emissions mitigation
    • Y02T90/10—Technologies relating to charging of electric vehicles
    • Y02T90/14—Plug-in electric vehicles
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02T—CLIMATE CHANGE MITIGATION TECHNOLOGIES RELATED TO TRANSPORTATION
    • Y02T90/00—Enabling technologies or technologies with a potential or indirect contribution to GHG emissions mitigation
    • Y02T90/10—Technologies relating to charging of electric vehicles
    • Y02T90/16—Information or communication technologies improving the operation of electric vehicles

Definitions

  • the application relates to a charging system for charging electric vehicles, comprising at least one back-end system with at least one charging control application, set up to control a plurality of at least one
  • the application also relates to a front-end system for a charging system and a method for operating a charging system.
  • Known charging systems include a backend system and usually a large number of charging stations.
  • a charging station is set up for charging electric vehicles.
  • a charging station can be used in a conventional manner via the required
  • Charging technology and at least one charging connection like a fixed
  • Charging cable During a charging process, electrical power can then be exchanged between the charging station and an electric vehicle connected via a charging cable.
  • an electrical storage device e.g.
  • a loading control application is implemented in the jaw system, for example on a processing unit such as a server.
  • a processing unit such as a server.
  • a charge control application is the eOperate system from Innogy SE.
  • Implemented charging system services that are required when operating a charging system and are used, for example, as part of a charging process at a charging station.
  • an authentication service, a load management service, a payment service, a software update service, etc. can be implemented monolithically as charging system services in the charging control application.
  • Such a charging control application can in particular be used by a large number of charging stations (simultaneously). This can result in a significant temporary load on the charging control application, even if this is only due to a high load on a specific charging system service. This then requires a considerable scaling of the entire charge control application.
  • Charging system service of the charging control application leads to a temporary failure of the entire charging control application.
  • the application is therefore based on the object of providing a charging system for charging electric vehicles which at least reduces the downtime of the charging system and in particular improves the scalability of the charging control application.
  • the task is achieved by a charging system for charging
  • the charging system comprises at least one back-end system with at least one charging control application.
  • the charging control application is set up to control a plurality of charging stations that can be connected to the backend system via at least one communication network.
  • the backend system there is a first charging system service
  • Charging control application implemented in the form of a first microservice. At least one further charging system service is in the backend system
  • Load control application implemented in the form of another microservice.
  • the downtime of a charging system is at least reduced and the scalability of the charging control application is improved by implementing the at least two (different) charging control services of the charging control application in the form of microservices.
  • a first microservice can be maintained and thus temporarily not available, while the at least one additional microservice can is still available and can be used.
  • microservices can be scaled independently of one another.
  • the charging system comprises at least one backend system.
  • the backend system comprises at least one physical processing unit (e.g. in the form of a server), preferably a plurality of distributed physical processing units (e.g. in the form of networked physical processing units).
  • a charging control application in the form of by the processing unit (in particular at least one processor of the
  • Computing unit executable software implemented.
  • the charging system comprises a plurality of
  • the charging station comprises at least one charging connection configured to deliver electrical power.
  • the charging connection can preferably also be set up to receive electrical power.
  • the charging connection can in particular be an electrical interface, for example in the form of a firmly attached charging cable with a charging plug or a charging socket or in the form of a charging plug or a charging socket for connecting a separate charging cable (e.g. a charging plug receptacle,
  • a firmly attached charging cable is to be understood in particular to mean that a user cannot separate the charging cable from the charging device without destroying it.
  • the charging station can comprise a charging device, which can have components in a conventional manner in order to enable a current flow from a power source (for example a public power grid, energy generator, etc.) via the charging connection and a charging cable.
  • a power source for example a public power grid, energy generator, etc.
  • an electric vehicle in particular its electrical energy store, can be charged (or discharged).
  • an electric vehicle is to be understood as a vehicle which can be operated at least partially electrically and which includes a rechargeable electrical storage device (for example a traction battery).
  • the charging device can be integrated in the charging station or designed as a “wallbox”. In particular, the charging device can be part of the charging station.
  • the charging device, in particular the components or the charging technology can also be integrated in a wall or a floor. It goes without saying that a bidirectional current or power transmission can take place via the charging cable and the charging technology of the charging device.
  • the charge control application according to the application comprises at least two
  • the charging system services are used in particular to operate the charging system.
  • a charging system service is in particular made available to other entities and can be used or claimed by them. In other words, a certain functionality of the charging control application is mapped by a charging system service.
  • An authentication service can be used as charging system services
  • Billing service compliant with calibration law etc. must be implemented in the charging control application.
  • At least two charging system services are formed in the form of microservices.
  • the charging system service is (largely) decoupled from the at least one other charging system service implemented as a microservice and, in particular, performs its corresponding (individual) task independently of the other microservices.
  • microservices By using microservices, a modular structure of the
  • the first microservice can have a first interface with a first
  • Microservice can have another interface with another
  • each microservice can have a (data) interface with a communication address that is preferably unique in the charging system.
  • the associated charging system service can be used (or controlled) via the interface.
  • a standard interface can be provided as the interface.
  • an interface can hide the implementation details of the respective microservice. This makes it possible to implement the
  • the first microservice can be implemented in a first programming language and the further microservice in a further programming language.
  • the respective charging system service can nevertheless be used in a simple manner by a further entity due to the interface provided in each case.
  • the first microservice can be implemented on at least one first physical computing unit.
  • the first microservice can also run on a
  • a plurality of first computing units can be implemented.
  • the at least one further microservice can be implemented on at least one further physical computing unit independent of the at least one first computing unit.
  • the other microservice can also be based on a number of other
  • Microservice be implemented, while another charging system service, in which no safety-relevant data is processed, is implemented on another
  • Security level can be implemented as a further microservice.
  • the safety effort in the charging system can be reduced overall.
  • unauthorized access to the security-relevant data is made more difficult because of the separate processing units.
  • the first physical computing unit can be independent of the further physical
  • Computing unit (and preferably vice versa) be scalable.
  • an increase in resources to increase performance can be individual for each microservice
  • Charge control application must be scaled up, as is required in a monolithic application according to the prior art.
  • the backend system can comprise at least one load control module (for example in the form of a load balancer).
  • the load control module can be set up to record the (instantaneous) load of at least one physical processing unit and / or at least one microservice.
  • the load control module can be configured to scale the at least one physical one
  • Computing unit (and / or the corresponding microservice) based on the recorded (instantaneous) (computing) load of the at least one
  • Scaling is to be understood in particular as increasing or decreasing the performance of a physical computing unit and / or a microservice.
  • microservices that have high load fluctuations occur, be implemented in a cloud.
  • a cloud provides a high level of scalability.
  • the in the backend system can be in the form of
  • Microservices implemented charging system services are made available to other entities for use.
  • an entity can use the at least two charging system services to complete a specific task or several specific tasks.
  • the charging system can comprise at least one front-end system.
  • An entity can, for example, comprise or form the front-end system.
  • the front-end system can preferably include at least one routing module.
  • the routing module can be set up to cause a first service request to be sent to the first microservice for the use of the first charging system service, based on a received charging action request and a charging action assignment table
  • Routing module be set up to cause a further service request to be sent to the at least one further microservice for the use of the at least one further charging system service, based on a received charging action request and the charging action assignment table.
  • the charging action request can, for example, be based on a user action and require the execution of a specific task or functionality, which is implemented by a charging system service in the backend system, which is mapped as a microservice
  • a user can initiate a loading process which, for example, initially requires an authentication service to be carried out. If the front-end system detects a corresponding charging action request, the routing module can generate a corresponding service request, in the present example an authentication service request, in particular and its
  • Authentication service is implemented, effect.
  • a loading action assignment table can be stored in the front-end system.
  • Charging action requests and the charging system services required for this must be saved.
  • the respective (one-to-one) communication addresses of the respectively assigned interfaces of the microservices can additionally be stored in a charging action assignment table. This enables the routing module to send a service request to the interface of the associated (correct) charging system service or microservice.
  • the first service request by at least a first
  • Data message be formed, comprising at least the first communication address (in the header of the service message) and service user data.
  • an authentication service request (especially in the header of the message) can contain the communication address of the interface of the
  • Authentication service and, as service user data, at least the authentication data to be checked e.g. user name and / or password and / or
  • Data messages can be formed and in particular sent to
  • the authentication service can then check the authentication data received via the assigned interface in a conventional manner (regardless of other microservices).
  • the authentication data can be stored with (in a storage unit of the physical processing unit on which the
  • Authentication service is implemented as a microservice
  • the first charging process is enabled, in particular by sending a
  • Release message is effected to the corresponding charging station to be released. If the result of the check is negative, the charging process is blocked,
  • a blocking message is transmitted to the charging station or no release message is transmitted.
  • other charging system services (described above) can be carried out in a conventional manner.
  • At least one charging station can have the front-end system, which is formed in particular from hardware and / or software.
  • the charging system can comprise at least one mobile user terminal. The at least one mobile user terminal can advise the front-end system, in particular from
  • a front-end system can preferably have at least one connection to at least one user interface (e.g. keyboard, keys, touch display, RFID module, NFC module, card module, etc.) and / or at least one connection to at least one communication module (e.g. controller with antenna ) have and / or comprise a user interface and / or a communication module.
  • at least one user interface e.g. keyboard, keys, touch display, RFID module, NFC module, card module, etc.
  • at least one communication module e.g. controller with antenna
  • the front-end system comprises at least one communication connection to a user interface, set up to generate at least one charging action request.
  • a previously described charging action request can be generated or received based on a user input.
  • a charging process can be initiated as a charging action request via the user interface, which (conventionally) requires the completion of at least one charging system service or a charging system task.
  • the front-end system comprises at least one (in particular previously described) routing module.
  • the routing module is set up to cause a first service request to be sent to a first microservice to use a first charging system service, based on a received charging action request and a charging action allocation table, the first charging system service of a charging control application being implemented in a back-end system in the form of the first microservice.
  • the front-end system can be installed, for example, as an executable application (app) on a mobile user terminal and can be executed by the latter.
  • the front-end system can also be installed, for example, as an executable application in a charging station and can be executed by the latter.
  • a mobile user terminal is in particular a smartphone
  • Yet another aspect of the application is a method for operating a charging system comprising a backend system with at least one
  • Charge control application configured to control a plurality of over
  • At least one communication network can be connected to the backend system
  • Charging stations with a first (in particular previously described) charging system service of the charging control application being implemented in the form of a first microservice in the backend system.
  • the procedure includes:
  • Charging system can be used.
  • Fig. 1 is a schematic view of an embodiment of a
  • Fig. 2 is a schematic view of a further embodiment of a
  • FIG. 3 shows a diagram of an exemplary embodiment of a method according to the present application.
  • FIG. 1 shows a schematic view of an exemplary embodiment of a
  • the charging system 100 comprises a backend system 102 and a plurality of charging stations 104.
  • the charging stations 104 can be connected to the backend system 102 via a (wireless and / or wired) communication network 118.
  • a charging station 104 has at least one charging connection that has a
  • Charging cable 108 can be coupled to a charging connection of an electric vehicle 106 in order to charge the electric vehicle 106 or its rechargeable battery.
  • the backend system 102 is formed by at least one physical processing unit (e.g. a server). At least one charging control application 103 is implemented on the at least one processing unit. The (modular) charging control application 103 is set up to control a plurality of charging stations 104 that can be connected to the backend system 102 via the at least one communication network 118. This is to be understood in particular as the charging control application 103 providing at least two (different) charging system services 110, 112 for the operation of the Charging system 100 provides.
  • a charging system service 110, 112 is set up, in particular, to take over (precisely) a specific task of the charging system 100 and in particular to carry it out.
  • the first charging system service 110 is an authentication service 110 and the further charging system service 112 is a load management service 112. It goes without saying that further (or different)
  • Charging system services such as a payment service, a software update service
  • Billing service compliant with calibration law, etc. can be implemented in the charging control application.
  • the first charging system service 110 is the
  • the charging control application 103 is implemented in the form of a first microservice 110 and at least the at least one further charging system service 112 of the charging control application 103 is implemented in the backend system 102 in the form of a further microservice 112.
  • precisely one first interface 114 with a first communication address is clearly assigned to the first microservice 110.
  • the first microservice 110 can only be used via the first interface 114.
  • a further interface 116 with a further communication address can be assigned to the at least one further microservice 112.
  • the further microservice 112 can only be used via the further interface 116.
  • Each interface 114, 116 preferably has one that is unique in the charging system 100
  • a charging station 104 can preferably be a
  • Front end system 120 include.
  • the front end system 120 includes, in particular, a routing module 124.
  • a front end system 120 can use a
  • User interface 122 e.g. a keypad, a near-field interface (e.g. NFC, RFID or Bluetooth module) and a communication module 126 or at least be connectable to a user interface 122 and a communication module 126 via at least one connection each.
  • the mode of operation will be described below.
  • FIG. 2 shows a schematic view of a further exemplary embodiment of a charging system 200 according to the present application.
  • the first microservice 210 (and the associated interface 214) is implemented in the present exemplary embodiment on at least one first physical computing unit 230 and can be executed by this.
  • the further microservice 212 (and the associated interface 216) is implemented in the present exemplary embodiment on at least one further physical computing unit 232 and can be executed by this.
  • the two physical computing units 230, 232 are in particular independent or decoupled from one another.
  • the backend system 202 in the present case comprises a load control module 234.
  • the load control module 234 is set up in particular to detect the
  • Load control module 234 can also be set up to scale at least the first physical computing unit 230 and / or the first microservice 210 and the further physical computing unit 232 and / or the further microservice 212, based on the detected (instantaneous) load on the at least one physical computing unit and / or the at least one microservice.
  • a front-end system 220 has in each case a charging action assignment table 236.
  • a further front-end system 240 having a routing module 244 and a charging action assignment table 248, is implemented on a mobile user terminal 238 (e.g. a smartphone).
  • the front-end system 240 can in particular be an application (app) that can be installed on the user terminal 238.
  • the front-end system 240 comprises at least one connection to at least one user interface 242 (e.g. touch display of the terminal 238), set up to generate at least one charging action request, and preferably at least one connection to one
  • a communication module 226, 248 is set up in particular to communicate with the backend system 202 via the communication network 218.
  • FIG. 3 shows a diagram of an exemplary embodiment of a method according to the present application.
  • the front-end system 220, 238, in particular via the at least one user interface 222, 242 can receive a charging action request.
  • the following is an example for the better
  • a charging process initiation request which can be based in particular on at least one user action by which the user would like to start a charging process at a charging station 204 for charging his electric vehicle.
  • receipt of such a charging action request can be detected.
  • the routing module 224, 244 can receive the
  • the routing module 224, 244 can determine which at least one charging system service requires the charging operation initiation request.
  • Loading action allocation table 236, 248 can be stored in a simple manner, the routing module 224, 244 can determine the at least one required loading system service. It goes without saying that further charging system services, for example a load management service, etc., are required in the case of a charging process initiation request can. For the sake of clarity, only the implementation of the authentication service is described in more detail in the present example.
  • the routing module 224, 244 can preferably create at least one service request, in this case an authentication service request,
  • the data message can be the communication address of the first interface 214 implemented as the first microservice 210 in the backend system 202
  • Authentication service 210 have. In particular, in the
  • Load action allocation table 236, 248 the communication address associated with the authentication service must be stored.
  • a data message can receive at least part of the service payload data
  • the authentication data can be received via the user interface 222, 242, for example.
  • the routing module 224, 244 sends the
  • Authentication service request in particular the at least one data message, via the communication network 218 to the corresponding microservice 210 or the interface 214 associated with this microservice 210.
  • the routing module 224, 244 can control the at least one communication module 226, 246 accordingly and send the at least one Effect data message.
  • the microservice 210 can be executed, in particular based on the received user data in the form of the user's authentication data.
  • the first microservice 210 can be executed by the computing unit 230.
  • the authorization of the user to carry out a loading process based on the received authentication data and user authentication data that is to say in particular previously stored authentication data from registered Users to be checked.
  • user accounts or corresponding user data can be stored in the processing unit 230 and / or a database to which the
  • Computing unit 230 or microservice 210 can access, be stored.
  • User name and password While other user data, such as account data, which are required, for example, for billing the charging process, but not for an authentication process, are not in the database of the processing unit 230 and / or the database to which the processing unit 230 or the microservice access 210 can access are stored.
  • the check in step 304 can, for example, compare the received user name and the associated password with the stored ones
  • step 305 microservice 210 can in particular send a release message to release the charging process to the corresponding charging station 204 in the event of a positive
  • microservice 210 and / or the physical computing unit 230 can be recorded by load control module 234.
  • the microservice 210 and / or the physical computing unit 230 can be designed to be scalable.
  • load control module 234 can scale the load or load on microservice 210 and / or physical computing unit 230
  • Microservice 210 and / or the physical processing unit 230 an increase or decrease in the performance of the microservice 210 and / or the physical processing unit 230.

Landscapes

  • Engineering & Computer Science (AREA)
  • Power Engineering (AREA)
  • Transportation (AREA)
  • Mechanical Engineering (AREA)
  • Charge And Discharge Circuits For Batteries Or The Like (AREA)

Abstract

Die Anmeldung betrifft ein Ladesystem (100, 200) zum Laden von Elektrofahrzeuge (108), umfassend mindestens ein Backendsystem (102, 202) mit mindestens einer Ladesteueranwendung (103, 203), eingerichtet zum Steuern einer Mehrzahl von über mindestens ein Kommunikationsnetz (118, 218) mit dem Backendsystem (102, 202) verbindbaren Ladestationen (104, 204), wobei in dem Backendsystem (102, 202) ein erster Ladesystemdienst (110, 210) der Ladesteueranwendung (103, 203) in Form eines ersten Microservice (110, 210) implementiert ist, und wobei in dem Backendsystem (102, 202) zumindest ein weiterer Ladesystemdienst (112, 212) der Ladesteueranwendung (103, 203) in Form eines weiteren Microservice (112, 212) implementiert ist.

Description

Ladesystem zum Laden von Elektrofahrzeugen
Die Anmeldung betrifft ein Ladesystem zum Laden von Elektrofahrzeugen, umfassend mindestens ein Backendsystem mit mindestens einer Ladesteueranwendung, eingerichtet zum Steuern einer Mehrzahl von über mindestens ein
Kommunikationsnetz mit dem Backendsystem verbindbaren Ladestationen. Darüber hinaus betrifft die Anmeldung ein Frontendsystem für ein Ladesystem und ein Verfahren zum Betreiben eines Ladesystems.
Bekannte Ladesysteme umfassen ein Backendsystem und in der Regel eine Vielzahl an Ladestationen. Eine Ladestation ist eingerichtet zum Laden von Elektrofahrzeugen. Hierzu kann eine Ladestation in herkömmlicher Weise über die erforderliche
Ladetechnik und mindestens einen Ladeanschluss verfügen, wie ein fest
angeschlagenes Ladekabel oder eine Ladesteckerbuchse zum Koppeln eines
Ladekabels. Während eines Ladevorgangs kann dann elektrische Leistung zwischen der Ladestation und einem über ein Ladekabel angeschlossenes Elektrofahrzeug ausgetauscht werden. Insbesondere kann ein elektrischer Speicher (z.B.
Traktionsbatterie des Elektrofahrzeugs) geladen werden. ln bekannten Ladesystemen ist in dem Backensystem eine Ladesteueranwendung implementiert, beispielsweise auf einer Recheneinheit, wie einem Server. Ein Beispiel einer solchen Ladesteueranwendung ist das eOperate-System der Firma Innogy SE. ln einer derartigen Ladesteueranwendung ist eine Vielzahl von monolithischen
Ladesystemdiensten implementiert, die bei einem Betrieb eines Ladesystems benötigt und beispielsweise im Rahmen eines Ladevorgangs an einer Ladestation genutzt werden. Als Ladesystemdienste können beispielsweise ein Authentifizierungsdienst, ein Lastmanagementdienst, ein Bezahldienst, ein Softwareupdatedienst etc. in der Ladesteueranwendung monolithisch implementiert sein. Eine derartige Ladesteueranwendung kann insbesondere von einer Vielzahl von Ladestationen (gleichzeitig) genutzt werden. Hierdurch kann es zu einer erheblichen temporären Belastung der Ladesteueranwendung kommen, auch wenn dies nur auf eine hohe Auslastung eines bestimmten Ladesystemdiensts zurückzuführen ist. Dies erfordert dann eine erhebliche Skalierung der gesamten Ladesteueranwendung.
Ferner kommt es während einer Aktualisierung oder Wartung eines
Ladesystemdienstes der Ladesteueranwendung zu einem temporäreren Ausfall der gesamten Ladesteueranwendung.
Daher liegt der Anmeldung die Aufgabe zugrunde, ein Ladesystem zum Laden von Elektrofahrzeugen bereitzustellen, welches die Ausfallzeiten des Ladesystems zumindest reduziert und insbesondere die Skalierbarkeit der Ladesteueranwendung verbessert.
Die Aufgabe wird anmeldungsgemäß durch ein Ladesystem zum Laden von
Elektrofahrzeugen nach Anspruch 1 gelöst. Das Ladesystem umfasst mindestens ein Backendsystem mit mindestens einer Ladesteueranwendung. Die
Ladesteueranwendung ist eingerichtet zum Steuern einer Mehrzahl von über mindestens ein Kommunikationsnetz mit dem Backendsystem verbindbaren Ladestationen ln dem Backendsystem ist ein erster Ladesystemdienst der
Ladesteueranwendung in Form eines ersten Microservice implementiert ln dem Backendsystem ist zumindest ein weiterer Ladesystemdienst der
Ladesteueranwendung in Form eines weiteren Microservice implementiert.
Im Gegensatz zum Stand der Technik ist erkannt worden, dass die Ausfallzeit eines Ladesystems zumindest reduziert und die Skalierbarkeit der Ladesteueranwendung verbessert wird, indem die mindestens zwei (verschiedenen) Ladesteuerdienste der Ladesteueranwendung in Form von Microservices implementiert sind. So kann ein erster Microservice beispielsweise gewartet werden und somit temporär nicht zur Verfügung stehen, während der mindestens eine weitere Microservice jedoch weiterhin zur Verfügung steht und genutzt werden kann. Darüber hinaus sind Microservices unabhängig voneinander skalierbar.
Das anmeldungsgemäße Ladesystem umfasst mindestens ein Backendsystem. Das Backendsystem umfasst mindestens eine physikalische Recheneinheit (z.B. in Form eines Servers), vorzugsweise eine Mehrzahl von verteilt angeordneten physikalischen Recheneinheiten (z.B. in Form von vernetzten physikalischen Recheneinheiten). Auf der mindestens einen Recheneinheit ist eine Ladesteueranwendung in Form von durch die Recheneinheit (insbesondere mindestens einen Prozessor der
Recheneinheit) ausführbarer Software implementiert.
Ferner umfasst das anmeldungsgemäße Ladesystem eine Mehrzahl von
Ladestationen. Die anmeldungsgemäße Ladestation umfasst mindestens einen Ladeanschluss, eingerichtet zum Abgeben von elektrischer Leistung. Vorzugsweise kann der Ladeanschluss auch zur Aufnahme von elektrischer Leistung eingerichtet sein. Der Ladeanschluss kann insbesondere eine elektrische Schnittstelle sein, beispielsweise in Form eines fest angeschlagenen Ladekabels mit einem Ladestecker oder einer Ladebuchse oder in Form eines Ladesteckers oder einer Ladebuchse zum Anschließen eines separaten Ladekabels (z.B. eine Ladesteckeraufnahme,
beispielsweise in Form einer Ladesteckerbuchse). Unter einem fest angeschlagenen Ladekabel ist insbesondere zu verstehen, dass ein Nutzer das Ladekabel nicht zerstörungsfrei von der Ladevorrichtung trennen kann.
Die Ladestation kann eine Ladevorrichtung umfassen, die in herkömmlicher Weise über Komponenten verfügen kann, um einen Stromfluss von einer Stromquelle (z.B. ein öffentliches Stromnetz, Energieerzeuger etc.) über den Ladeanschluss und einem Ladekabel zu ermöglichen. Hierdurch kann ein elektrisch betriebenes Fahrzeug bzw. Elektrofahrzeug, insbesondere dessen elektrischen Energiespeicher, geladen (oder entladen) werden. Unter einem Elektrofahrzeug ist vorliegend ein Fahrzeug zu verstehen, das zumindest teilweise elektrisch betrieben werden kann und einen wiederaufladbaren elektrischen Speicher (z.B. Traktionsbatterie) umfasst. Die Ladevorrichtung kann in der Ladestation integriert oder als„Wallbox“ gebildet sein. Insbesondere kann die Ladevorrichtung ein Teil der Ladestation sein. Auch kann die Ladevorrichtung, insbesondere die Komponenten bzw. die Ladetechnik, in einer Wand oder einem Boden integriert sein. Es versteht sich, dass eine bidirektionale Strom- bzw. Leistungsübertragung über die Ladekabel und die Ladetechnik der Ladevorrichtung erfolgen kann.
Die anmeldungsgemäße Ladesteueranwendung umfasst mindestens zwei
(verschiedene) Ladesystemdienste. Die Ladesystemdienste dienen insbesondere dem Betreiben des Ladesystems. Ein Ladesystemdienst wird hierbei insbesondere anderen Entitäten zur Verfügung gestellt und kann von diesen genutzt bzw. in Anspruch genommen werden. Anders ausgedrückt wird durch einen Ladesystemdienst eine bestimmte Funktionalität der Ladesteueranwendung abgebildet.
Als Ladesystemdienste können beispielsweise ein Authentifizierungsdienst, ein Lastmanagementdienst, ein Bezahldienst, ein Softwareupdatedienst, ein
eichrechtskonformer Abrechnungsdienst etc. in der Ladesteueranwendung implementiert sein.
Anmeldungsgemäß ist vorgesehen, dass mindestens zwei Ladesystemdienste, vorzugsweise sämtliche Ladesystemdienste der Ladesteueranwendung, in Form von Microservices gebildet sind. Ein durch einen Microservice implementierter
Ladesystemdienst ist (weitgehend) entkoppelt von dem mindestens einen weiteren als Microservice implementierter Ladesystemdienst und erledigt insbesondere seine entsprechende (einzelne) Aufgabe unabhängig von den anderen Microservices. Durch die Verwendung von Microservices kann ein modularer Aufbau der
Ladesteueranwendung (im Gegensatz zu dem aus dem Stand der Technik bekannten monolithischen Aufbau) bereitgestellt werden. Gemäß einer ersten Ausführungsform des anmeldungsgemäßen Ladesystems kann dem ersten Microservice eine erste Schnittstelle mit einer ersten
Kommunikationsadresse zugeordnet sein. Dem mindestens einen weiteren
Microservice kann eine weitere Schnittstelle mit einer weiteren
Kommunikationsadresse zugeordnet sein, die sich insbesondere von der ersten Kommunikationsadresse unterscheidet. Insbesondere kann jeder Microservice über eine (Daten) -Schnittstelle verfügen, mit einer in dem Ladesystem vorzugsweise eineindeutigen Kommunikationsadresse. Über die Schnittstelle kann der jeweils zugehörige Ladesystemdienst genutzt (bzw. angesteuert) werden.
Als Schnittstelle kann eine Standard-Schnittstelle vorgesehen sein. Eine Schnittstelle kann insbesondere die Implementierungsdetails des jeweiligen Microservice verbergen. Hierdurch ist es möglich, den jeweils zu implementierenden
Ladesystemdienst in der jeweils geeigneten Programmiersprache umzusetzen.
Beispielsweise können der erste Microservice in einer ersten Programmiersprache und der weitere Microservice in einer weiteren Programmiersprache implementiert sein. Durch die jeweils vorgesehene Schnittstelle kann der jeweilige Ladesystemdienst dennoch in einfacher Weise von einer weiteren Entität genutzt werden.
Gemäß einer besonders bevorzugten Ausführungsform des anmeldungsgemäßen Ladesystems kann der erste Microservice auf mindestens einer ersten physikalischen Recheneinheit implementiert sein. Der erste Microservice kann auch auf einer
Mehrzahl von ersten Recheneinheiten implementiert sein. Der mindestens eine weitere Microservice kann auf mindestens einer von der mindestens einen ersten Recheneinheit unabhängigen weiteren physikalischen Recheneinheit implementiert sein. Auch der weitere Microservice kann auf einer Mehrzahl von weiteren
Recheneinheiten implementiert sein. Hierdurch wird auch eine physikalische
Entkopplung der mindestens zwei Microservices bereitgestellt.
Vorzugsweise kann ein erster Ladesystemdienst, bei dem vertrauliche Daten, beispielsweise Nutzerdaten, wie Nutzername, Passwort, Kontodaten etc., verarbeitet werden, auf einer ersten Recheneinheit mit einem hohen Sicherheitslevel als
Microservice implementiert sein, während ein weiterer Ladesystemdienst, bei dem keine sicherheitsrelevanten Daten verarbeitet werden, auf einer weiteren
Recheneinheit mit einem im Vergleich zu ersten Recheneinheit geringerem
Sicherheitslevel als weiterer Microservice implementiert sein kann. Zum einen ist der Vorteil, dass der Sicherheitsaufwand in dem Ladesystem insgesamt reduziert werden kann. Zum anderen wird aufgrund der separaten Recheneinheiten ein unerlaubter Zugriff auf die sicherheitsrelevanten Daten erschwert.
Ferner kann, gemäß einer bevorzugten Ausführungsform des Ladesystems, die erste physikalische Recheneinheit unabhängig von der weiteren physikalischen
Recheneinheit (und vorzugsweise umgekehrt) skalierbar sein. So kann eine Erhöhung der Ressourcen zur Leistungssteigerung individuell für jeden Microservice
vorgenommen werden. Hierdurch wird insbesondere verhindert, dass bei einer hohen Belastung eines einzelnen Microservice die gesamte Infrastruktur und/oder
Ladesteueranwendung hoch skaliert werden muss, wie es bei einer monolithischen Anwendung gemäß dem Stand der Technik erforderlich ist.
Gemäß einer weiteren Ausführungsform des anmeldungsgemäßen Ladesystems kann das Backendsystem mindestens ein Laststeuerungsmodul (beispielsweise in Form eines load balancer) umfassen. Das Laststeuerungsmodul kann eingerichtet sein zum Erfassen der (augenblicklichen) Belastung von mindestens einer physikalischen Recheneinheit und/oder mindestens einem Microservice. Das Laststeuerungsmodul kann eingerichtet sein zum Skalieren der mindestens einen physikalischen
Recheneinheit (und/oder des entsprechenden Microservice), basierend auf der erfassten (augenblicklichen) (Rechen-) Belastung der mindestens einen
physikalischen Recheneinheit und/oder des mindestens einen Microservice. Unter Skalieren ist insbesondere ein Erhöhen oder Verringern der Leistungsfähigkeit einer physikalischen Recheneinheit und/oder eines Microservice zu verstehen.
Beispielsweise können Mikroservices, bei denen hohe Belastungsschwankungen auftreten, in einer Cloud implementiert sein. Eine Cloud stellt eine hohe Skalierbarkeit bereit.
Wie bereits beschrieben wurde, können die im Backendsystem in Form von
Microservices implementierten Ladesystemdienste anderen Entitäten zur Nutzung zur Verfügung gestellt werden. Anders ausgedrückt kann eine Entität zur Erledigung einer bestimmten Aufgabe oder mehrerer bestimmter Aufgabe die mindestens zwei Ladesystemdienste nutzen.
Das Ladesystem kann, gemäß einer bevorzugten Ausführungsform, mindestens ein Frontendsystem umfassen. Eine Entität kann beispielsweise das Frontendsystem umfassen oder dieses bilden. Das Frontendsystem kann vorzugsweise mindestens ein Routingmodul umfassen. Das Routingmodul kann eingerichtet sein zum Bewirken einer Aussendung einer ersten Dienstanfrage an den ersten Microservice zum Nutzen des ersten Ladesystemdiensts, basierend auf einer erhaltenen Ladeaktionsanfrage und einer Ladeaktionszuordnungstabelle ln entsprechender Weise kann das
Routingmodul eingerichtet sein zum Bewirken einer Aussendung einer weiteren Dienstanfrage an den mindestens einen weiteren Microservice zum Nutzen des mindestens einen weiteren Ladesystemdienstes, basierend auf einer erhaltenen Ladeaktionsanfrage und der Ladeaktionszuordnungstabelle.
Die Ladeaktionsanfrage kann beispielsweise auf einer Nutzeraktion basieren und die Ausführung einer bestimmten Aufgabe bzw. Funktionalität erfordern, die durch einen als Microservice abgebildeten Ladesystemdienst in dem Backendsystem
implementiert ist. Beispielsweise kann durch einen Nutzer ein Ladevorgang initiiert sein, der beispielsweise zunächst die Durchführung eines Authentifizierungsdienstes erfordert. Detektiert das Frontendsystem eine entsprechende Ladeaktionsanfrage, kann das Routingmodul eine entsprechende Dienstanfrage, im vorliegenden Beispiel eine Authentifizierungsdienstanfrage, insbesondere generieren und dessen
Aussendung an den entsprechenden Microservice, in dem der
Authentifizierungsdienst implementiert ist, bewirken. Hierzu kann in dem Frontendsystem eine Ladeaktionszuordnungstabelle gespeichert sein ln der Ladeaktionszuordnungstabelle können Zuordnungen zwischen
Ladeaktionsanfragen und hierfür erforderliche Ladesystemdienste gespeichert sein. Insbesondere bevorzugt können in einer Ladeaktionszuordnungstabelle zusätzlich die jeweiligen (eineindeutigen) Kommunikationsadressen der jeweils zugeordneten Schnittstellen der Microservices gespeichert sein. Hierdurch kann das Routingmodul die Aussendung einer Dienstanfrage an die Schnittstelle des zugehörigen (korrekten) Ladesystemdienst bzw. Microservice bewirken.
Vorzugsweise kann die erste Dienstanfrage durch mindestens eine erste
Datennachricht gebildet sein, umfassend zumindest die erste Kommunikationsadresse (im Header der Dienstnachricht) und Dienstnutzdaten. Basierend auf dem obigen Beispiel kann eine Authentifizierungsdienstanfrage (insbesondere im Header der Nachricht) die Kommunikationsadresse der Schnittstelle des
Authentifizierungsdienstes und als Dienstnutzdaten zumindest die zu prüfenden Authentifizierungsdaten (z.B. Nutzername und/oder Passwort und/oder
Ladestationskennung etc.) umfassen. Es versteht sich, dass zwei oder mehr
Datennachrichten gebildet und insbesondere gesendet werden können, um
insbesondere sämtliche zu einer Dienstanfrage gehörenden Dienstnutzdaten zu übertragen.
Der Authentifizierungs dienst kann dann in herkömmlicher Weise die über die zugeordnete Schnittstelle empfangenen Authentifizierungsdaten (unabhängig von weiteren Microservices) prüfen. Insbesondere können die Authentifizierungsdaten mit (in einer Speichereinheit der physikalischen Recheneinheit, auf der der
Authentifizierungsdienst als Microservice implementiert ist) gespeicherten
Nutzerauthentifizierungsdaten (von beispielsweise zuvor registrierten Nutzern) verglichen werden. Wird eine Korrespondenz, insbesondere Gleichheit, zwischen den erhaltenden Authentifizierungsdaten und den in z.B. Nutzerkonten gespeicherten Authentifizierungsdaten festgestellt, ist das Überprüfungsergebnis positiv. Anders ausgedrückt ist der Nutzer in diesem Fall berechtigt, einen Ladevorgang an der Ladestation durchzuführen. Wird keine Korrespondenz festgestellt, ist das
Überprüfungsergebnis negativ. Anders ausgedrückt ist der Nutzer nicht berechtigt, einen Ladevorgang an der Ladestation durchzuführen.
Bei einem positiven Überprüfungsergebnis wird der erste Ladevorgang freigegen, indem insbesondere von dem Authentifizierungsdienst das Aussenden einer
Freigabenachricht an die entsprechende freizugebende Ladestation bewirkt wird. Bei einem negativen Überprüfungsergebnis wird der Ladevorgang blockiert,
beispielsweise wird eine Sperrnachricht an die Ladestation übertragen oder keine Freigabenachricht übertragen. ln entsprechender Weise können andere (zuvor beschriebene) Ladesystemdienste in herkömmlicher Weise durchgeführt werden.
Gemäß einer weiteren Ausführungsform des anmeldungsgemäßen Ladesystems kann mindestens eine Ladestation das Frontendsystem, das insbesondere aus Hardware und/oder Software gebildet ist, aufweisen. Alternativ oder bevorzugt zusätzlich kann das Ladesystem mindestens ein mobiles Nutzerendgerät umfassen. Das mindestens eine mobile Nutzerendge rät kann das Frontendsystem, das insbesondere aus
Hardware und/oder Software gebildet ist, aufweisen. Neben dem Routingmodul kann ein Frontendsystem vorzugsweise über mindestens eine Verbindung zu mindestens einer Nutzerschnittstelle (z.B. Tastatur, Tasten, Touchdisplay, RFID-Modul, NFC- Modul, Kartenmodul etc.) und/oder mindestens eine Verbindung zu mindestens einem Kommunikationsmodul (z.B. Kontroller mit Antenne) verfügen und/oder eine Nutzerschnittstelle und/oder ein Kommunikationsmodul umfassen.
Ein weiterer Aspekt der Anmeldung ist ein Frontendsystem eines Ladesystems, insbesondere eines zuvor beschriebenen Ladesystems. Das Frontendsystem umfasst mindestens eine Kommunikationsverbindung zu einer Nutzerschnittstelle, eingerichtet zum Generieren mindestens einer Ladeaktionsanfrage. Insbesondere kann basierend auf einer Nutzereingabe eine zuvor beschriebene Ladeaktionsanfrage generiert bzw. erhalten werden. Beispielsweise kann als Ladeaktionsanfrage über die Nutzerschnittstelle ein Ladevorgang initiiert werden, der in (herkömmlicher Weise) die Erledigung mindestens eines Ladesystemdienstes bzw. einer Ladesystemaufgabe erfordert. Das Frontendsystem umfasst mindestens ein (insbesondere zuvor beschriebenes) Routingmodul. Das Routingmodul ist eingerichtet zum Bewirken einer Aussendung einer ersten Dienstanfrage an einen ersten Microservice zum Nutzen eines ersten Ladesystemdienstes, basierend auf einer erhaltenen Ladeaktionsanfrage und einer Ladeaktionszuordnungstabelle, wobei in einem Backendsystem der erste Ladesystemdienst einer Ladesteueranwendung in Form des ersten Microservice implementiert ist.
Das Frontendsystem kann beispielsweise als ausführbare Anwendung (App) auf einem mobilen Nutzerendgerät installierbar und von diesem ausführbar sein. Auch kann das Frontendsystem beispielsweise als ausführbare Anwendung in einer Ladestation installierbar und von dieser ausführbar sein.
Unter einem mobilen Nutzerendgerät ist insbesondere ein Smartphone,
Navigationsgerät des Elektrofahrzeugs, Tablet-Computer, Laptop, Smartwatch oder ein ähnliches tragbares Gerät zu verstehen.
Ein noch weiterer Aspekt der Anmeldung ist ein Verfahren zum Betreiben eines Ladesystems, umfassend ein Backendsystem mit mindestens einer
Ladesteueranwendung, eingerichtet zum Steuern einer Mehrzahl von über
mindestens ein Kommunikationsnetz mit dem Backendsystem verbindbaren
Ladestationen, wobei in dem Backendsystem ein erster (insbesondere zuvor beschriebener) Ladesystemdienst der Ladesteueranwendung in Form eines ersten Microservice implementiert ist. Das Verfahren umfasst:
Empfangen, durch den ersten Microservice, einer ersten Dienstanfrage zum
Nutzen des ersten Ladesystemdienst, und Ausführen des ersten Ladesystemdienstes bei Empfang der ersten
Dienstanfrage.
Insbesondere kann das Verfahren zum Betreiben eines zuvor beschriebenen
Ladesystems verwendet werden.
Die Merkmale der Ladesysteme, Frontendsysteme und Verfahren sind frei
miteinander kombinierbar. Insbesondere können Merkmale der Beschreibung und/oder der abhängigen Ansprüche, auch unter vollständiger oder teilweiser Umgehung von Merkmalen der unabhängigen Ansprüche, in Alleinstellung oder frei miteinander kombiniert eigenständig erfinderisch sein.
Es gibt nun eine Vielzahl von Möglichkeiten, das anmeldungsgemäße Verfahren, das anmeldungsgemäße Frontendsystem und das anmeldungsgemäße Ladesystem auszugestalten und weiterzuentwickeln. Hierzu sei einerseits verwiesen auf die den unabhängigen Patentansprüchen nachgeordneten Patentansprüche, andererseits auf die Beschreibung von Ausführungsbeispielen in Verbindung mit der Zeichnung. In der Zeichnung zeigt:
Fig- 1 eine schematische Ansicht eines Ausführungsbeispiels eines
Ladesystems gemäß der vorliegenden Anmeldung,
Fig. 2 eine schematische Ansicht eines weiteren Ausführungsbeispiels eines
Ladesystems gemäß der vorliegenden Anmeldung, und
Fig. 3 ein Diagramm eines Ausführungsbeispiels eines Verfahrens gemäß der vorliegenden Anmeldung.
Nachfolgend werden für gleiche Elemente gleiche Bezugszeichen verwendet. Die Figur 1 zeigt eine schematische Ansicht eines Ausführungsbeispiels eines
Ladesystems 100 gemäß der vorliegenden Anmeldung. Das Ladesystem 100 umfasst ein Backendsystem 102 und eine Mehrzahl von Ladestationen 104. Die Ladestationen 104 sind über ein (drahtloses und/oder drahtgebundenes) Kommunikationsnetz 118 mit dem Backendsystem 102 verbindbar.
Eine Ladestation 104 weist mindestens einen Ladeanschluss auf, der über ein
Ladekabel 108 mit einem Ladeanschluss eines Elektrofahrzeugs 106 gekoppelt werden kann, um das Elektrofahrzeug 106 bzw. dessen wiederaufladbare Batterie zu laden.
Das Backendsystem 102 wird durch mindestens eine physikalische Recheneinheit (z.B. ein Server) gebildet. Auf der mindestens einen Recheneinheit ist mindestens eine Ladesteueranwendung 103 implementiert. Die (modulartige) Ladesteueranwendung 103 ist eingerichtet zum Steuern einer Mehrzahl von über das mindestens eine Kommunikationsnetz 118 mit dem Backendsystem 102 verbindbaren Ladestationen 104. Hierunter ist insbesondere zu verstehen, das die Ladesteueranwendung 103 mindestens zwei (verschiedene) Ladesystemdienste 110, 112 für den Betrieb des Ladesystem 100 bereitstellt.
Ein Ladesystemdienst 110, 112 ist insbesondere eingerichtet, (genau) eine bestimmte Aufgabe des Ladesystem 100 zu übernehmen und insbesondere auszuführen.
Nachfolgend wird beispielhaft davon ausgegangen, dass der erste Ladesystemdienst 110 ein Authentifizierungsdienst 110 und der weitere Ladesystemdienst 112 ein Lastmanagementdienst 112. Es versteht sich, dass weitere (oder andere)
Ladesystemdienste, wie ein Bezahldienst, ein Softwareupdatedienst, ein
eichrechtskonformer Abrechnungsdienst etc. in der Ladesteueranwendung implementiert sein können. In dem Backendsystem 102 ist der erste Ladesystemdienst 110 der
Ladesteueranwendung 103 in Form eines ersten Microservice 110 implementiert und in dem Backendsystem 102 zumindest der mindestens eine weitere Ladesystemdienst 112 der Ladesteueranwendung 103 in Form eines weiteren Microservice 112 implementiert ist.
Vorliegend ist in dem bevorzugten Ausführungsbeispiel dem ersten Microservice 110 eindeutig genau eine erste Schnittstelle 114 mit einer ersten Kommunikationsadresse zugeordnet. Anders ausgedrückt kann der erste Microservice 110 nur über die erste Schnittstelle 114 genutzt werden. In entsprechender Weise kann dem mindestens einen weiteren Microservice 112 eine weitere Schnittstelle 116 mit einer weiteren Kommunikationsadresse zugeordnet sein. Der weitere Microservice 112 kann nur über die weiteren Schnittstelle 116 genutzt werden. Jede Schnittstelle 114, 116 verfügt vorzugsweise über eine in dem Ladesystem 100 eineindeutige
Kommunikationsadresse.
Wie ferner zu erkennen ist, kann vorzugsweise eine Ladestation 104 ein
Frontendsystem 120 umfassen. Das Frontendsystem 120 umfasst insbesondere ein Routingmodul 124. Zudem kann ein Frontendsystem 120 über eine
Nutzerschnittstelle 122 (z.B. ein Tastenfeld, eine Nahfeldschnittstelle (z.B. NFC, RFID oder Bluetooth Modul) und ein Kommunikationsmodul 126 verfügen oder zumindest mit einer Nutzerschnittstelle 122 und einem Kommunikationsmodul 126 über jeweils mindestens eine Verbindung verbindbar sein. Die Funktionsweise wird nachfolgend beschrieben werden.
Die Figur 2 zeigt eine schematische Ansicht eines weiteren Ausführungsbeispiels eines Ladesystems 200 gemäß der vorliegenden Anmeldung. Zur Vermeidung von
Wiederholungen werden nachfolgend im Wesentlichen nur die Unterschiede zu dem Ausführungsbeispiel nach Figur 1 beschrieben. Für die anderen Komponenten des Ladesystems 200 wird insbesondere auf die obigen Ausführungen verwiesen. Der erste Microservice 210 (und die assoziierte Schnittstelle 214) ist im vorliegenden Ausführungsbeispiel auf mindestens einer ersten physikalischen Recheneinheit 230 implementiert und ist durch diese ausführbar. Der weitere Microservice 212 (und die assoziierte Schnittstelle 216) ist im vorliegenden Ausführungsbeispiel auf mindestens einer weiteren physikalischen Recheneinheit 232 implementiert und ist durch diese ausführbar. Die beiden physikalischen Recheneinheiten 230, 232 sind insbesondere voneinander unabhängig bzw. entkoppelt.
Ferner umfasst das Backendsystem 202 vorliegend ein Laststeuerungsmodul 234. Das Laststeuerungsmodul 234 ist insbesondere eingerichtet zum Erfassen der
(augenblicklichen) Belastung zumindest der ersten physikalischen Recheneinheit 230 und/oder des ersten Microservice 210 und der weiteren physikalischen
Recheneinheit 232 und/oder des weiteren Microservice 212. Das
Laststeuerungsmodul 234 kann ferner eingerichtet sein zum Skalieren zumindest der ersten physikalischen Recheneinheit 230 und/oder des ersten Microservice 210 und der weiteren physikalischen Recheneinheit 232 und/oder des weiteren Microservice 212, basierend auf der erfassten (augenblicklichen) Belastung der mindestens einen physikalischen Recheneinheit und/oder des mindestens einen Microservice.
Darüber hinaus weist im vorliegenden Ausführungsbeispiel ein Frontendsystem 220 jeweils eine Ladeaktionszuordnungstabelle 236 auf.
Ferner ist ein weiteres Frontendsystem 240, aufweisend ein Routingmodul 244 und eine Ladeaktionszuordnungstabelle 248, auf einem mobilen Nutzerendgerät 238 (z.B. ein Smartphone) implementiert. Das Frontendsystem 240 kann insbesondere eine auf dem Nutzerendgerät 238 installierbare Anwendung (App) sein. Das Frontendsystem 240 umfasst zumindest eine Verbindung zu mindestens einer Nutzerschnittstelle 242 (z.B. Touchdisplay des Endgeräts 238), eingerichtet zum Generieren mindestens einer Ladeaktionsanfrage, und vorzugsweise zumindest eine Verbindung zu einem
Kommunikationsmodul 248. Ein Kommunikationsmodul 226, 248 ist insbesondere eingerichtet zum Kommunizieren mit dem Backendsystem 202 über das Kommunikationsnetz 218.
Die Funktionsweise bzw. der Betrieb des Ladesystems 200 nach Figur 2 wird beispielhaft mit Hilfe der Figur 3 näher beschrieben.
Die Figur 3 zeigt ein Diagramm eines Ausführungsbeispiels eines Verfahrens gemäß der vorliegenden Anmeldung ln einem ersten Schritt 301 kann das Frontendsystem 220, 238, insbesondere über die mindestens eine Nutzerschnittstelle 222, 242, eine Ladeaktionsanfrage erhalten. Beispielhaft wird nachfolgend zur besseren
Veranschaulichung davon ausgegangen, dass es sich bei der, insbesondere durch das Routingmodul 224, 244, erhaltene Ladeaktionsanfrage um eine
Ladevorgangsinitiierungsanfrage handelt, die insbesondere auf mindestens einer Nutzeraktion basieren kann, durch die der Nutzer einen Ladevorgang an einer Ladestation 204 zum Laden seines Elektrofahrzeugs starten möchte ln dem Schritt 301 kann ein Erhalten einer derartigen Ladeaktionsanfrage detektiert werden.
Im nächsten Schritt 302 kann das Routingmodul 224, 244 die erhaltene
Ladeaktionsanfrage auswerten und insbesondere im vorliegenden Beispiel feststellen, dass es sich um eine Ladevorgangsinitiierungsanfrage handelt. Insbesondere basierend auf einer gespeicherten Ladeaktionszuordnungstabelle 236, 248 kann das Routingmodul 224, 244 bestimmen, welcher mindestens eine Ladesystemdienst die Ladevorgangsinitiierungsanfrage erfordert. Wiederum beispielhaft wird
angenommen, dass die Ladevorgangsinitiierungsanfrage zumindest eine
Authentifizierung des Nutzers erfordert, also die Nutzung eines
Authentifizierungsdienstes. Eine entsprechende Zuordnung kann in der
Ladeaktionszuordnungstabelle 236, 248 gespeichert sein ln einfacher Weise kann das Routingmodul 224, 244 den mindestens eine erforderlichen Ladesystemdienst bestimmen. Es versteht sich, dass bei einer Ladevorgangsinitiierungsanfrage weitere Ladesystemdienste, beispielsweise ein Lastmanagementdienst etc., erforderlich sein können. Für eine bessere Übersichtlichkeit wird im vorliegenden Beispiel nur die Durchführung des Authentifizierungsdienstes näher beschrieben. ln Schritt 302 kann das Routingmodul 224, 244 vorzugsweise mindestens eine Dienstanfrage, vorliegend eine Authentifizierungsdienstanfrage, erstellen,
insbesondere in Form von einer oder mehrerer Datennachricht/en. Eine
Datennachricht kann die Kommunikationsadresse der ersten Schnittstelle 214 des als ersten Microservice 210 im Backendsystem 202 implementierten
Authentifizierungsdienstes 210 aufweisen. Insbesondere kann in der
Ladeaktionszuordnungstabelle 236, 248 die mit dem Authentifizierungsdienst assoziierte Kommunikationsadresse gespeichert sein. Als Dienstnutzdaten kann eine Datennachricht im vorliegenden Beispiel zumindest einen Teil von erhaltenen
Authentifizierungsdaten (Nutzername, Passwort etc.) des Nutzers aufweisen. Die Authentifizierungsdaten können beispielsweise über die Nutzerschnittstelle 222, 242 empfangen werden. ln Schritt 303 bewirkt das Routingmodul 224, 244 ein Senden der
Authentifizierungsdienstanfrage, insbesondere der mindestens einen Datennachricht, über das Kommunikationsnetz 218 an den entsprechenden Microservice 210 bzw. der mit diesem Microservice 210 assoziierten Schnittstelle 214. Insbesondere kann das Routingmodul 224, 244 das mindestens eine Kommunikationsmodul 226, 246 entsprechend ansteuern und ein Aussenden der mindestens einen Datennachricht bewirken.
Nach Erhalt der mindestens einen Datennachricht kann der Microservice 210 ausgeführt werden, insbesondere basierend auf den erhaltenen Nutzdaten in Form der Authentifizierungsdaten des Nutzers. Insbesondere kann der erste Microservice 210 von der Recheneinheit 230 ausgeführt werden. Bei der Ausführung kann insbesondere die Berechtigung des Nutzers zur Durchführung eines Ladevorgangs anhand der erhaltenen Authentifizierungsdaten und Nutzerauthentifizierungsdaten, also insbesondere vorab gespeicherten Authentifizierungsdaten von registrierten Nutzern, geprüft werden. Beispielsweise können Nutzerkonten bzw. entsprechende Nutzerdaten in der Recheneinheit 230 und/oder einer Datenbank, auf die die
Recheneinheit 230 bzw. der Microservice 210 zugreifen kann, gespeichert sein.
Besonders bevorzugt ist, wenn in dieser Datenbank nur die Nutzerdaten gespeichert sind, die für eine Authentifizierung eines Nutzers erforderlich sind (z.B. nur
Nutzername und Passwort), während andere Nutzerdaten, wie Kontodaten, die beispielsweise für eine Abrechnung des Ladevorgangs erforderlich sind, aber nicht für einen Authentifizierungsvorgang, nicht in der Datenbank der Recheneinheit 230 und/oder der Datenbank, auf die die Recheneinheit 230 bzw. der Microservice 210 zugreifen kann, gespeichert sind.
Die Überprüfung in Schritt 304 kann beispielsweise ein Vergleich des empfangenen Nutzernamens und des zugehörigen Passworts mit den gespeicherten
Authentifizierungsdaten, insbesondere den gespeicherten Nutzernamen und den jeweils zugeordneten Passwörtern, umfassen.
Bei einem positiven Überprüfungsergebnis, also wenn beispielsweise empfangener Nutzername und empfangenes Passwort mit einem gespeicherten Nutzernamen und dem zugeordneten Passwort übereinstimmen, kann in Schritt 305 der Ladevorgang an der Ladestation 204 freigegeben werden. Anders ausgedrückt kann in Schritt 305 durch den Microservice 210 insbesondere eine Freigabenachricht zur Freigabe des Ladevorgangs an die entsprechende Ladestation 204 bei einem positiven
Überprüfungsergebnis übertragen werden. Bei einem negativen
Überprüfungsergebnis wird der erste Ladevorgang nicht freigegeben. Beispielsweise kann in diesem Fall eine entsprechende Antwortnachricht in Schritt 305 übertragen werden.
Ferner kann insbesondere parallel zu Schritt 304 die Auslastung des Microservice 210 und/oder der physikalischen Recheneinheit 230 durch das Laststeuerungsmodul 234 erfasst werden. Der Microservice 210 und/oder die physikalische Recheneinheit 230 können skalierbar ausgebildet sein. Abhängig von der (augenblicklich) erfassten Belastung bzw. Auslastung des Microservice 210 und/oder der physikalischen Recheneinheit 230 kann das Laststeuerungsmodul 234 eine Skalierung des
Microservice 210 und/oder die physikalische Recheneinheit 230, ein Erhöhen oder Verringern der Leistungsfähigkeit des Microservice 210 und/oder der physikalischen Recheneinheit 230.

Claims

P a t e n t a n s p r ü c h e
1. Ladesystem (100, 200) zum Laden von Elektrofahrzeuge (108), umfassend: mindestens ein Backendsystem (102, 202) mit mindestens einer
Ladesteueranwendung (103, 203), eingerichtet zum Steuern einer Mehrzahl von über mindestens ein Kommunikationsnetz (118, 218) mit dem Backendsystem (102, 202) verbindbaren Ladestationen (104, 204),
wobei in dem Backendsystem (102, 202) ein erster Ladesystemdienst (110, 210) der Ladesteueranwendung (103, 203) in Form eines ersten Microservice (110, 210) implementiert ist, und
wobei in dem Backendsystem (102, 202) zumindest ein weiterer
Ladesystemdienst (112, 212) der Ladesteueranwendung (103, 203) in Form eines weiteren Microservice (112, 212) implementiert ist.
2. Ladesystem (100, 200) nach Anspruch 1, dadurch gekennzeichnet, dass
dem ersten Microservice (110, 210) eine erste Schnittstelle (114, 214) mit einer ersten Kommunikationsadresse zugeordnet ist, und
dem mindestens einen weiteren Microservice (112, 212) eine weitere
Schnittstelle (116, 216) mit einer weiteren Kommunikationsadresse zugeordnet ist.
3. Ladesystem (100, 200) nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass der erste Microservice (110, 210) auf mindestens einer ersten physikalischen Recheneinheit (230) implementiert ist, und
der mindestens eine weitere Microservice (112, 212) auf mindestens einer von der mindestens einen ersten Recheneinheit (230) unabhängigen weiteren physikalischen Recheneinheit (232) implementiert ist.
4. Ladesystem (100, 200) nach Anspruch 3, dadurch gekennzeichnet, dass die erste physikalische Recheneinheit (230) unabhängig von der weiteren physikalischen Recheneinheit (232) skalierbar ist.
5. Ladesystem (100, 200) nach einem der vorherigen Ansprüche, dadurch
gekennzeichnet, dass
das Backendsystem (102, 202) mindestens ein Laststeuerungsmodul (234) umfasst, eingerichtet zum Erfassen der Belastung von mindestens einer physikalischen Recheneinheit (230, 232) und/oder einem Microservice (110, 112, 210, 212),
wobei das Laststeuerungsmodul (234) eingerichtet ist zum Skalieren der mindestens einen physikalischen Recheneinheit (230, 232) und/oder des mindestens einen Microservices (110, 112, 210, 212), basierend auf der erfassten Belastung der mindestens einen physikalischen Recheneinheit (230, 232) und/oder des mindestens einen Microservices (110, 112, 210, 212).
6. Ladesystem (100, 200) nach einem der vorherigen Ansprüche, dadurch
gekennzeichnet, dass
das Ladesystem (100, 200) mindestens ein Frontendsystem (220, 240) umfasst, wobei das Frontendsystem (220, 240) mindestens ein Routingmodul (224, 244) umfasst, eingerichtet zum Bewirken einer Aussendung einer ersten
Dienstanfrage an einen bestimmten Microservice (110, 112, 210, 212) zum Nutzen des bestimmten Ladesystemdienstes des bestimmten Microservice (110, 112, 210, 212), basierend auf einer erhaltenen Ladeaktionsanfrage und einer Ladeaktionszuordnungstabelle (236, 248).
7. Ladesystem (100, 200) nach Anspruch 6, dadurch gekennzeichnet, dass
die erste Dienstanfrage durch mindestens eine erste Datennachricht gebildet ist, umfassend zumindest die erste Kommunikationsadresse und Dienstnutzdaten.
8. Ladesystem (100, 200) nach Anspruch 6 oder 7, dadurch gekennzeichnet, dass mindestens eine Ladestation (104, 204) das Frontendsystem (240) aufweist, und/oder
das Ladesystem (100, 200) mindestens ein mobiles Nutzerendgerät (238) umfasst, aufweisend das Frontsystem (240).
9. Frontendsystem (220, 240) für ein Ladesystems (100, 200), insbesondere eines Ladesystems (100, 200) nach einem der vorherigen Ansprüche, umfassend: zumindest eine Verbindung zu mindestens einer Nutzerschnittstelle (222, 242), eingerichtet zum Generieren mindestens einer Ladeaktionsanfrage,
mindestens ein Routingmodul (224, 244), eingerichtet zum Bewirken einer Aussendung einer ersten Dienstanfrage an einen ersten Microservice (110, 210) zum Nutzen eines ersten Ladesystemdienstes (110, 210), basierend auf einer erhaltenen Ladeaktionsanfrage und einer Ladeaktionszuordnungstabelle (236, 248), wobei in einem Backendsystem (102, 202) der erste Ladesystemdienst (110, 210) einer Ladesteueranwendung (103, 203) in Form des ersten
Microservice (110, 210) implementiert ist.
10. Verfahren zum Betreiben eines Ladesystems (100, 200), umfassend ein
Backendsystem (102, 202) mit mindestens einer Ladesteueranwendung (103, 203), eingerichtet zum Steuern einer Mehrzahl von über mindestens ein
Kommunikationsnetz (118, 218) mit dem Backendsystem (102, 202)
verbindbaren Ladestationen (104, 204), wobei in dem Backendsystem (102, 202) ein erster Ladesystemdienst (110, 210) der Ladesteueranwendung (103, 203) in Form eines ersten Microservice (110, 210) implementiert ist, das Verfahren umfassend:
Empfangen, durch den ersten Microservice (110, 210), einer ersten
Dienstanfrage zum Nutzen des ersten Ladesystemdienst (110, 210), und
Ausführen des ersten Ladesystemdienstes (110, 210) bei Empfang der ersten Dienstanfrage.
EP20702627.9A 2019-02-06 2020-01-29 Ladesystem zum laden von elektrofahrzeugen Withdrawn EP3921203A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102019102890.6A DE102019102890A1 (de) 2019-02-06 2019-02-06 Ladesystem zum Laden von Elektrofahrzeugen
PCT/EP2020/052119 WO2020160972A1 (de) 2019-02-06 2020-01-29 Ladesystem zum laden von elektrofahrzeugen

Publications (1)

Publication Number Publication Date
EP3921203A1 true EP3921203A1 (de) 2021-12-15

Family

ID=69375360

Family Applications (1)

Application Number Title Priority Date Filing Date
EP20702627.9A Withdrawn EP3921203A1 (de) 2019-02-06 2020-01-29 Ladesystem zum laden von elektrofahrzeugen

Country Status (3)

Country Link
EP (1) EP3921203A1 (de)
DE (1) DE102019102890A1 (de)
WO (1) WO2020160972A1 (de)

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8421592B1 (en) * 2008-10-15 2013-04-16 Sprint Communications Company L.P. Mediation of electric vehicle charging by wireless network provider
DE102008037576A1 (de) * 2008-11-21 2010-06-10 EnBW Energie Baden-Württemberg AG Computergestütztes Verfahren zur Optimierung der Energienutzung
US20130046660A1 (en) * 2011-08-16 2013-02-21 Richard Lowenthal Taxable Fringe Benefit Accounting for Electric Vehicle Charging Service

Also Published As

Publication number Publication date
WO2020160972A1 (de) 2020-08-13
DE102019102890A1 (de) 2020-08-06

Similar Documents

Publication Publication Date Title
EP2640596B1 (de) Ladevorrichtung zum laden eines fahrzeugakkumulators
DE102018209761A1 (de) Verfahren zur Konfiguration eines Ladesystems und Ladesystem zum Laden des elektrischen Energiespeichers eines Fahrzeugs
WO2020164909A1 (de) Verfahren zum betreiben eines ladesystems
DE102015016320A1 (de) Verfahren zur Verwaltung zumindest eines Parkplatzes
DE102016002945B4 (de) Kraftfahrzeug und Verfahren zum Bereitstellen mehrerer Online-Fahrzeugfunktionalitäten
DE102017202024B4 (de) Verfahren zum Koppeln eines portablen, mobilen Nutzergeräts mit einem in einem Kraftfahrzeug verbauten Fahrzeuggerät sowie Servervorrichtung
DE102009009310A1 (de) Kommunikation und Identifizierung zwischen einem Kraftfahrzeugbenutzergerät mit Head Unit und davon entfernt gelegener Vorrichtung
EP3921203A1 (de) Ladesystem zum laden von elektrofahrzeugen
DE102018123601A1 (de) Mehrfachladeanschlussvorrichtung für Elektrofahrzeuge
EP3626514B1 (de) Ladestation
DE102019107071A1 (de) Ladestation zum Laden von Elektrofahrzeugen
DE102020107365A1 (de) Verfahren und System zum Freischalten eines elektrischen Ladevorgangs für ein Kraftfahrzeug sowie Servervorrichtung
DE102018201672A1 (de) Verfahren und System zum Nachweis eines Ladevertrags eines Benutzers zum Freigeben eines Ladevorgangs zum Laden eines Elektrofahrzeugs an einer Ladeinfrastruktur
EP3585028A1 (de) Verfahren zur anbindung eines endgerätes in eine vernetzbare rechner-infrastruktur
WO2020164815A1 (de) Verfahren zum betreiben eines ladesystems
EP4072180A1 (de) Verfahren zur autorisierung eines ladevorgangs an einem ladepunkt
DE102018132979A1 (de) Abgesichertes und intelligentes Betreiben einer Ladeinfrastruktur
EP3328681B1 (de) System und verfahren zur energieversorgung eines elektrischen verbrauchers sowie eine energiestation
EP3898317A1 (de) Ladesystem für ein fahrzeug
DE102019111273A1 (de) Verfahren zum Starten eines Ladevorgangs an einer Ladestation
WO2018153641A1 (de) Ladevorrichtung zum laden eines elektrisch angetriebenen kraftfahrzeugs mit zugriff auf ein datennetzwerk und verfahren zum betreiben einer solchen ladevorrichtung
DE102016111858A1 (de) DLMS-Server, DLMS-Client und Verfahren für die DLMS-Kommunikationssicherheit
DE102022201082A1 (de) Verfahren zu einer eindeutigen Identifikation eines batterieelektrisch betriebenen Kraftfahrzeugs an einer Ladestation
DE102021121127A1 (de) Verfahren zum Betreiben eines Netzmanagementsystems für ein lokales Energienetz, Computerprogrammprodukt sowie Netzmanagementsystem
DE102021213161A1 (de) Ladesystem

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20210713

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: COMPLEO CHARGING SOLUTIONS AG

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20230801