Modular clean room full life cycle intelligent operation and maintenance data management method

Abstract

The application discloses a modular clean room full-life-cycle intelligent operation and maintenance data management method, and belongs to the technical field of clean room intelligent operation and maintenance. The method collects operation data of each functional module in the clean room, performs data bloodline analysis to generate modular operation and maintenance data assets, automatically divides the life cycle stages of the functional modules according to the update time sequence of the data assets, maps multi-source data into a dynamic hypergraph and performs module evolution analysis in the life cycle stages to obtain the correlation mode of each functional module, generates a full-life-cycle operation and maintenance task queue based on the correlation mode and writes back to the data assets to update the operation and maintenance labels of the functional modules. The data bloodline analysis guarantees the completeness and traceability of the operation and maintenance data, the dynamic hypergraph module evolution analysis mines the dynamic correlation mode among the functional modules, and adaptive life cycle division and accurate operation and maintenance task arrangement are realized.

Description

Technical Field

[0001] This invention relates to the field of intelligent operation and maintenance technology for cleanrooms, specifically a modular cleanroom full lifecycle intelligent operation and maintenance data management method. Background Technology

[0002] As production spaces sensitive to environmental parameters, cleanrooms rely heavily on operational data generated by numerous sensors, equipment controllers, and environmental monitoring systems for their operation and maintenance. Existing operational data management solutions typically store collected data from various functional modules centrally by channel or location, lacking tracing of data sources, transformation processes, and business semantics. When data records undergo multiple processing steps at intermediate transformation nodes, it becomes difficult to trace back to the original functional module, leading to reduced data asset credibility and hindering effective verification of data integrity. Furthermore, the lifecycle phase division of modular cleanroom equipment still generally relies on fixed time windows or manual experience thresholds. This rigid division method fails to reflect the actual state evolution rhythm of each functional module due to usage frequency, load variations, and differences in maintenance quality. This often results in situations where the commissioning period is not completed before entering the stable period calibration, or where stable period strategies are still used even when decay characteristics have already emerged.

[0003] On the other hand, the operational status of modules such as cleanroom temperature control, fan filtration units, differential pressure regulation, and personnel access management exhibits complex coupling relationships. Traditional correlation analysis or univariate threshold alarms can only reveal synchronous fluctuations between pairs of parameters, failing to capture the interconnected structure and evolutionary patterns formed by multiple modules over time from a global perspective. When a functional module enters a decline phase, its impact often propagates to other modules through multiple coupling links. This cross-module cascading degradation pattern is difficult to identify in static data reports, resulting in delayed and fragmented operation and maintenance tasks. How to automatically reconstruct the lineage links during the assetization of operation and maintenance data and adaptively divide the module lifecycle stages accordingly, and how to extract evolutionary patterns reflecting the dynamic relationships between functional modules from multi-source heterogeneous operation and maintenance data to drive the generation of full lifecycle operation and maintenance tasks, have become problems to be solved. Summary of the Invention

[0004] This paper provides a modular cleanroom full lifecycle intelligent operation and maintenance data management method to solve the problems in existing technologies, such as insufficient data asset credibility due to lack of lineage tracing of operation and maintenance data, and the inability to adapt to the dynamic evolution of module operation status due to reliance on fixed thresholds for lifecycle stage division. At the same time, it solves the problem that multi-source operation and maintenance data correlation analysis is limited to static statistics, making it difficult to capture the dynamic coupling evolution pattern between functional modules and thus unable to generate accurate full lifecycle operation and maintenance tasks.

[0005] To achieve the above objectives, the present invention provides the following technical solution: The present invention provides a modular cleanroom full lifecycle intelligent operation and maintenance data management method, comprising: collecting operational data of various functional modules within the cleanroom; performing data lineage analysis on the operational data to generate modular operation and maintenance data assets; dividing the lifecycle stages of the functional modules according to the update sequence of the modular operation and maintenance data assets; mapping multi-source data in the modular operation and maintenance data assets into dynamic hypergraphs within the lifecycle stages, and performing phantom evolution analysis on the dynamic hypergraphs to obtain the association patterns of each functional module; generating a full lifecycle operation and maintenance task queue based on the association patterns, and writing the full lifecycle operation and maintenance task queue back to the modular operation and maintenance data assets to update the operation and maintenance tags of the functional modules.

[0006] As a technical solution of the present invention, the process of performing data lineage analysis on operational data and generating modular operation and maintenance data assets includes: adding metadata tags to each piece of operational data according to data source, acquisition device, acquisition time, data version, and business semantics to obtain labeled operational data; dividing the labeled operational data into multiple modular data units according to the business semantics in the labeled operational data; establishing lineage edges between each modular data unit and functional modules, and writing the lineage edges into a data lineage graph; verifying the data integrity of the modular data units according to the lineage paths from functional modules to modular data units in the data lineage graph, and aggregating the verified modular data units into modular operation and maintenance data assets.

[0007] Preferably, when verifying data integrity, all lineage paths with the starting node as a functional module and the ending node as a modular data unit are selected from the data lineage diagram. For each lineage path, the data source node, transformation operation node, and storage node are extracted, and a path sequence is generated according to the data flow order. The data fields corresponding to the transformation operation nodes in the path sequence are mapped to integrity verification fields. These integrity verification fields are used to check for missing values, duplicate values, and outliers in the modular data units to obtain a data integrity score. When the data integrity score is higher than a preset passing score, the corresponding modular data unit is added to the modular operation and maintenance data asset. The data integrity score can be determined by the following formula:

[0008]

[0009] in, To score data integrity, This represents the total number of fields in a modular data unit. , , These represent the number of fields with missing values, the number of fields with duplicate values, and the number of fields with outliers. , , For preset weighting coefficients and This approach ensures the consistency and availability of data within modular operation and maintenance data assets.

[0010] As a technical solution of the present invention, when dividing the life cycle stages of functional modules according to the update sequence of modular operation and maintenance data assets, the data generation timestamp and data version number of each functional module are extracted from the modular operation and maintenance data assets; according to the order of data generation timestamps, the data version number change events are arranged into an update event sequence; the time interval of adjacent update events in the update event sequence is statistically analyzed to obtain an update interval sequence; abrupt change point detection is performed on the update interval sequence, and the time corresponding to the detected abrupt change point is used as the life cycle stage boundary point of the functional module between the debugging period, stable period, decline period and decommissioning period; according to the life cycle stage boundary point, a life cycle stage identifier is added to each data record of the functional module in the modular operation and maintenance data assets.

[0011] When detecting mutation points, a sliding window can be set on the update interval sequence, and the local mean of the update interval within each sliding window is recorded. The change in the update interval between adjacent window positions is calculated. If this change exceeds a preset perturbation threshold, the corresponding window position is marked as a candidate mutation position. Using the candidate mutation position as the center, the statistical characteristics of the two preset-length update interval subsequences before and after it are compared to screen out the formal mutation points, thereby determining the lifecycle stage boundary. The change in update interval can be expressed as:

[0012]

[0013] in, For the first Local mean of update interval within a sliding window This represents the change in the update interval between adjacent windows. This method automatically identifies module state inflection points based on objective changes in data change frequency, improving the accuracy of lifecycle phase division.

[0014] As a technical solution of the present invention, the steps of mapping multi-source data in modular operation and maintenance data assets into a dynamic hypergraph include: treating each operation and maintenance data record in the modular operation and maintenance data asset as a hypergraph node, and treating the functional module identifier, life cycle stage identifier, equipment status parameters, environmental indicators, personnel operation records, and material batch information in the operation and maintenance data record as node attributes of the hypergraph node; connecting at least two hypergraph nodes with the same functional module identifier and data association within the same life cycle stage into a hyperedge according to the node attributes; arranging all hyperedges within the same time window in chronological order to form a time slice sequence; and iteratively updating the hyperedges in the time slice sequence according to the methods of adding hyperedges, failing hyperedges, and weight updates to obtain a dynamic hypergraph.

