Method, device, equipment, medium and product for monitoring an embedded system

Abstract

This application provides a monitoring method, apparatus, device, medium, and product for embedded systems. The method includes: collecting execution events at multiple levels during the operation of the embedded system, where each level's execution events include a start event and an end event; decomposing the continuous execution time stream into a set of discrete execution segments based on the multiple levels of execution events to obtain an execution timeline list, wherein each execution segment in the set of discrete execution segments includes at least its level, start time, end time, and preempted execution segment identifier, preemptor identifier, and preemption depth; and determining the net execution time and preemption time of a target execution instance based on the obtained execution timeline list. This method aims to improve the accuracy of embedded system performance analysis and optimization decision-making.

Description

Technical Field

[0001] This application relates to the field of embedded system technology, and in particular to a monitoring method, apparatus, device, medium and product for embedded systems. Background Technology

[0002] With the rapid development of automotive electronics, industrial control and other fields, the functions of embedded real-time systems are becoming increasingly complex. Accurate analysis of the execution time of embedded real-time systems has become a key requirement for ensuring system real-time performance and optimizing performance.

[0003] Existing embedded system monitoring methods typically employ the Hook mechanism provided by the operating system. During task scheduling, the PreHook and PostHook functions are used to record the entry and exit events of the task, and the timestamps of the collected events are stored in the log. In post-event analysis, the total execution time of the task is obtained by traversing the log, matching the entry and exit event pairs of the task, and calculating the time difference.

[0004] However, in automotive electronic control units that conform to the AUTOSAR standard, the software architecture exhibits multi-level characteristics such as interrupt layer, task layer, and runnable layer. Existing methods can only monitor the execution time of the task layer and can only output the summary time value of the task, which can easily lead to fuzzy positioning of performance bottlenecks and limited monitoring results, thereby further reducing the accuracy of system analysis results. Summary of the Invention

[0005] This application provides methods, devices, equipment, media, and products for monitoring embedded systems, in order to improve the accuracy of embedded system performance analysis and the efficiency of problem localization.

[0006] In a first aspect, embodiments of this application provide a monitoring method for an embedded system, including:

[0007] Collect execution events at multiple levels during the operation of the embedded system. The execution events include the start and end events of each level.

[0008] For each level of execution event, the continuous execution time stream is dynamically divided into a set of discrete execution segments based on the occurrence of preemption. Each execution segment includes at least the level to which the execution segment belongs, the start time and the end time, as well as the identifier of the preempted execution segment, the identifier of the preemptor, and the preemption depth.

[0009] Based on the set of execution fragments, determine the net execution time and preemption time of the target execution instance, which is a single execution process determined by a pair of start and end events.

[0010] Optionally, execution events at multiple levels during the operation of the embedded system can be collected, specifically including:

[0011] Record the interrupt start event at the interrupt service routine entry point and the interrupt end event at the interrupt service routine exit point;

[0012] Record task start and task end events at task switching points;

[0013] Record the runnable start event before execution at the runnable layer, and record the runnable end event after execution at the runnable layer;

[0014] Each execution event record includes an event type, an identifier, and a timestamp; the event types include interrupt start event, interrupt end event, task start event, task end event, runnable start event, and runnable end event; the timestamp is used to record the time when the execution event occurred.

[0015] Optionally, for any execution event, the event type of the execution event is obtained from the record corresponding to the execution event, and the level to which the execution event belongs is determined based on the event type;

[0016] Among them, interrupt start event and interrupt end event correspond to the interrupt layer; task start event and task end event correspond to the task layer; and runnable start event and runnable end event correspond to the runnable layer.

[0017] Optionally, for each level of execution event, the continuous execution time stream is dynamically divided into a set of discrete execution segments based on the occurrence of preemption, specifically including:

[0018] Process each event in multiple levels of execution events based on timestamp order;

[0019] Initialize an active execution instance list and an execution timeline list; the active execution instance list stores execution instances that are currently executing but have not yet finished, and the execution timeline list stores generated execution segments; when any start event is processed, if the active execution instance list is not empty, generate an execution segment for the first execution instance at the end of the active execution instance list to record the continuous execution time preempted by the second execution instance corresponding to the start event; add the generated execution segment to the execution timeline list, and add the second execution instance to the end of the active execution instance list;

[0020] When any termination event is encountered, the active execution instance list is traversed to find an execution instance that matches both the level and identifier of the termination event. An execution fragment is generated for the found execution instance, added to the execution timeline list, and the found execution instance is removed from the active execution instance list.

[0021] Optionally, after removing the found execution instance from the list of active execution instances, if the list of active execution instances is still not empty after removal, the start time of the execution segment of the execution instance at the end of the list of active execution instances is updated to the timestamp of the end event, so as to record the start time of the execution instance at the end of the list of active execution instances resuming execution.

[0022] Optionally, an execution fragment is generated for the first execution instance located at the end of the list of active execution instances, specifically including:

[0023] Create an execution fragment. The start time of the execution fragment is the start time of the execution fragment of the first execution instance at the end, the end time is the timestamp of the start event, the preemptor identifier is the identifier of the start event, the preempted execution fragment identifier is the identifier of the first execution instance, and the preemption depth is the length of the list of active execution instances.

[0024] Optionally, an execution fragment is generated for the found execution instance, specifically including:

[0025] Create an execution fragment. The start time of the execution fragment is the start time of the execution fragment of the found execution instance, and the end time is the timestamp of the end event. The identifier of the preempted execution fragment is the identifier of the found execution instance. The preemptor identifier is empty, and the preemption depth is the length of the list of active execution instances.

[0026] Optionally, based on the execution timeline list, the net execution time of the target execution instance is calculated, specifically including:

[0027] Retrieve all execution fragments belonging to the target execution instance from the execution timeline list, wherein the identifier of the preempted execution fragment belonging to the target execution instance is the same as the identifier of the target execution instance;

[0028] From all the obtained execution fragments, determine the start timestamp of the target execution instance as the start time of the first execution fragment of the target execution instance, and determine the end timestamp of the target execution instance as the end time of the last execution fragment of the target execution instance;

[0029] The net execution time of the target execution instance is obtained by summing the durations of all the acquired execution segments; where the duration of each execution segment is obtained by subtracting the start time from the end time of the execution segment.

[0030] Optionally, the preemption time of the target execution instance is calculated, specifically including:

[0031] The total execution time of the target execution instance is calculated based on the difference between the start timestamp and the end timestamp of the target execution instance.

[0032] The preemption time of the target execution instance is determined based on the total execution time and net execution time of the target execution instance.

[0033] Optionally, after calculating the net execution time and preemption time of all execution instances, an execution record set containing performance data of all execution instances is generated, wherein each execution record includes at least the execution instance identifier, net execution time, total execution time, preemption time, and position index of the execution instance in the execution timeline list. The position index is used to backtrack and obtain detailed information of each execution segment of the execution instance.

[0034] Perform Top N analysis on the execution record set, sort in descending order by net execution time, extract a preset number of execution instances with the longest net execution time, generate and output an analysis report, which includes the performance metrics and location information of the execution records corresponding to the preset number of execution instances.

[0035] Optionally, Top N analysis includes at least one of the following patterns:

[0036] System-wide sorting refers to extracting a preset number of execution instances with the longest global net execution time from the execution records of all levels;

[0037] Grouping and sorting by level refers to extracting a preset number of execution instances with the longest net execution time from the execution records of each level.

[0038] Grouping and sorting by execution instance refers to grouping multiple execution records of the same execution instance and extracting a preset number of execution instances with the longest net execution time.

[0039] Secondly, embodiments of this application provide a monitoring device for an embedded system, comprising:

[0040] The acquisition module is used to collect execution events at multiple levels during the operation of the embedded system. The execution events include the start event and the end event of each level.

[0041] The processing module is used to dynamically divide the continuous execution time stream into a set of discrete execution segments based on the occurrence of preemption for each level of execution event. Each execution segment includes at least the level to which the execution segment belongs, the start time and the end time, as well as the identifier of the preempted execution segment, the identifier of the preemptor, and the preemption depth.

[0042] The processing module is also used to determine the net execution time and preemption time of the target execution instance based on the set of execution fragments. The target execution instance is a single execution process determined by a pair of start events and end events.

[0043] Optionally, the acquisition module is also used to record the interrupt start event at the interrupt service routine entry point and the interrupt end event at the interrupt service routine exit point;

[0044] Record task start and task end events at task switching points;

[0045] Record the runnable start event before execution at the runnable layer, and record the runnable end event after execution at the runnable layer;

[0046] Each execution event record includes an event type, an identifier, and a timestamp; the event types include interrupt start event, interrupt end event, task start event, task end event, runnable start event, and runnable end event; the timestamp is used to record the time when the execution event occurred.

[0047] Optionally, the acquisition module is also used to, for any given execution event, retrieve the event type of the execution event from the record corresponding to the execution event, and determine the level to which the execution event belongs based on the event type;

