Decentralized charging control system and method for coordinated charging of electric vehicles in the low-voltage distribution network

Abstract

Charging control system for the coordinated charging of electric vehicles in the low-voltage distribution network with energy, comprising a decentralised charging control system for determining the sequence of individual charging processes for the vehicles at charging stations, whereby the charging control system comprises devices for transmitting transmission orders to individual charging stations, b. a communication device connected to the decentralised charging control to ensure a secure communication process between the network participants, characterized in that the communication device for data exchange between the network participants has devices for transmitting a network vector which carries data about the charging control function and network information for the vehicles and is readable and writable by the charging stations within the communication chain, wherein the decentralised charging control takes over a prioritisation of the charging process on the basis of the charging parameters previously specified in the network vector by the network participants.

Description

[0001] The present invention relates to a decentralized charging control system for the coordinated charging of electric vehicles in the low-voltage distribution network with energy and a corresponding method for carrying out such charging coordination.

[0002] Low-voltage grids represent the lowest distribution level and serve to supply households and small to medium-sized industrial enterprises. Electric vehicles are typically also connected to this level and will soon represent an additional, previously uncontrolled, large-scale consumer for which the grids were not originally designed. Distribution grids vary in size and structure from country to country; approximately three to one hundred households, and thus also electric vehicles, are connected to such a distribution grid.

[0003] WO 2012 / 163421 A1 discloses a method for allocating electrical power or current to charging devices. Several charging devices capable of charging traction batteries of electrically powered vehicles are connected to a branch of a power supply network. The method identifies those charging devices connected to a vehicle for charging. A characteristic value for the electrical power or current to be allocated is determined. This power or current, corresponding to the characteristic value, is assigned in turn to one of the identified charging devices at successive time intervals. As a result, in each time interval, only the respective charging device can supply the power or current corresponding to the characteristic value to charge the connected traction battery.

[0004] WO 2012 / 149 230 A2 describes a method, a system, and a device for grouped charge distribution and prioritized charge distribution for electric vehicles (EVs). Distributed processing units (DPUs) receive member information about electric vehicles or their users. A power distribution manager (PDM) is coupled to each of the DPUs and includes a prioritizer that determines a prioritization for charging the EVs based on the received member information. The disclosed method includes detecting power requirements from electric vehicles within a cluster, generating vehicle-specific information using DPUs, transmitting this information to the PDM, and selecting and applying a prioritization algorithm based on the transmitted information.

[0005] DE 10 2010 040 395 A1 discloses a method and a device for efficiently charging a vehicle battery of an electric vehicle by a charging station of a group charging station. The connected vehicle battery is charged starting from an initial charging status according to a calculated charging priority value until the charging status of the vehicle battery reaches a selectable charging status. The calculated charging priority values ​​of the vehicle batteries simultaneously connected to the charging stations of the group charging station determine which batteries are charged within a charging interval.

[0006] Furthermore, WO 2013 / 045 449 A2 is known. This relates to a method for charging electric vehicles by charging stations, comprising the following steps: a) assigning electric vehicles to various electric vehicle supply devices of the charging stations; and b) charging the electric vehicles according to electric vehicle charging information and the provided charging power by the electric vehicle supply devices of the charging stations. A comparison of electric vehicle charging information, preferably load profiles, of electric vehicles and charging power information, preferably the provided charging power, of various charging stations is predicted based on electric vehicle information and a charging station parameter, and steps a) and b) are performed based on the predicted comparison.

[0007] WO 2013 / 100764 A1 describes a method, a charge controller, a charger, and a charging system for efficiently charging electric vehicle batteries. The process first determines a priority order for connected vehicles and assigns the maximum power budget to the highest-priority port. During the charging session, the actual power used is monitored and the power budget is adjusted accordingly. The remaining power budget is then allocated to the second-highest-priority port. Once the power budget exceeds a certain threshold, a charging session is started or restarted for this second-priority port.

[0008] The system described in EP 2 305 510 A2 describes a smart charging infrastructure for kiosk-powered electric vehicles. It combines an AC charging source (grid connection) with a DC charging source (battery-to-battery) and connects multiple vehicle charging stations via a local power bus. A central system controller continuously monitors the status of all connected vehicle batteries and optimizes the charging process based on various factors such as battery health, weather conditions, time of day, and grid status. Additionally, the system supports intelligent vehicle selection for customers by comparing their travel requests with battery charging information and external data to suggest the most suitable vehicle.

[0009] WO 2011 / 009 129 A1 describes a method for intelligent charging via regularly updated schedules, comprising the following steps: regularly sending a charging schedule over a network from a server to a plurality of electrical resources; receiving the charging schedule over the network from the server by at least one of the plurality of electrical resources; and replacing a previous charging schedule with the received charging schedule, wherein the previous charging schedule controlled the charging behavior for at least one of the plurality of electrical resources.

[0010] WO 2011 / 097 142 A2 describes a system for cooperative charging of electric vehicles using power line communication (PLC). Chargers connected to the same distribution transformer form independent local networks. Additionally, the internet and local networks can serve as the communication infrastructure. The connected chargers form a logical token-ring network, in which a fixed number of tokens circulate within the network. Only chargers with tokens are allowed to charge their vehicles, while the others must wait until they receive a token.

