Method for determining electric energy consumption of charging vehicle, medium and electronic device

Abstract

The application provides a charging vehicle power consumption determination method, a medium and an electronic device, relates to the field of vehicle charging, and comprises the following steps: a working charging vehicle performs a charging task at a first preset power; if the working charging vehicle is disconnected from a cloud platform, a reconnection request information is sent, and the working charging vehicle is adjusted to a second preset power; if the working charging vehicle is not successfully reconnected, a connection module is restarted; if the working charging vehicle is successfully reconnected within a first time window, the working charging vehicle continues to perform the charging task at the first preset power until the charging is completed; a charging completion signal is sent to the cloud platform; the cloud platform acquires GYT; and the power consumption of the working charging vehicle corresponding to the charging completion signal is generated according to the GYT, the first preset power and the second preset power. According to the application, a certain reconnection time is reserved for the disconnected working charging vehicle, the failure rate of an order is reduced, the charging power is reduced during the waiting period for reconnection, and accurate charging can be realized even if the charging fails finally.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of vehicle charging, in particular to a method for determining the electric energy consumption of a charging vehicle, a medium and an electronic device. BACKGROUND

[0002] In a vehicle charging system, after the cloud platform receives a charging order of a user, the corresponding charging task is sent to the corresponding charging vehicle. After the charging vehicle receives the corresponding charging task, due to unstable network or equipment damage, etc., the charging vehicle may be disconnected from the cloud platform. When the charging vehicle is disconnected from the cloud platform, the cloud platform directly ends the order. If the user wants to continue charging, the user needs to place an order again, which has a high order failure rate and poor user experience. Therefore, there is an urgent need for a method for reducing the order failure rate and realizing accurate charging. SUMMARY

[0003] To solve the above technical problems, the present application provides a method for determining the electric energy consumption of a charging vehicle, a medium and an electronic device, which at least partially solves the problems in the prior art.

[0004] In the first aspect of the present application, a method for determining the electric energy consumption of a charging vehicle is provided, which is applied to a vehicle charging system. The vehicle charging system includes a plurality of working charging vehicles performing charging tasks and a cloud platform. Each working charging vehicle sends connection confirmation information to the cloud platform every predetermined time interval. If the connection response information from the cloud platform is received, it is determined that the working charging vehicle is not disconnected. If the connection response information from the cloud platform is not received for a predetermined number of times in succession, it is determined that the working charging vehicle is disconnected from the cloud platform.

[0005] The cloud platform is used to perform the following steps:

[0006] S110, in response to receiving a charging task of a user, the charging task is assigned to the corresponding working charging vehicle according to a predetermined assignment rule;

[0007] The working charging vehicle is used to perform the following steps:

[0008] S210, in response to receiving the charging task assigned by the cloud platform, the corresponding charging task is performed at a first predetermined power. Each charging task includes a corresponding target electric quantity.

[0009] S220, if disconnection from the cloud platform is detected during the execution of the charging task, a reconnection request information is sent to the cloud platform, and the second predetermined power is adjusted to continue the execution of the charging task within a first time window. The second predetermined power is less than the first predetermined power. The start time of the first time window is the time of disconnection from the cloud platform.

[0010] S230, if no connection response information is received within the first response time period of the first time window, restarting the connection module of the working charging vehicle; the connection module is configured to communicate with the cloud platform;

[0011] S240, if connection response information is received within the second response time period of the first time window, adjusting to the first preset power to continue the charging task until the corresponding target power is reached; and sending a charging completion signal to the cloud platform; wherein the time length of the first response time period is less than the time length of the second response time period; and the time length of the first time window is equal to the sum of the time lengths of the first response time period and the second response time period.

[0012] The cloud platform is further configured to perform the following steps:

[0013] S120, in response to receiving the charging completion signal, obtaining a first working time set GYT=(GYT1, GYT2, GYT3, GYT4) corresponding to the charging completion signal; wherein GYT1 is the start time of the working charging vehicle performing the charging task at the first preset power corresponding to the charging completion signal; GYT2 is the time when the working charging vehicle corresponding to the charging completion signal is disconnected from the cloud platform; GYT3 is the time when the working charging vehicle corresponding to the charging completion signal receives the connection response information from the cloud platform; and GYT4 is the time when the working charging vehicle corresponding to the charging completion signal completes the charging task.

[0014] S130, generating the power consumption of the working charging vehicle corresponding to the charging completion signal according to GYT, the first preset power and the second preset power.

[0015] In a second aspect of the present application, a non-transitory computer readable storage medium is provided, and the storage medium stores at least one instruction or at least one program, and the at least one instruction or at least one program is loaded and executed by a processor to implement the foregoing charging vehicle power consumption determination method.

[0016] In a third aspect of the present application, an electronic device is provided, comprising a processor and the foregoing non-transitory computer readable storage medium.

[0017] The present application has at least the following beneficial effects:

[0018] The charging car electric energy consumption determination method provided in the application, when the working charging car is disconnected from the cloud platform, preferentially uses a small cycle with shorter use time but relatively lower success rate to attempt to reconnect with the cloud platform (the Tbox module directly sends a reconnection request information to the cloud platform) in a first time window, and if the small cycle fails, a large cycle with longer use time but relatively higher success rate is used (the Tbox module is restarted) to reconnect with the cloud platform. Through the reasonable design of the sequence of the large cycle and the small cycle, the reconnection time is saved, and the success rate of reconnection is ensured. And at the time of disconnection, the corresponding charging power is adjusted from a first preset power to a lower second preset power, because in the related art, the cloud platform charges the working charging car according to the charging time and the charging power, and after the working charging car is disconnected from the cloud platform, the cloud platform stops timing the charging time, and the IBM module immediately stops charging, that is, the order is terminated, and if the user wants to continue charging, the user needs to place a new order to the cloud platform. In the application, in order to reduce the failure rate of the order, after the working charging car detects that it is disconnected from the cloud platform, the IBM module adjusts the charging power to a lower second preset power, and continues to perform the charging task in a set first time window. After disconnection, the fixed low-power charging is used, because compared with the high-power continuous charging, if the reconnection fails or the timing fails, a high-power charging time that cannot be charged will be formed, causing a loss, and the low-power continuous charging is used to wait for reconnection, reducing the loss caused to the corresponding merchant of the cloud platform due to the reconnection failure or the charging failure, and further, the fixed low-power charging time is set, so as to ensure accurate charging even if the final reconnection fails. The application attempts to reconnect while setting low-power charging after the charging car is disconnected from the cloud platform, and sets a fixed low-power charging time. On the one hand, a certain reconnection time is reserved for the disconnected working charging car, reducing the failure rate of the order, and on the other hand, the charging power is reduced during the waiting period for reconnection, so that accurate charging can be realized even if the charging fails finally. BRIEF DESCRIPTION OF DRAWINGS

[0019] In order to more clearly illustrate the technical solutions in the embodiments of the application, the following will briefly introduce the drawings needed in the embodiment description. Obviously, the drawings in the following description are only some embodiments of the application, and other drawings can be obtained by those skilled in the art without creative labor.

[0020] Fig. 1 The cloud platform execution step flow chart in one embodiment of the charging car electric energy consumption determination method provided by the embodiments of the application;

[0021] Fig. 2 The working charging car execution step flow chart in one embodiment of the charging car electric energy consumption determination method provided by the embodiments of the application;

[0022] Fig. 3 The cloud platform execution step flow chart of another embodiment of the charging vehicle electric energy consumption amount determination method provided in the embodiments of the present application is shown in the following table. DETAILED DESCRIPTION

[0023] The technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work fall within the scope of protection of the present application.

[0024] It should be noted that the terms "first", "second", and the like in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and do not necessarily indicate a specific order or sequence. It should be understood that the data thus used can be interchanged under appropriate circumstances, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product or server including a series of steps or units does not necessarily have to be limited to those steps or units clearly listed, but can include other steps or units not clearly listed or inherent to these processes, methods, products or devices.

