An industrial equipment fault knowledge closed loop construction system and method based on automatic precipitation of repair work orders

Abstract

The application discloses an industrial equipment fault knowledge closed loop construction system and method based on automatic precipitation of maintenance work orders, and the system generates a maintenance work order event package by acquiring maintenance work orders, equipment maintenance data and field multi-modal accessory data; then constructs an industrial equipment fault knowledge ontology, and performs parent-child segmentation processing on equipment manuals, maintenance procedures and point inspection standards; then extracts equipment paths, fault phenomena, fault modes, fault causes, disposal measures, spare parts materials, disposal results and evidence sets from closed work orders to form candidate fault knowledge units; then writes credible knowledge into a knowledge graph and a vector retrieval library through vector similarity, equipment path matching, fault mode matching and credibility evaluation; finally, similar cases and disposal measures are recalled when a new work order is generated, and knowledge credibility and retrieval weights are updated according to maintenance results, so that a closed loop of maintenance practice, knowledge precipitation, knowledge reuse and feedback enhancement is realized.

Description

Technical Field

[0001] This invention relates to the fields of intelligent operation and maintenance of industrial equipment, fault knowledge management, maintenance work order data processing and knowledge graph construction, and in particular to a closed-loop construction system and method for industrial equipment fault knowledge based on automatic accumulation of maintenance work orders. Background Technology

[0002] In industrial production sites, equipment maintenance activities are typically recorded in the form of maintenance work orders. These work orders include information such as fault symptoms, alarm codes, maintenance procedures, spare parts replacement, on-site photos, voice instructions, maintenance videos, acceptance results, and recurrence details. As equipment maintenance time increases, the number of maintenance work orders continues to grow, containing a wealth of experience and knowledge related to fault identification, cause localization, selection of corrective measures, and verification of maintenance effectiveness.

[0003] Existing industrial equipment fault knowledge bases primarily rely on manual compilation. Maintenance engineers must manually sift through historical work orders, equipment manuals, and maintenance procedures before manually entering the information into the knowledge base. This method suffers from problems such as long compilation cycles, delayed knowledge updates, inconsistent summarization standards among different personnel, and difficulty in covering continuously added work orders. When equipment types are complex, fault modes are numerous, and the scale of maintenance records is large, manual maintenance knowledge bases struggle to meet the demands of industrial sites for fault response speed and accurate knowledge reuse.

[0004] Some existing solutions employ general document retrieval enhancement generation techniques, segmenting equipment manuals, maintenance documents, or historical records to create vector indexes, and then using semantic retrieval to assist in troubleshooting. However, general segmentation methods typically divide documents according to a fixed number of characters or natural paragraphs, which can easily disrupt the contextual relationships between "equipment type—component—operating conditions—safety constraints—operating procedures" in industrial equipment documents. This results in search results that, while semantically similar, lack applicable equipment boundaries and maintenance scenario constraints, thus affecting the reliability of troubleshooting recommendations.

[0005] Furthermore, existing knowledge retrieval systems are mostly based on static documents or static knowledge bases, failing to automatically convert completed maintenance work orders into reusable knowledge, and failing to fully utilize practical feedback such as maintenance acceptance results, fault recurrence, and downtime to evaluate the effectiveness of knowledge. For multimodal maintenance evidence such as on-site photos, voice recordings, and video clips, existing solutions typically store them only as attachments, lacking a mechanism to convert them into searchable fault tags, maintenance action tags, and evidence features, resulting in a large amount of on-site experience failing to enter the fault knowledge system.

[0006] Therefore, there is an urgent need for a new closed-loop knowledge construction scheme for industrial equipment faults. Summary of the Invention

[0007] In view of this, the purpose of this invention is to propose a closed-loop construction system and method for industrial equipment fault knowledge based on automatic accumulation of maintenance work orders. This solution can access maintenance work orders, extract fault knowledge in a structured manner, verify it in combination with the context of industrial documents, evaluate the credibility of knowledge using maintenance results, and continuously reuse and enhance the feedback in subsequent maintenance processes to construct a closed-loop industrial equipment fault knowledge system.

[0008] To achieve the above-mentioned technical objectives, the technical solution adopted by this invention is as follows: A method for constructing a closed-loop knowledge base for industrial equipment faults based on the automatic accumulation of maintenance work orders includes: S1. Obtain maintenance work order data, equipment maintenance data, and multimodal accessory data at the maintenance site for industrial equipment, and generate maintenance work order event packages with equipment number and work order number as the primary key of association. S2. Perform field normalization, time alignment, industrial terminology standardization, and equipment-level path mapping on the maintenance work order event package, and filter out work orders that can be stored based on work order completeness, work order completion status, and acceptance results. S3. Construct an industrial equipment fault knowledge ontology and establish fault association relationships between various entities; S4. Perform parent-child segmentation on the equipment maintenance documents to obtain the parent-child segmentation result, which includes parent and child segment documents, and make the child segment documents inherit the industrial context identifier of the corresponding parent segment document. S5. Based on the industrial equipment fault knowledge ontology and the parent-child segmentation processing result, extract knowledge from the work order that can be stored, and convert the data in the maintenance work order event package into candidate fault knowledge units. S6. Perform semantic vectorization, device path matching, and fault mode matching on the candidate fault knowledge unit, calculate the comprehensive similarity between the candidate fault knowledge unit and the existing fault knowledge unit, and determine the state of the candidate fault knowledge unit based on the comprehensive similarity. S7. Calculate the knowledge credibility of candidate fault knowledge units based on preset conditions, and write the candidate fault knowledge units that meet the preset requirements into the formal knowledge base according to the knowledge credibility. S8. When a new maintenance work order is generated, retrieve similar fault cases, standard handling procedures, and recommended handling measures from the formal knowledge base, and update the information of the corresponding fault knowledge unit according to the final handling result of the new maintenance work order.

[0009] As one possible implementation, further, in step S1 of this solution, the equipment maintenance data includes equipment ledger data, operation monitoring data, spare parts replacement data, and acceptance result data related to industrial equipment.

[0010] As one possible implementation, further, in step S2 of this solution, the completeness of the work order is calculated in the following manner: in, Indicates the first Completeness of each maintenance work order event package Indicates the first The first in the maintenance work order event package Class field, This represents a field validation function. Indicates the first Importance weights of class fields This indicates the number of field categories; when the completeness of the work order reaches the preset completeness threshold, the work order status is completed, and the acceptance result is passed, the corresponding maintenance work order event package is determined as a work order that can be stored.

[0011] As a possible implementation, further, in step S3 of this solution, the industrial equipment fault knowledge ontology includes equipment type, equipment instance, component, fault phenomenon, fault mode, fault cause, handling measures, spare parts materials, operating parameters, evidence data, and handling results.

[0012] As a possible implementation, further, in step S3 of this solution, the fault association relationship includes at least the relationship between the equipment containing components, the component corresponding to the fault phenomenon, the fault phenomenon corresponding to the fault mode, the fault mode corresponding to the fault cause, the fault cause corresponding to the handling measures, the handling measures corresponding to the spare parts materials, the handling measures corresponding to the handling result, and the maintenance work order verifying the fault knowledge.

[0013] As one possible implementation, further, in step S4 of this solution, the equipment maintenance documents include industrial equipment manuals, maintenance procedures, work instructions, and inspection standards.

[0014] As one possible implementation, the parent document in this solution is used to retain the equipment type, component path, operating scenario and safety constraints, while the child document is used to record the fault phenomenon, detection parameters, operating steps and handling points.

[0015] As a possible implementation, further, in step S4 of this solution, the parent-child segmentation process includes: dividing the parent segment document according to equipment type, component chapter, maintenance operation scenario and safety constraint boundary; dividing the sub-segment document within each parent segment document according to fault phenomenon, detection parameters, operation steps and handling points; and configuring parent segment identifier, equipment type identifier, component path identifier, operation scenario identifier and safety constraint identifier for each sub-segment document.

[0016] As one possible implementation, further, in step S5 of this solution, the fault description, maintenance process, spare parts replacement, acceptance conclusion, and multimodal accessory data at the maintenance site corresponding to the data in the maintenance work order event package are converted into candidate fault knowledge units. The candidate fault knowledge unit includes equipment path, fault phenomenon, fault mode, fault cause, handling measures, spare parts materials, handling results, and evidence set.

[0017] As a possible implementation, further, in step S5 of this solution, when converting the multimodal accessory data at the maintenance site, Convert on-site images into visual fault labels. Convert voice recordings into repair text records. Convert video recordings into keyframe tags and repair action tags. The visual fault labels, maintenance text records, keyframe labels, and maintenance action labels are then mapped together with the fault description, maintenance process, spare parts replacement, and acceptance conclusion to the candidate fault knowledge unit.

