Device management method, system and device, and electronic device

Abstract

The application discloses a device management method, system and device, and an electronic device. The method comprises the following steps: receiving a first data packet sent by a distributed control system (DCS) device management module, wherein the DCS device management module is deployed in a first operation environment and is used for collecting running state data of a DCS device; receiving a second data packet sent by a universal control system (UCS) device management module, wherein the UCS device management module is deployed in a second operation environment and is used for collecting running state data of a UCS device; analyzing and processing the first data packet and the second data packet by using a unified device management model, and generating corresponding control instructions; and performing device management according to the control instructions. The application solves the technical problems of data islands and different management standards caused by the independent deployment of DCS and UCS systems in a single environment.

Description

Technical Field

[0001] This application relates to the field of industrial automation control, and more specifically, to a method, system, device, and electronic equipment for equipment management. Background Technology

[0002] In industrial production processes, Distributed Control Systems (DCS) and Universal Control Systems (UCS) are two core types of control systems, widely used in process manufacturing industries such as chemical, oil refining, and power generation. DCS is typically based on a traditional architecture, generally compatible with desktop operating systems such as Windows, and is primarily used for closed-loop control of complex processes, characterized by high stability and strong real-time performance. UCS, on the other hand, is based on a minimalist "cloud-network-device" architecture, usually deployed in a dedicated private cloud environment, and is mainly used for flexible management and rapid iteration in general scenarios.

[0003] However, intelligent device management solutions in related technologies are typically designed only for a single type of control system (such as DCS or UCS), failing to consider the actual scenarios in industrial settings where DCS and UCS systems coexist and their deployment environments differ significantly. These technologies lack both a modular deployment architecture for DCS adapted to Windows environments and UCS adapted to dedicated environments, and a unified device management logic for different deployment environments. This significantly increases development and maintenance costs, and easily creates data silos, resulting in inconsistent device management standards and data incompatibility between DCS and UCS systems. This impacts device management efficiency and fails to address the technical challenges of independent deployment environments for DCS and UCS systems and the need for device management to adapt to different environments.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This application provides a device management method, system, apparatus, and electronic device to at least solve the technical problem that related technologies can only achieve device management in a single environment, making it difficult to solve the data silos and inconsistent management standards caused by the independent deployment environments of DCS and UCS systems.

[0006] According to one aspect of the embodiments of this application, a device management and control method is provided, comprising: receiving a first data packet sent by a distributed control system (DCS) device management and control module, wherein the DCS device management and control module is deployed in a first operating environment and is used to collect operating status data of the device to be managed, which is a DCS control system; receiving a second data packet sent by a general control system (UCS) device management and control module, wherein the UCS device management and control module is deployed in a second operating environment and is used to collect operating status data of the device to be managed, which is a UCS control system; analyzing and processing the first data packet and the second data packet using a unified device management and control model to generate corresponding control instructions; and executing device management and control according to the control instructions.

[0007] Optionally, the method further includes: detecting the control system type of the device to be managed; if the control system type of the device to be managed is DCS, initializing the DCS device management module deployed in the first operating environment, loading the first driver interface adapted to the DCS communication protocol, and performing device binding; if the control system type of the device to be managed is UCS, initializing the UCS device management module deployed in the second operating environment, loading the second driver interface adapted to the UCS network architecture, and performing device binding.

[0008] Optionally, the first data packet includes: a first status parameter, a first type label, and a first timestamp, wherein the first status parameter is the operating status data of the first device collected by the DCS device management module in a first data format, the first type label is used to indicate the control system type of the first device, the first timestamp is the timestamp of the first status parameter collection, and the first device is a device to be managed with a control system type of DCS; the second data packet includes: a second status parameter, a second type label, and a second timestamp, wherein the second status parameter is the operating status data of the second device collected by the UCS device management module in a second data format, the second type label is used to indicate the control system type of the second device, the second timestamp is the timestamp of the second status parameter collection, and the second device is a device to be managed with a control system type of UCS.

[0009] Optionally, the method further includes: based on the first type label, calling a preset protocol parsing library to convert the first state parameter into first standard data with a preset data structure; based on the second type label, calling a protocol parsing library to convert the second state parameter into second standard data with a preset data structure; and inputting the first standard data and the second standard data into the device control model.

[0010] Optionally, a unified equipment management and control model is used to analyze and process the first data packet and the second data packet, including: identifying first type parameters and second type parameters belonging to the same physical quantity type in the first standard data and the second standard data, mapping the first type parameters and the second type parameters to a unified monitoring view and uploading them to the central management and control module for visualization; and / or extracting first alarm event information and second alarm event information from the first standard data and the second standard data respectively, fusing the first alarm event information and the second alarm event information based on a unified fault analysis logic and performing fault analysis to obtain fault analysis results; and / or generating first control commands and second control commands corresponding to the first standard data and the second standard data respectively based on a unified control strategy.

[0011] Optionally, the device management and control is performed according to the control command, including: sending a first control command to the DCS device management and control module, and receiving a first feedback result returned by the DCS device management and control module after performing management and control on the first device according to the first control command, wherein the first feedback result includes at least the execution status of the first control command and the operating status of the first device; sending a second control command to the UCS device management and control module, and receiving a second feedback result returned by the UCS device management and control module after performing management and control on the second device according to the second control command, wherein the second feedback result includes at least the execution status of the second control command and the operating status of the second device.

