Charging method of charging vehicle, medium and electronic equipment

Abstract

The invention provides a charging method of a charging vehicle, a medium and electronic equipment, and relates to the field of vehicle charging, and the method comprises the steps: a cloud platform detects that all connected working charging vehicles are disconnected, and obtains a CD; if CDr is less than CDY; determining a first type of working charging vehicles and a second type of charging vehicles; sending a broadcast task of a power adjustment instruction to the first type of working charging vehicles; the first type working charging vehicle broadcasts a power adjustment instruction; the second type working charging vehicle does not receive the connection response information of the cloud platform, but receives a power adjustment instruction, adjusts the second preset power to the first preset power, and continues to correspondingly execute the charging task until the first time window ends; if the connection response information of the cloud platform is received, continuing to execute the charging task at the first preset power until the target electric quantity is reached; and a charging completion signal is sent to the cloud platform. According to the invention, the delay reconnection time is set, so that the probability of abnormal failure of the order is reduced.

Description

Technical Field

[0001] This application relates to the field of vehicle charging, and in particular to charging methods, media, and electronic equipment for charging vehicles. Background Technology

[0002] In vehicle charging systems, after the cloud platform receives a user's charging order, it sends the corresponding charging task to the appropriate charging vehicle. However, after receiving the charging task, the charging vehicle may lose connection with the cloud platform due to network instability or equipment malfunction. When this happens, the cloud platform terminates the order, and the user must re-order from the cloud platform to continue charging. This results in a high order failure rate and a poor user experience. Therefore, a charging method to reduce the order failure rate is urgently needed. Summary of the Invention

[0003] To address the aforementioned technical problems, this application provides a charging method, medium, and electronic device for a charging vehicle, which at least partially solves the problems existing in the prior art.

[0004] In a first aspect of this application, a charging method for a charging vehicle is provided, 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 a connection confirmation message to the cloud platform once every preset time interval. 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. If the cloud platform does not receive a connection confirmation message from the working charging vehicle within a preset connection time interval, it is determined that the working charging vehicle is disconnected from the cloud platform. The aforementioned cloud platform is used to perform the following steps: S110, in response to detecting that all connected working charging vehicles have lost connection, obtain the current power level of each disconnected working charging vehicle at the time of disconnection, so as to obtain the current power level set CD=(CD1, CD2, ..., CD2). r CD s ); r=1,2,…,s; s is the number of working charging vehicles that have lost connection with the cloud platform; CDr is the current power of the r-th working charging vehicle that has lost connection with the cloud platform; each charging task has a corresponding target power; the working charging vehicle that has lost connection reconnects with the cloud platform within the first time window; S120, if CD r <CDY; and if the working charging vehicle corresponding to CDr is successfully reconnected within the preset response time period, then the working charging vehicle corresponding to CDr is identified as a first-class working charging vehicle; CDY is a preset power threshold; if CD r<CDY; and if no successful reconnection of the working charging vehicle corresponding to CDr is detected within the preset response time period, then the working charging vehicle corresponding to CDr will be identified as a second type of working charging vehicle. S130, a broadcast task is performed to send a power adjustment command to the first type of working charging vehicle; wherein, when the working charging vehicle is not disconnected, the charging task is performed according to the first preset power; after the working charging vehicle is disconnected, the first preset power is adjusted to the second preset power; the first preset power is greater than the second preset power; The first type of working charging vehicle is used to perform the following steps: S210, in response to receiving a broadcast task of a power adjustment command, broadcast the aforementioned power adjustment command according to a preset short-range communication protocol; The second type of charging vehicle is used to perform the following steps: S310 reconnects to the cloud platform within the first time window according to the preset reconnection method; S320, in response to not receiving connection response information from the cloud platform, and receiving any power adjustment command broadcast according to a preset short-range communication protocol within the first time window, adjusts the second preset power to the first preset power and continues to execute the corresponding charging task until the first time window ends; 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. S330 If a connection response message from the cloud platform is received within the time window after power adjustment, the charging task continues at the first preset power until the target power is reached; and a charging completion signal is sent to the cloud platform.

[0005] In a second aspect of this application, a non-transitory computer-readable storage medium is provided, wherein at least one instruction or at least one program is stored in the storage medium, and the at least one instruction or at least one program is loaded and executed by a processor to implement the aforementioned charging method for a charging vehicle.

[0006] In a third aspect of this application, an electronic device is provided, including a processor and the aforementioned non-transitory computer-readable storage medium.

[0007] This application has at least the following beneficial effects: The charging method for the charging vehicle provided in this application, if the cloud platform loses connection to each working charging vehicle, first obtains the power level of each working charging vehicle at the moment of disconnection. If the power level is greater than a preset power level threshold, it means that the current power level is close to the target power level. Conversely, if the power level is less than the preset power level threshold, it means that the current power level is not close to the target power level. If the connection with the cloud is lost at this time, the user will most likely need to continue charging.

[0008] 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. Furthermore, it will be unable to communicate with the cloud platform at this time. 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 has a battery level below a preset 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 application, 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 charges at a lower second preset power within the first time window after the disconnection and waits for reconnection. In this application, 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 is also adjusted to the first preset power for charging within the first time window. 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 application reduces the probability of abnormal order failure by setting a delayed reconnection time. Attached Figure Description

