Software startup exception monitoring method and device and software monitoring system

Abstract

The application provides a software startup abnormality monitoring method, device and system, which comprises the following steps: a monitoring step, comprising: simultaneously monitoring the time length of a software startup process and the handshake signals of each stage of the software startup process; for each stage of the software startup process, detecting the handshake signals of the stage within a specified time limit corresponding to the stage; a judging step, comprising: when the handshake signals of the stage are not detected within the specified time limit, determining that the software startup is abnormal. The method can monitor each stage of the software startup process respectively, so that whether each stage of the software startup process is abnormal can be monitored, the position of the abnormality can be accurately located, and the diagnosability is improved.

Description

Technical Field

[0001] This invention relates to the field of software detection technology, and in particular to a method, apparatus and system for monitoring software startup anomalies. Background Technology

[0002] Train communication networks, often referred to as the "brain" and "nerves" of a train, are primarily used for data transmission in areas such as train control, status monitoring, fault diagnosis, system maintenance, onboard information services, video surveillance, and safety sensing. They are crucial systems for ensuring train safety and improving the quality of rail transit services. With increasing demands on train applications, various types of data need to be transmitted and exchanged between different devices on the train to complete related control and diagnostic functions. If any device malfunctions, it can cause a failure in the entire system, and prolonged malfunctions can even lead to the paralysis of the entire system.

[0003] Train equipment is generally designed with watchdog circuits to monitor for software malfunctions and to control the software to recover from them. Watchdogs have long modes (e.g., 60 seconds) and short modes (e.g., 500 milliseconds). During normal operation, the watchdog is usually in short mode, allowing for rapid restart and self-healing in case of software failure.

[0004] However, during the device software startup process, loading the software takes some time (usually a few seconds). During this time, the watchdog timer is typically set to long mode. If an anomaly occurs during software loading, the watchdog timer may not time out and trigger a self-healing restart of the device software until several tens of seconds have passed. During this extended period of anomaly, the device may have already malfunctioned or even crashed. Therefore, a method and mechanism are needed to promptly control the software's self-healing when an anomaly occurs during device software startup. Summary of the Invention

[0005] The main objective of this invention is to provide a method, apparatus, and system for monitoring software startup anomalies, so as to shorten the interval between startup anomalies and self-healing restarts and reduce the probability of system failures.

[0006] In a first aspect, the present invention provides a method for monitoring software startup anomalies, comprising: a monitoring step, comprising: simultaneously monitoring the duration of the software startup process and the handshake signals of each stage of the software startup process, and for each stage of the software startup process, detecting the handshake signal of that stage within a specified time limit corresponding to that stage; and a judgment step, comprising: when no handshake signal of that stage is detected within the specified time limit, determining that the software startup is abnormal.

[0007] In one embodiment, the determination step further includes: when a handshake signal for the phase is detected within a specified time limit, determining that the software starts normally in that phase.

[0008] In one embodiment, the determination step further includes: when it is determined that the software starts normally at each stage, then the software starts normally.

[0009] In one embodiment, after determining that the software startup is abnormal, the determination step further includes: controlling the software to restart; the method further includes: while the software restarts, re-executing the monitoring step and the determination step until the software startup is determined to be normal.

[0010] In one embodiment, the method further includes a log generation step, comprising: generating a software startup monitoring log based on the monitoring data generated by the monitoring step and the judgment data generated by the judgment step.

[0011] Secondly, the present invention provides a monitoring device for software startup anomalies, comprising: a monitoring module, configured to simultaneously monitor the duration of the software startup process and the handshake signals of each stage of the software startup process, and for each stage of the software startup process, detect the handshake signal of that stage within a specified time limit corresponding to that stage; and a judgment module, configured to determine that the software startup is abnormal when no handshake signal of that stage is detected within the specified time limit.

[0012] Thirdly, the present invention provides an electronic device, including: a processor and a memory, wherein the memory stores program code, and when the program code is executed by the processor, the steps of the software startup anomaly monitoring method described above are performed.

[0013] Fourthly, the present invention provides a software monitoring system, comprising: a watchdog circuit for monitoring whether an abnormality occurs during the operation of the software after startup, and outputting a reset command to control the software to restart when an abnormality occurs during the operation of the software after startup; and an electronic device as described above for monitoring whether an abnormality occurs during the startup of the software, controlling the software to restart when an abnormality occurs during the startup of the software, and transmitting the reset command output by the watchdog circuit to the software to control the software to restart when an abnormality occurs during the operation of the software after startup.

