Method, device and medium for constructing device topology

Abstract

This invention discloses a method, apparatus, device, and medium for constructing a device topology. By automatically acquiring the device attribute information of each device and transforming the scattered raw information into structured data of device objects with complete semantics according to a preset data format, the invention automatically queries the driver registry based on the device's identity data to match the most suitable target driver for each device. Finally, based on the structured data containing each device's identity data and hierarchical path data, the invention intelligently matches and mounts device drivers, automatically generating an accurate hierarchical topology. This achieves full automation from data acquisition to topology presentation, greatly improving the efficiency and accuracy of topology construction, significantly reducing the workload of manual configuration, eliminating manual input errors and deviations from the actual on-site structure, and ensuring a high degree of consistency between the topology in the management system and the on-site configuration.

Description

Technical Field

[0001] This invention relates to the field of industrial automation technology, and in particular to a method, apparatus, equipment, and medium for constructing a device topology. Background Technology

[0002] In large-scale process industries such as coal chemical and petrochemical manufacturing, the construction of equipment topology is a crucial aspect of engineering implementation. In related technologies, the hierarchical topology of equipment is typically constructed manually by engineers, who then manually create controllers, I / O cards, channels, and field instrument nodes based on design drawings.

[0003] However, this manual topology creation method has significant shortcomings. First, with a massive number of devices, manually creating nodes one by one and establishing hierarchical relationships is extremely time-consuming and inefficient. Second, manual configuration relies entirely on engineers' understanding of the on-site physical structure and design drawings, which can easily lead to problems such as incorrect device-parent node correspondence and missing hierarchical levels, resulting in an inaccurate topology that is disconnected from the actual on-site operating structure, thereby affecting the effectiveness of subsequent equipment monitoring, diagnosis, and maintenance functions. Summary of the Invention

[0004] In view of this, the present invention provides a method, apparatus, device and medium for constructing a device topology, in order to solve the technical problems of large workload, long time consumption and poor accuracy of manual configuration.

[0005] Firstly, a method for constructing a device topology is provided, the method comprising: In response to the request to build the device topology, obtain device attribute information for multiple devices; Based on device attribute information, structured data corresponding to each device is generated according to a preset data format. The structured data includes the identity data of each device and the hierarchical path data representing the subordinate relationship between multiple devices. Based on identity data and a preset driver registry, determine the target driver for each device; The target driver is attached to each device, and a hierarchical topology of multiple devices is generated based on structured data.

[0006] Secondly, a device for constructing a device topology is provided, the device comprising: The acquisition module is used to obtain device attribute information of multiple devices in response to the device topology construction request; The first generation module is used to generate structured data corresponding to each device based on device attribute information and according to a preset data format. The structured data includes the identity data of each device and the hierarchical path data representing the subordinate relationship between multiple devices. The determination module is used to determine the target driver for each device based on identity data and a preset driver registry. The second generation module is used to mount the target driver to each device and generate a hierarchical topology of multiple devices based on structured data.

[0007] Thirdly, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method for constructing the device topology described above.

[0008] Fourthly, a computer-readable storage medium is provided, which stores a computer program that, when executed by a processor, implements the steps of the method for constructing the above-described device topology.

[0009] The aforementioned method, apparatus, equipment, and medium for constructing the device topology structure automatically acquires the device attribute information of each device and transforms the scattered raw information into structured data of device objects with complete semantics according to a preset data format. Subsequently, based on the device's identity data, the driver registry is automatically queried to match the most suitable target driver for each device. Finally, based on the structured data containing each device's identity data and hierarchical path data, device drivers are intelligently matched and mounted, automatically generating an accurate hierarchical topology structure. This achieves full automation from data acquisition to topology presentation, greatly improving the efficiency and accuracy of topology construction, significantly reducing the workload of manual configuration, eliminating manual input errors and deviations from the actual on-site structure, and ensuring a high degree of consistency between the topology structure in the management system and the on-site configuration. Attached Figure Description

[0010] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 This is a flowchart illustrating a method for constructing a device topology in one embodiment of the present invention; Figure 2 This is a flowchart illustrating the process of constructing a device topology based on a distributed control system in an embodiment of the present invention for an intelligent agent-integrated device management system. Figure 3 This is a schematic diagram of the device for constructing the device topology in one embodiment of the present invention. Detailed Implementation

[0011] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the accompanying drawings in the present invention are only for illustrative and descriptive purposes and are not intended to limit the scope of protection of the present invention.

[0012] Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this invention illustrate operations implemented according to some embodiments of the invention. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or performed simultaneously. Moreover, those skilled in the art, guided by the content of this invention, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.

[0013] Furthermore, the embodiments described herein are merely some, not all, of the embodiments of the invention. The components of the embodiments of the invention described and illustrated herein can typically be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.

