Method and system for dynamically associating and reconfiguring a device information model with a task

Abstract

The application discloses a kind of equipment information model and task can be dynamically associated and reconfiguration method and system, belong to industrial automation control technical field, the system includes: management layer, execution layer and equipment layer;Among them, management layer is responsible for constructing equipment information model, and generating equipment task program and configuration information table;Execution layer is responsible for receiving equipment information model, equipment task program and configuration information table, and equipment task program and equipment information model are established mapping relationship;Equipment layer is based on the mapping relationship of execution layer establishment, dynamically loads, runs equipment information model and equipment task program.The system proposed in the application can realize the dynamic reconfiguration of the association between equipment task program and equipment information model, so that the task of parameter or internal algorithm change can quickly adapt to the existing system, thereby effectively maintaining the efficient operation of the system.

Description

Technical Field

[0001] This invention relates to the field of industrial automation control technology, and in particular to a method and system for dynamically associating and reconstructing equipment information models and tasks. Background Technology

[0002] Thanks to advancements in science and technology, human society is now in the midst of the Fourth Industrial Revolution. The first three industrial revolutions achieved mechanization, electrification, and informatization, while the goal of the Fourth Industrial Revolution is intelligentization, the core of which is the deep integration of networking, informatization, and intelligence. However, in the field of Operation Technology (OT), the Programmable Logic Controller (PLC), the core brain of industrial control, has been unable to integrate with advanced technologies such as the Internet and artificial intelligence due to issues such as closed systems, manufacturer monopolies, and proprietary communication protocols. This prevents it from meeting the flexibility, adaptability, and transparency requirements of modern manufacturing systems. Furthermore, as customer demands become increasingly diversified and personalized, manufacturing is shifting from large-scale mass production to large-scale customized production. To improve production efficiency, control systems must possess the ability to rapidly and dynamically reconfigure without downtime.

[0003] Current control architectures are still primarily centralized, centered around PLCs. PLCs often need to support multiple industrial communication protocols such as EtherCAT, Modbus, and Profinet to communicate with complex, heterogeneous devices in the industrial field and thus control them. Furthermore, these complex, heterogeneous devices typically cannot directly interact with each other, requiring the PLC as middleware. Fortunately, with the emergence of OPC UA (a new industrial software interface specification released by the OPC Foundation in 2006), it has become possible to utilize OPC UA's information modeling capabilities to create unified semantic models for complex, heterogeneous devices with diverse communication protocols and expose their interfaces. Users can not only control devices through the interfaces exposed by the OPC UA information model, but devices can also directly interact with each other using OPC UA's client / server and publish / subscribe communication methods without needing the PLC middleware. Therefore, due to these advantages, using OPC UA to build information models for complex, heterogeneous devices has become a trend in industrial field control.

[0004] It's important to note that information modeling technology is a core component of OPC UA technology. Equipment information models can be built using modeling languages ​​such as OPC UA and AML (Automation Markup Language). These modeling languages ​​follow object-oriented design principles, constructing corresponding information models by abstracting and describing equipment functions, attributes, and related digital information. This model provides a "digital representation" of physical equipment, shielding it from the specific differences in underlying hardware and providing services externally through standardized interfaces. Because various heterogeneous devices in industrial settings all use a unified standard to build their information models, seamless communication and data exchange between devices can be achieved based on this model.

[0005] However, while the aforementioned OPC UA information model scheme provides a degree of standardized encapsulation for complex heterogeneous devices, it also presents a critical problem: the ability to control devices through the interface provided by the device information model stems from the fact that the device information model and the device task are bound together as a whole. When a user calls the information model interface, the underlying call is still to the device task program. Therefore, the functionality of the device information model and the device task as a whole must be determined and developed during the design phase. For example, method nodes within the information model must be bound to functions in the task program via the API provided by OPCUA during the design and development phase. When a user calls a method node in the information model, the method node invokes the corresponding task program as a callback function. Since the task program is determined during the development phase, it cannot be dynamically changed. In other words, the device information model and the device task program are tightly coupled. When the device task changes, the device information model cannot automatically adapt to the task changes, requiring a complete redesign and development of both the device information model and the task, severely restricting the device's dynamic reconfiguration capabilities. If an algorithm or key parameter used in a task of a device is updated, but the interface exposed by the device's information model is not affected by these updates, the device information model and the task program must be redesigned and developed because the device information model and the task program are tightly coupled. This not only results in poor dynamic refactoring capability—the task cannot be dynamically modified at runtime—but also seriously affects production efficiency.