[0048] Among them, interrupt start event and interrupt end event correspond to the interrupt layer; task start event and task end event correspond to the task layer; and runnable start event and runnable end event correspond to the runnable layer.

[0049] Optionally, the processing module is also used to process each event in the execution events of multiple levels based on the timestamp order;

[0050] Initialize an active execution instance list and an execution timeline list; the active execution instance list stores execution instances that are currently executing but have not yet finished, and the execution timeline list stores generated execution segments; when any start event is processed, if the active execution instance list is not empty, generate an execution segment for the first execution instance at the end of the active execution instance list to record the continuous execution time preempted by the second execution instance corresponding to the start event; add the generated execution segment to the execution timeline list, and add the second execution instance to the end of the active execution instance list;

[0051] When any termination event is encountered, the active execution instance list is traversed to find an execution instance that matches both the level and identifier of the termination event. An execution fragment is generated for the found execution instance, added to the execution timeline list, and the found execution instance is removed from the active execution instance list.

[0052] Optionally, the processing module is further configured to, after removing the found execution instance from the list of active execution instances, update the start time of the execution segment of the execution instance at the end of the list of active execution instances to the timestamp of the end event if the list of active execution instances is still not empty after removal, so as to record the start time of the execution instance at the end of the list of active execution instances resuming execution.

[0053] Optionally, the processing module is also configured to create an execution fragment, wherein the start time of the execution fragment is the start time of the execution fragment of the last execution instance, the end time is the timestamp of the start event, the preemptor identifier is the identifier of the start event, the preempted execution fragment identifier is the identifier of the first execution instance, and the preemption depth is the length of the list of active execution instances.

[0054] Optionally, the processing module is also used to create an execution fragment, the start time of which is the start time of the execution fragment of the found execution instance, the end time of which is the timestamp of the end event, the identifier of the preempted execution fragment is the identifier of the found execution instance, the preemptor identifier is empty, and the preemption depth is the length of the list of active execution instances.

[0055] Optionally, the processing module is also configured to retrieve all execution segments belonging to the target execution instance from the execution timeline list, wherein the identifier of the preempted execution segment belonging to the target execution instance is the same as the identifier of the target execution instance;

[0056] From all the obtained execution fragments, determine the start timestamp of the target execution instance as the start time of the first execution fragment of the target execution instance, and determine the end timestamp of the target execution instance as the end time of the last execution fragment of the target execution instance;

[0057] The net execution time of the target execution instance is obtained by summing the durations of all the acquired execution segments; where the duration of each execution segment is obtained by subtracting the start time from the end time of the execution segment.

[0058] Optionally, the processing module is also used to calculate the total execution time of the target execution instance based on the difference between the start timestamp and the end timestamp of the target execution instance;

[0059] The preemption time of the target execution instance is determined based on the total execution time and net execution time of the target execution instance.

[0060] Optionally, the processing module is also used to generate a set of execution records containing performance data of all execution instances after calculating the net execution time and preemption time of all execution instances. Each execution record includes at least the execution instance identifier, net execution time, total execution time, preemption time, and position index of the execution instance in the execution timeline list. The position index is used to backtrack and obtain detailed information of each execution segment of the execution instance.

[0061] Perform Top N analysis on the execution record set, sort in descending order by net execution time, extract a preset number of execution instances with the longest net execution time, generate and output an analysis report, which includes the performance metrics and location information of the execution records corresponding to the preset number of execution instances.

[0062] Optionally, Top N analysis includes at least one of the following patterns:

[0063] System-wide sorting refers to extracting a preset number of execution instances with the longest global net execution time from the execution records of all levels;

[0064] Grouping and sorting by level refers to extracting a preset number of execution instances with the longest net execution time from the execution records of each level.

[0065] Grouping and sorting by execution instance refers to grouping multiple execution records of the same execution instance and extracting a preset number of execution instances with the longest net execution time.

[0066] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0067] The memory stores the instructions that the computer executes;

[0068] The processor executes computer execution instructions stored in memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0069] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0070] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0071] The embedded system monitoring method, apparatus, device, medium, and product provided in this application, by collecting start and end events at multiple levels, achieves complete monitoring of the execution behavior of the interrupt layer, task layer, and runnable layer, overcoming the limitation of traditional Hook mechanisms that can only monitor the task layer. By decomposing the continuous execution time stream into a set of discrete execution segments containing preemption context information, it provides a data foundation for refined performance analysis. By calculating the net execution time and preemption time based on the set of execution segments, it achieves two-dimensional performance analysis, which can accurately distinguish whether the performance bottleneck of the target execution instance is due to low algorithm efficiency or frequent preemption. It effectively solves the problems of existing technologies that can only monitor the execution time of the task layer, have difficulty distinguishing between net execution time and preemption time, and lead to vague performance bottleneck positioning and unclear optimization direction, thereby improving the accuracy of embedded system performance analysis and optimization decision-making. Attached Figure Description

[0072] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0073] Figure 1 A schematic diagram illustrating a scenario for the monitoring method of the embedded system provided in this application;

[0074] Figure 2 Flowchart of the monitoring method for the embedded system provided in this application Figure 1 ;

[0075] Figure 3 Flowchart of the monitoring method for the embedded system provided in this application Figure 2 ;

[0076] Figure 4 Flowchart of the monitoring method for the embedded system provided in this application Figure 3 ;

[0077] Figure 5 Flowchart of the monitoring method for the embedded system provided in this application Figure 4 ;

[0078] Figure 6 Flowchart of the monitoring method for the embedded system provided in this application Figure 5 ;

[0079] Figure 7 A schematic diagram of the structure of the monitoring device for the embedded system provided in this application;

[0080] Figure 8 A schematic diagram of the structure of the electronic device provided in this application.

[0081] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0082] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0083] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with the relevant laws, regulations, and standards of the relevant regions, have taken necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation portals for users to choose to authorize or refuse.

[0084] In modern automotive electronic control systems, embedded systems based on the AUTOSAR architecture (such as engine control units (ECUs) and body domain controllers) undertake complex real-time task scheduling and execution management. These systems typically contain multi-level execution units: the Interrupt Service Response (ISR) layer, the Task layer, and the Runnable layer. The ISR layer, used to respond to external hardware events (such as crankshaft speed signals and sensor data readiness interrupts), has the highest priority and can preempt other execution units. The Task layer, under the management of the operating system scheduler, executes periodic or event-triggered functional logic (such as fuel injection control logic and communication protocol stack processing) according to priority or time slices. The Runnable layer consists of schedulable functional modules within tasks in the AUTOSAR architecture, actively invoked by the task. For example, when task A in the Task layer actively calls the fuel injection parameter calculation module in the Runnable layer, the runnable execution time of the fuel injection parameter calculation module belongs to task A, but can be preempted by tasks in the ISR layer or with higher priority.

[0085] Because embedded systems based on the AUTOSAR architecture have high real-time requirements, developers need to accurately analyze the execution time of each level in order to optimize task priority configuration, avoid delays caused by interrupt preemption, and locate performance bottlenecks.

[0086] Existing methods for analyzing execution time at various levels typically rely on the task scheduler's hook mechanism (e.g., the task entry monitoring function PreHook and the task exit monitoring function PostHook). These hooks are only invoked during task switching to monitor the execution time of the Task layer. However, this monitoring mechanism has fundamental limitations: PreHook and PostHook can only be invoked during task scheduling, making it difficult to invoke them when hardware interrupts are triggered. Therefore, it can only monitor the Task layer scheduled by the task scheduler, making it difficult to actually monitor the execution time of the ISR layer, and it does not support monitoring of the Runnable layer. In addition, attempting to add monitoring code directly to the ISR layer introduces additional interrupt latency, which reduces the real-time performance of the ISR due to the measurement behavior itself. Similarly, for the Runnable layer, due to its fine-grained execution and high call frequency, using traditional timestamp recording methods would result in significant data storage and transmission overhead, leading to a degraded system performance.

[0087] As can be seen from the above scenarios, current technologies that only monitor the execution time of the Task layer are insufficient to cover the dynamic behavior of the ISR and Runnable layers, and lack recording of execution segments. This makes it difficult to effectively locate bottlenecks in the Runnable layer or quantify the impact of the ISR layer on system real-time performance. This technological limitation is particularly prominent in modern automotive electronic systems with increasingly complex functions and the prevalence of multi-core processors.

