Event simulation display method and device of MEMS test system and medium

Abstract

The invention discloses an event simulation display method and device of an MEMS test system and a medium. The method comprises the steps that log data are collected from at least one subsystem; performing timestamp synchronization on each log data, determining at least one event arranged along a timeline according to each log data, and generating an event sequence; determining a target event from the event sequence; and based on the user interface state model, according to the log data corresponding to the target event, reconstructing the user interface when the target event occurs, and displaying the user interface, thereby solving the problem that the isolation state of the multi-source log is not synchronous with time, automatically establishing an event causal chain, reducing the cost and error rate of manual data association, and improving the user experience. The event analysis and fault diagnosis period is shortened, the shutdown loss of equipment is reduced, the complete operation context of the target event can be restored in a visual mode, the technical threshold of system operation and maintenance is reduced, and the accuracy, usability and universality of root cause analysis are improved.

Description

Technical Field

[0001] This invention relates to the fields of industrial diagnostics, log processing, and computer technology, and in particular to an event simulation display method, device, and medium for a MEMS testing system. Background Technology

[0002] In modern manufacturing and testing environments, MEMS (Micro-Electro-Mechanical Systems) sensor test machines are key equipment for ensuring the reliability and performance of micro-sensors in automobiles, consumer electronics, and medical devices. They integrate complex subsystems such as precision actuators, hot chambers, control logic, sensor arrays, and human-machine interfaces. Each subsystem generates massive amounts of log data during operation, providing basic data support for equipment operation status analysis.

[0003] For analyzing the operational status of MEMS sensor testing machines, screen recording systems can record the device interface, and general log analysis platforms can aggregate, visualize, or replay log data. However, inconsistent log formats across subsystems, isolated storage, and time asynchrony caused by independent clock sources necessitate manual event association, a slow and error-prone process that leads to fragmented log data. Existing methods cannot simulate the actual user interface state of the machine when a fault occurs, making it difficult for operators to fully understand the event sequence and lacking the ability to reconstruct the operational context. General log analysis platforms cannot transform low-level system events into user interface states that operators can intuitively observe, forcing root cause analysis to rely on inference rather than direct observation, thus reducing the accuracy of root cause analysis. Summary of the Invention

[0004] This invention provides an event simulation display method, device, and medium for MEMS testing systems to solve the problems of fragmented log data, lack of operational context reconstruction capability in event simulation, inability to convert events into user interface states, and low accuracy of root cause analysis of failures caused by these issues in MEMS testing systems.

[0005] According to one aspect of the present invention, an event simulation display method for a MEMS testing system is provided. The MEMS testing system includes multiple subsystems, and the method includes:

[0006] Log data is collected from at least one subsystem; the log data is timestamped and synchronized, and at least one event arranged along the timeline is determined based on the log data to generate an event sequence; the target event is determined from the event sequence; based on the user interface state model, the user interface at the time the target event occurs is reconstructed according to the log data corresponding to the target event, and then displayed.

[0007] According to another aspect of the present invention, an event simulation display device for a MEMS testing system is provided. The MEMS testing system includes multiple subsystems, and the device includes:

[0008] The log collection module is used to collect log data from at least one subsystem; the synchronization and arrangement module is used to timestamp each log data and determine at least one event arranged along the timeline based on each log data to generate an event sequence; the target event module is used to determine the target event from the event sequence; and the interface display module is used to reconstruct the user interface when the target event occurs based on the user interface state model and the log data corresponding to the target event, and then display it.

[0009] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising:

[0010] At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores a computer program executable 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 execute the event simulation display method of the MEMS test system according to any embodiment of the present invention.

[0011] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions, the computer instructions being configured to cause a processor to execute and implement the event simulation display method of the MEMS test system according to any embodiment of the present invention.

[0012] According to another aspect of the present invention, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps of the method as described in any embodiment of the present invention.

[0013] The technical solution of this invention collects log data from multiple subsystems, generates an event sequence arranged along a timeline after timestamp synchronization, then specifically identifies target events, and finally reconstructs and displays the user interface at the time the target event occurs based on the user interface state model. This solves the problems of isolated state, time asynchrony, and fragmentation of multi-source logs, automatically establishes event causal chains, reduces the cost and error rate of manual data correlation, and can also restore the complete operational context of the target event in a visual way, presenting the interface state, operation path, and system prompts at the time the event occurs, avoiding diagnostic biases caused by missing context and improving the accuracy of root cause analysis of faults. At the same time, this method can directly focus on key target events without sifting through massive amounts of logs, shortening the event analysis and fault diagnosis cycle, reducing equipment downtime losses, and lowering the technical threshold for system operation and maintenance by replacing professional and complex original logs or abstract charts with a user interface, improving usability and universality. It can also provide standardized real-world scenario support for new operator training and team event review, helping to accumulate operation and maintenance experience and improve the overall operation and maintenance capabilities of the team.

[0014] 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

[0015] 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.

[0016] Figure 1 This is a flowchart of an event simulation display method for a MEMS testing system according to Embodiment 1 of the present invention;

[0017] Figure 2 This is a flowchart of another event simulation display method for a MEMS testing system provided in Embodiment 2 of the present invention;

[0018] Figure 3 This is a flowchart of another event simulation display method for a MEMS testing system provided in Embodiment 3 of the present invention;

[0019] Figure 4 This is a schematic diagram of the structure of an event simulation display device for a MEMS testing system according to Embodiment 4 of the present invention;

[0020] Figure 5This is a schematic diagram of the structure of an electronic device that implements the event simulation display method of the MEMS test system according to an embodiment of the present invention. Detailed Implementation

[0021] 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.

[0022] 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 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.

[0023] Example 1

[0024] Figure 1 This is a flowchart of an event simulation and display method for a MEMS testing system according to Embodiment 1 of the present invention. This embodiment is applicable to simulating and displaying events in a MEMS testing system. The method can be executed by an event simulation and display device for the MEMS testing system. This event simulation and display device for the MEMS testing system can be implemented in hardware and / or software and is generally configured in an electronic device. The MEMS system may include multiple subsystems.

[0025] In this embodiment of the invention, the MEMS testing system can be specifically understood as: a testing system related to microelectromechanical systems, which is a dedicated testing device for detecting the reliability and performance of microsensors through multi-module collaboration. The subsystems can be specifically understood as: subdivided modules within the MEMS testing system that possess independent functions and can generate dedicated log data. Each subsystem works collaboratively to support the operation of the entire testing system, and each subsystem can independently collect and record its own operating status and interaction data.

[0026] Correspondingly, such as Figure 1 As shown, the method includes:

[0027] S110. Collect log data from at least one subsystem.

[0028] In this embodiment of the invention, log data can be specifically understood as: structured or semi-structured records automatically generated by each subsystem of the MEMS test system during runtime, which may include information such as subsystem operation instructions, state changes, parameter values ​​and time stamps.

[0029] Specifically, for each subsystem object that needs to be collected, its proprietary format log data generated during operation is extracted through data interfaces, collection programs, or dedicated hardware.

[0030] Optionally, based on the above embodiments, the multiple subsystems may include at least two of the following: a control unit, a sensor array, an environmental monitoring module, and a user interface module.

[0031] In this embodiment of the invention, the control unit can be specifically understood as: a unit in the MEMS testing system used to issue test commands and coordinate the collaborative work of various subsystems. The log it generates can be a record of the execution of test commands, which may include information such as the command issuance time, execution status, and command content.

[0032] A sensor array can be understood as a detection module composed of multiple sensors of different types, used to collect the performance parameters of MEMS sensors and the physical quantities of the test environment. The logs it generates can be parameter monitoring data, which can include measured values ​​such as temperature, pressure and vibration, as well as the collection timestamp.

[0033] The environmental monitoring module can be understood as a dedicated module for monitoring the state of the test environment. The monitoring object can be the environmental indicators of the test chamber (such as a hot chamber). The logs it generates can be thermal temperature and humidity data, and can also be expanded to include environmental parameter records such as airflow and air pressure.

[0034] The user interface module can be specifically understood as an interaction module that connects the operator and the test system. It can include human-computer interaction components such as physical buttons and touch screens. The logs it generates can record the operation of interactive components such as buttons, including the operator's clicks, start and stop operations, and operation time.

[0035] By supporting flexible combinations of subsystems, an adaptive architecture can be built according to the testing scenario requirements of different MEMS sensors, eliminating the need to develop dedicated systems, reducing system development and maintenance costs. At the same time, the modular architecture ensures that each subsystem functions independently, and the failure of a single subsystem will not paralyze the entire testing system, reducing equipment downtime and improving overall operational reliability. In addition, different subsystems correspond to log data of different dimensions. Selecting at least two subsystems can ensure that log data covers key testing aspects such as command issuance, environmental status, parameter feedback, and operation interaction. Furthermore, the log data of multiple subsystems is complementary, enabling precise location of the root cause of the fault through cross-validation, improving the efficiency and accuracy of fault diagnosis.

[0036] S120. Timestamp synchronization is performed on each of the log data, and at least one event arranged along the timeline is determined based on each of the log data to generate an event sequence.

[0037] In this embodiment of the invention, the event sequence can be specifically understood as: a continuous process chain formed by connecting all events in chronological order, presenting the behavioral changes of the system from one moment to another.

[0038] Specifically, the log data from each subsystem is timestamped (this can be achieved by uniformly converting the logs to the same standard time base using high-precision time protocols or hardware clock sources for unified calibration), eliminating time discrepancies between logs from different subsystems. The corresponding behaviors of each subsystem (such as operation instructions and changes in status parameters) are extracted from the synchronized logs, these behaviors are defined as events and arranged in chronological order, and finally these events are chained together to form a continuous event sequence.

[0039] S130. Determine the target event from the event sequence.

[0040] In this embodiment of the invention, the target event can be specifically understood as: a specific event with analytical value selected from the event sequence (which may be an abnormal event or a critical operation event, etc.).

[0041] Specifically, based on the generated time-aligned event sequence, specific events that need to be analyzed in detail are located and extracted from the continuous event stream through preset filtering rules (such as anomaly judgment conditions and key operation identifiers), and these are taken as target events.

[0042] S140. Based on the user interface state model, reconstruct the user interface when the target event occurs according to the log data corresponding to the target event, and display it.

[0043] In this embodiment of the invention, the user interface state model can be specifically understood as: a model that defines the layout of interface elements, state transition rules, and display mapping logic (such as displaying a red warning box if vibration exceeds the limit), which is a rule base for converting log data into the visual state of the interface. The user interface can be specifically understood as: based on log data and the state model, restoring the real state of the machine interface when the target event occurs (such as button states and prompt information), rather than the interface of the pre-recorded video.

[0044] Specifically, the user interface state model is invoked, taking the log data corresponding to the target event as input. Through the rules and logic defined by the model, the information in the log is mapped to the visual state of the interface elements (such as button disabling and error message display). The simulation engine generates a high-fidelity visual simulation of the interface in real time based on these states (not pre-recorded video, supporting user interaction with interface elements), thereby reconstructing the user interface when the target event occurs and displaying the interface.

[0045] Understandably, the user interface can be integrated into the digital twin framework of a MEMS testing system for scenarios such as remote monitoring. The user interface can include a timeline slider, a central simulation panel, an overlay indicator, and a log detail panel. Correspondingly, the timeline slider allows selection of a target event's time point. The central simulation panel dynamically recreates the machine interface state at that time point (e.g., a touchscreen or physical control panel), the overlay indicator synchronously displays the corresponding sensor parameters and control signals, and the log detail panel provides log entries for that event, enabling drill-down analysis. Simultaneously, the visual timeline marks the target event (such as an anomaly window or critical event window) on the timeline (e.g., using different colors for highlighting), achieving accurate restoration of the interface state and providing intuitive visualization support for anomaly analysis and drill-down diagnostics through multi-component linkage.

[0046] Specifically, the visual timeline can be understood as an interface that visually displays a sequence of events, integrating events from different sources and annotating key information (such as exception windows and critical events) via a timeline. The digital twin framework can be understood as an architecture that links virtual copies of physical devices with the actual system; the reconstructed user interface is the framework's visualization component. The simulation engine can be understood as a functional module that converts execution log data into interface states and generates a visual interface in real time, supporting user interaction with interface elements.

[0047] The technical solution of this invention collects log data from multiple subsystems, generates an event sequence arranged along a timeline after timestamp synchronization, then specifically identifies target events, and finally reconstructs and displays the user interface at the time the target event occurs based on the user interface state model. This solves the problems of isolated state, time asynchrony, and fragmentation of multi-source logs, automatically establishes event causal chains, reduces the cost and error rate of manual data correlation, and can also restore the complete operational context of the target event in a visual way, presenting the interface state, operation path, and system prompts at the time the event occurs, avoiding diagnostic biases caused by missing context and improving the accuracy of root cause analysis of faults. At the same time, this method can directly focus on key target events without sifting through massive amounts of logs, shortening the event analysis and fault diagnosis cycle, reducing equipment downtime losses, and lowering the technical threshold for system operation and maintenance by replacing professional and complex original logs or abstract charts with a user interface, improving usability and universality. It can also provide standardized real-world scenario support for new operator training and team event review, helping to accumulate operation and maintenance experience and improve the overall operation and maintenance capabilities of the team.

[0048] Example 2

[0049] Figure 2 This is a flowchart of another event simulation display method for a MEMS testing system provided in Embodiment 2 of the present invention. This embodiment is a refinement of the "determining the target event from the event sequence" in the above embodiments. Figure 2 As shown, the method includes:

[0050] S210. Collect log data from at least one subsystem.

[0051] S220. Timestamp the log data and determine at least one event arranged along the timeline based on the log data to generate an event sequence.

[0052] S230. Based on the log data corresponding to the events in the event sequence, perform event anomaly detection and take the identified abnormal events as target events.

[0053] Specifically, based on the log data corresponding to each event in the event sequence, event anomaly detection is performed through preset anomaly judgment rules (such as parameter range and operation logic), and the identified abnormal events are determined as target events. It also supports manual intervention, allowing staff to directly select specific events from the event sequence as target events, thus balancing the efficiency of automatic filtering with the flexibility of manual analysis, and providing a focused analysis object for subsequent interface reconstruction.

[0054] Optionally, based on the above embodiments, performing event anomaly detection according to the log data corresponding to the events in the event sequence may include:

[0055] Based on the log data corresponding to the events in the event sequence, abnormal events are identified using a set threshold or an anomaly detection model.

[0056] In this embodiment of the invention, the threshold setting can be specifically understood as: a predefined range of normal state parameters or behavioral rules (such as sensor temperature less than or equal to 85 degrees Celsius, vibration less than or equal to 5 times the acceleration due to gravity, or command execution time less than or equal to 10 seconds, etc.), used to determine whether an event is abnormal. The anomaly detection model can be specifically understood as: an intelligent model based on an algorithm that learns the characteristics of normal events and identifies abnormal events that deviate from the characteristics.

[0057] Specifically, based on the log data corresponding to each event in the event sequence, the parameters and behaviors in the logs are compared with preset thresholds, and events exceeding the thresholds are judged as abnormal; alternatively, a trained anomaly detection model is used to analyze the feature deviation of the log data and identify events that do not conform to normal patterns. These two methods can filter out abnormal events from the event sequence, providing a basis for subsequently determining target events.

[0058] By setting thresholds, parameter ranges can be automatically compared. The anomaly detection model can analyze event characteristics in batches, shortening the anomaly identification time and replacing the traditional manual method of checking massive logs line by line, thus improving the efficiency of fault diagnosis. At the same time, the unified threshold standard and fixed model algorithm avoid the judgment bias caused by experience and state differences during manual screening, ensuring that the anomaly judgment results for the same log data are objective and consistent, providing a reliable analytical basis for subsequent diagnosis. In addition, by setting thresholds to adapt to explicit anomalies that exceed the parameters, the anomaly detection model can identify logical implicit anomalies, achieving comprehensive coverage of various anomaly scenarios in MEMS testing systems and reducing the probability of anomaly omission.

[0059] Optionally, based on the above embodiments, the anomaly detection model may include at least one of the following: an autoencoder, an isolation forest, a single-class support vector machine, and a recurrent neural network trained using historical log data items as samples, wherein the model is periodically retrained using verified normal operating data.

[0060] Specifically, considering the log data characteristics of the MEMS testing system, at least one anomaly detection model is selected from autoencoders, isolated forests, single-class support vector machines, and recurrent neural networks trained using historical log data items. Autoencoders, isolated forests, and single-class support vector machines are suitable for parameter anomaly identification in unsupervised scenarios, while recurrent neural networks excel at capturing the temporal features of logs and can identify logical anomalies (such as no sensor feedback after an instruction is issued). The selected model is used to analyze the time-aligned event sequence log data to filter out anomalous events. To prevent the model from failing due to changes in system operating status (such as parameter adjustments and changes in the test scenario), validated normal operating data (such as logs from fault-free periods) can be used to retrain the model at fixed intervals, updating the model's feature learning boundaries. This ensures that the model can always accurately distinguish between normal and anomalous events, providing stable and reliable anomaly identification results for subsequent target event determination and user interface reconstruction.

[0061] By offering a diverse selection of models, the technical advantages of different models are fully leveraged. Among them, autoencoders, isolated forests, and single-class support vector machines are suitable for parametric explicit anomaly identification in unsupervised scenarios, while recurrent neural networks excel at capturing temporal features to identify logical implicit anomalies. These models can be flexibly selected based on the characteristics of log data from MEMS testing systems to achieve comprehensive coverage of various anomalies and reduce the false negative rate. At the same time, the models are periodically retrained using validated normal operating data, which can update the model's feature cognition of normal states. This effectively responds to dynamic changes such as system changes in test objects and adjustments to operating parameters, preventing model failure due to feature drift and maintaining long-term stable detection capabilities. In addition, multiple models are available for on-demand deployment, eliminating the need to develop dedicated algorithms for different anomaly scenarios. Periodic retraining can be completed through automated processes, reducing algorithm development and maintenance costs and enhancing the practicality and universality of the technical solution.

[0062] S240. For the detected abnormal event, obtain the log data of the abnormal event within a set time window, and use it as abnormal log data for reconstructing the user interface of the abnormal event.

[0063] In this embodiment of the invention, the setting of the time window can be specifically understood as: a time range for extracting related log data, defined around the occurrence time of the abnormal event. It is not a fixed duration, but a time period dynamically determined by combining the default benchmark and intelligent strategy, so as to fully cover the causal chain of the abnormal event.

[0064] Specifically, for detected abnormal events, a set time window covering the causal sequence of the event is determined. Initially, a fixed duration (e.g., 30 seconds before and after the abnormality trigger point) is used as the default window. Then, by analyzing the causal relationships of the events, the root cause event and the final result event are identified. The window is intelligently expanded to cover the complete fault chain. For example, first, taking the detected abnormal event as the core node, the time-aligned event sequence within its default time window is retrieved. Using preset causal association rules (e.g., "Event B will inevitably be triggered within a certain time after Event A occurs" and "Parameter abnormality is strongly correlated with a certain operation command"), the starting event that triggered the abnormality (i.e., the root cause event) is traced backward, while the final system state event caused by the abnormality (i.e., the final result event) is traced forward. Subsequently, the starting boundary of the default time window is adjusted to the occurrence time of the root cause event, and the ending boundary is adjusted to the occurrence time of the final result event, thus completing the intelligent expansion of the window. In complex fault scenarios, an anomaly detection model can also be used to assist in determining the time sequence boundaries. Then, log data from each subsystem is extracted from this time window and used as abnormal log data.

[0065] It is important to emphasize that this data is not directly used for display. It needs to be interpreted and integrated based on the user interface state model to reconstruct a high-fidelity interface state. For example, discrete low-level log entries are first interpreted (such as SAFETY_DOOR_OPEN_SENSOR=1, indicating that the security door sensor's state data log entry shows that the security door is open). Then, these entries are mapped to a machine-specific user interface state model (such as a finite state machine). Based on the model rules (such as disabling the "Start Test" button when the security door is open), an overall snapshot of the interface at any given moment is synthesized. Finally, the simulation engine renders a user interface consistent with the one at the time of the abnormal event, realizing the transformation from data to a visual interface, which is different from the simple raw log display.

[0066] S250. Based on the user interface state model, reconstruct the user interface when the target event occurs according to the log data corresponding to the target event, and display it.

[0067] The technical solution of this invention collects log data from multiple subsystems, generates an event sequence arranged along a timeline after timestamp synchronization, and performs event anomaly detection by combining the event sequence with log data. Identified abnormal events are used as target events, and log data of the abnormal event within a set time window is obtained for reconstructing the corresponding user interface. This automatically locks onto abnormal events, eliminating the need for engineers to manually search through massive amounts of logs line by line, filtering irrelevant normal operation data, focusing on the core of the fault, reducing data processing volume and filtering time, and improving diagnostic efficiency. The set time window can completely retain relevant log data before, during, and after the abnormal event, forming complete fault chain data, providing support for reconstructing the complete fault occurrence process, avoiding diagnostic biases caused by missing context, helping engineers accurately trace the root cause of the fault, avoiding data incompleteness or simulation distortion caused by differences in the range of manually extracted logs, ensuring high fidelity of user interface reconstruction, and reducing the technical threshold, labor costs, and time costs of fault analysis. Ultimately, the user interface at the time of the target event is reconstructed and displayed based on the user interface state model, which solves the problems of isolation status, time asynchrony and fragmentation of multi-source logs, automatically establishes the event causal chain, reduces the cost and error rate of manual data correlation, and can also restore the complete operation context of the target event in a visual way, presenting the interface state, operation path and system prompts at the time of the event, avoiding diagnostic bias caused by missing context, and improving the accuracy of root cause analysis of faults.

[0068] Example 3

[0069] Figure 3 This is a flowchart of another event simulation display method for a MEMS testing system provided in Embodiment 3 of the present invention. This embodiment is a refinement of the "timestamp synchronization of each log data" in the above embodiments. Figure 3 As shown, the method includes:

[0070] S310. Collect log data from at least one subsystem.

[0071] Furthermore, based on the above embodiments, after collecting log data from the plurality of subsystems respectively, the method may further include:

[0072] If there is missing log data, the missing or corrupted log data items are estimated by using time interpolation or predictive modeling through the data gap compensation module, and the user interface displays an uncertainty indicator for the estimated state when the simulation interface is displayed.

[0073] In this embodiment of the invention, missing log data can be specifically understood as: during the process of collecting logs from multiple subsystems, due to reasons such as communication interruption, sensor failure, or storage anomaly, log data for some subsystems or some time points is not successfully acquired or is corrupted. The data gap compensation module can be specifically understood as: a functional module used to handle the problem of missing log data, filling data gaps through a preset algorithm to ensure the integrity of the log data.

[0074] Temporal interpolation can be understood as a completion method based on adjacent valid log data. It generates estimated data for the missing time period using linear or non-linear calculations based on known time points before and after the missing data (e.g., calculating the estimated value for the 15th second based on valid data from the 10th and 20th seconds of a subsystem). Predictive modeling can be understood as a completion method based on machine learning or statistical models. It trains a model using complete historical log data and predicts reasonable values ​​for missing data, suitable for scenarios with a large range of missing data.

[0075] The uncertainty indicator can be understood as: in the reconstructed user interface, a visual identifier (such as color coding and symbol hints) is used to mark the estimated data, distinguish between the actual collected data and the estimated data, and indicate to the user that the state of this part is the inference result.

[0076] Specifically, after collecting log data from all subsystems, the system performs a full verification of each subsystem's logs to check for data gaps, corruption, or missing data. If missing log data is detected, the data gap compensation module is activated. Based on the type and range of the missing data, it selects either time interpolation or predictive modeling to generate estimated values ​​for the missing log data items. For example, time interpolation is used for scenarios with a small range of missing data (such as calculating estimated temperature and humidity values ​​for the missing period based on the effective temperature and humidity values ​​before and after the missing data in the environmental monitoring module), while predictive modeling is used for scenarios with a large range of missing data (such as predicting missing button operation records in the user interface module based on a model trained on historical complete operation logs) to generate reasonable estimated values ​​for the missing data items. The completed log data is then used for subsequent timestamp synchronization and event sequence generation processes.

[0077] When reconstructing and displaying the user interface based on the completed data, uncertainty indicators are added to the interface states corresponding to all data estimated by the algorithm (such as marking the estimated sensor parameters with a preset color or adding a preset symbol next to the button operation record) to distinguish between the actual collected data and the estimated data, and to avoid users misjudging the actual operating state of the system.

[0078] To address data gaps or corruption issues arising during multi-subsystem log collection, two methods—time interpolation and predictive modeling—are used to fill in the gaps, ensuring the integrity of the time-aligned event sequence and preventing data breakpoints from halting fault analysis. The two methods can be flexibly selected based on the extent of the missing data: interpolation quickly generates high-confidence estimates for small gaps, while model prediction ensures data continuity for large gaps, balancing efficiency and result reliability. An uncertainty indicator has been added to the redesigned user interface to clearly distinguish between real collected data and algorithm-estimated data, helping users verify the rationality of estimates during fault diagnosis and avoiding the risk of misinterpreting estimated data as the actual system state, thus improving the accuracy of analysis results. Furthermore, data completion can be completed without interrupting the testing process, reducing downtime, lowering manual intervention costs, and enhancing the continuous operation capability of the MEMS testing system, eliminating the need to pause testing or restart the system due to partial data loss.

[0079] S320. The log data is calibrated using a network time protocol or internal clock offset to convert the timestamps from each subsystem into standard timestamps, and at least one event arranged along the timeline is determined based on the log data to generate an event sequence.

[0080] In this embodiment of the invention, Network Time Protocol (NTP) can be specifically understood as: a network-based time synchronization technology that obtains Coordinated Universal Time (UTC) by connecting to a public or private NTP server, corrects the local clock deviations of each subsystem, and achieves unified timestamps across multiple devices. Internal clock offset calibration can be specifically understood as: suitable for closed systems without a network, using the clock of a core subsystem (such as a control unit) as a reference, calculating the clock offsets of other subsystems by periodically sending heartbeat packets, and thus correcting the timestamp synchronization method. Standard timestamp can be specifically understood as: a time stamp unified to the same time base, eliminating time differences caused by independent crystal oscillators or hardware delays in different subsystems, and ensuring the consistency of the time dimension of log data.

[0081] Specifically, for the collected log data from each subsystem, a network time protocol or internal clock offset calibration method is selected based on the system deployment scenario to convert the local timestamps of each subsystem log into a unified standard timestamp, eliminating time deviations. For example, if the system is connected to a network, NTP is used, and each subsystem obtains standard UTC time by connecting to an NTP server to correct local clock deviations and generate standard timestamps. If the system is in a closed environment without a network, internal clock offset calibration is used, with the control unit's clock as the reference, periodically sending time-stamped heartbeat packets to other subsystems to calculate and compensate for the clock offset of each subsystem, achieving timestamp unification. After time synchronization is completed, key behavioral information of each subsystem (such as command issuance in control logs, parameter exceeding limits in sensor logs, and button operations in user interface logs) is extracted from the time-aligned log data and defined as events. All events are then concatenated according to the order of standard timestamps to generate an event sequence arranged along a timeline.

[0082] Optionally, based on the above embodiments, determining multiple events arranged along a timeline according to the log data and generating an event sequence may include at least one of the following:

[0083] Event identification is performed based on log data from different subsystems to determine system events in each subsystem; cross-system events with correlation are identified based on shared event identifiers in the log data from different subsystems; and system events that meet the time proximity condition and the set event causality condition are identified as cross-system events with correlation based on the system events identified from the log data of each subsystem.

[0084] In this embodiment of the invention, system events can be specifically understood as: independent behaviors or state changes with business significance identified from the log data of a single subsystem, including explicitly marked events (such as TEST_STARTED of the control unit, indicating a test start event) and implicit events (such as OVER_TEMPERATURE_EVENT triggered by a sensor temperature exceeding a threshold, indicating an over-temperature event). Shared event identifiers can be specifically understood as: unified identifiers carried by events across subsystems (such as a unique transaction identifier TX_ID), used to establish explicit associations between events in the logs of different subsystems.

[0085] Cross-system events can be understood as a set of events involving multiple subsystems that are logically related. Their correlation can be determined through shared identifiers, or by satisfying time proximity conditions and setting causal conditions. Time proximity conditions can be understood as events in different subsystems whose timestamps are within a set threshold range (e.g., ±5 milliseconds), serving as the time dimension for determining event correlation. Setting causal conditions can be understood as event triggering rules based on pre-defined business logic (e.g., a stalled motor inevitably causes a vibration spike), serving as the logical dimension for determining event correlation.

[0086] Specifically, for the log data of each subsystem, the independent system events of each subsystem are identified. For example, for logs with predefined tags (such as ALARM:OVER_TEMP (alarm: temperature too high) of the control unit and USER_EVENT:BUTTON_PRESS (user event: button pressed) of the user interface module), explicit system events are directly extracted; for raw logs without tags (such as continuous sensor temperature readings), significant state changes are converted into implicit system events (such as OVER_TEMPERATURE_EVENT) according to preset rules (such as temperature exceeding 85 degrees Celsius).

[0087] Subsequently, cross-system related events were identified in two ways: by directly matching explicitly related events using shared event identifiers in the logs of different subsystems, or by filtering out system events without shared identifiers that meet the time proximity condition and conform to the preset causal logic, and determining them as implicitly related cross-system events.

[0088] In a specific example, for events involving cross-subsystem collaborative operations (such as a user clicking "Start Test"), the unique transaction identifier carried in the log (such as TX789) is used to precisely match the button operation events of the user interface module with the test start command events of the control unit; for events without shared event identifiers, system events with timestamp intervals within a set threshold (such as motor stall events and vibration spike events within 5 milliseconds) and conforming to business causal logic (such as stall causing vibration) are selected and identified as implicitly related cross-system events.

[0089] Finally, all identified system events and cross-system events are arranged in chronological order according to a unified standard timestamp, generating an event sequence distributed along the timeline.

[0090] By identifying independent system events with business significance from heterogeneous logs of different subsystems, the original discrete log data is transformed into standardized event units. Cross-system correlations are then established using two strategies, breaking down information silos between subsystems and solving the problems of inconsistent log formats and difficulty in directly identifying event correlations. This provides a unified analysis platform for subsequent anomaly detection. Simultaneously, shared event identifiers enable accurate matching of collaboratively operated events with unified tags, while temporal proximity and causal conditions cover the correlation needs of implicit events without pre-defined tags. These two complementary approaches address both explicit and implicit event correlations, avoiding the omission of critical events due to a single correlation method. This approach enhances the accuracy and comprehensiveness of cross-system event correlation. Furthermore, the event sequences generated through time sorting and correlation analysis clearly present the chronological order and causal relationships of each event, helping technicians quickly locate the trigger source and clarify the interconnected impact of subsystem events when system anomalies occur, thus improving the efficiency and accuracy of root cause analysis. Moreover, this correlation strategy does not depend on the log format of a specific subsystem, supporting both standardized log systems with shared identifiers and simple log scenarios without preset tags. It can be flexibly applied to MEMS test systems with different architectures without requiring large-scale modifications to existing subsystems, reducing the deployment cost and adaptation difficulty of the technical solution.

[0091] S330. Determine the target event from the event sequence.

[0092] S340. Based on the user interface state model, reconstruct the user interface when the target event occurs according to the log data corresponding to the target event, and display it.

[0093] Optionally, based on the above embodiments, the user interface state model may include:

[0094] Element hierarchy layout is used to define the elements displayed on the interface and the parent-child relationships between elements; state transition rules are used to convert event log data into element state change logic; element display mapping relationship is used to map the logical state of an element to its display state; dynamic interaction logic rules are used to define the state change logic of an element in response to user interaction.

[0095] In this embodiment of the invention, the element hierarchy layout can be specifically understood as: the tree structure relationship of user interface elements (e.g., "over-temperature alarm dialog box" is a child element of "main interface"), used to determine the display hierarchy and nesting relationship of the interface. The state transition rule can be specifically understood as: mapping log events to the logic of user interface element state changes (e.g., ERROR_CODE_12 triggers "FAULT" LED to change from "OFF" to "Blinking"), which includes both data visual presentation and interactive functions and interface behavior. Here, ERROR_CODE_12 is the abnormal event identifier recorded in the system log (e.g., corresponding to motor stall fault), and "FAULT" LED (Light Emitting Diode) is the fault indicator element on the user interface; when the system recognizes the ERROR_CODE_12 event from the log data, it will trigger the state transition rule to switch the current state of the LED (originally "OFF", i.e., off state) to "Blinking" (i.e., blinking state).

[0096] The element display mapping relationship can be specifically understood as: the rules for translating the logical state of user interface elements (such as "disabled") into visual representations (such as graying out buttons or flashing LEDs). The dynamic interaction logic rules can be specifically understood as: defining the state changes of user interface elements in response to user operations (such as hiding the "over-temperature alarm dialog box" after clicking the "OK" button).

[0097] Specifically, the user interface state model can include four components: element hierarchy layout, which defines the nesting relationship of various elements in the interface (such as the "Start Test" button, the "Over Temperature Alarm" dialog box, and the "FAULT" LED), and clarifies the display hierarchy of the interface.

[0098] State transition rules map log data to visual styles (e.g., values ​​turn red when temperature > 85 degrees Celsius), driving the user interface's interactive logic and dynamic behavior. For example, the ERROR_CODE_12 log will trigger the "FAULT" LED to change from "OFF" to "Blinking." When a SAFETY_DOOR_OPEN event exists in the log, combined with temperature parameter events recorded in the sensor array log (e.g., TEMPERATURE > 85 degrees Celsius, indicating that the temperature inside the MEMS test chamber exceeds 85 degrees Celsius) and system status events recorded in the control unit log (e.g., SYSTEM_STATE = TESTING log, indicating that the current system is in "test running" mode), the rule will set the "Start Test" button to "Disabled" (displayed as gray and unclickable), and simultaneously trigger an "Over-Temperature Alarm" dialog box to pop up.

[0099] The elements display a mapping relationship, translating logical states (such as disabled and blinking) into corresponding visual representations (such as graying out buttons and blinking LEDs).

[0100] Dynamic interaction logic rules define the state changes of elements in response to user operations (such as hiding the alarm dialog box after clicking the "Confirm" button).

[0101] This model uses state transition logic (triggered by log events to switch the state of user interface elements) to allow the simulation engine to accurately recreate the complete user interface scenario when the fault occurred: it not only presents data values, but also reproduces interactive constraints such as "whether the button is available" and "whether the dialog box pops up", so that analysts can intuitively see "what the operator could or could not do at that time", rather than just looking at the data.

[0102] By defining the nesting relationships of interface elements through element hierarchy layout, mapping log events to user interface functional state changes based on state transition rules, and transforming logical states into intuitive visual representations by combining element display mapping relationships, and defining the response logic of user operations through dynamic interaction logic rules, a closed-loop interface logic system is formed. This not only breaks through the limitations of traditional logs that only display data, but also accurately restores the complete user interface interaction scenario at the time of the fault, allowing analysts to intuitively grasp the interface state and operational limitations at that time, but also ensures the consistency between the reconstructed user interface and the actual system interface logic, avoiding misjudgments in fault analysis due to state confusion. At the same time, the modular design of each component of the model allows for flexible configuration adjustments based on the interface characteristics of different MEMS test systems, without the need to redevelop core logic, reducing the adaptation cost of the solution. This model transforms complex log events into visual and interactive user interface scenarios, replacing the tedious process of manually interpreting discrete logs, lowering the technical threshold for fault analysis, and improving diagnostic efficiency.

[0103] Furthermore, based on the above embodiments, the event simulation and display method of the MEMS test system may further include at least one of the following:

[0104] The event sequence is arranged according to a timeline to generate a timeline control, which is displayed in the user interface so that the user can select from the event sequence by time; in response to the user's event selection operation, the corresponding log data of the event is obtained and displayed; a dynamic copy of the main simulation panel of the test system's user interface is displayed; in response to the triggering of the raw data indicator, one or more sensor values ​​or control signals are displayed.

[0105] In this embodiment of the invention, the timeline control can be specifically understood as: a visual interactive component generated based on the time sequence of events, supporting users to filter and locate historical events by time dimension, and serving as an interactive carrier connecting the event sequence and the interface simulation. The dynamic replica main simulation panel can be specifically understood as: a visual panel reconstructed based on the user interface state model that is completely consistent with the historical interface of the test system, serving as a carrier for presenting historical user interface scenes, distinct from passive video playback, and supporting user interactive analysis. The raw data indicator can be specifically understood as: an interactive control that triggers the display of historical raw data; clicking it displays underlying log data such as sensor values ​​and control signals synchronized with the current simulation interface.

[0106] Specifically, based on the generated event sequence, a timeline control is first generated and displayed on the user interface. Users can select target events by time using this control. After the system responds to the selection operation, it loads and displays the log data corresponding to the event. At the same time, the main simulation panel, a dynamic copy of the test system's user interface, is presented in the interface to restore the user interface state at historical moments.

[0107] The main simulation panel of the dynamic replica can be driven by the simulation engine, which maintains a machine-specific layered user interface representation (such as a test screen containing a control panel, with the panel nested with elements like a start button and status displays). Specifically, the layered user interface representation can be understood as a nested user interface structure maintained by the simulation engine, consistent with the real machine interface, divided into levels according to parent-child relationships (such as a test screen including a control panel, and the control panel including a start button), supporting hierarchical status management.

[0108] The simulation engine restores the position, style, and active state (such as button disabled or LED flashing red) of user interface elements at historical moments based on the visual layout definition, resource mapping, and machine-specific constants of the user interface state model.

[0109] Unlike passive video playback, this main simulation panel supports dynamic interaction logic: clicking on interface elements will not change historical events, but will trigger analysis functions (such as viewing button status attributes and associated logs, expanding historical sub-menus, and filtering element-related data).

[0110] When a user triggers the raw data indicator, the system will overlay and display raw data such as sensor values ​​or control signals synchronized with the current simulation interface, realizing the fusion presentation of historical user interface scenes and raw data, providing multi-dimensional support for fault analysis.

[0111] The event sequence is visualized along a timeline using a timeline control. Users can directly retrieve the corresponding log data by clicking on the target event, solving the problem of manually searching and matching events from massive amounts of discrete logs in traditional analysis, thus reducing the time cost of fault location. Simultaneously, the dynamic replica of the test system user interface presented on the main simulation panel supports interactive analysis, rather than static screenshots or passive video playback. This allows engineers to immerse themselves in viewing the complete state of the user interface and operational limitations at historical moments, intuitively understanding the human-computer interaction context at the time of the fault, and avoiding misjudgments due to missing information. By triggering raw data indicators, synchronized sensor values ​​and control signals can be overlaid on the dynamic replica of the user interface, achieving a fusion of interface state and raw data presentation. This allows engineers to complete the correlation analysis of phenomena and data on the same interface, forming a closed loop in fault analysis and improving the accuracy of root cause determination. Furthermore, this visualized and interactive design transforms complex log analysis into simple operation, lowering the technical threshold for fault analysis, expanding the scope of the tool's applicability, and reducing human training costs.

[0112] In a specific example, an event simulation display system for a MEMS testing system can consist of a log ingestion module, a log correlation engine, an event reconstruction module, a simulation engine, a graphical user interface (GUI), and a data gap compensation module. The log ingestion module is used to interface with heterogeneous data sources such as control units, sensor arrays, environmental monitors, and user interface modules. The log correlation engine, event reconstruction module, and simulation engine constitute the system processing link. The graphical user interface serves as the user interaction terminal, and the data gap compensation module serves as an auxiliary functional module to ensure data integrity.

[0113] The log ingestion module uses a built-in parser library to parse the proprietary log formats of different machine models, standardizing the heterogeneous raw log data into a unified intermediate format that includes fields such as timestamp, source, and event type.

[0114] The log-related engine uses NTP or internal clock offset calibration to normalize the timestamps of multi-source logs. At the same time, it performs event identification based on log data from different subsystems to determine the system events of each subsystem. Based on the shared event identifiers in the log data of different subsystems, it identifies related cross-system events. Based on the system events identified by the log data of different subsystems, it identifies system events that meet the time proximity condition and the set event causality condition as related cross-system events, generating a unified and causally consistent event sequence.

[0115] The event reconstruction module combines a set threshold or anomaly detection model to detect abnormal events and reconstructs a complete system state sequence before and after the anomaly occurs, including control signals, sensor readings, user interface element states, and operator inputs.

[0116] The simulation engine loads a machine-specific user interface state model, which includes element hierarchy layout, state transition rules, element display mapping relationships, and dynamic interaction logic. The engine renders a dynamic, interactive copy of the machine's user interface in real time based on the reconstructed system state, rather than a pre-recorded video. The graphical user interface enables users to select events by time, view the simulation interface, overlay raw data, and retrieve corresponding logs through a timeline slider, main simulation panel, overlay indicator, and log details panel.

[0117] The data gap compensation module completes missing or corrupted log data through time interpolation or predictive modeling, and marks the uncertainty indicator of the estimated state in the GUI.

[0118] This system breaks down information silos from heterogeneous data sources by standardizing multi-source logs, synchronizing time, and associating events, solving the problems of scattered data and unclear causal links in traditional log analysis. Combining rule-based and machine learning-based anomaly detection strategies ensures accurate identification of explicit anomalies while capturing subtle potential faults, improving the comprehensiveness and accuracy of anomaly detection. Dynamic simulation based on machine-specific user interface state models, unlike passive video playback, achieves high-fidelity restoration and interactive analysis of historical operation scenarios, allowing for intuitive understanding of the human-machine interaction context at the time of a fault. The graphical user interface integrates timeline controls, simulation panels, raw data overlays, and log details, forming a closed-loop analysis process of time positioning, scene viewing, and data verification, lowering the technical threshold for fault diagnosis and shortening the average repair time. Simultaneously, the lightweight log and state model design reduces storage and bandwidth overhead, pluggable model configuration supports multi-machine model adaptation, and digital twin integration capabilities expand application scenarios such as predictive maintenance, remote monitoring, and operator training, providing an efficient, flexible, and comprehensive technical solution for industrial automation diagnostics.

[0119] The technical solution of this invention collects log data from multiple subsystems and synchronizes the log data of each subsystem using network time protocols or internal clock offset calibration to convert the timestamps from different subsystems into a unified standard timestamp. This eliminates the time drift problem caused by independent clock sources in each subsystem, aligns log data from different sources based on a unified time benchmark, restores the causal logic of events, avoids event association errors caused by time deviations, and provides accurate time dimension support for subsequent anomaly detection and fault analysis. Simultaneously, the standardized timestamps provide a unified basis for automatic association of logs across subsystems, eliminating the need for engineers to manually check and adjust time differences, reducing the time cost and human error of manual intervention, improving the automation level and accuracy of log association, and laying the foundation for quickly generating complete event sequences. Furthermore, after time synchronization, the log data of each subsystem within the set time window of the abnormal event can be accurately matched in the time dimension, ensuring that related events before and after the fault are completely captured, avoiding log data omissions or misalignments, providing complete and aligned data support in the time dimension for the reconstruction of the user interface of abnormal events, and ensuring the fidelity of fault scene reconstruction and the reliability of root cause analysis. Then, an event sequence arranged along the timeline is generated, and the target event is specifically identified. Finally, the user interface at the time of the target event is reconstructed and displayed based on the user interface state model. This solves the problems of isolation, time asynchrony, and fragmentation of multi-source logs, automatically establishes event causal chains, reduces the cost and error rate of manual data correlation, and can also restore the complete operational context of the target event in a visual way, presenting the interface state, operation path, and system prompts at the time of the event, avoiding diagnostic bias caused by missing context, and improving the accuracy of root cause analysis of faults.

[0120] Example 4

[0121] Figure 4 This is a schematic diagram of the structure of an event simulation display device for a MEMS testing system provided in Embodiment 4 of the present invention. Figure 4 As shown, the device includes: a log acquisition module 410, a synchronization and arrangement module 420, a target event module 430, and an interface display module 440, wherein:

[0122] Log collection module 410 is used to collect log data from at least one subsystem respectively;

[0123] The synchronization and arrangement module 420 is used to synchronize the timestamps of each log data, and determine at least one event arranged along the timeline based on each log data to generate an event sequence;

[0124] Target event module 430, used to determine a target event from the event sequence;

[0125] The interface display module 440 is used to reconstruct the user interface when the target event occurs based on the user interface state model and the log data corresponding to the target event, and then display it.

[0126] The technical solution of this invention collects log data from multiple subsystems, generates an event sequence arranged along a timeline after timestamp synchronization, then specifically identifies target events, and finally reconstructs and displays the user interface at the time the target event occurs based on the user interface state model. This solves the problems of isolated state, time asynchrony, and fragmentation of multi-source logs, automatically establishes event causal chains, reduces the cost and error rate of manual data correlation, and can also restore the complete operational context of the target event in a visual way, presenting the interface state, operation path, and system prompts at the time the event occurs, avoiding diagnostic biases caused by missing context and improving the accuracy of root cause analysis of faults. At the same time, this method can directly focus on key target events without sifting through massive amounts of logs, shortening the event analysis and fault diagnosis cycle, reducing equipment downtime losses, and lowering the technical threshold for system operation and maintenance by replacing professional and complex original logs or abstract charts with a user interface, improving usability and universality. It can also provide standardized real-world scenario support for new operator training and team event review, helping to accumulate operation and maintenance experience and improve the overall operation and maintenance capabilities of the team.

[0127] Based on the above embodiments, the target event module 430 is specifically used for:

[0128] Based on the log data corresponding to the events in the event sequence, anomaly detection is performed, and the identified abnormal events are taken as target events. For the detected abnormal events, the log data of the abnormal events within a set time window is obtained as abnormal log data for reconstructing the user interface of the abnormal events.

[0129] Based on the above embodiments, the multiple subsystems may include at least two of the following: a control unit, a sensor array, an environmental monitoring module, and a user interface module.

[0130] Based on the above embodiments, the synchronization module 420 is specifically used for:

[0131] The timestamps from each subsystem are converted to standard timestamps using a network time protocol or internal clock offset calibration for each log data.

[0132] Based on the above embodiments, the target event module 430 is further configured to:

[0133] Based on the log data corresponding to the events in the event sequence, abnormal events are identified using a set threshold or an anomaly detection model.

[0134] Based on the above embodiments, the anomaly detection model may include at least one of the following: an autoencoder, an isolation forest, a single-class support vector machine, and a recurrent neural network trained using historical log data items as samples, wherein the model is periodically retrained using verified normal operating data.

[0135] Based on the above embodiments, the synchronization arrangement module 420 is further used for at least one of the following:

[0136] Event identification is performed based on log data from different subsystems to determine system events in each subsystem; cross-system events with correlation are identified based on shared event identifiers in the log data from different subsystems; and system events that meet the time proximity condition and the set event causality condition are identified as cross-system events with correlation based on the system events identified from the log data of each subsystem.

[0137] Based on the above embodiments, the user interface state model may include: element hierarchy layout, used to define the interface display elements and the parent-child relationship between elements; state transition rules, used to convert event log data into element state change logic; element display mapping relationship, used to map the logical state of elements to the display state of elements; and dynamic interaction logic rules, used to define the state change logic of elements in response to user interaction.

[0138] Furthermore, based on the above embodiments, the event simulation display device of the MEMS test system may further include at least one of the following: a timeline display module, an event selection module, a main simulation panel module, and an indicator triggering module, wherein:

[0139] The timeline display module is used to generate a timeline control based on the event sequence and display it in the user interface so that the user can select from the event sequence by time; the event selection module is used to retrieve and display the log data corresponding to the event in response to the user's event selection operation; the main simulation panel module is used to display a dynamic copy of the main simulation panel of the test system's user interface; and the indicator triggering module is used to display one or more sensor values ​​or control signals in response to the triggering of the raw data indicator.

[0140] Furthermore, based on the above embodiments, the event simulation display device of the MEMS testing system may further include: a data compensation module, wherein:

[0141] The data compensation module is used to estimate the missing or corrupted log data items by using time interpolation or predictive modeling after collecting log data from the multiple subsystems. The simulation interface is marked with an uncertainty indicator of the estimated state.

[0142] The event simulation display device of the MEMS test system provided in the embodiments of the present invention can execute the event simulation display method of the MEMS test system provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0143] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0144] In the technical solution disclosed herein, the information collected is information and data authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data all comply with the relevant laws, regulations and standards of the relevant countries and regions, necessary confidentiality measures have been taken, and they do not violate public order and good morals. Corresponding operation entry points are provided for users to choose to authorize or refuse.

