Distributed network discovery for industrial control systems

Abstract

A method for decentralized discovery and mapping of network devices connected to at least one Ethernet network and to control network modules to which an industrial distributed control system is connected. The method includes capturing, by the control network module, attributes of the device connected to at least one Ethernet network node using a link layer discovery protocol (LLDP), and constructing a switch data table identifying a medium access control (MAC) address for each port of an Ethernet switch associated with the control network module. The method further includes compiling, by the control network module, a rich neighbor data table for each device connected to the at least one Ethernet network node using the attributes captured by the LLDP and information from the switch data table, and formulating a list of neighbor network devices connected to the at least one Ethernet network node using the rich neighbor data. The control network module constructs a visual representation of the at least one Ethernet network node and its connected devices using a mapping application and a list of neighbor network devices.

Description

Technical Field

[0001] The present disclosure generally relates to industrial control systems. More specifically, the present disclosure relates to a decentralized network discovery and mapping method for an industrial distributed control system. Background Art

[0002] The deployment of industrial process control and automation systems across geographic locations is governed by several factors, such as distance, functionality, and environment. Distributed system architecture allows industrial distributed control systems (DCS) to be expanded and distributed over long distances. Therefore, network equipment (such as Ethernet switches, routers, node interfaces, gateways, firewalls, and network cables) including data and control networks between the assets of the DCS become key components of the DCS. The various network interconnect components used to connect the assets of the DCS support the ability to transmit and receive data and control signals using various transmission protocols such as Ethernet, serial, or wireless. In addition, the network is interconnected using network cables, which are composed of, for example, bundled copper wires or fiber optic cables, interconnecting the DCS assets and network components into, for example, a ring topology, a star topology, or a mesh network topology or a combination of wired and wireless networks to achieve the desired interconnectivity between distributed DCS assets.

[0003] Currently known network discovery and mapping solutions utilized in the industry are centralized solutions that require dedicated servers in their deployment. Key components of such centralized solutions involve: using a specific set of protocols (such as (SNMP) Simple Network Management Protocol) to scan for information about connected devices; using active or passive polling / scanning methods to identify connected devices, such as, for example, active scanning methods involving the use of pings to reach end devices and passive scanning methods that collect available network data (MAC addresses of ports) without sending direct ping requests. Network inventory and subsequent network mapping showing device connectivity enables several operations required to perform additional network management activities, such as, for example, configuration, patching, anomaly detection, and monitoring.

[0004] Centralized architecture solutions for data sharing and retrieval cause several problems due to the centralized nature of their deployment. For example, it presents a single point of failure, thus requiring redundant partners or remote backup, recovery, and migration. It allows limited scalability and increases security risks due to a single centralized architecture. Finally, centralized architectures also increase maintenance costs because the deployed nodes are outside the network that is discovered and mapped. Due to the above-mentioned problems with centralized architectures, network discovery solutions have not been introduced into the layers within industrial control systems where supervision and critical communication operations can be performed, such as Level 0, Level 1, and Level 2 in the Purdue model for industrial control systems. The result of introducing a network discovery solution at a supervisory control layer (such as Level 3 in the Purdue model) is a significant decrease in the accuracy of network management functions and (I / O) input / output communications at the supervisory level.

[0005] It is therefore an object of the present disclosure to provide a decentralized network discovery method for discovering connected devices in an industrial control network and to formulate a graph of discovered network nodes. Summary of the invention

[0006] The present disclosure relates to a decentralized network discovery and mapping method for an industrial distributed control system.

[0007] In a first embodiment, a method for identifying and mapping devices connected to a control and communication network is disclosed. The method includes: using a discovery protocol to capture attributes of the devices connected to the network. The method also includes: using the attributes captured by the discovery protocol and information from a local network switch to compile a table of enriched neighbor data for each device connected to the network. The method uses the enriched neighbor data to formulate a list of neighbor network devices connected to the network. A mapping application uses the list of neighbor network devices to construct a visual representation of the network and the devices connected to the network.

[0008] In a second embodiment, a method for discovering and mapping devices connected to a control and communication network of an industrial distributed control system is disclosed. The method includes: using a link layer discovery protocol (LLDP) to capture attributes of the device connected to an Ethernet network, and constructing a switch data table that identifies the media access control (MAC) address of each port of a local network switch. The method also includes: using the attributes captured by the LLDP and the identified MAC address and port from the switch data table to compile an enriched neighbor data table for each device connected to the network. The method uses the enriched neighbor data to create an initial list of neighbor network devices connected to the network, and requests an additional list of neighbor network devices connected to the at least one network device on the initial list of neighbor network devices. A mapping application uses the list of neighbor network devices to construct a visual representation of the network and the connected devices.

[0009] In a third embodiment, a decentralized method for discovering and mapping devices connected to a plurality of network nodes is disclosed. Each network node includes a control network module connected to an industrial distributed control system. The method includes: using a link layer discovery protocol (LLDP) by the control network module of each node to capture the attributes of the device connected to the network node associated with the control network module of the network node, and constructing a switch data table identifying the media access control (MAC) address of each port of the network switch associated with each device and the control network module of each network node. The method also includes: using the attributes captured by the LLDP and the information from the switch data table of the control network module by each control network module of each network node to compile an enriched neighbor data table for each device of the network node connected to the control network module. The method uses the enriched neighbor data to formulate a list of neighbor network devices of each control network module connected to each network node. At least one control network module uses its own list of neighbor network devices to request a list of neighbor network devices of the network node associated with each control network module. The requesting control network module uses a mapping application and the list of neighbor network devices to construct a visual representation of the plurality of network nodes and the device connected to the network node.

[0010] Other technical features may be apparent to those skilled in the art from the following drawings, descriptions and claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] For a more complete understanding of the present disclosure, reference is now made to the following description taken in conjunction with the accompanying drawings, in which:

[0012] Figure 1 An exemplary industrial process control and automation system is shown;

[0013] Figure 2 An exemplary control node using a mesh topology at the channel level of an I / O module is shown;

[0014] Figure 3 Shows Figure 2 An exemplary control node for using a modular control network node;

[0015] Figure 4 A control network module (CNM) is schematically shown;

[0016] Figure 5 An example method of constructing a switch data table according to the present disclosure is shown;

[0017] Figure 6 An example method for constructing an enriched neighbor data table according to the present disclosure is shown;

[0018] Figure 7 An example method of managing the enriched neighbor table data according to the present disclosure is shown;

[0019] Figure 8 An example method of constructing a My Neighbor Device Table according to the present disclosure is shown;

[0020] Fig. 9 shows an example graphical representation of an Ethernet network developed using the network discovery method of the present disclosure; and

[0021] Fig.10 The present invention is used to construct Fig. 9 This graphical representation is a block diagram of the third key component of the network discovery method. DETAILED DESCRIPTION

[0022] The accompanying drawings discussed below and the various embodiments for describing the principles of the present invention in this patent document are only carried out by way of illustration and should not be construed as limiting the scope of the present invention in any way. Those skilled in the art will appreciate that the principles of the present invention can be implemented in any type of suitably arranged device or system.

[0023] Industrial automation is an important feature of today's industrial processing plants. Industrial process control and automation systems need to continuously provide greater flexibility in the implantation and operation of industrial automation systems. Especially in complex DCS deployments, network interconnection between various assets and components of the DCS becomes a problem. For example, a large number of unmanaged Ethernet switch SKUs increase complexity and do not provide loop detection due to the lack of spanning tree detection methods.

[0024] Figure 1 An example centralized DCS 100 is shown. Figure 1 As shown, system 100 includes various components that facilitate the production or processing of at least one product or other material. For example, system 100 is used herein to facilitate the control of components in one or more plant buildings 101a-101n. Each plant building 101a-101n represents one or more processing facilities (or one or more parts thereof), such as one or more manufacturing facilities for producing at least one product or other material. Generally speaking, each plant building 101a-101n can implement one or more processes and can be referred to as a process system individually or collectively. A process system generally represents any system or part thereof that is configured to process one or more products or other materials in some manner.

[0025] exist Figure 1 In the system 100, the Purdue model of process control is used to implement it. In the Purdue model, "level 0" may include one or more sensors 102a and one or more actuators 102b. Sensors 102a and actuators 102b represent components in a process system that can perform any of a variety of functions. For example, sensor 102a can measure a variety of characteristics in a process system, such as temperature, pressure, or flow. In addition, actuator 102b can change a variety of characteristics in a process system. Sensors 102a and actuators 102b may represent any other or additional components in any suitable process system. Each sensor in sensor 102a includes any suitable structure for measuring one or more characteristics in a process system. Each actuator in actuator 102b includes any suitable structure for operating or affecting one or more conditions in a process system. Sensors and actuators may generally be referred to as field devices or process instruments.

[0026] At least one network 104 is coupled to the sensor 102a and the actuator 102b. The network 104 facilitates interaction with the sensor 102a and the actuator 102b. For example, the network 104 can transmit measurement data from the sensor 102a and provide control signals to the actuator 102b. The network 104 can represent any suitable network or combination of networks. As a specific example, the network 104 can represent an Ethernet network, an electrical serial network (such as a HART or Foundation Fieldbus network), a pneumatic control signal network, or any other or additional type of network.

[0027] In the Purdue model, "Level 1" may include one or more controllers 106 coupled to a network 104. Each controller 106 may use measurements from one or more sensors 102a to control the operation of one or more actuators 102b, among other things. For example, a controller 106 may receive measurement data from one or more sensors 102a and use the measurement data to generate control signals for one or more actuators 102b. Multiple controllers 106 may also operate in a redundant configuration, such as when one controller 106 operates as a primary controller and another controller 106 operates as a backup controller (which is synchronized with the primary controller and can take over the primary controller in the event of a failure of the primary controller). Each controller 106 includes any suitable structure for interacting with one or more sensors 102a and controlling one or more actuators 102b.

[0028] Two networks 108 are coupled to the controller 106. The networks 108 facilitate interaction with the controller 106, such as by transmitting data to and from the controller 106. The networks 108 may represent any suitable network or combination of networks. As a specific example, the networks 108 may represent a pair of Ethernet networks or a pair of redundant Ethernet networks, such as a Fault Tolerant Ethernet (FTE) network from HONEYWELL INTERNATIONAL INC.

[0029] At least one switch / firewall 110 couples network 108 to two networks 112. Switch / firewall 110 includes any suitable structure for providing communications between networks. Network 112 may represent any suitable network, such as a pair of Ethernet networks or an FTE network.

[0030] In the Purdue model, "Level 2" may include one or more machine-level controllers 114 coupled to a network 112. The machine-level controllers 114 perform various functions to support the operation and control of controllers 106, sensors 102a, and actuators 102b that may be associated with a particular piece of industrial equipment, such as a boiler or other machine. Each of the machine-level controllers 114 includes any suitable structure for providing access to, control of, or operations associated with a machine or other individual equipment. Each of the machine-level controllers 114 may, for example, represent a server computing device running a MICROSOFT WINDOWS operating system. Although not shown, different machine-level controllers 114 may be used to control different equipment in a process system (where each equipment is associated with one or more controllers 106, sensors 102a, and actuators 102b).

