A charging pile control method and system

Abstract

A charging pile control method and system, relating to the field of digital information transmission, the method comprising: after establishing a charging session with a user terminal, obtaining current charging information of the charging session, and calculating an initial power-off time according to the current charging information; sending the initial power-off time to the user terminal, so that the user terminal configures a local timing notification task based on the initial power-off time to generate a charging completion prompt information when the initial power-off time arrives; during the charging process, when a preset trigger event is detected, obtaining real-time charging information, and calculating a corrected power-off time according to the real-time charging information; when there is a deviation between the corrected power-off time and the initial power-off time, sending the corrected power-off time to the user terminal to instruct the user terminal to update the local timing notification task. The implementation of the present application can ensure the effective reach of charging status information in the scenario of poor user terminal network, and avoid economic loss of users caused by information delay.

Description

Technical Field

[0001] This application relates to the field of digital information transmission, and in particular to a charging pile control method and system. Background Technology

[0002] With the development of the electric vehicle industry, charging infrastructure, as a key supporting component, has become crucial in terms of service quality and user experience. Users need timely and accurate information about the charging status, such as whether charging is complete or if any abnormal interruptions have occurred, to manage their time effectively, move their vehicles promptly, and avoid resource hoarding and unnecessary costs.

[0003] Among related technologies, a cloud-based event-triggered notification method has been proposed. In this method, the charging station reports key events during the charging process, such as charging completion or interruption, to a cloud server in real time. Upon receiving this key event, the cloud server sends a push notification to a designated app on the user's mobile device via an application server, informing the user of the current status change of the charging station. This approach relies on the cloud as the core for information relay and distribution, achieving remote notification of charging status.

[0004] However, as charging scenarios become increasingly complex, users often find themselves in areas with unstable network signals, such as parking lots, shopping malls, or inside buildings, while waiting to charge. If a user happens to be in a network dead zone when the charging status is pushed out by the relevant technology, their mobile device will not receive the notification in time. This prevents the user from immediately knowing that charging is complete, potentially leading to unnecessary additional charges due to not being able to return to move their vehicle in time, thus impacting the overall charging service experience. Summary of the Invention

[0005] This application provides a charging pile control method and system to ensure the effective delivery of charging status information in scenarios where the user terminal network is poor, thereby avoiding economic losses to users due to information delays.

[0006] In a first aspect, this application provides a charging pile control method, applied to a charging pile control system. The method includes: after establishing a charging session with a user terminal, acquiring the current charging information of the charging session and calculating the initial power outage time based on the current charging information; sending the initial power outage time to the user terminal, so that the user terminal configures a local timed notification task based on the initial power outage time to generate a charging completion prompt message when the initial power outage time arrives; during the charging process, when a preset trigger event is detected, acquiring real-time charging information and calculating a corrected power outage time based on the real-time charging information; when there is a deviation between the corrected power outage time and the initial power outage time, sending the corrected power outage time to the user terminal to instruct the user terminal to update the local timed notification task.

[0007] In the above embodiments, the charging pile control system solves the problem of notifications not being delivered due to network issues by establishing local timed notification tasks on the user terminal and transferring the charging completion triggering mechanism from the cloud to the local terminal. At the same time, by dynamically calculating and sending corrected power outage times during the charging process, the accuracy of the local timed tasks is ensured, and efficient and reliable delivery of charging status information is achieved in weak network environments.

[0008] In conjunction with some embodiments of the first aspect, in some embodiments, after sending the initial power outage time to the user terminal, causing the user terminal to configure a local timed notification task based on the initial power outage time to generate a charging completion prompt message when the initial power outage time arrives, the method further includes: receiving location coordinate data and network signal strength reported by the user terminal; calculating the network offline probability of the user terminal within a preset time period before the local timed notification task is triggered based on the location coordinate data and network signal strength; determining the data synchronization time before the preset time period when the network offline probability exceeds a preset probability threshold; acquiring real-time charging information during the data synchronization time, calculating the corresponding corrected power outage time, and generating a synchronization data packet; and sending the synchronization data packet to the user terminal, causing the user terminal to update the local timed notification task based on the synchronization data packet.

[0009] In the above embodiments, the charging pile control system predicts the potential offline risk based on the user terminal's location and network signal, and proactively performs data synchronization before the predicted offline occurs. This allows the latest corrected power outage time to be synchronized to the user terminal in advance, avoiding the problem that the user terminal cannot receive subsequent correction information after entering a network signal blind zone, and improving the accuracy of local timed notification tasks.

[0010] In conjunction with some embodiments of the first aspect, in some embodiments, the step of acquiring real-time charging information during data synchronization, calculating the corresponding corrected power outage time, and generating a synchronization data packet specifically includes: during data synchronization, calculating the fluctuation variance value of the current data based on the current data of the charging session in historical time periods; when the fluctuation variance value is greater than a preset fluctuation threshold, calculating a time redundancy interval based on the fluctuation variance value; acquiring real-time charging information and calculating the corresponding corrected power outage time; superimposing the time redundancy interval onto the corrected power outage time to generate a power outage time window, and generating a synchronization data packet based on the power outage time window.

[0011] In the above embodiments, when the charging pile control system performs synchronization, it not only calculates and corrects the power outage time, but also introduces a time redundancy interval based on the historical current fluctuations to form a power outage time window. By providing a time range rather than a single time point, the fault tolerance of the notification is increased, and the estimated time and actual completion time are avoided due to temporary changes in the charging speed.

[0012] In conjunction with some embodiments of the first aspect, in some embodiments, after the step of sending a corrected power outage time to the user terminal to instruct the user terminal to update the local timed notification task when there is a deviation between the corrected power outage time and the initial power outage time, the method further includes: listening for a reception confirmation signal from the user terminal regarding the corrected power outage time; marking the user terminal as offline if no reception confirmation signal is detected within a preset timeout period; collecting charging data at a preset period during the period when the user terminal is offline, calculating the latest corrected power outage time, and updating the message retransmission task based on the latest corrected power outage time; pausing the message retransmission task to the user terminal until a network reconnection signal from the user terminal is detected and then resuming transmission.

[0013] In the above embodiments, the charging pile control system determines whether the information has been successfully delivered by listening to the confirmation signal. If it fails, the user is marked as offline, the transmission is paused and the latest correction data is cached. After the user terminal network is restored, the cached latest data is sent, which ensures the final consistency of the correction information after network fluctuations or interruption recovery and guarantees the integrity of data synchronization.

[0014] In conjunction with some embodiments of the first aspect, in some embodiments, before the step of marking the user terminal as offline when no confirmation signal is detected within a preset timeout period, the method further includes: receiving a heartbeat maintenance message from the user terminal, parsing the current version identifier of the local timed notification task in the heartbeat maintenance message; and sending a corrected power-off time to the user terminal when the current version identifier and the latest version identifier for correcting the power-off time are inconsistent.

[0015] In the above embodiments, the charging pile control system uses the version identifier of the local task carried in the heartbeat message to realize a lightweight status verification mechanism. It can quickly detect the data inconsistency between the terminal and the server without waiting for timeout, and actively trigger the retransmission of correction information, thus shortening the window period of data inconsistency caused by network packet loss and other reasons.