[0014] It should be noted that the term "comprising" will be used in the embodiments of the present invention to indicate the presence of a feature subsequently declared, but does not exclude the addition of other features. It should also be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0015] In large-scale process industries such as coal chemical and petrochemical plants, the number of fieldbus (such as HART and Profibus PA) instruments deployed is enormous, reaching hundreds or even thousands. Traditional equipment management systems (such as Emerson AMS and Siemens PDM) rely primarily on manual configuration by engineers when constructing the hierarchical topology of these devices (typically including controllers → I / O cards → channels → field instruments, etc.). This approach has significant drawbacks: First, manually creating nodes and establishing hierarchical relationships for a massive number of devices is extremely time-consuming and inefficient. Second, manual configuration depends entirely on engineers' understanding of the on-site physical structure and design drawings, which easily leads to errors in the correspondence between devices and parent nodes (such as channels and cards), and omissions in the hierarchy. This results in an inaccurate topology, a disconnect from the actual operating structure of the distributed control system (DCS), and consequently affects the effectiveness of subsequent equipment monitoring, diagnosis, and maintenance functions.

[0016] Based on this, this application proposes a method for constructing a device topology structure. By automatically obtaining the original device attribute information of each device from a data source (such as DCS), converting it into standardized structured data, and intelligently matching and mounting device drivers based on this data, an accurate device hierarchical topology structure is automatically generated. This achieves full automation from data acquisition to topology presentation, thereby solving the problems of large workload, long time consumption, and poor accuracy of manual configuration.

[0017] The following is a detailed description of this case, in conjunction with the relevant accompanying drawings in the instruction manual.

[0018] Please see Figure 1 This description and embodiment provides a method for constructing a device topology, specifically including the following steps: S10: In response to the device topology construction request, obtain device attribute information of multiple devices.

[0019] It is understood that the executing entity of this invention can be a device for constructing a device topology, or it can be a terminal or a server; no specific limitation is made here. This embodiment of the invention will be described using a server as an example.

[0020] In this step, when engineers need to build the hierarchical topology of the equipment, a topology construction request is triggered. Upon receiving this request, the system retrieves the equipment configuration information for each device in the factory.

[0021] Optionally, the multiple devices include at least a controller, I / O cards, channels, and field instruments. The device attribute information includes at least one of the following: node identifier, device tag number, device vendor ID, device type identifier, device version number, serial number, identifier of its parent node, hardware address, slot number, and other location information and communication information.

[0022] In practical applications, when engineers need to build the factory's equipment topology using the Intelligent Individual Device Management (iIDM) system, they can trigger a build request through the system interface. In response to this request, the system initiates an automatic topology building process, establishing a secure connection between the built-in OPC UA client and the OPC UA server on the DCS side. After the connection is established, the system sends a data subscription request to the OPC UA server on the DCS side to obtain equipment attribute information for each device in the factory.

[0023] S20: Based on device attribute information, generate structured data corresponding to each device according to a preset data format; The structured data includes the identity data of each device, as well as hierarchical path data that represents the subordinate relationships between multiple devices.

[0024] In this step, the raw attribute information of each device is typically heterogeneous and hashed, making this data format unsuitable for direct use in a device management system. Therefore, after obtaining the raw device attribute information, it needs to be parsed and reorganized. Based on a preset data format, the identity-related fields and parent node identifiers of each device are extracted from the device attribute information. Subsequently, the extracted identity-related fields and parent node identifiers are organized according to the preset data format to generate structured data conforming to the device management system. In this preset data format, each device is defined as an independent entity object. The structured data of this entity object not only includes the device's own identity data but also hierarchical path data representing the subordinate relationships between this device and other devices.

[0025] In practical applications, the default data format is the data format used internally by the iIDM system.

[0026] In one embodiment of this application, a specific structured data generation scheme is provided. In S20, structured data is generated based on device attribute information and according to a preset data format, specifically including the following steps S21-S25: S21: Extract the identity field from the device attribute information of each device; The identity field includes at least one of the following: device tag number, device manufacturer, device model, device version, device type identifier, and device serial number.

[0027] In this step, after obtaining the original attribute information of each device, this information is parsed to extract the core fields necessary for constructing the device identity, including at least one of the following: device tag number (such as PT-101, TT-205), manufacturer identifier (such as Rosemount, Siemens), device type identifier (such as 3051, SITRANS P320), device version information (such as Rev 2.0), device type identifier, and device serial number.

[0028] S22: Based on the identity field, generate identity data for each device according to a preset data format.

[0029] In this step, each device is treated as an entity object. The extracted key identity fields are organized and summarized according to a preset data format to generate identity data for each entity object. This integrates the various identity fields that were originally scattered in the original attribute information into identity data with complete semantics, facilitating subsequent processing and referencing.

[0030] S23: Extract the parent node identifier of each device from the device attribute information.