[0015] When iteratively updating hyperedges, the first-appearing hypergraph node association in the current time slice is taken as a new hyperedge, and the timestamp of the associated operation and maintenance data record is written into the creation time attribute of the new hyperedge. Existing hyperedges that no longer meet the node attribute association conditions in the current time slice are marked as failed hyperedges, and the failure time is recorded in their attributes. For existing hyperedges that are still retained in the current time slice, the activity weight is updated according to the number of node attribute changes of the hypergraph nodes they connect to. The information on new hyperedges, failed hyperedges, and activity weight changes of the same hypergraph node in different time slices is merged into the node evolution log of the dynamic hypergraph to complete the update of the dynamic hypergraph. This dynamic hypergraph can truly reflect the high-order, time-varying associations between multi-source data.

[0016] As a technical solution of the present invention, the process of obtaining the association pattern of each functional module by performing phantom evolution analysis on a dynamic hypergraph includes: taking each data object in the dynamic hypergraph as a hypergraph node, and taking the associated edge connecting at least two hypergraph nodes as a hyperedge; slicing the dynamic hypergraph according to the data generation time to obtain a time slice sequence; extracting the hypergraph connected components connected by hyperedges from each time slice; counting the hyperedge connection structures that appear more than a preset threshold in each hypergraph connected component and taking them as candidate hypergraph phantoms; tracking the node overlap, hyperedge merging, and hyperedge splitting events of the candidate hypergraph phantoms in adjacent time slices to generate a hypergraph phantom evolution trajectory; comparing the hypergraph phantom evolution trajectory with the life cycle stage of the functional module, determining the association pattern between each functional module based on its duration and stage transition direction in the life cycle stage, and writing the association pattern into the modular operation and maintenance data asset.

[0017] Node overlap can be calculated as follows:

[0018]

[0019] in, and These represent candidate hypergraph phantoms in two adjacent time slices. and The set of nodes in The node overlap degree reflects the stability of the motif over time. This analysis process can extract frequently occurring high-order association structures with clear evolutionary trends from the dynamic hypergraph, accurately characterizing the association patterns between modules.

[0020] As a technical solution of the present invention, the steps of generating a full lifecycle operation and maintenance task queue and updating operation and maintenance tags based on the association pattern include: matching the association pattern with the policy rules in the operation and maintenance policy library to obtain a set of candidate operation and maintenance tasks for the functional module under the lifecycle stage; assigning a task priority to each candidate operation and maintenance task according to the task urgency, resource consumption, and data update frequency in the candidate operation and maintenance task set; arranging the candidate operation and maintenance tasks into a full lifecycle operation and maintenance task queue according to the task priority and the order of the lifecycle stage; establishing a mapping relationship between the task identifier of each candidate operation and maintenance task in the full lifecycle operation and maintenance task queue and the operation and maintenance tag of the functional module; writing the mapping relationship back to the modular operation and maintenance data asset, and updating the operation and maintenance tag of the functional module using the task identifier.

[0021] When prioritizing tasks, the task type, execution cycle, affected module scope, and required historical data volume for each candidate maintenance task are extracted from the candidate maintenance task set. The task urgency level is determined based on the task type and affected module scope. Based on the required historical data volume, the resource usage of the corresponding data partition is queried in the distributed big data management node to obtain the resource usage. The data update frequency is determined based on the number of maintenance tag updates for functional modules within the execution cycle. Task priorities are assigned to each candidate maintenance task according to the ranking results of task urgency level, resource usage, and data update frequency. Task priorities can be determined using the following formula:

[0022]

[0023] in, Score the task priority. Quantify the urgency level of the task. For resource consumption, This is a normalized value for the data update frequency. , , The weighting coefficient is used. Based on this, the generated full lifecycle operation and maintenance task queue is highly matched with the actual status and association pattern of the module. The operation and maintenance tags are continuously updated with the dynamic write-back of the task queue, realizing the closed-loop linkage between data assets and operation and maintenance decisions, and improving the timeliness and accuracy of intelligent operation and maintenance throughout the entire lifecycle of the cleanroom.

[0024] The technical effects and advantages provided by the present invention in the above technical solution are as follows:

[0025] The mechanism for generating modular operation and maintenance data assets based on data lineage analysis adds metadata tags containing data source, acquisition device, acquisition time, data version, and business semantics to each piece of operational data. It then segments the data into modular data units according to business semantics, establishing lineage edges between functional modules and data units to form a data lineage graph. Along the lineage path from functional module to data unit in the graph, transformation operation nodes are extracted and mapped to integrity verification fields. Missing values, duplicate values, and outliers in the modular data units are checked for consistency, resulting in a data integrity score. Data units with scores higher than a preset passing score are included in the modular operation and maintenance data assets. This scheme allows each operation and maintenance data record to be traced back to its original functional module along the lineage path and undergoes structured integrity verification. This eliminates the defects of traditional operation and maintenance data management caused by opaque data processing links, leading to unquantifiable data quality and broken traceability. It achieves measurable data asset integrity and replayable data evolution processes. When dividing the lifecycle stages based on the update sequence of modular operation and maintenance data assets, the timestamps and data version numbers of each functional module's data are extracted from the data assets, arranged into an update event sequence, and the time intervals between adjacent update events are statistically analyzed. By performing sliding window mutation point detection on the update interval sequence, locations of significant changes in the update interval are identified as lifecycle stage demarcation points. The operation of functional modules is automatically divided into debugging, stable, declining, and decommissioning phases, and lifecycle stage identifiers are added to each data record. This approach shifts the basis for stage division from an external fixed cycle to the mutation characteristics of the ontology data update rhythm, enabling the demarcation points to adaptively match the actual state changes of each functional module, avoiding the lag and misalignment caused by manual division.

[0026] This process maps multi-source data from modular operation and maintenance (O&M) data assets into a dynamic hypergraph and performs motif evolution analysis. O&M data records are used as hypergraph nodes. Multiple nodes with data associations within the same lifecycle stage are connected into a hyperedge using node attributes such as functional module identifiers, lifecycle stage identifiers, and device status parameters. A time-slice sequence is formed according to time windows, and the dynamic hypergraph is iteratively obtained by adding, failing, and updating hyperedges and weights. Connected components of the hypergraph connected by hyperedges are extracted from the dynamic hypergraph. Frequently occurring hyperedge connection structures are statistically analyzed as candidate hypergraph motifs. The node overlap, hyperedge merging, and splitting events of motifs in adjacent time slices are tracked to generate motif evolution trajectories. The motif evolution trajectories are compared with the lifecycle stages of functional modules to obtain the association patterns between functional modules. This process overcomes the limitations of traditional O&M analysis, which only statistically analyzes single variables or pairwise relationships. It can capture the relationship subgraphs composed of multiple functional modules and their changing paths as they migrate throughout the lifecycle at a high-order interaction level, identifying dynamic association characteristics such as collaborative degradation and impact transmission between module groups. When generating a full lifecycle maintenance task queue based on association patterns, the association patterns are matched with the maintenance strategy library to obtain a set of candidate maintenance tasks. Priority is assigned to each task based on a combination of task urgency, resource consumption of distributed data partitions, and data update frequency determined by the number of maintenance tag updates within the execution cycle. Task queues are formed according to priority and lifecycle stage order and written back to modular maintenance data assets, with maintenance tags updated synchronously. This solution ensures that maintenance task triggering no longer relies on isolated single-point alarms or fixed plans, but is driven by dynamic association patterns and prioritized based on real-time resource status and data update frequency, forming a closed-loop adaptive maintenance task scheduling capability. Attached Figure Description

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

[0028] Figure 1 This is a flowchart of a modular cleanroom's full lifecycle intelligent operation and maintenance data management method.

[0029] Figure 2 This is a flowchart of the modular operation and maintenance data asset generation method;

[0030] Figure 3 This is a diagram illustrating the changes in the data version update intervals of functional modules and the division of their lifecycle stages;

[0031] Figure 4 It is the curve showing the change of hyperedge activity weights over time slices in a dynamic hypergraph. Detailed Implementation

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

