Running state recording and event analysis system based on embedded operating system

Abstract

This invention relates to a runtime status recording and event analysis system based on an embedded operating system, belonging to the field of embedded system testing. This invention achieves the recording and acquisition of runtime status for control events, task events, semaphore events, message queue events, timer events, and other extended and user-defined events. It also enables the uploading and analysis of the acquired events, ultimately displaying the event information and the event interaction sequence during the embedded system application's execution graphically in the development environment interface. Furthermore, this invention employs methods such as controlling the amount of data collected, combining dynamic and static buffer allocation, configurable upload tasks, and timestamp-driven drivers to reduce external interference, effectively ensuring the real-time requirements of the embedded operating system.

Description

Technical Field

[0001] This invention belongs to the field of embedded system testing, specifically relating to a system for recording and analyzing the running status of an embedded operating system. Background Technology

[0002] In recent years, with the rapid development of embedded technology, embedded products have been widely used in many fields such as aviation, aerospace, communications, and military. The demand for testing and analysis of embedded products has also gradually increased. There is an urgent need for a system for recording and analyzing the running status of embedded operating systems, which can collect and store multiple digital signals, analyze the collected signals, and intuitively display the timing relationship between the signals, so as to facilitate the analysis and location of abnormal problems.

[0003] More complex embedded real-time software systems are built on top of a real-time operating system (RTOS), which manages the system's resources. By recording when and how an application uses which system calls, and how the ROS schedules the application, we can understand how a real-time system actually operates.

[0004] Current operational status recording and event analysis software suffers from low versatility and inconvenient operation, necessitating the development of products with simpler structures and more stable performance to upgrade the existing software. Summary of the Invention

[0005] (a) Technical problems to be solved

[0006] The technical problem to be solved by this invention is how to provide a runtime status recording and event analysis system based on an embedded operating system, so as to solve the problems of low universality and inconvenient operation of existing runtime status recording and event analysis software.

[0007] (II) Technical Solution

[0008] To address the aforementioned technical problems, this invention proposes a runtime status recording and event analysis system based on an embedded operating system. The system includes: a network and serial port transmission module, an event message upload task, a buffer management module, an event acquisition module, an event recording module, a data analysis and processing module, an interface display module, and a parameter configuration module.

[0009] The network and serial port transmission module, located on the target machine, is used to transmit data collected by the target machine to the host machine via serial port or network, and to transmit control commands from the host machine to the target machine via serial port or network.

[0010] The event message upload task, located on the target machine, is used to transmit the event collection information recorded in the buffer management module to the host machine through a dedicated upload task;

[0011] The buffer management module, located on the target machine, manages the buffer where event messages are stored and is used for the allocation, release, and use of the buffer.

[0012] The event acquisition module, located on the target machine, is used to collect specified event attributes and timestamp information of the event occurrence, and store this information in the buffer management module.

[0013] The event logging module, located on the host machine, is used to receive the collected events, display the collection results on the interface display module, and store the collection results in a file for processing by the data analysis and processing module.

[0014] The data analysis and processing module, located on the host machine, is used to analyze and process the collected event information, and to provide feedback on the running status of each task and the switching relationship between running tasks and other events.

[0015] The interface display module, located on the host machine, is used to display the status diagram and status table;

[0016] The parameter configuration module, located on the host machine, is used to send control commands from the host machine back to the event logging module and the event acquisition module, in order to select the transmission mode and acquisition control method.

[0017] (III) Beneficial Effects

[0018] This invention proposes a runtime status recording and event analysis system based on an embedded operating system. It records and collects runtime status data for control events, task events, semaphore events, message queue events, timer events, and other extended and user-defined events. The system uploads and analyzes the collected events, ultimately displaying the event information and the event interaction sequence during the embedded system application's execution graphically in the development environment interface. Furthermore, this invention employs methods such as controlling the amount of data collected, combining dynamic and static buffer allocation, configurable upload tasks, and a timestamp-driven driver to reduce external interference and effectively ensure the real-time requirements of the embedded operating system. Attached Figure Description

[0019] Figure 1 This is a system architecture diagram of the present invention. Detailed Implementation

[0020] To make the objectives, contents, and advantages of the present invention clearer, the specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples.

[0021] The purpose of this invention is to propose a runtime status recording and event analysis system based on an embedded operating system. This system can be used to collect, count, and display various events generated on the embedded operating system (such as control events, task events, semaphore events, message queue events, and timer events), provide the event information required for analyzing the performance of the embedded operating system, analyze the collected events, and provide a visual graphical display window to display the analysis results. The system is divided into eight modules to realize the runtime status recording and event analysis of the embedded operating system. This software can both display the interaction relationships between related tasks, interrupts, and system objects of the application running on the embedded operating system and ensure that the real-time performance of the embedded operating system is not affected.

[0022] This invention provides a runtime status recording and event analysis system based on an embedded operating system, aiming to offer a visualized analysis approach. By analyzing various collected events, the system can understand the interactions between tasks and interrupt routines. This method graphically displays the event interaction sequences during the execution of the embedded system application by uploading the analyzed event data to the interface display module in the development environment.

[0023] Due to the real-time nature of embedded operating systems, the collected data cannot be processed on the target machine system alone; it needs to be transmitted to another host machine for post-processing. Therefore, the implementation of an embedded operating system-based runtime status recording and event analysis system is accomplished in two collaborative parts. One part is implemented on the target machine, primarily for recording runtime status, while the other part is implemented on the host machine, primarily for event analysis. The entire system's functions include test data collection, transmission, analysis, and communication and collaboration between the target and host machines.

[0024] The workflow of the embedded operating system-based runtime status recording and event analysis system is as follows: Figure 1Specifically, the target machine of this invention runs on a domestically developed embedded operating system. Various events on the target machine (including control events, task events, semaphore events, and timer events) are acquired and timestamped by an event acquisition module added to the kernel layer of the domestic embedded operating system. The recorded events are placed in a buffer management module, and the recorded event acquisition information is uploaded to the host machine via an event message upload task. The host machine is integrated into the development environment IDE. Upon receiving events acquired from the target machine, the event recording module added to the host machine IDE displays the acquisition results on the host machine IDE's interface display module and stores the acquisition results from the target machine in a file. Events are read, and the data analysis and processing module analyzes and processes the acquired events, displaying the processed analysis results on the interface display module.

[0025] This invention, a runtime status recording and event analysis system based on an embedded operating system, mainly consists of eight software modules, such as... Figure 1 As shown. Among them,

[0026] The network and serial port transmission module, located on the target machine, is used to transmit data collected by the target machine to the host machine via serial port or network, and to transmit control commands from the host machine to the target machine via serial port or network.

[0027] The event message upload task, located on the target machine, is used to transmit the event collection information recorded in the buffer management module to the host machine through a dedicated upload task.

[0028] The buffer management module, located on the target machine, manages the buffer where event messages are stored and is used for the allocation, release, and use of the buffer.

[0029] The event acquisition module, located on the target machine, is used to collect specified event attributes and timestamp information of the event occurrence, and store this information in the buffer management module.

[0030] The event logging module, located on the host machine, is used to receive collected events and, on the one hand, display the collected results on the interface display module, and on the other hand, store the collected results in a file for processing by the data analysis and processing module.

[0031] The data analysis and processing module, located on the host machine, is used to analyze and process the collected event information, and to provide feedback on the running status of each task and the switching relationship between running tasks and other events.

[0032] The interface display module, located on the host machine, is used to display the status diagram and status table;

[0033] The parameter configuration module, located on the host machine, is used to send control commands from the host machine back to the event logging module and the event acquisition module, in order to select the transmission mode and acquisition control method.

