A rapid redesign method for personalized customization production systems based on knowledge graphs

Abstract

This invention relates to a knowledge graph-based method for rapid reconfiguration design of personalized production systems. The method includes: acquiring historical engineering data related to products, processes, and equipment; performing knowledge fusion to establish a global-domain hierarchical ontology, forming a production system design knowledge graph; user-defined new product personalization requirements as task requirements for production system design reconfiguration; retrieving the design knowledge graph through processes such as requirement decomposition, equipment selection, and integration verification to obtain equipment integration scheme results; and completing the mechanical, electrical, and automation design of the production system based on the equipment integration scheme results. This invention automatically builds a production system design knowledge graph using engineering data. When product personalization requirements change, a design scheme meeting the new requirements is obtained through knowledge graph retrieval, enabling multidisciplinary collaborative design of the production system's mechanical, electrical, and automation components, and automatically verifying whether the scheme meets the requirements.

Description

Technical Field

[0001] This invention belongs to the field of intelligent production lines, specifically involving a rapid reconfiguration design method for a personalized customization production system based on knowledge graphs. Background Technology

[0002] Personalized customization production systems are based on robotic modular workstations and utilize AGV intelligent logistics as a connection. They are dynamically reconfigured according to rapidly changing small-batch customized products, representing the main mode of personalized production. The production system design process involves designing the mechanical and system layout of equipment based on product process requirements, planning the production process flow, designing the electrical system of automation systems and programming PLCs, verifying and debugging functions and performance, and providing feedback and corrections to the designed solutions until the system meets the design requirements.

[0003] Personalized customized production products are constantly evolving, requiring production systems to dynamically and rapidly reconfigure and adjust accordingly, placing high demands on system design. However, while commercial tools and information technology support this, four crucial stages—document management (data retrieval), engineering implementation (modeling and programming), verification and judgment (assessing design compliance), and process collaboration (feedback and correction)—still rely heavily on human intervention. Excessive human involvement leads to a lack of automation, resulting in time-consuming processes, error-prone workflows, difficulty in ensuring optimal solutions, and extremely high adjustment costs, failing to meet the requirements of personalized customized production. Therefore, establishing a design methodology that reduces human intervention and achieves fully automated collaboration is a research challenge in this field, aiming to address the problem of reliance on human experience in personalized customized production system design. Summary of the Invention

[0004] To address the shortcomings of existing technologies, the technical solution adopted by this invention to achieve the above objectives is as follows:

[0005] A rapid redesign method for personalized customization production systems based on knowledge graphs, comprising:

[0006] Step 1: Obtain historical engineering data related to products, processes, and equipment from the mechanical, electrical, and automation software design tools of the production system;

[0007] Step 2: Perform knowledge fusion processing on the acquired engineering data to establish rule templates and knowledge graph instances based on a global-domain hierarchical ontology, resulting in three types of knowledge bases;

[0008] Step 3: Users define new product personalization requirements as task requirements for the restructuring of the production system design scheme;

[0009] Step 4: Through the process of requirements decomposition, equipment selection, and integration verification, the design knowledge graph is retrieved to obtain the equipment integration solution results within the production system;

[0010] Step 5: Based on the selected equipment integration scheme results in the knowledge graph, use production system design tools to complete the mechanical, electrical, and automation design of the production system.

[0011] The method utilizes engineering data to automatically build a production system design knowledge graph. When product personalization requirements change, the method retrieves design solutions that meet the new requirements through knowledge graph retrieval, realizing multi-disciplinary joint design of mechanical, electrical, and automation systems in the production system, and automatically verifying whether the solutions meet the requirements.

[0012] The global-domain hierarchical ontology includes: a domain ontology, used to define product components and assembly connections, process flow sequence, and equipment structural capabilities; and a global ontology, used to define the basic constituent units and component relationships of the componentized system.

[0013] The domain ontology includes:

[0014] The product domain ontology describes the triple Product = (Component, port, Liaison) which consists of product components, ports, and assembly relationships; Component is the product component; port is the connection surface between product components; Liaison represents the assembly connection relationship between two adjacent components;

[0015] Process domain ontology, used to define triples composed of activities, ports, and timing relationships; Process =<Activity,port,temporal relation> Among them, Activity represents various assembly activities; temporalrelation indicates the sequential relationship between two adjacent assembly activities;

[0016] The device domain ontology is used to form a triple Equipment = (Equipment, port, Coordination) consisting of a device, a device port, and a coordination relationship; where Equipment represents various types of devices; port represents the interface between devices; and Coordination represents the coordination relationship between devices.

[0017] The knowledge fusion processing of the acquired engineering data includes: establishing rule templates for process knowledge and equipment resource knowledge based on the definition of triples in the ontology, according to the basic relationship between product process requirements and equipment process capabilities; and using knowledge extraction methods to extract instances from the engineering data, fill knowledge graph instances, and finally generate three types of knowledge bases.

[0018] The three types of knowledge bases include:

[0019] An instance library, used for configuring subsequent product, process flow, and equipment instances;

[0020] Type library, used for selecting abstract types;

[0021] Template library, used to describe product requirements, process requirements, and equipment requirements.

[0022] The process of demand decomposition, equipment selection, and integration verification involves loading rules, decomposing user-defined product requirements, querying and searching for instances that match the equipment type, and verifying the process to obtain the production system structure and complete production business flow. Specifically, this includes:

[0023] The user-defined product structure is further decomposed to obtain a set of equipment requirements at the action-level process and module level. In the equipment instance library, requirements and equipment capabilities are matched to obtain a candidate set of equipment types. For each equipment type defined in the candidate set, the corresponding equipment instances are integrated and combined at the smallest granularity, eliminating incompatible interfaces to obtain a system-level integration solution. The system integration solution undergoes system-level functional and performance verification to further eliminate system-level combinations that do not meet design requirements, ultimately yielding the system-level equipment module integration solution.

[0024] It generates mechanical equipment layout, electrical design layout, and control logic code through the interface between knowledge graphs and engineering tools, realizing mechanical, electrical, and automation design.

[0025] When the product changes, first redefine the product structure according to step three, then redefine the requirements, select equipment, and verify the system according to step four, and finally complete the mechanical, electrical, and automation design scheme according to step five.

[0026] A knowledge graph-based device for rapid reconfiguration of a personalized customization production system includes a processor and a memory. The memory stores the following program modules. When the processor loads the program modules, it executes the method steps described above to achieve rapid reconfiguration of the production system design based on the user's personalized product requirements.

[0027] The engineering data acquisition module is used to acquire engineering data related to products, processes, and equipment resources in the production line.

[0028] The knowledge fusion module is used to perform knowledge fusion processing on the relevant engineering data of products, processes and resources, and to establish rule templates and knowledge graph instances based on a global-domain hierarchical ontology to obtain three types of knowledge bases;

[0029] The task requirements module is used by users to define new personalized product requirements, which serve as task requirements for the redesign of the production system.

[0030] The integration results module is used to retrieve the design knowledge graph through the requirements decomposition, equipment selection and integration verification process, and obtain the equipment integration solution results within the production system.

[0031] The execution module is used to complete the mechanical, electrical, and automation design of the production system based on the selected equipment integration scheme results in the knowledge graph.

[0032] The present invention has the following beneficial effects and advantages:

[0033] 1. This invention utilizes existing process and equipment domain ontology to develop a new method for integrating process specifications and assembly workstation configurations. The design method of this invention focuses on addressing identified knowledge gaps and enabling personalized customization of process flows:

[0034] 2. This invention can propose a method for decomposing and specializing assembly tasks;

[0035] 3. The method of this invention proposes a way to match the required process capabilities with existing hardware capabilities;

