Software lag detection methods, devices, electronic equipment and software products

Abstract

This invention discloses a software stuttering detection method, apparatus, electronic device, and program product, relating to the field of semiconductor system software control technology. The method includes: detecting current response indicators, current action indicators, current resource indicators, and current thread indicators to determine an abnormal time window; mapping reference response indicators, reference action indicators, reference resource indicators, and reference thread indicators corresponding to the abnormal time window to different domains; performing software stuttering detection on the reference response indicators, reference action indicators, reference resource indicators, and reference thread indicators for a single domain to obtain a first abnormal indicator for that domain; determining the overall abnormality level of the single domain based on the first abnormal indicator, and determining the abnormal domain among the user interface domain, real-time control domain, and factory automation domain based on the overall abnormality level of the user interface domain, real-time control domain, and factory automation domain. The technical solution of this invention can improve the accuracy of semiconductor software stuttering detection.

Description

Technical Field

[0001] This invention relates to the field of semiconductor system control technology, and in particular to a software stuttering detection method, apparatus, electronic device, and program product. Background Technology

[0002] To mitigate performance degradation issues in semiconductor system software during operation, existing technologies detect software stuttering by monitoring the software's running status or system resource usage. For example, performance metrics such as CPU (Central Processing Unit), memory, and threads are collected during the semiconductor system software's operation and compared to preset thresholds. When one or more performance metrics exceed the threshold, the semiconductor system software is deemed to be in a stuttering state. However, existing technologies suffer from high subjectivity in stuttering judgment and low accuracy in detecting software stuttering. Summary of the Invention

[0003] This invention provides a software stuttering detection method, apparatus, electronic device, and program product, which can improve the accuracy of software stuttering detection in semiconductor systems.

[0004] According to one aspect of the present invention, a software lag detection method is provided, the method comprising: Obtain the current response metrics, current action metrics, current resource metrics, and current thread metrics for the current collection period, and perform software lag detection on the current response metrics, current action metrics, current resource metrics, and current thread metrics to determine abnormal time windows; Obtain the reference response index, reference action index, reference resource index, and reference thread index corresponding to the abnormal time window, and map the reference response index, the reference action index, the reference resource index, and the reference thread index to the user interface domain, the real-time control domain, and the factory automation domain. For a single domain among the user interface domain, the real-time control domain, and the factory automation domain, software stuttering detection is performed on the reference response index, the reference action index, the reference resource index, and the reference thread index to obtain the first abnormal index of the single domain. For a single domain, the overall anomaly level of the single domain is determined based on the first anomaly index, and an anomaly domain is determined among the user interface domain, the real-time control domain, and the factory automation domain based on the overall anomaly level of the user interface domain, the real-time control domain, and the factory automation domain.

[0005] According to another aspect of the present invention, a software lag detection device is provided, the device comprising: The abnormal time window location module is used to obtain the current response index, current action index, current resource index and current thread index of the current collection period, and to perform software lag detection on the current response index, the current action index, the current resource index and the current thread index to determine the abnormal time window; An abnormal time window indicator domain mapping module is used to obtain the reference response indicator, reference action indicator, reference resource indicator and reference thread indicator corresponding to the abnormal time window, and to map the reference response indicator, the reference action indicator, the reference resource indicator and the reference thread indicator to the user interface domain, the real-time control domain and the factory automation domain. The first abnormal indicator detection module is used to perform software stuttering detection on the reference response indicator, the reference action indicator, the reference resource indicator and the reference thread indicator for a single domain in the user interface domain, the real-time control domain and the factory automation domain, to obtain the first abnormal indicator of the single domain. An anomaly domain location module is used to determine the overall anomaly level of a single domain based on the first anomaly index, and to identify the anomaly domain among the user interface domain, the real-time control domain, and the factory automation domain based on the overall anomaly level of the user interface domain, the real-time control domain, and the factory automation domain.

[0006] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, which enables the at least one processor to perform the software stuttering detection method according to any embodiment of the present invention.

[0007] According to another aspect of the present invention, a computer program product is provided, the computer program product comprising a computer program that, when executed by a processor, implements the software stuttering detection method described in any embodiment of the present invention.

[0008] The technical solution of this invention detects software stuttering in semiconductor system software by analyzing current response metrics, current action metrics, current resource metrics, and current thread metrics to determine abnormal time windows. This avoids directly using threshold judgment methods for metrics and improves the accuracy of real-time software stuttering detection in semiconductor system software. Furthermore, by mapping reference response metrics, reference action metrics, reference resource metrics, and reference thread metrics within the abnormal time window to user interface domains, real-time control domains, and factory automation domains, and then performing software stuttering analysis on the reference response metrics, reference action metrics, reference resource metrics, and reference thread metrics for each domain, the solution is further refined. The system detects system lag by obtaining the first anomaly index for a single domain. Based on the first anomaly index, the overall anomaly level of the single domain is determined. Then, based on the overall anomaly level of each domain, the anomaly domain is identified in the user interface domain, real-time control domain, and factory automation domain. By detecting anomalies in the semiconductor system software in real time, the system performs anomaly verification based on reference response indicators, reference action indicators, reference resource indicators, and reference thread indicators within the anomaly time window. Furthermore, the system locates the anomaly domain in the user interface domain, real-time control domain, and factory automation domain based on the overall anomaly level of the single domain, thereby further improving the accuracy of semiconductor system software lag detection.

[0009] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

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

[0011] Figure 1 This is a flowchart of a software lag detection method provided in Embodiment 1 of the present invention; Figure 2 This is a flowchart of another software lag detection method provided in Embodiment 2 of the present invention; Figure 3 This is a schematic diagram of a software stuttering detection device according to Embodiment 3 of the present invention; Figure 4 This is a schematic diagram of the structure of an electronic device that implements the software stuttering detection method of this invention. Detailed Implementation

[0012] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0013] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0014] Example 1 Figure 1 This is a flowchart illustrating a software stuttering detection method according to Embodiment 1 of the present invention. This embodiment of the invention is applicable to situations involving software stuttering detection of semiconductor system software. The method can be executed by a software stuttering detection device, which can be implemented in hardware and / or software and can be configured in an electronic device that carries software stuttering detection functionality.

[0015] See Figure 1 The software lag detection methods shown include: S101. Obtain the current response index, current action index, current resource index, and current thread index for the current collection period, and perform software lag detection on the current response index, current action index, current resource index, and current thread index to determine the abnormal time window.

[0016] The current data collection period refers to the current period for collecting metrics. The abnormal time window is a time window that covers the current data collection period. This can be understood as the time span of the abnormal time window being greater than or equal to the time span of the current data collection period.

[0017] The current response metric is used to quantify the response status of the semiconductor software system during the current acquisition cycle. The current response metric is the data processing result of the current response data acquired during the current acquisition cycle. Specifically, the current response data is the response data directly acquired from the semiconductor software system during the current acquisition cycle. For example, the current response metric may include response time, refresh interval, and / or message processing latency.

[0018] The current action metric is used to quantify the action status of the semiconductor software system in the current acquisition cycle. The current action metric is the data processing result of the current action data acquired in the current acquisition cycle. Specifically, the current action data is the action data directly acquired from the semiconductor software system in the current acquisition cycle. For example, the current action metric may include action time, state transition time, and / or batch processing time.

[0019] Current resource metrics are used to quantify the resource usage of the semiconductor software system during the current acquisition cycle. Current resource metrics are the data processing results of the current resource data collected during the current acquisition cycle. The current resource data is the resource data directly collected from the semiconductor software system during the current acquisition cycle. For example, current resource metrics may include statistics on CPU (Central Processing Unit) utilization, memory utilization, thread count, I / O (input / output) latency, and / or communication latency. The statistics may include the average, peak, increment, and duration of the data within a defined time window.

[0020] The current thread metric quantifies the thread state of the semiconductor software system during the current acquisition period. The current thread metric is the data processing result of the current thread data collected during the current acquisition period. The current thread data is the thread data directly collected from the semiconductor software system during the current acquisition period. For example, the current thread metric may include thread occupancy, blocking duration, lock wait duration, queue backlog, and hotspot function call frequency. Specifically, the thread occupancy rate is the ratio of the CPU busy time of a thread during the current acquisition period to the total duration of the current acquisition period. The blocking duration is the difference between the blocking end time and the blocking start time. The lock wait duration is the cumulative duration of each lock wait time. The queue backlog is the ratio of the difference between the latest position in the queue and the consumed position in the queue to the latest position in the queue. The hotspot function call frequency is the number of times a hotspot function is called during the current acquisition period.