[0031] One or more operator stations 116 are coupled to the network 112. The operator stations 116 represent computing devices or communication devices that provide user access to the machine-level controller 114, which in turn may provide user access to the controller 106 (and possibly the sensor 102a and actuator 102b). As a specific example, the operator stations 116 may allow a user to view the operation history of the sensor 102a and actuator 102b using information collected by the controller 106 and / or the machine-level controller 114. The operator stations 116 may also allow a user to adjust the operation of the sensor 102a, actuator 102b, controller 106, or machine-level controller 114. Each of the operator stations 116 may, for example, represent a computing device running a MICROSOFT WINDOWS operating system.

[0032] At least one router / firewall 118 couples network 112 to two networks 120. Router / firewall 118 includes any suitable structure for providing communication between networks, such as a security router or a combination router / firewall. Network 120 may represent any suitable network, such as a pair of Ethernet networks or an FTE network.

[0033] In the Purdue model, "Level 3" may include one or more unit-level controllers 122 coupled to a network 120. Each unit-level controller 122 is typically associated with a unit in a process system, which represents a collection of different machines that operate together to implement at least a portion of a process. The unit-level controller 122 performs various functions to support the operation and control of lower-level components.

[0034] Access to the unit-level controller 122 may be provided by one or more operator stations 124. Each of the operator stations 124 includes any suitable structure for supporting user access and control of one or more components in the system 100. Each of the operator stations 124 may represent, for example, a computing device running a MICROSOFT WINDOWS operating system.

[0035] At least one router / firewall 121 couples network 120 to two networks 128. Router / firewall 121 includes any suitable structure for providing communication between networks, such as a security router or a combined router / firewall. Network 128 can represent any suitable network, such as a pair of Ethernet networks or an FTE network.

[0036] In the Purdue model, "Level 4" may include one or more plant-level controllers 130 coupled to the network 128. Each plant-level controller 130 is typically associated with one of the plants 101a-101n, which may include one or more processing units that implement the same, similar, or different processes. The plant-level controller 130 performs various functions to support the operation and control of lower-level components. As a specific example, the plant-level controller 130 may execute one or more manufacturing execution system (MES) applications, scheduling applications, or other or additional plant or process control applications. Each of the plant-level controllers 130 includes any suitable structure for providing access to, control of, or operations related to one or more processing units in a processing plant. Each of the plant-level controllers 130 may, for example, represent a server computing device running a MICROSOFT WINDOWS operating system.

[0037] Access to the plant-level controller 130 may be provided by one or more operator stations 132. Each of the operator stations 132 includes any suitable structure for supporting user access and control of one or more components in the system 100. Each of the operator stations 132 may represent, for example, a computing device running a MICROSOFT WINDOWS operating system.

[0038] At least one router / firewall 134 couples network 128 to one or more networks 136. Router / firewall 134 includes any suitable structure for providing communication between networks, such as a security router or a combination router / firewall. Network 136 can represent any suitable network, such as a full enterprise Ethernet or other network, or all or a portion of a larger network (such as the Internet).

[0039] In the Purdue model, "Level 5" may include one or more enterprise-level controllers 138 coupled to a network 136. Each enterprise-level controller 138 is typically capable of performing planning operations for multiple plants 101a-101n and controlling various aspects of the plants 101a-101n. The enterprise-level controller 138 may also perform various functions to support the operation and control of components in the plants 101a-101n. As a specific example, the enterprise-level controller 138 may execute one or more order processing applications, enterprise resource planning (ERP) applications, advanced planning and scheduling (APS) applications, or any other or additional enterprise control applications. Each of the enterprise-level controllers 138 includes any suitable structure for providing access to, control of, or operations related to one or more plants. Each of the enterprise-level controllers 138 may, for example, represent a server computing device running a MICROSOFT WINDOWS operating system. In this document, the term "enterprise" refers to an organization with one or more plants or other processing facilities to be managed. It should be noted that if a single plant 101a is to be managed, the functionality of the enterprise-level controller 138 can be incorporated into the plant-level controller 130 .

[0040] Access to the enterprise level controller 138 may be provided by one or more operator stations 140. Each of the operator stations 140 includes any suitable structure for supporting user access and control of one or more components in the system 100. Each of the operator stations 140 may represent, for example, a computing device running a MICROSOFT WINDOWS operating system.

[0041] The various levels of the Purdue model may include other components, such as one or more databases. The database associated with each level may store any suitable information associated with that level or one or more other levels of the system 100. For example, a historical database 141 may be coupled to the network 136. The historical database 141 may represent a component that stores various information about the system 100. The historical database 141 may, for example, store information used during production scheduling and optimization. The historical database 141 represents any suitable structure for storing information and facilitating information retrieval. Although shown as a single centralized component coupled to the network 136, the historical database 141 may be located elsewhere in the system 100, or multiple historical databases may be distributed at different locations in the system 100. In certain embodiments, Figure 1 The various controllers and operator stations in the Controllers may represent computing devices. For example, each of the controllers may include one or more processing devices 142 and one or more memories 144 for storing instructions and data used, generated, or collected by the processing devices 142.

[0042] Each of the controllers may also include at least one network interface 146, such as one or more Ethernet interfaces and / or Ethernet switches or wireless transceivers and routers. Additionally, each of the operator stations may include one or more processing devices 148 and one or more memories 150 for storing instructions and data used, generated, or collected by the processing devices 148. Each of the operator stations may also include at least one network interface 152, such as one or more Ethernet interfaces and / or Ethernet switches or wireless transceivers.