[0012] Optionally, the method further includes: obtaining a unified report template and a unified interface template, wherein the unified report template is used to define standardized data statistical fields covering all DCS and UCS equipment in the plant, and the unified interface template is used to define a standardized monitoring view layout covering all DCS and UCS equipment in the plant; mapping the first standard data, the second standard data, the fault analysis results, the first feedback results, and the second feedback results to the standardized fields of the unified report template and the unified interface template respectively, and rendering and generating a comprehensive equipment management and control report and an equipment visualization monitoring interface.

[0013] According to another aspect of the embodiments of this application, an equipment management system is also provided, including: a DCS equipment management module, a UCS equipment management module, and a unified equipment management module, wherein the DCS equipment management module is deployed in a first operating environment and is used to collect operating status data of the equipment to be managed whose control system type is DCS; the UCS equipment management module is deployed in a second operating environment and is used to collect operating status data of the equipment to be managed whose control system type is UCS; and the unified equipment management module is used to execute the equipment management method implementing any one of claims 1 to 7.

[0014] According to another aspect of the embodiments of this application, a device management and control apparatus is also provided, comprising: a first receiving module, configured to receive a first data packet sent by a distributed control system (DCS) device management and control module, wherein the DCS device management and control module is deployed in a first operating environment and is used to collect operating status data of the device to be managed, which is a DCS control system; a second receiving module, configured to receive a second data packet sent by a general control system (UCS) device management and control module, wherein the UCS device management and control module is deployed in a second operating environment and is used to collect operating status data of the device to be managed, which is a UCS control system; a processing module, configured to analyze and process the first data packet and the second data packet using a unified device management and control model to generate corresponding control instructions; and a management and control module, configured to execute device management and control according to the control instructions.

[0015] According to another aspect of the embodiments of this application, an electronic device is also provided, including: a memory and a processor, wherein the memory is used to store program instructions; and the processor is connected to the memory and used to execute the above-described device control method.

[0016] According to another aspect of the embodiments of this application, a non-volatile storage medium is also provided, the non-volatile storage medium including a stored computer program, wherein the device where the non-volatile storage medium is located executes the above-mentioned device control method by running the computer program.

[0017] According to another aspect of the embodiments of this application, a computer program product is also provided, including computer instructions, which, when executed by a processor, implement the above-described device control method.

[0018] In this embodiment, a first data packet is received from a DCS (Distributed Control System) device management module, which is deployed in a first operating environment and is used to collect operational status data of the device to be managed, which is a DCS-type control system. A second data packet is received from a UCS (Universal Control System) device management module, which is deployed in a second operating environment and is used to collect operational status data of the device to be managed, which is a UCS-type control system. A unified device management model is used to analyze and process the first and second data packets to generate corresponding control commands. Device management is executed according to the control commands, achieving the goal of unified access and collaborative control of multi-source heterogeneous device data. This eliminates the barriers between DCS and UCS systems and improves the standardized management efficiency of intelligent devices in various deployment environments. It also solves the technical problem that related technologies can only achieve device management in a single environment and cannot solve the data silos and inconsistent management standards caused by the independent deployment environments of DCS and UCS systems. Attached Figure Description

[0019] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0020] Figure 1 This is a hardware structure diagram of a computer terminal for implementing a device control method according to an embodiment of this application;

[0021] Figure 2 This is a flowchart of a device control method according to an embodiment of this application;

[0022] Figure 3 This is a complete flowchart illustrating a device control method according to an embodiment of this application;

[0023] Figure 4 This is a structural diagram of a device control system according to an embodiment of this application;

[0024] Figure 5 This is a structural diagram of an equipment control device according to an embodiment of this application. Detailed Implementation

[0025] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0026] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0027] First, some nouns or terms that appear in the explanation of the embodiments of this application shall be interpreted as follows:

[0028] DCS (Distributed Control System): A computer system specifically designed for industrial process control. Its core features are "distributed control, centralized operation, hierarchical management, flexible configuration, and convenient setup." In this application, it specifically refers to traditional control systems typically deployed in a Windows environment for handling closed-loop control in complex process industries such as chemical and oil refining.

[0029] UCS (Universal Control System): A new type of control system based on modern software-defined and cloud-native architectures. In this application, it specifically refers to a control system based on a minimalist "cloud-network-device" architecture, typically deployed in a dedicated private cloud environment. Unlike DCS, UCS emphasizes flexibility, scalability, and rapid iteration, making it suitable for flexible management and control in general scenarios. Its control logic often runs in the form of software services or containers.

[0030] Data silos refer to the phenomenon where data cannot flow and be shared freely between different systems or departments. In industrial settings, due to the independent deployment environments and different communication protocols of DCS and UCS systems, data from devices within the two systems often cannot be communicated, forming data silos. This application aims to break down this barrier through a unified management and control module, enabling data aggregation and sharing.

[0031] This application provides a device management method, which can be run in... Figure 1 The computer terminal shown is described below.

[0032] The device management method embodiments provided in this application can be executed on mobile terminals, computer terminals, or similar computing devices. Figure 1 A hardware structure block diagram of a computer terminal for implementing a device management method is shown. (For example...) Figure 1 As shown, the computer terminal 10 may include a processor 102, a memory 104 for storing data, and a transmission module 106 for communication functions. The processor 102 may include one or more processors. For ease of explanation, Figure 1 The diagram illustrates multiple processors, including processor 1 (102a), processor 2 (102b), ..., processor n (102n). Processor 102 may be a processing device including, but not limited to, a microcontroller unit (MCU) or a field-programmable gate array (FPGA).

[0033] In addition, a computer terminal may also include: a display, an input / output interface (I / O interface), a Universal Serial Bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0034] It should be noted that the aforementioned one or more processors and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10. As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0035] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the device control method in this embodiment. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby realizing the aforementioned device control method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0036] The transmission module 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission module 106 includes a network interface controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission module 106 may be a radio frequency (RF) module, used for data interaction with external networks or devices via wired and / or wireless network connections.

