CN112069020A - Airborne avionics equipment software fault monitoring system based on embedded operating system - Google Patents
Airborne avionics equipment software fault monitoring system based on embedded operating system Download PDFInfo
- Publication number
- CN112069020A CN112069020A CN202010810741.1A CN202010810741A CN112069020A CN 112069020 A CN112069020 A CN 112069020A CN 202010810741 A CN202010810741 A CN 202010810741A CN 112069020 A CN112069020 A CN 112069020A
- Authority
- CN
- China
- Prior art keywords
- interrupt
- monitoring
- monitoring module
- vector number
- system call
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
- G06F11/302—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a software system
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3604—Software analysis for verifying properties of programs
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- Computing Systems (AREA)
- Quality & Reliability (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Mathematical Physics (AREA)
- Software Systems (AREA)
- Computer Hardware Design (AREA)
- Debugging And Monitoring (AREA)
Abstract
The invention discloses an airborne avionics equipment software fault monitoring system based on an embedded operating system, which comprises an interrupt monitoring module operated on a BSP (base station processor), wherein the interrupt monitoring module identifies the current interrupt vector number and sets a flag bit of a non-lost storage area pointed by the interrupt vector number before entering an interrupt service program pointed by the interrupt vector number after a program enters a processor interrupt general entry function; when the interrupt service program exits, clearing the zone bit of the non-lost storage area pointed by the interrupt vector number; the flag bit of the unsettled bit in the non-lost storage area is read to identify which interrupt vector number has failed the interrupt service routine 'dead loop' or 'long blocking'. The invention realizes the monitoring of common software faults in the airborne avionics equipment.
Description
Technical Field
The invention relates to an embedded system, in particular to a software fault monitoring system of airborne avionics equipment in an embedded operating system environment.
Background
With the continuous improvement of the function and performance requirements of the airborne avionics equipment, the design complexity of software and hardware of the airborne avionics equipment is increasingly improved. In the present situation, the normalization and the process management of software can reduce the generation of software problems to a great extent, but cannot avoid the problems. Faults caused by airborne avionics software problems can cause failure of some important functions of the airplane, partial faults are only sporadically caused by the fact that the environment on the airplane is different from the ground simulation environment, great inconvenience is brought to troubleshooting, hidden dangers are brought to continuous use of equipment, and execution of airplane tasks can be seriously influenced. Under the condition, the monitoring capability of the software fault is very important, an important basis can be provided for the rapid positioning of the fault, and the maintainability of the product software layer is improved.
Disclosure of Invention
The invention aims to provide an airborne avionics equipment software fault monitoring system based on an embedded operating system, which is realized by calling an operating system hook function and inserting a BSP (board level support software), and realizes monitoring of common software faults such as pointer and address out-of-bounds access, illegal space access, dead loop, abnormal suspension of task (process), interrupt processing error, zero removal and the like, soft restart, subarea switching error in an ARINC653 operating system, system call (system call) error and the like on the premise of decoupling with an application program.
The invention aims to be realized by the following technical scheme:
an airborne avionics equipment software fault monitoring system based on an embedded operating system comprises an interrupt monitoring module running on a BSP (base station server), wherein the interrupt monitoring module identifies the current interrupt vector number and sets a flag bit of a non-lost storage area pointed by the interrupt vector number before entering an interrupt service program pointed by the interrupt vector number after a program enters a processor interrupt general entry function; when the interrupt service program exits, clearing the zone bit of the non-lost storage area pointed by the interrupt vector number; the flag bit of the unsettled bit in the non-lost storage area is read to identify which interrupt vector number has failed the interrupt service routine 'dead loop' or 'long blocking'.
Preferably, the interrupt monitoring module reads the set occurrence times of the non-lost storage area pointed by the interrupt vector number before the program enters the interrupt service program, and accumulates the set occurrence times; setting an interruption monitoring period, clearing the set occurrence frequency of the non-lost storage area when the interruption monitoring period is triggered, and judging the condition of abnormal frequent triggering of CPU interruption according to whether the set occurrence frequency in the interruption monitoring period exceeds a threshold value.
Preferably, the system further comprises a processor exception monitoring module running in the BSP, and when the processor exception monitoring module monitors that the hook function is called, the processor exception monitoring module records the type of the processor exception event, and simultaneously records stack information, CPU register information, time information, and other BIT detection information of the current task.
Preferably, the system further comprises a soft restart monitoring module running in the BSP, and when the program enters the reboot function, the soft restart monitoring module records the context to the non-lost storage area to complete the storage of the soft restart event information.
Preferably, the system also comprises a system call monitoring module for operating the ARINC653 operating system, wherein the system call monitoring module identifies the current system call vector number when the program enters the system call entry function, and sets the flag bit of the non-lost storage area pointed by the system call vector number; when the system call entry function normally exits, the flag bit clearing of the non-lost storage area pointed by the system call vector number is completed; and setting a system call monitoring period task with priority higher than that of partition scheduling, if the flag bit of a non-lost storage area pointed by a certain system call vector number is identified to be not cleared in the system call monitoring period range, indicating that the system call is in an abnormal state, and recording time, the system call number and system call parameters at the moment.
Preferably, the system also comprises an HM monitoring module aiming at the ARINC653 operating system, aiming at application level faults and based on hook function implementation provided by the operating system, and the recording of HM events and context information is completed when the hook function is triggered.
Preferably, the system further comprises an HM monitoring module aiming at the ARINC653 operating system, and the HM monitoring module is realized based on a hook function provided by the operating system and completes the recording of the HM event and the context information when the hook function is triggered.
Preferably, the system further comprises a task endless loop monitoring module running in the application layer, the task endless loop monitoring module adds an execution count at the end of the monitored task, and simultaneously establishes a monitoring task period, when the monitoring task period is triggered, the judgment of the count is executed, if the count is not changed in the set monitoring task period, the task is considered to have an endless loop, and the current context of the monitored task is recorded.
The invention has the beneficial effects that:
the invention is realized in a software form and is called by BSP software and an application program in a function interface form. The system has certain universality, can support airborne avionics common processors of PowerPC, ARM, MIPS and X86 series, and common airborne operating systems such as VxWorks and Tianmai, can realize the monitoring of common software faults on the premise of decoupling with airborne application programs, can effectively improve the positioning capability of the software faults, and improves the later maintenance efficiency of the software.
Drawings
Fig. 1 is a schematic diagram of the functional distribution of the software fault monitoring system.
FIG. 2 is a flow chart illustrating an interrupt bus entry function of a processor, wherein a dotted line is a monitoring process of an interrupt monitoring module.
Fig. 3 is a schematic diagram of monitoring of a task (process) dead loop monitoring module.
FIG. 4 is a flow chart of a system call global entry function, wherein the dotted line part is the monitoring process of the system call (system call) monitoring module.
Detailed Description
The present invention will be described in further detail with reference to the accompanying drawings and examples.
As shown in fig. 1, the present embodiment provides a software failure monitoring system based on an embedded operating system, which includes a first portion of failure monitoring software functional modules distributed in an application program and a second portion of failure monitoring software functional modules distributed in a BSP. Wherein the first part of the fault monitoring software functional module comprises: a task (process) dead loop monitoring module and an application layer Health monitoring (Health Monitor) module. The method runs on the same layer with the original function module in the application program, and realizes the function by monitoring the global data and function call of the original function module. The second part of the fault monitoring software functional module comprises: the system comprises an interruption monitoring module, a processor exception (exception) monitoring module, a soft restart monitoring module, a BSP Health monitoring (Health Monitor) module and a system call (system call) monitoring module, wherein functions are realized in the BSP in a function call mode. The functional modules are distributed in the BSP or the application program and are called, and finally, the functional modules are integrated with the BSP, the application program and the operating system for use.
Interruption monitoring module
The interruption problem is mainly caused by the following two reasons:
1) the interrupt service routine is in a 'loop-dead' or 'long-time blocking' state;
2) interrupts are frequently triggered due to abnormal causes, resulting in frequent handling of interrupts by the CPU.
These problems may cause the interrupt service routine to always occupy the CPU resources, and the application task (process) cannot be normally executed, thereby causing the product to function abnormally.
According to the analysis of the frequent reasons of the interrupt, the interrupt monitoring module realizes the identification of whether the 'dead cycle' or 'long-time blocking' condition exists or not by adding a 'probe' of an in-out interrupt service program in the BSP (see figure 2).
The BSP has a processor interrupt total entry function for all interrupts of the processor, for example, a handler corresponding to a 0x500 exception vector in the PowerPC is the processor interrupt total entry function, and the interrupt service routine is implemented by entering the corresponding interrupt service routine according to an interrupt vector number after entering the processor interrupt total entry function. The interrupt monitoring module provided by the invention identifies the interrupt vector number of the current time after a program enters a processor interrupt general entry function and before entering an interrupt service program pointed by the interrupt vector number, and calls a universal function interface to complete the flag bit position of a non-lost memory area (NVM) pointed by the interrupt vector number. The interrupt service program is normally executed immediately, and when the interrupt service program exits, the universal function interface is called again to complete the flag bit clearing of the non-lost storage area pointed by the interrupt vector number. Under the condition, after the power-on is finished or when the fault occurs, the fault phenomenon can be combined, whether the zone bit of the non-lost storage area has the unsettled zone bit or not is read, so that the fault of 'dead cycle' or 'long-time blocking' of the interrupt service program is identified, and the service program can be checked in a targeted manner.
In addition, the interrupt monitoring module realizes the monitoring of the condition of 'abnormal frequent triggering' of the interrupt by increasing the interrupt count before entering the interrupt service program in the interrupt general entry function of the processor. Before entering an interrupt service program, acquiring an interrupt vector number, and calling a provided function interface to complete the following work: and reading the set occurrence times of the non-lost storage area pointed by the interrupt vector number, and accumulating. Meanwhile, an interrupt monitoring period (in the invention, the interrupt monitoring period exists in a macro definition form and is defined by a user) is set, the set occurrence frequency of a non-lost storage area is cleared when the interrupt monitoring period is triggered, in this case, the frequency of entering certain interrupt in the interrupt monitoring period can be calculated, a threshold value is set by combining with the actual situation, and the interrupt exceeding the threshold value is considered to have the condition of 'abnormal and frequent triggering of a CPU'.
It should be noted that this interrupt management scheme is recommended to be enabled only during troubleshooting or interrupt fault monitoring, since it will prolong the interrupt processing time.
Processor exception (exception) monitoring module
Common on-board embedded operating systems have processing entries for processor exceptions (exceptions) that are provided to the user in the form of hook functions that are invoked before the embedded operating system kernel performs the exception default operation. The monitoring of the processor exception monitoring module aiming at the processor exception software problem is completed by utilizing a hook function. The hooking of the hook function and the processor abnormity monitoring module is realized in the BSP, and when the processor abnormity monitoring module monitors that the hook function is called, the type of the processor abnormity event is recorded, and simultaneously, the contents of stack information, CPU register information, time information, other BIT detection information and the like of the current task are recorded.
(III) Soft restart monitoring module
When the operating system detects some critical faults (total error), a reboot function is called to complete the restart of the operating system, and in addition, the application program actively calls the reboot function to cause the occurrence of soft restart.
In a common onboard embedded operating system BSP, an operating system generally calls a rebot function, the rebot function completes operations such as interrupt protection, CPU register protection, and Cache shutdown, and points a PC pointer to an initial address to complete a soft restart.
The soft restart monitoring module is realized based on the reboot function, records the context (stack information, CPU register information and time information) to the NVM when entering the reboot function by adopting a BSP code insertion mode, and finishes the storage of soft restart event information.
System call (system call) monitoring module under (four) ARINC653 operating system
In the ARINC653 operating system, a large number of system calls are used by the partition applications to complete core layer (CoreOS) hardware-driven calls and implement bus transceiving, data access, and other functions. If the situation of endless loop or long-time blocking exists in the driving function executed by the system call, the partition scheduling is influenced, and all partition applications can be seriously stopped executing.
The system call (system call) monitoring module implements detection of system call failures by instrumentation code at the BSP or coreOS's system call stub entry function. The implementation method is as shown in fig. 4, when entering the system call entry function, the system call vector number of this time is identified, the flag bit corresponding to the non-lost memory region (NVM) of the system call vector number is set, and when the system call entry function normally exits, the flag bit clearing corresponding to the NVM region of the system call vector number is completed. And meanwhile, starting a system call monitoring period task in the CoreOS, if the condition that the zone bit of the NVM corresponding to a certain system call vector number is not cleared is identified in the system call monitoring period range defined by a user, indicating that the system call is in an abnormal state, and recording information such as time, the system call number, system call parameters and the like for subsequent investigation.
It should be noted that this partition management manner implemented by periodic tasks may reduce the time certainty of the system to some extent, so it is recommended that the system is only started during troubleshooting or special state monitoring, the system call monitoring period should be much longer than the partition scheduling period (1000 times or more recommended), and the task execution time should be much shorter than the partition scheduling period (less than 1ms recommended).
Task (process) endless loop monitoring module
The Task endless loop monitoring module monitors the problem of infinite loop execution of a part of instructions caused by code compiling problem in a Task, and the implementation method is as shown in fig. 3, wherein an execution count (CNT _ A, CNT _ B) is added at the end of a monitored Task (Task _ A, Task _ B in the figure), namely, the monitored Task is counted once after being executed, a monitoring Task period is established, when the monitoring Task period is triggered, judgment of the count (CNT _ A, CNT _ B) is executed, if the count (CNT _ A, CNT _ B) sets that the monitoring Task period is not changed, the Task is considered to have an endless loop, an operating system interface function is called, and recording of the current context of the monitored Task is completed, wherein the record includes contents such as stack information, CPU register information, time information and other BIT detection information.
Health monitoring (Health Monitor) module
Hm (health monitor) is defined in section 2.4 of the ARINC653-1 protocol, and is divided into an application level, a partition level, and a module level for fault detection of applications, operating system software, and hardware. The fault monitoring of the application level can be realized in the form of hook function attachment of an operating system, and the fault monitoring hook processing mode of the partition level and the module level is not defined in the ARINC653-1 and is suggested in the ARINC653-5 protocol. Both partition level and module level fault handling hooks are defined in the HM configuration table.
The Health monitoring (Health Monitor) module is divided into an application layer Health monitoring (Health Monitor) module and a BSP Health monitoring (Health Monitor) module. The application layer Health monitoring (Health Monitor) module is used for monitoring the application layer faults and is realized based on a hook function provided by an operating system. The BSP Health monitoring (Health Monitor) module is realized by adding a definition function in an HM configuration table and modifying the configuration table again aiming at faults of a partition level and a module level. The application layer Health monitoring (Health Monitor) module and the BSP Health monitoring (Health Monitor) module can complete recording of current task stack information, time information and register information when a fault occurs.
It should be understood that equivalents and modifications of the technical solution and inventive concept thereof may occur to those skilled in the art, and all such modifications and alterations should fall within the scope of the appended claims.
Claims (8)
1. The utility model provides an airborne avionics equipment software fault monitoring system based on embedded operating system, contains the interrupt monitoring module of operation on BSP which characterized in that: the interrupt monitoring module identifies the current interrupt vector number and sets the flag bit of the non-lost storage area pointed by the interrupt vector number before the interrupt service program pointed by the interrupt vector number enters after the program enters the processor interrupt general entry function; when the interrupt service program exits, clearing the zone bit of the non-lost storage area pointed by the interrupt vector number; the flag bit of the unsettled bit in the non-lost storage area is read to identify which interrupt vector number has failed the interrupt service routine 'dead loop' or 'long blocking'.
2. The system according to claim 1, wherein the interrupt monitoring module reads the number of occurrences of setting of the non-lost storage area pointed by the interrupt vector number before the program enters the interrupt service program, and accumulates the number; setting an interruption monitoring period, clearing the set occurrence frequency of the non-lost storage area when the interruption monitoring period is triggered, and judging the condition of abnormal frequent triggering of CPU interruption according to whether the set occurrence frequency in the interruption monitoring period exceeds a threshold value.
3. The system according to claim 1, further comprising a processor exception monitoring module operating in the BSP, wherein when the processor exception monitoring module monitors that the hook function is called, the processor exception monitoring module records the type of the processor exception event, and records stack information, CPU register information, and time information of the current task, and other BIT detection information.
4. The software fault monitoring system for airborne avionics equipment based on an embedded operating system according to claim 1, further comprising a soft restart monitoring module operating in the BSP, wherein the soft restart monitoring module records the context to an unreleased memory area when the program enters a reboot function, thereby completing the saving of the soft restart event information.
5. The system according to claim 1, further comprising a system call monitoring module for the ARINC653 operating system, wherein the system call monitoring module identifies the system call vector number of the current time when the program enters the system call entry function, and sets a flag bit of a non-missing storage area pointed by the system call vector number; when the system call entry function normally exits, the flag bit clearing of the non-lost storage area pointed by the system call vector number is completed; and setting a system call monitoring period task with priority higher than that of partition scheduling, if the flag bit of a non-lost storage area pointed by a certain system call vector number is identified to be not cleared in the system call monitoring period range, indicating that the system call is in an abnormal state, and recording time, the system call number and system call parameters at the moment.
6. The system according to claim 1, further comprising an HM monitoring module for ARINC653 operating system, wherein the HM monitoring module is implemented by adding defined functions in an HM configuration table and modifying the configuration table again for partition level and module level failures.
7. The system according to claim 1, further comprising an HM monitoring module for ARINC653 operating system, wherein the HM monitoring module is implemented based on a hook function provided by the operating system for application level faults, and when the hook function is triggered, the HM event and context information are recorded.
8. The system according to claim 1, further comprising a task endless loop monitoring module running in an application layer, wherein the task endless loop monitoring module adds an execution count at the end of a monitored task, establishes a monitoring task period, executes a judgment on the count when the monitoring task period is triggered, determines that an endless loop has occurred in the task if the count does not change within a set monitoring task period, and records a current context of the monitored task.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010810741.1A CN112069020B (en) | 2020-08-13 | 2020-08-13 | Embedded operating system-based on-board avionics software fault monitoring system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010810741.1A CN112069020B (en) | 2020-08-13 | 2020-08-13 | Embedded operating system-based on-board avionics software fault monitoring system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112069020A true CN112069020A (en) | 2020-12-11 |
| CN112069020B CN112069020B (en) | 2023-09-15 |
Family
ID=73661542
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010810741.1A Active CN112069020B (en) | 2020-08-13 | 2020-08-13 | Embedded operating system-based on-board avionics software fault monitoring system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112069020B (en) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112905372A (en) * | 2021-02-02 | 2021-06-04 | 浙江大华技术股份有限公司 | Thread abnormity diagnosis method and device |
| CN114579431A (en) * | 2022-01-27 | 2022-06-03 | 南京航空航天大学 | Zero-removing error detection method based on hybrid analysis |
| CN117056062A (en) * | 2023-10-13 | 2023-11-14 | 武汉天喻信息产业股份有限公司 | Method and device for forcedly exiting interrupt service routine |
Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US3984820A (en) * | 1975-06-30 | 1976-10-05 | Honeywell Information Systems, Inc. | Apparatus for changing the interrupt level of a process executing in a data processing system |
| CN1475911A (en) * | 2003-07-08 | 2004-02-18 | 联想(北京)有限公司 | Method of monitoring machine group system operation procedure and monitoring management device |
| CN101162438A (en) * | 2006-10-10 | 2008-04-16 | 北京中电华大电子设计有限责任公司 | Regulating technology of built-in processor |
| CN103019848A (en) * | 2012-12-25 | 2013-04-03 | 北京航天测控技术有限公司 | Method for realizing peripheral component interconnect (PCI) bus non-vector interrupt |
| CN103544092A (en) * | 2013-11-05 | 2014-01-29 | 中国航空工业集团公司西安飞机设计研究所 | Health monitoring system of avionic electronic equipment based on ARINC653 standard |
| CN104090798A (en) * | 2014-07-08 | 2014-10-08 | 南京大学 | Dynamic and static combined interrupt drive program data race detection method |
| CN105049886A (en) * | 2015-07-10 | 2015-11-11 | Tcl集团股份有限公司 | Method and system for reporting infrared remote controller events |
| CN106227672A (en) * | 2016-08-10 | 2016-12-14 | 中车株洲电力机车研究所有限公司 | A kind of built-in application program fault catches and processing method |
| CN106445791A (en) * | 2016-10-25 | 2017-02-22 | 广东浪潮大数据研究有限公司 | Method for grabbing SAS Switch register data on SAS Switch whole cabinet |
| CN106444425A (en) * | 2016-10-24 | 2017-02-22 | 南京航空航天大学 | Design method of DCS controlled TTP/C bus controller catering to aeroengine |
-
2020
- 2020-08-13 CN CN202010810741.1A patent/CN112069020B/en active Active
Patent Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US3984820A (en) * | 1975-06-30 | 1976-10-05 | Honeywell Information Systems, Inc. | Apparatus for changing the interrupt level of a process executing in a data processing system |
| CN1475911A (en) * | 2003-07-08 | 2004-02-18 | 联想(北京)有限公司 | Method of monitoring machine group system operation procedure and monitoring management device |
| CN101162438A (en) * | 2006-10-10 | 2008-04-16 | 北京中电华大电子设计有限责任公司 | Regulating technology of built-in processor |
| CN103019848A (en) * | 2012-12-25 | 2013-04-03 | 北京航天测控技术有限公司 | Method for realizing peripheral component interconnect (PCI) bus non-vector interrupt |
| CN103544092A (en) * | 2013-11-05 | 2014-01-29 | 中国航空工业集团公司西安飞机设计研究所 | Health monitoring system of avionic electronic equipment based on ARINC653 standard |
| CN104090798A (en) * | 2014-07-08 | 2014-10-08 | 南京大学 | Dynamic and static combined interrupt drive program data race detection method |
| CN105049886A (en) * | 2015-07-10 | 2015-11-11 | Tcl集团股份有限公司 | Method and system for reporting infrared remote controller events |
| CN106227672A (en) * | 2016-08-10 | 2016-12-14 | 中车株洲电力机车研究所有限公司 | A kind of built-in application program fault catches and processing method |
| CN106444425A (en) * | 2016-10-24 | 2017-02-22 | 南京航空航天大学 | Design method of DCS controlled TTP/C bus controller catering to aeroengine |
| CN106445791A (en) * | 2016-10-25 | 2017-02-22 | 广东浪潮大数据研究有限公司 | Method for grabbing SAS Switch register data on SAS Switch whole cabinet |
Non-Patent Citations (3)
| Title |
|---|
| 胡修林, 于峰: "实时嵌入式系统软件的设计和实现机制", 华中科技大学学报(自然科学版), no. 05, pages 53 - 55 * |
| 陈宁;李向东;赵根学;: "机载嵌入式设备中故障管理机制的研究与实现", 微电子学与计算机, vol. 35, no. 01, pages 110 - 114 * |
| 黄东;孙晓民;: "开放式汽车控制平台OpenECU的研究", 微计算机信息, no. 25, pages 121 - 123 * |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112905372A (en) * | 2021-02-02 | 2021-06-04 | 浙江大华技术股份有限公司 | Thread abnormity diagnosis method and device |
| CN114579431A (en) * | 2022-01-27 | 2022-06-03 | 南京航空航天大学 | Zero-removing error detection method based on hybrid analysis |
| CN117056062A (en) * | 2023-10-13 | 2023-11-14 | 武汉天喻信息产业股份有限公司 | Method and device for forcedly exiting interrupt service routine |
| CN117056062B (en) * | 2023-10-13 | 2024-04-02 | 武汉天喻信息产业股份有限公司 | Method and device for forcedly exiting interrupt service routine |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112069020B (en) | 2023-09-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112069020A (en) | Airborne avionics equipment software fault monitoring system based on embedded operating system | |
| US7243267B2 (en) | Automatic failure detection and recovery of applications | |
| US9529694B2 (en) | Techniques for adaptive trace logging | |
| US7930594B2 (en) | Apparatus to preserve trace data | |
| EP0652518B1 (en) | Operating system based performance monitoring of programs | |
| US8286032B2 (en) | Trace messaging device and methods thereof | |
| US8640129B2 (en) | Hardware multithreading systems and methods | |
| US5758168A (en) | Interrupt vectoring for optionally architected facilities in computer systems | |
| JP5905904B2 (en) | Controlling debug exception generation | |
| WO2012016438A1 (en) | Debugger and debugging method thereof | |
| US20080127112A1 (en) | Software tracing | |
| US20170147422A1 (en) | External software fault detection system for distributed multi-cpu architecture | |
| WO2004003748A1 (en) | Method and system to implement a system event log for improved system anageability | |
| JPH05210517A (en) | Method of monitoring time in computer-system and computer-system | |
| US20120304184A1 (en) | Multi-core processor system, computer product, and control method | |
| US11853150B2 (en) | Method and device for detecting memory downgrade error | |
| CN114328102A (en) | Equipment state monitoring method, device, equipment and computer readable storage medium | |
| CN115543740A (en) | Method, system, equipment and storage medium for monitoring abnormal operation of service | |
| US20080162776A1 (en) | Identifying Race Conditions Involving Asynchronous Memory Updates | |
| US5790846A (en) | Interrupt vectoring for instruction address breakpoint facility in computer systems | |
| US5963737A (en) | Interupt vectoring for trace exception facility in computer systems | |
| KR20180134677A (en) | Method and apparatus for fault injection test | |
| JPH02294739A (en) | Fault detecting system | |
| CN113342596A (en) | Distributed monitoring method, system and device for equipment indexes | |
| CN111857689A (en) | Framework, function configuration method of framework, terminal and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |