Fault information storage method and device, computer equipment and storage medium

Abstract

The invention relates to the technical field of vehicles, and discloses a fault information storage method and device, computer equipment and a storage medium, and the method comprises the steps: obtaining fault information generated by a vehicle at the current moment, and storing the fault information to a first buffer area; the working state of the storage scheduling module at the current moment is obtained, and when the working state is an idle state, target fault information needing to be scheduled at present is determined according to the storage condition of the fault information in the first buffer area, and the target fault information is transmitted to the second buffer area; in the second buffer area, a storage scheduling module is scheduled to store the target fault information to a target memory, and a callback processing mechanism is triggered; and executing a storage process of the residual fault information in the first buffer area based on a callback processing mechanism. According to the method, the problem that part of fault information is lost due to the fact that a cache mechanism is lacked when the ECU controller processes the high-concurrency fault under the existing AUTOSAR architecture is solved.

Description

Technical Field

[0001] The present invention relates to the field of vehicle technology, and in particular to a method, device, computer equipment and storage medium for storing fault information. Background Art

[0002] In the field of automotive electronics, the Electronic Control Unit (ECU) plays a vital role, responsible for comprehensive monitoring and management of various electronic systems of the vehicle, including fault detection, storage and reporting. Currently, the software code architecture of the ECU for fault storage and reporting is mainly designed and implemented based on the AUTOSAR architecture.

[0003] However, the existing AUTOSAR architecture has obvious limitations in practical applications. It can only handle low-concurrency fault codes of less than 10, and it is difficult to cope with complex fault conditions. At the same time, the architecture lacks a logical layer cache mechanism, and the fault storage task is directly submitted to the NVM module without proper cache processing. Since the NVM module needs to submit tasks to the FEE and FLS modules in steps, and these two modules also process them in steps, the fault code storage process is complex and time-consuming. When a large number of faults occur in the system at the same time, the fault storage tasks that exceed the NVM processing capacity will be discarded, resulting in the loss of some valuable fault information. Summary of the invention

[0004] In view of this, embodiments of the present invention provide a method, apparatus, computer device and storage medium for storing fault information to solve the problem of partial fault information loss due to the lack of a cache mechanism when an ECU controller under the existing AUTOSAR architecture handles high-concurrency faults.

[0005] In a first aspect, an embodiment of the present invention provides a method for storing fault information, the method comprising:

[0006] Acquire fault information generated by the vehicle at the current moment, and store the fault information in a first buffer area;

[0007] Acquire the working state of the storage scheduling module at the current moment, and when the working state is an idle state, determine the target fault information that needs to be scheduled currently according to the storage status of the fault information in the first buffer area, and transfer the target fault information to the second buffer area;

[0008] In the second buffer area, scheduling the storage scheduling module to store the target fault information in the target memory and triggering the callback processing mechanism;

[0009] The storage process of the remaining fault information in the first buffer area is executed based on the callback processing mechanism.

[0010] In an optional implementation manner of the present application, before obtaining the fault information generated by the vehicle at the current moment, the method further includes:

[0011] Obtain at least one historical fault information and the historical occurrence time corresponding to the historical fault information;

[0012] The historical fault information is sequentially written into the free data blocks of the first buffer area in the order of the historical occurrence time from small to large.

[0013] In an optional implementation manner of the present application, storing the fault information in the first buffer area includes:

[0014] Detect whether there is an idle data block in the first buffer area;

[0015] If an idle data block is detected, generating identification information corresponding to the fault information, and storing the fault information in association with the identification information in the first idle data block in the first buffer area;

[0016] Or, if it is detected that there is no data block in the idle state, the storage state of the fault information is set to a waiting state until a data block in the idle state is detected.

[0017] In an optional implementation manner of the present application, determining the target fault information that currently needs to be scheduled according to the storage status of the fault information in the first buffer area includes:

[0018] Detecting whether there is at least one historical fault information in the first buffer area to obtain storage status;

[0019] Obtaining a scheduling strategy corresponding to the storage situation;

[0020] Based on the scheduling strategy, target fault information that currently needs to be scheduled is determined from the first buffer area.

[0021] In an optional implementation manner of the present application, determining the target fault information currently requiring scheduling from the first buffer area based on the scheduling strategy includes:

[0022] If there is at least one of the historical fault information, determine the candidate data block storing the historical fault information from the first buffer area, and use the first candidate data block among the candidate data blocks as the first data block; use the first historical fault information in the first data block as the target fault information;