[0088] The embedded system monitoring method provided in this application collects multiple levels of execution events during the operation of the embedded system. These multiple levels of execution events include interrupt start events (ISR start events) and interrupt end events (ISR end events), task start events and task end events, and runnable start events and runnable end events. Based on these multiple levels of execution events, the continuous execution time stream is dynamically divided into a set of discrete execution segments. Each execution segment in the set of discrete execution segments includes at least its level, start time, end time, preempted execution instance identifier, preemptor identifier, and preemption depth information. Based on the set of discrete execution segments, the net execution time and preemption time of the target execution instance are determined. This application achieves complete monitoring of the execution behavior of the three layers—ISR, Task, and Runnable—by collecting start and end events, overcoming the limitation of traditional Hook mechanisms that can only monitor the task layer. By dynamically dividing the continuous execution time stream into a set of discrete execution segments containing preemption context information, it provides a data foundation for refined performance analysis. By calculating net execution time and preemption time based on the set of execution segments, it achieves two-dimensional performance analysis, accurately distinguishing whether the performance bottleneck of a target execution instance stems from low algorithm efficiency or frequent preemption. This effectively solves the problems of existing technologies that can only monitor task-level execution time, have difficulty distinguishing between net execution time and preemption time, and lead to vague performance bottleneck location and unclear optimization direction. Therefore, it improves the accuracy of embedded system performance analysis and optimization decisions.

[0089] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0090] This application is applicable to automotive electronic control systems based on the AUTOSAR architecture (such as engine control units (ECUs), body domain controllers, etc.), as well as embedded system scenarios in industrial control, aerospace, and other fields that require real-time task scheduling and performance analysis. Figure 1 A schematic diagram of a scenario for the monitoring method of the embedded system provided in this application, such as... Figure 1As shown, in the AUTOSAR architecture, the automotive electronic control system contains multiple levels of execution units, namely the ISR layer, the Task layer, and the Runnable layer. For example, during operation, the ECU needs to simultaneously handle sensor interrupts, periodic tasks (such as fuel injection control logic), and Runnables called by tasks (such as parameter calculation modules).

[0091] Figure 2 Flowchart of the monitoring method for the embedded system provided in this application Figure 1 ,like Figure 2 As shown, the method includes:

[0092] S201. Collect execution events at multiple levels during the operation of the embedded system. The execution events include the start event and end event of each level.

[0093] More specifically, the system collects execution events at multiple levels during the operation of the embedded system, including: recording interrupt start events at the interrupt service routine entry point and interrupt end events at the interrupt service routine exit point; recording task start and task end events at task switching points; recording runnable start events before runnable execution and runnable end events after runnable execution; each execution event record includes an event type, an identifier, and a timestamp; event types include interrupt start event, interrupt end event, task start event, task end event, runnable start event, and runnable end event; the timestamp records the time the execution event occurred; and the identifier identifies different execution instances.

[0094] For example, an ISR start event is recorded at the ISR entry point, and an ISR end event is recorded at the ISR exit point; a Task start event and a Task end event are recorded at the Task switching point; a Runnable start event is recorded before the Runnable is executed, and a Runnable end event is recorded after the Runnable is executed.

[0095] Optionally, three levels of execution events and their recording timing can be defined. For the ISR layer (i.e., the interrupt layer), the ISR start event is recorded at the ISR entry point, and the ISR end event is recorded at the ISR exit point. For example, for the Task layer, the Task start event and Task end event are recorded at the Task switching point. For the Runnable layer, the Runnable start event and Runnable end event are recorded before and after Runnable execution. The capture of these events is achieved by actively inserting event records into the code, thus obtaining the various event records.

[0096] Optionally, for any execution event, the event type of the execution event is obtained from the record corresponding to the execution event, and the level to which the execution event belongs is determined according to the event type; wherein, the interrupt start event and interrupt end event correspond to the interrupt level; the task start event and task end event correspond to the task level; and the runnable start event and runnable end event correspond to the runnable level.

[0097] The event type identifies the type of the executed event (i.e., ISR start or ISR end, Task start or Task end, Runnable start or Runnable end), and the corresponding level can be deduced from the event type. Only embedded systems record this information.

[0098] In one possible implementation, an event type mapping relationship is established: Task start event = type 1, Task end event = type 2; ISR start event = type 3, ISR end event = type 4; Runnable start event = type 5, Runnable end event = type 6. Therefore, when determining the execution event level based on the event type, execution events of type 1 and type 2 belong to the Task layer, execution events of type 3 and type 4 belong to the ISR layer, and execution events of type 5 and type 6 belong to the Runnable layer. This embodiment achieves independent capture of execution events at the three levels—interrupt layer, task layer, and runnable layer—by actively inserting event recording code at ISR entry and exit points, Task switching points, and before and after Runnable execution. This overcomes the limitation of traditional Hook mechanisms, which can only monitor the task layer, and provides a data foundation for subsequent multi-level performance analysis. Meanwhile, a compact encoding format is used to record event types, identifiers, and timestamps. Hierarchical information is not recorded separately but is derived by analysis tools based on event types. There is no need to store hierarchy names or manually label them, thus saving storage space and reducing recording overhead, thereby reducing the impact on the real-time performance of embedded systems.

[0099] In one possible embodiment, the execution event is recorded using a compact encoding format of 3 fields (10 bytes) to obtain the event record corresponding to the execution event. The event record includes the event type (1 byte), identifier (1 byte), and timestamp (8 bytes) of the execution event. The timestamp of the execution event can be adjusted according to the precision requirements, or a 4-byte (32-bit) timestamp can be used.

[0100] S202. For each level of execution event, based on the occurrence of preemption, the continuous execution time stream is dynamically divided into a set of discrete execution segments to obtain an execution timeline list.

[0101] Each execution segment includes at least the execution segment's hierarchy, start time, end time, the preempted execution segment identifier, the preemptor identifier, and the preemption depth.

[0102] Optionally, before decomposing the continuous execution time stream into a set of discrete execution segments, the following core data structures are defined: execution segments, a list of active execution instances, and a list of execution timelines.

[0103] An execution fragment represents a continuous execution time segment of an execution instance, containing complete preemption context information. The specific fields of each execution fragment are shown in Table 1:

[0104] Table 1

[0105]

[0106] The start time refers to the moment when the execution segment begins; the end time refers to the moment when the execution segment ends; and the duration refers to the length of the execution segment, which is obtained by subtracting the start time from the end time.

[0107] The active execution instance list stores execution instances that are currently running but have not yet finished. Each element in the active execution instance list corresponds to an execution instance, and each execution instance contains a level, an execution instance identifier, and the start time of each execution segment. The level refers to the level to which the execution instance belongs; the execution instance identifier uniquely identifies the execution instance; and the execution segment start time records the start time of each execution segment within that execution instance. It's important to note that this active execution instance list uses a list structure, not a stack structure, supporting traversal and search based on level and identifier, as well as removal from any position. This design provides fault tolerance; when event records are incomplete, the execution instance corresponding to the end event may not be at the end of the list, requiring traversal to find a matching instance for processing.

[0108] The execution timeline list stores execution segments generated by dynamic segmentation, including execution segments at three levels: ISR layer, Task layer, and Runnable layer. Each execution segment contains complete information such as the level, identifier of the preempted execution segment, start time, end time, duration, preemptor identifier, and preemption depth, serving as the data foundation for subsequent in-depth analysis.

[0109] More specifically, for each level of execution events, the continuous execution time stream is dynamically divided into a set of discrete execution segments based on the occurrence of preemption. This includes: processing each event in the execution events of multiple levels in order of timestamps; initializing an active execution instance list and an execution timeline list; the active execution instance list stores execution instances that are currently executing but have not yet ended, and the execution timeline list stores the generated execution segments; when any start event is processed, if the active execution instance list is not empty, an execution segment is generated for the first execution instance at the end of the active execution instance list to record the continuous execution time of the first execution instance being preempted by the second execution instance corresponding to the start event; the generated execution segment is added to the execution timeline list, and the second execution instance is added to the end of the active execution instance list; when any end event is processed, the active execution instance list is traversed to find an execution instance that matches both the level and identifier of the end event, an execution segment is generated for the found execution instance, added to the execution timeline list, and the found execution instance is removed from the active execution instance list.

[0110] Optionally, an execution fragment is generated for the first execution instance at the end of the active execution instance list. This includes: creating an execution fragment with a start time equal to the start time of the first execution instance's execution fragment (i.e., the start time of the preempted execution fragment), an end time equal to the timestamp of the start event, a preemptor identifier equal to the identifier of the start event (i.e., the identifier of the second execution instance), a preempted execution fragment identifier equal to the identifier of the first execution instance, and a preemption depth equal to the length of the active execution instance list. The generated execution fragment is then added to the execution timeline list.

[0111] In one possible implementation, when any start event is processed, it is checked whether the list of active execution instances is empty. If the list of active execution instances is empty, there is no need to generate an execution fragment; instead, the second execution instance corresponding to the start event is directly added to the end of the list of active execution instances. During addition, the level and identifier of the second execution instance are recorded, and the start time of the execution fragment of the second execution instance is set to the timestamp of the start event.

[0112] In one possible implementation, if the list of active execution instances is not empty, the execution instance at the end of the list is obtained and designated as the first execution instance. An execution fragment is generated for the first execution instance to record the continuous execution time during which the first execution instance is preempted by the second execution instance corresponding to the start event.