[0036] 4. The method of this invention proposes a method for integrating equipment modules into an assembly workstation;

[0037] 5. The present invention proposes a comprehensive method for assessing the process capability of an assembly workstation. Attached Figure Description

[0038] Figure 1 This is a flowchart of the method of the present invention; Detailed Implementation

[0039] To make the above-mentioned objects, features, and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Many specific details are set forth in the following description to provide a thorough understanding of the present invention. However, the present invention can be implemented in many other ways different from those described herein, and those skilled in the art can make similar modifications without departing from the spirit of the invention. Therefore, the present invention is not limited to the specific embodiments disclosed below.

[0040] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used herein in the description of the invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention.

[0041] In this invention, a novel method is developed for integrating product requirement definitions, manufacturing process specifications, and manufacturing system equipment configurations using existing product, process, and equipment domain ontology. The specific process will be described below, with each step clearly outlined.

[0042] Preferably, in step 2, the global ontology can be defined as common concepts and relationships across the three domains of product, process, and equipment, expressed as a triple o = a set of concepts, a set of relationships, and a set of constraints.<C,R,A> ,in:

[0043] C represents the set of concepts for the production system. A production system that supports personalized customization should have modular and composable characteristics, that is, any concept should have a modular and hierarchical structure. The upper-level modules can be composed of multiple decomposable and composable lower-level modules. These modules have multiple ports, and the time-space relationships between modules are connected through connections.

[0044] Therefore, the global ontology concept set should mainly express three basic concepts. First, the structural concept expresses modular structure, mainly describing concepts between levels, such as robot units, storage units, fixture units, and other equipment units constituting an assembly station; second, the hierarchical concept unifies the concept hierarchy. It mainly describes concepts belonging to different levels, such as assembly systems, workstations, equipment units, and equipment modules; finally, the taxonomic concept defines classification terms, mainly describing different objects at the same level, such as processing workstations, transportation workstations, and warehousing workstations, etc., belonging to the workstation level.

[0045] Therefore, the production system is expressed as: System =<component,port,connection>

[0046] R is a set of relations in the production system, where hierarchical concepts are related by the hasParts relation, which describes the inclusion relationship between upper-level and lower-level concepts; structural concepts are related by the connects relation, which describes the structural connection relationship between concepts; and categorical concepts are related by the isA relation, which describes the subdivision of upper-level concepts.

[0047] A is a set of rules, A(i)∈A, which are used to constrain and regulate the construction of product, process and equipment models;

[0048] Preferably, in step 2, the domain ontology is based on the basic structure and hierarchical relationship of the global ontology, and is respectively oriented towards the specific concepts and relationships of the product domain, process domain and equipment domain.

[0049] Among them, the product domain ontology expresses the structure of the product, which is defined as being composed of multiple parts / segments connected by a specific assembly type.

[0050] In terms of common concepts, the product domain ontology structure concept set is expressed as a triple Product / Assembly = (Component, port, Liaison), consisting of product components, ports, and assembly relationships. Here, Component represents a product component; port represents the connection surface between product components; and Liaison represents the assembly connection relationship between two adjacent components.

[0051] The set of hierarchical concepts in the product domain ontology is as follows:<product,assembly,sub-assembly> The top layer is the product, which consists of multiple assemblies. Each assembly can also consist of multiple sub-assemblies, and so on in a nested manner until the bottom layer.

[0052] The classification concept of the product domain mainly includes the classification of product components, such as metal parts, non-metal parts, and composite material parts; the classification of component ports, such as clamping surface ports and connecting surface ports; and the classification of assembly types, such as screw connections, adhesive connections, and welding.

[0053] In terms of domain concepts, the product's geometric dimensions, quality, material properties, color, and process requirements are considered. Simultaneously, the product also has a State, describing the process of transitioning through different states during assembly to ultimately complete the finished product. Finally, the product's SpatialState describes its positional movement within the production system.