[0031] In this step, the parent node identifier for each device is extracted from the device attribute information. The parent node identifier points to the direct parent node of the current device and is the core basis for constructing the hierarchical relationship between devices. For example, the attribute information of a channel device contains the parent node identifier "IOModule 201," which points to its associated I / O card; the attribute information of an instrument contains the parent node identifier "Channel 301," which points to the channel it is attached to. By extracting the parent node identifier, the direct superior of each device in the hierarchical structure can be clearly identified.

[0032] S24: Based on the parent node identifier and device tag number, construct a hierarchy network among multiple devices.

[0033] In this step, the parent node identifiers of all devices are traversed, and the parent node identifier of each device is associated with its own tag number. For any device, if its parent node identifier points to another device, it indicates that the latter is the direct parent node of the former. For example, if the parent node identifier of an I / O card device points to a controller device, it means that the I / O card belongs to the controller; if the parent node identifier of a channel device points to an I / O card device, it means that the channel belongs to the I / O card; if the parent node identifier of a field instrument device points to a channel device, it means that the field instrument belongs to the channel. Through this layer-by-layer resolution, all devices are organized according to parent-child relationships. Devices without parent node identifiers or with empty parent node identifiers are identified as root node devices. Devices with parent node identifiers are identified as child node devices, and an association with the parent node is established based on the parent node identifier. On this basis, a complete dependency network is constructed. Each device not only knows who its own parent node is, but also indirectly associates with higher-level ancestor nodes through its parent node identifier. For example, a field instrument device is associated with the next level (I / O card) through its parent node (channel), and then associated with the top-level controller through the parent node of the I / O card, forming a complete subordinate chain.

[0034] S25: Generate hierarchical path data for each device based on the device tag number and the subordinate relationship network.

[0035] In this step, the process starts from the root node device in the hierarchy network and traverses downwards layer by layer. For each device, its device tag number is obtained as the node name in the path, and combined with its hierarchy relationship, a complete path from the root node to the current device is constructed. During the traversal, it is ensured that the generated path conforms to the valid parent-child relationship between device types, such as a controller as the parent node of an I / O card, an I / O card as the parent node of a channel, and a channel as the parent node of a field instrument. A recursive or iterative approach is used. For the root node device, its hierarchical path data is its own device tag number, such as "Controller A". For child node devices, their hierarchical path data is formed by concatenating the hierarchical path of its parent node with its own device tag number, using a preset separator, such as " / ". Taking a field instrument as an example, if its controller device tag number is "Controller A", its I / O card device tag number is "Card 1", its channel device tag number is "Channel 3", and its own device tag number is "PT-101", then the generated hierarchical path data is "Controller A / Card 1 / Channel 3 / PT-101".

[0036] S30: Based on identity data and the preset driver registry, determine the target driver for each device.

[0037] In this step, based on the identity data of each device, a preset driver registry is queried to determine whether a dedicated driver (DTM) for that device exists. Then, based on the query results, the most suitable target driver is determined for each device.

[0038] In one embodiment of this application, a specific device driver matching scheme is provided. In S30, the target driver corresponding to each device is determined based on identity data and a preset driver registry, specifically including the following steps S31-S37: S31: Based on the identity data of each device, determine whether the preset driver registry contains the dedicated driver for each device.

[0039] In this step, the identification data of each device is used as the basis for querying a pre-set driver registry to determine whether it contains the dedicated drivers for each device. The driver registry pre-stores registration information for various device-specific drivers, including the manufacturer identifier, device type identifier, and version number supported by the driver. The manufacturer identifier, device type identifier, and device version number from the device's identification data are used as search keywords to perform a search in the driver registry.

[0040] S32: For any device, if the default driver registry contains a dedicated driver for the device, obtain at least one available version of the dedicated driver.

[0041] S33: In cases where at least one version is available, the dedicated driver with the highest compatibility will be used as the target driver for the device.

[0042] S34: If at least one version is available, use the dedicated driver for that version as the target driver for the device.

[0043] For steps S32-S34, for any device, if the preset driver registry contains a dedicated driver for that device, then at least one available version of that dedicated driver is further obtained. Based on the device version number in the identity data, driver versions compatible with that device are filtered out and compiled into a list of available versions.

[0044] If multiple available versions are obtained, the version with the highest compatibility is selected as the target driver for the device. The version with the highest compatibility typically refers to one that can communicate normally with the device and has comprehensive functional support, ensuring that the device receives the most complete functional support possible while maintaining stable operation. Furthermore, if only one available version is obtained, the dedicated driver for that version is directly selected as the target driver for the device.

[0045] S35: If the default driver registry does not contain a dedicated driver for the device, determine whether the device description file corresponding to the device exists in the default device description file library.

[0046] S36: If a device description file corresponding to the device exists in the preset device description file library, the device description file shall be used as the target driver of the device.