[0113] This application's embodiments achieve precise recording of multi-level preemption relationships by generating an execution fragment containing a preemptor identifier and preemption depth for the first execution instance located at the end of the active execution instance list when processing the start event, if the list of active execution instances is not empty. Then, the second execution instance corresponding to the start event is added to the end of the list. This mechanism can completely capture the preempted, the preemptor, and the nesting depth at the moment preemption occurs, providing data support for subsequent analysis of the mutual influence between execution instances and solving the technical problem that traditional monitoring methods struggle to record preemption context.

[0114] Optionally, after removing the found execution instance from the list of active execution instances, if the list of active execution instances is still not empty after removal, the start time of the execution segment of the execution instance at the end of the list of active execution instances is updated to the timestamp of the end event, so as to record the start time of the execution instance at the end of the list of active execution instances resuming execution.

[0115] In one possible implementation, an active execution instance list, initialized to empty, is created to identify execution instances that are currently executing but have not yet finished. Simultaneously, an execution timeline list, initialized to empty, is created to store subsequently generated execution fragments.

[0116] In one possible implementation, when any starting event is processed, the corresponding level is first deduced based on the event type of the starting event. For example, for the ISR_START event type, it belongs to the ISR layer; for the Task_START event type, it belongs to the Task layer; and for the Runnable_START event type, it belongs to the Runnable layer. Then, if the list of active execution instances is not empty (indicating that an execution instance is currently executing, and the arrival of the new event constitutes preemption), the last execution instance in the list of active execution instances is obtained and recorded as the preempted instance. An execution fragment is generated for this preempted instance to record the start time of the execution fragment before preemption (i.e., the start time of the preempted instance's execution fragment), the end time of the execution fragment (i.e., the timestamp of the starting event), the preemptor identifier (i.e., the identifier of the starting event), and the preemption depth (i.e., the length of the list of active execution instances). The generated execution fragment is added to the execution timeline list. A new execution instance is then created for the starting event and added to the end of the active execution instance list. This new execution instance includes the hierarchy of the starting event, its identifier, and the execution fragment start time (i.e., the timestamp of the starting event). If the active execution instance list is empty, it means that the system is idle, no preemption has occurred, and no execution fragment is generated.

[0117] Optionally, an execution fragment is generated for the found execution instance, specifically including: creating an execution fragment, the start time of the execution fragment being the start time of the execution fragment of the found execution instance, the end time being the timestamp of the end event, the identifier of the preempted execution fragment being the identifier of the found execution instance, the preemptor identifier being empty, and the preemption depth being the length of the list of active execution instances.

[0118] In one possible implementation, when any termination event is encountered, the active execution instance list is traversed to find an execution instance that matches both the level and identifier of the termination event. An execution fragment is generated for the found execution instance. The start time of this execution fragment is the execution fragment start time recorded by the found execution instance, the end time is the timestamp of the termination event, the preemptor identifier is empty, the preempted execution fragment identifier is the identifier of the found execution instance, and the preemption depth is the length of the active execution instance list. The generated execution fragment is added to the execution timeline list. The found execution instance is removed from the active execution instance list. Then, it is checked whether the active execution instance list is still not empty after removal. If the active execution instance list is empty, the process ends; if the active execution instance list is still not empty, the execution instance at the end of the active execution instance list is retrieved, and the execution fragment start time is updated to the timestamp of the termination event.

[0119] Optionally, after all execution events have been processed, the execution timeline list stores all dynamically segmented execution segments. Each execution segment contains complete information such as level, execution instance identifier, start time, end time, duration, preemptor identifier, preempted execution segment identifier, and preemption depth, which serves as the mathematical basis for subsequent analysis.

[0120] In one possible implementation, when any termination event is processed, the corresponding level is first deduced based on the event type. For example, for the ISR_END event type, it belongs to the ISR layer; for the Task_END event type, it belongs to the Task layer; and for the Runnable_END event type, it belongs to the Runnable layer. Then, the active execution instance list is traversed to find an execution instance that matches both the level and identifier of the termination event. If found, this execution instance is recorded as a termination instance. Next, a final execution fragment is generated for this termination instance to record the start time of the execution fragment before the termination event (i.e., the start time of the execution fragment recorded by the termination instance), the end time of the execution fragment (i.e., the timestamp of the termination event), the preemptor identifier (empty, indicating normal termination without preemption), and the preemption depth (i.e., the length of the active execution instance list). The generated final execution fragment is added to the execution timeline list, and the termination instance is removed from the active execution instance list. If the list of active execution instances is still empty at this time, it means that an instance that was preempted will resume execution. Then, get the last execution instance in the list of active execution instances and mark it as the resumed instance. Update the start time of the execution segment of the resumed instance to the timestamp of the end event, that is, record the start time of the resumed execution, in order to prepare for the next split.

[0121] In the above embodiments, if no execution instance matching the level and identifier of the termination event is found in the list of active execution instances, it indicates that the termination event is abnormal (e.g., the corresponding start time is lost or recorded incorrectly), and the abnormal event is recorded.

[0122] In this embodiment, when processing a termination event, a traversal search method is used to locate the execution instance in the active execution instance list that matches the termination event level and identifier. After generating an execution fragment for it, the instance is removed, and the start time of the execution instance at the end of the active execution instance list is updated. This achieves fault tolerance handling for incomplete or out-of-order event records. This mechanism ensures that even in the event of event loss or abnormal order, execution fragments can still be correctly segmented and the continuity of the timeline can be maintained, improving the robustness and practicality of the monitoring method.

[0123] Optionally, after processing execution events at multiple levels, the execution timeline list is sorted in ascending order by start time to ensure that execution segments are arranged chronologically for subsequent analysis such as net execution time calculation and preemption time statistics. This execution timeline list includes complete preemption context information (i.e., preemptor identifier and preemption depth, etc.), providing a data foundation for subsequent execution timeline visualization tools and preemption relationship analysis tools.

[0124] This application's embodiments process start and end events based on timestamp order, dynamically maintain a list of active execution instances, and generate execution fragments in real time. This transforms the originally continuous and unordered execution time stream into a discrete set of execution fragments containing complete preemption contexts. It can accurately capture the start, end, and preemption moments of each execution instance at runtime, and record the depth and source of each preemption, improving the accuracy of the data provided for subsequent multi-dimensional performance analysis.

[0125] S203. Based on the execution timeline list, determine the net execution time and preemption time of the target execution instance.

[0126] The target execution instance is a single execution process defined by a pair of start events and end events.

[0127] More specifically, based on the execution timeline list, the net execution time of the target execution instance is calculated, which includes: obtaining all execution segments belonging to the target execution instance from the execution timeline list, wherein the identifier of the preempted execution segment belonging to the target execution instance is the same as the identifier of the target execution instance; determining the start timestamp of the target execution instance as the start time of the first execution segment of the target execution instance from all the obtained execution segments, and determining the end timestamp of the target execution instance as the end time of the last execution segment of the target execution instance; summing the durations of all the obtained execution segments to obtain the net execution time of the target execution instance; wherein the duration of each execution segment is obtained by subtracting the start time from the end time of the execution segment.

[0128] Optionally, based on the execution timeline list generated in step S202, all execution segments belonging to the target execution instance are obtained from the execution timeline list. The start timestamp and end timestamp of the target execution instance are determined. The start timestamp (i.e., the execution start time) is the start time (or the timestamp of the start event) of the first execution segment of the target execution instance, and the end timestamp (i.e., the execution end time) is the end event (or the timestamp of the end event) of the last execution segment of the target execution instance. All execution segments belonging to the target execution instance are filtered from the execution timeline list. The filtering conditions include that the time range of the execution segments is within the start timestamp and end timestamp of the target execution instance, the level of the execution segments is the same as the level of the target execution instance, and the identifier of the execution segments is the same as the identifier of the target execution instance. The durations of the execution segments that meet the above three conditions are summed to obtain the net execution time of the target execution instance. The net execution time refers to the actual time occupied by the central processing unit during a single complete execution of the target execution instance.

[0129] For example, the time range of the target execution instance is determined as follows: T_start = execution_target's START event timestamp (execution start time), T_end = execution_target's END event timestamp (execution end time). Then, all execution segments belonging to the execution_target are filtered from the execution timeline list, using the filtering criteria shown in Table 2 below:

[0130] Table 2

[0131]

[0132] The execution segments that meet the above three conditions are denoted as the segment_target set. Each execution segment also contains a preemptor identifier and preemption depth information, which are used to analyze preemption relationships and nesting levels.

[0133] In one possible embodiment, within an embedded real-time operating system, the target execution instance is a task identified as Task_Comm, which begins execution at timestamp t=100ms and ends at t=200ms. The execution fragment set records all execution fragments during this execution period. Execution fragments meeting the following criteria are selected: time range between 100ms and 200ms, level is Task, and identifier is Task_Comm. Three execution fragments with durations of 30ms, 20ms, and 40ms are selected. The durations of these three execution fragments are summed to obtain 90ms, which is the net execution time of the Task_Comm task.

[0134] This embodiment selects execution segments from the set of execution segments that have the same identifier and level as the target execution instance and whose time range is within the execution period of the target execution instance. The durations of the selected execution segments are accumulated to accurately calculate the total time actually occupied by the target execution instance in the CPU. This excludes the time preempted by other tasks or instances, providing accurate net execution time data for subsequent performance analysis.

[0135] Optionally, calculating the preemption time of the target execution instance specifically includes: calculating the total execution time of the target execution instance based on the difference between the start timestamp and the end timestamp of the target execution instance; and determining the preemption time of the target execution instance based on the total execution time and net execution time of the target execution instance.

[0136] Specifically, when the target execution instance is not a Task-level execution instance, the preemption time of the target execution instance is determined by calculating the difference between the total execution time and the net execution time of the target execution instance. When the target execution instance is a Task-level execution instance, execution fragments belonging to the Runnable layer within the time range corresponding to the start and end timestamps of the target execution instance are selected from the execution fragment set, and the total execution time of the execution fragments belonging to the Runnable layer is calculated. The preemption time of the Task layer is obtained by subtracting the net execution time of the Task layer execution instance from the total execution time of the target execution instance, and then subtracting the total execution time of the Runnable layer execution fragments.

[0137] Optionally, first calculate the total execution time of the target execution instance = end timestamp - start timestamp, then calculate the preemption time = total execution time - net execution time, which gives the time preempted by other execution instances.

[0138] In one possible implementation, for a Task execution instance, since the Runnable layer is actively invoked by the Task layer and is not preempted, the total execution time of the Runnable layer invoked by the Task layer needs to be excluded when calculating the preemption time of the Task execution instance. Specifically, the execution segments of the Runnable layer between the start and end timestamps of the Task execution instance are selected from the execution timeline list. The total execution time of the Runnable layer is obtained by accumulating the duration of the execution segments of the Runnable layer. Therefore, the preemption time of the Task execution instance = total execution time of the Task execution instance - net execution time of the Task execution instance - total execution time of the Runnable layer.

[0139] Optionally, this embodiment reflects the degree to which the target execution instance is preempted by calculating the preemption ratio of the target execution instance. The preemption ratio of the target execution instance is calculated as follows: (Preemption time of the target execution instance / Total execution time of the target execution instance) × 100%. This preemption ratio reflects the degree to which the target execution instance is preempted.

[0140] In one possible embodiment, within the same embedded real-time operating system, the target execution instance is a sensor data acquisition task identified as Task_Sensor, which is a Task-layer execution instance. This task starts execution at timestamp t=300ms and ends at t=400ms, with a total execution time of 100ms. If the net execution time of this task is calculated to be 60ms using the above method, then within the time range of t=300ms to t=400ms, execution segments belonging to the Runnable layer are selected, and the total execution time of these Runnable layer execution segments is calculated to be 15ms. Therefore, the preemption time of the Task_Sensor sensor data acquisition task is 100ms - 60ms - 15ms = 25ms.

[0141] This embodiment focuses on the execution instance of the Task layer. By defining the portion of the total execution time of the execution instance that does not belong to its own net execution time or the execution segment of the Runnable layer as the preempted time, it accurately quantifies the degree to which the Task layer task is interrupted or preempted by a higher priority task, which further helps to improve the accuracy of analyzing task response delay results.

[0142] Optionally, after calculating the net execution time and preemption time of all execution instances, an execution record set containing performance data of all execution instances is generated. Each execution record includes at least the execution instance identifier, net execution time, total execution time, preemption time, and the position index of the execution instance in the execution timeline list. The position index is used to backtrack and obtain detailed information of each execution segment of the execution instance. A Top N analysis is performed on the execution record set, and the records are sorted in descending order by net execution time. A preset number of execution instances with the longest net execution time are extracted, and an analysis report is generated and output. The analysis report includes the performance indicators and location information of the execution records corresponding to the preset number of execution instances.

[0143] Optionally, performance metrics include, but are not limited to, the net execution time, total execution time, preemption time, and preemption percentage of the target execution instance, and location information includes, but is not limited to, the starting position of each execution instance in the execution timeline list.

[0144] In one possible implementation, after calculating the net execution time and preemption time for all execution instances collected within the past hour, an execution record set containing 5000 records is generated. Developers set the default number of Top N analyses to 10. The system then sorts the execution record set by net execution time from largest to smallest, extracting the 10 execution instances with the longest net execution times. The system then generates an analysis report based on these 10 execution instances. The report lists the execution instance identifier, net execution time, total execution time, preemption time, preemption percentage, and timeline index for each of these 10 instances. The timeline index indicates the position of the target execution instance within the execution timeline list, allowing for backtracking to obtain detailed time information and preemption context data for that execution segment.

[0145] This embodiment performs Top N analysis on the calculated set of execution records to automatically identify and output a preset number of execution instances with the longest net execution time. This helps developers quickly locate the hot functions or tasks that consume the most CPU time in the system, providing a clear direction and goal for performance optimization.

[0146] Optionally, Top N analysis includes at least one of the following modes: system-wide sorting, which refers to extracting the first preset number of execution instances with the longest global net execution time from the execution records of all levels; grouping and sorting by level, which refers to extracting the second preset number of execution instances with the longest net execution time from the execution records of each level (e.g., ISR level, Task level, and Runnable level); and grouping and sorting by execution instance, which refers to grouping multiple execution records of the same execution instance and extracting the third preset number of execution instances with the longest net execution time.

[0147] In one possible implementation, three Top N analysis modes are provided for the user to choose from. If the user selects the full system sorting mode, the system will extract the 10 execution instances with the longest global net execution time from the execution records of all levels. It will find that among the 10 most time-consuming execution instances, 6 are Task layer tasks and 4 are ISR layer interrupt service functions.

[0148] In one possible implementation, if the user switches to the hierarchical grouping and sorting mode, the system extracts the three execution instances with the longest net execution time from the ISR layer, Task layer and Runnable layer respectively. It finds that the most time-consuming task in the Task layer is a communication task, while the most time-consuming execution segment in the Runnable layer is a certain mathematical calculation function.

[0149] In one possible implementation, if the user switches to the sorting mode by execution instance, enters the execution instance identifier Task_Log and sets the preset number to 3, the system will extract the 3 execution records with the longest net execution time from the multiple execution records of the task, and find that these 3 executions all occurred during the period when system log write operations are frequent.

[0150] This embodiment provides a multi-dimensional Top N analysis mode, enabling users to observe the performance information of the embedded system from a global perspective, a hierarchical perspective, and a single execution instance perspective, thus meeting the performance analysis needs in different scenarios and improving the flexibility and efficiency of problem localization.

[0151] The embedded system monitoring method provided in this application collects execution events from the ISR layer, Task layer, and Runnable layer. It decomposes the continuous execution time stream into a set of discrete execution segments containing preemption contexts, and then calculates the net execution time and preemption time of each execution instance from the set of execution segments. This method achieves precise quantitative analysis of multi-level nested preemption behavior in embedded systems, solving the technical problem that traditional monitoring tools can only observe a single task layer and are difficult to analyze the interaction effects between layers. This improves the accuracy of embedded system performance analysis and the efficiency of problem localization.

[0152] Figure 3 Flowchart of the monitoring method for the embedded system provided in this application Figure 2 ,like Figure 3 As shown, in this embodiment... Figure 2 Based on the examples, a monitoring method for embedded systems is described in detail, which includes:

[0153] S301: Collect execution events at multiple levels during the operation of the embedded system.

[0154] More specifically, an ISR start event is recorded at the ISR entry point, and an ISR end event is recorded at the ISR exit point; a Task start event and a Task end event are recorded at the Task switching point; a Runnable start event is recorded before Runnable execution, and a Runnable end event is recorded after Runnable execution. Each event record uses a compact encoding format and contains three fields: event type, identifier, and timestamp. The event type identifies the specific type of event, including six types: ISR start, ISR end, Task start, Task end, Runnable start, and Runnable end. The identifier uniquely identifies different execution instances, such as Task_1, ISR_2, Runnable_1, etc. The timestamp records the time when the execution event occurred. The above event records do not store hierarchical information separately; instead, the analysis tool deduces the hierarchical level of the event based on the event type. The specific deduction rules are: ISR start and ISR end events correspond to the ISR layer, Task start and Task end events correspond to the Task layer, and Runnable start and Runnable end events correspond to the Runnable layer. This compact encoding format saves storage space and reduces logging overhead while ensuring the integrity of event information. By actively inserting event logging code into the code, the execution events of the ISR layer, Task layer, and Runnable layer can be captured independently, providing complete execution event data for subsequent performance analysis at multiple layers.

[0155] For example, a compact encoding format using 10 bytes is shown in Table 3:

[0156] Table 3

[0157]

[0158] In one possible implementation, Task_A starts at 100μs, calls Runnable_R, is preempted by ISR_X, and ends at 600μs, resulting in multiple levels of execution events as shown in Table 4:

[0159] Table 4

[0160]

[0161] In one possible embodiment, Figure 4 Flowchart of the monitoring method for the embedded system provided in this application Figure 3 ,like Figure 4As shown, the system execution status is input (i.e., the start and end times of ISR / Task / Runnable), and execution events at multiple levels are output. The execution events are recorded using a compact encoding format. For example, the input execution event ISR_5 starts at 200μs and outputs [0x03][0x05][200μs timestamp], where [0x03] is the event type field, [0x05] is the identifier field, and [200μs timestamp] is the timestamp field.

[0162] Optionally, the format specification for event logging is defined as follows: Figure 4 As shown, [R1] is the event record structure, used to define the storage format (i.e., event type, identifier, and timestamp); [R2] is the event type definition, used to define 6 event type values ​​(type 1-type 6), where the start event type value for the Task level is 1 and the end event type value is 2; the start event type value for the ISR level is 3 and the end event type value is 4; and the start event type value for the Runnable level is 5 and the end event type value is 6; [R3] is the level derivation rule, used to define the mapping from event type to level. For example, event type values ​​1 and 2 map to the Task level, event type values ​​3 and 4 map to the ISR level, and event type values ​​5 and 6 map to the Runnable level.

[0163] For example, the [R1] event record structure uses a compact 10-byte format, namely 1 byte for the event type, 1 byte for the identifier, and 8 bytes for the timestamp, as shown in Table 5:

[0164] Table 5

[0165]

[0166] The timestamp field can be adjusted according to the actual precision requirements, or a 4-byte (32-bit) timestamp can be used. In this case, the event record structure is a 6-byte compact format (i.e., 1-byte event type + 1-byte identifier + 4-byte timestamp).

[0167] For example, the [R2] event type is defined as shown in Table 6:

[0168] Table 6

[0169]

[0170] For example, based on the [R3] level derivation rules, the Task layer is derived according to type 1 and 2; the ISR layer is derived according to type 3 and 4; and the Runnable layer is derived according to type 5 and 6.

[0171] In one possible embodiment, the input system execution status is shown in Table 7:

[0172] Table 7

[0173]

[0174] In one possible embodiment, the execution events at multiple levels output in step S301 are shown in Table 8:

[0175] Table 8

[0176]

[0177] S302. Dynamically divide the continuous execution time stream into a set of discrete execution segments.

[0178] More specifically, an active execution instance list and an execution timeline list are initialized; each execution event in multiple levels of execution events is processed in timestamp order; when any start event is processed, if the active execution instance list is not empty, an execution fragment is generated for the first execution instance at the end of the active execution instance list to record the event where the first execution instance is preempted by the second execution instance corresponding to the start event; the generated execution fragment is added to the execution timeline list; then the second execution instance is added to the end of the active execution instance list. When any end event is processed, the active execution instance list is traversed to find an execution instance that matches both the level and identifier of the end event; an execution fragment is generated for the found execution instance and added to the execution timeline list; then the found execution instance is removed from the active execution instance list. If the active execution instance list is still not empty after removal, the fragment start time of the execution instance at the end of the active execution instance list is updated to the timestamp of the end event.

[0179] Optionally, the execution segment of this application represents a continuous execution time of an execution instance, containing complete preemption context information. Each execution segment includes the execution segment's level, execution instance identifier (i.e., the identifier of the preempted execution segment), start time, end time, duration, preemptor identifier, and preemption depth. The level indicates the level to which the execution instance belongs, including the ISR level, Task level, or Runnable level; the execution instance identifier uniquely identifies the execution instance; the start and end times record the time range of the segment; the duration is obtained by subtracting the start time from the end time; the preemptor identifier records the identifier of the execution instance that preempted the segment; if the segment is not preempted, the preemptor identifier is empty; the preemption depth records the number of active execution instances when the segment occurs.

[0180] Optionally, the active execution instance list in this application is used to store all execution instances that are currently executing but have not yet ended. Each element in the list corresponds to an execution instance, including the level, execution instance identifier, and start time of the execution segment. The start time of the execution segment records the beginning time of the execution segment of that execution instance. The active execution instance list adopts a list structure, rather than a stack structure, supporting traversal search based on level and identifier, and removal from any position. This design provides fault tolerance, so that when the event record is incomplete, the execution instance corresponding to the end event may not be at the end of the active execution instance list. In this case, it is necessary to traverse and search for an instance with a matching level and identifier for processing.

[0181] Optionally, the execution timeline list in this application is used to store all execution fragments generated by dynamic segmentation, including all fragments at the three levels: ISR layer, Task layer, and Runnable layer.

[0182] In one possible embodiment, Figure 5 Flowchart of the monitoring method for the embedded system provided in this application Figure 4 The system retrieves execution events from multiple levels output in step S301, where each execution event includes an event type, an identifier, and a timestamp. The execution events are then sorted in ascending order of their timestamps. Figure 5 Step A1). Create a list of active execution instances and a list of execution timelines, both initialized to empty. Figure 5 Step A2).

