Soft bus-based charging station battery life prediction method and related device

Abstract

The application provides a soft bus-based charging station battery life prediction method and related device. The method obtains charging data and working data of a target vehicle on multiple charging devices through a soft bus module. Then, the charging data is processed in chronological order, the device computing resources of the computing module of each device in the multiple charging devices are determined according to the working data. Then, the charging data sequence is divided according to a computing task division rule, and multiple division tasks are allocated to the computing module on each charging device in the multiple charging devices according to a preset computing resource allocation rule to obtain multiple computing tasks. The elements in the charging data sequence in the multiple computing tasks are input into a preset battery life prediction model to obtain multiple prediction results. Finally, the battery prediction life is optimized based on a preset attenuation factor to obtain a target prediction result. The battery life prediction accuracy and efficiency are improved.

Description

Technical Field

[0001] This application relates to the field of intelligent power distribution technology, and in particular to a method and related device for predicting the battery life of a charging station based on a soft bus. Background Technology

[0002] Currently, the electric vehicle industry is experiencing rapid development. As of June 2025, the number of new energy vehicles in China reached 36.89 million, accounting for over 10% of the total number of vehicles, with pure electric vehicles accounting for over 69%. New registrations in the first half of the year increased by 27.86% year-on-year, with a penetration rate approaching 45%, marking a shift in the market from policy-driven to endogenous growth. Behind this explosive growth is the continuous iteration of battery technology as the core support. However, large-scale application has also exposed key pain points: insufficient accuracy in predicting the lifespan of power batteries leads to increased maintenance costs; traditional methods rely on laboratory environment simulations, which are difficult to adapt to complex and changing actual operating conditions, such as temperature fluctuations and differences in charge-discharge cycles, directly affecting user experience and asset value retention. Predicting the lifespan of vehicle power batteries based on charging piles has become a hot topic and is increasingly evolving into a standardized function. Currently, charging piles predict battery lifespan using fixed algorithms based on data from the last charging process or artificial intelligence models based on historical data. Users do not always charge at the same charging station, so user vehicle data is scattered across various charging stations within the station. Due to the limitations of data from a single charging station, the accuracy of battery life prediction will decrease significantly.

[0003] Therefore, how to improve the accuracy and efficiency of power battery life prediction by analyzing the charging status of battery stations is an urgent problem to be solved. Summary of the Invention

[0004] This application provides a method and related apparatus for predicting the battery life of a charging station based on a soft bus, which improves the accuracy and efficiency of battery life prediction.

[0005] In a first aspect, embodiments of this application provide a method for predicting the battery life of a charging station based on a soft bus, applied to a control module of a local area network (LAN). The LAN consists of multiple charging devices interconnected via physical communication links. Each of the multiple charging devices is equipped with a computing module and a soft bus module. The soft bus module, based on a soft bus protocol, enables signaling interaction between the charging devices through the physical communication links. The method includes:

[0006] The soft bus module is controlled to acquire charging data of the target vehicle on the multiple charging devices, and to acquire the working data of the multiple charging devices.

[0007] The charging data is processed in chronological order to obtain a charging data sequence;

[0008] Based on the working data, determine the device computing resources of the computing module of each of the plurality of charging devices to obtain computing resource data;

[0009] The charging data sequence is divided according to a preset calculation task division rule to obtain multiple division calculation tasks;

[0010] According to a preset computing resource allocation rule, the multiple partitioning tasks are allocated to the computing modules of each of the multiple charging devices to obtain multiple computing tasks; each of the multiple computing tasks includes at least one element in the charging data sequence.

[0011] Elements from the charging data sequence in the multiple computing tasks are input into a preset battery life prediction model to obtain multiple prediction results;

[0012] Based on a preset attenuation factor, a preset lifetime prediction weight calculation formula, and the charging data sequence, lifetime prediction weights are determined to obtain multiple lifetime prediction weights.

[0013] The target prediction result is obtained by weighting the multiple prediction results according to the multiple lifetime prediction weights.

[0014] Secondly, embodiments of this application provide a charging station battery life prediction device based on a soft bus, applied to a control module of a local area network (LAN). The LAN consists of multiple charging devices interconnected via physical communication links. Each of the multiple charging devices is equipped with a computing module and a soft bus module. The soft bus module, based on a soft bus protocol, enables signaling interaction between the charging devices through the physical communication links. The device includes:

[0015] The acquisition unit is used to control the soft bus module to acquire the charging data of the target vehicle on the multiple charging devices, and to acquire the working data of the multiple charging devices;

[0016] A determining unit is used to process the charging data in chronological order to obtain a charging data sequence; and to determine the device computing resources of the computing module of each of the plurality of charging devices based on the working data to obtain computing resource data.

[0017] The control unit is used to divide the charging data sequence according to a preset computing task division rule to obtain multiple division computing tasks; and to allocate the multiple division tasks to the computing modules on each of the multiple charging devices according to a preset computing resource allocation rule to obtain multiple computing tasks; each of the multiple computing tasks includes at least one element in the charging data sequence.

[0018] The calculation unit is used to input elements from the charging data sequence in the multiple calculation tasks into a preset battery life prediction model to obtain multiple prediction results; determine life prediction weights based on a preset attenuation factor, a preset life prediction weight calculation formula, and the charging data sequence to obtain multiple life prediction weights; and perform weighted calculation on the multiple prediction results according to the multiple life prediction weights to obtain a target prediction result.

[0019] Thirdly, embodiments of this application provide a charging device, including a processor, a memory, a communication interface, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the processor, and the programs include instructions for performing steps in any method of the first aspect of this application.

[0020] Fourthly, embodiments of this application provide a charging station battery life prediction system based on a soft bus, wherein the charging station battery life prediction system based on the soft bus is used to execute instructions for the steps in any of the methods in the first aspect of embodiments of this application.

[0021] Fifthly, embodiments of this application provide a computer-readable storage medium storing a computer program for electronic data interchange, wherein the computer program causes a computer to perform some or all of the steps described in any method of the first aspect of this application.

[0022] Sixthly, embodiments of this application provide a computer program product, wherein the computer program product includes a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps described in any method of the first aspect of this application. The computer program product may be a software installation package.

[0023] By implementing the embodiments of this application, the following beneficial effects are achieved:

[0024] This application provides a method and related apparatus for predicting the battery life of a charging station based on a soft bus. The method is applied to the control module of a local area network (LAN), which consists of multiple charging devices interconnected via physical communication links. Each charging device has a computing module and a soft bus module. The soft bus module uses a soft bus protocol to achieve signaling interaction between the charging devices via the physical communication links. The method includes: controlling the soft bus module to acquire charging data of a target vehicle on multiple charging devices, and acquiring working data of multiple charging devices; processing the charging data in chronological order to obtain a charging data sequence; and determining the computing resources of the computing module of each device based on the working data to obtain the number of computing resources. According to the pre-defined computational task partitioning rules, the charging data sequence is divided into multiple partitioned computational tasks. These tasks are then allocated to the computational modules of each of the multiple charging devices according to pre-defined computational resource allocation rules, resulting in multiple computational tasks. Each computational task includes at least one element from the charging data sequence. The elements from the charging data sequence in these multiple computational tasks are input into a pre-defined battery life prediction model, yielding multiple prediction results. Based on a pre-defined attenuation factor, a pre-defined life prediction weight calculation formula, and the charging data sequence, life prediction weights are determined, resulting in multiple life prediction weights. These weights are then used to weight the multiple prediction results to obtain the target prediction result. Thus, on the one hand, based on softbus technology, the historical charging data of each charging device within the charging station is integrated to achieve data sharing, thereby improving the accuracy of battery life prediction. On the other hand, through the self-organizing network capability and distributed computing power allocation and scheduling of the softbus, prediction tasks are rationally allocated to idle devices, reducing the resource consumption of individual devices and improving prediction efficiency. Attached Figure Description

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

[0026] Figure 1 This is an architecture diagram of a vehicle battery life prediction system based on a soft bus, provided in an embodiment of this application.

[0027] Figure 2 This is a schematic diagram of the structure of a charging device provided in an embodiment of this application;

[0028] Figure 3 This is a flowchart illustrating a method for predicting the battery life of a charging station based on a soft bus, as provided in an embodiment of this application.

[0029] Figure 4 This is a schematic diagram of a charging station networking structure based on a soft bus, provided in an embodiment of this application.

[0030] Figure 5 This is a schematic diagram of a soft bus network structure provided in an embodiment of this application;

[0031] Figure 6 This is a schematic diagram of an active networking process based on a soft bus, provided in an embodiment of this application.

[0032] Figure 7 This is a schematic diagram of a passive networking process based on a soft bus provided in an embodiment of this application;

[0033] Figure 8 This is a schematic diagram of a historical sequence management process based on a soft bus, provided in an embodiment of this application.

[0034] Figure 9 This is a functional module block diagram of a charging station battery life prediction device based on a soft bus, provided in an embodiment of this application. Detailed Implementation

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

[0036] The terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. 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 apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0037] In this application's embodiments, "connection" refers to various connection methods, such as direct or indirect connections, to achieve communication between devices, and this application's embodiments do not impose any limitations on this. The term "embodiment" as used herein means that a specific feature, structure, or characteristic described in connection with an embodiment can be included in at least one embodiment of this application. The appearance of this phrase in various locations throughout the specification does not necessarily refer to the same embodiment, nor is it a mutually exclusive, independent, or alternative embodiment. Those skilled in the art will explicitly and implicitly understand that the embodiments described herein can be combined with other embodiments.

[0038] The following is an explanation of the relevant terms used in this application:

[0039] Soft bus: It is a software architecture and communication protocol stack that runs on local area network devices. It builds a distributed collaborative framework on top of existing physical network connections, which supports automatic device discovery, service identification, standardized data exchange and resource sharing. It is a key software foundation for realizing cross-device data and computing power integration.

[0040] In the electric vehicle sector, the accuracy of power battery life prediction directly impacts the user experience. Existing charging station prediction methods rely solely on single-charge data or localized historical data from individual charging stations. Since users charge at different stations, the data is scattered across various charging points, leading to a significant decrease in prediction accuracy. Furthermore, the data limitations of individual charging stations prevent prediction algorithms from fully utilizing global data, and centralized computing deployment can result in excessive equipment resource consumption, affecting system response and stability.