[0047] For steps S35-S36, if the preset driver registry does not contain a dedicated driver for the device, the system continues to check if a device description file (DD file) corresponding to the device exists in the preset device description file library. A device description file records basic parameters, units, measurement ranges, etc., of the device. Although it does not have the complete functionality of a dedicated driver, it can achieve basic device identification and data access. Based on the manufacturer identifier and device type identifier in the device identity data, a search is performed in the preset device description file library. If a DD file corresponding to the device exists, that DD file is identified as the target driver for the device.

[0048] S37: If the device description file corresponding to the device does not exist in the preset device description file library, the preset general driver will be used as the target driver for the device.

[0049] In this step, if neither a dedicated driver nor a corresponding DD file exists, a default generic driver will be used as the target driver for the device. The generic driver can establish basic communication with most field devices, read basic device status information, and ensure that the device can at least be recognized and monitored by the system, preventing the device from being unable to connect to the system due to missing drivers.

[0050] Optionally, the default generic driver is genericDTM.

[0051] By using the above method, the most suitable target driver is determined for each device, realizing automated driver matching without manual intervention, which effectively improves the efficiency of device access and topology construction.

[0052] S40: Mount the target driver to each device and generate a hierarchical topology for multiple devices based on structured data.

[0053] In this step, for each device, a corresponding target driver is instantiated, a driver object is generated, and this driver object is registered to the core component fdtSERVER of the FDT (Field Device Tool) framework. A communication context is established between the driver object and the field device, and the device's basic parameters are initialized and read, enabling the device to have complete communication capabilities. Subsequently, each device is treated as a node, and based on the hierarchical path data of each device, the hierarchical relationships between nodes are determined, connecting the nodes according to parent-child relationships to form a hierarchical node tree. Simultaneously, device identity data for each device is added to the corresponding node, so that each node not only knows where it is attached but also knows who it is and which driver it should use. The final generated complete hierarchical topology is displayed in a tree or graphical format, containing the complete hierarchical relationship from controllers, I / O cards, channels to field instruments, and each device node has its corresponding driver attached. This allows engineers to directly access each device, read parameters, or perform diagnostic operations through the system interface without any additional manual configuration.

[0054] In one embodiment of this application, a specific topology generation scheme is provided. In S40, the target driver is mounted to each device, and a hierarchical topology of multiple devices is generated based on structured data. Specifically, this includes the following steps S41-S44: S41: Instantiate and load the corresponding target driver for each device.

[0055] In this step, after determining the target driver for each device, the Field Device Tool (FDT) framework service is invoked to instantiate and load the corresponding target driver for each device. Specifically, the target driver information for the device is passed to the core component of the FDT framework, fdtSERVER, which creates a driver instance based on the received information. For devices matching a Dedicated Driver (DTM), the system instantiates the corresponding DTM object; for devices matching a DD file, the system loads the corresponding DD file parser; and for devices matching a generic driver, the system instantiates a generic DTM object. After instantiation, the driver object is registered with fdtSERVER, putting the driver in a ready state. Subsequently, a communication context is established between the driver object and the device, completing the driver initialization and loading, enabling the device to have complete communication capabilities and laying the foundation for subsequent data interaction.

[0056] S42: Construct a tree-like data structure based on the hierarchical path data in the structured data.

[0057] In this step, after the driver is loaded, the hierarchical path data of each device is parsed, such as "Controller A / Card 1 / Channel 3 / Pressure Gauge PT-101", extracting the names of each node on the path and their hierarchical relationships. Starting from the root node device, the corresponding node objects are created layer by layer in memory according to the order of the hierarchical path, and parent-child reference relationships between nodes are established. For multiple nodes at the same level, the system sorts them according to preset rules (such as device tag number from largest to smallest) to ensure the orderliness of the tree structure.

[0058] Using the above method, a complete device tree is constructed in memory. The root node of the tree corresponds to the top-level controller, the leaf nodes correspond to field instrument devices, and the intermediate nodes correspond to I / O cards, channels, and other devices.

[0059] S43: Associate the device with the target driver loaded with the corresponding node in the tree data structure.

[0060] In this step, for each device node, a reference relationship is established from the node to its corresponding driver object. This ensures that the node not only contains the device's identity data and hierarchical location data, but also holds its corresponding driver object. For example, for the "Pressure Gauge PT-101" node in the tree structure, the previously instantiated Rosemount 3051 dedicated driver object is associated with this node. Through this association, each node gains the ability to communicate with its corresponding device, allowing the system to directly access the field device through the associated driver object when the user interacts with the node.

[0061] S44: Render the tree data structure into an interactive topology tree view in the graphical user interface, forming a hierarchical topology structure for multiple devices.

