METHOD AND DEVICE FOR CAUSE ANALYSIS OF PRODUCT DEFECTS BASED ON A KNOWLEDGE GRAPHEA

Abstract

The invention discloses a method for root cause analysis of product defects based on a knowledge graph, comprising: capturing the design data associated with the product, wherein the design data includes semi-structured and / or unstructured data; capturing the production data associated with the product, wherein the production data includes structured data; performing information extraction from the design data to obtain structured data; performing knowledge fusion of the knowledge generated from the production data and the structured design data, respectively, to create a target knowledge graph; and performing the tasks for root cause analysis of product defects using the target knowledge graph.

Description

AREA OF INVENTION

[0001] In general, the present invention relates to the field of knowledge graphs and in particular to methods and devices for root cause analysis of product defects based on knowledge graphs. STATE OF THE ART

[0002] In manufacturing, the production process must be controlled to improve product quality, reduce product defect rates, and ensure production capacity. Therefore, if a product defect occurs on the production line, it is essential to identify the root cause as quickly as possible to pinpoint the problem and ensure continued production efficiency. In the era of traditional manufacturing, root cause analysis of product defects typically relies on expert experience and is performed manually. However, due to the continuous development of manufacturing systems and processes, the potential points of failure and the pathways leading to product defects are becoming increasingly complex, making it difficult to manually identify the root cause quickly.

[0003] Since the dawn of the smart manufacturing era, efforts have been made to solve the problem of root cause analysis for product defects using intelligent methods, with knowledge graphs receiving considerable attention. A knowledge graph is a structured, machine-understandable semantic knowledge database that facilitates knowledge modeling, data integration, and data standardization, and provides advanced functionalities including data access and querying. Currently, knowledge graphs are typically built based on data from production systems, such as manufacturing execution systems (MES) and SAP systems. Therefore, root cause analysis for product defects relies solely on the relevant knowledge within the production department.

[0004] In actual production and manufacturing, however, the causes of product defects lie not only on the production side but can also be found on the design side. Production data is typically structured data stored in relational databases such as Oracle, Impala, etc., while the original design data is usually semi-structured or unstructured. There are barriers between heterogeneous data from multiple sources, making it difficult for computers to directly process and analyze it. Therefore, an improved solution for building a knowledge graph based on heterogeneous data from multiple sources is needed to achieve a deeper and more comprehensive root cause analysis of product defects. REVELATION OF THE INVENTION

[0005] When a product defect occurs on the production line, a root cause analysis is required. Given that smart manufacturing is typically knowledge-intensive, implementing knowledge graph technology to perform this analysis is advantageous. Knowledge graphs are structured semantic networks that enable the organization, management, and understanding of vast amounts of information. Specifically, entities, relationships between entities, and entity attributes extracted from existing data / raw data are used to construct a knowledge graph. The semantics contained within the knowledge graph are then used to draw conclusions about potential error paths and quantify the probability of the root cause of a defect.

[0006] Therefore, providing a method and a tool for root cause analysis of product defects based on a knowledge graph is desirable. This would allow for the identification of entities, relationships between entities, and entity attributes based on heterogeneous data from multiple sources across all aspects, from design to production. The resulting entities, relationships, and entity attributes would then be used to create a knowledge graph, thus avoiding the problem of knowledge graph-based root cause analysis of product defects focusing solely on the production side and failing to fully identify the root cause. Instead of relying only on data from the production system, the knowledge graph could therefore be based on data from the design side, expert experience, and so on.further developed, which has the advantage that the deductive ability of the knowledge graph can be used to derive a complete and in-depth possible path for the emergence of errors when a product defect occurs.

[0007] According to one aspect of the present invention, a method for root cause analysis of product defects based on a knowledge graph is provided, comprising: capturing the design data associated with the product, wherein the design data includes semi-structured and / or unstructured data; capturing the production data associated with the product, wherein the production data includes structured data; performing information extraction from the design data to obtain structured data; performing knowledge fusion of the knowledge generated from the production data and the structured design data, respectively, to create a target knowledge graph; and performing the tasks for root cause analysis of product defects using the target knowledge graph.

[0008] According to another aspect of the present invention, a system for performing a root cause analysis of product defects based on a knowledge graph is provided, comprising: a storage device; a processor connected to the storage device, wherein the processor is configured to cause one or more units to perform a method according to one of the various embodiments of the present invention.

[0009] According to a further aspect of the present invention, a computer-readable medium is provided on which a computer program containing instructions is stored, wherein the instructions, when executed by the processor, cause one or more units to perform a method according to one of the various embodiments of the present invention. DESCRIPTION OF THE FIGURES

[0010] Various embodiments of the claimed subject matter are now described by way of example with reference to the figures. The same reference numerals are used in different figures to refer to the same or similar parts. Fig. Figure 1 shows a module and data flow diagram for the root cause analysis of product defects based on a knowledge graph according to an embodiment of the present invention. Fig. Figure 2 shows an example of a design diagram of product components according to an embodiment of the present invention. Fig. Figure 3 shows a causal chain diagram for the root cause analysis of product defects using the knowledge graph created according to an embodiment of the present invention. Fig. Figure 4 shows a flowchart for the root cause analysis of product defects based on a knowledge graph according to an embodiment of the present invention. Fig. Figure 5 shows a block diagram of a device for root cause analysis of product defects based on a knowledge graph according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE EXECUTION FORMS