[0009] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0010] Figure 1 A flowchart of the cloud platform corresponding to one embodiment of the charging method for the charging vehicle provided in this application; Figure 2A flowchart corresponding to a first type of working charging vehicle in one embodiment of the charging method for the charging vehicle provided in this application; Figure 3 This is a flowchart of a second type of working charging vehicle in one embodiment of the charging method for the charging vehicle provided in this application. Detailed Implementation

[0011] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0012] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or server that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.

[0013] It should be noted that the following description covers various aspects of embodiments within the scope of the appended claims. It will be apparent that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on this application, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Additionally, this device and / or method can be implemented using structures and / or functionalities other than one or more of the aspects set forth herein.

[0014] Please refer to Figure 1-3As shown, an embodiment of this application provides a charging method for a charging vehicle. The vehicle charging system 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. If the cloud platform does not receive a connection confirmation message from the working charging vehicle within a preset connection time interval, it is determined that the working charging vehicle is disconnected from the cloud platform.

[0015] Here, the cloud platform communicates with each charging vehicle performing a charging task. Each charging vehicle includes a Tbox module and an IBM module. The Tbox, short for Telematics Box, is a crucial component of the vehicle-to-everything (V2X) system. It integrates long-distance communication and information technology for communication with the cloud platform. The IBM module controls the starting and stopping of the charging task and manages the charging power. After the charging vehicle is powered on, the Tbox module establishes communication with the cloud platform and simultaneously stores the unique identifier of the charging vehicle sent by the IBM module. The IBM module then starts charging at a preset power based on the user's charging task issued by the cloud platform. The Tbox module sends a connection confirmation message to the cloud platform at preset time intervals (e.g., 3 seconds, with the confirmation message being a heartbeat packet). Upon receiving a connection confirmation message from any charging vehicle, the cloud platform returns a corresponding connection response message, thus confirming a normal connection between the cloud platform and the charging vehicle. If a charging vehicle fails to receive a connection response message from the cloud platform for a preset number of consecutive attempts, the connection between the charging vehicle and the cloud platform is considered lost. If the cloud platform does not receive a connection confirmation message from the working charging vehicle within the preset connection time, it will determine that it has lost connection with the aforementioned working charging vehicle.

[0016] The aforementioned cloud platform is used to perform the following steps: S110, in response to detecting that all connected working charging vehicles have lost connection, obtain the current power level of each disconnected working charging vehicle at the time of disconnection, so as to obtain the current power level set CD=(CD1, CD2, ..., CD2). r CD s ); r = 1, 2, ..., s; s is the number of working charging vehicles that have lost connection with the cloud platform; CDr is the current power of the r-th working charging vehicle that has lost connection with the cloud platform; each charging task has a corresponding target power; the working charging vehicle that has lost connection reconnects with the cloud platform within the first time window.

[0017] S120, if CD r<CDY; and if the working charging vehicle corresponding to CDr is successfully reconnected within the preset response time period, then the working charging vehicle corresponding to CDr is identified as a first-class working charging vehicle; CDY is a preset power threshold; if CD r <CDY; and if no successful reconnection of the working charging vehicle corresponding to CDr is detected within the preset response time period, then the working charging vehicle corresponding to CDr is identified as a second type of working charging vehicle.

[0018] S130, a broadcast task is sent to the first type of working charging vehicle to send a power adjustment instruction; wherein, when the working charging vehicle is not disconnected, the charging task is performed according to the first preset power; after the working charging vehicle is disconnected, the first preset power is adjusted to the second preset power; the first preset power is greater than the second preset power.

[0019] If the cloud platform loses connection to each charging vehicle, it first obtains the battery level of each charging vehicle at the moment of disconnection. If the battery level is greater than the preset battery level threshold, it means that the current battery level is close to the target battery level. Conversely, if the battery level is less than the preset battery level threshold, it means that the current battery level is not close to the target battery level. If the connection with the cloud is lost at this time, the user will most likely need to continue charging.

[0020] 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. Furthermore, it will be unable to communicate with the cloud platform at this time. 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 broadcast task of sending a power adjustment command is sent to the first type of charging vehicles.

[0021] The first type of working charging vehicle is used to perform the following steps: S210, in response to receiving a broadcast task of a power adjustment command, broadcasts the power adjustment command according to a preset short-range communication protocol.

[0022] The second type of charging vehicle is used to perform the following steps: S310 reconnects to the cloud platform within the first time window according to the preset reconnection method.

[0023] Specifically, step S310 includes: S311 sends a reconnection request to the cloud platform and continues to perform the charging task within the first time window with the second preset power.

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

[0025] On the other hand, when a disconnection with the cloud platform is detected, the charging power of the work charging vehicle is adjusted from a first preset power to a second preset power. This is because in related technologies, the cloud platform calculates the billing for the work charging vehicle based on charging time and charging power. After the work charging vehicle disconnects from the cloud platform, the cloud platform stops timing the charging time, and the IBM module immediately stops charging, meaning the order is terminated. If the customer wants to continue the order, they need to place a new order with the cloud platform. In this application, after the work charging vehicle detects a disconnection from the cloud platform, the IBM module adjusts the charging power to a lower second preset power and executes it within a pre-set first time window. Charging at a fixed low power after a disconnection is because, compared to continuing to charge at high power, if reconnection fails or timing fails, a period of high-power charging time that cannot be billed will occur, resulting in losses. Continuing to charge at low power while waiting for reconnection reduces the losses caused to the cloud platform's corresponding merchants due to reconnection failure or billing failure. Furthermore, setting a fixed low-power charging duration ensures accurate billing even if reconnection ultimately fails.