[0062] In this step, a tree-like control or similar visual component is used to display the device nodes in memory layer by layer on the interface, forming the final hierarchical topology. The root node device is displayed at the top level, and child node devices are displayed below the parent node in an indented or connected manner, forming a clear hierarchical relationship. Each node is presented on the interface as an icon and a label. The icon is distinguished according to the device type (such as controller, I / O card, channel, field instrument), and the label displays the device tag number or device name. Users can expand or collapse nodes to view devices at different levels, and click on a node to view detailed device information or perform operations. Since each node is associated with a corresponding driver object, when a user double-clicks a node, the system can read the device's process values ​​in real time through the driver object, perform diagnostics, or modify parameters, enabling direct interaction with field devices.

[0063] The above method completes the entire process from driver loading and memory structure construction to interface rendering, ultimately forming an interactive factory equipment hierarchical topology, providing engineers with an intuitive and efficient equipment management and monitoring interface.

[0064] In one embodiment of this application, a specific topology storage scheme is provided. After S40, that is, after the target driver is mounted to each device and a hierarchical topology of multiple devices is generated based on structured data, the following steps are also included: Generate version numbers for the hierarchical topology based on a preset version number format; Store the hierarchical topology and its corresponding version number in a preset database.

[0065] In this embodiment, a version number is generated for the currently constructed hierarchical topology based on a preset version number format, ensuring that each generated version number is unique and identifiable. After the version number is generated, the complete hierarchical topology data and its corresponding version number are stored in a preset database. The preset database can be a relational database, a time-series database, or a dedicated asset database, used to persistently store the factory's equipment topology information. During storage, the information of each device node in the topology, the hierarchical relationships between nodes, the driver information associated with nodes, and the attribute data of nodes are organized and written according to the database schema. At the same time, the version number stored this time is associated with the topology data and saved to establish a version index. When subsequent topology changes occur, incremental updates can be performed based on the version number, and the new version is stored in the database again, retaining historical versions for traceability and comparison. Engineers can query the database to view the equipment topology at any historical moment, or compare the differences between two versions, providing strong support for equipment maintenance, fault diagnosis, and change management.

[0066] Optionally, the default version number format can be a timestamp format, such as "YYYYMMDD HHMMSS"; or an incrementing integer sequence, such as "V1.0, V1.1, V2.0".

[0067] In one embodiment of this application, a specific topology update scheme is provided. After S40, that is, after the target driver is mounted to each device and a hierarchical topology of multiple devices is generated based on structured data, the following steps are also included: When a change in the topology version number is detected or a change event notification is received, the changed node is determined in the current topology based on the device attribute information of the changed device. Based on the device attribute information and the structured data corresponding to the change node, the change form of the change node is determined, where the change form is adding a node, deleting a node, or data modification. The current hierarchical topology is updated based on the change type of the changed node and the device attribute information of the changed device.

[0068] In this embodiment, the system continuously subscribes to the topology version number node or topology change event node on the distributed control system side via an OPC UA client. When a change in the topology version number is detected or a change event notification is received, the system sends a change data request to the distributed control system side to obtain the device attribute information that has changed since the previous version. The changed device attribute information includes the complete attribute information of newly added devices, the identification information of removed devices, or the updated data of devices whose attribute information has changed.

[0069] Further, after obtaining the device attribute information of the changed device, the changed node is determined in the current hierarchical topology based on this information. For newly added devices, the parent node is located in the existing topology according to its parent node identifier in its device attribute information; for removed devices, the corresponding node is found in the current topology based on its device identifier; for devices with attribute changes, the existing node corresponding to that device is located. Subsequently, based on the device attribute information and the structured data corresponding to the changed node, the change type of the changed node is determined. There are three types of change types: added node, deleted node, or data change. If the changed device does not have a corresponding node in the existing topology, it is determined to be a newly added node; if the changed device has a corresponding node in the existing topology but the change information indicates that the device has been removed, it is determined to be a deleted node; if the changed device has a corresponding node in the existing topology and the change information is an attribute update, it is determined to be a data change.

[0070] Furthermore, based on the determined change type and the device attribute information of the changed device, the current hierarchical topology is updated accordingly. For newly added nodes, a new device node is created under the parent node, generating the node's identity data and hierarchical path data. The target driver is then matched and mounted according to the device attribute information, and the mounted driver object is associated with the newly added node. For deleted nodes, the node and all its child nodes are removed from the topology, and the associated driver resources are released. For nodes with data changes, the node's attribute information, such as device tag number and device version, is updated, and the driver is re-matched or the hierarchical path is adjusted as needed.

[0071] Furthermore, after each update, a new topology version number is generated, and the updated hierarchical topology is stored in the database to form a traceable version history, ensuring that engineers can always access the equipment topology that is consistent with the actual configuration on site.

[0072] By using the above method, only the parts that have changed are processed, while the nodes that have not changed retain their original state. The driver is not re-instantiated or the structure is not rebuilt, thereby avoiding repeated loading and resource waste.