[0021] Specifically, the system acquires the current response data, current action data, current resource data, and current thread data for the current data collection period. It then calculates the current response metric, current action metric, current resource metric, and current thread metric from these data.

[0022] For example, the current response data may include the trigger time and completion time of user actions, interface messages, page refreshes, or system feedback. Accordingly, the difference between the response completion time and the trigger time can be calculated to obtain the response time, i.e., the current response metric.

[0023] For example, the current action data may include the start and end times of the process action. Accordingly, the difference between the end and start times of the process action can be calculated to obtain the action time, i.e., the current action metric.

[0024] For example, current resource data may include CPU utilization, memory utilization, number of threads, I / O start time, I / O end time, communication transmission time, and communication reception time within a set time window before and after the start of the process event. Correspondingly, statistics can be performed on CPU utilization, memory utilization, and number of threads. For example, the mean, peak value, increment, and duration within the set time window can be calculated to obtain statistical values ​​for CPU utilization, memory utilization, and number of threads. The difference between the I / O end time and the I / O start time can be calculated to obtain I / O latency. The difference between the communication reception time and the communication transmission time can be calculated to obtain communication latency. At this point, the statistical values ​​for CPU utilization, memory utilization, number of threads, I / O latency, and communication latency constitute the current resource metrics.

[0025] For example, current thread data may include thread running state, thread blocked state, lock waiting state, queue length, and call stack usage results. Accordingly, thread occupancy rate, blocking duration, lock waiting duration, queue backlog, and hot function call frequency can be calculated, i.e., current thread metrics.

[0026] Specifically, software stuttering detection is performed on the current response metric, current action metric, current resource metric, and current thread metric. When any of these metrics is detected to be abnormal, a time window of a preset size preceding the current data collection period is selected as the starting point to determine the abnormal time window. The preset time window is the size of a pre-defined abnormal time window.

[0027] For example, software stuttering detection methods for indicators include threshold judgment, baseline deviation judgment, anomaly persistence judgment, and / or multi-indicator fusion judgment. When an anomaly is detected by at least one software stuttering detection method, the corresponding indicator is determined to be abnormal. Specifically, the threshold judgment method is used to detect whether the indicator exceeds a preset threshold. The baseline deviation judgment method is used to detect whether the operating condition corresponding to the indicator is significantly higher than the normal operating condition. The anomaly persistence judgment method is used to detect whether the anomaly occurs continuously, i.e., whether the anomaly is a non-infrequent fluctuation. The multi-indicator fusion judgment method is used to detect whether multiple indicators of the same type are simultaneously abnormal.

[0028] For example, the threshold judgment method for response indicators can be to detect whether the response time exceeds a preset response time threshold. The baseline deviation judgment method for response indicators can be to detect whether the response time is higher than a preset multiple or preset deviation of the normal baseline. The abnormal persistence judgment method for response indicators can be to detect whether response indicator abnormalities exist in multiple consecutive collection cycles. The multi-indicator fusion judgment method for response indicators can be to detect whether response time abnormalities and refresh detection abnormalities exist simultaneously.

[0029] For example, the threshold judgment method for action indicators can be to detect whether the action time exceeds the preset action time threshold for the corresponding process action. The baseline deviation judgment method for action indicators can be to detect whether the action time deviates from the preset ratio relative to the average time of the same normal batch. The persistence judgment method for action indicators can be to detect whether the action time of the same process action is repeated in multiple batches. The multi-indicator fusion judgment method for action indicators can be to detect whether there are simultaneous abnormal action time and abnormal state transition time.

[0030] For example, threshold judgment methods for resource metrics can include detecting whether the statistical values ​​of CPU utilization, memory utilization, thread count, I / O (input / output) latency, and communication latency exceed preset resource metric thresholds. Baseline deviation judgment methods for resource metrics can include detecting whether the deviation of resource metrics from the normal baseline exceeds preset resource metric thresholds. Persistence judgment methods for resource metrics can include detecting whether abnormal resource metrics persist for more than a preset duration. Multi-metric fusion judgment methods for resource metrics can include detecting whether both abnormal CPU utilization and abnormal thread count exist simultaneously.

[0031] For example, threshold judgment methods for thread metrics can include detecting whether thread blocking duration, lock waiting duration, queue backlog, or hotspot function call frequency exceed preset thread metric thresholds. Baseline deviation judgment methods for thread metrics can include detecting whether the activity level of abnormal threads within a set time window is significantly higher than historical normal levels. Persistence judgment methods for thread metrics can include detecting whether abnormal threads are continuously active, continuously blocked, or continuously backlogged within a preset continuous duration. Multi-metric fusion judgment methods for thread metrics can include detecting whether high thread occupancy anomalies, lock waiting anomalies, and repeated call stack hotspot anomalies coexist.

[0032] S102. Obtain the reference response indicator, reference action indicator, reference resource indicator, and reference thread indicator corresponding to the abnormal time window, and map the reference response indicator, reference action indicator, reference resource indicator, and reference thread indicator to the user interface domain, real-time control domain, and factory automation domain.

[0033] Reference response metrics are used to quantify the response status of the semiconductor software system within an abnormal time window. The reference response metric is the data processing result of reference response data collected within the abnormal time window. Specifically, the reference response data is response data directly collected from the semiconductor software system within the abnormal time window. For example, the reference response metric may include response time, refresh interval, and / or message processing latency.

[0034] Reference action metrics are used to quantify the action status of the semiconductor software system within an abnormal time window. Reference action metrics are the data processing results of reference action data collected within the abnormal time window. Specifically, reference action data refers to action data collected directly from the semiconductor software system within the abnormal time window. For example, reference action metrics may include action duration, state transition duration, and / or batch processing duration.

[0035] Reference resource metrics are used to quantify the resource usage of a semiconductor software system within an abnormal time window. Reference resource metrics are the data processing results of reference resource data collected within the abnormal time window. Specifically, the reference resource data is resource data directly collected from the semiconductor software system within the abnormal time window. For example, reference resource metrics may include statistics on CPU (Central Processing Unit) utilization, memory utilization, thread count, I / O (input / output) latency, and / or communication latency.

[0036] Reference thread metrics are used to quantify the thread status of a semiconductor software system within an abnormal time window. Reference thread metrics are the data processing results of reference thread data collected within the abnormal time window. Specifically, the reference thread data is thread data collected directly from the semiconductor software system within the abnormal time window. For example, reference thread metrics may include thread occupancy rate, blocking duration, lock wait time, queue backlog, and hotspot function call frequency.

[0037] The User Interface (UI) domain is used to define the software layer through which users interact with semiconductor equipment. For example, semiconductor equipment may include lithography machines, etching machines, and testing machines. The UI domain can provide a visual operating interface, displaying equipment status, alarm information, recipe parameters, and test results. The UI domain interacts with the real-time control domain.

[0038] The Real-Time (RT) domain is responsible for real-time motion control, state machine scheduling, and sequential logic control. For example, the RT domain can handle precise gripping by robotic arms, high-speed contact by probe stations, microsecond-level switching of laser valves, and synchronous control of buses. The RT domain interacts with the factory automation domain.

[0039] The Factory Automation Domain (FA) is used to enable interface communication, data exchange, and status synchronization between this device and the customer's factory.

[0040] Specifically, reference response data, reference action data, reference resource data, and reference thread data are obtained for the abnormal time window. Reference response metrics, reference action metrics, reference resource metrics, and reference thread metrics are then calculated from these data.

[0041] For example, reference response data may include the trigger time and corresponding completion time of user actions, interface messages, page refreshes, or system feedback. Accordingly, the difference between the response completion time and the trigger time can be calculated to obtain the response time, i.e., the reference response metric.

[0042] For example, reference motion data may include the start and end times of a process motion. Accordingly, the difference between the end and start times of a process motion can be calculated to obtain the motion time, i.e., the reference motion index.

[0043] For example, reference resource data may include CPU utilization, memory utilization, number of threads, I / O start time, I / O end time, communication transmission time, and communication reception time within a set time window before and after the start of the process event. Correspondingly, statistics can be performed on CPU utilization, memory utilization, and number of threads. For example, the mean, peak value, increment, and duration within the set time window can be calculated to obtain statistical values ​​for CPU utilization, memory utilization, and number of threads. The difference between the I / O end time and the I / O start time can be calculated to obtain I / O latency. The difference between the communication reception time and the communication transmission time can be calculated to obtain communication latency. In this case, the statistical values ​​for CPU utilization, memory utilization, number of threads, I / O latency, and communication latency constitute the reference resource indicators.

