Method for accessing standard knowledge graph to PLM platform

Abstract

The invention discloses a method for accessing a standard knowledge graph to a PLM platform, and the method comprises the following steps: S1, environment initialization: deploying an AP I gateway in the PLM platform, and setting an address and a login credential of a standard knowledge graph service in the AP I gateway; s2, metadata mapping: establishing a mapping relationship between the PLM data model and a standard knowledge graph ontology; s3, service registration: registering a PLM service event trigger service through an AP I interface; and S4, calling service: calling reasoning service based on the PLM data and the marker knowledge graph based on an event-driven mechanism. The method has the advantages that seamless connection between the standard knowledge graph and the PLM platform is achieved by designing an interface, semantic association between a structured data model in the PLM platform and a standard knowledge graph body is established by adopting dynamic body modeling and a hybrid (rule + artificial intelligence) entity mapping technology, and the semantic gap problem between heterogeneous data is solved.

Description

Technical Field

[0001] The present invention relates to the field of product lifecycle management (PLM) and knowledge graph technology, and in particular to a method for accessing a standard knowledge graph to a PLM platform. Background Art

[0002] Currently, PLM platforms lack structured knowledge management capabilities, resulting in severe data silos. Traditional data integration methods struggle to support dynamic semantic associations and intelligent reasoning. Furthermore, entity mapping between heterogeneous systems is inefficient and inaccurate, making it difficult for PLM platform users to use and evaluate standards based on scenarios or tasks.

[0003] As for existing solutions, rule-based data mapping has poor flexibility, high maintenance costs, and lacks unified standardized knowledge representation and interface specifications. Summary of the Invention

[0004] The purpose of the present invention is to provide a method for accessing a standard knowledge graph to a PLM platform, thereby solving the aforementioned problems existing in the prior art.

[0005] In order to achieve the above object, the technical solution adopted by the present invention is as follows:

[0006] A method for connecting a standard knowledge graph to a PLM platform includes the following steps:

[0007] S1. Environment initialization: Deploy the API gateway on the PLM platform and set the address and login credentials of the standard knowledge graph service in the API gateway;

[0008] S2. Metadata mapping: Establish a mapping relationship between the PLM data model and the standard knowledge graph ontology;

[0009] S3. Service registration: Register the PLM business event triggering service through the API interface;

[0010] S4. Invoke service: Invoke reasoning service based on PLM data and labeled knowledge graph based on event-driven mechanism.

[0011] Preferably, step S2 specifically includes the following contents:

[0012] S21. Semantic analysis of PLM metadata and standard knowledge graph ontology: By extracting the metadata model of the PLM platform, adding semantic tags to PLM data fields and associating them with the classes or attributes of the standard knowledge graph ontology, a semantic association is established between the structured data model in the PLM platform and the standard knowledge graph ontology.

[0013] S22, Mapping rule definition: Define the mapping rules from the PLM platform to the standard knowledge graph domain ontology, and automatically recommend candidate mapping relationships based on the trained machine learning model;

[0014] S23, conflict detection and mapping optimization: Eliminate naming conflicts, structural conflicts, and constraint conflicts between the PLM platform and the standard knowledge graph ontology through semantic disambiguation, setting structure adapters, and data type mandatory conversion;

[0015] S24. Dynamic maintenance of mapping relationships: Monitor data change events in the PLM platform to trigger re-execution of mapping rules; add version numbers to mapping rules and ontologies to support historical version backtracking and compatibility verification; automatically feed back user correction data on mapping results to the machine learning model to optimize subsequent mapping rule recommendations.

[0016] Preferably, step S22 specifically includes the following contents:

[0017] S221. Rule-driven static mapping: Explicit mapping rules are defined based on domain expert knowledge. The explicit mapping rules include:

[0018] Field to attribute mapping: PLM field names are directly matched with ontology attribute names;

[0019] Table to class mapping: PLM database tables are mapped to classes in the ontology;

[0020] Relationship conversion: PLM foreign key relationships are converted into ontology object attributes;