[0073] In one embodiment of this application, a specific topology comparison scheme is provided, which includes the following steps: In response to a topology comparison request, obtain the version numbers of at least two topologies to be compared included in the topology comparison request; Based on the version number, retrieve the target topology structure corresponding to each version number from the preset database; Perform node matching on multiple target topologies, identify the differing nodes, and mark the differing nodes in each target topology; The topology of multiple targets with marked differences is visualized.

[0074] In this embodiment, after multiple topology constructions and incremental updates, a pre-defined database stores multiple historical versions of hierarchical topologies. When engineers need to compare the differences between different versions of the topology, they can initiate a topology comparison request through the system interface. The system obtains the version numbers of at least two topologies to be compared, included in the comparison request. The comparison request can be triggered by engineers selecting two or more historical versions through a graphical user interface, or by inputting version numbers or selecting a time range to specify the target version to be compared. The system parses the request content and extracts the version number information of all topologies to be compared, which serves as the basis for subsequent data retrieval.

[0075] Furthermore, the system uses the version number as an index to read the structural data of the corresponding target topology from a preset database and loads it into memory for comparative analysis. Subsequently, the system performs node matching on multiple target topologies, employing depth-first search or breadth-first search algorithms. Using the unique identifier of each device node (such as device tag number or device ID) as the matching criterion, it compares the presence and attributes of nodes in each version of the target topology, identifying the following types of differences: nodes that exist only in version 1 but not in version 2 are marked as "deleted nodes"; nodes that exist only in version 2 but not in version 1 are marked as "new nodes"; nodes that exist in both versions but whose attribute information (such as device version, parent node position, etc.) has changed are marked as "changed nodes". For nodes with changed attributes, the specific changed fields and their values ​​before and after the change are further recorded. The identified difference nodes are marked with difference markers in each version of the topology for easy highlighting during subsequent visualization.

[0076] Furthermore, the graphical user interface can display multiple versions of the topology using side-by-side or overlay comparisons. For example, the left window displays the topology tree of version one, and the right window displays the topology tree of version two. Difference nodes are distinguished by preset visual identifiers: newly added nodes are highlighted in green with a "+" label, deleted nodes are displayed in gray or with a "-" label, and changed nodes are highlighted in yellow with a change details prompt. Users can click on the difference node to view specific change information, such as "Device version changed from 1.0 to 2.0" or "Parent node changed from card 1 to card 2." For comparisons of more than two versions, the system can display the topology structure of each version in a paginated or tabbed format, and uniformly mark the difference nodes.

[0077] The above methods enable engineers to intuitively understand the differences between different versions of the topology, quickly identify changes in field equipment, and provide strong support for equipment maintenance, change auditing, and troubleshooting.

[0078] In practical application scenarios, such as Figure 2The diagram illustrates the process of building a device topology based on a distributed control system (DCS) for the Intelligent Agent Integrated Device Management System (iIDM). The iIDM system is device management software running on an engineering workstation or host computer. After startup, the iIDM system enters the initialization phase, initializing the OPC UA client. The OPC UA client is responsible for initiating connection requests to the DCS system and receiving data. After client initialization, the iIDM system connects to and subscribes to device attribute information. A secure connection is established with the OPC UA server on the DCS side via the OPC UA protocol, and a subscription request is sent to obtain the raw device attribute information generated by the DCS side. After obtaining the device attribute information, the iIDM system parses the device attribute information of individual devices, extracting key information for each device and mapping it to structured data in the iIDM system's internal data format. This includes device type, manufacturer identifier, and device model, preparing for subsequent driver matching. Based on the parsed manufacturer and device type information, the system searches the preset driver registry for a matching device description file (DD) or dedicated device driver (DTM). If a matching DD / DTM is found, the DD / DTM loading operation is performed, instantiating the driver and attaching it to the corresponding device node, enabling the device to communicate. If no matching DD or DTM is found, a general device driver is matched for the device, and unidentified devices are recorded for later manual troubleshooting or driver supplementation, ensuring no device is overlooked. After parsing and matching all nodes and drivers, the device nodes with attached drivers are organized according to hierarchical path data to form a complete hierarchical topology. Engineers can view the generated complete device topology tree through a graphical interface. Each node has its corresponding driver attached, allowing direct device access and operation. The entire process requires no manual intervention, achieving automatic creation of the entire topology within minutes. Furthermore, in terms of protocol support, it supports multiple fieldbus protocols such as HART and Profibus PA. Topology synchronization and protocol communication layers are decoupled; OPC UA handles structure synchronization, and the FDT framework handles protocol access. Therefore, adding new protocols does not require modification of the topology algorithm, providing excellent scalability.

