Bms fault record data query method and device, equipment and medium

Abstract

This application relates to the field of BMS system technology, and discloses a method, apparatus, device, and medium for querying BMS fault record data. The method includes: determining whether the current operating environment meets the cache update conditions; if not, upon receiving a fault record query request, returning the currently cached BMS fault record data required by the fault record query request, and returning to the step of determining whether the current operating environment meets the cache update conditions; if yes, caching at least two of the latest second target fault record data, and returning to the step of determining whether the current operating environment meets the cache update conditions. Embodiments of this application can improve the query efficiency and response speed of BMS fault record data.

Description

Technical Field

[0001] This application relates to the field of BMS system technology, and in particular to a method, apparatus, device and medium for querying BMS fault record data. Background Technology

[0002] In existing BMS systems, fault log data is directly stored in non-volatile memory. This storage method necessitates frequent access to the non-volatile memory during fault query operations. The physical characteristics of this memory inherently introduce latency into the access process, typically ranging from 5 to 10 milliseconds. This latency severely hinders the system's responsiveness to real-time diagnostic needs, especially in dynamic scenarios requiring rapid battery status assessment, such as anomaly monitoring during electric vehicle operation. Furthermore, the lack of an effective data indexing mechanism in the storage architecture necessitates a linear traversal of the entire storage area for each query. This significantly extends data retrieval time and drastically reduces overall system query efficiency. As the amount of fault log data accumulates, the traversal time increases non-linearly, making it difficult for the system to extract critical data within a limited timeframe, impacting the timeliness and accuracy of fault diagnosis. In addition, frequent access to non-volatile memory accelerates storage media wear and tear, weakening system reliability. Summary of the Invention

[0003] The purpose of this application is to provide a method, apparatus, device, and medium for querying BMS fault record data, aiming to improve the query efficiency and response speed of BMS fault record data.

[0004] This application provides a method for querying BMS fault record data, including: Determine whether the current operating environment meets the cache update conditions; the cache update conditions are that the number of detected pre-query operations or the number of first target fault record data reaches a number threshold, the pre-query operation is used to indicate the start of the current query period, and the first target fault record data is the BMS fault record data that has been cached and queried in the current query period; If not, upon receiving a fault record query request, the currently cached BMS fault record data required by the fault record query request is returned; the step of determining whether the current operating environment meets the cache update conditions is then returned. If the conditions are met, cache at least two of the latest second target fault record data; return to the step of determining whether the current operating environment meets the cache update conditions; the second target fault record data is BMS fault record data that has not been cached in the current query period.

[0005] In some embodiments, the caching of at least two most recent second target fault record data includes: Read at least two of the latest second target fault record data from the memory; The read second target fault record data is cached at the end of the data queue of the currently cached BMS fault record data.

[0006] In some embodiments, when the number of the second target fault record data is not less than the number of BMS fault record data initially cached, the number of the latest second target fault record data cached each time is equal to the number of BMS fault record data initially cached.

[0007] In some embodiments, the quantity threshold is not less than half the number of BMS fault record data initially cached.

[0008] In some embodiments, the back transmission of the currently cached BMS fault record data required by the fault record query request includes: Based on the index information in the fault record query request, index the BMS fault record data required by the fault record query request in the cache area; The BMS fault record data required for the fault record query request is sent back to the request source that initiated the fault record query request via the controller local area network bus.

[0009] In some embodiments, the pre-query operation is a request initiated by a request source to indicate the start of the current query period or an operation in the current operating environment to indicate the start of the current query period.

[0010] In some embodiments, the pre-query operation is a fault count query request initiated by a request source, and the query method further includes: In response to the fault count query request, fault count response information is sent back to the request source; the fault count response information is used to characterize the number of BMS fault record data currently stored in the memory.

[0011] This application embodiment also provides a BMS fault record data query device, including: The first module is used to determine whether the current operating environment meets the cache update conditions. The cache update conditions are that the number of pre-query operations or the number of first target fault record data reaches a number threshold. The pre-query operation is used to indicate the start of the current query period. The first target fault record data is the BMS fault record data that has been cached and queried in the current query period. The second module is used to, if the cache update conditions are not met, return the currently cached BMS fault record data required by the fault record query request when a fault record query request is received; and return to the step of determining whether the current operating environment meets the cache update conditions. The third module is used to cache at least two of the latest second target fault record data if the cache update conditions are met; and to return to the step of determining whether the current operating environment meets the cache update conditions; the second target fault record data is BMS fault record data that has not been cached in the current query period.

[0012] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described method for querying BMS fault record data.

[0013] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method for querying BMS fault record data.