[0011] Furthermore, WO 2011 / 134 861 A1 discloses a distributed power supply system comprising a plurality of rechargeable power supply units, such as electric vehicles, connected to a common power grid at remote locations. A distribution controller is configured to control the power supply of the plurality of rechargeable power supply units according to calculated charging priorities.

[0012] DE 10 2005 025 954 A1 discloses a battery charging system consisting of a cable system connecting several rechargeable battery circuits (BS1-BS100). Each battery circuit contains a charge controller (LR1-LR100) and a rechargeable battery (B1-B100).

[0013] WO 2010 / 039 863 A1 discloses a power control system for vehicles. This system consists of an electrical system, a battery, a power interface (connected to the electrical system), a communication interface, a control unit (coupled to the electrical system and the communication interface), and a memory connected to the control unit. The memory contains executable instructions for the control unit. These instructions enable the reception of power consumption parameters from an external power controller via the communication interface, the activation of the electrical system to access an external power source via the power interface, and the forwarding of power to charge the battery.

[0014] Today's electric vehicles are mostly charged uncontrolled. The charging process begins as soon as the vehicles are connected to the grid. Since similar daily behavior, such as that of commuters and the fact that vehicle charging takes several hours, results in a very high level of simultaneity, uncontrolled charging represents a significant burden. The high expected simultaneity in the charging of electric vehicles (e.g., after-work peaks) can overload older or weaker grid structures, since grids are designed based on very low simultaneity of typical consumers. Distribution transformers and cables / overhead lines could be thermally overloaded, resulting in a reduced service life and, in the worst case, equipment failure.

[0015] The present invention is therefore based on the object of reducing network overloads caused by simultaneous charging processes triggered by electric vehicles and of providing a charging control system that reduces the simultaneity in charging the vehicles with energy and ensures coordination of the charging processes at the charging stations as long as the vehicle is at the charging station.

[0016] This object is achieved by a charging control system having the features of claim 1 and a method for the coordinated charging of electric vehicles having the features of claim 5. Preferred embodiments can be found in the subclaims.

[0017] The core of the invention lies in a decentralized charging controller for determining the sequence of individual charging processes for vehicles at charging stations. The charging controller contains devices for transmitting transmission orders to individual charging stations. The charging control system according to the invention further comprises a communication device connected to the decentralized charging controller to ensure a secure communication process among the network participants. For data exchange among the network participants, the communication device has devices for transmitting a network vector that carries data about the charging control function and network information for the vehicles and is readable and writable by the charging stations within the communication chain. The decentralized charging controller prioritizes the charging process based on the charging parameters previously specified in the network vector by the network participants.

[0018] The charging stations can therefore communicate with each other and agree on an optimal charging sequence. The difficulty of coordinating the charging of the vehicles lies in the fact that the charging request is transmitted to a coordination instance, which then performs the charging prioritization. This is achieved through a simple, decentralized charging control system that maps the charging urgency to individual waiting times via a charging protocol.

[0019] The invention developed solves this problem by having the charging stations communicate with each other and agree on the optimal charging sequence. This is done using simple, decentralized charging rules that map the charging urgency to individual waiting times. As soon as a charging spot becomes available in the network, or sufficient free network capacity is detected, all charging stations wait according to their individually calculated waiting time until the charging spot is blocked by a station for the duration of the charging (waiting time function). The station with the shortest individual waiting time is the first to take over the free charging capacity. The charging station with a high urgency receives a short waiting time, and the lowest urgency receives the longest waiting time. Charging is coordinated indirectly without the need for a central authority. This means that the vehicle with the most urgent charging request receives the free charging spot first.Waiting times are determined individually for each charging station using the defined waiting time function and can be expanded to accommodate additional vehicles without discrimination. Vehicles are prioritized according to charging urgency. Installation effort is reduced because few additional components are required.

[0020] If a vehicle realizes that it will not be charged by the desired departure time because it does not have a free charging slot, it can send a priority charging call to the vehicles (or charging stations) currently charging (cancellation function). These vehicles register the special situation and check for themselves whether they can release their charging slot without running the risk of not being charged themselves. If this is the case, the cancellation time function indirectly selects the least critical vehicle (since it has the shortest cancellation time). This vehicle releases the charging slot, and the "emergency" vehicle can take over the charging slot. This allows the system to react to extreme scenarios and, in an emergency, can give priority to vehicles with the highest charging priority by only allowing non-critical, charged vehicles to give up charging slots to critical vehicles.

[0021] The charging stations barely exchange data with each other. No private driving data is disclosed, and it is not possible to track which user is present on the network, when and where, and what charging energy they require. The communication protocol includes a set of rules that ensures robust communication between the charging stations. Unforeseen disruptions are filtered out and do not lead to system failure. Serial communication between the charging stations makes it possible to bridge longer distances between charging stations; not every station needs to be able to communicate with every other station.

[0022] A key advantage of the present invention is the non-discriminatory and, above all, anonymous coordination, without the transmission of private driving data such as arrival / departure times, ensured by these simple charging rules. This ensures high data security for sensitive information. With the decentralized charging rules, very little data needs to be exchanged between vehicles, enabling the use of very narrowband communication channels. The failure of one or more charging stations can be easily compensated for by the developed system, allowing the remaining charging stations to continue operating safely and with minimal impact on the grid.