[0026] S312, 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 connection module is used to communicate with the cloud platform.

[0027] Specifically, if no connection response information is received within the first response period of the first time window, meaning the reconnection with the cloud platform fails within the first response period of the first time window, the connection module of the charging vehicle is restarted, i.e., the Tbox module is restarted. Here, the time taken for the Tbox module to directly send a reconnection request to the cloud platform is less than the time required to restart the Tbox module, and the success rate of the Tbox module directly sending a reconnection request to the cloud platform is less than the success rate of restarting the Tbox module. Therefore, this application prioritizes using the shorter small loop (the Tbox module directly sends a reconnection request to the cloud platform). If the small loop fails, a large loop (restarting the Tbox module) is used to reconnect with the cloud platform. Through the reasonable design of the large and small loop sequences, reconnection time is saved while ensuring a high reconnection success rate.

[0028] In one exemplary embodiment of this application, after step S312, the above method further includes: S313, 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.

[0029] Specifically, if a connection response is received within the second response period of the first time window, indicating a successful reconnection in the large loop, the charging power is adjusted to a higher first preset power to execute the charging task until the target level is reached. Upon completion of charging, a charging completion signal is sent to the aforementioned cloud platform. For example, the first time window can be 90 seconds.

[0030] Subsequently, upon receiving the charging completion signal, the cloud platform can obtain: GYT1, the start time of the charging task executed by the charging vehicle corresponding to the charging completion signal at a first preset power; GYT2, the time when the charging vehicle corresponding to the charging completion signal lost connection with the cloud platform; GYT3, the time when the charging vehicle corresponding to the charging completion signal received the connection response information from the cloud platform; and GYT4, the time when the charging vehicle corresponding to the charging completion signal completed the charging task. Based on the corresponding start time, disconnection time, reconnection time, and end time, and according to GYT, the actual charging time at the first preset power and the actual charging time at the second preset power are obtained. The final energy consumption is then calculated, and the corresponding charging fee is obtained.

[0031] In this embodiment, when the charging vehicle loses connection with the cloud platform, a shorter but less successful loop is used within the first time window to attempt reconnection (the Tbox module directly sends a reconnection request to the cloud platform). If the shorter loop fails, a longer but more successful loop (restarting the Tbox module) is used to reconnect. This rational design of the sequence of the shorter and longer loops saves reconnection time while ensuring a high success rate. Furthermore, the charging power is adjusted from a first preset power to a lower second preset power upon disconnection. This is because in related technologies, the cloud platform calculates the charging vehicle's billing based on charging time and power. After the charging vehicle loses connection, the cloud platform stops timing the charging, and the IBM module immediately stops charging, thus terminating the order. If the user wants to continue charging, they need to place a new order with the cloud platform. In this embodiment, to reduce the order failure rate, after the charging vehicle detects a disconnection from the cloud platform, the IBM module adjusts the charging power to a lower, second preset power and continues charging within a pre-defined first time window. Charging at a fixed low power after disconnection is because, compared to continuing charging at high power, if reconnection or timing fails, a period of unbilled high-power charging will occur, resulting in losses. Continuing charging at low power while waiting for reconnection reduces losses to the corresponding merchant on the cloud platform due to reconnection or billing failures. Furthermore, setting a fixed low-power charging duration ensures accurate billing even if reconnection ultimately fails. This embodiment simultaneously attempts to reconnect after the charging vehicle disconnects from the cloud platform while setting low-power charging and a fixed low-power charging duration. On the one hand, it reserves sufficient reconnection time for the disconnected charging vehicle, reducing the order failure rate; on the other hand, reducing the charging power during the waiting period ensures accurate billing even if charging ultimately fails.

[0032] S320, in response to not receiving connection response information from the cloud platform, and receiving any power adjustment command broadcast according to a preset short-range communication protocol within the first time window, adjusts the second preset power to the first preset power and continues to execute the corresponding charging task until the first time window ends; 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.

[0033] S330 If a connection response message from the cloud platform is received within the time window after power adjustment, the charging task continues at the first preset power until the target power is reached; and a charging completion signal is sent to the cloud platform.

[0034] If a working charging vehicle (Type II working charging vehicle) fails to reconnect within the preset response time period and its power level is less than the preset power threshold, and receives any power adjustment instruction broadcast according to a preset short-range communication protocol within the first time window, it will adjust the second preset power to the first preset power and continue to perform the charging task until the first time window ends. If it receives a connection response information 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 to perform the above charging task at the first preset power until the target power level is reached.

[0035] In one exemplary embodiment of this application, after step S320, the aforementioned second type of working charging vehicle is used to perform the following steps: S340, broadcast the power adjustment information and corresponding transmission request according to a preset short-range communication protocol; wherein, the power adjustment information includes the power adjustment time and the corresponding unique identifier; The aforementioned first type of working charging vehicle is used to perform the following steps: S220: In response to receiving any power adjustment information and the corresponding transmission request, the power adjustment information and the corresponding transmission request are sent to the cloud platform.

