RTOS-based software operation real-time monitoring method and system

Abstract

The invention provides a real-time operating system (RTOS)-based software operation real-time monitoring method, which comprises the following steps of: configuring monitoring parameters, and reading and analyzing the configured monitoring parameters during power-on; the monitoring parameters at least comprise a real-time monitoring task quantity, a real-time monitoring task priority and a real-time monitoring task exception handling mode; creating a monitoring task according to the monitoring parameters, and performing real-time abnormality judgment on the software; and real-time abnormal information is counted and recorded, and fault processing is carried out according to the monitoring parameters. According to the method, the required resource overhead is relatively low, the influence on the application performance can be neglected, a priority-based preemptive task scheduling mechanism of RTOS is fully utilized, and the real-time monitoring of tasks with different priorities can be quickly realized under the condition of not changing the application, so that the reliable operation of the system is ensured, the fault range is isolated, and the problem reason is positioned.

Description

Technical Field

[0001] The present invention relates to the technical field of embedded operating systems, and in particular to a method and system for monitoring the real-time performance of software running based on a real-time operating system (RTOS). Background Art

[0002] In embedded systems, the real-time performance of applications is crucial. Each task has strict restrictions on the operation and execution time. Exceeding the designed time range may lead to serious consequences. To ensure real-time performance, most embedded software is developed based on a real-time operating system (RTOS).

[0003] At present, there are many real-time testing and evaluation methods for RTOS itself, and the main focus indicators include context switching time, preemption time, interrupt delay time, etc. Good RTOS real-time indicators are the basis of embedded application software real-time, but excellent RTOS real-time performance cannot guarantee that the application program will meet the system real-time indicator requirements. In a complete embedded system, there are basic drivers such as board support package (BSP), bus data transmission and reception, protocol analysis, etc. above RTOS, and the application program is above the basic driver. In addition to RTOS, the driver and application share operating system resources, including memory, tasks, locks, timers, interrupts and other resources. The design method and processing strategy will affect the real-time performance of the entire system, which may cause the embedded system real-time performance to fail to meet the requirements.

[0004] If the embedded software does not meet the real-time requirements, if it is not monitored and processed, it may cause system function failure and affect system reliability. Currently, the most common embedded software operation monitoring is the watchdog daemon. However, the watchdog program focuses on coarse-grained time monitoring and is difficult to use for real-time monitoring, because the watchdog program generally monitors timeouts and dead loops. Triggering the dog bite indicates that the system is in an abnormal fault state, and the watchdog trigger threshold is generally above the second level. The real-time scheduling and processing requirements of software are often in milliseconds or even shorter, and the time accuracy is higher than that of the watchdog. It is difficult to trigger the watchdog reset when the real-time does not meet the design. In addition, the watchdog is generally monitored based on the functional process. A functional process often involves multiple tasks, and the "feeding the dog" code needs to be added to the functional process. Most RTOS use a priority-based task scheduling mechanism. It is difficult to locate which tasks do not meet the requirements based on the monitoring of the functional process. Real-time monitoring needs to be based on task design. Summary of the invention

[0005] In view of the problems existing in the prior art, a method and system for real-time monitoring of software operation based on RTOS are provided, which can ensure that application software developed based on RTOS meets real-time requirements.

[0006] The first aspect of the present invention proposes a method for real-time monitoring of software operation based on RTOS, comprising:

[0007] Configure monitoring parameters, and read and parse the configured monitoring parameters when powered on; the monitoring parameters at least include the number of real-time monitoring tasks, the priority of real-time monitoring tasks, and the abnormal handling method of real-time monitoring tasks;

[0008] Create monitoring tasks based on monitoring parameters and conduct real-time abnormality judgment on the software;

[0009] Collect and record real-time abnormal information and handle faults based on monitoring parameters.

[0010] As a preferred solution, the monitoring parameters also include a real-time monitoring task scheduling period, a real-time monitoring task timeout threshold, and a real-time monitoring task timeout exception count.

[0011] As a preferred solution, the real-time abnormality judgment of the software specifically includes:

[0012] Step 1: Create a monitoring task and initialize the last judgment time to the current time of RTOS;

[0013] Step 2: Call the RTOS interface to delay according to the real-time monitoring task scheduling cycle to release CPU resources;

[0014] Step 3, obtain the current time of RTOS, and determine whether the current time of RTOS minus the last judgment time is greater than the timeout threshold of the real-time monitoring task. If so, proceed to step 4; if not, refresh the last judgment time to the current time of RTOS, and proceed to step 2;

[0015] Step 4: Add one to the number of scheduling timeouts to determine whether the number of scheduling timeouts is greater than or equal to the number of real-time monitoring task timeout exceptions. If so, it indicates that there is a real-time exception. Otherwise, refresh the last judgment time to the current RTOS time and go to step 2.

[0016] As a preferred solution, the statistics and records of real-time exception information include sending time, monitoring task priority, CPU occupancy of all current tasks, cumulative number of exceptions, timeout time and scheduling cycle, which are used for subsequent design improvement or problem positioning.

[0017] As a preferred solution, the real-time monitoring task exception handling method includes prompting, downgrading and restarting.

[0018] As a preferred solution, the fault handling according to the monitoring parameters specifically includes:

[0019] After real-time anomalies are detected, prompts, downgrades or restarts are performed; prompts include printing and recording logs, outputting user real-time anomaly information, but does not affect or interrupt normal business operations; downgrades include printing and recording logs, outputting user real-time anomaly information, issuing real-time anomaly events to applications, and applications downgrading services based on the event information; restarts include printing and recording logs, outputting user real-time anomaly information, issuing real-time restart preparation events to applications, and restarting the system.

[0020] The second aspect of the present invention proposes a software operation real-time monitoring system based on RTOS, comprising:

[0021] A configuration data management module is used to configure monitoring parameters, wherein the monitoring parameters include at least the number of real-time monitoring tasks, the priority of real-time monitoring tasks, the abnormal handling method of real-time monitoring tasks, the scheduling period of real-time monitoring tasks, the timeout threshold of real-time monitoring tasks, and the number of timeout abnormalities of real-time monitoring tasks;

[0022] The monitoring task management module is used to generate monitoring tasks according to monitoring parameters, perform real-time abnormality monitoring on the software, and output abnormality monitoring results;

[0023] Statistics and recording module, used to count and record real-time anomalies and record related information;

[0024] The fault handling module is used to perform corresponding exception handling according to the abnormal detection results and monitoring parameters.

[0025] As a preferred solution, in the monitoring task management module, the specific process of performing real-time abnormality monitoring on the software includes:

[0026] Step A: Create a monitoring task and initialize the last judgment time to the current time of RTOS;

[0027] Step B: Call the RTOS interface to delay according to the real-time monitoring task scheduling cycle to release CPU resources;

[0028] Step C, obtain the current time of RTOS, and determine whether the current time of RTOS minus the last judgment time is greater than the real-time monitoring task timeout threshold. If so, proceed to step D; if not, refresh the last judgment time to the current time of RTOS, and proceed to step B;

[0029] Step D, add one to the number of scheduling timeouts to determine whether the number of scheduling timeouts is greater than or equal to the number of real-time monitoring task timeout exceptions. If so, it indicates that there is a real-time exception. Otherwise, refresh the last judgment time to the current RTOS time and enter step B.

[0030] As a preferred solution, the statistics and recording module records information including sending time, monitoring task priority, CPU occupancy of all current tasks, cumulative number of exceptions, timeout time and scheduling cycle, which is used for subsequent design improvement or problem location.

[0031] As a preferred solution, in the fault handling module, fault handling methods including prompting, downgrading or restarting are executed; wherein prompting includes printing and recording logs, outputting user real-time abnormal information, but does not affect or interrupt normal business operation; downgrading includes printing and recording logs, outputting user real-time abnormal information, issuing real-time abnormal events to applications, and applications performing business downgrading processing according to event information; restarting includes printing and recording logs, outputting user real-time abnormal information, issuing real-time preparation restart events to applications, and restarting the system

[0032] Compared with the prior art, the beneficial effects of adopting the above technical solution are:

[0033] 1. The monitoring task of the present invention requires less resource overhead, has negligible impact on application performance, can be independently implemented and deployed without modifying the application, quickly adds real-time monitoring and exception handling support to the application software, and improves system reliability.

[0034] 2. After detecting a real-time anomaly, the present invention can quickly locate and isolate the problem based on post-analysis means such as recorded information, thereby improving development and maintenance efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Figure 1 This is a flow chart of the real-time monitoring method for software operation based on RTOS proposed by the present invention.

[0036] Figure 2 This is a flow chart of real-time abnormality judgment in an embodiment of the present invention.

[0037] Figure 3 This is a schematic diagram of the real-time monitoring system for software operation based on RTOS proposed by the present invention. DETAILED DESCRIPTION

[0038] Embodiments of the present application are described in detail below, and examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar modules or modules with the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present application, and cannot be construed as limitations on the present application. On the contrary, the embodiments of the present application include all changes, modifications and equivalents that fall within the spirit and connotation of the appended claims.

[0039] Example 1

[0040] In order to realize the real-time online monitoring of application software, and take processing measures such as prompting, recording and restarting when it is detected that the real-time requirements are not met, this embodiment proposes a real-time monitoring method for software operation based on RTOS, please refer to Figure 1 ,include:

[0041] Step 1: Configure monitoring parameters, and read and parse the configured monitoring parameters when powered on.

[0042] In order to improve the flexibility and portability of the monitoring method, in this embodiment, configurable monitoring parameters are provided. When powered on, the software reads and parses the configured monitoring parameters for subsequent real-time monitoring.

[0043] In one embodiment, the monitoring parameters mainly include: (1) the number of real-time monitoring tasks: cfgThreadNum; (2) the priority of the real-time monitoring task: cfgThreadPriorty; (3) the scheduling period of the real-time monitoring task: cfgThreadSchedulePeriod; (4) the timeout threshold of the real-time monitoring task: cfgThreadTimeOut; (5) the number of timeout exceptions of the real-time monitoring task: cfgThreadExceptionNumLimit; (6) the exception handling method of the real-time monitoring task (prompt / downgrade / reset): cfgThreadExceptionPolicy.

[0044] In actual applications, the query and modification of monitoring parameters can be completed through the provided query and modification interfaces.

[0045] Step 2: Create a monitoring task based on the monitoring parameters and perform real-time abnormality judgment on the software.

[0046] In this embodiment, after the real-time monitoring task is created, each monitoring task can determine whether the embedded software has a real-time exception at the specified priority. Since RTOS schedules according to task priority, once a high-priority task is ready, it will immediately preempt the low-priority task to obtain CPU resources. Therefore, through the created real-time monitoring task, according to the real-time judgment logic, it can be determined whether the embedded software has an exception that the application cannot obtain RTOS scheduling. For example, in the process of interrupt triggering, the processing of receiving messages and other scenarios, although the external input or response has arrived, it still cannot be processed in time due to the high driver priority or unreasonable application priority division, and the real-time requirements are not met.

[0047] Furthermore, this embodiment also provides a specific real-time abnormality judgment method, please refer to Figure 2 ,include:

[0048] Step 2.1, create a monitoring task and initialize the last judgment time T lastSchedule is the current time of RTOS. lastSchedule The specific meaning is the time when the RTOS last scheduled to enter this task.

[0049] Step 2.2, according to the real-time monitoring task scheduling period cfgThreadSchedulePeriod, call the RTOS interface to delay and release CPU resources;

[0050] Step 2.3, get the current time T of RTOS current , and determine the current RTOS time T current Subtract the last judgment time T lastSctedule Is it greater than the real-time monitoring task timeout threshold cfgThreadTimeOu? If so, go to step 2.4; if not, set the last judgment time T lastSchedule Refresh to RTOS current time T current , go to step 2.2. In this embodiment, T current Represents the current time after the delay according to the "Real-time monitoring task scheduling period".

[0051] Step 2.4: Scheduling timeout times N exception Add one to determine whether the number of scheduling timeouts is greater than or equal to the number of real-time monitoring task timeout exceptions cfgThreadExceptionNumLimit. If so, it means that the software has a real-time exception. Otherwise, the last judgment time T lastSchedule Refresh to RTOS current time T current , proceed to step 2.2.

[0052] The real-time abnormality judgment logic proposed in this embodiment is simple and consumes little resources.

[0053] Step 3: Count and record real-time abnormal information and handle faults according to monitoring parameters.

[0054] After real-time anomalies are detected, statistics are refreshed and recorded in a file using the best writing method. In one embodiment, the main records include information such as sending time, monitoring task priority, CPU occupancy of all current tasks, number of scheduling timeouts, timeout time, and scheduling cycle, which are used for subsequent design improvement or problem location.

[0055] At the same time, after real-time anomalies are detected, they can be handled according to the configured exception handling method. The fault handling methods generally include prompting, downgrading, and restarting. The details are as follows:

[0056] (1) Prompt: Print and record logs, output real-time abnormal information to users, but do not affect or interrupt normal business operations;

[0057] (2) Downgrade: Print and record logs, output user real-time exception information, send real-time exception events to the application, and the application performs service downgrade processing based on the event information;

[0058] (3) Restart: Print and record logs, output real-time exception information to users, send a real-time restart preparation event to the application, and restart the system.

[0059] The present invention proposes a preemptive task scheduling strategy based on RTOS to realize real-time online monitoring of application software, and when it is monitored that the real-time requirements are not met, processing measures such as prompting, recording and restarting are taken to facilitate subsequent analysis; at the same time, based on a flexible and configurable monitoring strategy, it allows the real-time monitoring of software operation to be quickly realized without changing the application program and without the need for "feeding the dog", providing a universal and portable real-time monitoring method.

[0060] In order to verify the effectiveness of the present invention, a specific verification process is given, and the specific process is as follows:

[0061] The embedded application software to be monitored is developed based on RTOS, which is mainly used for timing control of hardware. The control of hardware adopts synchronous mode. The control message sent to the hardware must wait for the response before the next step of the process can be processed. The process consists of multiple hardware control steps, and the entire process needs to be processed within a fixed time. Under the application software, there are also RTOS, driver and other programs running, and the task priority of RTOS and driver is higher than that of the application. If the high-priority tasks of OS or driver continue to occupy CPU resources, the real-time performance of application software cannot be guaranteed, which will inevitably affect the system function. Therefore, it is necessary to monitor the real-time operation of the software to prompt and isolate the problem.

[0062] According to the OS / driver / application software priority, set up three real-time monitoring tasks, and the configuration is shown in the following table.

[0063]

[0064] Among them, the application software priority is lower than 90, and the OS / driver priority is higher than 90. Therefore, a real-time monitoring task with a priority of 89 is set to monitor the OS / driver real-time performance and isolate OS / driver real-time abnormalities.

[0065] In the application software, the priority range of tasks related to the hardware timing control process is [100,105], and the priority of some tasks is [90,98]. A real-time monitoring task with a priority of 99 is set to isolate the real-time problems of this part of the application tasks.

[0066] To prevent tasks related to the hardware timing control process from excessively occupying CPU resources and affecting other application functions, a real-time monitoring task with a priority of 106 is set to isolate the real-time problems of the hardware timing control process.

