An object model-based industrial device integration system

Abstract

The application relates to an industrial equipment integration system based on a physical model, comprising a management platform, an intelligent agent and a protocol connector warehouse. The intelligent agent comprises an intelligent agent development kit and a supplier business model; the protocol connector warehouse is used for storing a plurality of protocol connectors, and different protocol connectors support different industrial communication protocols. The application is a supplier-oriented pluggable intelligent agent framework, which takes the physical model as a standard of business semantics, provides a standardized intelligent agent development kit, and enables a supplier to standardize equipment access to a management platform and realize plug-and-play only by introducing the intelligent agent development kit and following a simple fill-in-the-blank development specification without understanding complex underlying communication protocols and platform interfacing details.

Description

Technical Field

[0001] This invention relates to the field of industrial Internet of Things (IoT) technology, and more specifically to an industrial equipment integration system based on object models. Background Technology

[0002] Traditional automotive assembly lines typically consist of multiple stations with fixed functions connected in series, such as vehicle positioning stations, tire assembly stations, glass installation stations, and testing stations. The equipment at each station (such as robots, programmable logic controllers (PLCs), radio frequency identification (RFID) / vision readers, tightening guns, etc.) is provided by different suppliers, and they usually employ heterogeneous control systems, heterogeneous communication protocols, and heterogeneous data formats.

[0003] The current mainstream approach to equipment integration involves one-to-one protocol adaptation and data exchange between Supervisory Control and Data Acquisition (SCADA) systems or Manufacturing Execution Systems (MES) deployed in the factory workshop and equipment at each site. This approach has the following problems: First, the system is highly coupled. Adding, removing, replacing, or upgrading any site equipment requires extensive modifications to the underlying drivers and business logic of SCADA / MES, necessitating a complete system redeployment. This results in high development and maintenance costs and poor system scalability.

[0004] Secondly, data and business logic are disconnected. The upper-level system needs a deep understanding of the physical characteristics, communication details, and business implications of each device to realize a complete business chain, making upper-level applications complex and unable to quickly respond to flexible needs such as production cycle adjustments and the introduction of new models.

[0005] Finally, there is a lack of a unified anomaly monitoring and self-healing mechanism. When equipment fails or reports abnormal events, manual troubleshooting is often required, resulting in slow response times and impacting overall production line efficiency and product quality. Summary of the Invention

[0006] To address at least one technical problem in the existing technology, the present invention adopts the following technical solution: An industrial equipment integration system based on an object model includes: a management platform, intelligent agents, and a protocol connector warehouse; Intelligent agents, including intelligent agent development toolkits and supplier business models; The protocol connector warehouse stores multiple protocol connectors, each supporting different industrial communication protocols. The intelligent agent development toolkit is used for: connecting to the management platform, receiving the target device connection configuration issued by the management platform, dynamically loading the target protocol connector in the protocol connector repository based on the target device connection configuration, and establishing a connection with the target device through the target protocol connector. The supplier business model is used to: map the data of the target device to the attribute values ​​defined in the target device's object model; report business events to the management platform based on the attribute values; map the service call instructions of the object model instance of the target device to the control instructions of the target device; and send the control instructions to the target device through the target protocol connector.

[0007] In some embodiments, the device model includes one or more of the following: Attributes are static or dynamic descriptions of the device's operating status. An event is a notification event generated by the device when a business action is completed or when the business status is abnormal. Services, the control capabilities that services provide to equipment; Configuration refers to the setting values ​​or ranges of values ​​for the device's operating parameters.

[0008] In some embodiments, the structured data format for device connectivity configuration includes one or more of the following: The protocol field describes the device's industrial communication protocol. A parameter object is used to describe the device's connection parameters, which include one or more of the following: network address parameters, communication port parameters, and device identification parameters.

[0009] In some embodiments, the supplier business model includes one or more of the following: The attribute reading method is used to map device data to attribute values ​​defined in the device object model. Event triggering methods are used to define the conditions for triggering business events and the logic for encapsulating business event data. Service methods are used to map service call instructions from a device object model to control instructions for the device.

[0010] In some embodiments, the management platform is also used to: send business events to the purchasing party's manufacturing execution system, receive service call instructions initiated by the manufacturing execution system based on business events, send the service call instructions to the agent development kit, and receive the execution results of the service call instructions from the agent development kit.

[0011] In some embodiments, the management platform provides a graphical interface for displaying the operating status information of the intelligent agent and device data. The agent development kit is also used to report the agent's operational status information and device data to the management platform through a standard data channel.

[0012] In some embodiments, the agent development kit is also used to synchronize vendor-defined device models to the management platform.

[0013] In some embodiments, the agent development toolkit includes: The platform connection module is used to establish a message communication connection with the management platform; The configuration management module is used to subscribe to device-specific topics from the management platform and receive target device connection configurations from the management platform. The connection building engine is used to parse the target device connection configuration, dynamically load the target protocol connector from the protocol connector repository based on the target device connection configuration, and establish a connection with the target device through the target protocol connector.

[0014] In some embodiments, the connection to the build engine is specifically used for: The system parses the structured data format of the target device's connection configuration, determines the protocol type based on the protocol field value in the structured data format, searches for and loads the target protocol connector corresponding to the protocol type from the local protocol connector repository, and if the target protocol connector does not exist in the local protocol connector repository, it downloads and loads the target protocol connector from the remote protocol connector repository. Finally, it initializes the communication connection between the target protocol connector and the target device based on the connection parameters in the parameter object in the structured data format.

[0015] In some embodiments, the agent development toolkit further includes: The object model lifecycle management module is used to provide suppliers with the basic classes for object model definition, synchronize the device object models defined by suppliers to the management platform, and manage the creation and destruction of object model instances of devices.

[0016] In some embodiments, the agent development toolkit further includes: The data bus module provides a first standard interface for device model reporting, a second standard interface for business event reporting, and a third standard interface for service calls.

[0017] In some embodiments, the first standard interface is used to report the attribute names and attribute values ​​of the device object model; The second standard interface is used to report the name and data of business events; The third standard interface is used to receive service call instructions and route them to the service methods implemented in the vendor's business model. The service methods are used to map the service call instructions to the control instructions of the target device.

[0018] The beneficial effects of this invention are: This invention is a pluggable intelligent agent framework for equipment vendors. This framework uses the object model as the standard for business semantics and provides a lightweight, standardized intelligent agent development toolkit. This enables vendors to support the object model on their devices at a lower cost and in a unified manner, achieving plug-and-play functionality. Vendors do not need to understand complex underlying communication protocols and platform integration details; they only need to introduce the intelligent agent development toolkit and follow simple fill-in-the-blank development specifications to quickly and standardizedly connect their devices to a unified management platform. This solves the problem in traditional solutions where each vendor needs to perform repetitive, customized adaptations for the same platform. Attached Figure Description

[0019] Figure 1 A schematic diagram of an industrial equipment integration system based on a material model provided by the present invention; Figure 2 A schematic diagram of a supplier development process provided by the present invention; Figure 3 This is a schematic diagram of the working timing of an industrial equipment integration system based on a material model, provided by the present invention. Detailed Implementation

[0020] The embodiments of the present invention will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be understood that the preferred embodiments are only for illustrating the present invention and not for limiting the scope of protection of the present invention.

[0021] In this article, the term "and / or" describes the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship.

[0022] It should be noted that in this article, relational terms such as “first” and “second” are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations.

[0023] To address the challenges of device integration, the Industrial Internet of Things (IIoT) has introduced the concept of "object model." An object model is a digital and standardized description of a physical device in the digital space, defining the device's attributes, services (callable commands), and events.

[0024] For automotive manufacturing scenarios, externally defined generic object model platforms have the following problems: 1. The driving logic of events and instructions is deeply bound to the manufacturing business process (such as vehicle queue, site process, quality traceability), and it is difficult for general platforms to directly express how business events trigger a series of specific site services (such as "issuing tire assembly instructions").

[0025] 2. There are extremely high requirements for the real-time nature of instruction issuance, the certainty of success or failure feedback, and the real-time monitoring and automatic handling of abnormal states. A monitoring and alarm mechanism that is deeply integrated into the manufacturing process is needed.

[0026] 3. Due to differences in protocols or parameters, equipment from different suppliers cannot be scaled up in batches, requiring customized development or requiring suppliers to perform customized development.

[0027] The core idea of ​​this invention is a pluggable agent framework for equipment suppliers. This framework uses the object model as the standard for business semantics and provides a lightweight, standardized agent development toolkit (Agent SDK). This enables suppliers to make their devices support the object model at a lower cost and in a unified manner, achieving plug-and-play functionality. Therefore, this invention achieves a shift from "centralized platforms adapting to everything" to "empowering everything to proactively adapt to the central platform," transferring complexity from the supplier side to within the agent framework. This solves the "last mile" problem of industrial equipment access on a large scale, providing a foundation for building an open and flexible industrial IoT ecosystem.

[0028] Figure 1 A schematic diagram of an industrial equipment integration system based on a material model is provided for this invention, as shown below. Figure 1 As shown, the industrial equipment integration system includes: a management platform 11, an intelligent agent 12, and a protocol connector repository 13.

[0029] Management platform 11, deployed in the cloud, manages device object models and device connection configurations. The device object model is used to create object model instances for corresponding devices during runtime. The device object model defines an abstract template of a type of device capability (e.g., defining the attributes, events, services, and configurations of a certain type of device). An object model instance is a digital object of a specific device at runtime, a concretization of the device object model definition (e.g., assigning dynamic runtime values ​​to the attributes defined in the device object model). For example, when a specific device comes online, management platform 11 creates an object model instance based on its corresponding device object model to track the device's real-time status, routing events, and commands. The instance is destroyed when the device goes offline.

[0030] A device object model includes one or more of the following: attributes, events, services, and configurations.

[0031] Attributes are static or dynamic descriptions of the equipment's operating status, representing observable data of the equipment at a certain moment. Taking a tightening gun as an example, attributes include: torque value, angle value, equipment operating status, etc.

[0032] Events are notification events generated by the equipment when a business action is completed or when a business status is abnormal. Taking a tightening gun as an example, events include: equipment ready, tightening process completed, and torque over-limit anomaly. Accordingly, the event data corresponding to equipment ready includes: equipment ID and equipment ready event. The event data corresponding to tightening process completed includes: torque value, angle value, and tightening result. The event data corresponding to torque over-limit anomaly includes: current torque value and torque over-limit anomaly code.

[0033] Services provide control capabilities to equipment, which are equipment control capabilities that upper-level systems (such as Manufacturing Execution System, MES) can actively invoke. Taking a tightening gun as an example, services include: starting tightening, stopping tightening, etc.

[0034] This configuration describes the settings or ranges of operating parameters for the device, used to constrain the device's operating boundaries. Taking a tightening gun as an example, the configuration includes: torque threshold range, angle threshold range, etc.

[0035] In Management Platform 11, the device connection profile is created by the factory engineer. The structured data format of the connection profile includes one or more of the following: a protocol field and a params object. The protocol field describes the device's industrial communication protocol; the params object describes the device's connection parameters, which include one or more of the following: network address parameters, communication port parameters, and device identifier parameters. For example, a connection profile in JSON format might look like this: {"protocol": "modbus-tcp", "params": {"host": "127.0.0.1", "port": 502}}, indicating that the communication protocol is Modbus overtransmission control protocol (modbus-tcp), the network address is "127.0.0.1", and the communication port is 502.

[0036] Figure 1The protocol connector repository 13 shown is used to store multiple protocol connectors, with different protocol connectors supporting different industrial communication protocols. In this embodiment, a plug-in design is adopted for the protocol connectors. For example, the communication details of various industrial communication protocols are abstracted into independent "protocol connectors" and stored in the protocol connector repository 13, achieving complete decoupling between business logic and communication protocols, so that suppliers do not need to care about the underlying communication details. In some embodiments, the protocol connectors are stored in the form of dynamic libraries in a local protocol connector repository or a remote protocol connector repository.

[0037] Figure 1 The intelligent agent 12 shown is deployed at the device edge (as opposed to the cloud, it is the field end in the industrial IoT architecture). The device edge includes, for example, an industrial control computer, an edge gateway, or an edge server. In this embodiment, the intelligent agent 12 includes an intelligent agent development toolkit (Agent SDK) 1201 and a supplier business model 1202.

[0038] The Agent SDK1201 is used for: connecting to the management platform 11, receiving target device connection configurations issued by the management platform 11, dynamically loading target protocol connectors from the protocol connector repository 13 based on the target device connection configurations, and establishing connections with target devices through the target protocol connectors. As can be seen, the Agent SDK can drive device connection establishment through device connection configurations. Factory engineers only need to complete the device connection configurations without needing to understand the complex underlying communication protocols and platform interface details, achieving "configuration equals connection" and simplifying on-site device deployment.