[0025] It should be noted that various aspects of the embodiments described below are within the scope of the appended claims. It should be apparent that the aspects described herein can be embodied in a wide variety of forms and that any specific structure and / or function described herein is merely illustrative. Based on the present application, those skilled in the art should appreciate that one aspect described herein can be implemented independently of any other aspect and that two or more of these aspects can be combined in various ways. For example, an apparatus can be implemented and / or a method can be practiced using any number of the aspects set forth herein. In addition, such an apparatus can be implemented and / or such a method can be practiced using other structure and / or functionality in addition to or other than one or more of the aspects set forth herein.

[0026] Reference is made to Figs. 1-3 As shown in the drawings, the embodiments of the present application provide a charging vehicle electric energy consumption amount determination method, which is applied to a vehicle charging system, and the vehicle charging system includes a plurality of working charging vehicles performing charging tasks and a cloud platform; each working charging vehicle sends connection confirmation information to the cloud platform once every interval of a preset time period, and if connection response information from the cloud platform is received, it is determined that the working charging vehicle is not disconnected; if connection response information from the cloud platform is not received for a preset number of times in succession, it is determined that the working charging vehicle is disconnected from the cloud platform.

[0027] Here, the cloud platform communicates with each working charging vehicle that is performing a charging task, and the working charging vehicle includes a Tbox module and an IBM module. The Tbox is an important component in a telematics system, and its full name is Telematics Box. It integrates remote communication and information science technology and is used to communicate with the cloud platform. The IBM module is used to control the start and stop of the working charging vehicle performing a charging task and control the charging power. After the working charging vehicle is powered on, the Tbox module establishes communication with the cloud platform, and at the same time stores the unique identifier of the working charging vehicle sent by the IBM module; the IBM module starts charging at a first preset power according to the charging task of the user issued by the cloud platform. The Tbox module sends a connection confirmation information to the cloud platform every interval preset time period, for example, the preset time period is 3 seconds, and the connection confirmation information is a heartbeat packet. After receiving the connection confirmation information sent by any working charging vehicle, the cloud platform returns the corresponding connection response information, so as to determine that the cloud platform and the working charging vehicle are normally connected. If a working charging vehicle does not receive the connection response information of the cloud platform for a continuous preset number of times, it is determined that the working charging vehicle and the cloud platform are disconnected. If the cloud platform does not receive the connection confirmation information of the working charging vehicle within a preset connection time, it is determined that the working charging vehicle is disconnected.

[0028] The cloud platform is used to perform the following steps:

[0029] S110, in response to receiving a charging task of a user, the charging task is issued to a corresponding working charging vehicle according to a preset allocation rule.

[0030] Specifically, the cloud platform receives a charging task of a user, and allocates the charging task according to the current working condition and the remaining power of each charging working vehicle. The preset allocation rule here can be to preferentially allocate the charging task to an idle working charging vehicle with high remaining power.

[0031] The working charging vehicle is used to perform the following steps:

[0032] S210, in response to receiving a charging task issued by the cloud platform, a corresponding charging task is performed at a first preset power; each charging task includes a corresponding target power.

[0033] Specifically, each charging task includes a corresponding target power, for example, the target power can be 100% or 80%.

[0034] S220, if disconnection with the cloud platform is detected during the execution of the charging task, a reconnection request information is sent to the cloud platform, and adjusted to a second preset power to continue to execute the charging task within a first time window; the second preset power is less than the first preset power; the start time of the first time window is the time of disconnection with the cloud platform.

[0035] Specifically, if disconnection with the cloud platform is detected during the execution of the charging task, i.e., connection response information from the cloud platform is not received for a preset number of times in succession, the Tbox module of the working charging vehicle sends reconnection request information to the cloud platform, where the reconnection request information includes a unique identifier of the working charging vehicle.

[0036] On the other hand, the charging power of the working charging vehicle is adjusted from the first preset power to the second preset power when disconnection with the cloud platform is detected, because in the related art, the cloud platform charges the working charging vehicle according to the charging time and the charging power, and after the working charging vehicle is disconnected from the cloud platform, the cloud platform stops timing the charging time, and the IBM module immediately stops charging, i.e., the order is terminated, and if the customer wants to continue the order, the customer needs to place a new order with the cloud platform. In the present application, after the working charging vehicle detects disconnection with the cloud platform, the IBM module adjusts the charging power to a lower second preset power and executes within a set first time window. After disconnection, charging at a fixed low power is used because, compared to continuing charging at a high power, if reconnection fails or timing fails, a period of high-power charging time that cannot be charged will be formed, resulting in a loss. Continuing charging at a low power to wait for reconnection reduces the loss caused to the corresponding merchant of the cloud platform due to reconnection failure or charging failure, and further, a fixed low-power charging duration is set to ensure accurate charging even if reconnection ultimately fails.

[0037] S230, if connection response information is not received within the first response time period of the first time window, control the connection module of the working charging vehicle to restart; the connection module is used for communication with the cloud platform.

[0038] Specifically, if connection response information is not received within the first response time period of the first time window, i.e., reconnection with the cloud platform is not successful within the first response time period of the first time window, the connection module of the working charging vehicle is controlled to restart, i.e., the Tbox module is controlled to restart. Here, the time for the Tbox module to directly send reconnection request information to the cloud platform is less than the time for the Tbox module to restart, and the success rate of the Tbox module directly sending reconnection request information to the cloud platform is less than the success rate of the Tbox module restarting, so the present application preferentially uses the shorter cycle (the Tbox module directly sends reconnection request information to the cloud platform) and reconnects with the cloud platform using the longer cycle (the Tbox module restarts) if the shorter cycle fails. Through the reasonable design of the sequence of the longer cycle and the shorter cycle, the reconnection time is saved while the success rate of reconnection is ensured.

[0039] S240, if the connection response information is received in the second response time period of the first time window, adjusting to the first preset power to continue the charging task until the corresponding target power is reached; and sending a charging completion signal to the cloud platform; wherein the time length of the first response time period is less than the time length of the second response time period; and the time length of the first time window is equal to the time length of the first response time period and the second response time period.

[0040] Specifically, if the connection response information is received in the second response time period of the first time window, i.e. the large cycle reconnection is successful, at this time, the charging power is adjusted to the first preset power to execute the charging task until the corresponding target power is reached. And send a charging completion signal to the cloud platform after charging is completed. As an example: the first time window can be 90 seconds.

[0041] The cloud platform is also used to perform the following steps:

[0042] S120, in response to receiving the charging completion signal, obtaining the first working time set GYT=(GYT1, GYT2, GYT3, GYT4) corresponding to the charging completion signal; wherein GYT1 is the start time of the working charging car corresponding to the charging completion signal to execute the charging task with the first preset power; GYT2 is the time when the working charging car corresponding to the charging completion signal is disconnected with the cloud platform; GYT3 is the time when the working charging car corresponding to the charging completion signal receives the connection response information of the cloud platform; GYT4 is the time when the working charging car corresponding to the charging completion signal completes the charging task.

[0043] S130, generating the electric energy consumption of the working charging car corresponding to the charging completion signal according to GYT, the first preset power and the second preset power.

[0044] Specifically, the cloud platform obtains the corresponding start time, disconnection time, reconnection time and end time, and obtains the time actually charged with the first preset power and the time actually charged with the second preset power according to GYT. And calculate the final electric energy consumption to obtain the corresponding charging fee.

[0045] In the embodiment, when the working charging vehicle is disconnected from the cloud platform, a small cycle with shorter time but relatively lower success rate is used to reconnect with the cloud platform (the Tbox module directly sends a reconnection request information to the cloud platform) in a first time window. If the small cycle fails, a large cycle with longer time but relatively higher success rate is used to reconnect with the cloud platform (the Tbox module is restarted). Through the reasonable design of the sequence of the large cycle and the small cycle, the reconnection time is saved, and the success rate of reconnection is ensured. At the same time of disconnection, the corresponding charging power is adjusted from a first preset power to a second preset power. In the related art, the cloud platform charges the working charging vehicle according to the charging time and the charging power. After the working charging vehicle is disconnected from the cloud platform, the cloud platform stops timing the charging time, and the IBM module immediately stops charging, that is, the order is terminated. If the user wants to continue charging, the user needs to place a new order to the cloud platform. In the embodiment, in order to reduce the failure rate of the order, after the working charging vehicle detects the disconnection from the cloud platform, the IBM module adjusts the charging power to the second preset power, and continues to perform the charging task in the set first time window. After the disconnection, the fixed low power charging is used. Compared with the high power charging, if the reconnection fails or the timing fails, a high power charging time that cannot be charged will be formed, resulting in a loss. The low power charging is used to wait for reconnection, which reduces the loss caused to the corresponding merchant of the cloud platform due to the reconnection failure or the charging failure. Further, the fixed low power charging time is set, so that even if the reconnection fails finally, accurate charging can be ensured. In the embodiment, after the working charging vehicle is disconnected from the cloud platform, the working charging vehicle tries to reconnect and sets the low power charging, and the fixed low power charging time is set. On the one hand, the working charging vehicle disconnected from the cloud platform is reserved a certain reconnection time, and the failure rate of the order is reduced. On the other hand, the charging power is reduced during the waiting for reconnection, so that even if the charging fails finally, accurate charging can be realized.

