Vehicle battery fault operation data processing method and device and storage medium

Abstract

The invention discloses a vehicle battery fault operation data processing method and device and a storage medium. The method comprises the following steps: detecting that a vehicle battery has a first fault at the current moment; synchronizing the operation data, collected at the current moment and before the current moment, of the vehicle battery stored in the target data stack to a cache region in a battery management system; starting from the current moment, the operation data stored in the target data stack is continuously synchronized to the cache region until a preset stop condition is reached, and the preset stop condition is that the fault of the vehicle battery is not detected within the preset duration; and based on the operation data stored in the cache region when the preset stop condition is reached, obtaining a fault data recording packet of the vehicle battery, and synchronizing the fault data recording packet to the cloud server. The technical problems of incomplete operation data record and high resource occupation when the vehicle battery fails in the prior art are solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of electric vehicles, in particular to a vehicle battery fault operation data processing method and device and a storage medium. BACKGROUND

[0002] The monitoring and recording of the running state of the power battery of an electric vehicle can provide important basis when analyzing vehicle battery faults; currently, the recording and analysis of data when the battery fails mainly involves increasing data storage equipment at the vehicle end to record the running data of the battery, but this method requires high costs or uses the Unified Diagnostic Services (UDS) on-board diagnostic protocol to store simple fault data at the time of failure, which consumes the storage resources and running efficiency of the core processor of the battery management system. At the same time, due to the strong coupling of the voltage, temperature and current of the power battery, it is difficult to restore the vehicle operating environment before the fault occurs and locate the fault cause based on only one set of data, so this method does not effectively analyze the fault cause. In summary, the related art has the problems of incomplete recording of running data and high resource occupation when the vehicle battery fails.

[0003] At present, no effective solution has been proposed to solve the above problems. SUMMARY

[0004] The embodiments of the present application provide a vehicle battery fault operation data processing method and device and a storage medium to at least solve the technical problem of incomplete recording of running data and high resource occupation when the vehicle battery fails in the related art.

[0005] According to an aspect of an embodiment of the present application, a vehicle battery fault operation data processing method is provided, including: detecting that a vehicle battery has a first fault at a current time; synchronizing running data of the vehicle battery stored in a target data stack at the current time and before the current time to a cache area in a battery management system; continuously synchronizing the running data stored in the target data stack to the cache area from the current time until a preset stop condition is reached, wherein the preset stop condition is that no fault of the vehicle battery is detected within a predetermined time length; obtaining a fault data record package of the vehicle battery based on the running data stored in the cache area when the preset stop condition is reached, and synchronizing the fault data record package to a cloud server.

[0006] Optionally, the vehicle battery has multiple faults, and obtaining the fault data record package of the vehicle battery based on the running data stored in the cache area when the preset stop condition is reached includes: determining fault times corresponding to the multiple faults respectively; and determining fault data record packages corresponding to the multiple faults respectively from the running data stored in the cache area when the preset stop condition is reached based on the fault times corresponding to the multiple faults respectively.

[0007] Through the embodiment, the independent fault data record packages can be effectively extracted and formed from the cache area when handling multiple fault events, ensuring that each fault is fully supported by data for analysis. At the same time, through the cycle mechanism of the data stack and the accurate recording of the fault time, the optimization of resource use and the accurate capture of fault data are realized. The above method is not only suitable for the recording and analysis of single fault, but also can cope with the efficient management and identification of multiple faults in complex scenarios, and can provide a solid foundation for the fault diagnosis and prevention mechanism of the battery.

[0008] Optionally, based on the fault time corresponding to the multiple faults, the fault data record package corresponding to the multiple faults is determined from the running data stored in the cache area when the preset stop condition is reached, including: determining the first running data collected for a predetermined time before the fault occurrence time of any fault and the second running data collected for a predetermined time after the fault occurrence time of any fault from the running data stored in the cache area when the preset stop condition is reached; obtaining the fault data record package of any fault based on the first running data and the second running data; and obtaining the fault data record package corresponding to the multiple faults in the manner of obtaining the fault data record package of any fault.

[0009] Through the embodiment, it can be ensured that each fault data record package contains both the real-time data at the time of fault occurrence and sufficient pre and post running data for comprehensive evaluation of the fault scenario. In addition, through such a mechanism, it can avoid re-allocating and occupying additional storage resources at each fault occurrence, thereby optimizing the use efficiency of resources.

[0010] Optionally, the fault data record package is synchronized to the cloud server, including: sending the fault time corresponding to the multiple faults and the fault data record package to the cloud server for storage.

[0011] Through the embodiment, the accuracy and integrity of data transmission between the battery management system and the cloud server in the multi-fault situation. The additional transmission of fault time information can ensure the correct filing of data, and the sending of independent fault data record packages can guarantee the comprehensiveness of data required for each fault analysis. This mechanism not only optimizes the data transmission process, but also improves the efficiency and quality of fault data analysis on the cloud server.

[0012] Optionally, before synchronizing the running data of the vehicle battery stored in the target data stack at the current time and collected before the current time to the cache area in the battery management system, the method further comprises: detecting whether the number of data currently stored in the target data stack reaches a predetermined number; in the case that the number of data stored in the target data stack reaches the predetermined number, removing the running data with the earliest collection time from the target data stack among the running data stored in the target data stack, and storing the running data collected at the current time in the stack head position of the target data stack.