[0023] Or, if there is no historical fault information, the fault information is used as the target fault information.

[0024] In an optional implementation manner of the present application, the scheduling storage scheduling module stores the target fault information in the target storage and triggers a callback processing mechanism, including:

[0025] Processing the target fault information according to a preset data format of the target memory to obtain processed target fault information;

[0026] Scheduling the storage scheduling module to write the processed target fault information into a specified address of the target memory, and receiving a task completion signal sent by the storage scheduling module;

[0027] In response to the task completion signal, a callback processing mechanism is triggered.

[0028] In an optional implementation manner of the present application, the process of performing storage of the remaining fault information in the first buffer area based on the callback processing mechanism includes:

[0029] Based on the callback processing mechanism, detecting whether the second buffer area is in an empty state;

[0030] When the second buffer area is in an empty state, detecting whether there is remaining fault information in the first buffer area;

[0031] If there is remaining fault information, determining the next target fault information in the remaining fault information according to the historical occurrence time corresponding to the remaining fault information;

[0032] The next target fault information is transmitted to the second buffer area, and a storage operation of the next target fault information is performed until it is detected that the first buffer area is in an empty state.

[0033] In a second aspect, an embodiment of the present invention provides a storage device for fault information, the device comprising:

[0034] A first acquisition module, used for acquiring fault information generated by the vehicle at the current moment, and storing the fault information in a first buffer area;

[0035] A second acquisition module is used to acquire the working state of the storage scheduling module at the current moment, and when the working state is an idle state, determine the target fault information that needs to be scheduled currently according to the storage status of the fault information in the first buffer area, and transmit the target fault information to the second buffer area;

[0036] A scheduling module, configured to schedule the storage scheduling module to store the target fault information in a target memory in the second buffer area, and trigger a callback processing mechanism;

[0037] An execution module is used to execute a storage process of the remaining fault information in the first buffer area based on the callback processing mechanism.

[0038] In a third aspect, an embodiment of the present invention provides a computer device, comprising: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the method of the first aspect or any corresponding embodiment thereof by executing the computer instructions.

[0039] In a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium having computer instructions stored thereon, the computer instructions being used to enable a computer to execute the method of the first aspect or any corresponding embodiment thereof.

[0040] The method provided in the embodiment of the present application has the following beneficial effects:

[0041] The method provided in the embodiment of the present application avoids the immediate loss of fault information by acquiring and storing the fault information generated by the vehicle at the current moment in the first buffer area, thereby providing a basis for subsequent fault information processing. By acquiring the working status of the storage scheduling module, and determining and transmitting the target fault information to the second buffer area when it is idle according to the storage situation of the first buffer area, efficient scheduling and processing of fault information is achieved, and storage efficiency is improved. In the second buffer area, the target fault information is stored in the target memory through the scheduling storage scheduling module, and the callback processing mechanism is triggered, ensuring the reliable storage of the fault information and providing a flexible callback mechanism for subsequent processing. The storage process of the remaining fault information in the first buffer area is executed based on the callback processing mechanism, which realizes comprehensive and orderly processing of fault information and further improves the efficiency and reliability of fault storage management.

[0042] The method provided in the embodiment of the present application provides a time reference for subsequent processing by obtaining historical fault information and its time, thereby achieving timing management and efficient scheduling of fault information. Write to the first buffer area in time sequence to ensure the timing and orderliness of the fault information. Detect buffer idleness before storage to avoid information loss and ensure timely storage. When idleness is detected, generate identification information and associate storage to achieve accurate identification and effective storage. When the buffer is not idle, set the fault information to a waiting state until it is idle to ensure that information is not missed and improve storage reliability and integrity.

[0043] The method provided in the embodiment of the present application provides a data basis for the formulation of subsequent scheduling strategies by detecting the storage status of the first buffer area, thereby realizing effective management and scheduling of fault information. The scheduling strategy is obtained according to the storage status to realize intelligent scheduling and processing of fault information, thereby improving storage efficiency and processing flexibility. The target fault information is determined based on the scheduling strategy to ensure timely processing and storage of fault information and improve management accuracy and efficiency. When historical fault information exists, it is processed in an orderly manner and efficiently scheduled; when it does not exist, new fault information is processed in a timely manner to ensure the integrity and reliability of fault information management.