[0183] For example, such as Figure 5 Steps A3-A5 involve sequentially retrieving each event from multiple execution levels in ascending order of timestamps for processing. When processing any starting event, the level to which the starting event belongs is first deduced based on the event type. Figure 5 Step A3). Then check if the list of active execution instances is empty. If the list of active execution instances is empty, it means the system is idle and no preemption has occurred. In this case, there is no need to generate an execution fragment. Simply add the second execution instance corresponding to the starting event to the end of the list of active execution instances, and record the level and identifier of the second execution instance. Set the start time of its execution fragment to the timestamp of the starting event. Figure 5 Step A5). If the list of active execution instances is not empty, it means that an execution instance is currently executing, and the arrival of this start event constitutes preemption. Obtain the execution instance at the end of the list of active execution instances, denoted as the first execution instance. Generate an execution fragment for this first execution instance to record the event where the first execution instance is preempted by the second execution instance corresponding to this start event. Figure 5Step A4). Next, add the second execution instance corresponding to the starting event to the end of the active execution instance list, record the level and identifier of the second execution instance, and set the start time of its execution segment to the timestamp of the starting event (…). Figure 5 Step A5).

[0184] For example, after executing step A5, a step to determine whether there are any unprocessed events is executed, specifically including: if there are, then execute step A3; otherwise, sort all execution segments in the execution timeline list in ascending order of start time and output the execution timeline list.