[0033] See Figure 1 This invention provides a modular cleanroom full lifecycle intelligent operation and maintenance data management method. The overall implementation scheme of this method includes: collecting the operation data of each functional module in the cleanroom, performing data lineage analysis on the operation data, and generating modular operation and maintenance data assets; dividing the lifecycle stages of functional modules according to the update sequence of the modular operation and maintenance data assets; mapping the multi-source data in the modular operation and maintenance data assets into dynamic hypergraphs within the lifecycle stages, and performing phantom evolution analysis on the dynamic hypergraphs to obtain the association patterns of each functional module; generating a full lifecycle operation and maintenance task queue based on the association patterns, and writing the full lifecycle operation and maintenance task queue back to the modular operation and maintenance data assets to update the operation and maintenance tags of the functional modules.

[0034] In specific implementation, please refer to Figure 2 The modular cleanroom is equipped with multiple functional modules, including an air supply module, a filtration module, a temperature and humidity control module, a differential pressure regulation module, and a particle monitoring module. Sensors, controllers, and instruments installed on each functional module collect operational data according to a preset cycle. Each data entry automatically records the data source, acquisition device, acquisition time, and data version. The data source is the module number of the functional module that generated the data entry; the acquisition device is the sensor or instrument number that completed the data acquisition; the acquisition time is the Unix timestamp of the data acquisition action completion; and the data version is the firmware version number of the data acquisition software or edge gateway. Business semantics are annotated by the cleanroom maintenance engineer according to the production process operating procedures. The annotations include descriptions of operational semantics such as temperature adjustment commands, differential pressure setpoint verification, and particle count reset. The five fields—data source, acquisition device, acquisition time, data version, and business semantics—are concatenated into a single string and added as metadata tags to the corresponding operational data record, forming the annotated operational data.

[0035] Based on the business semantics in the labeled operational data, the labeled operational data is divided into multiple modular data units. Using the business semantic field as the grouping criterion, all labeled operational data records with identical business semantics are grouped into the same modular data unit. If the business semantic field contains hierarchical coding, then the segmentation is based on the lowest-level business semantic code. Each modular data unit is assigned a unique data unit identifier, which consists of the module number of the functional module, an underscore, and the business semantic field.

[0036] Establish a lineage edge between each modular data unit and a functional module, and write the lineage edge into the data lineage graph. Construct a directed graph structure containing functional module nodes and modular data unit nodes. Functional module nodes are named by module number, and modular data unit nodes are named by data unit identifier. For any modular data unit, create a directed edge from the corresponding functional module node to that modular data unit node; this directed edge is the lineage edge. Store the minimum and maximum timestamps of all running data records within the modular data unit, as well as a list of data version numbers for all running data records, in the attributes of the lineage edge. Persist all nodes and lineage edges to the graph database to form the data lineage graph.

[0037] After constructing the data lineage graph, all lineage paths with functional modules as the starting node and modular data units as the ending node are selected from the graph. Using the graph traversal query language of the graph database, the starting node type is specified as a functional module node, and the ending node type as a modular data unit node. A breadth-first search strategy is used to obtain all connected paths between nodes. Each lineage path consists of a sequence of nodes and an edge sequence. For each lineage path, all intermediate nodes in the node sequence, excluding the starting node representing the functional module node and the ending node representing the modular data unit node, are identified. These intermediate nodes are categorized according to their processing type: data source nodes, transformation operation nodes, and storage nodes. Data source nodes correspond to the raw sensor data buffer, transformation operation nodes correspond to data cleaning operators, time alignment operators, and state aggregation operators, and storage nodes correspond to message queue topics or object storage buckets. Following the actual data flow direction, these nodes are arranged into a path sequence, starting with the data source node, followed by the transformation operation node, and ending with the storage node.

[0038] The data field names referenced by each transformation operation node in the path sequence are extracted to form a field set. From this field set, parameters directly related to the cleanroom operation and maintenance quality are selected, including temperature measurements, relative humidity measurements, differential pressure measurements, wind speed measurements, and particle concentration measurements. The data fields corresponding to these parameters are mapped to integrity verification fields. Each integrity verification field corresponds to a specific set of columns within a modular data unit.

[0039] The integrity check field is used to verify the consistency of missing, duplicate, and outlier values ​​in the modular data units, resulting in a data integrity score. Specifically, the total number of records is calculated based on the number of records in each modular data unit. The integrity check fields are scanned row by row. If any integrity check field in a row has an empty value, that row is counted as a row with missing values. The total number of rows with missing values ​​is then counted. Calculate the proportion of missing values. Mark rows in the modular data unit where all values ​​in the integrity check field are equal as duplicate records, and count the number of duplicate rows. Calculate the proportion of duplicate values. For each numeric field in the integrity check field, calculate the mean of all record values ​​for that field. and standard deviation Values ​​outside the range The records are marked as abnormal records. The abnormal marking results of all integrity check fields are summarized. If a row is marked as abnormal in at least one integrity check field, then the row is counted as an abnormal value record row. The number of abnormal value record rows is counted. Calculate the proportion of outliers Data integrity score The calculation formula is:

[0040]

[0041] in, Indicates the data integrity score. The range of values ​​is ; This represents the missing value weighting coefficient, with a value of 0.4. This represents the weighting coefficient for repeated values, with a value of 0.3. This represents the outlier weighting coefficient, with a value of 0.3; the weighting coefficient satisfies... The weighting coefficients mentioned above are set based on the fact that missing values ​​directly reduce the amount of effective information and have a greater impact on data integrity than duplicate values ​​and outliers, while duplicate values ​​and outliers have a similar degree of interference with subsequent analysis.

[0042] When data integrity score When the score exceeds the preset passing score, the corresponding modular data unit is added to the modular operation and maintenance data asset. The preset passing score is set to 0.85, which is based on the minimum acceptable level of data record completeness and accuracy for cleanroom operation and maintenance data analysis. The modular data units that meet the conditions, along with their corresponding metadata tags and lineage information, are stored together in a columnar storage format data asset table to generate the modular operation and maintenance data asset.

[0043] In practice, the data generation timestamp and data version number of each functional module are extracted from the constructed modular operation and maintenance data assets. The modular operation and maintenance data assets are stored in a columnar storage format, with each row corresponding to a modular data unit that has passed data integrity verification. For each record in the modular operation and maintenance data assets, the value of the "functional module identifier" column is read as the currently processed functional module object; simultaneously, the values ​​of the "data generation timestamp" and "data version number" columns are read. The data generation timestamp is a Unix millisecond-level timestamp, and the data version number is a string composed of the major version number, minor version number, and revision number. All records belonging to the same functional module identifier are sorted in ascending order of their data generation timestamps, and the data version number corresponding to each record is extracted, forming a sequence of data version number change events in chronological order. If two adjacent records have the same data version number string, they are considered as no change event, and only the earliest representative event with the earliest timestamp is retained; if two adjacent records have different data version number strings, they are considered as a change event, and an event point is inserted into the change event sequence. The attributes of the event point include the timestamp of the change and the data version number after the change.

[0044] Based on the order of the data generation timestamps, the data version number change events are arranged into an update event sequence, denoted as... Each update event Includes timestamp and version number ,in , To update the total number of events. For each adjacent update event in the update event sequence. and Calculate the time interval The update interval sequence is obtained. ,in The unit is hours.

[0045] In the update interval sequence The length is set above. A sliding window is used, with a step size of one update interval. Sliding window length. The setting is 5, based on the premise that with a typical data acquisition frequency on the minute level, 5 update intervals can cover several hours of update density changes, smoothing out individual fluctuations without over-smoothing out the true stage transition signals. For a sliding window located at the [number missing]th [number missing]... At a starting position, the update interval subsequence contained in the window is: Calculate the arithmetic mean of all update intervals in the subsequence as the local mean of the update interval corresponding to the sliding window position. The calculation formula is:

[0046]

[0047] in, Indicates the starting position index of the sliding window. The range of values ​​is ; This indicates the length of the sliding window. ; This represents the offset index within the sliding window. Traverse from 0 to ; Indicates the th in the update interval sequence One update interval value; Indicates the sliding window starts from the first... The local mean of the update interval calculated at each location.