[0044] For example, reference thread data may include thread running state, thread blocked state, lock waiting state, queue length, and call stack usage results. Accordingly, thread utilization, blocking duration, lock waiting duration, queue backlog, and hot function call frequency can be calculated, i.e., reference thread metrics.

[0045] Specifically, based on data source attributes, execution subject attributes, function attribution attributes, or communication object attributes, the reference response indicators, reference action indicators, reference resource indicators, and reference thread indicators corresponding to the abnormal time window are mapped to the user interface domain, real-time control domain, and factory automation domain.

[0046] For example, based on the data source attributes, mapping the reference response indicators, reference action indicators, reference resource indicators, and reference thread indicators corresponding to the abnormal time window to the user interface domain, real-time control domain, and factory automation domain can include: mapping the indicators corresponding to data generated by the front-end page, interface message loop, and interface rendering module to the user interface domain; mapping the indicators corresponding to data generated by real-time control logic, state machine scheduling logic, and action execution logic to the real-time control domain; and mapping the indicators corresponding to data generated by interface communication, state synchronization, data write-back, and external interaction modules to the factory automation domain.

[0047] For example, based on the execution subject attribute, mapping the reference response indicators, reference action indicators, reference resource indicators, and reference thread indicators corresponding to the abnormal time window to the user interface domain, real-time control domain, and factory automation domain can include: if the execution subject corresponding to the data is a front-end process or interface thread, then the indicators corresponding to the data are classified into the user interface domain; if the execution subject is a real-time control process, control thread, or state machine thread, then the indicators corresponding to the data are classified into the real-time control domain; if the execution subject is a communication process, interface thread, or synchronization thread, then the indicators corresponding to the data are classified into the factory automation domain.

[0048] For example, based on functional attribution attributes, mapping the reference response indicators, reference action indicators, reference resource indicators, and reference thread indicators corresponding to the abnormal time window to the user interface domain, real-time control domain, and factory automation domain can include: if the data involves page display, log refresh, or human-machine interaction, then the corresponding indicators are assigned to the user interface domain; if the data involves action scheduling, process control, or state transition, then the corresponding indicators are assigned to the real-time control domain; if the data involves equipment communication, message synchronization, or data exchange, then the corresponding indicators are assigned to the factory automation domain.

[0049] For example, based on the attributes of the communication object, the reference response indicators, reference action indicators, reference resource indicators, and reference thread indicators corresponding to the abnormal time window can be mapped to the user interface domain, real-time control domain, and factory automation domain. This can include classifying the indicators corresponding to data related to user interface interaction into the user interaction domain; classifying the indicators corresponding to data related to equipment control objects into the real-time control domain; and classifying the indicators corresponding to data related to external systems, interface services, or data synchronization objects into the factory automation domain.

[0050] S103. For a single domain in the user interface domain, real-time control domain, and factory automation domain, perform software stuttering detection on the reference response index, reference action index, reference resource index, and reference thread index to obtain the first abnormal index of the single domain.

[0051] The first anomaly indicator is the reference response indicator, reference action indicator, reference resource indicator, and / or reference thread indicator for a single domain where an anomaly exists.

[0052] Specifically, for a single domain in the user interface domain, real-time control domain, and factory automation domain, software stuttering detection is performed on reference response metrics, reference action metrics, reference resource metrics, and reference thread metrics. When any of the reference response metrics, reference action metrics, reference resource metrics, and reference thread metrics is detected to be abnormal, the corresponding metric is identified as the first abnormal metric for that single domain.

[0053] S104. For a single domain, determine the overall anomaly level of the single domain based on the first anomaly indicator, and determine the anomaly domain among the user interface domain, real-time control domain, and factory automation domain based on the overall anomaly level of the user interface domain, real-time control domain, and factory automation domain.

[0054] The overall anomaly level is used to comprehensively characterize the anomaly level of an individual domain within the user interface domain, real-time control domain, and factory automation domain. The anomaly domain is the single domain with the highest overall anomaly level among the user interface domain, real-time control domain, and factory automation domain.

[0055] Optionally, for a single domain, the number of the first abnormal indicators is determined as the overall abnormality level of that domain. The single domain corresponding to the maximum value of the overall abnormality level of the user interface domain, real-time control domain, and factory automation domain is determined as the abnormal domain.

[0056] In an optional embodiment of the present invention, for a single domain, determining the comprehensive anomaly degree of the single domain based on a first anomaly index includes: for a single domain, determining the anomaly start time of the single domain based on the timestamp of the first anomaly index, and determining the preemptive score of each domain based on the chronological order of the anomaly start times of each domain; for a single domain, comprehensively considering the deviation of the first anomaly index from the normal baseline, the duration of the anomaly, the frequency of the anomaly, and the coverage of the first anomaly index to obtain the anomaly intensity of the single domain; for a single domain, comprehensively considering the time overlap and the number of repetitions between the first anomaly index and the process event to obtain the correlation degree of the process event; and for a single domain, comprehensively considering the preemptive score, the anomaly intensity, and the correlation degree of the process event to obtain the comprehensive anomaly degree of the single domain.

[0057] The anomaly initiation time is the earliest timestamp of the first anomaly indicator in a single domain. The pre-emptive score is used to measure the chronological order of anomalies in the user interface domain, real-time control domain, and factory automation domain. Essentially, the pre-emptive score detects which domain—user interface, real-time control, or factory automation—experiences an anomaly first.

[0058] The deviation of the first anomaly indicator from the normal baseline characterizes the degree of anomaly relative to normal operating conditions. Anomaly duration characterizes whether the anomaly corresponding to the first anomaly indicator persists. Anomaly frequency characterizes whether the anomaly corresponding to the first anomaly indicator recurs. First anomaly indicator coverage characterizes the extent to which the time span of the first anomaly indicator within a single domain covers the anomaly time window. Anomaly intensity measures the degree of anomaly in a single domain among the user interface domain, real-time control domain, and factory automation domain. Essentially, anomaly intensity detects which domain—user interface domain, real-time control domain, or factory automation domain—has the most significant anomaly.

[0059] The temporal overlap between the first anomaly indicator and a process event measures the degree of overlap between the first anomaly indicator and a specific process event from a temporal perspective. The frequency of co-occurrence between the first anomaly indicator and a process event characterizes the number of times the first anomaly indicator and a specific process event occur simultaneously. The correlation degree of the process event characterizes the degree of correlation between the first anomaly indicator and the process event. Essentially, the correlation degree of the process event detects which domain (user interface domain, real-time control domain, and factory automation domain) has the strongest correlation with the process event.

[0060] Specifically, for a single domain, the timestamps of each primary anomaly indicator are compared. The earliest timestamp is determined as the anomaly start time for that single domain. According to preset scoring rules, the initial score for each domain is determined based on the order of the anomaly start times for the user interface domain, real-time control domain, and factory automation domain.

[0061] For example, for a single domain, the timestamp of the first detected anomaly indicator within the domain can be extracted to obtain the anomaly start time for each domain. The domain with the earliest anomaly start time is assigned a pre-emptive score of 5; the domain with the second earliest anomaly start time is assigned a pre-emptive score of 3; and the domain with the latest anomaly start time is assigned a pre-emptive score of 1.

[0062] Specifically, for a single domain, the ratio of the difference between the normal baselines corresponding to the first abnormal indicator domain to the normal baseline is calculated to obtain the deviation magnitude of the first abnormal indicator relative to the normal baseline; the abnormal duration of the first abnormal indicator is calculated based on the difference between the last occurrence time and the first occurrence time of the first abnormal indicator; the abnormal occurrence frequency of the first abnormal indicator is determined based on the number of times the first abnormal indicator appears within the abnormal time window; the coverage of the first abnormal indicator is obtained by comparing the time span of the first abnormal indicator within the detected abnormal time window to the time span of the abnormal time window. For a single domain, the deviation magnitude of the first abnormal indicator relative to the normal baseline, the abnormal duration of the first abnormal indicator, the abnormal occurrence frequency of the first abnormal indicator, and the coverage of the first abnormal indicator are normalized and weighted and summed to obtain the abnormal intensity of the single domain.

[0063] Specifically, for a single domain, the degree of overlap between the existence time of the first abnormal indicator and the existence time of the process event is detected to obtain the time overlap between the first abnormal indicator and the process event; the number of times the first abnormal indicator and the process event coexist is detected to obtain the number of times the first abnormal indicator and the process event are repeatedly co-occurred; the time overlap between the first abnormal indicator and the process event and the number of times they are repeatedly co-occurred are weighted and summed to obtain the degree of correlation between the process event.

