Performance monitoring method of multi-rate simulation model, electronic equipment and storage medium

Abstract

The invention belongs to the technical field of simulation, and particularly relates to a performance monitoring method for a multi-rate simulation model, electronic equipment and a storage medium, and the method comprises the steps: determining a minimum common period based on the step length of each subsystem in the multi-rate simulation model, and determining a target collection period based on the minimum common period; in a preset number of target acquisition periods, acquiring performance data generated by execution of each subsystem for the first time in each target acquisition period, and taking the performance data as target monitoring data; based on the target monitoring data, the performance monitoring result of the multi-rate simulation model is determined, it is ensured that observation points of all subsystems in each target acquisition period are strictly aligned in time, the problem of performance data dislocation between the subsystems is solved, and the performance monitoring accuracy is improved. The acquired target monitoring data can truly reflect the running state of each subsystem in the same reference period, the performance expression difference of each subsystem under the same time dimension is accurately reflected, and the accuracy of performance monitoring of the multi-rate simulation model is improved.

Description

Technical Field

[0001] This application belongs to the field of simulation technology, and in particular relates to a performance monitoring method, electronic device and storage medium for a multi-rate simulation model. Background Technology

[0002] In semi-real-time simulation systems, a multi-rate simulation model architecture is often used to achieve a balance between high accuracy and efficient computation. These models are widely used in fields such as power system dynamic analysis, aerospace vehicle control verification, and intelligent automotive electronics development. In actual operation, the simulation model running on the CPU needs to interact with external hardware such as Field-Programmable Gate Arrays (FPGAs) and I / O boards in real time. To ensure timing synchronization and data consistency, the overall model is typically divided into multiple subsystems with different computational step sizes based on Simulink. The step size of each subsystem is configured proportionally to match the hardware response characteristics and the dynamic changes in the physical process, thereby improving simulation fidelity and enabling each component to operate at its optimal rate, fully utilizing computing resources.

[0003] Currently, when monitoring the performance of multi-rate simulation models, performance probes are typically injected into each subsystem during each simulation cycle. These probes collect key indicators such as CPU utilization, memory consumption, and step-size execution latency, which are then uniformly reported to the integrated monitoring platform via the simulation management service for users to analyze the system's operational status. However, because each subsystem runs with different step sizes, their execution frequencies inherently differ, making it difficult to align performance data across time dimensions. For example, when the step size ratio of subsystems sm, s1, and s2 is 1:2:4, within the same four reference clock cycles, sm executes four times, s1 executes twice, and s2 executes only once. The number of collected performance data points is uneven, and their temporal distribution is misaligned. This makes cross-subsystem performance comparison and correlation analysis difficult, and fails to accurately reflect the system's operational load status at a uniform moment. To address this issue, existing multi-rate simulation model performance data acquisition processes typically employ a minimum step size subsystem as the clock master, coordinating the synchronous operation of each subsystem in a multiple relationship. After data acquisition, only the latest fixed number (e.g., 10 steps) of performance data from each subsystem is retained, discarding the excess. Finally, the simulation service collects and aggregates this aligned performance data for analysis, aiding in identifying system bottlenecks and optimizing model configuration. However, due to the different running step sizes of each subsystem, the timestamps of the performance data cannot be effectively aligned. Even with the above processing, it cannot accurately reflect the overall operating status of the system within the same baseline period, making horizontal performance comparisons between different subsystems difficult and hindering accurate assessment of performance differences across subsystems over the same time dimension, resulting in low accuracy in performance monitoring.

[0004] Therefore, how to achieve synchronous acquisition of performance data of each subsystem in a multi-rate simulation model in order to improve the accuracy of model performance monitoring has become an urgent problem to be solved. Summary of the Invention

[0005] This application provides a performance monitoring method, electronic device, and storage medium for a multi-rate simulation model, aiming to achieve synchronous acquisition of performance data of each subsystem in the multi-rate simulation model, so as to improve the accuracy of model performance monitoring.

[0006] In a first aspect, embodiments of this application provide a performance monitoring method for a multi-rate simulation model, the method comprising: Based on the step size of each subsystem in the multi-rate simulation model, the minimum common period is determined, and based on the minimum common period, the target acquisition period is determined. Within a preset number of target acquisition cycles, the performance data generated by the first execution of each subsystem within each target acquisition cycle is collected and used as target monitoring data. Based on the target monitoring data, the performance monitoring results of the multi-rate simulation model are determined.