[0044] The method provided by the embodiment of the present application ensures the compatibility of fault information with the target memory, and improves storage efficiency and accuracy. By scheduling the storage module, reliable storage of fault information is achieved, and a clear signal is provided for subsequent processing. In response to the completion signal, the callback mechanism is triggered to achieve immediate subsequent processing after storage, which improves management consistency and efficiency. The storage process of the remaining fault information is executed to ensure that all fault information is processed in a timely and orderly manner. By detecting the status of the buffer area, step-by-step and orderly processing of fault information is achieved, and the historical occurrence time is taken into account to ensure the timing. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] In order to more clearly illustrate the specific implementation methods of the present invention or the technical solutions in the prior art, the drawings required for use in the specific implementation methods or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some implementation methods of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0046] Figure 1 is a flowchart of a method for storing fault information according to some embodiments of the present invention;

[0047] Figure 2 is a schematic diagram of the structure of a storage scheduling module according to an embodiment of the present invention;

[0048] Figure 3 is a schematic diagram of the process of fault information queue processing and transmission according to an embodiment of the present invention;

[0049] Figure 4 is a schematic diagram of a process for processing and storing vehicle fault information according to an embodiment of the present invention;

[0050] Figure 5 is a structural block diagram of a storage device for fault information according to an embodiment of the present invention;

[0051] Figure 6 It is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0052] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention.

[0053] According to an embodiment of the present invention, a method, apparatus, computer device and storage medium for storing fault information are 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 a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0054] In this embodiment, a method for storing fault information is provided. Figure 1 is a flow chart of a method for storing fault information according to an embodiment of the present invention. Figure 1 As shown, the process includes the following steps:

[0055] Step S11, obtaining the fault information generated by the vehicle at the current moment, and storing the fault information in the first buffer area.

[0056] In an embodiment of the present application, when a vehicle failure is detected, all information related to the failure will be obtained, wherein the failure information may include the type of failure, the time of occurrence, and related vehicle parameters (such as vehicle speed, engine status, etc.). The acquired failure information will be stored in a preset first buffer area, which is a structure array in the memory, i.e., a first-level buffer. The size of the first-level buffer can be flexibly configured according to the amount of failure information. The ID information of the BLOCK block can be recorded during storage, wherein the ID information is used to identify the storage location of the failure information, similar to a flag bit.

[0057] In the embodiment of the present application, before obtaining the fault information generated by the vehicle at the current moment, the following steps A1-A2 are included:

[0058] Step A1, obtaining at least one historical fault information and the historical occurrence time corresponding to the historical fault information.

[0059] In an embodiment of the present application, a database or buffer storing fault information is accessed to obtain at least one historical fault information. The historical fault information may include the type of fault, relevant vehicle parameters (such as vehicle speed, engine status, etc.), fault code, etc. Each historical fault information has a corresponding occurrence time, which records the specific time when the fault occurred.

[0060] Step A2, writing the historical fault information into the free data blocks in the first buffer area in order from small to large historical occurrence times.

[0061] In the embodiment of the present application, first, the order of writing is determined according to the time of occurrence of the historical fault information, and the order is from small to large, that is, the order of the fault occurrence. Free data blocks are found in the first buffer area, where free data blocks refer to those data blocks that are not currently occupied and can be used to store new fault information. According to the determined order, the historical fault information is written into the found free data blocks in sequence. Each fault information will occupy a data block, and the ID information of the corresponding BLOCK block is assigned to each historical fault information for subsequent processing.

[0062] In the embodiment of the present application, storing the fault information in the first buffer area includes the following steps B1-B3:

[0063] Step B1, detecting whether there is an idle data block in the first buffer area.

[0064] In the embodiment of the present application, before storing new fault information in the first buffer area, it is necessary to check whether there are free data blocks in the area. Data block detection can be performed by maintaining a free data block list or using a bitmap to mark free data blocks so as to quickly allocate them to new fault information. At the same time, when the fault information in the data block is successfully stored in the second buffer area or deleted, the free data block list or bitmap is updated.

[0065] Step B2: if it is detected that there is an idle data block, then generate identification information corresponding to the fault information, and associate the fault information with the identification information and store it in the first idle data block in the first buffer area.

[0066] In an embodiment of the present application, it has been detected that there is an idle data block in the first buffer area, and then a unique identification information needs to be generated for this fault information, wherein the identification information can be the ID information, timestamp, serial number or UUID of the BLOCK block, etc. The generated identification information is associated with the fault information, which can be achieved by creating an entry containing the fault information and the identification information in a data structure. Finally, the associated fault information and identification information are stored together in the first idle data block in the first buffer area. The storage process may include copying the data to the data block and updating the status of the data block to occupied.

