Software failure information recording method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention provides a software failure information recording method and device, electronic equipment and a storage medium, and relates to the technical field of computers.A reset triggering module is closed in response to software failure, and the reset triggering module is used for triggering a first controller to reset under the condition that a preset signal from software is not received and time is out; according to the method, the failure information when the software fails is stored in the nonvolatile storage space, and the reset triggering module is closed, so that the situation that the failure information cannot be recorded due to the fact that the reset triggering module triggers the first controller to reset when the failure information is not completely recorded due to overtime of the reset triggering module is avoided; therefore, the recording effectiveness of the failure information can be improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computers, and more particularly, to a software failure information recording method and device, an electronic device, and a storage medium. BACKGROUND

[0002] In related technologies, software running on a vehicle may fail, and therefore, when the software fails, failure information at the time of the failure can be recorded to facilitate engineers to locate the problem.

[0003] However, the inventors have found through long-term research that the failure information of the software may be missed, resulting in ineffective recording of the failure information. SUMMARY

[0004] Embodiments of the present application provide a software failure information recording method and device, an electronic device, and a storage medium, which can improve the effectiveness of recording software failure information.

[0005] In a first aspect, embodiments of the present application provide a software failure information recording method applied to a first controller running software, the method comprising: in response to the software failing, closing a reset trigger module, the reset trigger module being configured to trigger a reset of the first controller if a preset signal from the software is not received and a timeout occurs; and storing failure information at the time of the software failure in a non-volatile storage space.

[0006] In this embodiment, in response to the software failing, the reset trigger module is closed, the reset trigger module is configured to trigger a reset of the first controller if a preset signal from the software is not received and a timeout occurs, and the failure information at the time of the software failure is stored in a non-volatile storage space. By closing the reset trigger module, the situation that the failure information cannot be recorded due to the reset trigger module triggering a reset of the first controller before the failure information is recorded due to a timeout of the reset trigger module is avoided, thereby improving the effectiveness of recording the failure information.

[0007] In one possible implementation, the reset trigger module includes at least one of a software reset trigger module running on the first controller and a hardware reset trigger module connected to the first controller, and in response to the software failing, the reset trigger module is closed, including: in response to the software failing, at least one of the software reset trigger module and the hardware reset trigger module is closed.

[0008] In this embodiment, in response to the software failing, at least one of the software reset trigger module and the hardware reset trigger module is closed, which can close all reset trigger modules, thereby better recording the failure information.

[0009] In a possible implementation, the failure information includes a failure time, a software version of the software, a device identifier of the electronic device using the software, and running information of the software, and storing the failure information when the software fails into the nonvolatile storage space includes: storing the failure time, the software version, the device identifier, and the running information when the software fails into the nonvolatile storage space. In this embodiment, the information used for analyzing the cause when the software fails is stored as much as possible by storing the failure time, the software version, the device identifier, and the running information when the software fails into the nonvolatile storage space, which is beneficial to the analysis of the failure cause.

[0010] In a possible implementation, the first controller includes a register, a stack, and a random access storage space, the running information includes at least one of first running information in the register, second running information in the stack, and third running information of the random access storage space, and the step of storing the running information into the nonvolatile storage space includes at least one of: storing the first running information in the register into the nonvolatile storage space; or storing the second running information in the stack into the nonvolatile storage space; or storing the third running information of the random access storage space into the nonvolatile storage space.

[0011] In this embodiment, the first running information in the register, the second running information in the stack, and the third running information of the random access storage space are stored into the nonvolatile storage space, so that different running information can be stored into the nonvolatile storage space at the same time, and the storage efficiency of the running information can be improved.

[0012] In a possible implementation, the nonvolatile storage space includes a first nonvolatile storage space in the first controller and a first nonvolatile storage space in a second controller connected with the first controller, and the step of storing the failure information when the software fails into the nonvolatile storage space includes at least one of: storing the failure information when the software fails into the first nonvolatile storage space; or storing the failure information when the software fails into the second nonvolatile storage space.

[0013] In the embodiment, the first non-volatile storage space can be understood as a storage space inside the first controller, and the second non-volatile storage space can be understood as a storage space inside the second controller. The embodiment can store the failure information in the storage space inside the first controller, thereby improving the storage efficiency of the failure information. Alternatively, the embodiment can store the failure information in the storage space inside the second controller, thereby reducing the storage space resource requirement of the first controller. If the failure information is stored in the storage space inside the first controller and in the storage space inside the second controller, the multiple insurance for the record of the failure information is provided.