[0046] In an exemplary embodiment of the present application, after step S230, the working charging vehicle is further configured to perform the following steps:

[0047] S250, if the connection response information of the cloud platform is not received in the first time window, the charging task is stopped; and the first time window is determined as a low power time window.

[0048] Specifically, if the connection response information of the cloud platform is not received in the first time window, the IBM module controls the working charging vehicle to stop charging at the end of the first time window.

[0049] The cloud platform is further configured to perform the following steps:

[0050] S140, a second working time set GET=(GYT1, GYT2) is obtained.

[0051] S150, generating the power consumption of the working charging vehicle according to the GET, the length of the low-power time window, the first preset power and the second preset power.

[0052] Specifically, in the embodiment, (GYT2-GYT1) is the charging duration corresponding to the first preset power; the length of the first time window is the charging duration corresponding to the second preset power; the power consumption is calculated according to the charging duration corresponding to the first preset power, the charging duration corresponding to the second preset power, the first preset power and the second preset power, and then the corresponding charging fee is obtained.

[0053] In an exemplary embodiment of the present application, if there is at least one key charging vehicle performing a charging task in a range with the working charging vehicle as the center and a distance corresponding to a preset proximity communication protocol as the radius, the working charging vehicle is further used to perform the following steps after step S220:

[0054] S260, obtaining a key time interval list set GT=(GT1, GT2, …, GTn) according to the preset proximity communication protocol; i=1, 2, …, n; wherein n is the number of key charging vehicles; GTi is the key time interval list of the ith key charging vehicle; GTi=(GTi,1, GTi,2, …, GTi,f(i)); j=1, 2, …, f(i); f(i) is the number of times that the ith key charging vehicle receives connection response information in the third time window; GTi,j is the time interval between the sending time of the connection response information and the corresponding connection confirmation information received by the ith key charging vehicle for the jth time in the third time window segment; the end time of the third time window is the start time of the first time window. i n i i i1 i2 ij if（i） ij

[0055] Specifically, the proximity communication mode in the preset proximity communication protocol can be Bluetooth, NFC, RFID, etc. In the embodiment, the distance between each key charging vehicle and the working charging vehicle is less than the distance corresponding to the preset proximity communication protocol, i.e., the working charging vehicle can communicate with each key charging vehicle using the preset proximity communication protocol.

[0056] ​​​​​​​​​Here, the time interval list of each key charging vehicle in a period of time before the disconnection time of the working charging vehicle (in the third time window) is obtained, where each time interval represents the time interval between the sending time of the corresponding connection response information and the sending time of the corresponding connection confirmation information. The time interval between any two adjacent connection confirmation information is fixed, but due to network fluctuations and other conditions, the time of receiving the corresponding connection response information can be different.

[0057] S270, obtaining a set of key time fluctuation values GTB=(GTB1, GTB2, …, GTBn) according to GT; wherein GTBi is the time fluctuation value corresponding to the i-th key charging vehicle; GTBi=(∑i=1n(GTi-avg(GT1))) / f(i); avg() is a preset average value determination function. i , …, GTB n ); wherein GTBi is the time fluctuation value corresponding to the i-th key charging vehicle; GTBi=(∑i=1n(GTi-avg(GT1))) / f(i); avg() is a preset average value determination function. i i f（i） j=1 ij i 2

[0058] Specifically, the fluctuation value corresponding to the time interval list of each key charging vehicle in the third time window is obtained. The greater the fluctuation value, the greater the difference between the connection response information and the corresponding connection confirmation information corresponding to the key charging vehicle, that is, the key charging vehicle is unstable when connecting with the cloud platform in the third time window, and the network fluctuation is large, that is, the network connection can not be stable. On the contrary, if the fluctuation value is smaller, it means that the time interval between each corresponding connection response information and the corresponding connection confirmation information of the key charging vehicle is smaller, and the overall is more stable. The smaller the fluctuation, the smaller the network fluctuation in this period of time (in the third time window), that is, the network connection is more stable.

[0059] S280, if (a / n)≥n0, and no connection response information is received in the first time window, then in the second time window after the end of the first time window, the charging task is continued to be executed at the second preset power; wherein a is the number of time fluctuation values in GTB greater than the preset time fluctuation value threshold; n0 is a preset fluctuation value ratio; the start time of the second time window is the end time of the first time window.

[0060] S290, if the connection response information is received in the second time window, the charging task is continued to be executed at the first preset power until the target power is reached; and a charging completion signal is sent to the cloud platform.

[0061] The cloud platform is further configured to perform the following steps:

[0062] ​​​​​​S160, jump to step S120.

[0063] Specifically, (a / n) ≥ n0, it indicates that most of the key charging vehicles are likely to have large network fluctuations in the third time window, that is, the network connection in the third time window is likely to be unstable, so it may cause part of the working charging vehicles to be disconnected, therefore, in order to further reduce the failure probability of the order, for the working charging vehicle which has not been connected successfully after the end of the first time window, continue to perform the charging task in the second time window with the second preset power. That is, the reconnection waiting time is prolonged, and the failure probability of the order is further reduced, and the length of the second time window is also pre-set. It is convenient for the cloud to charge.

[0064] In an exemplary embodiment of the present application, after step S280, the working charging vehicle is further used to perform the following steps:

[0065] S2100, if no connection response information is received in the second time window, stop performing the charging task, and determine the first time window and the second time window as the low-power time window.

[0066] Specifically, if no connection response information of the cloud platform is received in the second time window, it indicates that the reconnection fails in the second time window, at this time, the IBM module controls the working charging vehicle to stop charging at the end time of the second time window.

[0067] S2110, broadcast the delay stop information and the corresponding sending request according to the pre-set short-distance communication protocol; the delay stop information includes the unique identifier of the working charging vehicle.

[0068] Specifically, at this time, since the actual low-power charging time of the working charging vehicle is the length of the first time window and the second time window, and since the working charging vehicle is disconnected from the cloud platform, the cloud platform cannot know the actual low-power charging time of the working charging vehicle, therefore, the working charging vehicle broadcasts the delay stop information and the corresponding sending request according to the pre-set short-distance communication protocol, and the delay stop information includes the unique identifier of the working charging vehicle.

[0069] The key charging vehicle is further used to perform the following steps:

[0070] S310, in response to receiving any delay stop information and corresponding sending request, and not disconnected from the cloud platform, the delay stop information is sent to the cloud platform.

[0071] Specifically, any key charging vehicle which is not disconnected from the cloud platform receives the delay stop information and the corresponding sending request, and then sends the delay stop information to the cloud platform.

[0072] The cloud platform is further used to perform the following steps:

[0073] S170, jump to step S140.

[0074] Specifically, after receiving the delay stop information, the cloud platform calculates the corresponding power consumption according to the unique identifier and the corresponding start time and disconnection time, and further charges.

[0075] In this embodiment, for the working charging vehicle whose reconnection time is extended and still fails to reconnect successfully, in order for the cloud platform to achieve accurate charging, it broadcasts the delay stop information and the corresponding sending request through the preset short-distance communication protocol without network. When any key charging vehicle that has not disconnected with the cloud platform receives it, it sends it to the cloud platform. Since the delay stop information includes the unique identifier corresponding to the working charging vehicle, the cloud platform can obtain the low-power charging duration (the length of the first and second time windows) according to the delay stop information after receiving it, and can determine the corresponding working charging vehicle according to the unique identifier to achieve accurate charging.