[0067] Step B3: If it is detected that there is no data block in the idle state, the storage state of the fault information is set to a waiting state until a data block in the idle state is detected.

[0068] In an embodiment of the present application, when it is determined that there are no free data blocks in the first buffer area that can be used to store new fault information, the storage state of the fault information is set to a waiting state, indicating that the fault information will not be discarded immediately, but will be retained in a temporary storage area or queue, and the state of the first buffer area will continue to be monitored, waiting until a free data block appears. During the waiting period, the state of the first buffer area can be periodically checked, or the appearance of free data blocks can be known through other mechanisms (such as interrupts, callbacks, etc.). When it is detected that there are free data blocks in the first buffer area, the fault information previously set to a waiting state is stored in the free data block. The subsequent processing flow will follow step B2 and subsequent steps until the fault information is successfully stored in the non-volatile memory.

[0069] Step S12, obtaining the working state of the storage scheduling module at the current moment, when the working state is an idle state, determining the target fault information that needs to be scheduled currently according to the storage status of the fault information in the first buffer area, and transmitting the target fault information to the second buffer area.

[0070] It should be noted that if Figure 2As shown, the storage scheduling module plays a key role in the AUTOSAR software architecture. It is mainly composed of three major components: the NVM module, the FEE module, and the FLS module. The NVM module, i.e., the non-volatile storage manager, is responsible for comprehensively managing the data access and operation of the non-volatile memory to ensure the persistence and consistency of the data. The FEE module, i.e., the flash EEPROM simulation module, simulates the operation mode of the EEPROM to enable the flash memory device to handle data writing and erasing tasks more efficiently, thereby extending the service life of the flash memory. The FLS module, i.e., the flash memory driver, directly interacts with the flash memory hardware, provides the underlying read, write, and erase functions, and is the basis for the operation of the flash memory device. These three modules work together to achieve efficient and stable storage scheduling in the AUTOSAR architecture. In addition, the present invention adds a layer of fault information storage management logic in the application layer, aiming to further optimize and enhance the ability and efficiency of the storage scheduling module in fault code processing.

[0071] In an embodiment of the present application, it is checked whether the storage scheduling module (including NVM module, FEE module, FLS module, etc.) is in an idle state. If so, the fault information is prepared to be taken out from the first buffer area for storage; at the same time, the target fault information to be scheduled is determined according to the storage situation of the fault information in the first buffer area (such as the time of occurrence), and it is transferred to the second buffer area for subsequent storage. When determining the target fault information, a variety of strategies can be adopted, such as giving priority to scheduling fault information with an earlier occurrence time, or scheduling according to the type or priority of the fault information. If there is too much fault information in the first buffer area, a paging or batch processing mechanism can be implemented to avoid performance problems caused by processing too much data at one time.

[0072] In the embodiment of the present application, determining the target fault information that needs to be scheduled currently according to the storage status of the fault information in the first buffer area includes the following steps C1-C3:

[0073] Step C1, detecting whether there is at least one historical fault information in the first buffer area, and obtaining the storage status.

[0074] In the embodiment of the present application, since the first buffer area is a structure array that can store multiple fault information, it is necessary to traverse the entire array to check the status of each data block. If fault information is found to be stored in the data block, it means that there is historical fault information in the first buffer area; if no stored fault information is found after traversing the entire array, it means that the first buffer area is empty. In practical applications, a counter or flag can be maintained in the first buffer area to record the number of fault information currently stored, and the value of the counter or flag can be updated each time fault information is stored or deleted.

[0075] Step C2, obtaining a scheduling strategy corresponding to the storage situation.

[0076] In an embodiment of the present application, a corresponding scheduling strategy is obtained according to the storage situation. This is a set of rules or algorithms for determining which one should be selected for storage when multiple fault information exist, such as "giving priority to the earliest one". After obtaining the scheduling strategy, the target fault information that currently needs to be scheduled can be determined from the first buffer area based on it. In practical applications, the scheduling strategy can be flexibly configured according to specific needs, and factors to be considered may also include the type of fault information, the degree of urgency, etc. To implement more complex scheduling strategies, algorithms or data structures such as priority queues and heaps can be used to assist in selecting target fault information.

[0077] Step C3: determining target fault information currently requiring scheduling from the first buffer area based on the scheduling strategy.

[0078] According to the scheduling strategy, the target fault information that needs to be scheduled is determined from the first buffer area. If there is historical fault information, it is selected according to the scheduling strategy (such as "first select the earliest"). If it does not exist, the newly generated fault information is used as the target. In practical applications, the scheduling strategy can be dynamically adjusted according to the system status and load to optimize performance and response speed.