[0014] In one embodiment, the electronic device includes at least one of the following: a field-programmable gate array and a complex programmable logic device.

[0015] Fifthly, the present invention provides an apparatus comprising: a central processing unit for starting and running software; and a software monitoring system as described above for monitoring whether any abnormalities occur in the software in the central processing unit during startup and operation, and controlling the software to restart when an abnormality occurs during startup and / or operation.

[0016] In a sixth aspect, the present invention provides a storage medium storing program code, wherein when the program code is executed by a processor, the steps of the software startup anomaly monitoring method described above are performed.

[0017] The software startup anomaly monitoring method of the present invention determines whether an anomaly has occurred in a given stage of the software startup process by detecting the handshake signal within a specified time limit corresponding to that stage. If no handshake signal is detected, it indicates that not only is that stage of the software startup process abnormal, but the entire software startup process is also abnormal. This method can monitor each stage of the software startup process separately, thereby enabling the detection of anomalies at each stage, accurately locating the anomaly, and improving diagnosability. Attached Figure Description

[0018] The accompanying drawings, which form part of this application, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an undue limitation of the invention. In the drawings:

[0019] Figure 1 A flowchart illustrating a method for monitoring software startup anomalies according to an exemplary embodiment of this application;

[0020] Figure 2 This is a schematic diagram of the structure of a device according to a specific embodiment of this application;

[0021] Figure 3 This is a flowchart of a method for monitoring software startup anomalies according to a specific embodiment of this application. Detailed Implementation

[0022] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0023] Example 1

[0024] This embodiment provides a method for monitoring software startup anomalies. Figure 1 This is a flowchart of a software startup anomaly monitoring method according to an exemplary embodiment of this application. Figure 1 As shown, the method in this embodiment may include:

[0025] S110: Monitoring steps, including: simultaneously monitoring the duration of the software startup process and the handshake signals of each stage of the software startup process; for each stage of the software startup process, detecting the handshake signal of that stage within a specified time limit corresponding to that stage.

[0026] S120: Judgment steps, including: if no handshake signal for this stage is detected within a specified time limit, determine that the software startup is abnormal.

[0027] Within a specified time limit corresponding to a certain stage of the software startup process, the handshake signal for that stage is detected. If no handshake signal is detected, the startup process at that stage is considered abnormal, thus indicating an overall software startup process anomaly. Through these steps, not only can software startup anomalies be identified, but their exact location within the startup process can also be pinpointed. This facilitates targeted analysis and troubleshooting of the anomaly, improving the diagnosability of the software startup process.

[0028] Those skilled in the art can divide the software startup process into multiple stages according to actual needs; the specific number of stages is not limited here. Normally, from the start of software startup, each stage of the software startup process completes sequentially over time. Therefore, each stage of the software startup process requires a corresponding duration, which corresponds one-to-one with each stage. The maximum value of this duration can be set to a specified time limit corresponding to the corresponding stage; of course, other durations can also be set as specified time limits, which are not limited here. Handshake signals are signals that correspond one-to-one with each stage of the software startup process; whether these handshake signals are high / low levels or other signals is not limited here.

[0029] At each stage of the software startup process, anomalies are determined by detecting the handshake signal within a specified time limit for that stage. Regardless of how the software startup process is divided into one or more stages, and regardless of the specific handshake signal, if no handshake signal is detected within the specified time limit corresponding to that stage, it indicates that the startup process at that stage is abnormal, thus achieving anomaly monitoring of the software startup process.

[0030] The judgment steps may also include: when a handshake signal for that stage is detected within a specified time limit, the software is judged to have started normally in that stage; when the software is judged to have started normally in all stages, the software is judged to have started normally.

[0031] After determining that the software startup is abnormal, the judgment steps may further include: controlling the software to restart. The method may also include: while the software restarts, re-executing the monitoring and judgment steps until the software startup is determined to be normal.

[0032] The method may also include a log generation step, which includes generating a software startup monitoring log based on the monitoring data generated by the monitoring step and the judgment data generated by the judgment step, for subsequent querying.

[0033] The software startup anomaly monitoring method of this embodiment determines whether an anomaly occurs in a certain stage of the software startup process by detecting the handshake signal of that stage within a specified time limit corresponding to each stage of the software startup process. When no handshake signal is detected, it indicates that not only is the startup of that stage of the software startup process abnormal, but also that the software startup process is abnormal.