[0006] like Figure 1The diagram illustrates the process of a PLC controlling underlying industrial equipment through an equipment information model (EIM). First, the user needs to construct the EIM organizational structure using development software. Then, they develop the control function program, which requires the use of a corresponding industrial protocol stack to control the underlying industrial equipment. Once developed, this program binds the APIs within the OPC UA protocol stack to the nodes in the EIM. After binding, the EIM runs within the OPC UA address space and cannot be modified. The higher-level PLC then accesses and calls the nodes in the EIM by accessing the OPC UA server, thereby controlling the underlying equipment. Once the EIM and control function program are developed and running, they cannot be changed. If a parameter or algorithm within the control program that does not affect the EIM needs to be updated, the control function program must be redeveloped and re-coupled with the EIM. This severely impacts industrial production efficiency and significantly restricts the dynamic reconfiguration capabilities of the industrial control system.

[0007] Furthermore, most PLC products on the market currently comply with the IEC 61131 standard. However, the IEC 61131 standard cannot meet the requirements of modern industrial control systems, such as open operation and dynamic reconfiguration. Therefore, starting in 2000, the International Electrotechnical Commission (IEC) began developing the IEC 61499 standard for distributed control systems, which was fully released in 2005. This standard addresses the limitations of IEC 61131 by introducing innovative designs such as function block encapsulation, event-driven mechanisms, and runtime management models, laying the theoretical framework for establishing distributed control systems with flexible and reconfigurable capabilities. IEC 61499 uses an event-triggered approach, unlike the periodic scanning of traditional PLCs. The execution within function blocks is triggered by events rather than a fixed cycle. When an event occurs, only the relevant function block is triggered to execute its algorithm, providing a foundation for dynamic system reconfiguration. In addition, open-source implementations based on the IEC 61499 standard, such as 4DIAC, have implemented runtime management through service interface function blocks and dynamically create / delete events and data connections to achieve task reconfigurability.

[0008] However, it should be noted that the IEC 61499 standard specifies that task execution is event-driven. The uncertainty of event triggering leads to uncertainty in task program execution, while traditional PLC tasks are triggered periodically. Therefore, compared to traditional PLCs, the task execution mechanism in the IEC 61499 standard is more complex, which is not conducive to deterministic control in industrial settings. Furthermore, due to the inherent complexity of the IEC 61499 standard's architecture, development and debugging based on this standard are more cumbersome than with traditional PLCs. Therefore, most applications of the IEC 61499 standard remain in the research stage, with traditional PLCs based on the IEC 61131 standard still being more prevalent in industrial settings. Moreover, the distributed control, event-driven, and reconfigurable control logic functions defined in this standard, while bringing high flexibility, also make the system more complex, leading to a corresponding increase in the probability of failure. In addition, the IEC 61499 standard does not consider integrating OPC UA to unify the various communication protocols used in the field and expose interfaces through the OPC UA information model to facilitate use by industrial operators. While combining traditional PLCs with the OPC UA information model solves problems such as isolated device information and inconsistent communication protocols, the inherent mechanism of OPC UA requires defining the actual operating logic for its nodes during the initial design and development phase. When a user accesses a variable node or calls a method node within the information model, the model performs the corresponding operation through mechanisms such as data sources or callback functions. However, a drawback is that the data sources bound to variable nodes and the callback functions bound to method nodes cannot be dynamically adjusted. Summary of the Invention

[0009] This invention provides a method and system for dynamically associating and reconstructing equipment information models and tasks, so as to at least partially solve the above-mentioned technical problems existing in the prior art.

[0010] To solve the above-mentioned technical problems, the present invention provides the following technical solution: On the one hand, this invention provides a system in which equipment information models and tasks can be dynamically associated and reconstructed, comprising: a management layer, an execution layer, and a equipment layer; wherein, The management layer is responsible for building the equipment information model, generating equipment task programs and configuration information tables, and distributing the equipment information model, equipment task programs, and configuration information tables to the execution layer. The execution layer is responsible for receiving the device information model, the device task program, and the configuration information table, and for establishing a mapping relationship between the generated device task program and the device information model after the device task program is generated. The device layer is used to dynamically load and run the device information model and device task program based on the mapping relationship between the device task program and the device information model established by the execution layer.

[0011] Furthermore, the management layer includes equipment model building tools and task program building tools; The device model building tool is used to build the device information model organization structure according to the interfaces that the device needs to expose to the outside world, generate an XML file describing the device information model organization structure, and import the XML file describing the device information model organization structure into the execution layer; The task program construction tool is used to construct device task programs and configuration information tables, and import the device task programs and configuration information tables into the execution layer. The device task programs are divided into IT tasks and OT domain tasks, which are used to control industrial equipment using the device's industrial protocol stack. The configuration information table is used to describe which variables or methods in the task need to be mapped to the nodes in the device information model.

[0012] Furthermore, the configuration information table is determined manually.

[0013] Furthermore, the device information model uses various types of nodes as basic building blocks, including object nodes, variable nodes, and method nodes.

[0014] Furthermore, object nodes are used to describe specific entities and functional units in a device or system.

[0015] Furthermore, variable nodes are used to represent the inherent properties and real-time running status of an object.

[0016] Furthermore, method nodes are used to define the executable behaviors and business functions of a device or system.

[0017] Furthermore, the execution layer includes a device model parser, a task program parser, a semantic matching parser, and a mapping executor; The device model parser is used to instantiate the XML file describing the organizational structure of the device information model issued by the management in the model address space, instantiate it into a device object instance, and perform semantic analysis on the instantiated model instance to extract the node handles that need to be mapped. The task program parser is used to perform semantic analysis on the identifiers in the device task program issued by the management layer, and extract the function handles and variable handles in the device task program according to the configuration information table issued by the management layer, so as to map them to the method nodes and variable nodes in the device information model later. The semantic matching parser is used to parse the internal logic of the device information model and the device task program based on the extraction results of the device model parser and the extraction results of the task program parser. It extracts the identifier name to be associated from the device task program and then matches it with the node in the device information model to finally form a mapping relationship table. The mapping executor is used to map and associate device information model instances and device task programs according to the mapping relationship table, thereby completing the binding of device information model instances and device task programs.

[0018] On the other hand, the present invention also provides a method for dynamically associating and reconstructing equipment information models and tasks, which is implemented by the aforementioned system for dynamically associating and reconstructing equipment information models and tasks.

[0019] The beneficial effects of the technical solution provided by this invention include at least the following: The system provided by this invention decouples the equipment information model from the equipment tasks. Furthermore, this system can dynamically change the mapping relationship between information model nodes and task program identifiers, dynamically reconstructing the association between task programs and the information model. Based on the system provided by this invention, users only need to focus on the development of equipment task programs without needing to worry about the coupling relationship between task programs and the equipment information model. The system can update the association between equipment tasks and the model in real time, enabling tasks with changes in parameters or internal algorithms to quickly adapt to the existing system, thereby maintaining efficient system operation and effectively reducing the development cost of industrial control systems. Attached Figure Description

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

[0021] Figure 1 It is an information model control flow chart for industrial equipment; Figure 2 This is an architecture diagram of a system where the device information model and tasks can be dynamically associated and reconstructed, as provided in the embodiments of the present invention. Figure 3 This is a flowchart illustrating the system implementation of the dynamic association and reconstruction of the device information model and the device task program provided in this embodiment of the invention; Figure 4 This is a schematic diagram of the prediction module information model provided in an embodiment of the present invention; Figure 5 This is a pseudocode diagram of the prediction module provided in an embodiment of the present invention; Figure 6 This is a schematic diagram of the workflow of a system where the device information model and tasks can be dynamically associated and reconstructed, as provided in an embodiment of the present invention. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of the present invention clearer, the embodiments of the present invention will be described in further detail below with reference to the accompanying drawings.

[0023] First, it should be noted that in the embodiments of the present invention, the words "exemplarily," "for example," etc., are used to indicate that they are examples, illustrations, or descriptions. Any embodiment or design scheme described as "exemplary" in the present invention should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of the term "exemplarily" is intended to present the concept in a specific manner. Furthermore, in the embodiments of the present invention, the meaning expressed by "and / or" can be both, or it can be either one or the other.