[0034] The target machine of this invention runs on a domestically developed embedded operating system. Since the target machine acquires data through an event acquisition module, this can interfere with the domestically developed embedded operating system under test. This interference must be controlled within a certain range; otherwise, the test results will be meaningless. Since this interference occurs entirely on the target machine, the program on the target machine should be as concise as possible, performing functions that can only be implemented on the target machine, while other functions are performed on the host machine.

[0035] Following this functional division approach, the target machine is responsible for data acquisition and transmission, while complex post-analysis functions are handled by the host machine. Communication and collaboration between the target and host machines are implemented using a client-server model. There are two types of communication between the target and host machines:

[0036] One type involves control commands initiated by the host machine, which are executed and responded to by the target machine. In this case, the target machine is the server and the host machine is the client.

[0037] Another method involves the target machine initiating the transmission of collected data, which is then received by the host machine. In this case, the target machine is the client and the host machine is the server.

[0038] The key challenge for the embedded operating system kernel on the target machine is to collect as much test information as possible while minimizing interference with the target system. This is mainly achieved through the following four aspects:

[0039] (1) By providing a variety of acquisition and control methods, the amount of data acquired can be precisely controlled.

[0040] The data acquisition and control methods of this invention are divided into a hierarchical acquisition method and a classification acquisition method. The hierarchical acquisition method divides the data to be acquired into three levels: events that cause context switching in the domestically produced embedded operating system under test are classified as the first level; events that cause changes in task status are classified as the second level; and all acquired events are classified as the third level. Users can select the acquisition level according to their needs, thereby controlling the amount of data acquired.

[0041] The categorized data collection method classifies system call events into control events, task events, semaphore events, and timer events. Control events include interrupt control events; task events include task creation, deletion, start, restart, suspension, and wake-up; semaphore events include creation, deletion, acquisition, and release; message queue events include creation, deletion, sending, emergency sending, broadcasting, receiving, and refresh; and timer events include creation, deletion, cancellation, delayed start, scheduled start, and reset. Users can choose to collect one or more of these event categories to precisely control the amount of data collected.

[0042] Furthermore, after collecting event data using different acquisition methods, this invention divides the event data into blocks according to time periods and uses an index table to store the starting address of the data blocks for each time period. Then, it uses an index-sequential search algorithm to query the corresponding stored data, which greatly reduces the amount of data that needs to be queried and significantly reduces the query time.

[0043] (2) Use a combination of dynamic and static buffer allocation in memory management to balance the contradiction between memory and time occupied by event acquisition.

[0044] A portion of the target machine's memory is used as a buffer to store the collected data. To improve memory utilization, a dynamic memory allocation strategy is employed: more memory is allocated when there is a large amount of data to collect, and the memory space is released to the embedded operating system when the data is idle, allowing other parts of the program to use it. However, dynamic memory allocation is a time-consuming operation, consuming more CPU time on the target machine and creating unusable memory fragments. Therefore, frequent allocation and release of small memory blocks can cause new temporal and spatial interference to the target machine. This invention addresses these contradictions by combining dynamic and static memory management techniques. The entire buffer storing the collected data is divided into equal-sized buffer blocks, with a minimum and maximum number of buffer blocks available for user selection. Users can dynamically allocate memory by configuring the size of each buffer block, the minimum number of buffer blocks, and the maximum number of buffer blocks.

[0045] (3) Use a dedicated upload task for data transmission, and make the priority, timing and method of the upload task configurable to reduce the interference of the upload activity on the original target machine system.

[0046] For example, the upload task can be prioritized by lowering its priority so that the upload only occurs when the embedded operating system on the target machine is relatively idle. Alternatively, data can be uploaded after data acquisition is complete, thus preventing data upload activity from affecting the target machine during data acquisition. The transmission methods of this invention are divided into three types: delayed transmission, continuous transmission, and post-transmission.

[0047] Delayed transmission mode means that after the parameter configuration module on the host IDE sends the start capture command, the target machine sends back data in real time. The host IDE saves the data in the file of the event logging module until the parameter configuration module on the host IDE sends the stop capture command. At this time, the data saved in the file of the event logging module is uploaded to the interface display module.