[0041] To address the aforementioned problems, this application provides a method and related apparatus for predicting the battery life of a charging station based on a soft bus. This method is applied to a control module of a local area network (LAN). The LAN consists of multiple charging devices interconnected via physical communication links. Each charging device is equipped with a computing module and a soft bus module. The soft bus module uses a soft bus protocol to enable signaling interaction between the charging devices via the physical communication links. The method includes: controlling the soft bus module to acquire charging data of a target vehicle on multiple charging devices, and acquiring working data from multiple charging devices; processing the charging data in chronological order to obtain a charging data sequence; and determining the computing resources of the computing module of each charging device based on the working data to obtain computing resources. The source data is divided into multiple computational tasks according to a preset computational task partitioning rule. These tasks are then allocated to the computational modules of each of the multiple charging devices according to a preset computational resource allocation rule. Each computational task includes at least one element from the charging data sequence. The elements from the charging data sequence in these multiple computational tasks are input into a preset battery life prediction model, resulting in multiple prediction results. Based on a preset attenuation factor, a preset life prediction weight calculation formula, and the charging data sequence, life prediction weights are determined, resulting in multiple life prediction weights. Finally, the multiple prediction results are weighted and calculated to obtain the target prediction result. This improves the accuracy and efficiency of battery life prediction.

[0042] The following is combined with Figure 1 The system architecture of a vehicle battery life prediction method based on a soft bus, as described in the embodiments of this application, is explained. Figure 1 This is an architecture diagram of a vehicle battery life prediction system based on a soft bus provided in an embodiment of this application. The vehicle battery life prediction system 100 based on the soft bus includes: a soft bus module 110, a prediction algorithm 120, and a low-level interface 130.

[0043] The soft bus module 110 is used to realize network management, communication protocol processing, and unified management of charging history sequences among multiple charging devices in the charging station. The soft bus module 110 includes a network management unit 111, a protocol framework unit 112, and a history sequence management unit 113. The network management unit 111 is used for network identification, online status detection, device topology confirmation, and logical group management of charging devices. In one possible embodiment, the network management unit 111 can complete online device detection based on the heartbeat frame mechanism of the soft bus protocol, and trigger a topology update operation when a new device is detected or a device goes offline, thereby ensuring the system's real-time monitoring of device status. The protocol framework unit 112 is used to perform soft bus protocol parsing, data calibration, message routing, and synchronization control on the physical communication link to ensure that all charging devices share a unified communication format and interaction logic. The protocol framework unit 112 can support multiple underlying communication methods (such as Ethernet, serial link, or CAN link) and shields the communication differences between different devices through the protocol layer, enabling the soft bus-based vehicle battery life prediction system 100 to achieve a consistent data exchange process in a heterogeneous device environment. Preferably, the protocol framework unit 112 can utilize a reliable transmission mechanism to segment and transmit large-scale historical charging data across devices, thereby improving transmission stability. The historical sequence management unit 113 is used to collect, time-align, format, and uniformly store target vehicle charging data from different charging devices, so as to provide a structured data foundation for subsequent task division and prediction model input. In one possible embodiment, the historical sequence management unit 113 can reconstruct the time sequence of cross-device data based on a unified timestamp system, enabling the generation of continuous and complete charging history sequences, thereby effectively solving the data dispersion problem caused by vehicles charging at different charging piles. To illustrate this more clearly, the details of the protocol framework unit 112 are described below. The protocol framework in the protocol framework unit 112 is designed for application scenarios, and standard communication protocols and soft bus functional requirements are defined. The main communication content of the soft bus module 110 includes two types of data: data and file data. At the same time, it must also meet certain protocol compatibility requirements. Based on these requirements, a standard protocol based on JSON format and oriented event objects is constructed.

[0044] The protocol frame format is shown in Table 1 below:

[0045] Table 1 Protocol Frame Format Framework

[0046]

[0047] The service identifier consists of a 1-byte service identifier string and a service standard string, used to describe the functional object of the current content service; for example, the service identifier string for the current battery life prediction function is "BATREM_PREDICT"; the operation instructions represent the instruction set of the current frame, including: probe login (0x01), back-connection login (0x02), data transfer (0x10), and file transfer (0x20); the multi-frame identifier consists of a 2-byte packet number and a 2-byte packet sequence number, used to indicate whether the current frame is a multi-frame transmission; when the packet number is 0 or 1, it indicates single-packet transmission; when the packet number is greater than 1, it is multi-packet transmission, in which case packet assembly processing is required after all packets are received; the data field is the target data content to be transmitted, consisting of a 2-byte data length and several bytes of data content; to ensure transmission reliability, the maximum length of the data content is 2048 bytes, and for large data transmissions, multiple packets are used. The data and content vary depending on the operation instructions, as shown in Tables 2, 3, and 4 below:

[0048] Table 2 Login Frame Data Field

[0049]

[0050] Table 3 Data Fields of Data Transmission Frames

[0051]

[0052] Table 4 File Transfer Frame Data Fields

[0053]

[0054] Based on the aforementioned communication protocol framework and current functional scenarios, data transmission frames are defined as follows: Heartbeat frames and Virtual Directory frames. The Heartbeat frame is used for connection status management. If the listening server does not receive a Heartbeat frame from a connected device for an extended period, it considers the communication interrupted; at this time, the connection is closed, and the event transmitter's connection to the device is simultaneously cancelled. The Virtual Directory frame is used to expose the file list in the current device and service sandbox directory. The sandbox directory is a virtual folder based on the shared file function of this soft bus framework; in the current device, it is actually a JSON file (.json). In the sandbox JSON file content, the key is the service name, and the key is a string array, with each string member being the absolute path of the file to be exposed. When the sandbox file content changes, or when two devices complete network association, a Virtual Directory frame broadcast is triggered. The historical sequence management unit is implemented based on the aforementioned Virtual Directory frames and file transmission frames. In the current vehicle battery life prediction service, the naming rule for the single charging historical sequence file is: startup time + vehicle unique identifier (VIN code). Since charging starts remotely via a cloud platform, it can be assumed that the charging pile equipment has completed platform time synchronization at this time, and the vehicle VIN code is unique; therefore, each charging history sequence file is unique, and the time periods do not overlap.

[0055] The prediction algorithm 120 is used to perform model calculations required for predicting vehicle battery life. The prediction algorithm 120 includes a distributed computing unit 121 and an algorithm unit 122. The distributed computing unit 121 distributes computing tasks among multiple computing nodes based on evaluation results, achieving parallel processing and improving the computational efficiency of life prediction. In one possible embodiment, the distributed computing unit 121 can dynamically schedule prediction tasks by combining device computing power, task queue length, and current workload to fully utilize available resources at the site. The algorithm unit 122 loads a preset battery life prediction model and performs predictive inference based on serialized charging data, ultimately outputting the prediction result. Preferably, the algorithm unit 122 can employ a life prediction method based on recurrent neural networks or time-series degradation models, obtaining an estimate of the remaining life of the vehicle battery through comprehensive analysis of charging patterns, temperature change trends, and battery degradation rates.

[0056] The underlying interface 130 provides basic communication and data interaction capabilities for the soft bus module 110 and the prediction algorithm 120. The underlying interface 130 includes a network interface 131, a file interface 132, and an algorithm model interface 133. The network interface 131 connects to the physical communication link, providing a low-level data transmission channel to the soft bus module; the file interface 132 interacts with the local storage system to read or write historical data files, task files, and serialized data; and the algorithm model interface 133 loads, calls, and updates model files used for lifetime prediction, providing a model runtime environment for the algorithm unit 122.

[0057] As can be seen, the soft bus module 110 enables unified data aggregation and management among charging devices, the prediction algorithm 120 enables efficient battery life prediction calculation, and the underlying interface 130 provides stable communication and data support. The vehicle battery life prediction system 100 based on the soft bus can effectively solve the problems of scattered charging data and non-shareable computing power in a multi-device collaborative environment, thereby significantly improving the accuracy and efficiency of vehicle battery life prediction.

[0058] The following is combined with Figure 2 The charging device in the embodiments of this application will be described. Figure 2 This is a schematic diagram of the structure of a charging device provided in an embodiment of this application, such as... Figure 2 As shown, the charging device includes one or more processors 210, a memory 220, a communication interface 230, and one or more programs 221. The processor 210 is communicatively connected to the memory 220 and the communication interface 230 via an internal communication bus.

[0059] The one or more programs 221 are stored in the memory 220 and configured to be executed by the processor 210. The one or more programs 221 include instructions for performing any step in the above method embodiments.

[0060] The processor 210 can be a central processing unit (CPU), a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, units, and circuits described in conjunction with the disclosure of this application. The processor can also be a combination that implements computational functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, etc. The communication unit can be a communication interface, transceiver, transceiver circuit, etc., and the storage unit can be a memory.

[0061] The memory 220 can be volatile memory or non-volatile memory, or it can include both. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of random access memory (RAM) are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous DRAM (DDR SDRAM), enhanced synchronous DRAM (ESDRAM), synchronous linked DRAM (SLDRAM), and direct rambus RAM (DR RAM).

[0062] It is understood that the charging device 200 may include more or fewer structural elements than those shown in the above block diagram, such as a power module, physical buttons, a Wi-Fi module, a speaker, a Bluetooth module, a sensor, a display module, etc., without limitation. It is understood that the charging device may incorporate elements such as... Figure 1 The architecture of the charging station battery life prediction system based on soft bus.

[0063] After understanding the software and hardware architecture of this application, the following will be combined with... Figure 3 This application describes a method for predicting the battery life of a charging station based on a soft bus. Figure 3 This is a flowchart illustrating a method for predicting battery life in a charging station based on a soft bus, provided in an embodiment of this application. The method is applied to a control module of a local area network (LAN), which consists of multiple charging devices interconnected via physical communication links. Each charging device is equipped with a computing module and a soft bus module. The soft bus module, based on the soft bus protocol, enables signaling interaction between the charging devices through the physical communication links. Specifically, the method includes the following steps:

[0064] Step S310: Control the soft bus module to acquire the charging data of the target vehicle on the multiple charging devices, and acquire the working data of the multiple charging devices.

[0065] Multiple charging devices form a local area network (LAN) via physical communication links. Each charging device has an internal soft bus module that performs operations such as device status synchronization, data transmission, and task distribution based on the soft bus protocol. This physical communication link can be CAN, Ethernet, RS-485 bus, or other media that support the soft bus protocol; no specific limitation is made here. The soft bus module is a protocol / software framework running on this physical link, enabling cross-device data sharing without relying on a central server, giving each charging device self-organizing and self-coordinating network capabilities. When the control module needs to collect charging data from a target vehicle, it can interact with the soft bus module to trigger a data request command to be broadcast within the LAN. Each charging device determines whether it has a matching charging history record or current charging process data for the target vehicle based on the received command and returns the corresponding data. The charging data of the target vehicle is measured in real time by the monitoring unit within the charging device and uploaded to the soft bus module via the internal controller of the charging device. The soft bus module then formats the data and distributes or synchronizes it within the LAN. After receiving charging data uploaded from different charging devices, the control module can collect the data according to time tags and vehicle identifiers to form a complete cross-device charging history sequence.

