A manufacturing whole-process data penetration method for steel structure order

CN122390042BActive Publication Date: 2026-09-25HANGZHOU CHUMING DIGITAL INTELLIGENCE TECH CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202610874087.8
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2026-06-17
Publication Date
2026-09-25
Estimated Expiration
2046-06-17

AI Technical Summary

Technical Problem

然而,上述方案各自独立运作,领域规则嵌入面向数学优化而非知识图谱路径推导,知识图谱推理面向参数推荐而非生成约束基准,且均未将工艺偏差隐性调整记录作为独立数据类型纳入贯通体系

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122390042B_ABST
    Figure CN122390042B_ABST
Patent Text Reader

Abstract

The application discloses a manufacturing whole-process data penetration method for steel structure orders, and belongs to the technical field of computers. The method is characterized in that personalized constraint benchmarks are established, process parameter implicit adjustment behaviors are identified and recorded, compliance of the adjustment behaviors that have occurred is automatically verified after component design changes, influences of the adjustment behaviors on subsequent work orders are forwardly analyzed, comprehensive response strategies for the manufacturing work orders are generated, and the comprehensive response strategies are summarized to order state timelines. Thus, the problem that process implicit adjustment is invisible and untraceable in steel structure manufacturing is solved, data penetration between design changes and process adjustment is realized, and the integrity and traceability of manufacturing whole-process information are ensured.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method for data integration throughout the entire manufacturing process of steel structure orders. Background Technology

[0002] Steel structure manufacturing is order-driven, and process engineers often make implicit on-site adjustments to theoretical process parameters based on actual conditions such as material batches and ambient temperature during production, such as adjusting welding current or preheating time. These adjustments are completely invisible in existing information systems; the comparison of parameters before and after the adjustments, the basis for the adjustments, and the impact on downstream processes are not systematically recorded, becoming a missing link in the overall manufacturing data.

[0003] In existing technologies, some solutions construct the correlation between design parameters and process parameters through statistical co-occurrence, some embed domain rules into optimization decision models, and others utilize knowledge graphs for welding process parameter recommendation. However, these solutions operate independently; domain rule embedding is geared towards mathematical optimization rather than knowledge graph path derivation, knowledge graph reasoning is geared towards parameter recommendation rather than generating constraint benchmarks, and none of them incorporate implicit process deviation adjustment records as an independent data type into the overall system.

[0004] The resulting problem is that when design changes occur to steel structure components, the implicit process adjustments that have already taken place cannot be automatically traced back to verify their compliance under the new design conditions along the manufacturing semantic constraints, making the process adjustments an untraceable breakpoint relative to the design changes. Summary of the Invention

[0005] This application provides a method for data integration across the entire manufacturing process for steel structure orders, the technical solution of which is as follows: On the one hand, a method for data integration across the entire manufacturing process for steel structure orders is provided, the method comprising: The personalized constraint parameter values ​​derived from the welding process knowledge base based on the semantic reasoning of steel structure component manufacturing are injected into the process process constraint rules deployed on the process execution association path in the dynamic process knowledge graph, thereby instantiating the process process constraint rules into executable constraint benchmarks. Based on the executable constraint benchmark, process parameter adjustment behavior is identified from the time sequence data of steel structure welding process, and the identification results are converted into adjustment records that are automatically verified by process deviation adjustment rules. In response to a component design change event, the updated constraint parameter values ​​are obtained by re-inferring based on the changed component manufacturing semantics. Based on the updated constraint parameter values, compliance backtracking is performed on the adjustment records, and forward impact determination is performed along the associated path of the process. The results of the forward impact determination and the compliance backtracking determination are intersected to generate a comprehensive response strategy for manufacturing work orders. The comprehensive response strategy is summarized in the order status timeline. Attached Figure Description

[0006] To more clearly illustrate the technical solutions in the embodiments of this application, 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 this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0007] Figure 1 This is a flowchart of a method for data integration throughout the entire manufacturing process of steel structure orders, provided in an embodiment of this application. Figure 2 This is a flowchart of another method for data integration throughout the entire manufacturing process of steel structure orders, provided in an embodiment of this application. Figure 3 This is a flowchart of another data integration method for the entire manufacturing process of steel structure orders provided in this application embodiment; Figure 4 This is a flowchart of another method for data integration throughout the entire manufacturing process of steel structure orders, provided in an embodiment of this application. Figure 5 This is a flowchart of another method for data integration throughout the entire manufacturing process of steel structure orders, provided in an embodiment of this application. Detailed Implementation

[0008] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0009] In this application, the terms "first," "second," etc., are used to distinguish identical or similar items with essentially the same function. It should be understood that there is no logical or temporal dependency between "first," "second," and "nth," nor are there any restrictions on quantity or execution order.

[0010] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, data stored, data displayed, etc.) and signals involved in this application are all authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0011] During steel structure manufacturing, process engineers often make implicit on-site adjustments to theoretical process parameters based on actual operating conditions such as material batches and ambient temperature, for example, adjusting welding current or preheating time. Such adjustments lack visibility and systematic recording in existing information systems, and the comparison of parameters before and after the adjustments, the basis for the adjustments, and the impact on downstream processes are not effectively tracked. Related technical solutions often operate independently, failing to incorporate implicit process deviation adjustments as an independent data type into the overall system. This results in a situation where, when steel structure components undergo design changes, the implicit process adjustments that have already occurred cannot be automatically traced back to verify their compliance under the new design conditions along manufacturing semantic constraints. This makes process adjustments an untraceable breakpoint relative to design changes, leading to a gap in the entire manufacturing process data.

[0012] To address this, this application proposes a method for data integration across the entire manufacturing process of steel structure orders. This method involves injecting personalized constraint parameter values, derived from the welding process knowledge base based on the manufacturing semantics of steel structure components, into the process constraint rules deployed along the process execution path in a dynamic process knowledge graph. This instantiates the process constraint rules into executable constraint benchmarks. Based on these executable constraint benchmarks, process parameter adjustment behaviors are identified from the time-series data of steel structure welding processes. The identification results are then transformed into adjustment records automatically verified by process deviation adjustment rules. In response to component design change events, updated constraint parameter values ​​are derived through re-inference based on the changed component manufacturing semantics. Compliance backtracking is performed on the adjustment records based on the updated constraint parameter values, and forward impact determination is performed along the process execution path. The results of the forward impact determination and the compliance backtracking determination are intersected to generate a comprehensive response strategy for manufacturing work orders. This comprehensive response strategy is then summarized in the order status timeline.

[0013] For ease of understanding, the following explains some key terms in this embodiment: Welding process knowledge base: This refers to a structured database that stores a large amount of professional knowledge, standards and specifications, expert experience, and recommended rules for process parameters in the welding field. Its content covers the range of welding parameters, process requirements, and precautions under different weld types, material grades, plate thicknesses, and other conditions, providing a basis for reasoning about process parameters.

[0014] Manufacturing semantics of steel structure components refers to the structured information describing the design, materials, processes, and quality aspects involved in the manufacturing of steel structure components. It includes the component's geometric features, material properties, weld information, and processing requirements, expressing the component's manufacturing intent and constraints in a semantic manner.

[0015] Personalized constraint parameter values: These refer to the range or specific values ​​of process parameters specific to a particular steel structural member, calculated through reasoning. These parameter values ​​take into account the unique properties and manufacturing requirements of the member, rather than using generic or default parameters.

[0016] Dynamic process knowledge graph: refers to a knowledge model constructed in the form of a knowledge graph that can reflect the steel structure manufacturing process and its interrelationships in real time. Its nodes can represent component entities, work order entities, process entities, process parameters, etc., while edges represent the execution, dependency, constraint and other relationships between them, and support real-time updates and queries.

[0017] Process execution association path: In a dynamic process knowledge graph, this refers to the logical sequence of connections between one process entity and another, or between one component entity and its related work order entity, through a series of associations. This path reflects the sequence and dependencies of manufacturing tasks.

[0018] Process constraint rules: These are logical rules deployed along the execution path of a process to regulate and verify process parameters during process execution. These rules define the conditions, ranges, or relationships that various process parameters should meet under a specific process.

[0019] Executable constraint baseline: refers to the set of instantiated rules that, after being injected with personalized constraint parameter values, acquire specific numerical boundaries or conditions, and can be directly used for the verification and judgment of actual process parameters.

[0020] Timing data for steel structure welding processes refers to time-stamped process parameter data collected in real time by sensors or recording systems during the steel structure welding process. Examples include records of changes in welding current, voltage, wire feed speed, and preheating temperature over time.

[0021] Process parameter adjustment behavior: refers to the operation process in which the actual value of process parameters deviates from the preset executable constraint benchmark during the execution of steel structure welding process, and intervention is carried out manually or automatically to restore it to the compliant range or achieve a new target value.

[0022] Process deviation adjustment rules: These are a set of specifications used to guide and verify the adjustment of process parameters. They define the permissible adjustment range, the basis for adjustment, the transmission effect after adjustment, and the requirements for the completeness and compliance of adjustment records.

[0023] Adjustment record: refers to a data entity that systematically records the adjustment of process parameters. It includes information such as the name of the adjusted parameter, the steady-state value before adjustment, the steady-state value after adjustment, the time of adjustment, the basis for adjustment, the explanation of the transmission constraints, and compliance markings.

[0024] Component design change events refer to events where the design drawings, bill of materials, or technical requirements of steel structure components are modified, resulting in changes to their manufacturing semantics. These events affect subsequent process parameter constraints and manufacturing processes.

[0025] Update constraint parameter values: refers to personalized constraint parameter values ​​that are re-inferred based on the modified component manufacturing semantics after a component design change event occurs, and are adapted to the new design requirements.

[0026] Compliance retrospective determination: After a component design change, the adjustment records that have occurred are re-evaluated based on the updated constraint parameter values ​​to determine their compliance status under the new design conditions and to trace the reasons for non-compliance.

[0027] Forward impact determination: This refers to analyzing the impact of design changes on related work order entities that have not yet been executed or are currently being executed after a component design change, along the process execution path, and determining the required process response category.

[0028] Integrated Response Strategy: This refers to a comprehensive response plan for manufacturing work orders that integrates compliance retrospective findings and forward impact assessment results. It aims to guide how to handle existing adjustments and incomplete processes to accommodate design changes.

[0029] Order Status Timeline: This refers to the time-series data recording key events, status changes, and important decisions throughout the entire lifecycle of a steel structure order, from creation to completion. Comprehensive response strategies will be aggregated here to achieve full traceability of the order process.

[0030] See Figure 1 The method of this application includes the following steps: 101. The personalized constraint parameter values ​​derived from the welding process knowledge base based on the semantic reasoning of steel structure component manufacturing are injected into the process process constraint rules deployed on the process execution association path in the dynamic process knowledge graph, so that the process process constraint rules are instantiated into executable constraint benchmarks.

[0031] In one embodiment, a set of general process parameter constraints can be predefined. For example, a fixed welding current range can be set for a certain general steel and welding method. These general constraint ranges are directly configured into the process constraint rules on the process execution path in the dynamic process knowledge graph. When a specific component needs to be manufactured, these rules directly serve as executable constraint benchmarks. Alternatively, process engineers can manually consult standard specifications in the welding process knowledge base based on experience, and manually calculate or select a set of personalized constraint parameter values ​​according to the type and size of the component. These parameter values ​​are manually entered into the corresponding process constraint rules in the dynamic process knowledge graph, thereby giving these rules specific numerical benchmarks and instantiating them as executable constraint benchmarks.

[0032] 102. Based on executable constraint benchmarks, identify process parameter adjustment behaviors from the time sequence data of steel structure welding processes, and convert the identification results into adjustment records that are automatically verified by process deviation adjustment rules.

[0033] In one embodiment, a threshold can be set. When the actual value of any process parameter in the timing data of the steel structure welding process continuously exceeds the range defined by the executable constraint baseline, it is marked as a potential process parameter adjustment. These marked events are manually reviewed by operators or quality inspectors to determine whether they constitute an actual adjustment and are manually recorded as adjustment records. These adjustment records are submitted to the process deviation adjustment rules for manual verification. For example, senior process engineers may judge the rationality and compliance of the adjustment based on experience and manually generate the adjustment records.

[0034] 103. In response to a component design change event, the updated constraint parameter values ​​are obtained by re-inferring based on the changed component manufacturing semantics.

[0035] When a component design change occurs, designers or process engineers can manually analyze the revised component design drawings and related technical documents to extract the revised component manufacturing semantic information. This includes identifying new weld types, material grades, or plate thickness parameters. This extracted information is manually entered into the system, which then uses preset simple mapping rules to retrieve the corresponding update constraint parameter values ​​from a predefined parameter table. Alternatively, upon receiving a design change notification, the system can prompt the user to manually input the revised component manufacturing semantics, for example, by selecting new design parameters through a drop-down menu or text box. Upon receiving this manual input, the system directly uses it as a condition to retrieve the corresponding update constraint parameter values ​​from a static process parameter database.

[0036] 104. Based on the updated constraint parameter values, perform compliance backtracking determination on the adjustment records, and perform forward impact determination along the process-related path. The results of the forward impact determination and the compliance backtracking determination are intersected to generate a comprehensive response strategy for manufacturing work orders. The comprehensive response strategy is summarized in the order status timeline.

[0037] In one embodiment, after obtaining the updated constraint parameter values, the process engineer can manually review each existing adjustment record. The engineer manually compares the adjusted steady-state values ​​recorded in the adjustment records with the updated constraint parameter values ​​to determine the compliance of the adjustment under the new design conditions. Based on their experience, the engineer manually assesses the impact of the design change on subsequent processes and related work orders, for example, by reviewing process flow diagrams to identify affected work orders. The engineer summarizes the manually determined compliance results and the forward impact assessment results, and manually formulates a comprehensive response strategy for manufacturing work orders based on preset simple rules, for example, by notifying relevant personnel via email or meetings. These manually formulated comprehensive response strategies are manually recorded in the order status timeline for later review.

[0038] This application establishes personalized constraint benchmarks, identifies and records implicit adjustments to process parameters, and automatically verifies the compliance of adjustments after component design changes. Simultaneously, it performs forward analysis on the impact on subsequent work orders, generates a comprehensive response strategy for manufacturing work orders, and summarizes it in the order status timeline. This solves the problem of invisible and untraceable implicit process adjustments in steel structure manufacturing, achieves data connectivity between design changes and process adjustments, and ensures the integrity and traceability of information throughout the entire manufacturing process.

[0039] This application further proposes a method to inject personalized constraint parameter values ​​derived from the welding process knowledge base based on the semantic reasoning of steel structure component manufacturing into the process process constraint rules deployed on the process execution association path in the dynamic process knowledge graph, thereby instantiating the process process constraint rules into executable constraint benchmarks. See [link to relevant documentation]. Figure 2 The steps include: 201. Extract the weld type, material grade, and plate thickness parameters from the manufacturing semantic information carried by the component entities in the dynamic process knowledge graph as inference conditions.

[0040] 202. Match the reasoning conditions with the welding process rules stored in the welding process knowledge base to obtain the constraint parameter values ​​for each process stage corresponding to the component entity.

[0041] 203. Execute the associated path along the process, write the constraint parameter values ​​of each process stage into the constraint parameter field of the corresponding work order entity, and establish a reference binding relationship between the constraint parameter field and the process constraint rule of the process, so that the process constraint rule of the process obtains a specific numerical benchmark and is instantiated into the executable constraint benchmark.

[0042] For example, the manufacturing semantic information carried by component entities in this dynamic process knowledge graph refers to the various structured and unstructured data related to the manufacturing process of a component, stored and associated with the component entity as the core within the dynamic process knowledge graph. This data includes, but is not limited to, the component's design attributes (such as geometric dimensions and materials), process attributes (such as weld location and welding requirements), production status (such as current process and completed working hours), and relationships with other entities (such as work orders, equipment, and personnel). Its function is to provide a comprehensive, accurate, and semantic data foundation for subsequent process reasoning. For instance, ontological modeling can be used to define the various manufacturing attributes and relationships of steel structure components as entities, relationships, and attributes in the knowledge graph, and then stored and managed using a graph database. Alternatively, standards such as the Resource Description Framework (RDF) can be used to construct semantic models of component entities, integrating information from design models and ERP / MES systems.

[0043] When extracting weld type, material grade, and plate thickness parameters as inference conditions, this step aims to filter out the most critical and direct attributes affecting welding process parameters from the complex semantic information of component manufacturing, serving as input for the welding process knowledge base to drive inference. Weld type determines the welding method and parameter range, material grade affects the welding performance and preheating requirements, and plate thickness parameters are directly related to welding current, voltage, number of layers, etc. Accurate extraction of these parameters is a prerequisite for ensuring the personalization and accuracy of the inference results. For example, these parameters can be directly extracted from their associated attributes by performing pattern matching on component entities using a predefined query language. Alternatively, information extraction techniques can be used to perform semantic analysis and structuring on the descriptive text associated with component entities.

[0044] The welding process knowledge base stores a structured collection of welding process rules, containing a wealth of welding process knowledge derived from expert experience, standard specifications, and historical data analysis. This knowledge exists in the form of rules, such as "When the weld type is X, the material grade is Y, and the plate thickness is Z, the recommended welding current range is AB amperes, and the preheating temperature is CD degrees Celsius." These rules are the core basis for personalized constraint parameter reasoning, ensuring the professionalism and reliability of the reasoning results. For example, a rule engine can be used to store and manage expert rules based on an If-Then structure. Alternatively, a case-based reasoning system can be built, storing historical successful welding cases as knowledge and recommending or deriving new process parameters through similarity matching.