[0014] The beneficial effects of this application are as follows: By introducing dynamic judgment of cache update conditions, at least two BMS fault record data are actively cached to the cache area when the cache update conditions are met; when the cache update conditions are not met, the currently cached BMS fault record data required by the fault record query request is returned in response to the received fault record query request. Therefore, by dynamically judging the cache update conditions and performing data return or cache update operations based on these conditions, the number of direct accesses to non-volatile memory is effectively reduced, improving the query efficiency and query response speed of BMS fault record data. Attached Figure Description

[0015] Figure 1 This is a flowchart of the BMS fault record data query method provided in the embodiments of this application.

[0016] Figure 2 This is a schematic diagram of the storage structure of BMS fault record data provided in the embodiments of this application.

[0017] Figure 3 This is a schematic diagram of the structure of the BMS fault record data query device provided in the embodiments of this application.

[0018] Figure 4 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0020] It should be noted that although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown may be performed in a different order than the module division in the device or the order in the flowchart. The terms "first," "second," etc., in the specification, claims, and drawings are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0021] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0022] In the fault record data processing of BMS systems, fault record data is directly stored in non-volatile memory, leading to response delays and low query efficiency during fault lookup. This problem stems from the fact that each fault query requires direct access to non-volatile memory without an effective indexing mechanism. The query operation must traverse the entire storage area, resulting in prolonged system response time, failing to meet real-time diagnostic needs, and impacting the timeliness of the diagnostic process and the overall system efficiency. For example, during vehicle operation, when the control system initiates a fault query request to obtain specific BMS fault record data, the system is required to sequentially scan all records in non-volatile memory to locate the required information. In this scenario, due to the lack of an indexing mechanism, the query operation cannot quickly locate the target data and must perform a complete traversal of the storage area, increasing query latency and affecting the real-time execution of diagnostic operations. This prevents the system from acquiring and processing fault information within the critical time window.

[0023] If the above problems are not resolved, the system's responsiveness in the real-time diagnostic process will be continuously constrained, fault information may not be obtained in a timely manner, which will lead to a decrease in the reliability of battery safety monitoring, increase the risk of system operation, and affect the overall functional integrity of the BMS system.

[0024] Based on this, embodiments of this application provide a method, apparatus, device, and medium for querying BMS fault record data. By dynamically determining cache update conditions and performing data backhaul or cache update operations based on these conditions, the number of direct accesses to non-volatile memory is effectively reduced, thereby improving the query efficiency and response speed of BMS fault record data.

[0025] See Figure 1 In one embodiment, a method for querying BMS fault record data is provided. The execution subject of the method is the processor of the BMS system, including but not limited to steps S101 to S103.

[0026] Step S101: Determine whether the current operating environment meets the cache update conditions.

[0027] If it does not meet the requirements, proceed to step S102; if it does meet the requirements, proceed to step S103.

[0028] The cache update condition is triggered when the number of pre-queried operations or the number of first-target fault record data reaches a certain threshold. In essence, the cache update condition refers to a specific state or event that triggers a cache data update or refresh. When the system operating environment meets this condition, the BMS fault record data in the cache will be processed or replaced accordingly to ensure the timeliness and relevance of the cached data. The quantity threshold is a preset numerical limit set for the number of first-target fault record data. When the number of first-target fault record data that has been queried in the cache reaches or exceeds this threshold, the cache update condition may be triggered.

[0029] A pre-query operation is used to indicate the start of the current query cycle. In essence, a pre-query operation is an operation or signal detected at the beginning of the current query cycle. This operation aims to inform the system in advance of the start of a new query cycle, thus preparing for subsequent fault data management and queries. The current query cycle refers to a predefined time period or operational phase used for managing and querying BMS fault record data. Within this cycle, the executing entity will perform data caching and query responses according to specific strategies.

[0030] The first target fault record data refers to the BMS fault record data that has been cached and queried within the current query period. In other words, the first target fault record data refers to BMS fault record data that has been queried within the current query period and is still stored in the cache. This data typically represents BMS fault record data that occurred and was stored later.

[0031] Battery Management System (BMS) fault log data refers to the data generated and recorded by the BMS system when it detects an abnormality or fault in the battery pack. BMS fault log data typically includes information such as the fault type, occurrence time, and relevant parameter values, and is of great significance for the diagnosis and maintenance of the BMS system.

[0032] Determining whether the current runtime environment meets the cache update conditions can be achieved in several ways. For example, a simple counter can be set to record the number of queries since the start of the current query cycle. When the number of queries reaches a preset value, a check on the cache update conditions can be triggered. Alternatively, a fixed time interval can be set to automatically perform the condition check at regular intervals.