[0021] S222. Machine learning-driven dynamic mapping: A training dataset is constructed based on manually standardized PLM field-ontology attribute mapping samples. The dataset is input into a BERT-based semantic similarity model or Siamese network to calculate the similarity between PLM field names, field values, and ontology attributes, thereby training the machine learning model. The trained machine learning model is used to recommend candidate mapping relationships, which are then confirmed or modified by the user.

[0022] Preferably, step S23 specifically includes: using unified terminology for standardized expression based on the synonym library, domain dictionary or standard specification in the ontology to eliminate naming conflicts between the PLM platform and the standard knowledge graph ontology; designing the middle-layer conversion logic to reorganize the PLM flat data according to the ontology hierarchy to eliminate structural conflicts between the PLM platform and the standard knowledge graph ontology; defining type conversion functions in the mapping rules to eliminate constraint conflicts between the PLM platform and the standard knowledge graph ontology;

[0023] The naming conflict is that the same entity has different names in the PLM platform and the ontology;

[0024] The structural conflict is that the flat table structure in PLM does not match the hierarchical relationship of the ontology;

[0025] The constraint conflict is that the value range of the PLM field conflicts with the ontology attribute definition.

[0026] Preferably, the API interface includes:

[0027] Knowledge query API: supports SPARQL / Cypher syntax retrieval;

[0028] Entity Update API: used to implement dynamic addition, deletion, and modification of standard knowledge graphs;

[0029] Reasoning Service AIP: implements logical reasoning based on the rule engine;

[0030] The communication protocol of the API interface is RESTful API and GraphQL dual-mode adaptation, and supports JSONLD data format; the security mechanism of the API interface is OAuth 2.0 authentication and access permission hierarchical control.

[0031] Preferably, step S4 specifically includes the following contents:

[0032] S41, Event monitoring and capture: Real-time capture of data change events in the PLM platform to trigger service processes;

[0033] S42, Event Processing and Routing: Filter irrelevant events based on business needs; route to different processing logic based on operation type and business scenario; convert raw events into inference service instructions;

[0034] S43. Service operation: High-priority events trigger services immediately, and low-priority events process services in batches; update the standard knowledge graph through SPARQL / API calls after event conversion, monitor the reasoning results of the standard knowledge graph, and reversely trigger PLM platform alarms and data rollbacks.

[0035] Preferably, step S41 specifically includes:

[0036] Database layer monitoring: capturing data change events through database log analysis;

[0037] Application layer monitoring: embed event publishing interface in PLM business logic;

[0038] Message queue integration: Push events to message queues to achieve asynchronous decoupling and high throughput.

[0039] Preferably, the reasoning service specifically includes the following contents:

[0040] S51, Standard Matching: Inferring products and specification categories through PLM task data and matching usage standards;

[0041] S52. Compliance Reasoning: Reasoning on products and / or components based on matching applicable standards to determine whether the current product data meets the requirements of the applicable standards. If there is no applicable standard, reasoning is performed based on approximate standards.

[0042] S53. Update PLM data according to the reasoning result: If the reasoning result shows that the PLM data does not meet the standard requirements, the classification updates the PLM data according to the reasoning result;

[0043] S54, dynamic feedback and optimization: record synchronization success / failure events and generate statistical reports; dynamically adjust the batch synchronization window size or number of concurrent threads based on historical data; feed back synchronization failure cases to the machine learning model to optimize event conversion logic.

[0044] Preferably, the semantic similarity of entities is calculated by combining product word vectors with the ontology hierarchy and / or by utilizing a rule engine to match applicable criteria;

[0045] If the current product completely falls within the scope of applicable standards, the matching is completed; if there is no applicable standard for the current product, the standards of similar products are matched to the entire product, or the standards are matched to the components and structure of the product.

[0046] Preferably, step S53 specifically includes the following contents:

[0047] S531. The categories of reasoning results specifically include:

[0048] The numerical class is the numerical value in the PLM data and the knowledge graph;

[0049] Process categories include process, flow, and method;

[0050] The definition class is to modify the definition of the data structure in PLM according to the structure of the knowledge graph;

[0051] S532: The processing of the inference result specifically includes:

[0052] Manual intervention: notify the administrator through alarms to handle the problem;

[0053] Automatic adjudication: Automatically adopt and update PLM data based on preset rules. For numerical types, PLM data is automatically updated according to the reasoning results. For process types, PLM processes are updated; for definition types, the definition of PLM data structure is modified.

[0054] The beneficial effects of this invention are as follows: 1. It uses dynamic ontology modeling and hybrid (rule + artificial intelligence) entity mapping technology to establish semantic associations between the structured data model in the PLM platform and the domain ontology of the standard knowledge graph, thus addressing the semantic gap between heterogeneous data. 2. It seamlessly integrates the standard knowledge graph with the PLM platform through the design of an API interface, automatically establishing structural design workflows, documentation requirements, and execution standards based on the structural design flow charts specified in the standard. 3. It uses an event-driven mechanism to enable PLM to invoke services and update data in the standard knowledge graph. BRIEF DESCRIPTION OF THE DRAWINGS

[0055] Figure 1 This is a system architecture diagram of the standard knowledge graph connected to the PLM platform in an embodiment of the present invention;

[0056] Figure 2 This is a flow chart of connecting a standard knowledge graph to a PLM platform in an embodiment of the present invention;

[0057] Figure 3 FIG. 4 is a flowchart of the inference service in an embodiment of the present invention. DETAILED DESCRIPTION

[0058] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present invention will be further described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0059] Example 1

[0060] like Figure 1 and Figure 2 As shown, in this embodiment, a method for accessing a standard knowledge graph to a PLM platform is provided, including the following parts:

[0061] 1. Environment initialization

[0062] Deploy the API gateway on the PLM platform and set the address and login credentials of the standard knowledge graph service in the API gateway.

[0063] 2. Metadata Mapping

[0064] Using dynamic ontology modeling and hybrid (rule + artificial intelligence) entity mapping technology, a mapping relationship is established between PLM data models (such as BOM, change order) and standard knowledge graph ontology. Specifically, it includes the following contents:

[0065] 2.1 Semantic Analysis of PLM Metadata and Standard Knowledge Graph Ontology

[0066] Establish semantic associations between the structured data models in the PLM platform (such as BOM tables, process routes, change orders) and the domain ontology of the standard knowledge graph (such as products, components, processes, procedures, etc.) to solve the semantic gap problem between heterogeneous data.

[0067] (1) PLM data model analysis: Extract the metadata model of the PLM platform (such as database table structure, field constraints, entity relationship diagram).

[0068] (2) Semantic mapping annotation: Add semantic tags (such as OWL annotations) to PLM data fields and associate them with classes or attributes in the ontology. The semantic tag addition can refer to the tag definition in the PLM platform form design process, or use a large language model to directly generate semantic tags. Associate with classes and attributes in the ontology based on character similarity and semantic similarity, such as directly matching PLM field names with ontology attribute names. Alternatively, the semantic tags of the two can be matched. If the semantic tags are consistent, an association can also be established.

[0069] 2.2 Mapping rule definition

[0070] (1) Rule-driven static mapping:

[0071] Based on domain expert knowledge, define explicit mapping rules (Schema Mapping Rules):

[0072] Field to attribute mapping: PLM field names are directly matched with ontology attribute names.

[0073] Table to class mapping: PLM database tables are mapped to classes in the ontology.

[0074] Relationship conversion: PLM foreign key relationships are converted to ontology object attributes.

[0075] (2) Dynamic mapping driven by machine learning:

[0076] Training data construction: based on manually annotated PLM field ontology attribute mapping samples.

[0077] Model training: A BERT-based semantic similarity model or Siamese network is used to calculate the similarity between PLM field names, field values, and ontology attributes.

[0078] Automatic recommendation: The model recommends candidate mapping relationships, which are then confirmed or modified by the user.

[0079] 2.3 Conflict Detection and Mapping Optimization

[0080] (1) Conflict type:

[0081] Naming conflicts: The same entity has different names in PLM and ontology.

[0082] Structural conflict: The flat table structure in PLM does not match the hierarchical relationship of the ontology (such as a multi-level BOM expanded into a tree structure).