[0064] Specifically, for a single domain, the weighted sum of the pre-emptive score, anomaly intensity, and correlation degree of process events is used to obtain the comprehensive anomaly degree of the single domain.

[0065] This solution combines the pre-occurrence score, anomaly intensity, and correlation with process events for a single domain to obtain the comprehensive anomaly level of that domain. It takes into account the anomaly occurrence order, anomaly intensity, and correlation with process events, thereby improving the accuracy of the comprehensive anomaly level of a single domain.

[0066] The technical solution of this invention detects software stuttering in semiconductor system software by analyzing current response metrics, current action metrics, current resource metrics, and current thread metrics to determine abnormal time windows. This avoids directly using threshold judgment methods for metrics and improves the accuracy of real-time software stuttering detection in semiconductor system software. Furthermore, by mapping reference response metrics, reference action metrics, reference resource metrics, and reference thread metrics within the abnormal time window to user interface domains, real-time control domains, and factory automation domains, and then performing software stuttering analysis on the reference response metrics, reference action metrics, reference resource metrics, and reference thread metrics for each domain, the solution is further refined. The system detects system lag by obtaining the first anomaly index for a single domain. Based on the first anomaly index, the overall anomaly level of the single domain is determined. Then, based on the overall anomaly level of each domain, the anomaly domain is identified in the user interface domain, real-time control domain, and factory automation domain. By detecting anomalies in the semiconductor system software in real time, the system performs anomaly verification based on reference response indicators, reference action indicators, reference resource indicators, and reference thread indicators within the anomaly time window. Furthermore, the system locates the anomaly domain in the user interface domain, real-time control domain, and factory automation domain based on the overall anomaly level of the single domain, thereby further improving the accuracy of semiconductor system software lag detection.

[0067] In an optional embodiment of the present invention, after determining the abnormal domain in the user interface domain, real-time control domain, and factory automation domain based on the comprehensive abnormality degree of the user interface domain, real-time control domain, and factory automation domain, the method further includes: within the abnormal time window corresponding to the abnormal domain, obtaining the abnormal thread index corresponding to each candidate thread, and determining the thread abnormality contribution, occurrence time score, and thread event correlation degree between the abnormal thread index and the process event for each candidate thread based on the abnormal thread index corresponding to each candidate thread; for a single candidate thread, comprehensively considering the thread abnormality contribution, occurrence time score of the abnormal thread index, and thread event correlation degree to obtain the thread abnormality degree of the candidate thread; and determining the abnormal thread among the candidate threads in the abnormal domain based on the thread abnormality degree of the candidate thread.

[0068] Candidate threads are threads invoked within the exception domain during the exception time window. Candidate threads are used to filter for exception threads within the exception domain. The exception thread index is a reference thread index for candidate threads that detect anomalies within the exception time window.

[0069] The thread anomaly contribution rate refers to the quantitative contribution of the abnormal thread indicators of a candidate thread to the anomaly situation of that candidate thread. The occurrence time score of the abnormal thread indicators characterizes the order in which these indicators appear. This score measures the degree of anomaly of the candidate thread over time. The thread event correlation rate refers to the degree of correlation between the abnormal thread indicators of a candidate thread and a process event. For example, the thread event correlation rate may include the temporal overlap and the number of times these indicators co-occur.

[0070] Thread anomaly level is used to comprehensively characterize the anomaly severity of candidate threads. It can be considered a combined result of the candidate thread's contribution to anomalies, the occurrence time of anomaly indicators, and the correlation between thread anomalies and events.

[0071] An abnormal thread is a thread among the candidate threads that is found to be abnormal. For example, an abnormal thread can be a candidate thread whose abnormality level reaches a preset abnormality level threshold. The preset abnormality level threshold is a pre-defined lower limit for the abnormality level of a thread. Alternatively, an abnormal thread can be a preset number of candidate threads ranked from highest to lowest abnormality level. The preset number of abnormal threads is a pre-defined number of abnormal threads among the candidate threads. The preset abnormality level threshold and the preset number of abnormal threads are used to determine whether a candidate thread is an abnormal thread.

[0072] Specifically, within the abnormal time window corresponding to the abnormal domain, the abnormal thread index corresponding to each candidate thread is obtained from the first abnormal index corresponding to each reference thread index.

[0073] Optionally, the number of abnormal thread metrics corresponding to a candidate thread is determined as the thread abnormality contribution. The number of abnormal thread metrics refers to the number of abnormal thread metrics associated with the candidate thread. Optionally, based on the number of abnormal thread metrics corresponding to the candidate thread, an abnormality score is performed on the candidate thread according to a preset abnormal thread number scoring rule to obtain the thread abnormality contribution of the candidate thread. Here, the preset abnormal thread number scoring is a pre-defined correspondence between the number of abnormal thread metrics and the thread abnormality contribution. Therefore, based on the numerical range of the number of abnormal thread metrics, the corresponding thread abnormality contribution can be determined.

[0074] Specifically, the occurrence time of the abnormal thread indicator for each candidate thread is detected. Based on the earliest occurrence time of the abnormal thread indicator for each candidate thread, an occurrence time score is determined.

[0075] Specifically, the time overlap and recurrence frequency between abnormal thread indicators and process events are detected. For a single abnormal thread indicator of a candidate thread, the time overlap between the abnormal thread indicator and the process event is weighted and summed to obtain the thread event correlation degree between the single abnormal thread indicator and the process event. For a candidate thread, the thread event correlation degree between each abnormal thread indicator and the process event is summed to obtain the thread event correlation degree of the candidate thread.

[0076] Specifically, for a single candidate thread, the thread abnormality degree is obtained by weighted summing of the thread abnormality contribution, the occurrence time score of the abnormal thread index, and the correlation degree of the thread event.

[0077] Optionally, the thread abnormality level of candidate threads is compared with a preset thread abnormality level threshold. If the thread abnormality level of a candidate thread is greater than or equal to the preset threshold, then the candidate thread is determined to be an abnormal thread. Optionally, the thread abnormality levels of each candidate thread are sorted in descending order. The candidate threads with the highest preset number of abnormal threads are determined to be abnormal threads.

[0078] This scheme determines the thread anomaly contribution, occurrence time score, and thread event correlation between the anomaly index and process events of each candidate thread within the anomaly time window corresponding to the anomaly domain. By comprehensively considering the thread anomaly contribution, occurrence time score, and thread event correlation, the scheme obtains the thread anomaly degree of each candidate thread. Based on this degree, the scheme identifies the anomaly thread from among the candidate threads in the anomaly domain. This further refines the identification of anomaly threads within the anomaly domain, improving the precision of software stuttering detection in semiconductor systems. Furthermore, by incorporating the thread anomaly contribution, occurrence time score, and thread event correlation between the anomaly index and process events of each candidate thread, the scheme further enhances the accuracy of anomaly thread detection.

[0079] In an optional embodiment of the present invention, after determining the abnormal thread among the candidate threads in the abnormal domain based on the thread abnormality degree of the candidate threads, the method further includes: determining the candidate functional modules associated with each abnormal thread, and obtaining the number of abnormal threads associated with each candidate functional module, the cumulative thread abnormal value, the number of abnormal module indicators, and the frequency of abnormal occurrence; for a single candidate functional module, comprehensively considering the number of abnormal threads associated with the candidate functional module, the cumulative thread abnormal value, the number of abnormal module indicators, and the frequency of abnormal occurrence to obtain the module abnormality degree of the candidate functional module; and determining the abnormal functional module based on the module abnormality degree of each candidate functional module.

[0080] Candidate functional modules are those associated with abnormal threads in the exception domain. The number of abnormal threads is the number of abnormal threads associated with each candidate functional module. The cumulative thread anomaly value is the sum of the thread anomaly severity of each abnormal thread associated with the candidate functional module. The number of abnormal module indicators is the number of the first abnormal indicator corresponding to the candidate functional module. The anomaly occurrence frequency is the number of times the candidate functional module exhibits an abnormal indicator within the anomaly time window. The module anomaly severity is used to comprehensively characterize the anomaly severity of the candidate functional module. The module anomaly severity can be a comprehensive result of the number of abnormal threads associated with the candidate functional module, the cumulative thread anomaly value, the number of abnormal module indicators, and the anomaly occurrence frequency.