[0011] The following description presents numerous specific details to facilitate a comprehensive understanding of the embodiments of the present invention. However, those skilled in the field will recognize that the invention can be implemented without one or more of these specific details or by using alternative methods, components, etc. In some embodiments, the known structures and processes are not shown or described in detail to avoid unnecessarily complicating the understanding of the present invention.

[0012] When a product defect occurs on the production line, it is crucial to identify the root cause as quickly as possible to pinpoint the problem and ensure subsequent production efficiency. With the development of various intelligent manufacturing technologies, it is no longer possible to rely solely on technicians for analyzing and identifying the causes of product defects. Instead, computers are now used to extract information from vast amounts of data, supporting decision-making in analyzing the root causes of product defects.Knowledge graphs can organize data from various sources in the form of entities, relationships between entities, and entity attributes in a network, providing a human-recognizable and machine-friendly representation of knowledge that is frequently used in analyzing the causes of product defects due to its knowledge integration and deductive capabilities.

[0013] Sometimes, a potential cause of a product defect lies on the production side, for example, a product defect resulting from a malfunction in the equipment that manufactures the product. Therefore, it is currently common practice to create a knowledge graph based on production-side data, such as data from manufacturing execution systems (MES) and SAP systems. The data from these systems is typically structured and stored in various relational databases like Oracle and Impala, allowing computers to easily extract information and map it to the ontology to create knowledge graphs.

[0014] In actual production, however, product defects can also originate on the design side, for example, due to incorrect component dimensions or incorrect material labeling during the design process. Furthermore, product defects caused by design issues have a more profound impact on the entire production process, making it necessary to create a knowledge graph based on design-related data. However, product design data is typically semi-structured or unstructured, and effective information cannot be directly retrieved by computers like structured data. In some cases, design-related data can be stored in a semi-structured data format, such as XML (Extensible Markup Language), JSON, or HTML (Hypertext Markup Language).In other cases, design-related data can be stored in unstructured data formats, such as CAD format, JPG format, any applicable image format, or PDF format.

[0015] To this end, the present invention proposes a method for root cause analysis of product defects based on knowledge graphs. This method not only relies on production-side data but can also advantageously utilize heterogeneous data from multiple sources, such as design, expert experience, etc., to create a knowledge graph and derive a more complete and detailed possible failure path when a product defect occurs. This provides more comprehensive decision support for root cause analysis of product defects. The proposed method for root cause analysis of product defects based on knowledge graphs is described in detail below. Those skilled in the art should understand that the present invention can be applied to any production line or production process without being limited to specific areas.

[0016] Fig. Figure 1 shows a module and data flow diagram for root cause analysis of product defects based on a knowledge graph according to an embodiment of the present invention, wherein the dashed boxes represent optional modules. Each module provided in this embodiment can be implemented in software and / or hardware and be integrated into a data processing device capable of executing this embodiment, or be distributed across multiple data processing devices capable of executing this embodiment.

[0017] With reference to Fig. 1. Design data D101 belonging to the product is obtained, the design data D101 is entered and stored in the design data storage unit M101 in a suitable format, whereby the design data D101 can be stored as semi-structured data and / or unstructured data.

[0018] In one embodiment, the design data associated with the product D101 can include product requirements documents, product assembly drawings, component design documents, component design drawings, circuit design files, circuit diagrams, design logs, etc. Among other things, circuit design files and design logs can be stored in XML (Extensible Markup Language) or HTTP (Hypertext Markup Language) format, which have semi-structured data structures. Product requirements documents and component design documents can be stored in any suitable office document or text format, while product assembly drawings, component design drawings, and circuit diagrams can be stored in image formats such as CAD, JPG, or PDF, and they have unstructured data structures.The above-mentioned design data sources serve only as examples and do not limit the scope of the present invention in any way.

[0019] Fig. Figure 2 shows an example of a design diagram of product components according to an embodiment of the present invention. Fig. Figure 2 is the engineering drawing of the product in this example, identified by the engineering drawing identification number (ID) in the upper left corner. The component's shape and size are shown in the center. The lower left corner of box 201 typically contains textual annotations related to the design, and boxes 202 and 203 in the center usually contain the component's dimensions. For example, box 202 might number the axial dimensions of an elliptical component, and box 203 might number the spherical diameter of a spherical component. As shown, engineering drawings typically contain graphical, numerical, and textual information, and the positions of graphics, numbers, and text vary from one engineering drawing to another.Creating a knowledge graph requires additional processing to obtain valid information that can be read by a computer from similarly sized diagrams of components.

[0020] With further reference to Fig. 1. The semi-structured and / or unstructured design data D102 are entered into the design data preprocessing unit M102 for preprocessing in order to be converted into structured data D103.

[0021] If the design data D102 in an embodiment is semi-structured data, the design data preprocessing unit M102 performs an information extraction operation with the design data D102.

[0022] In one embodiment, the information extraction process comprises one or more of the following steps: entity extraction, relationship extraction, and attribute extraction. Among these, the entity is identified using the design data D102 through the entity extraction process. For example, the entities "Component 1", "Component 2", and "Component 3" can be identified using the description "The shape of Component 1 is an ellipse, and Component 1 contains Component 2 and Component 3" through the entity extraction process.Among these, the relationship between entities is identified using the relationship extraction process from the design data D102. For example, the "inclusion" relationship between "Component 1" and "Component 2" and "Component 3" can be identified through the relationship extraction process based on the description "The shape of Component 1 is an ellipse and Component 1 includes Component 2 and Component 3". Among these, the attribute information of the entity is identified using the design data D102 through the attribute extraction process. For example, the attribute "Shape" that "Component 1" has, and that it has the value of an "elliptical shape", can be identified through the entity extraction process based on the description "The shape of Component 1 is an ellipse and Component 1 includes Component 2 and Component 3".In some implementation examples, the attribute extraction process can also be implemented as an instance of the relationship extraction process.