[0024] This embodiment provides a system in which device information models and tasks can be dynamically associated and reconstructed. Its overall architecture is as follows: Figure 2 As shown, it mainly consists of three layers: the management layer, the execution layer, and the device layer. The management layer is responsible for generating task programs and building device models, and then distributing the device information model, task programs, and configuration information tables to the execution layer. The execution layer receives the device information model, task programs, and configuration information tables, and categorizes the task programs into PLC tasks and IT domain tasks based on their type, using different strategies to establish mapping relationships between them and the information model. The device layer is responsible for dynamically loading and running the information model and task programs.

[0025] Specifically, the management team comprises the following two parts: Equipment model building tool: mainly responsible for building the organizational structure of equipment information models, generating XML files describing the organizational structure of information models, and importing them into the execution layer.

[0026] Task program building tool: mainly responsible for building device task programs, which use the device's industrial protocol stack and other technologies to control industrial equipment.

[0027] The execution layer is primarily the runtime environment for industrial control programs and includes the following modules: Device Model Parser: Responsible for instantiating the XML files generated by the device model building tools in the management layer into the model address space, and performing semantic analysis on the instantiated information model instances.

[0028] Task program parser: Responsible for semantic analysis of identifiers in task programs generated by the task program building tools in the management layer.

[0029] Semantic matching parser: It is responsible for parsing the internal logic of the device information model and the device tasks, extracting the identifier names to be associated from the device tasks, matching them with the nodes in the information model, and finally forming a mapping relationship table.

[0030] Mapping executor: Based on the mapping results of the semantic matching parser, it performs specific mapping operations to complete the binding between the information model and the task program.

[0031] The device layer mainly includes specific, complex, heterogeneous devices that have been loaded with a device management shell and have established a mapping relationship with the task program.

[0032] Based on the above, the system of this embodiment can realize the dynamic reconstruction of the association between the device information model and the device task program, that is, a method for dynamically associating and reconstructing the device information model and the task. The specific implementation process is as follows: Figure 3 As shown, the workflow of the above system is as follows: First, the upper-level controller of the management layer mainly consists of equipment model building tools and task program building tools. The equipment model building tools construct the equipment information model based on the interfaces the equipment needs to expose. The equipment information model uses various nodes as basic building blocks. Developers can manage object nodes, variable nodes, and method nodes in a structured manner according to specific organizational rules. Object nodes primarily describe specific entities and functional units within the equipment or system; they can be considered structural carriers and object instances in the information model, typically corresponding to physical or logical components such as sensors, controllers, and various functional subsystems. Variable nodes characterize the inherent attributes and real-time operating status of objects, reflecting key equipment parameters and process data, such as monitoring and control quantities like temperature, pressure, and voltage. Method nodes define the executable behaviors and business functions of the equipment or system. They are the core elements in the information model that carry specific operational logic; functions such as equipment initialization, startup control, and parameter calibration can all be implemented through method nodes. These nodes can define input and output parameters, representing the preconditions and results of function execution, respectively. After building the device information model using the model building tool, you will get a model XML file to describe the content of the model. By manipulating this file and then instantiating it on the server, you can obtain a device object instance.

[0033] The task program building tool is primarily used to generate task programs and configuration information tables that require manual definition. This tool can be a high-level language editor used to generate IT domain tasks, or it can be an OT domain task generated by a PLC. The configuration information table mainly describes which variables or methods in the task need to be mapped to nodes in the subsequent device model, and therefore requires manual definition. After the development of the aforementioned model XML file, task program, and configuration information table is completed, these files are distributed to the execution layer.

[0034] The execution layer mainly consists of a device model parser, a task program parser, a semantic matching parser, and a mapping executor. The device model parser processes the model XML file issued by the management layer, instantiating it into device object instances. It then performs semantic analysis on the model, extracting the handles of the nodes that need to be mapped. The task program parser extracts the function handles and variable handles from the task program based on the issued configuration information table, facilitating subsequent mapping with method nodes and variable nodes within the information model. The semantic matching parser analyzes the generated handle information to generate a mapping relationship table, which the mapping executor then uses to map and associate the information model instances with the task programs.

[0035] The following describes the implementation process of the system of the present invention using a robotic arm dynamic sorting industrial scenario as an example. This scenario mainly includes a robotic arm, an industrial camera, and a conveyor belt. The main workflow is as follows: the conveyor belt transports goods to the industrial camera's recognition area; the industrial camera identifies the type of goods and their coordinates; and the robotic arm moves to the designated position identified by the industrial camera to sort different types of goods into different areas. When the robotic arm sorts goods, considering that the goods themselves have a certain speed due to the conveyor belt and that the robotic arm needs time to move to the designated position, a position prediction module is required in this process. This module calculates the final coordinates based on the movement speed of the robotic arm, the movement speed of the goods, and the coordinates of the goods identified by the industrial camera, thereby improving the sorting accuracy. Since the prediction algorithm of the position prediction module can be continuously updated and optimized to maximize prediction accuracy, the task program of the prediction module is always in a state of continuous change and updating. To avoid affecting production efficiency, an information model can be constructed for the position prediction module, and the system for dynamically reconstructing the equipment information model and equipment tasks proposed in this embodiment can be used for dynamic updates.

[0036] like Figure 4 The diagram shows the constructed position prediction module information model. Position_Prediction is an object node representing the prediction module object, while Object_Position_X / Y / Z is a variable node representing the three-dimensional position coordinates of the goods on the conveyor belt currently identified by the industrial camera. Pick_Position_X / Y / Z represents the actual three-dimensional position coordinates picked up by the robotic arm after the current Object_Position_X / Y / Z three-dimensional position coordinates are predicted by the Prediction method node.

[0037] like Figure 5The image shows the pseudocode for the prediction module. This pseudocode defines the initial coordinates of the cargo identified by the industrial camera (object_position_X / Y / Z), the actual coordinates of the cargo when picked up by the robotic arm (pick_position_X / Y / Z), and the prediction algorithm function.

[0038] Based on the aforementioned information model XML file and task program code, the device model parser and task program parser analyze the handles in both respectively. After obtaining the handle information, the mapping relationship processor performs mapping and matching on the handle information to obtain a mapping relationship table. This mapping relationship table is then passed to the mapping executor, which uses a pointer mechanism to extract pointers to variables or methods in the task program and map them to the corresponding handles in the information model. Table 1 shows the mapping relationship table.

[0039] Table 1 Mapping Relationship Table

[0040] Traditional development methods require developers to instantiate the device information model, record the information of each node within the model, and then use the API within the UA stack to bind callback functions and data sources to each node. Any changes necessitate system downtime and repetition of these steps. However, the system proposed in this invention avoids these steps when the prediction algorithm is updated. It simply requires rebinding the prediction method node and the updated prediction function, significantly improving development and operational efficiency.

[0041] In addition to the IT domain tasks mentioned above, this system also adapts to OT domain tasks written in open-source PLCs such as Beremiz. This is because the working mechanism of PLCs such as Beremiz involves converting PLC programs written in five programming languages ​​into C language program files using the MATIEC compiler, and then linking them into dynamic link libraries using the GCC compiler. Therefore, by using the APIs of dynamic link libraries such as dlopen and dlsym in combination with pointer mechanisms, handles in the dynamic link libraries can be extracted and mapped to the device information model.

[0042] like Figure 6 The diagram shows the workflow of this system.

[0043] In summary, this embodiment provides a method and system for dynamically associating and reconstructing equipment information models and tasks. This system decouples the equipment information model from the equipment tasks and dynamically changes the mapping relationship between information model nodes and task program identifiers, thus dynamically reconstructing the association between task programs and the information model. Based on the system provided in this embodiment, users only need to focus on the development of equipment task programs without needing to worry about the coupling relationship between task programs and the equipment information model. The system can update the association relationship between equipment tasks and the model in real time, enabling tasks with changes in parameters or internal algorithms to quickly adapt to the existing system, thereby maintaining efficient system operation and effectively reducing the development cost of industrial control systems.

[0044] Furthermore, it should be noted that the present invention can be provided as a method, apparatus, or computer program product. Therefore, embodiments of the present invention can take the form of a completely or partially hardware embodiment, a completely or partially software embodiment, or an embodiment combining software and hardware aspects. Moreover, when implemented in software, embodiments of the present invention can take the form of a computer program product implemented on one or more computer-usable storage media containing computer-usable program code. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer program are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any usable medium accessible to a computer or a data storage device such as a server or data center containing one or more sets of usable media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive (SSD).

[0045] Embodiments of the present invention are described with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0046] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing terminal equipment to cause a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0047] It should also be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element. Furthermore, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. Additionally, the character " / " in this document generally indicates an "or" relationship between the preceding and following related objects, but it may also indicate an "and / or" relationship; please refer to the context for specific interpretation. "At least one" means one or more, and "more" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or multiple items. For example, at least one of a, b, or c can be expressed as: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0048] Furthermore, it is understood that in various embodiments of the present invention, the order of the above-mentioned process numbers does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0049] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0050] In the several embodiments provided by this invention, it should be understood that the disclosed devices, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of functional modules / units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the shown or discussed mutual couplings or direct couplings or communication connections may be through some interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms. Units described as separate components may or may not be physically separate, and components shown as units may or may not be physical units, i.e., they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs. Additionally, the functional units in the various embodiments of this invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

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

[0052] Finally, it should be noted that the above description is merely a preferred embodiment of the present invention. It should be pointed out that although preferred embodiments of the present invention have been described, those skilled in the art, once they understand the basic inventive concept of the present invention, can make several improvements and modifications without departing from the principles described herein. These improvements and modifications should also be considered within the scope of protection of the present invention. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present invention.

Claims

1. A system for dynamically associating and reconstructing equipment information models and tasks, characterized in that, The system comprises: a management layer, an execution layer, and a device layer; wherein... The management layer is responsible for building the equipment information model, generating equipment task programs and configuration information tables, and distributing the equipment information model, equipment task programs, and configuration information tables to the execution layer. The execution layer is responsible for receiving the device information model, the device task program, and the configuration information table, and for establishing a mapping relationship between the generated device task program and the device information model after the device task program is generated. The device layer is used to dynamically load and run the device information model and device task program based on the mapping relationship between the device task program and the device information model established by the execution layer.

2. The system for dynamically associating and reconstructing equipment information models and tasks as described in claim 1, characterized in that, The management layer includes equipment model building tools and task program building tools; The device model building tool is used to build the device information model organization structure according to the interfaces that the device needs to expose to the outside world, generate an XML file describing the device information model organization structure, and import the XML file describing the device information model organization structure into the execution layer; The task program construction tool is used to construct device task programs and configuration information tables, and import the device task programs and configuration information tables into the execution layer. The device task programs are divided into IT tasks and OT domain tasks, which are used to control industrial equipment using the device's industrial protocol stack. The configuration information table is used to describe which variables or methods in the task need to be mapped to the nodes in the device information model.

3. The system for dynamically associating and reconstructing equipment information models and tasks as described in claim 2, characterized in that, The configuration information table is determined manually.

4. The system for dynamically associating and reconstructing equipment information models and tasks as described in claim 2, characterized in that, The device information model uses various types of nodes as basic building blocks, including object nodes, variable nodes, and method nodes.

5. The system for dynamically associating and reconstructing equipment information models and tasks as described in claim 4, characterized in that, Object nodes are used to describe specific entities and functional units in a device or system.

6. The system for dynamically associating and reconstructing equipment information models and tasks as described in claim 4, characterized in that, Variable nodes are used to represent the inherent properties and real-time running status of an object.

7. The system for dynamically associating and reconstructing equipment information models and tasks as described in claim 4, characterized in that, Method nodes are used to define the executable behaviors and business functions of a device or system.

8. The system for dynamically associating and reconstructing equipment information models and tasks as described in claim 2, characterized in that, The execution layer includes a device model parser, a task program parser, a semantic matching parser, and a mapping executor; The device model parser is used to instantiate the XML file describing the organizational structure of the device information model issued by the management in the model address space, instantiate it into a device object instance, and perform semantic analysis on the instantiated model instance to extract the node handles that need to be mapped. The task program parser is used to perform semantic analysis on the identifiers in the device task program issued by the management layer, and extract the function handles and variable handles in the device task program according to the configuration information table issued by the management layer, so as to map them to the method nodes and variable nodes in the device information model later. The semantic matching parser is used to parse the internal logic of the device information model and the device task program based on the extraction results of the device model parser and the extraction results of the task program parser. It extracts the identifier name to be associated from the device task program and then matches it with the node in the device information model to finally form a mapping relationship table. The mapping executor is used to map and associate device information model instances and device task programs according to the mapping relationship table, thereby completing the binding of device information model instances and device task programs.

Images