[0079] In the embodiment of the present application, step C3 includes the following steps C31-C32:

[0080] Step C31, if there is at least one historical fault information, determine the candidate data blocks storing the historical fault information from the first buffer area, and use the first candidate data block in the candidate data blocks as the first data block; use the first historical fault information in the first data block as the target fault information.

[0081] In the embodiment of the present application, firstly, it is checked whether there is at least one historical fault information in the first buffer area (first-level buffer). If there is, candidate data blocks are determined from the data blocks storing the historical fault information, and the first data block among the candidate data blocks is marked as the first data block. Subsequently, the first historical fault information stored in the first data block is selected as the target fault information, and this fault information will be transferred to the second buffer area (secondary buffer) for subsequent storage processing.

[0082] Step C32: If there is no historical fault information, the fault information is used as the target fault information.

[0083] In the embodiment of the present application, when it is detected that there is no historical fault information in the first buffer area, it means that the first buffer area is currently empty, or the previous fault information has been processed and transferred to the second buffer area. In this case, the newly acquired fault information is directly used as the target fault information.

[0084] As an example, the data blocks corresponding to the fault information in the first buffer area are regarded as a queue. Figure 3 As shown, the queue in the current first buffer area (first-level buffer) stores the following fault information in order from the head to the tail: fault information 1, fault information 2, and fault information 3. The processing process is as follows: First, detect that there are three historical fault information in the first buffer area (first-level buffer): fault information 1, fault information 2, and fault information 3. According to the scheduling strategy of "giving priority to the earliest occurrence", select fault information 1 at the head of the queue as the target fault information, and dequeue it and pass it to the second buffer area (secondary buffer) for subsequent storage and processing. Subsequently, continue to detect and process the remaining fault information 2 and fault information 3 in sequence until the queue in the first buffer area is empty. Finally, all fault information is orderly transferred to the second buffer area for storage and processing according to the scheduling strategy.

[0085] Step S13: In the second buffer area, the scheduling storage scheduling module stores the target fault information into the target memory and triggers the callback processing mechanism.

[0086] In the embodiment of the present application, the scheduling storage scheduling module stores the target fault information in the target storage and triggers the callback processing mechanism, including the following steps D1-D3:

[0087] Step D1, processing the target fault information according to the preset data format of the target memory to obtain the processed target fault information.

[0088] It should be noted that the target memory refers to a non-volatile memory used to persistently store fault information, such as a specific area in a Flash memory (such as Dflash). The preset data format refers to the data organization form required by the target memory, which may include a specific data structure, encoding method, checksum or other elements used to ensure data integrity and readability.

[0089] In an embodiment of the present application, the target fault information will be encoded, compressed or converted according to the preset data format of the target memory to ensure that it meets the storage requirements. Before writing, a checksum and other mechanisms can be added to ensure the integrity and accuracy of the data. At the same time, the fault information can be encrypted to prevent unauthorized access and interpretation. In addition, metadata such as timestamps and fault type identifiers can be added to facilitate subsequent data retrieval and analysis. If the target fault information is too large, it can be sub-packetized to ensure that each packet of data meets the preset format requirements.

[0090] Step D2, the storage scheduling module writes the processed target fault information into the designated address of the target memory, and receives the task completion signal sent by the storage scheduling module.

[0091] In the embodiment of the present application, the storage scheduling module is responsible for managing the interaction with the target storage, including writing and reading data. The module writes the processed target fault information to the specified address of the target storage, and this process includes low-level storage operations such as data block allocation and data encoding.

[0092] Step D3, responding to the task completion signal, triggering the callback processing mechanism.

[0093] In an embodiment of the present application, when the fault information in the second buffer area is successfully stored in a non-volatile memory (such as the Dflash of the chip), the NVM module generates a task completion signal. This signal indicates that the storage task has been completed and subsequent processing can be performed. Wait for and capture this signal to trigger the callback processing mechanism. The mechanism will call the previously set callback function to erase the fault information that has been stored in the Dflash in the second buffer area to make room for the next fault information to be stored.

[0094] Step S14: executing a storage process of the remaining fault information in the first buffer area based on the callback processing mechanism.

[0095] In the embodiment of the present application, step S14 includes the following steps E1-E4:

[0096] Step E1: Based on the callback processing mechanism, detect whether the second buffer area is in an empty state.