[0037] The display can be, for example, a touchscreen liquid crystal display (LCD), which allows the user to interact with the user interface of the computer terminal 10. In addition, the computer terminal 10 can also connect to a cursor control device and a keyboard via an input / output interface. The cursor control device (e.g., a mouse, trackball, or touchpad) is mainly used to transmit directional information and command selection to the terminal and control the movement of the cursor on the display; the keyboard is mainly used to receive letters, numbers, and other control commands input by the user, thereby enabling interaction between the user and the computer terminal 10.

[0038] It should be noted here that, in some optional embodiments, the above... Figure 1 The computer terminal shown may include hardware elements (including circuitry), software elements (including computer code stored on a computer-readable medium), or a combination of both hardware and software elements. It should be noted that... Figure 1 This is only one instance of a specific particular instance, and is intended to illustrate the types of components that may exist in the aforementioned computer terminal.

[0039] In the above operating environment, this application provides an embodiment of a device management method. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Also, although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than that shown here.

[0040] Figure 2 This is a flowchart of a device management method according to an embodiment of this application, such as... Figure 2 As shown, the method includes the following steps:

[0041] Step S202: Receive the first data packet sent by the DCS device management module of the distributed control system. The DCS device management module is deployed in the first operating environment and is used to collect the operating status data of the device to be managed by the DCS control system.

[0042] Step S204: Receive the second data packet sent by the Universal Control System (UCS) device management module. The UCS device management module is deployed in the second operating environment and is used to collect the operating status data of the device to be managed, which is a UCS control system.

[0043] Step S206: The first data packet and the second data packet are analyzed and processed using a unified device management and control model to generate corresponding control commands.

[0044] Step S208: Perform equipment management according to control instructions.

[0045] Through steps S202 to S208 above, the goal of unified access and collaborative control of multi-source heterogeneous device data is achieved. This eliminates barriers between DCS and UCS systems, improves the standardized management efficiency of intelligent devices in various deployment environments, and solves the technical problem of data silos and inconsistent management standards caused by the independent deployment environments of DCS and UCS systems, which can only achieve device management in a single environment. The following is a detailed explanation.

[0046] In this embodiment of the application, step 200 is also included, which is used to realize environmental perception and module adaptation deployment.

[0047] Optionally, the environmental perception and module adaptation deployment steps involve identifying the type of existing control systems in the industrial site and the differentiated deployment strategy of the corresponding management modules to ensure accurate access of devices in heterogeneous environments. This includes: detecting the control system type of the device to be managed; if the control system type of the device to be managed is DCS, initializing the DCS device management module deployed in the first operating environment, loading the first driver interface adapted to the DCS communication protocol, and performing device binding; if the control system type of the device to be managed is UCS, initializing the UCS device management module deployed in the second operating environment, loading the second driver interface adapted to the UCS network architecture, and performing device binding.

[0048] Specifically, the first step is to perform environmental perception by reading device configuration information or network broadcast protocols to detect the type of control system to which the device to be managed belongs.

[0049] When the detection results indicate that the device to be managed belongs to the DCS, the initialization process of the DCS device management module is triggered. This DCS device management module is deployed in the first operating environment (Windows operating environment). During initialization, it loads the first driver interface adapted to the DCS communication protocol (such as traditional industrial control protocol drivers like OPC UA and Modbus TCP). After loading, it performs device discovery and binding operations, scans the DCS controllers in the Windows environment, identifies and establishes communication connections with the field intelligent devices, thereby completing the device access on the DCS side.

[0050] When the detection results indicate that the device to be managed belongs to UCS, the initialization process of the UCS device management module is triggered. This UCS device management module is deployed in the second operating environment (UCS dedicated private cloud operating environment). During the initialization process, it loads the second driver interface (such as cloud-native communication protocol drivers such as MQTT, HTTP / HTTPS, etc.) adapted to the UCS "cloud-network-device" architecture. After loading, it performs device discovery and binding operations, identifies and establishes communication connections with edge nodes or cloud devices through the private cloud network, thereby completing device access on the UCS side.

[0051] In this step, through the above-mentioned deployment and adaptation mechanism, the system can be compatible with both traditional Windows-based DCS environments and modern UCS environments based on private clouds. This enables precise adaptation and rapid binding of devices in heterogeneous environments, laying a solid foundation for subsequent unified data aggregation and management, and effectively avoiding the problem of devices being unable to access the system due to incompatibility with the environment.

[0052] In steps S202 and S204 above, the aim is to perform heterogeneous data standardization collection.

[0053] In this embodiment, the heterogeneous data standardization acquisition step specifically involves the DCS device management module and the UCS device management module performing differentiated acquisition and standardized encapsulation based on the data characteristics of their respective systems, so as to ensure that heterogeneous data can be correctly identified and processed by the unified device management (core) module.

[0054] Optionally, the first data packet includes: a first status parameter, a first type label, and a first timestamp, wherein the first status parameter is the operating status data of the first device collected by the DCS device management module in a first data format, the first type label is used to indicate the control system type of the first device, the first timestamp is the timestamp of the first status parameter collection, and the first device is the device to be managed with a control system type of DCS.