[0036] The aforementioned cloud platform is also used to perform the following steps: S140, in response to receiving a charging completion signal, acquire the first working time set GYT=(GYT1, GYT2, GYT3, GYT4, GYT5) 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; GYT4 is the time when the charging vehicle corresponding to the charging completion signal completes the charging task; and GYT5 is the power adjustment time of the charging vehicle corresponding to the charging completion signal.

[0037] S150 generates 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.

[0038] In this embodiment, to enable the cloud platform to accurately obtain energy consumption and perform accurate billing, firstly, the second type of working charging vehicle, disconnected from the cloud platform, broadcasts the aforementioned power adjustment information and corresponding transmission requests according to a preset short-range communication protocol. Upon receiving any power adjustment information and corresponding transmission request, the first type of working charging vehicle sends the power adjustment information and corresponding transmission request to the cloud platform. That is, the second type of working charging vehicle sends its power adjustment information (including power adjustment time and corresponding unique identifier) ​​to the cloud platform through the first type of working charging vehicle. This allows the cloud platform to obtain 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) based on the first working time set GYT. This allows the cloud platform to obtain the corresponding energy consumption and charging cost.

[0039] In one exemplary embodiment of this application, after step S320, the aforementioned second type of working charging vehicle is used to perform the following steps: If the S350 does not receive a connection response from the cloud platform within the time window after power adjustment, it will stop executing the charging task.

[0040] Specifically, if no connection response information is received from the cloud platform within the time window after power adjustment, the IBM module controls the charging vehicle to stop charging at the end of the first time window.

[0041] S360, Get the second working time set GET=(GYT1, GYT2, GYT5).

[0042] S370 generates the energy consumption of the working charging vehicle based on GET, the duration of the first time window, the first preset power, and the second preset power.

[0043] Specifically, the energy consumption is calculated based on the charging time corresponding to the first preset power, the charging time corresponding to the second preset power, the first preset power, and the second preset power, and then the corresponding charging cost is obtained.

[0044] In one exemplary embodiment of this application, the duration of the first time window is 90 seconds.

[0045] In an exemplary embodiment of this application, if there is at least one key charging vehicle performing a charging task within a radius centered on the location of the working charging vehicle and corresponding to a preset short-range communication protocol, then after step S311, the aforementioned working charging vehicle is further used to perform the following steps: S314, according to the preset short-range communication protocol, obtain the key time interval list set 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 sending time of the j-th connection response information and the corresponding connection confirmation information received by the i-th key charging vehicle within the third time window; the end time of the third time window is the start time of the first time window.

[0046] Specifically, the short-range communication method in the preset short-range communication protocol can be Bluetooth, NFC, RFID, etc. In this embodiment, the distance between each key charging vehicle and the working charging vehicle is less than the distance corresponding to the preset short-range communication protocol, that is, the working charging vehicle can communicate with each key charging vehicle using the preset short-range communication protocol.

[0047] Here, a list of time intervals for each key charging vehicle is obtained within a certain period of time (within the third time window) prior to the moment when the working charging vehicle disconnects. Here, each time interval represents the time interval between the time of receiving the corresponding connection response information and the time of sending the corresponding connection confirmation information. The time interval between sending any two adjacent connection confirmation information is fixed, but due to network fluctuations and other factors, the time of receiving the corresponding connection response information may be different.

[0048] S315, 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 average value determination function.

[0049] Specifically, the fluctuation value corresponding to the time interval list for each key charging vehicle within the third time window is obtained. The larger the fluctuation value, the larger the difference between the time interval between the connection response information and the corresponding connection confirmation information for that key charging vehicle. This indicates that the connection between that key charging vehicle and the cloud platform is relatively unstable within the third time window, possibly due to significant network fluctuations, meaning the network connection may be unstable. Conversely, the smaller the fluctuation value, the smaller the difference between the time interval between each corresponding connection response information and the corresponding connection confirmation information for that key charging vehicle. The overall connection is relatively stable, and the smaller the fluctuation, the smaller the network fluctuations may be within this period (within the third time window), meaning the network connection is relatively stable.

[0050] S316, 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.

[0051] S317, 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.

[0052] The aforementioned cloud platform is also used to obtain the corresponding charging time and, based on the corresponding charging time and the first preset power and the second preset power, to obtain the energy consumption of the charging vehicle.

[0053] Specifically, if (a / n) ≥ n0, it indicates that most critical charging vehicles may experience significant network fluctuations within the third time window, meaning the network connection may be unstable. This could lead to some charging vehicles disconnecting. Therefore, to further reduce the probability of order failure, charging vehicles that have not successfully connected by the end of the first time window will continue charging at a second preset power within the second time window. This extends the reconnection waiting time, further reducing the probability of order failure, and the duration of the second time window is also pre-set, facilitating billing in the cloud.

[0054] In one exemplary embodiment of this application, after step S316, the aforementioned charging vehicle is further configured to perform the following steps: S318, 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.

[0055] Specifically, if no connection response information is received from the cloud platform within the second time window, it indicates that the reconnection failed within the second time window. At this time, the IBM module controls the charging vehicle to stop charging at the end of the second time window.

[0056] S319, broadcast delayed stop information and corresponding transmission request according to a preset short-range communication protocol; the delayed stop information includes the unique identifier of the working charging vehicle.

[0057] Specifically, at this time, since the actual low-power charging time of the working charging vehicle is the sum of the lengths 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 delayed stop information and corresponding sending requests according to the preset short-range communication protocol. The delayed stop information here includes the unique identifier of the working charging vehicle.