[0023] In one embodiment, entity extraction can be performed using one or any number of the following: rule-based methods such as regular matching, etc.; methods based on statistical models, such as hidden Markov models, conditional Markov models, maximum entropy models, and conditional random field models, etc.; and methods based on deep learning, such as methods based on convolutional neural networks, recurrent neural networks, and neural networks that introduce attention mechanisms, such as LSTM-CRF, LSTM-CNN-CRF, Transformer, etc.

[0024] In one embodiment, relationship extraction can be performed using one or any number of the following: template-based relationship extraction methods; supervised learning-based relationship extraction methods, such as converting relationship extraction into classification problems and training models like support vector machines and Naive Bayes; weakly supervised learning-based relationship extraction methods, such as the bootstrapping method.

[0025] In one embodiment, entity extraction and relationship extraction are performed separately, one after the other. In other embodiments, entity extraction and relationship extraction are performed simultaneously, for example, using methods such as BERT, LSTM-RNN, and DGCNN.

[0026] In one embodiment, attribute extraction can be performed using one or any number of the following: based on unsupervised methods, such as rule-based slot-filling methods, clustering-based methods, etc.; semi-supervised methods based on dependencies, such as the PageRank algorithm; sequence annotation methods based on deep learning, such as CRF models, BI-GRU+CRF models, etc.

[0027] In one embodiment, information extraction can be performed using one or any number of the following elements: word segmentation, word list query, syntactic analysis, corpus processing, named entity recognition, term extraction, part-of-speech tagging, word meaning role and entity relationship recognition, and sequence tagging.

[0028] If, in another embodiment, the design data D102 is unstructured, the design data preprocessing unit M102 applies an optical character recognition (OCR) process to convert the text in the design data into a computer-readable text format before performing the information extraction process with the design data D102. After the unstructured design data D102 has been converted into a computer-readable text format, the information extraction process can continue as described above.

[0029] In one embodiment, structured data D103 can be stored in a relational database. In another embodiment, the structured data D103 is organized as design metadata with corresponding design drawing numbers, where the design drawing number can correspond to the index of the data table and the design metadata can correspond to the header rows of several data tables, each data table being considered a class, each row in the table representing an instance or object of the class, and each column in the table representing the attributes of the class. The design metadata can be extracted from the design data D102 by the information extraction process via the design data preprocessing unit M102, where the extracted design metadata can correspond to entities, relationships, and / or attributes.For example, the design metadata includes one or more of the following elements: product name, product number, number of components, component name, component number, component shape, component material, component size, and assembly sequence.

[0030] With further reference to Fig. 1. Structured data D103 is entered into the design knowledge generation unit M103 to obtain design knowledge D104.

[0031] In one embodiment, the design knowledge D104 can be obtained by converting the structured data D103 into a Resource Description Framework format (Resource Description Framework, RDF) or RDFS format.

[0032] Specifically, the structured data D103 can be converted into the Resource Description Framework (RDF) or RDFS format. For example, RDF or RDFS ternaries can organize the data in a {subject-predicate-object} format. They can also organize the data in a {subject-attribute-attribute-value} format. Since the assembly sequence of the product components has a significant impact on root cause analysis, time sequence information can be added to the RDF or RDFS ternary to create the corresponding RDF or RDFS quaternary.

[0033] In another embodiment, the design knowledge D104 can be obtained by assigning the structured data D103 to the ontology in the created ontology library. In this case, the design knowledge D104 can be a knowledge graph created based on the design data D101.

[0034] The process of creating a knowledge graph can initially involve developing an ontology based on design data associated with a product. Ontology can generally be understood as a conceptual description of a specific domain (e.g., the production of automotive parts) and represents knowledge data that can be understood by experts in terms of classes and relationships. Design-related ontologies can be developed from the bottom up, based on the design data associated with the product. Various ontology development methods can be used to develop the aforementioned ontology, such as Common-KADS, TOVE, IDEF5, and METHONTOLOGY. Ontology development can be implemented using the Web Ontology Language (OWL).Furthermore, the experience of experts can also be incorporated into the development of the ontology in order to further modify or improve the ontology from top to bottom based on expert knowledge.

[0035] As mentioned previously, structured data D103 can be converted to RDF ternary or RDF quaternary format, and subsequently, the RDF ternary or RDF quaternary data can be merged with the created ontology OWL to obtain construction knowledge D104. Specifically, R2RML (RDB to RDF Mapping Language) mapping can be used to map data fields to RDF ternaries or RDF quaternaries of the created ontology. Furthermore, other mapping methods can be used, such as Direct Mapping, D2RQ, etc.

[0036] With reference to Fig. 1. Production data D105 belonging to the product is obtained, the production data D105 is entered and stored in the production data storage unit M105 in a suitable format, whereby the production data D105 can be stored as structured data.

[0037] In one embodiment, the production data D105 associated with a product can include any production-related records, such as data from a factory, a production line, or a production plant, including data from a manufacturing execution system (MES), data from an SAP system, and production statistics (e.g., factory data, plant data, production line data, equipment data, etc.). Production data D105 is typically structured data in a format that can be easily processed by computers. For example, data from MES systems usually has a uniform format: Machine = {Machine type, Machine status...}. Production data D105 can be stored in relational databases such as Oracle, DB2, MySQL, Impala, etc. The production data sources mentioned above are only examples and do not limit the scope of the present invention in any way.