[0055] Specifically, the DCS device management module is deployed in a Windows operating environment. It loads a first driver interface adapted to the DCS communication protocol to collect the DCS device's operating status data (i.e., first status parameters) in a first data format. Since DCS typically uses traditional industrial control protocols or proprietary protocols, the first data format can be a specific binary stream, structured text, or a specific data structure defined by the DCS configuration. Furthermore, after collecting the first status parameters of the DCS device (such as temperature, pressure, flow rate, and switch status), the DCS device management module does not directly forward the raw data. Instead, it performs standardized encapsulation operations: First, it attaches a control system type label (i.e., a first type label) to the collected first status parameters. This label clearly identifies the data source as DCS (e.g., marked as "DCS" or a specific numerical code) so that subsequent modules can distinguish the data source. Second, it records the specific time of the first status parameter collection, generating a first timestamp to ensure data time synchronization and the accuracy of time-series analysis. Finally, it packages the first status parameters in the first data format, the first type label, and the first timestamp into a structured first data packet.

[0056] Optionally, the second data packet includes: a second status parameter, a second type label, and a second timestamp, wherein the second status parameter is the operating status data of the second device collected by the UCS device management module in a second data format, the second type label is used to indicate the control system type of the second device, the second timestamp is the timestamp of the second status parameter collection, and the second device is the device to be managed with a control system type of UCS.

[0057] Specifically, the UCS device management module is deployed in a dedicated private cloud operating environment for UCS. It collects operational status data (i.e., second status parameters) of the UCS device in a second data format by loading a second driver interface adapted to the UCS "cloud-network-device" architecture. Since UCS is typically based on a cloud-native architecture, the second data format can be a lightweight, standardized internet protocol data format, such as JSON, XML, or message formats based on the MQTT / HTTP protocol. Furthermore, after collecting the second status parameters of the UCS device, the UCS device management module also performs standardized encapsulation: First, it attaches a control system type label (i.e., a second type label) to the collected second status parameters. This label is used to clearly identify that the data originates from UCS (e.g., marked as "UCS" or a specific numerical code) so that subsequent modules can distinguish the data source; second, it records the specific time of collection of the second status parameters, generating a second timestamp to ensure data time synchronization and the accuracy of time-series analysis; finally, it packages the second status parameters in the second data format, the second type label, and the second timestamp into a structured second data packet.

[0058] During the aforementioned data acquisition process, a standardized encapsulation of heterogeneous system data was achieved by defining a data packet structure that includes status parameters, type labels, and timestamps. The introduction of type labels enables the unified device management module to quickly identify the data source, thereby accurately calling the corresponding protocol parsing library for normalization processing, eliminating data parsing barriers caused by different data formats between DCS and UCS. The addition of timestamps ensures the consistency of multi-source data in the time dimension, providing an accurate and reliable data foundation for subsequent real-time status monitoring, fault early warning, and linkage control based on a unified model, effectively improving the efficiency and accuracy of cross-system data fusion.

[0059] In step S206 above, the aim is to perform normalized aggregation and analysis based on a unified equipment management model.

[0060] Optionally, after receiving the first data packet from the DCS device management module and the second data packet from the UCS device management module, the unified device management module first needs to initiate tag-based data normalization processing, including: according to the first type of tag, calling a preset protocol parsing library to convert the first state parameter into first standard data with a preset data structure; according to the second type of tag, calling a protocol parsing library to convert the second state parameter into second standard data with a preset data structure; and inputting the first standard data and the second standard data into the device management model.

[0061] Specifically, the first data packet is parsed to extract the first type tag. Based on the first type tag (e.g., identified as "DCS"), the corresponding DCS protocol parsing submodule in the pre-built protocol parsing library is queried and invoked. This DCS protocol parsing submodule can perform semantic parsing and format conversion on the first state parameters according to the DCS communication specifications (such as the OPC UA object model or Modbus register mapping table), converting them from the DCS-specific first data format to a preset data structure defined internally by the unified device management module (such as a unified JSON Schema or standardized data objects), thereby generating first standard data. Based on this, combined with the timestamp and original tag in the first data packet, a first standard data record containing complete metadata is constructed.

[0062] Similarly, the second data packet is parsed to extract the second type tag. Based on the second type tag (e.g., identified as "UCS"), the corresponding UCS protocol parsing submodule in the pre-built protocol parsing library is queried and invoked. This UCS protocol parsing submodule can parse and format the second state parameter according to the UCS cloud-native communication specifications (such as MQTT topic mapping or RESTful API field definitions), converting it from the UCS-specific second data format to the same pre-defined data structure, thereby generating second standard data. Based on this, combined with the timestamp and tag in the second data packet, a second standard data record containing complete metadata is constructed.

[0063] Finally, the generated first and second standard data are input into a pre-defined unified equipment management model. Since the two types of data have been converted into the same preset data structure, the equipment management model does not need to write different processing logic for DCS and UCS. Instead, it can directly perform unified processing on the standardized data. For example, it can map similar parameters such as temperature and pressure from different sources to the same monitoring view, or perform cross-system fault early warning analysis based on unified threshold logic.

[0064] In the above process, by dynamically calling the protocol parsing library based on the type label, the automatic normalization of heterogeneous data formats is realized. This enables DCS and UCS to convert data into a unified standard data structure when there are significant differences in the underlying data formats, thereby shielding the impact of underlying heterogeneity and improving the system's compatibility and processing efficiency for multi-source heterogeneous data.

[0065] Optionally, a unified equipment management and control model is used to analyze and process the first data packet and the second data packet, including: identifying first type parameters and second type parameters belonging to the same physical quantity type in the first standard data and the second standard data, mapping the first type parameters and the second type parameters to a unified monitoring view and uploading them to the central management and control module for visualization; and / or extracting first alarm event information and second alarm event information from the first standard data and the second standard data respectively, fusing the first alarm event information and the second alarm event information based on a unified fault analysis logic and performing fault analysis to obtain fault analysis results; and / or generating first control commands and second control commands corresponding to the first standard data and the second standard data respectively based on a unified control strategy.

[0066] In this embodiment of the application, when the unified equipment management model analyzes and processes the first standard data and the second standard data, it can execute the following three optional or combined operation logics to achieve comprehensive closed-loop management from monitoring and early warning to control:

[0067] 1. Unified monitoring view mapping.

[0068] The equipment management model performs semantic recognition on the input first and second standard data, extracting first-type and second-type parameters belonging to the same physical quantity type (such as temperature, pressure, liquid level, flow rate, or on / off status). For example, it identifies that "reactor temperature" in the DCS and "tank temperature" in the UCS both belong to the physical quantity type "temperature". Subsequently, the first-type and second-type parameters are mapped to a unified monitoring view. In this view, regardless of whether the data originates from the DCS or UCS, similar parameters are presented in a unified chart format (such as trend curves, dashboards, or digital displays). Finally, the visualized data is uploaded to the monitoring system via a communication interface to the central management module, allowing operators to centrally view the operating status of all equipment in the plant on a single visual interface, eliminating the inconvenience of switching between systems to view data.

[0069] 2. Unified fault analysis.

[0070] The equipment management model extracts alarm event information from both the first and second standard data sets. Specifically, it extracts first alarm event information (such as alarm code, alarm level, occurrence time, and associated device ID) from the first standard data set and second alarm event information from the second standard data set. Subsequently, it fuses these two types of alarm information based on a pre-defined unified fault analysis logic, which includes, but is not limited to:

[0071] (1) Correlation analysis: Determine whether alarms in different systems are caused by the same root cause (for example, the pump pressure alarm in the DCS system and the motor current alarm in the UCS system may point to the same mechanical fault).

[0072] (2) Deduplication and priority sorting: If multiple alarms point to the same fault chain, the alarm information is merged and the fault level with the highest priority is determined.

[0073] (3) Root cause inference: Using unified fault tree or expert system rules, combined with the fused alarm information, the root cause of the fault is inferred.

[0074] Finally, the model generates fault analysis results that include fault description, severity level, and recommended measures, and pushes them to the central control module for alarm display.

[0075] 3. Unified control command generation.

[0076] The equipment management model analyzes the first and second standard data based on a preset unified control strategy (such as PID control logic, specific protection logic, or optimized control algorithm):

[0077] (1) For DCS equipment that needs to be adjusted, the equipment management model generates a first control command based on the first standard data. The command includes the target equipment ID, control action (such as opening adjustment, start and stop command) and target value, and the format is adapted to the DCS receiving requirements.

[0078] (2) For UCS devices that need to be adjusted, the device management model generates a second control command based on the second standard data, and the format is adapted to the UCS receiving requirements.

[0079] In the above process, the normalized data is processed in depth from multiple dimensions through a unified equipment management and control model, which realizes the unification of the monitoring interface (solving the inconvenience caused by data silos), the intelligent and global nature of fault analysis (improving the accuracy and comprehensiveness of fault diagnosis by integrating alarm information from multiple systems), and the coordination of control strategies (generating differentiated instructions based on unified logic to achieve coordinated linkage of cross-system equipment). This not only improves the level of precision in the management and control of equipment in the industrial field, but also significantly improves the safety and response efficiency of production operations.

[0080] In step S208 above, the aim is to execute unified instruction issuance and feedback.

[0081] Optionally, the equipment management steps based on the control instructions are manifested as a unified equipment management module distributing, tracking, and providing feedback on the control instructions in a closed loop, ensuring the accuracy and traceability of cross-system management. This includes: sending a first control instruction to the DCS equipment management module and receiving a first feedback result returned by the DCS equipment management module after performing management on the first device according to the first control instruction, wherein the first feedback result includes at least the execution status of the first control instruction and the operating status of the first device; sending a second control instruction to the UCS equipment management module and receiving a second feedback result returned by the UCS equipment management module after performing management on the second device according to the second control instruction, wherein the second feedback result includes at least the execution status of the second control instruction and the operating status of the second device.

[0082] Specifically, for device management on the DCS side, the unified device management module sends the generated first control command to the DCS device management module deployed in the Windows environment via an internal communication interface. Upon receiving the command, the DCS device management module uses its loaded first driver interface, adapted to the DCS communication protocol, to convert the first control command into a control signal recognizable by the DCS system's underlying layer (such as an analog output signal or a digital switch signal), and then sends it to the corresponding first device (i.e., the field intelligent device under the DCS system) to execute specific management actions (such as adjusting valve opening, starting a pump, etc.). After the first device completes its execution, the DCS device management module monitors the execution result and the latest operating parameters of the first device in real time, generating a first feedback result. This first feedback result includes at least the execution status of the first control command (e.g., "success," "failure," or a specific error code to indicate whether the command was executed correctly) and the current operating status of the first device (e.g., the actual temperature and pressure values ​​after execution). Subsequently, the DCS device management module sends this first feedback result back to the unified device management module, completing the closed-loop management on the DCS side.

[0083] For device management on the UCS side, the unified device management module sends the generated second control command to the UCS device management module deployed in the UCS dedicated private cloud environment. Upon receiving the command, the UCS device management module uses its loaded second driver interface, adapted to the UCS "cloud-network-device" architecture, to convert the second control command into a communication protocol message applicable to the UCS system and distribute it to the corresponding second device (i.e., the field intelligent device or edge controller under the UCS system) to execute the management action. After the second device completes the execution, the UCS device management module obtains the execution result and the latest operating parameters of the second device, generating a second feedback result. This second feedback result also includes at least the execution status of the second control command (e.g., "command confirmed," "execution timed out") and the current operating status of the second device (e.g., the latest telemetry data reported by the cloud). Subsequently, the UCS device management module transmits this second feedback result back to the unified device management module through the private cloud network, completing the closed-loop management on the UCS side.