[0016] In conjunction with some embodiments of the first aspect, in some embodiments, after the step of sending a corrected power outage time to the user terminal to instruct the user terminal to update the local timed notification task when there is a deviation between the corrected power outage time and the initial power outage time, the method further includes: obtaining the historical current sequence of the charging session before the current time, calculating the standard deviation of the historical current sequence to obtain a current fluctuation index; calculating a time correction coefficient based on the current fluctuation index when the current fluctuation index exceeds a preset fluctuation threshold; superimposing the time correction coefficient onto the corrected power outage time to generate a preferred power outage time; calculating the time difference between the preferred power outage time and the corrected power outage time; and sending a correction data packet containing the preferred power outage time to the user terminal when the time difference exceeds a preset difference threshold.

[0017] In the above embodiments, the charging pile control system analyzes the standard deviation of historical current sequences to quantify the stability of the charging process, and calculates the time correction coefficient accordingly to generate a more accurate preferred power outage time. This deeply optimizes the prediction of power outage time, improves the adaptive capability and accuracy of the prediction model, and makes the corrected time sent to the user more reliable.

[0018] In conjunction with some embodiments of the first aspect, in some embodiments, the step of calculating a time correction coefficient based on the current fluctuation index when the current fluctuation index exceeds a preset fluctuation threshold specifically includes: extracting the current difference between adjacent sampling points in the historical current sequence to generate a current change sequence; calculating the number of sampling points in the current change sequence that exceed the preset change threshold to obtain a fluctuation count; obtaining the total number of sampling points in the historical current sequence and calculating the ratio of the fluctuation count to the total number of sampling points to obtain a fluctuation frequency value; and determining the time correction coefficient based on the fluctuation frequency value and a preset coefficient mapping function.

[0019] In the above embodiments, the charging pile control system objectively evaluates the stability of charging power by calculating the frequency of points where the current changes drastically, i.e., the fluctuation frequency value. This makes the adjustment of the power outage time based on evidence, enhancing the technical feasibility of the entire optimization process and the accuracy of the results.

[0020] In a second aspect, embodiments of this application provide a charging pile control system, which includes: one or more processors and a memory; the memory is coupled to the one or more processors, and the memory is used to store computer program code, which includes computer instructions, and the one or more processors call the computer instructions to cause the charging pile control system to perform the method described in the first aspect and any possible implementation thereof.

[0021] Thirdly, embodiments of this application provide a computer program product containing instructions that, when the computer program product is run on a charging pile control system, cause the charging pile control system to execute the method described in the first aspect and any possible implementation thereof.

[0022] Fourthly, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on a charging pile control system, cause the charging pile control system to perform the method described in the first aspect and any possible implementation thereof.

[0023] Understandably, the charging pile control system provided in the second aspect, the computer program product provided in the third aspect, and the computer storage medium provided in the fourth aspect are all used to execute the methods provided in the embodiments of this application. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods, and will not be repeated here.

[0024] One or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages:

[0025] 1. By adopting a mechanism that combines local timing on the terminal with cloud correction, the notification triggering is transferred from the cloud to the local device, which effectively solves the problem of users being unable to receive push notifications due to poor network conditions on the user terminal, and achieves reliable delivery of charging completion information under weak network conditions.

[0026] 2. By adopting a scheme that predicts the probability of network offline based on location and signal strength, and actively synchronizes and corrects the time before offline, the problem of information update interruption during foreseeable weak network periods is effectively solved, and the proactive maintenance of local timed tasks is realized.

[0027] 3. By adopting the mechanism of listening for confirmation signals, marking offline status, and establishing message retransmission tasks, the problem of information loss due to network interruption during transmission is effectively solved, achieving eventual data consistency after user terminal reconnection and ensuring information integrity. Attached Figure Description

[0028] Figure 1 This is a flowchart illustrating a charging pile control method in an embodiment of this application;

[0029] Figure 2 This is another flowchart illustrating the charging pile control method in this application embodiment;

[0030] Figure 3 This is a schematic diagram of the physical device structure of a charging pile control system in the embodiments of this application. Detailed Implementation

[0031] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification of this application, the singular expressions “a,” “an,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this application refers to any or all possible combinations including one or more of the listed items.

[0032] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0033] In the specific implementation scenario of this application, several technical terms and processing logics are involved. A charging session refers to the entire service cycle from the start to the end of charging, after the user scans a code or authenticates through a user terminal (such as a mobile APP) and the charging pile is bound to the user's account. The initial power outage time is a preliminary estimate made by the system at the beginning of the charging session based on the initial state of the vehicle battery (such as current charge level, target charge level, and total battery capacity) and the rated or initial power of the charging pile. The calculation of this estimated time is the basis for all subsequent operations. The core mechanism of this application is that this time is sent to the user terminal, and the terminal application sets a local timed notification task. This task relies on the terminal's own operating system clock. After being set, even if the terminal loses network connection, it can still trigger a charging completion prompt message (such as a local notification, vibration, or sound) when the preset time point is reached. To cope with the inaccurate estimation caused by changes in charging power during the charging process (such as adjustments by the battery management system BMS, dynamic power allocation of the charging pile, etc.), the system introduces the concept of correcting the power outage time. When a preset trigger event (such as a change in charging power exceeding a threshold or the arrival of a fixed time interval) occurs, the system will recalculate the power outage time based on real-time charging information. If the corrected power outage time deviates from the previous time, it will be sent to the user terminal to update the local timer task, forming a closed-loop correction process to ensure the accuracy of the local timer.

[0034] The following describes the process of the method provided in this implementation. Please refer to [link / reference]. Figure 1 This is a flowchart illustrating a charging pile control method in an embodiment of this application.

[0035] S101. After establishing a charging session with the user terminal, obtain the current charging information of the charging session and calculate the initial power outage time based on the current charging information.

[0036] A charging session refers to a complete charging service interaction between a user and a charging station. The user terminal typically refers to a mobile device such as a smartphone with a charging service application installed. Current charging information includes the target charge percentage of the vehicle battery, the current charge percentage, the total battery capacity, and the current output power of the charging station. The initial power outage time refers to the estimated future time of full charge calculated based on the current charging information.

[0037] Specifically, once the user scans the code and confirms the start of charging via their terminal, the charging pile control system establishes a charging session. At this time, the control system retrieves the required charging information from the vehicle's Battery Management System (BMS) or the user's settings on the terminal. For example, if the total battery capacity is 80kWh, the current charge level is 20%, the user sets the charge to 90%, and the current charging power is 60kW, the control system calculates the required charge as 80*(90%-20%)=56kWh, with an estimated time of 56kWh / 60kW≈0.93 hours, or approximately 56 minutes. The control system adds this time to the current system time to obtain a specific timestamp as the initial power-off time.

[0038] In some embodiments, the vehicle's BMS may not provide accurate battery capacity or current battery level. To address this, the charging station control system employs a learning mode. During a preset time period after charging begins (e.g., the first 5 minutes), it continuously monitors changes in charging power and battery percentage. By calculating (power * time) / battery percentage increment, it inversely calculates an approximate value for the total battery capacity. Based on this approximation, it then calculates the initial power-off time to improve the accuracy of the estimation.