[0013] Through the cyclic stack and data updating mechanism of the embodiment, even in the case of limited storage resources, the system can continuously and efficiently record and update the battery running data, providing a solid foundation for fault detection and data analysis. At the same time, this mechanism can also optimize the running efficiency of the BMS, avoid unnecessary waste of storage resources, and improve the stability and reliability of the overall system during vehicle battery fault detection.

[0014] Optionally, the running data stored in the target data stack is continuously synchronized to the cache area from the current time until a preset stop condition is reached, including: continuously synchronizing the running data stored in the target data stack to the cache area from the current time, and controlling the timer to count down for a predetermined length of time from the current time; in the case that the next fault of the vehicle battery is detected, recording the fault occurrence time of the next fault, and resetting the timer, controlling the reset timer to count down for a predetermined length of time from the fault occurrence time of the next fault; repeat the above operation until the corresponding reset timer counts down to 0 when the vehicle battery last appeared a fault, and determine that the preset stop condition is reached.

[0015] Through the dynamic resetting of the timer and the setting of the stop condition of the embodiment, the duration of data recording can be automatically adjusted to ensure that the data within a certain time before and after the fault is completely preserved without manual intervention. This automated and intelligent data recording mechanism can significantly improve the accuracy and integrity of the fault data, while also effectively managing the storage resources in the vehicle-mounted system to prevent resource overuse from causing system performance degradation. In this way, the system can better adapt to rapidly changing fault scenarios, providing strong support for battery health management and fault prevention.

[0016] Optionally, synchronizing the fault data record package to the cloud server comprises: sending the fault data record package to the vehicle networking control unit through the CAN bus, and sending the fault data record to the cloud server for storage through the vehicle networking control unit.

[0017] Through the embodiment, the generated fault data record package is sent to the Tbox through the CAN bus, and then uploaded to the cloud server by the Tbox, so that seamless transmission of fault data from the vehicle end to the cloud end is ensured, and an efficient, safe and intelligent fault data processing chain is built, which can provide a solid technical foundation for fault diagnosis, prediction and prevention of the electric vehicle battery.

[0018] According to another aspect of the embodiment of the present application, a vehicle battery fault operation data processing device is also provided, comprising: a detection module configured to detect that a first fault of a vehicle battery occurs at a current time; a first data synchronization module configured to synchronize operation data of the vehicle battery stored in a target data stack at the current time and before the current time to a cache area in a battery management system; a second data synchronization module configured to continuously synchronize the operation data stored in the target data stack to the cache area from the current time until a preset stop condition is reached, wherein the preset stop condition is that no fault of the vehicle battery is detected within a predetermined time length; and a data package acquisition module configured to obtain a fault data record package of the vehicle battery based on the operation data stored in the cache area when the preset stop condition is reached, and synchronize the fault data record package to a cloud server.

[0019] According to another aspect of the embodiment of the present application, a non-volatile storage medium is also provided, which stores a plurality of instructions, and the instructions are adapted to be loaded and executed by a processor to implement any one of the vehicle battery fault operation data processing methods.

[0020] According to another aspect of the embodiment of the present application, an electronic device is also provided, which comprises one or more processors and a memory, and the memory is configured to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement any one of the vehicle battery fault operation data processing methods.

[0021] According to another aspect of the embodiment of the present application, a computer program product is also provided, which comprises a computer program, and the computer program is executed by a processor to implement the steps of any one of the vehicle battery fault operation data processing methods.

[0022] In the embodiment of the present application, by detecting that the vehicle battery has a first failure at the current time; the running data of the vehicle battery stored in the target data stack at the current time and before the current time is synchronized to the cache area in the battery management system; from the current time, the running data stored in the target data stack is continuously synchronized to the cache area until the preset stop condition is reached, wherein the preset stop condition is that no failure of the vehicle battery is detected within a predetermined time period; based on the running data stored in the cache area when the preset stop condition is reached, the failure data record package of the vehicle battery is obtained, and the failure data record package is synchronized to the cloud server, which achieves the purpose of efficiently and accurately recording and analyzing the running state of the battery when multiple failures occur continuously without increasing hardware cost, thereby achieving the technical effects of improving the accuracy of vehicle battery failure diagnosis and the utilization efficiency of vehicle storage resources, and solving the technical problems of incomplete recording of running data and high resource occupation when the vehicle battery fails in the related art. BRIEF DESCRIPTION OF DRAWINGS

[0023] The accompanying drawings described herein are used to provide a further understanding of the present application, form a part of the present application, the illustrative embodiments of the present application and the description thereof are used to explain the present application, and do not constitute an improper limitation on the present application. In the drawings:

[0024] Figure 1 is a flow chart of a vehicle battery failure running data processing method according to an embodiment of the present application;

[0025] Figure 2 is an optional vehicle battery failure running data processing flow chart according to an embodiment of the present application;

[0026] Figure 3 is a schematic diagram of a vehicle battery failure running data processing device according to an embodiment of the present application. DETAILED DESCRIPTION

[0027] In order 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 described clearly and completely below with reference to the accompanying drawings of the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor should be within the scope of protection of the present application.

[0028] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and in the above drawings are used to distinguish similar objects, and do not necessarily have to be used to describe a specific order or sequence. It should be understood that the data thus used can be interchanged under appropriate circumstances, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product or device that includes a series of steps or units does not have to be limited to only those steps or units clearly listed, but can include other steps or units not clearly listed or inherent to these processes, methods, products or devices.

[0029] First, for the convenience of understanding the embodiments of the present application, the following will explain some terms or nouns involved in the present application:

[0030] The vehicle information control box, also known as "Internet of Vehicles control unit", is a key hardware device in a vehicle for connecting the vehicle system with the Internet, which can support remote communication and data exchange, so that the vehicle can communicate with the cloud server or other external devices, and realize remote monitoring, diagnosis and other functions of the vehicle.

[0031] According to the embodiments of the present application, a method embodiment for processing vehicle battery fault operation data is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although the logical order is shown in the flowchart, in some cases, the steps shown or described herein can be executed in a different order.

[0032] Figure 1 is a flowchart of the vehicle battery fault operation data processing method according to the embodiments of the present application, as Figure 1 shown, the method comprises the following steps:

[0033] Step S102, detecting that the vehicle battery has a first fault at the current time;

[0034] Optionally, the execution subject of steps S102 to S108 can be the battery management system (Battery Management System, BMS) of the vehicle. The running state of the vehicle battery is monitored in real time by the BMS system, and the vehicle fault is recorded. In the case of detecting that the vehicle battery has a first fault at the current time, the fault time of the first fault is recorded, and the running data of the vehicle battery collected at that time. The running data can include but is not limited to the key parameters of the battery voltage, current, temperature, etc.

[0035] S104, synchronizing the running data of the vehicle battery stored in the target data stack at the current time and before the current time to the cache area in the battery management system;

[0036] Optionally, the target data stack refers to a specially designed data structure for storing the running data of the vehicle battery in real time and efficiently. The target data stack is a data stack for rolling storage of battery running data, which can be a last in first out (LIFO) data structure, in which the latest data is added to the top of the stack (i.e. the front end of the data stack), and the oldest data is stored at the bottom of the stack (i.e. the rear end of the data stack). The design purpose of the target data stack is to continuously update and save the recent battery running state data, such as the voltage, current, temperature and other key parameters of the battery, in a limited storage space. The data is recorded once every certain time (e.g. every 10 seconds), and the depth of the data stack is kept within a predetermined range (e.g. 300 records).

[0037] In an optional embodiment, before synchronizing the running data of the vehicle battery stored in the target data stack at the current time and before the current time to the cache area in the battery management system, the method further comprises: detecting whether the number of data currently stored in the target data stack reaches a predetermined number; in the case that the number of data stored in the target data stack reaches the predetermined number, removing the running data with the earliest collection time from the target data stack among the running data stored in the target data stack, and storing the running data collected at the current time in the head position of the target data stack.

[0038] Optionally, before synchronizing the running data in the target data stack to the cache area of the battery management system (BMS), it is detected whether the number of data currently stored in the target data stack reaches a predetermined maximum number. The presence of this detection mechanism is to ensure that the data stack can continue to update in a limited storage space, and will not exceed the storage limit because the number of data is too much. If the number of data stored in the target data stack does indeed reach the preset maximum number (such as 300), a circular stack compression method is adopted for data update. Specifically, the running data collected at the earliest time in the target data stack (i.e. the data at the tail position of the stack) is removed to release storage space. After removing the earliest data, the latest running data collected at the current time is stored at the head position of the data stack, i.e. the front end of the data stack. Such a design can ensure that the data stack always contains the battery running data within the latest time window, and even in the case of limited storage space, the data can be continuously updated to reflect the latest status of the battery. Through the circular data update mechanism, even in the case where the number of data reaches the maximum number, the target data stack can continuously record and update the running data of the vehicle battery, ensuring the real-time and effectiveness of the data, especially in fault detection and analysis, this mechanism can ensure that the system can respond quickly and capture the running state before and after the fault occurs, providing key data for fault diagnosis.

[0039] Through the circular stack compression and data update mechanism of the present embodiment, even in the case of limited storage resources, the battery management system can continuously and efficiently record and update the battery running data, providing a solid foundation for fault detection and data analysis. At the same time, this mechanism can also optimize the running efficiency of the BMS, avoid unnecessary waste of storage resources, and improve the stability and reliability of the overall system during vehicle battery fault detection.

[0040] Step S106, from the current time, continuously synchronize the running data stored in the target data stack to the cache area until a predetermined stop condition is met, wherein the predetermined stop condition is that no fault of the vehicle battery is detected within a predetermined time period;

[0041] Optionally, when it is detected that the vehicle battery has occurred a first fault at a certain current time, the battery running data in the target data stack since the current time and a period of time before the current time are captured and synchronized to the cache area of the battery management system (BMS); from the moment the fault is detected, the newly generated battery running data in the target data stack is continuously synchronized to the cache area, and this process will continue to capture the changes in the battery running state after the fault occurs; the above continuous data synchronization process will continue until a predetermined stop condition is met, i.e. no fault of the vehicle battery is detected again within a predetermined time period (e.g. 5 minutes). The selection of this time period can ensure that the running data before and after the fault is recorded completely, providing sufficient information for subsequent fault analysis.

[0042] By the above method, on the one hand, it can ensure that the key battery operation data can be quickly captured and recorded when the fault occurs, and on the other hand, by presetting the stop condition, the use of resources is limited, and the continuous occupation of the storage and processing resources of the BMS in the normal running state is avoided. In this way, fault data can be efficiently and accurately collected and processed without affecting the normal operation of the vehicle, thereby providing strong support for battery health monitoring and fault diagnosis.