[0023] Since the charging stations, which are permanently connected to the grid, communicate directly with each other via powerline, for example, and each can serve as a repeater to increase range, infrastructure costs remain very low. Common IP-based standard components can be used. This offers the advantage for grid operators of being able to plan for the additional grid load caused by electromobility, something that has not been possible to date and could hinder the spread of electromobility.

[0024] A simplified charging coordination process based on the developed charging rules can be implemented as follows: As soon as a charging spot becomes available in the network, or sufficient free network capacity is detected, all charging stations wait according to their individual waiting times until the charging spot is blocked by a station for the duration of the charging. The station with the shortest individual waiting time is the first to take over the free charging capacity. The charging station with a high urgency receives a short waiting time, and the lowest urgency receives the longest waiting time. This means that the vehicle with the most urgent charging request receives the free charging spot first. The waiting times are determined individually by each charging station using the specified charging control function or a prioritized charging control function.

[0025] The charging stations communicate with each other serially, meaning that not every vehicle or charging station needs to be able to communicate with every other one. This increases the range of the entire system and circumvents the range limitations of powerline systems. Definitions

[0026] A vehicle that is connected to a charging station has so-called vehicle parameters, preferably the arrival time, the departure time and the battery charge level.

[0027] The first vehicle parameter is the arrival time. This is a constant time and changes only relative to the current time in the timeline.

[0028] The departure time, like the arrival time, is a constant time and only changes relative to the current time in the timeline.

[0029] The vehicle's charge level determines the charging time. For reasons of longevity, it is always within the operating range of the battery.

[0030] Based on the vehicle parameters, a procedure was developed that allows vehicles to be differentiated according to their loading urgency. This procedure calculates a so-called shift time (see Fig. 1A). The shift time is a fundamental working parameter of the charging protocol. It is determined by the following formula: tdisplacement=(tdeparture−tarrival)−tchargingtime.

[0031] The postponement time is the time within which the charging duration can be postponed within the holding time. It is a time window that indicates how long a vehicle can start charging after arrival in order to be fully charged by the departure time. Basic protocol structure

[0032] In order to establish the context of the developed protocols, this section provides a summary of the tasks of these protocols.

[0033] Charging protocol: The task of the charging protocols is to determine the order in which the individual charging control processes are processed.

[0034] Communication protocol: The communication protocols ensure secure and stable communication between the individual participants.

[0035] In order to exchange information, both protocols are in contact with each other.

[0036] For decentralized charging, communication between the vehicles is necessary. The vehicles are connected to a charging station for charging. The charging station's job, in addition to charging the vehicle, is to establish communication with the other charging stations.

[0037] The task of the communication protocol is, on the one hand, to ensure a regulated communication process and, on the other hand, to resolve conflicts when several participants start transmitting at the same time. Network vector

[0038] The data exchange between vehicles is controlled via a network vector. The network vector is a column vector with four elements. The first element contains the charging count. This indicates how many vehicles are currently charging on the network. The second element contains the preferred charging call. This is set by a vehicle with critical vehicle parameters. The third element contains the vehicle identification (ID). The vehicle ID is a randomly generated number that the sender assigns to the network vector.

[0039] On the one hand, it is important for finding a solution in the event of a transmission conflict. On the other hand, the sender uses the vehicle ID to recognize the network vector it has sent. The last element of the network vector is preferably the signature. This signature is required for the regulated communication process. It indicates where in the communication chain the network vector has already been. Additional elements can be added to the network vector as needed. Communication propagation

[0040] The network vector is distributed within the communication chain from the charging stations (see Fig. 1B). There are three different participants in a communication chain. A distinction is made between left, right, and center. The participants on the far left and right only exist once; the remaining participants in the chain are middle participants. A transmission order is sent to the charging station via the charging protocol. The task of the communication protocol is to distribute the network vector to the other charging stations.

[0041] Four different transmission orders can be assigned via the charging protocol. The first transmission order is to send a transmission request. The vehicle increments the charging count and writes its randomly generated ID to the network vector. If the vehicle receives a network vector with the same vehicle ID, the transmission request has been confirmed. The second and third transmission order options are to set or reset a preferred charging call. The final option is to notify the release of a charging point currently in use.

[0042] Data exchange between the communication units is possible in both directions. However, a transmission request is only sent in one direction to prevent the occurrence of different data vectors in the network. Complication of two-way propagation

[0043] An example will demonstrate how and why different network vectors can arise in two-way propagation. There are six participants in this communication chain. Participants one, three, and five begin transmitting. Horizontal arrows represent a transmitted network vector. Vector X is the current network vector in the communication chain before transmission begins. Each of the three vehicles transmits a new network vector based on this network vector. In this example, only one charging point is available to the vehicles.

[0044] Participant one sends data vector A, and participant five sends data vector C. Both participants send a charging request and have incremented the charging count. The two data vectors can now only be distinguished by their third digit, the vehicle ID. The third sending participant resets its preferred charging call. It sends data vector B. A data conflict will occur between participants two and four due to the three different data vectors A, B, and C. If a conflict occurs between two transmission requests, the decision is made in favor of the larger vehicle ID.