[0033] As one implementation approach, the executing entity can continuously monitor specific external signals or internal states. When these signals or states change, it is defined as a pre-query operation being detected, which can trigger a judgment on cache update conditions. For example, a pre-query operation could be a simple system startup signal or a general query request issued by an external request source, indicating the start of a new query cycle.

[0034] One implementation approach is to detect the number of first-target fault record data by maintaining a simple list or array to record the identifiers of queried data and counting their quantities. The quantity threshold can be a pre-set fixed value; for example, when the number of first-target fault record data in the cache reaches this threshold, the cache update condition is considered met.

[0035] Step S102: Upon receiving a fault record query request, return the currently cached BMS fault record data required by the fault record query request. Return to step S101.

[0036] A fault log query request is a request initiated by an external request source or user to obtain specific BMS fault log data. This request typically contains relevant information for locating the required data.

[0037] If the determination result indicates that the cache update conditions are not met, upon receiving a fault record query request, the executing entity will send back the currently cached BMS fault record data required for the query request to the requesting source. Data return can be achieved by directly retrieving it from the cache and sending it to the requesting source. For example, when a fault record query request arrives, the executing entity can search for matching BMS fault record data in a data structure it maintains internally and send it directly through a standard communication interface. After completing the data return, the executing entity will return to the step of determining whether the current operating environment meets the cache update conditions, in order to continuously monitor and respond to environmental changes.

[0038] Step S103: Cache at least two of the most recent second target fault record data. Return to step S101.

[0039] The second target fault record data refers to BMS fault record data that has not been cached within the current query period. In other words, the second target fault record data refers to BMS fault record data that has not yet been cached within the current query period. This data typically consists of earlier occurring and stored BMS fault record data.

[0040] If the determination result indicates that the cache update condition is met, the execution entity will cache at least two of the most recent second target fault records. For example, the execution entity can maintain a pointer to the most recently stored second target fault record in memory. Each time the condition is not met, it reads the pointer pointing to at least two of the most recent second target fault records and adds them to the cache. After completing the caching operation, the execution entity will also return to the step of determining whether the current runtime environment meets the cache update condition to ensure dynamic updates of the cache state.

[0041] The following example will provide a more detailed explanation of the above technical solution: Suppose a BMS system for an electric vehicle requires frequent queries of fault record data for real-time diagnostics. In existing technologies, each query requires direct access to non-volatile memory, leading to response latency and inefficient query performance due to a lack of effective indexes.