[0084] Finally, the unified device management module receives the first feedback result from the DCS device management module and the second feedback result from the UCS device management module, and updates the device management view based on these feedbacks and records the operation and maintenance logs, thereby realizing closed-loop management of all controlled devices in the DCS and UCS systems throughout their entire lifecycle.

[0085] In this step, a two-way closed-loop mechanism of "command issuance - execution feedback - status update" is established to ensure the reliability and verifiability of control commands executed in heterogeneous environments (Windows DCS environment and cloud-native UCS environment). The first and second feedback results respectively include the command execution status and the device operating status, enabling the unified device management module to monitor the execution of commands and the final physical state of the device in real time, promptly detect execution anomalies or device failures, improve the real-time performance, security, and transparency of industrial field device management, and effectively avoid "blind control" caused by network latency or protocol conversion issues.

[0086] In this embodiment of the application, step S210 is also included, which is used to generate unified management and control reports and visual monitoring interfaces.

[0087] Optionally, the generation process of the comprehensive equipment management and control report and the equipment visualization monitoring interface involves three stages: template definition, data mapping, and rendering display. The aim is to achieve a unified presentation of cross-system data, including: obtaining a unified report template and a unified interface template. The unified report template is used to define standardized data statistical fields covering all DCS and UCS equipment in the plant, and the unified interface template is used to define a standardized monitoring view layout covering all DCS and UCS equipment in the plant; mapping the first standard data, the second standard data, the fault analysis results, the first feedback results, and the second feedback results to the standardized fields of the unified report template and the unified interface template, respectively, and rendering to generate the comprehensive equipment management and control report and the equipment visualization monitoring interface.

[0088] Specifically, the unified equipment management module first pre-configures or obtains unified report templates and unified interface templates from the configuration center. The unified report templates define standardized data statistics fields covering all equipment in the plant (such as equipment name, equipment ID, system type, real-time values, alarm levels, cumulative running time, maintenance records, etc.). These fields are independent of the specific data structure of the underlying DCS or UCS, forming a universal data display framework. The unified interface templates define standardized monitoring view layouts (such as process flow diagrams, equipment tree diagrams, trend graphs, alarm lists, etc.), specifying the location, style, and interaction logic of various data types on the interface.

[0089] Secondly, the various data obtained above are mapped to the standardized fields of the template. For example, similar parameters (such as temperature and pressure) from the first standard data (from DCS) and the second standard data (from UCS) are filled into the corresponding rows of the unified report and the corresponding monitoring points in the unified interface template according to the system type label of the equipment. The alarm information, fault description, and suggested measures in the fault analysis results are mapped to the alarm record field of the unified report and the real-time alarm area of ​​the unified interface template. The execution status and the latest operating status of the equipment in the first and second feedback results are updated to the operation log field of the unified report and the dynamic display area (such as color change and value refresh) of the corresponding equipment in the unified interface template. Through this mapping, the originally heterogeneous DCS and UCS data are transformed into standardized view data that conforms to the unified template specification.

[0090] Finally, based on the mapped standardized data, the front-end rendering engine is invoked: according to the structure and data of the unified report template, a comprehensive equipment management report is generated. This report displays the statistical information, historical trends, and operation and maintenance records of all DCS and UCS equipment in the plant in a unified format (such as Excel, PDF, or Web spreadsheet), supporting cross-system data comparison and analysis; and according to the layout and interaction logic of the unified interface template, a visual monitoring interface for equipment is generated. This interface intuitively displays the real-time status, process flow, alarm information, and control buttons of all equipment in the plant in a unified Web or client view. Operators can centrally monitor and operate DCS and UCS equipment without switching systems.

[0091] In this step, by introducing unified report templates and interface templates, the differences in data structure and interface style between DCS and UCS systems are masked, realizing "single-screen display" and "unified statistics" of cross-system data. This not only reduces the learning cost and operational complexity for operators and improves the human-computer interaction experience, but also enables managers to have a comprehensive grasp of the operating status of all equipment in the plant from a unified perspective, thereby improving the centralization level of equipment management and decision-making efficiency.

[0092] Figure 3 This is a complete flowchart illustrating a device control method according to an embodiment of this application, as shown below. Figure 3As shown, the method includes the following specific steps: First, the control system type is detected. If it is a DCS, a DCS device management module is deployed in the Windows environment and a first driver interface is loaded to perform device discovery and binding. Then, DCS device status parameters are collected in a first data format and a system type label and timestamp are attached to form a first data packet. If it is a UCS, a UCS device management module is deployed in the UCS private cloud environment and a second driver interface is loaded to perform device discovery and binding. Then, UCS device status parameters are collected in a second data format and a system type label and timestamp are attached to form a second data packet. Subsequently, the unified device management module receives the data packet, calls the protocol parsing library according to the system type label to convert the data into a unified standard data structure, and inputs it into the unified device management model. Based on the unified control strategy, a first control command or a second control command is generated for the DCS or UCS. Next, the control command is distributed to the corresponding DCS device management module or UCS device management module, converted into a DCS or UCS recognizable format respectively, and sent for execution, while receiving feedback results. Finally, a comprehensive management report and a visual monitoring interface covering all DCS and UCS devices in the plant are generated according to a unified template.