[0067] Based on the vxworks operating system, the C language codes for each real-time monitoring task are as follows:

[0068] DWORD t_lastSchdule=tickGet(); / / OS interface, initialize the last task scheduling time

[0069] DWORD t_curTime = tickGet(); / / Initialize current time

[0070] while(1) / / Based on the RTOS priority scheduling strategy, determine whether the configured real-time requirements are met

[0071] {

[0072] taskDelay(cfgThreadSchedulePeriod); / / OS interface delays and releases CPU resources

[0073] t_curTime = tickGet(); / / After the task obtains CPU resources again, get the current time

[0074] if((t_curTime-t_lastSchdule)>cfgThreadTimeOut) / / Judge whether the time interval between the current time and the last scheduling time exceeds the timeout threshold

[0075] {

[0076] / / Real-time exception handling

[0077] }

[0078] else / / Real-time performance meets requirements

[0079] {

[0080] t_lastSchdule = t_curTime;

[0081] }

[0082] }

[0083] The above real-time monitoring code is short, occupies little CPU resources, and has negligible performance impact. It makes full use of the priority-based preemptive task scheduling mechanism of RTOS. It can quickly realize real-time monitoring of tasks of different priorities without changing the application, ensuring reliable operation of the system, isolating the fault scope and locating the cause of the problem.

[0084] For further information, please refer to Figure 3 The embodiment of the present invention further proposes a software running real-time monitoring system based on RTOS, comprising:

[0085] A configuration data management module is used to configure monitoring parameters, wherein the monitoring parameters include at least the number of real-time monitoring tasks, the priority of real-time monitoring tasks, the abnormal handling method of real-time monitoring tasks, the scheduling period of real-time monitoring tasks, the timeout threshold of real-time monitoring tasks, and the number of timeout abnormalities of real-time monitoring tasks;

[0086] The monitoring task management module is used to generate monitoring tasks according to monitoring parameters, perform real-time abnormality monitoring on the software, and output abnormality monitoring results;

[0087] Statistics and recording module, used to count and record real-time anomalies and record related information;

[0088] The fault handling module is used to perform corresponding exception handling according to the abnormal detection results and monitoring parameters.

[0089] In the monitoring task management module proposed in this embodiment, the specific process of real-time abnormality monitoring of software includes:

[0090] Step A: Create a monitoring task and initialize the last judgment time to the current time of RTOS;

[0091] Step B: Call the RTOS interface to delay according to the real-time monitoring task scheduling cycle to release CPU resources;

[0092] Step C, obtain the current time of RTOS, and determine whether the current time of RTOS minus the last judgment time is greater than the real-time monitoring task timeout threshold. If so, proceed to step D; if not, refresh the last judgment time to the current time of RTOS, and proceed to step B;

[0093] Step D, add one to the scheduling timeout count, and determine whether the cumulative count is greater than or equal to the real-time monitoring task timeout exception count. If so, it indicates that there is a real-time exception. Otherwise, refresh the last judgment time to the RTOS current time and enter step B.

[0094] In order to facilitate subsequent design improvements or problem location, information including sending time, monitoring task priority, CPU occupancy of all current tasks, number of scheduling timeouts, timeout time, and scheduling cycle is recorded in the statistics and recording module.

[0095] At the same time, the real-time monitoring system proposed in the present invention also provides a specific fault handling method. In the fault handling module, fault handling methods including prompting, downgrading or restarting are executed; wherein, prompting includes printing and recording logs, outputting user real-time exception information, but does not affect or interrupt normal business operations; downgrading includes printing and recording logs, outputting user real-time exception information, issuing real-time exception events to applications, and the application performs business downgrade processing according to the event information; restarting includes printing and recording logs, outputting user real-time exception information, issuing real-time preparation restart events to applications, and restarting the system.

[0096] In particular, according to an embodiment of the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a computer readable medium, and the computer program includes a program code for executing the method shown in the flowchart.