[0043] In an optional embodiment, the running data stored in the target data stack is continuously synchronized to the cache area from the current time until the preset stop condition is reached, including: continuously synchronizing the running data stored in the target data stack to the cache area from the current time, and controlling the timer to count down from the current time for a predetermined time length; in the case where the next fault of the vehicle battery is detected, the fault occurrence time of the next fault is recorded, and the timer is reset for timing, and the reset timer is controlled to count down from the fault occurrence time of the next fault for a predetermined time length; repeat the above operation until the vehicle battery appears the last time, in the case where the corresponding reset timer counts down to 0, it is determined that the preset stop condition is reached.

[0044] Optionally, when the vehicle battery is first detected to have a fault, the battery operation data stored in the target data stack is synchronized to the cache area. At the same time, a timer is started by the battery management system, which counts down for a predetermined time length (such as 5 minutes) from the fault occurrence time. This operation can ensure that the operation data within a period of time before and after the fault occurs is recorded, providing a continuous data stream for subsequent fault analysis. Within the next predetermined time length, if the system detects that the battery has a fault again, it will record the fault occurrence time of this fault, and reset the previous timer for timing, that is, the timer will start counting down from the new fault occurrence time for 5 minutes. This reset mechanism can ensure that even if multiple faults occur continuously within a short period of time, the operation data before and after the fault can be continuously recorded and updated, which can provide a sufficient time window for analyzing the cause of each fault. Repeat the above process, that is, each time a new fault occurs, record the fault time, reset the timer, and continue to synchronize the running data in the data stack to the cache area. This process will continue until after the last fault, the timer counts down to 0, at which time no new fault is detected, and it is determined that the preset stop condition is reached, that is, no new fault is detected within 5 minutes. After reaching this stop condition, the synchronization of data in the data stack to the cache area is stopped, which means that the data recording before and after the fault has been completed, and the next step will enter the generation and uploading stage of the data packet.

[0045] Through the dynamic resetting of the timer and the setting of the stopping condition in this embodiment, the duration of data recording can be automatically adjusted to ensure that a certain period of data before and after the fault is completely preserved without manual intervention. This automated and intelligent data recording mechanism can significantly improve the accuracy and completeness of fault data, while also effectively managing storage resources in the vehicle system to prevent excessive resource occupation and resulting system performance degradation. In this way, the system can better adapt to rapidly changing fault scenarios and provide strong support for battery health management and fault prevention.

[0046] In step S108, based on the running data stored in the cache area when the preset stopping condition is reached, a fault data record package of the vehicle battery is obtained, and the fault data record package is synchronized to a cloud server.

[0047] Optionally, once the preset stopping condition is met, a fault data record package of the vehicle battery is generated based on all the running data stored in the cache area. The generated fault data record package will then be uploaded to the cloud server for storage. The cloud server can provide greater data storage capacity and more stable network connection than the vehicle system to ensure the safe storage and accessibility of fault data at any time.

[0048] In an optional embodiment, the vehicle battery experiences multiple faults. Based on the running data stored in the cache area when the preset stopping condition is reached, a fault data record package of the vehicle battery is obtained, including: determining the fault time corresponding to each of the multiple faults; and based on the fault time corresponding to each of the multiple faults, determining the fault data record package corresponding to each of the multiple faults from the running data stored in the cache area when the preset stopping condition is reached.

[0049] Optionally, during vehicle operation, if the battery management system detects multiple faults, each fault occurrence is accurately recorded, including the specific occurrence time of the fault. These time stamps are crucial for the subsequent generation of fault data packages. They serve as key reference points to demarcate the starting points of the time periods before and after the fault. When the vehicle battery is detected to have experienced a fault for the first time, the running data of the target data stack is started to be synchronized to the cache area and continuously recorded until the preset stopping condition (usually no new fault detected within 5 minutes) is met. At this time, the cache area stores a large amount of running data, covering the data from the last fault occurrence to the satisfaction of the stopping condition. Based on the previously determined fault time, the relevant data is extracted and organized from the cache area to form an independent fault data record package.

[0050] In the above embodiments, by effectively extracting and forming independent fault data record packages from the cache area when handling multiple fault events, it is ensured that each fault is fully supported by data for analysis, and at the same time, through the circular mechanism of the data stack and the accurate recording of the fault time, the optimization of resource use and the accurate capture of fault data are realized. The above method not only applies to the recording and analysis of single fault, but also can cope with the efficient management and identification of multiple faults in complex scenarios, and can also provide a solid foundation for the fault diagnosis and prevention mechanism of the battery.

[0051] In an optional embodiment, based on the fault time corresponding to each of the multiple faults, the fault data record package corresponding to each of the multiple faults is determined from the running data stored in the cache area when the preset stop condition is reached, including: determining the first running data collected for a predetermined time before the fault occurrence time of any fault and the second running data collected for a predetermined time after the fault occurrence time of any fault from the running data stored in the cache area when the preset stop condition is reached; obtaining the fault data record package of any fault based on the first running data and the second running data; and obtaining the fault data record package corresponding to each of the multiple faults in the manner of obtaining the fault data record package of any fault.

[0052] Optionally, for any fault, the specific time of its fault occurrence is determined. This time is the basis for subsequent data screening and fault package generation, ensuring the accuracy and pertinence of the running data. After determining the fault occurrence time, the running data within a predetermined time (for example, 5 minutes) before the time is extracted from the cache area, and this part of data is referred to as the first running data. These data are background information before the fault occurs; similarly, the running data within a predetermined time (also 5 minutes) after the fault occurrence time is collected, and this part of data is referred to as the second running data. The second running data can provide observation of the immediate response and subsequent impact after the fault occurs, which helps to analyze the direct cause of the fault and possible chain reaction. The first running data and the second running data are combined to generate a fault data record package containing the running data 5 minutes before and after the fault occurs, thereby ensuring that each fault has a complete data window for detailed analysis of the fault cause and influencing factors. This processing process involves accurate screening and reorganization of data in the cache area, which can ensure that each fault data record package contains not only the immediate data at the time of fault occurrence, but also sufficient pre- and post-period running data for comprehensive evaluation of the fault scenario. In addition, through such a mechanism, it is possible to avoid the reallocation and occupation of additional storage resources at each fault occurrence, thereby optimizing the use efficiency of resources.