[0066] The working data indicates the current operating status and available computing power of each charging device, including: CPU utilization, memory utilization, task queue length, current load power, device online status, communication link quality, and soft bus heartbeat frame response time. The soft bus protocol defines a unified device status reporting mechanism. Each charging device periodically sends a heartbeat frame carrying some of the aforementioned working data fields, which are used by the control module to assess device health and scheduleability. Furthermore, before the control module initiates a task, it can obtain more precise real-time working data from the soft bus module via instruction query to ensure the accuracy of subsequent task division and allocation.

[0067] Specifically, the system first uses a broadcast query mechanism defined by the soft bus protocol to send a target vehicle data request command to all charging devices. Upon receiving the request, each charging device's soft bus module returns the charging logs, real-time monitoring data, and historical charging sequences corresponding to the target vehicle, stored locally, to the control module. Simultaneously, the soft bus module also includes the device's current operating data within this request-response cycle, enabling the control module to obtain data status information for the entire charging station at once. To ensure the reliability and consistency of data transmission, the soft bus protocol supports a timestamp-based data synchronization mechanism, guaranteeing that data uploaded by each device can be correctly reassembled to a unified timescale.

[0068] For easier understanding, please refer to Figure 4 , Figure 4 This application provides a schematic diagram of a charging station network structure based on a soft bus, as illustrated in this embodiment. As can be seen, this network structure interconnects multiple charging devices through a local area network (LAN) and establishes data interaction between each charging device and its corresponding power battery via CAN communication links, enabling distributed execution of charging data acquisition and prediction tasks across devices. Specifically, the LAN uses a switch as the core network device, which is connected to multiple charging devices through physical communication links, forming a typical star or tree network structure. Multiple charging devices are connected to this switch, thereby achieving network reachability and unified operation of the soft bus protocol. In this embodiment, each charging device not only provides charging services to external vehicles or energy storage systems but also carries a soft bus module for performing operations such as device heartbeat detection, service discovery, data synchronization, and receiving computational tasks. A communication link is established with the power battery via the CAN interface. This CAN communication link is used to acquire real-time operating data of the power battery during charging, such as voltage, current, SOC, temperature, alarm information, and charging strategy parameters reported by the BMS. This data is uploaded to the local area network through the data acquisition unit inside the charging equipment and managed uniformly via a soft bus, providing a basic data source for subsequent charging data serialization processing and battery life prediction calculations. Figure 4The hardware networking method shown in this embodiment enables soft bus collaboration among multiple charging devices within the same local area network, allowing power battery charging data collected by different charging devices to be uniformly aggregated, sorted, and processed in a distributed manner. This networking structure not only solves the data dispersion problem caused by vehicles charging at different charging devices, but also provides a unified data channel and computing power sharing foundation for realizing a high-precision battery life prediction model.

[0069] It is evident that by controlling the soft bus module to collect the aforementioned data, it is possible not only to overcome the data silo limitations of a single charging pile and achieve the aggregation of complete charging history data of the target vehicle across devices, but also to simultaneously acquire the operating load information of all equipment in the entire station, providing a precise basis for subsequent distributed computing task division and scheduling, and further improving prediction efficiency and system stability.

[0070] Step S320: Process the charging data in chronological order to obtain a charging data sequence.

[0071] Charging data refers to the records of charging events generated by the target vehicle at different times and charging locations, collected from multiple charging devices via a soft bus module. This includes historical charging data and data from the currently ongoing charging process. Each piece of charging data is typically stored independently within the corresponding charging device, containing charging start time, end time, steady-state voltage, current, real-time SOC (State of Charge), battery temperature, alarm flags, and key parameters reported by the vehicle's Battery Management System (BMS) during the charging process. With the continuous expansion of charging stations, the target vehicle may repeatedly switch between different charging devices. Therefore, this charging data is spatially dispersed and may have inconsistent sampling intervals over time. It is essential to integrate this data into a continuous time series that can be used as model input through unified time series processing.

[0072] Specifically, the first step is to verify the time dimension of each data record. This involves parsing the time stamps carried in the data record, including the charging start time, end time, and sampling timestamp. With the support of the soft bus protocol, the internal clocks of each charging device can be kept consistent through a network time synchronization mechanism, thus avoiding data out-of-order issues caused by clock skew. Based on this, the control module aggregates data from different devices according to charging events and removes incomplete sampling segments or abnormal time points, such as data missing segments due to communication interruptions. Then, the control module sorts all charging records using the charging start time as the primary key, constructing a preliminary time-ordered list. After sorting, to meet the time continuity requirements of the battery life prediction model, the control module further performs interpolation and format standardization on the data according to a preset sampling period. For example, when the sampling frequency of a certain charging device is higher than that of other devices or when there are local data gaps, linear interpolation, spline interpolation, or model-driven estimation can be used to complete the time series, ensuring that all data meet a uniform time granularity. Finally, the control module organizes the processed data into a continuous charging data sequence according to the time series. Each data sequence reflects the complete charging history of the target vehicle across multiple charging devices and time periods.

[0073] It is evident that by performing time-series processing on charging data, charging data that was originally scattered across different charging devices and events can be organized into a continuous and analyzable time series with a unified format and time base, thus ensuring data consistency, usability, and model compatibility. In practical field applications, time-series processing effectively solves the problems of data silos and inconsistencies in sampling from multiple devices, and is key to achieving high-precision battery life prediction.

[0074] In one possible embodiment, the charging data includes historical charging data and charging time data. The step of processing the charging data in chronological order to obtain a charging data sequence specifically includes the following steps:

[0075] 321. Extract each charging event of the target vehicle from the historical charging data to obtain multiple charging event data;

[0076] 322. Determine the start time corresponding to each charging event data in the plurality of charging event data based on the charging time data to obtain a plurality of charging start times;

[0077] 323. Sort the multiple charging start times in chronological order to obtain a charging start time sequence;

[0078] 324. Determine the charging event data corresponding to each charging start time in the charging start time sequence to obtain the charging data sequence.

[0079] Historical charging data refers to vehicle charging process record files discovered and integrated by the soft bus historical sequence management unit and stored on different charging devices within the charging station's local area network. Each file is uniquely identified by its name, which includes "start time + vehicle VIN code," and fully records time-series data such as battery voltage, current, and temperature during a charging session, thus corresponding to an independent charging event. Charging time data is specifically the timestamp string in the filename or the metadata record in the file header, used to accurately identify the start time of each charging event.

[0080] Specifically, the prediction task initiating host broadcasts a query request containing the target vehicle's VIN code to the network via the soft bus. Upon receiving the virtual directory frame, the historical sequence management unit of each charging device reports a list of charging sequence files in its local "sandbox directory" that conform to the naming rules (i.e., filenames containing the VIN code). By aggregating these lists, the host can extract all relevant charging event files distributed across multiple devices in the charging station, forming preliminary sets of multiple charging event data. Next, the host assigns a machine-readable charging start time to each charging event data object by parsing the file names (e.g., "20231027143000" in the filename represents the start time of 14:30:00 on October 27, 2023) or reading the standardized timestamps recorded within the files. The host performs a time-series sorting algorithm (e.g., ascending order) on all extracted charging start times, generating a linear charging start time sequence arranged chronologically. This sequence objectively depicts the charging behavior timeline of the target vehicle within the charging station, clarifying the time intervals and chronological relationships between each charging event. Then, based on the established mapping relationship between "charging event data and charging start time", the host generates a time sequence and reorganizes the charging event data into an ordered list of data structures, which is the final charging data sequence.

[0081] It is evident that through the collaborative discovery of the soft bus and the standardized timestamp parsing, the physically dispersed and temporally discrete multiple charging records are intelligently reconstructed into a logically coherent and time-sequential standardized data sequence. This provides important and structurally regular data input for the subsequent application of prediction optimization algorithms based on time decay weights, thereby improving prediction accuracy and efficiency.

[0082] Step S330: Determine the device computing resources of the computing module of each of the plurality of charging devices based on the working data, and obtain computing resource data.

[0083] The operational data is collected in real time by the monitoring unit inside each charging device and reported to the control module via the soft bus module at preset intervals, serving as the basis for assessing the device's current ability to participate in distributed computing. Because the hardware configurations, actual loads, and operating frequencies of the multiple charging devices differ, their available computing resources vary significantly. Therefore, it is necessary to uniformly parse and quantify the operational data reported from the soft bus to generate computing resource data for task allocation decisions.

[0084] Specifically, after acquiring the operating data of each charging device, the control module first analyzes the computing resource utilization rate from the data, such as CPU utilization, memory utilization, available storage space, and the number of device interrupt events. Computing resource utilization rate represents the current level of computing resource consumption by the device and is the most basic parameter for determining whether the device has the capability to participate in computing. Next, the control module analyzes the device task queue length, which reflects the number of tasks currently queued for processing and can be used to determine the device's responsiveness in future periods. After extracting the multi-dimensional parameters, the control module normalizes and maps the various operating data according to a preset resource evaluation model. The resource evaluation model can be a multi-factor weighted model, a threshold-based segmented evaluation model, or a fitted model trained based on historical operating data. Taking a weighted model as an example, the control module can assign different weights to CPU utilization, task queue length, device temperature change rate, and load power, and calculate the current computing power availability of the device using a formula. For example, a charging device will have a higher computing power score when its CPU utilization is low and its task queue length is short; conversely, its computing power score will be appropriately reduced when the device temperature is high or it is under high charging load to avoid allocating too many computing tasks to the device. Finally, the control module binds the calculated computing power availability with the device identifier to generate corresponding computing resource data.

[0085] It is evident that by analyzing and modeling the working data, the raw equipment operating status information can be transformed into quantitative indicators representing the equipment's computing power, thus providing a basis for subsequent task allocation and resource scheduling. In charging stations, equipment load fluctuates rapidly with changes in vehicle charging behavior. Without real-time updates to computing resources, it will be difficult to guarantee the execution efficiency and stability of distributed prediction tasks.

[0086] In one possible embodiment, determining the device computing resources of the computing module of each of the plurality of charging devices based on the working data to obtain computing resource data specifically includes the following steps:

[0087] 331. Based on the working data, determine the computing resource utilization rate and task queue length of the computing module of each of the multiple charging devices, and obtain multiple computing resource utilization rates and multiple task queue lengths;

[0088] 332. Determine the computing power of the computing module of each of the multiple charging devices based on the multiple computing resource occupancy rates, and obtain the computing power resources;

[0089] 333. Determine the load parameters of each of the multiple charging devices based on the lengths of the multiple task queues, and obtain the load parameters;

[0090] 334. Based on the preset mapping relationship between load parameters and computing resource requirements, determine the required computing resources corresponding to the load parameters to obtain the computing resource requirements;

[0091] 335. Determine the computing resources of the computing module of each of the plurality of charging devices based on the computing resource requirements and the computing power resources, and obtain the computing resource data.