[0039] S102. Send the initial power outage time to the user terminal, so that the user terminal can configure a local timed notification task based on the initial power outage time to generate a charging completion prompt message when the initial power outage time arrives.

[0040] Local timed notification tasks refer to timers set at the operating system level of the user terminal, and their triggering does not depend on a network connection. Charging completion notifications are notifications generated locally on the user terminal to inform the user, and can take the form of status bar notifications, pop-ups, sounds, or vibrations.

[0041] Specifically, the charging pile control system sends the initial power outage time calculated in step S101 (e.g., a specific timestamp) to the application on the user terminal via a network (such as HTTPS or MQTT protocol). Upon receiving the timestamp, the application calls the relevant interface (API) of the operating system to register a scheduled task to wake up the application or trigger a local notification at a specified time. Thus, even if the user terminal subsequently enters airplane mode or a no-signal area, the operating system clock will still execute the task on time when the specified time arrives, displaying a notification to the user that charging is complete.

[0042] In some embodiments, the user terminal's operating system may restrict background application activity to save power, causing scheduled tasks to be delayed or canceled. In response, the system will request the user to grant the application permissions such as "ignore battery optimization" or "allow background activity." Simultaneously, when sending the initial power-off time, a slightly earlier pre-warning time can be attached. The user terminal can set an additional, imprecise scheduled task to attempt to wake the application before the main task triggers, increasing the probability of the main task triggering on time.

[0043] S103. During the charging process, when a preset trigger event is detected, real-time charging information is obtained, and the power outage time is corrected based on the real-time charging information.

[0044] Among these, the preset trigger event refers to a predefined condition that can cause the power outage time to be recalculated; it can be time-driven or event-driven. Real-time charging information refers to the dynamically changing charging parameters that the charging pile can obtain at any moment during the charging process, such as real-time charging power and real-time battery percentage. The corrected power outage time is the estimated completion time recalculated based on the real-time charging information.

[0045] Specifically, during the charging session, the charging pile control system continuously monitors the charging status. When a preset trigger event is met, such as a periodic check every 5 minutes or a change in charging power exceeding 10%, the system executes this step. At this time, the system re-acquires the current real-time charging information and uses a calculation logic similar to step S101, but with the latest real-time data, to recalculate a more accurate corrected power-off time. For example, if charging is halfway complete and the remaining required energy is 20kWh, but the power drops from 60kW to 40kW, the new estimated remaining time becomes 0.5 hours, and the system calculates the new corrected power-off time accordingly.

[0046] In some embodiments, there may be frequent small fluctuations in power during the trickle charging phase at the end of the charging process. To address this, the system employs a dynamic threshold strategy. When the battery level is below 80%, a larger power change threshold (e.g., 15%) is used as the trigger event; when the battery level is above 80% and the system enters the constant voltage or trickle charging phase, a smaller time period (e.g., every 10 minutes) is used as the primary trigger event, and the power change threshold is appropriately relaxed. This avoids excessively frequent calculation and transmission of correction information due to normal power drops at the end of the charging process, reducing unnecessary system overhead and communication.

[0047] S104. When there is a discrepancy between the corrected power outage time and the initial power outage time, send the corrected power outage time to the user terminal to instruct the user terminal to update the local timed notification task.

[0048] The deviation refers to the difference between the newly calculated corrected power outage time and the power outage time currently held by the user terminal (which may be the initial power outage time or the previous corrected power outage time). Updating the local scheduled notification task means that the user terminal cancels the old scheduled task and sets a new scheduled task based on the newly received corrected power outage time.

[0049] Specifically, after calculating the corrected power outage time in step S103, the charging pile control system compares it with the currently recorded power outage time already sent to the user. To avoid meaningless minor adjustments, the system sets a deviation threshold, such as 5 minutes. Only when the absolute value of the difference between the two times exceeds this threshold will the system deem an update necessary. After determining that an update is needed, the system sends the corrected power outage time to the user terminal. Upon receiving the data, the user terminal first cancels the previously set local timed task and then resets a task using the new timestamp.

[0050] In some embodiments, the transmission and updating of the corrected power outage time can be implemented in several ways: Optionally, a complete data packet containing a new timestamp and version number can be sent, and the terminal directly replaces the old timestamp with the new timestamp; alternatively, only a time difference value (such as "-120 seconds") can be sent, and the terminal updates the task locally after performing addition and subtraction operations on the existing timestamp, which involves a smaller data volume. It is understood that other methods can also be used to transmit and update the corrected power outage time, which are not limited here.

[0051] In some embodiments, poor network conditions may cause the command to correct the power outage time to fail to be sent. To address this, the system implements a simple acknowledgment and retry mechanism. After sending the correction command, a short timer is started to wait for the user terminal's acknowledgment (ACK) packet. If no acknowledgment is received within the specified time, the system will attempt to retransmit 1-2 times.

[0052] The following provides a more detailed description of the process of the method provided in this implementation. Please refer to [link / reference]. Figure 2 This is another flowchart illustrating the charging pile control method in this application.

[0053] S201. After establishing a charging session with the user terminal, obtain the current charging information of the charging session and calculate the initial power outage time based on the current charging information.

[0054] Refer to step S101, which will not be repeated here.

[0055] It's important to note that when calculating the initial power outage time, simply using a linear model of "total charge required / current power" has limited accuracy in practical applications because the charging power is not constant throughout the process. Therefore, it's necessary to calculate based on the segmented characteristics of the charging process, including three main stages: constant current, constant voltage, and trickle charging. Specifically, the system first queries the standard charging curve model corresponding to the vehicle model based on the acquired vehicle BMS information or historical charging data. This model defines the expected charging power within different percentage charge (SOC) ranges. During calculation, the system divides the charging process from the current SOC to the target SOC into multiple segments. For example, from 20% to 80% might be a high-power constant current stage, while from 80% to 90% it enters a constant voltage stage, where the power decreases linearly or non-linearly. The system calculates the charging time required for each segment separately, and then sums the times of each segment to obtain the total estimated charging time. For example, if the current SOC is 20%, the target is 90%, and the battery capacity is 80kWh. The system model indicates that the power output is 60kW in the 20%-80% range and 30kW on average in the 80%-90% range. The calculation process is as follows: The first stage requires 80kWh * (80%-20%) = 48kWh of charging, taking 48 / 60 = 0.8 hours; the second stage requires 80kWh * (90%-80%) = 8kWh of charging, taking 8 / 30 ≈ 0.27 hours. The total estimated time is 0.8 + 0.27 = 1.07 hours. Finally, this time is added to the current system time to obtain a more accurate initial power outage time. Furthermore, this calculation can incorporate a temperature correction coefficient to fine-tune the charging efficiency of each stage based on the current battery temperature, further improving the accuracy of the prediction.

[0056] S202. Send the initial power outage time to the user terminal, so that the user terminal can configure a local timed notification task based on the initial power outage time to generate a charging completion prompt message when the initial power outage time arrives.

[0057] Refer to step S102, which will not be repeated here.

[0058] S203. Receive the location coordinate data and network signal strength reported by the user terminal.