[0145] In the technical solution disclosed herein, if automated decision-making is involved, a corresponding operation entry will be provided to the user, allowing the user to choose to agree to or reject the automated decision result; if the user chooses to reject, the process will proceed to the expert decision-making process.

[0146] Example 5

[0147] Figure 5 A schematic diagram of an electronic device 10, which 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 (e.g., 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.

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

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

[0150] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 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 11 performs the various methods and processes described above, such as the event simulation display method of a MEMS test system, i.e.:

[0151] Log data is collected from at least one subsystem; the log data is timestamped and synchronized, and at least one event arranged along the timeline is determined based on the log data to generate an event sequence; the target event is determined from the event sequence; based on the user interface state model, the user interface at the time the target event occurs is reconstructed according to the log data corresponding to the target event, and then displayed.

[0152] In some embodiments, the event simulation display method of the MEMS test system can be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the event simulation display method of the MEMS test system described above can be performed. Alternatively, in other embodiments, processor 11 can be configured to perform the event simulation display method of the MEMS test system by any other suitable means (e.g., by means of firmware).

[0153] Various embodiments 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), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments 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.

[0154] 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.

[0155] 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.

[0156] 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).

[0157] 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.

[0158] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through 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 to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0159] 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 no limitation is imposed herein.

[0160] 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. An event simulation and display method for a MEMS testing system, characterized in that, The MEMS testing system includes multiple subsystems, and the method includes: Log data is collected from at least one subsystem. The log data is timestamped and synchronized, and at least one event arranged along the timeline is determined based on the log data to generate an event sequence; Identify the target event from the event sequence; Based on the user interface state model, the user interface at the time the target event occurs is reconstructed and displayed according to the log data corresponding to the target event.