[0048] Calculate the change in update interval of the sliding window between adjacent window positions, i.e., the change in the sliding window from position... Move to position At that time, the change in the local mean at the update interval ,in To update the interval change. Update the interval change. With preset disturbance threshold Comparison, preset perturbation threshold Set as update interval sequence The standard deviation is 1.5 times the standard deviation. The standard deviation of the update interval sequence is calculated from all update interval values ​​in the update interval sequence. The 1.5-fold factor is set based on the fact that, under the condition that the update frequency of the cleanroom functional module operation data is relatively stable, events with local mean fluctuations exceeding 1.5 times the standard deviation have a low probability of being accidental and are more likely to be system performance changes caused by life cycle stage transitions. When, position the sliding window The candidate mutation sites are marked, and the update interval for each candidate mutation site is... to The center position of the interval, i.e., the timestamp is At that moment.

[0049] Using each candidate mutation location as the center, truncate the data forward and backward by a preset length. Two update interval subsequences. Preset length. The setting is 10 because, at typical acquisition frequencies, 10 update intervals can represent the data update behavior of a functional module over several hours to a day, providing sufficient statistical information to determine differences in behavior before and after. The forward-trunculated subsequence is the closest sequence before the candidate mutation location. Each update interval, the truncated subsequence is the closest sequence after the candidate mutation position. Update intervals. Calculate the mean of the forward-trimmed subsequence. and standard deviation Calculate the mean of the subsequence that is cut off later. and standard deviation If the statistical characteristics of two subsequences simultaneously satisfy... and If a candidate mutation location is found to be a valid mutation point, then that location is selected. This condition indicates that both the central trend and fluctuation intensity of the update interval have changed significantly between the two phases. If a candidate mutation location does not meet the above condition, it is removed from the list of candidate mutation locations.

[0050] Based on the timestamp corresponding to the formal mutation point in the update event sequence, determine the lifecycle phase boundary point where the functional module transitions from the current lifecycle phase to the next lifecycle phase. If the timestamp corresponding to the formal mutation point is... Then As demarcation points, the lifecycle of a functional module is divided into four phases: debugging, stabilization, decline, and decommissioning. Specifically, the time period before the first formal mutation point after the functional module is put into operation is marked as the debugging phase; the time period between the first and second formal mutation points is marked as the stabilization phase; the time period between the second and third formal mutation points is marked as the decline phase; and the time period after the third formal mutation point is marked as the decommissioning phase. If fewer than three formal mutation points are detected during the functional module's operation, the phases that can be divided based on the existing formal mutation points are marked, and the remaining subsequent phases are left blank, to be recalculated and updated after new data is accumulated.

[0051] After determining all lifecycle phase boundaries, each data record for that functional module in the modular operation and maintenance data asset is traversed, and the data generation timestamp in the data record is compared with the lifecycle phase boundary. If the data generation timestamp is less than the first boundary timestamp, "Debugging Period" is written to the newly added column "Lifecycle Phase Identifier" of that data record; if the data generation timestamp is greater than or equal to the first boundary timestamp and less than the second boundary timestamp, "Stable Period" is written; if the data generation timestamp is greater than or equal to the second boundary timestamp and less than the third boundary timestamp, "Decline Period" is written; if the data generation timestamp is greater than or equal to the third boundary timestamp, "Retirement Period" is written. Through the above operations, the lifecycle phases of the functional module are divided, and the lifecycle phase identifier is persisted to the corresponding data record in the modular operation and maintenance data asset.

[0052] See Figure 3In the graph, the horizontal axis represents time in hours, ranging from 0 to 1000 hours; the vertical axis represents the local mean of the update interval. The unit is hours, and the value ranges approximately from 0 to 3.5 hours. The curve in the figure represents the local mean of the update interval. The trend of change, the curve is calculated based on a sliding window of length 5, reflecting the dynamic change of the local mean of the data version number update event interval of the functional module over time. The dashed line in the figure represents the preset disturbance threshold. Its value is approximately 0.7 hours, serving as a baseline for judging whether the change in update interval is significant. The background color block indicates the "debugging" lifecycle phase of the functional module, which covers the entire time period from time 0 hours to approximately 1000 hours.

[0053] Observing the trend of the curve, the local mean of the update interval fluctuates between 0.3 and 0.5 hours in the initial stage (from 0 to about 100 hours), which is below the disturbance threshold. This indicates that the data version updates are relatively frequent and stable. Subsequently, the curve shows a significant jump at approximately 100 hours, quickly reaching around 1 hour, and then fluctuating between 0.8 and 1.5 hours, still below the upper limit of the disturbance threshold, indicating that the update interval has increased to some extent but with relatively small fluctuations. As time progresses, especially after approximately 600 hours, the local mean of the update interval shows a gradual upward trend, and the fluctuation amplitude increases, with the highest value exceeding 3 hours at one point, clearly breaking through the disturbance threshold. This reflects a significant increase in the interval between data version update events and enhanced instability.

[0054] According to the update interval change amount defined in Example 2 With disturbance threshold The comparison rules show that the increase in the local mean of the multiple update intervals in the graph exceeds the perturbation threshold. The time periods can be considered as candidate mutation locations, indicating that the functional module may be undergoing a transition in its life cycle stage. Since the background blocks in the figure are marked as the debugging period, it indicates that the data reflects the update behavior characteristics of the functional module during the debugging period, and the dividing points of the stable period, decline period, or retirement period have not yet been identified.

[0055] In practice, maintenance data records are read one by one from the modular maintenance data asset. Each maintenance data record in the modular maintenance data asset includes a functional module identifier, a lifecycle stage identifier, equipment status parameters, environmental indicators, personnel operation records, material batch information, and a data generation timestamp. Each maintenance data record is treated as an independent hypergraph node, and a globally unique node identifier is assigned to each hypergraph node. The node identifier is composed of the data table name of the modular maintenance data asset, the primary key value of the maintenance data record, and the record version number. Node attributes are bound to the hypergraph nodes. Node attribute fields include: Functional module identifier, whose value is the content of the functional module identifier field in the operation and maintenance data record; Lifecycle stage identifier, whose value is the content of the lifecycle stage identifier field in the operation and maintenance data record; Equipment status parameters, whose values ​​are key-value pairs consisting of numerical fields such as air supply frequency, filter pressure resistance, fan current, and valve opening in the operation and maintenance data record; Environmental indicators, whose values ​​are key-value pairs consisting of fields such as temperature measurement, relative humidity measurement, differential pressure measurement, and particle concentration measurement in the operation and maintenance data record; Personnel operation records, whose values ​​are strings consisting of personnel number, operation action code, and operation timestamp in the operation and maintenance data record; and Material batch information, whose values ​​are strings consisting of material code and batch number in the operation and maintenance data record. All hypergraph nodes are stored in the node table of the graph database.

[0056] Based on node attributes, at least two hypergraph nodes with the same functional module identifier and data association within the same lifecycle stage are connected as a hyperedge. For all hypergraph nodes with the same lifecycle stage identifier, they are grouped according to their functional module identifier. Within each group with the same functional module identifier and the same lifecycle stage identifier, the data association strength between any pair of hypergraph nodes is calculated. The data association strength is calculated as follows: extract the key-value pairs of the device status parameters of the two hypergraph nodes, calculate the difference in common parameters, and if the difference in all common parameters does not exceed 5% of the corresponding parameter range, then the two hypergraph nodes are considered to have a data association; or, if the personnel numbers in the personnel operation records of the two hypergraph nodes are the same and the operation timestamps differ by no more than 60 seconds, then the two hypergraph nodes are considered to have a data association; or, if the material codes and batch numbers in the material batch information of the two hypergraph nodes are the same, then the two hypergraph nodes are considered to have a data association. If more than two hypergraph nodes within a group have data associations with each other, these hypergraph nodes are connected by a hyperedge. In the hypergraph database, a hyperedge is represented by a hyperedge record, which contains a unique identifier for the hyperedge and a list of node identifiers for the hypergraph nodes it connects to.