[0038] With further reference to Fig. 1. Structured data D106 is entered into the production knowledge generation unit M106 to obtain production knowledge D107.

[0039] In one embodiment, similar to the design knowledge D104, the production knowledge D107 can be obtained by converting the structured data D106 into a Resource Description Framework format (Resource Description Framework, RDF) or RDFS format.

[0040] In another embodiment similar to the design knowledge D104, the production knowledge D107 can be obtained by assigning the structured data D106 to ontologies in the created ontology library. In this case, the production knowledge D107 can be a knowledge graph created based on the production data D105.

[0041] The process of creating a knowledge graph can initially involve developing an ontology based on production data associated with a product. An ontology can generally be understood as a conceptual description of a specific domain (e.g., the production of automotive parts) and represents knowledge data that can be understood by experts in terms of classes and relationships. Production-related ontologies can be developed top-down based on the production data associated with the product. Various ontology development methods can be used to develop the aforementioned ontology, such as Common-KADS, TOVE, IDEF5, and METHONTOLOGY. Ontology development can be implemented using the Web Ontology Language (OWL).Furthermore, the experience of experts can also be incorporated into the development of the ontology in order to further modify or improve the ontology from top to bottom based on expert knowledge.

[0042] For the process of obtaining production knowledge D107 using module M106 to generate production knowledge based on structured data D106, reference is made to the description of the process for obtaining design knowledge D104 based on structured data D103, which is not described again here.

[0043] In the actual root cause analysis process for product defects, design data and production data reveal more about possible fault connection paths between products, components and production facilities; in contrast, the experience of experts can provide real fault connection paths for the root cause analysis of previous product defects, so that the inclusion of expert experience is also advantageous for the root cause analysis of product defects.

[0044] With further reference to Fig. 1. Optionally, expert data D108, which is associated with expert experience, is obtained, and the expert data D108 is entered and stored in a suitable format in an expert data storage unit M107.

[0045] In some cases, the expert data D108 may include: fault recording records, production equipment manuals, maintenance history documents, etc., wherein the expert data D108 may be stored as structured data, semi-structured data, and / or unstructured data. The expert data sources mentioned above serve only as examples and do not limit the scope of the present invention in any way.

[0046] In some cases, the expert knowledge D111 may be RDF ternary or RDF quaternary data. In this case, the expert knowledge D111 may be a knowledge graph created based on the expert data D108. For the process of using the expert knowledge generation unit M109 to obtain the expert knowledge D111 based on the structured data D109, please refer to the description of the process for obtaining the design knowledge D104 based on the structured data D103, which will not be described again here.

[0047] For the process of obtaining expert knowledge D111 based on the semi-structured and / or unstructured data D109 using the expert data preprocessing unit M108 and the expert knowledge generation unit M109, reference is made to the description of the process for obtaining design knowledge D104 based on the semi-structured and / or unstructured data D102, which is not described again here.

[0048] With further reference to Fig. 1. Design knowledge D104 and production knowledge D107, as well as optional expert knowledge D111, are entered into the knowledge fusion unit M104 to generate fused knowledge D112.

[0049] The goal of knowledge fusion is to integrate knowledge at different levels (e.g., concept level and data level). In one implementation example, knowledge fusion can include one or more of the following processes: data preprocessing, partitioning, load balancing, data set joining, result evaluation, and / or result output.

[0050] If the design knowledge D104 and the production knowledge D107, as well as optionally the expert knowledge D111, are RDF ternary or RDF quaternary data, the knowledge fusion aims to discover equivalent instances between data from different sources. In one embodiment, the knowledge fusion includes one or more of the following tasks: data cleansing, entity alignment, entity matching, entity disambiguation, and relationship deduplication. In this case, the merged knowledge D112 is RDF ternary or RDF quaternary data.

[0051] In the event that design knowledge D104, production knowledge D107, and optionally expert knowledge D111 are knowledge graphs created based on design data D101, production data D105, and expert data D108, the goal of knowledge fusion is to discover equivalent instances, equivalences, or concepts or attributes that contain relationships between multiple knowledge graphs. In one embodiment, knowledge fusion includes one or more of the following tasks: data cleansing, ontology alignment, ontology matching, entity alignment, entity matching, entity disambiguation, and relationship deduplication. In this case, the fused knowledge D112 is a complete knowledge graph that integrates design knowledge D104, production knowledge D107, and optional expert knowledge D111.

[0052] In other implementations, other methods can be used in the knowledge fusion process to incorporate expert experience and thus further modify or improve the process. For example, equivalent ontologies / entities, conflicting ontologies / entities, duplicate ontologies / relationships between entities, and / or attributes that can be merged can be identified through expert tagging.

[0053] In other embodiments, the knowledge data input into the knowledge fusion unit can include, in addition to the example data described above, knowledge data from other sources, including but not limited to: procurement knowledge from procurement data, knowledge from material data, and acceptance knowledge from acceptance data. The data sources serve only as examples and do not limit the scope of the present invention in any way. Depending on whether the data from different sources is structured, semi-structured, or unstructured, similar processing can be performed, with reference to the above descriptions of design data, production data, and / or expert data, to obtain the corresponding knowledge data.

[0054] In general, due to the sensitivity of various product-related data, encryption processing is required when retrieving raw data to ensure the robustness of the system, especially for raw data obtained electronically from clouds such as Azure. For example, when production data from an MES or SAP system is received from the cloud, the raw data is usually downloaded as key-value pairs, and at least the sensitive data contained therein is encrypted.