[0079] As can be seen, in the above solution, by automatically acquiring the device attribute information of each device and transforming the scattered raw information into structured data of device objects with complete semantics according to a preset data format, the solution automatically queries the driver registry based on the device's identity data to match the most suitable target driver for each device. Finally, based on the structured data containing each device's identity data and hierarchical path data, the solution intelligently matches and mounts device drivers, automatically generating an accurate hierarchical topology. This achieves full automation from data acquisition to topology presentation, greatly improving the efficiency and accuracy of topology construction, significantly reducing the workload of manual configuration, eliminating manual input errors and deviations from the actual on-site structure, and ensuring a high degree of consistency between the topology in the management system and the on-site configuration.

[0080] In one embodiment, a device topology construction apparatus is provided, which corresponds one-to-one with the device topology construction method described in the above embodiments. For example... Figure 3 As shown, the device topology construction apparatus 100 includes: an acquisition module 101, a first generation module 102, a determination module 103, and a second generation module 104. Detailed descriptions of each functional module are as follows: The acquisition module 101 is used to acquire device attribute information of multiple devices in response to the device topology construction request; The first generation module 102 is used to generate structured data corresponding to each device based on device attribute information and according to a preset data format. The structured data includes the identity data of each device and the hierarchical path data representing the subordinate relationship between multiple devices. The determination module 103 is used to determine the target driver for each device based on identity data and a preset driver registry. The second generation module 104 is used to mount the target driver to each device and generate a hierarchical topology of multiple devices based on structured data.

[0081] In one embodiment, the first generation module 102 is specifically used for: Extract the identity field from the device attribute information of each device. The identity field includes at least one of the following: device tag number, device manufacturer identifier, device model, device version number, device type identifier, and device serial number. Based on the identity field, generate identity data for each device according to a preset data format; Extract the parent node identifier of each device from the device attribute information; Based on the parent node identifier and device tag number, construct a hierarchy network among multiple devices; Based on the device tag number and the hierarchy network, generate hierarchical path data for each device.

[0082] In one embodiment, the determining module 103 is specifically used for: Based on the identity data of each device, determine whether the preset driver registry contains the dedicated driver for each device; For any device, if the default driver registry contains a dedicated driver for the device, obtain at least one available version of the dedicated driver; In cases where at least one version is available but multiple versions are available, the dedicated driver with the highest compatibility will be used as the target driver for the device. If at least one version is available, use the dedicated driver for that version as the target driver for the device. If the default driver registry does not contain a dedicated driver for the device, check if the device description file corresponding to the device exists in the default device description file library. If a device description file corresponding to the device exists in the preset device description file library, the device description file will be used as the target driver for the device. If the preset device description file library does not contain a device description file corresponding to the device, the preset generic driver will be used as the target driver for the device.

[0083] In one embodiment, the second generation module 104 is specifically used for: Instantiate and load the corresponding target driver for each device; A tree-like data structure is constructed based on hierarchical path data in structured data; Associate the device with the target driver loaded with the corresponding node in the tree data structure; The tree data structure is rendered into an interactive topology tree view in a graphical user interface, forming a hierarchical topology structure for multiple devices.

[0084] In one embodiment, the device further includes: The third generation module is used to generate version numbers for the hierarchical topology based on a preset version number format. The storage module is used to store the hierarchical topology and its corresponding version number to a preset database.

[0085] In one embodiment, the determining module 103 is further configured to: When a change in the topology version number is detected or a change event notification is received, the changed node is determined in the current topology based on the device attribute information of the changed device. Based on the device attribute information and the structured data corresponding to the change node, the change form of the change node is determined, where the change form is adding a node, deleting a node, or changing data.

[0086] In one embodiment, the device further includes: The update module is used to update the current hierarchical topology based on the change type of the changed node and the device attribute information of the changed device.

[0087] In one embodiment, the acquisition module 101 is further configured to: In response to a topology comparison request, obtain the version numbers of at least two topologies to be compared included in the topology comparison request; Based on the version number, retrieve the target topology structure corresponding to each version number from the preset database.

[0088] In one embodiment, the determining module 103 is further configured to perform node matching on multiple target topologies, determine the difference nodes, and mark the difference nodes in each target topology.

[0089] In one embodiment, the device further includes: The display module is used to visualize the topology of multiple targets with marked differences.

[0090] The device topology construction apparatus 100 provided by this invention automatically acquires the device attribute information of each device and transforms the scattered raw information into structured data of device objects with complete semantics according to a preset data format. Subsequently, it automatically queries the driver registry based on the device's identity data to match the most suitable target driver for each device. Finally, based on the structured data containing the identity data and hierarchical path data of each device, it intelligently matches and mounts device drivers, automatically generating an accurate hierarchical topology structure. This achieves full automation from data acquisition to topology presentation, greatly improving the efficiency and accuracy of topology construction, significantly reducing the workload of manual configuration, eliminating manual input errors and deviations from the actual on-site structure, and ensuring that the topology structure in the management system is highly consistent with the on-site configuration.