[0045] This matching reasoning involves comparing and logically judging the extracted reasoning conditions against rules in the welding process knowledge base to find the welding process rule that best matches the semantics of the current component manufacturing, and extracting the corresponding constraint parameter values. This process is a key step in realizing personalized process parameters, transforming general knowledge into customized guidance for specific components. For example, based on semantic matching algorithms, the reasoning conditions can be accurately or fuzzily matched with the conditional parts of the rules in the knowledge base. When the matching degree reaches a preset threshold, the execution of the corresponding rule is triggered. Alternatively, machine learning models can be used to train on historical welding data to learn the mapping relationship between reasoning conditions and constraint parameter values, thereby achieving model-based reasoning.

[0046] The process execution association path refers to the path in a dynamic process knowledge graph that describes the logical sequence and dependencies between different processes, between processes and work orders, and between work orders and components. This path reflects the complete manufacturing process of steel structure components from raw materials to finished products. Operating along this path ensures that the inferred constraint parameter values ​​are accurately injected into their corresponding processes and work orders, maintaining data consistency and process integrity. For example, relationship types such as "preceding process," "subsequent process," "belongs to work order," and "acts on component" can be defined in the knowledge graph, and process execution association paths can be constructed and identified by traversing these relationships. Alternatively, process execution association paths can be formed in the knowledge graph by integrating process information from a business process management system.

[0047] The constraint parameter field of this work order entity represents a specific production task within the knowledge graph. This field is a specific attribute used to store process parameter constraint values ​​related to the execution of the work order. These fields provide a concrete storage location for personalized constraint parameters, enabling each work order to carry its own unique process execution baseline. For example, a series of attributes (such as "maximum welding current" and "maximum preheating temperature") can be predefined in the work order entity model of the knowledge graph to directly store inferred constraint parameter values. Alternatively, flexible key-value pairs or JSONB fields can be used to dynamically store different types of constraint parameters and their values ​​within the work order entity.

[0048] Establishing a reference binding relationship between the constraint parameter field and the process constraint rule is the core of instantiating the process constraint rule. By establishing this reference binding relationship, the originally general process constraint rule is no longer abstract, but can directly reference specific values ​​stored in a particular work order entity, thereby obtaining an executable numerical benchmark. This binding ensures that the rule can make judgments based on the actual situation of the current component during execution. For example, a reference expression to a specific constraint parameter field in the work order entity can be embedded in the definition of the process constraint rule. When the rule is triggered, the system automatically parses and obtains the current value of that field. Alternatively, an explicit "reference" or "binding" relationship can be established in the knowledge graph to associate the process constraint rule entity with the constraint parameter field entity in the work order entity, and the bound value can be obtained through graph traversal during rule execution.

[0049] The process constraint rules for this operation are instantiated into an executable constraint benchmark. Instantiation refers to transforming the originally abstract and general process constraint rules into a benchmark specific to a particular work order and operation, with a clearly defined numerical range or condition, by injecting personalized constraint parameter values ​​for specific components. This benchmark is dynamic and personalized, guiding actual production operations and serving as the basis for identifying and verifying subsequent process parameter adjustments. For example, in a rule engine, a general rule template can be dynamically combined with specific parameter values ​​obtained from the work order entity to generate a specific rule instance for that work order. Alternatively, rule expressions bound to specific numerical values ​​can be compiled or interpreted into directly executable verification logic through code generation or script interpretation.

[0050] The above technical solution provides a clear and feasible implementation path for injecting process constraint rules into personalized constraint parameters and instantiating executable constraint benchmarks. This solution leverages the information architecture of the dynamic process knowledge graph itself to obtain an accurate reasoning foundation. After reasoning, it correctly establishes the association between parameters and rules, ensuring that the generated executable constraint benchmarks meet the actual manufacturing requirements of the components corresponding to the current steel structure order. From the manufacturing semantic information carried by the component entities in the dynamic process knowledge graph, weld type, material grade, and plate thickness parameters are accurately extracted as reasoning conditions. This step relies on the already organized component manufacturing semantic information in the dynamic process knowledge graph to extract the core conditions required for reasoning, eliminating the need to reorganize information from scattered external data sources. This ensures the consistency of information sources and accurately extracts the core elements affecting welding process parameters, providing an accurate and reliable foundation for subsequent matching and reasoning. The reasoning conditions are matched with the welding process rules stored in the welding process knowledge base to obtain the constraint parameter values ​​for each process stage corresponding to the component entity. This step utilizes the welding process knowledge that has been accumulated and verified in the domain to complete the matching, which can directly obtain the sub-process constraint parameters adapted to the current specific component, rather than a general and fuzzy constraint standard, providing an accurate numerical source for the subsequent generation of executable constraint benchmarks. Along the process execution association path, the constraint parameter values ​​of each process stage are written into the constraint parameter field of the corresponding work order entity, and a reference binding relationship is established between the constraint parameter field and the process constraint rule of that process. This allows the process constraint rule to obtain a specific numerical benchmark and be instantiated as an executable constraint benchmark. This step completes the parameter writing and binding along the original association path of process execution, which not only ensures that the constraint parameters can correspond to the correct process and work order, but also allows the originally abstract general process constraint rule to obtain a specific numerical benchmark corresponding to this component through reference binding, thus completing the instantiation of the rule. This allows the rule to be directly used for the identification and compliance verification of subsequent process parameter adjustment behavior, fundamentally avoiding the problem of parameter and rule mismatch.

[0051] This application further proposes extracting weld type, material grade, and plate thickness parameters from the manufacturing semantic information of the component entities in the dynamic process knowledge graph as inference conditions, including: Perform node structure analysis on the steel structure detailed design model file associated with the component entity, and traverse the component nodes and the weld nodes associated with the component nodes.

[0052] Extract the material grade and plate thickness parameters from the component node, and extract the weld type and welding process requirements from the weld node.

[0053] The weld type, material grade, plate thickness parameter, and welding process requirements are organized into structured reasoning conditions, which carry the manufacturing semantic relationship between the weld and the base material.

[0054] For example, this steel structure detailed design model file is a digital model file used in the field of steel structure manufacturing to describe in detail the geometry, material properties, connection methods, and manufacturing process requirements of components. These files are typically generated by professional BIM (Building Information Modeling) or CAD (Computer-Aided Design) software, such as Tekla Structures and Revit. Their internal data structure is usually organized in the form of a node tree, capable of fully containing detailed information about components and their sub-components (such as welds). This model file serves as a digital twin of the manufacturing process, providing an authoritative and comprehensive data source for subsequent process parameter reasoning.

[0055] The node structure parsing refers to the process of reading, understanding, and converting the hierarchical data structure within the detailed design model file of the steel structure. Its function is to parse the raw data stored in a specific format within the model file into structured data objects that can be accessed and processed by the program, such as tree or graph structures. Implementation methods can include: using the API (Application Programming Interface) or SDK (Software Development Kit) provided by the model file provider for programmatic parsing. Alternatively, if the model file conforms to open standards (such as IFC), it can be parsed using a corresponding parser library to obtain detailed information about each component and weld in the model and their interrelationships.

[0056] The traversal of component nodes and their associated weld nodes refers to the systematic access to each component node in the model data structure after the node structure analysis is completed, and further access to all directly or indirectly associated weld nodes under that component node. This process aims to ensure that all weld information related to the component can be completely identified and processed. This can be achieved using graph traversal algorithms, such as Depth-First Search (DFS) or Breadth-First Search (BFS), starting from the root node and exploring downwards layer by layer until all leaf nodes (such as weld nodes) are visited, and their association with their parent nodes (component nodes) is recorded.

[0057] This component node is a data unit representing a single steel structural component (such as a beam, column, slab, connector, etc.) in the detailed design model file of the steel structure. Each component node typically contains the component's geometric information, material properties, surface treatment requirements, etc. Its function is to act as a carrier of the base material property information, providing the weld with contextual information about the base material it is connected to.

[0058] This weld node is a data unit representing a single weld connection in the detailed design model file of the steel structure. Each weld node typically includes the weld type (such as fillet weld or bevel weld), dimensions, welding method, welding material, and specific welding process requirements. Its function is to serve as a carrier of the weld's own attribute information, describing the inherent characteristics and processing requirements of the weld.

[0059] Extracting material grade and plate thickness parameters refers to accurately reading and obtaining the corresponding material grade (e.g., Q345B, Q235B) and plate thickness (e.g., 10mm, 12mm) values ​​from the located component nodes. These parameters are key factors affecting welding process selection and parameter settings, directly determining the weldability of the base material. This is typically achieved by calling the attribute access interface provided by the model resolver, directly retrieving these attribute values ​​from the component node object based on predefined attribute names or identifiers.

[0060] Extracting weld type and welding process requirements refers to accurately reading and obtaining the corresponding weld type (e.g., single-sided weld, double-sided weld, fillet weld, etc.) and specific welding process requirements (e.g., preheating temperature, interpass temperature, post-weld heat treatment, etc.) from the located weld nodes. These parameters are specific to the processing characteristics and quality requirements of the weld itself. The implementation method is also through calling the attribute access interface provided by the model parser, directly retrieving these attribute values ​​from the weld node object based on predefined attribute names or identifiers.

[0061] Organizing the weld type, material grade, plate thickness, and welding process requirements into structured reasoning conditions means integrating and encapsulating the parameters extracted from component nodes and weld nodes according to a preset data model or format. This organization method aims to combine previously scattered parameter information in a logically clear and machine-processable manner. This can be achieved by encapsulating these parameters into a JSON object, an XML document, or a custom data structure containing explicit field names and corresponding values.

[0062] Enabling the inference conditions to carry the manufacturing semantic association between the weld and the base material means explicitly establishing and preserving the logical relationship between weld parameters and the parameters of the base material components they are connected to when organizing the structured inference conditions. This association ensures that the system can accurately identify the base material attributes corresponding to a specific weld during subsequent inference, avoiding parameter confusion or mismatch. This can be achieved by embedding the material grade and plate thickness parameters of the component to which each weld data unit belongs within the structured inference conditions, or by establishing a reference relationship between the weld and the component through a unique identifier, thereby clearly defining its manufacturing attribution at the data level.

[0063] The above technical solution solves the problem of lost semantic association between welds and base materials when extracting inference conditions. By parsing the node structure of the steel structure detailed design model file and traversing the component nodes and their associated weld nodes, the system directly utilizes the node hierarchy structure inherent in the detailed design model. This eliminates the need for manual construction of the association between welds and components, saving the cost of additional association annotations and avoiding errors caused by manual association. Material grade and plate thickness parameters are extracted from component nodes, and weld type and welding process requirements are extracted from weld nodes. This follows the original data storage logic of the detailed design model, extracting parameters belonging to the component base material and parameters belonging to the weld itself from their respective nodes, avoiding errors caused by cross-node parameter extraction and ensuring the accuracy of each type of parameter extraction. Weld type, material grade, plate thickness parameters, and welding process requirements are organized into structured inference conditions, carrying the manufacturing semantic association between welds and base materials. This ensures that each inference condition corresponding to a weld carries the correct base material parameter association, completely solving the problem of mismatched weld and base material parameters. This provides qualified and accurate input for injecting the personalized constraint parameter values ​​derived from the welding process knowledge base based on the semantic reasoning of steel structure component manufacturing into the dynamic process knowledge graph. It ensures the correctness of the basic information for subsequent full-process data integration and the accuracy of the reasoning results, thereby enabling the process constraint rules to be instantiated into personalized, executable constraint benchmarks that truly meet actual manufacturing needs.

[0064] This application further proposes a method for organizing weld type, material grade, plate thickness parameters, and welding process requirements into structured reasoning conditions, specifically including: Based on the nested hierarchical relationship between component nodes and weld nodes obtained from node structure analysis, a manufacturing attribution association is established between weld nodes and component nodes. This aims to clarify the logical relationship between each weld and its parent component, preventing mismatches between weld information and component material parameters from the outset. For example, in one implementation, when performing node structure analysis on a steel structure detailed design model file, the system identifies the nesting relationship of weld nodes under component nodes and generates a reference or identifier for each weld node pointing to its direct parent component node, thus explicitly recording its manufacturing attribution. In another implementation, this attribution association can be implicitly expressed by assigning each weld node a unique code containing the identifier of its parent component, such as "component ID weld sequence number".

[0065] For each weld node, the weld type and welding process requirements extracted from the weld node are combined with the material grade and plate thickness parameters extracted from the component node to which the weld node belongs to form a weld-level inference condition. The purpose of this step is to integrate all the inference parameters required for a single weld to form a complete and independent inference unit. For example, a data structure can be created for each weld node, such as a struct or object, containing fields such as "weld type," "welding process requirements," "material grade," and "plate thickness parameters," and the values ​​extracted from the corresponding node can be filled into these fields to form a complete weld-level inference condition. Alternatively, a key-value pair approach can be used to encapsulate these parameters and their values ​​into a mapping table and associate it with the corresponding weld node, ensuring that the inference condition for each weld is self-consistent and independent.

[0066] All weld-level inference conditions are bound to the component identifier of the component entity, forming a structured inference condition set organized by component. This step aggregates the inference conditions of all welds belonging to the same component, forming a component-centric set, facilitating subsequent matching and inference of process rules on a component-by-component basis. For example, a hash table or dictionary can be constructed with the component identifier as the key and the list of all weld-level inference conditions under that component as the value. Alternatively, a hierarchical JSON or XML document can be generated, where the top-level node represents the component, and each element in the array represents a weld-level inference condition for a single weld.

[0067] Through the above technical solution, a structured reasoning condition set with clear attribution and regular structure is obtained by establishing associations hierarchically, combining parameters by unit, and summarizing and binding by component. This solves the problem of parameter mismatch and structural chaos that easily occurs in the original organization method, and provides accurate and regular input for the matching reasoning of welding process constraint parameters. Based on the nested hierarchical relationship between component nodes and weld nodes obtained from node structure analysis, a manufacturing attribution association between weld nodes and component nodes is established. The original node hierarchy relationship after the detailed design model analysis is used to establish the attribution, without the need for additional configuration of association relationships. This ensures the accuracy of the attribution relationship and saves additional processing costs, fundamentally avoiding the problem of mismatch between welds and their parent material components, and conforming to the original manufacturing semantic logic. For each weld node, the weld type and welding process requirements extracted from the weld node are combined with the material grade and plate thickness parameters of the component node to which the weld node belongs to form weld-level inference conditions. All necessary inference parameters are integrated with a single weld as the smallest unit, combining the weld's own process information with the corresponding material parameters of the parent component. This ensures that each weld's inference conditions are complete and independent, facilitating subsequent rule matching and preventing parameter confusion between different welds, thus guaranteeing the independence and integrity of the inference conditions. All weld-level inference conditions are bound to the component identifier of the component entity, forming a structured inference condition set organized by component. This integrates all weld inference conditions by component, matching the process logic of steel structure manufacturing, which involves process handling on a component-by-component basis. It also facilitates the mapping of inferred constraint parameters back to specific components and welds, enabling the injection and use of constraint parameters in subsequent processes and improving the overall workflow's synergy. This move improves the accuracy and efficiency of subsequent welding process rule matching and reasoning, and provides a solid data foundation for instantiating the process constraint rules deployed on the process execution association path in the dynamic process knowledge graph into executable constraint benchmarks.

[0068] This application further proposes a method of matching inference conditions with welding process rules stored in a welding process knowledge base to obtain constraint parameter values ​​for each process stage corresponding to the component entity. This process includes: matching the inference conditions with the welding process rules stored in the welding process knowledge base; and performing consistency checks on the constraint values ​​for the same process parameter among multiple matched welding process rules. When the consistency check identifies multiple welding process rules that give inconsistent constraint values ​​for the same process parameter, based on the weld information in the component entity's manufacturing semantic information that matches the inference conditions, the welding process rule with the highest fit to the weld information is selected from the multiple welding process rules. The constraint parameter values ​​in the selected welding process rule are extracted, grouped according to the process stage sequence defined by the process route in the component entity's manufacturing semantic information, and the grouped constraint parameter values ​​are bound to the corresponding process stages to form constraint parameter values ​​for each process stage corresponding to the component entity.

[0069] For example, the goal of matching the inference conditions with welding process rules stored in the welding process knowledge base is to identify all potentially applicable rules related to the semantics of the current component manufacturing from the vast knowledge base. This matching process can be implemented in several ways. For instance, it can employ pattern matching based on a rule engine, comparing each attribute in the inference conditions (such as weld type, material grade, plate thickness parameters, etc.) with the preset condition fields in the welding process rules one by one; any rule that satisfies all conditions is considered a match. Alternatively, it can leverage the query capabilities of the Semantic Web or knowledge graph, constructing specific query statements (such as SPARQL queries) to retrieve welding process rules in the knowledge graph that are semantically related to the component features described by the inference conditions.

[0070] After matching multiple welding process rules, it is necessary to perform consistency checks on the constraint values ​​for the same process parameter within these rules. The purpose of this step is to identify and address potential rule conflicts before applying the constraint values ​​to actual production. Consistency checks can manifest as cross-checking of numerical ranges. For example, if multiple rules specify different allowable ranges for "welding current," the system will check for overlaps or conflicts. If one rule specifies 180A-200A and another specifies 190A-210A, they are consistent within the 190A-200A range. However, if a third rule specifies 150A-170A, it is inconsistent with the first two. Furthermore, consistency checks can also be semantic-level conflict detection. For instance, if one rule requires "preheating is mandatory," while another rule states "this material does not require preheating," even without specific numerical values, this constitutes a semantic inconsistency.

[0071] When consistency checks identify multiple welding process rules that provide inconsistent constraint values ​​for the same process parameter, this application proposes to select the welding process rule with the highest fit to the weld information from multiple welding process rules based on weld information that matches the inference conditions in the manufacturing semantic information of the component entity. This selection mechanism aims to resolve rule conflicts and ensure that the selected rule best meets actual manufacturing needs. The selection process can be based on a fit scoring model, calculating a fit score for each conflicting rule. This score comprehensively considers the degree of feature matching in the rule that is not covered by the inference conditions but is highly related to the weld information (such as weld groove form, welding position, weld grade, etc.), and the rule with the highest score is selected. Another approach is to use a predefined decision tree or expert system. This system makes intelligent decisions in the set of conflicting rules based on the detailed attributes of the weld and preset priority rules, selecting the welding process rule that best matches the current weld situation.