[0059] Among them, positioning coordinate data refers to the latitude and longitude information obtained by the positioning module (such as GPS) of the user terminal. Network signal strength refers to the signal strength indication value of the mobile network (such as 4G / 5G) or Wi-Fi currently connected to the user terminal, such as RSSI (Received Signal Strength Indication) or RSRP (Reference Received Power).

[0060] Specifically, after a charging session begins, the application on the user's terminal periodically (e.g., every minute) or when network conditions change, collects its own geographic location information and the signal strength of the current network connection. After collection, the application packages this data and reports it to the charging pile control system over the network. The charging pile control system receives and stores this data associated with a specific charging session for subsequent network condition prediction.

[0061] In some embodiments, users may refuse to grant location permissions to the application due to privacy concerns. In such cases, the system will report location data as an optional item. If location data cannot be obtained, subsequent calculations of the network offline probability will rely solely on network signal strength data and historical charging behavior data, or completely skip location-based predictions and rely solely on other correction mechanisms, ensuring that the core functionality of the method remains available even when the user does not authorize location access.

[0062] S204. Based on the location coordinate data and network signal strength, calculate the probability of the user terminal being offline within a preset time period before the local timed notification task is triggered.

[0063] The network offline probability is a quantified prediction that indicates the likelihood of a user's terminal being unable to connect to the network within a specific future time period. The preset time period refers to a time window extending forward from the expected power outage time, such as 15 minutes before the expected completion time.

[0064] Specifically, the charging pile control system maintains a historical database that records network signal strength at different geographical locations (represented by location coordinates). Upon receiving data reported by a user terminal, the system queries the historical network quality records for that location. Combining the currently reported signal strength and its changing trend (e.g., a continuous decrease in signal strength), the system can use a predictive model (such as a Naive Bayes classifier or a simple weighted scoring model) to calculate the probability that the user will enter a network signal dead zone (such as deep within an underground parking garage) within the next preset time period.

[0065] In some embodiments, the probability of network offline can be calculated in several ways: Optionally, a geographic grid system can be constructed, and the average and variance of historical network signal strength within each grid can be statistically analyzed. When a user enters a grid with low average signal and high variance, the probability of offline increases. Optionally, a machine learning model can be used, taking the user's historical movement trajectory, current location, signal strength, time, etc., as features, and outputting an offline probability value between 0 and 1. It is understood that other methods can also be used to calculate the probability of network offline, and this is not limited here.

[0066] In some embodiments, there may be insufficient historical data for specific charging stations (such as newly built underground parking lots), leading to inaccurate predictions. To address this, the system employs a cold start strategy. For data-sparse areas, the system assigns a higher base offline probability and relies more heavily on real-time network signal strength trends. When the signal strength rapidly decreases and falls below a certain threshold within a short period, the system significantly increases the predicted offline probability even without historical data support, achieving a conservative yet timely early warning.

[0067] It should be noted that, taking the Naive Bayes classifier as an example, this prediction model is a probabilistic classification model. Its core is to calculate the posterior probability that a user terminal will experience network offline within a preset time period (e.g., 15 minutes) given a set of observed features (input data). The input data is a multi-dimensional feature vector, specifically including: 1) Geographic location features: dividing the charging station and surrounding area into a fine geographic grid (e.g., 10m x 10m), and inputting the grid ID where the current user is located; 2) Network status features: the current network type (e.g., 4G, 5G, Wi-Fi), signal strength value (e.g., RSRP or RSSI), and the slope of signal strength change over the past minute; 3) Time features: the current hour (to distinguish network congestion at different times). The model output is a probability value between 0 and 1, i.e., P(Offline | Geographic Grid, Network Status, Time).

[0068] The model's training relies on massive amounts of historical user behavior data. Each sample in the training dataset contains the aforementioned input features, along with a "whether offline" label. This label is obtained through backtracking analysis of historical charging session logs: if, at a certain time point t, a user terminal loses its heartbeat connection with the server for more than a preset duration within a time window from t to t+15 minutes, then the data sample at time t is labeled as 1 (offline); otherwise, it is labeled as 0. The training criterion is to maximize the posterior probability, that is, to construct the model's probability table by learning the conditional probability distribution between each feature in the training data and the "offline" label. For example, the model will calculate the frequency of the "offline" label appearing under the grid ID "Underground Garage B2 Level C Zone," and the frequency of "offline" appearing under the condition that the signal strength in that grid is below -100dBm.

[0069] In a real-world charging session, the user's mobile app periodically (e.g., every 30 seconds) reports their current location and network status. The charging station control system receives this real-time data, constructs a feature vector consistent with the one used during training, and inputs it into a pre-trained Naive Bayes model. The model uses Bayes' theorem, combined with its internally stored prior and conditional probability tables, to quickly calculate the probability of being offline for the next 15 minutes under current conditions. This output probability value is then compared to a preset probability threshold to determine whether to trigger the forward data synchronization operation in step S205.

[0070] S205. When the probability of network offline exceeds a preset probability threshold, determine the data synchronization time before the network offline probability exceeds the preset probability threshold and the data synchronization time is within a preset time period.

[0071] The preset probability threshold is a critical value used to determine whether action needs to be taken, such as 70%. The data synchronization time refers to a calculated and determined specific time point at which data synchronization operations are performed before the user terminal is expected to enter a network blind spot.

[0072] Specifically, the charging pile control system continuously executes the calculation in step S204. This step is triggered when the calculated network offline probability exceeds a set threshold (e.g., an 80% probability that the user will go offline within 15 minutes before charging is complete). At this point, the system needs to determine an optimal synchronization time. This time cannot be too early (to avoid significant changes in charging status leading to data invalidation) nor too late (to avoid the user already being offline). A reasonable strategy is to select a point in time after the current moment but before the expected offline occurrence, for example, to execute the calculation or within one minute in the future.

[0073] In some embodiments, the data synchronization time can be determined in several ways: Optionally, a fixed lead time method can be used, where the probability exceeds a threshold, and the current time is used as the data synchronization time; alternatively, a dynamic decision-making method can be used, combining the signal strength decline rate. If the decline is fast, synchronization occurs; if the decline is slow, a slightly later time point (e.g., 2 minutes later) is set as the data synchronization time to obtain charging data closer to the final state. It is understood that other methods can also be used to determine the data synchronization time, and these are not limited here.

[0074] S206. During the data synchronization time, obtain real-time charging information, calculate the corresponding corrected power outage time, and generate a synchronization data packet.

[0075] The synchronization data packet is a set of data that contains the latest corrected power outage time and other possible auxiliary information (such as time redundancy intervals), and is used to send to the user terminal.

[0076] Specifically, when the system clock reaches the data synchronization time determined in step S205, the charging pile control system acquires the real-time charging information (current battery level, current power, etc.) and calculates the most accurate corrected power outage time based on this latest information. Subsequently, the system encapsulates this corrected power outage time and any other possible data into a structured synchronization data packet, ready for transmission.

[0077] In some embodiments, the data synchronization time may arrive at a moment when the charging state is extremely unstable (e.g., the vehicle's BMS is performing battery balancing, causing drastic power fluctuations). To address this, the system checks the power stability over a short period (e.g., the previous minute) when generating the synchronization data packet. If poor stability is detected, the system can add an "unstable" flag to the synchronization data packet. Upon receiving this flag, the user terminal can notify the user that "charging speed fluctuates significantly, and the completion time is estimated," thus managing user expectations.

[0078] In some embodiments, the charging pile control system calculates the fluctuation variance of the current data based on the current data of the charging session in the historical period during the data synchronization time; when the fluctuation variance is greater than the preset fluctuation threshold, it calculates the time redundancy interval based on the fluctuation variance; it obtains real-time charging information and calculates the corresponding corrected power outage time; it superimposes the time redundancy interval onto the corrected power outage time to generate a power outage time window, and generates a synchronization data packet based on the power outage time window.

[0079] The historical time period refers to a time window prior to the calculation, such as the past 10 minutes. The variance of the current data fluctuation is a statistical indicator used to quantify the dispersion of charging current readings within that time period; a larger variance indicates greater current instability. The time redundancy interval is a time length calculated based on the variance value, used to compensate for the uncertainty in prediction caused by current fluctuations. The power outage time window is a time range comprised of the corrected power outage time and the time redundancy interval.

[0080] Specifically, when step S206 determines that forward synchronization is needed, the charging pile control system first retrieves all current sampling data for the charging session over the past 10 minutes. Then, it calculates the variance of this data. The system sets a preset fluctuation threshold; for example, if the variance exceeds this threshold, the current charging process is considered unstable. At this point, the system calculates a time redundancy interval (e.g., time redundancy interval = k * fluctuation variance, where k is a coefficient) for a time redundancy interval of, for example, 5 minutes. After calculating the corrected power outage time, the system does not directly use this time point but combines it with the time redundancy interval to generate a power outage time window. For example, if the corrected power outage time is 10:30 and the redundancy interval is 5 minutes, the window could be [10:27:30, 10:32:30]. Finally, this time window is packaged into the synchronization data packet.

[0081] It's important to note that the mapping function used to calculate the time redundancy interval based on the variance of the fluctuation is not a simple linear relationship. Instead, it's typically a non-linear piecewise function derived from extensive historical data analysis and fitting to ensure robustness and reasonableness. Specifically, the system first extracts tens of thousands of completed charging session records from the historical charging database. For each record, at different points in the charging process, the system back-calculates the current fluctuation variance over a past period (e.g., 10 minutes) and simultaneously calculates the error between the predicted remaining time at that point and the final actual remaining time. This yields a large number of (variance variance, prediction error) data pairs. Then, through statistical analysis of these data pairs, a positive correlation between the variance and the prediction error can be observed. However, this relationship is usually not significant when the variance is small, but the error increases significantly after exceeding a certain threshold. Therefore, the mapping function is designed as follows: when the variance is below a "no-impact threshold" (e.g., variance less than 5), the time redundancy interval is 0, because minor fluctuations are considered normal; when the variance is in a "linear growth interval" (e.g., between 5 and 20), the time redundancy interval increases linearly with the variance, for example, redundancy interval (minutes) = 0.5 * (variance - 5); when the variance exceeds a "high volatility threshold" (e.g., greater than 20), to prevent extreme outliers from causing the redundancy interval to become too large, the redundancy interval may enter a logarithmic curve region with slower growth, or be directly set to a capped value (e.g., 10 minutes). The goal of this function is to ensure that the increased redundancy time can cover approximately 95% of the prediction error caused by fluctuations, thereby significantly improving the reliability of the power outage time window without sacrificing too much accuracy.

[0082] In some embodiments, the charging strategies of certain vehicle models may inherently cause regular, large current fluctuations at specific stages, resulting in consistently high variance values. To address this, the system can introduce a vehicle model identification mechanism. Using vehicle information obtained during the charging protocol handshake phase, the system can query the historical charging behavior patterns of that vehicle model. If the current large fluctuation is identified as part of the normal charging curve for that model, the system can reduce or ignore the impact of the fluctuation variance on the time redundancy interval, thereby avoiding overcompensation for normal charging behavior and improving the targeting and accuracy of the prediction.

[0083] S207. Send a synchronization data packet to the user terminal, so that the user terminal updates the local timed notification task based on the synchronization data packet.

[0084] Specifically, after generating a synchronization data packet, the charging pile control system sends it to the user terminal via the network. The purpose of this operation is to complete a final, valid data update before the user terminal's network connection is lost. Upon receiving the synchronization data packet, the user terminal's application parses out the corrected power outage time and uses that time to update its local timed notification task.

[0085] Referring to step S104, the execution logic of this step is similar to sending a regular correction of the power outage time to the user terminal. The core is to seize the time window and complete the update before the predicted offline event occurs.

[0086] In some embodiments, even if synchronization is performed in advance, there may be situations where the user terminal goes offline faster than expected, causing the synchronization packet to fail to be sent. To address this, the system requests a higher-priority acknowledgment when sending the synchronization data packet. If transmission fails, the system switches to a backup offline message processing flow (as described in steps S210 to S213), storing the important synchronization packet in a retransmission queue to ensure that the user receives this critical update as soon as they reconnect.

[0087] S208. During the charging process, when a preset trigger event is detected, real-time charging information is obtained, and the power outage time is corrected based on the real-time charging information.

[0088] Refer to step S103, which will not be repeated here.

[0089] S209. When there is a discrepancy between the corrected power outage time and the initial power outage time, send the corrected power outage time to the user terminal to instruct the user terminal to update the local timed notification task.

[0090] Refer to step S104, which will not be repeated here.

[0091] In some embodiments, the charging pile control system acquires the historical current sequence of the charging session before the current moment, calculates the standard deviation of the historical current sequence, and obtains a current fluctuation index; when the current fluctuation index exceeds a preset fluctuation threshold, it calculates a time correction coefficient based on the current fluctuation index; it adds the time correction coefficient to the corrected power outage time to generate a preferred power outage time; it calculates the time difference between the preferred power outage time and the corrected power outage time; when the time difference exceeds a preset difference threshold, it sends a correction data packet containing the preferred power outage time to the user terminal.

[0092] The historical current sequence refers to a series of current values ​​collected at a fixed frequency (e.g., every 10 seconds) over a past period (e.g., 15 minutes). The current fluctuation index, represented here by standard deviation, is an indicator that quantifies the dispersion of current data around its mean. The time correction factor is a time adjustment calculated based on the fluctuation index. The preferred power outage time is a more accurate predicted time obtained by adjusting the base corrected power outage time with this factor.

[0093] Specifically, before sending the regular correction information in step S209, the system performs an additional optimization calculation. It first acquires the historical current sequence and calculates its standard deviation. If the standard deviation exceeds a preset fluctuation threshold, it indicates that the charging process is unstable. Based on this standard deviation, the system calculates a time correction coefficient using a function or lookup table. For example, the larger the fluctuation, the larger the correction coefficient, meaning more time needs to be reserved for future uncertainties. Then, the system adds (usually sums) this coefficient to the regularly calculated corrected power-off time to obtain the preferred power-off time. Finally, the preferred power-off time and the corrected power-off time are compared. If the difference is greater than a difference threshold (e.g., 2 minutes), the optimization is considered effective, and the system sends a data packet containing the preferred power-off time to the user; otherwise, the original corrected power-off time is sent.

[0094] It's important to note that calculating a time correction coefficient using a function or lookup table refers to establishing a mapping model from quantitative indicators of charging process instability to predicted time deviation. Specifically, this function or lookup table is constructed through in-depth mining of massive amounts of historical charging data. The construction process is as follows: The system analyzes each charging session in the historical database. At each time point t of the session, it extracts the historical current sequence (e.g., the past 15 minutes) and calculates the current fluctuation index (e.g., standard deviation σ). Simultaneously, the system records the corrected power outage time T_pred calculated based on the information at time t and compares it with the final actual power outage time T_actual for that session, obtaining the prediction error ΔT = T_actual - T_pred. By processing tens of thousands of sessions, the system accumulates a large number of (σ, ΔT) data points. This function or lookup table is the result of fitting or binning these data points. If a function-based approach is used, multinomial regression or a more complex machine learning regression model is typically employed to fit the relationship between σ and ΔT, resulting in a time correction coefficient = f(σ). This function outputs the most probable prediction error as the correction coefficient based on the input real-time standard deviation. If a lookup table approach is used, the system divides the range of the standard deviation σ into multiple intervals (e.g., 0-0.5, 0.5-1.0, etc.), and then calculates the mean or median of ΔT for all data points falling within each interval, using this as the correction coefficient for that interval. For example, the lookup table might show that when the standard deviation is between 1.5 and 2.0, an average of 3.5 minutes of correction time is required. In practice, after calculating the real-time current fluctuation index, the system directly retrieves the corresponding time correction coefficient using this function or the lookup table.

[0095] In addition, to calculate the time correction coefficient, in some embodiments, the charging pile control system extracts the current difference between adjacent sampling points in the historical current sequence to generate a current change sequence; calculates the number of sampling points in the current change sequence that exceed a preset change threshold to obtain a fluctuation count; obtains the total number of sampling points in the historical current sequence and calculates the ratio of the fluctuation count to the total number of sampling points to obtain the fluctuation frequency value; and determines the time correction coefficient based on the fluctuation frequency value and the preset coefficient mapping function.

[0096] The current change sequence is a new sequence composed of the absolute values ​​of the differences between every two adjacent sampling points in the historical current sequence. The fluctuation count refers to the number of points in the current change sequence whose values ​​exceed a preset change threshold (e.g., 5A). The fluctuation frequency value is the ratio of the fluctuation count to the total number of sampling points, intuitively reflecting the frequency of drastic current changes. The preset coefficient mapping function is a function or rule table that converts the fluctuation frequency value into specific time-corrected seconds or minutes.

[0097] Specifically, this embodiment details a method for calculating the time correction coefficient mentioned above. The system first performs a difference operation on the historical current sequence to obtain a current change sequence reflecting the rate of current change. Then, the system iterates through this change sequence, counting the number of points with particularly large changes, i.e., fluctuation count. For example, if a total of 100 points are sampled, and 10 of them have current changes exceeding 5A, the fluctuation count is 10. Next, the fluctuation count is divided by the total number of sampled points to obtain the fluctuation frequency value (10 / 100 = 0.1). Finally, the system uses a preset mapping function, such as time correction coefficient = fluctuation frequency value * 300 seconds, to determine the final time correction coefficient (0.1 * 300 = 30 seconds). This coefficient is then used to generate the optimal power outage time.

[0098] In some embodiments, this step can be implemented in several ways: Optionally, the preset coefficient mapping function can be a piecewise function, for example, the coefficient is 0 when the fluctuation frequency is between 0 and 0.05; the coefficient increases linearly between 0.05 and 0.1; and the coefficient is a large fixed value when it exceeds 0.1. This can better fit the actual impact; Optionally, when calculating the fluctuation count, not only are the points exceeding the threshold counted, but the degree of exceeding the threshold is also weighted, that is, the more drastic the change, the greater the weight is given, so that the calculation result can better reflect the severity of the fluctuation. It is understood that other methods can also be used to implement this step, which are not limited here.

[0099] It's important to note that the time correction coefficient is determined based on the fluctuation frequency value and a preset coefficient mapping function. Here, the input is no longer the generalized standard deviation, but rather the more physically interpretable fluctuation frequency value. Specifically, the system analyzes historical data to explore the quantitative relationship between the frequency of drastic current changes and the final charging time prediction deviation. Specifically, the system processes a large number of historical charging records, calculating the fluctuation frequency value (i.e., the ratio of the number of sampling points where the current change exceeds the threshold to the total number of sampling points) for each record at different times, and correlating it with the prediction error at that time. Finally, a mapping function is constructed by using regression analysis or binning statistics on these (fluctuation frequency value, prediction error) data pairs. The output of this function f(fluctuation frequency value) is the time correction coefficient. For example, data analysis reveals that when the fluctuation frequency value is 0 (indicating stable current), the prediction error is close to 0; when the fluctuation frequency value is 0.05, the predicted time is on average 2 minutes faster than the actual time; and when the fluctuation frequency value reaches 0.15, the predicted time may be on average 8 minutes faster. This mapping function can be modeled as a nonlinear function, such as the time correction coefficient (minutes) = a * (fluctuation frequency value)^2 + b * (fluctuation frequency value), where coefficients a and b are obtained by fitting the above data. In practical use, after the system calculates the current fluctuation frequency value, it substitutes it into this function to obtain a dynamically adjusted time correction coefficient, which is used to generate a more accurate optimal power outage time. This method is better at capturing the abrupt changes in the charging process than simply using standard deviation, thus making the correction more targeted.

[0100] Furthermore, in some embodiments, the sampling frequency may affect the calculation results. For example, a higher sampling frequency and a larger total number of sampling points may lead to a lower calculated fluctuation frequency value. To address this, the system design incorporates the sampling frequency as a standardized parameter. The preset variation threshold and preset coefficient mapping function should be matched with a fixed sampling frequency. Alternatively, when calculating the fluctuation frequency value, it can be normalized to a unit time (e.g., the number of fluctuations per minute), i.e., fluctuation frequency value = fluctuation count / total observation time (minutes). This eliminates the influence of the sampling frequency itself on the final result, making the algorithm more universal.

[0101] S210. Listen for the confirmation signal from the user terminal regarding the correction of the power outage time.

[0102] The Acknowledgment (ACK) signal is a short message sent back to the server by the user terminal after successfully receiving and processing an instruction (such as updating the power outage time), indicating that the operation was successful.

[0103] Specifically, after the charging pile control system sends a corrected power outage time (or synchronization data packet) to the user terminal via the network each time, it does not consider the task complete. Instead, it starts a timer and enters a waiting state, listening for an acknowledgment packet from the user terminal. This acknowledgment signal is a design feature at the communication protocol level to ensure the reliability of message transmission.

[0104] In some embodiments, the listening for acknowledgment signals can be implemented in several ways: Optionally, it can be defined in the application layer protocol that each downlink instruction requires a corresponding uplink ACK response, and the server matches the instruction and acknowledgment using the message ID; alternatively, it can utilize the reliable transmission characteristics of the TCP protocol itself. Although TCP can guarantee the delivery of data packets, adding an acknowledgment at the application layer can ensure that the business logic has also been executed correctly (e.g., the timer has been successfully updated). It is understood that other methods can also be used to listen for acknowledgment signals, and this is not limited here.

[0105] In some embodiments, network latency may cause acknowledgment signals to arrive late, but not be lost. To address this, the system's timeout period needs to have some redundancy. This timeout period can be dynamically adjusted based on historical network latency data. For example, during peak network periods, the timeout period can be appropriately extended to reduce false positives caused by network jitter.

[0106] S211. If no confirmation signal is detected within the preset timeout period, the user terminal is marked as offline.

[0107] The preset timeout period is a reasonable duration, such as 5 seconds. Offline status is an internal identifier maintained by the charging pile control system for the user terminal, indicating that effective two-way communication with the terminal is currently unavailable.

[0108] Specifically, if the charging pile control system does not receive a reception confirmation signal from the user terminal after the timer started in step S210 reaches the preset timeout limit, the system will determine that the user terminal is likely in a network unreachable state. At this time, the system will associate the user terminal's device identifier (such as device ID or user ID) with an "offline" tag in its internal database or cache.

[0109] In some embodiments, offline status can be marked in several ways: optionally, a boolean field `is_offline` can be added to the user session information and set to `true`; optionally, the device ID can be added to a dedicated "offline device" set for quick lookup. It is understood that other methods can also be used to mark offline status, and this is not limited here.

[0110] In some embodiments, a timeout may occur due to accidental network packet loss, even though the user terminal is not actually offline. To address this, the system can perform a proactive "ping" before marking the user as offline. That is, after the timeout, instead of marking the user as offline, a lightweight heartbeat request packet is sent, followed by a shorter timeout. If this ping also fails, the user is confirmed offline. This double-confirmation mechanism effectively reduces the false positive rate.

[0111] In some embodiments, the charging pile control system receives the heartbeat maintenance message from the user terminal, parses the current version identifier of the local timed notification task in the heartbeat maintenance message, and sends the corrected power outage time to the user terminal when the current version identifier and the latest version identifier for correcting the power outage time are inconsistent.

[0112] Heartbeat maintenance messages are lightweight data packets periodically sent by user terminals to maintain a persistent connection with the server. A version identifier is a string or number used to mark the version of the power outage time data, such as a timestamp or an incrementing sequence number. Each time the server generates a new corrected power outage time, it assigns a new version identifier.

[0113] Specifically, this method serves as a supplement and optimization to the timeout judgment mechanism in step S211. When the user terminal's application sends a regular heartbeat packet, it also reports the version identifier of its currently locally stored power outage time. After receiving the heartbeat packet, the charging pile control system, in addition to confirming that the user is online, will parse the version identifier and compare it with the latest version identifier saved for the user on the server. If the two are found to be inconsistent, it means that the user terminal's data is outdated (possibly because a previous update command was lost in the network, but since the network was not completely interrupted, the heartbeat can still be reached). In this case, the system does not need to wait for the timeout and will actively resend the latest corrected power outage time and its version identifier to the user terminal.

[0114] In some embodiments, this step can be implemented in several ways: Optionally, the version identifier can be a millisecond-level timestamp of the correction time generated by the server, which is simple and unique; alternatively, the version identifier can be an integer starting from 1, incremented by 1 with each update, and the terminal and server synchronize this integer value. It is understood that other methods can also be used to implement this step, which are not limited here.

[0115] In some embodiments, the heartbeat message itself may be lost. In this case, the heartbeat verification mechanism and the aforementioned timeout retransmission mechanism are complementary, not replacements. The heartbeat mechanism can quickly handle scenarios where there is partial packet loss but the connection remains intact, while the timeout retransmission mechanism handles scenarios where the network is completely interrupted. The combination of the two can cover a wider range of network anomalies. Even if the heartbeat packet carrying the version number is lost, the timeout mechanism will still be triggered if subsequent correction information fails to be sent, ensuring eventual data consistency.

[0116] S212. While the user terminal is offline, collect charging data at a preset period, calculate the latest corrected power outage time, and update the message retransmission task based on the latest corrected power outage time.

[0117] The preset period refers to the time interval at which the system continues to calculate and correct the power outage time in the background after the user goes offline, for example, every 5 minutes. The message retransmission task refers to a data structure associated with the offline user, which stores the latest one or more messages to be sent to that user.

[0118] Specifically, when a user terminal is marked as offline, the charging pile control system will stop sending any new correction information to it to avoid wasting network resources. However, the system will not stop serving that user. It will switch to a silent update mode, continuing to collect charging data from the server and calculate the latest corrected power outage time according to a preset cycle. Whenever a new corrected power outage time is calculated, the system will not attempt to send it, but will instead update the message retransmission task associated with that user, ensuring that the task always stores the most accurate power outage time to date.

[0119] In some embodiments, the update of the message retransmission task can be implemented in several ways: Optionally, a message queue can be maintained for each offline user, and new messages can be enqueued after each calculation, with a queue length limit set; alternatively, only one message slot can be maintained for each offline user, and the latest corrected power outage time can be overwritten after each calculation, ensuring that only the final and latest message is retransmitted. It is understood that other methods can also be used to update the message retransmission task, which are not limited here.

[0120] S213. Suspend the message retransmission task to the user terminal until a network reconnection signal from the user terminal is detected and then resume transmission.

[0121] In this context, a network reconnection signal refers to a signal actively sent by a user terminal to the server after restoring its network connection, indicating that it has returned to online status. This is typically a heartbeat packet or a new service request.

[0122] Specifically, while a user terminal is offline, all prepared correction information is temporarily stored in a message retransmission task, and the sending operation is suspended. The charging pile control system continuously monitors all incoming connections and requests. When it detects that a user terminal previously marked as offline has resent a heartbeat packet or initiated any form of API request, the system considers that the terminal has restored its network connection. At this time, the system removes its offline mark and triggers a message retransmission task, sending the latest corrected power outage time cached therein to the user terminal.

[0123] In some embodiments, network reconnection detection can be implemented in several ways: optionally, by listening for successful reconnection events of long-lived connections (such as MQTT); optionally, by checking the device identifier in the received HTTP request header to determine whether it is in the offline device list. It is understood that other methods can also be used to implement network reconnection detection, and this is not limited here.

[0124] In some embodiments, user terminal networks may be extremely unstable, experiencing repeated disconnections and reconnections within a short period. To address this, the system can implement a transmission protection mechanism. After detecting a reconnection and successfully sending a retransmission message, the system initiates a brief silence period (e.g., 30 seconds). During this period, even if the user is detected disconnecting and reconnecting again, the message will not be retransmitted to avoid message storms caused by network jitter.

[0125] In this embodiment, a collaborative control mechanism is adopted, which establishes a local timed notification task on the user terminal side and dynamically corrects and proactively synchronizes the charging pile control system based on changes in charging status and network environment predictions. This achieves closed-loop feedback and adjustment of charging completion time estimation, effectively solving the problem of notification delay or failure caused by relying solely on cloud push in the prior art when the user terminal network is poor. This results in highly reliable and accurate delivery of charging status information, protecting user interests and optimizing the charging service experience.

[0126] The charging pile control system in the embodiments of this invention is described below from the perspective of hardware processing. Please refer to [link / reference]. Figure 3 This is a schematic diagram of the physical device structure of a charging pile control system in an embodiment of this application.

[0127] It should be noted that, Figure 3 The structure of the charging pile control system shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0128] like Figure 3As shown, the charging pile control system includes a CPU 301, which can perform various appropriate actions and processes according to a program stored in ROM 302 or a program loaded into RAM 303 from storage section 308, such as executing the methods described in the above embodiments. RAM 303 also stores various programs and data required for system operation. The CPU 301, ROM 302, and RAM 303 are interconnected via bus 304. I / O interface 305 is also connected to bus 304.

