EP3921203A1

EP3921203A1 - Charging system for charging electric vehicles

Info

Publication number: EP3921203A1
Application number: EP20702627.9A
Authority: EP
Inventors: Stephan CATER
Original assignee: Innogy SE
Current assignee: CCS Abwicklungs AG
Priority date: 2019-02-06
Filing date: 2020-01-29
Publication date: 2021-12-15
Also published as: WO2020160972A1; DE102019102890A1

Abstract

The application relates to a charging system (100, 200) for charging electric vehicles (108), comprising at least one backend system (102, 202) having at least one charging control application (103, 203) configured to control a multiplicity of charging stations (104, 204) able to be connected to the backend system (102, 202) via at least one communication network (118, 218), wherein a first charging system service (110, 210) of the charging control application (103, 203) in the form of a first microservice (110, 210) is implemented in the backend system (102, 202), and wherein at least one further charging system service (112, 212) of the charging control application (103, 203) in the form of a further microservice (112, 212) is implemented in the backend system (102, 202).

Description

Charging system for charging electric vehicles

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

Communication network with the backend system connectable charging stations. 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. For this purpose, a charging station can be used in a conventional manner via the required

Charging technology and at least one charging connection, like a fixed

attached charging cable or a charging socket for connecting a

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. In particular, an electrical storage device (e.g.

Electric vehicle's traction battery). In known loading systems, a loading control application is implemented in the jaw system, for example on a processing unit such as a server. One example of such a charge control application is the eOperate system from Innogy SE. In one such charge control application, there are a number of monolithic

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. For example, 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.

It also occurs during an update or maintenance of a

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.

According to the application, the task is achieved by a charging system for charging

Electric vehicles according to claim 1 solved. The charging system comprises at least one back-end system with at least one charging control application. The

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. In 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.

In contrast to the prior art, it has been recognized that 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. For example, 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. In addition, microservices can be scaled independently of one another.

The charging system according to the application 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.

Furthermore, the charging system according to the application comprises a plurality of

Charging stations. The charging station according to the application 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,

for example in the form of a charging socket). 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. In this way, an electrically operated vehicle or electric vehicle, in particular its electrical energy store, can be charged (or discharged). In the present case, 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

(various) charging system services. 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, a load management service, a payment service, a software update service, for example, can be used as charging system services

Billing service compliant with calibration law etc. must be implemented in the charging control application.

According to the application, it is provided that at least two charging system services, preferably all of the charging system services of the charging control application, are formed in the form of microservices. A microservice implemented

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. By using microservices, a modular structure of the

Charge control application (in contrast to the monolithic structure known from the prior art) are provided. According to a first embodiment of the charging system according to the application, the first microservice can have a first interface with a first

Communication address must be assigned. At least one other

Microservice can have another interface with another

Be assigned communication address that differs in particular from the first communication address. In particular, 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. In particular, an interface can hide the implementation details of the respective microservice. This makes it possible to implement the

Implement the charging system service in the appropriate programming language.

For example, 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.

According to a particularly preferred embodiment of the charging system according to the application, 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

Computing units be implemented. This also becomes a physical one

Decoupling of the at least two microservices provided.

A first charging system service in which confidential data, for example user data such as user name, password, account data, etc., can be processed on a first processing unit with a high security level as

Microservice be implemented, while another charging system service, in which no safety-relevant data is processed, is implemented on another

Computing unit with a lower compared to the first computing unit

Security level can be implemented as a further microservice. On the one hand, there is the advantage that the safety effort in the charging system can be reduced overall. On the other hand, unauthorized access to the security-relevant data is made more difficult because of the separate processing units.

Furthermore, according to a preferred embodiment of the charging system, the first physical computing unit can be independent of the further physical

Computing unit (and preferably vice versa) be scalable. Thus, an increase in resources to increase performance can be individual for each microservice

be made. In particular, this prevents the entire infrastructure and / or

Charge control application must be scaled up, as is required in a monolithic application according to the prior art.

According to a further embodiment of the charging system according to the application, 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

physical processing unit and / or the at least one microservice. Scaling is to be understood in particular as increasing or decreasing the performance of a physical computing unit and / or a microservice.

For example, microservices that have high load fluctuations occur, be implemented in a cloud. A cloud provides a high level of scalability.

As already described, the in the backend system can be in the form of

Microservices implemented charging system services are made available to other entities for use. In other words, an entity can use the at least two charging system services to complete a specific task or several specific tasks.

According to a preferred embodiment, 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

is implemented. For example, 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

Transmission to the corresponding microservice in which the