[0057] All hyperedges within the same time window are arranged chronologically to form a time slice sequence. The length of the time window is set to 24 hours, with midnight of the calendar day as the window boundary. For each time window, all hyperedges within the window are sorted in ascending order by the earliest timestamp generated in the associated operation and maintenance data record at the time of their creation, resulting in an ordered list of hyperedges. This ordered list of hyperedges and its corresponding time window start and end timestamps are considered as a time slice. All time slices are arranged in ascending order by the time window start timestamp to form a time slice sequence.

[0058] A dynamic hypergraph is constructed on the time-slice sequence through iterative updates. The iterative updates include three operations: adding hyperedges, invalidating hyperedges, and updating weights.

[0059] For handling newly added hyperedges: Each hyperedge in the current time slice's hyperedge list is compared with the existing hyperedge set in the constructed dynamic hypergraph. If a hyperedge connects a node identifier list containing a combination of nodes that has never appeared in the existing hyperedge set, and all hypergraph nodes within that combination are hypergraph nodes that already existed in the current or previous time slices, then that hyperedge is marked as a newly added hyperedge. The earliest data generation timestamp among all operation and maintenance data records associated with the newly added hyperedge is written into the creation time attribute of the newly added hyperedge, and the newly added hyperedge is added to the hyperedge set of the dynamic hypergraph.

[0060] For handling failed hyperedges: Iterate through each existing hyperedge in the existing hyperedge set and check if the node identifier list connected to that existing hyperedge still satisfies the node attribute association condition within the current time slice. The node attribute association condition is checked as follows: Obtain the latest node attributes of all hypergraph nodes connected to that existing hyperedge at the current time slice. If the lifecycle stage identifier of one or more of these hypergraph nodes has changed, causing them to no longer be in the same lifecycle stage, or the functional module identifier has changed, or the original data association strength no longer meets the threshold, then mark the existing hyperedge as a failed hyperedge. Use the start timestamp of the current time slice as the failure time, write it into the failure time attribute of the failed hyperedge, and remove the failed hyperedge from the active hyperedge set of the dynamic hypergraph, transferring it to the historical hyperedge set.

[0061] For weight updates: For existing hyperedges still retained in the current time slice (i.e., those not marked as invalid in the active hyperedge set), update the active weight of the existing hyperedge based on the number of node attribute changes of the hypergraph nodes connected to it. Maintain an attribute change counter for each existing hyperedge. This counter records the total number of times any attribute field of any hypergraph node among all hypergraph nodes connected to the existing hyperedge has been updated since the hyperedge was created. Each time any field of a hypergraph node's functional module identifier, lifecycle stage identifier, equipment status parameters, environmental indicators, personnel operation records, or material batch information changes, the attribute change counter for all active hyperedges belonging to the relevant hypergraph node is updated. Add 1. Weight of the superedge activity. The update formula is:

[0062]

[0063] in, This indicates the updated superedge activity weight. The range of values ​​is ; This represents the initial activity weight when the superedge is created. Set to 1.0; Indicates the attenuation coefficient. Set to 0.05; This represents a counter for changes in the hyperedge attribute. This is a non-negative integer value. Attenuation coefficient. The reason for setting it to 0.05 is that after the cleanroom functional module enters a stable period, the attribute update frequency of the hypergraph node is usually low. Using a decay rate of 0.05 can make the active weight decay to half of the initial weight after 20 attribute changes. This can smoothly reflect the decrease in the correlation strength without drastically reducing the weight in a few environmental fluctuations.

[0064] Information on new, failed, and active weight changes of the same hypergraph node across different time slices is merged into the node evolution log of the dynamic hypergraph. The node evolution log uses the node identifier as the key and records the node's appearance in each time slice, including: a list of hyperedge identifiers for new hyperedges associated with the node in the current time slice; a list of hyperedge identifiers for failed hyperedges associated with the node in the current time slice; and the hyperedge identifiers and updated active weights of active hyperedges associated with the node in the current time slice. After processing each time slice, the dynamic hypergraph is updated based on the node evolution log, adding new hyperedges to the graph structure, removing failed hyperedges, and refreshing the weight attributes of active hyperedges. Through iterative processing across time slices, a dynamic hypergraph containing complete evolutionary information is finally obtained.

[0065] See Figure 4 In the graph, the horizontal axis represents the time slice number, and the vertical axis represents the activity weight of the hyperedge. The graph represents the weight changes of each hyperedge in a dynamic hypergraph over time. The legend identifies five hyperedge curves: E1 (solid blue), E2 (dashed orange), E3 (dotted green), E4 (dotted red), and E5 (dotted purple). The initial activity weights of each hyperedge are close to 1.0, and they gradually decrease with increasing time slice numbers, reflecting the weakening of hyperedge association strength as hypergraph node attributes are continuously updated.

[0066] Specifically, the activity weights of hyperedges E1 and E2 decayed relatively slowly, remaining above 0.25 until approximately time slice 400, indicating that the attributes of the hypergraph nodes they connect change little and the associations are relatively stable. In contrast, the weights of hyperedges E3, E4, and E5 decayed more rapidly, dropping below 0.15 by time slice 400, reflecting frequent changes in the attributes of their associated nodes and a significant decrease in the strength of their associations.

[0067] The decay of the activity weight conforms to the weight update formula described in Example 3. The initial weights The attenuation coefficient is 1.0. Set to 0.05, attribute change counter The weights increase over time. The gradual decrease in weights in the graph reflects the real-time evolution of the hyperedge activity state in the dynamic hypergraph, effectively reflecting the dynamic characteristics of the change in the strength of the association between functional modules with the life cycle stage.

[0068] In practical implementation, all hypergraph node and hyperedge data are read from the constructed dynamic hypergraph. The dynamic hypergraph is persistently stored in the form of a graph database. Each hypergraph node corresponds to a data object, and each data object is represented by a unique node identifier in the dynamic hypergraph. The node identifier has been defined in Example 3. Each data object in the dynamic hypergraph is treated as a hypergraph node. The node identifier and all node attribute fields of each hypergraph node are extracted from the graph database. The node attribute fields include functional module identifier, lifecycle stage identifier, equipment status parameters, environmental indicators, personnel operation records, and material batch information. The associated edges connecting at least two hypergraph nodes in the dynamic hypergraph are treated as hyperedges. Each hyperedge is represented by a hyperedge identifier and a list of node identifiers it connects to. The hyperedge identifier, node identifier list, creation time attribute, failure time attribute, and activity weight of each hyperedge are extracted from the graph database.

[0069] The dynamic hypergraph is sliced ​​according to its data generation time to obtain a time slice sequence. The data generation time is obtained from the data generation timestamps in the operation and maintenance data records bound to the hypergraph nodes. For each hyperedge, its data generation time is the minimum value among the data generation timestamps in the operation and maintenance data records of all hypergraph nodes connected to that hyperedge. The time slices are divided as follows: a fixed time window length of 24 hours is used, with no overlap between adjacent time windows. The start time of the first time window is aligned with the earliest data generation time in the dynamic hypergraph. For each time window, all active hyperedges and their connected active hypergraph nodes are extracted to form a time slice. An active hyperedge is defined as one whose creation time is earlier than or equal to the end time of the time window and whose failure time is either empty or later than the start time of the time window. All time slices are sorted monotonically in ascending order according to their time window start times to form a time slice sequence.

[0070] In practice, each time slice extracts the connected components of the hypergraph connected by hyperedges. All hypergraph nodes and hyperedges within a time slice are traversed to construct an undirected association graph. The vertices of this graph are the hypergraph nodes within the time slice, and the edges represent the associations between each pair of hypergraph nodes connected by a hyperedge within the time slice. If a hyperedge connects more than two hypergraph nodes, an edge is added between each pair of these hypergraph nodes in the association graph. A breadth-first search is performed on the association graph to find all connected components. Each connected component contains a set of hypergraph nodes that are path-to-path to each other, along with a set of hyperedges connecting these nodes. Each connected component is treated as a hypergraph component, and the set of node identifiers and hyperedge identifiers contained within it are recorded.

[0071] Hyperedge connection structures that appear more than a preset threshold in each hypergraph connected component are identified and designated as candidate hypergraph modalities. Hyperedge connection structures are defined by hyperedge connection patterns, which describe the connection topology between hyperedges and hypergraph nodes within a hypergraph connected component. For each hypergraph connected component, the feature vector of its hyperedge connection pattern is extracted. The feature vector is constructed by grouping all hypergraph nodes within the component according to their functional module identifiers, counting the number of hypergraph nodes in each group, and simultaneously counting the number of hyperedges between each pair of functional module identifier groups. These statistics are then arranged into a fixed-length vector. All hypergraph connected components extracted from all time slices are clustered according to their hyperedge connection pattern feature vectors. Hypergraph connected components with identical feature vectors are grouped into the same type of hyperedge connection structure. The preset threshold is set to 3, based on the principle that if the same type of hyperedge connection structure appears less than 3 times, the structure is likely a pseudo-association caused by occasional sensor anomalies or transient operational behavior, and does not possess the characteristics representing a stable association between functional modules. The occurrence frequency of each hyperedge connection structure is counted, and hyperedge connection structures that occur 3 or more times are selected as candidate hypergraph modalities. Each candidate hypergraph modality is assigned a modality type identifier, and the feature vector of the corresponding hyperedge connection pattern is recorded.

[0072] The evolutionary trajectory of a candidate hypergraph motif is generated by tracking node overlap, hyperedge merging, and hyperedge splitting events in adjacent time slices. For each candidate hypergraph motif, the time slice sequence is traversed to identify all instances of that candidate hypergraph motif in each time slice. An instance is composed of a hypergraph connected component of a feature vector that conforms to the hyperedge connection pattern of the candidate hypergraph motif. For two adjacent time slices... and ,in This indicates the index of the time slice in the time slice sequence. The value is a positive integer. In the time slice Candidate hypergraphs exist One instance, in time slice There exists One instance. Calculate time slices. The first in An example and time slice The first in Node overlap between instances The calculation formula is:

[0073]

[0074] in, Indicates the degree of node overlap. The range of values ​​is ; Representing time slices The Middle Each instance contains a set of node identifiers; Representing time slices The Middle Each instance contains a set of node identifiers; Represents a set The number of node identifiers in the data; Represents a set The number of node identifiers in the data; This represents the number of node identifiers in the intersection of two sets. When When the value is greater than 0.5, the time slice is determined. The first in An example and time slice The first in Each instance is an instance on the same evolutionary chain.

[0075] The superedge merge event is defined as: in a time slice Two or more superedges belonging to different instances in the time slice In a time slice, a hyperedge is merged into a single instance, and the set of node identifiers connected by this merged hyperedge is the union of the set of node identifiers connected by the merged hyperedge. A hyperedge splitting event is defined as: in a time slice... A superedge belonging to the same instance in the time slice The superedge is split into two or more superedges belonging to different instances, and the union of the set of node identifiers connected by the split superedges is equal to the set of node identifiers connected by the original superedges. Record the time slice number, instance identifier, and superedge identifier of all superedge merging and splitting events.

[0076] Connect all instances on the same evolutionary chain in ascending order of time slice number to form a hypergraph motif evolution trajectory. The hypergraph motif evolution trajectory includes: trajectory identifier, motif type identifier of the corresponding candidate hypergraph motif, set of node identifiers and hyperedge identifiers of instances in each time slice of the trajectory, and list of hyperedge merging events and hyperedge splitting events that occur on the trajectory.

[0077] The evolution trajectory of the hypergraph schema is compared with the lifecycle stages of its functional modules. The start timestamp of each time slice covered by the hypergraph schema evolution trajectory is extracted, and the lifecycle stage identifier of each functional module corresponding to that timestamp is located in the modular operation and maintenance data asset. For each instance on the hypergraph schema evolution trajectory, the distribution of lifecycle stage identifiers of the functional modules corresponding to each hypergraph node within the instance is statistically analyzed. Based on the duration and stage transition direction of the hypergraph schema evolution trajectory within its lifecycle stages, the association patterns between functional modules are determined.

[0078] The duration is determined as follows: The number of consecutive time slices appearing in the same lifecycle phase of the hypergraph motif's evolution trajectory is calculated. This number of time slices is multiplied by the time window length of 24 hours to obtain the duration of the hypergraph motif's evolution trajectory within that lifecycle phase. The phase transition direction is determined as follows: When the lifecycle phase identifiers of two adjacent instances on the hypergraph motif's evolution trajectory change from the debugging phase to the stable phase, the phase transition direction is recorded as a positive transition; when changing from the stable phase to the decay phase or from the decay phase to the decommissioning phase, the phase transition direction is recorded as a decay transition; when jumping from the decay phase back to the stable phase, the phase transition direction is recorded as an abnormal bounce. Candidate hypergraph motifs corresponding to hypergraph motifs whose evolution trajectory duration exceeds 72 hours and whose phase transition direction is a predetermined direction are identified as valid association patterns between functional modules. The predetermined phase transition directions include positive transitions and decay transitions, but do not include abnormal bounces. Write the association patterns into the newly added association pattern storage table in the modular operation and maintenance data asset in JSON document format. The fields of the association pattern storage table include a list of functional module identifiers, a lifecycle stage identifier, an association pattern description, and an effective time period for the association pattern.

[0079] In practice, established association patterns are retrieved from modular operation and maintenance data assets. These association patterns are stored in a JSON document format in the association pattern storage table of the modular operation and maintenance data assets. Each association pattern record includes a list of functional module identifiers, a lifecycle stage identifier, an association pattern description, and a valid time period for the association pattern. The operation and maintenance policy library is implemented using a relational database table structure. Each row in the operation and maintenance policy library corresponds to a policy rule. Policy rule fields include policy number, applicable association pattern characteristics, applicable lifecycle stage, task type code, task execution cycle, scope of modules affected by the task, amount of historical data required by the task, default value for task urgency level, default value for resource consumption, and default value for data update frequency. The applicable association pattern characteristic field stores a regular expression matching template for the association pattern description text. The value of the association pattern description field in each retrieved association pattern record is matched with the applicable association pattern characteristic field of all records in the operation and maintenance policy library using regular expressions. Simultaneously, the lifecycle stage identifier in the association pattern record is compared with the applicable lifecycle stage field in the operation and maintenance policy library for equality. When the association pattern description field and lifecycle stage identifier of an association pattern record successfully match the applicable association pattern feature field and applicable lifecycle stage field of a policy rule in the operation and maintenance policy library, the task type code, task execution cycle, scope of modules affected by the task, amount of historical data required by the task, default values ​​for task urgency level, default values ​​for resource consumption, and default values ​​for data update frequency are extracted from that policy rule. Based on this policy rule, a candidate operation and maintenance task is generated for each functional module included in the functional module identifier list in the association pattern record. All generated candidate operation and maintenance tasks are collected to obtain a candidate operation and maintenance task set.

[0080] The task type, execution cycle, affected module scope, and required historical data volume for each candidate operation and maintenance task are extracted from the candidate operation and maintenance task set. The task type is directly read from the task type code field of the candidate operation and maintenance task; the task type name corresponding to the task type code is obtained by looking up the task type dictionary table stored in the operation and maintenance strategy library. The execution cycle is read from the execution cycle field of the candidate operation and maintenance task, with the execution cycle in hours representing the task's cyclic execution interval. The affected module scope is read from the task affected module scope field of the candidate operation and maintenance task; the affected module scope is a list of functional module identifiers, listing other functional modules that need to cooperate with or be affected when executing this candidate operation and maintenance task. The required historical data volume is read from the task required historical data volume field of the candidate operation and maintenance task; the required historical data volume in megabytes represents the size of historical data in the modular operation and maintenance data assets that need to be backtracked and analyzed when executing this candidate operation and maintenance task.

[0081] Based on task type and the scope of affected modules, the urgency level of candidate maintenance tasks is determined. A pre-defined task urgency mapping table is used in the maintenance system. This table uses the task type code and the number of affected modules as the joint input key, and outputs the task urgency level. The task urgency level is divided into five levels, represented by numbers 1 to 5, with higher numbers indicating higher urgency. The number of affected modules is the number of functional module identifiers included in the list of affected modules for the candidate maintenance task. The task urgency mapping table is constructed as follows: when the task type involves the control of core cleanroom environmental parameters and the number of affected modules is not less than 3, the task urgency level is set to 5; when the task type involves the control of core cleanroom environmental parameters and the number of affected modules is less than 3, the task urgency level is set to 4; when the task type is an equipment status monitoring task and the number of affected modules is not less than 2, the task urgency level is set to 3; when the task type is an equipment status monitoring task and the number of affected modules is less than 2, the task urgency level is set to 2; otherwise, the task urgency level is set to 1.

[0082] Based on the required historical data volume, the resource usage of the corresponding data partitions for candidate maintenance tasks is queried in the distributed big data management node. The distributed big data management node consists of multiple servers deployed in a cleanroom maintenance data center. Each server runs a distributed file system data node process and a distributed computing framework task management process. A data partition usage status table is maintained on the distributed big data management node. This table records the storage node number and current disk usage percentage of the data partitions corresponding to each functional module identifier within different time ranges. Based on the required historical data volume for the candidate maintenance task, the current disk usage percentage of the data partitions covering the required time range is queried from the data partition usage status table. The average disk usage percentage of each relevant data partition is then calculated to obtain the mean disk usage percentage. The product of this mean disk usage percentage and the required historical data volume for the candidate maintenance task is used as the resource usage volume. Resource usage is measured in megabytes.

[0083] The data update frequency is determined based on the number of times the operation and maintenance (O&M) tags of functional modules are updated within the execution cycle. The O&M tags of functional modules are stored in the O&M tag field of the modular O&M data asset. The O&M tag field value is updated by the task write-back operation after each O&M task execution. The number of change records for the O&M tag field of the functional module corresponding to the candidate O&M task is retrieved from the modular O&M data asset within the time range of the previous execution cycle from the current moment. This number of change records is used as the O&M tag update count. The data update frequency is obtained by dividing the O&M tag update count by the execution cycle length, with the unit being times per hour.

[0084] Based on the sorting results of task urgency, resource consumption, and data update frequency, task priorities are assigned to each candidate maintenance task. The task priority allocation uses a multi-attribute sorting method: all candidate maintenance tasks are first sorted by urgency from highest to lowest; for candidate maintenance tasks with the same urgency, they are sorted by resource consumption from lowest to highest; for candidate maintenance tasks with the same resource consumption, they are sorted by data update frequency from highest to lowest. After sorting, the candidate maintenance task at the top of the list is assigned a priority of 1, the next one is assigned 2, and so on, with lower priority values ​​indicating higher priority. After task priority allocation, the task priority value of each candidate maintenance task is written to the task priority field of the candidate maintenance task.

[0085] Candidate maintenance tasks are arranged into a full lifecycle maintenance task queue based on task priority and the order of their lifecycle stages. The full lifecycle maintenance task queue is an ordered list of tasks, sorted according to the following rules: First, all candidate maintenance tasks are grouped according to the order of their associated lifecycle stage identifiers in a preset stage sequence table. The preset stage sequence table specifies the order of the four lifecycle stages as debugging, stabilization, decline, and decommissioning. Within the same lifecycle stage group, candidate maintenance tasks are arranged in ascending order of task priority. For candidate maintenance tasks with the same priority, they are arranged in ascending order of their task execution cycle. After sorting, an ordered full lifecycle maintenance task queue is obtained.

[0086] A mapping relationship is established between the task identifier of each candidate maintenance task in the full lifecycle maintenance task queue and the maintenance tag of the functional module. Each candidate maintenance task is assigned a globally unique task identifier upon generation, which consists of a task type code, a functional module identifier, and a generation timestamp. The maintenance tag is an extended field set for each data record in the modular maintenance data asset table, with an initial value of an empty string. The mapping relationship is established as follows: for each candidate maintenance task in the full lifecycle maintenance task queue, a mapping record is generated. This record contains a task identifier field and a maintenance tag value field. The maintenance tag value field is a string concatenated from the candidate maintenance task's task type code and task priority value. This mapping record is then inserted into a mapping relationship table, which uses the task identifier as the primary key and the maintenance tag value as a non-key column.

[0087] The mapping relationship is written back to the modular operation and maintenance data asset, and the operation and maintenance tags of the functional modules are updated using the task identifier. The write-back operation process is as follows: traverse each mapping record in the mapping relationship table, and extract the task identifier field and the operation and maintenance tag value field from the mapping record. Based on the functional module identifier concatenated in the task identifier, locate all data records in the modular operation and maintenance data asset that belong to that functional module identifier and whose lifecycle stage identifier is the same as the lifecycle stage identifier corresponding to the candidate operation and maintenance task. Update the value of the operation and maintenance tag field of these data records to the content of the operation and maintenance tag value field in the mapping record. If a data record already has an old value in the operation and maintenance tag field before the write-back, concatenate the old value and the new value separated by a semicolon and store them in the operation and maintenance tag field of the data record. At the same time, the task identifier of this write-back is written as an independent audit log to the operation and maintenance tag change log table of the modular operation and maintenance data asset. The operation and maintenance tag change log table records the primary key of the data record, the task identifier, the operation and maintenance tag value before the change, and the operation and maintenance tag value after the change.

[0088] For each candidate operation and maintenance task, calculate the priority score. The calculation formula is:

[0089]

[0090] in, This indicates the priority score of the candidate operation and maintenance task. The value of is a non-negative real number. A higher value indicates a higher task priority; Indicates the level of urgency of the task. The value is an integer from 1 to 5, obtained by querying the aforementioned task urgency mapping table; Indicates resource usage. The value is a positive real number, and the unit is megabytes. It is obtained by querying the data partition usage in the distributed big data management node. This represents the maximum resource consumption among all candidate operation and maintenance tasks, in megabytes, and is used to normalize resource consumption. Indicates the data update frequency. The value is a non-negative real number, and the unit is times per hour. It is obtained by dividing the number of times the operation and maintenance label is updated within the execution cycle by the execution cycle. This represents the maximum data update frequency among all candidate operation and maintenance tasks, expressed in times per hour, and is used to normalize the data update frequency. This represents a weighted coefficient for task urgency, with a value of 0.5. This represents the weighting coefficient for resource utilization, with a value of 0.3. This represents the weighting factor for data update frequency, with a value of 0.2. The weighting factor for task urgency is... Take 0.5 as the weighting coefficient for resource usage. Take 0.3 as the weighting coefficient for data update frequency. The 0.2 value is chosen because task urgency has the greatest impact on operational priority, followed by resource utilization, and then data update frequency; the sum of the weights of these three factors is 1. In the revised formula, It is a dimensionless order value. Dimensionless normalized value (range of values) ), Dimensionless normalized value (range of values) The three quantities are dimensionless and have the same dimensions, so they can be directly added. Based on each candidate maintenance task... The scores are sorted from highest to lowest, and task priorities are assigned accordingly. The task with the highest score is assigned priority 1, the second highest score is assigned priority 2, and so on.

[0091] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A modular cleanroom full lifecycle intelligent operation and maintenance data management method, characterized in that, include: Collect operational data from various functional modules within the cleanroom, perform data lineage analysis on the operational data, and generate modular operation and maintenance data assets; Based on the update sequence of the modular operation and maintenance data assets, the lifecycle stages of the functional modules are divided; During the lifecycle phase, the multi-source data in the modular operation and maintenance data assets are mapped into a dynamic hypergraph, and the dynamic hypergraph is subjected to a modal evolution analysis to obtain the association pattern of each functional module. Based on the association pattern, a full lifecycle operation and maintenance task queue is generated, and the full lifecycle operation and maintenance task queue is written back to the modular operation and maintenance data asset to update the operation and maintenance tags of the functional modules.