[0042] The query method in this embodiment aims to solve this problem. After the BMS system starts, it first enters the step of determining whether the current operating environment meets the cache update conditions. In the initial state, the cache is empty and no pre-query operation has been detected, so the determination result is that the cache update conditions are not met. Subsequently, when the execution subject detects a pre-query operation, it determines that the cache update conditions are met, the current query cycle begins, and the execution subject performs a cache operation, reading at least two of the latest second target fault record data from the non-volatile memory and loading them into the cache area. For example, as Figure 2 As shown, the memory stores n BMS fault record data (n>20). When the execution entity receives a fault count query request initiated by the request source (e.g., the host computer), the execution entity reads the latest ten BMS fault record data from the memory (i.e., ... Figure 2 (Items n to n-9 in the list) and put them into the cache.

[0043] Subsequently, the execution entity returns to the step of determining the cache update conditions. Since the number of first target fault record data does not reach the threshold, the result is that the cache update conditions are not met. Suppose at this time, the request source (e.g., the host computer) initiates a fault record query request, requesting to query BMS fault record data A. The execution entity sends the BMS fault record data A in the cache back to the request source, and then returns to the step of determining the cache update conditions again.

[0044] In this state, the request source (e.g., the host computer) continuously initiates fault record query requests. The execution entity sends back the BMS fault record data in the cache to the request source, and returns to the step of judging the cache update condition after each sendback. When the number of the first target fault record data reaches the quantity threshold, the judgment result is that the cache update condition is not met, and the execution entity performs the caching operation again, reading the ten latest BMS fault record data in the current query period from the memory and putting them into the cache, that is, caching ten of the latest second target fault record data. For example, if the quantity threshold is set to 5, when the number of the first target fault record data reaches 5, the execution entity reads the ten latest BMS fault record data that are not cached in the current query period from the memory (i.e., Figure 2 The (n-10 to n-19) records are then placed in the cache. After caching is complete, the execution entity returns to the step of determining the cache update conditions, continuously monitoring changes in the operating environment. The current query cycle ends when all BMS fault record data in the cache memory is exhausted or a new pre-query operation is detected.

[0045] With this mechanism, once the cache is updated or the conditions are met within the current query cycle, subsequent query requests will preferentially retrieve data from the cache, thereby avoiding frequent access to slow non-volatile memory.

[0046] Based on the above examples, the technical solution of this embodiment demonstrates a technical contribution in solving the problems of the prior art. In the prior art, each BMS fault record query requires direct access to non-volatile memory, which leads to response delay. Furthermore, due to the lack of an effective indexing mechanism, the entire storage area needs to be traversed during the query, resulting in response delay and low query efficiency.

[0047] This embodiment effectively solves the aforementioned problems by introducing a caching mechanism and a dynamic cache update strategy. Specifically, by determining whether the current operating environment meets the cache update conditions, the execution entity can decide when to load the latest fault record from non-volatile memory into the cache, and when to directly respond to query requests from the cache. When the cache update conditions are not met, the execution entity proactively caches the latest second target fault record data to ensure that the cache contains the latest data that may be queried. When the cache update conditions are met, the execution entity directly returns the required data from the cache.

[0048] This method avoids frequent direct access to non-volatile memory, especially within a query cycle. Once relevant data is loaded into the cache, subsequent queries on this data will have a fast response time. Furthermore, by introducing the concepts of pre-query operations and a first target fault record data quantity threshold, this embodiment can adjust the cache update strategy according to the start and progress of the actual query cycle, further optimizing the cache hit rate and query efficiency. This technical solution improves the overall performance of BMS fault record data query by achieving a balance between query efficiency and data real-time performance, meeting the needs of real-time diagnostics.

[0049] In some embodiments, caching at least two latest second target fault record data includes: reading at least two latest second target fault record data from memory; and caching the read second target fault record data to the end of the data queue of the currently cached BMS fault record data.

[0050] The proposed solution, upon determining that the current operating environment meets the cache update conditions, first reads at least two of the latest second target fault record data from memory to effectively update the cache, and then proactively retrieves the latest second target fault record data that has not yet been cached from persistent storage. This read operation ensures the freshness and integrity of the cache data source. Subsequently, by caching the read second target fault record data to the end of the data queue of the currently cached BMS fault record data, these newly read second target fault record data are appended to the end of the existing cached data in an orderly manner. This mechanism of appending new data to the end of the data queue ensures that the BMS fault record data in the cache always maintains temporal continuity and order, meaning that the latest data is always located at the end of the queue.

[0051] By employing this explicit read and append strategy, this solution resolves the potential ambiguity in the basic solution's requirement to cache at least two of the latest second-target fault records, avoiding issues of cached data chaos or inefficiency caused by unclear cache update methods. It ensures that even when cache update conditions are not met, the executing entity can continuously replenish the cache with the latest fault record data in a structured and efficient manner, thus providing a consistently updated and ordered dataset for subsequent fault record query requests. This guarantees the timeliness of cached data and the accuracy of queries, enabling the system to quickly respond to query requests for the latest fault records at any time.

[0052] As a specific implementation, when the BMS system detects that the current operating environment meets the cache update conditions—for example, when the number of first target fault record data reaches a threshold—the execution entity needs to update the cache. At this time, the BMS controller can send a read command to its internal flash memory (as storage) to request two or more recently generated BMS fault record data entries that have not yet been cached in the current query cycle. After successfully reading these latest second target fault record data entries, the execution entity appends these data entries to the end of the BMS fault record data queue currently maintained in RAM (Random Access Memory) according to their generation time order. For example, if the cache queue already contains BMS fault record data A and B, and new BMS fault record data C and D are read, the cache queue will become BMS fault record data A, B, C, and D. In this way, the cache always contains the latest fault information and maintains the chronological order of fault occurrence.

[0053] The above technical solution clarifies how to specifically acquire and organize the latest BMS fault record data when the cache update conditions are met. This solution effectively solves the inefficiency and data corruption problems that may exist in the basic solution's cache update operation by reading the latest second target fault record data from the memory and appending it in an orderly manner to the end of the current cache data queue. This ensures that the fault record data in the cache always maintains its timeliness and integrity, enabling the system to continuously and efficiently update the cache. This provides an accurate, timely, and orderly dataset for subsequent fault record query requests, significantly improving the response speed and data reliability of fault queries.

[0054] In some embodiments, when the number of second target fault record data is not less than the number of BMS fault record data initially cached, the number of the latest second target fault record data cached each time is equal to the number of BMS fault record data initially cached.

[0055] The solution in this application, through the aforementioned mechanism, addresses the issue in the BMS fault record data query method where, when the executing entity determines that the current operating environment meets the cache update conditions and new second target fault record data needs to be cached, it first assesses the total amount of currently available, uncached second target fault record data. If this total amount is not less than the number of BMS fault record data set by the executing entity during initialization or initial loading, then the executing entity will adopt a batch update strategy, meaning that the number of the latest second target fault record data cached each time will be consistent with the number of BMS fault record data cached initially. This mechanism ensures that when there is sufficient new data available for caching, the cache update volume is stable and predictable, avoiding the cache management complexity caused by the uncertainty of the cache quantity each time, and unifying with the initial caching strategy, thereby improving the efficiency and stability of cache updates.

[0056] The following is a concrete example. Assume that the BMS system initially caches 10 of the latest BMS fault records upon startup. During system operation, when a cache update condition is detected, requiring the retrieval and caching of new second target fault records from memory, the execution entity checks the number of currently available, uncached second target fault records. If there are 15 second target fault records in memory at this time, since 15 is not less than the initial cached 10, the execution entity will cache 10 of the latest second target fault records each time, following the strategy of this application. If the next caching requirement is met when there are 22 available second target fault records, the execution entity will still cache 10 of the latest second target fault records. This method ensures that the batch size of each incremental cache is consistent with the initial cache batch size; for example, caching updates are performed in units of 10 records each time, until all new second target fault records are cached or other cache limits are reached.

[0057] Through the above technical solution, when new BMS fault record data needs to be cached, the executing entity can cache data in fixed batches, equal to the initial cache quantity, under specific conditions. This avoids the uncertainty of data volume during cache updates, making cache management more standardized and efficient. Especially when the system is running continuously and generating a large number of new fault records, this strategy can ensure the smoothness and predictability of cache updates, reduce cache jitter and management complexity, thereby improving the overall performance and stability of the BMS fault record data query method.

[0058] In some embodiments, the quantity threshold is not less than half the number of BMS fault record data cached initially.

[0059] This application's solution combines setting a quantity threshold of no less than half the number of BMS fault record data initially cached with a mechanism to determine whether the current operating environment meets the cache update conditions. Specifically, within the current query cycle, the execution entity continuously counts the number of first target fault record data that has been queried. When this number reaches or exceeds the preset quantity threshold, the execution entity determines that the cache update conditions are met, and caches at least two of the latest second target fault record data. If not, upon receiving a fault record query request, it returns the currently cached BMS fault record data required by the query request. In this way, it ensures that at least half of the initially cached data is effectively utilized before triggering a cache update. This avoids frequent cache updates caused by setting the quantity threshold too low, reducing unnecessary system overhead and resource consumption, while ensuring timely updates after the cached data is fully utilized, thus achieving a balance between data freshness and system efficiency.

[0060] For example, suppose that at the start of a query cycle, 10 of the latest BMS fault records are initially cached. According to the above technical solution, the quantity threshold will be set to be no less than half the number of initially cached BMS fault records, i.e., no less than 5. This means that the execution entity will only determine that the cache update condition is met if at least 5 of the first target fault records have been queried within the current query cycle. When the number of actually queried first target fault records reaches or exceeds this quantity threshold, the execution entity will cache multiple of the latest second target fault records until the cache update condition is no longer met.

[0061] By setting the quantity threshold to no less than half the number of BMS fault record data initially cached, the problem of how to reasonably set the cache update threshold to balance data freshness and system efficiency in the BMS fault record data query method is effectively solved. This setting avoids frequent cache updates caused by an excessively low quantity threshold, thereby reducing unnecessary memory read operations and data transfer overhead, and lowering the system load. At the same time, it also ensures that cached data is updated promptly after being fully utilized, avoiding long-term backhaul of outdated data and guaranteeing the accuracy and timeliness of query results. This makes the BMS fault record data query process more efficient and stable.

[0062] In some embodiments, returning the currently cached BMS fault record data required for the fault record query request includes: indexing the BMS fault record data required for the fault record query request in the cache area according to the index information in the fault record query request; and returning the BMS fault record data required for the fault record query request to the request source that initiated the fault record query request via the controller local area network bus.

[0063] Index information refers to key data used to identify and locate specific BMS fault record data. This index information may include, but is not limited to, fault codes, time ranges, fault levels, and vehicle component identifiers. For example, index information can be a timestamp range, allowing the executing entity to quickly locate records within a specified time period by traversing the fault records in the cache sorted by time; alternatively, index information can be a fault type identifier, allowing the executing entity to directly access fault records of the corresponding type through a pre-defined mapping between fault types and cached data locations.

[0064] When the BMS fault record data query method determines that the current operating environment does not meet the cache update conditions and receives a fault record query request, the solution of this application will initiate a precise data backhaul mechanism. First, the execution entity parses the fault record query request and extracts the index information carried within. This index information is a key clue provided by the requesting source to obtain a specific fault record. Subsequently, the execution entity uses this index information to efficiently search and filter the pre-cached BMS fault record data. Once the required BMS fault record data is accurately indexed and ready, the execution entity uses the controller area network bus as the communication medium to backhaul the BMS fault record data to the requesting source that initiated the query. In this way, the solution of this application not only utilizes a caching mechanism to improve query response speed, but also ensures the accuracy of the backhauled data and the stability of communication through precise indexing and reliable transmission, thereby making the entire fault query process more efficient and reliable.

[0065] The following is a concrete example. Assume a vehicle diagnostic tool acts as the request source, sending a fault record query request to the executing entity. This request aims to retrieve the most recent "battery overheating" fault record. Upon receiving this request, the BMS parses the index information contained in the request, namely the fault type "battery overheating" and the quantity "1". The executing entity then searches its internal buffer based on this index information. If the buffer contains multiple "battery overheating" fault records, the executing entity filters them based on the record's timestamp, selecting the most recent one. For example, these records might include the fault code, occurrence time, and battery temperature value. Next, the executing entity encapsulates this filtered BMS fault record data, converting it into a series of messages conforming to the Controller Area Network (CAN) bus communication protocol. These messages may be assigned specific CAN IDs, such as Extended CAN IDs used for diagnostic data transmission, to ensure their uniqueness and identifiability within the CAN network. Subsequently, these CAN messages are sent out through the vehicle's controller area network bus and are eventually received and parsed by the diagnostic tool, thus displaying the latest "battery overheating" fault record on the diagnostic tool's display interface.

[0066] Through the above technical solution, during the query process of BMS fault record data, the required BMS fault record data can be accurately located and extracted from the cache based on the index information carried in the fault record query request. This avoids unnecessary data transmission and significantly improves the efficiency of data query and bandwidth utilization. Simultaneously, utilizing the controller area network bus for data backhaul fully leverages its high reliability, real-time performance, and anti-interference capabilities in the vehicle environment, ensuring that BMS fault record data can be stably and timely transmitted to the requesting source. This effectively solves the problems of inaccurate data location and unreliable transmission during fault record data backhaul in complex vehicle environments, thereby improving the response speed and user experience of the entire BMS fault diagnosis system.

[0067] In some embodiments, a pre-query operation is a request initiated by a request source to indicate the start of the current query period or an operation in the current runtime environment to indicate the start of the current query period.

[0068] Through the above technical solution, this application clarifies two specific types of pre-query operations: requests initiated by external request sources and operations within the system's internal operating environment. These two definitions ensure that the BMS system can identify the start of a query cycle in a clear and controllable manner. When the executing entity receives a specific request from a request source, or when it detects a specific operation in its own operating environment, it can accurately determine that the current query cycle has begun. This explicit triggering mechanism eliminates the ambiguity in determining the start of the query cycle, enabling the executing entity to more reliably execute cache update conditions, thereby ensuring that the cached BMS fault record data remains synchronized and relevant to the current query cycle. This significantly improves the accuracy and efficiency of fault record data queries, avoiding problems such as cached data invalidation or query response delays caused by inaccurate cycle determination.

[0069] The following is a concrete example. As a specific implementation, the pre-query operation can be initiated by an external diagnostic device (the request source). For example, when the diagnostic device connects to the vehicle and starts the diagnostic program, it first sends a specific CAN diagnostic frame to the execution entity. The identifier and data content of this frame are preset as a "start fault query cycle" signal. After receiving and parsing the diagnostic frame, the execution entity recognizes it as a pre-query operation, thereby initiating a new query cycle. Alternatively, the pre-query operation can also be an internal operation of the execution entity. For example, after each vehicle power-on self-test, or when the execution entity detects that the BMS system has woken up from sleep mode and entered normal operating mode, these internal state changes are treated as pre-query operations, thereby triggering a new query cycle.

[0070] By employing the aforementioned technical solution and clearly defining the specific form of the pre-query operation, this application ensures that the BMS system can accurately and reliably determine the start of the query cycle. This enables the cache update conditions to be precisely triggered, thereby guaranteeing that the cached BMS fault record data is always up-to-date and valid, greatly improving the efficiency and accuracy of fault record data retrieval, and optimizing the diagnostic response capabilities of the BMS system.

[0071] In some embodiments, the pre-query operation is a fault quantity query request initiated by the requesting source, and the query method further includes: responding to the fault quantity query request by sending fault quantity response information back to the requesting source.

[0072] The fault count response information is used to characterize the number of BMS fault record data currently stored in the memory. It can be understood that the fault count response information is the core content of the response information sent back to the requesting source; it explicitly indicates the total number of BMS fault record data currently actually stored in the BMS system's internal memory (e.g., non-volatile memory such as EEPROM or Flash). This allows the requesting source to accurately know how many fault records are available for query. For example, if there are 150 fault records in the memory, the fault count response information will contain the value 150. This information can be a direct numerical value or an encoded numerical value, but its ultimate purpose is to clearly express the total number of fault records.

[0073] This application's solution concretizes the pre-query operation into a fault count query request and adds a step of responding with fault count information. This allows the requesting source to obtain the total number of fault records in storage before initiating a detailed query of BMS fault record data. When the requesting source initiates a fault count query request, the execution entity responds and sends back response information containing the number of currently stored BMS fault record data. This process not only triggers cache update conditions, enabling the execution entity to prepare data for subsequent detailed queries, but more importantly, it provides the requesting source with crucial contextual information. The requesting source can intelligently plan subsequent fault record query strategies based on the obtained total number of faults, for example, determining how many query requests are needed to retrieve all data, or deciding whether pagination queries are necessary based on the total number. This mechanism allows the requesting source to avoid blind queries, reducing unnecessary communication overhead and processing burden, thereby improving the overall efficiency and user experience of fault record data queries.

[0074] The following is a concrete example. Suppose an external diagnostic device acts as the request source, needing to retrieve all fault records from the BMS. Without the solution described in this application, the diagnostic device might need to repeatedly send query requests until no new fault records are received, only then can it be certain that all data has been retrieved. However, using the solution described in this application, the diagnostic device first sends a specific fault count query request to the executing entity. For example, it sends a message containing a specific function code via the CAN bus. Upon receiving this request, the executing entity immediately accesses its internal fault storage area (e.g., a dedicated Flash memory for storing fault logs) and counts the currently stored fault records, assuming 85. Subsequently, the executing entity constructs a fault count response message containing the value 85 and sends it back to the diagnostic device via the CAN bus. Upon receiving this response, the diagnostic device knows that there are a total of 85 fault records in the BMS. At this point, the diagnostic equipment can accurately calculate how many fault record query requests need to be sent based on the number of these 85 records (for example, if each query can retrieve 10 records, then 9 requests are needed), thus planning the data acquisition and avoiding redundant queries and uncertainties. Simultaneously, this fault count query request also serves as a pre-query operation, triggering the internal cache update mechanism of the execution entity to ensure that subsequent fault record query requests can efficiently retrieve data from the cache.

[0075] Through the above technical solution, the requesting source can know the total number of fault records in the storage before querying BMS fault record data. This allows the requesting source to optimize its query strategy based on the actual data volume, avoiding unnecessary duplicate queries or data omissions, and significantly improving the efficiency and accuracy of fault record data querying. At the same time, it also reduces the processing burden on the BMS system and optimizes the use of system resources.

[0076] See Figure 3 This application also provides a BMS fault record data query device, which can implement the above-mentioned BMS fault record data query method. The device includes: The first module 301 is used to determine whether the current operating environment meets the cache update conditions. The cache update conditions are that the number of pre-query operations or the number of first target fault record data reaches the quantity threshold. The pre-query operation is used to indicate the start of the current query period. The first target fault record data is the BMS fault record data that has been cached and queried in the current query period. The second module 302 is used to return the currently cached BMS fault record data required by the fault record query request when a fault record query request is received if the cache update conditions are not met; and return the steps for determining whether the current operating environment meets the cache update conditions. The third module 303 is used to cache at least two of the latest second target fault record data if the cache update conditions are met; it returns the steps for determining whether the current operating environment meets the cache update conditions; the second target fault record data is BMS fault record data that has not been cached in the current query period.

[0077] The specific implementation of the BMS fault record data query device is basically the same as the specific implementation of the BMS fault record data query method described above, and will not be repeated here.

[0078] Figure 4 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application.

[0079] The following reference Figure 4 To describe an electronic device 400 according to such an embodiment of the present disclosure. Figure 4 The electronic device 400 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments disclosed herein.

[0080] like Figure 4 As shown, the electronic device 400 is presented in the form of a general-purpose computing device. The components of the electronic device 400 may include, but are not limited to: at least one processing unit 410, at least one storage unit 420, a bus 430 connecting different system components (including storage unit 420 and processing unit 410), a display unit 440, etc.

[0081] The storage unit stores program code, which can be executed by the processing unit 410, causing the processing unit 410 to perform the steps described in the above-described BMS fault record data query method section of this specification according to various exemplary embodiments of this disclosure.

[0082] Storage unit 420 may include a readable medium in the form of a volatile storage unit, such as random access memory (RAM) 4201 and / or cache memory 4202, and may further include a read-only memory (ROM) 4203.

[0083] Storage unit 420 may also include a program / utility 4204 having a set (at least one) program module 4205, such program module 4205 including but not limited to: operating system, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.

[0084] Bus 430 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the various bus structures.

[0085] Electronic device 400 can also communicate with one or more external devices 400' (e.g., keyboard, pointing device, Bluetooth device, etc.), and with one or more devices that enable a user to interact with electronic device 400, and / or with any device that enables electronic device 400 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 450. Furthermore, electronic device 400 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 460. Network adapter 460 can communicate with other modules of electronic device 400 via bus 430. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 400, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0086] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0087] The BMS fault record data query method, apparatus, device, and medium provided in this application introduce a dynamic determination of cache update conditions. When the cache update conditions are met, at least two BMS fault record data entries are actively cached in the cache area. When the cache update conditions are not met, the currently cached BMS fault record data required by the query request is returned in response to the received fault record query request. Therefore, by dynamically determining the cache update conditions and performing data return or cache update operations based on these conditions, the number of direct accesses to non-volatile memory is effectively reduced, improving the query efficiency and response speed of BMS fault record data.

[0088] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, or network device, etc.) to execute the methods described above according to the embodiments of this disclosure.

[0089] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of readable storage media include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0090] Computer-readable storage media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable storage medium may also be any readable medium other than a readable storage medium that can transmit, propagate, or transfer a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0091] Those skilled in the art will understand that the above modules can be distributed in the device as described in the embodiments, or they can be modified accordingly and placed in one or more devices that are unique to this embodiment. The modules in the above embodiments can be combined into one module, or they can be further divided into multiple sub-modules.