[0054] Preferably, in step 2, the process domain ontology is described as an assembly task sequence formed by connecting multiple assembly process steps through temporal logical relationships.

[0055] In terms of common concepts, the structural concept set of the process domain ontology is expressed as a triple consisting of activities, ports, and timing relationships: Process =<Activity,port,temporal relation> Among them, Activity represents various assembly activities; compared to connection in the global ontology, temporal relation has a directional attribute, indicating the sequential relationship between two adjacent assembly activities.

[0056] The hierarchical concept set of the ontology of the process domain is as follows<task,operation,action> In this context, "task" refers to the system-level operation at the workstation; "operation" refers to the operation within the workstation level; and "action" refers to the low-level action performed by the robot.

[0057] The concept set of classifications of the process domain ontology includes: at the task level, mainly at the production system level, describing several types of tasks such as assembly, quality inspection, and transportation; at the operation level, mainly within the workstation, describing specific assembly operations such as loading, fixing, assembling, and unloading; and at the action level, mainly various robot meta-actions such as linear motion, rotational motion, clamping, and releasing.

[0058] In terms of domain concepts: an action should consist of a precondition and an effect, indicating the conditions that must be met before the action is executed and the impact on the external world after the action is executed. Ultimately, it should be expressed as a state transition system with state machine semantics. This also includes the action's start time (StartTime) and end time (EndTime).

[0059] Define two types of constraints: process decomposition constraints and operation object constraints.

[0060] The process decomposition constraint defines a specific process flow, which should consist of several lower-level process flows arranged in a specific temporal logical relationship. Specifically, the decomposition constraint for each task is defined: Task =<operations,ports,temporalrelationship> This expresses that a task consists of multiple operations arranged in a specific temporal order; and the decomposition constraints of operations, where operation =<actions,ports,temporal relationship> This expresses that an operation consists of multiple actions arranged in a specific temporal sequence.

[0061] The constraint on the operation object is defined as the liaison type of the product component assembly connection relationship that the process can complete, or the component type of the product component that can be manipulated, or the Activity Type. <requirements>Liaison Type establishes a cross-domain relationship between process type in the Process domain and components / connections in the Product domain, and serves as a type to distinguish Activities at the same level of taxonomy.

[0062] Preferably, in step 2, the equipment domain ontology can be expressed as the layout formed by the spatial layout relationship of the equipment in the production system, and the functions of the production system are formed by the cooperative relationship between the equipment.

[0063] In terms of common concepts, the global structural concept set of the device domain ontology is expressed as a triple consisting of device, device port, and cooperation relationship: Equipment = (Equipment, port, Coordination). Here, Equipment represents various types of devices; port represents the interface between devices; and Coordination represents the cooperation relationship between devices.

[0064] The hierarchical concept set of the device domain ontology is as follows<Production System,Workstation,Unit,Device,Component> In this context, the production system is the top-level concept, and the workstation is a single unit that completes an independent assembly task.

[0065] The classification concept set of the equipment domain mainly standardizes the specific classifications of workstations, equipment units, and equipment. For example, equipment units include operation units, storage units, and support units.

[0066] In terms of domain concepts, the main definitions are: the capabilities of the equipment, the functions of the equipment, and its behavior.

[0067] Equipment hasFunction Function, Equipment hasBehavior Behavior.

[0068] Function (functional sequence relationship), behavior (physical principle of implementing the function), and structure (components): for more precise matching of equipment requirements / equipment types: first, determine the abstract sequence flow that the equipment should complete based on the relationship between the process and the equipment function; then determine the physical principle (behavior) that the equipment should have to execute these functions; finally, determine the equipment component structure that the equipment should have.

[0069] Equipment also has states, describing the process of product assembly through different state transitions to finally complete the finished product; it also describes the product's positional state, describing the product's movement within the production system.

[0070] Equipment <hasstate>State