[0007] In one possible implementation, before collecting the performance data generated by each of the subsystems during its first execution within each of the target collection cycles, the method further includes: Based on the input-output connection relationships of each subsystem, the subsystems are topologically sorted to determine the logical execution order of each subsystem; Based on the logical execution order, a unique identifier is assigned to each of the subsystems to determine the execution sequence of each subsystem.

[0008] In one possible implementation, the step of topologically sorting the subsystems based on their input-output connections to determine their logical execution order includes: Based on the input-output connection relationships of each subsystem, determine whether an algebraic cycle exists; If so, the algebraic ring is decoupled to obtain a sortable structure of the algebraic ring; Based on the input-output connection relationships of each subsystem and the sortable structure of the algebraic ring, the subsystems are topologically sorted to determine the logical execution order of each subsystem.

[0009] In one possible implementation, the step of collecting performance data generated by the first execution of each subsystem within each target acquisition cycle within a preset number of target acquisition cycles, and using this data as target monitoring data, further includes: In each of the target acquisition cycles, when any of the subsystems times out, the performance data of the subsystem that timed out at the first timeout in the target acquisition cycle in which the timeout occurred is collected and used as the target monitoring data.

[0010] In one possible implementation, the collection of performance data generated by the first execution of each of the subsystems within each target collection cycle includes: Obtain performance probe start / stop instructions, which are used to indicate whether a performance probe is enabled or disabled. Based on the performance probe start / stop command, the target performance probe is determined from the preset performance probes of each subsystem; The target performance probe collects the performance data generated by the first execution of each of the subsystems within each target acquisition cycle.

[0011] In one possible implementation, determining the performance monitoring results of the multi-rate simulation model based on the target monitoring data includes: Based on the preset number of target acquisition cycles and the execution sequence of each subsystem, the target monitoring data is constructed into a two-dimensional monitoring data table; Based on the two-dimensional table of monitoring data, the performance monitoring results of the multi-rate simulation model are determined.

[0012] In one possible implementation, after determining the performance monitoring results of the multi-rate simulation model based on the target monitoring data, the method further includes: Real-time monitoring of the operating status of each subsystem; When a preset acquisition activation event is detected in any of the subsystems, the step of collecting the performance data generated by the first execution of each subsystem in each target acquisition cycle within a preset number of target acquisition cycles is re-executed as target monitoring data.

[0013] In one possible implementation, determining the minimum common period based on the step size of each subsystem in the multi-rate simulation model, and determining the target acquisition period based on the minimum common period, includes: The least common multiple of the step size of each subsystem is determined as the minimum common period; and the minimum common period is determined as a target acquisition period.

[0014] Secondly, embodiments of this application provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method as described in the first aspect or any of the implementations thereof.

[0015] Thirdly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method as described in the first aspect or any of the implementations thereof.

[0016] Fourthly, embodiments of this application provide a computer program product that, when run on an electronic device, causes the electronic device to execute the method described in the first aspect or any of its implementations.

[0017] The beneficial effects of this application embodiment compared with the prior art are as follows: The minimum common period is determined based on the step size of each subsystem in the multi-rate simulation model, and the target acquisition period is determined based on the minimum common period. A preset number of target acquisition periods are used to synchronously sample each subsystem in the multi-rate simulation model. The performance data generated by the first execution of each subsystem within each target acquisition period is used as the target monitoring data. This ensures that the observation points of all subsystems within each target acquisition period are strictly aligned in time, solving the problem of misalignment of performance data between subsystems. Synchronous acquisition of performance data of each subsystem in the multi-rate simulation model is achieved, enabling the acquired target monitoring data to truly reflect the operating status of each subsystem within the same reference period. By analyzing this target monitoring data, the performance monitoring results of the multi-rate simulation model are determined, accurately reflecting the performance differences of each subsystem in the same time dimension, thus improving the accuracy of performance monitoring of the multi-rate simulation model.