[0076] In an exemplary embodiment of the present application, after step S270, the above working charging vehicle is further configured to perform the following steps:

[0077] S2120, if (a / n) < n0 and no connection response information of the cloud platform is received within the first time window, stop performing the charging task; and determine the first time window as the low-power time window.

[0078] The cloud platform is further configured to perform the following steps:

[0079] S180, jump to step S140.

[0080] Specifically, if (a / n) < n0, it means that most key charging vehicles may have less network fluctuations within the third time window, i.e., the network connection within the third time window may be more stable, so the disconnection reason of the disconnected working charging vehicle may not be network-related. At this time, if the working charging vehicle does not receive the connection response information of the cloud platform within the first time window, it stops performing the charging task, i.e., does not extend the low-power charging time.

[0081] In an exemplary embodiment of the present application, after step S110, the cloud platform is further configured to perform the following steps:

[0082] S190, in response to detecting that any working charging vehicle is disconnected, obtaining a first time interval list set NT=(NT1, NT2, …, NT g , …, NT h ); g=1, 2, …, h; h is the number of working charging vehicles that have not disconnected; NT ga first time interval list of the gth unbroken working charging vehicle; NT g = (NT g1 , NT g2 , …, NT gk , …, NT gf(g) ); k = 1, 2, …, f(g); f(g) is the number of times that the gth unbroken working charging vehicle receives connection response information in the first time window; NT gk is the first time interval between the time of receiving the connection response information and the corresponding connection confirmation information of the gth unbroken working charging vehicle in the kth time of the first time window; the working charging vehicle that is disconnected in the first time window reconnects with the cloud platform;

[0083] Specifically, when the cloud platform detects that any working charging vehicle is disconnected, a first time interval list set NT is obtained, which includes each first time interval of each working charging vehicle that is not disconnected with the cloud in the first time window. Each first time interval represents the time interval between the time of receiving the corresponding connection response information and the corresponding connection confirmation information. The time interval between any two adjacent connection confirmation information is fixed, but due to network fluctuations and other conditions, the time of receiving the corresponding connection response information may be different.

[0084] S1100, if NT is not empty and the disconnected working charging vehicle is not successfully reconnected in the first time window, a first time fluctuation value set NTB=(NTB1, NTB2, …, NTB g , …, NTB h ) is obtained according to NT; wherein NTB g is the corresponding first time fluctuation value of the gth unbroken working charging vehicle in the first time window; NTB g = (∑ f（g） k=1 (NT gk -avg(NT g )) 2 ) / f(g).

[0085] Specifically, if the NT is not empty, it indicates that there is a working charging vehicle that is not disconnected from the cloud, and the disconnected working charging vehicle is not successfully reconnected within the first time window. At this time, the first time fluctuation value corresponding to each working charging vehicle is obtained. The greater the fluctuation value, the greater the difference between the connection response information corresponding to the working charging vehicle and the corresponding connection confirmation information, that is, the working charging vehicle is less stable in connecting with the cloud platform within the first time window, which may be due to the larger network fluctuation, that is, the network connection may not be stable. Conversely, the smaller the fluctuation value, the smaller the difference between each corresponding connection response information and the corresponding connection confirmation information of the working charging vehicle, and the more stable the whole, the smaller the fluctuation, and the smaller the network fluctuation within this period (within the first time window), that is, the network connection is more stable.

[0086] In S1200, if (b / h)≥n0, a broadcast task of sending a reconnection time extension instruction to h disconnected working charging vehicles is performed; b is the number of first time fluctuation values in NTB that are greater than a preset time fluctuation value threshold; and n0 is a preset fluctuation value ratio.

[0087] Specifically, if (b / h)≥n0, it indicates that most working charging vehicles may have larger network fluctuations within the first time window, that is, the network connection within the first time window may be less stable, so that part of the charging vehicles may not be successfully reconnected within the first time window after being disconnected. Therefore, in order to further reduce the failure probability of the order, the working charging vehicles that have not been connected successfully after the end of the first time window continue to perform the charging task in the second time window at a second preset power. That is, the reconnection waiting time is extended, the failure probability of the order is further reduced, and the length of the second time window is also preset. It is convenient for the cloud to perform billing. Since the working charging vehicle cannot receive the instruction of the cloud platform after being disconnected from the cloud platform, and the extension time set by the charging vehicle itself is the first time window, a broadcast task of sending a reconnection time extension instruction to each disconnected working charging vehicle is performed. That is, each disconnected working charging vehicle broadcasts the reconnection time extension instruction.

[0088] The disconnected working charging vehicle is used to perform the following steps:

[0089] In S310, in response to receiving the broadcast task of the reconnection time extension instruction, the reconnection time extension instruction is broadcasted according to a preset short-distance communication protocol.

[0090] Specifically, since the working charging vehicle disconnected from the cloud platform cannot receive the reconnection time extension instruction of the cloud platform, each disconnected working charging vehicle broadcasts the reconnection time extension instruction. Here, each disconnected working charging vehicle broadcasts the reconnection time extension instruction according to a preset short-distance communication protocol.

[0091] The working charging vehicle that is disconnected and fails to reconnect successfully within the first time window is used to perform the following steps:

[0092] S410, in response to receiving any reconnection time extension instruction broadcast according to the preset proximity communication protocol, the charging task is continued to be performed with a second preset power within a second time window; the start time of the second time window is the end time of the first time window; the second preset power is less than the first preset power; the working charging vehicle performs the charging task according to the first preset power when it is not disconnected; the first preset power is adjusted to the second preset power after the working charging vehicle is disconnected; each charging task has a corresponding target power.

[0093] Specifically, any working charging vehicle performs the charging task using the first preset power when it is not disconnected, attempts to reconnect with the cloud platform (performs the charging task using the second preset power) within the first time window through the steps S220-S230 after being disconnected, and if it fails to reconnect successfully within the first time window and receives any reconnection time extension instruction broadcast according to the preset proximity communication protocol, the charging task is continued to be performed with the second preset power within the second time window. That is, the reconnection time is extended.

[0094] S420, if the connection response information is received within the second time window, the charging task is continued to be performed with the first preset power until the target power is reached.

[0095] Specifically, if the connection response information is received within the second time window, that is, the working charging vehicle is successfully reconnected with the cloud platform within the second time window, the charging task is continued to be performed with the first preset power until the target power is reached.

[0096] In the embodiment, when the cloud platform detects that any working charging vehicle is disconnected, and is not successfully reconnected within the first time window, according to the fluctuation of each time interval between the connection response information and the corresponding connection confirmation information of each disconnected working charging vehicle, the greater the fluctuation value, the greater the difference between the connection response information and the corresponding connection confirmation information of the working charging vehicle, that is, the connection between the working charging vehicle and the cloud platform within the first time window is less stable, which may be due to the greater network fluctuation, that is, the network connection may not be stable. On the contrary, the smaller the fluctuation value, the smaller the difference between each corresponding connection response information and the corresponding connection confirmation information of the working charging vehicle, and the more stable the whole, the smaller the fluctuation, the smaller the network fluctuation within this period (within the first time window), that is, the more stable the network connection. Further, if (b / h)≥n0, it indicates that most of the working charging vehicles may have greater network fluctuation within the first time window, that is, the network connection within the first time window may be less stable, so it may cause some charging vehicles to be disconnected and still not successfully reconnected within the first time window. Therefore, in order to further reduce the failure probability of the order, the working charging vehicles that are still not connected successfully after the first time window ends continue to perform the charging task at a second preset power within a second time window. That is, the reconnection waiting time is extended, the failure probability of the order is further reduced, and the length of the second time window is also pre-set. It is convenient for the cloud platform to charge. Since the working charging vehicle cannot receive the instruction of the cloud platform after being disconnected from the cloud platform, and the extension time set by the charging vehicle itself is the first time window, a broadcast task of sending a reconnection time extension instruction to each disconnected working charging vehicle is performed. That is, each disconnected working charging vehicle broadcasts the reconnection time extension instruction. If the working charging vehicle is not successfully reconnected within the first time window and receives any reconnection time extension instruction broadcast according to the pre-set short-distance communication protocol, it continues to perform the above charging task at a second preset power within a second time window, that is, the reconnection time is extended. Finally, if the connection response information is received within the second time window, that is, the working charging vehicle is successfully reconnected with the cloud platform within the second time window, the charging task is continued at the first preset power until the target power is reached. In the embodiment, the cloud platform obtains the time interval fluctuation of each disconnected working charging vehicle within the first time window, thereby knowing the network fluctuation within the first time window and obtaining the network stability within the first time window. Further, if the network stability is low, it is considered that the disconnected working charging vehicle may not be successfully reconnected within the first time window due to network fluctuation. Therefore, the reconnection time of the disconnected working charging vehicle is extended. In this way, by setting reasonable reference factors, the order failure rate is further reduced, and the user experience is improved.