[0083] Constraint conflict: The value range of the PLM field conflicts with the ontology attribute definition.

[0084] (2) Solution:

[0085] Semantic disambiguation: Standardize terms using a unified terminology based on thesaurus in the ontology (such as WordNet), domain dictionaries, or standards. For example, the term "screwdriver" is standardized as "screwdriver." Standards, domain dictionaries, and synonyms are used as the primary reference for standardization.

[0086] Structural adapter: Design the middle-layer conversion logic to reorganize PLM flat data according to the ontology level.

[0087] Data type conversion: Define type conversion functions (such as integer → floating point) in the mapping rules.

[0088] 2.4 Dynamic Maintenance of Mapping Relationships

[0089] (1) Event monitoring: Monitor data change events on the PLM platform (such as new parts and design changes) to trigger the re-execution of mapping rules.

[0090] (2) Version management: Add version numbers to mapping rules and ontology models to support historical version backtracking and compatibility verification.

[0091] (3) Feedback loop: The user’s correction data on the mapping results (such as incorrect mapping annotations) is automatically fed back to the machine learning model to optimize subsequent mapping recommendations.

[0092] 3. Service Registration

[0093] Register the PLM business event trigger service through the API interface. The API interface includes:

[0094] Knowledge query API: supports SPARQL / Cypher syntax retrieval.

[0095] Entity Update API: Implement dynamic addition, deletion, and modification of standard knowledge graphs.

[0096] Reasoning service API: Implements logical reasoning based on the rule engine (such as compliance verification and product similarity analysis).

[0097] Communication protocol of the API interface: RESTful API and GraphQL dual-mode adaptation, supporting JSONLD data format.

[0098] API interface security mechanism: OAuth 2.0 authentication and access permission hierarchical control.

[0099] 4. Calling Service

[0100] The event-driven mechanism invokes reasoning services based on PLM data and labeled knowledge graphs. Specifically, it includes the following:

[0101] 4.1 Event Monitoring and Capture

[0102] Capture data change events (addition, deletion, modification) in the PLM platform in real time and trigger service processes.

[0103] (1) Database layer monitoring: Capture data change events through database log analysis (such as MySQL Binlog, MongoDB Oplog).

[0104] (2) Application layer monitoring: embed the event publishing interface in the PLM business logic (such as calling the event publishing API when the design changes or BOM updates).

[0105] (3) Message queue integration: Push events to message queues (such as Kafka and RabbitMQ) to achieve asynchronous decoupling and high throughput.

[0106] 4.2 Event Handling and Routing

[0107] (1) Event filtering: Filter irrelevant events based on business needs (e.g., only process PLM table changes associated with the knowledge graph).

[0108] (2) Event classification: Routing to different processing logic according to operation type (INSERT / UPDATE / DELETE) and business scenario (design, manufacturing, quality inspection).

[0109] (3) Event conversion: converting raw events into reasoning service instructions (e.g., parameter changes into parameter compliance check instructions, and design changes into standard matching instructions).

[0110] 4.3 Service Operation

[0111] (1) Operation mode:

[0112] Real-time triggering: High-priority events (such as design changes) trigger service immediately.

[0113] Batch processing: Low-priority events (such as historical data migration) are processed in batches to reduce system load.

[0114] (2) Operation logic:

[0115] PLM → Knowledge Graph: Update the knowledge graph through SPARQL / API calls after event conversion.

[0116] Knowledge Graph → PLM: Monitor the reasoning results of the knowledge graph (such as compliance verification failure) and trigger PLM platform alarms or data rollbacks.

[0117] In this embodiment, Figure 3 As shown in the figure, the specific execution process of the inference service is as follows:

[0118] 1. Standard matching

[0119] Infer product and specification categories through PLM task data (such as product name, BOM, specifications, parameters, documents, etc.) and match applicable standards.

[0120] (1) If the current product falls completely within the applicable standard range, the match is complete

[0121] (2) If there is no applicable standard for the current product, the standard of a similar product shall be matched to the entire product, or the standard shall be matched to the component parts and structure of the product.