[0043] In some DCS deployments, a mesh topology may be employed at the channel level of the I / O modules. Figure 2 An exemplary mesh topology at the channel level of an I / O module is shown in FIG. 1 . The enterprise controller 138, operator station 140, historical database 141, network 136, and controller 106 are described above with reference to FIG. Figure 1 The I / O module 203 has a connection to Figure 1 For simplicity, the multiple channels 102 of the field devices 102a and 102b are shown in FIG. Figure 2 , the I / O interface is not shown as being separate from the I / O module, but is shown as one unit. In addition to the network 136, an I / O network 207 is also shown. The I / O network 207 is a dedicated network. A plurality of controllers 203 are connected to the I / O network 207, while other controllers 203 are connected to the network 136.

[0044] Typically, field devices allow monitoring of manufacturing processes, such as physical properties (such as temperature, pressure, flow, etc.), and provide control of the process, such as opening / closing valves, increasing / reducing pressure, turning up / down heating or cooling units, etc. It is necessary to centralize control and information collection to improve plant efficiency. Each process in a plant has one or more input characteristics (i.e., control characteristics), and one or more output characteristics (i.e., process conditions).

[0045] An automation system using a DCS has its system of sensors, controllers, and associated computers distributed throughout an industrial plant. A DCS system uses methods such as publish / subscribe and request / response to move data from controllers to client servers and applications at the supervisory level. A DCS provides automated decisions based on real-time processing of data or as modified by the user in response to analysis of data collected from a running process.

[0046] In a DCS system, each controller can be assigned to a specific input / output module and a group of channels and field devices associated with the specific input / output module. The grouped channels and associated field devices are fixed by the type of I / O module, the physical location of the I / O module, or the network location of the I / O module. Therefore, flexibility is limited. However, in the current mesh topology network, the relationship between a controller and a group of I / O channels is no longer a constraint relationship between a controller and a group of specific I / O channels defined by an I / O module, but shows the I / O channels of multiple I / O modules that are meshed to a group of control nodes (i.e., controllers).

[0047] The I / O electronics have been decoupled from a specific controller. Specifically, Figure 2 I / O modules are shown, each having a plurality of channels at the channel level of the I / O module, wherein the channels of all I / O modules are connected in a mesh topology. Figure 2 In , not only have the I / O electronics been decoupled from a specific controller, but multiple controllers can be associated with a single I / O module and the channels therein using a mesh topology at the channel level of the I / O module. Each of the multiple controllers can be connected to one or more channels of a single I / O module.

[0048] The I / O grid is especially valuable for engineering efficiency when using Universal I / O Modules from Honeywell Process Solutions. By using technology such as Universal I / O Modules, the channel type is software configured. The types available include Analog Input, Analog Output, Digital Input, and Digital Output.

[0049] By adopting a mesh topology for the channels of the I / O modules, multiple advantages can be achieved. The I / O modules can be located geographically close to the field devices, regardless of which specific controller will use those I / O signals and equipment. This advantage supports the current demand to simplify the design by removing the field wiring box and deploying more I / O in the field compared to the traditional control center and remote instrument enclosure (RIE) deployment.

[0050] Another advantage is the ability to use standard Ethernet as the remote medium, including switching topologies and ring topologies. Using standard Ethernet technology can allow greater flexibility, greater stability and reliability, greater security, and greater scalability. Further Ethernet connections provide greater security at the I / O level and are ISA99 certified. However, the present disclosure is not limited to Ethernet technology.

[0051] In Advanced View, Figure 2A system 200 is included that includes a plurality of I / O modules 203, wherein each I / O module is connected to a plurality of field devices 202 via a channel 102 of the I / O module 203. A channel provides data for an industrial process. Process data from a field device or a process control strategy instruction provided to a field device is referred to herein as a channel. The channel 102 is configured in a mesh topology. Figure 2 A representative field device 202 connected to a plurality of field devices 202 via a channel 102 is shown. Hundreds of field devices 202 can be connected to an I / O module 203 via a channel 102. Field devices 202 are devices for generating process information or for actuating a processing unit by controlling a valve, a regulator, or other processing device. Exemplary field devices 202 can be sensors, actuators, or other processing devices, such as valves, flow controllers, and other equipment. The mesh topology allows signals to and from the channel and thus to and from the field device to reach the necessary controller, regardless of which I / O module the channel is associated with. Multiple controllers can control the outputs of different channels belonging to the same I / O module. Similarly, multiple controllers can control the inputs of different channels belonging to the same I / O module. Connections can be made, for example, via Ethernet technology or wireless technology.

[0052] The system 200 also includes a plurality of controllers 106. Each controller 106 is configured to receive a signal from any one of the plurality of channels 102 in the plurality of I / O modules 203, and transmit the signal to any one of the plurality of channels, wherein the channels 102 are connected in a mesh topology. Just as each channel 102 represents data of a process, the data is designated for a specific controller 106. By configuring the channels 102 in a mesh topology, specific data in a specific channel can be connected to an appropriate specific controller 106, regardless of which I / O module the channel is located in. In other words, data collected from field devices through channels can be used for any controller through the mesh topology of the channels. Similarly, signals or instructions from a controller can be used for any channel through the mesh topology of the channels.

[0053] Each controller 106 generates an information stream for further processing. In some embodiments, the controller 106 can be arranged in an electronic interconnection topology, such as by Ethernet technology. Suitable topologies include, but are not limited to, a ring topology and a star topology. The ring topology includes the interconnection of controllers, wherein each controller communicates with two other controllers. A star topology is one in which one or more controllers are interconnected with the remaining controllers. When these topologies are adopted, it is not necessary to interconnect each controller to all other controllers. In one embodiment, each controller is connected to at least one or two other controllers. Using controller topologies such as these, the controllers can also share information with each other. Exemplary controllers include application control systems, field device managers, remote terminal units, embedded controllers, programmable logic controllers, virtual nodes, or another device for receiving information and sending instructions to field devices 202. The controller 106 can be operated by a man-machine interface or by a pre-programmed automation system.