2. The method according to claim 1, characterized in that, Determining the target event from the event sequence includes: Based on the log data corresponding to the events in the event sequence, perform event anomaly detection and take the identified abnormal events as target events; For detected abnormal events, log data of the abnormal event within a set time window is obtained as abnormal log data for reconstructing the user interface of the abnormal event.

3. The method according to claim 1, characterized in that, The multiple subsystems include at least two of the following: a control unit, a sensor array, an environmental monitoring module, and a user interface module.

4. The method according to claim 1, characterized in that, Synchronize the timestamps of the log data, including: The timestamps from each subsystem are converted to standard timestamps using a network time protocol or internal clock offset calibration for each log data.

5. The method according to claim 2, characterized in that, Based on the log data corresponding to the events in the event sequence, perform event anomaly detection, including: Based on the log data corresponding to the events in the event sequence, abnormal events are identified using a set threshold or an anomaly detection model.

6. The method according to claim 5, characterized in that, The anomaly detection model includes at least one of the following: an autoencoder, an isolated forest, a single-class support vector machine, and a recurrent neural network trained using historical log data items as samples, wherein the model is periodically retrained using validated normal operating data.

7. The method according to claim 1, characterized in that, Based on the log data, multiple events arranged along a timeline are identified, and an event sequence is generated, including at least one of the following: Event identification is performed based on log data from different subsystems to determine system events for each subsystem. Based on shared event identifiers in log data from different subsystems, identify related cross-system events; Based on the system events identified from the log data of different subsystems, system events that meet the time proximity condition and the set event causality condition are identified as cross-system events with correlation.