[0122] Matching method:

[0123] Semantic similarity calculation: Combine word vectors (Word2Vec / BERT) with ontology hierarchical structure to calculate entity similarity.

[0124] Rule engine: defines domain constraint rules.

[0125] 2. Compliance Reasoning

[0126] Reasoning is performed on products and / or components based on matching applicable standards to determine whether the current product data meets the requirements of the applicable standards. If there is no applicable standard, reasoning is performed based on approximate standards.

[0127] 3. Update PLM data based on inference results

[0128] If the reasoning result shows that the data in the PLM does not meet the standard requirements, the classification updates the PLM data based on the reasoning result.

[0129] (1) Result category

[0130] Numerical type: Numerical values ​​in PLM data and knowledge graphs (such as parameters).

[0131] Process type: process, procedure, method, etc.

[0132] Definition class: Modify the definition of the data structure in PLM according to the structure of the knowledge graph.

[0133] (2) Result adoption strategy

[0134] Manual intervention: notify the administrator through alarms to handle the problem;

[0135] Automatic Adjudication: Automatically adopt and update PLM data based on preset rules. For numerical data, PLM data is automatically updated based on the reasoning results (such as adopting a better indicator). For process data, PLM processes are updated. For definition data, the definition of PLM data structures is modified.

[0136] 4. Dynamic feedback and optimization

[0137] (1) Synchronization log monitoring: record synchronization success / failure events and generate statistical reports (such as delay time and success rate).

[0138] (2) Adaptive strategy adjustment: Dynamically adjust the batch synchronization window size or the number of concurrent threads based on historical data.

[0139] (3) Model training: Feedback synchronization failure cases (such as mapping rule errors) to the machine learning model to optimize the event conversion logic.

[0140] Example 2

[0141] In this embodiment, a certain system PLM platform is taken as an example to specifically illustrate the execution process of integrating the standard knowledge graph into the PLM platform:

[0142] 1. The structural design workflow of a certain system PLM platform is as follows:

[0143] 1. Match the "structural design requirements" in the industry standards from the standard library. Specifically: extract entities such as "bolt strength grade" and "assembly tolerance" from the standard library, CAD drawings, and process documents.

[0144] 2. Through the API interface, automatically establish the structural design workflow, documentation requirements, and execution standards based on the structural design flow chart specified in the standard. Specifically, the API interface links the PLM BOM table with the "Material Process Quality Inspection" link in the knowledge graph.

[0145] 3. When PLM initiates a design change, it automatically triggers the knowledge graph reasoning service to check whether it complies with ISO standards.

[0146] 2. The specific process of mapping the BOM table in a certain system PLM platform to the knowledge graph is as follows:

[0147] 1. Data analysis:

[0148] Extract the fields of BOM table: panel, core material, adhesive layer.

[0149] 2. Ontology matching:

[0150] Map "fiber" to the entity attribute "reinforcement fiber", "face plate" to "resin matrix", "core material" to "sandwich material", and "bonding layer" to "adhesive".

[0151] 3. Conflict Resolution:

[0152] It is found that there is an attribute "Panel" in PLM, while the attributes in the ontology are "Resin Matrix" and "Reinforcement Fiber". Through the API, add the "Resin Matrix" and "Reinforcement Fiber" fields under the attribute "Panel" in PLM.

[0153] It was found that the value of the "Panel" field in PLM was a string (such as "Carbon Fiber Reinforced Composite Material"), while the ontology required binding to a material standard library (such as "Carbon Fiber Classification and Code Library"). A conversion rule was added to map the string to the standard library URI.

[0154] 4. Generate an instance:

[0155] After conversion, RDF triples are generated and automatically associated with a composite material class in the knowledge graph to achieve compliance verification.

[0156] 3. The process of knowledge graph update triggered by design change of a system PLM platform is as follows:

[0157] 1. Event triggering:

[0158] The engineer changes the weight of part XXX01 from '50g' to '60g' in PLM, triggering the BOM_UPDATE event.

[0159] 2. Event handling:

[0160] Events are routed to the "weight update processor", which combines a rule engine (such as Drools) with real-time stream processing (such as Apache Flink) and converts them into SPARQL update statements.

[0161] 3. Knowledge graph update:

[0162] Call the knowledge graph update interface through the API and modify XXX01 to 60g. Use a difference comparison algorithm (such as hash-based incremental detection) to synchronize only the changed data. Also encrypt the event message (such as TLS) and verify the signature to prevent data tampering.

[0163] 4. Reverse verification:

[0164] After the knowledge graph reasoning service detects a weight change, it verifies whether it complies with the ISO standard on weight limits and sends an alarm to the PLM if there is a violation.

[0165] By adopting the above technical solution disclosed in the present invention, the following beneficial effects are obtained:

[0166] This invention provides a method for integrating a standard knowledge graph into a PLM platform. By using dynamic ontology modeling and hybrid (rule + artificial intelligence) entity mapping technology, a semantic association is established between the structured data model in the PLM platform and the domain ontology of the standard knowledge graph, addressing the semantic gap between heterogeneous data. By designing an API interface, the standard knowledge graph is seamlessly integrated with the PLM platform, automatically establishing structural design workflows, documentation requirements, and execution standards based on the structural design flow chart specified in the standard. An event-driven mechanism is used to enable PLM to invoke services and update data on the standard knowledge graph.

[0167] The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present invention. These improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for integrating a standard knowledge graph into a PLM platform, characterized by: The following steps are included: S1. Environment initialization: Deploy the API gateway on the PLM platform and set the address and login credentials of the standard knowledge graph service in the API gateway; S2. Metadata mapping: Establish a mapping relationship between the PLM data model and the standard knowledge graph ontology; S3. Service registration: Register the PLM business event triggering service through the API interface; S4. Invoke service: Invoke reasoning service based on PLM data and labeled knowledge graph based on event-driven mechanism.

2. The method for integrating a standard knowledge graph into a PLM platform according to claim 1, characterized in that: Step S2 specifically includes the following contents: S21. Semantic analysis of PLM metadata and standard knowledge graph ontology: By extracting the metadata model of the PLM platform, adding semantic tags to PLM data fields and associating them with the classes or attributes of the standard knowledge graph ontology, a semantic association is established between the structured data model in the PLM platform and the standard knowledge graph ontology. S22, Mapping rule definition: Define the mapping rules from the PLM platform to the standard knowledge graph domain ontology, and automatically recommend candidate mapping relationships based on the trained machine learning model; S23, conflict detection and mapping optimization: Eliminate naming conflicts, structural conflicts, and constraint conflicts between the PLM platform and the standard knowledge graph ontology through semantic disambiguation, setting structure adapters, and data type mandatory conversion; S24. Dynamic maintenance of mapping relationships: Monitor data change events in the PLM platform to trigger re-execution of mapping rules; add version numbers to mapping rules and ontologies to support historical version backtracking and compatibility verification; automatically feed back user correction data on mapping results to the machine learning model to optimize subsequent mapping rule recommendations.

3. The method for integrating a standard knowledge graph into a PLM platform according to claim 2, characterized in that: Step S22 specifically includes the following contents: S221. Rule-driven static mapping: Explicit mapping rules are defined based on domain expert knowledge. The explicit mapping rules include: Field to attribute mapping: PLM field names are directly matched with ontology attribute names; Table to class mapping: PLM database tables are mapped to classes in the ontology; Relationship conversion: PLM foreign key relationships are converted into ontology object attributes; S222. Machine learning-driven dynamic mapping: A training dataset is constructed based on manually standardized PLM field-ontology attribute mapping samples. The dataset is input into a BERT-based semantic similarity model or Siamese network to calculate the similarity between PLM field names, field values, and ontology attributes, thereby training the machine learning model. The trained machine learning model is used to recommend candidate mapping relationships, which are then confirmed or modified by the user.