[0072] Extract constraint parameter values ​​from the selected welding process rules. This step aims to obtain the specific process parameter constraints after conflict resolution and optimization filtering. Extraction can be achieved by directly parsing the structured data of the selected rules, identifying and extracting the defined process parameters (such as welding current, welding voltage, welding speed, preheating temperature, interpass temperature, etc.) and their corresponding values, ranges, or enumerated values. Alternatively, if the welding process rules exist in the form of executable code or functions, the calculated or returned constraint parameter values ​​can be obtained by calling the corresponding interfaces or methods.

[0073] The extracted constraint parameter values ​​are grouped according to the sequence of process stages defined in the manufacturing semantic information of the component entity. This step ensures that each constraint parameter can be accurately assigned to its applicable manufacturing process. Grouping can be based on the process route data associated with the component entity, which clarifies the various process stages from raw material processing to assembly and their logical order. The system will assign "preheating temperature" to the "pre-welding preparation" process, "welding current" to the "welding" process, and "post-weld heat treatment temperature" to the "post-weld treatment" process, etc., according to the nature of the parameter and the definition of the process route. Another grouping method is that if the constraint parameter value already has semantic tags for process stages in the welding process rules, the system can directly perform automatic classification and grouping based on these tags.

[0074] The grouped constraint parameter values ​​are bound to the corresponding process stages, forming constraint parameter values ​​for each process stage corresponding to the component entity. This binding operation aims to establish a clear association between parameters and processes, laying the foundation for subsequently injecting these constraints into a dynamic process knowledge graph. Binding can be achieved by constructing structured data objects, for example, creating a list containing multiple process stage objects, each of which contains one or more constraint parameters and their values. In a knowledge graph environment, this can be represented by establishing clear semantic relationships (such as "has process constraints") between component entities, process stage entities, and constraint parameter entities, thereby forming a traceable and queryable constraint information network in the knowledge graph.

[0075] The above technical solution resolves the conflict issue arising from inconsistent constraint values ​​for the same process parameter across multiple rules when applying rules from the welding process knowledge base to specific components. By introducing a consistency verification mechanism, potential rule conflicts can be detected promptly, preventing inconsistent constraint values ​​from being passed on to subsequent stages. Furthermore, by selecting the rule with the highest fit from conflicting rules based on weld information matching the inference conditions within the component entity's manufacturing semantic information, the chosen constraint value not only conforms to general conditions but also accurately matches the actual welding manufacturing requirements of the current component, thereby improving the accuracy and applicability of the constraint benchmark. In addition, the selected constraint parameter values ​​are grouped and bound according to the sequence of process stages defined in the process route within the component entity's manufacturing semantic information. This ensures that each constraint parameter accurately corresponds to its applicable manufacturing process. This not only facilitates subsequent constraint injection along the process execution path but also guarantees the accuracy of parameter correspondences, aligning with the process-driven manufacturing characteristics of steel structure orders. This provides an accurate and conflict-free numerical basis for generating executable constraint benchmarks, thereby improving the accuracy and reliability of process parameter identification and design change processing.

[0076] This application further proposes a method for identifying process parameter adjustment behavior from timing data of steel structure welding processes based on this executable constraint benchmark. See [link to relevant documentation]. Figure 3 Specifically, it includes: 301. Extract the constraint intervals of each process parameter from the executable constraint benchmark, and mark the deviation status of the actual values ​​of the process parameters at each acquisition time in the time series data based on the constraint intervals to obtain the time series data carrying the deviation direction mark.

[0077] 302. Perform state flip detection on the timing data carrying the deviation direction mark. When it is detected that the deviation direction mark flips from the first deviation direction to the second deviation direction and the duration of the second deviation direction after the flip exceeds the preset minimum duration, it is determined that a process parameter adjustment behavior has occurred.

[0078] 303. The steady-state values ​​of the process parameters corresponding to the deviation state before the flip, the steady-state values ​​of the process parameters corresponding to the deviation state after the flip, and the time when the flip occurred are used as the identification results.

[0079] For example, extracting the constraint ranges of each process parameter from this executable constraint benchmark aims to provide clear judgment boundaries for subsequent deviations of actual process parameter values ​​from state markers. This executable constraint benchmark is a personalized, quantifiable range of process parameters generated for specific components and processes. In one implementation, the system can predefine constraint range data structures for various process parameters (e.g., welding current, voltage, wire feed speed, preheating temperature, etc.). When the executable constraint benchmark is instantiated, these structured constraint range values ​​are directly filled into the corresponding fields for the extraction module to read directly. In another implementation, the executable constraint benchmark can be a script or function containing logical judgment rules. During extraction, by executing this script or function, the upper and lower limits of each process parameter are dynamically calculated and returned based on the specific conditions of the current process and component, thus forming the constraint range.

[0080] Based on the constraint interval, deviation status labels are applied to the actual values ​​of process parameters at each acquisition time in the time series data, resulting in time series data with deviation direction labels. This aims to transform the original, continuous process parameter time series data into discrete state sequences with clear deviation semantics, providing standardized input for subsequent state reversal detection. By labeling the deviation status and direction, it is possible to intuitively reflect whether the process parameters are within the allowable range and the trend of deviation. In one implementation, for each acquisition time, the actual value of the process parameter is compared with the extracted constraint interval. If the actual value is within the interval, it is labeled "within constraint." If the actual value is higher than the upper limit, it is labeled "upward deviation." If the actual value is lower than the lower limit, it is labeled "downward deviation." A "positive deviation" label is added to "upward deviation," a "negative deviation" label is added to "downward deviation," and a "no deviation" label is added to "within constraint." In another implementation, fuzzy logic or interval membership functions can be used to evaluate the relationship between the actual value and the constraint interval. For example, a core compliance interval and a tolerance deviation interval can be defined. When the actual value is within the core compliance range, it is marked as "fully compliant". When it is within the tolerance deviation range but exceeds the core compliance range, it is marked as "slight positive deviation" or "slight negative deviation" depending on the direction of the deviation. When it exceeds the tolerance deviation range, it is marked as "serious positive deviation" or "serious negative deviation".

[0081] State reversal detection of time-series data carrying deviation direction markers is the core mechanism for identifying process parameter adjustment behavior. It analyzes the continuous changes in deviation direction markers to determine whether a transition from one stable state to another exists, thus distinguishing between random fluctuations and genuine adjustments. One implementation method can use a sliding window or event sequence analysis. For example, a fixed-size sliding window is defined, and the distribution of deviation direction markers is statistically analyzed within the window. When the dominant deviation direction within the window changes, and this change persists in subsequent windows, a state reversal is considered to have occurred. Another implementation method can use a rule-based state machine model. Different states are defined (e.g., "within stable constraints," "stable upward deviation," "stable downward deviation," etc.), along with the transition conditions between states. When the deviation direction marker sequence satisfies the condition for transitioning from one stable state to another, a state reversal event is triggered.

[0082] When a deviation direction marker is detected to have flipped from a first deviation direction to a second deviation direction, and the duration of this second deviation direction exceeds a preset minimum duration, a process parameter adjustment is determined to have occurred. This condition ensures that the identified "adjustment behavior" is stable and intentional, rather than a transient, random fluctuation. By introducing a "preset minimum duration," transient interference can be effectively filtered out, improving the accuracy and reliability of adjustment behavior identification. In one implementation, during the state flip detection process, once a change in the deviation direction marker is detected, the system starts a timer to record the duration of the new deviation direction marker. Only when this duration exceeds the preset minimum duration (e.g., 5 minutes, 10 minutes, or other values ​​set according to process characteristics) is it confirmed as a valid process parameter adjustment. In another implementation, statistical methods can be used, for example, after detecting a deviation direction flip, a statistical significance test is performed on the flipped data segment to determine the stability of the new deviation direction. If the new deviation direction is statistically persistent and its duration meets the minimum duration requirement, the adjustment behavior is confirmed.

[0083] The identification results are the steady-state values ​​of the process parameters corresponding to the deviation state before the reversal, the steady-state values ​​of the process parameters corresponding to the deviation state after the reversal, and the time when the state reversal occurred. The aim is to structure and output the key information of the identified adjustment behavior, providing a necessary and accurate data foundation for subsequent adjustment record generation, compliance retrospective, and impact analysis. In one implementation, the steady-state value before the reversal can be obtained by averaging, medianing, or modulating the actual values ​​of the process parameters over a stable period before the reversal. The steady-state value after the reversal is obtained by similar calculations over the sustained period after the reversal. The time when the state reversal occurs can be recorded as the time point when the deviation direction marker first stabilizes. In another implementation, more complex signal processing techniques can be used to determine the steady-state value; for example, using a low-pass filter to smooth the data and then identifying the plateau period. The reversal time can be defined as the inflection point of the smoothed curve or the time point when the derivative changes. This information is encapsulated into a structured data object containing fields such as the adjustment parameter name, the steady-state value before adjustment, the steady-state value after adjustment, and the time when the adjustment occurred.

[0084] To address the issue of random fluctuations in welding process parameter time-series data, the above technical solution proposes a method combining deviation marking and stable flip detection to accurately identify process parameter adjustment behavior. The constraint ranges for each process parameter are extracted from the executable constraint benchmark. Based on these constraint ranges, deviation status markings are applied to the actual values ​​of the process parameters at each acquisition time in the time-series data, resulting in time-series data carrying deviation direction markings. This step uses personalized executable constraints generated for the current steel structure order components as the judgment basis, rather than general constraint standards, ensuring that the deviation status markings conform to the actual process requirements of the current components. Simultaneously, a clear deviation direction is added to each acquisition time, providing a clear and unified judgment basis for subsequent flip detection, effectively avoiding the problem of inconsistent judgment standards in subsequent detection. State flip detection is performed on the time-series data carrying deviation direction markings. A process parameter adjustment behavior is determined only when the deviation direction marking flips from the first deviation direction to the second deviation direction, and the duration of the second deviation direction after the flip exceeds the preset minimum duration. This step combines two conditions—the direction of deviation reversal and the duration of maintenance—to effectively filter out temporary changes in deviation direction caused by random fluctuations. Only when the adjusted parameters stably maintain the new deviation state is it considered an adjustment. This mechanism avoids mistakenly identifying temporary disturbances as adjustments, improving the accuracy of the identification results. The steady-state values ​​of the process parameters corresponding to the deviation state before the reversal, the steady-state values ​​of the process parameters corresponding to the deviation state after the reversal, and the time of the state reversal are used as the identification results. The identification results output by this step fully cover all the core information required for the adjustment behavior, providing accurate basic data for subsequent processes such as generating adjustment records, compliance retrospectives, and determining the scope of impact, thereby ensuring the continuity and reliability of data throughout the entire manufacturing process.

[0085] This application further proposes a method for marking the deviation state of the actual values ​​of process parameters at each acquisition time in the time series data based on the constraint interval, thereby obtaining time series data carrying deviation direction markers. The specific steps include: The actual value of the process parameter is compared with the constraint range to determine whether the deviation at the acquisition time is within the constraint, out of bounds upward or downward, and a corresponding deviation direction mark is added to the acquisition time.

[0086] Identify the transition period in the time series data where the deviation direction marker flips, and match the change trajectory of the actual value of the process parameter during the transition period with the adjustment behavior feature pattern defined in the process deviation adjustment rule.

[0087] The deviation direction markers within the successfully matched transition period are corrected according to the adjustment behavior feature pattern and then output. The deviation direction markers within the unsuccessfully matched transition period are output according to the original comparison results, forming the time series data carrying the deviation direction markers.

[0088] The process involves comparing the actual value of the process parameter with the constraint range to determine whether the deviation at that acquisition moment is within the constraint, upward or downward, and attaching a corresponding deviation direction label to that acquisition moment. This aims to make a preliminary compliance judgment on each acquired actual value of the process parameter and assign it a label indicating the direction of deviation. This lays the foundation for subsequent refined analysis. In one implementation, the system can acquire real-time or historical actual values ​​of the process parameter and extract upper and lower limits from a preset constraint range. Through direct numerical comparison, if the actual value is less than the lower limit, it is marked as "downward out of bounds." If the actual value is greater than the upper limit, it is marked as "upward out of bounds." If the actual value is between the lower and upper limits (including the boundary), it is marked as "within the constraint." A corresponding deviation direction label is attached to each acquisition moment, for example, using an enumerated value or a Boolean flag. In another implementation, considering measurement errors and fluctuations in actual production, the system can introduce a small tolerance threshold. When the difference between the actual value of the process parameter and the boundary value of the constraint range is less than this threshold, it can still be considered "within the constraint." For example, if the actual value slightly exceeds the upper limit but is still within the tolerance range, it can still be marked as "within the constraint" to avoid overly sensitive deviation markings. The deviation direction marking can be represented numerically, such as -1 for downward deviation, 0 for within the constraint, and 1 for upward deviation.

[0089] The system identifies transition periods in the time series data where the deviation direction marker flips. It then matches the trajectory of the actual value change of the process parameter within this transition period with the adjustment behavior feature patterns defined in the process deviation adjustment rules. The aim is to accurately identify the intervals where process parameters are adjusted and to use predefined behavior patterns to verify whether these changes are genuine process adjustments rather than random fluctuations. This is crucial for filtering out noise and improving the accuracy of adjustment behavior identification. In one implementation, the system can use a sliding window technique to traverse the time series data carrying the deviation direction marker. When the deviation direction marker changes within the window, it is identified as a candidate transition period. For this candidate transition period, the sequence of actual process parameter values ​​is extracted and matched with the adjustment behavior feature patterns pre-stored in the process deviation adjustment rules. These feature patterns can include the slope, duration, and magnitude of parameter value changes. For example, a typical adjustment behavior is characterized by a parameter value rapidly rising or falling within a short period and then stabilizing at a new level. The matching algorithm can employ Dynamic Time Warping (DTW) or a feature vector-based classifier. In another implementation, the system can build a rule engine that continuously monitors changes in the deviation direction marker. An event is triggered when a deviation direction marker is detected to flip from one state (e.g., "within constraints") to another state (e.g., "upward out of bounds"). This event activates predefined process deviation adjustment rules, which contain descriptive patterns of the actual value changes in process parameters during the transition period. For example, a rule might be defined as "If a parameter changes from value A to value B within X seconds, and the rate of change exceeds Y, it is considered an adjustment action." The matching process determines whether the actual data meets these rule conditions.

[0090] The deviation direction markers for successfully matched transition periods are corrected according to the adjustment behavior characteristic pattern and then output. For unsuccessfully matched transition periods, the deviation direction markers are output according to the original comparison results, forming time-series data carrying deviation direction markers. This aims to refine the deviation direction of the initial markers, ensuring that the output time-series data accurately reflects the actual process parameter adjustment behavior. This avoids erroneous markers caused by transition fluctuations while preserving the authenticity of the original data. In one implementation, for successfully matched transition periods, the system uniformly corrects the deviation direction markers for all acquisition times within that period based on the actual deviation trend indicated by the matched adjustment behavior characteristic pattern (e.g., a smooth transition from "within constraints" to "upward overflow"). For example, if the pattern indicates that the period is an adjustment from normal to slightly higher, then all abnormal fluctuation points marked as "within constraints" or "downward overflow" within that period will be corrected to a transition state of "upward overflow" or "within constraints." For unsuccessfully matched transition periods, the deviation direction markers within them remain consistent with the original comparison results and are not modified. In another implementation, the system can maintain a state machine with states including "within constraints," "upward out of bounds," "downward out of bounds," and "adjusting." When a transition period is identified and a pattern of adjustment behavior is successfully matched, the state machine enters the "adjusting" state and, according to the pattern's indication, uniformly corrects the deviation direction markers within that period to the adjusted target state (e.g., if the pattern indication is stable at "upward out of bounds," then all markers within that period are corrected to "upward out of bounds"). When the match fails, the state machine does not change its current state and outputs the original deviation direction markers. All corrected or unchanged deviation direction markers together constitute the timing data carrying the deviation direction markers.

[0091] The above technical solution addresses the issue of mislabeling caused by transient fluctuations when directly comparing deviation markers. By first initially marking the deviation markers and then specifically correcting them for transition periods, the accuracy of the deviation direction markers is improved, providing a reliable foundation for subsequent accurate identification of process parameter adjustment behavior. For example, comparing the actual values ​​of process parameters with the constraint intervals determines the deviation state at the time of acquisition and adds corresponding deviation direction markers. This initial marking step completes the preliminary marking, providing an initial basis for subsequent corrections while preserving the true information of the original acquired data. The solution identifies transition periods in the time series data where the deviation direction markers flip, and matches the trajectory of the actual values ​​of process parameters within these transition periods with the adjustment behavior characteristic patterns defined in the process deviation adjustment rules. This approach only performs matching verification for transition periods prone to marking errors, eliminating the need to verify all time series data points, effectively improving processing efficiency. Matching based on predefined adjustment behavior characteristic patterns that conform to real process adjustment rules leverages domain knowledge to determine the true trend of change during transition periods, filtering out interference from transient fluctuations on the marking results. The deviation direction markers for successfully matched transition periods are corrected according to the adjustment behavior characteristic pattern before being output, while the deviation direction markers for unsuccessfully matched transition periods are output as the original comparison results. This correction mechanism can eliminate erroneous markers caused by transition fluctuations, while retaining the original results for unsuccessfully matched data, avoiding over-correction that could compromise the authenticity of the original data. The resulting time-series data carrying deviation direction markers retains the true information of the original acquired data while correcting errors caused by transition fluctuations, providing an accurate and reliable data foundation for subsequent accurate identification of process parameter adjustment behavior and ensuring the accuracy of data flow throughout the entire manufacturing process.