[0053] In an optional embodiment, synchronizing the fault data record package to the cloud server comprises: sending the fault time corresponding to each fault and the fault data record package to the cloud server for storage respectively.

[0054] Optionally, after the battery management system generates independent fault data record packages for multiple faults, not only the data packages themselves are sent to the cloud server, but also their corresponding fault time is sent together. This means that each fault data record package carries information about the specific time of the fault occurrence, which is very important for data analysis on the cloud server, as it provides a key basis for the time positioning of the data package. Combining each independent fault data record package with its corresponding fault time information forms a complete data transmission unit. Subsequently, these data transmission units are sent to the cloud server one by one. The sending process can ensure that the data record package of each fault is consistent with the actual time of its occurrence. After receiving the fault data record package and its corresponding fault time information from the battery management system, the cloud server will store and manage it. The large capacity storage capability and data management function of the cloud server enable it to safely and long-term save these data, at the same time, the cloud server can also conduct advanced data analysis to help identify fault patterns, predict potential risks and improve battery design. In this way, the cloud server can establish a detailed fault data archive, each archive entry contains fault data record package and its corresponding fault time information. This is very useful for historical tracking of faults, trend analysis and future preventive measures, and can also provide valuable debugging and optimization basis for engineers.

[0055] Through this embodiment, the accuracy and integrity of data transmission between the battery management system and the cloud server in the multi-fault situation. The additional transmission of fault time information can ensure the correct filing of data, while the sending of independent fault data record packages can guarantee the comprehensiveness of data required for each fault analysis. This mechanism not only optimizes the data transmission process, but also improves the efficiency and quality of fault data analysis on the cloud server.

[0056] In an optional embodiment, synchronizing the fault data record package to the cloud server comprises: sending the fault data record package to the vehicle Internet control unit through the Controller Area Network (CAN) bus, and sending the fault data record to the cloud server through the vehicle Internet control unit for storage.

[0057] Optionally, in the battery management system (BMS), once the fault data record package for one or more faults is generated, this data package is sent to the Tbox through the CAN bus of the in-vehicle network. The CAN bus can ensure efficient and stable transmission of data packages between different vehicle electronic control units, and can ensure data integrity and real-time performance even in complex in-vehicle environments. After receiving the fault data record package sent by the BMS through the CAN bus, the Tbox undertakes the task of uploading these data packages to the cloud server. As a communication gateway between the vehicle and the Internet, the Tbox has the ability to connect with external networks (such as 4G / 5G cellular networks, Wi-Fi, etc.), and can efficiently transmit vehicle data to the cloud (i.e., the cloud server). In this process, the Tbox not only handles data transmission, but also performs certain data preprocessing, such as data package format conversion or encryption, to ensure data security and compliance during transmission.

[0058] Through this embodiment, i.e., generating fault data record packages from the BMS, sending them to the Tbox through the CAN bus, and then uploading them to the cloud server by the Tbox, seamless transmission of fault data from the vehicle end to the cloud end can be ensured. This process not only reflects the importance of vehicle-cloud integration in fault data recording and analysis, but also highlights the key role of the Tbox as a vehicle data transmission gateway and the central position of the cloud server in data storage and analysis. The design of the entire mechanism aims to build an efficient, secure, and intelligent fault data processing chain, which can provide a solid technical foundation for fault diagnosis, prediction, and prevention of electric vehicle batteries.

[0059] As an optional embodiment, after the fault data record package uploaded to the cloud server is successfully stored, the server will feedback a storage completion flag information. This feedback information will be transmitted back to the battery management system through the Tbox, and the system will clear the fault data in the cache area after receiving the confirmation of data storage completion, in order to release the storage resources. At the same time, this mechanism can also ensure the security of data transmission, i.e., only when the data package is confirmed to be successfully stored, the original vehicle end cache data will be cleared, thereby avoiding the risk of data loss.

[0060] Through the above steps S102 to S108, the purpose of efficiently and accurately recording and analyzing the battery running state when multiple faults occur continuously without increasing hardware costs can be achieved, thereby achieving the technical effects of improving the accuracy of vehicle battery fault diagnosis and the resource utilization efficiency of the system, and thereby solving the technical problems of incomplete recording of running data and high resource occupation when the vehicle battery fails in related technologies.

[0061] Based on the above embodiments and optional embodiments, this application proposes an optional implementation method. Figure 2 This is an optional vehicle battery fault operation data processing flowchart according to an embodiment of this application, such as... Figure 2 As shown, this method proposes a way to store battery operating data during continuous high-frequency battery faults at multiple consecutive fault occurrence times, while reducing the resource consumption of the battery management system's own chip. This embodiment uses an iterative stacking method to continuously record battery operating data. When the first fault occurs, the corresponding battery operating data stack (i.e., the target data stack) is stored in the memory cache of the battery management system's own chip, along with the time of the fault occurrence. This process is repeated for multiple fault occurrence times. If no fault information is received within 5 consecutive minutes, the continuous storage of the stacked data into the cache is stopped. Simultaneously, the data in the cache and the time information corresponding to each fault occurrence are transmitted to the vehicle's T-box via CAN communication, and then the data is transmitted to cloud storage via the T-box. Specifically, this includes:

[0062] S1. Establish a rolling storage data stack. Record the real-time operating data of the vehicle battery, including battery temperature, voltage, current, etc., every 10 seconds. Store all the data recorded in one time into the rolling storage data stack. Set the depth of the data stack to 300. When the data is recorded 301 times, discard the first recorded data, push the data stack once, and release the head position of the stack to record 301 times. In this way, the most recent data is placed at the head position of the stack, and the earliest recorded data is placed at the tail position of the stack.

[0063] S2, establish a fault record storage buffer. When a fault occurs, copy the data from the rolling data stack to the buffer. Simultaneously, record the data at the head of the stack every 10 seconds in the buffer. Set a timer countdown timer T = 5 minutes, which decrements every 10 seconds. When the timer counts down to 0, the buffer stops recording data. If a fault occurs during the counter's decrementing time, the counter resets to T = 5 minutes.

[0064] S3, record the time of the fault occurrence, and disassemble and recombine the data in the buffer according to the time of the fault occurrence, 5 minutes before the fault, and 5 minutes after the fault occurrence. Combine the running data before and after each fault occurrence into a fault data record package corresponding to that fault; for example... Figure 2 As shown, in the case that the vehicle battery fails a total of n times, the fault data recording package corresponding to each fault includes the vehicle battery's operating data for 5 minutes before and after the corresponding fault occurred.

[0065] S4, the data of the fault data record data packet is sent to the Tbox through the CAN network cycle, when the Tbox receives the fault data record packet sent by the CAN network cycle, the fault data record packet is sent to the cloud (i.e. the cloud server), when the cloud stores the fault data, the acceptance storage data completion flag is fed back to the battery management system through the Tbox; after the battery management system accepts the data storage completion flag, the running data of the vehicle battery stored in the buffer area is emptied, and the cycle CAN network sending of the fault data is stopped.

[0066] In the embodiment, the running data of the battery is recorded in real time and high frequency by using the loop stack method of the rolling data stack, and the data of the latest state of the battery is recorded at all times; the depth of the cycle data stack is set to 300, and the data is recorded once every 10 seconds, so that the method can meet the high frequency recording of the battery data for 5 minutes; the data storage buffer area is designed for the common data buffer at the moment of continuous fault occurrence, so that the storage resources for data storage of a single fault can be significantly reduced; the moment of fault occurrence is recorded, the data packet of 5 minutes before and after the moment of fault occurrence is traced back in the storage buffer area, and a single fault data packet is established; the data packet is transmitted to the Tbox through the CAN communication protocol in real time and cycle; through the cloud data storage feedback mechanism, the data in the buffer area is cleared in time after storage, and the buffer storage resources are released.

[0067] It should be noted that in the embodiment, the latest data of the battery running is recorded in real time by using the loop stack method, which can avoid the problem of loss of real-time running data caused by network communication exception compared with real-time transmission to the cloud storage; the data of the cycle data stack is recorded by designing the common buffer storage area, the data in the storage buffer area is split into corresponding data packets of the occurrence time of each fault, and the method can reduce the chip storage area resources by N-1 times compared with the establishment of a buffer area for each fault; through the establishment of the network storage feedback mechanism, the data in the buffer area is transmitted to the cloud in time, which ensures the safety of the data and the release of the resources.

[0068] In the embodiment, a vehicle battery fault running data processing device is also provided, which is used to realize the above-mentioned embodiments and preferred embodiments, and will not be described again. As used below, the term "module" "device" can be a combination of software and / or hardware that realizes a predetermined function. Although the device described in the following embodiments is preferably realized in software, hardware, or a combination of software and hardware is also possible and is contemplated.

[0069] According to the embodiment of the present application, a device embodiment for implementing the vehicle battery fault operation data processing method is also provided, Figure 3 is a structural schematic diagram of a vehicle battery fault operation data processing device according to the embodiment of the present application, as Figure 3 shown, the vehicle battery fault operation data processing device comprises a detection module 300, a first data synchronization module 302, a second data synchronization module 304, and a data packet acquisition module 306, wherein:

[0070] The detection module 300 is configured to detect that the vehicle battery has a first fault at a current time;

[0071] The first data synchronization module 302 is connected to the detection module 300 and is configured to synchronize the operation data of the vehicle battery stored in the target data stack at the current time and before the current time to a cache area in the battery management system;

[0072] The second data synchronization module 304 is connected to the first data synchronization module 302 and is configured to continuously synchronize the operation data stored in the target data stack to the cache area from the current time until a preset stop condition is reached, wherein the preset stop condition is that no fault of the vehicle battery is detected within a predetermined time length;

[0073] The data packet acquisition module 306 is connected to the second data synchronization module 304 and is configured to obtain a fault data record packet of the vehicle battery based on the operation data stored in the cache area when the preset stop condition is reached, and synchronize the fault data record packet to a cloud server.