[0014] In a possible implementation, the method further includes: obtaining a preconfigured failure information storage link; storing the failure information when the software fails in the first non-volatile storage space, including: if the failure information storage link does not include a backup storage link, storing the failure information when the software fails in the first non-volatile storage space; and storing the failure information when the software fails in the second non-volatile storage space, including: if the failure information storage link includes the backup storage link, storing the failure information when the software fails in the second non-volatile storage space indicated by the backup storage link.

[0015] In the embodiment, the failure information when the software fails is stored in the first non-volatile storage space if the failure information storage link does not include a backup storage link, and the failure information when the software fails is stored in the second non-volatile storage space indicated by the backup storage link if the failure information storage link includes the backup storage link. In this way, the flexibility of the failure information storage is improved.

[0016] In a possible implementation, the failure information when the software fails is stored in the second non-volatile storage space indicated by the backup storage link, including: notifying the second controller to prepare to receive the failure information; and based on the backup storage link, sending the failure information to the second non-volatile storage space in the second controller to store the failure information in the second non-volatile storage space, if it is confirmed that the second controller is ready to receive the failure information.

[0017] In the embodiment, the failure information when the software fails is stored in the second non-volatile storage space indicated by the backup storage link, including: notifying the second controller to prepare to receive the failure information; and based on the backup storage link, sending the failure information to the second non-volatile storage space in the second controller to store the failure information in the second non-volatile storage space, if it is confirmed that the second controller is ready to receive the failure information. In this way, the failure information is sent after the second controller is ready, thereby improving the success rate of the record of the failure information.

[0018] In a second aspect, an embodiment of the present application provides a software failure information recording device, applied to a first controller, the first controller running software, and the device comprising: a response module, configured to close a reset trigger module in response to software failure, the reset trigger module being configured to trigger a first controller reset in a case where a preset signal from the software is not received and a timeout occurs; and a recording module, configured to store failure information when the software fails into a non-volatile storage space.

[0019] In a third aspect, an embodiment of the present application provides an electronic device, comprising a processor and a memory, wherein: the memory is configured to store a computer program; and the processor is configured to execute the program stored in the memory to implement the method described above.

[0020] In a fourth aspect, the present application provides a computer readable storage medium, the computer readable storage medium storing a computer program, and the computer program is executed by a processor to implement the method described above. BRIEF DESCRIPTION OF DRAWINGS

[0021] Figure 1 A flowchart of a software failure information recording method according to an embodiment of the present application.

[0022] Figure 2 A flowchart of a software failure information recording method according to another embodiment of the present application.

[0023] Figure 3 A structural diagram of a software failure information recording device according to an embodiment of the present application.

[0024] Figure 4 A structural diagram of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0025] In order to make the technical problems, technical solutions and beneficial effects of the present application clearer, the present application will be further described in detail below with reference to embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and not used to limit the present application.

[0026] Software running on a vehicle may fail, and software failure may cause a series of derivative problems such as increased collision risk, impact on driving assistance systems, information security problems, function failure or degradation. There are many reasons for software failure, including but not limited to software defects, device compatibility problems, external environmental factors, software support problems, and problems of specific brands or vehicle models. Recording the software environment on site after the occurrence of software failure problems can help engineers quickly locate and solve the problems.

[0027] In the related art, a diagnostic event manager (DEM) can be used to manage and diagnose fault events in a vehicle, for example, when a car (also referred to as a vehicle) has software failure, the DEM records the following information: 1) failure time; 2) vehicle information; 3) software version; 4) failure phenomenon description; 5) operation steps before failure; 6) environmental conditions, etc.