[0092] This application further proposes a step for detecting state flips in the aforementioned time-series data carrying deviation direction markers, including: scanning along the time axis of the time-series data carrying deviation direction markers to locate candidate flip points where the deviation direction markers have changed. For each candidate flip point, the deviation direction of the steady-state segment before the flip, the deviation direction of the steady-state segment after the flip, and the duration of the steady-state segment after the flip are extracted. The steady-state segment before the flip and the steady-state segment after the flip are the time intervals in which the deviation direction marker remains continuous and consistent. When the deviation direction of the steady-state segment before the flip is different from the deviation direction of the steady-state segment after the flip, and the duration exceeds a preset minimum maintenance duration, a valid state flip is confirmed to have occurred at the candidate flip point. The deviation state of the steady-state segment before the flip, the deviation state of the steady-state segment after the flip, and the time corresponding to the candidate flip point are used as the output of the state flip detection.

[0093] For example, scanning along the timeline of the timing data carrying deviation direction markers locates candidate flip points where the deviation direction markers have changed, aiming to comprehensively and thoroughly identify all potential process parameter state change points in the timing data. This scanning process can be implemented in several ways. For instance, the timing data can be traversed point by point, comparing the deviation direction markers of adjacent data points; once a change in the marker is detected, that point is marked as a candidate flip point. Another implementation method is to use sliding window technology, moving a fixed-size window along the data stream and detecting pattern changes in the deviation direction markers within the window; when a preset flip pattern is detected, the center point of the window is determined as a candidate flip point. In this way, the system can ensure that all moments of process parameter adjustment are taken into account, laying the foundation for accurate subsequent judgments.

[0094] For each candidate flip point, the deviation direction of the steady-state segment before the flip, the deviation direction of the steady-state segment after the flip, and the duration of the steady-state segment after the flip are extracted. The steady-state segment before and after the flip constitute the time interval during which the deviation direction marker remains continuous and consistent. The core of this step lies in clarifying the definition of a "steady-state segment," that is, the time interval during which the deviation direction marker remains continuous and consistent. In practice, the system traces data points backward from the candidate flip point until the deviation direction marker changes or the starting point of the time series data is reached, thereby determining the range and deviation direction of the steady-state segment before the flip. Similarly, the system traces data points backward until the deviation direction marker changes or the ending point of the time series data is reached, thereby determining the range and deviation direction of the steady-state segment after the flip and calculating the duration of the steady-state segment. For example, a threshold-based continuity detection algorithm can be used; when the deviation direction markers of N consecutive data points are consistent, a steady-state segment is considered to have been formed. In this way, it is possible to effectively distinguish between short-term parameter fluctuations and continuous state changes, providing a clear and accurate basis for subsequent validity judgments.

[0095] When the deviation direction of the steady-state segment before the flip is different from the deviation direction of the steady-state segment after the flip, and the duration exceeds the preset minimum maintenance time, a valid state flip is confirmed at the candidate flip point. The deviation state of the steady-state segment before the flip, the deviation state of the steady-state segment after the flip, and the time corresponding to the candidate flip point are used as the output of the state flip detection. This judgment mechanism combines the substantial change in deviation direction with the stability of state continuity to eliminate random interference. The system compares the deviation directions of the steady-state segment before and after the flip. If they are different, it indicates that the process parameter has indeed changed from one deviation state to another. The system compares the duration of the steady-state segment after the flip with the preset minimum maintenance time. The preset minimum maintenance time can be determined based on actual production experience, process specifications, or through historical data statistical analysis, for example, set to 5 minutes, 10 minutes, or longer, to ensure that only a continuous and stable state change is considered a valid adjustment. Only when both conditions are met simultaneously does the system confirm that a valid process parameter adjustment has occurred. The system encapsulates the detailed information of this valid state flip, including the deviation state before the flip, the deviation state after the flip, and the exact time when the flip occurred, and uses it as the output of the state flip detection for use in subsequent processes.

[0096] The above technical solution provides a standardized state reversal detection process that effectively eliminates interference from accidental fluctuations during process parameter acquisition and accurately identifies truly effective process parameter adjustments. Scanning along the timeline of time-series data carrying deviation direction markers ensures comprehensive coverage of all potential state change points, avoiding missed detections. For each candidate reversal point, the deviation direction of the steady-state segment before and after the reversal and the duration of the steady-state segment after the reversal are extracted, and the definition of the steady-state segment is clearly defined, enabling the system to clearly distinguish between temporary fluctuations and persistent state changes, providing an accurate basis for judging effective adjustments. By determining whether the deviation direction before and after the reversal is different, and combining this with whether the duration after the reversal exceeds the preset minimum maintenance duration, this application can effectively filter out short-lived, non-substantial parameter fluctuations, recognizing only persistent state changes that meet the conditions as effective adjustments. This dual verification mechanism avoids misjudging accidental fluctuations as adjustment behavior and ensures that truly effective adjustments can be accurately identified. The output includes the identification results of the deviation state before and after the reversal and the reversal time, providing reliable and high-quality input information for subsequently generating accurate adjustment records and responding to design changes, improving the accuracy and reliability of process parameter adjustment identification.

[0097] This application further proposes converting the identification results into adjustment records that are automatically verified by process deviation adjustment rules, see [link to relevant documentation]. Figure 4 The specific steps include: 401. Extract the adjustment parameter name, steady-state value before adjustment, steady-state value after adjustment, and adjustment time from the identification results, and generate the initial adjustment record by combining the adjustment basis description and transmission constraint description corresponding to the adjustment parameter name.

[0098] 402. Trigger the process deviation adjustment rule to perform an integrity check on the initial adjustment record, and check whether the adjustment parameter name, steady-state value before adjustment, steady-state value after adjustment, adjustment time, adjustment basis description and transmission constraint description in the initial adjustment record have been filled in.

[0099] 403. After the integrity check passes, the process deviation adjustment rules are triggered to perform compliance check on the initial adjustment record. The check is made to see if the adjustment range of the steady-state value after adjustment relative to the steady-state value before adjustment exceeds the allowable adjustment range defined in the process deviation adjustment rules, and an adjustment record with a compliance mark is generated.

[0100] For example, the system extracts the adjustment parameter name, the steady-state value before adjustment, the steady-state value after adjustment, and the time of adjustment from the identification results. Combined with the adjustment basis description and transmission constraint description corresponding to the adjustment parameter name, an initial adjustment record is generated. This step aims to structure the core information of the previously identified process parameter adjustment behavior and supplement necessary contextual information to form a preliminary, traceable adjustment record. One implementation method is that after receiving the identification results of the process parameter adjustment behavior, the system directly maps the fields in the identification results (such as parameter ID, value before adjustment, value after adjustment, and timestamp) to the corresponding fields in the initial adjustment record using preset data mapping rules. The system can provide a user interface or preset templates to guide process engineers to input or select the adjustment basis description (e.g., due to material batch changes, environmental temperature fluctuations, etc.) and transmission constraint description (e.g., the impact on subsequent heat treatment, dimensional accuracy, etc.). These descriptions can be stored as free text or selected from predefined options. Another approach is for the system to use Natural Language Processing (NLP) technology to automatically extract key information regarding adjustment justifications and transmission constraints from unstructured text descriptions (such as logs and reports) submitted by process engineers, and then structure and populate this information into the initial adjustment record. The system can integrate a historical adjustment data analysis module to intelligently recommend adjustment justifications and transmission constraints based on the adjustment parameter names and adjustment ranges, for process engineers to confirm or modify.

[0101] The process deviation adjustment rules trigger an integrity check on the initial adjustment record. This check verifies that the adjustment parameter name, pre-adjustment steady-state value, post-adjustment steady-state value, adjustment time, adjustment basis description, and propagation constraint description are all filled in. This step ensures that the initial adjustment record contains all necessary information fields to meet the needs of subsequent data analysis, traceability, and compliance assessment. Integrity verification is the first line of defense for ensuring data quality. One implementation is that the system maintains a configurable integrity verification rule set, which defines a list of required fields for each type of adjustment parameter. When an initial adjustment record is generated, the system automatically iterates through the fields of the record and compares them with the rule set. If any required field is found to be empty or formatted incorrectly (e.g., a numeric field contains non-numeric characters), the verification fails, and the user is prompted to supplement or correct it. Another implementation is that the system uses a metadata-based verification mechanism. Each adjustment record field is associated with metadata indicating whether it is a required field and its data type, length, and other constraints. When the initial adjustment record is submitted, the system automatically performs verification based on this metadata. For unstructured "Adjustment Basis Explanation" and "Transmission Constraint Explanation", the system can check whether they are empty or whether they have reached the preset minimum number of characters to ensure that their content has a certain degree of substance.

[0102] After the integrity check passes, the process deviation adjustment rules are triggered to perform a compliance check on the initial adjustment record. This checks whether the adjustment range of the steady-state value after adjustment relative to the steady-state value before adjustment exceeds the allowable adjustment range defined in the process deviation adjustment rules, generating an adjustment record with a compliance flag. This step aims to assess the rationality and standardization of process parameter adjustments, ensuring that on-site adjustments are within the preset process safety and quality control range, and providing a clear compliance status indication for subsequent decisions. One implementation is that the process deviation adjustment rules preset allowable adjustment ranges based on percentages or absolute values ​​for each process parameter. For example, the allowable adjustment range for welding current is ±5% or ±20A. After the integrity check passes, the system calculates the actual adjustment range between the steady-state value after adjustment and the steady-state value before adjustment, and compares it with the allowable adjustment range for the corresponding parameter. If the actual adjustment range exceeds the range, the adjustment record is marked as "non-compliant"; otherwise, it is marked as "compliant." Another implementation is that the allowable adjustment range is dynamic, calculated or queried in real time based on manufacturing semantic information such as the component's material, plate thickness, and weld type. For example, for high-strength steel, the allowable adjustment range for welding current is narrower. When performing compliance checks, the system queries or calculates the dynamic allowable adjustment range under the current working conditions based on the component information in the initial adjustment record, and then compares it. The verification results are also attached to the adjustment record in the form of compliance tags, such as "compliant", "minor deviation (requires approval)" and "serious deviation (prohibited)".

[0103] The above technical solution addresses the issues of non-standard process generation procedures and missing verification logic in related technologies, leading to unqualified and untraceable records. For example, core information such as the adjustment parameter name, steady-state value before adjustment, steady-state value after adjustment, and the time of adjustment are extracted from the identification results. Combined with the adjustment basis and transmission constraint descriptions corresponding to the adjustment parameter name, an initial adjustment record is generated. This makes the previously implicit on-site adjustment behavior explicit and structured, filling the missing links in the entire manufacturing process data and laying the foundation for subsequent data integration. By triggering process deviation adjustment rules in stages for integrity and compliance verification, this application ensures the information integrity and process standardization of the adjustment records. Integrity verification efficiently screens and intercepts unqualified records with missing information, avoiding invalid subsequent processing and reducing unnecessary computational resource consumption. Compliance verification determines whether the adjustment range is within the allowable range, ensuring the rationality of on-site adjustment behavior. The generated adjustment records with compliance tags are not only comprehensive and compliant with regulations, but their compliance status is also clear at a glance. This greatly improves the efficiency and accuracy of subsequent compliance retrospectives in the event of component design changes, making process adjustments no longer untraceable breakpoints relative to design changes, thereby truly realizing data connectivity throughout the entire manufacturing process.

[0104] This application further proposes a step for triggering the process deviation adjustment rule to perform integrity verification on the initial adjustment record, including: extracting an integrity verification template corresponding to the adjustment parameter name from the process deviation adjustment rule; the integrity verification template defines a set of required fields associated with the adjustment parameter name, data format constraints for each required field, and logical consistency constraints between the required fields. Based on the integrity verification template, each field in the required field set of the initial adjustment record is sequentially verified to ensure it is filled and conforms to the data format constraints. Once all required fields pass verification, the semantic consistency between different required fields in the initial adjustment record is cross-validated based on the logical consistency constraints. This semantic consistency includes the consistency between the pre-adjustment steady-state value and the direction indicated by the adjustment basis description, and the matching consistency between the post-adjustment steady-state value and the transmission constraint description.

[0105] For example, the process deviation adjustment rule refers to a predefined set of criteria, conditions, and logic used to guide and regulate the adjustment of process parameters. It can be stored in a dedicated rule engine, database, or knowledge base, serving as the basis for automated verification and decision-making by the system. For instance, these rules can exist as XML files, JSON configurations, or ontology-based semantic rules, containing information such as the adjustment range of different process parameters, adjustment basis requirements, and transmission constraints. Another implementation method is to encode these rules into program modules or scripts, which are called and executed when verification is required. These modules can dynamically load and apply the corresponding verification logic based on the input parameters. The adjustment parameter name is a string or code used to uniquely identify the adjusted process parameter. For example, in a welding process, the adjustment parameter name could be "welding current," "welding voltage," "wire feed speed," or "preheating temperature." Its function is to act as an index, enabling the system to accurately retrieve the corresponding verification logic and template from the process deviation adjustment rules based on the specific adjustment parameter.

[0106] This integrity verification template is a customized verification specification for specific adjustment parameter names. Its purpose is to provide a structured and parameterized basis for the integrity verification of initial adjustment records. This template can be defined in various forms. For example, it can be a JSON Schema file, which details which fields must be included in the adjustment record for a specific adjustment parameter (such as "welding current") (e.g., "steady-state value before adjustment", "steady-state value after adjustment", "adjustment basis description", etc.), the data type (e.g., numeric, string), value range, length limit, and other format requirements for each field, as well as the logical association rules between different fields (e.g., "steady-state value before adjustment" and "adjustment basis description"). Another implementation method is that the template can be a database table structure definition, which includes field names, data types, NOT NULL constraints, foreign key constraints, etc., supplemented by stored procedures or triggers to define the logical consistency verification rules between fields. The set of required fields clarifies the key information items that must exist in the initial adjustment record. For example, for the adjustment of welding current, "steady-state value before adjustment", "steady-state value after adjustment", and "adjustment basis description" must be filled in. The data format constraint specifies the concrete form of these field contents. For example, the "steady-state value before adjustment" must be a floating-point number within a specific range. The "Explanation of Adjustment Basis" must be a string with a length not exceeding 200 characters. The logical consistency constraint further defines the inherent correlation between different field values. For instance, if the "Explanation of Adjustment Basis" mentions "material batch changes," then the "steady-state value before adjustment" should be consistent with the original process parameters of that batch of materials. These constraints collectively ensure the basic quality and internal logical consistency of the adjustment records.

[0107] During the verification process, based on the integrity verification template, each field in the required field set of the initial adjustment record is sequentially verified to ensure it is filled and conforms to the data format constraints. This aims to perform a preliminary, basic integrity check on the initial adjustment record. Its purpose is to quickly filter out records that clearly do not meet the specifications, such as those lacking key information or with incorrect information format. This can be achieved by writing a verification function in a programming language (such as Python or Java) to iterate through each field of the initial adjustment record, check for null values, and use regular expressions, type conversions, or predefined data range checks to verify that the field content conforms to the data type, length, and numerical range format requirements specified in the template. Another approach is to utilize database table structure constraints (such as NOT NULL constraints and CHECK constraints) and data type definitions to automatically perform preliminary verification during data insertion or updates.

[0108] Once all required fields pass validation, the semantic consistency between different required fields in the initial adjustment record is cross-validated based on the logical consistency constraint. This step, after the basic validation passes, further examines the internal logical rationality of the adjustment record. Its purpose is to identify records that appear complete on the surface but contain contradictions or irrationalities. This can be achieved by executing predefined logical consistency rules through a rule engine. For example, checking whether the "steady-state value before adjustment" matches the original process conditions mentioned in the "adjustment basis description" involves querying historical data or a knowledge base. Another example is verifying whether the "steady-state value after adjustment" matches the constraints of downstream processes or related parameters described in the "transmission constraint description," which requires complex logical judgments or numerical calculations. The consistency between the steady-state value before adjustment and the adjustment basis description refers to whether there is a logical correspondence between the stable values ​​of the process parameters before adjustment and the description of the reason for this adjustment. For example, if the adjustment basis description is "due to the high hardness of material batch A, the welding current needs to be increased," then the "steady-state value before adjustment" should be the original welding current setting value for material batch A. The implementation can be achieved by extracting key entities and relationships from the "Adjustment Basis Description" using Natural Language Processing (NLP) technology and comparing them with the "Steady-State Value Before Adjustment," or by using preset keyword matching and rule chains for judgment. The consistency between the adjusted steady-state value and the conduction constraint description refers to whether the stable value of the adjusted process parameter meets the constraint requirements for its conduction influence on subsequent processes or related parameters. For example, if the "Conduction Constraint Description" states that "after the welding current increases, it is necessary to ensure that the heat input does not exceed a certain threshold," then the calculated heat input result corresponding to the "Adjusted Steady-State Value" should meet that threshold. This can be achieved by using a computational model or simulation tool to predict the impact on related parameters based on the "Adjusted Steady-State Value" and compare it with the constraint conditions defined in the "Conduction Constraint Description."

[0109] The above technical solution addresses the lack of specificity and depth in general verification methods. By extracting integrity verification templates corresponding to the names of adjustment parameters from process deviation adjustment rules, the verification rules are customized and parameterized. This ensures that records of different process adjustment parameters can be verified according to their specific requirements, avoiding inaccuracies caused by general rules. Based on the integrity verification template, each field in the required field set of the initial adjustment record is sequentially verified to ensure it is filled and conforms to data format constraints. This layered verification mechanism can quickly identify and exclude records that are fundamentally unqualified, improving verification efficiency. Furthermore, once the set of required fields has passed verification, the semantic consistency between different required fields is cross-verified based on logical consistency constraints. In particular, the consistency between the pre-adjustment steady-state value and the adjustment basis description, and the matching consistency between the post-adjustment steady-state value and the transmission constraint description are verified. This allows for the in-depth discovery and correction of problems that appear complete but have logical contradictions, thus ensuring the integrity, format correctness, and semantic consistency of the initial adjustment record. This provides a reliable and accurate data foundation for subsequent compliance verification and retrospective analysis after design changes, improving the accuracy and reliability of data integration throughout the entire manufacturing process.