[0097] In an embodiment of the present application, before starting to process the fault information, a callback function is set. The callback function will be called after the fault information in the second buffer area is successfully stored in a non-volatile memory (such as flash). The fault information in the second buffer area is submitted to the NVM module, and the storage operation is started. In this process, functional modules such as NVM, FEE, and FLS are periodically scheduled until the fault information is successfully stored in the Dflash of the chip. When the fault information is successfully stored in Dflash, the previously set callback function is called, wherein the main function of the callback function is to detect the status of the second buffer area. In the callback function, it is detected whether the second buffer area is in an empty state to ensure that all fault information has been successfully stored in the non-volatile memory and that the second buffer area is ready to receive new fault information.

[0098] Step E2: when the second buffer area is in an empty state, detecting whether there is any remaining fault information in the first buffer area.

[0099] In an embodiment of the present application, when the fault information in the second buffer area has been successfully submitted to the NVM module and the task has been completed (confirmed by the callback function), the second buffer area will be cleared to prepare for storing the next fault information. After this clearing state, check whether there is any unprocessed fault information in the first buffer area. If there is, the information is transferred to the second buffer area in a first-in-first-out order (FIFO), and the subsequent storage process is continued until all fault information is successfully stored in the non-volatile memory.

[0100] Step E3: If there is remaining fault information, then determine the next target fault information in the remaining fault information according to the historical occurrence time corresponding to the remaining fault information.

[0101] In an embodiment of the present application, when there are multiple fault information in the first buffer area or the second buffer area, the information needs to be processed in a certain order. The priority of processing is determined according to the historical occurrence time of the fault information. Specifically, the fault information with an earlier historical occurrence time is preferentially selected for processing to ensure that the fault information can be accurately stored in a non-volatile memory (such as flash) in chronological order.

[0102] Step E4, transferring the next target fault information to the second buffer area, and performing a storage operation of the next target fault information until it is detected that the first buffer area is in an empty state.

[0103] In an embodiment of the present application, the next target fault information is taken out from the first buffer area and transferred to the second buffer area to ensure that the fault information can be processed and stored in a predetermined order (e.g., FIFO order). When the next target fault information is transferred to the second buffer area, the storage operation of the fault information is started, that is, the functional modules such as NVM, FEE, FLS, etc. are called to store the fault information to a specified address in a non-volatile memory (such as flash). While performing the storage operation, the state of the first buffer area is detected to ensure that all fault information has been processed in a timely manner and that the first buffer area is already in an empty state. If there is any remaining fault information in the first buffer area, the above steps are repeated until all fault information is processed and stored in the non-volatile memory.

[0104] As an example, Figure 4As shown, starting from the initial state, the first cache area (first-level buffer) has stored the data block of "ID1+fault information 1", and there are multiple data blocks in idle state. When fault information 2 occurs, it is stored in the idle data block of the first-level buffer, and a unique identifier "ID2" is generated for it. Subsequently, the NVM, FEE, and FLS modules are periodically scheduled to check their working status. If both the NVM and FLS modules are in idle state, the "ID1+fault information 1" in the first-level buffer is transferred to the second cache area (secondary buffer), and the transferred data blocks are cleared using a cyclic clearing algorithm. Next, the fault information 1 in the secondary buffer is submitted to the NVM module, which is further submitted to the FEE and FLS modules for processing. Continue to periodically schedule these modules until the fault information 1 is successfully stored in the chip Dflash. If the storage is successful, the fault information in the secondary buffer is cleared to release storage space. After that, the storage process of fault information 2 is started, and the above process is repeated. After completing the storage of fault information 2, return to the first periodic scheduling step to continue monitoring and processing new fault information. In this way, the fault information generated by the vehicle can be processed and stored in an orderly and efficient manner to ensure the accuracy and completeness of the information.

[0105] In this embodiment, a storage device for fault information is also provided, which is used to implement the above embodiments and preferred implementation modes, and the descriptions that have been made will not be repeated. As used below, the term "module" can implement a combination of software and / or hardware of a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and conceivable.

[0106] This embodiment provides a storage device for fault information, such as Figure 5 As shown, including:

[0107] A first acquisition module 51 is used to acquire the fault information generated by the vehicle at the current moment and store the fault information in a first buffer area;

[0108] The second acquisition module 52 is used to acquire the working state of the storage scheduling module at the current moment. When the working state is an idle state, the target fault information that needs to be scheduled is determined according to the storage status of the fault information in the first buffer area, and the target fault information is transmitted to the second buffer area;