[0028] As one of the core modules in the Automotive Open System Architecture (AUTOSAR) architecture, the DEM is mainly responsible for recording, processing and storing information related to vehicle fault diagnosis. These information includes but is not limited to diagnostic trouble codes (DTCs), extended data (such as temperature and vehicle speed when the fault occurs) and frozen frames, which provide important basis for vehicle repair and error state handling. However, the DEM may have the following shortcomings: 1. When the software fails, the DEM itself may not work, or the non-volatile memory (NVM) it depends on may not work, which will cause the occasional software failure problem not to be recorded; 2. The DEM module records limited information, and some specific software failure reasons, such as software failure problems that are not defined by the DEM fault code, cannot be well recorded, so the specific failure reason cannot be located; 3. The DEM module recording process is not real-time when the software fails or the vehicle fails, but needs to be triggered after the fault detection counter accumulates to a certain value, and cannot record the first scene of the problem record.

[0029] Moreover, through the research of the inventor, it is found that since the failure information is not saved, the watchdog will trigger a reset, so that the failure information cannot be recorded in time, and therefore the software failure information recording omission may occur, resulting in invalid failure information recording.

[0030] Therefore, the embodiments of the present application provide a software failure information recording method, device, electronic equipment and storage medium, which can improve the recording effectiveness of the software failure information.

[0031] Next, the software failure information recording method is described.

[0032] Please refer to Figure 1 , Figure 1 A flowchart of a software failure information recording method provided by an embodiment of the present application is shown in FIG. 1. As shown in FIG. 1, the software failure information recording method provided by the embodiment of the present application includes the following steps. Figure 1The method shown can be applied to a first controller, the first controller running software, and the first controller can also be referred to as a first chip, for example, can be an Electronic Control Unit (ECU) in a vehicle, such as Figure 1 The method shown can include: S110, in response to the software failure, closing a reset trigger module, the reset trigger module being configured to trigger a first controller reset in a case where a preset signal from the software is not received and a timeout occurs.

[0033] In this embodiment, the reset processing module can be, for example, a watchdog, and the reset processing module in this embodiment can be configured with a timer, and if the preset signal from the software is received, the timer is reset, and if the preset signal from the software is not received and the timer times out, the first controller reset is triggered.

[0034] In this embodiment, since the reset trigger module triggers the first controller reset in a case where the preset signal from the software is not received and a timeout occurs, and after the software fails, the preset signal can not be sent to the reset trigger module in time, if the failure information is not recorded when the timer times out and the reset trigger module triggers the first controller reset, this can cause the failure information to be unable to be recorded in time. Therefore, the embodiment of the present application closes the reset trigger module to avoid the situation that the failure information cannot be recorded due to the reset trigger module triggering the first controller reset when the failure information has not been recorded in time due to the reset trigger module timeout. In this embodiment, the preset signal can be a signal indicating that the software is not failed, that is, a signal indicating that the software is working normally.

[0035] S120, storing the failure information when the software fails to a non-volatile storage space.

[0036] The non-volatile storage space can refer to a storage space in a non-volatile memory. The non-volatile memory is a storage device that can retain data after power failure. Optionally, after the first controller stores the failure information when the software fails to the non-volatile storage space, the first controller can perform a reset process.

[0037] In this embodiment, by closing the reset trigger module in response to the software failure, the reset trigger module being configured to trigger a first controller reset in a case where a preset signal from the software is not received and a timeout occurs, and storing the failure information when the software fails to a non-volatile storage space, by closing the reset trigger module, the situation that the failure information cannot be recorded due to the reset trigger module triggering the first controller reset when the failure information has not been recorded in time due to the reset trigger module timeout is avoided, and thus the recording effectiveness of the failure information can be improved.

[0038] In a possible implementation, the reset triggering module comprises at least one of a software reset triggering module running on the first controller and a hardware reset triggering module connected to the first controller, and the reset triggering module is closed in response to the software failure, comprising: The at least one of the software reset triggering module and the hardware reset triggering module is closed in response to the software failure.

[0039] The software reset triggering module is usually run in the form of a thread or a process through a software-implemented monitoring mechanism. In the embodiment, the software reset triggering module detects the running state of the software. If it is detected that a preset signal from the software is not received within a timeout, the first controller is triggered to reset. The hardware reset triggering module, also referred to as an external reset triggering module, runs independently of the first controller. The software state is monitored through a timer, and if the preset signal is not received within a specified time, the first controller is forced to reset.

[0040] In the embodiment, the first controller is controlled to reset through the software reset triggering module, which can reduce hardware cost, and the first controller is controlled to reset through the hardware reset triggering module, which can improve the reset success rate, and the first controller is controlled to reset through the software reset triggering module and the hardware reset triggering module, which can further improve the reset success rate.