[0110] This application further proposes a compliance verification method for the initial adjustment record triggered by the process deviation adjustment rule, including: extracting the allowable adjustment range corresponding to the adjustment parameter name from the process deviation adjustment rule, wherein the allowable adjustment range is defined with the pre-adjustment steady-state value as the reference center and the upper and lower floating ratios as boundaries; calculating the actual adjustment magnitude of the post-adjustment steady-state value relative to the pre-adjustment steady-state value, and comparing the actual adjustment magnitude with the allowable adjustment range; when the actual adjustment magnitude does not exceed the allowable adjustment range, the initial adjustment record is determined to be compliant, and it is checked whether a transmission constraint condition is defined in the process deviation adjustment rule for the adjustment parameter name. If it is defined and the actual adjustment magnitude triggers the transmission constraint condition, a transmission adjustment mark is added to the adjustment record.

[0111] For example, the process deviation adjustment rule refers to a predefined set of specifications used to guide and constrain the adjustment behavior of process parameters. These rules can be stored in a database, configuration file, or dedicated rule engine, containing adjustment restrictions, verification logic, and definitions of the resulting transmission effects for various process parameters. The adjustment parameter name identifies the specific process parameter being adjusted, such as welding current, welding voltage, wire feed speed, preheating temperature, etc. Through this name, the system can locate the specific definition of the parameter in the process deviation adjustment rule. The allowable adjustment range refers to the range within which a process parameter is allowed to change without violating the process specifications. The pre-adjustment steady-state value refers to the stable value of the parameter before the process parameter adjustment behavior occurs; this value is the benchmark for calculating the adjustment magnitude and defining the allowable adjustment range. The allowable adjustment range is centered on the pre-adjustment steady-state value, with upper and lower floating percentages defining the boundaries. This definition method makes the allowable adjustment range dynamically adaptable. For example, the system can dynamically calculate the specific upper and lower limit values ​​based on the pre-adjustment steady-state value, combined with preset percentage floating percentages (e.g., upper floating percentage of +5%, lower floating percentage of -3%). Alternatively, the allowable adjustment range can be determined by looking up a table or using a function based on expert experience. The table or function takes the steady-state value before adjustment and the name of the adjustment parameter as input, and outputs the specific upper and lower limits, or directly outputs the floating ratio.

[0112] After determining the allowable adjustment range, it is necessary to calculate the actual adjustment magnitude of the adjusted steady-state value relative to the original steady-state value. The adjusted steady-state value refers to the new stable value reached by the parameter after the adjustment is completed. The actual adjustment magnitude is the difference or ratio between the adjusted steady-state value and the original steady-state value, reflecting the actual degree of change in the process parameter. The actual adjustment magnitude can be calculated as the absolute difference between the adjusted and original steady-state values, for example, |adjusted steady-state value - original steady-state value|. Alternatively, the actual adjustment magnitude can also be calculated as the percentage change of the adjusted steady-state value relative to the original steady-state value, for example, ((adjusted steady-state value - original steady-state value) / original steady-state value) × 100%. The actual adjustment magnitude is compared with the allowable adjustment range to determine whether the actual adjustment is within the allowable limits. The comparison can be done by directly determining whether the adjusted steady-state value falls between the upper and lower limits of the allowable adjustment range, or by comparing the actual adjustment magnitude (e.g., percentage change) with the fluctuation ratio of the allowable adjustment range to determine whether it exceeds the limits.

[0113] When the actual adjustment range does not exceed the allowable adjustment range, the initial adjustment record is deemed compliant, indicating that the adjustment of the process parameter conforms to the preset process specifications in terms of magnitude and does not exceed the allowable range of variation. The system will further check whether a transmission constraint condition is defined for the name of the adjusted parameter in the process deviation adjustment rules. The transmission constraint condition refers to a predefined rule that affects other related process parameters or subsequent processes when a certain process parameter is adjusted. These conditions describe the specific situations that trigger the transmission effect, such as the adjustment range reaching a certain threshold or the adjustment direction being a specific direction. The transmission constraint condition can be defined as a series of logical expressions, such as "if the welding current adjustment range exceeds 5% and the weld type is a fillet weld, then the preheating temperature of the subsequent heat treatment process needs to be checked." Alternatively, the transmission constraint condition can also be represented by a decision table or decision tree in the rule engine. Based on the input such as the adjustment parameter name, adjustment range, and adjustment direction, it is determined whether there is a transmission effect and the specific conditions that trigger it. If it is defined and the actual adjustment range triggers the transmission constraint condition, a transmission adjustment mark is added to the adjustment record. This trigger refers to the actual adjustment magnitude satisfying the preset logical judgment in the transmission constraint conditions, thereby activating the corresponding transmission impact handling mechanism. The transmission adjustment flag is an identifier appended to the adjustment record, used to indicate that this adjustment has a cascading effect on other parameters or processes, requiring further attention or handling. The transmission adjustment flag can be a Boolean field or an enumerated type field, indicating the specific type of transmission impact.

[0114] The above technical solution enables accurate compliance verification of process parameter adjustments and proactive identification of their potential transmission effects. For example, by dynamically defining the allowable adjustment range based on the pre-adjustment steady-state value and combining upper and lower fluctuation limits, compliance judgments better align with the actual production practice of process engineers making fine-tuning adjustments based on the current state, avoiding misjudgments caused by using fixed ranges, thus improving the rationality and accuracy of verification. After confirming the compliance of the adjustment range, further checks and identification are performed to determine whether transmission constraints have been triggered, and a transmission adjustment marker is added to the adjustment record. This allows the system to promptly capture the chain reaction of this adjustment on subsequent processes or related parameters, making implicit transmission risks explicit. This mechanism solves the problems of insufficient precision in compliance judgment and easy omission of transmission effects in related technologies, providing more accurate and comprehensive adjustment information and constraint prompts for subsequent end-to-end manufacturing data integration, enhancing the integrity and reliability of data integration, and laying a solid foundation for subsequent change response and strategy formulation.

[0115] This application further proposes a method for determining compliance backtracking of adjustment records based on updated constraint parameter values. (See [link to relevant documentation]) Figure 5 Specifically, it includes: 501. The embedded adjustment basis and design parameter correlation rules in the process deviation adjustment rules are triggered. The adjustment basis description is extracted from the adjustment record. The design parameter conditions referenced in the adjustment basis description are traced back to the causal consistency with the changed component manufacturing semantics to obtain the causal correlation determination result.

[0116] 502. Based on the updated constraint parameter values, the compliance of the adjusted steady-state values ​​recorded in the adjustment record is re-determined to obtain the parameter compliance determination result.

[0117] 503. Integrate the causal relationship determination results with the parameter compliance determination results to generate compliance retrospective determination results carrying causal attribution tags. These causal attribution tags are used to distinguish whether non-compliance situations stem from invalid adjustment basis or insufficient adjustment magnitude.

[0118] For example, triggering the embedded adjustment basis and design parameter correlation rules within the process deviation adjustment rules refers to activating preset logical conditions or algorithms. These rules define how the basis for process adjustment is related to the design parameters of the steel structure components. This can be achieved through an event-driven mechanism, such as automatically triggering the preset correlation rule execution module when the system detects a component design change event. Alternatively, it can be achieved through scheduled tasks or manual intervention, with the system periodically executing the rule or it being manually initiated by a process engineer. It can also be achieved through API calls, with trigger commands sent by external systems. Extracting the adjustment basis description from the adjustment record refers to retrieving and obtaining textual or structured information explaining the reasons for the adjustment from the adjustment records that store details of past process parameter adjustments. This is typically achieved through database queries, knowledge graph traversal, or document parsing.

[0119] The causal consistency tracing of the design parameters and conditions referenced in the adjustment justification and the modified component manufacturing semantics aims to determine whether the original adjustment rationale remains valid after the design change. The adjustment justification often includes specific design parameters and conditions (e.g., plate thickness, material grade), while the modified component manufacturing semantics provides updated design information. Causal consistency tracing compares these original conditions with the updated design parameters to determine whether the original conditions still hold. This can be achieved through rule engine comparison, semantic matching algorithms, or knowledge graph reasoning. After tracing, the system obtains a causal relationship determination result, indicating whether the causal relationship between the original adjustment justification and the modified design still holds, presented for example as a Boolean value, a structured report, or an assessment with confidence levels.

[0120] Based on the updated constraint parameter value, the compliance of the adjusted steady-state values ​​recorded in the adjustment record is reassessed. This means comparing the actual adjusted process parameter values ​​with the personalized process constraints (i.e., the updated constraint parameter values) re-derived based on the new design conditions to assess whether they meet the new requirements. This can be achieved through interval comparison, rule set verification, or mathematical model calculation. This process will yield parameter compliance determination results, indicating whether the adjusted parameter values ​​comply with the updated constraints, and may include information such as compliance status, deviation amount, and deviation direction.

[0121] The causal relationship determination result is merged with the parameter compliance determination result to form a comprehensive assessment. The fusion process can be achieved through logic gate operations, decision matrices, or weighted scoring. After fusion, a compliance backtracking determination result carrying a causal attribution label will be generated. This causal attribution label is the core of this solution, explicitly used to distinguish whether non-compliance stems from an invalid adjustment basis or insufficient adjustment magnitude. For example, when the original adjustment basis is no longer valid due to design changes, it is labeled as "invalid adjustment basis." When the original basis still holds but the adjusted parameter value does not meet the new constraints, it is labeled as "insufficient adjustment magnitude." This can be achieved through pre-defined attribution logic, expert systems, or machine learning models.

[0122] The above technical solution addresses the problem of unclear attribution in the retrospective analysis of compliance during process adjustments following design changes. Through dual-dimensional verification—simultaneously tracing the causal relationship of the adjustment basis and the compliance of the adjustment parameters, and further integrating the results of these two dimensions—this application can clearly identify the specific reasons for non-compliance. For example, when a design change renders the original adjustment basis invalid, the system can clearly indicate that the non-compliance is caused by "invalid adjustment basis." Conversely, when the original basis remains valid, but the adjusted parameter values ​​do not meet the new constraints, the system can identify it as "insufficient adjustment magnitude." This refined causal attribution labeling provides a clear direction for subsequent targeted process correction measures, avoiding errors in response strategy formulation due to ambiguous attribution, thereby improving the accuracy and efficiency of manufacturing process response after design changes. Furthermore, relying on existing adjustment records and manufacturing semantic information in a dynamic process knowledge graph, this solution enables automated traceability and verification without the need for additional information collection, ensuring the automation and efficiency of the traceability process and further enhancing the data connectivity across the entire manufacturing process.

[0123] This application further proposes to trace the causal consistency between the design parameters and conditions referenced in the adjustment basis description and the changed component manufacturing semantics to obtain the causal relationship determination result. The specific steps include: The name of the referenced design parameter and the original value conditions of the design parameter name when the adjustment occurs are extracted from the adjustment basis description.

[0124] Extract the modified value corresponding to the design parameter name from the modified component manufacturing semantics, compare the original value condition with the modified value to determine whether the original value condition is still satisfied.

[0125] When the original value condition is no longer met, a causal relationship determination result indicating that the adjustment basis has failed is generated; when the original value condition is still met, a causal relationship determination result indicating that the adjustment basis has been established is generated.

[0126] For example, when parsing the referenced design parameter names and their original values ​​at the time of adjustment from the adjustment basis description, this step aims to transform the unstructured text of the "adjustment basis description" in the process adjustment record into machine-understandable and processable structured data. This means identifying the specific design parameters upon which the adjustment depends and their specific values ​​or conditions at the time of adjustment. This is the foundation for automated causal traceability. For instance, Natural Language Processing (NLP) techniques, such as rule-based pattern matching or machine learning models (e.g., named entity recognition, relation extraction), can be used to perform semantic analysis on the adjustment basis description text, identifying design parameter-related keywords (e.g., "plate thickness," "material grade," and "weld type") and their accompanying numerical or range descriptions. For example, if the description is "Adjust welding current due to plate thickness increased to 12mm," the system can parse the design parameter name as "plate thickness" and the original value condition as "12mm." Furthermore, predefined templates or structured input interfaces can be used to standardize the filling of the adjustment basis. When process engineers make adjustments, they are required to select design parameters from the drop-down menu and enter the corresponding values ​​or conditions, thereby directly generating structured design parameter names and original value conditions, avoiding a complex text parsing process.

[0127] The core of this step, extracting the modified values ​​corresponding to the design parameter names from the changed component manufacturing semantics and comparing the original value conditions with the modified values ​​to determine whether the original value conditions are still met, lies in obtaining the latest design parameter status after the design change and accurately comparing it with the original design parameter conditions relied upon during process adjustments to determine the validity of the original adjustment basis. For example, the system can maintain a component manufacturing semantic database or knowledge graph, storing various design parameters of the component and their latest values. Upon receiving a design parameter name, the system directly extracts the latest value of that parameter after the change by querying the database. Consistency comparison can be achieved through simple numerical equality judgments, range inclusion judgments, or logical condition judgments. For example, if the original condition is "plate thickness ≥ 10mm" and the modified value is "12mm", the system determines whether "12mm ≥ 10mm" is true. Integration with design systems (such as CAD / PLM systems) can also be achieved. When a design change occurs, the design system publishes a change event and provides the modified component design data. The system listens for these events and extracts the corresponding modified values ​​from the modified design data based on the parsed design parameter names. The comparison logic can use different comparison operators depending on the parameter type (numerical, enumerated, boolean, etc.).

[0128] When the original conditions are no longer met, a causal relationship determination result is generated indicating that the adjustment basis has failed; when the original conditions are still met, a causal relationship determination result is generated indicating that the adjustment basis has been established. This step, based on the consistency comparison results, explicitly provides a causal relationship judgment between the process adjustment basis and the design change, providing clear input for subsequent integrated response strategies. For example, result generation can be a simple conditional statement. For instance, if the comparison result is "not satisfied," the system generates a structured data object containing "causal relationship determination result: adjustment basis failed." If the comparison result is "satisfied," a structured data object containing "causal relationship determination result: adjustment basis established" is generated. These results can further include metadata such as timestamps and relevant parameter values. Alternatively, results can be generated through a predefined rule engine. The rule engine triggers different rule branches based on the Boolean result of the consistency comparison, with each branch corresponding to a causal relationship determination result generation logic. For example, rules can be defined such as "IF original conditions not satisfied THEN generate 'adjustment basis failed' result" and "IF original conditions satisfied THEN generate 'adjustment basis established' result."

[0129] The above technical solution achieves automated and accurate causal traceability of the basis for process adjustments, eliminating the need for manual interpretation of complex textual explanations. This solves the problem of lacking executable logical support for causal consistency traceability and failing to obtain structured causal relationship determination results. This solution can quickly and accurately identify situations where design changes render the original adjustment basis invalid, avoiding potential manufacturing risks caused by invalid basis. It provides structured causal relationship determination results (adjustment basis invalid or adjustment basis valid), providing clear and machine-readable input for subsequent comprehensive response strategies (such as compliance retrospective determination and forward impact determination), thereby supporting smarter and more automated decision-making. Therefore, this application improves the integrity and reliability of data integration, effectively linking process adjustment behavior with design change events, and bridging the untraceable gap between process adjustments and design changes in existing systems.

[0130] This application further proposes to redetermine the compliance of the adjusted steady-state value recorded in the adjustment record based on the updated constraint parameter value, and obtain the parameter compliance determination result. This process includes the following steps: The system extracts the revised theoretical setpoints associated with the adjustment parameter names corresponding to the adjustment record from the revised component manufacturing semantics, and uses these revised theoretical setpoints as the new benchmark center. This step aims to provide an accurate benchmark reference point consistent with the latest design changes for compliance reassessment. For example, the system parses the revised component manufacturing semantics, which includes information such as the latest design requirements, material specifications, and geometric dimensions of the component. By identifying the design parameters corresponding to the adjustment parameter names recorded in the adjustment record (e.g., welding current, preheating temperature, welding speed, etc.), the system can extract the revised theoretical setpoints of the adjustment parameters from this latest semantic information. For example, if the plate thickness of the component increases due to a design change, the system will obtain the theoretical setpoints of the welding current that match the new plate thickness from the revised component manufacturing semantics. These theoretical setpoints will serve as the central reference point for subsequent compliance judgments, ensuring the accuracy and timeliness of compliance assessments. In one implementation, the system can directly query the preset parameter value table or attribute fields in the revised component manufacturing semantics. In another implementation, the system can dynamically generate the theoretical set value by reasoning and calculating based on key attributes (such as material type and weld type) in the modified component manufacturing semantics through predefined engineering rules or expert systems.

[0131] The system constructs a compliance interval around the baseline center using the allowable offset range defined in the updated constraint parameter value, and compares the adjusted steady-state value with this compliance interval to determine whether the adjusted steady-state value falls within the compliance interval. This step is used to establish an acceptable range of process parameter fluctuations based on the new baseline center and to determine whether the actual adjusted value falls within this range, thus quantifying the allowable deviation. The updated constraint parameter value already includes the definition of allowable offset ranges for various process parameters. These definitions can be fixed values, percentages, or ranges dynamically calculated based on specific conditions. The system applies these allowable offset ranges to the changed theoretical setpoint (baseline center) determined in the previous step to construct a specific compliance interval. For example, if the baseline center is 200A and the allowable offset range is ±10A, then the compliance interval is [190A, 210A]. The system compares the adjusted steady-state value recorded in the adjustment record with this compliance interval to determine whether it falls within the interval. One comparison method is to directly check whether the adjusted steady-state value is greater than or equal to the lower limit of the interval and less than or equal to the upper limit of the interval. Another comparison method is to calculate the deviation between the adjusted steady-state value and the reference center, and determine whether the absolute value of the deviation is less than or equal to the absolute value of the allowable offset range.