[0018] As a possible implementation, further, in step S6 of this scheme, the repeated state, supplementary state and newly added state of the candidate fault knowledge unit are determined according to the comprehensive similarity.

[0019] In step S6, the overall similarity is calculated as follows: in, Representing candidate fault knowledge units With existing fault knowledge units The overall similarity between them Represents the cosine similarity of semantic vectors. Indicates the device path matching degree. Indicates the fault mode matching degree. , , These are existing fault knowledge units. The comprehensive vector, device path, and fault mode. , , These are candidate fault knowledge units. The comprehensive vector, device path, and fault mode. , , The corresponding weight coefficient is represented; the novelty of the candidate fault knowledge unit relative to the existing fault knowledge unit is determined based on the maximum value of the comprehensive similarity, and the repeated state, supplementary state and newly added state are determined according to the novelty.

[0020] As a possible implementation, further, in step S7 of this solution, the knowledge credibility of candidate fault knowledge units is calculated based on the completeness of the work order, the sufficiency of evidence, the effectiveness of handling, the recurrence situation, the consistency with the parent and child segmented documents, and the degree of conflict with the existing fault knowledge units. Based on the knowledge credibility, candidate fault knowledge units that meet the preset requirements are written into the formal knowledge base, and the rest are written into the knowledge base to be reviewed or the exclusion knowledge base. In step S7, the knowledge credibility is calculated as follows: in, This indicates the knowledge credibility of the candidate fault knowledge unit. Represents the normalization function. Indicates the completeness of the work order. Indicating sufficiency of evidence, Indicates the effectiveness of the treatment. This indicates the consistency between the candidate fault knowledge unit and the parent-child segmented documents. This indicates the degree of conflict between candidate fault knowledge units and existing fault knowledge units. These are all weight parameters for credibility calculation.

[0021] As a possible implementation, further, in step S8 of this solution, when a new maintenance work order is generated, similar fault cases, standard handling procedures, and recommended handling measures are recalled from the formal knowledge base based on the equipment path, fault description, alarm information, operation monitoring data, and / or multimodal evidence of the new maintenance work order. The credibility, applicability, and retrieval weight of the corresponding fault knowledge unit are updated according to the final handling result of the new maintenance work order, so as to form a closed loop of maintenance practice, knowledge accumulation, knowledge reuse, and feedback enhancement.

[0022] Based on the above, this solution also proposes a closed-loop system for constructing industrial equipment fault knowledge based on the automatic accumulation of maintenance work orders, including: The data access module is used to acquire maintenance work order data, equipment ledger data, operation monitoring data, spare parts replacement data, acceptance result data, and multimodal accessory data of industrial equipment, and generate maintenance work order event packages with equipment number and work order number as the associated primary keys; The work order management module is used to perform field normalization, time alignment, industrial terminology standardization, and equipment-level path mapping on the maintenance work order event package, and to filter out work orders that can be stored based on work order completeness, work order completion status, and acceptance results. The ontology construction module is used to construct an industrial equipment fault knowledge ontology, which includes equipment type, equipment instance, components, fault phenomenon, fault mode, fault cause, handling measures, spare parts materials, operating parameters, evidence data, and handling results. The parent-child segmentation module is used to segment industrial equipment manuals, maintenance procedures, work instructions, and inspection standards into parent and child segments, and to make the child segment document inherit the industrial context identifier of the corresponding parent segment document. The knowledge extraction module is used to extract knowledge from the work order that can be stored based on the industrial equipment fault knowledge ontology and the parent-child segmentation processing results, and to convert fault description, maintenance process, spare parts replacement, acceptance conclusion and multimodal accessory data of the maintenance site into candidate fault knowledge units. The vector deposition module is used to perform semantic vectorization, device path matching, and fault mode matching on the candidate fault knowledge units, and to calculate the comprehensive similarity between the candidate fault knowledge units and the existing fault knowledge units. The Trusted Fusion Module is used to calculate the knowledge trustworthiness of candidate fault knowledge units based on factors such as work order completeness, evidence sufficiency, handling effectiveness, recurrence, consistency with parent and child segmented documents, and conflict with existing fault knowledge units. Based on the knowledge trustworthiness, the candidate fault knowledge units are written into the formal knowledge base, the knowledge base to be reviewed, and the exclusion knowledge base. The closed-loop reuse module is used to recall similar fault cases, standard handling procedures and recommended handling measures from the formal knowledge base when a new maintenance work order is generated, and to update the credibility, applicability and retrieval weight of the corresponding fault knowledge unit according to the final handling result of the new maintenance work order.

[0023] As one possible implementation, the knowledge extraction module of this solution further includes a text extraction unit, an image tagging unit, a speech transcription unit, a video keyframe extraction unit, and a knowledge unit generation unit. The knowledge unit generation unit is used to uniformly map the text extraction results, image tagging results, speech transcription results, and video keyframe extraction results into candidate fault knowledge units that include device path, fault phenomenon, fault mode, fault cause, handling measures, spare parts materials, handling results, and evidence set.

[0024] As one possible implementation, the formal knowledge base described in this solution further includes a knowledge graph storage area and a vector index storage area. The knowledge graph storage area is used to store the structured relationships between devices, components, faults, causes, measures, spare parts, and results. The vector index storage area is used to store vector indexes of candidate fault knowledge units, parent-child segmented documents, historical fault cases, and recommended handling measures.

[0025] Compared with the prior art, the present invention has the following advantages by adopting the above technical solution: This solution unifies maintenance work orders, equipment ledgers, operation monitoring data, spare parts replacement records, acceptance results, and on-site multimodal attachments into a maintenance work order event package. Based on the industrial equipment fault knowledge ontology, it extracts candidate fault knowledge units of equipment path—fault phenomenon—fault mode—fault cause—handling measures—spare parts materials—handling results—evidence set. This enables the experience data that was originally scattered in maintenance personnel records, on-site attachments, and work order systems to be automatically precipitated into structured, searchable, and evaluable fault knowledge, reducing the workload of manually organizing the knowledge base and improving the timeliness and consistency of industrial equipment fault knowledge updates.

[0026] This solution also employs an industrial document parent-child segmentation mechanism, where the parent document retains equipment type, component path, operating scenario, and safety constraints, while the child document carries the fault phenomenon, detection parameters, operating steps, and key handling points. This avoids the problem of generic text segmentation disrupting the context of industrial maintenance documents. During knowledge extraction and retrieval, the system simultaneously utilizes semantic vector matching, equipment path matching, fault mode matching, and standard document consistency verification, which improves the accuracy of recalling similar fault cases and reduces the risk of inapplicable maintenance suggestions being recommended.

[0027] This solution further incorporates maintenance acceptance results, fault recurrence, downtime changes, and actual handling results by maintenance personnel into the knowledge credibility and applicability update mechanism. This ensures that the knowledge base is not statically stored but continuously optimized through maintenance practice. New work orders can access previously accumulated knowledge during processing, and the processing results, in turn, correct the knowledge weight and credibility, thus forming a closed loop of practice-accumulation-reuse-feedback reinforcement. This enhances the technical effectiveness of industrial equipment fault diagnosis, maintenance decision-making, and experience transfer. Attached Figure Description

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

[0029] Figure 1 This is a simplified implementation flowchart of the proposed method. Figure 2 This is a simplified diagram illustrating the connection of the unit modules of this system. Figure 3 This is a simplified schematic diagram of the knowledge extraction module in this system. Figure 4 This is a simplified diagram illustrating the structure of the formal knowledge base in this system. Detailed Implementation

[0030] The present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be particularly noted that the following embodiments are for illustrative purposes only and do not limit the scope of the invention. Similarly, the following embodiments are only some, not all, embodiments of the present invention, and all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0031] Combination Figure 1 As shown in the figure, this embodiment proposes a method for constructing a closed-loop knowledge system for industrial equipment faults based on the automatic accumulation of maintenance work orders, which includes: S1. Obtain maintenance work order data, equipment maintenance data, and multimodal accessory data at the maintenance site for industrial equipment, and generate maintenance work order event packages with equipment number and work order number as the primary key of association. S2. Perform field normalization, time alignment, industrial terminology standardization, and equipment-level path mapping on the maintenance work order event package, and filter out work orders that can be stored based on work order completeness, work order completion status, and acceptance results. S3. Construct an industrial equipment fault knowledge ontology and establish fault association relationships between various entities; S4. Perform parent-child segmentation on the equipment maintenance documents to obtain the parent-child segmentation result, which includes parent and child segment documents, and make the child segment documents inherit the industrial context identifier of the corresponding parent segment document. S5. Based on the industrial equipment fault knowledge ontology and the parent-child segmentation processing result, extract knowledge from the work order that can be stored, and convert the data in the maintenance work order event package into candidate fault knowledge units. S6. Perform semantic vectorization, device path matching, and fault mode matching on the candidate fault knowledge unit, calculate the comprehensive similarity between the candidate fault knowledge unit and the existing fault knowledge unit, and determine the state of the candidate fault knowledge unit based on the comprehensive similarity. S7. Calculate the knowledge credibility of candidate fault knowledge units based on preset conditions, and write the candidate fault knowledge units that meet the preset requirements into the formal knowledge base according to the knowledge credibility. S8. When a new maintenance work order is generated, retrieve similar fault cases, standard handling procedures, and recommended handling measures from the formal knowledge base, and update the information of the corresponding fault knowledge unit according to the final handling result of the new maintenance work order.

[0032] Industrial equipment maintenance data is typically scattered across work order systems, equipment ledger systems, condition monitoring systems, spare parts systems, acceptance systems, and field mobile terminals. The lack of a unified framework between these different data sets makes it difficult to organize the equipment involved in the same fault event, the fault symptoms, the repair process, spare parts replacement, and the acceptance results in a unified manner. This also hinders subsequent knowledge extraction and closed-loop data retention.

[0033] Therefore, step S1 of this solution will aggregate the scattered maintenance work orders, equipment ledgers, operation monitoring, spare parts replacement, acceptance results, and multimodal field records into a work order event package oriented towards a single maintenance event.

[0034] As one possible implementation, further, in step S1 of this solution, the equipment maintenance data includes equipment ledger data, operation monitoring data, spare parts replacement data, and acceptance result data related to industrial equipment.

[0035] As an example of implementation, this solution can obtain data from the following data sources: (1) Obtain the work order number, equipment number, fault description, maintenance process, maintenance measures, and maintenance personnel records from the maintenance work order system; (2) Obtain the equipment type, equipment instance number, equipment level, production line, and component structure from the equipment ledger system; (3) Obtain the operating parameters and alarm information corresponding to the maintenance work order time window from the status monitoring system; (4) Obtain the replacement spare parts, spare part models, spare part batches, and consumption quantities from the spare parts management system; (5) Obtain the maintenance completion status, acceptance status, downtime, and recurrence status from the acceptance system; (6) Obtain maintenance images, voice messages, videos, and supplementary on-site instructions from the on-site mobile terminal.

[0036] This plan uses work order numbers. Equipment number and maintenance time window As the join key, the above multi-source data is aggregated into an initial maintenance work order event package, which is defined as: in, , This refers to the start and end times of the maintenance time window. For the first An initial maintenance work order event package; Number the work order; Number the equipment; For equipment ledger information; This is a fault reporting information; For operational monitoring data; Record the repair process; For spare parts replacement records; For the acceptance results; For on-site multimodal accessories; This refers to time information related to maintenance events.

[0037] In this plan, operational monitoring data Data is typically collected continuously, while maintenance work orders are event-driven data. Therefore, it is necessary to extract data segments related to maintenance work orders from the continuous monitoring data.

[0038] Equipment At any moment Operational monitoring data for: in, For vibration data; Temperature data; For current data; For stress data; This is the rotational speed data; Alarm status.

[0039] For the Each work order is processed by the system based on the repair time. and completion time Extend the observation period for early signs of failure. Extend the observation period for repair and recovery. Get the running data capture window Its definition is: Therefore, the first The operation monitoring data corresponding to each work order is as follows: Based on the functions described above, in this solution, the fault repair event should include not only the repair execution period, but also the abnormal development stage before repair and the recovery verification stage after repair. Therefore, using an extended time window can ensure a more complete causal relationship between operational data and repair work orders.

[0040] in, For the first A screenshot window showing the running data corresponding to each work order; This refers to the time the work order was submitted, i.e., the start time of the repair time window. This refers to the work order completion time, which is the end time of the maintenance time window. This refers to the duration of abnormal observation before maintenance, i.e., the extended observation period for early signs of faults. This refers to the post-repair recovery observation period, which is an extension of the post-repair recovery observation period. For the equipment to which the monitoring data belongs; This is the equipment number corresponding to the current work order.

[0041] Because maintenance work orders are typically filled out by different maintenance personnel, issues such as missing fields, inconsistent wording, inconsistent time records, non-standard equipment names, and inconsistent fault terminology exist. Directly extracting knowledge from these work orders would lead to the same fault being described repeatedly, different faults being incorrectly merged, and reducing the quality of knowledge accumulation.

[0042] Therefore, step S2 of this solution converts the initial maintenance work order event package into a standardized work order with complete fields, consistent time, unified terminology, and clear equipment path, and filters out closed work orders with knowledge accumulation value.

[0043] As one possible implementation example, in step S2 of this solution, the first step obtained in step S1... Initial maintenance work order event package Perform the following processing: A1. Standardize industrial terminology for equipment names, component names, fault symptoms, maintenance actions, and spare parts names; A2. Align the maintenance start time, maintenance end time, acceptance time, and operation monitoring time with a unified clock. A3. According to the equipment number Query equipment ledger and generate equipment hierarchy path ; A4. Extract the set of fault phenomena from fault descriptions and alarm information. ; A5. Extracting a set of maintenance actions from the maintenance process and handling measures. ; A6. Extract spare parts set from spare parts replacement data ; A7. Extracting handling results from acceptance results ; A8. Determine whether the work order can enter the knowledge accumulation process based on the completeness of the fields and the acceptance status.

[0044] The standardized maintenance work order event package is represented as follows: in, Standardized maintenance work order event packages; For device-level paths; A collection of fault phenomena; A set of maintenance actions; For spare parts materials; The outcome of the action; This refers to the operational monitoring data corresponding to this work order; For multimodal accessory data at the maintenance site; This is a characteristic of the maintenance timing; For work order completeness.

[0045] Regarding the standardization of terminology, this step assumes that the original terminology filled in by the maintenance personnel is: The first in the industrial standard terminology database The term is The term mapping score is calculated based on literal similarity, semantic similarity, and device path constraints. The function is defined as follows: in, Original term Mapping to standard terminology Match score; Literal similarity is used to measure the degree of similarity between strings, abbreviations, and aliases; Semantic similarity is used to measure how close the meanings of two terms are in an industrial semantic model. The device path constraint score is used to determine whether the standard terminology applies to the current device path; These are the corresponding weighting coefficients.

[0046] The normalization result is obtained by selecting the standard term with the highest score that exceeds the term mapping threshold, which is defined as follows: in, To select the standard term with the highest score that exceeds the terminology mapping threshold, the standardization of industrial maintenance terminology in this model relies not only on literal similarity. For example, while terms like "belt misalignment," "belt deviation," and "conveyor belt misalignment" are different in meaning, they may correspond to the same standard fault phenomenon under a specific conveyor equipment path. By simultaneously introducing literal, semantic, and equipment path constraints, the obtained data processing results are made more accurate.

[0047] Based on the above technology, let the first... Each work order contains The key fields are categorized as follows: equipment path, fault description, alarm information, maintenance process, handling measures, spare parts record, acceptance result, and multimodal evidence. Each category of fields has a different level of importance for knowledge accumulation; therefore, a weighted completeness model is adopted, with the function defined as follows: in, Indicates the first Completeness of each maintenance work order event package Indicates the first The first in the maintenance work order event package Class field, This represents a field validation function. Indicates the first Importance weights of class fields This indicates the number of field categories; when the completeness of the work order reaches the preset completeness threshold, the work order status is completed, and the acceptance result is passed, the corresponding maintenance work order event package is determined as a work order that can be stored.

[0048] The field validation function is defined as follows: The weights satisfy: Under the defined logic of this function, the greater the contribution of a certain field to the accumulation of fault knowledge, the higher its weight. For example, handling measures and acceptance results directly determine whether knowledge can be reused, and their weight should be higher than that of ordinary remarks fields. Therefore, using weighted summation can more accurately evaluate whether a work order has accumulation value than simple field counting.

[0049] This solution is based on standardized maintenance work order event packages. and the corresponding work order completeness Work orders that can be stored can be filtered according to the following criteria: in, This is a collection of work orders that can be stored. The integrity threshold; This serves as a work order closure indicator; a value of 1 is used when the work is completed. This is the acceptance mark; it is set to 1 when acceptance is successful.