[0045] Participants two and four negotiate a solution among themselves and send the new data vector back in both directions. Vector A and B create vector D, and vectors B and C create the new vector E. With the conflict resolved, participants two and four transfer their data vectors to the charging protocol. The first participant receives data vector D. The transmission process ends for them, and they transfer data vector D to their charging protocol. For example, it may be the case that data vector D contains the vehicle ID of the first participant. Participant one confirms the charging request to this participant.

[0046] Participant six receives data vector C. As the outer participant, it passes the data vector to the loading protocol and sends it back again. Participants one, two, four, and six, for example, pass a data vector according to their loading protocol. The data vectors that were passed on differ from one another. This means that participants three and five are faced with a conflict resolution process. Participant three creates the new data vector G from data vectors E and D. Participant five creates the new data vector F from vectors E and C. The data vectors F and G do not differ from one another. For this reason, no new conflict arises, and all participants pass the new data vectors to their loading protocols. When data vector G is passed to the loading protocol, participant three confirms the loading.

[0047] This example shows that two-way propagation can temporarily result in different network vectors between vehicles. In this case, the result was that two vehicles started charging even though only one charging point was available.

[0048] In general, two-way propagation creates a separate, independent data loop between two senders. This example also describes an extreme case with a very low probability of occurrence. To prevent this scenario, some changes and security precautions must be added to the communication protocol. The solution to this is unilateral transmission initiation.

[0049] With the one-sided transmission start solution, the network vector is only sent to the right-hand node when a transmission request is received. If the far-right node receives a transmission request from the loading protocol, it always transmits to the left.

[0050] If a participant receives a network vector from the left, for example, it is forwarded to the right. When the data arrives at the right outer edge, the right-hand signature is added to the network vector. With the right-hand signature, the network vector continues to travel from participant to participant to the left until the left outer edge is reached.

[0051] After a participant has started sending or received a network vector, the participant enters a send mode. In this send mode, the communication protocol is blocked by the load protocol. Due to this blocking, the load protocol can no longer send new send requests to the communication protocol.

[0052] The block is only lifted upon receipt of a network vector with a left-sided signature. When the network vector reaches the left end of the communication chain, the left-sided signature is added to the network vector, as already described. The network vector is sent with the left-sided signature via all participants to the right end of the communication chain. Upon receipt of the left-sided signed network vector, not only is the block lifted, but the network vector is also transferred to the loading protocol.

[0053] Comparing one-way transmission with two-way propagation, the communication path within one-way transmission is longer and therefore somewhat more time-consuming. However, the advantage is that different network vectors can never occur within the communication chains, thus avoiding unexpected protocol sequences. Participant

[0054] The participants can be in three different states. The first state is the listening state. Here the participant only hears whether it is receiving a network vector from its neighbor or whether it is receiving a send request from the loading protocol. The second state is reception from the right. This state is assigned two properties. The first property is that the communication protocol is blocked compared to the loading protocol. This means that no new send request can be issued by the loading protocol. The second property of this state is that the participant expects a data vector with the signature from the right. The third state is reception from the left. A participant in this state expects a network vector with the left signature.

[0055] Fig. Figure 2A shows the flow diagram of the far right subscriber. Initially, the subscriber is in the listening-from-left state. It checks whether a network vector is being sent to it from the left. If this is not the case, it asks whether the loading protocol has issued a send request. The first state ends when a network vector arrives from the left. If a signal is received from the left, the right signature is added to the received network vector and the network vector is sent back to the left. The subscriber now jumps to state three, listening to the right. The subscriber expects a network vector from the left with the signature R / L. This state only ends when this signature is received. While the subscriber is in state three, the communication protocol is blocked from the loading protocol.Only upon receipt of an R / L signed network vector does the participant return to state one and transfer the network vector to the loading protocol via an interrupt.

[0056] In Fig. Figure 2B shows the flow diagram of the participant on the far left. The participant is initially in state one, listening to the left. The participant expects a network vector with the signature R or checks whether a send request has been issued by the loading protocol. If a send request has been issued by the loading protocol, a send flag A is set. Before the participant jumps to state two (send to the right), it sends the network vector to the right. When the second state is reached, the communication protocol is blocked from the loading protocol. If a network vector with the signature R is now received, it also receives the signature L. The send flag A is used to decide whether a conflict arises. The network vector is forwarded to the right and, via an interrupt, passes the network vector to the loading protocol and then jumps back to state one.

[0057] For a middle participant, a distinction must be made as to where in the communication chain the participant is located (see Fig. 2C). If the subscriber is second from the right, they must also listen to the right in order to detect a transmission request from the far right. This distinction is made using the comparison variable. In state one, the subscriber checks whether a network vector has been sent to them or whether a transmission request was issued by the loading protocol. If a transmission request has been received, the transmission flag S is set and the subscriber jumps to state two after transmitting on the right. If a network vector is received, the received network vector is sent to the right and the subscriber jumps to state two, listening from the right. In state two, a network vector with a signature R is expected. If an unsigned network vector arrives at the subscriber, it is deleted. In this state, the communication protocol is blocked from the loading protocol.Upon receiving an R-signed network vector, the participant jumps from state two. It compares the received network vector based on the transmit flag and transmits the network vector to the left. After transmitting, it enters state three (listening to the left).