[0097] In an exemplary embodiment of the present application, after step S190, the cloud platform is further configured to perform the following steps:

[0098] S1210, if the NT is empty and any working charging vehicle is detected to reconnect successfully within a preset response time period, a broadcast task of sending a power adjustment instruction to each working charging vehicle that reconnects successfully within the preset response time period is performed.

[0099] Specifically, if the NT is empty, that is, at the current time, all working charging vehicles are disconnected from the cloud platform, if all working charging vehicles are disconnected from the cloud platform, it is possible that it is caused by transient or phase network instability, at this time, it is highly probable that each working charging vehicle can reconnect successfully, so it can continue to charge at the first preset power, but according to the preset power setting, each working charging vehicle disconnected from the cloud platform is adjusted to the second preset power for charging after disconnection. Therefore, if any working charging vehicle is detected to reconnect successfully within a preset response time period, the time length of the preset response time period is less than the time length of the first time window, a broadcast task of sending a power adjustment instruction to each working charging vehicle that reconnects successfully within the preset response time period is performed.

[0100] The working charging vehicle that reconnects successfully within the preset response time period is used to perform the following steps:

[0101] S510, in response to receiving the broadcast task of sending the power adjustment instruction, the above-mentioned power adjustment instruction is broadcasted according to the preset short-distance communication protocol.

[0102] Specifically, the working charging vehicle that reconnects successfully within the preset response time period receives the broadcast task of sending the power adjustment instruction, and the above-mentioned power adjustment instruction is broadcasted according to the preset short-distance communication protocol.

[0103] The working charging vehicle that does not reconnect successfully within the preset response time period is used to perform the following steps:

[0104] S610, according to the preset reconnection method, the working charging vehicle reconnects with the cloud platform within the first time window.

[0105] Specifically, step S610 includes:

[0106] S611, the working charging vehicle sends a reconnection request information to the cloud platform, and continues to perform the above-mentioned charging task at the second preset power within the first time window.

[0107] S612, if no connection response information is received within the first response time period of the first time window, the corresponding connection module is restarted; the above-mentioned connection module is used to communicate with the cloud platform.

[0108] Here, steps S611-S612 are the same as steps S220-S230 described above, which will not be described here.

[0109] S620, in response to not receiving the connection response information of the cloud platform, and receiving any power adjustment instruction broadcast according to the preset short-distance communication protocol within the first time window, adjusting the second preset power to the first preset power, and continuing to perform the corresponding charging task until the end of the first time window; the length of the preset response time period is less than the length of the first time window, and the start time of the preset response time period is equal to the start time of the first time window.

[0110] Specifically, if the connection response information of the cloud platform is not received, and any power adjustment instruction broadcast according to the preset short-distance communication protocol is received within the first time window, the second preset power is adjusted to the first preset power, and the corresponding charging task is continued to be performed until the end of the first time window.

[0111] S630, if the connection response information of the cloud platform is received within the first time window except for the preset response time period, the above charging task is continued to be performed at the first preset power until the target power is reached; and a charging completion signal is sent to the cloud platform.

[0112] Specifically, if the connection response information of the cloud platform is received within the first time window except for the preset response time period, that is, the reconnection is successful, the above charging task is continued to be performed at the first preset power until the target power is reached; and a charging completion signal is sent to the cloud platform.

[0113] In the embodiment, if the NT is empty, that is, at the current time, all working charging vehicles are disconnected from the cloud platform. If all working charging vehicles are disconnected from the cloud platform, it is possible that it is caused by transient or periodic network instability. At this time, it is highly probable that each working charging vehicle can successfully reconnect. Therefore, it can continue to charge at the first preset power. However, according to the preset power setting, each working charging vehicle disconnected from the cloud platform adjusts to the second preset power for charging after disconnection. Therefore, if it is detected that any working charging vehicle successfully reconnects within the preset response time period, and the time length of the preset response time period is less than the time length of the first time window, a broadcast task of sending a power adjustment instruction to each working charging vehicle that successfully reconnects within the preset response time period is performed. Each working charging vehicle that successfully reconnects within the preset response time period broadcasts the power adjustment instruction. If a working charging vehicle that does not successfully reconnect within the preset response time period receives any power adjustment instruction broadcast according to the preset short-distance communication protocol within the first time window, the second preset power is adjusted to the first preset power, and the corresponding charging task is continuously performed until the end of the first time window. If the connection response information of the cloud platform is received within the first time window except for the preset response time period, that is, it is successfully reconnected, the charging task is continuously performed at the first preset power until the target power is reached. In the embodiment, all working charging vehicles are disconnected from the cloud platform, which may be caused by transient or periodic network instability. At this time, it is highly probable that each working charging vehicle can successfully reconnect. However, according to the preset power adjustment rule, each working charging vehicle charges at a lower second preset power within the first time window after disconnection and waits for reconnection. In the embodiment, it is highly probable that each working charging vehicle can successfully reconnect. In order to avoid slow charging speed, the charging power of all charging vehicles can be adjusted to the first preset power within the first time window. Therefore, the working charging vehicle that successfully reconnects within the preset response time period broadcasts the power adjustment instruction, so that each working charging vehicle that does not successfully reconnect within the preset response time period also adjusts to the first preset power for charging within the first time window according to the power adjustment instruction. Compared with continuously charging at the second preset power within the first time window, the charging time can be reduced. Compared with the related art in which disconnection directly closes the order, the embodiment reduces the probability of abnormal failure of the order due to the setting of the delayed reconnection time.

[0114] In an exemplary embodiment of the present application, after step S410, the working charging vehicle that is disconnected and does not successfully reconnect within the first time window is used to perform the following steps:

[0115] S430, if the connection response information is not received within the second time window, the working charging vehicle stops performing the charging task.

[0116] Specifically, if the connection response information is not received in the second time window, i.e., the reconnection fails, the working charging vehicle stops performing the charging task.

[0117] In an example embodiment of the present application, after step S620, the working charging vehicle that fails to reconnect within the preset response time period is further used to perform the following steps:

[0118] S640, broadcast the power adjustment information and the corresponding sending request according to a preset proximity communication protocol; wherein the power adjustment information comprises a power adjustment time and a corresponding unique identifier.

[0119] Specifically, in order to facilitate the cloud to accurately obtain the power consumption of the working charging vehicle, the power adjustment information and the corresponding sending request are broadcasted according to the preset proximity communication protocol.

[0120] The working charging vehicle that reconnects successfully within the preset response time period is further used to perform the following steps:

[0121] S520, in response to receiving any power adjustment information and corresponding sending request, the power adjustment information and the corresponding sending request are sent to the cloud platform.

[0122] Specifically, if any power adjustment information and corresponding sending request are received, the power adjustment information and the corresponding sending request are sent to the cloud platform, so that the cloud platform can obtain the charging time of the working charging vehicle that fails to reconnect within the preset response time period (the difference between the time length of the first preset power charging time and the time length of the preset response time period, and the charging time before disconnection) and the charging time of the working charging vehicle that reconnects successfully within the preset response time period (the time length of the preset response time period), and further determine the power consumption of the working charging vehicle that fails to reconnect within the preset response time period.

[0123] In an example embodiment of the present application, after step S190, the cloud platform is further used to perform the following steps:

[0124] S1220, if NT is empty, the current power of each disconnected working charging vehicle at the disconnection moment is obtained to obtain a current power set CD=(CD1, CD2, …, CD r , …, CD s ); r=1, 2, …, s; s is the number of working charging vehicles disconnected from the cloud platform; CDr is the current power of the rth working charging vehicle disconnected from the cloud platform; each charging task has a corresponding target power; the disconnected working charging vehicle reconnects with the cloud platform within the first time window.