[0092] The working data originates from the periodically broadcast heartbeat frames in the soft bus protocol. These frames not only maintain the online status of the connection, but their data fields also encapsulate real-time operating status parameters of the charging device, including CPU utilization (UsingCPU), NPU utilization (UsingNPU), and RAM utilization (UsingRAM). Furthermore, for devices supporting advanced task management, the task queue length maintained by its local task scheduler (i.e., the number of computational tasks currently queued for execution) can also be transmitted as part of the working data through a custom status reporting mechanism.

[0093] Specifically, the host computer performing the prediction task continuously listens to and analyzes the heartbeat frames and status reports from various charging devices. From these, it extracts the computing resource utilization rate (e.g., CPU utilization of 70%) to represent the instantaneous load of the computing module, and the task queue length (e.g., two tasks waiting in the queue) to indirectly reflect the current busy / idle status of the device. A preset conversion model correlates the "utilization rate" with the "remaining theoretical computing power." For example, an NPU with a nominal computing power of 10 TOPS, if its utilization rate is 60%, can be estimated to have approximately 4 TOPS of remaining available computing power. This calculation method ensures the comparability of utilization rate data from charging devices with different performance characteristics. A longer task queue length, even if the current CPU utilization rate is low, may indicate that the device is about to enter a busy state. The preset mapping relationship is essentially a prediction model based on experience or experimental data. This model can estimate the computing resources (e.g., at least 10% CPU idle and 200MB of available memory) required by a device to stably and timely process a new task based on a given load parameter. Then, it compares the calculated actual remaining computing resources of the device with the computing resource requirements of the new task. If the actual remaining resources are consistently and stably greater than the required resources, the device is determined to be "available" or "idle", and its remaining resource amount is used as a component of the final computing resource data.

[0094] As can be seen, this embodiment provides a method that ensures the task scheduler can accurately identify devices that truly have sufficient and stable idle resources, thereby minimizing the risk of improper task allocation, computational delays, or device overload caused by resource misjudgment. This provides a crucial resource awareness and evaluation foundation for achieving efficient and stable distributed parallel computing.

[0095] Step S340: Divide the charging data sequence according to the preset calculation task division rules to obtain multiple division calculation tasks.

[0096] The task partitioning rules are used to decompose the time-series processed charging data into several independently executable computational tasks at an appropriate data granularity. This allows each task to run in parallel on the computational modules of different charging devices, thereby improving the overall prediction efficiency of the system. The task partitioning rules are typically set based on the structural characteristics of the charging data sequence, the file data volume, the sequence time span, and the requirements of the computational model for input data. They also take into account the differences in computing power among the charging devices in the facility to avoid concentrating data on devices with lower computing power, which could lead to latency propagation. Preferably, the task partitioning rules can be formed by comprehensively considering information such as the number of charging record files, file size, and the time interval between different charging events.

[0097] Specifically, the process begins by parsing the generated charging data sequence, which contains multiple charging record files. Each file typically corresponds to complete data for the target vehicle during a single charging session, including charging start time, end time, voltage and current curves, SOC change records, temperature curves, and operating parameters reported by the BMS. Next, the control module labels each record file according to its source device to identify the original distribution of the charging data. After parsing the charging record files, the control module splits the file set according to task partitioning rules. For example, in sequences with large amounts of data, files can be prioritized based on data volume, allocating larger files to devices with more computing power. In cases where data volume differences are small but there are many source devices, charging sequences within different time intervals can be divided into independent tasks based on time period partitioning. Furthermore, task partitioning rules can incorporate preset device load constraints, such as avoiding scheduling multiple large tasks to the same device simultaneously, thus ensuring overall scheduling balance. To ensure that the partitioned tasks can be computed independently, the control module also performs consistency checks on the data within each partitioned task, ensuring its structural integrity, temporal continuity, and compliance with preset model input formats. Finally, each task is encapsulated into an independent task unit, with necessary task tags and metadata, such as task number, data source device, and data volume range, to facilitate subsequent task scheduling.

[0098] It is evident that by using a task partitioning mechanism, large-scale, cross-device charging history data can be broken down into multiple sub-tasks suitable for distributed computing, greatly reducing the computational load on individual devices while improving the parallel processing capability of the entire system, thereby enhancing the efficiency of predicting the lifespan of electric vehicle power batteries.

[0099] In one possible embodiment, dividing the charging data sequence according to a preset computational task partitioning rule to obtain multiple partitioning computational tasks specifically includes the following steps:

[0100] 341. Extract the charging record file of the target vehicle from the charging data sequence to obtain multiple charging record files;

[0101] 342. Determine the source device of each of the multiple charging record files to obtain the multiple file device sources;

[0102] 343. Select the charging record file corresponding to the target file device source from the plurality of file device sources to obtain the target charging record file; the target file device source is any one of the plurality of file device sources;

[0103] 344. Select the charging record files other than the target charging record file from the plurality of charging record files to obtain a charging record file set;

[0104] 345. Determine the data volume of each charging record file in the charging record file set to obtain the data volume of multiple files;

[0105] 346. Determine the computing resource occupancy parameters corresponding to the plurality of charging devices based on the computing resource data, thereby obtaining a plurality of computing resource occupancy parameters;

[0106] 347. The charging record file set is divided according to the computing task division rules, the multiple computing resource occupancy parameters, and the multiple file data volumes to obtain the multiple partitioned computing tasks.

[0107] The input is a time-series processed charging data sequence, essentially a list of all historical charging record files for the target vehicle, sorted by charging start time. Extracting the charging record files is a direct data access operation, as each element of the sequence is an independent data file corresponding to a single charging event. When the charging station exposes its local files to the network via a virtual directory frame (VirtDir), this frame contains not only a list of file paths but also an implicit unique identifier for the sending device. Therefore, when the host indexes each charging record file, it can simultaneously associate and record its physical storage location, i.e., the source device. The target device source typically refers to the "host" device that initiated this battery life prediction request; the filtered set of charging record files contains all historical files stored on other remote devices that require cross-network scheduling. The computation task partitioning rules are a formalized manifestation of the scheduling strategy, mainly including: proximity-first rule, which prioritizes allocating files to the local device where they are stored (the source of the target device) for computation; load balancing and matching rule, which performs a dual matching based on the data volume (large files first) and the device's computing resource usage parameters (high idle time devices first) for files that must be remotely allocated; and resource guarantee rule, which ensures that the device allocated to the target file has sufficient remaining resources to meet the minimum memory and computing power threshold required to run the prediction model. Based on these rules, the charging device iteratively traverses and matches the charging record file set with devices, ultimately partitioning and mapping the entire file set to different available computing devices, forming clear "file-target computing device" pairs, i.e., multiple partitioned computation tasks. Each partitioned computation task represents "executing a battery life prediction algorithm on one or more specified charging record files on a specified device."

[0108] It is evident that the intelligent task partitioning mechanism is a key scheduling layer for achieving efficient and stable distributed computing. It decomposes data sequences into independently executable file computing tasks and optimizes matching by integrating multi-dimensional rules based on data location (proximity), data characteristics (file size), and real-time system status (resource availability). This minimizes unnecessary data network transmission, reduces communication overhead and latency, and ultimately improves the efficiency of subsequent charging modules in predicting the lifespan of the power battery.

[0109] In one possible embodiment, the step of dividing the charging record file set according to the computing task partitioning rules, the plurality of computing resource occupancy parameters, and the plurality of file data volumes to obtain the plurality of partitioned computing tasks specifically includes the following steps:

[0110] 3471. Sort the multiple computing resource occupancy parameters in descending order to obtain a resource occupancy parameter sequence;

[0111] 3472. Sort the multiple file data volumes in ascending order to obtain a file data volume sequence;

[0112] 3473. Based on the computation task partitioning rules and the resource occupancy parameter sequence, each charging record file in the file data volume sequence is partitioned to obtain the multiple partitioning computation tasks.

[0113] The process of sorting multiple resource usage parameters in descending order essentially prioritizes the real-time computing power supply capabilities of all available charging devices within the local area network. A higher value for a resource usage parameter indicates more abundant remaining computing resources for that charging device. The resource usage parameter sequence generated by sorting the parameters in descending order effectively constructs a global device idleness ranking sequence, with the device at the top of the sequence considered the ideal executor of the current computing task. Sorting multiple file data volumes in ascending order assesses and ranks the workload of the charging data record file set to be computed. The file data volume is directly related to the basic computation cycles and memory usage required by the prediction model to process that file. Sorting the file data volume sequence in ascending order indicates that smaller files with relatively light computational loads are placed first, while larger, more computationally intensive files are placed later. Based on preset computing task partitioning rules, the two ordered sequences are collaboratively matched.

[0114] Specifically, the host maintains the two sequences mentioned above and follows an iterative process: First, based on the principle of proximity-first computation, for any charging record file, it first checks whether the source device where it is stored is in the current "resource occupancy parameter sequence" and ranks high (i.e., its own idle time is relatively high). If so, the file is directly assigned as a computation task to be executed locally by the source device, and the file is removed from the file sequence. At the same time, its position in the resource sequence is fine-tuned according to the newly undertaken task volume of the device. Next, for files that cannot be executed locally or whose local device resources are insufficient, cross-device matching based on sorting is performed. At this time, the scheduler adopts a "small file first, large file matching for the strongest machine" strategy. It starts from the head of the "file data volume sequence" (i.e., the smallest file) and tries to assign it to the currently idle device at the head of the "resource occupancy parameter sequence". After completing a match, the file is removed from the file sequence, and the resource parameters of the assigned device are updated and re-inserted into the sorting sequence (usually the ranking will drop) to reflect its increased load. Then, the next smallest file is matched with the updated, currently idle device, and so on iteratively. This allows tasks with low computational demands to be quickly distributed and completed, while tasks with high computational demands have a higher probability of being matched with powerful devices that maintain a relatively high level of idle time during the iteration process, thereby achieving a balanced distribution of the load globally and shortening the overall task completion time.

[0115] It is evident that by quantizing device resources and file loads into sortable sequences and designing matching iteration rules, the complex distributed scheduling problem is transformed into an efficient deterministic algorithm. Under the premise of ensuring that no single device is overloaded, the total completion time of all prediction subtasks is minimized, thereby achieving the technical effect of improving prediction efficiency at the system level.

[0116] Step S350: According to the preset computing resource allocation rules, the multiple partitioned tasks are allocated to the computing modules on each of the multiple charging devices to obtain multiple computing tasks; each of the multiple computing tasks includes at least one element in the charging data sequence.

[0117] Among them, the computing resource allocation rule refers to the set of strategies used by the control module to optimally schedule tasks based on the current computing resource data, load status, online status, and task execution capabilities of each charging device when performing distributed computing scheduling. This rule not only needs to consider the instantaneous available computing power of each device, but also factors such as device CPU utilization, task queue length, soft bus heartbeat response latency, device temperature, and rectification load level, in order to ensure the stability and consistency of task execution in a distributed structure.