[0081] An abnormal functional module is a functional module among the candidate functional modules that is found to be abnormal. For example, an abnormal functional module can be a candidate functional module whose abnormality level reaches a preset abnormality level threshold. The preset abnormality level threshold is a pre-defined lower limit for the abnormality level of a functional module. Alternatively, an abnormal functional module can be a candidate functional module ranked from highest to lowest abnormality level, representing a preset number of abnormal functional modules. The preset abnormality level threshold and the preset number of abnormal functional modules are used to determine whether a candidate functional module is an abnormal functional module.

[0082] Specifically, based on a pre-determined correspondence table between thread identifiers and module identifiers, or based on the process name, thread name, function symbol, call stack information, and log tags of the thread, candidate functional modules corresponding to each abnormal thread are determined.

[0083] Specifically, for a single candidate functional module, the number of abnormal threads associated with the candidate functional module is counted to obtain the total number of abnormal threads associated with the candidate functional module. The sum of the thread abnormality levels of each abnormal thread associated with the candidate functional module is calculated to obtain the cumulative thread abnormality value of the candidate functional module. The number of first abnormal indicators corresponding to the candidate functional module is counted to obtain the number of abnormal module indicators. The number of times the candidate functional module exhibits abnormal indicators within the abnormal time window is counted to obtain the anomaly frequency.

[0084] Specifically, for a single candidate functional module, the number of abnormal threads associated with the candidate functional module, the cumulative abnormal thread value, the number of abnormal module indicators, and the frequency of abnormal occurrence are weighted and summed to obtain the module abnormality degree of the candidate functional module.

[0085] Optionally, the module anomalousness of candidate functional modules is compared with a preset module anomalousness threshold. If the module anomalousness of a candidate functional module is greater than or equal to the preset module anomalousness threshold, then the candidate functional module is determined to be an anomalous functional module. Optionally, the module anomalousness of each candidate functional module is sorted in descending order. The candidate functional modules with the highest number of preset anomalous functional modules are determined to be anomalous functional modules.

[0086] This solution obtains the number of abnormal threads associated with each candidate functional module, the cumulative abnormal thread value, the number of abnormal module indicators, and the frequency of abnormal occurrences. For a single candidate functional module, it comprehensively considers these factors to determine the module's abnormality level. Based on the abnormality level of each candidate functional module, it identifies the abnormal functional modules. This further refines the identification of abnormal functional modules beyond just abnormal threads, improving the precision of software stuttering detection in semiconductor systems. Furthermore, by incorporating the number of abnormal threads associated with each candidate functional module, the cumulative abnormal thread value, the number of abnormal module indicators, and the frequency of abnormal occurrences to determine the module's abnormality level, the accuracy of abnormal functional module detection is further enhanced.

[0087] In an optional embodiment of the present invention, after determining the abnormal functional modules based on the degree of module abnormality of each candidate functional module, the method further includes: obtaining the abnormal occurrence order and second propagation relationship of the abnormal thread and the abnormal functional module; and connecting the abnormal thread and the abnormal functional module in series according to the abnormal occurrence order and the second propagation relationship to generate an abnormal link.

[0088] The order of exception occurrence is the chronological order in which the exception occurs in the thread and the functional module. The second propagation relationship is used to characterize the data transfer relationships between exception threads, between exception functional modules, and between exception threads and exception functional modules. For example, the second propagation relationship may include call relationships between exception threads, call relationships between exception functional modules, call relationships between exception threads and exception functional modules, interface call relationships, message passing relationships, queue passing relationships, and state transition relationships, etc.

[0089] An exception chain is the data propagation path between an exception thread and an exception functional module. Exception chains are used to characterize the data transfer relationship between exception threads and exception functional modules.

[0090] Specifically, the timestamps of the first abnormal indicators corresponding to each abnormal thread and abnormal functional module are compared, and the order in which the abnormalities of the abnormal threads and abnormal functional modules occur is determined according to the chronological order.

[0091] Specifically, it detects the call relationships between abnormal threads, between abnormal functional modules, between abnormal threads and abnormal functional modules, interface call relationships, message passing relationships, queue passing relationships, and state transition relationships to determine the second propagation relationship between abnormal threads and abnormal modules.

[0092] Specifically, based on the order of anomalies and the second propagation relationship, each abnormal thread and each abnormal functional module are connected in series to generate an abnormal chain.

[0093] This solution connects abnormal threads and abnormal functional modules in series by using the second propagation relationship and the order in which abnormalities occur, generating an abnormal chain. Based on the abnormal threads and abnormal functional modules, the abnormal chain is further determined, thereby improving the precision of software stuttering detection in semiconductor system software.

[0094] Example 2 Figure 2 This is a flowchart of a software stuttering detection method provided in Embodiment 2 of the present invention. Based on the above embodiments, this embodiment of the present invention specifies the step of "determining the abnormal domain in the user interface domain, real-time control domain, and factory automation domain according to the comprehensive degree of abnormality in the user interface domain, real-time control domain, and factory automation domain" as follows: "Determining the performance domain in the user interface domain, real-time control domain, and factory automation domain according to the comprehensive degree of abnormality; determining the abnormal start time of the performance domain according to the timestamp of the first abnormal indicator of the performance domain, and detecting the second abnormal indicator of the user interface domain, real-time control domain, and factory automation domain within a preset traceability time window before the abnormal start time of the performance domain; determining the triggering domain of the performance domain in the user interface domain, real-time control domain, and factory automation domain according to the order of appearance, correlation of change, and first propagation relationship of the first and second abnormal indicators in the user interface domain, real-time control domain, and factory automation domain; determining the abnormal domain according to the performance domain and the triggering domain of the performance domain." This achieves rapid determination of the performance domain and further improves the accuracy of abnormal domain detection. It should be noted that parts not described in detail in this embodiment of the present invention can be found in the descriptions of other embodiments.

[0095] See Figure 2 The software lag detection methods shown include: S201. Obtain the current response index, current action index, current resource index, and current thread index for the current collection period, and perform software lag detection on the current response index, current action index, current resource index, and current thread index to determine the abnormal time window.

[0096] S202. Obtain the reference response metrics, reference action metrics, reference resource metrics, and reference thread metrics corresponding to the abnormal time window, and map the reference response metrics, reference action metrics, reference resource metrics, and reference thread metrics to the user interface domain, real-time control domain, and factory automation domain.

[0097] S203. For a single domain in the user interface domain, real-time control domain, and factory automation domain, perform software stuttering detection on the reference response index, reference action index, reference resource index, and reference thread index to obtain the first abnormal index of the single domain.

[0098] S204. For a single domain, determine the overall anomaly level of the single domain based on the first anomaly indicator, and determine the performance domain among the user interface domain, real-time control domain, and factory automation domain based on the overall anomaly level.

[0099] The presentation domain is the domain that represents anomalies in the user interface domain, real-time control domain, and factory automation domain.

[0100] Specifically, the overall anomaly level of the user interface domain, real-time control domain, and factory automation domain is compared with a preset overall anomaly level threshold. If the overall anomaly level exceeds the preset threshold, then the corresponding user interface domain, real-time control domain, or factory automation domain is determined as the performance domain.

[0101] In an optional embodiment of the present invention, determining the performance domain among the user interface domain, real-time control domain, and factory automation domain based on the overall anomaly level includes: comparing the overall anomaly levels of the user interface domain, real-time control domain, and factory automation domain; and determining the performance domain among the user interface domain, real-time control domain, and factory automation domain based on the maximum value of the overall anomaly level.

[0102] Specifically, the overall anomaly levels of the user interface domain, real-time control domain, and factory automation domain are compared, and the maximum value of the overall anomaly level is selected. The user interface domain, real-time control domain, or factory automation domain corresponding to the maximum value of the overall anomaly level is determined as the performance domain.

[0103] This solution compares the overall anomaly levels of the user interface domain, real-time control domain, and factory automation domain. Based on the maximum value of the overall anomaly level, it determines the performance domain among the user interface domain, real-time control domain, and factory automation domain, thereby improving the detection efficiency of the performance domain.

[0104] S205. Based on the timestamp of the first abnormal indicator of the performance domain, determine the abnormal start time of the performance domain, and detect the second abnormal indicators of the user interface domain, real-time control domain, and factory automation domain within the preset traceability time window before the abnormal start time of the performance domain.

[0105] The preset traceability time window is a pre-defined time window used for trigger domain detection. The second anomaly indicator is the anomaly indicator of the user interface domain, real-time control domain, and factory automation domain within the preset traceability time window prior to the anomaly start time of the performance domain. The second anomaly indicator is used to detect the trigger domain of the performance domain.