[0041] In the embodiment, the at least one of the software reset triggering module and the hardware reset triggering module is closed in response to the software failure, so that all the reset triggering modules are closed, and thus the failure information can be better recorded.

[0042] In another possible implementation, the software reset triggering module and the hardware reset triggering module can also be set with different reset timings, and then the reset triggering module with the smaller reset timing is closed, so that the failure information can be better recorded, and the first controller can be triggered after the recording of the failure information is completed.

[0043] In a possible implementation, the method further comprises: detecting a failure event indicating that the software fails, the failure event comprising an abnormal callback (OS ErrHook) event of a system running on the first controller, a reset triggering (CPU Reset) event of the first controller, or a hardware trap (Hardware Trap) event of the first controller; and if the failure event is detected, it is determined that the software fails.

[0044] In a possible implementation, the failure information comprises a failure time, a software version of the software, a device identifier of an electronic device using the software, and running information of the software, and the failure information when the software fails is stored to a non-volatile storage space, comprising: The failure time when the software fails, the software version, the device identifier and the running information are stored into the non-volatile storage space.

[0045] The failure time can be the time when the software fails is detected. The software version can be the version of the software. The device identifier is used to indicate the electronic device where the software is installed. If the electronic device is a vehicle, the device identifier can be, for example, the vehicle identification number. The running information can be the running information of the software when the software fails is detected. The running information can include, but is not limited to, the key parameters and the running code address of the software when running, the function call chain recorded by the stack when running, and the local variables and static variables when running. By using the above information in combination with the Executable and Linkable Format (ELF) file of the software, the environment when the software fails can be restored, and the cause of the software failure can be restored. The ELF file is a standard file format for binary files, executable files, object code, shared libraries and core dumps.

[0046] In the embodiment, by storing the failure time when the software fails, the software version, the device identifier and the running information into the non-volatile storage space, the information used for analyzing the cause when the software fails is stored as much as possible, which is beneficial to the analysis of the cause of the failure.

[0047] In a possible implementation, the first controller includes a register, a stack and a random access memory (RAM), and the running information includes at least one of first running information in the register, second running information in the stack and third running information of the random access memory. The step of storing the running information into the non-volatile storage space includes at least one of the following: storing the first running information in the register into the non-volatile storage space; or storing the second running information in the stack into the non-volatile storage space; or storing the third running information of the random access memory into the non-volatile storage space.

[0048] The first running information includes the key parameters and the running code address of the software when running. The second running information includes the function call chain of the software when running. The third running information includes the local variables and static variables of the software when running. In the embodiment, the register can include, but is not limited to, general registers R0-R15 and special registers such as a program counter (PC).

[0049] In the embodiment, the first running information in the register is stored into the nonvolatile storage space, the second running information in the stack is stored into the nonvolatile storage space, and the third running information in the random access storage space is stored into the nonvolatile storage space, so that different running information can be stored into the nonvolatile storage space at the same time, and the storage efficiency of the running information is improved.

[0050] In a possible implementation, the nonvolatile storage space includes a first nonvolatile storage space in the first controller and a first nonvolatile storage space in a second controller connected with the first controller, and the failure information when the software fails is stored into the nonvolatile storage space, including at least one of the following: The failure information when the software fails is stored into the first nonvolatile storage space, or the failure information when the software fails is stored into the second nonvolatile storage space.

[0051] In the embodiment, the first nonvolatile storage space can be understood as a storage space inside the first controller, and the second nonvolatile storage space can be understood as a storage space inside the second controller. The failure information can be stored in the storage space inside the first controller, so that the storage efficiency of the failure information is improved, or the failure information can be stored in the storage space inside the second controller, so that the storage space resource requirement of the first controller is reduced. If the failure information is stored in the storage space inside the first controller and the storage space inside the second controller, multiple insurance is provided for the record of the failure information.

[0052] In a possible implementation, the method further includes: Obtaining a preconfigured failure information storage link.

[0053] Correspondingly, the failure information when the software fails is stored into the first nonvolatile storage space, including: If the failure information storage link does not include a backup storage link, the failure information when the software fails is stored into the first nonvolatile storage space; Correspondingly, the failure information when the software fails is stored into the second nonvolatile storage space, including: If the failure information storage link includes a backup storage link, the failure information when the software fails is stored into the second nonvolatile storage space indicated by the backup storage link.