[0054] The system 200 also includes a network 136, which may be a supervisory control network, to direct information flow to and from the controller 106. The network 136 receives information flow from the controller 106 and transmits control strategy information to the controller 106. When a requesting node needs data from a responding node, it sends a request for the data over the network, and the responding node returns the data over the network. The network 136, as a supervisory control network, includes supervisory control computers and interface hardware to enable communication and control between client servers and industrial plants.

[0055] The system 200 may also include a data center that houses the enterprise controller 138, operator stations 140, and / or a historical database 141 for receiving and storing information streams from the network 136. The sorted data may then be retrieved for analysis. The data storage may be local storage, remote storage, or cloud storage.

[0056] Through the mesh topology of the I / O module channels, Figure 2 It is shown that the connection between the controller 106 and the channels 102 of the I / O modules 203 can be made in a variety of different ways. For example, connection 211 shows the controller 106 connected to different channels 102 of different I / O modules 203. One controller 106 can be connected to multiple channels 102 within the same I / O module 203. The I / O modules connect the I / O to the system through a network. The network can be, for example, a supervisory network or a dedicated I / O network. A controller connected to the network 136 can be connected to the channels 102 of an I / O module that is also connected to the network 136. A controller connected to the network 136 can be connected to the channels 102 of an I / O module that is connected to the I / O network 207 via connection 215.

[0057] Large Ethernet deployments may require a large number of managed Ethernet switch configurations, especially in DCS systems that employ a fault-tolerant Ethernet (FTE) redundant network configuration. For example, in a DCS system employing 150 FTE nodes, 8 pairs of Ethernet switches with 330 ports will be required to interconnect the 150 FTE nodes. This includes a FTE network consisting of 165 primary and 165 secondary switch pairs. In addition, in industrial plants, it is not uncommon to have several pairs of Ethernet or fiber optic cables with lengths between 100 meters and 10 kilometers used in the interconnection of various nodes of the DCS. In a mesh topology network, this interconnection burden in the plant equipment (such as unmanaged network switches and cables) becomes even greater, where the relationship between a controller and a set of I / O channels is no longer a constrained relationship between a controller and a specific set of I / O channels defined by an I / O module, but rather shows the I / O channels of multiple I / O modules that are meshed to a set of control nodes (i.e., controllers).

[0058] Figure 3 A modular system architecture is schematically illustrated that facilitates several functions while reducing complexity during DCS network deployment. Figure 2 The Ethernet network 207 has been replaced by a control network module (CNM) 310 that includes several key architectural elements. These include built-in security, including signed firmware and deep packet inspection protocols. The common platform configuration architecture operates a connectivity component that can configure and operate multiple wired or fiber optic network ports for interconnection to devices and I / O modules and supervisory networks. A mode selection feature allows the user to select a default network port configuration based on the application of the control node. A built-in hardware Ethernet switch provides expansion capabilities to provide network connectivity to other controllers or expansion to other control nodes. The CNM 310 also includes a configuration component that allows the user to easily access and configure new network port functions and easily introduce new connectivity functions into the network served by the control network module.

[0059] The CNM 310 can be configured as a single I / O terminal assembly (IOTA) module or interconnected with another CNM 310 via the backplane of an equipment cabinet or frame or connected together using data and control cables to provide an active system IOTA that can easily interconnect multiple controllers 106 or I / O modules 203. The CNM 310 can also be interconnected in a variety of other configurations, such as, for example Figure 6 The active-passive system (IOTA) deployment shown in Figure 7 The various deployments are explained in more detail below.

[0060] Figure 4Schematically illustrated are components of the CNM 310. The CNM 310 includes a mode component 410, a control component 420, a configuration component 430, a security component 440, an expansion component 450 connected to a plurality of expansion ports 465a-n, a system connectivity port 460, and a plurality of I / O ports 455a-n.

[0061] Mode component 410 acts as a rotary switch that allows a user to select and implement stored pre-programmed deployment functions of operating software 435, such as, for example, security policies and firewalls, virtual LANs (VLANs), and / or quality of service (QoS) networking. Control component 420 is responsible for executing the necessary functions via configuration component 430 based on the mode component selection made by the user. Processor 432 executes operating software 435 that runs the programmed functions of CNM 310.

[0062] The CNM 310 may also be programmed to perform customized network functions when used in conjunction with the configuration component 430. The configuration component 430 consists of configurable hardware and software that enable dedicated customized port configurations to perform dedicated network functions. The configuration component 430 provides an independent interface to the control component 420 to allow for rapid configuration and secure bootstrapping. For example, the configuration component 430 may include a Bluetooth or other wireless communication hardware module that operates a two-way wireless software protocol to establish two-way communication between the CNM 310 and a remotely located handheld device (not shown) such as a smart phone, tablet computer, or laptop PC. A user using a handheld device may directly query the port configuration settings of the I / O ports 455a-n and the expansion ports 465a-n, and set customized port settings such as, for example, port speed, switch port analyzer (SPAN), and VLAN configuration.

[0063] The safety component 440 includes both hardware applications and software applications that provide one or more safety attributes, such as hardware authentication, firewalls, secure boot, signature firmware, and deep packet inspection. When other components of the network module are connected to an external source, the safety component 440 is responsible for ensuring authentication. For example, the safety component will provide appropriate safety authentication to an external handheld device that is connected or attempts to be connected to the configuration module 430. In addition, the safety component monitors I / O ports 455a-n and expansion ports 465a-n, detecting any changes at the ports. The safety component 440 notifies the control component when an irregular condition is detected. Then, the control component can send a status message of the detected irregular condition to a supervisory controller (such as an enterprise controller 138) or to an operator station 140 through the system connectivity port 460 and the network connection 136.