[0074] In the embodiment of the present application, by setting the detection module 300 for detecting that the vehicle battery has a first failure at the current time; the first data synchronization module 302 connected to the detection module 300, for synchronizing the running data of the vehicle battery stored in the target data stack at the current time and before the current time to the cache area in the battery management system; the second data synchronization module 304 connected to the first data synchronization module 302, for continuously synchronizing the running data stored in the target data stack to the cache area from the current time, until the preset stop condition is reached, wherein the preset stop condition is that no failure of the vehicle battery is detected within a predetermined time length; the data packet acquisition module 306 connected to the second data synchronization module 304, for obtaining the failure data record packet of the vehicle battery based on the running data stored in the cache area when the preset stop condition is reached, and synchronizing the failure data record packet to the cloud server, which achieves the purpose of efficiently and accurately recording and analyzing the battery running state when multiple failures occur continuously without increasing hardware costs, thereby achieving the technical effects of improving the accuracy of vehicle battery failure diagnosis and the resource utilization efficiency of the system, and further solving the technical problems of incomplete recording of running data and high resource occupation when the vehicle battery fails in the related art.

[0075] It should be noted that each of the above modules can be implemented by software or hardware. For example, for the latter, each of the above modules can be located in the same processor, or in different processors in any combination.

[0076] It should be noted that the detection module 300, the first data synchronization module 302, the second data synchronization module 304, and the data packet acquisition module 306 correspond to steps S102 to S108 in the embodiment, and the above modules have the same instances and application scenarios as the corresponding steps, but are not limited to the contents disclosed in the above embodiment. It should be noted that the above modules can run in a computer terminal as part of the device.

[0077] It should be noted that the optional or preferred embodiments of the present embodiment can refer to the related description in the embodiment, which will not be repeated here.

[0078] The vehicle battery failure running data processing device described above can also include a processor and a memory, and the detection module 300, the first data synchronization module 302, the second data synchronization module 304, and the data packet acquisition module 306 are stored in the memory as program modules, and the processor executes the above program modules stored in the memory to realize the corresponding functions.

[0079] The processor comprises a core, and the core is used to call corresponding program modules in the memory. The core can be one or more. The memory can comprise a non-permanent memory in a computer readable medium, a random access memory (RAM) and / or a non-volatile memory such as a read-only memory (ROM) or a flash memory (flash RAM), and the memory comprises at least one memory chip.

[0080] According to the embodiment of the present application, an embodiment of a non-volatile storage medium is also provided. Optionally, in the embodiment, the non-volatile storage medium comprises a stored program, wherein the program is used to control a device where the non-volatile storage medium is located to execute any of the vehicle battery fault operation data processing methods when the program is running.

[0081] Optionally, in the embodiment, the non-volatile storage medium can be located in any of computer terminals in a computer terminal group in a computer network, or in any of mobile terminals in a mobile terminal group, and the non-volatile storage medium comprises a stored program.

[0082] Optionally, when the program is running, the non-volatile storage medium is used to control a device where the non-volatile storage medium is located to perform the following functions: detecting that a vehicle battery has a first fault at a current time; synchronizing operation data of the vehicle battery stored in a target data stack at the current time and before the current time to a cache area in a battery management system; continuously synchronizing the operation data stored in the target data stack to the cache area since the current time until a preset stop condition is reached, wherein the preset stop condition is that no fault of the vehicle battery is detected within a predetermined time length; obtaining a fault data record package of the vehicle battery based on the operation data stored in the cache area when the preset stop condition is reached, and synchronizing the fault data record package to a cloud server.

[0083] According to the embodiment of the present application, an embodiment of a processor is also provided. Optionally, in the embodiment, the processor is used to run a program, wherein the program is used to execute any of the vehicle battery fault operation data processing methods when the program is running.

[0084] According to the embodiment of the present application, an embodiment of a computer program product is also provided, which is adapted to execute a program that is initialized with any of the vehicle battery fault operation data processing method steps when the computer program product is executed on a data processing device.

[0085] Optionally, the computer program product described above, when executed on the data processing device, is adapted to execute the program of the following method steps: detecting that the vehicle battery has a first fault at a current time; synchronizing running data of the vehicle battery stored in a target data stack at the current time and before the current time to a cache area in the battery management system; continuously synchronizing the running data stored in the target data stack to the cache area from the current time until a preset stop condition is reached, wherein the preset stop condition is that no fault of the vehicle battery is detected within a predetermined time length; obtaining a fault data record package of the vehicle battery based on the running data stored in the cache area when the preset stop condition is reached, and synchronizing the fault data record package to a cloud server.

[0086] The electronic device provided in the embodiments of the present application includes a processor, a memory, and a program stored on the memory and executable on the processor. When the processor executes the program, the following steps are implemented: detecting that the vehicle battery has a first fault at a current time; synchronizing running data of the vehicle battery stored in a target data stack at the current time and before the current time to a cache area in the battery management system; continuously synchronizing the running data stored in the target data stack to the cache area from the current time until a preset stop condition is reached, wherein the preset stop condition is that no fault of the vehicle battery is detected within a predetermined time length; obtaining a fault data record package of the vehicle battery based on the running data stored in the cache area when the preset stop condition is reached, and synchronizing the fault data record package to a cloud server.

[0087] The sequence of the embodiments described above is only for description, and does not represent the advantages or disadvantages of the embodiments.

[0088] In the above-described embodiments of the present application, the description of each embodiment has its own focus, and the parts not described in detail in a certain embodiment can be referred to the relevant description of other embodiments.

[0089] In the several embodiments provided in the present application, it should be understood that the disclosed technology can be implemented in other ways. Of course, the device embodiment described above is only schematic. For example, the division of the above modules can be a logical function division, and there can be another division manner in actual implementation, for example, a plurality of modules or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the shown or discussed mutual elements can be through some interface, indirect coupling or communication connection between modules or components, which can be electrical or other forms.