[0185] For example, such as Figure 5 Steps A6-A9: When any termination event is encountered, first, the level to which the termination event belongs is deduced based on the event type. Then, the list of active execution instances is traversed to find an execution instance that matches both the level and identifier of the termination event. Figure 5 Step A6). If no matching execution instance is found, it indicates an event exception. Record the exception event and proceed to determine if there are any unprocessed events. If a matching execution instance is found, generate an execution fragment for that instance. Figure 5 Step A7). The specific method for generating an execution fragment is as follows: Create an execution fragment whose start time is the fragment start time recorded by the found execution instance, whose end time is the timestamp of the end event, whose preemptor identifier is empty, and whose preemption depth is the length of the active execution instance list. Add the generated execution fragment to the execution timeline list. Then remove the found execution instance from the active execution instance list. Figure 5 Step A8). Check if the list of active execution instances is still not empty after removal. If the list of active execution instances is empty, proceed to determine if there are any unprocessed events. If the list of active execution instances is still not empty, obtain the execution instance at the end of the list and update its execution segment start time to the timestamp of the end event to record the start time of the execution instance's resumption of execution. Figure 5 Step A9).

[0186] Optionally, after processing all events, all execution segments in the execution timeline list are sorted in ascending order by start time to ensure that the segments are arranged in chronological order. The execution timeline list stores all dynamically generated execution segments (i.e., a collection of discrete execution segments), each containing complete preemption context information, providing a data foundation for subsequent analysis.

[0187] Optionally, the list of active execution instances in this application is a list structure, not a stack structure.

[0188] In one possible embodiment, the list of active execution instances during the processing is shown in Table 9:

[0189] Table 9

[0190]

[0191] Each element in the list of active execution instances is a structure containing three fields: level, identifier, and start time. At 100μs, Task 10 is added to the list of active execution instances; at 150μs, the execution fragment corresponding to Task 10 is saved to the execution timeline list (100-150μs), and the Runnable 3 state is added to the list of active execution instances; at 200μs, the execution fragment corresponding to Runnable 3 is saved to the execution timeline list (150-200μs), and the ISR 5 state is added to the list of active execution instances; at 250μs, the execution fragment corresponding to ISR 5 is saved to the execution timeline list (200-250μs), and the ISR 5 state is removed from the list of active execution instances, and Runnable 3 resumes execution (i.e., the update start time is 250μs); at 300μs, the execution fragment corresponding to Runnable 3 is saved to the execution timeline list (250-300μs), and the Runnable 3 state is removed from the list of active execution instances, and Task 10 resumes execution. Task 10 resumes execution (i.e., update starts at 300μs); at 600μs, the execution fragment corresponding to Task 10 is saved to the execution timeline list (300-600μs), and the status of Task 10 is removed from the active execution instance list, which is then cleared. The final output execution timeline list is shown in Table 10.

[0192] Table 10

[0193]

[0194] Optionally, the execution timeline list can be sorted in ascending order of start time to show the fragmented nature of system execution time.

[0195] S303. Based on the execution timeline list, obtain the net execution time and preemption time of the target execution instance.

[0196] More specifically, based on the execution timeline list, the start and end timestamps of the target execution instance are obtained; all execution segments that meet preset conditions are filtered from the execution timeline list, including that the time range of the execution segment is within the target execution instance's start and end timestamps, the execution segment's level is the same as the target execution instance, and the execution segment's identifier is the same as the target execution instance's identifier; the durations of all filtered execution segments are summed to obtain the net execution time of the target execution instance; the total execution time is calculated based on the difference between the target execution instance's start and end timestamps, and the preemption time of the target execution instance is determined by calculating the difference between the total execution time and the net execution time.

[0197] In one possible implementation, for Task layer execution instances, the calculation of preemption time needs further refinement. When the target execution instance is a Task layer execution instance, all execution fragments belonging to the Runnable layer within the time range of the target execution instance's start and end timestamps are selected from the execution fragment set, and the total execution time of these Runnable layer execution fragments is calculated. Here, preemption time specifically refers to the total execution time minus the net execution time of the Task layer execution instance, and then minus the total execution time of the Runnable layer execution fragments. This is because the execution time of Runnable instances actively invoked by the Task layer should not be included in the preemption time.

[0198] By applying the above calculations to all execution units in the execution timeline list, an execution record set containing performance data for all execution instances is generated. Each execution record includes at least the execution instance identifier, net execution time, total execution time, and preemption time, as well as the position index (or timeline index) of the execution record in the execution fragment set, used to backtrack and obtain detailed preemption context information.

[0199] In one possible embodiment, Figure 6 Flowchart of the monitoring method for the embedded system provided in this application Figure 5 ,like Figure 6 As shown, first obtain input 1 and input 2, that is, obtain the execution timeline list and the start and end times of the target execution instance obtained in step S302, and then... Figure 6 After the calculations in steps C1-C4, an execution record set is generated and output, as shown in Table 11.

[0200] Table 11

[0201]

[0202]

[0203] Optionally, when performing an instance on each target... Figure 6 In the calculation and processing of steps C1-C4, three filtering conditions are first defined: Condition 1 (time range), the execution segment is within the [start time, end time] of the target execution instance; Condition 2 (level matching), the execution segment level is the same as the target execution instance level (including ISR level, Task level, or Runnable level); Condition 3 (identifier matching), the execution segment identifier is the same as the target execution instance identifier (e.g., ISR_1, Task_1, or Runnable_1). Then, each execution segment is checked, traversing all execution segments in the execution timeline list, and the three filtering conditions are applied to determine whether to include them. The durations of execution segments that meet the three filtering conditions are accumulated to obtain the net execution time. Finally, preemption-related indicators are calculated, including total execution time, preempted time, and preemption ratio.

[0204] S304. Based on the performance data of the execution instance, perform Top N analysis and output an analysis report.

[0205] More specifically, after calculating the net execution time and preemption time of all execution instances, an execution record set containing performance data of all execution instances is generated; a Top N analysis is performed on the execution record set, sorted in descending order by net execution time, and a preset number of execution instances with the longest net execution time are extracted, and a Top N analysis report containing performance metrics of the preset number of execution instances is output.

[0206] In one possible embodiment, the analysis report is shown in Table 12:

[0207] Table 12

[0208]

[0209]

[0210] Optionally, Top N analysis supports at least one of the following modes: System-wide sorting mode extracts a preset number of execution instances with the longest global net execution time from execution records across all levels. This mode is used to identify global performance hotspots. Grouping and sorting mode by level extracts a preset number of execution instances with the longest net execution time from execution records at the ISR, Task, and Runnable levels respectively. This mode is used to analyze the performance characteristics of each level and identify the most time-consuming interrupt handling, the most time-consuming task, and the most time-consuming runnable. Grouping and sorting mode by execution unit groups multiple execution records of the same execution unit and extracts a preset number of execution instances with the longest net execution time for that unit. This mode is used to analyze the worst-case execution of a single execution unit and can be used for WCET (Worst-Case Execution Time) evaluation.

[0211] Optionally, the Top N analysis report includes performance metrics for the execution records and their position indexes within the execution fragment set. Performance metrics include at least net execution time, total execution time, preemption time, and preemption percentage. The position index is used to retrieve detailed preemption context information, including the preemptor identifier and preemption depth for each execution fragment, thereby analyzing which execution units frequently preempt the target unit and the distribution of preemption depth. Through this two-dimensional performance analysis, the root causes of performance bottlenecks at the ISR layer, Task layer, and Runnable layer can be accurately identified.

[0212] Optionally, execution instances with long net execution times indicate that the algorithm is inefficient and needs to be optimized; execution instances with long preemption times indicate that the algorithm is frequently preempted and needs to be optimized in terms of task priority configuration or interrupt management strategy.

[0213] Figure 7 A schematic diagram of the structure of the monitoring device for the embedded system provided in this application is shown below. Figure 7 As shown, the monitoring device 70 for the embedded system provided in this embodiment includes:

[0214] The acquisition module 701 is used to collect execution events at multiple levels during the operation of the embedded system. The execution events include the start event and the end event of each level.

[0215] The processing module 702 is used to dynamically divide the continuous execution time stream into a set of discrete execution segments based on the occurrence of preemption for each level of execution event. Each execution segment includes at least the level to which the execution segment belongs, the start time and the end time, as well as the identifier of the preempted execution segment, the identifier of the preemptor, and the preemption depth.

[0216] The processing module 702 is also used to determine the net execution time and preemption time of the target execution instance based on the set of execution fragments, wherein the target execution instance is a single execution process determined by a pair of start events and end events.

[0217] Optionally, the acquisition module 701 is also used to record the interrupt start event at the interrupt service routine entry point and the interrupt end event at the interrupt service routine exit point.

[0218] Record task start and task end events at task switching points;

[0219] Record the runnable start event before execution at the runnable layer, and record the runnable end event after execution at the runnable layer;

[0220] Each execution event record includes an event type, an identifier, and a timestamp; the event types include interrupt start event, interrupt end event, task start event, task end event, runnable start event, and runnable end event; the timestamp is used to record the time when the execution event occurred.

[0221] Optionally, the acquisition module 701 is also used to, for any given execution event, retrieve the event type of the execution event from the record corresponding to the execution event, and determine the level to which the execution event belongs based on the event type;

[0222] Among them, interrupt start event and interrupt end event correspond to the interrupt layer; task start event and task end event correspond to the task layer; and runnable start event and runnable end event correspond to the runnable layer.

[0223] Optionally, the processing module 702 is also configured to process each event in the execution events of multiple levels based on the timestamp order;

[0224] Initialize an active execution instance list and an execution timeline list; the active execution instance list stores execution instances that are currently executing but have not yet finished, and the execution timeline list stores generated execution segments; when any start event is processed, if the active execution instance list is not empty, generate an execution segment for the first execution instance at the end of the active execution instance list to record the continuous execution time preempted by the second execution instance corresponding to the start event; add the generated execution segment to the execution timeline list, and add the second execution instance to the end of the active execution instance list;

[0225] When any termination event is encountered, the active execution instance list is traversed to find an execution instance that matches both the level and identifier of the termination event. An execution fragment is generated for the found execution instance, added to the execution timeline list, and the found execution instance is removed from the active execution instance list.

[0226] Optionally, the processing module 702 is further configured to, after removing the found execution instance from the list of active execution instances, update the start time of the execution segment of the execution instance at the end of the list of active execution instances to the timestamp of the end event if the list of active execution instances is still not empty after removal, so as to record the start time of the execution instance at the end of the list of active execution instances resuming execution.

[0227] Optionally, the processing module 702 is further configured to create an execution fragment, wherein the start time of the execution fragment is the start time of the execution fragment of the last execution instance, the end time is the timestamp of the start event, the preemptor identifier is the identifier of the start event, the preempted execution fragment identifier is the identifier of the first execution instance, and the preemption depth is the length of the list of active execution instances.

[0228] Optionally, the processing module 702 is also used to create an execution fragment, wherein the start time of the execution fragment is the start time of the execution fragment of the found execution instance, the end time is the timestamp of the end event, the identifier of the preempted execution fragment is the identifier of the found execution instance, the preemptor identifier is empty, and the preemption depth is the length of the list of active execution instances.