[0055] With further reference to Fig. 1. Optionally, the merged knowledge data D112 is entered into the knowledge graph generation unit M110 to create the knowledge graph D113.

[0056] In one embodiment, the merged knowledge data D112 can include design knowledge D104, production knowledge D107, and optionally expert knowledge D111. In other embodiments, the merged knowledge data D112 can include procurement knowledge, material knowledge, and acceptance knowledge. If the merged knowledge data D112 is RDF ternary or RDF quaternary data, it is mapped to the ontology in the created ontology library to create a complete knowledge graph D113. As described above, the ontology library can be built top-down and / or bottom-up based on various raw data associated with the product.In one embodiment, the created ontology library includes one or more of the following ontologies: design ontology, product ontology, equipment ontology, material ontology, real asset ontology, process segment ontology, expert ontology, procurement ontology, and acceptance ontology.

[0057] Using the method described above, a complete knowledge graph can integrate heterogeneous data from multiple sources, including the design side, the production side, expert experience, etc., to derive a more complete and detailed possible failure path when a product failure occurs, thus providing more comprehensive decision support for the root cause analysis of product failures.

[0058] In one embodiment, the created knowledge graph can be stored in a graph database, and the entities, relationships between entities, and / or entity attributes in the knowledge graph can be queried using a query language such as SPARQL, thus providing support for root cause analysis of product defects. In another embodiment, the created knowledge graph can be visualized, using, for example, entities in the knowledge graph D113 as nodes and the relationships between entities as connecting edges to generate a graph. Attributes can also be designed as entities, and attribute relationships between entities and entity attributes can be designed as relationships between entities, allowing them to be handled similarly.

[0059] Furthermore, the created knowledge graph can be used to provide more comprehensive applications. With further reference to Fig. 1. The created knowledge graph D113 is entered into the knowledge graph application unit M111 to perform tasks for analyzing the cause of product defects.

[0060] In one embodiment, the knowledge graph application unit M111 can provide services for generating causal chains for product defects. For example, the product defect causal chain generation service can visualize all possible defect cause paths based on the defective product, component, or defect phenomenon queried by the user. In another embodiment, the knowledge graph application unit M111 can visualize all possible defect cause paths based on the knowledge graph stored in the graph database and calculate the weight for each connecting edge, where the connecting edge with the higher weight indicates a higher probability / frequency of defect. In one embodiment, the weight of each connecting edge can be calculated based on degree centrality, eigenvector centrality, intermediate centrality, or connection centrality.

[0061] Fig. Figure 3 shows a causal chain diagram for the root cause analysis of product defects using the knowledge graph created according to an embodiment of the present invention. As in Fig. As shown in Figure 3, each point represents an entity, and each connecting edge represents the relationship between entities. For example, node A represents product A, node MA represents production plant A, node PA represents production facility A, node DA represents design document A, and the reference mark with the suffix B is expressed in the same way as the reference mark with the suffix A. In the example in Fig. 3. The product / component attributes contained in the design file are also designed as entities, where Ma represents the material, Si the size, and Dr the drawing. The presence of connecting edges between nodes indicates the presence of potential fault paths, and connecting edges with a higher weight indicate a higher probability / frequency of faults.

[0062] In one embodiment, a Depth First Search (DFS) can be performed in descending order of connection edge weighting until the actual root cause of the defect is found. For example, when performing the root cause analysis for product B, the first step is to reach production plant MB along the connection edge with a weighting of 0.6; if production plant MB is not the cause of the defect, the next step is to reach design document DB along the connection edge with a weighting of 0.5; to determine if design document DB is the cause of the defect, the dimensions, materials, and drawings in design document DB must be checked in order from highest to lowest weighting; if design document DB is not the cause of the defect, the next step is to check design document DA with a weighting of 0.3.A similar procedure should be followed until the exact cause of the error is found.

[0063] In one embodiment, the M111 knowledge graph application unit can provide root cause search services for product defects. For example, multiple potential root cause nodes can be provided based on the defective product, the defective component, or the defect phenomenon queried by the user. In one embodiment, users can use the SPARQL language to perform queries. In another embodiment, the returned root cause nodes can be sorted and filtered according to the order of the connecting edges' weighting, from largest to smallest, as described above.

[0064] In one embodiment, the knowledge graph application unit M111 can provide an automated root cause generation service for product defects. For example, if a defect occurs on the production line, the knowledge graph application unit M111 can provide the user with derived root cause nodes for the product defect based on the identified defect. In one embodiment, the user can be provided with multiple possible root cause nodes, and the provided root cause nodes can be sorted and filtered in descending order according to the connection edge weights, as described above.

[0065] The above descriptions have shown how heterogeneous data from multiple sources related to products can be used to create a knowledge graph and provide a variety of applications for root cause analysis of product defects based on this knowledge graph. To further improve the root cause analysis capability of the created knowledge graph, the present invention also provides a method for training the created knowledge graph using a machine learning model.

[0066] With further reference to Fig. 1. The created knowledge graph D113 is optionally entered into the knowledge graph training unit M112 to be trained using a machine learning model.