[0106] Specifically, the earliest timestamp of the first anomaly indicator in the performance domain is used to obtain the anomaly start time of the performance domain. Using the anomaly start time of the performance domain as the base time, historical response data, historical action data, historical resource data, and historical thread data are obtained from the user interface domain, real-time control domain, and factory automation domain within a preset traceability time window before the anomaly start time of the performance domain.

[0107] Specifically, historical response data, historical action data, historical resource data, and historical thread data are calculated separately to obtain historical response metrics, historical action metrics, historical resource metrics, and historical thread metrics.

[0108] For example, historical response data can include the trigger time and completion time of user actions, interface messages, page refreshes, or system feedback. Accordingly, the difference between the response completion time and the trigger time can be calculated to obtain the response time, i.e., the historical response metric.

[0109] For example, historical action data may include the start and end times of a process action. Accordingly, the difference between the end and start times of a process action can be calculated to obtain the action time, i.e., the historical action metric.

[0110] For example, historical resource data can include CPU utilization, memory utilization, number of threads, I / O start time, I / O end time, communication transmission time, and communication reception time within a set time window before and after the start of a process event. Correspondingly, statistics can be performed on CPU utilization, memory utilization, and number of threads. For example, the mean, peak value, increment, and duration within the set time window can be calculated to obtain statistical values ​​for CPU utilization, memory utilization, and number of threads. The difference between the I / O end time and the I / O start time can be calculated to obtain I / O latency. The difference between the communication reception time and the communication transmission time can be calculated to obtain communication latency. In this case, the statistical values ​​for CPU utilization, memory utilization, number of threads, I / O latency, and communication latency constitute historical resource indicators.

[0111] For example, historical thread data may include thread running state, thread blocked state, lock waiting state, queue length, and call stack usage results. Accordingly, thread occupancy rate, blocking duration, lock waiting duration, queue backlog, and hot function call frequency can be calculated, i.e., historical thread metrics.

[0112] Specifically, for each individual domain in the user interface domain, real-time control domain, and factory automation domain, software stuttering detection is performed on historical response metrics, historical action metrics, historical resource metrics, and historical thread metrics. When any one of these metrics is found to be abnormal, the corresponding metric is identified as the second abnormal metric for that individual domain.

[0113] The historical response metrics are used to quantify the response of the semiconductor software system within a preset traceability time window prior to the onset of an anomaly in the performance domain. The historical response metrics are the data processing results of historical response data collected within the preset traceability time window prior to the onset of an anomaly in the performance domain. The historical response data is the response data directly collected from the semiconductor software system within the preset traceability time window prior to the onset of an anomaly in the performance domain. For example, the historical response metrics may include response time, refresh interval, and / or message processing latency.

[0114] The historical action metrics are used to quantify the action status of the semiconductor software system within a preset retrospective time window prior to the onset of an anomaly in the performance domain. The historical action metrics are the data processing results of historical action data collected within the preset retrospective time window prior to the onset of an anomaly in the performance domain. The historical action data is action data directly collected from the semiconductor software system within the preset retrospective time window prior to the onset of an anomaly in the performance domain. For example, the historical action metrics may include action duration, state transition duration, and / or batch processing duration.

[0115] Historical resource metrics are used to quantify the resource usage of the semiconductor software system within a preset retrospective time window prior to the onset of an anomaly in the performance domain. These historical resource metrics are the data processing results of historical resource data collected within the preset retrospective time window prior to the onset of an anomaly in the performance domain. The historical resource data is resource data directly collected from the semiconductor software system within the preset retrospective time window prior to the onset of an anomaly in the performance domain. For example, historical resource metrics may include statistics on CPU (Central Processing Unit) utilization, memory utilization, thread count, I / O (input / output) latency, and / or communication latency.

[0116] Historical thread metrics are used to quantify the thread state of the semiconductor software system within a preset tracing time window prior to the onset of an anomaly in the performance domain. Historical thread metrics are the data processing results of historical thread data collected within the preset tracing time window prior to the onset of an anomaly in the performance domain. Specifically, historical thread data is thread data directly collected from the semiconductor software system within the preset tracing time window prior to the onset of an anomaly in the performance domain. For example, historical thread metrics may include thread occupancy rate, blocking duration, lock wait duration, queue backlog, and hotspot function call frequency.

[0117] S206. Based on the order of occurrence, correlation of change, and first propagation relationship of the first and second abnormal indicators in the user interface domain, real-time control domain, and factory automation domain, determine the triggering domain of the performance domain in the user interface domain, real-time control domain, and factory automation domain.

[0118] The order of appearance is used to characterize the chronological order in which the first and second anomaly indicators appear. The correlation of changes is used to characterize the correlation between the changing trends of the first and second anomaly indicators. The first propagation relationship is used to characterize the data propagation relationship between the user interface domain, the real-time control domain, and the factory automation domain. The triggering domain is the domain that triggers anomalies in the performance domain.

[0119] Specifically, the domain in which the second abnormal indicator appears earlier than the first abnormal indicator in the performance domain, the trend of the second abnormal indicator is correlated with the trend of the first abnormal indicator in the performance domain, and there is a first propagation relationship between the second abnormal indicator and the performance domain is determined as the triggering domain of the performance domain.

[0120] S207. Determine the exception domain based on the presentation domain and the triggering domain of the presentation domain.

[0121] Specifically, if a triggering domain exists for the presentation domain, then both the triggering domain and the presentation domain are defined as exception domains; if no triggering domain exists for the presentation domain, then the presentation domain is defined as an exception domain.

[0122] The technical solution of this invention, by determining the manifestation domain in the user interface domain, real-time control domain, and factory automation domain based on the comprehensive degree of anomaly, achieves rapid determination of the manifestation domain. Based on the determination of the manifestation domain, and considering the order of appearance, correlation of changes, and first propagation relationship of the second anomaly indicators in the user interface domain, real-time control domain, and factory automation domain within a preset traceability time window prior to the anomaly start time of the manifestation domain, the trigger domain of the manifestation domain is determined in the user interface domain, real-time control domain, and factory automation domain. Based on the manifestation domain and the trigger domain of the manifestation domain, the anomaly domain is determined, further improving the accuracy of anomaly domain detection.

[0123] Based on the above embodiments, the present invention also provides a preferred embodiment of a software lag detection method. This software lag detection method includes: Step 1: Obtain the current response data, current action data, current resource data, and current thread data for the current collection period; calculate the current response metrics, current action metrics, current resource metrics, and current thread metrics for each of the current response data, current action data, current resource data, and current thread data.

[0124] Step 2: Perform software lag detection on the current response metrics, current action metrics, current resource metrics, and current thread metrics to determine the abnormal time window.

[0125] Step 3: Obtain the reference response data, reference action data, reference resource data, and reference thread data corresponding to the abnormal time window, and map the reference response data, reference action data, reference resource data, and reference thread data corresponding to the abnormal time window to the UI domain, RT domain, and FA domain based on the data source attribute, execution subject attribute, function attribution attribute, or communication object attribute of each data.

[0126] Step 4: For each domain, calculate the reference response data, reference action data, reference resource data, and reference thread data corresponding to the abnormal time window to obtain the reference response index, reference action index, reference resource index, and reference thread index; for each domain, perform software stutter detection on the reference response index, reference action index, reference resource index, and reference thread index to determine the first abnormal index for each domain.

[0127] Step 5: Determine the initial score for each domain based on the order of the anomaly start times in each domain; normalize and weight the deviation of the first anomaly indicator from the normal baseline, the duration of the anomaly, the frequency of the anomaly, and the coverage of the first anomaly indicator in each domain to obtain the anomaly intensity value for each domain; for each domain, weight the sum of the time overlap and the number of repetitions between the first anomaly indicator and the process event to obtain the process event correlation value.

[0128] Step 6: Weight and fuse the pre-emptive scores, anomaly intensity values, and process event correlation values ​​of the UI, RT, and FA domains to obtain the comprehensive anomaly value for each domain; determine the domain with the highest comprehensive anomaly value as the performance domain; within a preset traceability time window before the anomaly initiation time, extract the second anomaly indicators for the UI, RT, and FA domains respectively, and compare the order of appearance, change correlation, and first propagation relationship of the second anomaly indicators of each domain with the first anomaly indicators in the performance domain; based on the order of appearance, change correlation, and first propagation relationship of the second anomaly indicators of each domain with the first anomaly indicators in the performance domain, detect the triggering domain of the performance domain in each domain; determine the target domain based on the performance domain and the triggering domain.