8. The method according to claim 1, characterized in that, The user interface state model includes: Element hierarchy layout is used to define the elements displayed on the interface and the parent-child relationships between elements; State transition rules are used to convert event log data into the state change logic of elements; Element display mapping is used to map the logical state of an element to its display state. Dynamic interaction logic rules are used to define the logic for changing the state of an element in response to user interaction.

9. The method according to claim 1, characterized in that, It also includes at least one of the following: The event sequence is arranged according to a timeline to generate a timeline control, which is then displayed in the user interface so that the user can select from the event sequence by time. In response to the user's event selection operation, the corresponding log data for the event is retrieved and displayed; The main simulation panel displays a dynamic copy of the user interface of the test system; In response to the triggering of the raw data indicator, display one or more sensor values ​​or control signals.

10. The method according to claim 1, characterized in that, After collecting log data from the multiple subsystems respectively, the process also includes: If there is missing log data, the missing or corrupted log data items are estimated by using time interpolation or predictive modeling through the data gap compensation module, and the user interface displays an uncertainty indicator for the estimated state when the simulation interface is displayed.

11. An event simulation display device for a MEMS testing system, characterized in that, The MEMS testing system includes multiple subsystems, and the device includes: The log collection module is used to collect log data from at least one subsystem. The synchronization and arrangement module is used to synchronize the timestamps of each log data, and determine at least one event arranged along the timeline based on each log data to generate an event sequence; A target event module is used to determine a target event from the event sequence; The interface display module is used to reconstruct and display the user interface when the target event occurs based on the user interface state model and the log data corresponding to the target event.

12. 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 executable 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 event simulation display method of the MEMS test system according to any one of claims 1-10.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed by a processor, implement the event simulation display method of the MEMS test system according to any one of claims 1-10.

14. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the event simulation display method for the MEMS test system according to any one of claims 1-10.

Images