[0050] Based on step S2, this solution obtains a set of work orders that can be retained. Among them, the set of work orders that can be settled Each standardized maintenance work order event package All include device paths Fault symptoms Maintenance actions Spare parts collection , handling results Operation monitoring data Multimodal attachments and completeness These parameters will be used in subsequent steps to map to an industrial equipment fault knowledge ontology and serve as direct input for candidate knowledge extraction.

[0051] In this solution, maintenance work orders contain various types of knowledge, including equipment, components, faults, causes, measures, spare parts, and results. However, without a unified ontology constraint, the knowledge in different work orders cannot form a stable structure, nor can it perform equipment-level reasoning, fault mode merging, and maintenance measure reuse. Therefore, step S3 of this solution establishes a unified semantic skeleton capable of carrying industrial equipment fault knowledge, enabling the knowledge subsequently extracted from maintenance work orders to be stored in a consistent data structure.

[0052] As a possible implementation, further, in step S3 of this solution, the industrial equipment fault knowledge ontology includes equipment type, equipment instance, component, fault phenomenon, fault mode, fault cause, handling measures, spare parts materials, operating parameters, evidence data, and handling results.

[0053] In step S3 of this solution, the fault association relationship includes at least the relationship between the equipment containing components, the fault phenomenon corresponding to the component, the fault mode corresponding to the fault phenomenon, the fault cause corresponding to the fault mode, the handling measures corresponding to the fault cause, the spare parts and materials corresponding to the handling measures, the handling result corresponding to the handling measures, and the relationship between the maintenance work order verifying the fault knowledge.

[0054] As an example, step S3 of this solution includes the following sub-steps: Construct an industrial equipment fault knowledge ontology, defined as follows: in, A knowledge ontology for industrial equipment failures; A collection of entity types; A set of relation types; It is a collection of attributes.

[0055] The entity type set includes: in, For equipment type; For device instances; For components; This is a fault phenomenon; This is a fault mode; Cause of the malfunction; As a measure to deal with the situation; For spare parts materials; Operating parameters; For evidence data; The outcome of the handling.

[0056] The set of relation types includes: in, The equipment includes components; This indicates a component malfunction. The fault mode corresponds to the fault phenomenon; The fault mode corresponds to the fault cause; The cause of the malfunction and corresponding handling measures; Spare parts and materials will be used for the disposal measures; The disposal measures produce disposal results; Verify fault knowledge for repair work orders.

[0057] The ontology is instantiated as an industrial equipment fault knowledge graph, which is defined as follows: in, For industrial equipment fault knowledge graphs; A set of entity nodes; It is a set of entity relations.

[0058] For standardized work orders Device path Let its hierarchical structure be: in, For device type nodes; For device instance nodes, the corresponding definitions are: to These are component nodes at different levels; This represents the number of device path levels.

[0059] The inclusion relationship is established based on adjacent levels, and it is defined as follows: in, They represent the first Standardized work order In the middle, the first , Each level of component node, For a set of entity relations, This represents the number of device path levels.

[0060] Based on the technology in this step, after subsequently extracting the fault phenomenon, fault mode, fault cause, and handling measures, they will be attached to the end-of-path component node according to the ontology relationship, which is defined as: in, For the first Standardized work order In the middle, the first Each level of component node, For the fault symptoms, For failure mode, For the cause of the malfunction, For maintenance actions, The outcome of the handling.

[0061] Under the defined logic of this model, industrial equipment faults are not isolated texts, but rather attached to specific equipment levels and component objects. By attaching fault knowledge to the component nodes at the end of the equipment path, the applicable boundaries of the same fault mode in different equipment and different components can be clearly distinguished.

[0062] In this solution, when the system selects the entity from the work order... Mapping to Ontology Entity At that time, calculate the mapping confidence: in, For work order entities Mapping to Ontology Entity Confidence level; For semantic similarity; Entity type consistency score; The score is given for consistency of equipment hierarchical location. These are the corresponding weighting coefficients.

[0063] The ontology entity with the highest confidence level that meets the threshold is selected as the mapping result, which is defined as: in, The ontology entity with the highest confidence level that meets the threshold is... For work order entities Mapping to Ontology Entity The confidence level.

[0064] In step S4 of this plan, the equipment maintenance documents include industrial equipment manuals, maintenance procedures, work instructions, and inspection standards.

[0065] Industrial equipment manuals, maintenance procedures, inspection standards, and work instructions typically have a clear hierarchical structure. If a common text segmentation method is used, it is easy to separate the equipment's scope of application, safety constraints, fault diagnosis criteria, and operating procedures, resulting in a lack of industrial context in the knowledge retrieved subsequently.

[0066] Therefore, step S4 of this solution preserves the contextual boundaries of industrial documents while achieving precise retrieval of specific fault knowledge points through parent-child segmentation processing.

[0067] In step S4 of this solution, the parent segment document is used to retain the equipment type, component path, operation scenario and safety constraints, while the child segment document is used to record the fault phenomenon, detection parameters, operation steps and key points of handling.

[0068] The parent-child segmentation process includes: dividing parent documents according to equipment type, component chapter, maintenance operation scenario, and safety constraint boundary; dividing sub-documents within each parent document according to fault phenomenon, detection parameters, operation steps, and handling points; and configuring parent document identifier, equipment type identifier, component path identifier, operation scenario identifier, and safety constraint identifier for each sub-document.

[0069] As an example, step S4 of this solution includes the following sub-steps: Process the industrial document set, let the industrial document set be: in, For a collection of industrial documents; defined For the first An industrial document; This refers to the number of industrial documents.

[0070] First, divide the parent document according to equipment type, component section, work scenario, and safety constraint boundaries, defined as follows: in, For the first Each parent segment document; For parent segment metadata; This is the main text of the father's paragraph.

[0071] Parent segment metadata includes: in, The type of equipment applicable to the parent segment; For the parent segment, the applicable component path; This is for maintenance operation scenarios applicable to the parent segment; For parent segment safety constraints.

[0072] Subsequently, each parent segment is divided into sub-segments according to the fault symptoms, detection parameters, operating procedures, and key points of handling: in, For the first The first parent segment Each segment; This represents the number of child segments under the parent segment.

[0073] Each child segment inherits the parent segment context, which is defined as: in, Complete metadata for the sub-segment; For parent segment metadata; This is local metadata for the sub-segment itself, including fault symptoms, detection parameters, operating procedures, and key points for handling.

[0074] Let adjacent text blocks in the document be... and Calculate the parent segment split score between the two, which is defined as: in, For in text block and The score is calculated by splitting the parent segment between segments; The title features are scored to determine... Is this a new chapter title? Score for changes in equipment type; Score the component path change; Score for changes in safety constraints; These are the corresponding weighting coefficients.

[0075] when At that time, and Establish parent segment boundaries between them, where, The score threshold for segmenting the parent segment.

[0076] Under the logic of the function definition above, the parent segment undertakes the function of saving the industrial context. Therefore, the parent segment split should occur at the location where the equipment type, component path, operation scenario and safety constraints change, and should not rely solely on a fixed number of characters.

[0077] In the father section Within the system, the segmentation score is calculated based on the specific changes in knowledge points: in, The score is for segmenting a child segment within the parent segment; Score the changes in fault symptoms; Scoring is given based on the changes in the detection parameters; Score based on changes in operational steps; Score for changes in handling actions; These are the corresponding weighting coefficients.

[0078] when When a child segment boundary is established within the parent segment, the child segment boundary is established. The score is calculated by splitting the parent segment into child segments.

[0079] Through step S4, this solution obtains the parent-child segmented document library. Its definition is: in, Parent document; This is a sub-document; This is the industrial context metadata inherited by the sub-segment.

[0080] This parent-child segmented document library will serve as the standard knowledge anchor for knowledge extraction in subsequent steps, as the standard document consistency basis for credibility evaluation, and as the source of standard handling procedures for knowledge retrieval of new work orders in subsequent steps.

[0081] In this solution, although the work orders that can be stored have been standardized, the fault descriptions, repair processes and on-site evidence in them still exist in unstructured forms such as natural language, pictures, voice and video, and cannot be directly written into the fault knowledge base.

[0082] Therefore, step S5 of this solution converts the unstructured maintenance experience in the closed maintenance work order into structured candidate fault knowledge units.

[0083] As a possible implementation, further, in step S5 of this solution, the fault description, maintenance process, spare parts replacement, acceptance conclusion, and multimodal accessory data at the maintenance site corresponding to the data in the maintenance work order event package are converted into candidate fault knowledge units.