[0048] Continuous transmission mode means that once the event acquisition module on the target machine starts collecting data, it sends the collected data to the event logging module on the host machine's IDE. When the collected data accumulates to a certain level, the IDE automatically uploads it to the interface display module, and the IDE pops up a chart window.

[0049] Post-event analysis mode refers to the host machine's IDE parameter configuration module sending a start capture command and continuing to capture until the target machine needs to restart, at which point the host machine's IDE sends a stop capture command. Once the target machine restarts and reconnects to the host machine, the host machine's IDE event logging module uploads data from the user-specified memory region to the interface display module, and a chart window pops up on the IDE.

[0050] (4) Using timestamps to drive the program. Obtaining the system's current time accuracy when an event occurs is crucial. Embedded operating systems running on the target machine use two types of timestamps: the first is called a sequence number, where the event time is not the actual moment it occurred, but merely the order in which events occurred. The second is the actual time of occurrence, which requires higher clock precision. In this invention, the high-precision clock is implemented using a hardware counter. The hardware counter counts continuously until it overflows, generating an interrupt upon overflow, and then restarts counting from the beginning. This method not only ensures high counting accuracy but also reduces the frequency of interrupts, minimizing disruption to the system.

[0051] Key points of this invention:

[0052] (1) Operation status recording and real-time event acquisition technology based on multiple acquisition and control methods

[0053] This invention employs multiple acquisition and control methods to reduce interference with the target system and ensure real-time acquisition. Furthermore, this invention stores event data in blocks according to time periods, using an index table to store the starting address of each time period's data block, and employing an index-sequential search algorithm, which greatly improves query speed.

[0054] (2) Memory management method based on a combination of dynamic and static buffer allocation

[0055] To balance the conflict between memory and time consumption in event acquisition, this invention employs a memory management method that combines dynamic and static buffer allocation. Users can select configuration parameters to dynamically allocate memory, which improves memory utilization and ensures the real-time performance of the embedded operating system.

[0056] Effects of the invention:

[0057] This invention enables the recording and acquisition of the runtime status of control events, task events, semaphore events, message queue events, timer events, and other extended and user-defined events. It also enables the uploading and analysis of the acquired events, ultimately displaying the event information and the event interaction sequence during the embedded system application's execution graphically in the development environment interface. Furthermore, this invention employs methods such as controlling the amount of data collected, combining dynamic and static buffer allocation, configurable upload tasks, and timestamp-driven programming to reduce external interference, effectively ensuring the real-time requirements of the embedded operating system.

[0058] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the technical principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A runtime status recording and event analysis system based on an embedded operating system, characterized in that, The system includes: a network and serial port transmission module, an event message upload task, a buffer management module, an event acquisition module, an event logging module, a data analysis and processing module, an interface display module, and a parameter configuration module; The network and serial port transmission module, located on the target machine, is used to transmit data collected by the target machine to the host machine via serial port or network, and to transmit control commands from the host machine to the target machine via serial port or network. The event message upload task, located on the target machine, is used to transmit the event collection information recorded in the buffer management module to the host machine through a dedicated upload task; The buffer management module, located on the target machine, manages the buffer where event messages are stored and is used for the allocation, release, and use of the buffer. The event acquisition module, located on the target machine, is used to collect specified event attributes and timestamp information of the event occurrence, and store this information in the buffer management module. The event logging module, located on the host machine, is used to receive the collected events, display the collection results on the interface display module, and store the collection results in a file for processing by the data analysis and processing module. The data analysis and processing module, located on the host machine, is used to analyze and process the collected event information, and to provide feedback on the running status of each task and the switching relationship between running tasks and other events. The interface display module, located on the host machine, is used to display the status diagram and status table; The parameter configuration module, located on the host machine, is used to send control commands from the host machine back to the event logging module and the event acquisition module, and to select the transmission mode and acquisition control method. in, The event acquisition module uses a layered acquisition method, which divides the data to be collected into three levels: events that cause context switching in the domestically produced embedded operating system under test are classified as the first level; events that cause changes in task status are classified as the second level; and all collected events are classified as the third level. Users can select the acquisition level according to their needs, thereby controlling the amount of data collected. The event acquisition module uses a categorized acquisition method, classifying system call events into control events, task events, semaphore events, and timer events. Control events include interrupt control events; task events include task creation, deletion, start, restart, suspension, and wake-up events; semaphore events include creation, deletion, acquisition, and release events; message queue events include creation, deletion, sending, emergency sending, broadcasting, receiving, and refresh events; and timer events include creation, deletion, cancellation, delayed start, scheduled start, and reset events. Users can select one or more of these event categories to precisely control the amount of data collected. After collecting event data using different acquisition methods, the event data is divided into blocks according to time periods and stored. An index table is used to store the starting address of the data block for each time period, and then an index-sequential search algorithm is used to query the corresponding stored data.