[0018] It is understood that the electronic devices, computer-readable storage media, and computer program products provided in the embodiments of this application have the same beneficial effects as the performance monitoring method of the multi-rate simulation model described above, and will not be repeated here. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a flowchart illustrating a performance monitoring method for a multi-rate simulation model. Figure 2 A flowchart illustrating a performance monitoring method for a multi-rate simulation model provided in an embodiment of this application; Figure 3 A flowchart illustrating another performance monitoring method for a multi-rate simulation model provided in an embodiment of this application; Figure 4A flowchart illustrating an execution sequence generation method in a performance monitoring method for a multi-rate simulation model provided in an embodiment of this application; Figure 5 A flowchart illustrating one implementation of step S2 in a performance monitoring method for a multi-rate simulation model provided in an embodiment of this application; Figure 6 This is a schematic diagram of performance data acquisition in a performance monitoring method for a multi-rate simulation model provided in an embodiment of this application; Figure 7 This is a schematic diagram illustrating another performance data acquisition method in a performance monitoring method for a multi-rate simulation model provided in an embodiment of this application; Figure 8 A flowchart illustrating another implementation of step S2 in a performance monitoring method for a multi-rate simulation model provided in an embodiment of this application; Figure 9 A flowchart illustrating an automatic wake-up performance acquisition mechanism for timeout in a performance monitoring method for a multi-rate simulation model provided in an embodiment of this application; Figure 10 This is a schematic diagram of the structure of a performance monitoring system for a multi-rate simulation model provided in an embodiment of this application. Detailed Implementation

[0021] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0022] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0023] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0024] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0025] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0026] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0027] Figure 1 This is a flowchart illustrating a performance monitoring method for a multi-rate simulation model. Figure 1 The diagram illustrates the data acquisition process for existing multi-rate simulation models. For subsystems sm, s0, and s1, the parameters and step size ratios of each subsystem are first initialized (e.g., sm:s0:s1 = 1:2:4). The subsystem sm with the smallest step size is selected as the clock master, coordinating the synchronous operation of each subsystem according to the multiple ratio. Each subsystem injects a performance probe during the simulation step to collect runtime performance data and compiles performance data for 10 simulation steps. After subsystem s1 completes the collection of 10 steps of performance data, subsystems sm and s0, running faster, will collect more data. However, only the latest 10 steps of performance data are retained, and the excess is discarded. Finally, the aligned 10-step performance data from each subsystem are collected and analyzed to help identify system bottlenecks and optimize model configuration.

[0028] The above method has the following technical problems: 1. The different operating steps of each subsystem and the misaligned timestamps of performance data make it impossible to reflect the overall system status within the same benchmark period, resulting in difficulties in horizontal comparison. 2. When a subsystem times out, the operating status of other subsystems at that moment is not visible, making it difficult to determine whether it is a local anomaly or a coordination problem, and making fault attribution difficult; 3. Lack of a performance view aligned to execution time makes it impossible to linearly reconstruct the actual execution order and dependencies between multi-rate subsystems; 4. The high-frequency subsystem generates a large amount of performance data, while the low-frequency subsystem generates sparse data. The inconsistent data density affects the accurate analysis and display of the overall performance trend.

[0029] To address the aforementioned technical issues, this application proposes a performance monitoring method for multi-rate simulation models. First, during the initialization phase, the step size relationship of each subsystem is clarified, and a minimum common period is determined as a unified time benchmark to resolve the issue of performance data timing misalignment. Second, a subsystem execution sequence is generated through topological sorting, constructing a clear simulation pipeline that facilitates performance bottleneck analysis by execution order. A configurable performance probe mechanism is introduced to support dynamic start and stop monitoring points during runtime, balancing flexibility and low overhead. Within each acquisition cycle, only the first-step performance data of each subsystem is collected, achieving strict alignment of performance data. When a timeout is detected, the system immediately resumes full data acquisition to capture abnormal context. Finally, the data is organized into a two-dimensional table according to subsystem ID and acquisition cycle, supporting horizontal cycle comparison and vertical link analysis, achieving high-precision, low-interference performance monitoring and significantly improving the accuracy and efficiency of multi-rate simulation model performance monitoring.

[0030] For ease of understanding, the technical solution of this application will be described in detail below with reference to the accompanying drawings.

[0031] Figure 2 This is a flowchart illustrating a performance monitoring method for a multi-rate simulation model provided in one embodiment of this application. Figure 3 This is a flowchart illustrating another performance monitoring method for a multi-rate simulation model provided in an embodiment of this application. Figure 2 and Figure 3 As shown, for ease of explanation, only the parts relevant to this embodiment are shown. The method provided in this embodiment includes the following steps: S1. Based on the step size of each subsystem in the multi-rate simulation model, determine the minimum common period, and based on the minimum common period, determine the target acquisition period.