[0067] In one embodiment, the created knowledge graph D113 is fed into the machine learning model, and supervised training is performed based on the most probable error path or error node of the output. For example, the created knowledge graph D113 is fed into the machine learning model in the form of a graph, where the nodes and edges of the knowledge graph can each be converted into multidimensional vectors; subsequently, the knowledge graph D113 can output the most probable error path or error node, which can also be represented as a multidimensional vector, where, for example, as described above, the most probable error paths or error nodes are filtered according to the order of the connecting edge weights from largest to smallest.In one embodiment, the machine learning model can be a neural graph network model, for example one or more of a graph convolutional network, a graph autoencoder, a graph generative network, a graph recurrent network, or a graph attentional network.

[0068] During the training process, the machine learning model can use the actual fault path or fault node as a label, with the most probable fault path of the output or the difference between the fault node and the label being used as the loss function. Training the knowledge graph D113 is achieved by minimizing this loss function. For example, the most probable fault path of the output or the difference between the fault node and the label can be measured using cosine similarity, log-likelihood similarity, Euclidean distance, Manhattan distance, etc. The trained knowledge graph D114 is then fed into the knowledge graph application unit M111 to perform the product fault root analysis task.

[0069] Fig. Figure 4 shows a flowchart for the root cause analysis of product defects based on a knowledge graph according to an embodiment of the present invention, wherein the dashed boxes represent optional operations. Each step provided in this embodiment can be implemented by one or more devices with computing capabilities in the form of software and / or hardware.

[0070] In step S401, design data associated with the product can be obtained, where the design data includes semi-structured and / or unstructured data. The process of step S401 can be carried out, for example, by referencing... Fig. 1. The design data storage unit M101 described above will be implemented.

[0071] In one embodiment, the design data originates from one or more of the following: product requirements documents, product assembly drawings, component design documents, component design drawings, circuit design files, graphical schematics, and design logs. For example, circuit design files and design logs can be stored in XML (Extensible Markup Language) or HTTP (Hypertext Markup Language) format, which have semi-structured data structures. Product requirements documents and component design documents can be stored in any suitable office document or text format, while product assembly drawings, component design drawings, and circuit graphics can be stored in image formats such as CAD or JPG, or PDF, and they have unstructured data structures.

[0072] In step S402, the production data associated with the product can be obtained, whereby the production data includes structured data. The process of step S402 can be carried out, for example, by referencing... Fig. 1. The production data storage unit M105 described above will be implemented.

[0073] In one example, the production data originates from one or more of the following areas: Manufacturing Execution System (MES), SAP system, production statistics. Production statistics data can include production records from factories, production records from plants, production records from production lines, and / or production records from equipment.

[0074] In step S403, an optical character recognition (OCR) process can optionally be applied to the design data to convert text in the design data into a computer-readable text format. This process in step S403 can be performed, for example, by referencing... Fig. 1. The described design data preprocessing unit M102 will be implemented.

[0075] In step S404, information extraction for design data can be performed to obtain structured data. The process from step S403 can be modified, for example, by referencing... Fig. 1. The described design data preprocessing unit M102 will be implemented.

[0076] In one embodiment, performing information extraction from the design data further includes performing entity extraction from the design data to identify entities and relationships between entities. For example, entity extraction can be performed using one or any number of the following: rule-based methods such as regular matching, etc.; methods based on statistical models, such as hidden Markov models, conditional Markov models, maximum entropy models, and conditional random field models, etc.; and methods based on deep learning, such as methods based on convolutional neural networks, recurrent neural networks, and neural networks that introduce attentional mechanisms, such as LSTM-CRF, LSTM-CNN-CRF, Transformer, etc.For example, relationship extraction can be performed using one or any number of the following: template-based relationship extraction methods; supervised learning-based relationship extraction methods, such as converting relationship extraction into classification problems and training models like support vector machines and Naive Bayes; weakly supervised learning-based relationship extraction methods, such as the bootstrapping method.

[0077] In one embodiment, entity extraction and relationship extraction are performed separately, one after the other. In other embodiments, entity extraction and relationship extraction are performed simultaneously, for example, using methods such as BERT, LSTM-RNN, and DGCNN.

[0078] In another embodiment, performing information extraction from the design data further includes performing attribute extraction from the design data to identify attributes of entities within the design data. For example, attribute extraction can be performed using one or any number of the following: based on unsupervised methods, such as rule-based slot-filling methods, clustering-based methods, etc.; semi-supervised methods based on dependencies, such as the PageRank algorithm; or sequence annotation methods based on deep learning, such as CRF models, BI-GRU+CRF models, etc. In another example, the attribute extraction process can also be implemented as a specific instance of the relationship extraction process and can therefore be implemented using a similar relationship extraction method.

[0079] In one embodiment, performing information extraction from the design data includes one or more of the following tasks: word segmentation, word list querying, syntactic analysis, corpus processing, named entity recognition, term extraction, part-of-speech tagging, recognition of word meaning roles and entity relationships, and sequence tagging.

[0080] In one embodiment, the structured design data is organized as design metadata with corresponding design drawing numbers. The design drawing number can correspond to the index of the data table, and the design metadata can correspond to the header rows of multiple data tables, where each data table is considered a class, each row in the table represents an instance or object of the class, and each column in the table represents the attributes of the class. The design metadata can then be extracted through an information extraction process, with the extracted design metadata potentially corresponding to entities, relationships, and / or attributes.For example, the design metadata includes one or more of the following elements: product name, product number, number of components, component name, component number, component shape, component material, component size, and assembly sequence.

[0081] Optionally, one or more of the following elements—expert experience, procurement data, material data, and acceptance data—can also be retrieved in step S405. The process of step S405 can, for example, be carried out with reference to… Fig. The expert experience storage unit M107, as described above, will be implemented. The data from various sources is structured, semi-structured, or unstructured and can be processed with reference to the corresponding descriptions above.