2. The system for recording and analyzing runtime status based on an embedded operating system as described in claim 1, characterized in that, The target machine runs on a domestically developed embedded operating system. Various events on the target machine are acquired and timestamped by an event acquisition module added to the kernel layer of the domestic embedded operating system. The recorded events are placed in a buffer management module, and the collected event information is uploaded to the host machine via an event message upload task. The host machine is integrated into the development environment IDE. After receiving events acquired from the target machine, the event recording module added to the host machine IDE displays the acquisition results on the host machine IDE's interface display module. Simultaneously, the acquisition results from the target machine are stored in a file. Events are read, and the data analysis and processing module analyzes and processes the acquired events, displaying the processed analysis results on the interface display module.

3. The system for recording and analyzing runtime status based on an embedded operating system as described in claim 1, characterized in that, The communication and collaboration between the target machine and the host machine is implemented using a client-server model.

4. The system for recording and analyzing runtime status based on an embedded operating system as described in claim 3, characterized in that, There are two types of communication between the target machine and the host machine: Control commands initiated by the host machine are executed and responded to by the target machine. In this case, the target machine is the server and the host machine is the client. Another method involves the target machine initiating the transmission of collected data, which is then received by the host machine. In this case, the target machine is the client and the host machine is the server.

5. The system for recording and analyzing runtime status based on an embedded operating system as described in claim 1, characterized in that, The system divides the entire buffer storing the collected data into buffer blocks of equal size, and provides a minimum number of buffer blocks and a maximum number of buffer blocks for users to choose from; users can dynamically allocate memory by configuring the size of each buffer block, the minimum number of buffer blocks, and the maximum number of buffer blocks.

6. The system for recording and analyzing runtime status based on an embedded operating system as described in claim 5, characterized in that, The system has three transmission methods: delayed transmission, continuous transmission, and post-transmission. Delayed transmission mode means that after the parameter configuration module on the host machine IDE sends the start capture command, the target machine sends back data in real time. The host machine IDE saves the data in the file of the event logging module until the parameter configuration module on the host machine IDE sends the stop capture command. At this time, the data saved in the file of the event logging module is uploaded to the interface display module. Continuous transmission mode means that once the event acquisition module on the target machine starts collecting data, it sends the collected data to the event recording module on the host machine's IDE. When the collected data accumulates to a certain level, the IDE automatically uploads it to the interface display module, and the IDE pops up a chart window. Post-event analysis mode refers to the host machine's IDE parameter configuration module sending a start capture command and continuing to capture until the target machine needs to restart, at which point the host machine's IDE sends a stop capture command. After the target machine restarts and reconnects to the host machine, the host machine's IDE event logging module uploads the user-specified memory area data to the interface display module, and the IDE pops up a chart window.

7. The system for recording and analyzing runtime status based on an embedded operating system as described in claim 1, characterized in that, The system uses timestamps to drive the program. The high-precision clock is implemented through a hardware counter. The hardware counter counts continuously until it overflows, generating an interrupt when it overflows, and then starts counting from the beginning again.

Images