[0058] In state three, a network vector with the signature R / L is expected. Only upon receiving such a network vector does the node leave state three, transfer the received network vector to the loading protocol via the interrupt, and return to state one. Security requirement and conflict resolution

[0059] If more vehicles than those authorized for a given network section begin charging, this can lead to unwanted network overloads. To prevent unwanted simultaneous charging and avoid risking network overload, decentralized control requires that each vehicle has the same network vector at all times. Conflict resolution is required to avoid discrepancies.

[0060] For example, a vehicle can send four possible changes via the network vector. This would mean that 16 different possibilities could arise in the event of a conflict. If a conflict occurs, the 16 possibilities are divided into four cases. Only the first three positions of the network vector are compared. The fourth position, the signature, is irrelevant for the comparison.

[0061] Case 1 affects all network vectors whose charging number and preferred charging call are the same, but there are different vehicle IDs. This conflict arises, for example, when both participants send a charging request at the same time, terminate charging at the same time, or both participants set or reset a preferred charging call at the same time.

[0062] Case 2 covers vectors where the charging location and the preferred charging call are different. This case occurs when participant A begins charging and participant B sets or resets the preferred charging call. Another possibility is the release of the charging location by participant C ending charging and participant D setting or resetting the preferred charging call.

[0063] Case 3 consists on one side of a participant sending a charging request and on the other side of a participant sending a charging end.

[0064] Case 4 describes the network vectors where a preferred load call is set and a preferred load call is reset at the same time.

[0065] The first position in the data vector is the number of loads, the second position is the preferred load calls and the third position is the vehicle ID. Conflict cases

[0066] The following examples illustrate conflict resolution. For example, participant six begins sending a network vector at the same time as participant five. After participant six has sent network vector A, it receives network vector B. This creates a conflict because the vector does not have the expected left signature and is subsequently deleted. Participant six waits until it receives a network vector with the left signature. After participant five has sent network vector B, it immediately receives network vector A. Participant five then resolves the resulting conflict between the received network vector A and the network vector B sent at the beginning. The conflict is therefore resolved by forwarding network vector C to the left.

[0067] A left-sided conflict is handled according to the same principle as a right-sided conflict: After sending network vector B, participant two waits until a network vector with the left signature, network vector C, arrives. The conflict between vectors A and B is negotiated by participant one.

[0068] Another example illustrates a conflict between two middle participants. Participant four, for example, starts sending a network vector to the right. Shortly afterwards, participant three receives a send request and sends network vector B to participant four. Participant four waits for a right-sided signed network vector from the left. As soon as it receives network vector A, participant four sends network vector A on to participant three and expects a network vector with the left signature from the left. Participant four will first receive network vector B sent by participant three and delete it because of the missing signature. The conflict between network vectors A and B is negotiated by participant three. This sends the resulting solution vector C on to the left. Both participants now wait for a left-sided network vector with a left signature.

[0069] In another example, three nodes begin transmitting simultaneously. Devices one and five want to begin transmitting and submit a transmit request. Device three simultaneously resets its preferred load call. A column vector X is the current network vector before transmitting begins.

[0070] In the first step, network vector A is sent from node one to node two, network vector B from node three to node four, and network vector C from node five to node six. The three nodes one, three, and five are now in the second state. They are blocked from the loading protocol and expect a data vector with the right signature from the right.

[0071] In the second step, network vector A is sent from participant two to participant three. Network vector B is sent from participant four to participant five, and network vector D is sent from participant six to participant five.

[0072] After the second step, participants two and four are in state two. The sixth participant is in state three. It waits for a data vector with a left signature from the left side.

[0073] In the third step, participant five receives the network vector D and compares it with the network vector C sent by it. Since only the first three digits of the network vector are compared, no conflict arises here. Participant five then sends the network vector D to the left to participant four and switches to the third state. Participant five will see the network vector B sent by participant four in the second step. However, it expects a network vector with the left-sided signature and then deletes the network vector B. In the fifth step, participant four sends the network vector to participant three and switches to the third state. In the sixth step, participant three receives the network vector D. This is where the first conflict arises: the network vector B sent in step one is now compared with the received network vector D. After the conflict has been resolved, the newly created network vector E is sent on to participant two.Participant three jumps to state three and will first receive the network vector A sent in the second step, but will delete it based on the incorrect signature.

[0074] In the seventh step, network vector E is received from participant one. Participant one compares network vectors A and E. This conflict creates network vector F. Before network vector F is sent via participants two, three, four, and five to participant six, the left signature is added to it. In the eighth step, participant one sends the left-sided signed network vector F to the left. After sending, the blocking with respect to the loading protocol is lifted and the data is also transmitted to the loading protocol. Upon receipt of network vector F, participants two to six each lift their blocking with respect to the loading protocol and transmit the received network vector F to the protocol. In the case of a unilateral start of transmission, it can be seen that even if several participants start transmitting, only one network vector was generated and all sent network vectors were nevertheless included in the conflict cases. Charging protocol

[0075] Within the scope of this invention, a decentralized charging protocol was developed. Three additional protocols were developed for comparison. Six different control modes can be distinguished: no control, minimum power control, centralized control, decentralized control, dynamic waiting time, and preferential charging.