[0034] The method described in this embodiment facilitates rapid self-healing and restarting in the event of software startup anomalies. Traditional software handling can only restart the software after the watchdog timer fails and times out. The method of this invention can monitor for anomalies at each stage of the software startup process, and can immediately restart the software once an anomaly is detected, greatly shortening the self-healing time and reducing the probability of system failure.

[0035] The method in this embodiment improves the diagnosability of the software startup process. Traditional software diagnostic logs record watchdog overflows causing software restarts, but these only identify startup anomalies and cannot pinpoint the exact location of the anomaly, making targeted cause analysis and optimization difficult. The method of this invention monitors each stage of the software startup process separately, enabling precise location of anomalies and improving diagnosability.

[0036] Example 2

[0037] This embodiment provides a monitoring device for software startup anomalies, including: a monitoring module, used to simultaneously monitor the duration of the software startup process and the handshake signals of each stage of the software startup process, and for each stage of the software startup process, to detect the handshake signal of that stage within a specified time limit corresponding to that stage; and a judgment step, used to determine that the software startup is abnormal when no handshake signal of that stage is detected within the specified time limit.

[0038] In this embodiment, the monitoring device for software startup anomalies may further include a processor and a memory. The memory stores program code. When the program code is executed by the processor, a monitoring module and a judgment module are executed to realize the monitoring of anomalies in the software startup process.

[0039] Example 3

[0040] This embodiment provides an electronic device, which may include a processor and a memory. The memory stores program code, and when the program code is executed by the processor, it performs the steps of the software startup anomaly monitoring method described above.

[0041] In one embodiment, an electronic device may include one or more processors, input / output interfaces, network interfaces, and memory.

[0042] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.

[0043] Example 4

[0044] This embodiment provides a software monitoring system, which may include: a watchdog circuit for monitoring whether any abnormalities occur during the operation of the software after startup, and outputting a reset command to control the software to restart when an abnormality occurs during the operation of the software after startup; and an electronic device as described above for monitoring whether any abnormalities occur during the startup of the software, controlling the software to restart when an abnormality occurs during startup, and transmitting the reset command output by the watchdog circuit to the software to control the software to restart when an abnormality occurs during the operation of the software after startup.

[0045] The electronic device includes at least one of the following: field-programmable gate arrays and complex programmable logic devices.

[0046] Example 5

[0047] This embodiment provides a device that may include: a central processing unit (CPU) for starting and running software; and a software monitoring system as described above for monitoring whether any abnormalities occur during the startup and operation of the software in the CPU, and controlling the software to restart when an abnormality occurs during startup and / or operation.

[0048] Example 6

[0049] This embodiment provides a specific implementation of a method for detecting software startup anomalies. Figure 2 This is a schematic diagram of the structure of a device according to a specific embodiment of this application.

[0050] Figure 2 The device 20 includes a Central Processing Unit (CPU) 22 and a software monitoring system 21. The software monitoring system 21 includes a Field Programmable Gate Array (FPGA) 211 and a watchdog timer 212. The FPGA includes a monitoring module 2111 and a self-healing control module 2112. Of course, the FPGA can be replaced by a CPLD (Complex Programmable Logic Device) or other electronic devices capable of performing the corresponding functions.

[0051] In this embodiment, an FPGA is used to monitor the CPU software startup process and control self-healing startup. The monitoring module primarily monitors the handshake signal between the CPU and the FPGA within a specified time limit. The self-healing control module (i.e., the judgment module) quickly generates a reset signal and sends it to the CPU to restart the software if the monitoring module fails to detect the CPU's handshake signal within the specified time limit. The flag can be set by writing to a register based on the handshake signal; alternatively, other suitable methods can be used to detect the handshake signal.

[0052] In this embodiment, the device software startup process can be divided into the following three stages:

[0053] 1) Booting from BSP (Board Support Package);

[0054] 2) Operating system startup;

[0055] 3) Application launch.

[0056] In related technologies, the device only switches the watchdog mode from long mode to short mode after the application starts. Therefore, without a monitoring and rapid self-healing mechanism during software startup, any abnormal software startup will lead to prolonged device malfunction. Thus, it is necessary to monitor each of the three stages of the software startup process separately.

[0057] Monitoring the three phases of software startup mainly includes the following steps:

[0058] (1) When the device starts normally, a timeout value for BSP startup can be set based on experience. This timeout value is the duration required from the start of software startup to the completion of BSP startup. Under normal circumstances, the processor will handshake with the FPGA before the timeout. During the BSP startup phase, the FPGA can be used to monitor whether there is a first handshake signal corresponding to BSP startup before the timeout. If there is, it indicates that BSP startup is normal; if not, it is considered that BSP startup is abnormal. At this time, self-healing restart is initiated, the central processing unit is immediately reset and the counter is cleared to zero, and the cause of the abnormality is recorded. The central processing unit then restarts. When the central processing unit restarts, the abnormal monitoring of the software startup process is performed again.

[0059] (2) Similarly, a timeout value can be set when the operating system starts. This timeout value is the duration required from the start of software startup to the completion of operating system startup. After the BSP starts normally, it continues to monitor for a second handshake signal related to operating system startup. If there is one, it indicates that the operating system startup is normal; if not, it is considered that the operating system startup is abnormal. At this time, it enters a self-healing restart, immediately resets the central processing unit and clears the counter, records the cause of the abnormality, and then the central processing unit starts to restart. When the central processing unit restarts, it re-monitors the abnormality of the software startup process.

[0060] (3) Finally, a timeout value is also set for application startup. This timeout value is the duration required from the start of software startup to the completion of application startup. After the operating system starts normally, it continues to monitor for the third handshake signal related to application startup. If it is present, it indicates that the application startup is normal; if not, it is considered that the application startup is abnormal. At this time, it enters a self-healing restart, immediately resets the central processing unit and clears the counter, records the cause of the abnormality, and then the central processing unit starts to restart. During the central processing unit restart, the abnormal monitoring of the software startup process is performed again.

[0061] Figure 3 This is a flowchart of a software startup anomaly monitoring method according to a specific embodiment of this application, as follows: Figure 3 As shown, the specific process for monitoring the software startup process may include:

[0062] (1) When the device software starts, the three timers of the FPGA start timing simultaneously and monitor the handshake signal of the BSP startup;

[0063] (2) If a handshake signal for BSP startup is detected within the first timeout period, then BSP startup is considered normal.

[0064] (3) If the handshake signal for BSP startup is not detected within the first timeout period, it is diagnosed as a BSP startup abnormality and the cause of the abnormality is recorded. A reset signal that meets the requirements is generated by the self-healing control module and sent to the central processing unit, while the counter is cleared. The central processing unit is immediately restarted and returns to step (1).

[0065] (4) If the BSP starts normally, the FPGA continues to monitor the handshake signal of the operating system startup;

[0066] (5) If a handshake signal for operating system startup is detected within the second timeout period, the operating system startup is considered to be normal.

[0067] (6) If no handshake signal for operating system startup is detected within the second timeout period, the operating system startup is diagnosed as abnormal and the cause of the abnormality is recorded. A reset signal that meets the requirements is generated by the self-healing control module and sent to the central processing unit, while the counter is cleared. The central processing unit is immediately restarted and returns to step (1).

[0068] (7) If the operating system starts normally, the FPGA continues to monitor the handshake signal of the application startup;

[0069] (8) If a handshake signal for application startup is detected within the third timeout period, the application startup is considered to be normal.

[0070] (9) If no handshake signal for application startup is detected within the third timeout period, the application startup is diagnosed as abnormal and the cause of the abnormality is recorded. A reset signal that meets the requirements is generated by the self-healing control module and sent to the central processing unit, while the counter is cleared. The central processing unit is immediately restarted and returns to step (1).

[0071] (10) If the application starts normally, the device software is considered to have started normally, and the central processing unit sets the watchdog timer to short mode.

[0072] Record and save the data generated in steps (1) to (10) to generate a diagnostic log for querying.

[0073] The software startup anomaly monitoring method of this embodiment, by dividing the software startup process of the central processing unit and monitoring the three startup processes separately through the FPGA, has significant advantages, which are reflected in the following aspects:

[0074] (1) Improved diagnosability. Traditional software diagnostic logs record watchdog overflows causing device restarts, but these only indicate an abnormality during startup and cannot pinpoint the exact location of the anomaly, making targeted cause analysis and optimization difficult. This embodiment segments and monitors the startup process separately, enabling precise location of the anomaly and improving diagnosability.

[0075] (2) Improved self-healing speed. Traditional software processing can only restart the device when the watchdog timer fails and times out. This embodiment can monitor whether there are any abnormalities in each startup stage, and can restart immediately once an abnormality occurs, which greatly shortens the self-healing time and reduces the probability of system failure.

[0076] This embodiment can be widely applied in the field of rail transit control and can be promoted to the market outside the railway system, with a very broad prospect.

[0077] Example 7

[0078] This embodiment provides a storage medium storing program code. When the program code is executed by a processor, the steps of the software startup exception monitoring method described above are performed.

[0079] Those skilled in the art will understand that embodiments of the present invention can be provided as methods or computer program products. Therefore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0080] This invention is described with reference to flowchart illustrations of methods and computer program products according to embodiments of the invention. It should be understood that each step in the flowchart and combinations of steps in the flowchart can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing device, generate instructions for implementing the process. Figure 1 A device for a function specified in one or more processes.

[0081] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 The function specified in one or more processes.

[0082] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 Steps of a specified function in one or more processes.

[0083] Storage media, including permanent and non-permanent, removable and non-removable media, can be used to store information by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by computing devices.

[0084] It should be noted that the terminology used herein is for the purpose of describing particular implementations only and is not intended to limit the exemplary implementations according to this application. When the terms “comprising” and / or “including” are used in this specification, they indicate the presence of features, steps, operations, devices, components and / or combinations thereof.

[0085] It should be noted that the terms "first," "second," etc., used in the specification, claims, and drawings of this application are used to distinguish similar objects and are not used to describe a specific order or sequence. It should be understood that such terms can be used interchangeably where appropriate so that the embodiments of this application described herein can be implemented, for example, in sequences other than those illustrated or described herein.

[0086] It should be understood that the exemplary embodiments described herein can be implemented in many different forms and should not be construed as being limited to the embodiments set forth herein. These embodiments are provided so that the disclosure of this application is thorough and complete, and that the concept of these exemplary embodiments is fully conveyed to those skilled in the art, and should not be construed as limiting the invention.

Claims

1. A method of monitoring software startup anomalies, the method comprising: The application is applied to train equipment, the train equipment includes a central processing unit and a software monitoring system, the software monitoring system includes an FPGA and a watchdog, the FPGA includes a monitoring module and a self-recovery control module, the FPGA is used for monitoring a software starting process of the central processing unit and controlling self-recovery starting, the software starting process includes a board support package starting stage, an operating system starting stage and an application program starting stage, and the monitoring method of the software starting exception includes: (1) starting the equipment software, the central processing unit sets the watchdog to a long mode, three timers of the FPGA start timing simultaneously and monitor a handshake signal of the board support package starting; (2) if the handshake signal of the board support package starting is monitored within a first timeout time, the board support package starting is normal; (3) if the handshake signal of the board support package starting is not monitored within the first timeout time, the board support package starting is diagnosed as an exception and an exception reason is recorded, a reset signal meeting a requirement is generated by the self-recovery control module and sent to the central processing unit, the counter is cleared, the central processing unit is restarted immediately and returns to step (1); (4) if the board support package starting is normal, the FPGA continues to monitor a handshake signal of the operating system starting; (5) if the handshake signal of the operating system starting is monitored within a second timeout time, the operating system starting is normal; (6) if the handshake signal of the operating system starting is not monitored within the second timeout time, the operating system starting is diagnosed as an exception and an exception reason is recorded, a reset signal meeting a requirement is generated by the self-recovery control module and sent to the central processing unit, the counter is cleared, the central processing unit is restarted immediately and returns to step (1); (7) if the operating system starting is normal, the FPGA continues to monitor a handshake signal of the application program starting; (8) if the handshake signal of the application program starting is monitored within a third timeout time, the application program starting is normal; (9) if the handshake signal of the application program starting is not monitored within the third timeout time, the application program starting is diagnosed as an exception and an exception reason is recorded, a reset signal meeting a requirement is generated by the self-recovery control module and sent to the central processing unit, the counter is cleared, the central processing unit is restarted immediately and returns to step (1); (10) if the application program starting is normal, the equipment software starting is normal, the central processing unit sets the watchdog to a short mode; data generated in steps (1) to (10) is recorded and saved, a diagnosis log is generated for query to locate a specific position of an exception.