[0054] The failure information storage link refers to a link where the failure information is stored, and is used to indicate a transmission mode or a transmission end point of the failure information. The transmission mode can include, but is not limited to, Ethernet, a serial peripheral interface (SPI), a universal asynchronous receiver / transmitter (UART), and the like, without limitation.

[0055] In the embodiment, if the storage link does not include the backup storage link, it indicates that the failure information when the software fails needs to be stored locally in the first controller, and the failure information when the software fails is stored in the first non-volatile storage space. If the storage link includes the backup storage link, it indicates that the failure information when the software fails needs to be stored outside the first controller, and the failure information when the software fails is stored in the second non-volatile storage space indicated by the backup storage link.

[0056] In the embodiment, the preconfigured failure information storage link is acquired. If the failure information storage link does not include the backup storage link, the failure information when the software fails is stored in the first non-volatile storage space. If the failure information storage link includes the backup storage link, the failure information when the software fails is stored in the second non-volatile storage space indicated by the backup storage link. In this way, the flexibility of failure information storage can be improved. Optionally, if the failure information storage link includes the backup storage link, the failure information can also be stored in the first non-volatile storage space synchronously.

[0057] In another possible implementation, the failure information can also be stored in the second non-volatile storage space only when the first non-volatile storage space is full.

[0058] In a possible implementation, storing the failure information when the software fails in the second non-volatile storage space indicated by the backup storage link includes: notifying the second controller to prepare to receive the failure information; and based on the backup storage link, sending the failure information to the second non-volatile storage space in the second controller to store the failure information in the second non-volatile storage space, under the condition that it is confirmed that the second controller is ready to receive the failure information.

[0059] In the embodiment, the first controller can send a request instruction to the second controller, the request instruction is used to request the second controller to receive the invalidation information, if the second controller is ready, the second controller feeds back a response instruction to the request instruction to the first controller, and then the first controller can confirm that the second controller is ready to receive the invalidation information, and then the first controller sends the invalidation information to the second non-volatile storage space in the second controller based on the backup storage link, so as to store the invalidation information to the second non-volatile storage space.

[0060] In the embodiment, by informing the second controller to be ready to receive the invalidation information, and confirming that the second controller is ready to receive the invalidation information, the invalidation information is sent to the second non-volatile storage space in the second controller based on the backup storage link, so as to store the invalidation information to the second non-volatile storage space, so that the invalidation information can be sent after the second controller is ready, and the success rate of recording the invalidation information can be improved.

[0061] In a possible implementation, the invalidation information can be first stored in the first non-volatile storage space, and then the invalidation information stored in the first non-volatile storage space is copied to the second non-volatile storage space. In another possible implementation, the invalidation information can also be sent to the second controller while being stored in the first non-volatile storage space.

[0062] In another possible implementation, the invalidation information can also be directly sent to the second controller, and then the second controller stores the invalidation information in the second non-volatile storage space after receiving the invalidation information, so that the storage efficiency of the invalidation information can be improved.

[0063] Please refer to Figure 2 , Figure 2 A flowchart of a software invalidation information recording method provided by another embodiment of the application is shown in FIG. 2. Figure 2 As shown in the method, the method can include the following steps. S201, deploying an invalidation recording software.

[0064] In the embodiment, the software invalidation recording software is deployed locally and deployed on other controllers in the same domain respectively, and the software deployed on the other controllers is used to receive.

[0065] The other controllers can refer to the description of the second controller, which is not described herein.

[0066] S202, running the automotive software.

[0067] S203, waiting for the automotive software to fail, triggering the OS ErrHook, the CPU Reset or the hardware Trap.

[0068] S204, turn off the external watchdog and the software watchdog.

[0069] In the embodiment, the watchdog reset can be avoided due to the storage of the failure information exceeding the watchdog interval.

[0070] The external watchdog can refer to the description of the hardware reset triggering module, and the software watchdog can refer to the description of the software reset triggering module, which are not described herein.

[0071] S205, store the data of the register into the non-volatile memory through the assembly language.

[0072] In the embodiment, the existing general registers R0-R15 and special registers PC and the like are saved into the local non-volatile memory, so that the values in the registers are not changed due to subsequent operations.