[0132] Furthermore, when the determination is non-compliant, the system calculates the direction and amount of deviation of the adjusted steady-state value relative to the compliance range, and generates a parameter compliance determination result carrying this deviation direction and amount. This step aims to provide detailed deviation information when non-compliance is detected, facilitating subsequent analysis and correction. If the determination in the previous step is non-compliant, the system will further analyze the specific circumstances of the adjusted steady-state value's deviation from the compliance range. The deviation direction indicates whether the adjusted value is too high or too low, such as "out of bounds upwards" or "out of bounds downwards." The deviation amount quantifies the specific value exceeding the compliance range. For example, if the upper limit of the compliance range is 210A and the adjusted steady-state value is 220A, then the deviation direction is "out of bounds upwards," and the deviation amount is 10A. This deviation direction and deviation amount information will be encapsulated in the parameter compliance determination result. One calculation method is that if the adjusted steady-state value is greater than the upper limit of the compliance range, the deviation direction is positive, and the deviation amount is the adjusted steady-state value minus the upper limit value. If the deviation is less than the lower limit of the compliance range, the deviation direction is negative, and the deviation amount is the lower limit value minus the adjusted steady-state value. Another calculation method is to determine the relative position of the adjusted steady-state value and the benchmark center, and then combine this with its distance from the boundary of the compliance range to comprehensively judge the deviation direction and deviation amount.

[0133] The above technical solution provides a more accurate and practical mechanism for re-determining the compliance of existing process adjustment records after design changes. By extracting the theoretical setpoints associated with the adjustment parameter names corresponding to the adjustment records from the modified component manufacturing semantics, and using these as the re-determined benchmark center, the compliance judgment benchmark can maintain a high degree of consistency with the actual requirements after the design change. This effectively avoids judgment bias caused by using the old benchmark, thus ensuring the accuracy of the compliance assessment. A compliance interval around this benchmark center is constructed using the allowable offset range defined in the updated constraint parameter values, and compared with the adjusted steady-state value. This not only maintains the uniformity of the entire process constraint rule system without requiring additional redefinition of offset standards, but also adapts to the new benchmark center, obtaining a compliance judgment range that meets the current design change requirements, thus balancing rule uniformity and change adaptability. When the conclusion is determined to be non-compliant, the direction and amount of deviation of the adjusted steady-state value relative to the compliance range are calculated, and a parameter compliance determination result carrying this information is generated. This detailed deviation information can provide a clear and specific reference for the subsequent formulation of process correction plans, helping relevant personnel to quickly locate the adjustment direction and the magnitude of correction required, improving the efficiency and pertinence of subsequent processing, and making the entire compliance retrospective result more practical, thereby meeting the need for accurate compliance retrospective after design changes in the whole process data integration.

[0134] This application further proposes a step to generate a compliance retrospective determination result carrying a causal attribution marker by integrating causal correlation determination results and parameter compliance determination results. This step includes: when the causal correlation determination result indicates that the adjustment basis is invalid, and the parameter compliance determination result indicates non-compliance, generating a compliance retrospective determination result carrying a dominant marker of invalid basis. When the causal correlation determination result indicates that the adjustment basis is valid, but the parameter compliance determination result indicates non-compliance, generating a compliance retrospective determination result carrying a dominant marker of insufficient adjustment magnitude. When the causal correlation determination result indicates that the adjustment basis is valid, and the parameter compliance determination result indicates compliance, generating a compliance retrospective determination result carrying a marker that the adjustment is still compliant.

[0135] The causal relationship determination result is a state or data structure used to characterize the effectiveness of the basis for the original process adjustment after the design change. It can be a Boolean value, such as "effective" or "ineffective," or a more detailed enumeration type or structured data containing the specific reasons for the failure. The purpose of this result is to attribute the cause of the adjustment at the "cause" level, i.e., to determine whether the logical premise of the original adjustment has changed due to the design change. The parameter compliance determination result is another state or data structure used to characterize whether the adjusted process parameter values ​​meet the new constraints after the design change. It can be a Boolean value, such as "compliant" or "non-compliant," or a more detailed enumeration type or structured data containing the degree or direction of non-compliance. The purpose of this result is to attribute the cause of the adjustment at the "result" level, i.e., to determine whether the actual parameter values ​​after the adjustment meet the new technical specifications.

[0136] The "Failure Dominant" flag is a specific attribution marker generated when the causal relationship indicates that the adjustment basis is invalid, and the parameter compliance determination indicates non-compliance. This flag explicitly states that the main reason for non-compliance is that the basis for the original adjustment is no longer valid; for example, the design parameters on which the original adjustment relied are no longer met. The "Insufficient Adjustment Dominant" flag is another specific attribution marker generated when the causal relationship indicates that the adjustment basis is valid, but the parameter compliance determination indicates non-compliance. This flag explicitly states that the main reason for non-compliance is that the magnitude of the original adjustment failed to meet the new constraints; that is, the direction of the adjustment is correct, but the magnitude is insufficient or excessive. The "Adjustment Still Compliant" flag is a specific attribution marker generated when the causal relationship indicates that the adjustment basis is valid, and the parameter compliance determination indicates compliance. This flag explicitly states that the original adjustment remains valid and compliant after the design change, requiring no further processing.

[0137] By assigning corresponding attribution tags to three different combinations of causal correlation determination results and parameter compliance determination results, the specific causes of non-compliance are clearly distinguished. This provides a clear and accurate attribution reference for subsequently formulating process response strategies after design changes, solving the problem of the original fusion-generated results lacking clear attribution classification and ensuring the traceability and continuity of manufacturing process data in design change scenarios. For scenarios where the causal correlation determination results show that the adjustment basis is invalid, and the parameter compliance determination results also show non-compliance, a compliance backtracking determination result carrying a dominant tag of invalid basis is generated. Attribution judgment is made by combining the two determination results from different sources. The causal correlation determination result reflects whether the original adjustment basis has lost its validity due to the design change, while the parameter compliance determination result reflects whether the adjusted parameters meet the updated constraint requirements. The attribution result obtained by combining the two judgments can accurately pinpoint the core cause of non-compliance in this scenario: the design change caused the original adjustment's underlying conditions to be invalid, facilitating subsequent direct reconstruction and correction of the adjustment basis. For scenarios where the causal relationship determination results show the adjustment basis is valid, but the parameter compliance determination results show non-compliance, a compliance backtracking determination result with a dominant marker indicating insufficient adjustment magnitude is generated. This classification clarifies that in such scenarios, the original adjustment's starting point meets the changed design requirements; only the adjustment magnitude does not meet the updated constraints. This marker guides subsequent corrections only to the adjustment magnitude, without overturning the original adjustment basis, avoiding unnecessary duplication of work and effectively improving the efficiency of process modification. For scenarios where both results show compliance, a compliance backtracking determination result with a marker indicating the adjustment remains compliant is generated. This classification clarifies that the original process adjustment still meets process constraints after the design change and requires no further adjustments. The original adjustment record can be directly retained, reducing unnecessary process verification workload and ensuring production efficiency. These clear attribution markers provide a refined decision-making basis for subsequently generating comprehensive response strategies for manufacturing work orders, improving the accuracy and execution efficiency of the response strategy.

[0138] This application further proposes a method for determining forward effects along the process execution path. The method includes: starting with the component entity of the changed component in the dynamic process knowledge graph, traversing along the process execution path to locate all associated work order entities with manufacturing dependencies on the changed component; triggering process constraint rules, using the updated constraint parameter values ​​as the updated executable constraint benchmark, and re-verifying the process constraint conditions of each associated work order entity to obtain the constraint compliance status of each associated work order entity; and generating a forward effect determination result based on the execution progress information and constraint compliance status of each associated work order entity. This forward effect determination result is used to indicate the required process response category for each associated work order entity under a component design change event.

[0139] For example, the forward impact determination along the process flow path refers to the systematic assessment of the impact of a component design change on subsequent manufacturing processes and related work orders. Its purpose is to identify all affected manufacturing stages through prediction and analysis, and to provide clear response strategies for these stages, thereby avoiding production interruptions, quality problems, or rework caused by design changes. This determination process can be achieved by constructing an impact analysis model that simulates the propagation path of design changes in the manufacturing process, or by using an expert system that determines the scope and extent of the change's impact based on pre-defined rules and a knowledge base.

[0140] Starting with the component entity in the dynamic process knowledge graph representing the changed component, this method traverses along the process execution association path to locate all related work order entities with manufacturing dependencies on the changed component. The aim is to accurately identify all manufacturing work orders affected by design changes. The "dynamic process knowledge graph" is a semantic network containing components, processes, work orders, and their interrelationships, reflecting the real-time status and dependencies of the manufacturing process. "Component entities" are nodes in the knowledge graph representing specific components, carrying their design and manufacturing attributes. "Process execution association paths" describe the logical sequence and dependencies between various processes and work orders in the manufacturing process from raw materials to finished products. "Manufacturing dependencies" refer to the technical or logical dependence of the execution of a work order or the production of a component on the completion of another component or work order. This location process can be implemented in one way: utilizing the traversal query function of the graph database, starting from the component entity corresponding to the changed component, a depth-first or breadth-first search is performed along the predefined manufacturing dependency edges in the knowledge graph until all relevant work order entities are found. Another approach is for the system to maintain a pre-computed dependency table. When a component changes, the system directly queries this table to obtain a list of all work orders that directly or indirectly depend on the changed component.

[0141] This triggers process constraint rules, using updated constraint parameter values ​​as updated executable constraint benchmarks. It re-verifies the process constraint conditions of each associated work order entity, obtaining the constraint compliance status of each associated work order entity. The aim is to ensure that all affected work orders meet the new design requirements. Here, "process constraint rules" are predefined logical conditions or ranges used to regulate specific process parameters. "Updated constraint parameter values" are process parameter values ​​reflecting the new design requirements, obtained through re-reasoning based on component design change events. "Updated executable constraint benchmarks" inject these updated parameter values ​​into the process constraint rules, making them the new verification standard. "Constraint compliance status" indicates whether the current process parameters of the work order meet the updated constraint benchmarks. This verification process can be implemented in one way: the system loads the updated constraint parameter values ​​into a rule engine, which automatically executes the process constraint rules and compares them with the recorded or planned process parameters of each associated work order entity to determine whether they comply with the new constraints. Another approach is to develop a dedicated parameter comparison module. This module receives updated constraint parameter values ​​and compares them one by one with the process parameters of each associated work order entity. Based on preset deviation thresholds and directions, it determines the compliance status of each work order.

[0142] Based on the execution progress information and constraint compliance status of each associated work order entity, a forward impact determination result is generated. This result indicates the required process response category for each associated work order entity under component design change events, aiming to provide clear and actionable guidance for affected work orders. "Execution progress information" refers to the current production status of each associated work order entity, such as not started, in progress, or completed. The "forward impact determination result" is a targeted recommendation provided by the system after comprehensively considering work order progress and constraint compliance. The "process response category" is the specific handling measure, such as production suspension, rework assessment, and parameter adjustment. This result generation process can be implemented in the following ways: One method is that the system has a built-in decision logic that combines the work order's execution progress (e.g., "not started," "in progress," "completed") and constraint compliance status (e.g., "compliant," "non-compliant") to output the corresponding process response category. For example, for a work order that is "in progress" and "non-compliant," it is recommended to "trigger the process suspension response category." For work orders that are "completed" but "non-compliant," it is recommended to "trigger a rework assessment response category." Alternatively, the system provides a configurable response strategy matrix, allowing users to customize process response categories under different combinations of progress and compliance statuses based on actual production needs. The system then automatically generates forward impact determination results based on this matrix.

[0143] The above technical solution leverages the established relationships within a dynamic process knowledge graph to accurately and comprehensively locate all related work order entities within the scope of design change impact, effectively avoiding omissions or misjudgments that occur in traditional methods. By injecting updated constraint parameter values ​​into the process constraint rules, instantiating them as updated executable constraint benchmarks, it ensures that the verification logic for re-verifying the process constraints of related work order entities remains synchronized with the requirements after the design change, thus outputting accurate and reliable constraint compliance status. Furthermore, by combining the execution progress information and constraint compliance status of each related work order entity, it can generate forward impact determination results with clearly defined process response categories. This provides clear and operable input for subsequently generating comprehensive response strategies for manufacturing work orders, greatly improving the accuracy and efficiency of data integration throughout the entire steel structure order manufacturing process and solving the problem of inaccurate and unclear forward impact determination after design changes occur.

[0144] This application further proposes a method for locating and modifying all associated work order entities with manufacturing dependencies on components, the steps of which include: Obtain the component entity corresponding to the changed component from the dynamic process knowledge graph, and extract the component identifier of the component entity.

[0145] Starting with the component identifier, the search extends outward along the process execution association path between the component entity and the work order entity, collecting all work order entities that have a direct reference relationship with the component identifier.

[0146] Simultaneously, based on the assembly dependency relationship between component entities in the dynamic process knowledge graph, the downstream component entity that is modified to be an assembly prerequisite is located, and the work order entities associated with the downstream component entity are included in the set of associated work order entities.

[0147] For example, in the method described above, it is necessary to obtain the component entity corresponding to the changed component from the dynamic process knowledge graph and extract the component identifier of that component entity. A component entity is a node in the knowledge graph representing a physical component, carrying various manufacturing semantic information of the component, such as material, dimensions, and design parameters. The component identifier is a code used to uniquely identify the component entity; it can be a globally unique identifier (UUID) automatically generated by the system, or a composite code formed by combining project information and component number. This step aims to accurately locate the starting component involved in the design change, providing an accurate benchmark for subsequent work order positioning.

[0148] Starting with the component identifier, the search expands outward along the process execution association path between the component entity and the work order entity, collecting all work order entities that have a direct reference relationship with the component identifier. The process execution association path is the relationship connecting component entities and work order entities in a dynamic process knowledge graph; it describes the various processes a component undergoes during manufacturing and their corresponding work orders. For example, in a graph database, this can be represented as a directed edge from a component entity to a work order entity, indicating that the work order is responsible for handling a certain process of that component. A direct reference relationship means that the work order entity explicitly points to or is associated with a specific component entity, indicating that the work order was created for the manufacturing of that component. Through this path, all work orders directly related to the manufacturing of changed components can be identified; these work orders are the most direct manifestation of the impact of design changes.

[0149] To more comprehensively identify the scope of impact, this application also locates downstream component entities that require the changed component as a prerequisite for assembly, based on the assembly dependencies between component entities in the dynamic process knowledge graph. The work order entities associated with these downstream component entities are then included in the set of associated work order entities. Assembly dependencies refer to the requirement in steel structure manufacturing that the assembly or processing of certain components depends on the completion of other components (i.e., prerequisites for assembly). For example, welding a secondary beam requires the main beam to be positioned first. When a changed component undergoes a design change as a prerequisite for assembly, its manufacturing process or assembly requirements are affected even if the design of the downstream component itself remains unchanged. Downstream component entities refer to those components that depend on the changed component at the assembly level. By traversing these assembly dependencies, components indirectly affected by the design change can be identified, and their associated work orders can be included in the analysis.

[0150] The above technical solution enables the complete identification of all related work orders affected by design changes. This solution not only considers work orders directly associated with the changed components but also identifies downstream components and their related work orders indirectly affected by the changed components as pre-assembly components by introducing assembly dependencies between component entities. This dual-path retrieval mechanism effectively compensates for the indirect impacts missed in traditional methods, ensuring the completeness of the identification of the design change's impact scope. This provides a comprehensive and accurate analysis object for subsequent compliance backtracking determination of adjustment records based on updated constraint parameter values ​​and for determining forward impacts along the associated paths of the process. This avoids the problem of missing or inaccurate process responses due to incomplete impact scope identification, and improves the depth and breadth of data integration throughout the entire manufacturing process.

[0151] This application further proposes triggering the process constraint rule for this operation, using the updated constraint parameter value as the updated executable constraint benchmark, and re-verifying the process constraint conditions of each associated work order entity to obtain the constraint compliance status of each associated work order entity. This includes: extracting the updated constraint interval corresponding to each process parameter from the updated constraint parameter value, loading the updated constraint interval into the parameter comparison logic of the process constraint rule for this operation, and completing the update of the executable constraint benchmark. For each associated work order entity, extracting the executed process parameter record of the associated work order entity, comparing the actual value of each process parameter in the executed process parameter record with the corresponding updated constraint interval one by one to obtain the compliance mark of a single process parameter. Summarizing the compliance marks of all process parameters under the associated work order entity, if the compliance mark of any process parameter indicates a deviation, the constraint compliance status of the associated work order entity is determined to be non-compliant; otherwise, it is determined to be compliant.

[0152] For example, when implementing the above technical solution, it is necessary to extract the updated constraint intervals corresponding to each process parameter from the updated constraint parameter values. The aim is to obtain the latest allowable range set for each specific process parameter (such as welding current, voltage, preheating temperature, etc.) after the design change. For instance, this can be achieved by parsing a structured data file containing updated constraint parameter values ​​(such as JSON or XML format), or by querying a database or knowledge graph related to component manufacturing semantics, to obtain the upper and lower limits of each process parameter, thereby forming an accurate updated constraint interval. Alternatively, these updated interval data can be obtained from a centralized parameter management service by calling a predefined API interface.