[0109] The scheduling module 53 is used to schedule the storage scheduling module to store the target fault information in the target memory in the second buffer area and trigger the callback processing mechanism;

[0110] The execution module 54 is used to execute the storage process of the remaining fault information in the first buffer area based on the callback processing mechanism.

[0111] In an optional embodiment of the present application, the device also includes: a writing module, used to obtain at least one historical fault information and the historical occurrence time corresponding to the historical fault information; and write the historical fault information in sequence into the free data blocks of the first buffer area in the order of the historical occurrence time from small to large.

[0112] In an optional embodiment of the present application, the first acquisition module 51 is used to detect whether there is an idle data block in the first buffer area; if an idle data block is detected, identification information corresponding to the fault information is generated, and the fault information is associated with the identification information and stored in the first idle data block in the first buffer area; or, if it is detected that there is no idle data block, the storage state of the fault information is set to a waiting state until an idle data block is detected.

[0113] In an optional embodiment of the present application, the second acquisition module 52 is used to detect whether there is at least one historical fault information in the first buffer area to obtain the storage status; obtain the scheduling strategy corresponding to the storage status; and determine the target fault information that currently needs to be scheduled from the first buffer area based on the scheduling strategy.

[0114] In an optional embodiment of the present application, the second acquisition module 52 is used to determine the candidate data blocks storing the historical fault information from the first buffer area if there is at least one historical fault information, and use the first candidate data block in the candidate data blocks as the first data block; use the first historical fault information in the first data block as the target fault information; or, if there is no historical fault information, use the fault information as the target fault information.

[0115] In an optional embodiment of the present application, the scheduling module 53 is used to process the target fault information according to the preset data format of the target memory to obtain the processed target fault information; the scheduling storage scheduling module writes the processed target fault information to the specified address of the target memory, and receives the task completion signal sent by the storage scheduling module; responds to the task completion signal and triggers the callback processing mechanism.

[0116] In an optional embodiment of the present application, the execution module 54 is used to detect whether the second buffer area is in an empty state based on the callback processing mechanism; when the second buffer area is in an empty state, detect whether there is remaining fault information in the first buffer area; if there is remaining fault information, determine the next target fault information in the remaining fault information according to the historical occurrence time corresponding to the remaining fault information; pass the next target fault information to the second buffer area, and execute the storage operation of the next target fault information until it is detected that the first buffer area is in an empty state.

[0117] See also Figure 6 , Figure 6 is a schematic diagram of the structure of a computer device provided by an optional embodiment of the present invention, such as Figure 6 As shown, the computer device includes: one or more processors 10, a memory 20, and interfaces for connecting various components, including high-speed interfaces and low-speed interfaces. Various components are connected to each other using different buses for communication, and can be installed on a common mainboard or installed in other ways as needed. The processor can process the instructions executed in the computer device, including instructions stored in or on the memory to display the graphical information of the GUI on an external input / output device (such as, a display device coupled to the interface). In some optional embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Similarly, multiple computer devices can be connected, and each device provides some necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system).

[0118] The processor 10 may be a central processing unit, a network processor or a combination thereof. The processor 10 may further include a hardware chip. The hardware chip may be a dedicated integrated circuit, a programmable logic device or a combination thereof. The programmable logic device may be a complex programmable logic device, a field programmable gate array, a general purpose array logic or any combination thereof.

[0119] The memory 20 stores instructions executable by at least one processor 10, so that at least one processor 10 executes the method shown in the above embodiment.

[0120] The memory 20 may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function; the data storage area may store data created by the use of a computer device based on the presentation of a small program landing page, etc. In addition, the memory 20 may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some optional embodiments, the memory 20 may optionally include a memory remotely arranged relative to the processor 10, and these remote memories may be connected to the computer device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0121] The memory 20 may include a volatile memory, such as a random access memory; the memory may also include a non-volatile memory, such as a flash memory, a hard disk or a solid state drive; the memory 20 may also include a combination of the above types of memory.

[0122] The computer device further comprises a communication interface 30 for the computer device to communicate with other devices or a communication network.

[0123] The embodiment of the present invention also provides a computer-readable storage medium. The method according to the embodiment of the present invention can be implemented in hardware, firmware, or can be implemented as a computer code that can be recorded in a storage medium, or can be implemented as a computer code that is originally stored in a remote storage medium or a non-temporary machine-readable storage medium and will be stored in a local storage medium through a network download, so that the method described herein can be stored in such software processing on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only storage memory, a random access memory, a flash memory, a hard disk or a solid-state hard disk, etc.; further, the storage medium can also include a combination of the above types of memories. It can be understood that a computer, a processor, a microprocessor controller, or programmable hardware includes a storage component that can store or receive software or computer code. When the software or computer code is accessed and executed by a computer, a processor, or hardware, the method shown in the above embodiment is implemented.