[0092] Exemplary embodiments of this disclosure have been specifically shown and described above. It should be understood that this disclosure is not limited to the detailed structures, arrangements, or implementations described herein; rather, this disclosure is intended to cover various modifications and equivalent arrangements contained within the spirit and scope of the appended claims.

Claims

1. A method for querying BMS fault record data, characterized in that, include: Determine if the current runtime environment meets the cache update conditions; The cache update condition is that the number of pre-query operations or the number of first target fault record data reaches a threshold. The pre-query operation is used to indicate the start of the current query period. The first target fault record data is the BMS fault record data that has been cached and queried in the current query period. If it does not meet the requirements, when a fault record query request is received, the currently cached BMS fault record data required by the fault record query request will be sent back. Return to the step of determining whether the current runtime environment meets the cache update conditions; If the conditions are met, cache at least two of the most recent second target fault record data; Return to the step of determining whether the current operating environment meets the cache update conditions; the second target fault record data is BMS fault record data that has not been cached within the current query period.

2. The method for querying BMS fault record data according to claim 1, characterized in that, The cache contains at least two recent second target fault records, including: Read at least two of the latest second target fault record data from the memory; The read second target fault record data is cached at the end of the data queue of the currently cached BMS fault record data.

3. The method for querying BMS fault record data according to claim 1, characterized in that, When the number of second target fault record data is not less than the number of BMS fault record data initially cached, the number of the latest second target fault record data cached each time is equal to the number of BMS fault record data initially cached.