[0125] Specifically, the specific method for the disconnected working charging vehicle to reconnect with the cloud platform in the first time window in the embodiment is the same as the above steps, which will not be described here.

[0126] S1230, if the CD r CDY is a preset power threshold; if the CD r CDY is a preset power threshold; if the CD

[0127] S1240, sending a broadcast task of power adjustment instruction to the first type of working charging vehicle; wherein, the working charging vehicle performs a charging task according to a first preset power when it is not disconnected; the first preset power is adjusted to a second preset power when the working charging vehicle is disconnected; the first preset power is greater than the second preset power;

[0128] The first type of working charging vehicle is used to perform the following steps:

[0129] S710, in response to receiving the broadcast task of power adjustment instruction, broadcasting the power adjustment instruction according to a preset short-distance communication protocol;

[0130] The second type of working charging vehicle is used to perform the following steps:

[0131] S810, reconnecting with the cloud platform in a first time window according to a preset reconnection method;

[0132] S820, in response to not receiving the connection response information of the cloud platform and receiving any power adjustment instruction broadcasted according to the preset short-distance communication protocol in the first time window, adjusting the second preset power to the first preset power and continuing to perform the charging task until the end of the first time window; the time length of the preset response time period is less than the time length of the first time window, and the start time of the preset response time period is equal to the start time of the first time window;

[0133] S830, if the connection response information of the cloud platform is received within the time after the power adjustment in the first time window, the charging task is continued to be performed at the first preset power until the target power is reached; and a charging completion signal is sent to the cloud platform.

[0134] In this embodiment, if NT is empty, it means that the cloud platform has lost connection to each working charging vehicle. First, the power of each working charging vehicle at the moment of disconnection is obtained. If the power is greater than the preset power threshold, it means that the current power is close to the target power. Conversely, if the power is less than the preset power threshold, it means that the current power is not close to the target power. If the connection with the cloud is lost at this time, the user will most likely need to continue charging.

[0135] When all charging vehicles lose connection with the cloud platform, it may be due to momentary or periodic network instability. In this case, it is highly likely that each charging vehicle will successfully reconnect. Therefore, it can continue charging at the first preset power, but according to the preset power setting, each charging vehicle that loses connection with the cloud platform will adjust to the second preset power after the disconnection. Therefore, if a charging vehicle with a power level below the preset power threshold is detected to successfully reconnect within the preset response time period (the first type of charging vehicle), a power adjustment command broadcast task is sent to the first type of charging vehicles. The first type of charging vehicles broadcast the aforementioned power adjustment command. Here, the length of the preset response time period is shorter than the length of the first time window. If a charging vehicle (Type II) fails to reconnect within a preset response time period and its battery level is less than a preset battery threshold, and receives any power adjustment command broadcast according to a preset short-range communication protocol within the first time window, it will adjust its second preset power to the first preset power and continue charging until the first time window ends. If it receives a connection response from the cloud platform within the time after the power adjustment within the first time window, i.e., the reconnection is successful, it will continue charging at the first preset power until the target battery level is reached. In this embodiment, if all charging vehicles lose connection with the cloud platform, it may be due to momentary or periodic network instability. In this case, it is highly likely that each charging vehicle can reconnect successfully. However, according to the preset power adjustment rules, each charging vehicle will charge at a lower second preset power within the first time window after the disconnection and wait for reconnection. In this embodiment, to avoid slowing down the charging speed, the charging power of all charging vehicles is adjusted to the first preset power within the first time window. Therefore, by using the first type of working charging vehicle to broadcast the power adjustment command, each second type of working charging vehicle can also adjust to the first preset power for charging within the first time window according to the power adjustment command. Compared with continuously charging at the second preset power within the first time window, the charging time can be reduced. Moreover, compared with related technologies, where disconnection directly closes the order, this embodiment reduces the probability of abnormal order failure by setting a delayed reconnection time.

[0136] In one exemplary embodiment of this application, after step S820, the aforementioned second type of working charging vehicle is used to perform the following steps:

[0137] S840, broadcast the power adjustment information and the corresponding sending request according to a preset proximity communication protocol; wherein the power adjustment information comprises a power adjustment time and a corresponding unique identifier.

[0138] The first type of working charging vehicle is configured to perform the following steps:

[0139] S720, in response to receiving any power adjustment information and the corresponding sending request, send the power adjustment information and the corresponding sending request to the cloud platform.

[0140] In the embodiment, in order to enable the cloud platform to accurately charge, first, the second type of working charging vehicle disconnected with the cloud platform broadcasts the power adjustment information and the corresponding sending request according to a preset proximity communication protocol, and the first type of working charging vehicle receives any power adjustment information and the corresponding sending request, and then sends the power adjustment information and the corresponding sending request to the cloud platform. That is, the second type of working charging vehicle sends its power adjustment information (including the power adjustment time and the corresponding unique identifier) to the cloud platform through the first type of working charging vehicle, so that the cloud platform obtains the charging time corresponding to the first preset power (the sum of the charging time before disconnection and the time interval between the power adjustment time and the completion of charging) and the charging time corresponding to the second preset power (the time interval between the disconnection time and the power adjustment time). Further, the corresponding electric energy consumption and the charging fee are obtained.

[0141] In an exemplary embodiment of the present application, after step S1230, the cloud platform is further configured to perform the following steps:

[0142] S1250, if any second type of working charging vehicle fails to reconnect successfully within the first time window, obtain the sub-area identifier corresponding to the second type of working charging vehicle; each sub-area corresponding to each sub-area identifier has a corresponding preset reconnection time; the length of the preset response time period is less than the length of the first time window, and the start time of the preset response time period is equal to the start time of the first time window.

[0143] Specifically, the preset reconnection time corresponding to each sub-area is determined according to the following steps:

[0144] S1251, divide the area where the vehicle charging system is located according to a preset charging position to obtain a set of sub-area identifiers QY=(QY1, QY2, …, QY x , …, QY y ); x=1, 2, …, y; y is the number of sub-areas obtained by dividing the area where the vehicle charging system is located; QY x is the area identifier of the xth sub-area in the vehicle charging system; each sub-area has a corresponding charging position.

[0145] Here, the area where the vehicle charging system is located is divided into zones based on preset charging locations, so that each sub-zone has a corresponding charging location. Each sub-zone has a corresponding zone identifier.

[0146] S1252, Based on QY, obtain the sub-region historical reconnection time list set LT=(LT1, LT2, ..., LT... x , ..., LT y ); where LT x For QY x Corresponding historical reconnection time list; LT x =(LT x1 LT x2 , ..., LT xp , ..., LT xq ); LT xp For the p-th critical event within the fourth time window, located at QY x The historical reconnection time of the working charging vehicles in the sub-region; the above key events are the events in which all working charging vehicles lose connection with the cloud platform and all automatically reconnect successfully; the end time of the fourth time window is the time when all connected working charging vehicles are detected to have lost connection.

[0147] Here, the historical reconnection time of each sub-region is obtained for each critical event (the event in which all working charging vehicles and the cloud platform are completely disconnected and automatically reconnected successfully) within the fourth time window before the current time, so as to obtain the historical multiple reconnection times of each sub-region.