[0073] S206, save the data in the stack into the local non-volatile memory according to the configuration file.

[0074] S207, save the data in the RAM space into the local non-volatile memory according to the configuration file.

[0075] In the embodiment, the configuration file can be used to configure the configuration mode of the data (also referred to as information). In the embodiment, the configuration file defines the storage address and total storage space of the data, for example, defines the storage address and total storage space of the registers, the stack and the RAM respectively. Specifically, the start address and the end address of the failure record RAM space are defined, so that the data is extracted from the start address and the end address of the RAM space. In addition, whether the standby record link of the failure record is enabled and the specific implementation (that is, the transmission mode) thereof; and the start address and the end address of the non-volatile memory for recording the failure information are defined, so as to be stored into the non-volatile memory.

[0076] S208, save the failure time, vehicle information and software version into the local non-volatile memory according to the fixed format according to the configuration file.

[0077] S209, check whether the configuration file contains the standby failure information storage link.

[0078] In the embodiment, if yes, S210-S212 are executed.

[0079] S210, notify other controllers to prepare to accept the software failure record data.

[0080] S211, confirm whether the other controllers are ready to accept the failure record data.

[0081] In this embodiment, if ready, continue to S212.

[0082] S212, transmit the failure information in the local non-volatile storage medium to other controllers through a backup link.

[0083] S213, check whether the transmission process is completed.

[0084] In this embodiment, if not completed, continue to perform S212, and if completed, proceed to S215. In this embodiment, a flag bit can be configured at the start frame and the end frame of the failure information, and the second controller determines that the transmission process is completed according to the flag bits of the start frame and the end frame, and then notifies the first controller.

[0085] S214, notify other controllers in the same domain to prepare to power off or restart.

[0086] S215, an engineer obtains the failure record and acquires the ELF file of the software according to the software version.

[0087] S216, analyze the failure cause of the automotive software according to the ELF file obtained in S208 and the software failure record obtained in S207.

[0088] In summary, the embodiment of the application provides a novel automotive software failure cause recording method, which is different from the traditional DEM module (diagnostic event manager), does not depend on the NVM module, and can record more information when the software fails. The method includes a trigger condition, a recording behavior, and a post-processing after recording: the trigger condition includes but is not limited to a chip hardware Trap (hardware exception), an OS ErrHook (system exception), and a CPU Reset (CPU reset); after triggering, the registers, the stack, the running RAM of the chip, and the failure time, the vehicle information, and the software version are recorded in the local storage medium according to the priority, or are transmitted to other chips in the same domain through communication modes such as Ethernet, SPI, and UART and saved as a binary file; when the recording behavior is completed, the user can analyze the stored binary file to complete the recovery of the software failure site. This method has various optional recording forms when recording software failure, has better recording robustness, records more information, helps engineers to determine the software failure cause more quickly, significantly shortens the software defect repair time in the vehicle mass production development and test stage, and accelerates the product development efficiency.

[0089] The NVM module is a non-volatile storage abstraction software in the automotive development system architecture. It relies on non-volatile storage driver software. If we assume that the success probability of the non-volatile storage driver software is p1 and the success probability of the NVM itself is p2, then since p1 and p2 are both < 1, p1 * p2 < p1. That is, using non-volatile storage driver software to record software failure information is more stable. Using a backup software recording link can enhance the robustness and stability of recording: If we assume that the success probability of the non-volatile storage driver software is p1 and the success probability of the backup link is p2, then since p1 and p2 are both < 1, we must have (1-p1) * (1-p2) < (1-p1). That is, using a backup software recording link can reduce the probability of recording failure.

[0090] Therefore, this embodiment can improve the stability and robustness of software failure records: because the present invention only relies on the storage medium at the chip level, and after configuring a backup storage method, the failure information can also be transmitted to other controllers for storage through the configured transmission link, providing double insurance for software failures; and the information recorded in this embodiment is more detailed, which can greatly reduce the time engineers spend analyzing problems, especially for intermittent problems, and can save the time required for reproduction.

[0091] The method embodiments have been described above; the product embodiments are described below.