[0118] Specifically, after completing the task division, the control module first matches the task quantity (such as the number of files, file size, and time span) of each division with the acquired device computing resource data. Based on a pre-established resource mapping model, the control module maps the task quantity to a computing demand level and the device computing power to a computing power level, then matches the two according to computing resource allocation rules. During the matching process, the control module can also combine the online device detection results from the soft bus module to ensure that tasks are only assigned to charging devices with normal communication and stable soft bus heartbeat frame responses. Then, the control module sends corresponding calculation instructions to the target charging device via the soft bus protocol. The instructions contain the input data index or data content of the corresponding division task. After receiving the task, the charging device's computing module enters the calculation pending execution state, forming multiple final calculation tasks. Each calculation task contains at least one element from the charging data sequence, such as an independent charging record file or a charging data segment within a certain time interval, to ensure the independent computability of the task. After each device executes its task, it can transmit the corresponding intermediate calculation results or final prediction results back via the soft bus for subsequent weighted calculations and result fusion.

[0119] It is evident that the computing resource allocation mechanism enables efficient and dynamic distributed task scheduling among multiple charging devices. While making full use of global computing resources, it avoids performance degradation caused by excessive device load, ensuring that each task is assigned to the most suitable device for processing. This not only effectively improves computing execution efficiency but also enhances the overall scalability and stability of the system.

[0120] Step S360: Input the elements in the charging data sequence from the multiple computing tasks into a preset battery life prediction model to obtain multiple prediction results.

[0121] Real-time computing resource status refers to the dynamic load parameters of each charging device, periodically broadcast within the local area network via heartbeat frames in the soft bus protocol. These parameters mainly include CPU utilization (UsingCPU), NPU utilization (UsingNPU), and memory utilization (UsingRAM). These parameters are collected by the local monitoring unit of each device and encapsulated in the data field of the heartbeat frame. They are then broadcast or queried via the soft bus, allowing any device in the network acting as the initiator (host) of the prediction task to have a real-time understanding of the global computing resource distribution. Multiple historical charging data files are uniquely identified by naming rules (start time + vehicle VIN code) and stored locally or in a shared directory on their respective charging devices, recording data from a single charging process. Each file serves as a complete, temporally continuous data sequence unit, representing the smallest granularity for lifetime prediction.

[0122] The massive amount of time-slice data and the large-scale time-series model algorithms require significant computing resources. Prolonged high CPU usage can severely impact system interrupt responses, leading to unpredictable problems. To address this, a distributed computing unit is constructed, leveraging the parameters and file-sharing capabilities of the soft bus. Prediction calculations for different time-slice sequence files are distributed across various idle devices within the facility. The algorithm unit utilizes sequence-based AI prediction models or historical sequence-based prediction algorithms, both based on existing models. However, existing models or algorithms often require continuous data with a fixed sampling period for time series data. While single-charge data meets this requirement in the current application scenario, extended to all data across the entire facility, the sequence is discontinuous. Therefore, an optimized algorithm is needed. The heartbeat frame defined in the aforementioned protocol framework includes not only the heartbeat count (HeartBeatCount) but also device resource usage parameters such as CPU utilization (UsingCPU), NPU utilization (UsingNPU), and memory utilization (UsingRAM). These parameters are updated in real time to the device parameters in the corresponding device connection list within the network unit. This allows any device on the soft bus to monitor the equipment status of the site system in real time. In addition, a computing power request frame (CompReq), a computing power request response frame (CompReqAck), and a computation result frame (CompResult) are added. The computing power request frame has the event title "CompReq" and parameters including the user's unique device code (UserID) and the charging data sequence file name (OrderFile). The computing power request response frame has the event title "CompReqAck" and parameters including the request result (ReqAck) and the rejection reason (FileReason); the FileReason value is 0 when the request is approved. The computation result frame has the event title "CompResult" and parameters including the predicted lifetime result (BatLifeResult). When a user clicks on the battery life prediction service on the charging station's billing interface, the prediction process is triggered. The current device acts as the host, using the user's unique vehicle identification number (VIN) to locate the corresponding sequence file in the aforementioned prediction sequence container, and sorts them by file size to form a target file table. Then, based on the resource usage of the device list in the network unit (when the AI ​​model relies on the NPU unit, it is sorted first by NPU usage; when the system does not have an NPU unit, or when the algorithm relies on the CPU, it is sorted first by CPU usage; finally, memory usage is checked to ensure that the remaining memory meets the minimum budget requirement), a device idle table is formed.

[0123] Specifically, firstly, the master device initiating the prediction task retrieves and aggregates relevant historical charging data files distributed across all networked devices using the query interface provided by the historical sequence management unit of the soft bus, based on the VIN code of the target vehicle, forming a list of files to be calculated. Simultaneously, the host parses continuously received heartbeat frames and maintains a real-time updated list of device idle statuses (i.e., the "device idle table"). Devices in this list are sorted according to the remaining availability of key resources. For AI prediction models relying on NPU acceleration, they are prioritized by NPU idle rate; for algorithms using only the CPU, they are prioritized by CPU idle rate. The remaining memory of the devices is also checked to ensure it meets the minimum requirements for model operation. During allocation, a multi-round matching process is executed, prioritizing proximity and load balancing. Specifically, a historical charging data file is preferentially allocated to the local device where it is stored for calculation to reduce network transmission overhead. If the local device resources are insufficient, the file is allocated to the remote idle device with the most abundant computing resources and sufficient memory requirements, according to the "device idle status list." For calculation tasks with large data volumes (large file sizes), devices with higher idle rates are prioritized to avoid creating new performance bottlenecks. The final output of this allocation decision is to generate a mapping relationship that clarifies which specific charging device with sufficient idle resources should be responsible for calculating each historical charging data file. The allocation instruction is sent to the target device via a computing power request frame (CompReq) defined in the soft bus protocol, and the target device confirms with a computing power request response frame (CompReqAck). Finally, each allocated device independently and in parallel invokes its locally deployed battery life prediction model to process the allocated file, initiating the distributed computing process.

[0124] As can be seen, the global resource view built through the soft bus transforms the massive prediction computing task from a centralized processing mode that traditionally relies on a single central server into a parallel processing mode across multiple idle devices. This not only significantly shortens the overall computing time and improves the response efficiency of the prediction service, but more importantly, it distributes the computing load across multiple nodes in the network, effectively avoiding the problem of response delays or even system instability caused by a single device performing high-intensity operations for a long time. Thus, while improving prediction accuracy (by integrating multi-source data), it also ensures the robustness and service reliability of the entire charging station operation system.

[0125] Step S370: Determine the lifetime prediction weights based on the preset attenuation factor, the preset lifetime prediction weight calculation formula, and the charging data sequence to obtain multiple lifetime prediction weights.

[0126] The determination of lifetime prediction weights is based on the charging start timestamp corresponding to each sequence. This timestamp is uniquely determined when the data file is generated, thus assigning a clear time attribute to each historical charging data and its corresponding initial prediction result. A preset attenuation factor ( ) is an empirical constant used to control the rate at which the weight decays over time. Its default value is 0.05, and it can be adjusted specifically according to the aging characteristics of different battery chemistry systems. The preset lifetime prediction weight calculation formula is:

[0127]

[0128] in, For weight values, As the attenuation factor, This refers to the time difference (the time difference between the start time of the sequence and the current time, in days). Specifically, firstly, for each initial prediction result, the charging module or its coordination module parses the start timestamp of that charging session from the metadata or filename of the corresponding historical charging data file. Next, it calculates the time difference between this timestamp and the current system time. t. Then, Substituting t along with the preset decay factor λ into the above exponential decay formula, the original decay value of the prediction result is calculated. After obtaining the original decay values ​​corresponding to all prediction results, all original decay values ​​are summed, and each original decay value is normalized (i.e., divided by the sum) to finally obtain the standardized weight corresponding to each prediction result, which has a sum of 1. After normalization, the weight of recent data will be much higher than that of earlier data.

[0129] It should be noted that the timestamp acquisition method, the unit of time difference, and the specific value of the decay factor can all be adaptively configured according to the actual data recording format and battery decay model. The core of this application is to introduce a weight allocation mechanism based on time exponential decay in order to achieve effective fusion and value assessment of multi-source historical data.

[0130] It is evident that most existing methods, limited to single or short-term continuous data, cannot effectively utilize fragmented historical data left by users at different times and charging stations. This application's embodiments construct a mathematical model to quantitatively evaluate the "timeliness value" of historical data by introducing a time decay factor and a normalized weight calculation formula. Thus, at the data level, it overcomes the limitations of a single data source, significantly improving the accuracy, robustness, and timeliness of lifespan prediction results.

[0131] In one possible embodiment, determining the lifetime prediction weights based on a preset attenuation factor, a preset lifetime prediction weight calculation formula, and the charging data sequence to obtain multiple lifetime prediction weights specifically includes the following steps:

[0132] 371. Based on the charging data, determine the last charging data of the target vehicle to obtain the first charging data;

[0133] 372. Determine the first charging start time in the first charging data;

[0134] 373. Determine the charging start time corresponding to the multiple charging devices in the charging data sequence to obtain multiple charging start times;

[0135] 374. Subtract the first charging start time from each of the plurality of charging start times to obtain a plurality of time differences;

[0136] 375. Calculate the plurality of time differences and the decay factor according to the lifetime prediction weight calculation formula to obtain the plurality of lifetime prediction weights.

[0137] The charging data sequence is a list of historical charging record files for the target vehicle, organized chronologically. The last charging data is selected from this time-series sequence, with the most recent timestamp as the first charging data. The precise start time is obtained by parsing the metadata of the first charging data, and all other charging record files in the sequence are parsed in parallel to extract a series of charging start times, thus comprehensively depicting the temporal distribution of historical charging behavior. Then, by executing... The operation, where, Typically, these are negative or absolute values. For each historical charging event, a time difference relative to the most recent charging event is calculated. Then, this time difference is substituted into a preset lifetime prediction weight calculation formula to obtain a set of normalized lifetime prediction weights that sum to 1. .

[0138] It is evident that by employing a quantifiable time-series data processing workflow, the prior knowledge of data timeliness in battery health status assessment is transformed into weight parameters that can be embedded in the prediction model. This not only solves the modeling challenge of non-uniform and discontinuous historical data sequences caused by the randomness of charging behavior at the algorithmic level, but more importantly, it assigns higher weights to recent data through an exponential decay mechanism. This enables the final fusion prediction results to more sensitively and accurately reflect the current and recent degradation trajectory of the battery, thereby significantly improving the accuracy, robustness, and practical guiding value of the life prediction model.

[0139] Step S380: The multiple prediction results are weighted according to the multiple lifetime prediction weights to obtain the target prediction result.

[0140] The host computer collects the computation result frames (CompResult) returned by each distributed computing device via a soft bus. These frames encapsulate the initial prediction results. Combined with the charging start timestamp for each task maintained locally on the host (used for calculation) and the calculated weights The host calculates a correction term for each initial prediction result. Then, the host sets each corrected prediction value to its corresponding weight. Multiply the products and sum them to obtain a single, fused target prediction result. .

[0141] Specifically, once all sequence predictions are complete, a prediction result table is generated (sequence start timestamp + prediction lifetime), where the prediction lifetime is in days. The weight of each prediction result in the table can be assumed to decrease over time. Therefore, a decay factor is introduced. The formula for the weighting of the prediction results can be derived as follows:

[0142]

[0143] The final optimized prediction result is:

[0144]

[0145] in, For the first i Each original data weight value; For the first i The difference between the original data and the current time; This is the attenuation factor, and its value can be modified based on experience for different types of batteries. The default value is 0.05. This represents the total number of predicted results; For the predicted results, For the original number i One predicted data point.

[0146] This algorithm can, to some extent, solve the problems of poor prediction accuracy caused by the small amount of data from a single charge and the inability to use non-continuous sampling sequences.

[0147] As can be seen, the exponential decay weighting method highlights the contribution of recent high-value data. Therefore, the final target prediction result not only fully mines and utilizes the information contained in fragmented historical data, but also significantly improves the accuracy, reliability, and practical reference value of the prediction result through a scientific fusion algorithm, thereby achieving a more accurate and stable intelligent assessment of the remaining life of vehicle batteries.

[0148] In one possible embodiment, the soft bus module includes a network management unit, a protocol unit, and a data management unit. Before controlling the soft bus module to acquire charging data of the target vehicle on the multiple charging devices and acquiring the operating data of the multiple charging devices, the method further includes the following steps:

[0149] A1. Detect the responses of the multiple charging devices to the online detection frames sent by the network management unit to the multiple charging devices, and obtain multiple online statuses;

[0150] A2. Based on the multiple online states, determine the connected charging devices among the multiple charging devices to obtain a set of connected charging devices;

[0151] A3. Register device identifiers for all charging devices in the connected charging device set to obtain multiple registration identifiers;

[0152] A4. Determine the topological relationship of all charging devices in the connected charging device set based on the multiple registration identifiers to obtain the charging device topological relationship;

[0153] A5. Based on the topology of the charging devices, perform link confirmation on the set of connected charging devices to obtain the communication availability status;

[0154] A6. Based on the communication availability status, network the charging devices in the connected charging device set to obtain the local area network system.

[0155] In this system, the probe source in the network management unit acts as a dynamic client, actively initiating TCP connection attempts to all possible IP addresses within the current network segment and sending a specific probe login frame (operation command 0x01). This frame encapsulates the service name initiating the probe and the device's unique code to identify itself. Simultaneously, the listening server on each device continuously listens to a preset port, waiting to receive such probe frames or connection requests from other devices. When the listening server receives a valid probe login frame, it performs authentication; if successful, a connection is established. At the same time, this device, as the probe source, also receives responses from other devices. Through this handshake mechanism combining active and passive association, the set of all online and authenticated devices is ultimately determined, forming a preliminary set of connected charging devices. Device identification registration refers to the registration of each successfully connected device's unique code and corresponding network socket information into the list of valid clients maintained by the event transmitter. This list forms the basis for any subsequent directional or broadcast communication on the soft bus. Topology does not refer to the physical cabling topology, but rather to the logical communication topology constructed based on the aforementioned client list and connection status, thus clarifying which devices at the soft bus level have established direct communication session links. Finally, the networking process signifies the formal formation of the local area network system at the soft bus logical level. At this point, a distributed collaborative network consisting of multiple charging devices interconnected through a standardized soft bus protocol, equipped with device discovery, identity management, and stable links, is ready, providing a stable communication infrastructure for subsequent "data management unit" file discovery and "protocol unit" data exchange.

[0156] For easier understanding, please refer to Figure 5 , Figure 5 This is a schematic diagram of a soft bus network structure provided in this embodiment. As can be seen, Figure 5 The demonstration showcases the interaction structure of three typical devices—Device A, Device B, and Device C—within a soft bus architecture. Each device includes both a listening server and an event transmitter, forming a multi-point interconnection through a local area network (LAN) communication channel, thereby enabling cross-device event publishing and listening mechanisms. Specifically, Devices A, B, and C each have their own listening server and event transmitter. The listening server continuously listens for event messages from other charging devices on the soft bus and triggers corresponding processing logic based on the event type. The event transmitter generates an event within its own charging device and broadcasts it externally in the format specified by the soft bus protocol. This soft bus service architecture employs an event-driven mechanism, enabling cross-device synchronization, data sharing, and asynchronous task triggering without establishing a fixed communication peer relationship between different devices. Figure 5The diagram uses dashed lines and arrows to illustrate the event interaction paths between multiple devices. Device A's event transmitter can send events not only to Device B's listening server but also to Device C's listening server; Device B can also broadcast its events to Devices A and C; Device C can send events to Devices A and B. Through this many-to-many event propagation method, a globally reachable event publishing network is formed among the devices, achieving interconnection and decentralized event scheduling among distributed devices. Furthermore, under the soft bus protocol, each event broadcast process includes information such as event identifier, event parameters, source device identifier, and event priority, allowing the listening server to classify and process received events. For example, when Device B's listening server receives an event from Device A, it can determine whether data updates, state synchronization, or initiating corresponding computing tasks are needed based on the event identifier. On the other hand, the event transmitter can select the broadcast range according to the soft bus task scheduling strategy when generating events, thereby reducing unnecessary network load and improving event propagation efficiency.

[0157] It is evident that the event interaction structure between different devices through the soft bus service enables multiple charging devices to build a flexible distributed interaction system in a local area network environment. Each device can act as both an event source and an event listener. Event propagation does not depend on a central node, thereby avoiding single points of failure and improving system reliability.

[0158] For easier understanding, please refer to Figure 6 , Figure 6This is a schematic diagram illustrating an active networking process based on a soft bus, as provided in an embodiment of this application. As can be seen, the soft bus system as a whole consists of a listening server on the target device side and a probe source and message transmitter on the source device side, forming a distributed communication system integrating automatic device discovery, two-way handshake authentication, connection maintenance, and event forwarding. Through this system, multiple devices within a local area network can automatically establish communication links without manual configuration, and subsequently achieve data sharing and distribution of computing tasks. Specifically, the target device runs a listening server. Upon startup, the process begins by creating the server and checking for "Client connection?". If the result is "N", it indicates the client is not connected, and the listening server waits for a successful connection. If the result is "Y", it indicates a successful connection. Then, it checks for "Receive login frame?". If the result is "N", it proceeds to the "Login timeout?" check. If this check is "N", it continues waiting to receive login frames. If the result is "Y", it returns to the "Client connection?" check until the client connects successfully. If the "Receive login frame?" check is "Y", it further checks for "Is this a probe login frame?". If the check result is "N", it is determined to be a non-network-required frame type, the connection is directly disconnected, and the passive process (i.e., passive connection process, such as...) is entered. Figure 7(As shown in the connection process) If the verification result is "Y", the "probe frame information authentication" process is initiated. During the probe frame information authentication stage, an "authentication passed?" check is performed. If authentication fails (result is "N"), an authentication failure command is sent back to the source device, followed by a "connection disconnected?" check. If authentication passes (result is "Y"), an authentication success command is sent back to the probe source in the source device, and the "client connection?" check for the next charging device is performed. Then, the "connection disconnected?" status monitoring is entered. If the determination is "Y", the "client connection?" check continues. If the determination is "N", the "disconnection timeout?" check is performed. If the result is "N" (disconnection did not time out), the "connection disconnected" check is performed again. If the disconnection did not time out (result is "Y"), the connection is disconnected, and the "client connection?" check is performed again until the client connection is completed, thus completing the active networking response process on the target device side. On the source device side, the probe source and message transmitter work together to initiate the network setup. After the probe source starts, the process "begins" and then performs the "random probe IP acquisition" operation. After acquiring the IP to be probed within the network segment, a TCP connection is established, and a "connection successful?" check is performed. If it is "N", it means that no TCP connection has been established, and the random probe IP acquisition phase is restarted. If it is "Y", after the connection is established, a probe login frame is sent to the target device's listening server, and then the authentication feedback from the target device is waited for. When the "Authentication Successful?" step is "Y", the probe source sends the handover socket to the message transmitter and simultaneously performs another random IP acquisition to continue probing for the next IP and establish a TCP / IP connection. When it is "N", if the probe source receives an authentication failure reply or does not receive a reply within the specified time, it will actively disconnect and enter the random IP acquisition step to continue probing for the next IP. When the message transmitter receives the handover socket sent by the probe source, that is, it receives the authentication successful reply, and the message transmitter starts the process (socket registration). The message transmitter will trigger the "Probe Source Handover Socket?" judgment. If it is "N", it waits; if it is "Y", it hands over the current communication socket to the message transmitter, which performs the "socket registration" operation, incorporating the socket into the soft bus communication management system. At this point, the active networking process on the source device side is completed, and subsequent data interaction and task collaboration can be carried out based on the registered socket.

[0159] As can be seen, this proactive networking process relies on the proactive detection of the probe source, the accurate verification of the listening server, and the orderly handover of sockets to realize the automated networking of charging station equipment within the local area network. The communication link between devices can be established without manual intervention, laying the communication foundation for subsequent charging data sharing and distributed computing power scheduling. It meets the actual business needs of multi-device collaboration in charging stations and improves the self-organizing networking capability and operation and maintenance convenience of the soft bus system.

