Nuclear facility work ticket management system and method across legal person institutions

Abstract

The invention belongs to the technical field of nuclear facility operation, maintenance and management, and particularly relates to a system and a method for managing work tickets of nuclear facilities across legal person institutions. Comprising a work ticket management module, a data authority control module, an AI work order generation module and a dependency rule management module. The method has the beneficial effects that the problems of low cooperation efficiency, authority conflict and data isolation compliance challenge faced by work ticket management in the nuclear facility field and under an independent legal person main body coexistence architecture are effectively solved, and the limitation of a general multi-tenant model in a specific complex business scene is overcome. According to the method, the work order management efficiency and compliance in a complex scene can be remarkably improved.

Description

Technical Field

[0001] This invention belongs to the field of nuclear facility operation and maintenance management technology, specifically relating to a nuclear facility work permit management system and method that spans multiple legal entities. Background Technology

[0002] As enterprises continue to develop and expand, a two-tier management structure of head office and branch offices has become the organizational structure for most companies, with each branch office operating as an independent legal entity. In the field of operation and maintenance management of nuclear facilities (such as nuclear power plants), branch offices, as independent legal entities, can independently operate their own work management business, while also accepting work tasks assigned by the head office; moreover, work management also has data access restrictions, with the head office able to view all branch office data, while branch offices are limited to their own data, and data is isolated between independent legal entities. Summary of the Invention

[0003] The purpose of this invention is to provide a nuclear facility work order management system and method that spans multiple legal entities, capable of handling complex business operations similar to those currently being managed across multiple legal entities, and effectively solving problems such as low efficiency and permission conflicts in traditional work order collaboration.

[0004] The technical solution of the present invention is as follows: a nuclear facility work order management system that spans multiple legal entities, including a work order management module, a data access control module, an AI work order generation module, and a dependency rule management module;

[0005] The work order management module is responsible for the creation, allocation, status tracking and completion management of work orders, and supports three-level work order processes and associated sub-orders and auxiliary orders; based on the business rule engine, it realizes the hierarchical flow and state machine management of work orders.

[0006] The data access control module isolates data, ensuring that the head office can view all data, while branch offices can only view their own data, thus meeting compliance requirements in the nuclear facilities field. A company_id field is designed in the database table structure for data sharding. The backend automatically intercepts SQL queries in all data query interfaces, appending the company_id condition of the current user's branch office, and dynamically controls permissions based on business rules.

[0007] The AI ​​work order generation module automatically parses unstructured text and generates structured work orders, including identifying work order level, nature, and dependencies. It uses a BERT model for fine-tuning, extracts and classifies features from the input text, and outputs work order type and level. At the same time, it uses a graph neural network to construct a task dependency graph and uses a graph attention network to calculate node features and dependency weights.

[0008] The dependency rule management module defines and validates business rules for work ticket dependencies, ensuring that the hierarchy and collaboration relationships meet the requirements, stores hard constraints, and provides a dynamic validation interface. When validating the dependency matrix, it automatically triggers correction logic.

[0009] The work order includes the original work order, sub-work order, and auxiliary work order. Each work order contains fields such as work order code, work order level, company ID, risk factor, and estimated working hours. It accepts user input and data generated by AI-driven work orders, and is protected by a data permission module to ensure legal entity filtering during queries.

[0010] A method for managing work permits for nuclear facilities that spans multiple legal entities includes the following steps:

[0011] Step 1: Design of the semantic parsing model;

[0012] Step 2: Graph Neural Network Design;

[0013] Step 3: Define dependency rules and constraints.

[0014] In step 1, the semantic parsing model extracts the work order type and level from the text data, and uses BERT as the base model to fine-tune the classification task.

[0015] Text feature vectorization: H = BERT(x) ∈ R d

[0016] Where x is the input text, and d is the hidden layer dimension, set to 768.

[0017] Classification layer: P(y) i |x)=Softmax(W i H+b i )

[0018] Among them, y i For the i-th output label, W i b i These are the training parameters.

[0019] In step 2, the graph neural network is used to construct a dependency graph between tasks, ensuring that the completion conditions of the upper-level work ticket are bound to the status of the lower-level work ticket, including graph structure definition and graph attention network computation.

[0020] The process of defining the graph structure in step 2 is as follows:

[0021] In a graph neural network, a node is defined as each work ticket, and the node features h. i = [Work order level ∈ {1, 2, 3}, risk coefficient ∈ [0, 1], estimated working hours ∈ R] + Edges are used to represent dependencies, such as e.ij This indicates that task j depends on task i for completion.

[0022] The graph attention network calculation in step 2 includes:

[0023] Node feature transformation, performing a linear transformation on each node feature: z i =W·h i , W∈R d`×d Where d = 3, which is the original feature dimension of the node, and d' is the hidden layer dimension, which is set to 32;

[0024] Calculate the attention weights of neighboring nodes j of node i: e ij =LeakyReLU(a T ·[z i ||z j ]), where a is the training parameter;

[0025] To normalize the attention weights, perform softmax normalization on all neighboring nodes of node i:

[0026] node h i renew: The final output dependency weight matrix: A = [a ij ].

[0027] Step 3 introduces a hard constraint and a dynamic verification mechanism. The hard constraint, based on business requirements, requires that a first-level work ticket must have a second-level sub-ticket, and a second-level work ticket must have a third-level sub-ticket; the auxiliary ticket level must be consistent with the original ticket, and it must be bound to the original ticket in a dependency relationship. The dynamic verification mechanism mainly verifies whether the output dependency matrix meets the hard constraint. If it does not meet the constraint, an alarm is triggered and automatic correction is performed. That is, if the first-level / second-level work ticket has no sub-ticket, a default sub-ticket is automatically generated, and the adjustment right for the original ticket and auxiliary ticket levels that are inconsistent is reset to zero.

[0028] The beneficial effects of this invention are: it effectively solves the challenges of low collaboration efficiency, permission conflicts, and data isolation compliance in work order management under the coexistence of independent legal entities in the nuclear facility field, and overcomes the limitations of the general multi-tenant model in this specific complex business scenario. This method can significantly improve the efficiency and compliance of work order management in complex scenarios. Attached Figure Description

[0029] Figure 1 This is a diagram of the work order system for cross-legal entity work management;

[0030] Figure 2 This is a flowchart of a method for managing work permits for nuclear facilities that spans multiple legal entities, provided by the present invention. Detailed Implementation

[0031] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0032] A nuclear facility work order management system that spans multiple legal entities includes a work order management module, a data access control module, an AI work order generation module, and a dependency rule management module.

[0033] The work order management module is responsible for the creation, allocation, status tracking, and completion management of work orders (including original orders, sub-orders, and auxiliary orders). It supports a three-level work order process (level 1, 2, and 3) and associated sub-orders and auxiliary orders; based on a business rule engine, it implements hierarchical flow and state machine management of work orders. Each work order includes fields such as work order code, work order level, company ID (company_id), risk coefficient, and estimated working hours. It accepts user input and data generated by AI-driven work orders, and is protected by a data permission module to ensure legal entity filtering during queries.

[0034] The data access control module implements strict data isolation, ensuring that the head office can view all data, while branch offices can only view their own data, meeting compliance requirements in the nuclear facilities field. The main design element is the `company_id` field in the database table structure, used for data sharding. The backend automatically intercepts SQL queries in all data query interfaces, appending the `company_id` condition of the current user's branch office (head office users skip this logic). Access is dynamically controlled based on business rules.

[0035] The AI ​​work order generation module automatically parses unstructured text (such as work defect descriptions) and generates structured work orders, including identifying core elements such as work order level, nature, and dependencies. It uses a BERT model for fine-tuning, extracts and classifies features from the input text, and outputs work order type, level, etc. At the same time, it uses a graph neural network to construct a task dependency graph and uses a graph attention network to calculate node features and dependency weights.

[0036] The dependency rule management module defines and validates business rules for work ticket dependencies, ensuring that the hierarchy and collaboration relationships meet requirements. It stores hard constraints (such as a first-level work ticket must have a second-level sub-ticket, and auxiliary tickets must be at the same level as the original ticket) and provides a dynamic validation interface. When validating the dependency matrix, it automatically triggers correction logic.

[0037] Cross-corporate work management model:

[0038] Work ticket

[0039] Hierarchy and Process:

[0040] ■ Level 1 Work Order (Headquarters → Branch): Issued by the head office, received and assigned to the branch office as a Level 2 work order. After all Level 2 work orders are completed, the branch office submits a completion application to the head office.

[0041] ■ Level 2 Work Order (Branch Office → Workshop): After the workshop completes the work package and on-site preparation, the workshop accepts the work order.

[0042] Then, three levels of work permits were assigned.

[0043] ●Level 3 Work Permit (Workshop → Team): After the team completes the preparatory work, it applies for a scheduling plan.

[0044] ●Data permissions: The head office can view all data of all branches, while branches are limited to their own data, and data is isolated between independent legal entities.

[0045] Work ticket auxiliary ticket

[0046] ● Function: To coordinate with the original invoice and issue collaborative tasks to other units; the level of the document is consistent with the original invoice. ● Collaboration Process: The person in charge of the original invoice coordinates the execution of the supplementary invoice and needs to fill in the relevant information in both the original and supplementary invoices.

[0047] For example, the auxiliary tickets for a primary work order require coordination between the head office and branch offices to ensure data access compliance.

[0048] Work ticket

[0049] ● Function: A document used by the original unit to assign tasks to a lower level. It is one level lower than the original document. Only one sub-document can be generated from one original document, but auxiliary documents can be issued simultaneously.

[0050] ● Basis for Completion: The completion status of sub-tickets and auxiliary tickets serves as the basis for the completion of the original ticket. For example, a sub-ticket of a first-level work order is a second-level work order, and its completion status directly affects the completion application of the first-level work order.

[0051] Key process and permission design:

[0052] 1. Work Completion Conditions

[0053] ●The completion of the superior work order requires the completion of all associated sub-tickets and auxiliary tickets.

[0054] 2. Data access control design

[0055] ●Headquarters Perspective: View all branch offices' first-level, second-level, and third-level work orders and related auxiliary / sub-orders. ●Branch Office Perspective: Only view work orders for the branch office; cross-branch collaboration requires generating auxiliary orders through the head office to ensure data isolation.

[0056] 3. Collaborative scenario handling:

[0057] ● Cross-branch collaboration: When collaboration is required between independent legal entity branches (such as branch A and branch B), the head office coordinates through the auxiliary ticket of the first-level work order, and the branches do not directly share data.

[0058] ● Sub-ticket and auxiliary ticket association: The auxiliary ticket of a sub-ticket must be of the same level as the original ticket. For example, the sub-ticket of a level 2 work order is level 3.

[0059] Its auxiliary tickets are also of level three.

[0060] Data access control model design:

[0061] To meet the stringent data isolation requirements and collaboration rules among independent legal entities in the nuclear facility sector, this invention establishes a data access control module to implement these requirements. Firstly, in the work management data structure design, a `company_id` field is set for each table, and this field is used for database sharding. This design deeply serves the cross-legal entity work order business model of nuclear facilities. Its core lies in identifying independent legal entities through `company_id` and ensuring that when querying data, the backend intercepts SQL queries, automatically appending the current user's branch company to all data query interfaces. If the current user belongs to the head office, this logic is skipped. This is fundamentally different from general multi-tenant isolation technology, which typically does not involve such complex dynamic access control based on business rules (such as work order hierarchy, type, and collaboration process).

[0062] Based on the work order business model designed above, this invention also proposes an AI-driven intelligent work ticket generation method, which mainly parses unstructured work defect description text into structured work tickets and sub / auxiliary tickets, and identifies core elements such as work ticket level (level 1, level 2, level 3), work ticket nature (original ticket, sub-ticket, auxiliary ticket), dependencies between tasks, and collaboration requirements.

[0063] like Figure 2 As shown, a method for managing work permits for nuclear facilities that spans multiple legal entities includes the following steps:

[0064] Step 1: Semantic parsing model design

[0065] The semantic parsing model extracts key information such as work order type and level from text data. BERT is used as the base model, with fine-tuning for the classification task.

[0066] Text feature vectorization: H = BERT(x) ∈ R d

[0067] Where x is the input text, and d is the hidden layer dimension, set to 768.

[0068] Classification layer: P(y) i |x)=Softmax(W i H+b i )

[0069] Among them, y i For the i-th output label, Wi b i These are the training parameters.

[0070] Step 2: Graph Neural Network Design

[0071] Graph neural networks are used to construct dependency graphs between tasks, ensuring that the completion conditions of higher-level work tickets are bound to the status of lower-level work tickets. This includes graph structure definition and graph attention network computation.

[0072] The process of defining a graph structure is as follows:

[0073] In a graph neural network, node Nod e Defined as each work ticket, node feature h i = [Work order level ∈ {1, 2, 3}, risk coefficient ∈ [0, 1], estimated working hours ∈ R] + Edges are used to represent dependencies, such as e. ij This indicates that task j depends on task i for completion.

[0074] Graph attention network computation includes:

[0075] Node feature transformation, performing a linear transformation on each node feature: z i =W·h i , W∈R d`×d Where d = 3, which is the original feature dimension of the node, and d' is the hidden layer dimension, which is set to 32.

[0076] Calculate the attention weights of neighboring nodes j of node i: e ij =LeakyReLU(a T ·[z i ||z j ]), where a is the training parameter.

[0077] To normalize the attention weights, perform softmax normalization on all neighboring nodes of node i:

[0078] node h i renew: The final output dependency weight matrix: A = [a ij ].

[0079] Step 3: Define dependency rules and constraints

[0080] To ensure that the generated dependencies conform to business rules, this invention also introduces hard constraints and a dynamic verification mechanism. The hard constraints, based on business requirements, stipulate that a first-level work ticket must have a second-level sub-ticket, and a second-level work ticket must have a third-level sub-ticket; the auxiliary ticket level must be consistent with the original ticket, and it must be bound to the original ticket as a dependency. The dynamic verification mechanism mainly verifies whether the output dependency matrix meets the hard constraints. If it does not, an alarm is triggered and automatic correction is performed. That is, if a first- or second-level work ticket has no sub-ticket, a default sub-ticket is automatically generated, and the adjustment weight for inconsistent auxiliary ticket levels is reset to zero.

Claims

1. A nuclear facility work permit management system that spans multiple legal entities, characterized in that: It includes a work ticket management module, a data access control module, an AI work order generation module, and a dependency rule management module; The work order management module is responsible for the creation, allocation, status tracking and completion management of work orders, and supports three-level work order processes and associated sub-orders and auxiliary orders; Based on the business rule engine, the hierarchical flow and state machine management of work tickets are realized; The data access control module isolates data, ensuring that the head office can view all data, while branch offices can only view their own data, thus meeting compliance requirements in the nuclear facilities field. A company_id field is designed in the database table structure for data sharding. The backend automatically intercepts SQL queries in all data query interfaces, appending the company_id condition of the current user's branch office, and dynamically controls permissions based on business rules. The AI ​​work order generation module automatically parses unstructured text and generates structured work orders, including identifying work order level, nature, and dependencies. It uses a BERT model for fine-tuning, extracts and classifies features from the input text, and outputs work order type and level. At the same time, it uses a graph neural network to construct a task dependency graph and uses a graph attention network to calculate node features and dependency weights. The dependency rule management module defines and validates business rules for work ticket dependencies, ensuring that the hierarchy and collaboration relationships meet the requirements, stores hard constraints, and provides a dynamic validation interface. When validating the dependency matrix, it automatically triggers correction logic.

2. The nuclear facility work permit management system across legal entities as described in claim 1, characterized in that: The work order includes the original work order, sub-work order, and auxiliary work order. Each work order contains fields such as work order code, work order level, company ID, risk factor, and estimated working hours. It accepts user input and data generated by AI-driven work orders, and is protected by a data permission module to ensure legal entity filtering during queries.

3. A method for managing work permits for nuclear facilities that span multiple legal entities, characterized in that, Includes the following steps: Step 1: Design of the semantic parsing model; Step 2: Graph Neural Network Design; Step 3: Define dependency rules and constraints.

4. The method for managing work permits for nuclear facilities across legal entities as described in claim 3, characterized in that: In step 1, the semantic parsing model extracts the work order type and level from the text data, and uses BERT as the base model to fine-tune the classification task. Text feature vectorization: H = BERT(x) e R d Where x is the input text, and d is the hidden layer dimension, set to 768. Classification layer: P(y i |x) = Softmax(W i H + b i ) where y i is the i-th output label, W i , b i are the training parameters.

5. The method for managing work permits for nuclear facilities across legal entities as described in claim 3, characterized in that: In step 2, the graph neural network is used to construct a dependency graph between tasks, ensuring that the completion conditions of the upper-level work ticket are bound to the status of the lower-level work ticket, including graph structure definition and graph attention network computation.

6. The method for managing work permits for nuclear facilities across legal entities as described in claim 5, characterized in that, The process of defining the graph structure in step 2 is as follows: In the graph neural network, the node Node is defined as each work ticket, and the node feature h i = [work order level ∈ {1, 2, 3}, risk coefficient ∈ [0, 1], and estimated working hours ∈ R + ]; The edge edge is used to represent the dependency relationship, for example, e ij represents that task j depends on the completion of task i.

7. The method for managing work permits for nuclear facilities across legal entities as described in claim 5, characterized in that, The graph attention network calculation in step 2 includes: Node feature transformation, performing a linear transformation on each node feature: z i =W·h i , W∈R d`×d Where d = 3, which is the original feature dimension of the node, and d' is the hidden layer dimension, which is set to 32; Calculate the attention weights of neighboring nodes j of node i: e ij =LeakyReLU(a T ·[z i ||z j ]), where a is the training parameter; To normalize the attention weights, perform softmax normalization on all neighboring nodes of node i: node h i renew: The final output dependency weight matrix: A = [a ij ].

8. The method for managing work permits for nuclear facilities across legal entities as described in claim 3, characterized in that: Step 3 introduces a hard constraint and a dynamic verification mechanism. The hard constraint, based on business requirements, requires that a first-level work ticket must have a second-level sub-ticket, and a second-level work ticket must have a third-level sub-ticket; the auxiliary ticket level must be consistent with the original ticket, and it must be bound to the original ticket in a dependency relationship. The dynamic verification mechanism mainly verifies whether the output dependency matrix meets the hard constraint. If it does not meet the constraint, an alarm is triggered and automatic correction is performed. That is, if the first-level / second-level work ticket has no sub-ticket, a default sub-ticket is automatically generated, and the adjustment right for the original ticket and auxiliary ticket levels that are inconsistent is reset to zero.

Images