[0084] The candidate fault knowledge unit includes equipment path, fault phenomenon, fault mode, fault cause, handling measures, spare parts materials, handling results, and evidence set.

[0085] In addition, in step S5 of this solution, when converting the multimodal accessory data at the maintenance site, Convert on-site images into visual fault labels. Convert voice recordings into repair text records. Convert video recordings into keyframe tags and repair action tags. The visual fault labels, maintenance text records, keyframe labels, and maintenance action labels are then mapped together with the fault description, maintenance process, spare parts replacement, and acceptance conclusion to the candidate fault knowledge unit.

[0086] As an example of implementation, step S5 of this solution includes the following sub-steps: The sedimentable work order obtained in step S2 The industrial equipment fault knowledge ontology obtained in step S3 The parent-child segmented document library obtained in step S4 For the input, the following information is extracted respectively: (1) Extracting fault phenomena from fault description ; (2) Inferring the fault mode based on the equipment path and fault symptoms ; (3) Extract the cause of the failure from the maintenance process, test results and on-site evidence. ; (4) Extracting treatment measures from maintenance procedures ; (5) Extract spare parts materials from the spare parts record ; (6) Extract treatment results from acceptance records and recurrence records. ; (6) Extracting evidence sets from images, audio, and video. .

[0087] Candidate fault knowledge units are represented as follows: in, For the first One candidate fault knowledge unit; For device path; This is a fault phenomenon; This is a fault mode; Cause of the malfunction; As a measure to deal with the situation; For spare parts materials; The outcome of the action; For the collection of evidence; For work order completeness.

[0088] Let the multimodal attachment data be: in, Photos from the scene; For voice recording; For repair video; To supplement the text on site.

[0089] The above data are converted into evidentiary features, and their function is defined as follows: in, Label the images as evidence, such as cracks, wear, leaks, burns, and looseness; This refers to the repair and fault descriptions transcribed from speech. For video keyframe tags and repair action tags; To supplement the text extraction results on site; A function for extracting fault tags from images; This is a speech transcription function; Functions for extracting keyframes and motion tags from video; This is a text extraction function.

[0090] The merged set of evidence for: Under the defined logic of this function, on-site photos, audio, and video reflect the fault facts from visual, linguistic, and operational perspectives, respectively. After being uniformly converted into evidence tags, they can be used in conjunction with text work orders to support the judgment of fault causes and handling effectiveness.

[0091] This scheme also calculates the extraction confidence level for each type of element in the candidate fault knowledge unit. (Based on fault cause) For example, the function for extracting confidence is defined as follows: in, To extract the cause of the fault under the constraints of the current work order, ontology, and parent-child segmented documents. Confidence level; The probability that the cause of the fault is supported by the repair process text. Record the repair process; To provide multimodal evidence supporting the probability of this cause of failure, For the collection of evidence; To support the probability of the cause of the failure in the knowledge ontology of industrial equipment failures. A knowledge ontology for industrial equipment failures; The probability that the parent-child segmented document supports the cause of this failure. A parent-child segmented document library; These are the corresponding weight coefficients, and the cumulative sum of these weight coefficients is 1.

[0092] Under the functional definition logic of confidence, the cause of a failure cannot be inferred solely from maintenance texts; it also requires consideration of on-site evidence, ontological constraints, and standard document content. If a failure cause is supported simultaneously by the maintenance process, multimodal evidence, equipment ontology, and maintenance procedures, its credibility as a candidate knowledge element is stronger.

[0093] Since candidate fault knowledge units may completely duplicate existing knowledge, or they may simply supplement new evidence, equipment paths, or handling details, or they may represent new fault experience, the knowledge base will contain duplicate records, conflicting records, and low-value redundant records if similarity identification is not performed. Therefore, step S6 of this solution determines whether the candidate fault knowledge unit is duplicate knowledge, supplementary knowledge, or newly added knowledge relative to existing knowledge, in order to achieve flexible updating of the knowledge base.

[0094] Step S6 of this solution will use the candidate fault knowledge units obtained in step S5. Converted to a multi-view vector, its definition is: in, This is the comprehensive vector of candidate fault knowledge units; This is the device path vector; This is a vector representing the fault symptoms; This represents the fault mode vector; This is the fault cause vector; Vector of disposal measures; This is the evidence vector.

[0095] For the existing first in the knowledge base Knowledge Units Its data vector is defined as: in, For the first one already in the knowledge base Knowledge Units The combined vector, These correspond to the device path vector, fault phenomenon vector, fault mode vector, fault cause vector, handling measure vector, and evidence vector, respectively.

[0096] This scheme will calculate the comprehensive similarity between candidate fault knowledge units and existing fault knowledge units based on the above data.

[0097] Since the similarity of industrial equipment fault knowledge depends not only on text semantics but also on equipment hierarchical paths and fault modes, the comprehensive similarity is composed of semantic similarity, equipment path matching degree, and fault mode matching degree. The comprehensive similarity is calculated as follows: in, Representing candidate fault knowledge units With existing fault knowledge units The overall similarity between them Represents the cosine similarity of semantic vectors. Indicates the device path matching degree. Indicates the fault mode matching degree. , , These are existing fault knowledge units. The comprehensive vector, device path, and fault mode. , , These are candidate fault knowledge units. The comprehensive vector, device path, and fault mode. , , This represents the corresponding weight coefficient, which satisfies .

[0098] This scheme determines the novelty of the candidate fault knowledge unit relative to the existing fault knowledge unit based on the maximum value of the comprehensive similarity, and determines the duplicate state, supplementary state and new state according to the novelty.

[0099] Under the formula definition of the comprehensive similarity, its logical meaning includes: First, if the semantic descriptions of two knowledge units are similar, they may describe the same fault experience. Second, industrial equipment failures are highly equipment-dependent; the same text description may not be the same failure under different component paths. Third, the failure mode determines whether maintenance measures can be reused. Therefore, comprehensive similarity needs to consider three dimensions simultaneously: semantics, path, and pattern.

[0100] Furthermore, this scheme assumes the following candidate knowledge paths: The existing knowledge path is: The length of their longest common prefix is: Then the device path matching degree is: in, Existing fault knowledge unit The Middle Each level of component node, For candidate fault knowledge units The Middle Each level of component node, For device path matching degree; For two device paths, the number of consecutive levels starting from the root node must be the same. The number of candidate knowledge path levels; This represents the number of existing knowledge path levels.

[0101] Under the functional logic definition of the above device path matching degree, the longer the common prefix of the device paths of two fault knowledge, the closer their device type, device instance and component level are, and the stronger their reusability.

[0102] Furthermore, this scheme calculates the maximum similarity between candidate knowledge and the existing knowledge base, which is defined as: Novelty of candidate knowledge Defined as: in, The maximum comprehensive similarity between candidate knowledge and existing knowledge; The novelty of candidate knowledge.

[0103] according to The state of knowledge is defined as follows: in, The state of the candidate fault knowledge unit; This is a repeating state; To supplement the status; This is a newly added status; The threshold for repeated judgments; To supplement the judgment threshold, and .

[0104] In step S6, this scheme uses the maximum comprehensive similarity between candidate knowledge and existing knowledge. Novelty of candidate knowledge Identify the existing knowledge unit most similar to the candidate knowledge and the repeated, supplementary, or newly added states of candidate knowledge. Combined with the first One candidate fault knowledge unit The comprehensive vector of its corresponding candidate fault knowledge unit These data will be used for subsequent knowledge credibility evaluation. Among them, repeated states and supplementary states will affect the updating of evidence for existing knowledge; newly added states will affect whether new knowledge is included in the formal knowledge base.

[0105] Because the experience in maintenance work orders is not always reliable, some maintenance records may lack evidence, some maintenance measures may temporarily restore the equipment but the failure may recur in the short term, and some work order experience may conflict with standard procedures. Without credibility evaluation, low-quality knowledge will enter the knowledge base and affect subsequent recommendations. Therefore, step S7 of this solution evaluates the credibility of candidate fault knowledge units based on maintenance process evidence, acceptance results, recurrence status, consistency with standard documents, and existing knowledge conflict level, and determines their entry method into the knowledge base.