[0129] Step 7: Within the abnormal time window corresponding to the target domain, obtain the abnormal thread indicators corresponding to each candidate thread; determine the thread abnormality contribution based on the number of abnormal thread indicators corresponding to the candidate thread; obtain the thread event correlation value between the occurrence time of the abnormal thread indicator and the target process event, and perform a weighted summation of the thread abnormality contribution and the thread event correlation value to obtain the thread abnormality value of each candidate thread; identify the candidate threads whose thread abnormality values ​​exceed the preset threshold or whose ranking is high as abnormal threads.

[0130] Step 8: Based on the pre-established correspondence table between thread identifiers and module identifiers, or based on the process name, thread name, function symbol, call stack information, and log tag of the thread, determine the candidate functional modules corresponding to each abnormal thread; perform weighted fusion on the number of abnormal threads, cumulative thread abnormal value, number of abnormal module indicators, and frequency of abnormal occurrence under a single candidate functional module to obtain the module abnormal value of each candidate functional module; determine the candidate functional modules whose module abnormal value exceeds the preset threshold or whose ranking is high as abnormal functional modules.

[0131] Step 9: Extract the second propagation relationship and the sequence of exceptions between the abnormal thread and the abnormal function module; wherein, the propagation relationship includes the call relationship, interface call relationship, message passing relationship, queue passing relationship or state transition relationship; according to the sequence of exceptions and the second propagation relationship, connect the abnormal thread and the abnormal function module to form an abnormal chain.

[0132] This solution enables precise location of abnormal domains, abnormal threads, abnormal modules, and abnormal links, which can reduce misjudgments and invalid optimizations. It establishes a causal chain between process events and abnormalities, and can significantly improve the accuracy of software stuttering detection in semiconductor system software.

[0133] Example 3 Figure 3This is a schematic diagram of a software stuttering detection device provided in Embodiment 3 of the present invention. This embodiment of the invention is applicable to situations involving software stuttering detection of semiconductor system software. The device can execute a software stuttering detection method and can be implemented in hardware and / or software. The device can be configured in an electronic device that carries a software stuttering detection function.

[0134] See Figure 3 The software lag detection device shown includes: an abnormal time window positioning module 301, an abnormal time window index domain mapping module 302, a first abnormal index detection module 303, and an abnormal domain positioning module 304. The system includes the following modules: An abnormal time window location module 301, which acquires the current response index, current action index, current resource index, and current thread index for the current acquisition period, and performs software stutter detection on these indices to determine the abnormal time window; an abnormal time window index domain mapping module 302, which acquires the reference response index, reference action index, reference resource index, and reference thread index corresponding to the abnormal time window, and maps these indices to the user interface domain, real-time control domain, and factory automation domain; a first abnormal index detection module 303, which performs software stutter detection on the reference response index, reference action index, reference resource index, and reference thread index for a single domain within the user interface domain, real-time control domain, and factory automation domain to obtain the first abnormal index for that single domain; and an abnormal domain location module 304, which, based on the first abnormal index, determines the overall abnormality level of a single domain, and, based on the overall abnormality level of the user interface domain, real-time control domain, and factory automation domain, identifies the abnormal domain within these three domains.

[0135] The technical solution of this invention detects software stuttering in semiconductor system software by analyzing current response metrics, current action metrics, current resource metrics, and current thread metrics to determine abnormal time windows. This avoids directly using threshold judgment methods for metrics and improves the accuracy of real-time software stuttering detection in semiconductor system software. Furthermore, by mapping reference response metrics, reference action metrics, reference resource metrics, and reference thread metrics within the abnormal time window to user interface domains, real-time control domains, and factory automation domains, and then performing software stuttering analysis on the reference response metrics, reference action metrics, reference resource metrics, and reference thread metrics for each domain, the solution is further refined. The system detects system lag by obtaining the first anomaly index for a single domain. Based on the first anomaly index, the overall anomaly level of the single domain is determined. Then, based on the overall anomaly level of each domain, the anomaly domain is identified in the user interface domain, real-time control domain, and factory automation domain. By detecting anomalies in the semiconductor system software in real time, the system performs anomaly verification based on reference response indicators, reference action indicators, reference resource indicators, and reference thread indicators within the anomaly time window. Furthermore, the system locates the anomaly domain in the user interface domain, real-time control domain, and factory automation domain based on the overall anomaly level of the single domain, thereby further improving the accuracy of semiconductor system software lag detection.

[0136] In an optional embodiment of the present invention, the anomaly domain localization module 304 includes: a first-order score determination unit, configured to determine the anomaly start time of a single domain based on the timestamp of a first anomaly indicator, and determine the first-order score of each domain based on the chronological order of the anomaly start times of each domain; an anomaly intensity determination unit, configured to, for a single domain, comprehensively consider the deviation of the first anomaly indicator from the normal baseline, the duration of the anomaly, the frequency of the anomaly, and the coverage of the first anomaly indicator to obtain the anomaly intensity of the single domain; a process event correlation degree determination unit, configured to, for a single domain, comprehensively consider the time overlap and the number of repetitions between the first anomaly indicator and the process event to obtain the process event correlation degree; and a comprehensive anomaly degree determination unit, configured to, for a single domain, comprehensively consider the first-order score, the anomaly intensity, and the process event correlation degree to obtain the comprehensive anomaly degree of the single domain.

[0137] In an optional embodiment of the present invention, the anomaly domain location module 304 includes: a performance domain determination unit, configured to determine a performance domain among the user interface domain, real-time control domain, and factory automation domain based on the maximum value of the comprehensive anomaly degree; a second software stuttering detection index determination unit, configured to determine the anomaly start time of the performance domain based on the timestamp of the first anomaly index of the performance domain, and detect the second anomaly index of the user interface domain, real-time control domain, and factory automation domain within a preset traceability time window before the anomaly start time of the performance domain; a trigger domain determination unit, configured to determine the trigger domain of the performance domain among the user interface domain, real-time control domain, and factory automation domain based on the order of appearance, change correlation, and first propagation relationship of the first anomaly index and the second anomaly index in the user interface domain, the real-time control domain, and the factory automation domain; and an anomaly domain determination unit, configured to determine the anomaly domain based on the performance domain and the trigger domain of the performance domain.

[0138] In an optional embodiment of the present invention, the performance domain determination unit includes: a comprehensive anomaly degree comparison subunit, used to compare the comprehensive anomaly degree of the user interface domain, the real-time control domain, and the factory automation domain; and a performance domain determination subunit, used to determine the anomaly domain among the user interface domain, the real-time control domain, and the factory automation domain based on the maximum value of the comprehensive anomaly degree.

[0139] In an optional embodiment of the present invention, the apparatus further includes: an abnormal thread index acquisition module, configured to, after determining the abnormal domain in the user interface domain, real-time control domain, and factory automation domain based on the comprehensive abnormality degree of the user interface domain, real-time control domain, and factory automation domain, acquire the abnormal thread index corresponding to each candidate thread within the abnormal time window corresponding to the abnormal domain, and determine the thread abnormality contribution, occurrence time score, and thread event correlation degree between the abnormal thread index and the process event of each candidate thread based on the abnormal thread index corresponding to each candidate thread; a thread abnormality degree determination module, configured to, for a single candidate thread, comprehensively consider the thread abnormality contribution, occurrence time of the abnormal thread index, and thread event correlation degree to obtain the thread abnormality degree of the candidate thread; and an abnormal thread determination module, configured to, based on the thread abnormality degree of the candidate thread, determine the abnormal thread among the candidate threads in the abnormal domain.

[0140] In an optional embodiment of the present invention, the apparatus further includes: a candidate functional module determining module, configured to, after determining the abnormal thread among the candidate threads in the abnormal domain according to the thread abnormality degree of the candidate thread, determine the candidate functional module associated with each abnormal thread, and obtain the number of abnormal threads associated with each candidate functional module, the cumulative thread abnormal value, the number of abnormal module indicators, and the frequency of abnormal occurrence; a module abnormality degree determining module, configured to, for a single candidate functional module, comprehensively consider the number of abnormal threads associated with the candidate functional module, the cumulative thread abnormal value, the number of abnormal module indicators, and the frequency of abnormal occurrence to obtain the module abnormality degree of the candidate functional module; and an abnormal functional module determining module, configured to determine the abnormal functional module according to the module abnormality degree of each candidate functional module.

[0141] In an optional embodiment of the present invention, the device further includes: a propagation relationship acquisition module, used to acquire the abnormal occurrence order and second propagation relationship of the abnormal thread and the abnormal function module; and an abnormal link generation module, used to connect the abnormal thread and the abnormal function module in series according to the abnormal occurrence order and the second propagation relationship to generate an abnormal link.