[0032] Preferably, the least common multiple of the step size of each subsystem is determined as the minimum common period; and the minimum common period is determined as a target acquisition period.

[0033] As an example, the subsystem with the smallest step size in the multi-rate simulation model is taken as the reference subsystem, and the step size of the reference subsystem is taken as the reference clock period. The step sizes of the remaining subsystems are all integer multiples of the step size of the reference subsystem. The least common multiple of the step sizes of all subsystems is determined as the minimum common period, and the minimum common period is determined as a target acquisition period. Using the reference clock period as the synchronization source, within a target acquisition period, each subsystem is triggered to execute at multiples of the reference clock period, thereby ensuring that all subsystems achieve time alignment at key nodes of each target acquisition period, providing a synchronization basis for the unified acquisition of subsequent performance data.

[0034] For example, the multi-rate simulation model has three subsystems sm, s0, and s1, with step sizes of 1s, 2s, and 4s, respectively. The subsystem sm with the smallest step size is taken as the reference subsystem, and the reference clock period is its step size of 1s. The minimum common period is 4s, so one target acquisition cycle is 4s. Within one target acquisition cycle, subsystem sm is executed 4 times, subsystem s0 is executed 2 times, and subsystem s1 is executed 1 time.

[0035] Optionally, a target acquisition period can also be set to an integer multiple of the minimum common period.

[0036] S2, within a preset number of target acquisition cycles, collects the performance data generated by the first execution of each subsystem within each target acquisition cycle, and uses it as target monitoring data.

[0037] In one possible implementation, such as Figure 4 As shown, before performing step S2, the following steps may also be included: S21. Based on the input-output connection relationship of each subsystem, perform topological sorting on each subsystem to determine the logical execution order of each subsystem.

[0038] As an example, step S21 may optionally include: Based on the input-output connection relationships of each subsystem, determine whether an algebraic cycle exists; If so, the algebraic ring is decoupled to obtain a sortable structure of the algebraic ring; Based on the input-output connections of each subsystem and the sortable structure of the algebraic ring, the subsystems are topologically sorted to determine the logical execution order of each subsystem.

[0039] Preferably, during the initialization phase of the multi-rate simulation model, a directed dependency graph of all subsystems is constructed based on the input-output connection relationships of each subsystem; based on the input-output connection relationships of each subsystem, it is determined whether an algebraic cycle exists in each subsystem; if so, for strongly coupled subsystems with algebraic cycles, standard decomposition techniques (such as introducing delay units or pseudo-iterative decoupling mechanisms) are used to transform them into sortable structures, ensuring that the sorting results are acyclic and conform to the actual execution flow; based on the input-output connection relationships and the sortable structure of algebraic cycles of each subsystem, topological sorting is performed on each subsystem to determine the logical execution order of each subsystem; if no subsystem has an algebraic cycle, topological sorting is performed directly on each subsystem based on the directed dependency graph to determine the logical execution order of each subsystem.

[0040] S22, assign a unique identifier to each subsystem based on the logical execution order to determine the execution sequence of each subsystem.

[0041] Optionally, this process is consistent with the Simulink underlying module ID generation mechanism. Based on the logical execution order, a unique identifier is assigned to each subsystem through system-level dependency analysis to indicate its execution order. Based on the unique identifier of each subsystem, the execution sequence of each subsystem is constructed. Based on this execution sequence, the entire simulation process of the multi-rate simulation model can be restored into a clear pipeline execution view, accurately mapping the position of each subsystem in the data flow. This allows for precise location of the specific link where delay or bottleneck occurs in performance monitoring, realizing fine-grained performance attribution analysis oriented towards the execution path.

[0042] In one possible implementation, step S2 may also include: In each target acquisition cycle, when any subsystem times out, the performance data of the subsystem that timed out at the first timeout in the target acquisition cycle in which the timeout occurred is collected and used as target monitoring data.

[0043] Preferably, in a continuous preset number of target acquisition cycles, the performance data generated by the first execution of each subsystem that did not time out in each target acquisition cycle, and the performance data of each subsystem that timed out when it first timed out in the target acquisition cycle in which the timeout occurred, are collected as target monitoring data.