[0160] For easier understanding, please refer to Figure 7 , Figure 7This is a schematic diagram of a passive networking process based on a soft bus, provided in an embodiment of this application. As can be seen, this process mainly consists of a listening server on the target device side and a probe source, listening server, and event transmitter on the source device side. Through their collaboration, they achieve operations such as automatic device discovery, triggering of return connection events, bidirectional authentication connection, socket migration, and event reporting, forming a local area network soft bus communication framework with high robustness, adaptability, and distributed coordination capabilities. Specifically, on the target device side, the listening server enters a continuous listening state after startup, waiting for return connection probe requests from source devices within the local area network. The listening server receives return connection frames sent by the probe source on the source device side and performs a "return connection probe login frame?" check to determine whether the listening server has received the "return connection probe frame" sent by the source device. When the result is "No" (N), the target device remains in a listening state and continues to wait until the source device initiates a valid probe. When the result is "Yes" (Y), it indicates that the target device has successfully received the probe request from the source device. At this time, the listening server will immediately trigger the "login reply" process, that is, send an acknowledgment response to the source device, causing the source device to determine "Target server reply?" and identify whether the target device is in a connectable state. After this process is completed, the return connection processing on the target device side ends. On the source device side, the probe source is responsible for initiating the automatic discovery process. At the beginning, after the probe source starts, it receives the "trigger return connection login" command sent by the listening server and enters the "Return connection event occurred?" judgment. When the result is "No" (N), it means that no return connection confirmation has been received from the target device yet, and the probe source will continue to maintain the listening and probe state. When the result is "Yes" (Y), it means that the source device has detected a valid return connection event from the target device. At this point, the source device will obtain the target IP from the detected event and create a TCP connection based on that target IP. It then sends a callback frame to the target device to complete the first phase of the connection handshake. After completing the callback, the source device will ask "Target server reply?". If the result is "No" (N), it means the target device has not returned a valid login response, and the source device will terminate the current connection attempt and return to sending the callback frame. If the result is "Yes" (Y), it means the target device has correctly responded to the source device's callback frame. At this point, the source device will perform a "socket handover" operation, transferring the temporary communication socket currently maintained by the probe source to the local event transmitter for a "probe source socket handover?" check to ensure long-term stable session persistence. After the socket handover is complete, the callback process on the source device side ends. Simultaneously, the source device's listening server and event transmitter operate in parallel. After startup, the listening server receives socket handover from the probe source and judges the back connection authentication result. When the back connection authentication is successful, it triggers back connection login, and the listening server ends this stage to formally establish a stable communication link.After the event transmitter enters the "start" phase (i.e., startup), it enters the "probe source handover socket?" judgment process. When the judgment is "no" (N), the event transmitter remains in standby and does not send events; when the judgment is "yes" (Y), the event transmitter performs "socket registration", adding the connected socket to the soft bus event management system. The event transmitter is then responsible for subsequent data event reporting, heartbeat maintenance, and status synchronization.

[0161] As can be seen, through a multi-level linkage mechanism of target device monitoring, source device detection, bidirectional back connection confirmation, socket handover and event registration, this embodiment realizes a passive networking process without manual intervention, enabling multiple charging devices in the local area network to automatically discover and establish stable communication connections under the soft bus framework, effectively improving the system's plug-and-play capability, dynamic expansion capability and network autonomy capability.

[0162] For easier understanding, please refer to Figure 8 , Figure 8This is a schematic diagram of a historical sequence management process based on a soft bus provided in this application embodiment. As can be seen, this embodiment mainly uses the soft bus construction, resource adaptation, model deployment, and prediction execution process to manage vehicle charging data and predict vehicle battery life. It forms a standardized implementation system covering the entire process from basic environment configuration to prediction functions, including steps such as local area network deployment, soft bus interaction, virtual directory parsing, sequence container registration, historical sequence archiving, and predicted sequence output. This ensures stability in scenarios involving cross-site deployment of multiple charging devices and distributed computing, achieving collaborative optimization of charging data integration and distributed computing power scheduling. Specifically, the soft bus, as an upper-layer protocol service, is used to broadcast "virtual directory frames" to multiple charging devices (charging piles). The soft bus first sends virtual directory frames to all charging devices in the network. After receiving the virtual directory frames, each charging device parses them using its built-in "Virtual Directory Parsing VirPraseFunc." This parsing process identifies the unique vehicle identifier, data file name, device identifier, and corresponding sequence start timestamp, among other index information, contained in the virtual directory structure. After parsing, each charging device generates a "temporary prediction sequence container" based on the parsed result and inputs the temporary prediction sequence container to the "prediction sequence container registration RegisterFunc" on the soft bus side. The prediction sequence container registration RegisterFunc controls the prediction sequence container through "input / output". The prediction sequence container registration RegisterFunc is actually a prediction sequence container registration function. It is used to perform index mapping on temporary containers from different devices and integrate global input / output, thereby unifying the historical prediction data of multiple devices and multiple vehicles into a systematic management structure. The prediction sequence container uses the vehicle unique identification code (e.g., vehicle unique identification code (1) to vehicle unique identification code (N)) as a first-level index to build a vehicle-centric charging history sequence management structure. In the sequence entry corresponding to each vehicle unique identification code, a "charging history sequence container" is set up to store the charging process data of the vehicle on multiple different devices. Furthermore, in each charging history sequence container, the data source is distinguished according to the device identifier of different charging devices (device identifier (a), device identifier (b), device identifier (c), and device identifier (d), etc.). Each device identifier includes "Sequence Start Timestamp", "File Name", and "File Size". The Sequence Start Timestamp identifies the starting sampling time of the charging sequence generated by the device, ensuring the time continuity management of historical sequences; the File Name corresponds to the specific name of the original charging data file reported by the device; and the File Size is used to quickly determine the size of the file's content and whether there are any abnormal truncations.The above fields together constitute the smallest data unit of the historical sequence, enabling the system to accurately index, quickly retrieve, and support subsequent sequence-level prediction calculations.

[0163] It can be seen that, through Figure 8 The historical sequence management mechanism shown in the soft bus-based historical sequence management process, in this embodiment, automates the processes of virtual directory broadcasting, directory parsing, sequence archiving, and container registration within the soft bus framework. This mechanism not only adapts to distributed deployment structures with multiple devices and vehicles but also avoids the bottlenecks of traditional centralized data management in terms of communication pressure, file storage, and index complexity. It provides a stable, unified, and scalable basic data structure for subsequent distributed predictive computing and battery life modeling.

[0164] The above mainly describes the solutions of the embodiments of this application from the perspective of the method execution process. It is understood that, in order to achieve the above functions, the charging device includes corresponding hardware structures and / or software modules for executing each function. Those skilled in the art should readily recognize that, in conjunction with the units and algorithm steps of the various examples described in the embodiments provided herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0165] This application embodiment can divide the charging device into functional units according to the above method example. For example, each function can be divided into a separate functional unit, or two or more functions can be integrated into one processing unit. The integrated unit can be implemented in hardware or as a software functional unit. It should be noted that the unit division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0166] When dividing each function into modules according to its corresponding function. Figure 9 This is a functional module block diagram of a charging station battery life prediction device based on a soft bus, provided in an embodiment of this application. The charging station battery life prediction device 900 based on the soft bus includes:

[0167] The acquisition unit 910 is used to control the soft bus module to acquire the charging data of the target vehicle on the multiple charging devices, and to acquire the working data of the multiple charging devices.

[0168] The determining unit 920 is used to process the charging data in chronological order to obtain a charging data sequence; and to determine the device computing resources of the computing module of each of the plurality of charging devices based on the working data to obtain computing resource data.

[0169] The control unit 930 is used to divide the charging data sequence according to a preset computing task division rule to obtain multiple division computing tasks; and to allocate the multiple division tasks to the computing modules on each of the multiple charging devices according to a preset computing resource allocation rule to obtain multiple computing tasks; each of the multiple computing tasks includes at least one element in the charging data sequence.

[0170] The calculation unit 940 is used to input elements of the charging data sequence in the multiple calculation tasks into a preset battery life prediction model to obtain multiple prediction results; determine life prediction weights based on a preset attenuation factor, a preset life prediction weight calculation formula, and the charging data sequence to obtain multiple life prediction weights; and perform weighted calculation on the multiple prediction results according to the multiple life prediction weights to obtain a target prediction result.

[0171] In one possible embodiment, the charging data includes historical charging data and charging time data. Specifically, the determining unit 920, in processing the charging data in chronological order to obtain a charging data sequence, is used for:

[0172] Multiple charging event data are obtained by extracting each charging event of the target vehicle from the historical charging data;

[0173] Based on the charging time data, the start time corresponding to each charging event data in the plurality of charging event data is determined to obtain a plurality of charging start times;

[0174] The multiple charging start times are sorted in chronological order to obtain a charging start time sequence;

[0175] The charging event data corresponding to each charging start time in the charging start time sequence is determined to obtain the charging data sequence.

[0176] In one possible embodiment, the determining unit 920, in determining the device computing resources of the computing module of each of the plurality of charging devices based on the working data, and obtaining computing resource data, is specifically used for:

[0177] Based on the working data, the computing resource utilization rate and task queue length of the computing module of each of the multiple charging devices are determined, resulting in multiple computing resource utilization rates and multiple task queue lengths;

[0178] The computing power of the computing module of each of the multiple charging devices is determined based on the multiple computing resource occupancy rates, and the computing power resources are obtained.

[0179] The load parameters of each of the multiple charging devices are determined based on the lengths of the multiple task queues, thus obtaining the load parameters.

[0180] The required computing resources corresponding to the load parameters are determined based on the preset mapping relationship between load parameters and computing resource requirements, thus obtaining the computing resource requirements.

[0181] The computing resources of the computing module of each of the plurality of charging devices are determined based on the computing resource requirements and the computing power resources, and the computing resource data is obtained.

[0182] In one possible embodiment, the control unit 930, in dividing the charging data sequence according to a preset calculation task division rule to obtain multiple division calculation tasks, is specifically used for:

[0183] The charging record file of the target vehicle is extracted from the charging data sequence to obtain multiple charging record files;

[0184] Determine the source device of each of the multiple charging record files to obtain the multiple file device sources;

[0185] A target charging record file is obtained by selecting the charging record file corresponding to the target device source from the plurality of file device sources; the target device source is any one of the plurality of file device sources.

[0186] From the plurality of charging record files, the charging record files other than the target charging record file are selected to obtain a charging record file set;

[0187] Determine the data volume of each charging record file in the charging record file set to obtain the data volume of multiple files;

[0188] Based on the computing resource data, the computing resource occupancy parameters corresponding to the multiple charging devices are determined, resulting in multiple computing resource occupancy parameters;

[0189] The charging data record file set is divided according to the computing task division rules, the multiple resource usage parameters, and the multiple file data volumes to obtain the multiple partitioned computing tasks.

[0190] In one possible embodiment, the control unit 930, in dividing the charging data record file set according to the computational task partitioning rules, the plurality of resource occupancy parameters, and the plurality of file data volumes to obtain the plurality of partitioning computational tasks, is specifically configured to:

[0191] The resource occupancy parameters are sorted in descending order to obtain a resource occupancy parameter sequence;

[0192] The file data volumes of the multiple files are sorted in ascending order to obtain a file data volume sequence;

[0193] Based on the computation task partitioning rules and the resource occupancy parameter sequence, each charging record file in the file data volume sequence is partitioned to obtain the multiple partitioning computation tasks.

[0194] In one possible embodiment, the calculation unit 940, in determining the lifetime prediction weights based on a preset attenuation factor, a preset lifetime prediction weight calculation formula, and the charging data sequence, and obtaining multiple lifetime prediction weights, is specifically used for:

[0195] Based on the charging data, the last charging data of the target vehicle is determined to obtain the first charging data;

[0196] Determine the first charging start time in the first charging data;

[0197] Determine the charging start time corresponding to the plurality of charging devices in the charging data sequence to obtain a plurality of charging start times;

[0198] Subtracting the first charging start time from each of the plurality of charging start times yields a plurality of time differences.