[0058] The aforementioned key charging vehicle is also used to perform the following steps: S0001, in response to receiving any delay stop information and the corresponding sending request, and without disconnecting from the cloud platform, the aforementioned delay stop information is sent to the cloud platform.

[0059] Specifically, if any key charging vehicle that has not lost connection with the cloud platform receives the delay stop information and the corresponding sending request, it will send the delay stop information to the cloud platform.

[0060] The aforementioned cloud platform is also used to perform the following steps: After receiving the delayed stop information, the cloud platform calculates the corresponding power consumption based on the unique identifier and the corresponding start time and disconnection time, and then further calculates the billing.

[0061] In this embodiment, for working charging vehicles that have extended reconnection time but still fail to reconnect successfully, in order for the cloud platform to achieve accurate billing, the delayed stop information and the corresponding sending request are broadcast through a preset short-range communication protocol that does not require a network. When any key charging vehicle that is not disconnected from the cloud platform receives the broadcast, it sends the broadcast to the cloud platform. Since the delayed stop information includes a unique identifier corresponding to the working charging vehicle, the cloud platform can obtain the low-power charging duration (the sum of the lengths of the first and second time windows) based on the delayed stop information, and can determine the corresponding working charging vehicle based on the unique identifier, so as to achieve accurate billing for it.

[0062] In one exemplary embodiment of this application, after step S315, the aforementioned charging vehicle is further configured to perform the following steps: S3100, 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.

[0063] The aforementioned cloud platform is also used to calculate the corresponding power consumption and further billing.

[0064] Specifically, if (a / n) < n0, it means that most critical charging vehicles may have less network fluctuation in the third time window, that is, the network connection may be more stable in the third time window. Therefore, the disconnection of the working charging vehicle may not be due to network reasons. In this case, if the working charging vehicle does not receive the connection response information from the cloud platform in the first time window, it will stop executing the charging task, that is, it will not extend the low-power charging time.

[0065] In one exemplary embodiment of this application, the cloud platform is further configured to perform the following steps: S001, in response to detecting a disconnection of any working charging vehicle, obtain the first time interval list set NT=(NT1, NT2, ..., NT...). g , ..., NT h ); g = 1, 2, ..., h; h is the number of charging vehicles that are not disconnected from the network; NT g List of the first time intervals for the g-th uninterrupted 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 the g-th uninterrupted charging vehicle receives connection response information within the first time window; NT gk The first time interval is the time between the sending time of the k-th connection response information and the corresponding connection confirmation information received by the g-th unconnected working charging vehicle in the first time window; the working charging vehicle that loses connection within the first time window reconnects with the cloud platform.

[0066] Specifically, when the cloud platform detects that any working charging vehicle has lost connection, it obtains a first time interval list NT. Here, it includes each first time interval within the first time window for each working charging vehicle that has not lost connection with the cloud. Each first time interval represents the time interval between receiving the corresponding connection response information and sending the corresponding connection confirmation information. The time interval between sending any two adjacent connection confirmation information is fixed, but due to network fluctuations and other factors, the time to receive the corresponding connection response information may be different.

[0067] S002, if NT is not empty, and the disconnected charging vehicle fails to reconnect successfully within the first time window, then based on NT, obtain the first time fluctuation value set NTB = (NTB1, NTB2, ..., NTB...). g , ..., NTB h ); where NTB g The first time fluctuation value corresponding to the g-th uninterrupted charging vehicle within the first time window; NTB g =(∑ f（g） k=1 (NT gk -avg(NT g )) 2 ) / f(g); avg() is the preset average value determination function.

[0068] Specifically, if NT is not empty, it indicates that there are charging vehicles that have not lost connection with the cloud, and that the charging vehicles that lost connection failed to reconnect successfully within the first time window. In this case, the first-time fluctuation value corresponding to each charging vehicle is obtained. The larger the fluctuation value, the larger the difference between the time interval between the connection response information and the corresponding connection confirmation information for that charging vehicle. In other words, the connection between that charging vehicle and the cloud platform is relatively unstable within the first time window, possibly due to large network fluctuations, meaning the network connection may not be stable. Conversely, the smaller the fluctuation value, the smaller the difference between the time interval between the corresponding connection response information and the corresponding connection confirmation information for that charging vehicle. Overall, the connection is relatively stable, and the smaller the fluctuation, the smaller the network fluctuations may be within this period (within the first time window), meaning the network connection is relatively stable.

[0069] S003, if (b / h)≥n0, then broadcast a task to send a reconnection time extension instruction to h unconnected working charging vehicles; b is the number of first time fluctuation values ​​in NTB that are greater than the preset time fluctuation value threshold; n0 is the preset fluctuation value ratio.

[0070] Specifically, if (b / h) ≥ n0, it indicates that most charging vehicles may experience significant network fluctuations within the first time window, meaning the network connection may be unstable. This could lead to some charging vehicles failing to reconnect within the first time window after disconnection. Therefore, to further reduce the order failure probability, charging vehicles that fail to reconnect by the end of the first time window will continue charging at a second preset power within the second time window. This extends the reconnection waiting time, further reducing the order failure probability, and the duration of the second time window is also pre-set for cloud computing and billing. Since charging vehicles cannot receive instructions from the cloud platform after disconnection, and the extension time set for the charging vehicle itself is the first time window, a broadcast task is performed to send a reconnection time extension instruction to each working charging vehicle that has not disconnected. In other words, each working charging vehicle that has not disconnected broadcasts the reconnection time extension instruction.