Authentication service is implemented, effect. For this purpose, a loading action assignment table can be stored in the front-end system. In the loading action assignment table, assignments between

Charging action requests and the charging system services required for this must be saved. Particularly preferably, 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.

Preferably, 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. Based on the above example, 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

Charging station identifier etc.). It goes without saying that two or more

Data messages can be formed and in particular sent to

in particular to transmit all service user data belonging to a service request.

The authentication service can then check the authentication data received via the assigned interface in a conventional manner (regardless of other microservices). In particular, 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)

User authentication data (for example from previously registered users) are compared. If correspondence, in particular equality, is established between the authentication data received and the authentication data stored in, for example, user accounts, the check result is positive. Different Expressed in this case, the user is entitled to carry out a charging process at the charging station. If no correspondence is found, that is

Check result negative. In other words, the user is not authorized to carry out a charging process at the charging station.

In the event of a positive check result, 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,

for example, a blocking message is transmitted to the charging station or no release message is transmitted. In a corresponding manner, other charging system services (described above) can be carried out in a conventional manner.

According to a further embodiment of the charging system according to the application, at least one charging station can have the front-end system, which is formed in particular from hardware and / or software. Alternatively or preferably in addition, 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

Hardware and / or software is formed. In addition to the routing module, 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.

Another aspect of the application is a front-end system of a charging system, in particular of a charging system described above. The front-end system comprises at least one communication connection to a user interface, set up to generate at least one charging action request. In particular a previously described charging action request can be generated or received based on a user input. For example, 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,

To understand the navigation device of the electric vehicle, tablet computer, laptop, smartwatch or similar portable device.

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:

Receiving, by the first microservice, a first service request to the

Benefit of the first charging system service, and Run the first charging system service upon receipt of the first

Service request.

In particular, the method for operating a previously described

Charging system can be used.

The characteristics of the charging systems, front-end systems and processes are free

can be combined with each other. In particular, features of the description and / or the dependent claims can be independently inventive on their own or freely combined with one another, even with complete or partial circumvention of features of the independent claims.

There are now a large number of possibilities for designing and further developing the method according to the application, the front-end system according to the application and the charging system according to the application. For this purpose, reference is made, on the one hand, to the claims subordinate to the independent claims, and, on the other hand, to the description of exemplary embodiments in conjunction with the drawing. In the drawing shows:

Fig. 1 is a schematic view of an embodiment of a

Charging system according to the present application,

Fig. 2 is a schematic view of a further embodiment of a

Charging system according to the present application, and

3 shows a diagram of an exemplary embodiment of a method according to the present application.

The same reference symbols are used below for the same elements. FIG. 1 shows a schematic view of an exemplary embodiment of a

Charging system 100 according to the present application. 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.

In the following, it is assumed by way of example that 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. In the backend system 102, 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.

In the present case, in the preferred exemplary embodiment, precisely one first interface 114 with a first communication address is clearly assigned to the first microservice 110. In other words, the first microservice 110 can only be used via the first interface 114. In a corresponding manner, 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

Communication address.

As can also be seen, 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. In addition, 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. To avoid

Repetitions are essentially only the differences to the embodiment according to Figure 1 described below. For the other components of the charging system 200, reference is made in particular to the statements above. 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.

Furthermore, 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

(instantaneous) loading of at least the first physical computing unit 230 and / or the first microservice 210 and the further physical ones

Computing unit 232 and / or the further microservice 212. 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.

In addition, in the present exemplary embodiment, a front-end system 220 has in each case a charging action assignment table 236.

Furthermore, 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

Communication module 248. A communication module 226, 248 is set up in particular to communicate with the backend system 202 via the communication network 218.

The mode of operation or the operation of the charging system 200 according to FIG. 2 is described in greater detail by way of example with the aid of FIG.

FIG. 3 shows a diagram of an exemplary embodiment of a method according to the present application. In a first step 301, 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

In the illustration, it is assumed that the charge action request received, in particular by the routing module 224, 244, is a

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. In step 301, receipt of such a charging action request can be detected.

In the next step 302, the routing module 224, 244 can receive the

Evaluate the charge action request and, in particular, determine in the present example that it is a charge process initiation request. In particular, based on a stored charging action allocation table 236, 248, the routing module 224, 244 can determine which at least one charging system service requires the charging operation initiation request. Again is exemplary

assumed that the charge initiation request is at least one

Requires authentication of the user, i.e. the use of a

Authentication service. A corresponding assignment can be made in the

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. In step 302, the routing module 224, 244 can preferably create at least one service request, in this case an authentication service request,

especially in the form of one or more data messages. A

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. In the present example, a data message can receive at least part of the service payload data