[0076] To divide a day into fixed points in time, the day is divided into 86,400 seconds. Each second represents a point in time in which a specific sequence of processes is executed. For the sake of clarity, the individual processes will be referred to as functions.

[0077] In Fig. Figure 3 shows eight functions, numbered from a to h. These functions are part of the five developed controls. Before describing the controls individually, each of the eight functions will first be briefly explained for a better overview.

[0078] The task of the network vector (a) is to pass information on to the other network participants. All participants have read and write access to this vector. If, for example, a vehicle finishes charging, this is written to the network vector. This informs the other vehicles that charging has ended. The charging start function (b) calculates the vehicle's charging time and has the task of entering the charging information into the vehicle's network vector. The charging end function (c) ends the charging of the vehicle and marks the vehicle as fully charged. The charging end function writes the completion of charging information into the network vector.

[0079] The individual waiting time function (d) calculates a waiting time for the vehicles based on the vehicle data. The charging interruption function (e) has a similar task to the charging end function. It stops charging the vehicle even if the battery is not fully charged and writes the end of charging into the network vector. The vehicle search function (f) finds those vehicles among all the vehicle participants that are waiting for a charging space. The vehicles are sorted using the vehicle data in the sorting function (g). The last function to be described here is the interruption time function (h). It calculates an interruption time for charging vehicles, after which charging is terminated. No control

[0080] When a vehicle arrives at a charging station, it doesn't know how many other vehicles are connected to that network section and currently charging. This means that the number of vehicles charging simultaneously is at its maximum. This becomes problematic when several vehicles are charging at the same time in that network section and the maximum permissible power of the transformer or the network section is exceeded. A network vector, whose task is to share network information with the other vehicles, does not exist in uncontrolled control. Uncontrolled control is intended to serve as a reference case compared to decentralized control.

[0081] When a vehicle is connected to the charging station, the protocol detects that the vehicle has arrived and switches to the "start charging" function. The "start charging" function calculates a charging time for the vehicle. Once this charging time is complete, the protocol switches to the "end charging" function. In the "end charging" function, the vehicle is marked as fully charged. The vehicle's departure time is queried based on the vehicle data. If the vehicle must depart while it is still charging, the "abort charging" function is started. The abort charging function marks the vehicle as aborted and has departed. This sequence is repeated every second for every vehicle in the network section. Minimum power control

[0082] The minimum power charging protocol uses the vehicle's holding time rather than its maximum charging power. When a vehicle arrives at a charging station, the charging power is first calculated. The calculated charging power is precisely sufficient to fully charge the battery by the time the vehicle departs. After charging begins, the next task of the protocol, at the departure time, is to complete charging. Charging a vehicle at full charging power does not automatically mean that the vehicle will finish charging at the exact time of departure; the charging time depends on the battery's charge level. Central control

[0083] Centralized control means that there is a central control unit to which all vehicle data is transferred upon the vehicle's arrival. Using this vehicle data, the control unit optimally coordinates the charging of the vehicles.

[0084] At the central control system, a predetermined sequence of tasks is performed every second. First, a check is made to see if a charging bay is available. If so, the search function is used to locate vehicles waiting for a charging bay. The found vehicles are then sorted according to their vehicle parameters.

[0085] The protocol has four possible sorting methods: sorting by arrival times, departure times, charge level, and shift times. If three vehicles are waiting for a charging spot, the central control unit calculates the shift time for all vehicles. The vehicle with the shortest shift time is ultimately assigned the charging spot. When charging begins, the vehicle is assigned a charging time. Once the charging time is over, the protocol terminates charging for the participant. If a vehicle's battery is not fully charged upon departure, the vehicle must abort charging.

[0086] If the tasks of a structured process are distributed from one processor to several, the process is decentralized. If the coordination task of the charging stations is no longer assigned to a central unit, but to the individual vehicles themselves, a centralized control system becomes a decentralized one. Dynamic waiting time

[0087] The decentralized charging protocol requires communication within the vehicles. Important network information is distributed among the participants via a network vector.

[0088] To prevent charging from starting immediately upon a vehicle's arrival at the charging station, a waiting time has been introduced. This waiting time is calculated by passing the vehicle parameters to a waiting time function. Once the waiting time has elapsed, the vehicle checks the network vector to determine whether a charging point is available and begins charging based on that point.

[0089] Firstly, the waiting time is calculated after the vehicle arrives at the charging station; secondly, the waiting time is recalculated for all waiting vehicles after one vehicle has finished charging. The different waiting times of the vehicles result in a decentralized start of charging. This decentralized start of charging can be compared to a race for a charging spot: The vehicles wait their individual waiting time and, after this time, check whether a charging spot is available. The vehicle with the shortest waiting time wins the race and thus also the charging spot.

[0090] The flowchart of the decentralized dynamic control protocol is shown in Fig. 4. After the vehicle arrives, the dynamic charging time is calculated. The next protocol process is a waiting time query. This leads to a query about the charging location and, if both queries are successful, calls the start of charging for the vehicle. This start of charging is written to the network vector. The next process is a query about the charging time. Once this has expired, charging is terminated and entered into the network vector. A new waiting time is calculated for the waiting vehicles. If a vehicle is currently charging but has to leave due to its departure time, charging is aborted. A new charging time is calculated for the waiting vehicles.