4. The method for integrating a standard knowledge graph into a PLM platform according to claim 2, characterized in that: Step S23 specifically involves using unified terminology to perform standardized expressions based on the synonym library, domain dictionary, or standard specifications in the ontology to eliminate naming conflicts between the PLM platform and the standard knowledge graph ontology; Design the middle-layer conversion logic to reorganize the PLM flat data according to the ontology level to eliminate the structural conflicts between the PLM platform and the standard knowledge graph ontology; Define type conversion functions in mapping rules to eliminate constraint conflicts between the PLM platform and standard knowledge graph ontology; The naming conflict is that the same entity has different names in the PLM platform and the ontology; The structural conflict is that the flat table structure in PLM does not match the hierarchical relationship of the ontology; The constraint conflict is that the value range of the PLM field conflicts with the ontology attribute definition.

5. The method for integrating a standard knowledge graph into a PLM platform according to claim 1, characterized in that: The API interface includes: Knowledge query API: supports SPARQL / Cypher syntax retrieval; Entity Update API: used to implement dynamic addition, deletion, and modification of standard knowledge graphs; Reasoning Service AIP: implements logical reasoning based on the rule engine; The communication protocol of the API interface is RESTful API and GraphQL dual mode adaptation, supporting JSONLD data format; The security mechanism of the API interface is OAuth 2.0 authentication and access permission hierarchical control.

6. The method for integrating a standard knowledge graph into a PLM platform according to claim 1, characterized in that: Step S4 specifically includes the following contents: S41, Event monitoring and capture: Real-time capture of data change events in the PLM platform to trigger service processes; S42, Event Processing and Routing: Filter irrelevant events based on business needs; route to different processing logic based on operation type and business scenario; convert raw events into inference service instructions; S43. Service operation: High-priority events trigger services immediately, and low-priority events process services in batches; update the standard knowledge graph through SPARQL / API calls after event conversion, monitor the reasoning results of the standard knowledge graph, and reversely trigger PLM platform alarms and data rollbacks.

7. The method for integrating a standard knowledge graph into a PLM platform according to claim 6, characterized in that: Step S41 specifically includes: Database layer monitoring: capturing data change events through database log analysis; Application layer monitoring: embed event publishing interface in PLM business logic; Message queue integration: Push events to message queues to achieve asynchronous decoupling and high throughput.

8. The method for integrating a standard knowledge graph into a PLM platform according to any one of claims 1 to 7, characterized in that: The reasoning service specifically includes the following: S51, Standard Matching: Inferring products and specification categories through PLM task data and matching usage standards; S52. Compliance Reasoning: Reasoning on products and / or components based on matching applicable standards to determine whether the current product data meets the requirements of the applicable standards. If there is no applicable standard, reasoning is performed based on approximate standards. S53. Update PLM data according to the reasoning result: If the reasoning result shows that the PLM data does not meet the standard requirements, the classification updates the PLM data according to the reasoning result; S54, dynamic feedback and optimization: record synchronization success / failure events and generate statistical reports; dynamically adjust the batch synchronization window size or number of concurrent threads based on historical data; feed back synchronization failure cases to the machine learning model to optimize event conversion logic.

9. The method for integrating a standard knowledge graph into a PLM platform according to claim 8, characterized in that: In step S51 , the semantic similarity of entities is calculated by combining product word vectors with the ontology hierarchy and / or using a rule engine to match applicable criteria; If the current product completely falls within the scope of applicable standards, the matching is completed; if there is no applicable standard for the current product, the standards of similar products are matched to the entire product, or the standards are matched to the components and structure of the product.

10. The method for integrating a standard knowledge graph into a PLM platform according to claim 8, characterized in that: Step S53 specifically includes the following contents: S531. The categories of reasoning results specifically include: The numerical class is the numerical value in the PLM data and the knowledge graph; Process categories include process, flow, and method; The definition class is to modify the definition of the data structure in PLM according to the structure of the knowledge graph; S532: The processing of the inference result specifically includes: Manual intervention: notify the administrator through alarms to handle the problem; Automatic adjudication: Automatically adopt and update PLM data based on preset rules. For numerical data, PLM data is automatically updated according to the reasoning results. For process data, the PLM process is updated. For definition classes, modify the definition of the PLM data structure.

Images