[0082] In step S406, knowledge fusion can be performed on the knowledge generated based on production data and structured design data, respectively, to create a target knowledge graph. Optionally, the knowledge fusion can be further extended to data generated based on one or more of the following elements: expert experience, procurement data, material data, and acceptance data, to create a target knowledge graph. The process of step S406 can be implemented, for example, by the design knowledge generation unit M103, the production knowledge generation unit M106, and the expert knowledge generation unit M109, which reference... Fig. 1 are described. Furthermore, the process of step S406 can be, for example, described with reference to Fig. The knowledge fusion unit M104 described in section 1 can be implemented. Optionally, the process from step S406 can be carried out, for example, by referring to... Fig. The described knowledge graph generation unit M110 will be implemented.

[0083] In one embodiment, the production data and structured design data can each be converted into one of the following formats: Resource Description Framework (RDF) ternary format, RDF quaternary format with time information, RDFS ternary format or RDFS quaternary format with time information, in order to obtain knowledge that is generated on the basis of the production data or the structured design data, respectively.

[0084] In the next embodiment, the ontology library can establish an ontology library comprising multiple ontologies based on at least the design data and the production data (optionally one or more of the elements expert experience, procurement data, material data, acceptance data); and subsequently, the production data and the structured design data in RDF or RDFS ternary format or in RDF or RDFS quaternary format are mapped to the multiple ontologies to obtain the production data based on the production data and the knowledge contained in the structured design data. For example, ontologies can be developed bottom-up and / or top-down based on the primal data associated with the product.For example, the ontology library includes one or more of the following ontologies: design ontology, product ontology, equipment ontology, material ontology, real asset ontology, process segment ontology, expert ontology, procurement ontology, and acceptance ontology.

[0085] In one embodiment, knowledge fusion includes one or more of the following tasks, assuming the knowledge based on the production data and the structured design data is RDF ternary or RDF quaternary data: data cleansing, entity alignment, entity matching, entity disambiguation, and relationship deduplication. In this embodiment, the fused knowledge is mirrored across the multitude of ontologies to create the target knowledge graph.

[0086] In another embodiment, knowledge fusion encompasses one or more of the following tasks when the knowledge based on production data and structured design data is mirrored across multiple ontologies: data cleansing, entity alignment, entity matching, entity disambiguation, and relationship deduplication. In this embodiment, the fused knowledge is the target knowledge graph.

[0087] In an optional embodiment, a similar processing can still be carried out based on one or more of the elements expert experience, procurement data, material data and acceptance data with reference to the above description to create the target knowledge graph.

[0088] In another embodiment, during knowledge fusion, equivalent ontologies / entities, contradictory ontologies / entities, duplicate ontologies / relationships between entities and / or attributes that can be merged can be identified by expert identification.

[0089] In step S407, a task to analyze the cause of a product defect can be performed based on the target knowledge graph. The process of step S405 can, for example, be carried out by referring to Fig. The described knowledge graph application unit M111 will be implemented.

[0090] In one embodiment, performing root cause analysis tasks for product defects based on the target knowledge graph includes the following: using at least the entities in the target knowledge graph as nodes; using the relationships between the entities as connecting edges; and calculating the weight of each connecting edge. Furthermore, using a depth-first search to perform the root cause analysis task based on the weight of each connecting edge. For example, the weight of each connecting edge can be calculated based on degree centrality, eigenvector centrality, intermediate centrality, or connection centrality. For example, the root cause analysis task includes a service to generate a causal chain for product defects, a service to search for root causes of product defects, and / or a service to automatically generate the root causes of product defects.

[0091] Optionally, in step S408, the target knowledge graph can be trained using a machine learning model, and then the task of analyzing the cause of product defects from step S407 can be performed based on the trained target knowledge graph. The process of step S408 can be carried out, for example, by referencing Fig. The described knowledge graph training unit M112 will be implemented.

[0092] In one embodiment, the use of a machine learning model to train the target knowledge graph can include: using at least the entities in the target knowledge graph as nodes and using the relationships between the entities as connecting edges to generate a graph; representing the nodes and connecting edges as vectors and using a neural graph network model to train the target knowledge graph. For example, a neural graph network model can be one or any combination of a graph convolutional network, a graph autoencoder, a graph generation network, a graph recurrent network, or a graph attention network.

[0093] In one embodiment, the use of a machine learning model to train the target knowledge graph can include the following: The difference between the most probable error path or error node output by the target knowledge graph and the actual error path or error node is used as the loss function, and the training of the target knowledge graph is achieved by minimizing the loss function.

[0094] For example, the most probable error path of the output or the difference between the error node and the label can be measured by cosine similarity, log likelihood similarity, Euclidean distance, Manhattan distance, etc.

[0095] Fig. Figure 5 shows a block diagram of a device for root cause analysis of product defects based on a knowledge graph according to an embodiment of the present invention.