[0071] Constraints are defined as follows:

[0072] Decomposition constraint: It stipulates that a workstation should be composed of several equipment units connected according to specific interface relationships, and an equipment unit application should be composed of several devices connected according to interface relationships.

[0073] Constraints with process: Forced decomposition of workstations and tasks, equipment units and operations, devices and actions.

[0074] Specification definition: Different types of equipment are identified by function and behavior, and the basis for distinguishing different types of equipment is the classification and definition of equipment type based on process capability.

[0075] Preferably, in step 2, the instance library includes: automatically extracting relations and objects from the data using an instance-filling method. The extracted objects include equipment models in design software, function blocks in automated programming software, and typical modules in electrical design software. Based on the relevant concepts and relational triples defined in the ontology, triple instances are automatically declared to form an equipment component library, a capability library (instances), and a template library for typical product structures, control program structures, and system layout structures.

[0076] For the equipment domain, examples are mainly extracted from product design data; for the process domain, examples are mainly extracted from electrical design data and automation transformation data; and for the equipment domain, examples are mainly extracted from electrical design data and equipment mechanical design data.

[0077] Based on the characteristics of data in these domains, corresponding conceptual abstraction rules are defined to complete the mapping definition between actual data and ontological concepts, forming product instances, process instances, and equipment instances.

[0078] Three types of knowledge bases are formed. The first type is the instance library, which contains various existing product, process flow, and equipment instances (including production system level, workstation level, and equipment unit level); these instances are mainly used for subsequent instance configuration. The instance library includes:

[0079] Product module: Extracted from product design software, it meets the definition of product structure triples in the ontology (mainly extracting the product component BOM table, the collection and physical attributes of product components, the assembly connection relationship, assembly connection type and assembly process parameters of product components, etc. from the product CAD file).

[0080] Capability modules: extracted from automated programming tools. The extraction levels include: control function blocks that correspond to actions in the process and represent the robot's atomic actions. These function blocks are described using the basic concept of state machines and expressed as triples; extracted variables as preconditions and execution results of actions; and extracted steps as actions.

[0081] Equipment Module: Extracted from equipment design software and related equipment supplier websites, the extraction hierarchy includes system, workstation, equipment unit, equipment, and equipment component. Based on the basic equipment structure BOM defined from the equipment itself, the connection relationships of equipment components, and equipment interfaces, equipment capabilities, behaviors, and parameters are extracted from equipment supplier websites and instantiated. Equipment status is also extracted from the automation programming software.

[0082] The second category is type libraries, which describe abstract types and are mainly used for type selection.

[0083] The third category is the template library, which describes product requirements, process requirements, and equipment requirements. Requirement templates include: Product templates: defined as templates formed by typical product structures, upon which users define product requirements; Process templates: structural templates for typical tasks, operations, and actions. Based on product requirement instances, process templates are instantiated, and process instances that meet the requirements are queried from the process instance library to form process requirement descriptions; Equipment templates: descriptions of the layout of workstation structures within typical manufacturing systems, the layout of equipment units within workstations, and the relationships between equipment modules within equipment units.

[0084] Preferably, in step three, the user extracts the structure defining the task specification from the type library, instance library, and template library based on the product structure template, including the product component table (BOM) and the product component connection structure. This directly forms the initial process (Task_Assembly).

[0085] Preferably, in step four,

[0086] Requirements breakdown:

[0087] (1) Initialization of process / equipment requirements

[0088] The initial template is defined as:

[0089] Product: product(component, liaison);

[0090] Task: Task(Task_Assembly,Task_Transport,temporal relationship);

[0091] System: system(Workstation_Assembly, Workstation_Transport, MaterialFlow);

[0092] Select a predefined initial template, which represents the system's basic capabilities. Based on the appropriate template, extract user-defined information from the product structure requirements, and instantiate the task requirements and corresponding workstation (layout) requirements from the template:

[0093] Product structure requirements are expressed as a sequence of assembly tasks: the number of assembly tasks, and the order of these tasks ({Task_Assembly_Req(i)}).<Type,Para> ,TemporalRelation(i)}): Type, including main assembly type, number of assembly connection parts, and part size.

[0094] First, determine the list of assembly task requirements in Task_Assembly_Req(i) within the product structure requirements. Then, based on whether the assembly task capabilities provided by the process flow requirement template match (mainly considering capability type and parameters, not specific structure), select the appropriate task requirement template and the corresponding workstation layout requirement template.

[0095] Then, the task requirement type and parameter Task_Assembly_Req(i) from the product structure requirements are...<Type,Para> And the temporal relationship of the task time, TemporalRelation(i), are instantiated and populated into the selected task template;

[0096] Finally, based on multiple assembly tasks Task_Assembly_Req(i)<Type,Para> One logistics task, Task_Transport_Req(i)<Type,Para> The TemporalRelation(i) function determines the number of corresponding assembly and logistics workstations, as well as the link relationships between these workstations.

[0097] (2) Task to operation decomposition

[0098] Based on the assembly and logistics requirements in the process specifications, the assembly tasks Task_Assembly_Req(i) in the task list are processed.<Type,Para> And the logistics task Task_Transport_Req(i)<Type,Para> The requirements are broken down further, down to the Operation level.

[0099] First, select a suitable operation requirement template. The output operation is mainly at the workstation level, and the operations show a clear temporal logical relationship. The process includes: the number of assembly and connection parts, the part / finished product entry and exit method, and the main assembly type. These are the interfaces exposed by the template to the outside world, used to determine which template to select. The internal encapsulated structure of the template includes: part receiving method, workstation internal storage method, movement method from storage position to installation position, fixed positioning method, assembly operation application method, finished product storage method after assembly, and finished product outbound method.

[0100] Based on the interface exposed by the template, determine whether the template is suitable. After selecting it, extract the relevant information (including assembly type, number of parts, and part size) from the process requirements, and instantiate the internal structure of the selected template to determine all operations, operation types, operation parameters, and timing logic between operations.

[0101] (3) Operation to action decomposition

[0102] Based on the various operations in the process requirements, the assembly task Operation_Req(i) in the operation list is processed.<Type,Para> The requirements are broken down further, down to the Action level.

[0103] First, select a suitable action requirement template. The output actions are mainly at the robot action meta-language level. Each action can be regarded as a state transition, and there is a clear temporal logical relationship between actions. Each operation, after decomposition, forms a complete state transition system with a state machine semantic description.

[0104] The main atomic state machine Actions include MoveLTo, MoveRTo, Open_Gripper, and Close_Gripper. The action requirement template describes these actions, each exposing its triggering conditions, parameters (position, opening distance), execution result, and constraints between actions. The main exposed element is the parameters. Then, based on whether the operated object meets the parameter requirements, an appropriate template is selected, and the internal structure, preconditions, and execution result are instantiated to form a complete action sequence (state machine).

[0105] (4) Equipment Requirements Breakdown: Workstation > Unit

[0106] Input: During the process initialization phase, the correspondence between AssemblyTask and AssemblyWorkstation, and between TransportTask and AssemblyWorkstation;

[0107] In the Task>Operation decomposition phase, the corresponding Operation sequence is assigned to the workstation.

[0108] First, based on the Operation sequence, obtain the Function sequence for the workstation;

[0109] Then, it queries the template collection workstation(function,behavior,unit) to find templates that meet the requirements of Function, determines whether the behavior meets the requirements, and finally decomposes them into combinations of Units.

[0110] Final output: Based on the operational requirements, including the number of entries and exits, the final output determines the number of storage units (storage method), the number of execution robots (operation method), the number of internal logistics units (logistics method), and the number of assembly and fixing units (fixing method) at the workstation. This makes the relationship between behavior and equipment closer, allowing for different physical implementation methods. At the same time, removing templates that do not meet the behavior requirements is also crucial for selecting equipment templates that meet the product requirements. Finally, the operational process information is extracted, and the instantiation of functions / behaviors / units is completed.