2. An apparatus for monitoring software startup anomalies, comprising: The application is applied to train equipment, the train equipment includes a central processing unit and a software monitoring system, the software monitoring system includes an FPGA and a watchdog, the FPGA includes a monitoring module and a self-recovery control module, the FPGA is used for monitoring a software starting process of the central processing unit and controlling self-recovery starting, the software starting process includes a board support package starting stage, an operating system starting stage and an application program starting stage, and the monitoring method of the software starting exception includes: The monitoring module is used for starting the three timers of the FPGA simultaneously and monitoring the handshake signal of the board support package start in the case that the device software is started and the central processor sets the watchdog to the long mode; if the board support package start is normal, the FPGA continues to monitor the handshake signal of the operating system start; if the operating system start is normal, the FPGA continues to monitor the handshake signal of the application program start; in the case that the device software is started normally, the central processor sets the watchdog to the short mode; the data generated by the monitoring module and the judging module are recorded and saved to generate a diagnosis log for query to locate the specific position of the abnormality; The judging module is used for judging that the board support package start is normal when the handshake signal of the board support package start is monitored within the first timeout time; if the handshake signal of the board support package start is not monitored within the first timeout time, it is diagnosed that the board support package start is abnormal and the abnormal reason is recorded, and a reset signal meeting the requirement is generated by the self-recovery control module and sent to the central processor, and the counter is cleared, the central processor is restarted immediately, the three timers of the FPGA are started simultaneously and the handshake signal of the board support package start is monitored in the case that the device software is started and the central processor sets the watchdog to the long mode; if the handshake signal of the operating system start is monitored within the second timeout time, the operating system start is normal; if the handshake signal of the operating system start is not monitored within the second timeout time, it is diagnosed that the operating system start is abnormal and the abnormal reason is recorded, and a reset signal meeting the requirement is generated by the self-recovery control module and sent to the central processor, and the counter is cleared, the central processor is restarted immediately, the three timers of the FPGA are started simultaneously and the handshake signal of the board support package start is monitored in the case that the device software is started and the central processor sets the watchdog to the long mode; if the handshake signal of the application program start is monitored within the third timeout time, the application program start is normal; if the handshake signal of the application program start is not monitored within the third timeout time, it is diagnosed that the application program start is abnormal and the abnormal reason is recorded, and a reset signal meeting the requirement is generated by the self-recovery control module and sent to the central processor, and the counter is cleared, the central processor is restarted immediately, the three timers of the FPGA are started simultaneously and the handshake signal of the board support package start is monitored in the case that the device software is started and the central processor sets the watchdog to the long mode; if the application program start is normal, the device software start is normal.

3. An electronic device, comprising: It comprises: A processor and a memory, wherein the memory stores program codes, and when the program codes are executed by the processor, the steps of the software start abnormality monitoring method in claim 1 are executed.

4. A software monitoring system, characterized by It comprises: A watchdog circuit used for monitoring whether an abnormality occurs in the running process of software after the software is started, and outputting a reset instruction to control the software to restart when the abnormality occurs in the running process of the software after the software is started. The electronic device of claim 3, wherein the watchdog circuit is configured to monitor whether the software is abnormal during a booting process, to control the software to restart when the software is abnormal during the booting process, and to deliver a reset instruction output by the watchdog circuit to the software to control the software to restart when the software is abnormal during a running process after the booting process.

5. The software monitoring system of claim 4, wherein, The electronic device comprises at least one of the following: a field programmable logic gate array and a complex programmable logic device.

6. An apparatus, comprising: The electronic device comprises at least one of the following: a field programmable logic gate array and a complex programmable logic device. The electronic device comprises at least one of the following: a field programmable logic gate array and a complex programmable logic device. The electronic device comprises at least one of the following: a field programmable logic gate array and a complex programmable logic device.

7. A storage medium, characterized by The electronic device comprises at least one of the following: a field programmable logic gate array and a complex programmable logic device. The electronic device comprises at least one of the following: a field programmable logic gate array and a complex programmable logic device. The electronic device comprises at least one of the following: a field programmable logic gate array and a complex programmable logic device. The electronic device comprises at least one of the following: a field programmable logic gate array and a complex programmable logic device. The electronic device comprises at least one of the following: a field programmable logic gate array and a complex programmable logic device. The electronic device comprises at least one of the following: a field programmable logic gate array and a complex programmable logic device. The electronic device comprises at least one of the following: a field programmable logic gate array and a complex programmable logic device. The electronic device comprises at least one of the following: a field programmable logic gate array and a complex programmable logic device. The electronic device comprises at least one of the following: a field programmable logic gate array and a complex programmable logic device. The electronic device comprises at least one of the following: a field programmable logic gate array and a complex programmable logic device. The electronic device comprises at least one of the following: a field programmable logic gate array and

Images