CN117539712A - Linux universal fault monitoring method for airborne embedded field - Google Patents
Linux universal fault monitoring method for airborne embedded field Download PDFInfo
- Publication number
- CN117539712A CN117539712A CN202311490534.2A CN202311490534A CN117539712A CN 117539712 A CN117539712 A CN 117539712A CN 202311490534 A CN202311490534 A CN 202311490534A CN 117539712 A CN117539712 A CN 117539712A
- Authority
- CN
- China
- Prior art keywords
- thread
- information
- monitoring
- fault
- operating system
- 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.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 152
- 238000012544 monitoring process Methods 0.000 title claims abstract description 78
- 230000006870 function Effects 0.000 claims description 27
- 230000002159 abnormal effect Effects 0.000 claims description 11
- 230000005856 abnormality Effects 0.000 claims description 4
- 230000026676 system process Effects 0.000 claims description 4
- 238000001514 detection method Methods 0.000 abstract description 3
- 238000003745 diagnosis Methods 0.000 abstract description 3
- 238000007726 management method Methods 0.000 description 28
- 230000006978 adaptation Effects 0.000 description 5
- 238000010586 diagram Methods 0.000 description 5
- 238000013461 design Methods 0.000 description 4
- 230000000737 periodic effect Effects 0.000 description 4
- 230000003068 static effect Effects 0.000 description 4
- 238000012545 processing Methods 0.000 description 3
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000009863 impact test Methods 0.000 description 1
- 230000002035 prolonged effect Effects 0.000 description 1
- 238000013024 troubleshooting Methods 0.000 description 1
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/3013—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is an embedded system, i.e. a combination of hardware and software dedicated to perform a certain function in mobile devices, printers, automotive or aircraft systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3051—Monitoring arrangements for monitoring the configuration of the computing system or of the computing system component, e.g. monitoring the presence of processing resources, peripherals, I/O links, software programs
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3055—Monitoring arrangements for monitoring the status of the computing system or of the computing system component, e.g. monitoring if the computing system is on, off, available, not available
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3466—Performance evaluation by tracing or monitoring
- G06F11/3476—Data logging
-
- 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/362—Software debugging
- G06F11/366—Software debugging using diagnostics
Abstract
The invention provides a Linux general fault monitoring method device oriented to an onboard embedded field, which comprises the following steps: determining the fault type to be monitored; determining corresponding content to be monitored according to the fault type to be monitored; configuring monitoring parameters of the content to be monitored; when determining that the content to be monitored has faults according to the monitoring parameters, recording the faults; the fault types include at least: processor exception monitoring, soft restart monitoring, interrupt monitoring, system call monitoring, CPU state monitoring, memory state monitoring, and running state monitoring. Technical support and support are provided for subsequent fault detection and diagnosis of products based on the Linux operating system.
Description
Technical Field
The invention belongs to the field of airborne embedded systems based on Linux operating systems, and particularly relates to a Linux universal fault monitoring method oriented to the field of airborne embedded systems.
Background
At present, more and more equipment products use a Linux operating system, and the mature Linux ecology is utilized, so that the product functions can be rapidly realized, and the development and transplanting period is greatly reduced.
However, in the Linux environment, once a fault occurs, the fault is difficult to arrange, and the reliability of a product is affected to a certain extent.
Especially for faults which are difficult to reproduce, after monitoring is temporarily added, the external field upgrading is coordinated, the problem is waited for reproduction to finish fault positioning, and in the process, the following problems are encountered:
(1) The fault is not repeated, so that the cause of the fault cannot be defined;
(2) The fault is repeated but the monitoring is not in place, so that the monitoring needs to be increased again, the troubleshooting period is prolonged, and the whole process is stressed by the addition of the outfield and the supervision of authorities.
Disclosure of Invention
The invention provides a Linux general fault monitoring method oriented to the airborne embedded field, which provides technical support and support for subsequent fault detection and diagnosis based on Linux operating system products.
The invention provides a Linux general fault monitoring method oriented to an onboard embedded field, which comprises the following steps:
determining the fault type to be monitored;
determining corresponding content to be monitored according to the fault type to be monitored;
configuring monitoring parameters of the content to be monitored;
when determining that the content to be monitored has faults according to the monitoring parameters, recording the faults;
the fault types include at least: processor exception monitoring, soft restart monitoring, interrupt monitoring, system call monitoring, CPU state monitoring, memory state monitoring, and running state monitoring.
Optionally, the processor exception monitoring corresponding content includes:
instruction acquisition exception, data access exception, instruction execution exception, and bus access exception;
the corresponding recorded fault information includes: abnormality occurrence time, abnormality vector type, TCB information of abnormal threads and general system information;
the TCB information includes: thread name, thread register information, thread stack state, stack content, function call relation of thread, current running core number of thread;
the system general information includes: thread information and operating system process information in the current process; the information of each thread in the current process comprises: each thread list, each thread ID, each thread running state, each thread register information and thread running core number in the process; the information of each process of the operating system comprises: each process list, each process ID, the running state of each process, register information of each process and the like in the operating system.
Optionally, the soft restart monitoring corresponding content includes: the operating system is restarted softly;
the corresponding recorded fault information includes: restarting the generation time, restarting the thread information and the system general information;
the restarting thread information includes: thread name and thread ID;
the system general information includes: restarting the process information of the thread and the process information of the operating system;
the process information of the restarting thread comprises: each thread list, each thread ID, each thread running state and each thread register information in the process;
the information of each process of the operating system comprises: each process list, each process ID, each running state of each process and each process register information in the operating system.
Optionally, the interrupting the monitoring of the corresponding content includes: interrupting the fault;
the corresponding recorded fault information includes: the current system time, the basic information of each process of the current operating system and the triggering times of each fault interrupt;
the interrupt failure includes: the number of interrupts occurring exceeds a preset number and the interrupts are not exited.
Optionally, the system call monitoring corresponding content includes: the system calling program is not exited;
the corresponding recorded fault information includes: current system time, system call parameter information, thread name triggering system call, thread ID.
Optionally, the CPU state monitoring corresponding content includes: the utilization rate of the CPU exceeds the standard;
the corresponding recorded fault information includes: the method comprises the steps of current system time, basic information of each process/thread of an operating system, CPU service conditions of each process/thread and information of the process occupying the highest CPU resource;
the information of the highest process occupying CPU resources comprises: the method comprises the steps of a process name, a process ID, a process running state, process register information, each thread name, each thread ID, each thread running state and each thread running core number in a process.
Optionally, the content corresponding to the memory state monitoring includes: the utilization rate of the memory exceeds the standard;
the corresponding recorded fault information includes: the current system time, the basic information of each process of the current operating system, the memory use condition of each process and the information of the process occupying the highest memory resource;
the information of the highest process occupying the memory resources comprises: the method comprises the steps of a process name, a process ID, a process running state, process register information, each thread name, each thread ID, each thread running state and each thread running core number in a process.
Optionally, the operation state monitoring corresponding content includes: the running states of the processes and threads in the system are abnormal;
the corresponding recorded fault information includes: current system time, crash process/thread name, process/thread ID, register information, stack information, function call stack, process/thread run state
The impact gesture of the device, the mark required by high-speed shooting in the strong impact test process and the like are provided.
The invention provides a Linux general fault monitoring method oriented to the airborne embedded field, which provides technical support and support for subsequent fault detection and diagnosis based on Linux operating system products. Meanwhile, the scheme completes the generalized function adaptation, and the supported Linux operating system mainly comprises the following types: wing Linux operating system versions and kylin operating system versions. The adapted processor types mainly include: feiteng FT2000AHK, feiteng FT2000/4, feiteng D2000, feiteng E2000 processors, and the like.
Drawings
FIG. 1 is a schematic illustration of exception management;
FIG. 2 is a schematic diagram of soft restart management;
FIG. 3 is a schematic diagram of interrupt management;
FIG. 4 is a schematic diagram of system call management;
FIG. 5 is a schematic diagram of CPU/memory state management;
FIG. 6 is a schematic diagram of operational state management.
Detailed Description
In order to make the objects, technical solutions and advantages of the embodiments of the present invention more clear, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. It will be apparent that the described embodiments are some, but not all, embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without making any inventive effort are intended to fall within the scope of the present invention.
Features and exemplary embodiments of various aspects of the invention are described in detail below. In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without some of these specific details. The following description of the embodiments is merely intended to provide a better understanding of the invention by showing examples of the invention. The present invention is in no way limited to any particular arrangement and method set forth below, but rather covers any adaptations, alternatives, and modifications of structure, method, and device without departing from the spirit of the invention. In the drawings and the following description, well-known structures and techniques have not been shown in detail in order not to unnecessarily obscure the present invention.
It should be noted that, without conflict, the embodiments of the present invention and features of the embodiments may be combined with each other, and the embodiments may be referred to and cited with each other. The invention will be described in detail below with reference to the drawings in connection with embodiments.
The present invention will be described in further detail with reference to examples, but embodiments of the present invention are not limited thereto.
The invention provides a Linux general fault monitoring method oriented to the airborne embedded field by combining with the attached drawings.
As shown in fig. 1-6, the present invention provides a Linux general fault monitoring method for an airborne embedded field, which includes the following matters.
1.1Linux operating System failure analysis
Under the condition that the application process is regarded as a black box, failure analysis is carried out on Linux software, and the software failure types can be divided into the following categories: processor exceptions (including process level, kernel level), interrupt faults, soft resets, dead loop faults, system call faults, and the like. Aiming at the failure mode, the scheme designs corresponding fault monitoring software, and the main functions comprise:
(1) Processor exception management;
(2) Soft restart management;
(3) Interrupt management;
(4) Managing system call;
(5) CPU state management;
(6) Managing the memory state;
(7) Running state management
(8) Support to carry on static and dynamic configuration to content, parameter, etc. monitored;
meanwhile, the scheme completes the generalized function adaptation, and the supported Linux operating system mainly comprises the following types: wing Linux operating system versions and kylin operating system versions. The adapted processor types mainly include: feiteng FT2000AHK, feiteng FT2000/4, feiteng D2000, feiteng E2000 processors, and the like.
1.2 processor exception management
Processor exception monitoring monitors processor exception occurrences in the system.
The implementation mode is that an exception handling hook of an operating system is hung, and the storage record of exception information is realized in the exception handling hook.
The monitored anomalies include:
1) Instruction acquisition exception;
2) Data access anomalies;
3) Instruction execution exception;
4) Bus access exceptions.
The 4 exceptions may be process level exceptions or kernel level exceptions.
When an abnormal condition exists, monitoring information required for facilitating subsequent analysis is provided:
1) Abnormal occurrence time;
2) An anomaly vector type;
3) The task control block TCB information of the abnormal thread comprises thread names, thread register information, thread stack states, stack contents, function call relations of the thread, a thread current running core number and the like;
4) The system general information specifically comprises:
information of each thread in the current process: each thread list, each thread ID, each thread running state, each thread register information, thread running core number and the like in the process;
operating system process information: each process list, each process ID, the running state of each process, register information of each process and the like in the operating system.
5) Custom information:
the universal interface function is provided, and content to be acquired and recorded, such as acquisition of external information of temperature, voltage and the like, can be customized in the interface function according to requirements, and when an operating system is abnormal, the interface function can be automatically called, so that the recording of the customized information is realized.
1.3 Soft restart management
The restarting management realizes the acquisition and recording of the resetting mode and the fault information before resetting, and is used for fault positioning and fault analysis.
The implementation mode is that the operating system is hung on a system restart hook, and the restart monitoring information is stored and recorded in the hook.
Under the condition of soft reset, the restarting condition in the system is monitored, and monitoring information required by restarting condition analysis is acquired and stored:
1) Restarting the time of occurrence
2) Restarting thread information including thread name, thread ID, etc.;
3) The system general information specifically comprises:
restarting the process information of the thread: each thread list, each thread ID, each thread running state, each thread register information and the like in the process; operating system process information: each process list, each process ID, the running state of each process, register information of each process and the like in the operating system.
4) Custom information:
the universal interface function is provided, and the content to be acquired and recorded, such as temperature, voltage and other external information, can be customized in the interface function according to the requirements, and can be automatically called when the operating system is in soft reset, so that the user-defined information can be recorded.
1.4 interrupt management
The interrupt management realizes the monitoring of the interrupt condition of the current system, and when the interrupt frequency of a certain interrupt source of the system exceeds a set threshold value in a period of time, or the interrupt service routine is not exited for a long time, the interrupt fault is considered to occur, and the monitoring of the condition of the operating system is completed.
The implementation method is that corresponding hooks are added in the total entry function and the total exit function of the interrupt processing of the operating system, whether the interrupt times exceed a set threshold value is judged in the total entry function of the interrupt processing, and whether the interrupt service routine is not exited for a long time is judged in the total exit function of the interrupt processing.
The recorded content includes:
1) Current system time
2) Basic information of each process of the current operating system, triggering times of interruption of each fault and the like;
3) Custom information: such as temperature, voltage, etc.
The implementation mode of acquiring the custom information is to provide a general call script, and the content to be acquired and recorded can be customized in the script according to the requirement. When the interrupt times of a certain interrupt source exceeds a threshold value, the script is automatically called, so that the user-defined information is recorded.
1.5 System call management
The system call management mainly completes the monitoring of the system call of the user state of the operating system, and when the condition of endless circulation or overlong time occurs in the system call, the information acquisition and recording are completed.
The implementation mode is to add corresponding hooks in the total entry function and the total exit function of the system call of the operating system. If the total entry function is entered but the total exit function is not entered beyond a set time threshold, then the system call is considered to have a dead loop or an excessive time.
The information recorded by the system call comprises:
1) Current system time;
2) The system calls each parameter information;
3) Triggering the thread name, the thread ID and the like of the system call;
1.6 CPU/memory State management
The CPU resource management realizes the monitoring of the current CPU use condition, and when the CPU use rate exceeds the set threshold value, the monitoring record of the operating system condition is completed. The CPU utilization includes the CPU utilization of the process and the CPU utilization of the thread. When the CPU utilization rate exceeds the set threshold value, the monitoring of the CPU utilization condition of the operating system is completed
The memory resource management realizes the monitoring of the current memory use condition, and when the memory use rate exceeds the set threshold value, the monitoring of the memory condition of the operating system is completed.
The implementation mode is that a periodic task is started in the background of an operating system, CPU utilization rate and memory utilization rate are periodically obtained, and when the CPU utilization rate and the memory utilization rate exceed a set threshold value, the recording of related information is completed.
The content of the CPU state management record includes:
1) Current system time
2) Basic information of each process/thread of operating system, CPU service condition of each process/thread
3) The information of the highest process occupying CPU resources comprises a process name, a process ID, a process running state, process register information, thread names, thread IDs, thread running states, thread running core numbers and the like.
4) Custom information: the general call script is provided, and the content to be acquired and recorded, such as the temperature, the voltage and other external information, can be customized in the script according to the requirements, and when the CPU resource exceeds the threshold value, the script can be automatically called, so that the record of the customized information is realized.
The content of the memory state management record comprises:
1) Current system time
2) Basic information of each process of the current operating system and memory use condition of each process
3) The information of the highest process occupying the memory resources comprises a process name, a process ID, a process running state, process register information, thread names, thread IDs, thread running states, thread running core numbers and the like.
4) Custom information: the general calling script is provided, the content to be acquired and recorded, such as the temperature, the voltage and other external information, can be customized in the script according to the requirements, and when the memory resource exceeds the threshold value, the script can be automatically called, so that the recording of the customized information is realized.
1.7 run State management
The system running state management is mainly used for periodically monitoring the running states of key processes and threads in the system, and when abnormal states such as stopping and exiting of the running states of the processes and threads in the system occur, the acquisition and recording of fault information of fault processes and threads are completed.
The implementation mode is that a periodic task is started in the background of the operating system, the running state of the operating system is periodically obtained, and when abnormal states such as stop and exit of processes and threads in the system occur, the recording of related information is completed.
The recorded content includes:
1) Current system time;
2) Fault process/thread name, process/thread ID, register information, stack information, function call stack, process/thread running status, etc
3) Custom information: the general calling script is provided, and the content to be acquired and recorded, such as the temperature, voltage and other external information, can be customized in the script according to the requirements, and can be automatically called when the running states of the key process and the thread are abnormal, so that the recording of the customized information is realized.
Meanwhile, in order to monitor the system stop condition caused by the stop operation of the operating system or the power supply problem, the system running state management designs a background periodic task with high priority in the kernel, the background periodic task periodically acquires and updates the current running time of the system, and when the system does not update the running time of the system any more, the failure of the kernel of the operating system or the underlying CPU hardware is judged.
1.8 generalized code implementation
And the Linux-based general fault monitoring software supports static and dynamic configuration management on monitored contents, monitored parameters and the like.
The static configuration management function is to read the configuration file under the appointed directory before the general fault management software runs, so as to realize the static configuration of each monitoring function.
The dynamic configuration refers to that the configuration of the general fault management software is changed dynamically through a Linux command in the running process of the general fault management software, so that the dynamic configuration of each monitoring function is realized.
Meanwhile, a corresponding adaptation layer is added through software, so that generalized function adaptation is realized, and the supported Linux operating system mainly comprises the following types: wing Linux operating system versions and kylin operating system versions. The adapted processor types mainly include: feiteng FT2000AHK, feiteng FT2000/4, feiteng D2000, feiteng E2000 processors, and the like.
Currently, under the Linux operating system in our project, the problem that the fault monitoring capability of a product end is insufficient, and the design problem is solved, so that the problem is seamless and circulated is generally existed. Especially for faults which are difficult to reproduce, after monitoring is temporarily increased, the external field is coordinated, and the problem is waited for reproduction to finish fault positioning.
Based on the method, in order to improve maintainability and fault location capability of products, the method monitors and records common fault phenomena in the products based on Linux software ecology, combines and records state information of other operating systems and hardware modules, and simultaneously considers the adaptability of application on various operating systems, processors and hardware platforms, thereby realizing a set of universal fault management software based on Linux 'three-conversion' version.
The software is adapted as factory settings in all subsequent model products and will be managed as CBB and iterated continuously as testability requirements, hardware testability design capabilities are improved. The software improves maintainability of equipment products based on the Linux operating system, and has wide application scenes.
The above description is merely a further embodiment of the present invention, but the protection scope of the present invention is not limited thereto, and any person skilled in the art will be able to apply equivalents and modifications according to the technical solution and the concept of the present invention within the scope of the present invention disclosed in the present invention.
Claims (8)
1. The Linux general fault monitoring method for the airborne embedded field is characterized by comprising the following steps of:
determining the fault type to be monitored;
determining corresponding content to be monitored according to the fault type to be monitored;
configuring monitoring parameters of the content to be monitored;
when determining that the content to be monitored has faults according to the monitoring parameters, recording the faults;
the fault types include at least: processor exception monitoring, soft restart monitoring, interrupt monitoring, system call monitoring, CPU state monitoring, memory state monitoring, and running state monitoring.
2. The method for monitoring Linux universal faults in an embedded field on board according to claim 1, wherein the content corresponding to processor anomaly monitoring comprises:
instruction acquisition exception, data access exception, instruction execution exception, and bus access exception;
the corresponding recorded fault information includes: abnormality occurrence time, abnormality vector type, TCB information of abnormal threads and general system information;
the TCB information includes: thread name, thread register information, thread stack state, stack content, function call relation of thread, current running core number of thread;
the system general information includes: thread information and operating system process information in the current process; the information of each thread in the current process comprises: each thread list, each thread ID, each thread running state, each thread register information and thread running core number in the process; the information of each process of the operating system comprises: each process list, each process ID, the running state of each process, register information of each process and the like in the operating system.
3. The method for monitoring Linux universal faults in an embedded field on board according to claim 1, wherein the content corresponding to soft restart monitoring comprises: the operating system is restarted softly;
the corresponding recorded fault information includes: restarting the generation time, restarting the thread information and the system general information;
the restarting thread information includes: thread name and thread ID;
the system general information includes: restarting the process information of the thread and the process information of the operating system;
the process information of the restarting thread comprises: each thread list, each thread ID, each thread running state and each thread register information in the process;
the information of each process of the operating system comprises: each process list, each process ID, each running state of each process and each process register information in the operating system.
4. The method for monitoring Linux universal faults in an embedded field on board according to claim 1, wherein the content corresponding to the interrupt monitoring comprises: interrupting the fault;
the corresponding recorded fault information includes: the current system time, the basic information of each process of the current operating system and the triggering times of each fault interrupt;
the interrupt failure includes: the number of interrupts occurring exceeds a preset number and the interrupts are not exited.
5. The method for monitoring Linux universal faults in an embedded field on board according to claim 1, wherein the system call monitoring corresponding content comprises: the system calling program is not exited;
the corresponding recorded fault information includes: current system time, system call parameter information, thread name triggering system call, thread ID.
6. The method for monitoring Linux universal faults in an embedded field on board according to claim 1, wherein the content corresponding to the CPU state monitoring comprises: the utilization rate of the CPU exceeds the standard;
the corresponding recorded fault information includes: the method comprises the steps of current system time, basic information of each process/thread of an operating system, CPU service conditions of each process/thread and information of the process occupying the highest CPU resource;
the information of the highest process occupying CPU resources comprises: the method comprises the steps of a process name, a process ID, a process running state, process register information, each thread name, each thread ID, each thread running state and each thread running core number in a process.
7. The method for monitoring Linux universal faults in an embedded field on board according to claim 1, wherein the content corresponding to the memory state monitoring comprises: the utilization rate of the memory exceeds the standard;
the corresponding recorded fault information includes: the current system time, the basic information of each process of the current operating system, the memory use condition of each process and the information of the process occupying the highest memory resource;
the information of the highest process occupying the memory resources comprises: the method comprises the steps of a process name, a process ID, a process running state, process register information, each thread name, each thread ID, each thread running state and each thread running core number in a process.
8. The method for monitoring Linux universal faults in an embedded field on board according to claim 1, wherein the operation state monitoring corresponding content comprises: the running states of the processes and threads in the system are abnormal;
the corresponding recorded fault information includes: current system time, crash process/thread name, process/thread ID, register information, stack information, function call stack, process/thread running status.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311490534.2A CN117539712A (en) | 2023-11-09 | 2023-11-09 | Linux universal fault monitoring method for airborne embedded field |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311490534.2A CN117539712A (en) | 2023-11-09 | 2023-11-09 | Linux universal fault monitoring method for airborne embedded field |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN117539712A true CN117539712A (en) | 2024-02-09 |
Family
ID=89781763
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311490534.2A Pending CN117539712A (en) | 2023-11-09 | 2023-11-09 | Linux universal fault monitoring method for airborne embedded field |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117539712A (en) |
-
2023
- 2023-11-09 CN CN202311490534.2A patent/CN117539712A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| WO2022160756A1 (en) | Server fault positioning method, apparatus and system, and computer-readable storage medium | |
| US8776028B1 (en) | Virtual execution environment for software delivery and feedback | |
| JP5176837B2 (en) | Information processing system, management method thereof, control program, and recording medium | |
| CN109656742B (en) | Node exception handling method and device and storage medium | |
| WO2023115999A1 (en) | Device state monitoring method, apparatus, and device, and computer-readable storage medium | |
| CN103092746A (en) | Positioning method and system for thread anomaly | |
| CN111324423B (en) | Method and device for monitoring processes in container, storage medium and computer equipment | |
| US10528110B2 (en) | Method for diagnosing power supply failure in a wireless communication device | |
| CN111813646B (en) | Method and device for injecting application probe in docker container environment | |
| CA2904253A1 (en) | Computer system using in-service software upgrade | |
| CN109976886B (en) | Kernel remote switching method and device | |
| CN106997313B (en) | Signal processing method and system of application program and terminal equipment | |
| CN115543740A (en) | Method, system, equipment and storage medium for monitoring abnormal operation of service | |
| US20230409391A1 (en) | Thread priority adjusting method, terminal, and computer-readable storage medium | |
| CN112069020A (en) | Airborne avionics equipment software fault monitoring system based on embedded operating system | |
| CN113220535A (en) | Method, device and equipment for processing program exception and storage medium | |
| CN117539712A (en) | Linux universal fault monitoring method for airborne embedded field | |
| CN116795576A (en) | Log printing-based device driver debugging method and device and electronic device | |
| CN115934390A (en) | Method and system for processing application program crash and device for running application program | |
| CN115237728A (en) | Visual monitoring method for real-time operating system running state | |
| CN111966599B (en) | Virtualization platform reliability testing method, system, terminal and storage medium | |
| CN114911578A (en) | Storage system monitoring and fault collecting method and device, terminal and storage medium | |
| CN112905375A (en) | Self-recovery method and device of double-core intelligent ammeter management unit and computer equipment | |
| CN117093630B (en) | Dynamic output method for abnormal log of vehicle-mounted system | |
| CN113836035B (en) | Battery management system testing method and device and electronic equipment |
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 |