[0044] In practice, at the beginning of each target acquisition cycle, only the performance data generated by the first execution of each subsystem within that target acquisition cycle is collected to ensure that the observation points of all subsystems are strictly aligned in time. For subsystems with faster running speeds, the performance data of subsequent execution steps within each target acquisition cycle is not recorded, and only the measurement results of the first step are retained. If a subsystem times out in any target acquisition cycle, the performance context information of its first timeout is collected first for fault attribution analysis.

[0045] As an example, such as Figure 5 As shown, a minimum common period is set based on the step size of each subsystem, and the target acquisition period is determined. Waiting for the next target acquisition period to begin, it is determined whether any subsystem has timed out. If so, the performance data generated by the first execution of each subsystem that did not time out within the target acquisition period, and the performance data of each subsystem that timed out when it first timed out within the target acquisition period, are collected as target monitoring data. If not, the performance data generated by the first execution of each subsystem within the target acquisition period are collected as target monitoring data. Further, it is determined whether the number of target acquisition periods collected has reached a preset number. If so, it enters a sleep state and reports the target monitoring data; otherwise, it waits for the next target acquisition period to begin.

[0046] For example, the multi-rate simulation model has three subsystems: sm, s0, and s1, with step sizes of 1s, 2s, and 4s respectively, a minimum common period of 4s, and a target acquisition period of 4s. Figure 6 As shown, all three subsystems operate normally without timeouts. In two consecutive target acquisition cycles, the performance data generated by each subsystem during its first execution within each target acquisition cycle is collected, i.e., the performance data generated during the clock cycle shown in step 1 of the figure, and used as target monitoring data. Figure 7 As shown, in the first target acquisition cycle, all three subsystems sm, s0, and s1 operate normally. The performance data generated by the first execution of each subsystem in the first target acquisition cycle is collected, which is the performance data generated in the clock cycle shown in step 1 of the figure. In the second target acquisition cycle, subsystems s0 and s1 operate normally, so the performance data generated by the first execution of subsystems s0 and s1 in this target acquisition cycle is collected, which is the performance data generated in the clock cycle shown in step 1 of the figure, as the target monitoring data. Subsystem sm times out in this target acquisition cycle, so the performance data of subsystem sm at the first timeout in this target acquisition cycle is collected, which is the performance data generated in the clock cycle shown in timeout step 1 of the figure, as the target monitoring data.

[0047] It should be noted that the preset quantity can be customized according to the actual situation, and this application does not limit it.

[0048] In one possible implementation, step S2 may include: Obtain performance probe start / stop commands, which are used to indicate whether a performance probe is enabled or disabled. Based on the performance probe start / stop command, the target performance probe is determined from the preset performance probes of each subsystem; The performance data generated by the first execution of each subsystem within each target acquisition cycle is collected using target performance probes.

[0049] Specifically, performance probes are lightweight monitoring modules pre-integrated into the code of each subsystem. Their principle is similar to the performance events (perf events) mechanism in the Linux kernel, recording the start and end times and running status of core phases such as simulation start, main computation, and clock synchronization by inserting timestamp collection points into critical execution paths. Pre-set performance probes have been embedded in each subsystem during the system development phase, and their basic metrics (such as simulation cycle time and idle time) have been set.

[0050] As an example, such as Figure 8 As shown, preset performance probes are integrated into the critical execution paths of each subsystem, and their default enabled basic indicators are set. Users can dynamically select to enable or disable specific preset performance probes through the human-computer interaction device according to diagnostic needs. It is determined whether the performance probe start / stop command indicated by the user has been received. If not, data is collected and reported to each subsystem through each preset performance probe. If so, the target performance probe is determined from the preset performance probes of each subsystem based on the performance probe start / stop command, the target performance probe is dynamically selected and enabled, and data is collected and reported to the subsystem through the target performance probe, so as to achieve refined, low-intrusion and flexibly adjustable performance monitoring capabilities.

[0051] S3, based on target monitoring data, determines the performance monitoring results of the multi-rate simulation model.

[0052] In one possible implementation, step S3 may include: Based on a preset number of target acquisition cycles and the execution sequence of each subsystem, the target monitoring data is constructed into a two-dimensional table of monitoring data; Based on the two-dimensional table of monitoring data, the performance monitoring results of the multi-rate simulation model are determined.

[0053] Preferably, the target monitoring data is organized into columns based on the target acquisition cycle and rows based on the execution sequence of each subsystem. The maximum, minimum, and average execution times of each preset performance probe can be calculated before each column, constructing a two-dimensional table of monitoring data. This ensures data alignment and reflects the actual execution order of each subsystem. Based on this two-dimensional table, the cycle in which each subsystem first times out can be identified through horizontal analysis, and the specific stage where the timeout occurs can be located through vertical analysis. This facilitates rapid analysis of performance bottlenecks and the determination of accurate performance monitoring results.

[0054] In one possible implementation, after performing step S3, the following may also be included: Real-time monitoring of the operational status of each subsystem; When a preset acquisition activation event is detected in any subsystem, the step of collecting the performance data generated by the first execution of each subsystem in each target acquisition cycle within a preset number of target acquisition cycles is re-executed as target monitoring data.

[0055] Optionally, to reduce interference with the real-time performance of the simulation, after continuously collecting a preset number of target acquisition cycles or a specified number of steps (e.g., 100 steps), the system automatically enters a sleep state, suspending data acquisition and reporting until the next preset acquisition activation event (e.g., a timeout event) occurs. At this time, the system exits the sleep state, resumes full data acquisition and reporting, and re-executes the steps of collecting the performance data generated by the first execution of each subsystem in each target acquisition cycle within the preset number of target acquisition cycles, using this data as target monitoring data. This achieves efficient and low-disturbance periodic performance monitoring.

[0056] In one possible implementation, such as Figure 9 As shown, after continuously collecting a preset number of target acquisition cycles or a specified number of steps (such as 100 steps), the system automatically enters a sleep state. During the execution of each subsequent simulation step, the system monitors the runtime of each subsystem in real time and accumulates its timeout count. If no subsystem timeout is detected, the system continues normal simulation. When any subsystem timeout is detected, the system will mark the timeout event and increment the corresponding count. When the next target acquisition cycle arrives, if there is a timeout record, the system will exit the sleep state in advance and immediately resume full data acquisition and reporting.

[0057] The technical solution provided by this implementation method ensures that the performance context information of the relevant subsystems can be captured as soon as an anomaly occurs, improving the observability of timing anomalies and performance bottlenecks, while avoiding unnecessary impact of continuous monitoring on the simulation real-time performance, thus achieving a balance between anomaly response and system efficiency.

[0058] The technical solution provided in this application determines the minimum common period based on the step size of each subsystem in the multi-rate simulation model, and determines the target acquisition period based on the minimum common period. It synchronously samples each subsystem in the multi-rate simulation model through a preset number of target acquisition periods, and uses the performance data generated by the first execution of each subsystem within each target acquisition period as the target monitoring data. This ensures that the observation points of all subsystems are strictly aligned in time within each target acquisition period, solving the problem of misalignment of performance data between subsystems and realizing the synchronous acquisition of performance data of each subsystem in the multi-rate simulation model. This allows the acquired target monitoring data to truly reflect the operating status of each subsystem within the same reference period. By analyzing this target monitoring data, the performance monitoring results of the multi-rate simulation model are determined, accurately reflecting the performance differences of each subsystem in the same time dimension, thus improving the accuracy of performance monitoring of the multi-rate simulation model.

[0059] Figure 10 This is a schematic diagram of the structure of a performance monitoring system for a multi-rate simulation model provided in one embodiment of this application. Based on the above embodiment, this embodiment further explains and optimizes the technical solution. Specifically, in this embodiment, as... Figure 10 As shown, the system includes a clock synchronization module, a topology sorting and ID generation module, a performance probe management module, a data acquisition and synchronization module, an anomaly wake-up and triggering module, and a data aggregation and analysis module.

[0060] Optionally, the clock synchronization module and the topology sorting and ID generation module are used for initialization settings. The clock synchronization module is specifically used to determine the minimum common period based on the step size of each subsystem in the multi-rate simulation model, and to determine the target acquisition period based on the minimum common period, ensuring the time consistency of all components within the system. This is crucial for data accuracy and the sequential recording of events. The topology sorting and ID generation module is specifically used to perform topology sorting on each subsystem based on the input-output connection relationships, determining the logical execution order of each subsystem; and assigning a unique identifier to each subsystem based on the logical execution order, thus determining the execution sequence of each subsystem, which is helpful for subsequent data processing and flow control.