[0090] The modules described above as separate components may or may not be physically separate, and the components shown as modules may or may not be physical modules, i.e., may be located in one place, or may be distributed to multiple modules. Part or all of the modules can be selected as needed to achieve the purpose of the embodiment.

[0091] In addition, the functional modules in each embodiment of the present application can be integrated in one processing module, or each module can exist physically alone, or two or more modules can be integrated in one module. The integrated module can be realized in the form of hardware or in the form of a software functional module.

[0092] The integrated module, if realized in the form of a software functional module and sold or used as an independent product, can be stored in a computer readable nonvolatile storage medium. Based on this understanding, the technical solutions of the present application, essentially or the part that contributes to the prior art, or all or part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a nonvolatile storage medium, including a number of instructions to make a computer device (which can be a personal computer, a server or a network device, etc.) execute all or part of the steps of the embodiments of the present application. The aforementioned nonvolatile storage medium includes: a U disk, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), a mobile hard disk, a magnetic disk or an optical disk, and various media that can store program codes.

[0093] The above is only the preferred embodiment of the present application, and it should be pointed out that for those skilled in the art, without departing from the principles of the present application, a number of improvements and refinements can be made, which should also be considered as the protection scope of the present application.

Claims

1. A vehicle battery malfunction operation data processing method characterized by, The method comprises: detecting that a vehicle battery has a first fault at a current time; synchronizing running data of the vehicle battery stored in a target data stack at the current time and before the current time to a cache area in a battery management system; continuously synchronizing the running data stored in the target data stack to the cache area from the current time until a preset stop condition is reached, wherein the preset stop condition is that no fault of the vehicle battery is detected within a predetermined time length; based on the running data stored in the cache area when the preset stop condition is reached, obtaining a fault data record package of the vehicle battery, and synchronizing the fault data record package to a cloud server.

2. The method of claim 1, wherein, The vehicle battery has multiple faults, and the obtaining of the fault data record package of the vehicle battery based on the running data stored in the cache area when the preset stop condition is reached comprises: determining fault times corresponding to the multiple faults respectively; based on the fault times corresponding to the multiple faults respectively, determining fault data record packages corresponding to the multiple faults respectively from the running data stored in the cache area when the preset stop condition is reached.

3. The method of claim 2, wherein, The obtaining of the fault data record package of any fault comprises: determining first running data collected within the predetermined time length before a fault occurrence time of the any fault and second running data collected within the predetermined time length after the fault occurrence time of the any fault from the running data stored in the cache area when the preset stop condition is reached; based on the first running data and the second running data, obtaining the fault data record package of the any fault; the obtaining of the fault data record packages corresponding to the multiple faults respectively is performed in the same manner as the obtaining of the fault data record package of the any fault. The synchronizing of the fault data record package to the cloud server comprises:

4. The method of claim 2, wherein, sending the fault times corresponding to the multiple faults and the fault data record packages corresponding to the multiple faults to the cloud server for storage respectively. Before the synchronizing of the running data of the vehicle battery stored in the target data stack at the current time and before the current time to the cache area in the battery management system, the method further comprises:

5. The method of claim 1, wherein, detecting whether a number of data currently stored in the target data stack reaches a predetermined number; in a case where the number of data stored in the target data stack reaches the predetermined number, removing running data with the earliest collection time from the target data stack among the running data stored in the target data stack, and storing running data collected at the current time in a stack head position of the target data stack. The continuously synchronizing of the running data stored in the target data stack to the cache area from the current time until the preset stop condition is reached comprises:

6. The method of claim 1, wherein, continuously synchronizing the running data stored in the target data stack to the cache area from the current time, and controlling a timer to count down the predetermined time length from the current time. ​ In a case where a next fault of the vehicle battery is detected, a fault occurrence time of the next fault is recorded, and the timer is timed reset, and the reset timer is controlled to count down the predetermined time length from the fault occurrence time of the next fault; The above operation is repeatedly performed until, in a case where the reset timer corresponding to a latest fault of the vehicle battery counts down to 0, it is determined that the preset stop condition is reached.

7. The method according to any one of claims 1 to 6, characterized in that, The synchronizing of the fault data record package to the cloud server comprises: The fault data record package is sent to a vehicle networking control unit through a CAN bus, and the fault data record is sent to the cloud server for storage through the vehicle networking control unit.

8. A vehicle battery malfunction operation data processing apparatus characterized by comprising: Comprise: The detection module is configured to detect a first fault of the vehicle battery at a current time; The first data synchronization module is configured to synchronize running data of the vehicle battery stored in the target data stack to a cache area in a battery management system, the running data being collected at the current time and before the current time; The second data synchronization module is configured to continuously synchronize the running data stored in the target data stack to the cache area from the current time until a preset stop condition is reached, wherein the preset stop condition is that no fault of the vehicle battery is detected within a predetermined time length; The data package acquisition module is configured to obtain a fault data record package of the vehicle battery based on the running data stored in the cache area when the preset stop condition is reached, and synchronize the fault data record package to a cloud server.

9. A non-volatile storage medium, comprising: The non-volatile storage medium stores a plurality of instructions, the instructions being adapted to be loaded and executed by the processor to implement the vehicle battery fault running data processing method of any one of claims 1 to 7.

10. An electronic device, comprising: Comprise one or more processors and a memory, the memory being configured to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the vehicle battery fault running data processing method of any one of claims 1 to 7. Comprise one or more processors and a memory, the memory being configured to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the vehicle battery fault running data processing method of any one of claims 1 to 7.

Images