[0071] The uninterrupted charging vehicle is used to perform the following steps: S011, in response to receiving a broadcast task that sends a reconnection time extension instruction, the reconnection time extension instruction is broadcast according to a preset short-range communication protocol.

[0072] Specifically, since the charging vehicle disconnected from the cloud platform cannot receive the reconnection time extension instruction from the cloud platform, each charging vehicle that is not disconnected broadcasts the reconnection time extension instruction. Here, each charging vehicle that is not disconnected broadcasts the above-mentioned reconnection time extension instruction according to a preset short-range communication protocol.

[0073] The charging vehicle that loses connection and fails to reconnect within the first time window is used to perform the following steps: S021, in response to receiving any reconnection time extension instruction broadcast according to a preset short-range communication protocol, the charging task continues to be executed at a second preset power within the 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 charging task is executed according to the first preset power when the working charging vehicle is not disconnected; after the working charging vehicle is disconnected, the first preset power is adjusted to the second preset power; each charging task has a corresponding target power.

[0074] Specifically, when any charging vehicle is connected, it performs a charging task using a first preset power. If the connection is lost, it attempts to reconnect to the cloud platform within the first time window through steps S010-030 (performing a charging task at a second preset power). If the reconnection fails within the first time window, and a reconnection time extension instruction broadcast according to a preset short-range communication protocol is received, the charging task continues to be performed at the second preset power within the second time window. That is, the reconnection time is extended.

[0075] S022, if a connection response message is received within the second time window, the power is adjusted to the first preset power and the charging task continues until the target power is reached.

[0076] Specifically, if a connection response is received within the second time window, meaning a successful reconnection to the cloud platform is achieved within the second time window, the charging process will be adjusted back to the first preset power and continue until the target power level is reached.

[0077] In this embodiment, when the cloud platform detects that any working charging vehicle has lost connection, the working charging vehicle attempts to reconnect with the cloud platform within a first time window. If it fails to reconnect within the first time window, the platform analyzes the fluctuation of each time interval between the connection response information and the corresponding connection confirmation information of each working charging vehicle that has not lost connection. A larger fluctuation indicates a larger difference between the time intervals of the connection response information and the corresponding connection confirmation information for that working charging vehicle, meaning the connection between the working charging vehicle and the cloud platform within the first time window is relatively unstable, possibly due to significant network fluctuations, indicating an unstable network connection. Conversely, a smaller fluctuation indicates a smaller difference between the time intervals of each corresponding connection response information and the corresponding connection confirmation information for that working charging vehicle, indicating overall stability. Smaller fluctuations suggest less network fluctuations during this period (within the first time window), indicating a more stable network connection. Furthermore, if (b / h) ≥ n0, it indicates that most charging vehicles may experience significant network fluctuations within the first time window, meaning the network connection may be unstable. This could lead to some charging vehicles failing to reconnect successfully within the first time window after disconnection. Therefore, to further reduce the order failure probability, charging vehicles that fail to reconnect by the end of the first time window will continue charging at a second preset power within the second time window. This extends the reconnection waiting time, further reducing the order failure probability, and the duration of the second time window is also pre-set for billing by the cloud platform. Since the charging vehicles cannot receive instructions from the cloud platform after disconnection, and the extension time set by the charging vehicle itself is the first time window, a broadcast task is performed to send a reconnection time extension instruction to each working charging vehicle that has not disconnected. In other words, each working charging vehicle that has not disconnected broadcasts the reconnection time extension instruction. If reconnection fails within the first time window, and a reconnection time extension instruction is received according to a preset short-range communication protocol, the charging task will continue at a second preset power within the second time window, thus extending the reconnection time. Finally, if a connection response is received within the second time window, indicating successful reconnection with the cloud platform, the charging task will resume at the first preset power until the target power is reached.

[0078] This embodiment, based on reserving a reconnection time of the first time window for disconnected charging vehicles, obtains the time interval fluctuation of each undisconnected charging vehicle within the first time window through the cloud platform. This allows for the understanding of network fluctuations within the first time window and the determination of network stability. Furthermore, if network stability is low, it is considered that network fluctuations may have caused the disconnected charging vehicle to fail to reconnect within the first time window. Therefore, the reconnection time of the disconnected charging vehicle is extended. By setting reasonable reference factors, the order failure rate is further reduced, and the user experience is improved.

[0079] In one exemplary embodiment of this application, after step S120, the cloud platform is further configured to perform the following steps: S160, if any second-type working charging vehicle fails to reconnect successfully within the first time window, the sub-region identifier corresponding to the second-type working charging vehicle is obtained; each sub-region 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.

[0080] Specifically, the preset reconnection time for each sub-region is determined according to the following steps: S161, the area where the vehicle charging system is located is divided into regions according to the preset charging location to obtain a sub-region identifier set QY=(QY1, QY2, ..., QY...). x QY y ); x = 1, 2, ..., y; y is the number of sub-regions obtained by dividing the area where the vehicle charging system is located; QY x This is the area identifier for the x-th sub-region in the vehicle charging system; each sub-region has a corresponding charging location.