2. The modular cleanroom full lifecycle intelligent operation and maintenance data management method according to claim 1, characterized in that, The step of performing data lineage analysis on the operational data to generate modular operation and maintenance data assets includes: Metadata tags are added to each piece of operational data according to its data source, acquisition device, acquisition time, data version, and business semantics to obtain labeled operational data. Based on the business semantics in the annotated running data, the annotated running data is divided into multiple modular data units; Establish a lineage boundary between each modular data unit and the functional module, and write the lineage boundary into the data lineage graph; Based on the lineage path from the functional module to the modular data unit in the data lineage diagram, the data integrity of the modular data unit is verified, and the modular data units that pass the verification are aggregated into the modular operation and maintenance data asset.

3. The modular cleanroom full lifecycle intelligent operation and maintenance data management method according to claim 1, characterized in that, The step of dividing the lifecycle stages of the functional modules according to the update sequence of the modular operation and maintenance data assets includes: Extract data from each functional module of the modular operation and maintenance data asset to generate a timestamp and data version number; The data version number change events are arranged into an update event sequence according to the order of the data generation timestamps; The time intervals between adjacent update events in the update event sequence are statistically analyzed to obtain the update interval sequence. The update interval sequence is subjected to mutation point detection, and the time corresponding to the detected mutation point is used as the life cycle stage dividing point of the functional module between the debugging period, the stable period, the decline period and the retirement period. Based on the lifecycle stage boundary points, lifecycle stage identifiers are added to each data record of the functional module in the modular operation and maintenance data asset.

4. The modular cleanroom full lifecycle intelligent operation and maintenance data management method according to claim 1, characterized in that, The step of mapping multi-source data in the modular operation and maintenance data asset to a dynamic hypergraph includes: Each operation and maintenance data record in the modular operation and maintenance data asset is treated as a hypergraph node, and the functional module identifier, life cycle stage identifier, equipment status parameters, environmental indicators, personnel operation records and material batch information in the operation and maintenance data record are used as the node attributes of the hypergraph node. Based on the node attributes, at least two hypergraph nodes that have the same functional module identifier and are associated with data within the same lifecycle stage are connected into a hyperedge. Arrange all superedges within the same time window in chronological order to form a time slice sequence; The hyperedges in the time slice sequence are iteratively updated according to the methods of adding new hyperedges, invalidating hyperedges, and weight updates to obtain the dynamic hypergraph.

5. The modular cleanroom full lifecycle intelligent operation and maintenance data management method according to claim 1, characterized in that, The step of performing phantom evolution analysis on the dynamic hypergraph to obtain the association patterns of each functional module includes: Each data object in the dynamic hypergraph is taken as a hypergraph node, and the associated edge connecting at least two hypergraph nodes is taken as a hyperedge; The dynamic hypergraph is sliced ​​according to the data generation time to obtain a time slice sequence; Extract the hypergraph connected components connected by the hyperedges from each of the time slices; The hyperedge connection structures that appear more than a preset threshold number of times in each hypergraph connected component are counted, and these hyperedge connection structures are used as candidate hypergraph moduli. Track the node overlap, hyperedge merging, and hyperedge splitting events of the candidate hypergraph motifs in adjacent time slices to generate the hypergraph motif evolution trajectory; The evolution trajectory of the hypergraph phantom is compared with the life cycle stages of the functional modules. Based on the duration and stage transition direction of the evolution trajectory of the hypergraph phantom in the life cycle stages, the association patterns between the functional modules are determined. Write the association pattern into the modular operation and maintenance data asset.

6. The modular cleanroom full lifecycle intelligent operation and maintenance data management method according to claim 1, characterized in that, The step of generating a full lifecycle operation and maintenance task queue based on the association pattern, and writing the full lifecycle operation and maintenance task queue back to the modular operation and maintenance data asset to update the operation and maintenance tags of the functional modules includes: The association pattern is matched with the policy rules in the operation and maintenance policy library to obtain a set of candidate operation and maintenance tasks for the functional module under the life cycle stage. Based on the task urgency, resource consumption, and data update frequency in the candidate operation and maintenance task set, assign a task priority to each candidate operation and maintenance task. The candidate maintenance tasks are arranged into the full lifecycle maintenance task queue according to the task priority and the order of the lifecycle stages. Establish a mapping relationship between the task identifier of each candidate operation and maintenance task in the full lifecycle operation and maintenance task queue and the operation and maintenance tag of the functional module; The mapping relationship is written back to the modular operation and maintenance data asset, and the operation and maintenance label of the functional module is updated using the task identifier.

7. The modular cleanroom full lifecycle intelligent operation and maintenance data management method according to claim 2, characterized in that, The step of verifying the data integrity of the modular data unit according to the lineage path from the functional module to the modular data unit in the data lineage diagram, and aggregating the verified modular data units into the modular operation and maintenance data asset, includes: Select all lineage paths from the data lineage diagram, with the starting node being the functional module and the ending node being the modular data unit; For each of the aforementioned lineage paths, the data source nodes, transformation operation nodes, and storage nodes on the path are extracted, and a path sequence is generated according to the data flow order; Map the data fields corresponding to the transformation operation nodes in the path sequence to integrity verification fields; The integrity verification field is used to check for missing values, duplicate values, and outliers in the modular data unit to obtain a data integrity score. When the data integrity score is higher than the preset passing score, the modular data unit is added to the modular operation and maintenance data asset.

8. The modular cleanroom full lifecycle intelligent operation and maintenance data management method according to claim 3, characterized in that, The step of detecting mutation points in the update interval sequence and using the time corresponding to the detected mutation point as the boundary point of the functional module's life cycle stages between the debugging period, stable period, decline period, and retirement period includes: A sliding window is set on the update interval sequence, and the local mean of the update interval within each sliding window is recorded; Calculate the change in update interval of the sliding window between adjacent window positions, and mark the window positions where the change in update interval exceeds a preset perturbation threshold as candidate mutation positions; Using the candidate mutation position as the center, compare the statistical characteristics of the update interval subsequences of two preset lengths before and after the candidate mutation position to screen out the formal mutation point; Based on the timestamp corresponding to the formal mutation point in the update event sequence, the life cycle stage boundary point at which the functional module moves from the current life cycle stage to the next life cycle stage is determined.

9. The modular cleanroom full lifecycle intelligent operation and maintenance data management method according to claim 4, characterized in that, The step of iteratively updating the hyperedges in the time slice sequence according to the method of adding new hyperedges, invalidating hyperedges, and updating weights to obtain the dynamic hypergraph includes: The first supergraph node relationship to appear in the current time slice is taken as the new superedge, and the timestamp of the operation and maintenance data record associated with the new superedge is written into the creation time attribute of the new superedge. Mark existing superedges in the current time slice that no longer meet the node attribute association conditions as failed superedges, and record the failure time in the attributes of the failed superedges; For existing hyperedges that are still retained in the current time slice, update the activity weight of the existing hyperedges according to the number of node attribute changes of the hypergraph nodes connected to the existing hyperedges; The information on new hyperedges, failed hyperedges, and changes in activity weights of the same hypergraph node in different time slices is merged into the node evolution log of the dynamic hypergraph, and the dynamic hypergraph is updated according to the node evolution log.

10. The modular cleanroom full lifecycle intelligent operation and maintenance data management method according to claim 6, characterized in that, The step of assigning task priority to each candidate maintenance task based on the task urgency, resource consumption, and data update frequency in the candidate maintenance task set includes: Extract the task type, execution cycle, affected module range, and required historical data volume for each candidate operation and maintenance task from the candidate operation and maintenance task set; Based on the task type and the scope of the affected modules, the task urgency level of the candidate maintenance tasks is determined; Based on the required amount of historical data, query the data partition usage of the candidate operation and maintenance task in the distributed big data management node to obtain the resource usage. The data update frequency is determined based on the number of times the operation and maintenance tags of the functional modules are updated within the execution cycle; Based on the sorting results of the task urgency level, resource consumption, and data update frequency, assign the task priority to each candidate maintenance task.

Images