[0092] Please see Figure 3 , Figure 3 This is a schematic diagram of a software failure information recording device provided in an embodiment of this application. Figure 3 The illustrated device can be applied to a server, and the device may include a response module 310 and a recording module 320, wherein: The response module 310 is used to disable the reset trigger module in response to a software failure. The reset trigger module is used to trigger the first controller to reset if a preset signal from the software is not received and a timeout occurs. The recording module 320 is used to store the failure information when the software fails to a non-volatile storage space.

[0093] In one possible implementation, the reset trigger module includes at least one of a software reset trigger module running on the first controller and a hardware reset trigger module connected to the first controller. When the response module 310 shuts down the reset trigger module in response to a software failure, it is configured to: In response to a software failure, at least one of the software reset trigger module and the hardware reset trigger module is disabled.

[0094] In a possible implementation, the failure information includes a failure time, a software version of the software, a device identifier of an electronic device using the software, and running information of the software, and when the recording module 320 stores the failure information when the software fails into the non-volatile storage space, the recording module 320 is configured to perform at least one of the following: store the failure time, the software version, the device identifier, and the running information when the software fails into the non-volatile storage space.

[0095] In a possible implementation, the first controller includes a register, a stack, and a random access storage space, the running information includes at least one of first running information in the register, second running information in the stack, and third running information of the random access storage space, and when the recording module 320 stores the running information into the non-volatile storage space, the recording module 320 is configured to perform at least one of the following: store the first running information in the register into the non-volatile storage space; or store the second running information in the stack into the non-volatile storage space; or store the third running information of the random access storage space into the non-volatile storage space.

[0096] In a possible implementation, the non-volatile storage space includes a first non-volatile storage space in the first controller and a first non-volatile storage space in a second controller connected to the first controller, and when the recording module 320 stores the failure information when the software fails into the non-volatile storage space, the recording module 320 is configured to perform at least one of the following: store the failure information when the software fails into the first non-volatile storage space; or store the failure information when the software fails into the second non-volatile storage space.

[0097] In a possible implementation, the recording module 320 is further configured to perform the following: obtain a preconfigured failure information storage link; When the recording module 320 stores the failure information when the software fails into the first non-volatile storage space, the recording module 320 is configured to perform the following: if the failure information storage link does not include a backup storage link, store the failure information when the software fails into the first non-volatile storage space; When the recording module 320 stores the failure information when the software fails into the second non-volatile storage space, the recording module 320 is configured to perform the following: if the failure information storage link includes a backup storage link, store the failure information when the software fails into the second non-volatile storage space indicated by the backup storage link.

[0098] In a possible implementation, when the recording module 320 stores the failure information when the software fails into the second non-volatile storage space indicated by the backup storage link, the recording module 320 is configured to perform the following: The second controller is notified to prepare to receive the invalidation information; and in a case where it is confirmed that the second controller is ready to receive the invalidation information, the invalidation information is sent to a second non-volatile storage space in the second controller based on the backup storage link, so as to store the invalidation information to the second non-volatile storage space.

[0099] It should be noted that, for the convenience and brevity of description, the specific working processes of the apparatuses and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be described here. In the several embodiments provided in the present application, the coupling between the modules can be electrical. In addition, each functional module in each embodiment of the present application can be integrated in one processing module, or each module can exist physically independently, or two or more modules can be integrated in one module. The integrated module can be realized in the form of hardware or in the form of a software functional module.

[0100] The present application also provides an electronic device 40, please refer to Figure 4 , comprising a processor 410 and a memory 420, wherein the memory 410, for storing computer programs; the processor 420, for executing the program stored on the memory 410, realizing the software invalidation information recording method introduced in any embodiment of the present application. The electronic device 40 may, for example, be a vehicle, a vehicle-mounted terminal or a server.

[0101] The present application also provides a computer readable storage medium, the computer readable storage medium stores a computer program, the computer program is executed by the processor to realize the software invalidation information recording method introduced in any embodiment of the present application.

[0102] In the present application, unless otherwise explicitly limited, the terms "mounting", "connecting", "connecting" should be understood broadly, for example, it can be fixedly connected, or it can be detachably connected, or integrally connected; it can be mechanically connected, or it can be electrically connected; it can be directly connected, or it can be indirectly connected through an intermediate medium, or it can be the communication inside two elements. For those skilled in the art, the specific meaning of the above terms in the present application can be understood according to the specific circumstances.