[0081] 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.

[0082] S162, 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 ); LTxp 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. 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.

[0083] S163, Based on 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.

[0084] S164, 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 in China has been determined to be QY. x The preset reconnection time for the corresponding sub-region.

[0085] Here, multiple historical reconnection times corresponding to various key events in the history of each sub-region are clustered. If the number of historical reconnection times in a certain cluster is greater than a preset number, it means that the charging vehicles in that sub-region mostly reconnected successfully within the corresponding time of that cluster when key events occurred in history. In this case, the longest historical reconnection time in this cluster is determined as the preset reconnection time for that sub-region.

[0086] S170, a broadcast task is sent to each first-type working charging vehicle to the corresponding second-type charging vehicle that failed to reconnect within the first time window, which includes a time extension instruction; the time extension instruction includes the corresponding preset reconnection time and a unique identifier.

[0087] Specifically, when all charging vehicles lose connection with the cloud platform, it may be due to momentary or periodic network instability. In this case, there is a high probability that each charging vehicle will successfully reconnect. Therefore, for the second type of charging vehicles that fail to reconnect within the first time window, their reconnection time is extended to reduce the order failure rate. However, since the second type of charging vehicles are disconnected from the cloud platform, the first type of charging vehicles that have successfully reconnected need to act as a medium for information transmission. That is, a broadcast task is sent to each first type of charging vehicle to the time extension instruction corresponding to each second type of charging vehicle that failed to reconnect within the first time window. Since each second type of charging vehicle is located in a different sub-region, although the time extension is performed for all of them, this application determines the corresponding extended reconnection time based on the preset reconnection time corresponding to the sub-region where each second type of charging vehicle is located.

[0088] The aforementioned first type of working charging vehicle is used to perform the following steps: S730, in response to receiving a broadcast task for each time extension instruction, broadcasts each time extension instruction according to a preset short-range communication protocol; The second type of working charging vehicle that fails to reconnect within the first time window shall perform the following steps: S850, in response to receiving the corresponding preset reconnection time and unique identifier, and the preset reconnection time is greater than the length of the first time window, then reconnects 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.

[0089] Specifically, as an example: if the preset reconnection time for the second type of working charging vehicle that fails to reconnect within the first time window is 300s, and the duration of the first time window is 90s, then the extension time is 210s.

[0090] If S860 receives a connection response from the cloud platform within the extended time, it continues to perform the charging task at the first preset power until the target power is reached; and sends a charging completion signal to the cloud platform.

[0091] In this embodiment, when all working charging vehicles lose connection with the cloud platform, it may be due to momentary or periodic network instability. In this case, there is a high probability that each working charging vehicle will successfully reconnect. Therefore, for the second type of charging vehicles that fail to reconnect within the first time window, their reconnection time is extended to reduce the order failure rate. However, since the second type of working charging vehicles are disconnected from the cloud platform, the first type of working charging vehicles that have successfully reconnected need to act as a medium for information transmission. That is, a broadcast task is sent to each first type of working charging vehicle to the time extension instruction corresponding to each second type of charging vehicle that failed to reconnect within the first time window. Since each second type of working charging vehicle is located in a different sub-region, although the time extension is performed, considering that the network condition may be affected by the location of each working charging vehicle, such as some locations having obstructions that may result in poor network conditions, this embodiment determines the corresponding extended reconnection time based on the preset reconnection time corresponding to the sub-region where each second type of working charging vehicle is located. Compared to using the same extended reconnection time for all, considering the location of each sub-region where the second-class working charging vehicle is located, it can provide a more accurate extended reconnection time for the charging vehicles in each sub-region, and more effectively reduce the probability of order failure.

[0092] Embodiments of this application also provide a computer program product including program code that, when the program product is run on an electronic device, causes the electronic device to perform the steps of the methods described above according to various exemplary embodiments of this application.

[0093] Furthermore, although the steps of the method in this application are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or a step may be broken down into multiple steps.

[0094] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, mobile terminal, or network device, etc.) to execute the methods according to the embodiments of this application.

[0095] In an exemplary embodiment of this application, an electronic device capable of implementing the above-described method is also provided.

[0096] Those skilled in the art will understand that various aspects of this application can be implemented as a system, method, or program product. Therefore, various aspects of this application can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or a combination of hardware and software implementations, collectively referred to herein as a "circuit," "module," or "system."

[0097] An electronic device according to this embodiment of the present application. The electronic device is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of this application.

[0098] Electronic devices are manifested in the form of general-purpose computing devices. Components of an electronic device may include, but are not limited to: at least one processor, at least one memory, and buses connecting different system components (including memory and processor).

[0099] The memory stores program code that can be executed by a processor, causing the processor to perform the steps described in the "Exemplary Methods" section above, according to various exemplary embodiments of this application.

[0100] The storage may include readable media in the form of volatile storage, such as random access memory (RAM) and / or cache memory, and may further include read-only memory (ROM).

[0101] The storage may also include programs / utilities having a set (at least one) of program modules, including but not limited to: an operating system, one or more applications, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0102] A bus can represent one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus that uses any of the various bus architectures.

[0103] The electronic device can also communicate with one or more external devices (such as keyboards, pointing devices, Bluetooth devices, etc.), one or more devices that enable a user to interact with the electronic device, and / or any device that enables the electronic device to communicate with one or more other computing devices (such as routers, modems, etc.). This communication can be performed via input / output (I / O) interfaces. Furthermore, the electronic device can communicate with one or more networks (such as local area networks (LANs), wide area networks (WANs), and / or public networks, such as the Internet) via a network adapter. As shown in the figure, the network adapter communicates with other modules of the electronic device via a bus. It should be understood that, although not shown in the figure, other hardware and / or software modules can be used in conjunction with the electronic device, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0104] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, terminal device, or network device, etc.) to execute the methods according to the embodiments of this application.

[0105] In exemplary embodiments of this application, a computer-readable storage medium is also provided, on which a program product capable of implementing the methods described above is stored. In some possible implementations, various aspects of this application may also be implemented as a program product including program code, which, when the program product is run on a terminal device, causes the terminal device to perform the steps of the various exemplary embodiments of this application described in the "Exemplary Methods" section above.

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

[0107] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting programs for use by or in conjunction with an instruction execution system, apparatus, or device.

[0108] The program code contained on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0109] Program code for performing the operations of this application can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0110] Furthermore, the above figures are merely illustrative of the processes included in the method according to exemplary embodiments of this application, and are not intended to be limiting. It is readily understood that the processes shown in the above figures do not indicate or limit the temporal order of these processes. Additionally, it is readily understood that these processes may be executed synchronously or asynchronously, for example, in multiple modules.

[0111] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0112] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A charging method for a charging vehicle, characterized in that, Applied to a vehicle charging system, the vehicle charging system 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 once every preset time interval; if a connection response message is received from the cloud platform, it is determined that the working charging vehicle has not lost connection. If no connection response information is 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; if the cloud platform does not receive a connection confirmation information from the working charging vehicle within a preset connection time interval, 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 detecting that all connected working charging vehicles have lost connection, obtain the current power level of each disconnected working charging vehicle at the time of disconnection, so as to obtain the current power level set CD=(CD1, CD2, ..., CD2). r CD s ); r=1,2,…,s; s is the number of working charging vehicles that have lost connection with the cloud platform; CDr is the current power of the r-th working charging vehicle that has lost connection with the cloud platform; each charging task has a corresponding target power; the working charging vehicle that has lost connection reconnects with the cloud platform within the first time window; S120, if CD r <CDY; and if the working charging vehicle corresponding to CDr is successfully reconnected within the preset response time period, then the working charging vehicle corresponding to CDr is identified as a first-class working charging vehicle; CDY is a preset power threshold; if CD r <CDY; and if no successful reconnection of the working charging vehicle corresponding to CDr is detected within the preset response time period, then the working charging vehicle corresponding to CDr will be identified as a second type of working charging vehicle. S130, a broadcast task is performed to send a power adjustment command to the first type of working charging vehicle; wherein, when the working charging vehicle is not disconnected, the charging task is performed according to the first preset power; after the working charging vehicle is disconnected, the first preset power is adjusted to the second preset power; the first preset power is greater than the second preset power; The first type of working charging vehicle is used to perform the following steps: S210, in response to receiving a broadcast task of a power adjustment command, broadcast the power adjustment command according to a preset short-range communication protocol; The second type of charging vehicle is used to perform the following steps: S310 reconnects to the cloud platform within the first time window according to the preset reconnection method; S320, in response to not receiving connection response information from the cloud platform, and receiving any power adjustment command broadcast according to a preset short-range communication protocol within the first time window, adjusts the second preset power to the first preset power and continues to execute the corresponding charging task until the first time window ends; 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. S330, if a connection response message from the cloud platform is received within the time window after power adjustment, the charging task continues at the first preset power until the target power is reached; and a charging completion signal is sent to the cloud platform.

2. The charging method for the charging vehicle according to claim 1, characterized in that, Step S310 includes: S311 sends a reconnection request to the cloud platform and continues to perform the charging task within the first time window with the second preset power. S312, 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 connection module is used to communicate with the cloud platform.

3. The charging method for the charging vehicle according to claim 1, characterized in that, After step S320, the second type of working charging vehicle is used to perform the following steps: S340, broadcast the power adjustment information and the corresponding transmission request according to a preset short-range communication protocol; wherein, the power adjustment information includes the power adjustment time and the corresponding unique identifier; The first type of charging vehicle is used to perform the following steps: S220: In response to receiving any power adjustment information and the corresponding transmission request, the power adjustment information and the corresponding transmission request are sent to the cloud platform.

4. The charging method for the charging vehicle according to claim 3, characterized in that, The cloud platform is also used to perform the following steps: S140, in response to receiving a charging completion signal, acquire the first working time set GYT=(GYT1, GYT2, GYT3, GYT4, GYT5) 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; GYT4 is the time when the charging vehicle corresponding to the charging completion signal completes the charging task; and GYT5 is the power adjustment time of the charging vehicle corresponding to the charging completion signal. S150 generates 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.

5. The charging method for the charging vehicle according to claim 4, characterized in that, After step S320, the second type of working charging vehicle is used to perform the following steps: If the S350 does not receive a connection response from the cloud platform within the time window after adjusting the power, it will stop executing the charging task. S360, retrieve the second working time set GET=(GYT1, GYT2, GYT5); S370 generates the energy consumption of the working charging vehicle based on GET, the duration of the first time window, the first preset power, and the second preset power.

6. The charging method for the charging vehicle according to claim 5, 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