[0153] The updated constraint range is loaded into the parameter comparison logic of the process constraint rules for this operation, completing the update of the executable constraint benchmark. The purpose of this step is to ensure that subsequent compliance checks are based on the latest design requirements. For example, these updated constraint ranges can be dynamically injected into the rule engine's configuration, allowing it to use the new range values ​​when performing comparison operations. Alternatively, the system can maintain a configurable parameter verification module that receives and updates its internally stored constraint ranges through a programming interface, thereby adjusting its comparison benchmark in real time.

[0154] For each associated work order entity, the executed process parameter records for that entity are extracted. This aims to obtain the process parameter values ​​recorded during the actual manufacturing process for each work order affected by design changes. For example, this can be achieved by querying the Manufacturing Execution System (MES) or a historical database, retrieving the time-series data of process parameters actually collected during production, related to that work order, based on the work order identifier. Alternatively, the system can obtain tamper-proof executed process parameter records from a distributed ledger or blockchain, ensuring the authenticity and integrity of the data.

[0155] The system compares the actual values ​​of each process parameter in the executed process parameter record with the corresponding updated constraint interval one by one to obtain a compliance mark for each individual process parameter. This aims to determine whether each specific process parameter meets the updated design requirements. For example, the system can perform a numerical comparison operation on the actual value of each process parameter to determine whether it falls within the corresponding updated constraint interval. If the actual value exceeds the interval, it is marked as "deviation." If it is within the interval, it is marked as "compliance." Furthermore, fuzzy logic or an expert system can be used to perform a more refined evaluation of the degree of compliance between the actual value and the constraint interval and generate corresponding compliance marks.

[0156] The system aggregates the compliance markers of all process parameters under the associated work order entity. If any process parameter's compliance marker indicates a deviation, the constraint compliance status of the associated work order entity is determined to be non-compliant; otherwise, it is determined to be compliant. This aims to provide an overall compliance assessment for each associated work order. For example, the system can iterate through the compliance markers of all individual process parameters. Once any marker is found to be "deviation," the constraint compliance status of the entire work order is immediately determined to be "non-compliant." If all parameters are marked as "compliant," the work order status is determined to be "compliant." This "one-vote veto" mechanism ensures strict adherence to design changes and avoids overall quality risks caused by local non-compliance.

[0157] The above technical solution clarifies the complete process for constraint compliance verification of related work orders affected by design changes. By extracting the updated constraint ranges corresponding to each process parameter from the updated constraint parameter values ​​and loading them into the parameter comparison logic of the process constraint rules, the real-time performance and accuracy of the verification benchmark are ensured, avoiding errors in verification results caused by using the old benchmark. For each related work order entity, its executed process parameter records are extracted, and the actual values ​​of each process parameter are compared one by one with the updated constraint ranges. This ensures complete coverage of all process parameters affected by design changes, guaranteeing that no parameter requiring verification is missed, and allowing the compliance status of each parameter to be independently and accurately identified. By summarizing the compliance marks of all process parameters and adopting a rule that any deviation from any parameter constitutes overall non-compliance, the manufacturing process can be strictly guaranteed to meet the changed design requirements, avoiding the omission of non-compliant work orders. This rigorous verification mechanism enables the system to obtain the accurate constraint compliance status of each associated work order based on the updated constraint parameters, thereby providing a reliable foundation for generating accurate forward impact determination results and comprehensive response strategies for manufacturing work orders. It solves the technical challenge of accurately assessing the compliance of executed work orders in design change scenarios.

[0158] This application further proposes a method to generate a forward impact determination result based on the execution progress information and constraint compliance status of each associated work order entity. Specifically, this includes: reading the execution progress information from the work order status field of each associated work order entity, and classifying the associated work order entity into unstarted work orders, in-process work orders, and completed work orders. For an in-process work order with a constraint compliance status of non-compliance, determining whether to trigger a process pause response category; for a completed work order with a constraint compliance status of non-compliance, determining whether to trigger a rework assessment response category. The constraint compliance status corresponding to the unstarted work order, the in-process work order, and the completed work order is combined with the triggered process response category to generate a forward impact determination result carrying a work order classification tag and a response category tag.

[0159] For example, the system reads the execution progress information from the work order status field of each associated work order entity and categorizes the associated work order entity into three types: not started, in progress, and completed. This aims to obtain the current production execution status of each associated work order entity and classify it accordingly. Execution progress information is typically stored in the work order entity's data structure. For instance, it can be an enumerated type field (e.g., "not started," "in progress," "completed") or calculated using a timestamp field (e.g., "planned start time," "actual start time," "actual completion time") combined with the current date. After reading this information, the system explicitly classifies the work order entity into three categories: "not started," "in progress," and "completed," allowing for differentiated response strategies for work orders at different production stages. For example, this information can be obtained by querying the work order status database in a Management System for Orders (MES) or Enterprise Resource Planning (ERP) system. Alternatively, it can be determined by parsing the production plan or scheduling data associated with the work order entity and assessing its current production stage.

[0160] For an in-progress work order with a constraint compliance status of "non-compliant," determine whether to trigger a process pause response category. This step targets work orders that are in production but whose process parameters no longer meet the new constraints, aiming to stop losses promptly. When the system detects that the constraint compliance status of an in-progress work order is "non-compliant," it assesses whether the current production activity needs to be stopped immediately. Triggering a process pause response category means that the system will issue an instruction to the relevant production unit, requiring the suspension of production for that work order to avoid continuing to produce components that do not meet the new design or process requirements. For example, this can be implemented by sending a pause instruction to the MES system, or by displaying a warning message on the production Kanban board and requiring operators to manually pause production.

[0161] For completed work orders with a non-compliant constraint status, the system determines the rework assessment response category. This step, for work orders where production has been completed but their process parameters do not meet the new constraints, aims to conduct risk assessment and decision-making. For completed work orders, since production activities have ended, a direct "pause" operation is not possible. Therefore, when the constraint compliance status is "non-compliant," the system triggers a "rework assessment response category." This means that a detailed quality inspection, performance test, or impact analysis of the completed component is required to determine whether rework, scrapping, or other remedial measures are necessary. For example, the system can automatically generate a rework assessment report and send it to the quality department or process engineer for review. Alternatively, the work order can be marked as "pending assessment" in the knowledge graph and associated with the corresponding assessment process.

[0162] By combining the constraint compliance status of the unstarted, in-process, and completed work orders with the triggered process response category, a forward impact determination result carrying work order classification and response category tags is generated. This aims to structurally integrate the constraint compliance status and corresponding process response recommendations of different work order categories, forming a clear and actionable output. By combining the work order classification (unstarted, in-process, completed), its constraint compliance status (compliant, non-compliant), and the specific process response category determined based on these statuses (e.g., process suspension, rework assessment, no response required), a comprehensive result containing "work order classification tag" and "response category tag" can be generated. For example, this information can be encapsulated into a data object or record containing fields such as work order ID, work order type (unstarted / in-process / completed), constraint status (compliant / non-compliant), and recommended response (suspension / rework assessment / none). Alternatively, a structured report can be generated, clearly listing the detailed information and recommended response measures for each affected work order.

[0163] Through the above technical solution, by classifying the execution progress of related work order entities in a refined manner and combining it with their constraint compliance status, differentiated process response strategies are provided for work orders at different production stages. For example, by reading the execution progress information from the work order status field, work orders are divided into three categories: not started, in progress, and completed. This allows the system to accurately grasp the current production stage of each work order, laying the foundation for accurate subsequent responses. For in progress work orders with non-compliance constraints, the system can promptly trigger a process pause response, effectively preventing the continued production of defective products, thereby reducing material waste and rework costs, and ensuring production efficiency and product quality. For completed work orders with non-compliance constraints, the system triggers a rework assessment response, avoiding blind rework and instead conducting a risk assessment first to ensure the rationality and economy of subsequent processing decisions. By combining these classifications, statuses, and response suggestions into clearly labeled forward impact determination results, targeted decision-making basis can be obtained directly and efficiently when generating comprehensive response strategies. This improves the intelligence level and response efficiency of data integration throughout the manufacturing process and avoids production chaos and resource waste caused by adopting a "one-size-fits-all" response approach to work orders with different progress.

[0164] This application further proposes a method for generating a comprehensive response strategy for manufacturing work orders by intersecting the results of forward impact determination and compliance backtracking determination, specifically including: The forward determination conclusions of each related work order entity are extracted from the forward impact determination results, and the retrospective determination conclusions of the corresponding work order entities are extracted from the compliance retrospective determination results. These forward and retrospective determination conclusions are then paired at the work order level to form a dual-path determination combination at the work order dimension. This aims to accurately align the outputs of two independent analysis processes at the smallest granularity (i.e., work order entity), thereby providing a correct foundation for subsequent comprehensive analysis. For example, a unique work order identifier can be generated for each work order entity, and this identifier can be output as metadata when generating the forward impact determination results and the compliance retrospective determination results. By comparing these unique work order identifiers, the correspondence between the forward and retrospective determination conclusions can be established. Alternatively, when work order identifiers are not directly available or differ, the association between work orders and component entities, as well as the creation or modification timestamps of the work orders, can be used for auxiliary matching. For example, for work orders under the same component entity, their forward and backward determination conclusions should have a certain temporal correlation. The system can perform fuzzy matching based on the component entity ID and time window, and then perform accurate matching through manual confirmation or further semantic analysis. Furthermore, the predefined relationships between work order entities and component entities, as well as between work order entities and process execution paths, in the dynamic process knowledge graph can be utilized. Through the knowledge graph's query mechanism, retrieval and matching can be performed based on the work order entity ID or its associated component entity ID.

[0165] For each dual-path determination combination of this work order dimension, the comprehensive response category of the corresponding work order entity is determined based on the collaborative determination rules of the forward determination conclusion and the retrospective determination conclusion. This step is crucial for achieving comprehensive decision-making, as it integrates the results of forward impact analysis (focusing on the future) and compliance retrospective analysis (focusing on the past) to generate a unified and actionable response recommendation. For example, a collaborative determination matrix can be preset, which uses the type of "forward determination conclusion" (e.g., unaffected, requires attention, requires adjustment, requires rework) and the type of "retrospective determination conclusion" (e.g., compliant, invalid basis, insufficient adjustment) as input dimensions. Each cell of the matrix predefines the corresponding "comprehensive response category" (e.g., no action required, parameter update, recommended readjustment, forced rework). After receiving the dual-path determination combination, the system directly looks up the comprehensive response category in the table. Alternatively, a rule engine based on domain expert knowledge can be established. These rules can be expressed as "IF [forward conclusion is X] AND [backward conclusion is Y] THEN [overall response category is Z]", for example, "IF forward conclusion is 'adjustment needed' AND backward conclusion is 'insufficient adjustment' THEN overall response category is 'pull adjustment suggestion'". The rule engine can handle more complex logic and priorities, providing more flexible response strategies. With sufficient data, a classification model can also be trained based on historical design change and process response data. Using the feature vectors of "forward determined conclusion" and "backward determined conclusion" as input, the model outputs the predicted "overall response category", thereby learning more refined collaborative patterns from historical data.

[0166] The system aggregates the comprehensive response categories of all work order entities and writes them into the order status timeline along the association paths between component entities and order entities in the dynamic process knowledge graph, thus obtaining the comprehensive response strategy. This step elevates the scattered work order-level response information to the order level and records it in the form of a timeline for easy macro-management and traceability. In specific implementation, the system can obtain the component entities associated with all work order entities from the dynamic process knowledge graph, and then trace back to the order entity through the association paths such as "contains" and "belongs to" between the component entities and the order entity. Then, a "status timeline" attribute is maintained on the order entity, and the aggregated comprehensive response category (for example, it can be a structured JSON object containing the response category and timestamp of each work order) is written into this timeline as a new event record. In addition, once the comprehensive response categories of all work order entities are determined, the system can trigger an "order response summary" event. This event carries the response information of all work orders and is sent to the order management module through a message queue. After receiving the message, the order management module is responsible for parsing the information, formatting it, and updating the corresponding order entity attributes in the order status timeline database or knowledge graph. During the aggregation process, the comprehensive response categories can also be aggregated hierarchically. For example, it can be used to count how many work orders under an order need "automatic parameter synchronization update" and how many need "rework warning". This aggregated information can be further written into the order status timeline and combined with a visualization interface to intuitively display the overall health status of the order and the key points that need attention in the form of charts or dashboards.

[0167] The above technical solutions address the problem that, after a design change, the results of forward impact determination and compliance retrospective determination exist independently and lack correlation at the work order level, making it impossible to collaboratively generate accurate work order-level response plans and to systematically summarize them by order dimension. For example, by pairing forward and retrospective determination conclusions at the work order level, accurate alignment of different analysis results at the smallest granularity is ensured, avoiding mismatches in subsequent analyses and laying a solid foundation for comprehensive decision-making. Determining the comprehensive response category of work order entities based on collaborative determination rules fully integrates the impact of design changes on future processes and the compliance status of existing process adjustments, thereby generating more accurate and comprehensive work order-level response suggestions than single analysis results, making production decisions more targeted and effective. By summarizing the comprehensive response categories of all work order entities and writing them into the order status timeline along the association path between component entities and order entities in the dynamic process knowledge graph, dispersed work order-level response information is aggregated to the order level and presented in a structured, time-ordered manner. This enables production managers to intuitively and comprehensively grasp the impact of design changes on the entire order and the necessary countermeasures, greatly improving the transparency and efficiency of order production control, truly realizing data connectivity throughout the entire steel structure order manufacturing process, and providing accurate and effective basis for order production control.

[0168] This application further proposes a dual-path determination combination for each work order dimension. Based on the collaborative determination rules of the forward determination conclusion and the backtracking determination conclusion, the comprehensive response category of the corresponding work order entity is determined. Specifically, this includes: extracting the impact level of the work order entity from the forward determination conclusion; extracting the adjustment record compliance attribution type of the work order entity from the backtracking determination conclusion; and determining the comprehensive response category of the work order entity based on the collaborative determination matrix and the combination of the impact level and the adjustment record compliance attribution type. The comprehensive response category includes at least: automatic parameter synchronization update, pushing readjustment suggestions while maintaining the current adjustment basis, and triggering a rework warning and requiring the reconstruction of the adjustment basis.

[0169] To accurately assess the impact of design changes on each work order entity, this application extracts the impact level of the work order entity from the forward impact assessment results. This level aims to quantify the impact of design changes on a specific work order entity, thereby providing crucial information for subsequent response decisions. For example, a pre-defined rule engine can be used to classify the impact level into different levels, such as "high," "medium," "low," or "severe," "moderate," and "minor," based on the process response category indicated in the forward impact assessment results (e.g., process suspension, rework assessment, etc.) and the execution progress of the associated work order entity (e.g., not started, in progress, completed). Alternatively, a machine learning model can be trained to automatically assess and output a quantified impact score, combining the actual processing results of work orders in historical design change cases with forward impact analysis data, and then mapping the score to a predefined level.

[0170] To gain a deeper understanding of the root causes of compliance issues in historical process adjustments, this application extracts the compliance attribution type of the work order entity's adjustment records from the retrospective determination conclusions. This type aims to identify the fundamental reasons for non-compliance in the work order entity's historical process adjustments, providing a historical adjustment-level basis for developing targeted response strategies. Specifically, pre-defined attribution tags can be directly read from the compliance retrospective determination results, such as "based on invalid basis as the primary factor," "insufficient adjustment range as the primary factor," or "adjustment still compliant." These tags are generated by fusing the causal relationship determination results and parameter compliance determination results during the retrospective determination process. Alternatively, semantic analysis techniques can be used to parse the textual descriptions in the retrospective determination conclusions, identify the key factors leading to non-compliance, and categorize them into predefined attribution types, such as "design parameter changes causing the original basis to be inapplicable," "process personnel adjusting too much / too little," and "new constraint range tightening."

[0171] To systematically integrate forward impact and retrospective attribution information, this application uses a collaborative determination matrix to determine the comprehensive response category of a work order entity based on a combination of the impact level and the adjustment record compliance attribution type. This matrix, as a decision-making tool, can systematically match results from two different sources, thereby avoiding biases caused by single-dimensional decision-making and making response decisions more consistent with the actual state of the current process. For example, the collaborative determination matrix can be a two-dimensional lookup table, where rows represent different "impact levels" (e.g., high, medium, low), and columns represent different "adjustment record compliance attribution types" (e.g., invalid basis, insufficient adjustment, still compliant). Each cell of the matrix predefines a corresponding "comprehensive response category." During system runtime, the system directly queries the matrix to obtain the results based on the extracted level and type. Alternatively, the collaborative determination matrix can also be implemented using a set of rule-based expert systems, for example, defining a series of rules such as "IF [impact level] IS X AND [attribution type] IS Y THEN [comprehensive response category] IS Z." When the level and type are input, the rule engine traverses these rules, finds matching rules, and outputs the corresponding comprehensive response category.

[0172] To provide clear and actionable response guidelines, this comprehensive response category includes at least: automatic parameter synchronization and updates, pushing readjustment suggestions while maintaining the current adjustment basis, and triggering rework warnings and requiring the reconstruction of adjustment basis. These categories cover different scenarios, from those requiring no manual intervention to those requiring in-depth manual processing, ensuring the comprehensiveness and relevance of the response. For example, when the work order entity is minimally affected and the adjustment record is compliant, the system can automatically synchronize the updated constraint parameter values ​​to the process parameter field of the work order, achieving automatic parameter synchronization and updates without manual intervention. When the work order entity is moderately affected and the adjustment record is attributed to insufficient adjustment range, the system pushes suggested adjustment range and direction to process engineers and prompts them to make fine adjustments based on the existing adjustment basis, i.e., pushing readjustment suggestions while maintaining the current adjustment basis. When the work order entity is highly affected and the adjustment record is attributed to invalid basis, the system issues a high-level warning and forces process engineers to reassess and establish new adjustment basis, even involving rework, i.e., triggering rework warnings and requiring the reconstruction of adjustment basis. In addition to the above three, it can also include "notification for observation only," "manual review and confirmation," and "production suspension pending decision" to cover a wider range of actual production scenarios.