[0091] There's a separate waiting time function for each vehicle parameter. Charging can thus be controlled in four different ways: arrival, departure, battery level, and delay time.

[0092] The next example explains the different control variants in more detail using three vehicles. The following assumptions were made: Vehicle C is charging and only one charging bay is available. Vehicle A and Vehicle B have different vehicle parameters, but both are waiting for a charging bay. By arrival time

[0093] The individual waiting time is calculated using a waiting time function (see Fig. 5A). Fig. Figure 5B shows the waiting time function for the arrival time control. The waiting time is plotted on the Y-axis in seconds, and the X-axis is t ankunft in hours. The waiting time function can be calculated using the formula Fig. Describe 5B.

[0094] t ankunft is calculated from the arrival time and the current time. tankunft=current time−arrival time.

[0095] Fig. 5A shows vehicles A and B. The waiting time function can be configured as in Fig. 5B, divide it into two parts. If the t ankunft between 0 and 8 hours, the function has a very steep gradient. Due to the gradient, the displayed waiting times are easily distinguishable from each other. If t ankunft between 8 and 24 hours, the waiting time function has only a very slight gradient. By departure time

[0096] For control after the departure time, the waiting time function (see Fig. 6A). You will be t (abfahrt) The function can be defined by the formula according to Fig. 6B describe.

[0097] The first part of the waiting time function applies to the range of t anfahrtbetween 0 and 8 hours. Here, the waiting time function has a very large slope. The large slope is needed to clearly distinguish the waiting times from each other. The second part of the waiting time function applies to the range from t anfahrt between 8 and 24 hours. Here, the waiting time function has a very slight slope. According to battery level

[0098] The vehicles arrive at the charging station with different battery levels. This means that the vehicles require different charging times. If the vehicles are controlled according to their battery level, the waiting time function t warte = t max / 50 x charge level is used to calculate the waiting time. The charge level is passed to the waiting time function as a percentage.

[0099] The shift time was previously referred to as the basic working parameter of the charging protocol. The shift time is preferably composed of all known vehicle parameters. The shift time is calculated using the formula: tverschiebe=tankunft−tabfahrt−tladedauer

[0100] Fig. 7 B shows the waiting time function calculated using t verschiebe a waiting time is calculated. The waiting time function is defined by the formula in Fig. 7B below and is divided into two parts. Located t verschiebe between 0 and 3 hours, the function has a very high slope to better distinguish the displayed waiting times. In the range for t verschiebe between 3 and 24 hours, the waiting function has a small gradient. Preferred cargo

[0101] In the case of preferential charging, it is assumed that vehicle A with a very long waiting time is blocking the charging point. If vehicle B with a short waiting time and an earlier departure arrives later than vehicle A, it has little chance of being charged. The preferential charging model is intended to make it possible to return charging vehicles to standby mode, thus allowing vehicles with critical vehicle parameters to make an interim charge.

[0102] This model was based on dynamic control based on the shift time. Compared to the other control models, this model yielded the best results because all vehicle parameters were considered.

[0103] Fig. Figure 8 shows the flowchart of the charging protocol. After the vehicle arrives, the individual waiting time is calculated. In the next process, the waiting vehicles are checked for a preferred charging call. If there is a preferred charging call, a termination condition is set for the charging vehicles. If a charging vehicle fulfills this termination condition, a termination time is calculated based on the remaining time. The next process of the protocol checks the waiting times. If a waiting time has expired and a charging slot has become available, the vehicle can begin charging. This is then written to the network vector. After checking the waiting times, the charging duration is checked in the next process. Once charging is complete, the vehicle is removed from the charging slot. A new waiting time is calculated for the remaining vehicles. Next, the termination time is checked.If this time has expired for a vehicle, the vehicle aborts charging and a note is made in the network vector. If a vehicle has to leave during charging due to the departure time, it will also abort charging. A new waiting time is then calculated for the waiting vehicles.

[0104] Fig. Figure 9A shows the waiting function of the preferred loading call. The formula below describes this function. The time t verschiebe the function. Based on this time, the wait function determines a waiting time. Compared to the control without a preferred loading call, the wait function is divided into three parts. If t verschiebe between 3 and 24 hours, the waiting function has a very low gradient. If t verschiebe But now in the range of 1 / 5 and 3 hours, the slope of the waiting function is very large. If the time t verschiebeless than 1 / 5 of an hour, the vehicle has critical parameters and must be charged as quickly as possible and sends a priority charging call.

[0105] The following example will explain the advantage of preferential loading using two vehicles, step by step.

[0106] There is one charging station available and no vehicle is at the charging station. The arrival of the first vehicle A (see Fig. 9A) the vehicle's travel time is first calculated. Based on this travel time, a waiting time is determined ( Fig. 9B).

[0107] After the waiting time has elapsed, vehicle A checks the network vector to see if a charging slot is available. In this example, a charging slot is available, and vehicle A begins charging. While vehicle A is charging, another vehicle, vehicle B, arrives at the network section at approximately 12 noon.