[0064] The expansion components 450 are hardware Ethernet switches that provide a mechanism for horizontally scaling and extending the port connections of the CNM 310. Data and control signals to and from the controller 106 are connected to the expansion components 450 via expansion ports 465a-n and cables 127a-n using a mix of copper or fiber optic cables, using wired or wireless Ethernet or serial network protocols. A software-defined internal network between the expansion components and the expansion components separates the data and control connections into data plane connections 451 and control plane connections 453. The control plane connections 453 are used to pass firmware updates, configuration data, such as, for example, port speed, SPAN, and VLAN, to the expansion components and expansion ports 465a-n. The control plane connections 453 are also used to send status messages from the expansion ports 465a-n to the control components 420, such as, for example, sending notifications of the status and configuration of the ports 465a-n and the operational status of the expansion components 450 to the controller 136 or operator station 140. Since data plane connection 451 does not have the burden of also passing control signals between control component 420 and expansion component 450, data signals traveling on data plane connection 451 travel uninterruptedly at a high rate higher than they would if data signals were shared with control signals.

[0065] The CNM 310 is connected to the I / O modules 203 and devices of the control node through a plurality of connectivity ports consisting of I / O ports 455a-n, and to the supervisory layer of the DCS via a system connectivity port 460. Ports 455a-n and system connectivity port 460 are connected to the control component 420. The system connectivity port 460 provides an "uplink" to the supervisory layer of the DCS via the network connection 136 to provide notifications to the DCS of the status and / or changes of the control network module 310. This can include, for example, cable breaks or reconnection of new device connections and disconnections, as well as any changes in port speed. In addition, notifications can be sent to the DCS to monitor the port discard rate and abnormal traffic rate of the connected I / O module 203 or another connected device in order to attempt to connect an unknown device to the I / O ports 455a-n and to shut down the port due to a MAC flapping / loop condition. Based on the type of I / O module 203 or other device connected to the control node, connections are made to and from the I / O modules 203 using cables 126a-n to I / O ports 455a-n using a mix of copper or fiber optic cables, using either wired or wireless Ethernet or serial network protocols.

[0066] Described above and in Figure 4The CNM 310 shown in the figure can be configured as a single I / O terminal assembly (IOTA) module or interconnected with another CNM 310 via the backplane of an equipment cabinet or frame to provide an active system IOTA that can be easily interconnected to multiple I / O modules 203 and controllers 106 in a DCS control node. Alternatively, two network control modules 310 can be connected together using data and control cable connections.

[0067] The present disclosure uses the decentralized network architecture just described with a data collection and mapping method that discovers connected devices connected to an Ethernet network and can provide a graphical representation of the devices connected to the network to a user. The data discovery method of the present disclosure overcomes the limitations and complexity of centralized network discovery methods and provides network management capabilities at the supervisory and IO communication levels without affecting communications on the Ethernet network.

[0068] The present disclosure uses the following three key components to establish a decentralized network discovery and mapping method for devices connected on an Ethernet network. The first component of the discovery method uses the Link Layer Discovery Protocol (LLDP) with specific vendor-customized Type Length Values ​​(TLVs) to locate network devices located in any neighboring nodes. The second component uses the information captured from the LLDP vendor-customized TLVs and uses local network switch information to build rich neighbor data. The third component uses a process to parse the Ethernet network, which then allows the construction of a graphical representation of devices that depict multiple nodes connected to the Ethernet network.

[0069] In the first component, based on IEEE 802 technology, the device connected to the network 136 uses LLDP to announce the identity and capabilities of any neighboring device on the wired Ethernet local area network. The CNM 310 connected to the control node will exchange LLDP packets with the neighboring CNM 310 in another node. The LLDP packet supports attributes for learning information about neighboring devices contained in the control node and connected to the Ethernet network. These attributes have a limited format called type length value (TLV). Devices that support LLDP can use TLV to receive and send information with their neighbors. For example, the attribute can contain the media access control (MAC) address of the sending device, the hardware or physical address of the device, and the Internet Protocol (IP) address of the device connected to the network using the Internet Protocol for communication. The TLV can also include a device type attribute, which identifies and represents the current device connected to the Ethernet network, such as, for example, a device operating at a specific port speed or having an identification icon used when representing a device on a DCS. Other information that can be defined by the TLV can include a network time protocol NTP server IP address, a virtual local area network (VLAN) ID, and a node ID. Based on the vendor's definition, VLAN and Node IDs are used to identify a VLAN or a node using a numeric string.The information provided by the LLDP data packet is stored in the CNM 310 as vendor node information and used in subsequent components of the network discovery method.