[0142] The software stuttering detection device provided in this embodiment of the invention can execute the software stuttering detection method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the method.

[0143] The acquisition, storage, and application of the current response indicators, current action indicators, current resource indicators, current thread indicators, reference response indicators, reference action indicators, reference resource indicators, reference thread indicators, occurrence time of abnormal thread indicators, thread event correlation between abnormal thread indicators and process events, and propagation relationship between abnormal threads and abnormal functional modules involved in the technical solutions of the embodiments of the present invention all comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0144] Example 4 Figure 4 A schematic diagram of an electronic device 400 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (such as helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0145] like Figure 4 As shown, the electronic device 400 includes at least one processor 401 and a memory, such as a read-only memory (ROM) 402 and a random access memory (RAM) 403, communicatively connected to the at least one processor 401. The memory stores computer programs executable by the at least one processor. The processor 401 can perform various appropriate actions and processes based on the computer program stored in the ROM 402 or loaded into the RAM 403 from storage unit 408. The RAM 403 can also store various programs and data required for the operation of the electronic device 400. The processor 401, ROM 402, and RAM 403 are interconnected via a bus 404. An input / output (I / O) interface 405 is also connected to the bus 404.

[0146] Multiple components in electronic device 400 are connected to I / O interface 405, including: input unit 406, such as keyboard, mouse, etc.; output unit 407, such as various types of displays, speakers, etc.; storage unit 408, such as disk, optical disk, etc.; and communication unit 409, such as network card, modem, wireless transceiver, etc. Communication unit 409 allows electronic device 400 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0147] Processor 401 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 401 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 401 performs the various methods and processes described above, such as software stuttering detection methods.

[0148] In some embodiments, the software stuttering detection method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 408. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 400 via ROM 402 and / or communication unit 409. When the computer program is loaded into RAM 403 and executed by processor 401, one or more steps of the software stuttering detection method described above may be performed. Alternatively, in other embodiments, processor 401 may be configured to perform the software stuttering detection method by any other suitable means (e.g., by means of firmware).

[0149] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations may include: implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0150] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0151] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0152] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0153] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0154] A computing system can include clients and servers. Clients and servers are generally geographically separated and typically interact via communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system. It addresses the shortcomings of traditional physical hosts and VPS (Virtual Private Server) services, such as high management difficulty and weak business scalability.

[0155] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0156] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for detecting software lag, characterized in that, The method includes: Obtain the current response metrics, current action metrics, current resource metrics, and current thread metrics for the current collection period, and perform software lag detection on the current response metrics, current action metrics, current resource metrics, and current thread metrics to determine abnormal time windows; Obtain the reference response index, reference action index, reference resource index, and reference thread index corresponding to the abnormal time window, and map the reference response index, the reference action index, the reference resource index, and the reference thread index to the user interface domain, the real-time control domain, and the factory automation domain. For a single domain among the user interface domain, the real-time control domain, and the factory automation domain, software stuttering detection is performed on the reference response index, the reference action index, the reference resource index, and the reference thread index to obtain the first abnormal index of the single domain. For a single domain, the overall anomaly level of the single domain is determined based on the first anomaly index, and an anomaly domain is determined among the user interface domain, the real-time control domain, and the factory automation domain based on the overall anomaly level of the user interface domain, the real-time control domain, and the factory automation domain.

2. The software lag detection method according to claim 1, characterized in that, The determination of the overall anomaly degree of a single domain based on the first anomaly index includes: For a single domain, the anomaly start time of the single domain is determined based on the timestamp of the first anomaly index, and the priority score of each domain is determined based on the order of the anomaly start times of each domain. For a single domain, the deviation of the first abnormal indicator from the normal baseline, the duration of the abnormality, the frequency of the abnormality, and the coverage of the first abnormal indicator are combined to obtain the abnormality intensity of the single domain. For a single domain, the degree of temporal overlap and the number of recurrences between the first abnormal indicator and the process event are combined to obtain the degree of correlation of the process event; For a single domain, the preemptive score, the anomaly intensity, and the correlation degree of the process event are combined to obtain the comprehensive anomaly degree of the single domain.

3. The software lag detection method according to claim 1, characterized in that, The step of determining the abnormal domain among the user interface domain, the real-time control domain, and the factory automation domain based on the comprehensive anomaly level of the user interface domain, the real-time control domain, and the factory automation domain includes: Based on the overall anomaly level, a performance domain is determined among the user interface domain, the real-time control domain, and the factory automation domain; Based on the timestamp of the first abnormal indicator of the performance domain, determine the abnormal start time of the performance domain, and detect the second abnormal indicator of the user interface domain, the real-time control domain, and the factory automation domain within a preset traceability time window before the abnormal start time of the performance domain. Based on the order of occurrence, correlation of changes, and first propagation relationship of the first and second abnormal indicators in the user interface domain, the real-time control domain, and the factory automation domain, the triggering domain of the performance domain is determined in the user interface domain, the real-time control domain, and the factory automation domain. The exception domain is determined based on the presentation domain and the trigger domain of the presentation domain.

4. The software lag detection method according to claim 3, characterized in that, The step of determining the performance domain among the user interface domain, the real-time control domain, and the factory automation domain based on the overall anomaly level includes: A comparison is made of the overall anomaly levels of the user interface domain, the real-time control domain, and the factory automation domain; Based on the maximum value of the overall anomaly level, the performance domain is determined in the user interface domain, the real-time control domain, and the factory automation domain.

5. The software lag detection method according to claim 1, characterized in that, After determining the anomalous domain among the user interface domain, real-time control domain, and factory automation domain based on the comprehensive anomaly level of the user interface domain, real-time control domain, and factory automation domain, the method further includes: Within the abnormal time window corresponding to the abnormal domain, obtain the abnormal thread index corresponding to each candidate thread, and determine the thread abnormality contribution, occurrence time score, and thread event correlation degree between the abnormal thread index and the process event based on the abnormal thread index corresponding to each candidate thread. For a single candidate thread, the thread abnormality degree is obtained by comprehensively considering the thread abnormality contribution, the occurrence time score of the abnormal thread index, and the correlation degree of the thread event. Based on the degree of thread abnormality of the candidate threads, an abnormal thread is determined from each of the candidate threads in the abnormality domain.

6. The software lag detection method according to claim 5, characterized in that, After determining the abnormal thread from among the candidate threads in the exception domain based on the thread abnormality degree of the candidate threads, the method further includes: Determine the candidate functional modules associated with each abnormal thread, and obtain the number of abnormal threads associated with each candidate functional module, the cumulative thread abnormal value, the number of abnormal module indicators, and the frequency of abnormal occurrence. For a single candidate functional module, the number of abnormal threads associated with the candidate functional module, the cumulative abnormal thread value, the number of abnormal module indicators, and the frequency of abnormal occurrence are combined to obtain the module abnormality degree of the candidate functional module. The abnormal functional modules are determined based on the degree of abnormality of each candidate functional module.

7. The software lag detection method according to claim 6, characterized in that, After determining the abnormal functional modules based on the degree of abnormality of each candidate functional module, the method further includes: Obtain the order of occurrence and second propagation relationship of the abnormal thread and the abnormal functional module; Based on the order in which the anomalies occur and the second propagation relationship, the abnormal thread and the abnormal function module are connected in series to generate an anomaly chain.

8. A software lag detection device, characterized in that, The device includes: The abnormal time window location module is used to obtain the current response index, current action index, current resource index and current thread index of the current collection period, and to perform software lag detection on the current response index, the current action index, the current resource index and the current thread index to determine the abnormal time window; An abnormal time window indicator domain mapping module is used to obtain the reference response indicator, reference action indicator, reference resource indicator and reference thread indicator corresponding to the abnormal time window, and to map the reference response indicator, the reference action indicator, the reference resource indicator and the reference thread indicator to the user interface domain, the real-time control domain and the factory automation domain. The first abnormal indicator detection module is used to perform software stuttering detection on the reference response indicator, the reference action indicator, the reference resource indicator and the reference thread indicator for a single domain in the user interface domain, the real-time control domain and the factory automation domain, to obtain the first abnormal indicator of the single domain. An anomaly domain location module is used to determine the overall anomaly level of a single domain based on the first anomaly index, and to identify the anomaly domain among the user interface domain, the real-time control domain, and the factory automation domain based on the overall anomaly level of the user interface domain, the real-time control domain, and the factory automation domain.

9. An electronic device, characterized in that, The electronic device includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the software stuttering detection method according to any one of claims 1-7.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the software stuttering detection method according to any one of claims 1-7.

Images