[0039] Among them, the supplier business model 1202 is used to: map the data of the target device to the attribute values ​​defined by the target device object model, report business events to the management platform 11 based on the attribute values, map the service call instructions of the object model instance of the target device to the control instructions of the target device, and send the control instructions to the target device through the target protocol connector.

[0040] In some embodiments, Figure 1 The supplier business model 1202 includes one or more of the following: attribute reading methods, event triggering methods, and service methods. The attribute reading method maps device data to attribute values ​​defined in the device object model. The event triggering method defines the business event triggering conditions and business event data encapsulation logic. The service method maps service call instructions from the device object model to device control instructions.

[0041] As can be seen, suppliers do not need to understand the complex underlying communication protocols and platform interface details. They only need to introduce the Agent SDK 1201 and follow the simple business model fill-in-the-blank development specification. They can focus on the abstraction of the business functions of the device. By inheriting the base class and implementing the mapping method of device data (i.e., attribute reading method) and the mapping method of device control instructions (i.e., service method), they can quickly complete the construction of the business model. This transforms the supplier's work from complex system integration to business function implementation.

[0042] In some embodiments, Figure 1 The management platform 11 is also used for: sending business events to the purchasing party's Manufacturing Execution System (MES), receiving service call instructions initiated by the MES based on business events, issuing service call instructions to the Agent SDK 1201, and receiving the execution results of the service call instructions fed back by the Agent SDK 1201. It can be seen that the management platform 11's actions of sending business events to the MES, receiving service call instructions initiated by the MES, issuing service call instructions to the Agent SDK 1201, and receiving the execution results of the service call instructions fed back by the Agent SDK 1201 together constitute an event-driven bidirectional instruction control closed loop. That is, equipment business events drive the MES to make business decisions, the MES business decisions are transformed into equipment control instructions, and the execution results of the control instructions are fed back to the management platform 11, forming a complete closed loop of "event triggering → instruction issuance → execution feedback". Compared with the traditional MES polling method, the event-driven architecture of this invention shortens the exception response time and realizes real-time bidirectional closed-loop control of control instruction issuance and execution status feedback.

[0043] In some embodiments, Figure 1 The management platform 11 provides a graphical interface for displaying the operational status information and device data of the agent 12. The Agent SDK 1201 is also used to report the operational status information and device data of the agent 12 to the management platform 11 via a standard data channel. Therefore, in this embodiment, the operational status and device data of the agent 12 are displayed on the graphical interface of the management platform 11, achieving end-to-end observability and facilitating simplified development, debugging, and maintenance troubleshooting processes through graphical debugging and monitoring.

[0044] In some embodiments, Figure 1The Agent SDK 1201 is also used to synchronize the device object model defined by the supplier to the management platform 11. In this embodiment, the Agent SDK 1201 encapsulates common capabilities such as communication capabilities with the management platform 11 and device connection construction capabilities, and exposes a simple programming interface to the supplier, enabling the supplier to define the device object model and develop the business model.

[0045] In some embodiments, Figure 1 The Agent SDK 1201 includes: a platform connection module, a configuration management module, a connection building engine, an object model lifecycle management module, and a data bus module.

[0046] The platform connection module is used to establish message communication connections with the management platform 11, such as establishing a Message Queuing Telemetry Transport (MQTT) connection. The platform connection module is responsible for establishing and maintaining the network communication connection between the agent 12 and the management platform 11. For example, after the agent 12 starts up, the platform connection module automatically establishes a connection with the management platform 11 via the MQTT protocol. In addition, after establishing a connection with the management platform 11, the platform connection module can also receive device connection configurations issued by the management platform and receive service call commands. Furthermore, the platform connection module can also be responsible for the heartbeat keep-alive mechanism of the connection, ensuring the continuous availability of the communication link.

[0047] The configuration management module is used to subscribe to device-specific topics from the management platform 11 and receive target device connection profiles issued by the management platform 11. For example, the configuration management module receives target device connection profiles issued by the management platform 11 through the platform connection module. In addition, the configuration management module can also store and manage currently effective device connection configurations, and supports triggering the re-establishment of device connections when device connection configurations are updated.

[0048] The connection building engine parses the target device's connection profile, dynamically loads the target protocol connector from the protocol connector repository 13 based on the connection profile, and establishes a connection with the target device through the target protocol connector. The connection building engine is responsible for dynamically establishing industrial communication connections with physical devices based on the target device's connection profile, and is the core engine for realizing "configuration as connection". For example, the connection building engine can parse the protocol field value of the connection profile, determine the type of protocol connector to be loaded, and dynamically load the target protocol connector from the protocol connector repository 13 based on the protocol connector type, thereby establishing a connection with the target device through the target protocol connector.

[0049] The device model lifecycle management module provides suppliers with basic classes for device model definitions, synchronizes supplier-defined device models to the management platform 11, and manages the creation and destruction of device model instances. This module is responsible for the complete lifecycle management of device models from definition to runtime instance, serving as core support for supplier-based fill-in-the-blank development. For example, it provides suppliers with basic classes for device model definitions, allowing them to define device models (including attributes, events, services, and configurations) by inheriting from these classes. In this embodiment, suppliers can define device models using annotations or configuration files. Furthermore, the module can automatically synchronize device models defined by suppliers in business classes to the management platform 11, eliminating the need for suppliers to manually call the platform's Application Programming Interface (API). Additionally, when a device goes online, the module creates a corresponding device model instance (runtime digitized object) on the management platform 11 based on the device model; when the device goes offline, it destroys the corresponding device model instance, releasing resources on the management platform 11.

[0050] The data bus module provides a standard Application Programming Interface (API), including: a first standard interface for reporting device object models, a second standard interface for reporting business events, and a third standard interface for service calls. The first standard interface reports the attribute names and values ​​of the device object models. The second standard interface reports the names and data of business events. The third standard interface receives service call instructions and routes them to the service methods implemented in the supplier business model 1202. The service methods map the service call instructions to control instructions for the target device. Therefore, the data bus module is responsible for bidirectional data flow between the supplier business model 1202 and the management platform 11, serving as a unified channel for both device data uplink and instruction downlink.

[0051] For example, the first standard interface for reporting by the device object model is: reportProperty(propertyName, value), where propertyName is the property name of the device object model, and value is the property value of the device object model. When the device property value changes, the device property change can be reported through the first standard interface. The first standard interface reports the device property name and property value to the management platform 11, and is invoked when the property value changes.

[0052] For example, the second standard interface for reporting business events is: `triggerEvent(eventName, payload)`, where `eventName` is the name of the business event, and `payload` is the data of the business event. This second standard interface reports the business event to the management platform 11, carrying the event name and event data.

[0053] For example, the third standard interface for service invocation is the onServiceCall interface, which is used to receive service invocation instructions and route them to the service methods implemented in the vendor business model 1202. The third standard interface receives service invocation instructions issued by the management platform 11 and routes them to the service methods implemented in the vendor business model 1202 for execution.

[0054] In some embodiments, the connection to the build engine is specifically used for: The system parses the structured data format (JSON format) of the target device's connection profile, determines the protocol type based on the protocol field value in the structured data format, searches for and loads the target protocol connector corresponding to the protocol type from the local protocol connector repository, and if the target protocol connector does not exist in the local protocol connector repository, it downloads and loads the target protocol connector from the remote protocol connector repository. The system initializes the communication connection between the target protocol connector and the target device based on the connection parameters (such as network address parameters, communication port parameters, device identifier parameters, etc.) in the parameter (params) object in the structured data format.

[0055] For example, the structured data format of the device connection profile is JSON: {"protocol": "modbus-tcp", "params": {"host": "127.0.0.1", "port": 502}}, indicating that the communication protocol is Modbus over transmission control protocol (modbus-tcp), the network address is "127.0.0.1", and the communication port is 502. The connection building engine initializes the communication connection between the target protocol connector and the target device based on these parameters.

[0056] Figure 2 A schematic diagram of a supplier development process provided by the present invention, such as Figure 2 As shown, the supplier development process includes the following steps 21 to 24: 21. The supplier creates a project and imports the Agent SDK dependency. 22. The supplier declares the required protocol connectors. 23. The supplier develops the business model (including: creating a business class that inherits from the base class provided by the Agent SDK, defining the unique identifier, attribute list, event list, and service list of the device object model, implementing attribute reading methods, event triggering methods, and service methods in the business class, and registering the business class with the Agent SDK's module builder, thereby completing the business model construction). 24. The supplier packages the developed business model and Agent SDK into an agent and deploys it to the device edge.

[0057] Figure 3 A timing diagram illustrating the operation of an industrial equipment integration system based on a material model, as provided by this invention, is shown below. Figure 3 As shown, the working sequence is described as follows: Steps 1 to 25: 1. Factory engineers create device instances and configure connection parameters on the management platform.

[0058] The structured data format of a device connection profile includes one or more of the following: a protocol field and a params object. The protocol field describes the device's industrial communication protocol; the params object describes the device's connection parameters, which include one or more of the following: network address parameters, communication port parameters, and device identifier parameters. For example, a structured data format for a connection profile in JSON format: {"protocol": "modbus-tcp", "params": {"host": "127.0.0.1", "port": 502}}, indicates that the communication protocol is the Modbus overtransmission control protocol (modbus-tcp), the network address is "127.0.0.1", and the communication port is 502.

[0059] 2. The management platform sends the device connection configuration (Connection Profile) to the agent.

[0060] Intelligent agents are deployed at the edge of the device (as opposed to the cloud, they are the field end in the industrial IoT architecture). Examples of devices at the edge include industrial control computers, edge gateways, and edge servers.

[0061] The intelligent agent includes the Agent SDK and the supplier's business model. The Agent SDK receives the device connection configuration (Connection Profile) issued by the management platform.

[0062] 3. The agent parses the structured data format of the Connection Profile, determines the protocol type based on the protocol field value in the structured data format, and dynamically loads the protocol connector corresponding to the protocol type.

[0063] The Agent SDK in the intelligent agent parses the structured data format of the Connection Profile, determines the protocol type based on the protocol field value in the structured data format, and dynamically loads the protocol connector corresponding to the protocol type.

[0064] 4. The intelligent agent establishes a connection with the physical device through the protocol connector.

[0065] The Agent SDK in the intelligent agent establishes a connection with the physical device through a protocol connector. It is evident that the Agent SDK can drive device connection establishment through device connection configuration. Factory engineers only need to complete the device connection configuration, without needing to understand the complex underlying communication protocols and platform interface details, achieving "configuration equals connection" and simplifying on-site device deployment.

[0066] 5. The physical device returns a connection confirmation to the protocol connector.

[0067] 6. The protocol connector returns the connection status to the smart agent.

[0068] 7. The intelligent agent reports the online status of the device to the management platform.

[0069] 8. The management platform sends equipment online notifications to the factory engineers.

[0070] 9 to 14 represent the loop process of periodic data acquisition: The protocol connector reads device data; the physical device returns raw data to the protocol connector; the protocol connector triggers a data arrival callback to the intelligent agent; the intelligent agent parses and transforms the data to obtain device attribute values; the intelligent agent reports the attribute values ​​to the management platform; the management platform forwards the attribute data to the Manufacturing Execution System (MES system).

[0071] 15. The factory engineer creates a production order in the MES system, triggering the tightening service.

[0072] 16. The MES system sends service call instructions to the management platform.

[0073] 17. The management platform forwards service call instructions to the intelligent agent.

[0074] 18. The intelligent agent parses and converts the instructions to obtain the control commands for the physical devices.

[0075] 19. The intelligent agent sends control commands to the protocol connector.

[0076] 20. The protocol connector sends control commands to the physical device to execute device control.

[0077] 21. The physical device returns the execution result to the protocol connector.

[0078] 22. The protocol connector returns the execution status to the agent.

[0079] 23. The intelligent agent reports the service execution results to the management platform.

[0080] 24. The management platform forwards the service execution results to the MES system.

[0081] 25. The MES system displays the execution completion status to the factory engineers.

[0082] As can be seen, this invention realizes the transformation from "centralized platform adapting to everything" to "empowering everything to actively adapt to the central platform", shifting the complexity from the supplier side to the Agent framework, thereby solving the "last mile" problem of industrial equipment access on a large scale and providing a foundation for building an open and flexible industrial Internet of Things ecosystem.

[0083] The above embodiments are merely preferred embodiments provided to fully illustrate the present invention, and the scope of protection of the present invention is not limited thereto. Equivalent substitutions or modifications made by those skilled in the art based on the present invention are all within the scope of protection of the present invention.

Claims

1. An industrial equipment integration system based on a physical model, characterized in that, The industrial equipment integration system includes: a management platform, intelligent agents, and a protocol connector repository; The intelligent agent includes an intelligent agent development toolkit and a supplier business model; The protocol connector warehouse is used to store multiple protocol connectors, and different protocol connectors support different industrial communication protocols; The intelligent agent development toolkit is used for: connecting to the management platform, receiving target device connection configurations issued by the management platform, dynamically loading target protocol connectors from the protocol connector repository based on the target device connection configurations, and establishing connections with target devices through the target protocol connectors; The supplier business model is used to: map the data of the target device to the attribute values ​​defined in the target device object model; report business events to the management platform based on the attribute values; map the service call instructions of the object model instance of the target device to the control instructions of the target device; and send the control instructions to the target device through the target protocol connector.

2. The system according to claim 1, characterized in that, The device model includes one or more of the following: Attributes, which are static or dynamic descriptions of the device's operating status; The event is a notification event generated by the device when a business action is completed or when the business status is abnormal; Services, which are the control capabilities provided by the device; Configuration, which refers to the description of the setting values ​​or value ranges of the device's operating parameters.

3. The system according to claim 1, characterized in that, The structured data format of the device connection configuration includes one or more of the following: Protocol field, which describes the industrial communication protocol of the device; A parameter object, which describes the device's connection parameters, wherein the connection parameters include one or more of the following: network address parameters, communication port parameters, and device identifier parameters.

4. The system according to claim 1, characterized in that, The supplier business model includes one or more of the following: An attribute reading method, wherein the attribute reading method is used to map the data of the device to attribute values ​​defined by the device object model; The event triggering method is used to define the business event triggering conditions and the business event data encapsulation logic; A service method is provided for mapping service call instructions of a device object model to control instructions of the device.

5. The system according to claim 1, characterized in that, The management platform is also used to: send the business event to the purchasing party's manufacturing execution system, receive the service call instruction initiated by the manufacturing execution system based on the business event, send the service call instruction to the agent development kit, and receive the execution result of the service call instruction fed back by the agent development kit.

6. The system according to claim 1, characterized in that, The management platform provides a graphical interface, which is used to display the operating status information and device data of the intelligent agent. The intelligent agent development toolkit is also used to report the operating status information of the intelligent agent and the device data to the management platform through a standard data channel.

7. The system according to claim 1, characterized in that, The intelligent agent development toolkit is also used to synchronize the device object model defined by the supplier to the management platform.

8. The system according to claim 1, characterized in that, The intelligent agent development toolkit includes: The platform connection module is used to establish a message communication connection with the management platform; The configuration management module is used to subscribe to device-specific topics from the management platform and receive target device connection configurations issued by the management platform. A connection building engine is used to parse the connection configuration of the target device, dynamically load the target protocol connector in the protocol connector repository based on the connection configuration of the target device, and establish a connection with the target device through the target protocol connector.

9. The system according to claim 8, characterized in that, The connection building engine is specifically used for: The structured data format of the target device connection configuration is parsed, the protocol type is determined according to the protocol field value in the structured data format, the target protocol connector corresponding to the protocol type is searched and loaded from the local protocol connector repository, if the target protocol connector does not exist in the local protocol connector repository, the target protocol connector is downloaded from the remote protocol connector repository and loaded, and the communication connection between the target protocol connector and the target device is initialized according to the connection parameters in the parameter object in the structured data format.

10. The system according to claim 8, characterized in that, The intelligent agent development toolkit also includes: The object model lifecycle management module is used to provide suppliers with basic classes for object model definition, synchronize the device object models defined by suppliers to the management platform, and manage the creation and destruction of object model instances of devices.

11. The system according to claim 8, characterized in that, The intelligent agent development toolkit also includes: The data bus module provides a first standard interface for device model reporting, a second standard interface for business event reporting, and a third standard interface for service calls.

12. The system according to claim 11, characterized in that, The first standard interface is used to report the attribute names and attribute values ​​of the device object model; The second standard interface is used to report the name and data of the business event; The third standard interface is used to receive service call instructions and route them to the service methods implemented in the supplier's business model, wherein the service methods are used to map the service call instructions to control instructions for the target device.

Images