[0096] The exemplary computer device 500 comprises an internal communication bus 502 and a processor (e.g., a central processing unit (CPU)) 504 coupled to the internal communication bus 502. The processor 504 is used to execute instructions stored in the memory device 506 to implement the method of product failure root cause analysis based on the knowledge graph described in detail above. The memory device 506 is suitable for the tangible embodiment of computer program instructions and data and may include various forms of storage devices, including, for example, semiconductor storage devices such as EPROM, EEPROM, and flash memory devices; data carriers such as internal hard disks and removable media; magneto-optical data carriers and CD-ROM data carriers, etc. The computer device 500 may also include an input / output (I / O) interface 508, allowing various I / O devices (e.g.,Cursor control devices (such as a mouse, keyboard, etc.) can be connected to the computer device 500 via the I / O interface 508 to allow a user to issue various commands and enter data. The computer device 500 can also include a display unit 510 for displaying a graphical user interface.

[0097] The computer program can contain instructions that can be executed by the computer, and these instructions are used to instruct the processor 504 of the computing device 500 to perform the product failure root cause analysis method based on the knowledge graph of the present invention. Programs can be stored on any data carrier, including a storage device. For example, the program can be implemented in digital electronic circuits or in computer hardware, firmware, software, or a combination thereof. The processes / method steps described in the present invention can be executed by a programmable processor that executes program instructions to perform methods, steps, and operations by processing input data and generating outputs.

[0098] It should be noted that "based on" in this description means "at least based on" and not "only based on". In addition to what is described herein, various modifications can be made to the disclosed embodiments and implementations without altering the scope of the disclosed embodiments and implementations. Accordingly, the descriptions and examples contained herein should be interpreted in an illustrative rather than a limiting sense. The scope of the present invention should be assessed solely with reference to the claims.

Claims

[1] Method for root cause analysis of product defects based on a knowledge graph, which includes: Capturing the design data associated with the product, wherein the design data comprises semi-structured data and / or unstructured data; Capturing the production data associated with the product, where the production data includes structured data; Performing information extraction on the design data to obtain structured data; Performing a knowledge fusion of the knowledge generated based on the production data and the structured design data to create a target knowledge graph; and Carrying out the root cause analysis tasks for product defects using the target knowledge graph. [2] The method of claim 1, further comprising: Generating expert knowledge based on expert experience; The knowledge generated based on the production data and the structured design data is merged with the expert knowledge to build the target knowledge graph. [3] The method of claim 1, further comprising: Before performing information extraction from the design data, an optical character recognition process is applied to the design data to convert text in the design data into a computer-readable text format. [4] The method of claim 1, wherein the information extraction from the design data comprises: Perform entity extraction and relationship extraction from the design data to identify entities and relationships between entities from the design data. [5] The method of claim 4, wherein performing information extraction from the design data further comprises: performing attribute extraction from the design data to identify attributes of entities from the design data. [6] The method of claim 1, wherein performing the information extraction from the design data comprises one or more of the following tasks: Word segmentation, word list retrieval, syntactic analysis, corpus processing, named entity recognition, term extraction, part-of-speech tagging, word meaning role and entity relationship detection, and sequence tagging. [7] The method of claim 1, wherein the structured design data is organized in the form of design metadata with corresponding design drawing numbers. [8] The method of claim 7, wherein the construction metadata corresponds to the entities, the relationship between the entities, the attribute of an entity, or any combination thereof obtained by performing the information extraction; and / or the construction metadata comprises one or more of the following elements: Product name, product number, component quantity, component name, component number, component shape, component material, component size and assembly sequence. [9] The method of claim 1, further comprising: Converting the production data and structured design data into one of the following formats: Resource Description Framework (RDF) ternary format, RDF quaternary format with time information, RDFS format, or RDFS quaternary format with time information, in order to obtain knowledge generated based on the production data or the structured design data, respectively. [10] The method of claim 9, further comprising: Creating an ontology library based at least on the design data and the production data, the ontology library comprising multiple ontologies; Mirroring the production data and the structured design data that have an RDF or RDFS ternary format or an RDF or RDFS quaternary format to the ontologies in order to obtain knowledge generated based on the production data and the structured design data. [11] The method of claim 10, wherein the ontology library comprises one or more of the following: design ontology, product ontology, device ontology, material ontology, real asset ontology, process segment ontology, expert ontology, procurement ontology, and acceptance ontology. [12] A method according to claim 1, wherein the design data is derived from one or more of the following elements: Product requirement documents, product assembly drawings, component design documents, component design drawings, circuit design files, graphical schematics and design records. [13] Method according to claim 1, wherein the production data originate from one or more of the following areas: production control system (MES), SAP system, production statistics data. [14] The method of claim 1, wherein performing the tasks for analyzing the product failure causes based on the target knowledge graph comprises: Using at least the entities in the target knowledge graph as nodes, using the relationships between the entities as connecting edges, and calculating the weight of each connecting edge; In addition, depth-first search is used to perform the tasks of analyzing the causes of product defects based on the weight of each connecting edge. [15] The method of claim 14, wherein the weight of each connecting edge is calculated based on degree centrality, eigenvector centrality, betweenness centrality, or connection centrality. [16] The method of claim 1, further comprising: Using at least the entities in the target knowledge graph as nodes and Using the relationships between the entities as connecting edges to generate a graph; Representing the nodes and connecting edges as vectors and using a neural graph network model to train the target knowledge graph; and Performing the tasks of analyzing the causes of product defects using the trained target knowledge graph. [17] The method of claim 16, wherein the graph neural network model comprises one of the following: graph convolutional network, graph autoencoder, graph generation network, recurrent graph network, or graph attention network. [18] System for root cause analysis of product defects based on a knowledge graph, comprising: a memory; a processor coupled to the memory, the processor configured to cause one or more devices to perform a method according to any one of claims 1 to 17. [19] A computer-readable medium having stored thereon a computer program comprising instructions which, when executed by a processor, cause one or more units to carry out a method according to any one of claims 1 to 17.

Images