[0097] It should be noted that the computer-readable medium shown in the embodiment of the present application may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, - but not limited to - an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, a computer-readable storage medium may be any tangible medium containing or storing a program, which may be used by an instruction execution system, device or device or used in combination with it. In the present application, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, wherein a computer-readable program code is carried. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, which may send, propagate, or transmit programs for use by or in conjunction with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wired, etc., or any suitable combination of the above.

[0098] The flowchart and block diagram in the accompanying drawings illustrate the possible architecture, functions and operations of the system, method and computer program product according to various embodiments of the present application. Wherein, each box in the flowchart or block diagram can represent a module, a program segment, or a part of the code, and the above-mentioned module, program segment, or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of boxes in the block diagram or flowchart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0099] The units involved in the embodiments described in this application may be implemented by software or hardware, and the units described may also be set in a processor. The names of these units do not, in some cases, constitute limitations on the units themselves.

[0100] As another aspect, the present application also provides a computer program product or a computer program, which includes a computer instruction stored in a computer-readable storage medium. A processor of a computer device reads the computer instruction from the computer-readable storage medium, and the processor executes the computer instruction, so that the computer device executes the real-time monitoring method for software operation based on RTOS described in the above embodiment.

[0101] As another aspect, the present application also provides a computer-readable medium, which may be included in the electronic device described in the above embodiment; or may exist independently without being assembled into the electronic device. The above computer-readable medium carries one or more programs, and when the above one or more programs are executed by an electronic device, the electronic device implements the RTOS-based software operation real-time monitoring method described in the above embodiment.

[0102] It should be noted that, although several modules or units of the equipment for action execution are mentioned in the above detailed description, this division is not mandatory. In fact, according to the embodiments of the present application, the features and functions of two or more modules or units described above can be embodied in one module or unit. On the contrary, the features and functions of one module or unit described above can be further divided into being embodied by multiple modules or units.

[0103] Through the description of the above implementation methods, it is easy for those skilled in the art to understand that the example implementation methods described here can be implemented by software or by combining software with necessary hardware. Therefore, the technical solution according to the implementation methods of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which can be a personal computer, a server, a touch terminal, or a network device, etc.) to execute the method according to the implementation methods of the present application.

[0104] For those skilled in the art, the specific meanings of the above terms in the present invention can be understood in specific situations; the drawings in the embodiments are used to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Generally, the components of the embodiments of the present invention described and shown in the drawings herein can be arranged and designed in various different configurations.

[0105] Although the embodiments of the present application have been shown and described above, it can be understood that the above embodiments are exemplary and cannot be understood as limitations on the present application. Ordinary technicians in this field can change, modify, replace and modify the above embodiments within the scope of the present application.

Claims

1. A method for monitoring the real-time performance of software operation based on RTOS, characterized in that: include: Configure monitoring parameters, and read and parse the configured monitoring parameters when powered on; the monitoring parameters at least include the number of real-time monitoring tasks, the priority of real-time monitoring tasks, and the abnormal handling method of real-time monitoring tasks; Create monitoring tasks based on monitoring parameters and conduct real-time abnormality judgment on the software; Collect and record real-time abnormal information and handle faults based on monitoring parameters.

2. The method for monitoring the real-time performance of software operation based on RTOS according to claim 1, characterized in that: The monitoring parameters also include a real-time monitoring task scheduling period, a real-time monitoring task timeout threshold, and a real-time monitoring task timeout exception number.

3. The method for monitoring the real-time performance of software operation based on RTOS according to claim 2, characterized in that: The real-time abnormality judgment of the software specifically includes: Step 1: Create a monitoring task and initialize the last judgment time to the current time of RTOS; Step 2: Call the RTOS interface to delay according to the real-time monitoring task scheduling cycle to release CPU resources; Step 3, obtain the current time of RTOS, and determine whether the current time of RTOS minus the last judgment time is greater than the timeout threshold of the real-time monitoring task. If so, proceed to step 4; if not, refresh the last judgment time to the current time of RTOS, and proceed to step 2; Step 4: Add one to the number of scheduling timeouts to determine whether the number of scheduling timeouts is greater than or equal to the number of real-time monitoring task timeout exceptions. If so, it indicates that there is a real-time exception. Otherwise, refresh the last judgment time to the current RTOS time and go to step 2.

4. The method for monitoring the real-time performance of software operation based on RTOS according to claim 1, characterized in that: The statistics and records of real-time abnormal information include sending time, monitoring task priority, CPU occupancy of all current tasks, cumulative number of abnormalities, timeout time and scheduling cycle, which are used for subsequent design improvement or problem location.

5. The method for monitoring the real-time performance of software operation based on RTOS according to claim 1, characterized in that: The real-time monitoring task exception handling methods include prompting, downgrading and restarting.

6. The method for monitoring the real-time performance of software operation based on RTOS according to claim 5, characterized in that: The fault handling according to the monitoring parameters specifically includes: After real-time anomalies are detected, prompts, downgrades or restarts are performed; prompts include printing and recording logs, outputting user real-time anomaly information, but does not affect or interrupt normal business operations; downgrades include printing and recording logs, outputting user real-time anomaly information, issuing real-time anomaly events to applications, and applications downgrading services based on the event information; restarts include printing and recording logs, outputting user real-time anomaly information, issuing real-time restart preparation events to applications, and restarting the system.

7. A software running real-time monitoring system based on RTOS, characterized in that: include: A configuration data management module is used to configure monitoring parameters, wherein the monitoring parameters include at least the number of real-time monitoring tasks, the priority of real-time monitoring tasks, the abnormal handling method of real-time monitoring tasks, the scheduling period of real-time monitoring tasks, the timeout threshold of real-time monitoring tasks, and the number of timeout abnormalities of real-time monitoring tasks; The monitoring task management module is used to generate monitoring tasks according to monitoring parameters, perform real-time abnormality monitoring on the software, and output abnormality monitoring results; Statistics and recording module, used to count and record real-time anomalies and record related information; The fault handling module is used to perform corresponding exception handling according to the abnormal detection results and monitoring parameters.

8. The RTOS-based software operation real-time monitoring system according to claim 7, characterized in that: In the monitoring task management module, the specific process of real-time abnormal monitoring of software includes: Step A: Create a monitoring task and initialize the last judgment time to the current time of RTOS; Step B: Call the RTOS interface to delay according to the real-time monitoring task scheduling cycle to release CPU resources; Step C, obtain the current time of RTOS, and determine whether the current time of RTOS minus the last judgment time is greater than the real-time monitoring task timeout threshold. If so, proceed to step D; if not, refresh the last judgment time to the current time of RTOS, and proceed to step B; Step D, add one to the number of scheduling timeouts to determine whether the number of scheduling timeouts is greater than or equal to the number of real-time monitoring task timeout exceptions. If so, it indicates that there is a real-time exception. Otherwise, refresh the last judgment time to the current RTOS time and enter step B.

9. The RTOS-based software operation real-time monitoring system according to claim 7, characterized in that: The statistics and recording module records information including sending time, monitoring task priority, CPU occupancy of all current tasks, cumulative number of exceptions, timeout time and scheduling cycle, which is used for subsequent design improvement or problem location.

10. The RTOS-based software operation real-time monitoring system according to claim 7, characterized in that: In the fault handling module, fault handling methods including prompting, downgrading or restarting are executed; wherein prompting includes printing and recording logs, outputting user real-time exception information, but does not affect or interrupt normal business operations; downgrading includes printing and recording logs, outputting user real-time exception information, issuing real-time exception events to applications, and the applications perform business downgrade processing according to the event information; restarting includes printing and recording logs, outputting user real-time exception information, issuing real-time preparation restart events to applications, and restarting the system.

Images