BMS cloud data consistency test system and method for mobile terminal application
By using a cloud-based BMS data consistency testing system for mobile applications, the problems of data asynchrony and lack of automated detection in BMS systems have been solved. This system enables data consistency verification and self-healing, thereby improving system reliability and testing efficiency.
Patent Information
- Application Number
- CN202610903884.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-06-23
- Publication Date
- 2026-08-04
AI Technical Summary
Existing BMS systems suffer from data latency, packet loss, and out-of-order issues during data transmission, resulting in data displayed on mobile devices being out of sync with the original BMS data. Furthermore, the lack of a full-link automated consistency detection mechanism impacts system reliability and anomaly troubleshooting efficiency.
Establish a real-time data collection and standardized processing system across the entire chain from BMS to cloud platform to APP and mini-program. Perform multi-dimensional consistency verification through the benchmark data source stored on the cloud platform, including comparison of timestamps, values, integrity and check codes, to achieve anomaly classification, location and self-healing repair.
Ensuring cross-platform consistency of BMS data improves system reliability, significantly enhances detection efficiency and accuracy, shortens anomaly detection cycle, reduces manual testing costs, and achieves full-process traceability.
Smart Images
Figure CN122513318A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of battery management technology, and in particular to a cloud-based data consistency testing system and method for BMS (Battery Management System) for mobile applications. Background Technology
[0002] With the rapid popularization of new energy storage, power batteries, battery swapping cabinets, low-speed electric vehicles and distributed energy systems, the battery management system (BMS) has become a core component for ensuring safe battery operation, extending cycle life and improving energy utilization.
[0003] The Battery Management System (BMS) is responsible for collecting key parameters of the battery pack in real time, including individual cell voltage, total voltage, charging and discharging current, temperature, insulation status, remaining charge (SOC), state of health (SOH), and fault alarms. This data is then uploaded to the cloud platform via a communication module for storage, calculation, analysis, and display. Users and maintenance personnel primarily access the cloud platform through lightweight terminals such as mobile applications (APPs) and WeChat mini-programs to achieve functions such as battery status monitoring, remote control, historical data query, and receiving abnormal alarms.
[0004] In practical engineering applications, BMS data needs to undergo multi-level transmission and processing from the acquisition end to the mobile display end, including BMS hardware acquisition, edge gateway, communication network, cloud platform access service, data parsing, database storage, interface service, APP / mini-program requests, local parsing, and interface rendering. This link involves multiple links such as hardware, network, server, protocol parsing, and front-end display. An abnormality in any link may lead to data inconsistency issues.
[0005] The existing technology has the following technical defects: First, data transmission delays, packet loss, and out-of-order delivery can easily cause the data displayed in the APP / mini-program to be out of sync with the original BMS data. In weak network environments, mobile devices may experience issues such as timeout retries, outdated caches, and APIs returning old data when fetching data, leading to discrepancies between the voltage, current, and SOC values seen by users and the actual battery status, which can result in misjudgments in severe cases. Second, the display standards across multiple terminals are not uniform. Apps and mini-programs use different development frameworks, data parsing logics, and interface rendering rules. When the same data is obtained from the cloud platform at the same time, the values may be inconsistent due to differences in parsing accuracy, unit conversion, decimal retention, timestamp processing, etc., which affects the credibility of the system. Third, there is a lack of a fully automated consistency detection mechanism. Traditional detection methods rely on manual comparison and sampling verification, which are inefficient, have low coverage, cannot be continuously monitored 24 / 7, and are difficult to quickly locate whether the anomaly occurs on the BMS, cloud, APP, or mini-program. Fourth, abnormal data cannot be automatically traced and recorded. When data inconsistencies occur, maintenance personnel lack key information such as timestamps, data snapshots, and link logs, resulting in long troubleshooting cycles and high repair costs. Fifth, a tiered alarm and self-healing mechanism has not been established. Different levels of anomalies, such as minor delays, serious deviations, and data loss, are not differentiated and handled. The system is unable to automatically perform self-healing operations such as retrying fetching, clearing the cache, and retransmitting data. Summary of the Invention
[0006] The purpose of this invention is to provide a BMS cloud data consistency testing system and method for mobile applications. It has the advantages of BMS end-to-end data standardization processing, multi-dimensional consistency verification, anomaly hierarchical location and self-healing repair, and comprehensively improves the accuracy, consistency and stability of BMS cloud data transmission and display.
[0007] The above-mentioned technical objective of the present invention is achieved through the following technical solution: The BMS cloud data consistency testing method for mobile applications includes the following steps: Step 1: Establish real-time data collection and standardized processing across the entire chain from BMS to cloud platform to APP and mini-program; Step 2: Using the raw BMS data stored on the cloud platform as the baseline data source, construct a baseline database with a unique identifier and verification code; Step 3: The BMS uploads real-time data to the cloud platform via its own 4G network. Step 4: The APP and mini-program retrieve real-time data from the cloud platform according to the strategy, recalculate and generate a display snapshot, and save it locally; Step 5: The background statistics cloud platform collects real-time data from the cloud platform, APP, and mini-program respectively, and performs multi-dimensional consistency comparison with the benchmark data source of the cloud platform's benchmark library, including timestamp comparison, numerical comparison, integrity comparison, and check code comparison. Step 6: Determine and classify anomalies based on preset thresholds; Step 7: Anomaly location, log recording, alarm push, and self-healing; Step 8: Visual statistics and report output from the background statistics cloud platform.
[0008] The preferred option is as follows: Preferred: In step one, Real-time data includes individual cell voltage, total voltage, charge / discharge current, temperature, SOC, SOH, fault codes, device serial number, acquisition timestamp, and upload timestamp.
[0009] Preferred: In step one, Standardization processes include unified timestamp format, unified physical quantity units, unified data precision, unified field names, and unified protocol parsing rules.
[0010] Preferred: In step two, The baseline data source is stored in a time-series database. Each data entry contains a data ID, device SN, timestamp, original value, parsed value, and checksum.
[0011] Preferred: In step four, The strategies include timed fetching, event-triggered fetching, page refresh fetching, and alarm-linked fetching.
[0012] Preferred: In step five, Multi-dimensional consistency comparison includes, Timestamp consistency: the time difference between BMS data collection time, cloud database entry time, and mobile display time must be less than or equal to a set threshold. Numerical consistency: deviations of key indicators such as voltage, current, SOC, and temperature ≤ set thresholds; Completeness and consistency: required fields are complete with no missing characters, no garbled text, and no parsing failures. Verification code consistency: the verification codes in the cloud platform's baseline library completely match the verification codes recalculated by the APP and mini-program.
[0013] Preferred option: In step six, The anomaly classification includes normal, warning, general anomaly, severe anomaly, and malfunction.
[0014] Preferred: In step seven, Anomaly localization determines whether the anomaly point is located at the BMS data collection end, cloud storage, APP parsing, mini-program parsing, or network transmission.
[0015] A cloud-based BMS data consistency testing system for mobile applications, including BMS, cloud platform, APP, mini-program, and backend statistics cloud platform. The backend statistics cloud platform has a consistency detection module, an anomaly alarm module, and a data visualization module. BMS connects to the cloud platform via wireless network; BMS connects to the APP and mini-program via Bluetooth; the cloud platform connects to the APP and mini-program via wireless network; and the cloud platform connects to the backend statistics cloud platform via wireless network.
[0016] Preferably, the background statistics cloud platform also includes a computer-readable storage medium that stores computer programs.
[0017] In summary, the present invention has the following beneficial effects: 1. Ensure cross-terminal consistency of BMS data and improve system reliability. Use the benchmark data of the cloud platform as a unified standard and perform multi-dimensional consistency verification with the APP and mini-program terminals. Avoid misjudgment of battery status, display abnormalities and business logic errors caused by data asynchrony, time sequence disorder and numerical deviation from the source. Significantly improve the credibility of data throughout the entire link from BMS cloud to mobile terminal. 2. Establish standardized testing benchmarks. Through standardized data collection and the construction of a cloud-based benchmark library, a unified and standardized comparison benchmark will be formed to ensure the authority and accuracy of the comparison standard. 3. By comparing and verifying data from four dimensions—time stamp, value, integrity, and check code—a comprehensive verification of data consistency is achieved, significantly improving detection efficiency and accuracy. 4. No manual verification is required. The system automatically completes anomaly judgment, level classification and anomaly node location, and pushes alarms in real time, which significantly reduces the cost of manual testing, shortens the anomaly discovery cycle and improves the level of testing automation. 5. The entire process is traceable and statistically verifiable, facilitating problem review and optimization. Through snapshot records, test reports, and result statistics output, the entire testing process is fully traceable and auditable. Attached Figure Description
[0018] Figure 1 This is a schematic diagram of the system architecture of Example 1; Figure 2 This is a schematic diagram of the workflow of Example 2; Figure 3 This is a schematic diagram of the workflow of Example 3. Detailed Implementation
[0019] The present invention will be further described in detail below with reference to the accompanying drawings. Example 1:
[0020] Cloud-based BMS data consistency testing system for mobile applications, such as Figure 1 As shown, it includes BMS, cloud platform, APP, mini-program, and backend statistics cloud platform. BMS is connected to the cloud platform via wireless network, BMS is connected to the APP and mini-program via Bluetooth, cloud platform is connected to the APP and mini-program via wireless network, and cloud platform is connected to the backend statistics cloud platform via wireless network.
[0021] The background statistics cloud platform has a built-in consistency detection module, an anomaly alarm module, a data visualization module, and a computer-readable storage medium. It stores computer programs, and the modules work together to support fully automated testing, verification, anomaly handling, and statistical output. The devices are interconnected through 4G wireless network and Bluetooth, covering the entire data transmission and detection scenario.
[0022] BMS comes with a 4G network. BMS collects battery data once per second and uploads it to the cloud platform via 4G. Users can check the battery status in real time through the APP and mini-program. The BMS has no 4G network and only has a Bluetooth module. The BMS collects battery data once per second and uploads it to the APP and mini-program via Bluetooth. Users can check the battery status in real time through the APP and mini-program, and then upload it to the cloud platform via 4G. Example 2:
[0023] Methods for testing cloud-based BMS data consistency for mobile applications, such as Figure 2 As shown, the BMS has a built-in 4G network. The specific operation steps are as follows: Step 1: Establish real-time data collection and standardized processing across the entire chain from BMS to cloud platform to APP and mini-program; Real-time data includes individual cell voltage, total voltage, charge / discharge current, temperature, SOC, SOH, fault codes, device serial number, acquisition timestamp, and upload timestamp; Standardization processes include unifying timestamp formats, physical quantity units, data precision, field names, and protocol parsing rules. By using unified standardization rules, data discrepancies caused by different terminals and different parsing logics are eliminated, providing a unified data benchmark for subsequent consistency comparisons. The individual unit voltage is 2.985V to 3.350V. Total voltage: 26V; Charge / discharge current: -2.8A, in discharge state; Temperature: 32℃; SOC: 86.5%; SOH: 98.2% Fault code: 00, normal status; Device ID: UT001; Data collection timestamp: 2026-03-31 09:30:45; Unified standardization in the cloud: Timestamp format: YYYY-MM-DD HH:MM:SS Voltage unit: V, rounded to one decimal place; Electric current unit: A, rounded to one decimal place; Temperature unit: °C; SOC / SOH: Percentage; Unified fields: vol, cur, temp, soc, soh, alarm; Step 2: Using the raw BMS data stored on the cloud platform as the baseline data source, construct a baseline database with a unique identifier and verification code; The baseline data source is stored in a time-series database. Each data entry contains a data ID, device SN, timestamp, original value, parsed value, and checksum. After receiving the raw data uploaded by BMS, the cloud platform parses, verifies, and stores it, and generates: Data ID: UID202603170930450017MD5; Verification code: 9E387D1FCB2A4F7C81123456789ABCDE; Stored in the database as a benchmark for subsequent comparisons; Step 3: The BMS uploads real-time data to the cloud platform via its own 4G network. Step 4: The APP and mini-program retrieve real-time data from the cloud platform according to the strategy, recalculate and generate a display snapshot, and save it locally; The strategies include timed fetching, event-triggered fetching, page refresh fetching, and alarm-linked fetching; The app retrieves data every 2 seconds. The mini-program retrieves data every 3 seconds. After successful retrieval, the mobile app and mini-program will save the data locally. Display value, display time, parsed fields, and recalculated MD5; Step 5: The background statistics cloud platform collects real-time data from the cloud platform, APP, and mini-program respectively, and performs multi-dimensional consistency comparison with the benchmark data source of the cloud platform's benchmark library, including timestamp comparison, numerical comparison, integrity comparison, and check code comparison. Timestamp consistency: The time difference between BMS collection time, cloud database entry time, and mobile display time must be less than or equal to a set threshold of 3 seconds. Numerical consistency: deviations of key indicators such as voltage, current, SOC, and temperature ≤ set thresholds; Voltage deviation ≤ 0.005V; Current deviation ≤ 0.1A; SOC deviation ≤ 0.5%; The deviation of key temperature indicators is ≤1℃; Completeness and consistency: the required fields vol, cur, soc, ts, and sn have no missing characters, no garbled characters, and no parsing failures; Check code consistency: the check codes in the cloud platform's benchmark library are completely matched with the check codes recalculated by the APP and mini-program, and the MD5 check codes are consistent with the cloud benchmark.
[0024] Step 6: Determine and classify anomalies based on preset thresholds; Anomaly classification includes normal, warning, general anomaly, severe anomaly, and malfunction; Normal: Completely consistent; Note: A time difference of 2-3 seconds is generally acceptable. Abnormal: SOC deviation 0.5%~1%; Serious abnormality: Voltage deviation > 0.005V, inconsistent fault codes; Fault: Field missing, MD5 mismatch; Step 7: Anomaly location, log recording, alarm push, and self-healing; In anomaly localization, it is determined whether the anomaly point is located at the BMS data collection end, cloud storage, APP parsing, mini-program parsing, or network transmission. The detected SOC (State of Content) for the mini-program display was 85.2%. Cloud-based benchmark = 86.5%; Deviation 1.3%; At this point, the system determines: general anomaly; Anomaly identification: Parsing and caching issues on the mini-program side; Self-healing: Automatically triggers the mini-program to re-fetch and clear local cache; Log entries include: time, device, anomaly point, baseline value, displayed value, snapshot, and MD5. Push notifications: SMS, background messages, and app pop-ups; Step 8: Visual statistics and report output from the background cloud platform; Backend display: total number of devices, online rate, data consistency rate, number of anomalies, anomaly type ranking, anomaly time period distribution, and anomaly device ranking; supports exporting daily and weekly reports. Through actual operation and verification, this embodiment can achieve a data consistency rate of ≥99.8%, shorten the anomaly location time from several hours to within 1 minute, and significantly improve system stability. Example 3:
[0025] Methods for testing cloud-based BMS data consistency for mobile applications, such as Figure 3 As shown, the BMS does not have a 4G network and only has a built-in Bluetooth module. The specific operation steps are as follows: Step 1: Establish real-time data collection and standardized processing across the entire chain from BMS to cloud platform to APP and mini-program; Real-time data includes individual cell voltage, total voltage, charge / discharge current, temperature, SOC, SOH, fault codes, device serial number, acquisition timestamp, and upload timestamp; Standardization processes include unifying timestamp formats, physical quantity units, data precision, field names, and protocol parsing rules. By using unified standardization rules, data discrepancies caused by different terminals and different parsing logics are eliminated, providing a unified data benchmark for subsequent consistency comparisons. The individual unit voltage is 2.985V to 3.350V. Total voltage: 26V; Charge / discharge current: -2.8A, in discharge state; Temperature: 32℃; SOC: 86.5%; SOH: 98.2% Fault code: 00, normal status; Device ID: UT001; Data collection timestamp: 2026-03-31 09:30:45; Unified standardization in the cloud: Timestamp format: YYYY-MM-DD HH:MM:SS Voltage unit: V, rounded to one decimal place; Electric current unit: A, rounded to one decimal place; Temperature unit: °C; SOC / SOH: Percentage; Unified fields: vol, cur, temp, soc, soh, alarm; Step 2: Using the raw BMS data stored on the cloud platform as the baseline data source, construct a baseline database with a unique identifier and verification code; The baseline data source is stored in a time-series database. Each data entry contains a data ID, device SN, timestamp, original value, parsed value, and checksum. After receiving the raw data uploaded by BMS, the cloud platform parses, verifies, and stores it, and generates: Data ID: UID202603170930450017MD5; Verification code: 9E387D1FCB2A4F7C81123456789ABCDE; Stored in the database as a benchmark for subsequent comparisons; Step 3: The BMS uploads real-time data to the APP and mini-program via its built-in Bluetooth. Apps and mini-programs upload factual data to the cloud platform; Step 4: The APP and mini-program calculate and generate display snapshots according to the strategy, and save them locally; The strategies include timed fetching, event-triggered fetching, page refresh fetching, and alarm-linked fetching; The app retrieves data every 2 seconds. The mini-program retrieves data every 3 seconds. After successful retrieval, the mobile app and mini-program will save the data locally. Display value, display time, parsed fields, and recalculated MD5; Step 5: The background statistics cloud platform collects real-time data from the cloud platform, APP, and mini-program respectively, and performs multi-dimensional consistency comparison with the benchmark data source of the cloud platform's benchmark library, including timestamp comparison, numerical comparison, integrity comparison, and check code comparison. Timestamp consistency: The time difference between BMS collection time, cloud database entry time, and mobile display time must be less than or equal to a set threshold of 3 seconds. Numerical consistency: deviations of key indicators such as voltage, current, SOC, and temperature ≤ set thresholds; Voltage deviation ≤ 0.005V; Current deviation ≤ 0.1A; SOC deviation ≤ 0.5%; The deviation of key temperature indicators is ≤1℃; Completeness and consistency: the required fields vol, cur, soc, ts, and sn have no missing characters, no garbled characters, and no parsing failures; Check code consistency: the check codes in the cloud platform's benchmark library are completely matched with the check codes recalculated by the APP and mini-program, and the MD5 check codes are consistent with the cloud benchmark.
[0026] Step 6: Determine and classify anomalies based on preset thresholds; Anomaly classification includes normal, warning, general anomaly, severe anomaly, and malfunction; Normal: Completely consistent; Note: A time difference of 2-3 seconds is generally acceptable. Abnormal: SOC deviation 0.5%~1%; Serious abnormality: Voltage deviation > 0.005V, inconsistent fault codes; Fault: Field missing, MD5 mismatch; Step 7: Anomaly location, log recording, alarm push, and self-healing; In anomaly localization, it is determined whether the anomaly point is located at the BMS data collection end, cloud storage, APP parsing, mini-program parsing, or network transmission. The detected SOC (State of Content) for the mini-program display was 85.2%. Cloud-based benchmark = 86.5%; Deviation 1.3%; At this point, the system determines: general anomaly; Anomaly identification: Parsing and caching issues on the mini-program side; Self-healing: Automatically triggers the mini-program to re-fetch and clear local cache; Log entries include: time, device, anomaly point, baseline value, displayed value, snapshot, and MD5. Push notifications: SMS, background messages, and app pop-ups; Step 8: Visual statistics and report output from the background cloud platform; Backend display: total number of devices, online rate, data consistency rate, number of anomalies, anomaly type ranking, anomaly time period distribution, and anomaly device ranking; supports exporting daily and weekly reports. Through actual operation and verification, this embodiment can achieve a data consistency rate of ≥99.8%, shorten the anomaly location time from several hours to within 1 minute, and significantly improve system stability.
[0027] This specific embodiment is merely an explanation of the present invention and is not intended to limit the invention. After reading this specification, those skilled in the art can make modifications to this embodiment without contributing any inventive step, but such modifications are protected by patent law as long as they are within the scope of the claims of the present invention.
Claims
1. A BMS cloud data consistency testing method for mobile applications, characterized by: The following steps are included: Step 1: Establish real-time data collection and standardized processing across the entire chain from BMS to cloud platform to APP and mini-program; Step 2: Using the raw BMS data stored on the cloud platform as the baseline data source, construct a baseline database with a unique identifier and verification code; Step 3: The BMS uploads real-time data to the cloud platform via its own 4G network. Step 4: The APP and mini-program retrieve real-time data from the cloud platform according to the strategy, recalculate and generate a display snapshot, and save it locally; Step 5: The background statistics cloud platform collects real-time data from the cloud platform, APP, and mini-program respectively, and performs multi-dimensional consistency comparison with the benchmark data source of the cloud platform's benchmark library, including timestamp comparison, numerical comparison, integrity comparison, and check code comparison. Step 6: Determine and classify anomalies based on preset thresholds; Step 7: Anomaly location, log recording, alarm push, and self-healing; Step 8: Visual statistics and report output from the background statistics cloud platform.
2. The BMS cloud data consistency testing method for mobile applications according to claim 1, characterized in that: In step one, Real-time data includes individual cell voltage, total voltage, charge / discharge current, temperature, SOC, SOH, fault codes, device serial number, acquisition timestamp, and upload timestamp.
3. The BMS cloud data consistency testing method for mobile applications according to claim 1, characterized in that: In step one, Standardization processes include unified timestamp format, unified physical quantity units, unified data precision, unified field names, and unified protocol parsing rules.
4. The BMS cloud data consistency testing method for mobile applications according to claim 1, characterized in that: In step two, The baseline data source is stored in a time-series database. Each data entry contains a data ID, device SN, timestamp, original value, parsed value, and checksum.
5. The BMS cloud data consistency testing method for mobile applications according to claim 1, characterized in that: In step four, The strategies include timed fetching, event-triggered fetching, page refresh fetching, and alarm-linked fetching.
6. The BMS cloud data consistency testing method for mobile applications according to claim 1, characterized in that: In step five, Multi-dimensional consistency comparison includes, Timestamp consistency: the time difference between BMS data collection time, cloud database entry time, and mobile display time must be less than or equal to a set threshold. Numerical consistency: deviations of key indicators such as voltage, current, SOC, and temperature ≤ set thresholds; Completeness and consistency: required fields are complete with no missing characters, no garbled text, and no parsing failures. Verification code consistency: the verification codes in the cloud platform's baseline library completely match the verification codes recalculated by the APP and mini-program.
7. The BMS cloud data consistency testing method for mobile applications according to claim 1, characterized in that: In step six, The anomaly classification includes normal, warning, general anomaly, severe anomaly, and malfunction.
8. The BMS cloud data consistency testing method for mobile applications according to claim 1, characterized in that: In step seven, Anomaly localization determines whether the anomaly point is located at the BMS data collection end, cloud storage, APP parsing, mini-program parsing, or network transmission.
9. A BMS cloud data consistency testing system for mobile applications, used in the BMS cloud data consistency testing method for mobile applications as described in claim 1, characterized in that: It includes BMS, cloud platform, APP, mini program, and back-end statistics cloud platform. The back-end statistics cloud platform has a consistency detection module, an anomaly alarm module, and a data visualization module. BMS connects to the cloud platform via wireless network; BMS connects to the APP and mini-program via Bluetooth; the cloud platform connects to the APP and mini-program via wireless network; and the cloud platform connects to the backend statistics cloud platform via wireless network.
10. The BMS cloud data consistency testing system for mobile applications according to claim 9, characterized in that: The background statistics cloud platform also includes computer-readable storage media that stores computer programs.