[0106] As a possible implementation, further, in step S7 of this solution, the knowledge credibility of candidate fault knowledge units is calculated based on the completeness of the work order, the sufficiency of evidence, the effectiveness of handling, the recurrence situation, the consistency with the parent and child segmented documents, and the degree of conflict with the existing fault knowledge units. Based on the knowledge credibility, candidate fault knowledge units that meet the preset requirements are written into the formal knowledge base, and the rest are written into the knowledge base to be reviewed or the exclusion knowledge base. In step S7, the knowledge credibility is calculated as follows: in, This indicates the knowledge credibility of the candidate fault knowledge unit. Represents the normalization function. Indicates the completeness of the work order. Indicating sufficiency of evidence, Indicates the effectiveness of the treatment. This indicates the consistency between the candidate fault knowledge unit and the parent-child segmented documents. This indicates the degree of conflict between candidate fault knowledge units and existing fault knowledge units. These are all weight parameters for credibility calculation.

[0107] As an example of implementation, step S7 of this solution may include the following sub-steps: For each candidate fault knowledge unit The evaluation metrics include: work order completeness. (Obtained via step S2); sufficiency of evidence Effectiveness of the handling (Calculated based on acceptance results, recurrence rate, and downtime); Document consistency (Based on candidate knowledge and parent-child segmented document library) (obtained through comparison); degree of conflict (Obtained by comparing candidate knowledge with the opposite conclusions in the existing knowledge base).

[0108] Finally, the knowledge credibility is calculated. .

[0109] Specifically, regarding the sufficiency of evidence Suppose the evidence set includes textual evidence, image evidence, audio evidence, video evidence, and operational data evidence: The levels of support for candidate knowledge from various types of evidence are as follows: The sufficiency of evidence is then defined as: in, For the sufficiency of evidence; For the degree of support of textual evidence; For the degree of support of photographic evidence; For the degree of support of voice evidence; For the degree of support of video evidence; The degree of support from operational data evidence; For the corresponding weight coefficients, the weights satisfy the condition that the sum of the weights is 1.

[0110] Under the functional definition of sufficiency of evidence described above, the more valid evidence supporting a candidate knowledge, the higher its authenticity. For certain fault types, the weight of operational data and image evidence can be higher than that of voice recordings; for operational faults, the weight of video action tags can be increased.

[0111] In this plan, the effectiveness of the measures is used to measure whether the maintenance actions have truly resolved the fault. The system comprehensively considers acceptance testing, the number of recurrences within the observation period, and the improvement in downtime.

[0112] set up: in, For the first The effectiveness of handling candidate knowledge; This is the acceptance mark; a value of 1 is used when acceptance is passed. This is the preset number of times the same type of fault will recur within the observation period; This serves as a baseline for the number of recurrences. This refers to the downtime of this fault; The historical average downtime for similar faults; These are the corresponding weight coefficients, and the weights satisfy: .

[0113] Under the functional reasoning logic of handling validity, its purpose is as follows: First, the successful acceptance demonstrates that the maintenance measures are effective immediately. Second, the fewer the number of recurrences during the observation period, the more effective the maintenance measures are. Third, if the downtime is shorter than the historical average downtime, it indicates that the measures taken are efficient.

[0114] Therefore, the three factors are weighted to form an indicator of the effectiveness of the disposal.

[0115] To ensure document consistency, this solution matches the fault phenomena, fault causes, and handling measures in the candidate knowledge units with the sub-segments in the parent-child segmented document library, and requires that the parent metadata of the sub-segment be consistent with the device path of the candidate knowledge.

[0116] Document consistency is defined as: in, To ensure consistency between candidate knowledge and standard documents; Sub-segments in a parent-child segmentation document library; For sub-segment document vectors; The parent component path inherited by the child segment; Safety constraints of the parent segment inherited by the child segment; The score is based on the consistency between the response measures and safety constraints; The semantic similarity between candidate knowledge and sub-segment content; The matching degree between the candidate knowledge device path and the parent segment path. , These are candidate fault knowledge units. The comprehensive vector and device path; These are the measures to be taken.

[0117] Under the functional definition logic of document consistency, standard document consistency requires not only semantic similarity of text, but also consistency of device paths and security constraints. If a candidate measure is semantically similar to a procedure, but the device path is inconsistent, it should not be considered as having high consistency.

[0118] Regarding conflict level, this solution detects whether there are conflicts between candidate knowledge and existing knowledge. Conflicts include situations where the fault causes are opposite, the handling measures are mutually exclusive, and the handling results are contradictory, even within the same device path and fault mode.

[0119] Conflict level is defined as: The conflict determination function is: in, The degree of conflict between candidate knowledge and existing knowledge; For the current moment, it serves as the formal knowledge base; For the first in the formal knowledge base Each knowledge unit; The overall similarity obtained in step S6; Here is the conflict determination function. This is a candidate fault knowledge unit.

[0120] Regarding knowledge credibility, this scheme uses a normalized logic function to calculate knowledge credibility, which is defined as follows: in, ; This indicates the knowledge credibility of the candidate fault knowledge unit. Let represent the normalization function, which is the normalization function that maps the confidence level to the interval [0,1]. Indicates the completeness of the work order. Indicating sufficiency of evidence, Indicates the effectiveness of the treatment. This indicates the consistency between the candidate fault knowledge unit and the parent-child segmented documents. This indicates the degree of conflict between candidate fault knowledge units and existing fault knowledge units. All of these are weight parameters for credibility calculation.

[0121] Under the functional definition logic of knowledge credibility, candidate knowledge is more credible when the work order is complete, the evidence is sufficient, the handling is effective, and it conforms to the standard document; therefore, the corresponding item is a positive contribution. If the candidate knowledge conflicts with existing knowledge, the credibility should be reduced; therefore, the conflict degree is a negative contribution. The logical function can convert the linear synthesis result into a credibility level between 0 and 1, which facilitates subsequent database entry judgment.

[0122] Regarding the determination of data entry and the updating of the knowledge base, this solution is based on the credibility of the knowledge. and knowledge status The function is defined as follows: in, Storage category for candidate knowledge; To be included in the official knowledge base; To be written into the knowledge base to be reviewed; To be included in the exclusion knowledge base; This is the threshold for formal warehousing. The threshold to be reviewed; and .

[0123] Knowledge base updates are represented as: in, This is the official knowledge base before the update; For the updated official knowledge base; Update functions for the knowledge base; For candidate fault knowledge units; To ensure the credibility of knowledge; This refers to the candidate knowledge state obtained in step S6.

[0124] when At that time, the candidate fault knowledge unit As new verification evidence for existing knowledge; when When, the system uses it as a supplementary description to existing knowledge; when and When this happens, the system writes it into the formal knowledge base as new knowledge.

[0125] Through step S7, this scheme obtains a formal knowledge base, which is defined as follows: in, Formal knowledge unit; To ensure the credibility of knowledge; For knowledge applicability; For knowledge vectors; For device path; This is the fault mode; these parameters will be used in subsequent steps for knowledge retrieval, recommendation ranking, and feedback updates for new work orders.

[0126] Traditional knowledge bases are mostly static, lacking mechanisms for continuous verification and weight updates based on subsequent maintenance practices. This leads to the knowledge base becoming outdated and failing to reflect the true effectiveness of a maintenance measure in the current production environment. Therefore, step S8 of this solution reuses existing knowledge during the processing of new maintenance work orders and updates the knowledge's credibility, applicability, and retrieval weight based on actual maintenance results, forming a dynamic closed loop.

[0127] In step S8 of this solution, when a new maintenance work order is generated, similar fault cases, standard handling procedures, and recommended handling measures are recalled from the formal knowledge base based on the equipment path, fault description, alarm information, operation monitoring data, and / or multimodal evidence of the new maintenance work order. The credibility, applicability, and retrieval weight of the corresponding fault knowledge unit are updated according to the final handling result of the new maintenance work order, so as to form a closed loop of maintenance practice, knowledge accumulation, knowledge reuse, and feedback enhancement.

[0128] As one possible implementation, step S8 of this solution may further include the following sub-steps: When a new repair work order When generated, a new work order event package is generated following steps S1 and S2, and a retrieval vector is generated following steps S5 and S6, defined as follows: in, Request a new repair work order; The device path corresponding to the new work order; This refers to the fault description or fault phenomenon for the new work order. This refers to the operational monitoring data corresponding to the new work order; This is multimodal evidence corresponding to the new work order; This is the new work order request vector.

[0129] From the formal knowledge base The system recalls similar fault cases, standard handling procedures, and recommended handling measures, and sorts them according to matching scores.

[0130] For new work orders With the knowledge base Knowledge Units The matching score is calculated and defined as follows: in, For new work orders With knowledge unit Match score; This is the new work order request vector; For knowledge unit vectors; For the new work order's equipment path; For knowledge unit device paths; Infer fault modes for new work orders; For knowledge unit failure modes; To assess the credibility of knowledge units; For the applicability of knowledge units; The ranking weights are determined by the following conditions: all weights are greater than 0 and their sum is 1.