[0091] Specific limitations regarding the device topology construction apparatus can be found in the limitations on the device topology construction method described above, and will not be repeated here. Each module in the aforementioned device topology construction apparatus can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the electronic device in hardware form, or stored in the memory of the electronic device in software form, so that the processor can call and execute the operations corresponding to each module.

[0092] In one embodiment, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method for constructing the device topology described above.

[0093] In one embodiment, a computer-readable storage medium is provided, which stores a computer program that, when executed by a processor, implements the method for constructing the above-described device topology.

[0094] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or electronic device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0095] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0096] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the system can be divided into different functional units or modules to complete all or part of the functions described above.

[0097] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A method for constructing a device topology, characterized in that, include: In response to the request to build the device topology, obtain device attribute information for multiple devices; Based on the device attribute information, structured data corresponding to each device is generated according to a preset data format. The structured data includes the identity data of each device and hierarchical path data representing the subordinate relationship between multiple devices. Based on the identity data and the preset driver registry, the target driver corresponding to each device is determined; The target driver is mounted to each device, and a hierarchical topology of multiple devices is generated based on the structured data.

2. The method for constructing the device topology according to claim 1, characterized in that, The step of generating structured data corresponding to each device based on the device attribute information and according to a preset data format specifically includes: The identity field is extracted from the device attribute information of each device, wherein the identity field includes at least one of the following: device tag number, device manufacturer identifier, device model, device version number, device type identifier, and device serial number; Based on the identity field, identity data for each device is generated according to the preset data format; Extract the parent node identifier of each device from the device attribute information; Based on the parent node identifier and the device tag number, a hierarchy network among multiple devices is constructed; Based on the device tag number and the subordinate relationship network, hierarchical path data for each device is generated.

3. The method for constructing the device topology according to claim 1, characterized in that, The step of determining the target driver for each device based on the identity data and the preset driver registry specifically includes: Based on the identity data of each device, determine whether the preset driver registry contains the dedicated driver for each device; For any device, if the preset driver registry contains a dedicated driver for the device, obtain at least one available version of the dedicated driver; In cases where at least one version is available but multiple versions are available, the dedicated driver with the highest compatibility will be used as the target driver for the device. If at least one version is available, use the dedicated driver for that version as the target driver for the device. If the preset driver registry does not contain a dedicated driver for the device, determine whether a device description file corresponding to the device exists in the preset device description file library. If the device description file corresponding to the device exists in the preset device description file library, the device description file will be used as the target driver of the device. If the preset device description file library does not contain the device description file corresponding to the device, the preset general driver will be used as the target driver for the device.

4. The method for constructing the device topology according to claim 1, characterized in that, The steps of mounting the target driver to each device and generating a hierarchical topology of multiple devices based on the structured data specifically include: Instantiate and load the corresponding target driver for each device; Based on the hierarchical path data in the structured data, a tree-like data structure is constructed; The device loaded with the target driver is associated with the corresponding node in the tree data structure; The tree data structure is rendered into an interactive topology tree view in a graphical user interface, forming the hierarchical topology structure of multiple devices.

5. The method for constructing the device topology according to claim 1, characterized in that, After mounting the target driver to each device and generating a hierarchical topology of multiple devices based on the structured data, the process further includes: The version number of the hierarchical topology is generated based on a preset version number format; The hierarchical topology and its corresponding version number are stored in a preset database.

6. The method for constructing a device topology according to claim 1, characterized in that, After mounting the target driver to each device and generating a hierarchical topology of multiple devices based on the structured data, the process further includes: When a change in the topology version number is detected or a change event notification is received, the changed node is determined in the current topology based on the device attribute information of the changed device. Based on the device attribute information and the structured data corresponding to the change node, the change form of the change node is determined, wherein the change form is adding a node, deleting a node, or data change; The current hierarchical topology is updated based on the change type of the changed node and the device attribute information of the changed device.

7. The method for constructing the device topology according to claim 1, characterized in that, Also includes: In response to a topology comparison request, obtain the version numbers of at least two topologies to be compared included in the topology comparison request; Based on the version number, retrieve the target topology structure corresponding to each version number from the preset database; Node matching is performed on multiple target topologies to identify differing nodes, and the differing nodes are marked in each target topology. The topology of multiple targets with marked differences is visualized.

8. A device for constructing a device topology, characterized in that, include: The acquisition module is used to obtain device attribute information of multiple devices in response to the device topology construction request; The first generation module is used to generate structured data corresponding to each device based on the device attribute information and according to a preset data format. The structured data includes the identity data of each device and the hierarchical path data representing the subordinate relationship between multiple devices. The determination module is used to determine the target driver corresponding to each device based on the identity data and the preset driver registry; The second generation module is used to mount the target driver to each device and generate a hierarchical topology of multiple devices based on the structured data.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method for constructing a device topology as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the method for constructing the device topology as described in any one of claims 1 to 7.

Images