[0148] S1253, According to LT, cluster each historical reconnection time list to obtain a cluster list set JL=(JL1, JL2, ..., JL... x , ..., JL y JL x For QY x The corresponding list of clusters; JL x =(JL x1 JL x2 , ..., JL xm , ..., JL xf(x) ); m=1, 2,…, f(x); f(x) is JL x The corresponding number of clusters; JL xm For JL x The corresponding m-th cluster; each cluster list contains at least one cluster; each cluster contains at least one historical reconnection time.

[0149] S1254, if JL xm If the number of historical reconnection times within the JL is greater than or equal to the preset number, then JL will be...xm The longest historical reconnection time is determined as the preset reconnection time of the sub-region x The preset reconnection time of the corresponding sub-region.

[0150] Here, for each sub-region, a plurality of historical reconnection times corresponding to a plurality of key events in history are clustered, and if the number of historical reconnection times in a certain cluster is greater than a preset number, it indicates that the working charging vehicle in the sub-region mostly reconnects successfully within the corresponding time in the cluster when a key event occurs in history. At this time, the longest historical reconnection time in the cluster is determined as the preset reconnection time corresponding to the sub-region.

[0151] S1260, a broadcast task of sending each time extension instruction corresponding to each second type of charging vehicle that has not successfully reconnected within the first time window to each first type of working charging vehicle; the time extension instruction includes a corresponding preset reconnection time and a unique identifier.

[0152] Specifically, since all working charging vehicles are disconnected from the cloud platform, it may be caused by transient or periodic network instability, at this time, each working charging vehicle can reconnect successfully with high probability. Therefore, for the second type of charging vehicle that has not successfully reconnected within the first time window, the reconnection time is extended to reduce the failure rate of orders. However, since the second type of working charging vehicle is disconnected from the cloud platform, it is necessary to use the first type of working charging vehicle that has successfully reconnected to act as an information transmission medium. That is, a broadcast task of sending each time extension instruction corresponding to each second type of charging vehicle that has not successfully reconnected within the first time window to each first type of working charging vehicle. Since each second type of working charging vehicle is in a different sub-region, although they are both extending the time, the present application determines the corresponding extended reconnection time according to the preset reconnection time corresponding to the sub-region where each second type of working charging vehicle is located.

[0153] The first type of working charging vehicle is used to perform the following steps:

[0154] S730, in response to receiving the broadcast task of each time extension instruction, broadcasting each time extension instruction according to a preset close-range communication protocol;

[0155] The second type of working charging vehicle that has not successfully reconnected within the first time window is used to perform the following steps:

[0156] S850, in response to receiving the corresponding preset reconnection time and the unique identifier, and the preset reconnection time being greater than the length of the first time window, reconnecting with the cloud platform within the extended time; the extended time is the difference between the preset reconnection time and the length of the first time window.

[0157] Specifically, as an example: if the preset reconnection time of the second type of working charging car which fails to reconnect within the first time window is 300s, and the length of the first time window is 90s, then the extension time is 210s.

[0158] S860, if the connection response information of the cloud platform is received within the extension time, the charging task is continued to be performed at the first preset power until the target power is reached; and a charging completion signal is sent to the cloud platform.

[0159] In this embodiment, when all working charging cars are disconnected from the cloud platform, it may be caused by transient or periodic network instability, at this time, the probability of successful reconnection of each working charging car is high. Therefore, for the second type of charging car which fails to reconnect within the first time window, the reconnection time is extended to reduce the failure rate of the order. However, since the second type of working charging car is disconnected from the cloud platform, the first type of working charging car which has successfully reconnected needs to act as an information transmission medium. That is, a broadcast task of sending a time extension instruction corresponding to each second type of charging car which fails to reconnect within the first time window to each first type of working charging car. Since each second type of working charging car is in a different sub-area, although the time is extended, considering that the network situation may be affected by the location of each working charging car, for example, some locations are blocked, and the network status may not be good. Therefore, in this embodiment, the extension reconnection time corresponding to each second type of working charging car is determined according to the preset reconnection time of the sub-area corresponding to each second type of working charging car. Compared with using the same extension reconnection time, considering the location factor of each sub-area of the second type of working charging car, a more accurate extension reconnection time can be provided for the charging car in each sub-area, and the order failure probability can be effectively reduced.

[0160] In an exemplary embodiment of the present application, after step S1253, the above method further comprises:

[0161] S1255, if JL x The number of historical reconnection times corresponding to any cluster in JL x The longest historical reconnection time in JL x is determined as the preset reconnection time of the sub-area corresponding to QY

[0162] Specifically, if the number of historical reconnection times corresponding to any cluster in JL x is less than the preset number, it indicates that the length of the corresponding historical reconnection time in the sub-area is relatively uniform, and it may be affected by other factors in addition to the location. In order to maximize the reduction of the order failure rate, the longest historical reconnection time in JL x is determined as the preset reconnection time of the sub-area corresponding to QY x .

[0163] Embodiments of the present application also provide a computer program product, which comprises program codes for causing an electronic device to perform the steps of the methods according to various exemplary embodiments of the present application described above in the specification when the program product is run on the electronic device.

[0164] In addition, although various steps of the methods in the present application are described in a particular order in the accompanying drawings, this does not require or imply that the steps must be performed in the particular order, or that all of the illustrated steps must be performed to achieve the desired results. Additionally or alternatively, certain steps can be omitted, a plurality of steps can be combined into one step, one step can be split into a plurality of steps, etc.

[0165] From the above description of the embodiments, those skilled in the art will readily appreciate that the example embodiments described herein can be implemented by software and / or by hardware combined with software. Accordingly, the technical solutions of the embodiments of the present application can be embodied in the form of a software product. The software product can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash disk, a mobile hard disk, etc.) or a network, and includes a number of instructions to enable a computing device (which can be a personal computer, a server, a mobile terminal, or a network device, etc.) to perform the methods according to the embodiments of the present application.

[0166] In the example embodiments of the present application, an electronic device capable of implementing the above method is also provided.

[0167] Those skilled in the art can understand that various aspects of the present application can be implemented as a system, a method or a program product. Therefore, various aspects of the present application can be embodied in the form of a complete hardware implementation, a complete software implementation (including firmware, microcode, etc.), or an implementation of hardware and software combined, which can be collectively referred to as "circuitry", "module" or "system" herein.

[0168] The electronic device according to this embodiment of the present application. The electronic device is merely an example and should not impose any limitation on the functions and use range of the embodiments of the present application.

[0169] The electronic device is in the form of a general computing device. The components of the electronic device can include, but are not limited to, the at least one processor described above, the at least one memory described above, and a bus connecting different system components (including the memory and the processor).

[0170] The memory stores program codes that can be executed by the processor to cause the processor to perform the steps according to various exemplary embodiments of the present application described in the above "Exemplary Methods" section of the specification.

[0171] The storage can include a readable medium in the form of volatile storage such as random access memory (RAM) and / or cache memory, and can further include a non-volatile storage such as read only memory (ROM).

[0172] The storage can also include a program / utility, having a set of program modules such as an operating system, one or more application programs, other program modules, and program data, each of which can be executed by the processor(s) 1010. Each of the operating system, one or more application programs, other program modules, and program data can include an implementation of a networking environment.

[0173] The bus can represent one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration bus, a processor or local bus using any of a variety of bus architectures.

[0174] The electronic device can also communicate with one or more external devices such as a keyboard or a pointing device, through an I / O interface. Additionally, the electronic device can communicate with one or more devices that enable a user to interact with the electronic device through an input device or devices 1012. The input device or devices 1012 can include, for example, a microphone, a camera, a button, a switch, a touch-sensitive screen, a gesture-sensitive screen, a speaker, a voice-recognition and / or biometric circuitry, or any combination thereof. The input device or devices 1012 can also include a network interface device that can communicate a user's use of the electronic device to one or more other electronic devices, and / or enable a user to use the electronic device to communicate with one or more other electronic devices. The electronic device can also include a output device, such as a speaker, a printer, a display, or any combination thereof. The output device can enable a user to

[0175] Those skilled in the art will readily understand that the example embodiments described herein can be implemented by software and / or by software in combination with the necessary hardware. Thus, the technical solutions according to the embodiments of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash disk, a mobile hard disk, or the like) or a network, and includes a number of instructions to enable a computing device (which can be a personal computer, a server, a terminal device, or a network device, etc.) to perform the methods according to the embodiments of the present application.

[0176] In the example embodiments of the present application, a computer readable storage medium is also provided, on which a program product capable of implementing the method described above is stored. In some possible implementation manners, various aspects of the present application can also be implemented in the form of a program product, which includes program codes for causing the terminal device to perform the steps described in the "example method" section above according to various example embodiments of the present application when the program product is run on the terminal device.

[0177] The program product can adopt any combination of one or more readable media. The readable medium can be a readable signal medium or a readable storage medium. The readable storage medium may, for example, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or apparatus, or any combination of the above. More specific examples (non-exhaustive list) of the readable storage medium include an electrical connection having one or more wires, a portable disc, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above.