[0131] Under the reasoning logic of this model, knowledge recommendation for new work orders cannot be based solely on text similarity. If a knowledge unit is semantically similar to a new work order but the device path does not match, the recommendation risk is high; if a knowledge unit has high credibility and good recent applicability, its ranking should be improved even if the text similarity is slightly lower. Therefore, the matching score comprehensively considers semantic similarity, device path, failure mode, knowledge credibility, and recent applicability.

[0132] Regarding the updating of knowledge applicability, when maintenance personnel use recommended knowledge... After the repair is completed, a feedback value is generated based on the actual handling feedback, which is defined as follows: in, For the first Secondary knowledge reuse feedback value; This is a sign indicating that the maintenance has passed inspection. This refers to the number of times the same type of fault recurred within the observation period following this repair. This serves as a baseline for the number of recurrences. This refers to the downtime for this maintenance. The historical average downtime for similar faults; These are the corresponding weighting coefficients.

[0133] Knowledge applicability is updated exponentially, and is defined as follows: in, For knowledge units In the Applicability before the second feedback; For knowledge units In the Applicability after feedback; Historical applicability retention coefficient; Feedback values ​​from this repair.

[0134] Under the reasoning logic above, knowledge applicability should retain both long-term historical performance and reflect recent actual usage effects. The exponential sliding update can avoid drastic fluctuations caused by a single abnormal feedback, while allowing recent feedback to gradually influence subsequent recommendation rankings.

[0135] Regarding knowledge credibility feedback updates, for knowledge units that have been adopted and generated feedback... According to the feedback value Update its credibility, which is defined as: in, For knowledge units In the Credibility before the first feedback; For the knowledge unit (K_l) in the first... Credibility after the feedback; Update the step size to improve credibility; This is the feedback value for this knowledge reuse.

[0136] Under the reasoning logic of the above formula, if the feedback value of this maintenance... Higher than current credibility This indicates that the knowledge performed better than historical evaluations in actual maintenance, and its credibility should be increased; if A value lower than the current confidence level indicates that the knowledge has performed poorly recently and its confidence level should be reduced. This update formula allows knowledge confidence level to dynamically change with maintenance practices.

[0137] Regarding retrieval weight feedback updates To enable the system to gradually learn the contribution of different matching factors to repair success, the system updates the retrieval ranking weights. Let the matching features in this recommendation be: Based on feedback values The weights are updated by normalization, defined as follows: in, For the first Before the first feedback Each retrieval weight; The (t+1)th feedback after the first feedback Each retrieval weight; Update the step size to retrieve weights; These are the feedback values ​​from this repair. For the first One matching feature; Index for normalized summation.

[0138] Under the reasoning logic of this formula, if a recommendation is successful and a certain matching feature value is high, it indicates that the feature contributed to the successful recommendation, and the weight corresponding to that feature should be appropriately increased. By normalizing the denominator, it can be ensured that the updated weights still sum to 1.

[0139] Through step S8, this scheme forms the following closed loop: The corresponding knowledge base iteration process is as follows: in, This is the knowledge base obtained through step S7; This is the knowledge base after receiving feedback from new work orders; This is a new repair work order; These are the knowledge units that have been recalled and adopted. These are the feedback values ​​from this repair. This is a feedback update function.

[0140] Combination Figure 2 As shown, based on the above, this solution also proposes a closed-loop construction system for industrial equipment fault knowledge based on automatic accumulation of maintenance work orders, including: The data access module is used to acquire maintenance work order data, equipment ledger data, operation monitoring data, spare parts replacement data, acceptance result data, and multimodal accessory data of industrial equipment, and generate maintenance work order event packages with equipment number and work order number as the associated primary keys; The work order management module is used to perform field normalization, time alignment, industrial terminology standardization, and equipment-level path mapping on the maintenance work order event package, and to filter out work orders that can be stored based on work order completeness, work order completion status, and acceptance results. The ontology construction module is used to construct an industrial equipment fault knowledge ontology, which includes equipment type, equipment instance, components, fault phenomenon, fault mode, fault cause, handling measures, spare parts materials, operating parameters, evidence data, and handling results. The parent-child segmentation module is used to segment industrial equipment manuals, maintenance procedures, work instructions, and inspection standards into parent and child segments, and to make the child segment document inherit the industrial context identifier of the corresponding parent segment document. The knowledge extraction module is used to extract knowledge from the work order that can be stored based on the industrial equipment fault knowledge ontology and the parent-child segmentation processing results, and to convert fault description, maintenance process, spare parts replacement, acceptance conclusion and multimodal accessory data of the maintenance site into candidate fault knowledge units. The vector deposition module is used to perform semantic vectorization, device path matching, and fault mode matching on the candidate fault knowledge units, and to calculate the comprehensive similarity between the candidate fault knowledge units and the existing fault knowledge units. The Trusted Fusion Module is used to calculate the knowledge trustworthiness of candidate fault knowledge units based on factors such as work order completeness, evidence sufficiency, handling effectiveness, recurrence, consistency with parent and child segmented documents, and conflict with existing fault knowledge units. Based on the knowledge trustworthiness, the candidate fault knowledge units are written into the formal knowledge base, the knowledge base to be reviewed, and the exclusion knowledge base. The closed-loop reuse module is used to recall similar fault cases, standard handling procedures and recommended handling measures from the formal knowledge base when a new maintenance work order is generated, and to update the credibility, applicability and retrieval weight of the corresponding fault knowledge unit according to the final handling result of the new maintenance work order.

[0141] Combination Figure 3 As shown, as a possible implementation, the knowledge extraction module of this solution further includes a text extraction unit, an image tagging unit, a speech transcription unit, a video keyframe extraction unit, and a knowledge unit generation unit. The knowledge unit generation unit is used to uniformly map the text extraction results, image tagging results, speech transcription results, and video keyframe extraction results into candidate fault knowledge units that include device path, fault phenomenon, fault mode, fault cause, handling measures, spare parts materials, handling results, and evidence set.

[0142] In addition, combined Figure 4 As shown, the formal knowledge base described in this solution further includes a knowledge graph storage area and a vector index storage area. The knowledge graph storage area is used to store the structured relationships between devices, components, faults, causes, measures, spare parts and results. The vector index storage area is used to store vector indexes of candidate fault knowledge units, parent and child segmented documents, historical fault cases and recommended handling measures.

[0143] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0144] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods of various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0145] The above description is only a part of the embodiments of the present invention and does not limit the scope of protection of the present invention. Any equivalent device or equivalent process transformation made based on the content of the present invention specification and drawings, or direct or indirect application in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for constructing a closed-loop knowledge system for industrial equipment faults based on the automatic accumulation of maintenance work orders, characterized in that, It includes: S1. Obtain maintenance work order data, equipment maintenance data, and multimodal accessory data at the maintenance site for industrial equipment, and generate maintenance work order event packages with equipment number and work order number as the primary key of association. S2. Perform field normalization, time alignment, industrial terminology standardization, and equipment-level path mapping on the maintenance work order event package, and filter out work orders that can be stored based on work order completeness, work order completion status, and acceptance results. S3. Construct an industrial equipment fault knowledge ontology and establish fault association relationships between various entities; S4. Perform parent-child segmentation on the equipment maintenance documents to obtain the parent-child segmentation result, which includes parent and child segment documents, and make the child segment documents inherit the industrial context identifier of the corresponding parent segment document. S5. Based on the industrial equipment fault knowledge ontology and the parent-child segmentation processing result, extract knowledge from the work order that can be stored, and convert the data in the maintenance work order event package into candidate fault knowledge units. S6. Perform semantic vectorization, device path matching, and fault mode matching on the candidate fault knowledge unit, calculate the comprehensive similarity between the candidate fault knowledge unit and the existing fault knowledge unit, and determine the state of the candidate fault knowledge unit based on the comprehensive similarity. S7. Calculate the knowledge credibility of candidate fault knowledge units based on preset conditions, and write the candidate fault knowledge units that meet the preset requirements into the formal knowledge base according to the knowledge credibility. S8. When a new maintenance work order is generated, retrieve similar fault cases, standard handling procedures, and recommended handling measures from the formal knowledge base, and update the information of the corresponding fault knowledge unit according to the final handling result of the new maintenance work order.