[0173] The above technical solution combines forward impact information from design changes with retrospective attribution information from existing process adjustments to collaboratively deduce the appropriate response category for each work order entity, thus solving the problem of inaccurate single-dimensional decision-making. For example, extracting the impact level of a work order entity from forward determination conclusions accurately grasps the magnitude of the impact of design changes on each work order entity, providing core evidence at the impact level for subsequent response decisions and avoiding decisions that are divorced from the actual impact of design changes. Extracting the compliance attribution type of adjustment records for work order entities from retrospective determination conclusions provides evidence at the historical level of existing adjustments, clarifying the root causes of non-compliance and avoiding the problem of only considering the impact of current design changes while ignoring the actual situation of existing adjustments. Based on the collaborative determination matrix, determining the comprehensive response category of the corresponding work order entity according to the combination of impact level and compliance attribution type of adjustment records allows for systematic matching of results from two different sources, avoiding biases caused by single-dimensional decision-making and making response decisions more consistent with the actual state of the current process. The system clearly defines different levels of comprehensive response categories, covering scenarios ranging from those requiring no human intervention to those requiring in-depth human processing. The response requirements for each category are clear and explicit, enabling automated processing of low-risk scenarios as well as providing clear manual processing guidelines for high-risk scenarios. This facilitates quick action by relevant personnel and provides clear and accurate information for subsequent summarization into the order status timeline, ensuring the accuracy of the comprehensive response strategy after design changes and effectively supporting the seamless integration of data throughout the entire manufacturing process.

[0174] The following example will provide a more detailed explanation of the above technical solution: In a steel bridge component manufacturing scenario, there exists a manufacturing order involving the welding of a specific box girder. The original design requirements for this box girder are: fillet weld type, Q345B material grade, and 20mm plate thickness.

[0175] The system injects personalized constraint parameter values ​​derived from the welding process knowledge base based on the manufacturing semantics of steel structure components into the process constraint rules deployed on the process execution association paths in the dynamic process knowledge graph, thus instantiating the process constraint rules into executable constraint benchmarks. For example, the system extracts weld type, material grade, and plate thickness parameters from the manufacturing semantic information carried by the component entities in the dynamic process knowledge graph as inference conditions. For instance, by performing node structure analysis on the steel structure detailed design model file associated with the component entities, traversing the component nodes and the weld nodes associated with the component nodes, the system extracts the material grade Q345B and plate thickness 20mm from the component nodes, and extracts the weld type (fillet weld) and welding process requirements (e.g., penetration depth not less than 5mm) from the weld nodes. The system organizes this information into structured inference conditions, carrying the manufacturing semantic association between the weld and the base material. The system then matches and infers these inference conditions with the welding process rules stored in the welding process knowledge base. For example, the matching "Q345B material, 20mm thick fillet weld" corresponds to a welding current range of 250A-300A and a preheating temperature range of 100℃-120℃. The system performs consistency checks on multiple matching rules and selects the rule with the highest fit. Along the process execution path, these constraint parameter values ​​(such as welding current 250A-300A, preheating temperature 100℃-120℃) are written into the constraint parameter field of the corresponding work order entity, and a reference binding relationship is established between the constraint parameter field and the process constraint rule. This allows the process constraint rule to obtain a specific numerical benchmark and be instantiated as an executable constraint benchmark. This solves the problem in related technologies where knowledge graph reasoning only recommends parameters rather than generating constraint benchmarks.

[0176] During the actual welding process of the box girder, user A, a process engineer, discovered that the welding spatter was slightly larger due to slight differences in the welding performance of the current batch of steel. Based on experience, user A implicitly adjusted the welding current from the theoretical set value of 280A to 270A. The system, based on executable constraint benchmarks, identifies process parameter adjustment behavior from the time-series data of the steel structure welding process. Specifically, the system extracts the constraint range of each process parameter (e.g., welding current 250A-300A) from the executable constraint benchmarks and marks the deviation state of the actual values ​​of the process parameters at each acquisition time in the time-series data based on the constraint range. When the system detects that the deviation direction mark of the welding current flips from "within constraint" to "downward overflow" (relative to the original set value of 280A), and the duration of the "downward overflow" state exceeds the preset minimum maintenance duration (e.g., 5 minutes), it determines that a process parameter adjustment behavior has occurred. The system uses the steady-state value of 280A before the flip, the steady-state value of 270A after the flip, and the time when the state flip occurred as the identification results.

[0177] The system converts the identification results into adjustment records automatically verified by process deviation adjustment rules. The system extracts the adjustment parameter name (welding current), the steady-state value before adjustment (280A), the steady-state value after adjustment (270A), and the time of adjustment from the identification results. It then combines this with the adjustment basis description corresponding to the adjustment parameter name (e.g., "Differences in steel batch performance lead to large spatter") and the conduction constraint description (e.g., "Reduced welding current affects penetration") to generate an initial adjustment record. The system triggers process deviation adjustment rules to perform an integrity check on the initial adjustment record, verifying that all required fields are filled and conform to data format constraints, and performing semantic consistency cross-validation. After the integrity check passes, the system triggers process deviation adjustment rules to perform a compliance check on the initial adjustment record, checking whether the adjustment range (10A) of the steady-state value after adjustment (270A) relative to the steady-state value before adjustment (280A) exceeds the allowable adjustment range defined in the process deviation adjustment rules (e.g., allowable adjustment range is ±5%). If it does not exceed this range, the initial adjustment record is determined to be compliant, and an adjustment record with a compliance flag is generated. This solves the problem that implicit adjustment records of process deviations in related technologies are not included as an independent data type in the overall system.

[0178] Several weeks later, a design change event occurred for the box girder component. Due to bridge structural optimization, the plate thickness of the box girder increased from 20mm to 22mm, while the material grade remained unchanged. In response to the component design change event, the system re-inferred updated constraint parameter values ​​based on the changed component manufacturing semantics (weld type: fillet weld, material grade: Q345B, plate thickness: 22mm). For example, the new welding current constraint range became 260A-310A, and the preheating temperature range became 110℃-130℃.

[0179] Based on the updated constraint parameter values, the system performs a compliance backtracking determination on User A's adjustment records. The system triggers the embedded rules for the correlation between adjustment basis and design parameters within the process deviation adjustment rules, extracting the adjustment basis description "large spatter due to batch performance differences in steel" from the adjustment records, and parsing the referenced design parameter conditions (e.g., original plate thickness 20mm). The system compares the original value condition (plate thickness 20mm) with the corresponding changed value (plate thickness 22mm) in the modified component manufacturing semantics. Since the original plate thickness condition of 20mm is no longer met, the system generates a causal correlation determination result indicating the adjustment basis failure. Using the updated constraint parameter values ​​(welding current 260A-310A) as a benchmark, the system re-determines the compliance of the adjusted steady-state value of 270A recorded in the adjustment records. The system integrates the causal correlation determination result (adjustment basis failure) with the parameter compliance determination result (parameters still compliant), generating a compliance backtracking determination result carrying a dominant marker of basis failure. This solves the problem that when design changes occur to steel structure components, the implicit process adjustments that have already taken place cannot be automatically traced back to verify their compliance under the new design conditions along the manufacturing semantic constraints.

[0180] The system determines the forward impact along the process execution path. Starting with the modified component (box girder) entity in the dynamic process knowledge graph, the system traverses the process execution path to locate all related work order entities with manufacturing dependencies on the modified component. For example, the system identifies subsequent "box girder assembly work order" and "bridge section final assembly work order". The system triggers process constraint rules, updates constraint parameter values ​​as the updated executable constraint benchmark, and re-verifies the process constraint conditions of each related work order entity. For example, for the "box girder assembly work order", the system checks whether its executed welding parameter records still comply with the updated constraints. Based on the execution progress information of each related work order entity (e.g., "box girder assembly work order" is an in-progress work order, "bridge section final assembly work order" is an unstarted work order) and constraint compliance status, the system generates the forward impact determination result. For example, if the constraint compliance status of the "box girder assembly work order" is non-compliant, the system determines the trigger process pause response category.

[0181] The system intersects the results of forward impact determination with the results of compliance retrospective determination to generate a comprehensive response strategy for manufacturing work orders. The system extracts the forward determination conclusions for each related work order entity from the forward impact determination results and the retrospective determination conclusions for the corresponding work order entity from the compliance retrospective determination results. It then pairs the forward and retrospective determination conclusions at the work order level, forming a dual-path determination combination at the work order dimension. For example, for a box girder welding work order, its retrospective determination conclusion is "based on failure as the dominant factor," and its forward determination conclusion is "no direct impact." Based on the collaborative determination matrix, the system determines the comprehensive response category for the corresponding work order entity according to the combination of the impact level and the compliance attribution type of the adjustment record. For example, for a box girder welding work order, the system determines the comprehensive response category as "triggers rework warning and requires reconstruction of the adjustment basis." For a "box girder assembly work order," if its forward determination conclusion is "triggers process suspension," and its retrospective determination conclusion is "not applicable," then the comprehensive response category is "process suspension and awaiting new process guidance." The system aggregates the comprehensive response categories of all work order entities and writes these categories into the order status timeline along the association path between component entities and order entities in the dynamic process knowledge graph. This makes process adjustments no longer untraceable breakpoints relative to design changes, achieving seamless data flow throughout the entire manufacturing process.

[0182] All of the above-mentioned optional technical solutions can be combined in any way to form the optional embodiments of this application, and will not be described in detail here.

[0183] The above are merely optional embodiments of this application and are not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for data integration across the entire manufacturing process for steel structure orders, characterized in that, The method includes: The personalized constraint parameter values ​​derived from the welding process knowledge base based on the semantic reasoning of steel structure component manufacturing are injected into the process process constraint rules deployed on the process execution association path in the dynamic process knowledge graph, thereby instantiating the process process constraint rules into executable constraint benchmarks. Based on the executable constraint benchmark, process parameter adjustment behavior is identified from the time sequence data of steel structure welding process, and the identification results are converted into adjustment records that are automatically verified by process deviation adjustment rules. In response to a component design change event, the updated constraint parameter values ​​are obtained by re-inferring based on the changed component manufacturing semantics. Based on the updated constraint parameter values, compliance backtracking is performed on the adjustment records, and forward impact determination is performed along the associated path of the process. The results of the forward impact determination and the compliance backtracking determination are intersected to generate a comprehensive response strategy for manufacturing work orders. The comprehensive response strategy is summarized in the order status timeline.

2. The method according to claim 1, characterized in that, The process of injecting personalized constraint parameter values ​​derived from the welding process knowledge base based on the semantic reasoning of steel structure component manufacturing into the process process constraint rules deployed on the process execution association path in the dynamic process knowledge graph, thereby instantiating the process process constraint rules into executable constraint benchmarks, includes: Weld type, material grade and plate thickness parameters are extracted from the manufacturing semantic information carried by the component entities in the dynamic process knowledge graph as inference conditions. The reasoning conditions are matched and reasoned with the welding process rules stored in the welding process knowledge base to obtain the constraint parameter values ​​of each process stage corresponding to the component entity. Execute the associated path along the process, write the constraint parameter values ​​of each process stage into the constraint parameter field of the corresponding work order entity, and establish a reference binding relationship between the constraint parameter field and the process constraint rule, so that the process constraint rule obtains a specific numerical benchmark and is instantiated into the executable constraint benchmark.

3. The method according to claim 2, characterized in that, The step of extracting weld type, material grade, and plate thickness parameters as inference conditions from the manufacturing semantic information carried by the component entities in the dynamic process knowledge graph includes: The node structure of the steel structure detailed design model file associated with the component entity is parsed, and the component nodes and the weld nodes associated with the component nodes are traversed. Extract the material grade and plate thickness parameters from the component nodes, and extract the weld type and welding process requirements from the weld nodes; The weld type, material grade, plate thickness parameters, and welding process requirements are organized into structured reasoning conditions, which carry the manufacturing semantic association between the weld and the base material.

4. The method according to claim 1, characterized in that, The step of identifying process parameter adjustment behaviors from the timing data of steel structure welding processes based on the executable constraint benchmark includes: The constraint intervals of each process parameter are extracted from the executable constraint benchmark, and the actual values ​​of the process parameters at each acquisition time in the time series data are marked with deviation status based on the constraint intervals to obtain time series data with deviation direction markings. The timing data carrying the deviation direction marker is subjected to state flip detection. When it is detected that the deviation direction marker flips from the first deviation direction to the second deviation direction and the duration of the second deviation direction after the flip exceeds the preset minimum duration, it is determined that a process parameter adjustment behavior has occurred. The steady-state values ​​of the process parameters corresponding to the deviation state before the flip, the steady-state values ​​of the process parameters corresponding to the deviation state after the flip, and the time when the state flip occurred are used as the identification results.

5. The method according to claim 1, characterized in that, The process of converting the identification results into adjustment records that are automatically verified by process deviation adjustment rules includes: Extract the adjustment parameter name, steady-state value before adjustment, steady-state value after adjustment, and adjustment time from the identification results, and generate an initial adjustment record by combining the adjustment basis description and conduction constraint description corresponding to the adjustment parameter name; The process deviation adjustment rule is triggered to perform an integrity check on the initial adjustment record, checking whether the adjustment parameter name, the steady-state value before adjustment, the steady-state value after adjustment, the adjustment time, the adjustment basis description, and the transmission constraint description in the initial adjustment record have all been filled in; After the integrity check passes, the process deviation adjustment rule is triggered to perform a compliance check on the initial adjustment record, checking whether the adjustment range of the adjusted steady-state value relative to the unadjusted steady-state value exceeds the allowable adjustment range defined in the process deviation adjustment rule, and generating the adjustment record carrying a compliance mark.

6. The method according to claim 1, characterized in that, The compliance backtracking determination of the adjustment record based on the updated constraint parameter value includes: Trigger the embedded adjustment basis and design parameter correlation rules in the process deviation adjustment rules, extract the adjustment basis description from the adjustment record, and trace the causal consistency between the design parameter conditions referenced in the adjustment basis description and the changed component manufacturing semantics to obtain the causal correlation determination result. Based on the updated constraint parameter value, the compliance of the adjusted steady-state value recorded in the adjustment record is re-determined to obtain the parameter compliance determination result; By integrating the causal relationship determination result with the parameter compliance determination result, a compliance backtracking determination result carrying a causal attribution label is generated. The causal attribution label is used to distinguish whether the non-compliance situation stems from the failure of the adjustment basis or the insufficient adjustment magnitude.

7. The method according to claim 6, characterized in that, The step of re-determining the compliance of the adjusted steady-state values ​​recorded in the adjustment record based on the updated constraint parameter values ​​to obtain the parameter compliance determination result includes: Extract the modified theoretical setting value associated with the adjustment parameter name corresponding to the adjustment record from the modified component manufacturing semantics, and use the modified theoretical setting value as the redefined reference center; A compliance interval is constructed around the reference center using the allowable offset range defined in the updated constraint parameter values. The adjusted steady-state value is compared with the compliance interval to determine whether the adjusted steady-state value is within the compliance interval. When the determination is non-compliant, the deviation direction and deviation amount of the adjusted steady-state value relative to the compliance range are calculated, and a parameter compliance determination result carrying the deviation direction and the deviation amount is generated.

8. The method according to claim 1, characterized in that, The determination of forward influence along the associated path of the process includes: Starting with the component entity of the modified component in the dynamic process knowledge graph, the associated path is traversed along the process to locate all associated work order entities that have a manufacturing dependency relationship with the modified component. Trigger the process constraint rules, use the updated constraint parameter values ​​as the updated executable constraint benchmark, re-verify the process constraint conditions of each associated work order entity, and obtain the constraint compliance status of each associated work order entity. Based on the execution progress information of each associated work order entity and the constraint compliance status, a forward impact determination result is generated. The forward impact determination result is used to indicate the required process response category for each associated work order entity under the component design change event.

9. The method according to claim 8, characterized in that, Starting with the component entity of the modified component in the dynamic process knowledge graph, the process traverses the associated path along the process to locate all associated work order entities that have a manufacturing dependency relationship with the modified component, including: Obtain the component entity corresponding to the changed component from the dynamic process knowledge graph, and extract the component identifier of the component entity; Starting from the component identifier, the search extends outward along the process execution association path between the component entity and the work order entity, collecting all work order entities that have a direct reference relationship with the component identifier; Simultaneously, based on the assembly dependency relationship between component entities in the dynamic process knowledge graph, the downstream component entity that is the pre-assembly component of the changed component is located, and the work order entity associated with the downstream component entity is included in the set of associated work order entities.

10. The method according to claim 1, characterized in that, The method of intersecting the forward impact determination results with the compliance backtracking determination results to generate a comprehensive response strategy for manufacturing work orders includes: The forward determination conclusions of each associated work order entity are extracted from the forward influence determination results, and the backtracking determination conclusions of the corresponding work order entity are extracted from the compliance backtracking determination results. The forward determination conclusions and the backtracking determination conclusions are paired at the work order level to form a dual-path determination combination at the work order dimension. For each of the two-way determination combinations of the work order dimensions, the comprehensive response category of the corresponding work order entity is determined based on the collaborative determination rule of the forward determination conclusion and the backtracking determination conclusion. The comprehensive response categories of all the work order entities are summarized, and the comprehensive response categories are written into the order status timeline along the association path between component entities and order entities in the dynamic process knowledge graph to obtain the comprehensive response strategy.

Citation Information

Patent Citations

  • Automobile wire harness process rule automatic matching method based on knowledge graph

    CN121542440A

  • Whole-process quality traceability data association method and system

    CN122088828A