[0108] Vehicle B first calculates the shift time based on the vehicle parameters. Since t verschiebe If the charging time is less than 1 / 5 of an hour and the vehicle wants to be charged as quickly as possible, vehicle B sets a priority charging call. This priority charging call triggers a check of the termination condition for all charging vehicles.

[0109] The termination condition is met if t rest > 0, where t rest = t Haltedauer - 2 xt Ladedauer If a charging vehicle meets this termination condition, it will not immediately terminate charging and will release the charging space to the preferred charging caller. The vehicle will be allocated a charge based on t rest and the termination function calculates a termination time. The termination function is calculated from tabbreak=tmax / 12×trest

[0110] A termination time is necessary for the charging vehicles because, in the event of a priority charging call, all charging vehicles would otherwise give up their charging space, even though only one is required. Then, one of the vehicles would unnecessarily release its charging space. The termination time can prevent such a situation. After one of the vehicles has released the charging space, the vehicle with the priority charging call takes over the charging point. Based on the network vector, the other vehicles recognize that termination is no longer necessary.

[0111] The following example describes a case where a termination condition must be met: Vehicle A will hand over the charging space to vehicle B after the termination time has elapsed, and vehicle B can begin charging. After vehicle B has finished charging, vehicle A calculates a waiting time again and terminates the charging process after the waiting time has elapsed. Short character description Fig. 1A Shift time for vehicle A, Fig. 1B communication chain Fig. 2A Communication for right-hand participant Fig. 2B Communication for left participant Fig. 2C communication for medium participants Fig. 3 Functions of the controls Fig. 4 Flowchart for dynamic control Fig. 5A Example arrival time Fig. 5B Waiting time function arrival time Fig. 6A Example departure time Fig. 6B Waiting time function Departure time Fig. 7A Example shift time Fig. 7B Waiting time function shift time Fig. 8 Preferred loading flowchart Fig. 9A Waiting function postponement time - preferred charge Fig. 9B Waiting time vehicle A

Claims

[1] Charging control system for the coordinated charging of electric vehicles in the low-voltage distribution network with energy, comprising a decentralised charging control system for determining the sequence of individual charging processes for the vehicles at charging stations, whereby the charging control system comprises devices for transmitting transmission orders to individual charging stations, b. a communication device connected to the decentralised charging control system to ensure secure communication between the network participants, characterized bythat the communication device for exchanging data between the network participants has devices for transmitting a network vector which carries data on the charging control function and network information for the vehicles and is readable and writable by the charging stations within the communication chain, whereby the decentralised charging control takes over prioritisation of the charging process on the basis of the charging parameters previously specified in the network vector by the network participants. [2] Charging control system according to claim 1, characterized by that the communication of the communication device and the data exchange takes place via power lines. [3] Charging control system according to claim 1 or 2, characterized by that each vehicle has the same network vector at all times and that the network vector includes the loading number, the preferred loading call, the vehicle identification number (vehicle ID) and, if applicable, a signature. [4] Charging control system according to one of the preceding claims, characterized by that the charging control comprises a charging protocol and the communication device comprises a communication protocol containing parameters for charging coordination between the vehicles. [5] A method for the coordinated charging of electric vehicles in the low-voltage distribution network with energy, in which a decentralised charging control determines the sequence of individual charging processes for the vehicles at charging stations, whereby the decentralised charging control transmits transmission orders to individual charging stations via a charging protocol and in which a communication device connected to the decentralised charging control ensures a secure and stable communication process among the network participants via a communication protocol, characterized bythat the communication device transmits at least one network vector for data exchange between the network participants, which carries data about the charging control function and network information and is distributed within the communication chain by the charging stations, and that a prioritization of the charging process is carried out by the decentralized charging control on the basis of predetermined parameters. [6] Method according to claim 5, characterized by that the data exchange between the charging stations takes place serially via one-way or two-way propagation, whereby each network participant has read and write rights to the network vector in order to specify or enter charging parameters or, if necessary, delete the vector in the event of a conflict. [7] Method according to claim 5 or 6, characterized by , that a. the start of charging is recorded and entered into the vehicle’s network vector, b. an end-of-charge function stops the charging of the vehicle and marks the vehicle as fully charged, c. the end of the loading is written into the network vector by the end-of-load function, d. an individual waiting time function calculates a waiting time for the vehicles based on the vehicle data, e. a charging termination function stops charging the vehicle, even if the vehicle is not yet fully charged and writes the end of charging into the network vector, f. a search function sorts those vehicles that are waiting for a charging point. [8] Method according to one of the preceding claims, characterized by that the charging controller reads data about the start of charging, the end of charging or the termination of charging from the network vector or writes it into the network vector. [9] Method according to one of the preceding claims, characterized bythat to resolve conflicts, the elements of a received network vector such as the number of loads, the preferred load call, the vehicle identification number of a vehicle are compared with the network vector sent to another vehicle and in the event of a conflict, the network vector is deleted and a new network vector is generated. [10] Method according to one of the preceding claims, characterized by that the decentralized control of the charging processes takes place depending on the arrival time, departure time, the battery level in the vehicle or the shift time, whereby the shift time defines the time in which the charging time can be shifted within the holding time and can be calculated using the following formula: tshift=(tdeparture−tarrival)−tloading time

Images