4. The method for querying BMS fault record data according to claim 1, characterized in that, The quantity threshold is not less than half the number of BMS fault record data cached for the first time.

5. The method for querying BMS fault record data according to claim 1, characterized in that, The BMS fault record data currently cached and required by the fault record query request is returned, including: Based on the index information in the fault record query request, index the BMS fault record data required by the fault record query request in the cache area; The BMS fault record data required for the fault record query request is sent back to the request source that initiated the fault record query request via the controller local area network bus.

6. The method for querying BMS fault record data according to claim 1, characterized in that, The pre-query operation is either a request initiated by the request source to indicate the start of the current query period or an operation in the current operating environment to indicate the start of the current query period.

7. The method for querying BMS fault record data according to claim 6, characterized in that, The pre-query operation is a fault count query request initiated by the request source, and the query method further includes: In response to the fault count query request, fault count response information is sent back to the request source; the fault count response information is used to characterize the number of BMS fault record data currently stored in the memory.

8. A device for querying BMS fault record data, characterized in that, include: The first module is used to determine whether the current runtime environment meets the cache update conditions; The cache update condition is that the number of pre-query operations or the number of first target fault record data reaches a threshold. The pre-query operation is used to indicate the start of the current query period. The first target fault record data is the BMS fault record data that has been cached and queried in the current query period. The second module is used to, if the cache update conditions are not met, return the currently cached BMS fault record data required by the fault record query request when a fault record query request is received. Return to the step of determining whether the current runtime environment meets the cache update conditions; The third module is used to cache at least two of the latest second target fault record data if the cache update conditions are met. Return to the step of determining whether the current operating environment meets the cache update conditions; the second target fault record data is BMS fault record data that has not been cached within the current query period.

9. An electronic device, characterized in that, The electronic device includes a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, it implements the BMS fault record data query method according to any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the BMS fault record data query method according to any one of claims 1 to 7.

Images