[0111] (5) Equipment Requirements Breakdown: Unit > Device

[0112] Input: The Operation assigned to the Unit, and the sequence of Actions derived from the Operation.

[0113] These actions can be used again as functional requirements, and appropriate templates can be selected. At this level, it is basically sufficient to manipulate the corresponding components as long as the appropriate type and parameters are used; in addition, once the layout is determined, corresponding requirements are also put forward for the working range of the equipment unit.

[0114] Some units are already quite mature and do not need to be further decomposed.

[0115] The equipment with robots needs to be checked again.

[0116] (6) Modify the process according to the equipment.

[0117] Before any device action is invoked, there must be clear preconditions (such as whether the fixture meets the requirements). If the preconditions are not met, the process needs to be modified.

[0118] The product status transformation, process flow, and equipment conversion must be seamlessly integrated to form a complete requirement.

[0119] Call the device requirement template: unit(function,behavior,device), similar to the method above.

[0120] Equipment selection: Based on the workstation(function,behavior), unit(function,behavior), and device(function,behavior) obtained from the specification, select the existing results from the instance library.

[0121] First, regarding the workstation level, if a suitable option is available, select it directly.

[0122] Then there's the unit level; if there's a suitable option, just select it.

[0123] Finally, there's the device level; if a suitable option is available, then choose that.

[0124] If no options are found at any of the three levels, then the requirement is deemed unsatisfactory.

[0125] Instance integration:

[0126] Based on the unit's requirements, integrate the selected device instances, determine whether the interface meets the requirements, and if not, exit the process.

[0127] Based on the requirements of the workstation, integrate the selected unit instances, determine whether the interface meets the requirements, and exit if it does not.

[0128] System verification:

[0129] Based on the selected system instances, key indicators are calculated to determine whether they meet the requirements. If not, the process exits.

[0130] The final step of process instantiation should consider adding the preconditions and results of the action and associating them with the equipment status.

[0131] The above description constitutes the main features of the present invention. It should be noted that, for those skilled in the art, several improvements and modifications can be made without departing from the principles described in the present invention, and these improvements and modifications should be considered within the scope of protection of the present invention.< / hasstate> < / requirements>

Claims

1. A rapid redesign method for a knowledge graph-based personalized customization production system, characterized in that, include: Step 1: Obtain historical engineering data related to the product, process, and equipment; Step 2: Perform knowledge fusion processing on the acquired engineering data to establish rule templates and knowledge graph instances based on a global-domain hierarchical ontology, resulting in three types of knowledge bases; The global-domain hierarchical ontology includes: a domain ontology, used to define product components and assembly connection relationships, process flow sequence, and equipment structural capabilities respectively; and a global ontology, used to define the basic constituent units of the componentized system and component relationships. The three types of knowledge bases include: an instance library, used for configuring subsequent product, process flow, and equipment instances; a type library, used for selecting abstract types; and a template library, used for describing product requirements, process requirements, and equipment requirements. Step 3: Users define new product personalization requirements as task requirements for the redesign of the production system; users extract the structure of the defined task specification from the type library, instance library, and template library based on the product structure template, including the product component table BOM and the product component connection structure. Step 4: Through the process of requirements decomposition, equipment selection, and integration verification, the design knowledge graph is retrieved to obtain the equipment integration solution results within the production system; Step 5: Based on the selected equipment integration scheme results in the knowledge graph, complete the mechanical, electrical, and automation design of the production system.

2. The rapid reconfiguration design method for a knowledge graph-based personalized customization production system according to claim 1, characterized in that, By utilizing engineering data, a knowledge graph for production system design can be automatically built. When product customization requirements change, design solutions that meet the new requirements can be retrieved through the knowledge graph. This enables multidisciplinary joint design of the production system, including mechanical, electrical, and automation systems, and automatically verifies whether the solutions meet the requirements.