[0129] The following components are connected to I / O interface 305: input section 306 including audio input devices, push-button switches, etc.; output section 307 including liquid crystal display (LCD) and audio output devices, indicator lights, etc.; storage section 308 including hard disks, etc.; and communication section 309 including network interface cards such as LAN (Local Area Network) cards, modems, etc. Communication section 309 performs communication processing via a network such as the Internet. Drive 310 is also connected to I / O interface 305 as needed. Removable media 311, such as disks, optical disks, magneto-optical disks, semiconductor memories, etc., are installed on drive 310 as needed so that computer programs read from them can be installed into storage section 308 as needed.

[0130] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing computer programs for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 309, and / or installed from removable medium 311. When the computer program is executed by CPU 301, it performs the various functions defined in the present invention.

[0131] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, program segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those shown in the drawings.

[0132] Specifically, the charging pile control system of this embodiment includes a processor and a memory. The memory stores a computer program. When the computer program is executed by the processor, it implements the charging pile control method provided in the above embodiment.

[0133] In another aspect, the present invention also provides a computer-readable storage medium, which may be included in the charging pile control system described in the above embodiments; or it may exist independently and not be assembled into the charging pile control system. The storage medium carries one or more computer programs, which, when executed by a processor of the charging pile control system, cause the charging pile control system to implement the charging pile control method provided in the above embodiments.

[0134] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0135] As used in the above embodiments, depending on the context, the term "when..." can be interpreted as meaning "if...", "after...", "in response to determining...", or "in response to detecting...". Similarly, depending on the context, the phrase "when determining..." or "if (the stated condition or event) is interpreted as meaning "if determining...", "in response to determining...", "when (the stated condition or event) is detected", or "in response to detecting (the stated condition or event)".

Claims

1. A charging pile control method, characterized in that, The method, applied to a charging pile control system, includes: After establishing a charging session with the user terminal, the current charging information of the charging session is obtained, and the initial power outage time is calculated based on the current charging information. Send the initial power outage time to the user terminal, so that the user terminal configures a local timed notification task based on the initial power outage time to generate a charging completion prompt message when the initial power outage time arrives; During the charging process, when a preset trigger event is detected, real-time charging information is acquired, and the power outage time is calculated and corrected based on the real-time charging information. When there is a deviation between the corrected power outage time and the initial power outage time, the corrected power outage time is sent to the user terminal to instruct the user terminal to update the local timed notification task.

2. The method according to claim 1, characterized in that, After the step of sending the initial power outage time to the user terminal, causing the user terminal to configure a local timed notification task based on the initial power outage time to generate a charging completion prompt message when the initial power outage time arrives, the method further includes: Receive the location coordinate data and network signal strength reported by the user terminal; Based on the location coordinate data and the network signal strength, calculate the probability of the user terminal being offline within a preset time period before the local timed notification task is triggered. When the network offline probability exceeds a preset probability threshold, determine the data synchronization time before the preset time period when the network offline probability is greater than the preset probability threshold. Real-time charging information is acquired during the data synchronization time, and the corresponding corrected power outage time is calculated to generate a synchronization data packet; The synchronization data packet is sent to the user terminal, so that the user terminal updates the local timed notification task based on the synchronization data packet.