[0093] Overall, this application proposes an architecture of "dedicated deployment in different environments + unified management and control" for scenarios where DCS and UCS coexist. By deploying a DCS device management and control module in a Windows environment and a UCS device management and control module in a UCS private cloud respectively, the underlying communication and data acquisition challenges of heterogeneous systems are solved by utilizing their respective adapted driver interfaces. On this basis, a unified device management and control module running in the central environment is established. This module has a built-in unified device management and control model, which can standardize and normalize heterogeneous data from different environments, and perform integrated analysis to generate unified views, reports and control commands. This breaks through the limitations of traditional solutions that only support a single system or cannot achieve unified management and control, effectively solving the data silo problem caused by the independent deployment environments of DCS and UCS. While reducing development and maintenance costs, it achieves standardized, centralized and efficient management and control of all equipment in the plant.

[0094] According to an embodiment of this application, a device management and control system is provided. The device management and control system provided in this embodiment of the application is described below.

[0095] Figure 4 This is a structural diagram of a device management and control system provided according to an embodiment of this application. For example... Figure 4 As shown, the system includes: a DCS device management module 40, a UCS device management module 42, and a unified device management module 44, wherein...

[0096] The DCS device management module 40 is deployed in the first operating environment and is used to collect the operating status data of the devices to be managed that are controlled by a DCS system.

[0097] In this embodiment, the DCS device management module 40 is located in the DCS controller communication area and deployed in the Windows operating environment. By loading the first driver interface adapted to the DCS communication protocol, it collects DCS device status parameters in the first data format and adds system type tags and timestamps to form the first data packet.

[0098] UCS device management module 42, deployed in the second operating environment, is used to collect operating status data of the devices to be managed that are controlled by a UCS system.

[0099] In this embodiment, the UCS device management module 42 is located in the UCS controller communication area and deployed in the UCS dedicated private cloud operating environment. By loading the second driver interface adapted to the UCS "cloud-network-device" architecture, it collects UCS device status parameters in the second data format and adds system type tags and timestamps to form the second data packet.

[0100] Unified device management module 44 is used to perform the above. Figure 2 The equipment management method shown.

[0101] In this embodiment, the unified device management module 44 serves as the central management environment. It is responsible for receiving data packets from the DCS and UCS device management modules, parsing heterogeneous data and converting it into normalized data based on system type tags using an internally pre-built protocol parsing library, and then inputting it into the unified device management model containing logic for status monitoring, parameter control, fault early warning, and operation and maintenance records for analysis and processing. This generates DCS control commands and UCS control commands, which are then sent to the corresponding DCS and UCS device management modules to execute control. Simultaneously, a unified management report is generated based on the normalized data through a report generation engine, and finally a unified visual monitoring interface is output, realizing cross-system data aggregation, unified analysis, and centralized management.

[0102] Through the DCS device management module 40, UCS device management module 42 and unified device management module 44 in the above-mentioned device management device, the purpose of unified access and collaborative control of multi-source heterogeneous device data is achieved. This realizes the technical effect of eliminating the barriers between DCS and UCS systems and improving the standardized management efficiency of intelligent devices in various deployment environments. In turn, it solves the technical problem that the related technologies can only realize device management in a single environment and are difficult to solve the data silos and inconsistent management standards caused by the independent deployment environments of DCS and UCS systems.

[0103] According to an embodiment of this application, a device control apparatus is also provided. The device control apparatus provided in the embodiment of this application will be described below.

[0104] Figure 5 This is a structural diagram of a device control system according to an embodiment of this application. Figure 5 As shown, the device includes:

[0105] The first receiving module 50 is used to receive the first data packet sent by the DCS equipment management module of the distributed control system. The DCS equipment management module is deployed in the first operating environment and is used to collect the operating status data of the controlled equipment of the DCS type.

[0106] The second receiving module 52 is used to receive the second data packet sent by the general control system UCS device management module, wherein the UCS device management module is deployed in the second operating environment and is used to collect the operating status data of the device to be managed with the control system type UCS.

[0107] Processing module 54 is used to analyze and process the first data packet and the second data packet using a unified device management and control model, and generate corresponding control instructions;

[0108] The control module 56 is used to perform equipment control based on control commands.

[0109] Through the first receiving module 50, the second receiving module 52, the processing module 54, and the control module 56 in the above-mentioned equipment control device, the purpose of unified access and collaborative control of multi-source heterogeneous equipment data is achieved. This realizes the technical effect of eliminating the barriers between DCS and UCS systems and improving the standardized control efficiency of intelligent devices in various deployment environments. In turn, it solves the technical problem that the relevant technologies can only realize equipment control in a single environment and are difficult to solve the data silos and inconsistent management standards caused by the independent deployment environments of DCS and UCS systems.

[0110] It should be noted that the device management device in this application embodiment can be used to execute the device management method provided in this application embodiment. Therefore, the relevant explanations and descriptions in the above device management method also apply to the device management device, and will not be repeated here.

[0111] This application also provides an electronic device, including: a memory and a processor, wherein the memory is used to store program instructions; and the processor is connected to the memory and used to execute the above-described device control method.

[0112] It should be noted that the aforementioned electronic equipment is used to perform Figure 2 The device control method shown above is also applicable to this electronic device, and will not be repeated here.

[0113] This application also provides a non-volatile storage medium, which includes a stored computer program, wherein the device containing the non-volatile storage medium executes the above-described device management method by running the computer program.

[0114] It should be noted that the aforementioned non-volatile storage media is used for execution. Figure 2 The device management method shown above is also applicable to this non-volatile storage medium, and will not be repeated here.