[0070] In the second component of the network discovery method (such as Figure 4 In the control component 420 and the extension component 450 of the CNM 310 shown in FIG. 1 , the compilation of neighbor data is based on information available locally on the network node, which comes from two key sources: incoming LLDP messages and local Ethernet switch information. The local Ethernet switch function that allows data to be passed through the local Ethernet switch also stores a MAC table (such as Table 1) containing the MAC address and port number of the Ethernet switch associated with the CNM 310. The data contained in the local switch will be read by the network discovery method and used as an initial data structure.

[0071] MAC Address Port Number Aa 3 Bb 6 Cc 1 … …

[0072] Table 1 .

[0073] Figure 55. A method 500 for building a switch data table (such as Table 1 above) is shown in FIG. 5. In method 500, the CNM 310 reads the MAC table 510 of the local Ethernet switch at an assigned time interval 505 (such as every 60 seconds). In step 515, the data read from the local Ethernet switch is cleaned to map the MAC address to the local CNM 301 user port number and remove any internal ports. After this cleanup step 515, the MAC address is queried in step 520. This query 520 determines whether the MAC address exists on the network. If the MAC address does not exist, the entry is captured and recorded in step 525 and entered into the local switch data table along with the MAC address and port number. If an entry exists in the local switch data table, the port number is updated 530 if it is different. For all MAC addresses that are not available in the local switch data table, these addresses are deleted from the local Ethernet switch in step 535.

[0074] The method uses the LLDP information and the local switch data of Table 1 to construct an enriched neighbor data table, such as Table 2 shown below.

[0075] MAC Address Port Number Device Type Node ID IP address firmware Aa 3 CNM 41 10.0.0.32 v1.8.9 2 other Abcs 192.168.0.5 Version Information …

[0076] Table 2

[0077] Table 2 is constructed by CNM 310 upon receiving the LLDP message. Table 2 includes information of the device, such as, for example, the MAC address, port number, device type (e.g., whether the device is a CNM), IP address of the device, and firmware version loaded in the device. Figure 6 A block diagram 600 of a method for constructing the enriched neighbor data table shown in Table 2 is shown. In a first step 610, data is first parsed from the received LLDP packet. Next, in step 610, the MAC address of the device is looked up using the local switch data of Table 1. In step 615, the MAC address of the entry is entered into the enriched neighbor data table using the following logic. In step 625, if the entry does not exist, a record is created in the enriched neighbor data table using the MAC address and port number of the device. If the MAC address exists in the enriched neighbor data table, then in step 620, any updates or changes to the data associated with the device are entered into the enriched neighbor data table.

[0078] The auxiliary My Neighbor data table is further constructed for use by the third component of the network discovery method of the present disclosure. The My Neighbor device table (Table 3) is as follows.

[0079] Port Number Device Type Neighboring Devices 1 CNM "CNM Details" 2 other "MAC address of the device" 4 other "null" 3 … …

[0080] Table 3

[0081] Figure 7 A method 700 is shown for managing the enriched neighbor data of Table 2. The method 700 manages the enriched neighbor data table to ensure that the data in Table 2 is correct and valid before using it to build the My Neighbor Devices table of Table 3. This will provide the mapping application with the most up-to-date information.

[0082] In method 700, a local counter is periodically set once in step 705 for each set time period (such as, for example, every 30 seconds). The counter is set to start from 0 and incremented by all port numbers contained in Table 3. The counter is incremented in step 715. In step 720, a decision step is performed to verify whether the device should still exist in the enriched neighbor data table 2. If all ports have been verified, the method 700 ends. However, if more ports need to be verified, the program branches to a decision step 730 where the MAC address is still available in the network. For example, if the MAC address is not available, the MAC address is deleted in step 740, and the counter is incremented in step 710 to verify the next port. If the MAC address exists, the MAC address is verified in step 735 to ensure that the MAC address of the port number is correct. The MAC address is verified against the port number entered in the local switch data table. After the port number is verified, the method jumps to step 715 and increments the counter to verify the next port in the enriched neighbor data table.

[0083] Figure 8 A method 800 is shown for building a My Neighbor Device Table as shown above in Table 3. The graphical application of the third component of the network discovery method uses Table 3 to help build a graphical representation of the devices connected to the Ethernet network.

[0084] The counter is set to start at 0 in step 805 and incremented by all port numbers for each port of CNM310 contained in Table 3 in step 810. In step 815, the port number is checked to confirm whether an LLDP device is connected to the port. This is done by querying the local switch data from Table 1 for the checked port in step 820. If no MAC address is associated with the port, then in step 830, a "null" text designation or label is added to Table 4. In step 835, if a single MAC address is encountered, an entry is created in my neighbor device table using the MAC address of the device sending the LLDP data. This is shown in the table under the neighbor device column "MAC address of the device" to be listed. A single entry represents an end node without LLDP capability. If two or more entries are encountered, such as MAC 1, MAC 2, MAC 3, etc., the first 2 or 3 MAC addresses are entered into the neighbor device column to report several MAC addresses that are not LLDP connected.

[0085] If an LLDP connection mode is encountered in step 815, and if the device type is known based on the query in step 840 (e.g., a CNM, such as CNM 301 as a neighboring device), an entry is created in Table 3 using the node icon. The icon is received as a TLV attribute in the LLDP packet. However, if the device type is unknown, a MAC address is constructed for the unknown device in step 850, and an entry is created in my neighbor table using the constructed MAC address. If more than one LLDP device is found to be connected to a particular single port, a data string consisting of, for example, a series of MAC addresses (e.g., MAC 1, MAC 2, MAC 3) is used as an entry for the port. After step 835 or step 850, the method branches back to step 810, and the counter is incremented to the next port connected to the CNM until all ports have been checked for CNM 310.

[0086] Fig. 9 A graphical representation of an Ethernet network developed using the third key component of the network discovery method of the present disclosure is shown. The third component uses a drawing application that can be loaded in the CNM 310 or executed on the operator station 140. The drawing application constructs a schematic diagram or graph for an Ethernet network of nodes using the My Neighbor devices of Table 3. Fig. 9 The example schematic diagram of shows a sample secure network 900 that may be displayed by a drawing application. In this exemplary schematic diagram, an Ethernet network shows a plurality of network nodes, each of which includes a CNM configured to manage secure IO modules 903. CNM 1 acts as a secure network controller for CNMs 2-4.

[0087] As a network controller, CNM 1 is connected to the DCS via FTE switch 910 and to the security management system controller 915. Switch 910 and controller 915 are connected to CNM 1 through the supervisory network 136. This graphical representation will be similar to what you would see when you connect to the Figure 4 The same network diagram that a user would see when connecting a portable device of the configuration component 430 of the CNM 310 in the node to any of the CNMs 1-4 within the node. Alternatively, the network diagram may be displayed at the operator station 140. The visibility of the different connected nodes of the network enables the user to perform a number of network management activities from any of the CNMs on the network.

[0088] Fig.10 A block diagram 950 of a third key component of a network discovery method and used by the present disclosure to construct a graphical schematic diagram is shown. In step 955, each CNM or non-LLDP device entry in the My Neighbor Device Table for a first CNM is copied to a pending CNM list. Next, in step 960, the method either selects the next CNM on the copied CNM list to process, or exits loop 965 when no more CNMs or non-LLDP devices are encountered. In step 970, the next CNM in the pending CNM list is queried for its own My Neighbor Device Table. The information contained in the My Neighbor Device Table is parsed, and any new or updated CNMs or any non-LLDP devices contained in the queried CNM My Neighbor Device Table are added to the pending CNM list. In step 980, the graphical application uses the pending CNM list to capture previously discovered devices into other CNMs. The method branches back to step 960 to process the next CNM entry on the My Neighbor Device Table until all entries in the table have been processed. When completed, the graphical application constructs a Fig. 9 Schematic representation of the network shown.

[0089] It may be advantageous to set forth the definitions of certain words and phrases used throughout this patent document. The terms "include" and "comprising" and their derivatives are meant to include, but are not limited to, this. The term "or" is inclusive, meaning and / or. The phrase "associated with..." and its derivatives may mean including, included within, interconnected with, contained within, connected to, or connected with, coupled to, or coupled with, communicable with, collaborate with, interlaced, juxtaposed, close to, coupled to, or combined with, have, have the property of, have a relationship with, or have a relationship with. When used with a list of items, the phrase "at least one of..." means that different combinations of one or more of the listed items may be used, and only one item in the list may be needed. For example, "at least one of A, B, and C" includes any combination of A, B, C, A and B, A and C, B and C, and A and B and C.

[0090] The description in this application should not be construed as implying that any particular element, step, or function is an essential or critical element that must be included within the scope of the claims. The scope of subject matter protected by a patent is limited only by the claims as allowed. In addition, none of the claims is intended to invoke 35 U.S.C. §112(f) with respect to any of the appended claims or claim elements, unless the exact words "means for..." or "step for..." followed by a participle phrase identifying the function are expressly used in a particular claim. The use of terms such as (but not limited to) "mechanism", "module", "device", "unit", "component", "element", "member", "device", "machine", "system", "processor" or "controller" within the claims is understood and intended to refer to structures known to those skilled in the relevant art, as further modified or enhanced by the features of the claims themselves, and is not intended to invoke 35 U.S.C. §112(f).

[0091] Although the present disclosure has described certain embodiments and generally associated methods, changes and permutations of these embodiments and methods will be apparent to those skilled in the art. Therefore, the above description of the exemplary embodiments does not limit or restrict the present disclosure. Other changes, substitutions and variations are also possible without departing from the spirit and scope of the present disclosure as defined in the following claims.

Claims

1. A method for identifying a network device connected to a communication network and displaying a graphical representation of the network device, the method comprising: capturing attribute data of the network devices connected to the communication network using a discovery protocol; compiling a neighbor data table for said network device connected to said communications network using said attribute data captured by said discovery protocol and information from a communications network switch; as well as using the neighbor data table to formulate a neighbor device table listing the network devices connected to the communication network, Wherein a drawing application uses the neighbor device table to construct a graphical representation of the communication network on a display. 2 . The method of claim 1 , wherein the capturing step uses a Link Layer Discovery Protocol (LLDP) to capture the attribute data of the network device.

3. The method according to claim 2, wherein the method further comprises: A switch data table is constructed that identifies a media access control (MAC) address for each port of the communications network switch.

4. The method of claim 3, wherein the step of compiling the neighbor data table uses the attribute data captured by the LLDP and the identified MAC addresses and ports from the switch data table.

5. The method of claim 4, wherein the neighbor data table is used to construct the neighbor device table containing the MAC address, port number, network device type, and the network connection to a neighboring network device.

6. The method of claim 5, wherein the drawing application uses the neighbor device table to construct the graphical representation of the communication network and the network devices connected to the communication network on the display of a display device.

7. An apparatus for discovering a plurality of network devices connected to a communication network and displaying graphical representations of the plurality of network devices on a display device, the apparatus comprising: a control network module, the control network module being communicatively coupled to the plurality of network devices; a first component, the first component being executed by a control component of the control network module arranged to capture attribute data of the plurality of network devices; a second component executed by the control component of the control network module arranged to construct a switch data table identifying a media access control (MAC) address of each port of a communications network switch associated with each of the plurality of network devices and using the attribute data and the switch data table to construct a neighbor data table for the plurality of network devices connected to the communications network; as well as A third component is executed by the control component of the control network module arranged to use the neighbor data table to construct a neighbor device table, the neighbor device table being arranged to build the graphical representation of the communication network on the display device.

8. The apparatus of claim 7, wherein each of the plurality of network devices uses a Link Layer Discovery Protocol (LLDP) to exchange communication packets with the control network module, the communication packets containing the attribute data of each network device connected to the control network module.

9. An apparatus according to claim 8, wherein the attribute data includes at least the MAC address of the sending network device, the network device type, the network device physical address and the Internet Protocol (IP) address of the network device, and the second component uses the attribute data received by the control network module from each network device and the MAC address and port number of the communication network switch associated with the control network module to construct the switch data table.

10. The apparatus of claim 9, wherein the second component uses the attribute data captured by the LLDP and the port number from the switch data table to build a neighbor data table for the plurality of network devices connected to the communication network, and the second component uses the neighbor data table to build a neighbor device table for each MAC address of the communication network, the neighbor device table containing the port number, the network device type, and the network connection to a neighboring network device.

Images