3. The method according to claim 2, characterized in that, The step of acquiring real-time charging information during the data synchronization time, calculating the corresponding corrected power outage time, and generating a synchronization data packet specifically includes: During the data synchronization time, the fluctuation variance of the current data is calculated based on the current data of the charging session within the historical time period. When the fluctuation variance value is greater than a preset fluctuation threshold, a time redundancy interval is calculated based on the fluctuation variance value. Obtain real-time charging information and calculate the corresponding corrected power outage time; The time redundancy interval is superimposed on the corrected power outage time to generate a power outage time window, and a synchronization data packet is generated based on the power outage time window.

4. The method according to claim 1, characterized in that, After the step of sending the corrected power outage time to the user terminal to instruct the user terminal to update the local timed notification task when there is a deviation between the corrected power outage time and the initial power outage time, the method further includes: Listen for the confirmation signal received from the user terminal regarding the corrected power outage time; If the received confirmation signal is not detected within the preset timeout period, the user terminal will be marked as offline. While the user terminal is offline, charging data is collected at a preset period, the latest corrected power outage time is calculated, and the message retransmission task is updated based on the latest corrected power outage time. The message retransmission task to the user terminal is suspended until a network reconnection signal from the user terminal is detected, at which point transmission is resumed.

5. The method according to claim 4, characterized in that, Before the step of marking the user terminal as offline when no confirmation signal is detected within a preset timeout period, the method further includes: Receive the heartbeat maintenance message from the user terminal and parse the current version identifier of the local timed notification task in the heartbeat maintenance message; If the current version identifier and the latest version identifier of the corrected power outage time are inconsistent, the corrected power outage time is sent to the user terminal.

6. The method according to claim 1, characterized in that, After the step of sending the corrected power outage time to the user terminal to instruct the user terminal to update the local timed notification task when there is a deviation between the corrected power outage time and the initial power outage time, the method further includes: Obtain the historical current sequence of the charging session before the current moment, calculate the standard deviation of the historical current sequence, and obtain the current fluctuation index; When the current fluctuation index exceeds a preset fluctuation threshold, a time correction coefficient is calculated based on the current fluctuation index. The time correction coefficient is added to the corrected power outage time to generate the preferred power outage time; Calculate the time difference between the preferred power outage time and the corrected power outage time; When the time difference exceeds a preset difference threshold, a correction data packet containing the preferred power outage time is sent to the user terminal.

7. The method according to claim 6, characterized in that, The step of calculating a time correction coefficient based on the current fluctuation index when the current fluctuation index exceeds a preset fluctuation threshold specifically includes: Extract the current difference between adjacent sampling points in the historical current sequence to generate a current change sequence; The number of sampling points in the current change sequence that exceed a preset change threshold is calculated to obtain the fluctuation count; Obtain the total number of sampling points in the historical current sequence, and calculate the ratio of the fluctuation count to the total number of sampling points to obtain the fluctuation frequency value; The time correction coefficient is determined based on the fluctuation frequency value and the preset coefficient mapping function.

8. A charging pile control system, characterized in that, The charging pile control system includes: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code including computer instructions, and the one or more processors call the computer instructions to cause the charging pile control system to perform the method as described in any one of claims 1-7.

9. A computer-readable storage medium comprising instructions, characterized in that, When the instruction is executed on the charging pile control system, the charging pile control system performs the method as described in any one of claims 1-7.

10. A computer program product, characterized in that, When the computer program product is run on the charging pile control system, it causes the charging pile control system to perform the method as described in any one of claims 1-7.

Images