[0178] The computer readable signal medium can include a data signal propagated in a baseband or as part of a carrier wave, in which readable program codes are borne. Such a propagated data signal can take on many forms, including but not limited to an electromagnetic signal, an optical signal, or any suitable combination of the above. The readable signal medium can also be any readable medium that is not a readable storage medium and that can send, propagate or transmit the program for use by or in connection with an instruction execution system, apparatus or device.

[0179] The program codes contained on the readable medium can be transmitted by any suitable medium, including but not limited to wireless, wired, optical cable, RF, etc., or any suitable combination of the above.

[0180] The program code may be executed by one or more programmable processing devices to perform the operations described herein. The processing devices may include processors, microprocessors, microcontrollers, programmable logic devices, field programmable gate arrays (FPGAs), or other processing devices. The processing devices may be configured to execute program code stored in memory. The memory may include one or more types of memory such as volatile memory (e.g., random access memory (RAM), dynamic random access memory (DRAM), or static random access memory (SRAM)), non-volatile memory (e.g., read only memory (ROM), programmable read only memory (PROM), erasable programmable read only memory (EPROM), electrically erasable programmable read only memory (EEPROM), flash memory, solid state memory, or other non-volatile memory), or other types of memory.

[0181] In addition, the above-described flowcharts are merely illustrative of the processes included in the method according to the exemplary embodiments of the present application, and are not intended to limit the purpose. It is easily understood that the processes shown in the above-described flowcharts do not indicate or limit the time sequence of the processes. In addition, it is also easily understood that the processes can be executed synchronously or asynchronously, for example, in a plurality of modules.

[0182] It should be noted that, although several modules or units of the device for action execution are mentioned in the above detailed description, such a division is not mandatory. Indeed, according to the embodiments of the present application, the features and functionalities of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functionalities of one module or unit described above can be further divided into embodied by a plurality of modules or units.

[0183] The above merely describes specific embodiments of the present application, but the protection scope of the present application is not limited thereto, and any changes or replacements easily thought of by those skilled in the art within the technical scope disclosed by the present application should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. A method for determining the energy consumption of a charging vehicle, characterized in that, This invention is applied to a vehicle charging system, which includes several working charging vehicles that perform charging tasks and a cloud platform. Each working charging vehicle sends a connection confirmation message to the cloud platform at preset time intervals. If a connection response message is received from the cloud platform, it is determined that the working charging vehicle is not disconnected. If a connection response message is not received from the cloud platform for a preset number of consecutive times, it is determined that the working charging vehicle is disconnected from the cloud platform. The cloud platform is used to perform the following steps: S110, in response to receiving a user's charging task, the charging task is sent to the corresponding working charging vehicle according to a preset allocation rule; The charging vehicle is used to perform the following steps: S210, in response to receiving a charging task from the cloud platform, executes the corresponding charging task at a first preset power; wherein, each charging task includes a corresponding target power. S220, if a disconnection with the cloud platform is detected during the execution of the charging task, a reconnection request is sent to the cloud platform, and the power is adjusted to the second preset power. The charging task continues to be executed within the first time window; the second preset power is less than the first preset power; the start time of the first time window is the time of disconnection with the cloud platform. S230, if no connection response information is received within the first response time period of the first time window, the connection module of the working charging vehicle is restarted; the connection module is used to communicate with the cloud platform; S240, if a connection response information is received within the second response time period of the first time window, the charging task is continued at the first preset power until the corresponding target power is reached; and a charging completion signal is sent to the cloud platform; wherein, the length of the first response time period is less than the length of the second response time period; and the length of the first time window is equal to the sum of the lengths of the first response time period and the second response time period; The cloud platform is also used to perform the following steps: S120, in response to receiving a charging completion signal, acquire the first working time set GYT=(GYT1, GYT2, GYT3, GYT4) corresponding to the charging completion signal; where GYT1 is the start time of the charging vehicle corresponding to the charging completion signal executing the charging task at a first preset power; GYT2 is the time when the charging vehicle corresponding to the charging completion signal loses connection with the cloud platform; GYT3 is the time when the charging vehicle corresponding to the charging completion signal receives the connection response information from the cloud platform; and GYT4 is the time when the charging vehicle corresponding to the charging completion signal completes the charging task. S130, generate the energy consumption of the working charging vehicle corresponding to the charging completion signal based on GYT, the first preset power and the second preset power.

2. The method for determining the energy consumption of a charging vehicle according to claim 1, characterized in that, After step S230, the charging vehicle is further configured to perform the following steps: S250, if no connection response information from the cloud platform is received within the first time window, the charging task is stopped; and the first time window is determined as a low-power time window; The cloud platform is also used to perform the following steps: S140, Get the second working time set GET=(GYT1, GYT2); S150 generates the energy consumption of the working charging vehicle based on GET, the duration of the low-power time window, the first preset power, and the second preset power.

3. The method for determining the energy consumption of a charging vehicle according to claim 2, characterized in that, If, within a radius centered on the location of the working charging vehicle and corresponding to a preset short-range communication protocol, there exists at least one key charging vehicle performing a charging task, then after step S220, the working charging vehicle is further configured to perform the following steps: S260, according to the preset short-range communication protocol, obtains a list of key time intervals GT=(GT1, GT2, ..., GT...). i , ..., GT n ); i = 1, 2, ..., n; where n is the number of critical charging vehicles; GT i For the list of critical time intervals for the i-th critical charging vehicle; GT i =(GT i1 GT i2 , ..., GT ij , ..., GT if（i） ); j=1,2,…,f(i); f(i) is the number of times the i-th key charging vehicle receives connection response information within the third time window; GT ij The time interval between the time when the i-th key charging vehicle receives the connection response information and the time when the corresponding connection confirmation information is sent for the j-th time within the third time window; the end time of the third time window is the start time of the first time window; S270, based on GT, obtain the key time fluctuation value set GTB=(GTB1, GTB2, ..., GTB) i , ..., GTB n ); among which, GTB i GTB represents the time fluctuation value corresponding to the i-th critical charging vehicle. i =(∑ f（i） j=1 (GT ij -avg(GT i )) 2 ) / f(i); avg() is the preset function to determine the average value; S280, if (a / n)≥n0, and no connection response information is received within the first time window, then after the first time window ends, the charging task continues to be executed at the second preset power within the second time window; where a is the number of time fluctuation values ​​in GTB that are greater than the preset time fluctuation value threshold; n0 is the preset fluctuation value ratio; the start time of the second time window is the end time of the first time window; S290, if a connection response is received within the second time window, the power is adjusted to the first preset power to continue the charging task until the target power is reached; and a charging completion signal is sent to the cloud platform. The cloud platform is also used to perform the following steps: S160, proceed to step S120.

4. The method for determining the energy consumption of a charging vehicle according to claim 3, characterized in that, After step S280, the charging vehicle is further configured to perform the following steps: S2100: If no connection response information is received within the second time window, the charging task is stopped, and the first and second time windows are determined as low-power time windows. S2110, broadcast delayed stop information and corresponding sending request according to a preset short-range communication protocol; the delayed stop information includes the unique identifier of the working charging vehicle; The key charging vehicle is used to perform the following steps: S310, in response to receiving any delay stop information and the corresponding sending request, and without disconnecting from the cloud platform, the delay stop information is sent to the cloud platform; The cloud platform is also used to perform the following steps: S170, proceed to step S140.

5. The method for determining the energy consumption of a charging vehicle according to claim 3, characterized in that, After step S270, the charging vehicle is further configured to perform the following steps: S2120, if (a / n) < n0, and no connection response information from the cloud platform is received within the first time window, then the charging task is stopped; and the first time window is determined as a low-power time window; The cloud platform is also used to perform the following steps: S180, proceed to step S140.

6. The method for determining the energy consumption of a charging vehicle according to claim 1, characterized in that, The first time window lasts for 90 seconds.

7. A non-transitory computer-readable storage medium, characterized in that, The storage medium stores at least one instruction or at least one program segment, which is loaded and executed by a processor to implement the method as described in any one of claims 1-6.

8. An electronic device, characterized in that, Includes a processor and the non-transitory computer-readable storage medium as described in claim 7.

Images