Have authentication data (user name, password, etc.) of the user. The authentication data can be received via the user interface 222, 242, for example. In step 303, 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. In particular, 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.

After receiving the at least one 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. In particular, the first microservice 210 can be executed by the computing unit 230. During execution, in particular 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. For example, 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.

It is particularly preferred if only those user data are stored in this database that are required for authentication of a user (e.g. only

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

Include authentication data, in particular the stored user name and the respectively assigned passwords.

In the event of a positive check result, that is to say if, for example, the received user name and received password match a stored user name and the assigned password, the charging process at the charging station 204 can be enabled in step 305. In other words, in 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

Verification results are transmitted. With a negative

Check result, the first loading process is not released. In this case, for example, a corresponding response message can be transmitted in step 305.

Furthermore, in particular parallel to step 304, the utilization of 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. Depending on the (currently) recorded load or load on microservice 210 and / or physical computing unit 230, load control module 234 can scale the

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.

Claims

Patent claims

A charging system (100, 200) for charging electric vehicles (108), comprising: at least one backend system (102, 202) with at least one

Charging control application (103, 203), set up to control a plurality of charging stations (104, 204) that can be connected to the backend system (102, 202) via at least one communication network (118, 218),

wherein a first charging system service (110, 210) of the charging control application (103, 203) in the form of a first microservice (110, 210) is implemented in the backend system (102, 202), and

wherein in the backend system (102, 202) at least one further

Charging system service (112, 212) of the charging control application (103, 203) is implemented in the form of a further microservice (112, 212).

2. charging system (100, 200) according to claim 1, characterized in that

a first interface (114, 214) having a first communication address is assigned to the first microservice (110, 210), and

the at least one further microservice (112, 212) has another

Interface (116, 216) is assigned to a further communication address.

3. Charging system (100, 200) according to claim 1 or 2, characterized in that the first microservice (110, 210) is implemented on at least one first physical computing unit (230), and

the at least one further microservice (112, 212) is implemented on at least one further physical processing unit (232) independent of the at least one first processing unit (230).

4. Charging system (100, 200) according to claim 3, characterized in that the first physical computing unit (230) is scalable independently of the further physical computing unit (232).

5. charging system (100, 200) according to any one of the preceding claims, characterized

marked that

the backend system (102, 202) comprises at least one load control module (234), set up to record the load of at least one physical processing unit (230, 232) and / or a microservice (110, 112, 210, 212),

wherein the load control module (234) is set up to scale the at least one physical processing unit (230, 232) and / or the at least one microservice (110, 112, 210, 212), based on the recorded load of the at least one physical processing unit (230, 232) and / or of the at least one microservice (110, 112, 210, 212).

6. Charging system (100, 200) according to one of the preceding claims, characterized

marked that

the charging system (100, 200) comprises at least one front-end system (220, 240), the front-end system (220, 240) comprising at least one routing module (224, 244), set up to cause a first transmission

Service request to a specific microservice (110, 112, 210, 212) for using the specific charging system service of the specific microservice (110, 112, 210, 212), based on a received charge action request and a charge action assignment table (236, 248).

7. charging system (100, 200) according to claim 6, characterized in that

the first service request is formed by at least one first data message, comprising at least the first communication address and service user data.

8. charging system (100, 200) according to claim 6 or 7, characterized in that the front-end system (240) has at least one charging station (104, 204), and / or

the charging system (100, 200) comprises at least one mobile user terminal (238), having the front system (240).

9. Front end system (220, 240) for a charging system (100, 200), in particular a charging system (100, 200) according to one of the preceding claims, comprising: at least one connection to at least one user interface (222, 242), set up to generate at least a charge action request,

At least one routing module (224, 244), set up to cause a first service request to be sent to a first microservice (110, 210) for the use of a first charging system service (110, 210), based on a received charging action request and a charging action assignment table (236, 248) , wherein in a backend system (102, 202) the first charging system service (110, 210) of a charging control application (103, 203) in the form of the first

Microservice (110, 210) is implemented.

10. A method of operating a charging system (100, 200) comprising a

Back-end system (102, 202) with at least one charging control application (103, 203), set up to control a plurality of at least one

Communication network (118, 218) with the backend system (102, 202)

connectable charging stations (104, 204), with a first charging system service (110, 210) of the charging control application (103, 203) being implemented in the backend system (102, 202) in the form of a first microservice (110, 210), the method comprising:

Received, by the first microservice (110, 210), a first

Service request for using the first charging system service (110, 210), and

Executing the first charging system service (110, 210) upon receipt of the first service request.