3. The rapid reconfiguration design method for a knowledge graph-based personalized customization production system according to claim 1, characterized in that, The domain ontology includes: The product domain ontology describes the triple Product = (Component, port, Liaison) which consists of product components, ports, and assembly relationships; Component is the product component; port is the connection surface between product components; Liaison represents the assembly connection relationship between two adjacent components; Process domain ontology, used to define triples composed of activities, ports, and timing relationships; Process=<Activity,port, temporal relation> Among them, Activity represents various assembly activities; temporal relation indicates the sequential relationship between two adjacent assembly activities; The device domain ontology is used to form a triple Equipment=(Equipment, port, Coordination) consisting of a device, a device port, and a coordination relationship; where Equipment represents various types of devices; port represents the interface between devices; and Coordination represents the coordination relationship between devices.

4. The rapid reconfiguration design method for a knowledge graph-based personalized customization production system according to claim 1, characterized in that, The knowledge fusion processing of the acquired engineering data includes: establishing rule templates for process knowledge and equipment resource knowledge based on the definition of triples in the ontology, according to the basic relationship between product process requirements and equipment process capabilities; and using knowledge extraction methods to extract instances from the engineering data, fill knowledge graph instances, and finally generate three types of knowledge bases.

5. The rapid reconfiguration design method for a knowledge graph-based personalized customization production system as described in claim 1, characterized in that, The process of demand decomposition, equipment selection, and integration verification involves loading rules, decomposing user-defined product requirements, querying and searching for instances that match the equipment type, and verifying the process to obtain the production system structure and complete production business flow. Specifically, this includes: The user-defined product structure is further decomposed to obtain a set of equipment requirements at the action-level process and module level. In the equipment instance library, requirements and equipment capabilities are matched to obtain a candidate set of equipment types. For each equipment type defined in the candidate set, the corresponding equipment instances are integrated and combined at the smallest granularity, eliminating incompatible interfaces to obtain a system-level integration solution. The system integration solution undergoes system-level functional and performance verification to further eliminate system-level combinations that do not meet design requirements, ultimately yielding the system-level equipment module integration solution.

6. The rapid reconfiguration design method for a knowledge graph-based personalized customization production system according to claim 1, characterized in that, It generates mechanical equipment layout, electrical design layout, and control logic code through the interface between knowledge graphs and engineering tools, realizing mechanical, electrical, and automation design.

7. The rapid reconfiguration design method for a knowledge graph-based personalized customization production system according to claim 1, characterized in that, When the product changes, first redefine the product structure according to step three, then redefine the requirements, select equipment, and verify the system according to step four, and finally complete the mechanical, electrical, and automation design scheme according to step five.

8. A rapid redesign device for a knowledge graph-based personalized customization production system, characterized in that, include: The processor and memory, wherein the memory stores the following program modules, and when the processor loads the program modules, it executes the steps of the method described in any one of claims 1-7, thereby enabling rapid reconfiguration of the production system design scheme according to the user's personalized product requirements; The engineering data acquisition module is used to acquire engineering data related to products, processes, and equipment resources in the production line. The knowledge fusion module is used to perform knowledge fusion processing on the relevant engineering data of products, processes and resources, and to establish rule templates and knowledge graph instances based on a global-domain hierarchical ontology to obtain three types of knowledge bases; The task requirements module is used by users to define new personalized product requirements, which serve as task requirements for the redesign of the production system. The integration results module is used to retrieve the design knowledge graph through the requirements decomposition, equipment selection and integration verification process, and obtain the equipment integration solution results within the production system. The execution module is used to complete the mechanical, electrical, and automation design of the production system based on the selected equipment integration scheme results in the knowledge graph.

Images