[0115] This application also provides a computer program product, including computer instructions, which, when executed by a processor, implement the above-described device control method.

[0116] It should be noted that the above-mentioned computer program product is used to execute Figure 2 The device control method shown above is also applicable to this computer program product, and will not be repeated here.

[0117] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0118] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0119] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0120] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0121] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0122] If the integrated unit 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 this application, in essence, or the part that contributes to the prior art, or all or 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 this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0123] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for equipment control, characterized in that, include: The system receives a first data packet sent by the DCS device management module, wherein the DCS device management module is deployed in a first operating environment and is used to collect the operating status data of the device to be managed, which is of the DCS control system type. The system receives a second data packet sent by the Universal Control System (UCS) device management module, wherein the UCS device management module is deployed in the second operating environment and is used to collect the operating status data of the device to be managed, which is a UCS control system. A unified device management and control model is used to analyze and process the first data packet and the second data packet to generate corresponding control commands; The device is managed according to the control instructions.

2. The method according to claim 1, characterized in that, The method further includes: Detect the type of control system of the equipment to be managed; When the control system type of the device to be managed is DCS, the DCS device management module deployed in the first operating environment is initialized, and the first driver interface adapted to the DCS communication protocol is loaded to perform device binding. When the control system type of the device to be managed is UCS, the control module of the UCS device management and control deployed in the second operating environment is initialized, and the second driver interface adapted to the UCS network architecture is loaded to perform device binding.

3. The method according to claim 1, characterized in that, The first data packet includes: a first status parameter, a first type label, and a first timestamp, wherein the first status parameter is the operating status data of the first device collected by the DCS device management module in a first data format, the first type label is used to indicate the control system type of the first device, the first timestamp is the timestamp of the first status parameter collection, and the first device is a device to be managed with a control system type of DCS. The second data packet includes: a second status parameter, a second type label, and a second timestamp. The second status parameter is the operating status data of the second device collected by the UCS device management module in a second data format. The second type label is used to indicate the control system type of the second device. The second timestamp is the timestamp of the collection of the second status parameter. The second device is a device to be managed with a control system type of UCS.

4. The method according to claim 3, characterized in that, The method further includes: Based on the first type label, a pre-set protocol parsing library is invoked to convert the first state parameter into first standard data with a preset data structure; Based on the second type label, the protocol parsing library is invoked to convert the second state parameter into second standard data of the preset data structure; Input the first standard data and the second standard data into the equipment management model.

5. The method according to claim 4, characterized in that, A unified device management model is used to analyze and process the first data packet and the second data packet, including: Identify first-type parameters and second-type parameters belonging to the same physical quantity type in the first standard data and the second standard data, map the first-type parameters and the second-type parameters to a unified monitoring view and upload them to the central control module for visualization; and / or First alarm event information and second alarm event information are extracted from the first standard data and the second standard data, respectively. Based on a unified fault analysis logic, the first alarm event information and the second alarm event information are fused and fault analysis is performed to obtain the fault analysis result; and / or Based on a unified control strategy, a first control command and a second control command corresponding to the first standard data and the second standard data are generated respectively.

6. The method according to claim 5, characterized in that, Executing device management and control according to the control instructions includes: The first control command is sent to the DCS device management module, and the first feedback result returned by the DCS device management module after performing management on the first device according to the first control command is received. The first feedback result includes at least the execution status of the first control command and the operating status of the first device. The second control command is sent to the UCS device management module, and the second feedback result returned by the UCS device management module after performing management on the second device according to the second control command is received. The second feedback result includes at least the execution status of the second control command and the operating status of the second device.

7. The method according to claim 6, characterized in that, The method further includes: Obtain a unified report template and a unified interface template, wherein the unified report template is used to define standardized data statistics fields covering all DCS and UCS equipment in the plant, and the unified interface template is used to define a standardized monitoring view layout covering all DCS and UCS equipment in the plant. The first standard data, the second standard data, the fault analysis result, the first feedback result, and the second feedback result are respectively mapped to the standardized fields of the unified report template and the unified interface template, and the equipment comprehensive management and control report and the equipment visual monitoring interface are rendered and generated.

8. An equipment control system, characterized in that, include: The system comprises a DCS device management module, a UCS device management module, and a unified device management module. The DCS equipment management and control module is deployed in the first operating environment and is used to collect the operating status data of the controlled equipment with a control system type of DCS. The UCS device management module is deployed in the second operating environment and is used to collect the operating status data of the devices to be managed that are controlled by a UCS system. The unified equipment management module is used to execute the equipment management method according to any one of claims 1 to 7.

9. An equipment control device, characterized in that, include: The first receiving module is used to receive the first data packet sent by the DCS device management module of the distributed control system, wherein the DCS device management module is deployed in the first operating environment and is used to collect the operating status data of the device to be managed, which is of the DCS control system type. The second receiving module is used to receive the second data packet sent by the general control system UCS device management module, wherein the UCS device management module is deployed in the second operating environment and is used to collect the operating status data of the device to be managed with the control system type UCS. The processing module is used to analyze and process the first data packet and the second data packet using a unified device management and control model, and generate corresponding control commands. The control module is used to perform device control based on the control commands.

10. An electronic device, characterized in that, include: A memory and a processor, wherein the memory is used to store program instructions; The processor, connected to the memory, is used to execute the device control method according to any one of claims 1 to 7.

11. A non-volatile storage medium, characterized in that, The non-volatile storage medium includes a stored computer program, wherein the device containing the non-volatile storage medium executes the device management method according to any one of claims 1 to 7 by running the computer program.

12. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the device control method according to any one of claims 1 to 7.

Images