[0229] Optionally, the processing module 702 is further configured to obtain all execution segments belonging to the target execution instance from the execution timeline list, wherein the identifier of the preempted execution segment belonging to the target execution instance is the same as the identifier of the target execution instance;

[0230] From all the obtained execution fragments, determine the start timestamp of the target execution instance as the start time of the first execution fragment of the target execution instance, and determine the end timestamp of the target execution instance as the end time of the last execution fragment of the target execution instance;

[0231] The net execution time of the target execution instance is obtained by summing the durations of all the acquired execution segments; where the duration of each execution segment is obtained by subtracting the start time from the end time of the execution segment.

[0232] Optionally, the processing module 702 is further configured to calculate the total execution time of the target execution instance based on the difference between the start timestamp and the end timestamp of the target execution instance;

[0233] The preemption time of the target execution instance is determined based on the total execution time and net execution time of the target execution instance.

[0234] Optionally, the processing module 702 is further configured to generate an execution record set containing performance data of all execution instances after calculating the net execution time and preemption time of all execution instances. Each execution record includes at least the execution instance identifier, net execution time, total execution time, preemption time, and position index of the execution instance in the execution timeline list. The position index is used to backtrack and obtain detailed information of each execution segment of the execution instance.

[0235] Perform Top N analysis on the execution record set, sort in descending order by net execution time, extract a preset number of execution instances with the longest net execution time, generate and output an analysis report, which includes the performance metrics and location information of the execution records corresponding to the preset number of execution instances.

[0236] Optionally, Top N analysis includes at least one of the following patterns:

[0237] System-wide sorting refers to extracting a preset number of execution instances with the longest global net execution time from the execution records of all levels;

[0238] Grouping and sorting by level refers to extracting a preset number of execution instances with the longest net execution time from the execution records of each level.

[0239] Grouping and sorting by execution instance refers to grouping multiple execution records of the same execution instance and extracting a preset number of execution instances with the longest net execution time.

[0240] The embedded system monitoring device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0241] Figure 8 A schematic diagram of the structure of the electronic device provided in this application. Figure 8 As shown, the electronic device 80 provided in this embodiment includes at least one processor 801 and a memory 802. Optionally, the device 80 further includes a communication component 803. The processor 801, memory 802, and communication component 803 are connected via a bus 804.

[0242] In a specific implementation, at least one processor 801 executes computer execution instructions stored in memory 802, causing at least one processor 801 to perform the above-described method.

[0243] The specific implementation process of processor 801 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0244] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0245] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0246] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0247] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0248] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0249] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0250] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0251] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0252] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0253] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0254] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0255] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0256] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A method of monitoring an embedded system, characterized in that, include: Collect execution events at multiple levels during the operation of the embedded system, including start and end events for each level; For each level of execution event, the continuous execution time stream is dynamically divided into a set of discrete execution segments based on the occurrence of preemption. Each execution segment includes at least the level to which the execution segment belongs, the start time and the end time, as well as the identifier of the preempted execution segment, the identifier of the preemptor, and the preemption depth. Based on the set of execution fragments, determine the net execution time and preemption time of the target execution instance, wherein the target execution instance is a single execution process determined by a pair of start events and end events.

2. The method according to claim 1, characterized in that, Collect execution events at multiple levels during the operation of the embedded system, specifically including: Record the interrupt start event at the interrupt service routine entry point and the interrupt end event at the interrupt service routine exit point; Record task start and task end events at task switching points; Record the runnable start event before execution at the runnable layer, and record the runnable end event after execution at the runnable layer; Each execution event record includes an event type, an identifier, and a timestamp; the event types include interrupt start event, interrupt end event, task start event, task end event, runnable start event, and runnable end event; the timestamp is used to record the time when the execution event occurs.

3. The method according to claim 2, characterized in that, Also includes: For any given execution event, the event type of the execution event is obtained from the record corresponding to the execution event, and the level to which the execution event belongs is determined based on the event type; Interrupt start event and interrupt end event correspond to the interrupt layer; task start event and task end event correspond to the task layer. The runnable start event and runnable end event correspond to the runnable layer.

4. The method according to claim 1, characterized in that, For each level of execution event, the continuous execution time stream is dynamically divided into a set of discrete execution segments based on the occurrence of preemption, specifically including: Each event in the execution events of the multiple levels is processed in order of timestamp; Initialize an active execution instance list and an execution timeline list; the active execution instance list stores execution instances that are currently executing but have not yet finished, and the execution timeline list stores generated execution segments; when any start event is processed, if the active execution instance list is not empty, generate an execution segment for the first execution instance located at the end of the active execution instance list to record the continuous execution time of the first execution instance being preempted by the second execution instance corresponding to the start event; add the generated execution segment to the execution timeline list, and add the second execution instance to the end of the active execution instance list; When any termination event is processed, the active execution instance list is traversed to find an execution instance that matches both the level and identifier of the termination event. An execution fragment is generated for the found execution instance, added to the execution timeline list, and the found execution instance is removed from the active execution instance list.

5. The method according to claim 4, characterized in that, Also includes: After removing the found execution instance from the list of active execution instances, if the list of active execution instances is still not empty after removal, the start time of the execution segment of the execution instance at the end of the list of active execution instances is updated to the timestamp of the end event, so as to record the start time of the execution instance at the end of the list of active execution instances resuming execution.

6. The method according to claim 4, characterized in that, Generate an execution fragment for the first execution instance located at the end of the list of active execution instances, specifically including: An execution fragment is created, wherein the start time of the execution fragment is the start time of the execution fragment of the last first execution instance, the end time is the timestamp of the start event, the preemptor identifier is the identifier of the start event, the preempted execution fragment identifier is the identifier of the first execution instance, and the preemption depth is the length of the list of active execution instances.

7. The method according to claim 4, characterized in that, Generate execution fragments for the found execution instances, specifically including: An execution fragment is created, wherein the start time of the execution fragment is the start time of the execution fragment of the found execution instance, the end time is the timestamp of the end event, the identifier of the preempted execution fragment is the identifier of the found execution instance, the preemptor identifier is empty, and the preemption depth is the length of the list of active execution instances.

8. The method according to claim 1, characterized in that, Based on the execution timeline list, calculate the net execution time of the target execution instance, specifically including: Obtain all execution segments belonging to the target execution instance from the execution timeline list, wherein the identifier of the preempted execution segment belonging to the target execution instance is the same as the identifier of the target execution instance; From all the acquired execution segments, the start timestamp of the target execution instance is determined as the start time of the first execution segment of the target execution instance, and the end timestamp of the target execution instance is determined as the end time of the last execution segment of the target execution instance; The net execution time of the target execution instance is obtained by summing the durations of all acquired execution segments; wherein the duration of each execution segment is obtained by subtracting the start time from the end time of the execution segment.

9. The method according to claim 8, characterized in that, The preemption time of the target execution instance is calculated, specifically including: The total execution time of the target execution instance is calculated based on the difference between the start timestamp and the end timestamp of the target execution instance. The preemption time of the target execution instance is determined based on the total execution time and net execution time of the target execution instance.

10. The method according to claim 1, characterized in that, Also includes: After calculating the net execution time and preemption time of all execution instances, an execution record set containing the performance data of all execution instances is generated. Each execution record includes at least the execution instance identifier, net execution time, total execution time, preemption time, and the position index of the execution instance in the execution timeline list. The position index is used to backtrack and obtain detailed information of each execution segment of the execution instance. A Top N analysis is performed on the execution record set, and the records are sorted in descending order by net execution time. A preset number of execution instances with the longest net execution time are extracted, and an analysis report is generated and output. The analysis report includes the performance indicators and location information of the execution records corresponding to the preset number of execution instances.

11. The method according to claim 10, characterized in that, The Top N analysis includes at least one of the following patterns: System-wide sorting refers to extracting a preset number of execution instances with the longest global net execution time from the execution records of all levels; Grouping and sorting by level refers to extracting a preset number of execution instances with the longest net execution time from the execution records of each level. Grouping and sorting by execution instance refers to grouping multiple execution records of the same execution instance and extracting a preset number of execution instances with the longest net execution time.

12. A monitoring device for an embedded system, characterized in that, include: The acquisition module is used to collect execution events at multiple levels during the operation of the embedded system. The execution events include the start event and the end event of each level. The processing module is used to dynamically divide the continuous execution time stream into a set of discrete execution segments based on the occurrence of preemption for each level of execution event. Each execution segment includes at least the level to which the execution segment belongs, the start time and the end time, as well as the identifier of the preempted execution segment, the identifier of the preemptor, and the preemption depth. The processing module is further configured to determine the net execution time and preemption time of the target execution instance based on the set of execution fragments, wherein the target execution instance is a single execution process determined by a pair of start events and end events.

13. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-11.

Images