CN118075267B - Digital back-end service platform construction method based on design circuit - Google Patents
Digital back-end service platform construction method based on design circuit Download PDFInfo
- Publication number
- CN118075267B CN118075267B CN202410480383.0A CN202410480383A CN118075267B CN 118075267 B CN118075267 B CN 118075267B CN 202410480383 A CN202410480383 A CN 202410480383A CN 118075267 B CN118075267 B CN 118075267B
- Authority
- CN
- China
- Prior art keywords
- data
- ontology
- equipment
- micro
- service
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000013461 design Methods 0.000 title claims abstract description 127
- 238000010276 construction Methods 0.000 title claims abstract description 28
- 238000013507 mapping Methods 0.000 claims abstract description 83
- 238000004458 analytical method Methods 0.000 claims abstract description 47
- 238000004422 calculation algorithm Methods 0.000 claims abstract description 32
- 238000004891 communication Methods 0.000 claims abstract description 16
- 238000012407 engineering method Methods 0.000 claims abstract description 14
- 238000000034 method Methods 0.000 claims description 59
- 230000006870 function Effects 0.000 claims description 37
- 238000010586 diagram Methods 0.000 claims description 30
- 239000008186 active pharmaceutical agent Substances 0.000 claims description 29
- 238000006243 chemical reaction Methods 0.000 claims description 22
- 230000007246 mechanism Effects 0.000 claims description 20
- 238000012549 training Methods 0.000 claims description 20
- 230000005540 biological transmission Effects 0.000 claims description 19
- 230000008569 process Effects 0.000 claims description 18
- 238000004364 calculation method Methods 0.000 claims description 17
- 238000003860 storage Methods 0.000 claims description 17
- 238000012545 processing Methods 0.000 claims description 14
- 238000013528 artificial neural network Methods 0.000 claims description 13
- 238000012938 design process Methods 0.000 claims description 9
- 239000000463 material Substances 0.000 claims description 9
- 230000003068 static effect Effects 0.000 claims description 9
- 230000008859 change Effects 0.000 claims description 8
- 238000000605 extraction Methods 0.000 claims description 8
- 238000003058 natural language processing Methods 0.000 claims description 8
- 230000004927 fusion Effects 0.000 claims description 7
- 238000004806 packaging method and process Methods 0.000 claims description 6
- 239000008188 pellet Substances 0.000 claims description 6
- GGKJAKNXFOWECF-DDCYWINGSA-N dav protocol Chemical compound CN(C)N\N=C1/N=CN=C1C(N)=O.CC1=NC=C(CNC(=O)N(CCCl)N=O)C(N)=N1.C([C@H](C[C@]1(C(=O)OC)C=2C(=C3C([C@]45[C@H]([C@@]([C@H](OC(C)=O)[C@]6(CC)C=CCN([C@H]56)CC4)(O)C(=O)OC)N3C=O)=CC=2)OC)C[C@@](C2)(O)CC)N2CCC2=C1NC1=CC=CC=C21 GGKJAKNXFOWECF-DDCYWINGSA-N 0.000 claims description 5
- 238000012800 visualization Methods 0.000 claims description 5
- 238000012098 association analyses Methods 0.000 claims description 4
- 238000013136 deep learning model Methods 0.000 claims description 4
- 238000013135 deep learning Methods 0.000 claims description 3
- 230000002441 reversible effect Effects 0.000 claims description 3
- 230000001360 synchronised effect Effects 0.000 claims description 2
- 230000001960 triggered effect Effects 0.000 claims description 2
- 238000007726 management method Methods 0.000 description 22
- 239000013598 vector Substances 0.000 description 19
- 238000005457 optimization Methods 0.000 description 15
- 230000000007 visual effect Effects 0.000 description 10
- 238000005516 engineering process Methods 0.000 description 9
- 238000004519 manufacturing process Methods 0.000 description 9
- 238000013499 data model Methods 0.000 description 8
- 230000010354 integration Effects 0.000 description 8
- 230000018109 developmental process Effects 0.000 description 5
- 238000012423 maintenance Methods 0.000 description 5
- 238000004088 simulation Methods 0.000 description 5
- 230000008602 contraction Effects 0.000 description 4
- 238000011161 development Methods 0.000 description 4
- 239000000284 extract Substances 0.000 description 4
- 230000036541 health Effects 0.000 description 4
- 238000002372 labelling Methods 0.000 description 4
- 238000012544 monitoring process Methods 0.000 description 4
- 238000005070 sampling Methods 0.000 description 4
- 230000002457 bidirectional effect Effects 0.000 description 3
- 238000007405 data analysis Methods 0.000 description 3
- 238000009826 distribution Methods 0.000 description 3
- 230000003993 interaction Effects 0.000 description 3
- 238000005096 rolling process Methods 0.000 description 3
- 230000011218 segmentation Effects 0.000 description 3
- 239000000243 solution Substances 0.000 description 3
- 230000009466 transformation Effects 0.000 description 3
- 230000001133 acceleration Effects 0.000 description 2
- 230000002776 aggregation Effects 0.000 description 2
- 238000004220 aggregation Methods 0.000 description 2
- 238000013459 approach Methods 0.000 description 2
- 238000009411 base construction Methods 0.000 description 2
- 230000006835 compression Effects 0.000 description 2
- 238000007906 compression Methods 0.000 description 2
- 238000013527 convolutional neural network Methods 0.000 description 2
- 230000008878 coupling Effects 0.000 description 2
- 238000010168 coupling process Methods 0.000 description 2
- 238000005859 coupling reaction Methods 0.000 description 2
- 238000013075 data extraction Methods 0.000 description 2
- 230000007547 defect Effects 0.000 description 2
- 238000005286 illumination Methods 0.000 description 2
- 238000002347 injection Methods 0.000 description 2
- 239000007924 injection Substances 0.000 description 2
- 230000002452 interceptive effect Effects 0.000 description 2
- 230000000670 limiting effect Effects 0.000 description 2
- 238000005259 measurement Methods 0.000 description 2
- 239000000203 mixture Substances 0.000 description 2
- 238000003062 neural network model Methods 0.000 description 2
- 238000009877 rendering Methods 0.000 description 2
- 238000013550 semantic technology Methods 0.000 description 2
- 241000380131 Ammophila arenaria Species 0.000 description 1
- 241001463014 Chazara briseis Species 0.000 description 1
- 241000412611 Consul Species 0.000 description 1
- 102100038367 Gremlin-1 Human genes 0.000 description 1
- 101001032872 Homo sapiens Gremlin-1 Proteins 0.000 description 1
- 241000533950 Leucojum Species 0.000 description 1
- 230000003044 adaptive effect Effects 0.000 description 1
- 230000004931 aggregating effect Effects 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 239000003990 capacitor Substances 0.000 description 1
- 238000004140 cleaning Methods 0.000 description 1
- 230000000295 complement effect Effects 0.000 description 1
- 238000010219 correlation analysis Methods 0.000 description 1
- 238000013480 data collection Methods 0.000 description 1
- 238000013523 data management Methods 0.000 description 1
- 238000007418 data mining Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000013501 data transformation Methods 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000000586 desensitisation Methods 0.000 description 1
- 238000003745 diagnosis Methods 0.000 description 1
- 238000005538 encapsulation Methods 0.000 description 1
- 238000011156 evaluation Methods 0.000 description 1
- 238000002474 experimental method Methods 0.000 description 1
- 238000011478 gradient descent method Methods 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 238000013173 literature analysis Methods 0.000 description 1
- 230000015654 memory Effects 0.000 description 1
- 238000005065 mining Methods 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 238000012856 packing Methods 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 238000013439 planning Methods 0.000 description 1
- 238000011176 pooling Methods 0.000 description 1
- 230000003449 preventive effect Effects 0.000 description 1
- 238000005295 random walk Methods 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 230000002829 reductive effect Effects 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 238000007650 screen-printing Methods 0.000 description 1
- 238000012216 screening Methods 0.000 description 1
- 230000006403 short-term memory Effects 0.000 description 1
- 238000000547 structure data Methods 0.000 description 1
- 230000001502 supplementing effect Effects 0.000 description 1
- 230000009897 systematic effect Effects 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F30/00—Computer-aided design [CAD]
- G06F30/30—Circuit design
- G06F30/39—Circuit design at the physical level
- G06F30/398—Design verification or optimisation, e.g. using design rule check [DRC], layout versus schematics [LVS] or finite element methods [FEM]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
- G06F16/36—Creation of semantic tools, e.g. ontology or thesauri
- G06F16/367—Ontology
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F30/00—Computer-aided design [CAD]
- G06F30/30—Circuit design
- G06F30/39—Circuit design at the physical level
- G06F30/392—Floor-planning or layout, e.g. partitioning or placement
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F30/00—Computer-aided design [CAD]
- G06F30/30—Circuit design
- G06F30/39—Circuit design at the physical level
- G06F30/394—Routing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F40/00—Handling natural language data
- G06F40/20—Natural language analysis
- G06F40/279—Recognition of textual entities
- G06F40/289—Phrasal analysis, e.g. finite state techniques or chunking
- G06F40/295—Named entity recognition
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F40/00—Handling natural language data
- G06F40/30—Semantic analysis
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/547—Remote procedure calls [RPC]; Web services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
- G06N3/00—Computing arrangements based on biological models
- G06N3/02—Neural networks
- G06N3/04—Architecture, e.g. interconnection topology
- G06N3/042—Knowledge-based neural networks; Logical representations of neural networks
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
- G06N3/00—Computing arrangements based on biological models
- G06N3/02—Neural networks
- G06N3/04—Architecture, e.g. interconnection topology
- G06N3/045—Combinations of networks
- G06N3/0455—Auto-encoder networks; Encoder-decoder networks
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
- G06N3/00—Computing arrangements based on biological models
- G06N3/02—Neural networks
- G06N3/04—Architecture, e.g. interconnection topology
- G06N3/0464—Convolutional networks [CNN, ConvNet]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
- G06N3/00—Computing arrangements based on biological models
- G06N3/02—Neural networks
- G06N3/08—Learning methods
- G06N3/084—Backpropagation, e.g. using gradient descent
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
- G06N5/00—Computing arrangements using knowledge-based models
- G06N5/02—Knowledge representation; Symbolic representation
- G06N5/022—Knowledge engineering; Knowledge acquisition
- G06N5/025—Extracting rules from data
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
- G06N5/00—Computing arrangements using knowledge-based models
- G06N5/04—Inference or reasoning models
- G06N5/041—Abduction
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
- H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/133—Protocols for remote procedure calls [RPC]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/55—Push-based network services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/566—Grouping or aggregating service requests, e.g. for unified processing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45595—Network integration; Enabling network access in virtual machine instances
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2111/00—Details relating to CAD techniques
- G06F2111/02—CAD in a network environment, e.g. collaborative CAD or distributed simulation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2115/00—Details relating to the type of the circuit
- G06F2115/12—Printed circuit boards [PCB] or multi-chip modules [MCM]
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Computational Linguistics (AREA)
- Evolutionary Computation (AREA)
- Artificial Intelligence (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- Computer Networks & Wireless Communication (AREA)
- Data Mining & Analysis (AREA)
- General Health & Medical Sciences (AREA)
- Signal Processing (AREA)
- Mathematical Physics (AREA)
- Health & Medical Sciences (AREA)
- Life Sciences & Earth Sciences (AREA)
- Biophysics (AREA)
- Biomedical Technology (AREA)
- Molecular Biology (AREA)
- Geometry (AREA)
- Computer Security & Cryptography (AREA)
- Audiology, Speech & Language Pathology (AREA)
- Animal Behavior & Ethology (AREA)
- Databases & Information Systems (AREA)
- Architecture (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The application discloses a digital back-end service platform construction method based on a design circuit, which relates to the field of digital platform construction and comprises the following steps: collecting structured data and unstructured data; based on the ontology and the semantic template, acquiring functional information of the equipment, and constructing a three-dimensional digital twin model based on Web GL standards; constructing a domain knowledge graph based on an ontology engineering method; carrying out semantic analysis on unstructured data and extracting equipment attributes; adopting TransE knowledge representation learning algorithm to obtain semantic mapping relation between the three-dimensional digital twin model and the domain knowledge graph, and generating the equipment knowledge graph; adopting a micro server architecture; decoupling communication between micro services through a REST interface; performing ontology mapping from the equipment knowledge graph to the micro-service domain model through ontology reasoning rules, and generating a micro-service domain model code by utilizing the Jena framework; container orchestration and management was performed using Kubernetes. Aiming at the problem of low construction efficiency of a back-end service platform in the prior art, the application improves the efficiency.
Description
Technical Field
The application relates to the field of digital platform construction, in particular to a digital back-end service platform construction method based on a design circuit.
Background
Along with the rapid development of information technology and the intelligent transformation of manufacturing industry, the intelligent design, manufacture and service concepts represented by digital twin are becoming industry consensus. In each link of the whole life cycle of the product, the digital representation of the product is constructed around a physical entity, and through data driving, model supporting and service enabling, design optimization, manufacturing coordination and operation and maintenance value increase are realized, so that the digital representation becomes a key element of the core competitiveness of a manufacturing enterprise. However, current digital twinning techniques still face a number of challenges. Firstly, mass heterogeneous data is generated in the device circuit design process, unified semantic representation and association mechanisms are lacked, the data value is difficult to fully mine, and full life cycle management is difficult to support. Secondly, the existing research on geometric accuracy of the multi-focus twin model lacks field semantics and has insufficient intelligent interaction and feedback capability with physical entities. In addition, knowledge acquisition and application are often disjoint, and field expert experience is difficult to precipitate and reuse, and difficult to guide production practice.
In the aspect of digital twin platform construction, a traditional software development mode is mainly adopted at present, and the digital twin platform is long in period, high in cost, poor in flexibility and maintainability from demand analysis, architecture design to service development and system integration. Although the micro-service can promote the system elasticity, different teams and departments are respectively administrative, the service lacks unified semantics, and the integration is difficult. And lack of effective knowledge multiplexing and automation mechanisms, platform construction is highly dependent on field experts and technicians, and efficiency bottlenecks are prominent. Meanwhile, the original system and the new service are difficult to integrate, the data among the fractured systems are difficult to open, and the platform is difficult to quickly adapt to the personalized requirements of various fields and links.
In the related art, for example, a method for constructing a distributed digital native service platform is provided in chinese patent document CN114879940a, which includes: acquiring equipment information of third-party equipment; analyzing the equipment information to obtain analyzed equipment information; performing digital abstract processing on the analyzed equipment information to obtain object definition information; constructing a model of the object according to the object definition information; and constructing a distributed digital native service platform according to the object model. In the method, equipment information is analyzed and subjected to digital abstract processing to obtain object definition information and an object model, but a unified semantic representation and mapping mechanism is lacked. The information of different devices may adopt different data formats and terms, and lack of unified semantic standards leads to a great deal of data conversion and mapping work in building a back-end service platform. The platform construction efficiency of this solution is therefore to be further improved.
Disclosure of Invention
Aiming at the problem of low construction efficiency of a back-end service platform in the prior art, the application provides a digital back-end service platform construction method based on a design circuit, which constructs a knowledge graph, containerization arrangement and the like covering the full life cycle data of equipment through ontology and semantic analysis, thereby improving the construction efficiency of the back-end service platform.
Technical solution the object of the present application is achieved by the following technical solution.
The specification provides a digital back-end service platform construction method based on a design circuit, which comprises the following steps: step one, performing equipment circuit design by adopting a circuit design tool, generating a circuit schematic diagram and a PCB layout file, and obtaining structured data and unstructured data of the equipment circuit design, wherein the unstructured data comprises equipment function description and technical parameters; step two, deploying a data acquisition gateway, acquiring the structured data of the equipment circuit design in the step one through a multi-protocol adapter, and transmitting the acquired structured data to a cloud data processing center through a secure channel after encryption processing; decrypting the encrypted structured data in a cloud data processing center, carrying out semantic analysis on the structured data based on an ontology and a semantic template, extracting functional information of equipment, carrying out static storage encryption and dynamic access encryption on the extracted functional information, and then storing the functional information in an equipment knowledge base, and constructing a three-dimensional digital twin model corresponding to an equipment entity based on Web GL standards; step three, defining an ontology model of the equipment circuit field by using OWL ontology language based on an ontology engineering method, converting the equipment circuit design structured data in the step one into an ontology instance triplet in RDF format, establishing semantic mapping between the triplet and an ontology concept based on SPARQL query sentences to form an RDF knowledge base of an equipment knowledge graph, and carrying out semantic reasoning on the RDF knowledge base by using a Jena reasoning engine based on SWRL rules to construct a field knowledge graph of the equipment knowledge graph; performing semantic analysis on the unstructured data in the first step by adopting a BERT language model, and extracting equipment attributes; and TransE, a knowledge representation learning algorithm is adopted, a semantic mapping relation between the three-dimensional digital twin model and the domain knowledge graph in the second step is obtained, and a device knowledge graph is generated based on the mapping relation.
Step four, a digital twin service platform is constructed by adopting a micro service architecture and a containerization technology, the platform is split into a plurality of micro services such as equipment access, data processing, model construction, application service and the like, and the micro services are in decoupling communication through a REST interface; constructing a micro-service domain ontology in each micro-service by adopting an ontology engineering method, realizing ontology mapping from an equipment knowledge graph to a micro-service domain model by using an ontology reasoning rule, and generating a micro-service domain model code by using a Jena framework; packaging the micro-services by adopting a Docker container engine, and carrying out container arrangement and elasticity management by adopting Kubernetes; and injecting the equipment knowledge graph ontology URI into a container environment variable, dynamically loading a physical model ontology when the micro-service runs, and realizing semantic interoperation among the micro-services through ontology matching and JSON-LD serialization.
Among other things, web GL (Web Graphics Library) is Java SCRIPT API that renders interactive 2D and 3D graphics in a Web browser, without the use of plug-ins. It can be used in the HTML5 < canvas > element by introducing an API compliant with opengles 2.0. The Web GL standard is formulated and maintained by Khronos Group; PCB (Printed Circuit Board) is a circuit board for electrical connection between electronic components. PCB layout refers to the process of reasonably arranging and connecting individual electronic components on a circuit board. The PCB layout file contains design information such as physical dimensions, stacked structures, line trends, vias, text screen printing and the like of the circuit board, and common formats are Gerber, ODB++, and the like. Apache Jena is an open source Java framework for building semantic Web and linking data applications. It provides a whole set of tools and libraries supporting RDF（Resource Description Framework）、RDFS（RDF Schema）、OWL（Web Ontology Language）、SPARQL（SPARQL Protocol and RDF Query Language） and other semantic web technical standards. The Jena framework comprises RDFAPI components, an ontology API, an inference engine, a query engine and the like, and is an important tool for developing a knowledge graph and an ontology-driven application. Apache Jena is an open source Java framework for building semantic Web and linking data applications. It provides a whole set of tools and libraries supporting RDF（Resource Description Framework）、RDFS（RDF Schema）、OWL（Web Ontology Language）、SPARQL（SPARQL Protocol and RDF Query Language） and other semantic web technical standards. The Jena framework comprises RDFAPI components, an ontology API, an inference engine, a query engine and the like, and is an important tool for developing a knowledge graph and an ontology-driven application.
In the first step, a circuit design tool is adopted to design a device circuit, and the method comprises the following steps: adopting an EDA circuit design tool, drawing a circuit schematic diagram and laying out and wiring a PCB (printed Circuit Board) based on a predefined circuit design specification and a device library, generating a structured data file reflecting the electric connection topology and physical layout characteristics of equipment, automatically checking whether the generated structured data file meets the predefined design rule and constraint conditions through a design rule checking and design constraint checking engine integrated by the EDA tool, verifying the correctness and manufacturability of a design scheme, and realizing the automatic checking and verification of the design data of the equipment circuit; the method comprises the steps of adopting a Product Data Management (PDM) system to perform unified management and version control on structured data files such as schematic files, PCB layout files, BOM bill of materials, design change records and the like generated in the process of designing an equipment circuit, and converting the structured data files generated by heterogeneous design tools into unified data formats and data models through data extraction and conversion tools built in the PDM system to form a standardized equipment circuit design structured data set; the method comprises the steps of adopting a product life cycle management PLM system to perform unified management and semantic extraction on unstructured data files such as device function description documents, technical parameter manuals, user demand documents and the like, performing semantic analysis and labeling on the unstructured data files through a natural language processing engine integrated by the PLM system, extracting key semantic information such as device functions, parameters, demands and the like, establishing semantic indexes, and realizing semantic association and tracking between an unstructured semantic data set and a device circuit design structured data set.
The second step is to deploy a data acquisition gateway, collect structural data of a device circuit design through a multi-protocol adapter, and transmit the collected structural data to a cloud data processing center, and the second step includes: a multi-protocol adapter is deployed in a data acquisition gateway, and directional acquisition and incremental acquisition are carried out on equipment circuit design structured data files distributed in a heterogeneous design environment by configuring access rights and frequency limits of file transmission protocols such as FTP, HTTP, web DAV and the like and setting data acquisition triggering conditions of industrial communication protocols such as OPCUA, MQTT and the like, so that redundancy and resource expenditure of data acquisition are reduced; after the heterogeneous data file is acquired, the data in different protocol formats are automatically identified and structurally extracted through a protocol analysis module, and the extracted structured data are converted into a unified data format and a unified data model through a data conversion module, so that standardized processing of the heterogeneous data is realized; integrating a data encryption and compression module in a data acquisition gateway, and adopting an asymmetric encryption algorithm to encrypt the acquired structured data of the equipment circuit design so as to ensure the confidentiality of the data; compressing and packaging the encrypted data by adopting a lossless compression algorithm, so as to reduce the bandwidth occupation of data transmission; the encrypted and compressed data packet is safely and efficiently transmitted to a cloud data processing center by deploying a VPN and other security channels between an enterprise intranet and a cloud and adopting SSL/TLS and other security transmission protocols; in a cloud data processing center, based on a predefined circuit design domain ontology represented by OWL, RDF and other standards and a semantic template defined by XML Schema and other standards, automatic semantic analysis and mapping are carried out on device circuit design structured data transmitted to the cloud, and functional information such as device circuit topology, device parameters, pin connection and the like is extracted to form structured functional description with definite semantic association; in a cloud data processing center, the device function information extracted by semantic analysis is stored in a device knowledge base in a relational database table form, data desensitization is realized through access control mechanisms such as role authority management of a database, data static encryption is realized through mechanisms such as transparent data encryption of the database, data dynamic encryption is realized through mechanisms such as password authentication and session encryption of an application program end, and the storage and access security of sensitive data in the device knowledge base are ensured multiple times; based on the structural function information stored in the equipment knowledge base, a three-dimensional digital twin model corresponding to the physical entity circuit equipment one by one is constructed by adopting a visual modeling engine based on three-dimensional graphic standards such as Web GL; the visual interface provided by the digital twin model is used for displaying the geometric parameters and the operation parameters of each component of the physical entity in real time, supporting the interactive online operation of the three-dimensional model and realizing the visual monitoring, analysis and control of the physical entity.
Further, the method also comprises a step five of carrying out semantic guidance convergence and fusion on the device circuit design structured data acquired in the step two by utilizing semantic information describing the device knowledge graph in the step three to construct a data warehouse covering the full life cycle data of the device; adopting TensorFlow deep learning frames in a data warehouse, carrying out feature extraction and representation learning on equipment physical quantity data and state data by utilizing a predefined deep learning model, constructing an equipment running state prediction model, and carrying out prediction analysis on the equipment physical quantity data and the state data; according to the equipment knowledge graph constructed in the third step, embedding the topological structure and semantic association of the equipment knowledge graph into an input layer of a graph neural network by adopting a graph neural network algorithm, obtaining graph characteristic representation in the equipment circuit design structural data through hidden layer calculation of the graph neural network, and carrying out graph calculation and association analysis on the equipment circuit design structural data according to the graph characteristic representation; and (3) feeding back the predicted analysis result of the equipment physical quantity data and the state data, the graph calculation and the correlation analysis result to the equipment circuit design step of the step one, and adjusting and optimizing the circuit schematic diagram and the PCB layout file.
When the semantic convergence of the full life cycle data of the equipment is carried out, the concept system, the attribute and the relation defined by the equipment knowledge graph ontology are utilized to carry out semantic extraction and ontology mapping on multi-source heterogeneous data from links such as product design, production and manufacture, after-sales service and the like, the multi-source heterogeneous data are converted into a unified RDF format, and the unified RDF format is stored in a graph database to form an instantiation representation of the equipment knowledge graph as a semantic layer of a data warehouse. When deep learning prediction is carried out on physical quantity data and state data, structured data such as equipment operation condition parameters, performance parameters, fault information and the like are input into a TensorFlow tensor calculation chart, data characteristics are extracted through a convolutional neural network, time sequence data are modeled through the convolutional neural network, and an end-to-end data characteristic learning and prediction analysis pipeline is formed. The prediction analysis result can be used for application scenes such as equipment health management, predictive maintenance and the like. When the graph calculation and the association analysis are carried out on the equipment circuit design data, the entity and the relation of the equipment knowledge graph are embedded into a low-dimensional vector space through a graph neural network, and graph characteristic representation of the equipment topological structure and the association semantics is obtained through the graph rolling and pooling operation of the graph neural network. On the basis, device parameters, connection topology, constraint rules and the like in the circuit schematic diagram are subjected to reasoning calculation by combining association rules defined by expert knowledge, circuit design defects are identified, and device selection and layout and wiring are optimized. And the digital twin analysis optimization result is fed back to the equipment design link to form closed loop optimization of design, manufacture, operation and maintenance and service, and the performance, quality and reliability of the equipment are continuously and iteratively improved. And simultaneously, the optimized design scheme is solidified into the equipment knowledge graph, so that reference and multiplexing are provided for the design of the follow-up similar equipment.
Further, the fifth step further includes: when the graph neural network is embedded, all entities and relations of the equipment knowledge graph are formed into a heterogeneous network, wherein the entities comprise equipment, devices, materials, processes and the like, and the relations comprise connection, composition, constraint and the like; the graph neural network generates the context embedding of the entity and the relation through a random walk sampling strategy, transmits and aggregates node neighborhood information to a target node through multi-layer graph convolution, and performs joint embedding representation learning on different types of entities and relations; during design defect identification and optimization, constructing a task-oriented special knowledge graph based on engineering knowledge such as device selection specifications, layout wiring rules, version change records and the like; learning importance weights of circuit design elements by using a graph neural network model based on an attention mechanism, and carrying out weighted representation on rules in a special knowledge graph; and comparing the design scheme with the rules through a map homomorphic matching algorithm, and identifying, positioning and correcting design elements violating the rules.
Further, the collecting the structured data in the second step includes: a Web DAV file transmission protocol adapter and an MQTT communication protocol adapter are deployed in a data acquisition network, and a structured data file which is generated in the circuit design process of the Web DAV protocol acquisition equipment and contains a schematic diagram file and a PCB layout file is utilized; the method comprises the steps of collecting structured data information which is generated in the circuit design process of equipment and contains BOM bill of materials and design change records through an MQTT communication protocol; converting the collected structured data file and structured data message into structured data in JSON format by adopting a data conversion engine based on a data description language; encrypting the converted structured data in the JSON format by adopting an asymmetric encryption algorithm to obtain encrypted structured data; and transmitting the encrypted structured data to a cloud data processing center through a TLS transmission protocol. The Web DAV protocol operates a file system through an HTTP method such as GET, PUT, etc., and defines file attributes through an XML format. The MQTT protocol organizes messages through a topic tree based on a publish/subscribe model, supporting QoS to ensure reliable transmission of messages. The data conversion engine extracts each field to form a structured JSON object through grammar and semantic analysis of files such as a schematic diagram, a BOM and the like, and unifies the original data format. The asymmetric encryption uses RSA algorithm, and the transmission security is ensured by public key encryption and private key decryption. TLS provides a point-to-point encryption channel at the transport layer to prevent data leakage. At the cloud, the structured data is decrypted and restored, then the structured data is associated with knowledge in the field of circuit design through semantic technology, a three-dimensional visual model is built, and a data base is provided for the digital twin platform. The process runs through links of data acquisition, conversion, encryption, transmission, analysis, modeling and the like, and realizes an end-to-end data flow.
Further, constructing the three-dimensional digital twin model in the second step includes: decrypting the received data by adopting an asymmetric encryption algorithm in a cloud data processing center to obtain plaintext structured data in a JSON format; based on a predefined circuit design domain ontology expressed in OWL ontology language and a semantic analysis template defined based on XML Schema, carrying out semantic analysis and semantic mapping on the plaintext structured data, and extracting device circuit topology structure diagram data and device parameter data as device function information; storing the extracted equipment function information into a relational database, adopting a transparent data encryption mechanism of the database to carry out static storage encryption on the equipment function information, and adopting a session encryption mechanism of an application server to carry out dynamic transmission encryption on the access process of the equipment function information; and acquiring equipment circuit topology structure diagram data and equipment parameter data from a relational database, and constructing a three-dimensional digital twin model corresponding to the physical entity circuit equipment by adopting a three-dimensional visualization engine based on Web GL graphic standards. The circuit design ontology defines classes, attributes, relations and the like through OWL to form a concept system and an inference rule in the circuit field. The semantic analysis template defines the mapping relation between the JSON field and the ontology concept through XSD to guide the semantic ETL process. The relational database adopts symmetric encryption algorithms such as AES and the like to encrypt at the data page level, so as to protect static data. The application server encrypts the dynamically transmitted data in the HTTPS session with the client to prevent man-in-the-middle attacks. The three-dimensional visualization engine renders 3D scenes in browser-side hardware acceleration using Web GL through Java SCRIPT APIS, such as three. By analyzing the topological structure and parameters, a corresponding geometric model, texture, illumination shadow and the like are generated, and vivid digital twinning is constructed. The digital twin model can interactively display the internal structure and the running state of the equipment on one hand, and can accept the simulation parameters to drive the behavior of the simulation equipment on the other hand, and is a tie for connecting physical and digital spaces. The data is properly handled in the links of acquisition, transmission, storage, access, analysis and visualization, external data is converted into internal assets, and digital twin application is enabled. Through the interoperability of the semanteme promotion data, the confidentiality of the data is ensured through encryption, and the interpretability of the data is visually promoted, so that the full life cycle data stream of the high-quality, high-safety and high-performance device is constructed.
Further, the constructing the domain knowledge graph in the third step includes: based on an ontology engineering method, defining concepts and relations of the equipment circuit field by adopting an OWL ontology language to form a field ontology model; analyzing the structured data file of the device circuit design in the first step into a form of attribute field and value pairs, and converting the attribute field and value pairs into ontology instance triples expressed in a subject-predicate-object form by adopting RDF (remote data function) statements; in the process of generating the ontology instance triples, through a predefined SPARQL query statement, based on names and data types of all attribute fields in a structured data file of the equipment circuit design, matching corresponding concepts and attributes in an domain ontology model, and establishing semantic mapping rules between the attribute fields and the ontology concepts; according to semantic mapping rules, mapping subjects in the ontology instance triples into instances of ontology concepts, mapping objects into values of object attributes, and mapping predicates into relations between the ontology concepts to form an RDF knowledge base taking a domain ontology as a Schema; importing the RDF knowledge base into an RDF database constructed based on an Apache Jena framework, and performing semantic reasoning based on SWRL rules predefined in a domain ontology model by adopting a Jena reasoning engine; the Jena reasoning engine adopts a Pellet-based reasoning algorithm, matches the ontology instance triples with the conditional parts in the SWRL rules through forward rule matching, and uses new triples generated by forward matching as the input of the subsequent rules through reverse rule linking to obtain associated triples; constructing a device domain knowledge graph containing each component part and association relation of a device circuit physical model according to the original ontology instance triples, the novel association triples obtained by reasoning and the device circuit domain ontology model; the ontology model provides a conceptual framework of the knowledge graph, the ontology instance triples provide basic data of the knowledge graph, and the associated new triples provide expanded content of the knowledge graph.
The ontology engineering method formally represents domain knowledge by defining concept layers (such as equipment, components and materials), data attributes (such as parameters and specifications) and object attributes (such as connection and composition). The structured data is converted into RDF format through ETL, the field names are mapped into concepts, the field values are mapped into instances, and the foreign key relationship is mapped into attributes. And establishing semantic mapping from data to ontology based on the character string similarity matching concept through SPARQL. The RDF database supports the storage and retrieval of large-scale triples, and the Jena framework provides an OWL semantic parsing and reasoning interface. SWRL defines the reasoning rule through the horn clause, and Pellet carries out reasoning based on the first-order logic through tableau algorithm. The multi-level knowledge graph is composed of bottom instance data, middle concept definition and top rule constraint, the scattered data are integrated into a semantically rich knowledge base, and support is provided for intelligent application of the digital twin platform.
Further, in the third step, an equipment knowledge graph is constructed, which further includes: performing natural language processing on the unstructured data files acquired in the first step by adopting a BERT-based pre-training language model, and identifying named entities; when the named entity recognition is carried out, adding the equipment attribute information in the professional dictionary in the equipment circuit field into an embedded layer of the BERT model, and marking the equipment attribute information to the corresponding word position in the unstructured data file in a template matching mode; respectively carrying out RDF format conversion on the three-dimensional digital twin model constructed in the second step and the equipment field knowledge graph constructed in the third step to obtain an entity-relation triplet list which is used as training data of TransE knowledge representation learning algorithm; initializing TransE model parameters, and training a TransE model by using training data; minimizing the difference between the embedding distance of the positive sample triplet and the embedding distance of the negative sample triplet until the model converges to obtain the three-dimensional digital twin model and the embedding representation of the entity and the relation of the knowledge graph in the equipment field; respectively calculating Euclidean distance between the obtained entity embedding representation and the relation embedding representation, obtaining entity pairs and relation pairs with the Euclidean distance smaller than a threshold value, and establishing a semantic mapping relation between a three-dimensional digital twin model and a knowledge graph in the equipment field; according to the obtained semantic mapping relation, adding the RDF triples of the entity and the relation in the three-dimensional digital twin model and the embedded representation of the entity and the relation obtained by the TransE model into the domain knowledge graph to obtain the equipment knowledge graph.
The BERT model learns the contextual representation of the word through a bidirectional transducer encoder and optimizes the task of named entity recognition through a fine-tuning mode. The addition of the domain dictionary is helpful to improve the recognition accuracy of the professional entity. The TransE model learns the low-dimensional vector representation of entities and relationships by translating invariance assumptions (h+r≡t), so that entities with similar semantics are closer in the embedding space. Negative sampling generates negative samples by replacing the head or tail entities of the triples based on MARGIN RANKING loss optimization. Through the approach degree of Euclidean distance measurement three-dimensional model entity and knowledge graph concept in the embedded space, the entity pairs smaller than the threshold form equivalent mapping, and the corresponding relation can be analogically migrated. And integrating the three-dimensional model into the knowledge graph in an RDF form, and adding entity link information to form a more comprehensive and fine-grained equipment knowledge representation. The digital twin entity establishes connection with the physical semantic entity, and the atlas can express the corresponding relation and the constraint rule.
Wherein RDF (Resource Description Framework) knowledge base is a semantic database that represents and stores knowledge in RDF triples. RDF triples are composed of subjects (objects), predicates (PREDICATE), and objects (objects), and represent resources, relationships between resources, and values of relationships, respectively. The RDF knowledge base is constructed based on an ontology model in a specific field, the ontology defines semantic elements such as concepts, attributes and relations, and a structured semantic pattern (Schema) is provided for the RDF triples. RDF knowledge base supports semantic queries (preferably SPARQL) and reasoning, implicit knowledge and associations can be found. An RDF database is a database management system dedicated to storing and managing RDF data. Compared with the traditional relational database, the RDF database adopts a graphical data model to store entities and relations thereof in the form of RDF triples. Common RDF databases are Apache Jena TDB, open Link Virtuoso, allegro Graph, etc. The RDF database provides an efficient triplet storage, indexing and query mechanism supporting SPARQL query language and ontology inference rules. RDF databases are an important infrastructure for building semantic web applications and knowledge maps. RDF knowledge bases focus on ontology-centric knowledge representation and reasoning, while RDF databases focus on RDF data storage and querying. The two are mutually complementary, and jointly support the construction and application of the semantic net and the knowledge graph. In practice, the RDF knowledge base can be imported into the RDF database for persistent management, and the query and reasoning capabilities of the RDF database are utilized to construct an efficient and intelligent semantic application system.
Wherein SPARQL (SPARQL Protocol and RDF Query Language) is a semantic query language for querying RDF data, similar to SQL in a relational database. The SPARQL Query statement retrieves the triplet data satisfying the condition from the RDF knowledge base by specifying a Query Pattern (Query Pattern) and a condition constraint. Through SPARQL query sentences, required data can be flexibly retrieved from the RDF knowledge base, and query and reasoning at the semantic level are supported. In the scheme, the SPARQL query statement is used for matching attribute fields in the structured data file with concepts and attributes in the domain ontology to establish semantic mapping rules. Wherein SWRL (Semantic Web Rule Language) is a language for describing OWL ontology inference rules, combining OWLDL (Description Logic) and features of rule markup language (e.g., rule ml). SWRL rules are expressed in the form of IF-THEN for describing inference rules and constraints in the ontology. Reasoning and knowledge discovery can be performed on the ontology knowledge base through SWRL rules, and knowledge which is not explicitly defined in the domain ontology model is supplemented. In the scheme, SWRL rules are used for carrying out semantic reasoning on the RDF knowledge base, and new association triples are generated through forward rule matching and reverse rule linking to expand the content of the knowledge base. The SPARQL query statement provides a flexible RDF data query mechanism for establishing semantic mapping between structured data and domain ontology; the "SWRL rules" provide a ontology-based reasoning rule definition mechanism for semantic reasoning and knowledge discovery on the RDF knowledge base. The knowledge base construction, query and reasoning are realized by combining the knowledge base construction, query and reasoning, and intelligent data analysis and decision application are supported.
Among them, ontology (ontologiy) is a formalized, explicit domain knowledge representation method for describing concepts, attributes and relationships within the domain. Here, the circuit design domain ontology is constructed using OWL (Web Ontology Language) language for representing core concepts, attributes and relationships of the circuit design domain. OWL is an ontology description language based on RDF (Resource Description Framework) and RDFS (RDF Schema), and has rich semantic expression capability and reasoning support. The circuit design domain ontology typically includes the following elements: class (Class): representing core concepts in the field of circuit design such as components, connections, parameters, etc. Attribute (Property): the attributes representing classes are divided into Object attributes (Object properties) and Data attributes (Data properties). Object properties represent relationships between classes, such as connection relationships between elements; the data attributes represent data characteristics of the class, such as parameter values of the elements. Individual (Individual): examples of classes are represented, such as specific element examples, connection examples, and the like. Axiom (Axiom): representing classes, attributes, constraints and rules between individuals, such as topological relationships between elements, parameter value ranges, etc.
Wherein XML Schema is a Schema language for defining XML document structures and data types. The semantic parsing template is defined based on XML Schema and is used for guiding semantic parsing and mapping of the structural circuit design data in the JSON format. The semantic parsing template includes the following: data structure definition: XML Schema is used to define the structure, hierarchy, and data types of JSON data, such as objects, arrays, strings, numbers, and the like. Semantic annotation: on the basis of data structure definition, a labeling mechanism (such as xsd) of XML Schema is used for labeling semantic information of JSON data, such as element types, connection relations, parameter meanings and the like. Mapping rules: mapping rules between the JSON data and the ontology in the circuit design field are defined, and corresponding relations between objects and attributes in the JSON data and classes and attributes in the ontology are specified. The semantic analysis template provides a declarative mode, and the structural data in the JSON format is associated with the circuit design field body, so that the semantic analysis and semantic promotion of the data are realized. Through a predefined semantic parsing template, JSON data can be automatically converted into an RDF knowledge base taking an ontology as a schema, and subsequent semantic query, reasoning and application are supported. "Circuit design Domain ontology expressed in OWL ontology semantics" provides a semantic knowledge representation of the circuit design domain, while "semantic parsing templates defined based on XML Schema" provides a bridge that maps structured design data to domain ontologies. The two are combined, so that semantic representation and integration of circuit design data are realized, and a knowledge base is provided for the construction of a digital twin model.
Further, in the third step, an equipment knowledge graph is constructed, which further includes: performing natural language processing on unstructured data files such as a device use manual, a maintenance manual and the like acquired through a Web DAV protocol in the first step by adopting a BERT-based pre-training language model; the BERT model performs word segmentation on unstructured text through character-level word segmentation and WordPiece word segmentation methods, and part-of-speech tagging and named entity recognition are completed through a multi-task learning mechanism; when the named entity recognition is carried out, adding key attribute information such as equipment names, models, parameters and the like in a professional dictionary in the equipment circuit field into an embedded layer of a BERT model, marking the attribute information to corresponding word positions in unstructured texts in a template matching mode, realizing fusion of field knowledge and language models, improving the extraction accuracy of the professional attribute information of the equipment, and outputting structured equipment attribute feature data; the connection relation between entity information such as equipment component names, position coordinates and the like and components in the equipment three-dimensional digital twin model constructed by adopting the three-dimensional js engine in the second step is expressed as a triplet in a subject-predicate-object form by adopting an RDF data model; performing triplet format alignment on the ontology instance triples and the associated new triples contained in the equipment knowledge graph field knowledge graph constructed based on the ontology engineering method in the third step; combining the digital twin model triplets and the domain knowledge map triplets into a unified entity-relation triplet list, and using the unified entity-relation triplet list as TransE knowledge representation learning algorithm training data.
Training the TransE model by randomly initializing TransE model parameters, setting super parameters such as embedded dimension, distance function, negative sampling strategy, learning rate and the like, and utilizing entity-relation triplet list data; the TransE model maps entities and relations in the digital twin model and the domain knowledge graph to the same low-dimensional vector space, so that the semantic similarity between the entities in the space can be measured by the distance between vectors; performing model training iteration, and minimizing the difference between the embedding distance of the positive sample triplet and the embedding distance of the negative sample triplet until convergence to obtain a digital twin model entity, a relationship and a domain knowledge graph entity and a low-dimensional embedding representation of the relationship; the Euclidean distance between the digital twin model obtained by learning the TransE model and the entity embedded representation of the domain knowledge graph and the Euclidean distance between the relation embedded representations are calculated, a distance threshold value is set, a digital twin entity-domain knowledge entity pair and a digital twin relation-domain knowledge relation pair with the distance smaller than the threshold value are obtained, and a semantic mapping relation between two knowledge sources is established; according to the semantic mapping relation between the digital twin model and the domain knowledge graph, adding the RDF triples of the entity and the relation in the digital twin model into the domain knowledge graph of the equipment knowledge graph formed by the ontology instance triples and the reasoning new triples, so as to realize semantic fusion of the three-dimensional model data and the ontology knowledge; adding semantic mapping established by TransE model as equivalent relation between digital twin entity and domain knowledge entity into the fused knowledge graph; matching the device names in the attribute features according to the device attribute features output by the BERT model, establishing a corresponding relation between the concept nodes and the attribute features, and supplementing the attribute features as attribute data of the concept nodes; finally, a multi-dimensional device knowledge graph comprising a device knowledge graph entity, a three-dimensional digital twin entity, a physical-digital mapping relation and device attributes is formed.
Wherein minimizing the difference between the embedding distance of the positive sample triplet and the embedding distance of the negative sample triplet until the model converges, comprises: setting the embedding dimension of TransE model as k, randomly initializing a k-dimensional real vector for each entity and relation in training data as the embedding representation; for each positive sample triplet (h, r, t) in the training data, calculating an L1 norm distance between a head entity embedded vector h, a relation embedded vector r and a tail entity embedded vector t in the triplet as a positive sample embedded distance based on a basic assumption h+r approximately equal to t of a TransE model; adopting a damage-based negative sampling method, replacing a head entity or a tail entity in the positive sample triplet (h, r, t) with other entities randomly sampled in training data, constructing a negative sample triplet (h ', r, t) or (h, r, t'), and calculating the embedding distance as a negative sample embedding distance; constructing a TransE model loss function by taking the difference between the maximized positive sample embedding distance and the maximized negative sample embedding distance as an optimization target, optimizing and solving the loss function by adopting a random gradient descent method, and updating the values of each entity and the relation embedding vector by a back propagation algorithm; after training of all triples is completed once, judging whether the value of the loss function is smaller than a set convergence threshold value, if not, entering the next round of iterative optimization, if so, stopping training, and outputting the current entity and relation embedding representation.
Further, in the fourth step, a digital back-end service platform is constructed, including: dividing the digital back-end service platform into micro services according to functions, wherein each micro service is used as an independent service function; defining concepts, data attributes, object attributes and attribute constraints of data and services processed by the micro-service by adopting an ontology engineering method based on OWL2 ontology language in the micro-service to form a domain ontology model of the micro-service; mapping the ontology of the equipment knowledge graph constructed in the third step into a domain ontology model of the micro-service through SWRL ontology reasoning rules; the method comprises the steps that a front part of an SWRL rule is a class and attribute in an equipment knowledge graph body, a rear part of the SWRL rule is a class and attribute in a domain ontology model of micro-service, and class instance or attribute mapping in the rear part is triggered when a rule front part condition is met; when the ontology instance mapping is carried out, comparing the semantic similarity of the equipment knowledge graph ontology with the semantic similarity of the domain ontology model of the micro-service by using a semantic similarity calculation method based on description logic, establishing an equivalent relationship between a concept pair with the semantic similarity larger than a threshold value, and converting the instance of the concept in the equipment knowledge graph ontology into the instance of the corresponding concept in the domain ontology model of the micro-service; for the mapped microservice ontology model, converting TBox knowledge in the ontology into Java classes through a Jena framework, converting ABox knowledge into object instances, and generating a microservice domain model code; when the micro-service runs, the ontology and the micro-service data are synchronized through the ontology operation API of Jena; and taking the domain ontology as unified semantic representation of micro-service data exchange, determining semantic mapping relations of different micro-service data through ontology matching, and carrying out data serialization processing of the ontology through a JSON-LD format to enable data returned by a micro-service interface to have semantic annotation.
The micro-service architecture improves the agility and expansibility of the system through functional decoupling and service autonomy. Each micro-service encapsulates a specific service boundary, providing a standard interface to the outside. The micro-service domain ontology formally defines the core concepts related to the service, and describes type layers, constraint conditions and association relations by using subclasses, attributes, individual axioms and the like of OWL 2. SWRL rules express domain knowledge through first-order predicate logic for ontology reasoning. The device model body and the micro-service body establish mapping through SWRL rules, and the device instance of the physical space is automatically related to the digital entity of the service space. Semantic similarity distinguishes the relation of semantic equivalence, generalization, association and the like by measuring the semantic distance of concepts in an ontology. Through the bidirectional conversion of the ontology, the codes and the data, the micro-service can sense and adapt to the change of the domain knowledge. The ontology is used as a domain language and is the basis for communication among different teams and systems. The JSON-LD is used as a semantic interoperation format, so that the self-descriptive property of the interface is enhanced. The ontology penetrates through links such as modeling, mapping, generating, calling and the like of the micro-service, so that the data carries richer semantics. When domain knowledge is updated, ontology reasoning can automatically trigger data synchronization and service collaboration. The micro-service uses the knowledge graph as a data base, and enables data sharing and business collaboration through semantic technology.
Wherein OWL2 (WebOntologyLanguage 2) is a semantic web language used to build the ontology, the latest version of OWL. OWL2 is expanded and improved on the basis of OWL, and richer semantic expression capability and reasoning support are provided. TBox (Terminological Box) is the term knowledge in the ontology knowledge base describing concepts, attributes and relationships between them in the field. TBox knowledge defines patterns or metamodels of ontologies, providing conceptual abstractions and structured representations of the domain. ABox (Assertional Box) is assertion knowledge in the ontology knowledge base describing specific instances in the field and their attributes and relationships. The ABox knowledge represents the actual data and facts of the domain based on concepts and attributes defined by the TBox knowledge. JSON-LD (JSON for LINKING DATA) is a JSON (Java Script Object Notation) based lightweight link data format. The JSON-LD combines JSON data with link data (LINKED DATA) to provide a method of embedding semantic annotations and links in JSON data. Specifically, the OWL2 ontology language provides the language foundation for building the domain ontology; "TBox knowledge" and "ABox knowledge" represent conceptual knowledge and example knowledge of an ontology, respectively; the "JSON-LD format" provides a semantic representation method that combines JSON data with ontologies. Through the technologies, the construction, ontology mapping, data exchange and semantic annotation of the micro-service domain model can be realized, and the micro-service integration and collaboration based on the ontology are supported.
Further, in the fourth step, a digital back-end service platform is constructed, and the method further includes: for each micro-service divided in the step four, an API gateway is adopted as a unified entry of the micro-service, RESTful APIs based on the HTTP protocol are adopted among interfaces, and the interfaces of a plurality of micro-services are integrated and arranged through API arrangement; the method comprises the steps that a Docker container engine is adopted to conduct containerization packaging on micro services, codes of micro service operation are defined through Docker file, and a Docker mirror image is built based on the Docker file; with Kubernetes container orchestration, a Docker image is deployed in a pod of Kubernetes, and resource requirements and constraints of the pod are defined by the deployment file. The API gateway provides a unified service access entrance to the outside, shields the complexity of internal services, and can realize the functions of routing, authentication, current limiting, monitoring and the like. The RESTful API designs standard interfaces based on HTTP verbs and resource paths, and the API orchestrates the combination of support interfaces and flow control. The Docker realizes one-time encapsulation and runs everywhere by packing application codes and dependencies thereof. The Docker file declares the build steps of the image, such as copying code, installing dependencies, exposing interfaces, etc. Mirror image construction and distribution are completed through build and push commands. Kubernetes provides container orchestration and cluster management capabilities on a Docker basis. The deployment file declares the desired state of the service in yaml format, such as copy number, port mapping, health check, etc. The pod, as a basic unit of scheduling and scaling, encapsulates a set of closely cooperating containers. The process realizes automatic deployment and dynamic expansion and contraction of the micro-service through the container technology, and improves portability, maintainability and high availability of the service.
When performing ontology instance mapping between an equipment knowledge graph ontology and a micro-service domain ontology model, establishing an equivalence relation between concept pairs with semantic similarity larger than a threshold value by using a semantic similarity calculation method based on description logic, and converting an instance of a concept in the domain knowledge graph ontology into an instance of a corresponding concept in the micro-service domain ontology model, wherein the method comprises the following steps: for each pair of concepts in the device knowledge graph ontology and the microservice domain ontology model, calculating semantic similarity between the device knowledge graph ontology and the microservice domain ontology model by using a semantic similarity calculation method based on description logic. Semantic similarity computation considers the grammatical structure and semantic relationships of concepts, including hierarchical structures, attributes, constraints, etc. of the concepts. The common semantic similarity calculation method comprises the following steps: feature-based methods (e.g., tversky models), information content-based methods (e.g., lin models), hybrid strategy-based methods (e.g., li models), and the like. The range of values for semantic similarity is typically between [0,1], with larger values representing higher semantic similarity between concepts. And setting a threshold value of semantic similarity, and judging whether the two concepts are semantically similar to the degree that an equivalent relationship can be established. The selection of the threshold value needs to comprehensively consider factors such as domain knowledge, granularity of ontology, mapping accuracy and the like, and a proper threshold value can be determined through experiments and expert evaluation. Common threshold setting methods are: fixed thresholding (e.g., set to 0.8), adaptive thresholding (e.g., dynamically adjusted based on similarity distribution), confidence-based thresholding (e.g., confidence information of the combined concepts), etc. And establishing an equivalence relation between the device knowledge graph ontology and the microservice domain ontology model for the concept pairs with the semantic similarity being greater than or equal to a threshold value (Equivalence Relationship). The equivalence relation may be through OWL in OWL2 ontology language: the equivalence Class attribute indicates that the two concepts are semantically equivalent. The concept pairs that establish equivalence relations may form an equivalence concept set that may be replaced and referenced with each other in subsequent ontology mapping and data transformations. And converting the concept examples in the equipment knowledge graph ontology into corresponding concept examples in the microservice domain ontology model according to the established equivalence relation. The instance transformation process needs to consider the mapping of attributes and the transformation of values, ensuring that the transformed instance has the correct type and attribute values in the micro-service domain ontology model. Instance conversion can be implemented through an API provided by an ontology operation framework such as Jena, etc., for example, a new instance is created by using a create Individual method of Ont Class, an add Property method of Individual is used for adding an attribute value, etc. After instance conversion, consistency check is needed to be carried out on the conversion result, so that the converted ontology instance can meet constraint conditions and logic consistency in the ontology model in the micro-service field. consistency checks can use an ontology inference engine or a consistency check tool, such as Pellet, hermiT, etc., to infer and check the ABox knowledge based on the TBox knowledge of the ontology and SWRL rules. If consistency problems are found, ontology debugging and repairing are needed, and the consistency of the converted instance and the ontology model in the micro-service field is ensured.
Further, in the fourth step, a digital back-end service platform is constructed, and the method further includes: when a Docker mirror image of the micro service is constructed, injecting the URI of the micro service field body constructed in the fourth step into the Docker mirror image in the form of an environment variable through an ENV instruction of a Docker file; when the micro service container is started, the URI of the micro service domain body is obtained by reading the environment variable, and the Apache Jena framework is used for loading the micro service domain body. The ENV instruction of the Docker file is used for setting environment variables of the container, and the environment variables can be read by an application when the container runs. And injecting the ontology URI into the mirror image to decouple the micro service from the ontology in the specific field, so that the reusability of the mirror image is improved. When the micro service is started, the ontology is dynamically loaded through the environment variable, so that hard coding of the ontology is avoided, and the service is more easily adapted to the evolution of the ontology. Jena is used as a semantic Web framework to provide APIs (application program interfaces) such as loading, inquiring, reasoning and the like of an ontology, and is widely used for knowledge graph application. Through body injection and dynamic loading, service images can be independent of specific knowledge fields and connected with different external bodies according to environment information. When domain knowledge changes, only the mirror image needs to be reconstructed and the ontology URI needs to be updated, and the service code does not need to be modified. Introducing a device data stream into a digital back-end service platform through a container arrangement engine when a micro service runs, firstly, completing protocol analysis and data extraction by accessing the device into the micro service, calling a data processing micro service to perform data cleaning, conversion and storage, and completing semantic annotation of the device data based on a domain ontology; then, a micro-service is built by a data processing micro-service calling model, semantic data is input into the knowledge graph built in the third step, and data semantic fusion is realized through ontology reasoning, graph embedding and other technologies; and finally, inquiring and calling equipment data from the knowledge graph by using the application service micro-service, developing various application service functions, and realizing deep mining of the full life cycle data value of the equipment.
Wherein URI (Uniform Resource Identifier) is an abbreviation of uniform resource identifier for identifying and locating resources on the internet. URIs provide a common way to identify and access various types of resources, such as web pages, files, services, mailboxes, etc. In the semantic web and ontology domains, URIs are used as an important mechanism for identifying resources for uniquely identifying concepts, attributes, instances, etc. in an ontology. Through the URI, global reference and link can be carried out on the ontology elements, and sharing and interoperation among the ontologies are realized. In the micro-service architecture, the URI of the micro-service domain ontology is used as an environment variable to be injected into the Docker mirror image, so that the following purposes can be achieved: identifying domain ontology of microservices: the semantic basis and the data model of the micro-service are defined by the domain ontology used by the URI identification micro-service. Decoupling ontologies and microservices: the URI of the ontology is used as an environment variable, so that the position and access mode of the ontology can be decoupled from the codes of the micro-service, and the flexibility and maintainability of the micro-service are improved. Dynamically loading a body: when the micro-service container is started, the URI of the ontology is obtained by reading the environment variable, and the ontology is dynamically loaded by using frames such as Apache Jena, and the like, so that the dynamic binding of the ontology and the micro-service is realized. Version management of support ontology: by modifying the ontology URI in the environment variable, the ontology version used by the micro-service can be conveniently switched, and evolution and upgrading of the ontology are supported.
Compared with the prior art, the application has the advantages that: the multi-protocol adapter is adopted to collect the structured and unstructured data generated in the equipment circuit design process, semantic analysis and three-dimensional visual modeling are carried out, automatic association and semantic enrichment of the design data and a three-dimensional model are realized, the integrity and consistency of the data are ensured, and the subsequent semantic processing and analysis application are facilitated.
Introducing an ontology model oriented to the circuit design field, automatically associating design data to the field concept by utilizing the technologies of ontology semantic mapping, reasoning and the like, and constructing a semantically rich field knowledge graph. And then, utilizing a knowledge representation learning algorithm to mine semantic association between the knowledge graph and the three-dimensional model. The method breaks through the limitation of lack of semantics of the existing twin model, and realizes fusion representation and semantic collaboration of domain knowledge, physical models and entity data.
The digital twin service is designed by adopting a micro-service architecture, and the automatic mapping and code generation of domain knowledge to a micro-service data model are realized through ontology reasoning, so that the design and development of the micro-service are greatly simplified; meanwhile, a container technology is introduced to realize automatic deployment, dynamic capacity expansion and reduction and fault self-healing of the micro-service, so that the robustness of the system is improved. Micro-service semantic interoperability avoids inter-service coupling and facilitates third party service integration.
The knowledge graph is applied to the full life cycle management of design data, multi-source data convergence is realized through semantic guidance, and a traceable and credible data base is constructed. On the basis of data convergence, a knowledge-graph-aided graph neural network and a deep learning model are adopted to conduct predictive analysis on the running state of equipment, and feedback is used for guiding design optimization, so that a full closed loop of design-simulation-running-maintenance-optimization is formed.
Drawings
FIG. 1 is an exemplary flow chart of a digital back-end service platform construction method based on design circuitry according to some embodiments of the present description;
FIG. 2 is an exemplary flow chart for transmitting collected data to a cloud according to some embodiments of the present description;
FIG. 3 is an exemplary flow chart for constructing a three-dimensional digital twin model according to some embodiments of the present description;
FIG. 4 is an exemplary flow chart for constructing a domain knowledge graph, in accordance with some embodiments of the present description;
FIG. 5 is an exemplary flow chart of constructing a device knowledge graph, in accordance with some embodiments of the present description;
FIG. 6 is an exemplary flow diagram for constructing a digital back-end service platform according to some embodiments of the present description.
Detailed Description
The method and system provided in the embodiments of the present specification are described in detail below with reference to the accompanying drawings.
FIG. 1 is an exemplary flow chart of a digital back-end service platform construction method based on a design circuit according to some embodiments of the present disclosure, as shown in FIG. 1, comprising: carrying out equipment circuit design by adopting a circuit design tool, generating a circuit schematic diagram and a printed circuit PCB layout file, and obtaining structured data and unstructured data of the equipment circuit design, wherein the unstructured data comprises equipment function description and technical parameters; deploying a data acquisition gateway, acquiring the structured data in the first step through a multi-protocol adapter, and transmitting the acquired structured data to a cloud data processing center; in a cloud data processing center, semantic analysis is carried out on structural data based on a body and a semantic template, functional information of equipment is obtained, the extracted functional information is stored into an equipment knowledge base after static storage encryption and dynamic access encryption, and a three-dimensional digital twin model corresponding to the equipment entity is constructed based on Web GL standards of a Web image base; constructing a domain knowledge graph by utilizing the structured data in the first step based on the ontology engineering method; carrying out semantic analysis on unstructured data in the first step by adopting a natural language processing method, and extracting equipment attributes; according to the extracted equipment attribute, adopting TransE knowledge representation learning algorithm, obtaining semantic mapping relation between the three-dimensional digital twin model in the second step and the constructed domain knowledge map, and generating equipment knowledge map according to the obtained semantic mapping relation; constructing a digital back-end service platform by adopting a micro-server architecture and a containerization mode; splitting the digital back-end service platform into a plurality of micro services, wherein the micro services comprise equipment access, data processing, model construction and application services; decoupling communication between micro services through a REST interface; constructing a micro-service domain ontology in each micro-service by adopting an ontology engineering method, performing ontology mapping from an equipment knowledge graph to a micro-service domain model by using an ontology reasoning rule, and generating a micro-service domain model code by using an Apache Jena framework; and packaging the micro-services by adopting a Docker container engine, arranging and managing containers by adopting Kubernetes, and constructing a digital back-end service platform.
And (3) carrying out equipment circuit design by adopting a circuit design tool, generating a circuit schematic diagram and a PCB layout file, and obtaining structural data (such as component parameters, a netlist and the like) and unstructured data (such as a design description document) of the equipment circuit design, wherein the unstructured data comprises equipment function description and technical parameters. Specifically, first, a circuit design engineer performs a schematic design of a device circuit using a circuit design tool such as Altium Designer, cadence Allegro, or the like. In the schematic diagram design process, an engineer selects required components from a component library, such as a resistor, a capacitor, an integrated circuit and the like, drags the components to a schematic diagram editing interface, and connects pins of the components according to design requirements to form a complete circuit topology structure. After the schematic drawing is drawn, the design tool automatically generates a component list (BOM) file, wherein the content comprises structural parameters such as component material numbers, specifications, quantity and the like. Meanwhile, the tool stores the circuit schematic diagram under a local engineering catalog in file formats such as SchDoc. Next, the engineer uses a design tool to make PCB layout designs based on the schematic diagram. And arranging the components on the PCB panel, and finishing operations such as wiring, layout optimization and the like. In the design process, the tool checks at any time whether the layout meets the electrical rules and design specifications. After the layout is completed, the tool generates PCB manufacturing files in Gerber format. At the same time, a structured netlist file is generated that contains the wiring topology, wiring parameters. The PCB layout file and netlist file are also saved in the local engineering directory. In the above circuit design process, engineers also need to write design description documents to describe the functional description, key technical parameters, design notes, etc. of the device in detail. The document is typically stored in Doc folders under engineering directories in unstructured file form such as PDF, word, etc.
FIG. 2 is an exemplary flow diagram of transmitting collected data to a cloud, deploying a data collection gateway, collecting structured data files such as schematic files, PCB layout files, etc. via a Web DAV protocol, and collecting structured data messages such as BOM, design change records, etc. via an MQTT protocol, according to some embodiments of the present description. And converting the collected structured data file and information into a JSON format through a data conversion engine, encrypting by using an asymmetric encryption algorithm, and transmitting to a cloud through a TLS protocol. Specifically, a data acquisition gateway program is deployed on a local computer or local area network server of a designer. The gateway is developed by using Java language, is constructed based on a Spring Boot framework, and can specify parameters such as a data acquisition catalog, a transmission protocol, an encryption algorithm and the like through configuration files. The gateway collects structured data files such as schematic files (. SchDoc) under the specified directory of a designer's local computer, PCB layout files (Gerber) and the like through a Web DAV (Web Distributed Authoringand Versioning) protocol. The Web DAV is used as an extension of the HTTP protocol and supports remote read-write operation of files on the Web server. A lightweight Web DAV server is embedded in the gateway, and a designer allows the gateway to access and collect files by configuring a Web DAV shared directory. For structured data messages such as BOM, design change records, etc., the gateway collects through MQTT (Message Queuing Telemetry Transport) protocol. The design tool supports the publishing of BOM and other data to a specified MQTT theme in a JSON format, and the gateway subscribes to the theme and receives message data published in real time. The MQTT is used as a lightweight publish/subscribe message protocol and supports flexible data transmission and real-time communication. After the gateway collects the structured data file and the information, the structured data file and the information are converted into a unified JSON format through a built-in data conversion engine. For schematic files, PCB layout files and the like, the gateway calls a corresponding parser, extracts key data fields and assembles the key data fields into a structured JSON object. For messages such as BOM which are already in JSON format, the gateway can perform field screening and structure optimization on the messages so as to enable the messages to be matched with a data model of the system. In order to ensure the safety of data transmission, the gateway uses an RSA asymmetric encryption algorithm to encrypt the structured data in the JSON format. The gateway generates 1024-bit RSA key pairs, the public key is built-in or distributed to the cloud through a secure channel, and the private key is stored locally in the gateway. In the encryption process, the gateway encrypts the data by using the public key, so that only the cloud end with the private key can be decrypted. The encrypted data is transmitted to the cloud end through TLS (Transport Layer Security) protocols. And the gateway establishes TLS connection with the cloud end, so that data encryption and integrity check of a transmission layer are ensured. The gateway establishes a secure communication channel with the cloud end by configuring an IP address, a port number and a TLS certificate. After being encrypted by TLS, the JSON data is sent to a data receiving API interface of the cloud through an HTTPSPOST request.
FIG. 3 is an exemplary flow diagram of constructing a three-dimensional digital twin model for decrypting received encrypted data using an asymmetric encryption algorithm at a cloud data processing center, according to some embodiments of the present description. Based on the circuit design field ontology and the semantic analysis template, carrying out semantic analysis on the structured JSON data, and extracting a circuit topology structure diagram and parameters of the equipment as equipment function information. And carrying out static storage and dynamic access encryption on the equipment function information by adopting transparent data encryption and session encryption, and storing the equipment function information into an equipment knowledge base. Meanwhile, a three-dimensional digital twin model is built based on the Web GL standard.
Specifically, data decryption: and after receiving the JSON data encrypted by the RSA public key, the cloud data processing center decrypts the JSON data by using the built-in RSA private key. The decryption process invokes standard RSA algorithm libraries, such as Open SSL, bouncy Castle, etc., to ensure confidentiality of the data. And obtaining original JSON format data after decryption. Semantic parsing: in order to realize the semantic extraction of design data, a circuit design field body and a semantic analysis template are constructed in advance. The ontology is described in OWL (Web Ontology Language) language, defining domain concepts, attributes and relationships, such as components, connections, parameters, etc. The semantic parsing template is expressed using JSON-LD (JSON for LINKING DATA) format, mapping JSON fields with ontology concepts. In the analysis process, the Apache Jena framework is used for loading the domain ontology, and the automatic conversion from JSON data to the ontology instance is realized through SPARQL query sentences, so that semantic elements such as entities, relations and the like are extracted. Knowledge extraction: on the basis of semantic analysis, a circuit topology structure diagram and key parameters of the equipment are further extracted to serve as equipment function information. The ontology instances are stored in the form of an attribute map using RDF (Resource Description Framework) graphics databases, such as APACHE TINKER Pop. and traversing the language through the Gremlin graph, taking the components as nodes and the connecting wires as edges, and extracting the circuit topological structure. Meanwhile, through SPARQL inquiry, key information such as component parameters, version change and the like is extracted. The extracted functional information of the equipment is organized in the form of a knowledge graph. And (3) safe storage: to secure the storage of sensitive design data, transparent Data Encryption (TDE) and session Encryption techniques are employed. And performing static encryption storage on the equipment function information by using the TDE, namely encrypting the data before writing the data into the disk, and ensuring that the data on the physical storage medium is unreadable. the TDE is implemented by an integrated encryption module (e.g., SQL CIPHER) and the encryption key is generated and managed by a key management system. For dynamic data access, session encryption based on SSL/TLS is used, so that confidentiality of data in the network transmission process is guaranteed. And (5) knowledge warehouse entry: the encrypted device function information is stored in the device knowledge base in the form of RDF triples (subject-predicate-object). The knowledge base uses Graph database implementations, such as Neo4j, janus Graph, etc., to support efficient Graph traversal and SPARQL queries. The semantic parsed RDF data is imported into the graph database in batches through RDFETL (Extract, transform, load) tools, such as APACHEANY, to construct a complete knowledge graph. Three-dimensional modeling: for digital twinning of visual presentation devices, three-dimensional models are built using the Web GL (Web Graphics Library) standard. The Web GL serves as a browser-native 3D rendering API supporting hardware acceleration and cross-platform interactions. Through Web GL frames such as three.js, the circuit schematic diagram, the PCB layout and the like are converted into a three-dimensional visual model. Model data is stored in glTF (GL Transmission Format) format, supporting network transport and rendering. In the modeling process, the geometrical model and the spatial layout of the components are generated by analyzing the schematic diagram topology and the layout coordinates, and visual attributes such as materials, illumination and the like are added to the model, so that a vivid visual effect is realized. And the three-dimensional model is associated with semantic information in the equipment knowledge base, so that data-driven visualization is realized.
FIG. 4 is an exemplary flow chart for building domain knowledge graph, using an ontology engineering approach to building a device circuit domain ontology model, according to some embodiments of the present description. And analyzing the structured data file into attribute-value pairs, converting the attribute-value pairs into an ontology instance triplet through semantic mapping rules, and storing the ontology instance triplet into a JenaRDF database. And obtaining the association triples through Pellet reasoning based on SWRL rules. And constructing a domain knowledge graph by combining the ontology model, the instance triplet and the associated triplet. Specifically, the body construction: and constructing an ontology model in the field of equipment circuits by using an ontology engineering method. The ontology engineering is a systematic ontology construction method and comprises the steps of demand analysis, concept extraction, attribute definition, relationship modeling and the like. First, core concepts and relationships are obtained through literature analysis and expert interviews with the field of device circuitry. Concepts, attributes and relationships are then formally defined in OWL (Web Ontology Language) language using an ontology editing tool, such as Prot g e. OWL is used as a semantic Web standard and supports rich logic expression capability. The ontology model defines core concepts Of devices, components, pins, connections, parameters, etc., and hierarchical relationships (such as sub Class Of), attribute relationships (such as HAS PARAMETER), etc. among them. The ontology model is stored in the form of OWL files. Data analysis: and analyzing the collected structured design data files, such as schematic diagram files, netlist files and the like, into attribute-value pair forms. The analysis process is realized by writing a special analyzer, such as using a PY PARSING library analysis schematic file of Python to extract information such as component names, pin numbers, connection relations and the like. The parsed attribute-value pairs are stored in JSON format for convenient subsequent processing. Semantic mapping: and converting the parsed attribute-value pairs into an ontology instance triplet through semantic mapping rules. The semantic mapping rules are defined in JSON-LD (JSON for LINKING DATA) format, mapping JSON attribute names to ontology concepts and attributes. For example, the names of the components in the schematic diagram are mapped to Device class examples in the ontology, the Pin numbers are mapped to Pin class examples, and the Connection relations are mapped to has Connection attributes. The mapping process is implemented by the Apache Jena framework, which uses its API to convert JSON data into instance triples in RDF format. And (3) knowledge storage: and storing the converted ontology instance triples into a Jena TDB database. TDB is a native RDF triplet store supporting SPARQL queries and ontology reasoning. And the instance triples are imported into the TDB in batches through the Jena API, so that a knowledge base is constructed. The TDB supports storage based on a disk, and can realize efficient management of massive triples. Rule reasoning: and reasoning the ontology instance based on SWRL (Semantic Web Rule Language) rules to obtain an implicit association triplet. The SWRL rule is expressed in terms of a Horn clause, with the front piece (Body) consisting of a series of atoms (Atom) and the back piece (Head) consisting of one Atom. An atom may be a type predicate, an attribute predicate, etc. For example, a rule is defined that if two pins are connected by a wire, the components to which they belong are also connected. And (3) reasoning SWRL rules by using a Pellet reasoning machine, automatically deducing new association facts according to attribute relations among ontology instances, and enriching a knowledge graph. And (3) constructing a map: and integrating the ontology model, the ontology instance triples and the related triples obtained by reasoning to construct the domain knowledge graph. The knowledge graph is expressed in the form of RDF graph, the nodes are instances of the ontology concept, and the edges are attribute relations among the instances. The knowledge graph is stored by using a graph database such as Apache Jena or Neo4j, and flexible graph query and analysis are supported. Meanwhile, SPARQL endpoints are provided, so that knowledge maps can be queried and inferred through standard SPARQL sentences.
FIG. 5 is an exemplary flow diagram for building a device knowledge graph, using BERT-based pre-training models for named entity recognition, for unstructured data, in accordance with some embodiments of the present specification. RDF format conversion is carried out on the knowledge graph and the three-dimensional model, the TransE algorithm is used for learning the embedded representation, the similarity is calculated, semantic mapping is built, and the semantic mapping is integrated into the unified equipment knowledge graph. Specifically, named entity recognition: and carrying out named entity recognition on the collected unstructured data, such as a design description document. Named Entity Recognition (NER) is a key task of natural language processing, aimed at recognizing specific types of entities, such as person names, place names, organization names, etc., from unstructured text. Here, the NER is performed using a BERT (Bidirectional Encoder Representations from Transformers) -based pre-trained model. BERT is a language model based on a transducer architecture, and multiple NLP tasks can be realized through pre-training and fine tuning. The NER model is trained using a pre-trained BERT model, such as BERT-Base, and fine-tuning on labeling data in the field of device circuitry. The design description document is input into a trained NER model, and key entities such as equipment names, key parameters and the like are identified. The recognition result is output in the form of entity type and location. And (3) knowledge graph conversion: and converting the constructed knowledge graph into an RDF format. Knowledge-graph is stored in the graph database in the form of nodes and edges, which need to be converted into standard RDF triples for integration with other data sources. Node and edge information is extracted from the graph database through SPARQL query by using an RDF tool library such as Apache Jena or RDF4J, and is converted into a triple form of a subject-predicate-object. The converted RDF data is stored in a format of Turtle, RDF/XML and the like.
Three-dimensional model conversion: and carrying out RDF format conversion on the constructed three-dimensional model. The three-dimensional model is stored in glTF format and contains information such as geometry, materials, scenes and the like. This information needs to be extracted and mapped into the RDF data model. The glTF model was parsed into JSON structured data using a glTF-Trans former or the like tool. The JSON data is then converted into RDF triples according to a predefined RDF mapping template. For example, map the name of the model to rdfs: label attribute, map geometry data to geo: asWKT attributes, etc. And establishing association between the converted RDF data and the original three-dimensional model to form a visual representation with rich semantics. Semantic embedding: the knowledge graph and three-dimensional model in RDF format are subjected to embedded representation learning by using TransE (TRANSLATING EMBEDDING FOR MODELING MULTI-relational Data) algorithm. TransE is a distance-based knowledge-graph embedding model that maps entities and relationships into a continuous low-dimensional vector space so that semantic relationships between entities can be represented by vector operations. And inputting the RDF triples of the knowledge graph and the three-dimensional model into a TransE model, and learning the embedded vectors of the entity and the relation through optimization algorithms such as random gradient descent. The learned embedded vector can characterize semantic similarity of entities and relationships.
Semantic mapping: and calculating the semantic similarity between the knowledge map entity and the three-dimensional model entity by using the embedded vector obtained by learning, and establishing a semantic mapping relation. And comparing the distances between the entity embedded vectors by using measurement modes such as cosine similarity and the like to obtain a similarity score. And according to the similarity threshold, establishing a semantic mapping relation between the entity pairs with high similarity, and adding the semantic mapping relation into a new RDF triplet. For example, the device entities in the knowledge-graph are "has Model Representation" related to corresponding components in the three-dimensional model. Map integration: and integrating the named entity identification result, the knowledge graph RDF data, the three-dimensional model RDF data and the semantic mapping relation to construct a unified equipment knowledge graph. Using map databases such as Apache Jena or Neo4j, RDF triples from different sources are imported into the same map store. Semantic isomerism among different data sources is eliminated through ontology alignment and instance matching technology, and knowledge fusion and association are realized. The finally formed device knowledge graph comprises multi-source heterogeneous data such as structured attributes, unstructured descriptions, three-dimensional models and the like of the device and semantic association among the multi-source heterogeneous data, and provides a comprehensive and consistent device knowledge representation.
FIG. 6 is an exemplary flow diagram for constructing a digital back-end service platform based on a micro-service architecture, according to some embodiments of the present description. According to the function division micro services, each micro service constructs the domain ontology thereof. And mapping the concept and the instance of the equipment knowledge graph into the micro-service ontology through SWRL rule reasoning and semantic similarity calculation. The ontology is converted into micro-service domain model code using the Jena framework. An ontology is used as a semantic data exchange format between micro services. Specifically, the micro-services are divided: the system is divided into a plurality of micro-services according to the business functions of the digital twin platform. Each micro-service is responsible for an independent business domain such as equipment management, simulation analysis, fault diagnosis, etc. The micro services interact through lightweight communication protocols (such as RESTful API, gRPC and the like), so that loose coupling architecture design is realized. The development, deployment and arrangement of the micro services are realized by using a Spring Cloud, a Kubernetes and other micro service frameworks and containerization technologies. And (3) building a domain ontology: for each micro-service, its domain ontology is built formally describing the core concepts, attributes and relationships that the service involves. The domain ontology is defined using OWL (Web Ontology Language) language, capturer service related domain knowledge. For example, the ontology of the device management service may include concepts of devices, components, attributes, etc., as well as hierarchical and attribute relationships between them. And constructing and maintaining the micro-service ontology by using ontology editing tools such as Prot g and the like and cooperating with domain experts.
Concept mapping: and mapping the concepts and the examples in the constructed device knowledge graph into the micro-service ontology. Concept matching and association across ontologies are achieved through SWRL (Semantic Web Rule Language) rule reasoning and semantic similarity calculation. For example, using SWRL rules "device concepts in device knowledge graph are equivalent to device concepts in device management service ontology", a concept map between two ontologies is established. Semantic similarity between concepts is calculated using a semantic embedding-based similarity calculation method, such as TransE, to find the most relevant concept pairs. The concept mapping results are stored in the form of OWL ontology mapping files. Body conversion: the micro-service ontology is converted into domain model code of programming languages such as Java by using an Apache Jena framework. Jena provides a rich API supporting parsing, querying and manipulation of OWL ontologies. Through the Ontology Model (Jena's API), the microservice Ontology is loaded and the code generator is used to convert the Ontology classes, properties and relationships into corresponding Java classes, properties and methods. The generated domain model code is used as a core data structure of the micro-service, and encapsulates business entities and logic required by the service. Data exchange format: an ontology is used as a semantic data exchange format between micro services. The input and output data of the microservice are represented in RDF (Resource Description Framework) format, i.e., in the form of a subject-predicate-object triplet. RDF data is serialized and transmitted in a standard format such as Turtle, RDF/XML and the like. The microservices exchange data in RDF format via communication protocols such as HTTP, message queues, and the like. The receiving micro-service uses the Jena framework to analyze RDF data and maps the RDF data to the domain object defined by the ontology, so that the semantic interpretation and processing of the data are realized. Service orchestration: automatic discovery, selection and combination of micro-services is achieved based on semantic descriptions using an ontology-driven service orchestration method. Each microservice describes its functions, inputs, outputs, and pre-conditions, etc., using an ontology language such as OWL-S (Semantic Markup for Web Services). The service requester queries the service registry through the SPARQL, and finds the matched service according to the semantic description. And using semantic reasoning and planning algorithms to automatically generate service combination flows, and realizing flexible arrangement of complex business logic.
The micro services are encapsulated using a Docker container engine, and the micro service interfaces are orchestrated through an API gateway. Container lay-up and auto-collapsing were performed using Kubernetes. Injecting the micro-service ontology URI into a container environment variable through a Docker file for initializing and loading the micro-service in the container. Specifically, the container is packaged: the micro-services are packaged as independent container images using a Docker container engine. A Docker file is created for each micro-service, describing the build steps and the operating environment of the container. The Docker file includes instructions for base image selection, application code copying, dependency library installation, environment variable setting, and the like. Microservice code and dependencies are packaged into executable JAR or WAR files using maven, gradle, etc. build tools. And constructing a container mirror image according to the file of the Docker through the Docker build command, and pushing the container mirror image to a Docker mirror image warehouse (such as Docker Hub) for version management and distribution. Interface arrangement: interfaces to micro services are orchestrated and exposed using an API gateway. The API gateway is used as a unified entrance of the micro-service and provides the functions of routing, authentication, current limiting, monitoring and the like. Using the API gateway frameworks Spring Cloud Gateway, zuul, etc., routing rules are defined to forward external requests to the corresponding micro-service instance. Routing paths, HTTP methods, request/response formats, etc. for each micro-service are declared through YAML profiles or annotations. The API gateway obtains the instance address of the micro-service from the service registry (e.g., eureka, consul) to implement dynamic routing and load balancing.
Arranging a container: the micro-service containers are orchestrated and managed using Kubernetes. Kubernetes is an open-source container orchestration platform that provides a declarative API and a rich ecosystem. One Kubernetes Deployment object is created for each micro-service, defining the configuration of container copy number, resource limitations, health checks, etc. Through Kubernetes Service objects, stable network addresses and load balancing are created for micro services. The automatic expansion and contraction (HPA) function of the Kubernetes horizontal Pod is used, the number of container copies is dynamically adjusted according to indexes such as CPU, memory and the like, and elastic expansion and contraction of micro services are realized. Zero-shutdown deployment and version management of micro services are realized through a rolling update and rollback mechanism of Kubernetes. And (3) body injection: in the Docker file, the URI of the microservice entity is injected into the environment variables of the container through the ENV instruction. And in a start script or configuration file of the micro-service, reading the environment variable, acquiring the URI of the ontology, using the Jena framework, loading the ontology file through an HTTP request or a file system, analyzing the ontology file into an ontology model object, and inquiring, reasoning and operating the ontology through Ont Model API of Jena by the micro-service to realize dynamic loading and application of domain knowledge. Service discovery: dynamic discovery and communication between micro services is achieved using a Kubernetes service discovery mechanism. Each microservice exposes a stable network endpoint through Kubernetes Service and registers with the Kubernetes built-in DNS system. The microservices make interactions through service names (e.g., device management services) rather than specific IP addresses and ports. The Kubernetes automatically analyzes the corresponding container IP and port according to the service name, and transparent communication between services is realized. Through the service discovery and load balancing of the Kubernetes, the high availability and dynamic expansion and contraction of the micro-services are realized. Configuration management: configuration information and sensitive data of the micro-services are managed using the Config Map and Secret objects of Kubernetes. The configuration file, database connection character string, API key and other information of the micro service are defined as Config Map or Secret resource, and are injected into the container through environment variable or file mounting mode. By the rolling update mechanism of the Kubernetes, the hot loading of configuration changes is realized without restarting the container. The deployment template and configuration of the micro service are defined by using a Kubernetes package management tool such as Helm, etc., so that one-key deployment and upgrading are realized.
And carrying out semantic aggregation on the structural design data based on the domain knowledge graph to construct a data warehouse covering the whole life cycle. On the basis of a data warehouse, a TensorFlow framework is used for constructing a device running state prediction model, and prediction analysis is carried out on physical quantity and state data. And carrying out representation learning on the knowledge graph by using the graph neural network model, excavating the correlation characteristics among design parameters, and guiding design optimization. Specifically, semantic convergence: and carrying out semantic aggregation on the structural design data by using the constructed domain knowledge graph. The design data includes structural parameters, process parameters, simulation results, etc. of the device. And mapping the scattered design data into a unified semantic representation through ontology concepts and relations in the knowledge graph. For example, device parameter data from different sources, such as length, diameter, etc., is mapped onto corresponding attributes of the device body. And (3) using SPARQL query and SWRL rules to realize semantic integration and reasoning of data and eliminate semantic isomerism and conflict among the data. Data warehouse: on the basis of semantic convergence, a data warehouse covering the whole life cycle of the equipment is constructed. The data warehouse adopts a star mode or a snowflake mode, and the design data is organized according to dimensions and fact tables. Dimension tables include devices, components, materials, etc., reflecting the attributes and hierarchy of data. The fact table comprises design parameters, simulation results, test data and the like, and records data snapshots of the equipment at different stages. The semantically designed data is loaded into the data warehouse using an ETL (Extract, transform, load) tool, such as APACHENIFI, KETTLE, etc. The data warehouse provides an integrated, topic-oriented view of data, supporting multidimensional data analysis and mining.
State prediction: on the basis of the data warehouse, a TensorFlow framework is used for constructing a device running state prediction model. The operating state data includes time series data of physical quantities (such as temperature, pressure) and states (such as normal, fault) of the device. The operating state of the device is modeled and predicted using an LSTM (Long Short-Term Memory) isochronous sequence prediction model. And taking the historical operation data as the input of the model, training the model in a supervised learning mode, and learning the association rule between the physical quantity and the state. And predicting the future running state by using the trained model, so as to realize the health monitoring and preventive maintenance of the equipment. Knowledge graph embedding: and performing representation learning on the domain knowledge graph by using a graph neural network (Graph Neural Network, GNN) model. GNN is a deep learning model that enables end-to-end learning directly on graph structure data. Entities and relationships in the knowledge-graph are embedded into the low-dimensional vector space using GNN models, such as Graph Convolutional Network (GCN), graph Attention Network (GAT), and the like. Semantic associations and structural features between entities are learned by aggregating neighbor information of the entities. The embedded entity vector may be used for downstream analysis tasks such as entity classification, link prediction, etc. And (3) design optimization: and (5) utilizing the knowledge graph embedding learned by the GNN to mine the correlation characteristics among the design parameters and guiding the design optimization. The design parameters are used as entities in the knowledge graph, and the embedded vectors of the design parameters are learned through the GNN model. Semantic similarity between design parameters is calculated using the embedded vectors, and potential association rules are found.
Claims (4)
1. A digital back-end service platform construction method based on a design circuit comprises the following steps:
Step one, performing equipment circuit design by adopting a circuit design tool, generating a circuit schematic diagram and a printed circuit PCB layout file, and obtaining structured data and unstructured data of the equipment circuit design, wherein the unstructured data comprises equipment function description and technical parameters;
Deploying a data acquisition gateway, acquiring the structured data in the first step through a multi-protocol adapter, and transmitting the acquired structured data to a cloud data processing center; in a cloud data processing center, semantic analysis is carried out on structural data based on a body and a semantic template, functional information of equipment is obtained, the extracted functional information is stored into an equipment knowledge base after static storage encryption and dynamic access encryption, and a three-dimensional digital twin model corresponding to the equipment entity is constructed based on Web GL standards of a Web image base;
Thirdly, constructing a domain knowledge graph by utilizing the structured data in the first step based on the ontology engineering method; carrying out semantic analysis on unstructured data in the first step by adopting a natural language processing method, and extracting equipment attributes; according to the extracted equipment attribute, adopting TransE knowledge representation learning algorithm, obtaining semantic mapping relation between the three-dimensional digital twin model in the second step and the constructed domain knowledge map, and generating equipment knowledge map according to the obtained semantic mapping relation;
Step four, constructing a digital back-end service platform by adopting a micro-server architecture and a containerization mode; splitting the digital back-end service platform into a plurality of micro services, wherein the micro services comprise equipment access, data processing, model construction and application services; decoupling communication between micro services through a REST interface; constructing a micro-service domain ontology in each micro-service by adopting an ontology engineering method, performing ontology mapping from an equipment knowledge graph to a micro-service domain model by using an ontology reasoning rule, and generating a micro-service domain model code by using an Apache Jena framework; packaging the micro-services by adopting a Docker container engine, arranging and managing containers by adopting Kubernetes, and constructing a digital back-end service platform;
Further comprises:
fifthly, carrying out semantic guidance convergence and fusion on the structured data acquired in the second step according to the equipment knowledge graph in the third step, and constructing a data warehouse covering the whole life cycle data of the equipment;
Adopting TensorFlow deep learning frames in a data warehouse, carrying out feature extraction and representation learning on equipment physical quantity data and state data by utilizing a predefined deep learning model, constructing a prediction model of the running state of the equipment, and carrying out prediction analysis on the equipment physical quantity data and the state data;
In the fifth step, further comprising:
According to the equipment knowledge graph constructed in the third step, embedding the topological structure and semantic association of the equipment knowledge graph into an input layer of a graph neural network by adopting a graph neural network algorithm, obtaining graph characteristic representation in the structured data through hidden layer calculation of the graph neural network, and carrying out graph calculation and association analysis on the structured data according to the graph characteristic representation;
The equipment physical quantity data and the state data prediction analysis result in the fifth step, and the graph calculation and association analysis result are fed back to the equipment circuit design step in the first step, and the circuit schematic diagram and the PCB layout file are adjusted;
In the second step, structured data is collected, including:
A Web DAV file transmission protocol adapter and an MQTT communication protocol adapter are deployed in a data acquisition network, and a structured data file which is generated in the circuit design process of the Web DAV protocol acquisition equipment and contains a schematic diagram file and a PCB layout file is utilized; the method comprises the steps of collecting structured data information which is generated in the circuit design process of equipment and contains BOM bill of materials and design change records through an MQTT communication protocol;
Converting the collected structured data file and structured data message into structured data in JSON format by adopting a data conversion engine based on a data description language;
encrypting the converted structured data in the JSON format by adopting an asymmetric encryption algorithm to obtain encrypted structured data;
Transmitting the encrypted structured data to a cloud data processing center through a TLS transmission protocol;
Step four, a digital back-end service platform is constructed, which comprises the following steps:
Dividing the digital back-end service platform into micro services according to functions, wherein each micro service is used as an independent service function;
defining concepts, data attributes, object attributes and attribute constraints of data and business processed by the micro-service by adopting an ontology engineering method based on OWL2 ontology language in the micro-service content to form a domain ontology model of the micro-service;
Mapping the ontology of the equipment knowledge graph constructed in the third step into a domain ontology model of the micro-service through SWRL ontology reasoning rules; the method comprises the steps that a front part of an SWRL ontology reasoning rule is a class and attribute in a domain knowledge graph ontology, a rear part is a class and attribute in a domain ontology model of a micro service, and class instance or attribute mapping in the rear part is triggered when a rule front part condition is met;
When the ontology instance mapping is carried out, comparing the semantic similarity of the equipment knowledge graph ontology with the semantic similarity of the ontology of the domain ontology model of the micro-service by using a semantic similarity calculation method based on description logic, establishing an equivalent relationship between a concept pair with the semantic similarity larger than a threshold value, and converting the instance of the concept in the domain knowledge graph ontology into the instance of the corresponding concept in the domain ontology model of the micro-service;
For the mapped microservice ontology model, converting TBox knowledge in the ontology into Java classes through a Jena framework, converting ABox knowledge into object instances, and generating a microservice domain model code; when the micro-service runs, the ontology and the micro-service data are synchronized through the ontology operation API of Jena;
the method comprises the steps of taking a domain ontology as unified semantic representation of micro-service data exchange, determining semantic mapping relations of different micro-service data through ontology matching, and carrying out data serialization processing of the ontology through a JSON-LD format to enable data returned by a micro-service interface to have semantic annotation;
step four, a digital back-end service platform is constructed, and the method further comprises the following steps:
For each micro-service divided in the step four, an API gateway is adopted as a unified entry of the micro-service, RESTful APIs based on the HTTP protocol are adopted among interfaces, and the interfaces of a plurality of micro-services are integrated and arranged through API arrangement;
The method comprises the steps that a Docker container engine is adopted to conduct containerization packaging on micro services, codes of micro service operation are defined through Docker file, and a Docker mirror image is built based on the Docker file;
adopting Kubernetes container arrangement, deploying a Docker mirror image in a pod of the Kubernetes, defining resource requirements and constraint conditions of the pod through deployment files, and constructing a digital back-end service platform;
step four, a digital back-end service platform is constructed, and the method further comprises the following steps:
when a Docker mirror image of the micro service is constructed, injecting the URI of the micro service field body constructed in the fourth step into the Docker mirror image in the form of an environment variable through an ENV instruction of a Docker file;
When the micro service container is started, the URI of the micro service domain body is obtained by reading the environment variable, and the Apache Jena framework is used for loading the micro service domain body.
2. The method for constructing a digital back-end service platform based on a design circuit according to claim 1, wherein:
In the second step, a three-dimensional digital twin model is obtained, which comprises the following steps:
Decrypting the received data by adopting an asymmetric encryption algorithm in a cloud data processing center to obtain plaintext structured data in a JSON format;
Based on a predefined circuit design domain ontology expressed in OWL ontology language and a semantic analysis template defined based on XML Schema, carrying out semantic analysis and semantic mapping on the plaintext structured data, and extracting device circuit topology structure diagram data and device parameter data as device function information;
storing the extracted equipment function information into a relational database, carrying out static storage encryption on the equipment function information by adopting a transparent data encryption mechanism of the relational database, and carrying out dynamic transmission encryption on the access process of the equipment function information by adopting a session encryption mechanism of an application server;
And acquiring equipment circuit topology structure diagram data and equipment parameter data from a relational database, and constructing a three-dimensional digital twin model corresponding to the equipment by adopting a three-dimensional visualization engine based on Web GL graphic standards.
3. The digital back-end service platform construction method based on the design circuit according to claim 2, wherein:
In the third step, a domain knowledge graph is constructed, which comprises the following steps:
based on the ontology engineering method, adopting OWL ontology language to express and define concepts and relations of the equipment circuit field to form a field ontology model;
Analyzing the structured data file in the first step into a form of attribute field and value pairs, and converting the attribute field and value pairs into ontology instance triples expressed in a subject-predicate-object form by adopting RDF statements;
In the process of generating the ontology instance triples, establishing semantic mapping rules between attribute fields and ontology concepts based on names and data types of attribute fields in a structured data file and matching corresponding concepts and attributes in an domain ontology model through a predefined SPARQL query statement;
According to semantic mapping rules, mapping subjects in the ontology instance triples into instances of ontology concepts, mapping objects into values of object attributes, and mapping predicates into relations between the ontology concepts to form an RDF knowledge base taking a domain ontology as a Schema;
Importing the RDF knowledge base into an RDF database constructed based on an Apache Jena framework, and performing semantic reasoning based on SWRL ontology reasoning rules predefined in a domain ontology model by adopting a Jena reasoning engine; the Jena reasoning engine adopts a Pellet-based reasoning algorithm, matches the ontology instance triples with the conditional parts in the SWRL rules through forward rule matching, and uses new triples generated by forward matching as the input of the subsequent rules through reverse rule linking to obtain associated triples;
and constructing a domain knowledge graph of the equipment according to the obtained ontology instance triples, the association triples and the domain ontology model.
4. The digital back-end service platform construction method based on design circuit according to claim 3, wherein:
In the third step, a device knowledge graph is constructed, and the method further comprises the following steps:
Performing natural language processing on the unstructured data files acquired in the first step by adopting a BERT-based pre-training language model, and identifying named entities; when the named entity recognition is carried out, adding the equipment attribute information in the professional dictionary in the equipment circuit field into an embedded layer of the BERT model, and marking the equipment attribute information to the corresponding word position in the unstructured data file in a template matching mode;
Respectively carrying out RDF format conversion on the three-dimensional digital twin model constructed in the second step and the equipment field knowledge graph constructed in the third step to obtain an entity-relation triplet list which is used as training data of TransE knowledge representation learning algorithm;
initializing TransE model parameters, and training a TransE model by using training data; minimizing the difference between the embedding distance of the positive sample triplet and the embedding distance of the negative sample triplet until the model converges to obtain the three-dimensional digital twin model and the embedding representation of the entity and the relation of the knowledge graph in the equipment field;
respectively calculating Euclidean distance between the obtained entity embedding representation and the relation embedding representation, obtaining entity pairs and relation pairs with the Euclidean distance smaller than a threshold value, and establishing a semantic mapping relation between a three-dimensional digital twin model and a knowledge graph in the equipment field;
And adding the entity-relation triplet list and the embedded representation of the entity and the relation obtained by the TransE model into the domain knowledge graph according to the obtained semantic mapping relation to obtain the equipment knowledge graph.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410480383.0A CN118075267B (en) | 2024-04-22 | 2024-04-22 | Digital back-end service platform construction method based on design circuit |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410480383.0A CN118075267B (en) | 2024-04-22 | 2024-04-22 | Digital back-end service platform construction method based on design circuit |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN118075267A CN118075267A (en) | 2024-05-24 |
| CN118075267B true CN118075267B (en) | 2024-07-02 |
Family
ID=91095820
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202410480383.0A Active CN118075267B (en) | 2024-04-22 | 2024-04-22 | Digital back-end service platform construction method based on design circuit |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN118075267B (en) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN118277638B (en) * | 2024-05-29 | 2024-10-22 | 天津建设发展集团股份公司 | Enterprise information management method and system |
| CN118377479B (en) * | 2024-06-26 | 2024-09-17 | 宁波沃尔斯软件有限公司 | Low-code software application system with reusable model |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110069380A (en) * | 2019-03-20 | 2019-07-30 | 浙江工业大学 | A kind of evolution of Web distributed software and monitoring method based on micro services |
| CN116306931A (en) * | 2023-05-24 | 2023-06-23 | 典基网络科技(上海)有限公司 | Knowledge graph construction method applied to industrial field |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109871259A (en) * | 2013-08-16 | 2019-06-11 | 运软网络科技(上海)有限公司 | A kind of imitative brain calculates the method and system of virtualization |
| CN110750702B (en) * | 2019-09-11 | 2023-03-31 | 中国科学院上海微系统与信息技术研究所 | Micro-service retrieval method and device, electronic equipment and storage medium |
| CN111428053B (en) * | 2020-03-30 | 2023-10-20 | 西安交通大学 | Construction method of tax field-oriented knowledge graph |
-
2024
- 2024-04-22 CN CN202410480383.0A patent/CN118075267B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110069380A (en) * | 2019-03-20 | 2019-07-30 | 浙江工业大学 | A kind of evolution of Web distributed software and monitoring method based on micro services |
| CN116306931A (en) * | 2023-05-24 | 2023-06-23 | 典基网络科技(上海)有限公司 | Knowledge graph construction method applied to industrial field |
Also Published As
| Publication number | Publication date |
|---|---|
| CN118075267A (en) | 2024-05-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN118075267B (en) | Digital back-end service platform construction method based on design circuit | |
| JP2022002075A (en) | Information recommendation method and device, electronic apparatus, program and computer readable storage medium | |
| Harth et al. | Linked data management | |
| US9342556B2 (en) | RDF graphs made of RDF query language queries | |
| Berko et al. | Application of ontologies and meta-models for dynamic integration of weakly structured data | |
| Euzenat et al. | Ontology alignments: an ontology management perspective | |
| Correia et al. | Data management in digital twins: a systematic literature review | |
| Lehmann et al. | Managing geospatial linked data in the GeoKnow project | |
| Draschner et al. | Distrdf2ml-scalable distributed in-memory machine learning pipelines for rdf knowledge graphs | |
| Pan et al. | Evolving to multi-modal knowledge graphs for engineering design: state-of-the-art and future challenges | |
| Flahive et al. | A methodology for ontology update in the semantic grid environment | |
| US11797577B2 (en) | Smart data warehouse for cloud-based reservoir simulation | |
| Paulheim et al. | Embedding Knowledge Graphs with RDF2vec | |
| Liang et al. | A survey of inductive knowledge graph completion | |
| Repta et al. | Automated process recognition architecture for cyber-physical systems | |
| Yuan | Towards ontology-based software architecture representations | |
| Yue | Semantic web-based intelligent geospatial web services | |
| Jirkovský | Semantic integration in the context of cyber-physical systems | |
| Dhakal | Log Analysis and Anomaly Detection in Log Files with Natural Language Processing Techniques | |
| Gallina et al. | Ontology-based identification of commonalities and variabilities among safety processes | |
| Kaur et al. | Towards Transparent Governance by Unifying Open Data. | |
| Roussopoulos et al. | Design semantics on accessibility in unstructured data environments | |
| Menik et al. | Towards a robust knowledge graph-enabled machine learning service description framework | |
| Batista et al. | Enabling data legitimacy in data-driven projects | |
| Hofer et al. | Construction of Knowledge Graphs: Current State and Challenges. Information 2024, 15, 509 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant |