Data processing method, computer device and storage medium
By introducing a unified timestamp and abnormal condition judgment in BMS device testing, the problems of data synchronization and stability of multiple BMS devices were solved, and the accurate reflection of battery pack status and stable system operation were achieved.
Patent Information
- Application Number
- CN202611045854.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-07-14
- Publication Date
- 2026-11-03
AI Technical Summary
In existing technologies, when multiple BMS devices are tested concurrently, the polling time difference results in data with independent receiving timestamps, leading to poor data synchronization and difficulty in reflecting the overall operating status of the battery pack. Furthermore, the abnormal handling mechanism is rigid, which can easily cause the acquisition program to crash or become blocked.
A unified timestamp mechanism is adopted to generate a unified timestamp for each collection cycle, and anomaly condition judgment is introduced to record or skip abnormal data, ensuring data synchronization and system stability.
It improves the synchronization and reliability of testing, maintenance and data analysis of multiple BMS devices, accurately reflects the overall operating status of the battery pack, avoids misjudgment caused by time asynchrony, and maintains system stability in the face of failure.
Smart Images
Figure CN123030431A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of data processing technology, and in particular to a data processing method, computer equipment, and storage medium. Background Technology
[0002] With the rapid development of new energy vehicles, energy storage power stations, and electric ships, the performance testing and data analysis of battery management systems (BMS), as the core component ensuring the safe and efficient operation of battery packs, are particularly important. In laboratory testing or field maintenance scenarios, it is often necessary to monitor and record data from multiple BMS devices simultaneously for extended periods to evaluate battery consistency, charge-discharge characteristics, and fault response mechanisms.
[0003] Existing data acquisition solutions often suffer from time differences in polling when dealing with concurrent testing of multiple BMS devices, resulting in data from different BMS devices having their own independent receiving timestamps.
[0004] However, this timing misalignment leads to significant errors in the subsequent joint analysis of data from multiple devices, making it difficult to reflect the overall operating status of the battery pack. Summary of the Invention
[0005] This application provides a data processing method, computer equipment, and storage medium, aiming to solve the problem of difficulty in achieving data synchronization in the existing technology during BMS testing, maintenance, and data analysis.
[0006] In a first aspect, embodiments of this application provide a data processing method applied to multiple BMS devices to be polled, the method comprising: In response to the data recording start command, the current acquisition period is used as the target acquisition period; Generate a unified timestamp for the target acquisition period; Based on the unified timestamp, the operating data corresponding to each BMS device is read sequentially; Determine whether the running data meets preset abnormal conditions; If the running data does not meet the preset abnormal conditions, the running data is recorded in the target data cache of the BMS device; According to the unified timestamp, the data of all the BMS devices are recorded in a preset record file, and the next collection cycle of the target collection cycle is taken as the new target collection cycle, returning to the step of generating the unified timestamp of the target collection cycle.
[0007] A further technical solution is that determining whether the operating data meets preset abnormal conditions further includes: If the running data meets a preset abnormal condition, a preset abnormal identifier is written into the target data cache of the BMS device.
[0008] A further technical solution is that the generation of a unified timestamp for the target acquisition period includes: Obtain the total number of BMS devices to be polled and the estimated time for a single polling round; If the total number of BMS devices to be polled is less than or equal to the first preset number threshold, or the estimated time for a single polling round is less than or equal to the preset polling threshold, then the start or midpoint of the target collection cycle will be used as the unified timestamp. If the total number of BMS devices to be polled is greater than the first preset number threshold, or the estimated time for a single polling round is greater than the preset polling threshold, then the base time of the target collection cycle is used as a unified timestamp, and the actual reading time corresponding to each BMS device is recorded respectively.
[0009] A further technical solution is that the preset abnormal conditions include communication timeout conditions, data loss conditions, and parsing abnormal conditions, and the determination of whether the running data meets the preset abnormal conditions includes: Determine whether the running data meets the communication timeout condition, the data missing condition, and the parsing anomaly condition; If the running data meets at least one of the communication timeout condition, the data missing condition, and the parsing anomaly condition, then the running data is determined to meet the preset anomaly condition.
[0010] A further technical solution is that the communication timeout conditions include at least one of command response timeout, frame interval timeout, and heartbeat loss timeout, and the method includes: If no response message is received from the BMS device within the target acquisition period, the instruction response timeout is determined to be triggered. When receiving multiple consecutive frames of data sent by the BMS device, if the time interval between two adjacent frames exceeds a preset interval threshold, the frame interval timeout is determined to be triggered. If no heartbeat message is received from the BMS device within multiple consecutive target acquisition cycles, the heartbeat loss timeout is determined to be triggered.
[0011] A further technical solution is that the parsing anomaly conditions include at least one of the following: verification anomaly, device address mismatch, instruction type mismatch, data format anomaly, and data value anomaly.
[0012] A further technical solution is that, after determining whether the running data meets the preset abnormal conditions, the method further includes: Determine the anomaly type of the runtime data; Based on the aforementioned exception type, a corresponding target status code is generated; The target status code is then written into the target data cache as the exception identifier.
[0013] A further technical solution is that, based on the exception type, generating the corresponding target status code includes: If the exception type is instruction response timeout, then a first target status code is generated; If the anomaly type is frame interval timeout, then a second target status code is generated; If the anomaly type is heartbeat loss timeout, then a third target status code is generated; If the anomaly type is missing data, then a fourth target status code is generated; If the exception type is a parsing exception, then a fifth target status code is generated; If the exception type is a verification exception, then a sixth target status code is generated; If the anomaly type is device offline, then a seventh target status code is generated.
[0014] Secondly, embodiments of this application also provide a computer device, which includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the above-described method.
[0015] Thirdly, embodiments of this application also provide a computer-readable storage medium storing a computer program that, when executed by a processor, can implement the above-described method.
[0016] This application provides a data processing method, a computer device, and a storage medium. The method includes: responding to a data recording initiation command, setting the current acquisition period as a target acquisition period; generating a unified timestamp for the target acquisition period; sequentially reading the operating data corresponding to each BMS device based on the unified timestamp; determining whether the operating data meets preset abnormal conditions; if the operating data does not meet the preset abnormal conditions, recording the operating data in the target data buffer of the BMS device; recording the data of all BMS devices in a preset record file according to the unified timestamp, and setting the next acquisition period of the target acquisition period as the new target acquisition period, returning to the step of generating the unified timestamp for the target acquisition period.
[0017] This application's embodiments generate a unique unified timestamp in each acquisition cycle. For BMS devices that return data normally, the unified timestamp is recorded in the target data buffer. That is, all BMS devices polled within the acquisition cycle share this unified timestamp for data recording. By using the unified timestamp, data from multiple BMS devices obtained in the same polling round are associated with the same acquisition batch, reducing data alignment difficulties caused by each device using independent recording times. Simultaneously, the actual reading time of each BMS device can be recorded to preserve the true time information of the data. This improves the synchronization of multiple BMS devices during testing, maintenance, and data analysis, thereby accurately reflecting the overall operating status of the battery pack and avoiding misjudgments caused by time asynchrony. Furthermore, this application introduces a step of "determining whether the operating data meets preset abnormal conditions." This means that when a BMS device experiences a communication failure or data anomaly, the system can identify and execute the corresponding anomaly handling process (such as recording an anomaly flag or skipping it) without causing the entire acquisition program to crash or be blocked. This fault-tolerance mechanism ensures that when faced with multiple devices waiting to be polled, even if one device fails, the data recording of other normal devices can continue according to the collection cycle, thus improving the stability and reliability of the system under complex operating conditions. Attached Figure Description
[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.
[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0020] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.
[0021] Figure 1 A flowchart illustrating a first embodiment of a data processing method provided in this application; Figure 2 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation
[0022] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0023] The following disclosure provides numerous different embodiments or examples for implementing various structures of this application. To simplify the disclosure, specific examples of components and arrangements are described below. These are merely examples and are not intended to limit the scope of this application. Furthermore, reference numerals and / or letters may be repeated in different examples. Such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed.
[0024] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.
[0025] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of the application. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.
[0026] It should also be further understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.
[0027] As used in this specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if [described condition or event] is detected" may be interpreted, depending on the context, as "once determined," "in response to determination," "once [described condition or event] is detected," or "in response to detection of [described condition or event]."
[0028] With the rapid development of new energy vehicles, energy storage power stations, and electric ships, the performance testing and data analysis of battery management systems (BMS), as the core component ensuring the safe and efficient operation of battery packs, are particularly important. In laboratory testing or field maintenance scenarios, it is often necessary to monitor and record data from multiple BMS devices simultaneously for extended periods to evaluate battery consistency, charge-discharge characteristics, and fault response mechanisms.
[0029] Existing multi-BMS data acquisition and recording methods typically employ a polling mechanism, where the host computer sequentially sends read commands to each BMS and receives feedback data. However, due to the time difference in polling, data from different BMS devices often carries their own independent receiving timestamps. This timing discrepancy leads to significant errors in the subsequent joint analysis of multi-device data, making it difficult to reflect the overall operating status of the battery pack.
[0030] Furthermore, in practical applications, due to the instability of communication links, the response delay of BMS devices themselves, or hardware failures, abnormal situations such as communication timeouts, data packet loss, or data parsing failures are prone to occur in some devices. The existing abnormal handling mechanisms are relatively rigid. Once a BMS device experiences a communication failure or data abnormality, the acquisition program is prone to getting blocked, reporting errors, or even crashing and exiting directly, resulting in the inability to record data from other normally operating BMS devices at the same time, which seriously disrupts the continuity of test data. In addition, when BMS devices experience abnormal situations, traditional log files often only show blank data or garbled characters, making it difficult for data analysts to distinguish whether the device itself has a value of zero, communication is interrupted, or parsing is incorrect, greatly increasing the difficulty of subsequent data cleaning and troubleshooting.
[0031] To address the aforementioned technical issues, this application provides a data processing method that improves the synchronization, continuity, and reliability of multiple BMS devices during testing, maintenance, and data analysis, thereby accurately reflecting the overall operating status of the battery pack and avoiding misjudgments caused by time asynchrony.
[0032] See Figure 1 , Figure 1 This is a flowchart illustrating a first embodiment of a data processing method provided in this application. The method may include the following steps: Step 110: In response to the data recording start command, use the current acquisition period as the target acquisition period.
[0033] Step 120: Generate a unified timestamp for the target acquisition period.
[0034] For steps 110-120, for example, after connecting multiple BMS devices to the host computer, a BMS device list can be established, and a corresponding data buffer can be established for each BMS device. When the user starts the recording function, the host computer can read data from multiple BMS devices according to the set collection period and generate a unified timestamp in each collection period.
[0035] Step 130: Based on the unified timestamp, read the operation data corresponding to each BMS device in sequence.
[0036] In step 130, the operating data covers multi-dimensional information reflecting the real-time operating conditions of the battery pack, mainly including electrical parameters (such as voltage and current), thermal management parameters (such as temperature), battery status indicators (such as SOC), and safety diagnostic information (such as alarm status).
[0037] Step 140: Determine whether the running data meets the preset abnormal conditions.
[0038] Step 150: In response to the fact that the running data does not meet the preset abnormal conditions, the running data is recorded in the target data cache area of the BMS device.
[0039] Step 160: According to the unified timestamp, record the data of all the BMS devices in a preset record file, and take the next acquisition cycle of the target acquisition cycle as the new target acquisition cycle, and return to the step of generating the unified timestamp of the target acquisition cycle.
[0040] This embodiment generates a unique unified timestamp in each acquisition cycle. For BMS devices that return data normally, the unified timestamp is recorded in the target data buffer. This means that all BMS devices polled within the acquisition cycle share this unified timestamp for data recording. By using the unified timestamp, data from multiple BMS devices in the same polling round are associated with the same acquisition batch, reducing data alignment difficulties caused by each device using independent recording times. Simultaneously, the actual read time of each BMS device can be recorded to preserve the true time information of the data. This improves the synchronization during multi-BMS testing, maintenance, and data analysis, accurately reflecting the overall operating status of the battery pack and avoiding misjudgments due to time asynchrony. Furthermore, this application introduces a step of "determining whether the operating data meets preset abnormal conditions." This means that when a BMS device experiences a communication failure or data anomaly, the system can identify and execute the corresponding anomaly handling process (such as recording an anomaly flag or skipping it) without causing the entire acquisition program to crash or be blocked. This fault-tolerance mechanism ensures that when faced with multiple devices waiting to be polled, even if one device fails, the data recording of other normal devices can still continue on a cycle, improving the stability and reliability of the system under complex operating conditions.
[0041] Referring to a second embodiment of a data processing method provided in this application, the method may include the following steps: Step 210: In response to the data recording start command, use the current acquisition period as the target acquisition period.
[0042] Step 220: Generate a unified timestamp for the target acquisition period.
[0043] Step 230: Based on the unified timestamp, read the operation data corresponding to each BMS device in sequence.
[0044] Step 240: Determine whether the running data meets the preset abnormal conditions.
[0045] Step 250: In response to the fact that the running data does not meet the preset abnormal conditions, the running data is recorded in the target data cache area of the BMS device.
[0046] Step 260: In response to the running data meeting the preset abnormal conditions, a preset abnormal identifier is written into the target data cache area of the BMS device.
[0047] Step 270: According to the unified timestamp, record the data of all the BMS devices in a preset record file, and take the next acquisition cycle of the target acquisition cycle as the new target acquisition cycle, and return to the step of generating the unified timestamp of the target acquisition cycle.
[0048] This embodiment generates a unique unified timestamp in each acquisition cycle. For BMS devices that return data normally, the unified timestamp is recorded in the target data buffer. All BMS devices polled within the acquisition cycle share this unified timestamp for data recording. This unified timestamp associates data from multiple BMS devices obtained in the same polling cycle with the same acquisition batch, reducing data alignment difficulties caused by independent recording times for each device. Simultaneously, the actual read time of each BMS device can be recorded to preserve the true time information of the data. This improves the synchronization of multiple BMS devices during testing, maintenance, and data analysis, accurately reflecting the overall operating status of the battery pack and avoiding misjudgments due to time asynchrony. Furthermore, this application introduces a step of "determining whether the operating data meets preset abnormal conditions" and executes different recording strategies based on the determination result. This means that when a BMS device experiences a communication failure or data anomaly, the system can identify and execute the corresponding anomaly handling process (such as recording an anomaly flag or skipping it) without causing the entire acquisition process to crash or be blocked. This fault-tolerance mechanism ensures that when faced with multiple devices waiting to be polled, even if one device fails, the data recording of other normal devices can continue according to the collection cycle, thus improving the stability and reliability of the system under complex operating conditions.
[0049] This application adopts a serial polling method to test BMS devices one by one, enabling the host computer to accurately identify the response status of each BMS device. Once a BMS device experiences a communication failure or data anomaly, the system can immediately mark it as abnormal and automatically skip it, thereby continuing to read the subsequent BMS devices normally, effectively avoiding the blockage of the entire acquisition cycle by a single point of failure.
[0050] In some embodiments, the generation strategy for the unified timestamp can be dynamically adjusted according to the total number of BMS devices to be polled. For details, please refer to the third embodiment, which provides a specific description of how to generate the unified timestamp for the target collection period. In the third embodiment, generating the unified timestamp for the target collection period in response to the user's recording initiation command may include the following steps: Step 221: Obtain the total number of BMS devices to be polled and the estimated time for a single round of polling.
[0051] Step 222: If the total number of BMS devices to be polled is less than or equal to the first preset quantity threshold, or the estimated time for a single round of polling is less than or equal to the preset polling threshold, then the start point or midpoint of the target collection cycle is used as the unified timestamp.
[0052] Step 223: If the total number of BMS devices to be polled is greater than the first preset number threshold, or the estimated time for a single round of polling is greater than the preset polling threshold, then the base time of the target collection cycle is used as a unified timestamp, and the actual reading time corresponding to each BMS device is recorded respectively.
[0053] Specifically, the estimated time for a single round of polling = number of BMS * average reading time per BMS. If the estimated time for a single round of polling is less than the preset time threshold, it can be considered that the time difference between the data of each BMS in this round is small, and the starting time of the sampling period or the midpoint time of the period can be used as a unified timestamp.
[0054] The first preset quantity threshold and the preset polling threshold can be set and adjusted according to the actual situation, and this application does not make specific limitations here.
[0055] In other words, when dealing with a small number of BMS devices, all devices can be read quickly within a single acquisition cycle. Therefore, the start and midpoint of the sampling cycle can be used as timestamps.
[0056] For a large number of BMS devices, the start time of each sampling period can be used as a timestamp to indicate that the data belongs to the same round of collection. For example, if data needs to be collected from 50 BMS devices, the recorded data can be as follows: Timestamp of this batch of data collection: 10:00:00.000; BMS-1 actual read time: 10:00:00.010, voltage 380V; BMS-2 actual read time: 10:00:00.120, voltage 382V; BMS-3 actual read time: 10:00:00.230, voltage 379V; ...... BMS-50 actual reading time: 10:00:04.900, voltage 381V.
[0057] In this way, each BMS device records the actual read time when a read is successfully completed. This ensures that data from the same round is easy to classify and compare, while also preserving the true acquisition time of each BMS device.
[0058] In some embodiments, the preset abnormal conditions include communication timeout conditions, data loss conditions, and parsing abnormal conditions. For details, please refer to the fourth embodiment, which provides a detailed description of how to determine whether the running data meets the preset abnormal conditions. In the fourth embodiment, determining whether the running data meets the preset abnormal conditions may include the following steps: Step 241: Determine whether the running data meets the communication timeout condition, the data missing condition, and the parsing anomaly condition.
[0059] Step 242: If the running data satisfies at least one of the communication timeout condition, the data missing condition, and the parsing anomaly condition, then the running data is determined to meet the preset anomaly condition.
[0060] In some embodiments, the communication timeout conditions include at least one of command response timeout, frame interval timeout, and heartbeat loss timeout. The specific meanings and determination rules for each of the above-mentioned communication timeout types are as follows: Command response timeout: This refers to a situation where the host computer does not receive a response message from the BMS device within a preset command period after issuing a read command. The determination rule is: if no response message is received from the BMS device within the target acquisition period, the command response timeout is triggered. Frame interval timeout: This refers to the time the host computer waits for subsequent message bytes after receiving a partial response message from the BMS device, exceeding a preset character interval threshold. The determination rule is: when receiving multiple consecutive frames of data sent by the BMS device, if the time interval between two adjacent frames exceeds the preset interval threshold, the frame interval timeout is triggered. Heartbeat Loss Timeout: This refers to a situation where the BMS device is configured to periodically and actively report data, but the host computer fails to receive any heartbeat messages actively reported by the BMS device within the set heartbeat monitoring period. The determination rule is: if no heartbeat messages are received from the BMS device within multiple consecutive target acquisition periods, the heartbeat loss timeout is determined to be triggered.
[0061] In some embodiments, the parsing anomaly conditions include at least one of the following: verification anomaly, device address mismatch, instruction type mismatch, data format anomaly, and data value anomaly. Specifically, if the calculated result of the checksum, CRC, or other preset check fields in the returned message does not match the check value originally carried in the message, it indicates that the data has been damaged or lost during transmission, and can be judged as a check anomaly; if the BMS address in the returned message is inconsistent with the target BMS address currently being read by the host computer, it can be judged as a device address mismatch, which is usually caused by communication crosstalk or addressing errors; if the instruction type, data type, or function code in the returned message does not correspond to the read instruction issued by the host computer, it indicates that there is a logical misalignment in the device's response, and can be judged as an instruction type mismatch; if the returned data does not conform to the predetermined protocol format specifications, such as field position offset, byte order disorder, or missing data area, it can be judged as a data format anomaly; if the parsed data significantly exceeds the reasonable range allowed by the protocol or cannot be effectively converted, such as SOC (State of Charge) exceeding 100%, temperature field containing illegal characters, or voltage field being empty, it can be judged as a data value anomaly.
[0062] In some embodiments, the preset exception identifier can be an invalid value, an error code string, or a status flag. The exception identifiers for communication timeout, data missing, or parsing exception can be the same or different. For data consistency and ease of maintenance, the exception identifier can be defined with reference to the classification rules of HTTP status codes. It should be noted that those skilled in the art will understand that the 'HTTP-like status code' here only refers to an encoding mechanism that distinguishes different exception types (such as communication timeout, data missing, etc.) through a combination of multiple digits, and is not limited to a specific HTTP network transmission protocol. Specifically, after determining whether the running data meets the preset exception conditions, the exception type of the running data can be determined; based on the exception type, a corresponding target status code is generated; and the target status code is written as the exception identifier into the target data cache.
[0063] The step of generating a corresponding target status code based on the exception type may include: 1) If the exception type is instruction response timeout, then generate the first target status code; For example, the first target status code can be 40301 TIMEOUT_CMD.
[0064] 2) If the anomaly type is frame interval timeout, then generate a second target status code; For example, the second target status code can be 40302 TIMEOUT_FRAME.
[0065] 3) If the anomaly type is heartbeat loss timeout, then generate a third target status code; For example, the third target status code can be 40303 TIMEOUT_HEARTBEAT.
[0066] 4) If the anomaly type is missing data, then generate a fourth target status code; For example, the fourth target status code can be 40400 DATA_MISSING.
[0067] 5) If the exception type is a parsing exception, then generate the fifth target status code; For example, the fifth target status code can be 40500 PARSE_ERROR.
[0068] 6) If the exception type is a verification exception, then generate a sixth target status code; For example, the sixth target status code can be 40600 CHECK_ERROR.
[0069] 7) If the anomaly type is device offline, then generate the seventh target status code.
[0070] For example, the seventh target status code can be 40700 OFFLINE.
[0071] In addition, when the BMS device returns data normally, a preset normal transition status identifier can be recorded, such as 20000OK. In this embodiment, '20000 OK' is only a custom success status code example. In practical applications, the specific number of digits and meaning of this value can be defined by those skilled in the art according to business needs, and does not constitute a limitation on the scope of protection of this invention.
[0072] Corresponding to the above data processing methods, this application also provides a data processing apparatus. This data processing apparatus includes a unit for performing the above data processing methods and can be configured in a desktop computer, tablet computer, laptop computer, or other terminal.
[0073] like Figure 2 As shown in the figure, this application provides a computer device including a processor 111, a communication interface 112, a memory 113, and a communication bus 114, wherein the processor 111, the communication interface 112, and the memory 113 communicate with each other through the communication bus 114. Memory 113 is used to store computer programs; In one embodiment of this application, when the processor 111 executes a program stored in the memory 113, it implements the data processing method provided in any of the foregoing method embodiments, including: In response to the data recording start command, the current acquisition period is used as the target acquisition period; Generate a unified timestamp for the target acquisition period; Based on the unified timestamp, the operating data corresponding to each BMS device is read sequentially; Determine whether the running data meets preset abnormal conditions; If the running data does not meet the preset abnormal conditions, the running data is recorded in the target data cache of the BMS device; According to the unified timestamp, the data of all the BMS devices are recorded in a preset record file, and the next collection cycle of the target collection cycle is taken as the new target collection cycle, returning to the step of generating the unified timestamp of the target collection cycle.
[0074] In some embodiments, determining whether the running data meets preset abnormal conditions further includes: If the running data meets a preset abnormal condition, a preset abnormal identifier is written into the target data cache of the BMS device.
[0075] In some embodiments, generating a unified timestamp for the target acquisition period in response to a user's recording initiation command includes: Get the total number of BMS devices to be polled; If the total number of BMS devices to be polled is less than or equal to the first preset number threshold, then the start or midpoint of the target collection period is used as the unified timestamp. If the total number of BMS devices to be polled is greater than the first preset threshold, then the starting point of the target collection period is used as the unified timestamp.
[0076] In some embodiments, the preset abnormal conditions include communication timeout conditions, data loss conditions, and parsing abnormal conditions. Determining whether the running data meets the preset abnormal conditions includes: Determine whether the running data meets the communication timeout condition, the data missing condition, and the parsing anomaly condition; If the running data meets at least one of the communication timeout condition, the data missing condition, and the parsing anomaly condition, then the running data is determined to meet the preset anomaly condition.
[0077] In some embodiments, the communication timeout condition includes at least one of command response timeout, frame interval timeout, and heartbeat loss timeout, and the method includes: If no response message is received from the BMS device within the target acquisition period, the instruction response timeout is determined to be triggered. When receiving multiple consecutive frames of data sent by the BMS device, if the time interval between two adjacent frames exceeds a preset interval threshold, the frame interval timeout is determined to be triggered. If no heartbeat message is received from the BMS device within multiple consecutive target acquisition cycles, the heartbeat loss timeout is determined to be triggered.
[0078] In some embodiments, the parsing anomaly conditions include at least one of the following: verification anomaly, device address mismatch, instruction type mismatch, data format anomaly, and data value anomaly.
[0079] In some embodiments, after determining whether the running data meets preset abnormal conditions, the method further includes: Determine the anomaly type of the runtime data; Based on the aforementioned exception type, a corresponding target status code is generated; The target status code is then written into the target data cache as the exception identifier.
[0080] In some embodiments, generating the corresponding target status code based on the exception type includes: If the exception type is instruction response timeout, then a first target status code is generated; If the anomaly type is frame interval timeout, then a second target status code is generated; If the anomaly type is heartbeat loss timeout, then a third target status code is generated; If the anomaly type is missing data, then a fourth target status code is generated; If the exception type is a parsing exception, then a fifth target status code is generated; If the exception type is a verification exception, then a sixth target status code is generated; If the anomaly type is device offline, then a seventh target status code is generated.
[0081] It will be understood by those skilled in the art that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program may be stored in a storage medium, which is a computer-readable storage medium. The computer program is executed by at least one processor in the computer system to implement the process steps of the embodiments of the above methods.
[0082] Therefore, embodiments of this application also provide a computer-readable storage medium storing a computer program thereon, wherein the computer program, when executed by a processor, implements the steps of the data processing method provided in any of the foregoing method embodiments, including: In response to the data recording start command, the current acquisition period is used as the target acquisition period; Generate a unified timestamp for the target acquisition period; Based on the unified timestamp, the operating data corresponding to each BMS device is read sequentially; Determine whether the running data meets preset abnormal conditions; If the running data does not meet the preset abnormal conditions, the running data is recorded in the target data cache of the BMS device; According to the unified timestamp, the data of all the BMS devices are recorded in a preset record file, and the next collection cycle of the target collection cycle is taken as the new target collection cycle, returning to the step of generating the unified timestamp of the target collection cycle.
[0083] In some embodiments, determining whether the running data meets preset abnormal conditions further includes: If the running data meets a preset abnormal condition, a preset abnormal identifier is written into the target data cache of the BMS device.
[0084] In some embodiments, generating a unified timestamp for the target acquisition period in response to a user's recording initiation command includes: Get the total number of BMS devices to be polled; If the total number of BMS devices to be polled is less than or equal to the first preset number threshold, then the start or midpoint of the target collection period is used as the unified timestamp. If the total number of BMS devices to be polled is greater than the first preset threshold, then the starting point of the target collection period is used as the unified timestamp.
[0085] In some embodiments, the preset abnormal conditions include communication timeout conditions, data loss conditions, and parsing abnormal conditions. Determining whether the running data meets the preset abnormal conditions includes: Determine whether the running data meets the communication timeout condition, the data missing condition, and the parsing anomaly condition; If the running data meets at least one of the communication timeout condition, the data missing condition, and the parsing anomaly condition, then the running data is determined to meet the preset anomaly condition.
[0086] In some embodiments, the communication timeout condition includes at least one of command response timeout, frame interval timeout, and heartbeat loss timeout, and the method includes: If no response message is received from the BMS device within the target acquisition period, the instruction response timeout is determined to be triggered. When receiving multiple consecutive frames of data sent by the BMS device, if the time interval between two adjacent frames exceeds a preset interval threshold, the frame interval timeout is determined to be triggered. If no heartbeat message is received from the BMS device within multiple consecutive target acquisition cycles, the heartbeat loss timeout is determined to be triggered.
[0087] In some embodiments, the parsing anomaly conditions include at least one of the following: verification anomaly, device address mismatch, instruction type mismatch, data format anomaly, and data value anomaly.
[0088] In some embodiments, after determining whether the running data meets preset abnormal conditions, the method further includes: Determine the anomaly type of the runtime data; Based on the aforementioned exception type, a corresponding target status code is generated; The target status code is then written into the target data cache as the exception identifier.
[0089] In some embodiments, generating the corresponding target status code based on the exception type includes: If the exception type is instruction response timeout, then a first target status code is generated; If the anomaly type is frame interval timeout, then a second target status code is generated; If the anomaly type is heartbeat loss timeout, then a third target status code is generated; If the anomaly type is missing data, then a fourth target status code is generated; If the exception type is a parsing exception, then a fifth target status code is generated; If the exception type is a verification exception, then a sixth target status code is generated; If the anomaly type is device offline, then a seventh target status code is generated.
[0090] The storage medium is a physical, non-transient storage medium, such as a USB flash drive, external hard drive, read-only memory (ROM), magnetic disk, or optical disk, or any other physical storage medium capable of storing program code. The computer-readable storage medium can be non-volatile or volatile.
[0091] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software 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 implementations should not be considered beyond the scope of this application.
[0092] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For example, the division of each unit is merely a logical functional division, and there may be other division methods in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.
[0093] The steps in the methods of this application embodiment can be adjusted, merged, or deleted according to actual needs. The units in the apparatus of this application embodiment can be merged, divided, or deleted according to actual needs. Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.
[0094] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a terminal, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.
[0095] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.
[0096] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Since these modifications and variations fall within the scope of the claims and their equivalents, this application also intends to include these modifications and variations.
[0097] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
Claims
1. A data processing method, characterized in that, The method, applicable to multiple BMS devices awaiting polling, includes: In response to the data recording start command, the current acquisition period is used as the target acquisition period; Generate a unified timestamp for the target acquisition period; Based on the unified timestamp, the operating data corresponding to each BMS device is read sequentially; Determine whether the running data meets preset abnormal conditions; If the running data does not meet the preset abnormal conditions, the running data is recorded in the target data cache of the BMS device; According to the unified timestamp, the data of all the BMS devices are recorded in a preset record file, and the next collection cycle of the target collection cycle is taken as the new target collection cycle, returning to the step of generating the unified timestamp of the target collection cycle.
2. The method according to claim 1, characterized in that, The step of determining whether the running data meets preset abnormal conditions further includes: If the running data meets a preset abnormal condition, a preset abnormal identifier is written into the target data cache of the BMS device.
3. The method according to claim 1, characterized in that, The unified timestamp for generating the target acquisition period includes: Obtain the total number of BMS devices to be polled and the estimated time for a single polling round; If the total number of BMS devices to be polled is less than or equal to the first preset number threshold, or the estimated time for a single polling round is less than or equal to the preset polling threshold, then the start or midpoint of the target collection cycle will be used as the unified timestamp. If the total number of BMS devices to be polled is greater than the first preset number threshold, or the estimated time for a single polling round is greater than the preset polling threshold, then the base time of the target collection cycle is used as a unified timestamp, and the actual reading time corresponding to each BMS device is recorded respectively.
4. The method according to claim 1, characterized in that, The preset abnormal conditions include communication timeout conditions, data missing conditions, and parsing abnormal conditions. Determining whether the running data meets the preset abnormal conditions includes: Determine whether the running data meets the communication timeout condition, the data missing condition, and the parsing anomaly condition; If the running data meets at least one of the communication timeout condition, the data missing condition, and the parsing anomaly condition, then the running data is determined to meet the preset anomaly condition.
5. The method according to claim 1, characterized in that, The communication timeout condition includes at least one of command response timeout, frame interval timeout, and heartbeat loss timeout; the method includes: If no response message is received from the BMS device within the target acquisition period, the instruction response timeout is determined to be triggered. When receiving multiple consecutive frames of data sent by the BMS device, if the time interval between two adjacent frames exceeds a preset interval threshold, the frame interval timeout is determined to be triggered. If no heartbeat message is received from the BMS device within multiple consecutive target acquisition cycles, the heartbeat loss timeout is determined to be triggered.
6. The method according to claim 1, characterized in that, The parsing anomaly conditions include at least one of the following: verification anomaly, device address mismatch, instruction type mismatch, data format anomaly, and data value anomaly.
7. The method according to claim 1, characterized in that, After determining whether the running data meets the preset abnormal conditions, the method further includes: Determine the anomaly type of the runtime data; Based on the aforementioned exception type, a corresponding target status code is generated; The target status code is then written into the target data cache as the exception identifier.
8. The method according to claim 7, characterized in that, The step of generating a corresponding target status code based on the exception type includes: If the exception type is instruction response timeout, then a first target status code is generated; If the anomaly type is frame interval timeout, then a second target status code is generated; If the anomaly type is heartbeat loss timeout, then a third target status code is generated; If the anomaly type is missing data, then a fourth target status code is generated; If the exception type is a parsing exception, then a fifth target status code is generated; If the exception type is a verification exception, then a sixth target status code is generated; If the anomaly type is device offline, then a seventh target status code is generated.
9. A computer device, characterized in that, The computer device includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the method as described in any one of claims 1-7.
10. A computer-readable storage medium, characterized in that, The storage medium stores a computer program that, when executed by a processor, can implement the method as described in any one of claims 1-7.