[0103] The terms "first", "second", "third", "fourth" and the like (if any) in the present application are used to distinguish similar objects, and do not necessarily describe a specific order or sequence. "Multiple" means not less than two.

[0104] The term "and / or", within the context of the present application, is used to associate associated objects, and means that three relationships can exist, for example, A and / or B can mean that A exists alone, A and B exist together, and B exists alone. In addition, the character " / " within the present application generally means that the associated objects before and after are in an "or" relationship. "Multiple" means no less than two.

[0105] Unless otherwise specified, all steps in the present application can be performed in sequence or randomly. For example, a method includes steps A and B, which means that the method can include steps A and B performed in sequence, or steps B and A performed in sequence. For example, it is mentioned that the method can further include step C, which means that step C can be added to the method in any order, for example, the method can include steps A, B and C, or steps A, C and B, or steps C, A and B, etc.

[0106] The above is only a preferred embodiment of the present application, and is not intended to limit the present application. Any modification, equivalent replacement and improvement made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A method of recording software failure information, characterized by, The method is applied to a first controller running software, and comprises: in response to failure of the software, closing a reset trigger module configured to trigger a reset of the first controller if a preset signal from the software is not received and a timeout occurs; storing failure information of the software at the time of failure to a non-volatile storage space.

2. The method of claim 1, wherein, The reset trigger module comprises at least one of a software reset trigger module running on the first controller and a hardware reset trigger module connected to the first controller, and the step of closing the reset trigger module in response to failure of the software comprises: in response to failure of the software, closing at least one of the software reset trigger module and the hardware reset trigger module.

3. The method of claim 1, wherein, The failure information comprises a failure time, a software version of the software, a device identifier of an electronic device using the software, and running information of the software, and the step of storing the failure information of the software at the time of failure to the non-volatile storage space comprises: storing the failure time, the software version, the device identifier, and the running information of the software at the time of failure to the non-volatile storage space.

4. The method of claim 3, wherein, The first controller comprises a register, a stack, and a random access storage space, the running information comprises at least one of first running information in the register, second running information in the stack, and third running information of the random access storage space, and the step of storing the running information to the non-volatile storage space comprises at least one of: storing the first running information in the register to the non-volatile storage space; or, storing the second running information in the stack to the non-volatile storage space; or storing the third running information of the random access storage space to the non-volatile storage space.

5. The method according to any one of claims 1-4, characterized in that, The non-volatile storage space comprises a first non-volatile storage space in the first controller and a first non-volatile storage space in a second controller connected to the first controller, and the step of storing the failure information of the software at the time of failure to the non-volatile storage space comprises at least one of: storing the failure information of the software at the time of failure to the first non-volatile storage space; or, storing the failure information of the software at the time of failure to the second non-volatile storage space.

6. The method of claim 5, wherein, The method further comprises: obtaining a pre-configured failure information storage link; The step of storing the failure information of the software at the time of failure to the first non-volatile storage space comprises: if the failure information storage link does not include a backup storage link, storing the failure information of the software at the time of failure to the first non-volatile storage space; The step of storing the failure information of the software at the time of failure to the second non-volatile storage space comprises: if the failure information storage link includes a backup storage link, storing the failure information of the software at the time of failure to the second non-volatile storage space indicated by the backup storage link.

7. The method of claim 5, wherein, The storing of the failure information of the software failure into the second non-volatile storage space indicated by the backup storage link comprises: informing the second controller to prepare to receive the failure information; in the case of confirming that the second controller is ready to receive the failure information, sending the failure information to the second non-volatile storage space in the second controller based on the backup storage link to store the failure information into the second non-volatile storage space.

8. An apparatus for recording software failure information, characterized by comprising: The application is applied to a first controller, wherein the first controller runs software, and the device comprises: a response module, configured to, in response to the software failure, close a reset trigger module, wherein the reset trigger module is configured to trigger the first controller to reset in the case of not receiving a preset signal from the software and timing out; a recording module, configured to store failure information of the software failure into a non-volatile storage space.

9. An electronic device, comprising: The application comprises a processor and a memory, wherein: the memory is configured to store a computer program; the processor is configured to execute the program stored on the memory to implement the method in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a computer program, and the computer program is executed by the processor to implement the method in any one of claims 1-7. The computer readable storage medium stores a computer program, and the computer program is executed by the processor to implement the method in any one of claims 1-7.

Images