[0124] Although the embodiments of the present invention have been described in conjunction with the accompanying drawings, those skilled in the art may make various modifications and variations without departing from the spirit and scope of the present invention, and such modifications and variations are all within the scope defined by the appended claims.

Claims

1. A method for storing fault information, characterized in that: The method comprises: Acquire fault information generated by the vehicle at the current moment, and store the fault information in a first buffer area; Acquire the working state of the storage scheduling module at the current moment, and when the working state is an idle state, determine the target fault information that needs to be scheduled currently according to the storage status of the fault information in the first buffer area, and transfer the target fault information to the second buffer area; In the second buffer area, scheduling the storage scheduling module to store the target fault information in the target memory and triggering the callback processing mechanism; The storage process of the remaining fault information in the first buffer area is executed based on the callback processing mechanism.

2. The method according to claim 1, characterized in that Before obtaining the fault information generated by the vehicle at the current moment, the method further includes: Obtain at least one historical fault information and the historical occurrence time corresponding to the historical fault information; The historical fault information is sequentially written into the free data blocks of the first buffer area in the order of the historical occurrence time from small to large.

3. The method according to claim 1, characterized in that The storing the fault information to the first buffer area comprises: Detect whether there is an idle data block in the first buffer area; If an idle data block is detected, generating identification information corresponding to the fault information, and storing the fault information in association with the identification information in the first idle data block in the first buffer area; Or, if it is detected that there is no data block in the idle state, the storage state of the fault information is set to a waiting state until a data block in the idle state is detected.

4. The method according to claim 2, characterized in that: The determining the target fault information that needs to be currently dispatched according to the storage status of the fault information in the first buffer area includes: Detecting whether there is at least one historical fault information in the first buffer area to obtain storage status; Obtaining a scheduling strategy corresponding to the storage situation; Based on the scheduling strategy, target fault information that currently needs to be scheduled is determined from the first buffer area.

5. The method according to claim 4, characterized in that The determining target fault information currently requiring scheduling from the first buffer area based on the scheduling strategy includes: If there is at least one of the historical fault information, determine the candidate data block storing the historical fault information from the first buffer area, and use the first candidate data block among the candidate data blocks as the first data block; use the first historical fault information in the first data block as the target fault information; Or, if there is no historical fault information, the fault information is used as the target fault information.

6. The method according to claim 1, characterized in that The storage scheduling module stores the target fault information in the target storage and triggers a callback processing mechanism, including: Processing the target fault information according to a preset data format of the target memory to obtain processed target fault information; Scheduling the storage scheduling module to write the processed target fault information into a specified address of the target memory, and receiving a task completion signal sent by the storage scheduling module; In response to the task completion signal, a callback processing mechanism is triggered.

7. The method according to claim 1, characterized in that The process of performing storage of the remaining fault information in the first buffer area based on the callback processing mechanism includes: Based on the callback processing mechanism, detecting whether the second buffer area is in an empty state; When the second buffer area is in an empty state, detecting whether there is remaining fault information in the first buffer area; If there is remaining fault information, determining the next target fault information in the remaining fault information according to the historical occurrence time corresponding to the remaining fault information; The next target fault information is transmitted to the second buffer area, and a storage operation of the next target fault information is performed until it is detected that the first buffer area is in an empty state.

8. A storage device for fault information, characterized in that: The device comprises: A first acquisition module, used for acquiring fault information generated by the vehicle at the current moment, and storing the fault information in a first buffer area; A second acquisition module is used to acquire the working state of the storage scheduling module at the current moment, and when the working state is an idle state, determine the target fault information that needs to be scheduled currently according to the storage status of the fault information in the first buffer area, and transmit the target fault information to the second buffer area; A scheduling module, configured to schedule the storage scheduling module to store the target fault information in a target memory in the second buffer area, and trigger a callback processing mechanism; An execution module is used to execute a storage process of the remaining fault information in the first buffer area based on the callback processing mechanism.

9. A computer device, characterized in that: include: A memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the method according to any one of claims 1 to 7 by executing the computer instructions.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a computer to execute the method according to any one of claims 1 to 7.

Images