[0199] The multiple time differences and the decay factor are calculated according to the lifetime prediction weight calculation formula to obtain the multiple lifetime prediction weights.

[0200] In one possible embodiment, the soft bus module includes a network management unit, a protocol unit, and a data management unit. Before the control unit 930 controls the soft bus module to acquire charging data of the target vehicle on the multiple charging devices and acquires the operating data of the multiple charging devices, the method further includes:

[0201] The system detects the responses of the multiple charging devices to the online detection frames sent by the network management unit to the multiple charging devices, and obtains multiple online statuses.

[0202] Based on the multiple online states, determine the connected charging devices among the multiple charging devices to obtain a set of connected charging devices;

[0203] Register device identifiers for all charging devices in the connected charging device set to obtain multiple registration identifiers;

[0204] The topological relationship of all charging devices in the connected charging device set is determined based on the multiple registration identifiers to obtain the charging device topological relationship;

[0205] Based on the device topology, link confirmation is performed on the set of connected charging devices to obtain the communication availability status.

[0206] Based on the communication availability status, the charging devices in the connected charging device set are networked to obtain the local area network system.

[0207] This application also provides a computer-readable storage medium storing a computer program for electronic data interchange, which causes a computer to perform some or all of the steps of any of the methods described in the above method embodiments, wherein the computer includes a charging device.

[0208] This application also provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps of any of the methods described in the above method embodiments. The computer program product may be a software installation package, and the computer includes a charging device.

[0209] It should be noted that, for the sake of simplicity, the above embodiments are all described as a series of actions. Those skilled in the art should understand that this application is not limited to the described order of actions, as some steps in the embodiments of this application can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions, steps, modules, or units involved are not necessarily essential to the embodiments of this application.

[0210] In the above embodiments, the descriptions of each embodiment have different focuses. Parts not described in detail in a certain embodiment can be referred to in the relevant descriptions of other embodiments. The specific embodiments described above further illustrate the purpose, technical solutions, and beneficial effects of the embodiments of this application. It should be understood that the above descriptions are merely specific implementations of the embodiments of this application and are not intended to limit the protection scope of the embodiments of this application. Any modifications, equivalent substitutions, improvements, etc., made based on the technical solutions of the embodiments of this application should be included within the protection scope of the embodiments of this application.

Claims

1. A soft bus based charging station battery life prediction method, characterized in that, The application relates to a control module applied to a local area network, wherein the local area network is composed of a plurality of charging devices interconnected through physical communication links; each charging device in the plurality of charging devices is provided with a computing module and a soft bus module; the soft bus module realizes signaling interaction between the charging devices through the physical communication links based on a soft bus protocol; The soft bus is a software architecture and communication protocol stack running on a local area network device, and is a distributed collaborative framework supporting device automatic discovery, service identification, standardized data exchange and resource sharing built on physical network connection, and is used for realizing cross-device data and computing power integration; the method comprises the following steps: The soft bus module is controlled to acquire charging data of a target vehicle on the plurality of charging devices and working data of the plurality of charging devices; The charging data is processed in time sequence to obtain a charging data sequence; Device computing resources of the computing module of each device in the plurality of charging devices are determined according to the working data to obtain computing resource data; The charging data sequence is divided according to a preset computing task division rule to obtain a plurality of division computing tasks; The plurality of division computing tasks are allocated to the computing module on each charging device in the plurality of charging devices according to a preset computing resource allocation rule to obtain a plurality of computing tasks; each computing task in the plurality of computing tasks comprises at least one element in the charging data sequence; Elements in the charging data sequence in the plurality of computing tasks are input into a preset battery life prediction model to obtain a plurality of prediction results; wherein the elements correspond to independent data files of one charging event; Life prediction weights are determined based on a preset attenuation factor, a preset life prediction weight calculation formula and the charging data sequence to obtain a plurality of life prediction weights; The plurality of prediction results are weighted calculated according to the plurality of life prediction weights to obtain a target prediction result. The life prediction weights are determined based on the preset attenuation factor, the preset life prediction weight calculation formula and the charging data sequence to obtain the plurality of life prediction weights, which comprises the following steps: The last charging data of the target vehicle in the charging data is determined to obtain first charging data; A first charging start time in the first charging data is determined; Corresponding charging start times of the plurality of charging devices in the charging data sequence are determined to obtain a plurality of charging start times; Each charging start time in the plurality of charging start times is subtracted from the first charging start time to obtain a plurality of time difference values; The plurality of time difference values and the attenuation factor are calculated according to the life prediction weight calculation formula to obtain the plurality of life prediction weights.

2. The method of claim 1, wherein, The charging data comprises historical charging data and charging time data; the charging data is processed in time sequence to obtain a charging data sequence, which comprises the following steps: Each charging event data of the target vehicle is extracted from the historical charging data to obtain a plurality of charging event data; The start time corresponding to each charging event data in the plurality of charging event data is determined according to the charging time data to obtain a plurality of charging start times; Sort the plurality of charging start times in chronological order to obtain a charging start time sequence; Determine the charging event data corresponding to each charging start time in the charging start time sequence to obtain the charging data sequence.

3. The method of claim 1, wherein, The computing resource data of the computing module of each of the plurality of charging devices is determined according to the working data, including: The computing resource occupancy rate and the task queue length of the computing module of each of the plurality of charging devices are determined according to the working data to obtain a plurality of computing resource occupancy rates and a plurality of task queue lengths; The computing resource of the computing module of each of the plurality of charging devices is determined according to the plurality of computing resource occupancy rates to obtain a computing resource; The load parameter of each of the plurality of charging devices is determined according to the plurality of task queue lengths to obtain a load parameter; The required computing resource corresponding to the load parameter is determined based on a preset mapping relationship between the load parameter and the computing resource requirement to obtain a computing resource requirement; The computing resource of the computing module of each of the plurality of charging devices is determined according to the computing resource requirement and the computing resource to obtain the computing resource data.

4. The method according to any one of claims 1 to 3, characterized in that, The charging data sequence is divided according to a preset computing task division rule to obtain a plurality of division computing tasks, including: Extract the charging record files of the target vehicle from the charging data sequence to obtain a plurality of charging record files; Determine the source device of each charging record file in the plurality of charging record files to obtain a plurality of file device sources; Select the charging record file corresponding to the target file device source from the plurality of file device sources to obtain a target charging record file; the target file device source is any one of the plurality of file device sources; Filter out the charging record files in the target charging record file from the plurality of charging record files to obtain a charging record file set; Determine the data amount of each charging record file in the charging record file set to obtain a plurality of file data amounts; Determine the computing resource occupancy parameter corresponding to the plurality of charging devices according to the computing resource data to obtain a plurality of computing resource occupancy parameters; Divide the charging record file set according to the computing task division rule, the plurality of computing resource occupancy parameters, and the plurality of file data amounts to obtain the plurality of division computing tasks.

5. The method of claim 4, wherein, The charging data sequence is divided according to a preset computing task division rule to obtain a plurality of division computing tasks, including: Sort the plurality of computing resource occupancy parameters in descending order to obtain a resource occupancy parameter sequence; Sort the plurality of file data amounts in ascending order to obtain a file data amount sequence; Divide each charging record file in the file data amount sequence based on the computing task division rule and the resource occupancy parameter sequence to obtain the plurality of division computing tasks.

6. The method of claim 1 or 2, wherein, The soft bus module includes a networking management unit, a protocol unit and a data management unit, and before the control of the soft bus module obtaining charging data of a target vehicle on the plurality of charging devices and obtaining working data of the plurality of charging devices, the method further comprises: Detecting a plurality of online states of the plurality of charging devices in response to the networking management unit sending an online detection frame to the plurality of charging devices; Determining connected charging devices in the plurality of charging devices according to the plurality of online states to obtain a set of connected charging devices; Registering device identification for all charging devices in the set of connected charging devices to obtain a plurality of registration identifications; Determining a topology relationship of all charging devices in the set of connected charging devices according to the plurality of registration identifications to obtain a charging device topology relationship; Confirming a link of the set of connected charging devices based on the charging device topology relationship to obtain a communication available state; Networking the charging devices in the set of connected charging devices according to the communication available state to obtain the local area network system.

7. A soft bus based charging station battery life prediction apparatus, characterized by, A control module applied to a local area network, the local area network being composed of a plurality of charging devices interconnected through physical communication links; each charging device in the plurality of charging devices being provided with a computing module and a soft bus module, the soft bus module being based on a soft bus protocol to realize signaling interaction between the charging devices through the physical communication links; The soft bus is a software architecture and communication protocol stack running on local area network devices, and is a distributed collaborative framework supporting device automatic discovery, service identification, standardized data exchange and resource sharing built on physical network connections, and is used to realize integration of cross-device data and computing power, and the device comprises: An acquisition unit configured to control the soft bus module to acquire charging data of a target vehicle on the plurality of charging devices and to acquire working data of the plurality of charging devices; A determination unit configured to process the charging data in chronological order to obtain a charging data sequence, and to determine device computing resources of the computing module of each device in the plurality of charging devices according to the working data to obtain computing resource data; A control unit configured to divide the charging data sequence according to a preset computing task division rule to obtain a plurality of division computing tasks, and to allocate the plurality of division tasks to the computing module on each charging device in the plurality of charging devices according to a preset computing resource allocation rule to obtain a plurality of computing tasks, each computing task in the plurality of computing tasks including at least one element in the charging data sequence; A computing unit configured to input the elements in the charging data sequence in the plurality of computing tasks into a preset battery life prediction model to obtain a plurality of prediction results, to determine a life prediction weight based on a preset decay factor, a preset life prediction weight calculation formula and the charging data sequence to obtain a plurality of life prediction weights, and to perform weighted calculation on the plurality of prediction results according to the plurality of life prediction weights to obtain a target prediction result; The element corresponds to an independent data file of a charging event; the life prediction weight is calculated based on a preset attenuation factor, a preset life prediction weight calculation formula and the charging data sequence, a plurality of life prediction weights are obtained, and the method comprises the following steps: According to the last charging data of the target vehicle in the charging data, a first charging data is obtained; A first charging start time in the first charging data is determined; A charging start time corresponding to the plurality of charging devices in the charging data sequence is determined, and a plurality of charging start times are obtained; Each charging start time in the plurality of charging start times is subtracted by the first charging start time, and a plurality of time difference values are obtained; The plurality of time difference values and the attenuation factor are calculated according to the life prediction weight calculation formula, and the plurality of life prediction weights are obtained.

8. A charging device, characterized by Comprise: A processor, a memory, a communication interface and one or more programs; The one or more programs are stored in the memory and configured to be executed by the processor, and the programs comprise instructions for executing the steps in the method of any one of claims 1-6.

9. A soft bus based charging station battery life prediction system, characterized in that, The soft bus-based charging station battery life prediction system executes the method of any one of claims 1-6.

Images