[0061] Optionally, the performance probe management module, data acquisition and synchronization module, and exception wake-up and triggering module are used for the management and control of runtime behavior. The performance probe management module is responsible for deploying and managing performance probes. Specifically, it obtains performance probe start / stop commands and, based on these commands, determines the target performance probe from the preset performance probes of each subsystem. The data acquisition and synchronization module collects performance data generated by the first execution of each subsystem within a preset number of target acquisition cycles, using this data as target monitoring data, and synchronizes it to the central database to ensure data integrity and real-time performance. The exception wake-up and triggering module promptly detects and responds to exceptions, triggering corresponding processing mechanisms. Specifically, it monitors the real-time operating status of each subsystem; when a preset acquisition activation event is detected in any subsystem, it re-executes the step of collecting performance data generated by the first execution of each subsystem within a preset number of target acquisition cycles, using this data as target monitoring data.

[0062] Optionally, a data aggregation and analysis module is used for output and feedback. Specifically, it is used to construct a two-dimensional table of monitoring data based on a preset number of target acquisition cycles and the execution sequence of each subsystem. The two-dimensional table of monitoring data is then analyzed in depth to determine the performance monitoring results of the multi-rate simulation model in order to support decision-making.

[0063] The above module division is based on the principles of functional independence and specialization, allowing each module to focus on its specific responsibilities, facilitating maintenance and upgrades, and improving the system's scalability and flexibility. This approach not only effectively manages and optimizes system performance but also enables rapid adaptation to new demands and technological challenges.

[0064] The performance monitoring system for a multi-rate simulation model provided in this application embodiment has the same beneficial effects as the performance monitoring method for a multi-rate simulation model described above.

[0065] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0066] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments 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. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0067] In summary, the technical solution provided in this application has the following key technical points: 1. Using the reference subsystem clock as the source, construct a unified sampling reference for multi-rate systems to achieve time alignment of cross-rate performance data.

[0068] 2. By decoupling from dependency analysis and algebraic rings, the execution order of subsystem logic is determined, a unique ID is generated, and the simulation pipeline is restored.

[0069] 3. The probe is pre-embedded and can be started and stopped on demand during operation, balancing low invasiveness with monitoring flexibility, and supporting refined performance data acquisition.

[0070] 4. Upon detecting a timeout, full monitoring is immediately activated, breaking through the dormancy limit and ensuring that abnormal contexts are captured and analyzed as soon as possible.

[0071] Based on the above key technical points, the technical solution provided in this application has the following beneficial effects: 1. Achieve performance data alignment By using minimum common period synchronous sampling, the problem of performance data misalignment between multi-rate subsystems is solved, enabling performance data of different durations to be compared and analyzed within the same period. Even if timeout occurs, performance hotspots can still be recorded.

[0072] 2. Restore the execution order to facilitate bottleneck identification. Based on the performance data of the subsystem within the same target acquisition cycle, a simulation pipeline view is constructed. This accurately maps data flow dependencies, facilitating latency tracing along the execution path and enabling fine-grained performance attribution analysis.

[0073] 3. Sensitive and low-interference anomaly response An automatic wake-up mechanism with timeout is introduced to immediately resume full data collection when an anomaly is detected. This not only captures contextual information in the first instance but also avoids the performance overhead of continuous monitoring, thus balancing observability and real-time performance.

[0074] 4. Flexible and controllable monitoring, adaptable to diagnostic needs. The probe supports dynamic start and stop during runtime, combined with a periodic sleep strategy, to achieve on-demand data collection. It satisfies the requirements of routine monitoring with lightweight and low intrusion, while also enabling rapid in-depth diagnosis when problems occur, thus improving debugging efficiency.

[0075] On the other hand, this application also provides a computer storage medium storing executable program code; the executable program code is used to execute the performance monitoring method of any of the above-mentioned multi-rate simulation models.

[0076] On the other hand, this application also provides an electronic device, including a memory and a processor; the memory stores program code that can be executed by the processor; the program code is used to execute the performance monitoring method of any of the above-mentioned multi-rate simulation models.

[0077] For example, the program code may be divided into one or more modules / units, which are stored in the memory and executed by the processor to complete this application. The one or more modules / units may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the program code in an electronic device.