2. The method for constructing a closed-loop knowledge system for industrial equipment faults based on automatic maintenance work order accumulators as described in claim 1, characterized in that, In step S1, the equipment maintenance data includes equipment ledger data, operation monitoring data, spare parts replacement data, and acceptance result data for industrial equipment. In step S2, the completeness of the work order is calculated as follows: ； in, Indicates the first Completeness of each maintenance work order event package Indicates the first The first in the maintenance work order event package Class field, This represents a field validation function. Indicates the first Importance weights of class fields This indicates the number of field categories; when the completeness of the work order reaches the preset completeness threshold, the work order status is completed, and the acceptance result is passed, the corresponding maintenance work order event package is determined as a work order that can be stored.

3. The method for constructing a closed-loop knowledge system for industrial equipment faults based on automatic maintenance work order accumulators as described in claim 1, characterized in that, In step S3, the industrial equipment fault knowledge ontology includes equipment type, equipment instance, component, fault phenomenon, fault mode, fault cause, remedial measures, spare parts and materials, operating parameters, evidence data and remedial results; In step S3, the fault association relationship includes at least the relationship between the equipment containing components, the fault phenomenon corresponding to the component, the fault mode corresponding to the fault phenomenon, the fault cause corresponding to the fault mode, the handling measures corresponding to the fault cause, the spare parts and materials corresponding to the handling measures, the handling result corresponding to the handling measures, and the relationship between the maintenance work order and the fault knowledge.

4. The method for constructing a closed-loop knowledge system for industrial equipment faults based on the automatic accumulation of maintenance work orders as described in claim 1, characterized in that, In step S4, the equipment maintenance documents include industrial equipment manuals, maintenance procedures, work instructions, and inspection standards; The parent document is used to retain equipment type, component path, operating scenario and safety constraints, while the child document is used to record fault phenomena, detection parameters, operating steps and key points of handling. In step S4, the parent-child segmentation process includes: dividing the parent document according to equipment type, component chapter, maintenance operation scenario, and safety constraint boundary; Within each parent document, sub-documents are divided according to fault symptoms, detection parameters, operation steps, and handling points; each sub-document is configured with a parent document identifier, equipment type identifier, component path identifier, operation scenario identifier, and safety constraint identifier.

5. The method for constructing a closed-loop knowledge loop for industrial equipment faults based on automatic accumulation of maintenance work orders as described in claim 1, characterized in that, In step S5, the fault description, repair process, spare parts replacement, acceptance conclusion, and multimodal accessory data at the repair site corresponding to the data in the repair work order event package are converted into candidate fault knowledge units. The candidate fault knowledge unit includes equipment path, fault phenomenon, fault mode, fault cause, handling measures, spare parts materials, handling results and evidence set; In step S5, when converting the multimodal accessory data at the maintenance site, Convert on-site images into visual fault labels. Convert voice recordings into repair text records. Convert video recordings into keyframe tags and repair action tags. The visual fault labels, maintenance text records, keyframe labels, and maintenance action labels are then mapped together with the fault description, maintenance process, spare parts replacement, and acceptance conclusion to the candidate fault knowledge unit.

6. The method for constructing a closed-loop knowledge loop for industrial equipment faults based on automatic accumulation of maintenance work orders as described in claim 1, characterized in that, In step S6, the repeated state, supplementary state and newly added state of the candidate fault knowledge unit are determined according to the comprehensive similarity. In step S6, the overall similarity is calculated as follows: ； in, Representing candidate fault knowledge units With existing fault knowledge units The overall similarity between them Represents the cosine similarity of semantic vectors. Indicates the device path matching degree. Indicates the fault mode matching degree. , , These are existing fault knowledge units. The comprehensive vector, device path, and fault mode. , , These are candidate fault knowledge units. The comprehensive vector, device path, and fault mode. , , The corresponding weight coefficient is represented; the novelty of the candidate fault knowledge unit relative to the existing fault knowledge unit is determined based on the maximum value of the comprehensive similarity, and the repeated state, supplementary state and newly added state are determined according to the novelty.

7. The method for constructing a closed-loop knowledge system for industrial equipment faults based on automatic maintenance work order accumulators as described in claim 1, characterized in that, In step S7, the knowledge credibility of candidate fault knowledge units is calculated based on the completeness of the work order, the sufficiency of evidence, the effectiveness of the handling, the recurrence, the consistency with the parent and child segmented documents, and the degree of conflict with the existing fault knowledge units. Based on the knowledge credibility, candidate fault knowledge units that meet the preset requirements are written into the formal knowledge base, and the rest are written into the knowledge base to be reviewed or the exclusion knowledge base. In step S7, the knowledge credibility is calculated as follows: ；； in, This indicates the knowledge credibility of the candidate fault knowledge unit. Represents the normalization function. Indicates the completeness of the work order. Indicating sufficiency of evidence, Indicates the effectiveness of the treatment. This indicates the consistency between the candidate fault knowledge unit and the parent-child segmented documents. This indicates the degree of conflict between candidate fault knowledge units and existing fault knowledge units. All of these are weight parameters for credibility calculation.

8. The method for constructing a closed-loop knowledge loop for industrial equipment faults based on automatic accumulation of maintenance work orders as described in claim 1, characterized in that, In step S8, when a new maintenance work order is generated, similar fault cases, standard handling procedures, and recommended handling measures are recalled from the formal knowledge base based on the equipment path, fault description, alarm information, operation monitoring data, and / or multimodal evidence of the new maintenance work order. The credibility, applicability, and retrieval weight of the corresponding fault knowledge unit are updated according to the final handling result of the new maintenance work order, so as to form a closed loop of maintenance practice, knowledge accumulation, knowledge reuse, and feedback enhancement.

9. A closed-loop system for constructing industrial equipment fault knowledge based on automatic accumulation of maintenance work orders, characterized in that, include: The data access module is used to acquire maintenance work order data, equipment ledger data, operation monitoring data, spare parts replacement data, acceptance result data, and multimodal accessory data of industrial equipment, and generate maintenance work order event packages with equipment number and work order number as the associated primary keys; The work order management module is used to perform field normalization, time alignment, industrial terminology standardization, and equipment-level path mapping on the maintenance work order event package, and to filter out work orders that can be stored based on work order completeness, work order completion status, and acceptance results. The ontology construction module is used to construct an industrial equipment fault knowledge ontology, which includes equipment type, equipment instance, components, fault phenomenon, fault mode, fault cause, handling measures, spare parts materials, operating parameters, evidence data, and handling results. The parent-child segmentation module is used to segment industrial equipment manuals, maintenance procedures, work instructions, and inspection standards into parent and child segments, and to make the child segment document inherit the industrial context identifier of the corresponding parent segment document. The knowledge extraction module is used to extract knowledge from the work order that can be stored based on the industrial equipment fault knowledge ontology and the parent-child segmentation processing results, and to convert fault description, maintenance process, spare parts replacement, acceptance conclusion and multimodal accessory data of the maintenance site into candidate fault knowledge units. The vector deposition module is used to perform semantic vectorization, device path matching, and fault mode matching on the candidate fault knowledge units, and to calculate the comprehensive similarity between the candidate fault knowledge units and the existing fault knowledge units. The Trusted Fusion Module is used to calculate the knowledge trustworthiness of candidate fault knowledge units based on factors such as work order completeness, evidence sufficiency, handling effectiveness, recurrence, consistency with parent and child segmented documents, and conflict with existing fault knowledge units. Based on the knowledge trustworthiness, the candidate fault knowledge units are written into the formal knowledge base, the knowledge base to be reviewed, and the exclusion knowledge base. The closed-loop reuse module is used to recall similar fault cases, standard handling procedures and recommended handling measures from the formal knowledge base when a new maintenance work order is generated, and to update the credibility, applicability and retrieval weight of the corresponding fault knowledge unit according to the final handling result of the new maintenance work order.

10. The industrial equipment fault knowledge closed-loop construction system based on automatic maintenance work order accumulator as described in claim 9, characterized in that, The knowledge extraction module includes a text extraction unit, an image tagging unit, a speech transcription unit, a video keyframe extraction unit, and a knowledge unit generation unit. The knowledge unit generation unit is used to uniformly map the text extraction results, image tagging results, speech transcription results, and video keyframe extraction results into candidate fault knowledge units that include device path, fault phenomenon, fault mode, fault cause, handling measures, spare parts materials, handling results, and evidence set. The formal knowledge base includes a knowledge graph storage area and a vector index storage area. The knowledge graph storage area is used to store the structured relationships between devices, components, faults, causes, measures, spare parts and results. The vector index storage area is used to store vector indexes of candidate fault knowledge units, parent and child segmented documents, historical fault cases and recommended handling measures.

Images