[0078] The electronic device may be a desktop computer, laptop, handheld computer, or cloud server, etc. The electronic device may include, but is not limited to, processors and memory. Those skilled in the art will understand that the electronic device may also include input / output devices, network access devices, buses, etc.

[0079] The processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0080] The memory can be an internal storage unit of the electronic device, such as a hard drive or RAM. It can also be an external storage device, such as a plug-in hard drive, SmartMedia Card (SMC), Secure Digital (SD) card, or Flash Card. Furthermore, the memory can include both internal and external storage units. The memory is used to store the program code and other programs and data required by the electronic device. The memory can also be used to temporarily store data that has been output or will be output.

[0081] The computer storage medium and electronic device described above are created based on the above method. Their technical functions and beneficial effects will not be elaborated here. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0082] The embodiments described above are merely illustrative of several implementations of the present invention, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these all fall within the protection scope of the present invention. Therefore, the protection scope of this invention patent should be determined by the appended claims.

Claims

1. A performance monitoring method for a multi-rate simulation model, characterized in that, The method includes: Based on the step size of each subsystem in the multi-rate simulation model, the minimum common period is determined, and based on the minimum common period, the target acquisition period is determined. Within a preset number of target acquisition cycles, the performance data generated by the first execution of each subsystem within each target acquisition cycle is collected and used as target monitoring data. Based on the target monitoring data, the performance monitoring results of the multi-rate simulation model are determined.

2. The method according to claim 1, characterized in that, Before collecting the performance data generated by each of the subsystems during its first execution within each of the target collection cycles, the method further includes: Based on the input-output connection relationships of each subsystem, the subsystems are topologically sorted to determine the logical execution order of each subsystem; Based on the logical execution order, a unique identifier is assigned to each of the subsystems to determine the execution sequence of each subsystem.

3. The method according to claim 2, characterized in that, The step of performing topological sorting on each subsystem based on the input-output connection relationships of each subsystem to determine the logical execution order of each subsystem includes: Based on the input-output connection relationships of each subsystem, determine whether an algebraic cycle exists; If so, the algebraic ring is decoupled to obtain a sortable structure of the algebraic ring; Based on the input-output connection relationships of each subsystem and the sortable structure of the algebraic ring, the subsystems are topologically sorted to determine the logical execution order of each subsystem.

4. The method according to claim 1, characterized in that, The step of collecting performance data generated by the first execution of each subsystem within each target acquisition cycle within a preset number of target acquisition cycles, as target monitoring data, further includes: In each of the target acquisition cycles, when any of the subsystems times out, the performance data of the subsystem that timed out at the first timeout in the target acquisition cycle in which the timeout occurred is collected and used as the target monitoring data.

5. The method according to claim 1, characterized in that, The collection of performance data generated by the first execution of each of the subsystems within each target collection cycle includes: Obtain performance probe start / stop instructions, which are used to indicate whether a performance probe is enabled or disabled. Based on the performance probe start / stop command, the target performance probe is determined from the preset performance probes of each subsystem; The target performance probe collects the performance data generated by the first execution of each of the subsystems within each target acquisition cycle.

6. The method according to claim 2, characterized in that, The process of determining the performance monitoring results of the multi-rate simulation model based on the target monitoring data includes: Based on the preset number of target acquisition cycles and the execution sequence of each subsystem, the target monitoring data is constructed into a two-dimensional monitoring data table; Based on the two-dimensional table of monitoring data, the performance monitoring results of the multi-rate simulation model are determined.

7. The method according to claim 1, characterized in that, After determining the performance monitoring results of the multi-rate simulation model based on the target monitoring data, the process further includes: Real-time monitoring of the operating status of each subsystem; When a preset acquisition activation event is detected in any of the subsystems, the step of collecting the performance data generated by the first execution of each subsystem in each target acquisition cycle within a preset number of target acquisition cycles is re-executed as target monitoring data.

8. The method according to any one of claims 1 to 7, characterized in that, The determination of the minimum common period based on the step size of each subsystem in the multi-rate simulation model, and the determination of the target acquisition period based on the minimum common period, includes: The least common multiple of the step size of each subsystem is determined as the minimum common period; and the minimum common period is determined as a target acquisition period.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1 to 8.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 8.

Images