Node management for node communication networks of highly versatile field devices in control and automation systems

Abstract

A node communication network of a process control or factory automation system includes nodes, which are highly versatile (HV) field devices that store corresponding tag identifiers. A DHCP server assigns corresponding endpoint identifiers to nodes connected to the network. A network node manager manages a mapping database and a status database, the mapping database stores the association between the tag identifiers of network nodes and the assigned endpoint identifiers, and the status database stores the update status of network nodes. A DNS server responds to requests for endpoint identifiers in conjunction with the network node manager to allow nodes to be discovered within the network. The HV device node is a data source that establishes and maintains (sometimes simultaneously) corresponding communication sessions with one or more other nodes over the network, the one or more other nodes being consumers of data generated by the HV device, and the data transmitted via the communication session can be used to control an industrial process.

Description

Technical Field

[0001] The present application relates generally to process control and factory automation systems, and more particularly to enhanced field devices used in these systems that are capable of performing a variety of different functions simultaneously in different contexts and are capable of communicating with different or separate client devices or applications using one or more different communication protocols. Background Art

[0002] Distributed process control systems, such as those used in chemical, petroleum, industrial, or other process plants for manufacturing, refining, converting, generating, or producing physical materials or products, typically include one or more process controllers communicatively coupled to one or more field devices via a physical layer, which may be an analog, digital, or combined analog / digital bus, or may include one or more wireless communication links or networks. Field devices may be, for example, valves, valve positioners, switches, and transmitters (e.g., temperature, pressure, level, and flow rate sensors) that are located within a process environment and typically perform physical process control functions, such as opening or closing a valve, measuring process and / or environmental parameters, such as flow, temperature, or pressure, etc., to control one or more processes performed within the process plant or system. Smart field devices, such as those conforming to the well-known Field devices that use the Fieldbus protocol may also perform control calculations, alarm functions, and other control functions typically performed within a controller. A process controller is also typically physically located in a plant environment, receives signals indicating process measurements made by field devices and / or other information related to the field devices, and executes control applications such as running different control modules that make process control decisions, generate process control signals based on the received information, and coordinate with control modules or blocks being executed in field devices such as and Fieldbus field devices. In order to perform this communication, the control module in the process controller sends control signals to various input / output (I / O) devices, which then send these control signals to actual field devices via dedicated communication lines or links (communication physical layer), thereby controlling the operation of at least a portion of a process plant or system, for example, controlling at least a portion of one or more industrial processes that are run or executed within the plant or system. The I / O devices that are usually also located in a factory environment are usually arranged between the process controller and one or more field devices, and for example, by converting electrical signals into digital values ​​and converting digital values ​​into electrical signals to achieve communication therebetween. Different I / O devices are provided to support field devices using different dedicated communication protocols. Specifically, different I / O devices are provided between the process controller and each field device using a specific communication protocol, so that a first I / O device is used to support a HART field device, a second I / O device is used to support a Fieldbus field device, and a third I / O device is used to support a Profibus field device, etc. As used herein, field devices, controllers, and I / O devices are usually referred to as "process control devices," and are usually located in, provided with, or installed in the field environment of a process control system or a plant.

[0003] Furthermore, information from field devices and process controllers is typically made available to one or more other hardware devices, such as operator workstations, personal computers or computing devices, data historians, report generators, centralized databases, or other centralized management computing devices, through the process controllers via a data highway or communication network. These devices are typically located in a control room or other location away from the harsher field environment of the plant, for example, in the back-end environment of the process plant. Each of these hardware devices is typically centralized across the entire process plant or a portion of the process plant. These hardware devices run applications that, for example, enable operators to perform functions related to controlling the process and / or operating the process plant, such as changing settings for process control routines, modifying the operation of control modules within controllers or field devices, viewing the current state of the process, viewing alarms generated by field devices and controllers, simulating the operation of the process for the purpose of training personnel or testing process control software, maintaining and updating configuration databases, and the like. The data highways used by the hardware devices and process controllers can include wired communication paths, wireless communication paths, or a combination of wired and wireless communication paths, and typically use packet-based communication protocols and non-time-sensitive communication protocols, such as Ethernet or IP protocols.

[0004] As described above, a process control system can include multiple field devices that provide many different functional capabilities within a plant, and these field devices are typically communicatively coupled to a process controller using one of a variety of specialized physical interfaces or physical layers of communication interfaces developed specifically for process control. For example, a common process control communication physical interface uses a two-wire interface that is established in a point-to-point wiring connection arrangement (e.g., only one field device is communicatively coupled to a specific wired interface) or in a multi-drop wiring connection arrangement (e.g., multiple field devices are communicatively coupled to a wired interface). However, some field devices may be connected to the controller using a wireless communication physical layer that may include a wireless gateway and transmitter / receiver devices. Furthermore, field devices are typically configured to communicate with the process controller using one of a variety of highly specialized communication protocols. These communication protocols are typically digital signal protocols, but can also be analog protocols (e.g., 4-20mA protocol) or combined digital and analog protocols (e.g., HART protocol). Some of these protocols operate using relatively simple commands and / or communications (e.g., the ON and OFF commands used in the CAN protocol), while other protocols are more complex and require more commands and / or more communication information, which may or may not include simple commands. For example, more complex protocols may use, for example, a Highway Addressable Remote Transducer (HART). Communication protocols to transmit analog values ​​with digital communications superimposed on the analog values. Other field devices may use fully digital communications that provide many types of communications (e.g., Fieldbus communication protocol). Other process control communication protocols include the PROFIBUS communication protocol, although additional process control communication protocols have been developed and are currently in use. Each of these communication protocols requires or requires support by a specific physical layer, which may include a two-wire, four-wire, or other physical layer, specific switches, etc. In addition, the physical layer may specify maximum or minimum wire lengths, wire thickness, wire type, terminal type, other electrical characteristics, etc. However, it is important that field devices are configured to communicate using a single protocol and have a unified interface for communicating using the communication protocol and the physical layer associated with that protocol.

[0005] Due to the development of these various field device communication protocols, each of which typically utilizes different communication lines (physical layers) and signaling formats, various field devices (e.g., field devices using different protocols) are communicatively coupled to a process controller via different input / output devices (I / O devices), each of which conforms to a different one of the process control protocols and supports a specific type of physical layer. That is, a typical plant may have a controller coupled to a plurality of different I / O devices, including a Fieldbus I / O device (which in turn couples to one or more FOUNDATION Fieldbus field devices via a two-wire or four-wire bus conforming to FOUNDATION Fieldbus), a HART I / O device coupled to each of one or more HART-compliant field devices via a separate two-wire or four-wire single-drop connection, a CAN I / O device coupled to one or more CAN-compliant field devices via a CAN-compliant wiring connection, and so forth.

[0006] Furthermore, coupling the communication ports of field devices to the terminal blocks of the I / O devices, and ultimately to the process controllers in the process plant, is often a complex process. Field devices must be coupled to I / O cards, which convert signals received from the field devices into signals that can be processed by the process controller, and convert signals received from the controller into signals that can be processed by the field devices. Consequently, each channel of each I / O card corresponding to a particular field device must be associated with an appropriate signal type (in order for the signal to be properly processed by the I / O card), and the I / O card must be communicatively coupled to a controller or controllers, which will ultimately receive signals from and / or send signals to the field devices coupled to the I / O card.

[0007] As described above, each field device uses a specific communication medium or physical layer (e.g., a two-wire cable, a wireless link, or optical fiber) via a terminal block on the I / O device, and is also coupled to the I / O device using one of the above or other specialized process control communication protocols (HART, CAN, WirelessHART, FOUNDATION Fieldbus, PROFIBUS, etc.) that have been developed in the process control industry. Furthermore, the I / O devices are typically connected separately to the process controller via another bus or wired connection. The use of these different input / output devices means that the physical and logical connections between the different field devices must be accurately mapped so that the controller connected to the different I / O devices can track which field devices are connected to which port of each input / output device in order to transmit signals to that field device via the correct "path." This problem is particularly troublesome in the HART protocol, in which each field device is connected to a different output port of the HART-compliant I / O device. In addition, communication with process control field devices must be carried out through defined communication paths, which typically include communication between the field device and a dedicated I / O device (typically via a first communication protocol), communication between the I / O device and the process controller (via a second and different communication protocol), and communication between the process controller and a user device or application (e.g., a process control operator application, a process control configuration application, etc. located in a server or other user interface device, via yet another different communication protocol). In any case, all communications to and from the field device are routed or sent through the I / O device and the process controller via a dedicated communication path (link). Therefore, all data to and from the field device must be sent through the process controller and one or more I / O devices. In this case, the process controller must initiate and coordinate all messages or communications to and from the field device via designated links from the process controller to the I / O device and from the I / O device to the field device. This configuration provides a high degree of security because all applications seeking to communicate with the field device must be able (and authorized) to communicate with the process controller, which then acts as a proxy or server for information from the field device. In addition, external applications cannot communicate directly with the field device.

[0008] While process control field devices typically use specialized communication hardware and protocols, it is well known that communications between certain other devices within a process plant are performed using general-purpose IP or other packet-based communication protocols. For example, a packet-based or general-purpose IP protocol is typically used over an Ethernet bus that communicatively connects one or more distributed process controllers to one or more user interfaces, databases (e.g., configuration databases and history databases), servers, etc. within a back-end plant environment. Thus, Ethernet (which is both the physical layer and part of the data link layer) is an important communication platform for automation systems because it enables flexibility, scalability, and performance in a way previously unseen in automation. To help support the adoption of Ethernet in automation, the Advanced Physical Layer (APL) specification is being designed to support the connection of field devices in remote and hazardous locations. Following APL is the IEEE P802.3cg project, which focuses on the development of enhancements to the existing IEEE 802.3 Ethernet standard (IEEE 802.3) for Ethernet over twisted-pair cabling (10BASE-T1L). This development is important because there is a long list of automation protocols developed for various purposes that can operate on top of the Ethernet physical layer.

[0009] To support this emerging trend toward Ethernet-based communication in process control, the FieldComm group has standardized HART-IP as part of HART version 7. Although HART-IP was originally designed to allow hosts to communicate efficiently with gateways, it has now emerged as a method for devices to communicate directly with I / O servers and hosts / controllers. HART-IP is already used in monitoring, control, diagnostics, and condition monitoring applications. Because HART-IP already has a complete description of the devices it supports, it is a good protocol for layering above APL. Another protocol gaining widespread support at the device level is OPC Unified Architecture (OPC UA). Although OPC UA itself does not understand device communications and types, considerable effort is underway to provide some level of support in this area. While HART-IP and OPC UA may see relatively rapid market adoption, they will not be alone in their use. Other protocols, such as Ethernet IP and PROFINET, are already available on Ethernet and will be able to run on APL when they become available. Furthermore, IT-driven protocols such as MQTT and AMQP will emerge as important protocols as the Industrial Internet of Things (IIoT) gains acceptance.

[0010] However, in process plants that already include an installed base that relies heavily on more traditional field devices (such as HART or FOUNDATION Fieldbus field devices), supporting Ethernet or other advanced physical layers, such as those associated with packet-based or general-purpose IP communication protocols, is difficult and not straightforward because these various communication protocols will need to be synthesized or merged somewhere in the process control network via one or more electronic marshaling cabinets or devices. It is not currently clear how to integrate these advanced protocols in a typical process plant architecture so that they can operate in a reliable and robust manner.

[0011] Furthermore, in addition to control systems, other systems have been developed to support other activities within process plant and manufacturing automation environments. Plant asset management (PAM) or maintenance systems are typically configured to enable maintenance personnel to perform maintenance activities on equipment (such as field devices, but also other types of equipment) within a plant or manufacturing facility setting. PAM is used to configure and provision equipment, run diagnostics on equipment once deployed, monitor equipment alarms, and perform a long list of other functions. Furthermore, condition monitoring systems are becoming increasingly common and are being deployed in many locations. Condition monitoring systems can perform a variety of functions, including energy monitoring, equipment and device monitoring, and process monitoring. These condition monitoring systems typically stream data from the plant, perform condition monitoring, and provide feedback to users and, in some cases, to the control system itself. Similarly, data logging systems exist within plant and manufacturing automation settings to collect and record data for later use. For example, energy and monitoring data can be collected centrally by a data logging system for analysis and to establish an alarm management system, for example, if water leakage or energy loss due to a leak or rupture in a pipe is detected. Likewise, smart metering systems are being implemented in many settings to perform ongoing or continuous metering. Metering can be a critical process in large-scale distributed systems such as oil and gas fields, pipelines, chemical storage, and finished product storage. For example, in a chemical storage system, it is important to have accurate readings about what materials are present. Smart metering refers to the process of installing smart meter reading systems, reading these meters through controllers or independently through remote monitoring systems, and transmitting the readings to a processing location such as an edge gateway or a central data server. Additionally, environmental monitoring needs to be performed in many settings based on safety considerations, EPA mandates or regulations, etc. For example, many plants have environmental reporting requirements, such as reporting of NOx, SOx, and other items, and it is critical that the data from these systems is time-stamped, not affected by daylight saving time adjustments, and is secure.

[0012] In any case, these other systems are in many cases dedicated systems that perform data collection, calculations, and reporting in a manner separate from the process control system. In these cases, these systems require their own infrastructure, wiring, communication paths, communication protocols, etc. In some cases, such as in a plant asset management system, these systems can communicate with and use some or all of the process control field devices. However, in these cases, the application, server, or other data collection device must communicate with the field device via the process controller using various dedicated field device protocols and physical layers installed for the field device to obtain data from the field device, send messages to the field device, and perform other activities related to the field device. Similarly, in these cases, the process controller (and typically, one or more I / O devices) participates in and is responsible for performing communications with the field device to support these other systems, and the field device itself does not have the specific knowledge or ability to directly support these other systems. This technology places the process controller in the middle of the communication with the field device and is responsible for performing communications with the field device to support other applications or uses other than process control, such as maintenance activities, continuous monitoring, metering, etc. This additional load can make the process controller less effective or can cause communication with specific field devices to be lost or slowed because the process controller needs to prioritize the communications that are necessary or required in any particular situation. Furthermore, this situation makes the field devices much less effective in supporting multiple uses. Summary of the Invention

[0013] A new and highly versatile (HV) process control or factory automation field device is configured with an interface and communication connection structure that enables the field device to operate as a data server that directly or indirectly communicates with and supports multiple different applications or clients while simultaneously performing standard process and factory automation control functions. In addition, various different process control and factory automation network architectures, particularly communication architectures, support the universal field device to enable the universal field device to simultaneously communicate with multiple different client devices or applications (each associated with a different system) using the same or different communication protocols via a common communication network infrastructure. In one embodiment, the communication architecture uses an IP-based communication protocol and infrastructure that is directly connected to the highly versatile field device, and the communication architecture can use one or more switches to route IP communications from / to the field device to other client devices, such as process or factory automation controllers, condition monitoring systems, plant asset management systems, data logging systems, etc. In this case, the highly versatile field device can be connected to one or more client devices (e.g., process or factory automation controllers, PAM system devices, data logger systems, etc.) via an APL network (first-level network) through a switch, and then to a second-level network using another IP-based packet communication protocol, such as Ethernet. These one or more systems (e.g., process controllers of a process control system, PAM servers of a PAM system, data logger databases, condition monitoring applications of a condition monitoring system, etc.) can communicate directly with the highly versatile field device via the second-level network, the switch, and the first-level network to gain access to the highly versatile field device or directly obtain data from the highly versatile field device.

[0014] In other cases, various client devices and applications may be connected to a third-level control network, which is connected to the second-level control network via a second switch that can achieve security or isolation from the second-level network. Other client devices or applications may be associated with non-control systems, such as PAM systems, data logging systems, monitoring systems, etc. In yet another embodiment, the third-level network may be connected to an edge gateway device via a firewall, which can connect the third-level network to various applications or devices in the cloud or other remote locations, thereby enabling client devices in the cloud or other remote locations to access field device data as clients of the field devices via various networks using communication connections based on IP packet communication.

[0015] In yet another scenario, cloud-based applications and devices (clients) can be connected directly to a first-level network via a first-level network switch (such as an APL power switch) to provide support for applications at remote sites. This support can include process or factory automation controllers located in the cloud, and can include other applications or devices associated with other systems such as PAM systems, data logging systems, condition monitoring systems, etc. In another scenario, highly versatile field devices can be installed in a more traditional process control architecture that includes the use of traditional or legacy field devices connected to an APL network or other IP-based communication network located in the factory. In yet another scenario, the highly versatile field devices can be connected to a flat network via a first-level, IP-based communication network (such as an APL network) to which process controllers, operator stations, application stations, databases, and engineering stations associated with process control and other systems (e.g., PAM systems, data logging systems, condition monitoring systems) are connected.

[0016] The highly versatile (HV) field devices and network architecture described herein can support APL or other Ethernet or general IP-based physical layers and various communication protocols running on them in a manner that enables the highly versatile field devices to act as servers for multiple different client devices simultaneously. In addition, when protocols such as security protocols require additional handshakes, confirmations, etc., the highly versatile field devices described herein can nest protocols within other protocols for use. In addition, the highly versatile field devices described herein include configuration capabilities that enable easy configuration of process control systems by supporting multiple I / O types, including packet-based, IP-based, or other high-level protocols such as HART-IP, OPC UA, Ethernet, and the like. The highly general field devices and associated network architecture described herein support mixed physical layer and multi-protocol support, which can be used to achieve improved control while providing direct support for non-control systems because the highly general field devices described herein are capable of supporting request / response, publish / subscribe, event-based communication, reporting communication, and streaming communication, which greatly helps to support a combination of control and Industrial Internet of Things (IIoT) applications (also generally referred to as monitoring systems in this article) that are interested in measurement and actuator data, its capabilities, its diagnostics, and information that can be determined by the combination of these measurements, capabilities, and diagnostics.

[0017] Furthermore, the highly versatile field device is highly secure because it includes multiple security features that make it more secure in the more open communication environments it is intended to be used in. These security features may include, for example, a root of trust feature, a secure boot feature, and an endpoint identity feature, secure storage, encryption capabilities, secure communications, secure device provisioning features, and secure audit functionality, all of which are combined in the field device to provide a high level of security not previously available in process control field devices.

[0018] Therefore, highly versatile (HV) field devices can be nodes of a process control and / or automation network as described herein, which is generally referred to as a node communication network in this article. Node communication networks generally support packet-based, IP-based or other high-level protocols for communicating information between nodes of the network. New nodes such as new HV field devices can join the node communication network and be discovered by other nodes, and each node is identified by a unique endpoint identifier within the node communication network. Thus, in an embodiment, a system for managing nodes of a node communication network of a process control or automation system includes a network node manager communicatively connected to the node communication network, and a domain name service (DNS) accessible to the network node manager. The network node manager includes a mapping database that stores an association between corresponding tags or identifiers of multiple devices used in the process control or automation system and corresponding endpoint identifiers of multiple devices used in the node communication network, wherein the multiple devices include one or more highly versatile (HV) field devices. Each of the one or more HV field devices has corresponding one or more physical components that perform one or more corresponding physical functions during the runtime operation of the process control or automation system to control, for example, an industrial process. The network node manager also includes a state database that stores the corresponding states of the multiple devices. The DNS of the system provides a response to a request for an endpoint identification of a particular device among the plurality of devices via the node communication network, wherein the response is generated based on a mapping database and a state database of a network node manager.

[0019] Furthermore, since highly versatile (HV) field devices can join a node communication network and be discovered, in an embodiment, the highly versatile field device includes one or more physical components that perform physical functions to control an industrial process within a process control or automation system, a communication interface to the node communication network, one or more processors, and one or more non-transitory memories in which a tag or identifier corresponding to the HV field device has been provisioned and stored. The one or more non-transitory memories further store computer-executable instructions that, when executed by the one or more processors, cause the HV field device to perform the following operations: upon power-up of the HV field device, detect that the HV field device is connected to the node communication network via the communication interface; and transmit a request for an endpoint identification of the HV field device to a DHCP server of the node communication network via the node communication network, wherein the request includes an indication of the tag or identifier corresponding to the HV field device. Execution of the computer-executable instructions by one or more processors causes the HV field device to further: obtain, from the DCHP server via the node communication network, an endpoint identifier assigned to the HV field device by the DCHP server; and establish a communication session with another device on the node communication network using the endpoint identifier assigned to the HV field device, wherein the other device is a consumer of data generated by the HV field device, and the generated data corresponds to a physical function performed by the HV field device during runtime operation of a process control or automation system. Furthermore, execution of the computer-executable instructions causes the HV field device to transmit data corresponding to a physical function performed by one or more physical components of the HV field device to the other device via the established communication session during runtime operation of the process control or automation system, thereby controlling an industrial process.

[0020] In an embodiment, a method at a highly versatile (HV) field device of a process control or automation system includes: detecting, by the HV field device, upon power-up of the HV field device, that the HV field device is connected to a node communication network via a communication interface of the HV field device, the node communication network having nodes identified by corresponding endpoint identifiers within the node communication network. Furthermore, the method includes transmitting, by the HV field device, via the node communication network, a request for an endpoint identifier to a DHCP server of the node communication network, identifying the HV field device within the node communication network by means of the endpoint identifier, wherein the request includes an indication of a tag or identifier of the HV field device, and the tag or identifier identifies the HV field device within the process control automation or automation system; and obtaining, by the HV field device, from a DCHP server via the node communication network, an endpoint identifier assigned to the HV field device. Furthermore, the method includes establishing, by the HV field device, a communication session with another device on the node communication network and using the endpoint identifier assigned to the HV field device, wherein the other device is a consumer of data indicating physical functions performed by one or more physical components of the HV field device during runtime operation of controlling an industrial process of the process control or automation system. Furthermore, the method includes transmitting, by the HV field device to another device via the communication session, data indicative of physical functions performed by one or more physical components of the HV field device during runtime operation of the process control or automation system, thereby controlling the industrial process.

[0021] Furthermore, the use of highly versatile (HV) field devices in a node communication network, combined with the above-described device discovery method, benefits from complex network resource management schemes that can be implemented in the node communication network. In an embodiment, a controller controls a physical device in an industrial process or factory automation plant that performs operations on one or more raw materials to convert the one or more raw materials into products. The HV field device is coupled to the controller and receives commands from the controller and transmits parameters to the controller. The communication network includes an advanced physical layer (APL) infrastructure - APL wiring, (one or more) APL power switches that provide connectivity and power via the APL wiring, and (one or more) APL field switches that receive power from (one or more) APL power switches and distribute power and connectivity to the HV field devices, and also includes a network resource management component that is configured to manage network resources on the communication network to facilitate communication of network traffic on the network, the network traffic including managed network traffic known to the network resource management component and unmanaged network traffic unknown to the network resource management component.

[0022] In various embodiments, the network resource management component implements a deterministic management scheme, while in other embodiments, the network resource management component implements a non-deterministic management scheme. Some embodiments of the network resource management component that implement a deterministic management scheme implement a time-sensitive networking (TSN) network management scheme, in which both TSN-based and non-TSN devices can operate on the communications network. In embodiments, the deterministic network resource management component allocates network resources to allow time-critical data to be transmitted between a source and a destination with minimal congestion. In some embodiments, the network resource management component includes one or more outbound ports. Each outbound port includes multiple queues, each accommodating a corresponding class of network traffic. A queue selection unit for each outbound port is configured to receive input data and determine which queue to place the input data into, while a transmission selection algorithm is configured to select which data to take from each of the multiple queues. Each queue has an associated gate, and a gate control list determines which of the multiple gates is open. If a gate is closed, transmission of the data is blocked even if the transmission selection algorithm has already selected data for transmission, thereby giving priority to data other than the data with the highest assigned priority. In an embodiment, a time-aware shaper controls or synchronizes the gate control list of each egress port to create a clear communication channel for ultra-low latency data transmission.

[0023] In an embodiment implementing a non-deterministic network resource management component, the network resource management component includes an interface that controls network traffic passing through a switch port by enabling and disabling the port and throttling the network passing through the port, particularly when the network traffic is identified by source, destination, and application type. A flexible runtime model is used to allocate network resource usage and, in an embodiment, is used to optimize the allocation of network resources across the network as new devices join the communications network, in part by controlling one or more APL field switches and / or power switches. In an embodiment, a certain percentage of network resources is allocated to unmanaged network traffic, and the network resource management component adjusts the switch when the detected percentage of unmanaged traffic exceeds the allocated percentage.

[0024] In an embodiment, a method for managing network resources in an industrial process control or factory automation system includes implementing a controller that controls physical devices in the system. The controller is configured to perform operations on one or more raw materials to convert the materials into products and to communicate with a plurality of highly versatile (HV) field devices coupled to the controller via a communication network to receive commands from the controller and transmit parameter values ​​to the controller. The method also includes configuring a communication network using one or more APL power switches to facilitate communication of network traffic over an APL medium, each APL power switch configured to provide connectivity to other devices and each APL power switch including a power supply to provide power via the APL medium. Furthermore, the method includes using one or more APL field switches, each APL field switch receiving power from one of the one or more APL power switches via the APL medium, and each APL field switch configured to distribute both communication signals and power signals to HV field devices communicatively coupled to the corresponding APL field switch via the APL medium. The method also includes configuring a network resource management component to manage network resources on the communication network to facilitate communication of traffic on the network, the traffic including managed network traffic known to the network resource management component and unmanaged network traffic unknown to the network resource management component.

[0025] Implementing highly versatile (HV) field devices in a node communication network, in combination with the above-described device discovery method, also benefits from a new method for establishing communication between an application and the HV field device and between the HV field device and other HV field devices. In an embodiment, a method includes receiving a message from a first client device or application at the HV field device indicating a selection of a first publication category from a plurality of publication categories, the first publication category corresponding to the type of information desired by the client device. The HV field device transmits an identification of each of a plurality of publication lists corresponding to the first category in the plurality of publication categories to the first client device or application. The plurality of publication lists are stored on the HV field device, and each publication list is a set of parameters associated with the HV field device. The HV field device receives a selection of a first list from the plurality of publication lists identified by the HV field device from the first client device or application, and thereafter transmits a set of parameters associated with the first publication list from the plurality of publication lists to the first client device or application.

[0026] In various embodiments, the publication categories include monitoring and control categories and / or condition monitoring categories. In embodiments, the publication lists may include manufacturer-defined publication lists, user-defined publication lists, and / or customized publication lists. In embodiments, the method further includes receiving, at the HV field device, a message from a second client device or application indicating a selection of a second publication category from a plurality of publication categories, and transmitting, from the HV field device to the second client device or application, an identification of each publication list in a second plurality of publication lists corresponding to the second publication category from the plurality of publication categories received from the second client device or application. The method further includes receiving, at the HV field device, from the second client device or application, a selection of one of the second plurality of publication lists identified by the HV field device, and thereafter transmitting, from the HV field device to the second client device or application, a parameter set associated with the selection of one of the second plurality of publication lists received from the second client device or application. In embodiments, receiving the selection of one of the plurality of publication lists from the first or second device or application further includes receiving an update rate specifying a frequency with which the parameter set associated with the one of the publication lists is to be transmitted from the HV field device to the respective client device or application.

[0027] In various embodiments, an HV field device or a control or automation system including such an HV field device may be configured to perform these methods. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] Figure 1 is a block diagram of a highly general field device as described herein.

[0029] Figure 2 An APL network is shown in which highly versatile field devices as described herein may be used.

[0030] Figure 3 A first example communication architecture is shown that uses an APL network to support access by multiple client applications / devices to a highly versatile field device.

[0031] Figure 4 A second example communication architecture is shown that uses an APL network to support access by multiple client applications / devices to a highly versatile field device.

[0032] Figure 5 A third example communication architecture is shown that uses an APL network to support access by multiple client applications / devices to a highly versatile field device.

[0033] Figure 6 A fourth example communication architecture is shown that uses an APL network to support access by multiple client applications / devices to a highly versatile field device.

[0034] Figure 7 A fifth example communication architecture is shown that uses an APL network to support access by multiple client applications / devices to a highly versatile field device.

[0035] Figure 8 Shown in Figure 1 A block diagram of the various safety features and components implemented in a highly versatile field device.

[0036] Figure 9 A block diagram illustrating an example system for managing nodes of a node communication network of an industrial process plant or manufacturing plant automation system, which may include Figure 1 and Figure 8 One or more highly versatile field devices.

[0037] Figure 10 shows the initial connection of a highly versatile field device to the Figure 9 First example message flow that may occur when nodes communicate on a network.

[0038] Figure 11 shows the initial connection of a highly versatile field device to the Figure 9 A second example message flow that may occur when nodes communicate on a network.

[0039] Figure 12 Shown for use such as Figure 9 Block diagram of an example security architecture for a node management system of a node communication network such as the node communication network shown in .

[0040] Figure 13 A block diagram of a node management system of a node communication network including a plurality of network node managers is shown.

[0041] Figure 14 A block diagram of network management components that may be configured to manage network traffic in the disclosed communications architecture is shown.

[0042] Figure 15 Shown by Figure 14 A block diagram of an example outbound port of a network device managed by a network management component.

[0043] Figure 16 It is through Figure 14 Figure 1 is a diagram of two example data flows for a controlled network managed by a network management component.

[0044] Figure 17 A block diagram depicting various components of a publish-subscribe communication architecture is shown.

[0045] Figure 18 Shown by Figure 17Example communication flow diagram for the publish-subscribe communication architecture. DETAILED DESCRIPTION

[0046] Now refer to Figure 1 , a highly versatile (HV) field device 10 is generally shown in block diagram form. Specifically, the highly versatile field device 10 includes field device hardware 12, which can be, for example, one or more sensors, actuators, valve seats and valve stems, or any other typical or desired control hardware associated with the operation of the field device. The control hardware 12 can be any combination of hardware typically associated with any type of control device, such as sensors (e.g., temperature sensors, flow meters, liquid level sensors, pressure sensors, etc.), valves or other flow gas or liquid flow control structures, igniters, fans, motors, actuators, pumps, etc. The control hardware 12 can be, for example, a control structure that measures or senses one or more physical phenomena in a factory or manufacturing plant setting, or controls or influences one or more physical phenomena in a factory or manufacturing plant setting, and can be any control hardware associated with any known control field device.

[0047] In addition, the highly versatile (HV) field device 10 includes a computer processor 14, computer memory 16, a hardware communication interface 18, an external communication interface 20 (which is connected to the physical layer of an external communication network, not shown), and a power supply 22. Generally speaking, the hardware communication interface 18 uses any desired communication technology or protocol, including any proprietary protocol or technology, any open process control protocol or technology, such as HART, FOUNDATION Fieldbus, CAN, Profibus, etc., to enable communication between the processor 12 (specifically, one or more applications or routines stored in the memory 16 and executed on the processor 12) and the field device hardware 12. The communication interface 18 can be an internal input / output device that multiplexes and / or conditions signals from the hardware device 12 and converts these signals for reading by or transmission to the processor 14, or vice versa. The communication interface 18 can convert signals from the processor 14 to be transmitted to control or affect the operation of the hardware 12 in any known or desired manner, and can likewise convert signals from the hardware 12 to the processor 14 in any known or desired manner. Furthermore, the processor 14 may execute one or more hardware control applications 30 (which may be stored in the memory 16 ) to communicate with, control, read signals from, change settings of, etc. any or all of the field device hardware 12 . The hardware control applications 30 may be stored in ROM or RAM of the memory 16 , and / or may be implemented as an ASIC, an executable application, or in any other desired manner.

[0048] Furthermore, the power supply 22 is preferably coupled to the communication interface 20, and more specifically, to the physical layer of the bus or wired network to which the field device 10 is connected, receives power from the physical layer in the form of an electric current (e.g., a DC current), and converts the electric current into a power signal (typically, one or more voltage signals), which is provided to various other components of the device 10 to power these devices as needed. The power supply 22 is capable of providing sufficient power to the processor 14 to enable the operation of the processor 14 as described herein. Furthermore, the power supply 22 can power the memory 16, the interface 18, and one or more field device hardware components 12. If desired, the power supply 22 can include a battery or be entirely composed of a battery. If the power supply 22 includes a battery, the battery can be charged by a power signal provided via an external wired communication network. In other cases, a battery can be used to provide power to the field device 10, and the communication network to which the field device 10 is connected can be a wireless network. In this case, the communication interface 20 can be a wireless communication interface including an antenna and a wireless receiver.

[0049] Additionally, the memory 16 may store one or more communication applications 32 that execute on the processor 14 and control communications with external devices via the communication interface 20. The communication applications 32 may be programmed to use any known or standard format, such as XML, JSON, etc., and may perform communications over one or more different communication networks, such as wired networks, wireless networks, etc., using known or standard communication protocols.

[0050] Importantly, the processor 14 of the device 10 is sufficiently powerful to host and execute an operating system (OS) 34 stored in the memory 16, and the OS 34 is typically executed in real time on the processor 14, so that the applications 30 and 32 can be executed on the processor 14 in a structured manner as separate applications that share processor resources. In particular, the OS 34 can be a general-purpose operating system, such as the Linux operating system, or a real-time operating system (RTOS), including any of a variety of lightweight operating systems, such as the ThreadX operating system. A variety of different applications 32 and processor and communication loading techniques will be discussed in more detail below. In any case, the processor 14 can execute any number of different communication applications 32 and / or can enable any communication application 32 to establish multiple and different communication threads or agents (also referred to as communication processes) that execute simultaneously in the processor 14, which enables the universal field device 10 to communicate simultaneously (i.e., in an overlapping manner) with different external applications (generally referred to herein as client applications or client devices), and these applications can be in the same or different external devices, hosts, or servers connected to the field device 10 via the communication interface 20. Of course, the communication interface 20 may conform to any desired standard communication protocol or paradigm, such as an IP or packet-based protocol, such as TCP, UDP, HTTP, HTTPS, TLS, DTLS, or the like.

[0051] As will be appreciated, during operation, the OS 34 executing on the processor 14 may establish and manage a communication stack 38, such as a TCP, UDP, or other IP or packet-based stack, to perform external, packet-based digital communications via the communication interface 20. In addition, the OS 34 may establish and manage multiple different communication threads (processes) that may run simultaneously (and at the same or different speeds) via the communication interface 20 and the underlying communication stack 38. In particular, as Figure 1 As shown, the OS 34 can establish various communication threads 40 that implement the same or different higher-level or more specialized communication protocols, such as the HART-IP protocol, an OPC protocol such as the OPC UA protocol, an email protocol, or any other type of communication protocol used by different types of external applications for various purposes. Thus, the OS 34 running on the processor 14 can create, manage, and destroy (stop using) various different communication threads 40 (also called communication processes or sockets) during operation, where the threads 40 run simultaneously to provide communication with different external devices and applications. The various different threads 40 can use the same or different higher-level communication protocols to more efficiently communicate with different clients (i.e., external devices or applications). Figure 1In the example shown, the OS 34 manages four threads 40, wherein a first of the threads 40 uses HART-IP, which can be used to communicate with a process controller that uses field devices to perform process control, wherein a second and third of the threads 40 run the OPC UA protocol and communicate with a device maintenance system and a data monitoring system, and wherein a fourth of the threads 40 uses an email protocol to communicate with an email server to send emails to one or more people. Of course, any number of threads 40 can be created and run simultaneously, and each thread can use one of any number of different communication protocols to communicate with a variety of different types of client devices and applications, such as process or automation controllers, maintenance systems, monitoring systems, data collection systems, general communication systems such as email systems, text systems, Internet-based communication systems such as Twitter and Facebook, and the like.

[0052] Thus, as will be appreciated, the highly versatile field device 10 can store and execute different modules, applications, or routines that enable the device 10 to communicate with different client devices and / or applications via the communication interface 20, thereby supporting a variety of different uses and enabling multiple different client systems (such as control systems, maintenance systems, monitoring systems, etc.) to access the same or different field device information within the device 10 (e.g., information from or about the field device hardware device 12). Communications with these various client systems can use different higher-level communication protocols that are packetized using the underlying IP communication stack 38 based on the specific needs of the client application. For example, some protocols, such as HART-IP, are more suitable for control applications and control communications because HART-IP generally provides faster, more reliable, and real-time data streaming. Other protocols, such as OPC UA, are more suitable for monitoring or maintenance applications because they provide more diagnostic capabilities without the need for fast or real-time communication. Other protocols may enable the device 10 to efficiently provide or construct web pages for client devices to enable users to browse device information from the device 10, send emails or texts, communicate with external networks or public networks such as the Internet, or provide other device information in other formats for different client applications and purposes. In addition, the communication system of the highly versatile field device 10 and the OS 34 may enable communication connections between the field device 10 and external client devices to be established independently of each other, without the other client systems being aware of which other systems are accessing or communicating with the highly versatile field device 10.

[0053] In some cases, the application 30 can access and obtain data from the field device hardware 12 and can store this data in the random access memory 16 of the device 10. Depending on its purpose or function, the application 32 can access the data in the memory 16 and publish this data to one or more external devices or client applications. In other cases, the application 32 can enable authorized client devices to view or even change the configuration data or settings of the field device hardware 12. Typically, the control system can include an application that communicates with an authorized controller to change the settings of the field device hardware 12 and change the configuration of the hardware 12. Similarly, applications associated with a PAM system can enable authorized users to view device data and change device configuration settings to run other applications on the device (such as calibration applications, test applications, etc.). Other systems, such as monitoring systems, may have more limited access to the device hardware 12 or to the device data stored in the memory 16.

[0054] In one example embodiment, the application or module 32 may be or include a device model that is mapped to a specific communication protocol. As an example, the application 32 may use OPC UA communications and APIs and may include a device model that is mapped to OPC UA via a profile. The device model enables the application 32 to be configured to provide certain device data and functionality (according to the device model) so that it can be accessed by external client devices using a specific communication protocol or paradigm.

[0055] Thus, for example, an application 32 may use a Process Automation Device Information Model (PA-DIM), which may be accessed by any client application capable of opening a client / server connection to a field device 10 and subscribing to data publications. While the general concepts of PA-DIM have been defined by the FieldComm Group (FCG) working group, current device information models do not support control, extensions for condition monitoring, standard publish / subscribe lists, and templates for supporting customized publish / subscribe lists. In this case, a PA-DIM for use in a highly versatile field device 10 may be implemented on top of or in addition to existing field device hardware and communication interfaces. Here, the PA-DIM may be capable of communicating in a specific protocol, such as OPC UA, which is compatible with IP packet-based communication protocols and may be used to standardize the information available from the field device 10.

[0056] Generally speaking, the highly versatile field device 10 is configured to operate in a field environment of a factory or manufacturing plant and, for example, includes support for a high-level protocol operating over an open physical layer to perform communication between the field device and one or more client devices, which may be devices associated with any number of different systems, such as a control system, a maintenance system, a monitoring system, etc. Thus, the client device may be a process controller (associated with a control system), a maintenance application or server (associated with a device or plant maintenance system), a monitoring application or server (associated with a monitoring system), and / or other systems.

[0057] In one embodiment, the highly versatile (HV) field device 10 can communicate via an advanced physical layer (APL). For example, Figure 2 An APL-based network 80 is shown in which a highly versatile field device 10 can be used to provide support for multiple client applications and devices. The APL network 80 supports a variety of field devices 82 (any or all of which can be Figure 1 APL is a highly versatile field device 10) that provides communication between a field device (e.g., a controller, a server, a user interface device, etc.) and any other device (e.g., a controller, a server, a user interface device, etc.) using packet-based or high-level (e.g., common IP-based) communication protocols. Importantly, APL provides a two-wire physical communication layer (two-wire bus) that supports both digital communication and power delivery to the devices connected to the physical layer. Unlike previous control-specific communication physical layers (e.g., those associated with protocols such as FOUNDATION Fieldbus, HART, Profibus, CAN, etc.), APL provides sufficient power (in the form of voltage and current) on the two-wire bus to power a microprocessor based on a common or higher-level operating system (e.g., a microprocessor based on a common or higher-level operating system) within a field device connected to the APL physical layer or bus. Figure 1 This higher power level is required to enable a processor with the functionality to run a general purpose or real-time OS, such as the one referenced above. Figure 1as described. However, APL does not provide so much power (particularly voltage) over the two-wire physical layer that it is dangerous to use it in hazardous environments due to the risk of sparks. Therefore, APL has enough power to power process control devices with microprocessors running operating systems such as real-time operating systems, but not enough power to cause potential safety issues in actual process control environments where field devices are located. Generally speaking, an APL network provides approximately 1.4 watts of power to each device (on the branch line) at 14 volts or less, preferably 10 volts or less. In addition, an APL network provides a two-wire reinforced physical layer or wire by using 14 gauge stranded wire, which makes the wiring less susceptible to braking in the field and enables more power (current) with lower voltage levels due to the reduced resistance. Furthermore, APL supports traditional Ethernet-based communications in the form of IP-based or packet-based digital communications, making APL communications readily usable in other types of applications besides control applications, and thereby extending the communications power of traditional Ethernet down into process control or factory automation environments or factories without the drawbacks of the Ethernet physical layer (which typically provides 48 volts over thin or higher gauge single strand wiring).

[0058] Although the APL network is described as a communication network connected to a highly versatile field device in this article, other communication networks may also be used to connect to and power a highly versatile field device. Generally speaking, such a network preferably uses a cable of 14 gauge (.06 inch diameter) or lower (e.g., 12 gauge, 10 gauge, etc.), and also preferably uses a twisted cable to provide better power transmission with a stronger and more flexible cable. Further, these networks preferably provide 14 volts or less and more preferably 10 volts or less power to limit the occurrence of sparks in hazardous areas. Equally, these networks should preferably provide a power of at least 200 milliwatts, and in some cases can provide a power of up to 2 watts to each device. In other embodiments, the network can provide a power of at least 300 milliwatts to the device, and can provide a power of up to 4 watts. More preferably, the network provides a power of between 1 and 2 watts to the field device with a voltage between a maximum of 10 to 14 volts, although lower voltage can be used, and the network for powering the field device can provide a power higher than the power (wattage) specified herein.

[0059] exist Figure 2In a system, the network 80 includes an APL power switch 84 that is connected to a control system (e.g., a process controller) and / or other applications 90 in the cloud or other network via, for example, an Ethernet or other bus 85. The cloud application 90 can be or can include any one or all of the applications of a variety of different systems, such as control applications (controllers) associated with the control system, maintenance applications associated with the maintenance system, monitoring applications and devices (servers) associated with the monitoring system, etc. As an example, the cloud application 90 can include simulation applications, control applications, data storage and processing applications, etc. In any case, the APL power switch 84 includes an APL power device that provides power via an APL physical layer, and the APL power switch 84 acts as a gateway to the APL network 80, and in particular, acts as a gateway to various APL field switches 86 that are connected to the APL power switch 84 via a bus or wired network 88 that conforms to the APL physical layer standard. As Figure 2 As shown, the bus or network 88 can be a trunk line, or it can be a ring connection, as shown by the dashed portion of the bus 88. In any case, the bus 88 is an APL physical layer, including, for example, a two-wire or four-wire wired network, which provides communication signals and power signals from the APL power switch 84 to the APL field switches 86. In addition, each APL field switch 86 has one or any other number of highly versatile field devices 82 connected thereto via an appropriate APL physical layer or link 92. As an example, the APL link 92 can comply with the APL specification and can be a two-wire or four-wire bus that provides or enables the transmission of communication signals and power signals between the APL field switch 86 and the field devices 82.

[0060] Of course, the APL power switch 84 acts as a gateway to the bus 85 and operates to multiplex signals from external sources onto the link 88 using the communication protocol established for the network 80. Similarly, the power switch 84 is operable to decode messages from any field switch 86 on the link 88 and addressed to a destination outside the network 80 (which may be messages from the field devices 82) and send these messages onto the link 85. Similarly, the APL field switch 86 decodes the message on the link 88 and, if addressed to one of the field devices 82 connected to the field switch 86, places the message on the branch or link 92 for transmission to the field device 82. Similarly, the field switch 86 receives messages from the field device 82 via the link 92 and places these messages on the link 88 for transmission to another field switch 86 or the power switch 84. Generally speaking, the field devices 82 are all APL-compatible field devices because they use the APL physical layer and the communication protocol supported by the APL physical layer (e.g., the IP communication protocol) to communicate via the links 92 and 88. The field devices 82 may also receive power via the link 92 , with that power being provided from the field switch 86 , and ultimately from the APL power switch 84 and its associated power supply through the bus 88 .

[0061] In one example, Figure 2 The APL (physical layer) can be a ruggedized, two-wire, loop-powered Ethernet physical layer that uses 10BASE-T1L plus extensions for installation in operating conditions and hazardous areas of process plants. In this case, the APL power switch 84 provides connectivity between all standard Ethernet networks and field devices and includes a power supply to provide power to the APL field switch 86 and field devices 82. Typically, the power switch 84 will be located in a control room or in a junction box located on a slide. Similarly, the APL field switch 86 can be designed for installation and operation in hazardous areas. The field switch 86 is loop-powered by the APL power switch 84 and distributes communication signals and power to the field devices 82 via branch lines 92. The Advanced Physical Layer (APL) project was initiated to create a protocol-neutral Ethernet that can solve the problem of discovering long-distance Ethernet protocols. As described herein, this physical layer can be used in process automation and process instrumentation equipment to connect field devices in remote and hazardous locations, for example, and operates to extend the Ethernet physical layer that operates at 10 Mb / sec over a single pair of cables. Furthermore, APL extends 10BASE-T1L for use in hazardous areas, which enables the development of standards related to typical protection methods, especially intrinsic safety.

[0062] so, Figure 2The network 80 may use any communication protocol supported by the APL, such as any protocol supported by an Ethernet connection. These protocols include, but are not limited to, the Internet Protocol (IP), packet-based protocols, time-sensitive and non-time-sensitive protocols, and the like. Specifically, these protocols may include HART-IP, OPC UA, and any other desired protocols designed for process control communications. Similarly, these protocols may include protocols not traditionally used in process automation, such as general-purpose IP protocols, including protocols that support request / response, publish / subscribe, and event-based communications, as well as data streaming.

[0063] The use of network 80 illustrates one method for implementing the APL physical layer and supported communication protocols in a process control system or factory automation environment to communicate between field devices (such as field device 82) and other devices (such as process controller 11 or Figure 2 84 and other devices on the network 85 / 90). Of course, in other cases, the process controller can be directly connected to the APL power switch 84 to provide communication with the power switch using the APL physical layer, and thereby perform communication between the field devices 82 and the controller (e.g., controller 11) using the APL physical layer. In addition, while power can be provided in or associated with the APL power switch 84 and can send power to the field switch 86 via the bus 88, the APL field switch 86 can be powered separately or can include its own power supply or source and power itself and the field devices 82 via the APL spur line 92.

[0064] Generally speaking, Network 80 is used to support the process control or factory automation system environment. Figure 1 One or more highly versatile field devices 10 or Figure 2 An example of a way to independently network field devices 82 to provide communications within a process control or factory automation system using more traditional IP-based communication protocols, while also providing communications (e.g., traditional IP-based communications) between highly general field devices and other systems such as maintenance systems, monitoring systems, etc.

[0065] However, it is also possible to integrate the APL physical layer (and the IP communication protocols that use it) within an existing plant or manufacturing plant network. Specifically, the entire I / O system can be used in the field environment of a plant or manufacturing plant to support multiple I / O types, while maintaining the plant's more traditional I / O architecture and simultaneously supporting multiple different systems directly from the highly versatile field devices. Typically, the highly versatile field devices 10 provide or support a hybrid physical layer that can support multiple different communication protocols, including traditional process control protocols and more commonly used or general IP-based protocols, while also supporting multiple different systems in a direct client / server relationship. This versatility results in improved control, while supporting a combination of control and Industrial Internet of Things (IIoT) applications (which are typically interested in measurement and actuator data), their capabilities, and their diagnostics.

[0066] Figure 3 One example of a more traditional factory and plant automation control architecture incorporating or supporting the highly versatile (HV) field device 10 described herein is shown in FIG. Figure 3 The plant 100 includes process automation (PA) and factory automation (FA) components and control devices connected to one or more process and factory automation controllers via a communication network backbone such as an Ethernet communication network. Figure 3 As shown, a plant 100 includes a plant automation area or section 102 and a process automation area or section 104. The plant automation section 102 is shown as including a single APL network 106 having a control topology that reflects how instrumentation and control are typically set up in an automated plant. However, in this case, the APL network 106 is used to connect each of a set of different FA highly versatile (HV) field devices 108 and 110 to a common or shared network backbone 112, which can be, for example, 100 megabit (M) or Gigabit Ethernet. The APL network 106 includes an APL power switch 114, which is connected to an APL field switch 116 and a plurality of FA highly versatile field devices 110 via, for example, a 100M APL network connection 120, and includes an APL field switch 116 connected to each of a set of discrete FA highly versatile field devices 108.

[0067] Similarly, the process automation portion 104 includes an APL power switch 122 connected to two APL field switches 124A and 124B via, for example, a 10M APL network connection 126 . Figure 3The APL field switch 124A is shown connected via a trunk line to two highly versatile PA field devices 128 and an adapter device 130, which is connected to a legacy field device (in this case, a HART 4-20mA field device 132) and acts as an input and output device for the legacy field device. Similarly, the APL field switch 124B is shown directly connected to the two highly versatile PA field devices 128 and is also connected to an APL field switch 124C, which is in turn connected to two highly versatile (HV) field devices 128. Of course, the highly versatile field devices 108, 110, 128 communicate via their respective APL networks 104 and 106 with devices connected to the network backbone 112 via the APL power switches 114 and 122. In this way, highly versatile field devices 108, 110, and 128 can be communicatively connected to one or more controllers 140 on the network backbone 112 via a variety of different APL field switches and APL power switches using different APL-supported physical layers (or communication networks with different speeds), while performing control in process and factory settings using conventional control techniques.

[0068] However, if Figure 3 As shown, the network backbone 112 is connected through a switch 142 to another network 144 to which other plant or factory applications and assets can be connected. In particular, as Figure 3As shown, plant asset management devices 145, one or more operator consoles 146, and one or more databases 148 (e.g., control configuration and history databases) can be connected to a network 144, which in this case can be a Gigabit Ethernet network. The devices 145-148 can communicate with the controller 140 via a network switch 142 and directly with the highly versatile field devices 108, 110, and 128 on the APL networks 104 and 106 via the APL power switches 114 and 122. In addition, the plant asset management system 145 can include an asset management application 150 that obtains data from the various highly versatile field devices 108, 110, and 128 (e.g., by subscribing as a client). In addition, other applications 151 and / or 152 and / or devices 154 (such as computer devices such as servers or hosts) associated with other systems (e.g., monitoring systems, data logging systems, etc.) can be connected to the network 144 and act as clients of various data available from the highly versatile field devices 108, 110, and 128. Thus, for example, the plant asset management system 145 can execute one or more asset management applications 150 (in the device 145 or in other devices connected to the networks 144 and 112), which can discover and register with any of the highly general field devices 108, 110, and 128 to obtain data from them as clients (the field devices 108, 110, and 128 operate as servers for their internal data and information). Similarly, other applications 151, 152 can discover and register with the field devices 108, 110, and 128 and subscribe to data from them. Once registered with the field devices 108, 110, and 128, the plant asset management application 150 or other applications 151, 152 can communicate directly with the field devices 108, 110, and 128 via the network 144, the switch 142, and one of the APL power switches 114, 122, and possibly one or more of the field switches 116, 124A-C. This architecture enables the process automation and factory automation controller 140 to use the field devices 108, 110, 128 to control the factory and manufacturing plant floor without having to manage or serve as a conduit for communications for other systems, such as a plant asset management system implemented in the device 145. However, in this case, the switch 142 acts as a security switch (e.g., a firewall) so that authorized applications and users can access the network 112 (and, by extension, the APL networks 104 and 106 and their associated field devices) only when authorized or using appropriate security techniques.

[0069] Of course, although Figure 3The system 100 shows four highly versatile FA field devices 108 and 110 connected via a single APL network 106, and shows six highly versatile PA field devices 128 connected via a single APL network 104, but each of the factory automation and process automation systems may include any number of highly versatile field devices connected to the controller 140 (and network 112) via any number of different APL networks, each of which may have any number of field switches associated therewith. In addition, as Figure 3 As shown, an APL network can use different types of communication hardware and communication speeds (physical layer) for each network connection (e.g., depending on the usage), and each APL network can include highly versatile field devices connected directly to its power switch or via one or more field switches.

[0070] In another example architecture, Figure 3 The system can be expanded to include or provide one or more applications in another network, such as in the cloud, to gain access to the highly versatile field device 10. For example, Figure 4 Shows something like Figure 3 100 , wherein the network 144 is coupled to another network 164, which may be a factory or manufacturing plant business network within the factory or manufacturing plant, via a firewall device 162. The network 164 may also be connected to a cloud 168 via an edge gateway 166 using, for example, the OPC UA protocol and a supporting physical layer. One or more other applications associated with other systems, such as monitoring systems, data logging systems, and the like, may be stored and executed in computer devices in the cloud 168, and these devices and applications may communicate with highly versatile (HV) field devices 108, 110, 128 as clients via the edge gateway 166 (and network 164), via the firewall 162 and network 144, via the switch 142 and network 112, and via one of the APL power switches 114, 122 through one of the APL networks 102 or 104 to which the field devices 108, 110, 128 are connected. This architecture or configuration provides access to highly versatile field devices from applications (client applications) and devices in one or more external networks (i.e., networks external to the factory or manufacturing plant). As will be understood, Figure 4 The edge topology network runs on top of or in parallel with the process and factory automation systems 102, 104. Edge devices or applications 166 and 168 can be used, for example, to support factory information integration including scheduling, asset monitoring, analysis, simulation, and other functions.

[0071] In yet another example, factory and manufacturing plant automation network architectures can make highly versatile field devices (also referred to herein as highly connectable field devices) directly available to cloud-based devices or applications. Cloud-based topologies can be used in process plants to run in parallel with process instrumentation and can be used, for example, for condition-based monitoring, which is commonly used for energy monitoring, equipment and device monitoring, and process monitoring. Here, the monitoring system streams data from the plant, performs analysis on it, and provides recommendations back to the user and, in some cases, to the control system itself. Figure 5 , wherein a network architecture 180 includes APL networks 102 and 104 connected via APL power switches 114 and 122 to a cloud network 181 having various client applications 182 therein. Client applications 182 can be applications associated with any of the various systems described above, including process control or factory automation control systems, plant asset management systems, data logging systems, monitoring systems, and the like. Furthermore, these client applications 182 can communicate with the power switches 114 and 122 of APL networks 102 and 104 using any desired IP communication protocol, such as the OPC UA protocol using, for example, 100M or Gigabit Ethernet or any other suitable physical layer. Here, client applications 182 can directly access highly versatile field devices 108, 110, and 128 of APL networks 102 and 104 via APL power switches 114 and 122. This type of architecture is useful in providing support for remote sites in a factory or manufacturing plant automation setting, enabling control and other access to highly versatile field devices via remote or cloud-based connections.

[0072] Figure 6 and Figure 7 Another control system architecture is shown that includes highly versatile (HV) field devices that can be accessed by various client devices or applications. Specifically, Figure 6 and Figure 7 The network architecture of NVIDIA is designed to work with both traditional networking and flat networking. Generally speaking, traditional networking provides access to devices through controllers and I / O servers, while flat networking provides direct access to highly versatile field devices.

[0073] For example, Figure 6A process control network 200 is shown having an engineering station 202, an application station 204, an operator station 206, and a gateway 208, which are connected to a controller 210 and I / O devices 212 via a communication network 214, which may be Ethernet. The controller 210 is connected to one or more APL networks 216, each of which has a power switch 218 connected to one or more highly versatile field devices 220 via zero or one or more field switches (not shown). Additionally, the controller 210 can be connected to conventional process control field devices 224 via standard or conventional I / O devices 222, such as HART, FOUNDATION Fieldbus, WirelessHART, CAN, Profibus, etc. Similarly, the I / O devices 212 can be communicatively connected to one or more APL networks 226, each of which has a power switch 228 connected to one or more highly versatile field devices 230 via zero or one or more field switches (not shown). Additionally, a remote or cloud-based application 232 can connect to the network 214 via the gateway 208 to gain access to the controller 210 and the I / O devices 212 to obtain data from the highly versatile field devices 220, 230. The I / O devices can be, for example, those described in detail in U.S. patent application Ser. No. 16 / 573,380, filed on Sep. 17, 2019, and entitled “Integration of Multiple Communication Physical Layers and Protocols in a Process Control Input / Output Device,” the entire disclosure of which is hereby expressly incorporated herein by reference.

[0074] also, Figure 7A flattened process control network 250 is shown with an engineering station 252, an application station 254, an operator station 256, and a gateway 258 (as well as cloud-based devices connected in a cloud network 259 coupled to the gateway 258), all connected to a controller 260 and an I / O network 262 via a high-speed, high-throughput communication network 264 (e.g., a Gigabit Ethernet network). I / O networks 262B and 262C are shown as APL networks with different APL power switches 266A and 266B connected to the Gigabit network 264. APL network 262A can be a high-speed APL network, such as a 100M network, that includes one or more field switches 268A connected to a variety of highly versatile field devices 270A that support or are used for control in a factory automation environment. In this example, APL network 262B can be a slower-speed APL network, such as a 10M network, that includes one or more field switches 268B connected to a variety of highly versatile field devices 270B that support or are used for control in a process environment. Additionally, the I / O network 262C may include switches connected to I / O devices 280 that support traditional field devices such as HART, Fieldbus, etc., under the control of the controller 260. In this flat architecture, highly versatile field devices 270 may be controlled by the controller 260 while also connecting to and providing data to clients (e.g., client applications) in the stations 252, 254, 256 and in the cloud network 259 that is connected directly (or via a gateway 258) to the gigabit network 264.

[0075] exist Figure 6 The traditional network 200 and Figure 7 In the flat network 250, device tagging must be unique. In both cases, the device includes a unique ID, is assigned a unique tag, and supports multiple application sessions. However, even here, the highly general field devices 220, 224, 230 and 270 described in this document support requests and a publish / subscribe model. In order to establish a publish / subscribe device, the publisher (the highly general field device) must be discovered and, once discovered, authenticated using a session. Once a session is established, the highly general field device can support predefined and customized publish lists. A client or client application can subscribe to an existing publish list, or set up a customized publish list and then subscribe to it, as will be explained in more detail herein.

[0076] As will be appreciated, the highly versatile field devices disclosed herein can support many different uses or systems. In particular, the highly versatile field devices are primarily used as control field devices and operate as control field devices to perform process or factory automation control activities in response to a process or automation controller. However, the highly versatile field devices can also support factory asset management systems (including configuration of the equipment). Typically, factory asset management systems are used to configure and provision equipment, run diagnostics on equipment after it is deployed, monitor equipment alarms, and a long list of many other functions. In addition, the highly versatile field devices described herein can support IIoT platforms for continuous condition monitoring. More particularly, condition monitoring systems can be deployed in many locations to perform various functions, including energy monitoring, equipment and device monitoring, and process monitoring. Such monitoring systems can stream data from the factory, perform condition monitoring, and provide recommendations back to the user, and in some cases back to the control system itself.

[0077] In another case, the highly versatile field devices described herein can support data logger systems. As an example, many systems collect energy and monitoring data in a centralized manner to analyze and establish alarm management systems, such as when a leak or energy loss is detected due to a pipeline leak or rupture, and these systems can subscribe to or connect to the highly versatile field devices described herein to obtain data for analysis and data logging. Similarly, the highly versatile field devices described herein can support secure smart metering systems. In particular, metering can be a critical process in large-scale distributed systems (such as oil and gas fields, pipelines, chemical storage, and finished product storage). For example, in a chemical storage system, it is important to have accurate readings about what materials are present. Smart metering systems typically include smart meter reading systems that meter the smart meter reading systems through a controller or independently through a remote monitoring system, and then transmit the readings to a processing location, such as an edge gateway or a central data server. In addition, the highly versatile field devices disclosed herein can support environmental monitoring, such as environmental monitoring required by the Environmental Protection Agency (EPA) or monitoring required for other purposes. As an example, many factories have environmental reporting requirements, such as reporting of NOx, SOx, and other items. These systems are often dedicated systems that perform data collection, calculations, and reporting. It is critical that data from these systems is time stamped, unaffected by daylight saving time adjustments, and secure.The highly versatile field devices described herein can additionally provide these additional features to the data provided to client applications.

[0078] Therefore, as will be appreciated, the highly versatile field devices and field device network architecture described herein support a wide range of application scenarios. The data required in these scenarios is often different. Compared to control applications that require measured parameters, unit codes, and status information, condition monitoring applications require information about the operation and health of the device. For example, for a valve, control data includes the valve output value (also known as the target or valve setpoint) and its actual position, as well as its unit code and status information. On the other hand, valve condition monitoring data includes valve setpoint, stroke, actuation, instrument air, percentage of stroke per reversal, temperature, and other measurements. To make it easier for device manufacturers, these different sets of device parameters for these different applications can be included in pre-built templates for control, condition monitoring, data logging, environmental monitoring, or other functions. Users can also define their own templates and download them to highly versatile field devices. On the other hand, custom templates can be created on the fly. Client applications can then subscribe to these templates. To streamline the plug-and-play operation of highly versatile field devices, these templates can be included as part of the application connection, allowing the field device (server) to tell the client what templates it has, and the client can subscribe to them or define its own custom templates.

[0079] In any case, because highly versatile field devices directly support IP communication with client devices, i.e., without going through a process controller using one or more dedicated control protocols and physical layers, highly versatile field devices and the network architecture in which they are located require additional security that is superior to traditional field devices and networks. As described above, the highly versatile field devices described herein are capable of simultaneously implementing IP-based connections between these devices (i.e., field instruments) and multiple different client data consumers. Therefore, the highly versatile field devices and supporting networks include field device servers and client applications and devices, wherein the field device servers include field devices such as sensors such as flow, pressure, temperature, etc., valves, process analyzers, etc., and as described above, the clients include hosts such as PLCs, DCS controllers, plant asset management and edge gateways and applications stored and executed on the hosts or other computer devices, such as process controller applications, plant asset management applications, environmental monitoring applications, condition monitoring applications, data logging applications, smart metering applications, etc.

[0080] To provide this support, the communication interface of the highly versatile field device described herein includes session-oriented capabilities over IP and can, for example, support both UDP and TCP. Most real-time implementations use UDP, which gives designers considerable control over connection management, timeouts, and other capabilities. As a result, publish messages can be used to send periodic and exception-based data from field devices to subscribing clients such as controllers. Clients subscribe to devices to receive published messages. Once subscribed to a field device's publish list, the client listens on an IP endpoint, and the field device publishes messages to that endpoint. Therefore, highly versatile field devices and the networks in which they reside must implement strict security.

[0081] In traditional control systems using traditional field devices, control system cybersecurity and control system design and operation assume that control instruments and instrument networks are secure because they are physically isolated and protected by the control system network. To support this type of security, control system implementations typically include considerable use of firewalls, network monitoring, and other defense mechanisms located between the layers of the control system. However, in reality, field devices and field device networks themselves are typically not monitored, making anomaly detection difficult. In addition, these traditional control field devices and networks are also unprotected, making them targets for attacks. This security flaw is further exacerbated when the protocols used in the control network are converted to other protocols such as MODBUS and OPC DA, where semantics and context are lost (e.g., unit codes). In these cases, when a client receives a measurement value, such as a device measurement value converted to an OPC DA value using an OPC DA state, the client will not be aware that the value or the state of the value has been changed. These systems do not provide a standardized way to map the original value along with its unit code and state to automation applications and other clients.

[0082] Highly versatile field devices and the networks in which they are deployed address these security issues by incorporating security mechanisms into the field devices and the network, which can include the use of TLS, authentication certificates, and a complete secure chain of trust. Specifically, Figure 8 It is shown that in Figure 1 The highly versatile field devices 10 and the Figure 2-Figure 7 A rough diagram of the various security features provided in the network. Specifically, Figure 8 As shown, security features include a root of trust component 302, a secure boot feature 304, an endpoint identity feature 306, secure storage 308, and cryptographic capabilities 310. Additionally, security features include secure communication features 312, device provisioning 314, and security audit functionality 316.

[0083] In particular, each highly versatile field device 10 includes or contains a root of trust component 302, which forms the foundation of device security. Trust in embedded security refers to the expectation that a field device will operate as designed. Specifically, device software trusts the hardware to operate as intended, applications running on the device trust the operating system to not corrupt the device configuration, and remote systems communicating with the device trust the identity of the device to which they are connected. The process of establishing this trust is called attestation, and the field device's root of trust 302 is the point at which attestation and authentication begin. Once established, this root of trust extends through each trust layer and provides the foundation for each. Therefore, the root of trust component 302 is a critical building block in the highly versatile field device 10 because it provides the foundation for protecting the device and all communications with it. The root of trust component 302 can be established using any of a variety of methods and can take many forms, but generally, it ensures that the boot code on the field device is the code intended by the manufacturer. This root of trust feature 302 protects the boot code in a manner that makes it unchangeable or incorruptible to external tampering. In a simple case, the root of trust component 302 can be established by storing and / or executing the manufacturer's boot code for the field device 10 in a non-writable location in the device processor's memory map or directly from that location. Alternatively, the device can include a root of trust component 302 that enables updates and patches to the boot code by allowing the boot code to be loaded from a protected memory area into some protected memory storage set aside for firmware execution. An important aspect of the root of trust component is to ensure that the initial code is what the manufacturer intended before execution, and that the root of trust component protects the manufacturer's code (or updated code) from tampering by a third party. When the code starts, the root of trust derives its internal keys from the provided device identity input, and the device performs self-tests and code verification on itself to verify its identity and establish basic keys for the root of trust to use with other devices in the network.

[0084] In addition, the highly versatile field device 10 includes a secure boot feature or process 304. The secure boot process 304 prevents the execution of unauthorized code when the device is powered on and prevents the exposure of embedded boot code and software. The secure boot process can be implemented in many different ways, including using digitally signed binary strings, using a secure and trusted boot loader, using boot file encryption, and using a secure microprocessor. Although the secure boot feature 304 can be centered around digitally signed boot files, booting is not secure unless those signatures are verifiable using some kind of immutable root of trust. Therefore, in order to verify the boot file, the highly versatile field device has a digital key installed in it (and established by the root of trust component 302) when the device is manufactured or after manufacturing using a trusted application, and this digital key is then used to execute or enable other security features. In addition, the secure boot process protects software on the device, such as proprietary algorithms, and provides trusted repair measures. That is, the secure boot process 304 provides the ability to securely repair the process control system in the event of a device failure or compromise, because the repair relies on the secure boot process having checks on the validity of the firmware image being booted or using the root of trust component 302. The device secure boot process 304 provides standardization of these checks to ensure that a bad device cannot cause damage beyond its own.

[0085] Additionally, the device secure boot process 304 provides or enables secure firmware updates. Specifically, secure firmware upgrades involve validating incoming payloads intended to replace existing firmware images, which is critical to maintaining device integrity throughout the system lifecycle. Both the source of the payload and the payload itself must be verified before being applied, and with a properly implemented secure boot process 304, failure to validate incoming code results in a secure rollback to a known, validated boot image. Furthermore, the secure boot process 304 enables secure connections to cloud resources because the secure boot process 304 ensures that the device authenticates itself to the cloud whenever it attempts to connect to it through the use of embedded keys and certificates.

[0086] Likewise, the highly versatile field device 10 provides an endpoint identity feature 306. In particular, endpoint identity is a fundamental building block necessary for most other security measures. To provide endpoint identity, the highly versatile field device 10 includes a unique device identifier or identity, and the unique device identity is linked to the device's unique device ID.

[0087] In addition, the highly versatile field device 10 includes secure program storage 308. In particular, the program storage can be implemented in off-chip flash memory, the contents of which are copied to SRAM or external DDR memory for operation once the field device is booted. The hardware root of trust protects the device's unique ID and the keys associated with that ID, and therefore protects facilities (communications) derived from these keys. The device includes secure storage 308 for the rest of the chip and serves as an identification or authentication device.

[0088] Furthermore, the highly versatile field device utilizes and implements encryption 310 across transport protocols (data in motion), in storage (data at rest), and in applications (data in use). While the various types of cryptographic services listed below can be used to implement encryption in this manner, device manufacturers may utilize other cryptographic services. As an example, the highly versatile field device may utilize or include a standards-based symmetric cipher suite (PSK or PKI), a hash function, and a random number generator of appropriate strength and a validated cryptographic algorithm implementation based on NIST / FIPS standards, and may achieve interoperability of cryptographic keys.

[0089] Furthermore, the highly versatile field device 10 provides secure communications by including a secure end-to-end communication protocol stack 312. The highly versatile field device 10 may provide secure transmission using TLS, hash functions using SHA-2 (a hash function used to generate MAC codes), and encryption using AES-128.

[0090] Similarly, the highly versatile field device 10 provides or includes secure device provisioning 314 (typically performed by the manufacturer in a secure or trusted environment using a secure process), which may include writing certain information to the device, such as a device tag, a pre-shared key and / or certificate, a syslog server host name and port, a DNS server name, and optionally a default port number and a static IP address and mask on which the device listens. Devices should be provisioned before they are installed in the factory. This provisioning is typically referred to as onboarding. In one example, during the provisioning phase, the device should have the following information set by the secure device provisioning process, including (1) the device name and the name of the unit in which the device will be installed, (2) the pre-shared key or X.509 certificate that will be used to establish a session, (3) the host name and port used to connect to the syslog server, (4) the name of the DNS server, (5) the static IP address and its sub-mask (this is optional), and (6) an optional port number in the event that the default port number is blocked by a firewall (this is also optional). All of this information should be loaded into a secure location in the device. This information must also be available to the host that will open a session with the device.

[0091] In addition, the highly versatile field device 10 includes or supports a security audit function (e.g., system log) 316 that enables the field device 10 to be monitored as part of normal operation. To assist in such monitoring, the highly versatile field device 10 supports audit logging, including providing audit log information to a system log server. Specifically, for event response and auditing, event logs are used as valuable input that can help to continuously measure and assess risk and mitigate threats. This requires the ability to capture system and security events (which may not be security events), transmit events to a host using a system log, and apply inspection of system events. To achieve this functionality, the highly versatile field device 10 supports an audit log and an audit function (system log). In particular, the device (server) can record the following in a local volatile audit log: (1) the last time / date the server was powered on; (2) the last time / date the security credentials were modified; (3) the server status; (4) a circulating 128-entry session summary list; and (5) a timestamp, such as an 8-byte unsigned integer timestamp. Each session summary record may include (1) the client identity including the IP address (IPv4, IPv6) and port number, (2) the connect / disconnect time / date for that client, (3) start / end configuration change counters, (4) the session state, and (5) communication counters indicating the number of published (burst), request, and response PDUs. Additionally, the highly versatile field device 10 may support syslog by supporting or providing push audit messages (syslog messages) that are pushed to a security information and event management system supporting the field device 10. These pushed messages are critical for detecting security attacks and unauthorized manipulation of the field device 10. Detection enables improvements to plant security policies and procedures to minimize vulnerabilities.

[0092] As an example, a highly versatile field device 10 and the clients connected to it can support various communication security protocols, such as TLS versions 1.2 and 1.3; and DTLS versions 1.2 and 1.3. For TLS and DTLS, a secure handshake is used to establish a secure session. Once established, the communication is protected with TLS. Sessions can be established using certificates or using pre-shared keys. Highly versatile field devices can support both PKI and pre-shared keys (PSK). OPC UA fully supports certificates, so if OPC UA is used to communicate with the field device 10, certificates will be used. If the end user decides to use symmetric keys, the system is designed to manage these keys. In addition, the highly versatile field device 10 can support different security protocols (PSK and PKI) for different sessions or with different clients.

[0093] Network node management

[0094] Figure 9is a block diagram of an example system 400 for managing nodes of a node communication network 402 of an industrial process plant or manufacturing plant automation system, wherein at least one highly versatile (HV) field device 10 is a corresponding node of the network 402. In an example embodiment, the system 400 may be included in Figure 3-Figure 7 1 and 2, or otherwise support any one or more of the embodiments of the factory and manufacturing plant automation networking and control architectures shown in FIG. 1 . For example, at least a portion of the node communication network 402 may include Figure 6 The conventional process control network 200, and / or at least a portion of the node communication network may include Figure 7 Flat process control network 250.

[0095] exist Figure 9 , the node communication network 402 includes a backbone 408 (which may be implemented, for example, using Ethernet technology (e.g., 100Mb or Gigabit Ethernet technology, and / or other suitable types of technology)) and includes one or more advanced physical layer (APL) components 410 that provide an advanced physical layer to securely and flexibly connect devices D1-Dn (which are physically located within a process plant, automation network, or field environment thereof, as indicated by reference numeral 412a) to the backbone 408. For example, Figure 9 The APL component 410 may be included in Figure 2 APL-based network 80, Figure 3 Thus, the devices D1-Dn disposed within the field environment 412a of the industrial process plant or manufacturing plant automation system are considered to be nodes of the node communication network 402.

[0096] Devices D1-Dn may include one or more field devices, each of which performs a corresponding physical function during runtime operation of a plant or network, thereby controlling an industrial process. For example, the field devices included in D1-Dn may include sensors, valves, actuators, meters, other types of measuring devices, etc. In addition to field devices, devices D1-Dn may include other types of devices disposed within a field environment 412a of a process plant or automation network, such as controllers; I / O devices, systems and / or components thereof; safety instrumented system (SIS) components; process control or automation network communication components, such as adapters, routers, gateways, etc.; user interface devices; portable devices; etc. Some of devices D1-Dn may be highly versatile (HV) field devices, such as highly versatile field device 10, for example, devices D1-D4 and Dn in Figure 9 Some of the devices D1-Dn may be legacy or conventional devices, such as Figure 9, and thus can be communicatively connected to the APL component 410 (and thus to the backbone 408 of the node communication network 402) via the adapter 415, where the adapter 415 supports the local I / O of the legacy device D5 and thereby enables the legacy device D5 to communicate through the communication network 402 via the APL component 410.

[0097] Other nodes 418, 420, 422, 425 of the node communication network 402 may directly or without using any APL component 410 (e.g. Figure 9 shown) or via corresponding APL components and / or APL networks ( Figure 9 4 and 5. These other nodes 418, 420, 422, 425 are typically (but not necessarily) located in a back-end environment of the process plant or automation network (and / or remote from the process plant or automation network), as shown by reference numeral 412b, and are shielded from or protected from the harsher on-site environment 412a of the process plant or automation network. Figure 9 As shown, one or more controllers 418, configuration databases or servers 420, and edge gateways 422 of a process plant or automation network can be directly connected to the backbone 408 and / or otherwise communicatively connected to the backbone 408 without using any APL components 410. For example, such components 418, 420, 422 can be communicatively connected to the backbone 408 via a second-level network (e.g., a layer 2 network). Other systems 425, 428 related to the process plant or automation network can also be communicatively connected to the backbone 408 of the node communication network 402, such as a plant asset management system 425, a diagnostic system, an analysis system, a data logging system, a condition monitoring system, and / or other types of systems 428, for example, via a second-level network, a third-level network (e.g., a layer 3 network), and / or a higher-level network. For example, at least some of the other systems 425, 428 can reside in a cloud computing system. Generally speaking, the nodes 418 - 428 disposed in the backend environment 412 b are considered nodes of the node communication network 402 , regardless of whether the nodes 418 - 428 are communicatively connected to the backbone 408 using any APL components and / or networks.

[0098] Generally speaking, in a manner such as discussed elsewhere herein, during runtime operation of a process plant or automation network, at least some of the devices D1-Dn generate data as the devices D1-Dn perform their respective functions during runtime control of an industrial process, wherein the generated data may include data indicative of the respective physical functions as they are performed and / or related data. As such, the devices D1-Dn are considered "data hosts" or "data servers" within the node communication network 402 because such devices generate or produce data that can be manipulated, utilized, or otherwise consumed by other devices. Other devices and / or systems 418-428 may be consumers of the data generated by the devices D1-Dn and, therefore, may be considered "data clients" of the "data hosts" within the node communication network 402 because such devices manipulate, utilize, or consume data that has been generated / produced by the host device.

[0099] A specific data host and a specific data client can establish a (secure) communication session on the node communication network 402, and, for example, upon request, the specific data host and the specific data client can transmit data to each other via the communication session. Additionally or alternatively, the data host can publish various data via the node communication network 402, and various data clients can subscribe to various data published by various data hosts. In an example scenario, a specific data host and a specific data client establish a communication session with each other via the node communication network 402, the specific host publishes specific data via the communication session, and the specific data client subscribes to data published by the specific data host via the established communication session.

[0100] Some of the nodes D1-Dn, 418-428 can be both data hosts and data clients. For example, the controller 418 can be a data client for data generated by the data host field device D3, and the controller 418 can also be a data host that generates data consumed by another field device Dn, another controller 418, another system 428, etc. (e.g., a control signal generated by the controller 418 that executes a control routine on the data generated by the field device D3). Typically, within the node communication network 402, each node D1-Dn, 418-428 of the node communication network 402 (whether the node operates as a data host, a data client, or both) is connected to the network via a corresponding IP address (which, in embodiments, can be a secure endpoint identity 306, for example, as described above with respect to the secure endpoint identity 306). Figure 8 The IP address may be assigned to the node by a Dynamic Host Configuration Protocol (DHCP) service (e.g., in a manner such as described elsewhere in this disclosure), which may be hosted on a DHCP server 430 of the system 400. Figure 9As shown, the DCHP server 430 is communicatively connected to the node communication network 402, for example, via a backbone line 408. In some arrangements, the node communication network 402 may include multiple DCHP servers 430, which may operate in a redundant manner (e.g., for backup purposes) or in parallel to service corresponding sets of requests for node queries for IP addresses / endpoint identities used within the system 400.

[0101] On the other hand, within a process control system or automation network, each device D1-Dn is identified by and / or associated with one or more corresponding logical identifiers or tags, such as a device tag, one or more data tags that identify the type of data transmitted and / or received by the device, etc. For example, a device tag can be a first-order device identification or device identifier because the device tag directly identifies the device, while a data tag can be a second-order device identification or device identifier because the data tag indirectly identifies the device via specific data to be produced or consumed by the device. Generally speaking, in one or more configurations of a process control system or automation network, for example, in one or more configuration databases 420, the tags or identifiers identified and / or associated with the devices D1-Dn are defined. The one or more configuration databases 420 can be nodes of the node communication network 402, for example, as Figure 9 As shown, or one or more configuration databases 420 can be connected via one or more other types of process control or automation networks ( Figure 9 4. The network (not shown) is communicatively connected to the devices D1-Dn, which may include a legacy or conventional process control or automation network. Some identifiers or tags may be manually or automatically provisioned to the respective devices D1-Dn (e.g., during bench provisioning and / or commissioning of the devices D1-Dn, or at some other time prior to initial power-up of the devices D1-Dn within the field environment 412a), and / or some identifiers or tags may be downloaded to or otherwise stored in the respective devices D1-Dn along with the configuration of the respective devices. The respective device tags and any respective data tags identified and / or associated with each device D1-Dn are in Figure 9 Indicated by a circled "label" symbol.

[0102] The system 400 for managing nodes (e.g., nodes D1-Dn and 418-428) of a node communication network 402 includes a network node manager 432 that is communicatively connected to the node communication network 402. The network node manager 432 is aware of (e.g., stores information indicating) all devices that have been connected to the node communication network 402 and have been discovered, e.g., "nodes" of the node communication network 402. For example, the network node manager 432 may store identifications of discovered devices (e.g., corresponding IP addresses, endpoint identities or names, and / or corresponding device identifications) in a discovered device data store or database 435. In embodiments, at least a portion of the discovered device data store 435 may be associated with the network node manager 432 ( Figure 9 ) integrated, and / or at least a portion of the discovered device data store 435 may be implemented as a separate node of the node communication network 402, such as Figure 9 . The network node manager 432 also stores and updates the corresponding status or condition of the discovered device in the discovered device data store 435. Non-limiting examples of possible device status or conditions include debugged, active, inactive, offline, faulty, booting, undergoing diagnosis, limited operation and / or any other suitable status or condition. The device status or condition can be updated by the device itself or by other devices. In some embodiments, the device status and / or condition can refer to operational, physical, component and / or equipment status and / or condition. In some embodiments, the network node manager 432 also stores the corresponding security credentials of the discovered device and / or associated with the discovered device.

[0103] Additionally, the network node manager 432 is communicatively connected to other management nodes of the node communication network 402, such as a DHCP server or service 430, a DNS server or service 438, a security manager 440, and / or a syslog server 442, for example, via the backbone 408. Generally speaking, within the node communication network 402, the network node manager 432 performs node management, including assisting various devices in discovering other devices by utilizing the discovered device data store 435, coordinating the flow of information between the various management nodes 430, 438, 440, 442, and so on.

[0104] To this end, the discovered device data store 435 stores associations or mappings between device identifications defined in the process control configuration database 420 (e.g., the device tag of the device and, optionally, data tags associated with the device) and corresponding IP addresses / endpoint identifications that have been assigned to the devices by the DHCP server 430. Thus, the discovered device data store 435 is interchangeably referred to herein as the "mapping database 435." For illustration, consider an example device D1 that has been provisioned and / or configured with its identifying device tag A and two data tags B and C that identify two specific types of data generated by the device D1. The DHCP server 430 assigns the IP address A1B2 to the device D1. Thus, the mapping database 435 (e.g., the discovered device database 435) stores indications of associations between (1) the device tag A and the IP address A1B2, (2) the data tag B and the IP address A1B2, and (3) the data tag C and the IP address A1B2.

[0105] When assigning an IP address to a device, the DHCP server 430 and / or the device itself can use the indication of the association between the device identifier (e.g., tag) and the assigned IP address, for example, by directly updating the mapping database 435, and / or by notifying a domain name service server (438) which updates the mapping database 435 with the newly created association or mapping, to cause the mapping database 435 to be updated accordingly. Typically, the DNS server 438 manages the mapping database 435 and its contents; however, in other embodiments, the network node manager 432 and / or other management nodes such as the DHCP server 430 can manage the mapping database 435 and its contents. Note that although Figure 9 Mapping database 435 is shown as a separate node of network 402 , but in embodiments, mapping database 435 may be supported and / or integrated into one or more other management nodes, such as network management node 432 or DNS server 438 .

[0106] In practice, the system 400 for managing nodes (e.g., nodes D1-Dn and 418-428) of the node communication network 402 also includes a domain name service (DNS) server 438 communicatively connected to the node communication network 402. The DNS server 438 provides domain name services within the node communication network 402. Thus, the DNS server 438 receives a request or query from a first device for the assigned IP address of a second device, where the second device is identified in the request or query by a configuration identifier of a particular device (e.g., a device identifier or tag stored in the process control configuration database 420). Upon receiving the request, the DNS server 402 accesses the mapping database 435 to obtain the IP address of the second device and returns it to the first device, e.g., enabling the first device to communicate with the second device using the IP address of the second device. In some embodiments, the DNS server 438 also considers the device status indicated in the device status database 435 in its response. For example, if the second device is not functioning, the DNS server 438 may reply with an indication of this in addition to or instead of the requested IP address of the second device. In some arrangements, the node communication network 402 may include multiple DNS servers 438.

[0107] System 400 for managing nodes (e.g., nodes D1-Dn and 418-428) of node communication network 402 may include a security manager 440 communicatively coupled to node communication network 402. Generally speaking, security manager 440 of node communication network 402 may provide and manage security credentials for various devices and nodes of network 402. That is, security manager 440 may automate certificate management and credential provisioning and management. For example, security manager 440 may assign one or more keys and / or one or more passwords to each device, may verify certificates and / or other types of security credentials upon request, and so forth. Furthermore, security manager 440 may include an interface through which various security credentials may be provisioned or otherwise stored to a device (e.g., before the device is powered on in field environment 412a via workstation provisioning). Additionally or alternatively, security manager 440 may provide various security credentials to a device when a corresponding IP address is assigned to the device (e.g., by DHCP server 430). The security manager 440 may include a user interface via which a user may manually enter security credentials, and / or may include a communication interface via which a tool or other computing device may provide and / or obtain security credentials for the device. Additional details regarding security credentials are described elsewhere in this disclosure.

[0108] In an embodiment, a system 400 for managing nodes (e.g., nodes D1-Dn and 418-428) of a node communication network 402 includes a system log server 442 (also referred to herein as "log server 442") that is communicatively connected to the node communication network 402. Generally speaking, the system log server 442 is a centralized log server that records or logs events about the network 402, such as when devices connect to and disconnect from the node communication network 402, when communication sessions are established and torn down, and so on. The devices themselves can notify the log server 442 of the occurrence of various events, such as whenever the device connects to the network 402 and / or is about to disconnect from the network 402. For example, when the device is a highly versatile field device 10, the device can utilize the security audit function 310 (as described above with respect to Figure 8 42) to communicate connections, disconnections, and other types of information to the syslog server 442. In some cases, devices may additionally notify the syslog server 442 of events related to other devices. Logs stored at the syslog server 442 may be audited and / or otherwise analyzed for the purpose of mitigating security issues.

[0109] Note that although Figure 9 DHCP server 430, network node manager 432, DNS server 438, security manager 440, log server 442, and mapping database 435 (e.g., the "management" node of network 402) are shown as separate and distinct nodes of node communication network 402, but this is for ease of illustration only and not limitation. Any two or more of these management nodes 430, 432, 435, 438, 440, and 442 can be implemented as integral nodes as desired. For example, network node manager 432 can include DNS service or server 438, network node manager 432 can include DHCP service or server 430, DNS server 438 can include mapping database 435, and so on. In addition, although Figure 9 Each of the nodes or servers 430, 432, 435, 438, 440, 442 is illustrated as a respective single node, but in embodiments, the system 400 may include multiple of each of the nodes 430, 432, 435, 438, 440, and / or 442. Further, any one or more of the management nodes 430-442 may be implemented or hosted by any suitable computing system, such as one or more physical and / or virtual servers, one or more databases, etc., at least portions of which may be located locally or proximate to the process plant or automation system, and / or at least portions of which may be located remotely from the process plant or automation system, such as at a server farm, in a cloud computing system, etc.

[0110] Generally speaking, management nodes or components 430, 432, 435, 438, 440, 442 of system 400 operate to provide management and security of nodes or devices D1-Dn and 418-428 of node communication network 402. For example, system 400 may provide device discovery, device status tracking, device security, and other types of device management.

[0111] To illustrate, Figure 10 An example message flow 500 is shown that occurs when an example device 502 initially connects to the node communication network 402. The device 502 can be a highly versatile field device, such as device 10, D1-D4, or Dn, or the device 502 can be a legacy field device, such as device D5, which is connected to the APL component 410 and the network 402 via the adapter 415. Thus, in the case where the device 502 is a legacy device, the adapter 415 communicates with the network 402 on behalf of the legacy device, even in the case of Figure 10 Adapter 415 is not shown in FIG. In general, message flow 500 may occur in Figure 9 In the embodiment of the system 400, or may appear in other systems for managing nodes of a node communication network of a process control system or automation network. However, for ease of illustration and not for the purpose of limitation, the following also refers to Figure 8 and Figure 9 Message flow 500 is described.

[0112] In the example message flow 500, the device 502 has been provisioned with its own identity before being powered on 505 and connected to the node communication network 402. That is, the device's unique identification (e.g., device tag) and, optionally, any data tags corresponding to data to be sent and / or received by the device during runtime operation may have been provisioned or otherwise stored in a memory of the device 502, for example, manually by an operator and / or through the use of a provisioning, debugging, or other suitable tool such as a security manager 440 or 605. The process of storing identity and other information in the device 502 when it has not yet been powered on for runtime operation and when it is not connected to the network 402 is referred to herein as "bench-provisioning" and is described in more detail elsewhere within this disclosure. In any event, as previously discussed, the unique identification of the device (e.g., the device tag) and any data tags associated with the device 502 are typically already defined in one or more configurations stored in the configuration database 420 of the process control system or automation network, and therefore, the device 502 is provisioned with a logical identifier (e.g., the corresponding device tag) by which the device 502 is known to the process control system or automation network, and optionally with any corresponding data tags that are also known to the process control system or automation network.

[0113] The device 502 is physically located and installed at its intended location in a process control plant or automation network, for example, in its field environment (such as Figure 9 The device 502 is then powered on, as indicated by reference numeral 505. For example, the device 502 may be powered on using Figure 8 The secure boot feature 304 is used to power on.

[0114] After powering on 505, device 502 broadcasts a discover DHCP message (508) via network 402 to determine or discover any DHCP servers serving node communication network 402 that will be able to assign an IP address or endpoint identifier to device 502 so that device 502 can be identified within network 402 and identified as a node of network 402. Discover DHCP message 508 is received by any DHCP service and / or server serving network 402, such as Figure 10 In the example embodiment, the DHCP server 510 is Figure 9 An embodiment of a DHCP server 430.

[0115] In example message flow 500, DHCP server 510 responds to discover DHCP message 508 with a DHCP offer 512, which identifies DHCP server 510 and includes IP addressing information for device 502. For example, offer 512 may include endpoint identity 306 for device 502. Device 502 selects one of the responding DHCP servers (in this scenario, DHCP server 510) and sends an acceptance 515 of offer 512, where acceptance 515 includes a request for corresponding network parameters and other information associated with the IP address (e.g., endpoint identity 306) that has been assigned to device 502. DHCP server 510 responds 518 with the requested information, thereby providing device 502 with not only the IP address (e.g., endpoint identity 306) that has been assigned to device 502, but also other parameters such as the network mask, gateway, router, and / or other network configuration parameters. In some embodiments, the assigned IP address is valid only for a limited amount of time (eg, a lease), and DHCP server 510 indicates the duration of the lease to device 502 in response 518 .

[0116] In some embodiments, the node communication network 402 supports stateless address configuration (SLAAC). In these embodiments, instead of the DHCP server 510 assigning an IP address to the device 502, the device 502 selects its own IP address (e.g., its own endpoint identity 306), for example, based on a prefix advertised on the device 502's connection interface to the network 402. In these embodiments, in response 518, the DHCP server 510 may inform the device 502 of the network configuration and / or other types of parameters, such as a time server, a domain name, a DNS service and / or server, etc.

[0117] In any event, at this point 520 in the message flow 500 (e.g., after the device 502 has received the response 518), both the device 502 and the DHCP server 510 know the association between the device's process control / automation network identification (e.g., device tag) and the IP address / endpoint identifier that has been assigned to the device 502. In some embodiments, the device 502 and the DHCP server 510 may additionally or alternatively know the corresponding association between each of the device's data tags and the IP address assigned to the device 502. In this way, the DHCP server 510 and / or the device 502 can update the discovered device / mapping data store or database 522 with the new association or mapping. In an example embodiment, the discovered device / mapping data store or database 522 is Figure 9 An embodiment of a discovered device / mapping data store 435.

[0118] In the example branch of the message flow 500 indicated by reference numeral 525, the DCHP server 510 may communicate an indication of a new association or mapping between the device 502 and its assigned IP address to the network node manager and / or DNS server 528, and the network node manager and / or DNS server 528 may update 530 the mapping database 522 with an indication of the new association between the device's identification and the IP address assigned to the device 502 (and / or a corresponding association between each of the device's data tags and the IP address assigned to the device 502). In an example embodiment, the network node manager and / or DNS server 528 is Figure 9 In an embodiment of at least one of the network node manager 432 or the DNS server 438. Additionally or alternatively, the device 502 may transmit to the network node manager and / or the DNS server 528 an indication of a new association between the device's identification and the IP address assigned to the device 502 (and / or a corresponding association between each of the device's data tags and the IP address assigned to the device 502), such as Figure 10 denoted by reference numeral 532, so that the mapping database 522 is updated accordingly (reference numeral 535).

[0119] Importantly, system 400 can provide the capability for "plug and play" devices, such as Figure 11 An example message flow is shown in 550. Figure 11 In FIG, a device 552 (e.g., "device A") physically arrives at a location in a process control plant or automation network where the device 552 will be installed and operated during runtime to control an industrial process. The device 552 may be a highly versatile device, such as one of the highly versatile field devices 10, D1-D4, and Dn, or the device 552 may be a legacy device, such as device D5 to be connected to the node communication network 402 via the adapter 415 and the APL component 410. Thus, in the case where the device 552 is a legacy device, the adapter 415 communicates on behalf of the device 552 via the node communication network 402, even if Figure 11 Adapter 415 is not shown in FIG. In general, message flow 550 may occur in Figure 9 In the embodiment of the system 400, or may appear in other systems for managing nodes of a node communication network of a process control system or automation network. However, for ease of illustration and not for the purpose of limitation, the following also refers to Figure 8-Figure 9 To describe the message flow 550.

[0120] Before powering up 555 the device 552 in the field for runtime operation, the device 552 may be provisioned (e.g., bench provisioned) with a device tag and, optionally, information such as a corresponding data tag, one or more security credentials (e.g., keys, certificates, passwords, etc.), the respective IP addresses of the DHCP server 430, DNS server 438, and / or network node manager 432, the IP address of the syslog server 442, the IP address of the security manager 440, and / or other information. For example, an operator or user may communicatively and temporarily connect an otherwise unconnected device 552 to a security manager 440 or 605, to a provisioning or debugging tool (not shown), or to another suitable device or tool, via which such information is provisioned or otherwise stored in the memory of the device 552, thereby bench provisioning the device 552. In embodiments where security credentials are bench provisioned to the device 552, the security manager 440 typically assigns the one or more security credentials to the device 552. In an embodiment where the device 552 is a highly versatile field device 10, the device 552 can utilize the onboard device provisioning feature 314 to obtain identification and security credentials from the security manager 440, and the obtained information can be stored in the onboard secure storage device 308 for use by features such as, for example, the root of trust 302, secure boot 304, cryptographic capabilities 310, secure communications 312, security auditing 316, etc.

[0121] exist Figure 11In the embodiment of the system 400 supporting the message flow 550, for ease of discussion and not for limitation, the network node manager includes or hosts a DNS service. Figure 11 In the example, the network node manager and the DNS service or server are integral nodes, such as those indicated by reference numeral 560. Figure 11 In the example embodiment, the DHCP server is a separate node of the node communication network, for example, as represented by reference numeral 562. In the example embodiment, the network node manager / DNS service 560 is Figure 9 The network node manager 432 and the DNS server 438 are embodiments of the present invention, and the DCHP server 562 is Figure 9 An embodiment of a DHCP server 430.

[0122] When the device 552 is powered on 555 (e.g., by utilizing the secure boot feature 304), the device 552 sends a request 558 to the overall network node manager / DNS service 560 for an IP address or endpoint identity via which the device 552 will be identified within the node communication network 402. For example, the device 552 may utilize the IP address of the network node manager / DNS service 560 that was provisioned into the device 552 by the workstation to send the request 558 to the network node manager / DNS service 560. Upon receiving the device's request 558, the network node manager / DNS service 560 interfaces with a DHCP server 562 (e.g., via a message exchange 565) to obtain the IP address of the device 552 (e.g., to obtain the device's endpoint identity 306), and the network node manager / DNS service 560 returns the device's assigned IP address / endpoint identity (and optionally other information, such as previously discussed) to the device 552 in a response 568. For example, the device 552 may store its assigned IP address / endpoint identity and other information in secure storage 308 at the device 552. At this point 570 in the message flow 550, the device 552 is known or identified by its configured device identification or tag within the process control system or automation network, and is known or identified by its assigned IP address / endpoint identity within the node communication network 402. The association between the device's configured identification or tag and the device's IP address / endpoint identity is stored in a mapping database or discovered device data store, such as the mapping database 435, which is accessible to at least the network node manager / DNS service 560, as previously described. In addition, the network node manager / DNS service 560 updates the status of the device 552 within the mapping database or discovered device data store to "connected," "active," "available," or some appropriate equivalent state indicating that the device 552 is active and operational. At Figure 11In the example embodiment shown, the discovered devices / mapping database is integrated with the network node manager / DNS server 560 .

[0123] Thus, at this point 570 in the message flow 550, the device 552 has been "plugged in" to the node communication network 402. That is, the device 552 has been connected to the node communication network 402 and can be used to communicate with other nodes of the network 402. After completing the connection 570, the device 552 notifies the syslog server 572 that the device 552 has been connected to the network 402 (e.g., as represented by reference numeral 575), and the syslog server 572 records the connection event. In the example, the syslog server 572 is an embodiment of the syslog server 442, and the device 552 utilizes the security audit feature 316 to provide an indication of the connection event to the log server 442.

[0124] Note that although Figure 11 In FIG. 5 , device 552 is shown as obtaining its assigned IP address by communicating with network node manager / DNS service 560, but this is only one of many possible embodiments. For example, device 552 may obtain its assigned IP address by utilizing a broadcast discovery DHCP message, e.g., with a Figure 10 500. In another example, device 552 may be provisioned with an IP address from DHCP server 562, and upon power-up 555, device 552 may communicate directly with DHCP server 562 to request and / or obtain the IP address and associated parameters for device 552. Of course, other embodiments are possible.

[0125] Further references Figure 11 While device 552 remains "plugged in" or connected to node communication network 402, network node manager / DNS service 560 tracks and updates the discovered devices or mapping database (e.g., discovered devices / mapping database 435, as previously described, which is in Figure 11 578 ). In message flow 550 , the network node manager / DNS service 560 polls the device 552 (e.g., periodically, on demand, when triggered, etc.) and receives the current operational status from the device 552 in response to the poll, e.g., as represented by message exchange 578 . For example, the network node manager / DNS service 560 may poll each device it knows about (e.g., via a discovered device or mapping database) to obtain updates on the device status. Additionally or alternatively, Figure 11(not shown in the figure), the device 552 may provide the current status and / or condition to the network node manager / DNS service 560 on its own, for example, periodically and / or when the status and / or condition of the device changes (e.g., a fault is discovered, the device 552 undergoes diagnostics, is restarted, etc.). Additionally or alternatively, a third-party device may provide updates on the status and / or condition of the device 552 to the network node manager / DNS service 560 (also not shown in the figure). Figure 11 ), such as when a diagnostic tool takes device 552 offline for diagnostic purposes, when a security manager (e.g., security manager 440) discovers a security anomaly related to device 552 that needs to be mitigated and affects the state of the device, etc. In any case, network node manager / DNS service 560 updates the state and / or status of device 552 within the discovered device database.

[0126] When device 552 is connected to node communication network 402, other devices or nodes of network 402 can discover device 552 and establish communication with device 552 (e.g., the "... and works" part of "plug and play"). To illustrate, consider an example scenario in which device 552 is a field device that generates data while operating during the runtime of a process control system or automated plant. In this scenario, field device 552 and controller device 580 (e.g., Figure 11552) is included in a process control loop that operates during runtime of an industrial process plant or automation network to control an industrial process. The configuration of the process control loop, the field device 552, and the controller 580 is stored in the configuration database 420, and each of the field device 552 and the controller 580 has been provisioned with its device tag or identification (e.g., as indicated in the configuration database 420) and has been assigned a unique IP address by the DHCP server 562. In addition, the controller 580 stores (and executes during runtime) one or more control modules or routines that are configured to operate on data generated by the field device 552, where such generated data is referenced by the field device's device tag or by one or more corresponding data tags associated with the field device 552. That is, the controller 580 is configured as a consumer (e.g., client) of runtime data generated by the field device 552 (e.g., host). The configuration of the controller 580 and the configuration of the control modules or routines to be executed by the controller 580 are defined within the configuration database 420 and downloaded to and / or otherwise provided to the controller 580 for storage and execution during runtime operation. As such, the controller 580 knows the device tags and / or data tags associated with the field devices 552 (e.g., as provided in the downloaded configuration); however, the controller 580 does not have a priori knowledge of the IP addresses that have been assigned to the field devices 552 within the node communication network 402.

[0127] Therefore, in order to establish communication with the field device 552 through the node communication network 402, the controller 580 discovers the field device 552 via the node communication network 402. Specifically, Figure 11As shown, the controller 580 (e.g., via a DNS client executing on the controller 580) queries the DNS service or server 560 for the IP address of the field device 552 (as shown at reference numeral 582), for example, by utilizing the IP address of the DNS server 560 that has been provisioned to the controller 580 workstation and providing the DNS server 560 with the device tag and / or data tag of the field device 552 known to the controller 580. Upon receiving the query 582, the DNS service 560 accesses a mapping database / discovered device data store to find the IP address that has been assigned to the field device 552. The DNS service 560 replies to the controller 580 with the IP address assigned to the field device 552 and / or an indication of the current status of the field device (reference numeral 585). For example, when the field device 552 is active, the DNS service 560 may return only the IP address of the field device 552, the DNS service 560 may return the IP address of the field device 552 and an indication of the current status of the field device (e.g., active, temporarily out of service, etc.), the DNS service 560 may return an indication that the field device 552 has been disconnected from the network 402, etc.

[0128] In an embodiment, upon receiving the query 582, the DNS service 560 may use their respective security credentials (e.g., keys, certificates, etc.) to authenticate the controller 580 and the field device 552. For example, the DNS service 560 may authenticate the controller 580 and / or the field device 552 by querying the security manager 440 for authentication, verification, validation, etc., utilizing the corresponding security credentials already stored in the discovered device database 435.

[0129] In any case, upon receiving the reply 585 from the DNS service 560, the controller 580 has discovered the field device 552 with which the controller 580 is to communicate during execution of the process control loop. The controller 580 can use the IP address of the field device (and the field device 552 can use the IP address of the controller) to communicate via the node communication network 402 in any suitable manner (e.g., direct messaging, client / server type communication, request / response, publish / subscribe, etc., such as described elsewhere in this disclosure) to execute the control loop, and / or for other purposes. In an embodiment, the controller 580 and the field device 552 utilize their respective IP addresses to establish a secure communication session over the network 402, and the controller 580 and the field device 552 transmit data and information via the secure communication session, as shown by reference numeral 588. For example, the controller 580 and the field device 552 may exchange security credentials (which may have been assigned by the security manager 440 and provisioned to each of the devices 580, 552 by the workstation), may verify the credentials with the security manager 440 and / or the network node manager 560, and / or may take other associated actions to protect the communication session. Typically, each of the controller 580 and the field device 552 notifies the syslog server 572 of the establishment and teardown of the session, as well as other events associated with the communication session ( Figure 11 not shown).

[0130] Note that although the above example scenario refers to the client device 580 (e.g., device B) as a controller and the host device 552 (e.g., device A) as a field device, both of which are included in the same process control loop, this is for illustrative purposes only. In practice, any type of client device connected to the node communication network 402 can utilize similar methods (e.g., message exchanges 582, 585) to discover one or more host devices that generate data for the client device to consume.

[0131] Now back Figure 9As previously discussed, network node manager 432 can discover devices that have attached or connected to node communication network 402, store the device identification (e.g., whether a first-level device identification such as a device tag or a second-level device identification such as a data tag) and the IP address of the discovered device in mapping database / discovered device data store 435, and maintain updated status and / or conditions of the discovered device in mapping database / discovered device data store 435. For example, in an embodiment where network node manager 432 and DHCP server 430 are integral nodes, network node manager 432 discovers newly connected devices by receiving queries from devices to DHCP server 430 for IP addresses. When network node manager 432 is a different node from DHCP server 430, DHCP server 430 can notify network node manager 432 and / or DNS server 438 of newly connected devices and their corresponding device identification / IP address associations. When the DHCP server 430 notifies only one of the network node manager 432 or the DNS server 438 of a newly connected device (and its corresponding device identification / IP address association), the other node can query the notified node (e.g., periodically or otherwise as needed) for any newly added devices and their corresponding IP addresses and device identifications. Thus, in general, the mapped / discovered device database 435 can store device identifications and corresponding IP addresses, as well as updated device status and state information.

[0132] In an embodiment, the mapping or discovered device database 435 also stores security credentials for at least some of the discovered devices, such as keys, certificates, passwords, etc. At least some of the security credentials may have been generated by the security manager 440 and stored directly in the discovered device database 435 by the security manager 440 (e.g., provisioned via a workbench). Additionally or alternatively, at least some of the security credentials may be provided to the network node manager 432 by the security manager 440 and / or by the devices themselves during device discovery for storage in the discovered device database 435. For example, referring to Figure 11 , device 552 can provide its workstation-provisioned security credentials or information (eg, keys, certificates, passwords, etc.) to network node manager 560 along with a request for its IP address 558 .

[0133] The network node manager 432 can manage device security for individual devices and between multiple devices using device credentials and / or security information stored in the discovered device database 435. For example, the network node manager 432 can verify or validate the device credentials of a host device that is attempting to connect to the node communication network L15, the network node manager 432 can verify or validate the device credentials of a client device (such as in conjunction with a query of the client device for the IP address of the host device, for example, as per reference numeral 582), ... and the network node manager 432 can verify or validate the device credentials of a client device (such as in conjunction with a query of the client device for the IP address of the host device, for example, as per reference numeral 582). Figure 11 578) to verify or validate the device credentials, etc. Additionally or alternatively, the network node manager 432 may rely on the security manager 440 to verify and / or validate the device credentials and security information, such as by requiring the security manager 440 to perform verification, validation, and other security tasks.

[0134] Of course, the client device and the host device can use their respective security credentials or information to establish a communication session through the node communication network 402, such as in Figure 11 402. For example, in addition to providing the client device and the host device with their respective security credentials during workbench provisioning, the security manager 440 can also manage the respective keys and verify the credentials after provisioning, e.g., when the device is connected to the network 402 and / or while the device remains connected to the network 402. If a device fails to successfully authenticate or be successfully authenticated, the device can be isolated and blocked from communicating with other nodes of the node communication network 402 until the device's security credentials and / or information have been resolved, e.g., manually.

[0135] This security technique advantageously allows for easy replacement of physical devices. For example, a physical replacement device need only be provisioned using the security credentials that were already provisioned into the device it is replacing. Thus, when the physical replacement device is identified within the process control system using the device tag and security credentials of the previous device, using the techniques described herein, the physical replacement device will automatically be configured with the same settings as the device it is replacing and can be plug-and-play installed.

[0136] Figure 12 A block diagram of an example security architecture 600 is shown, illustrating at least some of the security techniques and / or aspects of a system for managing nodes of a node communication network of an industrial process plant or automation system, such as those described elsewhere herein. The security architecture 600 may be used to Figure 9 For example, the security architecture 600 may be used to protect the device and / or node of the system 400 or other suitable system. Figure 1 The highly versatile field device 10 of the present invention and / or the Figure 8However, for the purpose of illustration and not limitation, reference is made to Figure 8 safety features and Figure 9 The architecture 600 is described with reference to the system 400 .

[0137] like Figure 12 As shown, the architecture 600 includes a security manager 605 that can communicate with a host device 608 and a client device 610 for security purposes. In an example embodiment, the security manager 605 is Figure 9 In an embodiment of a security manager 440, the host device 608 is an embodiment of one of the devices or systems 10, D1-Dn, 418, 422, 425, 428, and the client device 610 is an embodiment of another of the devices or systems 10, D1-Dn, 418, 422, 425, 428. Figure 12 In the example shown, the client device 610 is a consumer of data generated or produced by the host device 608 as the devices 608, 610 operate during runtime operation of an industrial process plant or automation network. For example, the host device 608 may be Figure 11 The field device 552, and the client device 610 can be Figure 11 Controller 580.

[0138] The security manager 605 includes a provisioning engine 612 that, during workstation provisioning of devices of an industrial process plant or automation system that are to be connected to the node communication network 402, e.g., when such devices have not yet been powered on for runtime operation within the industrial process plant or automation system and when such devices are not connected to the network 402, generates or otherwise determines corresponding security credentials for such devices. The provisioning engine 612 records or stores the provisioned credentials for such devices in a credential data store 615. Typically, workstation provisioning occurs when such devices are located on-site at the process plant or automation system; however, workstation provisioning may occur at any time before such devices are powered on for connection to the node communication network 402, such as when such devices are located at a manufacturing plant, at a staging location, etc.

[0139] The provisioning engine 612 operates in conjunction with a workbench provisioning application 618, which can be provided via a user interface of the security manager 605 and / or can be otherwise exposed to or provided at a user interface of another device (e.g., a handheld computing device or other type of tool) for managing provisioning. For example, the security manager 605 can download instances of the workbench provisioning application 618 to various user-operated computing devices or tools, the security manager 605 can host workbench provisioning as a service accessible to various user-operated computing devices or tools, etc. In general, the workbench provisioning application 615 provides users with access to the security manager 605 for defining, generating, viewing, and managing device security credentials, and / or for performing other tasks related to provisioning security credentials to devices.

[0140] The security manager 605 also includes a credential management engine 620, which generally manages the security credentials of devices as they attempt to connect to the network 402, connect to each other, and during runtime operations of the industrial process plant or automation system. For example, the credential management engine 620 can authenticate or verify various devices, provide keys to various requesting devices, verify certificates, etc. In doing so, the credential management engine 620 can access the credential data store 615. Typically, but not necessarily, the credential management engine 620 operates automatically, e.g., without requiring any user input.

[0141] In an embodiment, each of the provisioning engine 612, the workbench provisioning application 618, and the credential management engine 620 includes a corresponding set of computer-executable instructions that are stored on one or more memories of the security manager 605 and are executable by one or more processors of the security manager 605 to perform its corresponding tasks and / or functions.

[0142] The host device 608 stores one or more routines or applications 622 on one or more of its memories that, when executed by one or more processors of the host device 608, enable the host device 608 to communicate with the security manager 605. Similarly, the client device 610 stores one or more routines or applications 625 on one or more of its memories that, when executed by one or more processors of the client device 610, enable the client device 610 to communicate with the security manager 605. For example, the host device 608 may include a provisioning routine 622a that obtains a device identification of the host device 608 (e.g., a device tag of the host device 608, any associated data tags, etc.) and associated security credentials of the host device 608 from the provisioning engine 612, such as during workstation provisioning of the host device 608. The information obtained by the provisioning routine 622a is stored in one or more memories of the host device 608 ( Figure 12In example embodiments where the host device 608 is a highly versatile field device such as the highly versatile field device 10, for example, the provisioning routine 622a may include the device provisioning function 314, and the obtained device identification and / or security credentials may be stored in the secure program memory 308.

[0143] Similarly, client device 610 may include a provisioning routine 625a that obtains a device identification of client device 610 (e.g., a device tag of client device 610, any associated data tags, etc.) and associated security credentials of client device 610, for example, during workstation provisioning of client device 610. Additionally, provisioning routine 625a of client device 610 may also obtain the corresponding device identification (e.g., a device tag, associated data tags, etc.) of any host device (including host device 608) that generates runtime data consumed and operated by client device 610 during runtime. The information obtained by provisioning routine 625a is stored in one or more memories (not shown) of client device 610.

[0144] At a time other than during provisioning, such as during and / or while connected to the node communication network 402, the host device 608 can execute a key request routine 622b, via which the host device 608 requests a key (e.g., a private key, a public key, etc.) from the credential management engine 620 of the security manager 605. For example, the key request routine 622b can be included in the secure communication feature 312. Similarly, the client device 610 can execute a key request routine 625b, via which the client device 610 requests a key (e.g., a private key, a public key, etc.) from the credential management engine 620. Furthermore, to perform authentication, verification, validation, and / or other types of credential evaluation during and while connected to the network 402, each of the host device 608 and the client device 610 can execute a respective credential evaluation routine 622c, 625c that interfaces with the credential management engine 620 of the security manager 605 to perform credential evaluation, for example, by accessing stored credentials 615. For example, when the host device 608 and the client device 610 execute respective join routines 628, 630 to respectively and securely join the node communication network 402 and thereby be able to establish a communication path or even a communication session 632, at least some device security routines or applications 612b, 612c, 620a, 620c may be executed. Figure 8 Any one or more of the security features and / or security protocols discussed (eg, 306, 310, 312, etc.) are used to establish a secure communication session 632.

[0145] Note that in Figure 12 6, the applications or routines 622a, 622b, 622c, 628 of the host device 608 are shown as separate and distinct applications or routines, however, this is for clarity of discussion only. In practice, the functionality of the host device applications / routines 622a, 622b, 622c, 628 can be implemented using a fewer or greater number of separate and distinct applications or routines. Similarly, the functionality of the client device applications / routines 625a, 625b, 625c, 630 can be implemented using a fewer or greater number of separate and distinct applications or routines, and the various functions provided by the security managers 612, 615, 620 can be implemented using a fewer or greater number of separate and distinct engines, applications, or routines.

[0146] Now go to Figure 13 In some embodiments, the node communication network 402 may include multiple network node managers 432, at least some of which may be redundant and serve as backup network node managers, and / or at least some of which may be distributed in nature. For example, Figure 13 An example system 650 arrangement for managing nodes of a node communication network of an industrial process control or automation system is shown, wherein the system 650 includes a plurality of distributed network node managers 652, 655, 658. The system 650 may be an embodiment of the system 400 and for clarity of description, reference is made herein to the system 400. Figure 9 However, it should be understood that other systems for managing nodes of a node communication network of an industrial process control or automation system can readily incorporate multiple redundant and / or distributed network node managers 652-658 using the principles and techniques described herein.

[0147] like Figure 13As shown, each network node manager 652-658 is communicatively connected to other types of management nodes of the system 650 via the backbone of the node communication network 660, such as one or more DHCP servers 662, one or more DNS servers 665, one or more security managers 668, one or more log servers 670, etc. In addition, each network node manager 652-658 serves a different set of host devices 672, 675, 678, respectively, wherein the different sets of host devices 672, 675, 678 are mutually exclusive sets. In this way, each network node manager 652-658 manages the device label, IP address or endpoint identification, status, and optionally security information of each host device included in its corresponding set of host devices 672, 675, 678, for example, via its corresponding mapping database. In this way, a query for the endpoint identification of a device not managed by the first network node manager received at a first network node manager can be routed to another network node manager that manages the device via the node communication network 600. In some embodiments, one or more of the network node managers 652-658 may share (and update) at least a portion of their respective mapping databases with at least one other of the node managers 652-658, such that at least one other of the node managers may service queries for non-managed devices without having to communicate with the managing network node manager.

[0148] In addition, the node communication network 402 can utilize time synchronization to synchronize clocks between network components or nodes, such as clocks between devices D1-Dn (which can include one or more highly versatile devices, such as highly versatile field devices 10) and nodes 418, 420, 422, 425, 428, 430, 432, 435, 438, 440, 442, etc. Time synchronization between nodes is particularly important because process control requires that certain information be sent and / or received at specific times or within specific time windows in order to maintain industrial process stability and safety. For example, NTP (Network Time Protocol), PTP (Precision Time Protocol), and / or other suitable time synchronization technologies can be used to synchronize clocks between nodes of the node communication network 402.

[0149] Network resource management

[0150] While the node communication network 80 in the plant 100 is extremely flexible, in part because it utilizes an IP-based network, implementing an IP-based network in a process or factory automation control environment requires consideration of factors that may be of concern in a typical or traditional process or factory automation control network. For example, the self-routing nature of an IP-based network means that, without proper management, the network's performance under normal, overload, and failure scenarios will be different and / or unpredictable. As an example, under high load and contention scenarios, an IP-based network may drop or delay packets. When packets are delayed or dropped, the performance of monitoring and control applications will be adversely affected by the resulting delay and jitter. Therefore, when performing network design in a process or factory automation control network, it is important to understand how applications (e.g., monitoring and control applications, condition monitoring applications, etc.) will be affected under varying network conditions. Specifically, it is important to provide the required quality of service (QoS) to support existing and emerging application requirements while also supporting a combination of traditional field devices 224, traditional I / O devices 222, and highly versatile field devices 82.

[0151] It is also important that the IP-based network can be configured to support a variety of topologies. For example, the node communication network 80 should support traditional factory automation or process automation topologies such as Figure 3 , which includes highly versatile field devices 82 and legacy field devices 224 coupled to the APL network architecture 892 through adapter devices 130. The communication network 80 should support Figure 4 , which runs on top of or in parallel with a traditional factory or process automation topology and supports planned information integration such as scheduling, asset monitoring, analysis, simulation, and other functions. That is, the communication network 80 should be configurable to facilitate communication between highly versatile field devices 82 and / or traditional field devices 224 (via adapter devices 130) on the one hand and various applications including cloud-based client applications 182 on the other hand via one or more edge gateways 166, as described above. Further, the communication network 80 should support cloud-based topologies such as Figure 5 , which can run in parallel with automation instrumentation and can be used, for example, for condition-based monitoring (e.g., energy monitoring, equipment and device monitoring, and process monitoring). In such a system, as described above, the monitoring system can transmit data from the plant 100 to one or more cloud-based applications 182, which perform analysis and transmit data and / or recommendations back to users and / or elements in the process control network 200, such as the controller 140.

[0152] The node communication network 80 should also be configurable to facilitate communication between nodes such as Figure 6 In the traditional networking environment shown and in Figure 7 1. In a conventional networking environment, the highly versatile field devices 82 and the conventional field devices 224 transmit data (via the adapter device 130) to the controller 140 or the I / O device 212 for use by the controller 140 and / or for use by other applications that can receive data forwarded by the controller 140 or the I / O device 212. In a flat networking environment, each of the highly versatile field devices 82 and the conventional field devices 224 sends data directly to other devices (e.g., the controller 140) and applications (e.g., operating on the engineering station 202, on the application station 204, on the operator station 206, or in the cloud 168) via the communication network 80.

[0153] Whether implemented in a traditional or flattened networking environment, because some data flowing from the highly versatile field devices 82 and the traditional field devices 224 to the various applications and devices of the process control network 200 is more time-sensitive than other data, the communication network 80 must be configured to account for this time sensitivity. For example, some control modules (i.e., control routines or portions of control routines) operating within the controller 140 may require certain data more frequently than other control modules and / or more frequently than condition monitoring applications that do not perform real-time control of the process. Therefore, it is important that the communication network 80 prioritize time-critical and time-sensitive data over less delay-sensitive data while supporting the transmission of a variety of data types to and from the various devices and applications.

[0154] As above reference Figure 3-Figure 7 As described, the communication network 80 is implemented as an IP-based network using an APL network architecture 892 that includes APL power switches 84 and APL field switches 86 coupled to each other via an APL bus 88 (e.g., Ethernet) and coupled (e.g., via a firewall device 162) to various highly versatile field devices 82, adapter devices 130, controllers 140, workstations 206, 145, 202, 204, edge gateways 166, and / or the cloud 168. The APL power switches 84 and APL field switches 86 facilitate the communication of data to and from the field devices 82 and 224 and to and from various applications. In some embodiments, the APL power switches 84 and field switches 86 can communicate with various other switches (e.g., Figure 3 The L2 switches shown in FIG) collaborate to facilitate the communication of data from source to destination.

[0155] As also described above, the communication network 80 supports both client / server and publish / subscribe communication and, in addition to facilitating communication between field instruments and applications, also enables internet connectivity between Open Platform Communications (OPC) Unified Architecture (UA) servers (e.g., field instruments) and OPC UA clients (e.g., controllers), each of which can be either a client or a server in various instances. The communication network 80 supports both User Datagram Protocol (UDP) and Transport Control Protocol (TCP) communication modes. In a client / server communication session, directed communication occurs between a host and a single, specific device. The addresses of both the source and destination devices are specific and unambiguous, and all client / server requests specify the request and response data to be transmitted. Meanwhile, in publish / subscribe communication, new values ​​(e.g., measurements, status values, etc.) are transmitted from the server (e.g., device) only when needed. For example, with respect to parameters published from a highly versatile field device 82 to the controller 140, parameters can be transmitted as often as needed to allow control actions to correct for unmeasured disturbances or respond to setpoint changes.

[0156] The communication network 80 is configured to work with the highly versatile field devices 82 to support a variety of use cases. Of course, the primary use case is a control case, allowing the highly versatile field devices 82 and the legacy field devices 224 to communicate with the controller 140 and / or with the operator station 206 (in the latter case, via the adapter device 130) to facilitate control of the process plant 100. While in a traditional process plant communication network, field devices communicate only with their respective controllers, and the operator station receives necessary parameter data from the controller and, through the controller, sends new setpoint data to the field device, the communication network 80 can be configured to facilitate communication directly between the operator station 206 and the highly versatile field devices 82 and the legacy field devices 224. Specifically, the communication network 80 can be configured to allow a particular field device to publish parameter data to multiple consumers of that data simultaneously. Thus, a valve, for example, can publish parameter data to both the controller 140 and the operator station 206, which can save bandwidth by eliminating duplicate transmissions of data. That is, a single transmission may convey data to both the controller 140 and the operator station 206 , rather than requiring a second transmission of the data from the controller 140 to the operator station 206 , as is typical with conventional control networks.

[0157] The communication network 80 can also improve plant asset management (PAM), including the configuration of equipment. PAM systems are used to configure and provision equipment, run diagnostics on the equipment once deployed, monitor equipment alarms, and perform other functions. For example, the PAM system can receive condition monitoring data from field devices 82 and / or 224 to determine when the equipment is malfunctioning, requires calibration, etc.

[0158] Industrial IoT (Internet of Things) platforms may also benefit from the implementation of the communication network 80 as described herein. An Industrial IoT platform for continuous condition monitoring may be deployed to monitor various parameters within the process plant 100. Such a system may monitor functions such as energy consumption, equipment and device functionality / performance, and process performance. Such a system typically operates using various parameters collected from a large number of devices throughout the process plant 100 as input. In conventional systems, an Industrial IoT platform that performs continuous monitoring receives data indirectly from field devices via a controller 140 and / or one or more other devices such as an operator station 206 or a plant asset management device 145. However, in the system described herein, these Industrial IoT platforms may receive data directly from the devices that are the data sources, without the need to program an intermediary device to relay the data, either through direct requests or using publish / subscribe (i.e., by subscribing to the data).

[0159] Other processes may similarly be facilitated by the communication network 80 described herein. For example, data logging may be enabled by streamlining the collection of energy and monitoring data, metering may be enabled by streamlining the collection of data from smart meter reading systems and transmitting the data to processing applications via, for example, the edge gateway 166 and / or the cloud 168, and environmental monitoring may be enabled by streamlining the collection of data from sensors that monitor NOx, SOx, and other emissions or potential emissions that must be monitored and reported for regulatory compliance.

[0160] As will be appreciated, implementing traditional monitoring and control data and other non-traditional data such as described in the use cases above on the same network can lead to problems such as delays and dropped packets that do not exist with traditional control networks, which transmit data only between individual devices and controllers and over which the transmission of such data is scheduled, specifically requested by the controller, or otherwise strictly controlled to ensure that high-priority, delay-sensitive data is received from the devices at the controller (or vice versa) in a timely manner. One challenge is accommodating scheduled network traffic (e.g., monitoring and control data transmitted between field devices and controllers) and unscheduled traffic (e.g., condition monitoring and other data transmitted between devices and applications) on the same network.

[0161] To solve and / or prevent such problems, the communication network 80 includes a network resource management component 800. Figure 14Generally, the network resource management component 800 interacts with various physical network devices (e.g., the APL power switch 84 and the APL field switch 86) via the physical network (e.g., the APL bus 88) to manage network resources (e.g., bandwidth and scheduling), thereby facilitating the communication of managed network traffic (network traffic known to the network resource management component 800, such as scheduled network traffic) and unmanaged network traffic (network traffic unknown to the network resource management component 800, such as unscheduled request-response network traffic). In various embodiments, the network resource management component 800 may be centralized in a specific device, such as the APL power switch 84, or may be distributed across various APL power switches 84 and APL field switches 86 throughout the communication network 80, the controller 140, and so on. That is, the network resource management component 800 may be a logical component embodied in a specific physical component or distributed across various physical components. For example, the network resource management component 800 can be implemented in the I / O device 212, in the controller 140, in the switch, or as a separate hardware entity, and can actually be distributed among various hardware entities (e.g., multiple controllers 140 and / or multiple I / O devices 212, etc.).

[0162] By managing network resources to facilitate the communication of managed and unmanaged network traffic, the network resource management component 800 facilitates communication between various devices and applications in various modes while ensuring that scheduled and / or high-priority network traffic reaches its destination without undue or unacceptable delays. This includes at least: network traffic between a highly versatile field device 82 and another highly versatile field device 82; network traffic between a highly versatile field device 82 and a controller 140; network traffic between a highly versatile field device 82 and multiple other highly versatile field devices 82; network traffic between a highly versatile field device 82 and an application running on a workstation (on the process control network 80, through the edge gateway 166, or a cloud-based application 182); and network traffic between a highly versatile field device 82 and multiple applications running on the workstation.

[0163] The network resource management component 800 can be implemented using time-sensitive networking (TSN) or not. Each embodiment will be described below.

[0164] TSN-based network management

[0165] TSN-based network management requires managing TSN-based network resources (e.g., devices and applications) while allowing non-TSN resources to access the same network. In other words, TSN-based network management facilitates the communication of managed and unmanaged network traffic. As part of this networking solution, TSN network devices and applications need to be aware of priorities, and network resources must be allocated in a way that allows time-critical data to be transmitted with minimal blocking when transferring data from source to destination.

[0166] The TSN-based network resource management component 800 prioritizes data transmissions based on rules and traffic types. For example, in some embodiments, priorities are assigned based on default traffic types typically associated with TSN-based networks, as shown in Table 1.

[0167] Table 1

[0168]

[0169]

[0170] However, when implemented in a factory automation or process control plant (e.g., plant 100), priorities need not be assigned based on the same type of traffic that might be present in an average network. Instead, by way of example and not limitation, priorities may be assigned based on the specific type of network traffic that might be present in a factory automation or process control environment. Table 2 is an example listing of traffic types and priorities, although it will be appreciated that the traffic type associated with each priority level may be assigned based on the needs of the system operator.

[0171] Table 2

[0172] Priority Business Type 0 (lowest) background 1 Do your best 2 Excellent efforts 3 Equipment condition and health monitoring 4 Low priority control (higher delay tolerance) 5 High priority control (lower delay tolerance) 6 Inter-network control 7 (highest) Network Control

[0173] Referring to Table 2, some data used by factory automation controllers or process controllers may be more time-sensitive than other data. Those familiar with such automation processes will understand that such data may be more time-sensitive because the data is part of a frequently executed control loop, or where small changes can have an outsized impact very quickly, or because the data is part of a safety system that must respond quickly to events, such as to prevent or mitigate a hazardous situation. Other data used by the controller may be less sensitive to increased latency, such as due to being part of a less frequently executed control loop or a process that exhibits sudden changes relative to being unresponsive to minor disturbances.

[0174] In any case, various types of data within the plant 100 can be assigned different priorities within the TSN-based networking scheme implemented by the network resource management component 800. Data prioritization according to the networking scheme is performed in the outbound ports 818 of TSN-based devices, such as the highly versatile field devices 82, the adapter devices 130, the APL power switches 84, the APL field switches 86, etc. Of course, each TSN-based device that sends data can have a corresponding outbound port 818.

[0175] Figure 15 An example outbound port 818 is shown. Data enters the outbound port 818 via input 819 and is placed into one of a plurality of queues 822A-822N by a queue selection unit 820. The queue selection unit 820 may determine which of the queues 822A-822N to place specific data based on the priority of the data and / or the type of data. In an embodiment, each of the queues 822A-822N may correspond to a specific priority, and each priority may be associated with one of the queues 822A-822N. In other embodiments, each of the queues 822A-822N may correspond to a specific priority, but multiple queues in the queues 822A-822N may be associated with one of the associated priorities. That is, each priority may be assigned a single queue in the queues 822A-822N, or may be assigned multiple queues in the queues 822A-822N. In an embodiment, each of the queues 822A-822N may have data associated with it at more than one priority level (e.g., if there are fewer queues than priorities or traffic types). In an embodiment, each of the queues 822A-822N may have data associated with a particular data source, data type, data destination, or data flow associated therewith.

[0176] In any case, each of queues 822A-822N has an associated transmission selection algorithm 824A-824N that operates to select which data to remove from the corresponding queue 822A-822N. A plurality of gates 826A-826N, each associated with a corresponding one of queues 822A through 822N, determines whether the data selected by the corresponding transmission selection algorithm 824A-824N can be transmitted. An open gate 826A-826N allows the data selected by the corresponding transmission selection algorithm 824A-824N to be transmitted from the corresponding one of queues 822A-822N, while a closed gate 826A-826N prevents the data from being transmitted. A gate control list 828 determines which of the plurality of gates 826A-826N is open at any given time. A transmission selection unit 830 selects which data provided and / or available from an open gate 826A-826N is transmitted from a data output 832 by selecting the highest available priority frame for transmission. As a result, in this arrangement, even if the transmission selection algorithms 824A-824N determine the order in which data will be transmitted from the corresponding queues 824A-824N, the gates 826A-826N can prevent transmission to effectively give priority to data other than the data with the highest assigned priority. Therefore, the gates 826A-826N are important in properly handling traffic to achieve appropriate transmission of time-sensitive scheduled traffic. As described, each of the gates 826A-826N can be opened or closed. Multiple of the gates 826A-826N can be open (or closed) at any given moment.

[0177] Of course, controlling gates 826A-826N to ensure highly predictable delivery of data in a real-time system, while taking into account delays and jitter during transmission through various switches between devices, requires knowledge of the network topology, knowledge of the devices and applications sending and receiving data, knowledge of the timing requirements of the data, and, to the extent possible, knowledge of what traffic may not be scheduled traffic but may still occur on the network.

[0178] To this end, the network resource management component 800 may include a routing information component 802 that determines and / or stores information about the network topology and the routing of data from one point in the network to any other point. For example, the routing information component 802 may store data indicating that a particular network switch (e.g., one of the APL field switches 86) is connected to a particular upstream device (e.g., a particular APL power switch 84) and a downstream device (e.g., a highly versatile field device 82). By having "knowledge" of the network topology, the routing information component 802 allows the network resource management component 818 to estimate the network latency between any two devices and / or applications sending traffic over the network and to predictably schedule recurring traffic.

[0179] The key to mapping the network topology is understanding which devices exist on the communication network 80. The device registration component 804 can implement this function, as described above with respect to device discovery. By implementing the device registration component 804, the network resource management component 800 is aware of all discovered devices. The component can also implement a DHCP server and / or a DNS server to register devices.

[0180] The network resource management component 800 may have routines or data for obtaining and / or storing network scheduling information 806, which may be received from or programmed by the controller 140 and / or various workstations and relates to the timing requirements of various data to be transmitted over the communication network 80. In an embodiment, some of the network scheduling information 806 is obtained directly from a configuration file that programs the controller 140 (e.g., from control loop timing requirements specified in the configuration file). In an embodiment, as described herein, some of the network scheduling information 806 is determined based on publish-subscribe requests established between specific devices. That is, when each publishing device (e.g., the highly versatile field device 82) establishes a subscription with another device or application, it may update the network scheduling information 806 so that the network resource management component 800 can appropriately allocate network resources.

[0181] The network resource allocation information 808 may store various data associated with the allocation of network resources and may include information such as associations between data types and assigned priorities, specific time slots reserved for specific data priorities, specific scheduled data transmissions, etc., and include bandwidth allocations for unscheduled services (e.g., request-response services).

[0182] The time-aware shaper 810 can utilize the network resource allocation information 808, the routing information 802, and the network scheduling information 806 to configure and synchronize the gate control list 828 to meet the real-time requirements of the communication network 80 and the various devices and applications on it. Because control data is often transmitted on a recurring schedule within the plant 100, it is possible to know when a particular transmission will occur. However, it should be understood that prioritization of data does not, in itself, guarantee that the data will be transmitted at the correct time, because by the time the scheduled data is ready for transmission, other lower-priority data may have already been transmitted over the communication network 80. If the lower-priority transmission already in progress is large, it must be completed before any other data can be transmitted, thereby delaying the scheduled data.

[0183] This is where the gate control lists 828 come into play. Each gate control list 828 establishes or implements a repeating pattern of opening and closing gates in its associated outbound port 818. By synchronizing the gate control lists 828 of each outbound port 818 and programming them accordingly, a clear transmission path can be created for the scheduled data at the appropriate time. That is, each outbound port 818 must have a synchronized clock so that the gates 826A-826N of each outbound port 818 can be opened and / or closed at the exact right time to facilitate ultra-low latency data transmission. In an embodiment, the TSN-based network resource management component 800 uses the Precision Time Protocol (PTP) to synchronize the clocks associated with each outbound port 818. Taking into account the network topology, routing information for each scheduled transmission, delays incurred as data passes through various switches, network scheduling information, and network resource allocation information, the time-aware shaper 810 can manage the gate control lists 828A-828N to accurately time the opening and closing of gates 826A-826N in each egress port 818 so that the appropriate gates in the gates 826A-826N are opened and closed at precisely the correct time and interval.

[0184] Figure 16 834 is a diagram illustrating an example data flow 834 of this concept. In the example data flow 834, two different endpoint systems 840 and 842 send corresponding data frames 836 and 838 to a third endpoint system 844 via a network switch 846. Each of the endpoint systems 840, 842, 844 can be a device or application in the plant 100. By way of example and not limitation, the endpoint systems 840 and 842 can each be a highly generalized field device 82 that sends parameter data to an endpoint system 844, which can be a controller 140. In another example, the endpoint systems 840 and 842 can be highly generalized field devices 82 that send health status data to the endpoint system 844, which can be a plant asset management device 145 on which an asset management system (AMS) is executed. In general, each of the endpoint systems 840, 842, 844 can be any device that communicates through the node communication network 80, and can include devices for which data frames 836 and 838 are scheduled traffic or unscheduled traffic, transmitted according to a publish-subscribe protocol, a request-response protocol, or based on some other standard.

[0185] In the example data flow 834, two data frames 836 and 838 are simultaneously transmitted from their respective endpoint systems 840 and 842 to endpoint system 844. Between the respective endpoint systems 840 and 842 and endpoint system 844, each data frame passes through a network switch 846. Each of the endpoint systems 840, 842, 844 and the network switch 846 is shown in the example data flow 834 as having an egress port 818 of its corresponding element. Of course, it should be understood that the devices and systems described herein, including the highly versatile field device 82, the APL power switch 84, the APL field switch 86, and other devices, can each have multiple egress ports 818. Back Figure 16 , when data frames 836 and 838 both arrive at network switch 846, data frames 836 and 838 are placed in respective queues 894A and 894B of network switch 846, which are considered to have arrived simultaneously. When data frames 836 and 838 are transmitted from network switch 846, data frame 836 will be transmitted before data frame 838 because data frame 836 has a higher priority than data frame 838.

[0186] When data frames 836 and 838 arrive at input 819 of outbound port 818 of network switch 846, queue selection unit 820 analyzes data frames 836 and 838 to determine the priority or data type of each. Queue selection unit 820 places data from respective data frames 836 and 838 into respective queues 894A and 894B. Transmission selection algorithm 824 may select data for transmission from each data frame 836 and 838, and, assuming that transmission gates 826 for respective queues 894A and 894B are both open, transmission selection routine 830 may select the highest priority data (data from data frame 836) for transmission before selecting data from data frame 838 for transmission.

[0187] Slightly modifying this example, if data frames 836 and 838 each have the same priority, or if data frame 836 has a lower priority than data frame 838, the network resource management component 800 may still facilitate the arrival of data frame 836 before data frame 838, for example, if data frame 836 is scheduled network traffic and data frame 838 is unscheduled network traffic. For example, data frame 836, while having a lower priority, may contain data from a highly versatile field device 104 that the controller 140 desires at a particular time. In this case, the network resource management component 800 may configure the communication network 80 so that data frame 836 arrives at the endpoint system 844 (e.g., the controller 140) before the higher priority data frame 838. The network resource management component 800 can configure the gate control lists 828 of the various outbound ports 818 via the time-aware shaper 810 so that a clear data transmission path is created for the data frame 836, while one or more transmission gates 826 along the data path of the data frame 838 (e.g., the transmission gates 826 corresponding to the queue 894B in the network switch 846) remain closed to block the transmission of the data frame 838 until the transmission of the data frame 836 is completed.

[0188] As will be appreciated, the network configuration component (NCC) 816 of the network resource management component 800 can discover devices (e.g., in cooperation with the device registration component 804) and determine the topology of the communication network 80. The NCC 816 can be centralized or distributed. In any case, the NCC can receive a request to discover the physical topology of the communication network 80 (or a portion thereof) and, in response, can traverse the topology of the network to discover each device and how it is connected to the network 80. Alternatively, or in addition, the NCC 816 can cooperate with the device registration component 804 to determine the connectivity of each new device registered via the device registration component 804, thereby determining the topology of the network 80.

[0189] The NCC 816 may also be responsible for managing switches and routers (e.g., APL power switch 84, APL field switch 86, etc.) in the communication network 80. The NCC 816 may integrate and / or cooperate with the time-aware shaper 810 to, for example, configure gate control lists 828 for various outbound ports 818. The NCC 816 is also responsible for determining routes between devices and applications operating on the network 80 (e.g., determining routing information 802), and for configuring the switches and routers within its scope using the routing information 802, network scheduling information 806, and network resource allocation information 808.

[0190] A user configuration component (UCC) 812 may be responsible for managing various endpoint stations (e.g., highly versatile field devices 82, adapter devices 130, workstations, and applications). The UCC 812 requests scheduled flows of network traffic by issuing requests to the NCC 816. These requests provide specific requirements for those scheduled flows of network traffic by specifying the endpoint devices (sender and receiver) for each flow and specific timing requirements (e.g., the frequency of flow occurrence, the size of the data payload, and the time sensitivity, sequence order, etc. of the data payload).

[0191] The NCC 816 can communicate with the UCC 812 to receive the communication requirements of the various traffic flows that will appear on the network 80, determine the routing of each traffic flow, and schedule the transmission of each traffic flow. The scheduling of the transmission of each traffic flow can include using the time-aware shaper 810 to create and manage the gate control list 828 for each switch and router controlled by the NCC 816. The NCC 816 then transmits the necessary scheduling data to each of the switches and routers it controls.

[0192] Non-TSN-based network management

[0193] In an embodiment where the network resource management component 800 is not based on the time-sensitive networking (TSN) protocol, network traffic can be managed by controlling the traffic flow through network switches (e.g., the APL power switch 84 and the APL field switch 86). The network resource management component 800 in a non-deterministic (i.e., non-TSN-based) system includes a network manager 814. The network manager 814 monitors and adjusts the network traffic flow between various devices in the network 80, particularly in the network switches. Devices and hosts communicate with the network manager 814 to allocate traffic, for example, by requesting publish-subscribe traffic flows. The network manager 814 will then control the traffic passing through the switch by enabling and disabling various ports of the switch and by suppressing the network traffic passing through the ports. In such an embodiment, network traffic can be identified, for example, by the traffic source (i.e., sender), destination (i.e., receiver), and application type.

[0194] The network manager 814 maintains a flexible runtime model 815 of the devices on the communication network 80. The network manager 814 uses the flexible runtime model 815 of the network, which may be stored, for example, as routing information 802 and device registration information 804, to allocate network resource usage. The network resource allocation may be stored, for example, in network resource allocation information 808. The network manager 814 may cooperate with the device registration 804 so that when a device joins the network 80, the network manager 814 is part of the joining process and uses its flexible runtime model 815 of the network 80 and algorithms to optimize traffic flow through the network. Once network resources have been allocated (and information about the allocation is stored, for example, in network resource allocation information 808), the network manager 814 may use this information to manage switches.

[0195] At some point after each device joins the network 80, the various devices request negotiated bandwidth from the network manager 814. For example, a device may negotiate with the network manager 814 for publish-subscribe bandwidth between specific devices (e.g., between one of the highly versatile field devices 82 and the controller 140, or between one of the highly versatile field devices 82 and the controller 140 and the operator station 206). If the network manager 814 approves the request, the device may begin publishing data to hosts that subscribe to the data.

[0196] The network manager 814 may allocate a specific portion or percentage of bandwidth on the network 80 for unmanaged traffic, such as network traffic from non-scheduled communications (e.g., ad hoc request-response communications), which is considered "best effort" traffic. The network manager 814 may monitor the flow of traffic through the network 80 and may adjust switches when the percentage of unmanaged traffic exceeds the allocated amount.

[0197] In any of the embodiments described herein, the network resource management component 800 supports unmanaged network traffic on the managed network 80 and supports publish-subscribe in both directions on the network (i.e., from field devices to controllers / applications and from controllers / applications to field devices). As described above, security and plug-and-play operations can similarly be supported. Peer-to-peer network traffic can also be supported. The network resource management component 800 also facilitates devices acting as both data publishers and data subscribers within the same device.

[0198] Release Kit

[0199] Because the node communication network 80 supports publish-subscribe and request-response services between any devices on the communication network 80, and because each of the highly versatile field devices 82 and adapter devices 130 can publish data to and subscribe to data from multiple devices, the highly versatile field devices 82 and node communication network 80 support a wide range of use cases, including monitoring and control, plant asset management, condition monitoring, data logging, secure plant metering, environmental monitoring, and more, as described above. Also as described above, any particular highly versatile field device 82 or adapter device 130 can connect to more than one application type. For example, one of the highly versatile field devices 82 can support secure connections for both monitoring and control and condition monitoring, and the connections can be completely separate and support different workloads, with separate applications each subscribing to different sets of data available from the highly versatile field device 82. Consequently, the published parameter lists sent from the highly versatile field device 82 to each respective application will be different. Given these new capabilities in devices and applications, simplifying the publish-subscribe initiation protocol becomes desirable.

[0200] As will be appreciated, each device or application may have various parameters or other data available for publication to other devices or applications on the communication network 80. As an example, a valve may have monitoring and control parameters (e.g., current set point, valve temperature, etc.) as well as condition monitoring parameters (e.g., valve travel, valve actuation, valve pressure, cycle count, etc.). Different types of available parameters may be of interest to different applications in the process plant 100. For example, an associated controller 140 may require monitoring and control parameters to implement a control loop that controls a process, while a plant asset management device 145 may require condition monitoring parameters to monitor the condition of equipment in the process plant 100 and determine when maintenance is required, when equipment has failed, when equipment has lost calibration, and so on.

[0201] To this end, devices (and possibly applications) operating on the communication network 80 may have predefined lists of parameters and other data available for subscription. Figure 17 An example server 848 (eg, a highly general field device 82, an application, a controller 140, etc.) and an example application 874 (eg, another highly general field device 82, a controller 140, or another application) are shown. Figure 17 The server is illustrated as a highly generic field device and therefore shows various elements that may not be present in the controller (e.g., sensors) or application (e.g., sensors, communication circuitry, etc.), but Figure 17 The general concept illustrated in relates to a collection of publication lists 858 stored in a server 848. Specifically, go to Figure 17, the server 848 (e.g., a highly versatile field device 82) includes one or more sensors 851 (e.g., a temperature sensor, a position sensor, a pressure sensor, a flow sensor, etc.). The sensor 851 sends data to a processor 852, which can monitor the data from the sensor, store the data from the sensor, execute a process control module to implement part of the control strategy, and / or transmit the data to one or more other devices (e.g., a controller) or applications. The server 848 includes communication circuitry 854 to facilitate communication with various devices and applications via the communication network 80. The server 848 also includes a memory device 850, which may include a parameter store 856 for storing various parameters of the server 848 (e.g., data from sensors, publish-subscribe, etc.). The server 848 also includes various publication lists 858 in the memory 850, at least some of which are predefined and determined by the device or application manufacturer.

[0202] Therefore, the memory 850 of server 848 includes one or more manufacturer-defined publication lists 860. Each manufacturer-defined publication list 860 may include parameters commonly transmitted from server 848 for a specific application. For example, the first of the manufacturer-defined publication lists 860 may include device parameters related to process control. If server 848 is a valve, the manufacturer-defined publication list 860 may be a monitoring and control publication list 868 and may include valve setpoint, valve temperature, and upstream and downstream flow rates and / or pressures. If server 848 is a level transmitter, the monitoring and control publication list 868 may include the level. Meanwhile, the second of the manufacturer-defined publication lists 860 may be a condition monitoring publication list 870, which includes device parameters related to monitoring the condition of the device itself. For example, if server 848 is a valve, the manufacturer-defined condition monitoring publication list 870 may include parameters such as valve travel, valve actuation, valve pressure, cycle count, and the like.

[0203] Server 848 includes at least one predefined publication list 858, which is defined by the manufacturer as a manufacturer-defined publication list 860. In an embodiment, manufacturer-defined publication list 860 includes multiple publication lists. In an embodiment, at least one of manufacturer-defined publication lists 860 is a monitoring and control publication list 868. In an embodiment, at least one manufacturer-defined publication list 860 is a condition monitoring publication list 870. In an embodiment, the manufacturer-defined publication lists include a monitoring and control publication list 868 and a condition monitoring publication list 870, and may include multiple monitoring and control publication lists 868 and / or multiple condition monitoring publication lists 870. In some embodiments, manufacturer-defined publication lists 860 may also include one or more publication lists defined for applications other than monitoring and control or condition monitoring.

[0204] The server 848 may also store one or more user-defined release lists 862 in the memory 850. The user-defined release lists 862 may be defined, for example, by a particular plant operator operating, for example, a single plant 100 or multiple plants 100, and may be defined for use at a single plant 100 or across multiple plants 100. Similar to the manufacturer-defined release lists 860, the user-defined release lists 862 may include zero, one, or more monitoring and control release lists 868, condition monitoring release lists 870, and release lists for applications other than monitoring and control or condition monitoring.

[0205] Furthermore, the server 848 may store one or more customized publication lists 864 in the memory 850. Customized publication lists 864 may be defined, for example, for specific devices or applications, or for specific groups of devices or applications, within the plant 100. For example, in most cases, a controller 140 may subscribe to a manufacturer-defined publication list 860 or a user-defined publication list 862 for a specific type of device (e.g., a specific valve type) within the associated process control network 200, but may require (or not require) one or more specific parameters for a group of devices (e.g., the same specific valve type) within the process control network 200. Thus, a customized publication list 864 may be defined for that group of devices. Similar to the manufacturer-defined publication lists 860 and the user-defined publication lists 862, the customized publication lists 864 may include zero, one, or more monitoring and control publication lists 868, condition monitoring publication lists 870, and publication lists for applications other than monitoring and control or condition monitoring.

[0206] In an embodiment, each publication list 858 includes associated publication list metadata 872. The publication list metadata 872 includes, for example, one or more of a device type code, a device type string, a manufacturer code, a manufacturer string, a device revision, a publication list category (e.g., control, condition monitoring, etc.), a publication list name (e.g., "MfgControlList"), and a list of parameters included in the publication list. In such an embodiment, the metadata 872 can be transmitted by the server 848 to a client 874 requesting to subscribe to data from the server 848, as described in more detail below.

[0207] As described throughout, a client 874 can be a highly versatile field device 82, an adapter device 130, or an application on the communication network 80 that subscribes to a published data source. For example, a client 874 can be a controller 862, another highly versatile field device 82, or an adapter device 130, an application 874A on an operator station 206, an application 874B on an application station 204, an application 874C on an engineering station 202, a cloud-based application 874D, an application accessing the communication network 80 through an edge gateway 166, and the like.

[0208] Each release list 858 can be defined as having information about the device type, manufacturer, and device revision; information about the device address, tag, release list category, release list name, version; and information about parameters that are part of the release list. For example, the release data for a typical monitoring and control release list 868 might look like:

[0209]

[0210]

[0211] However, the publication data for a typical condition monitoring publication list 870 might look like:

[0212]

[0213]

[0214] A release list 858 may be defined in a similar manner, including information about the device, information about the type of release list, and various parameters of the release list 858. Release lists may be defined individually or in groups. The following example shows how the two release list outputs above may be defined in groups:

[0215]

[0216]

[0217]

[0218] When a client 874 wants to subscribe to a server 848, during the initial handshake between the client 874 and the server 848, the client discovers and selects a particular one of the available publication lists 858 for the server. Figure 18An example communication flow diagram 876 of an initial handshake interaction between a client 878 and a server 880 is shown. The client 878 initiates a publish-subscribe session by sending an initial "hello" message 882 to the server 880. In an embodiment, the initial "hello" message includes an indication of a publication list category (e.g., monitoring and control, condition monitoring, etc.). In response to the initial "hello" message 882, the server 880 responds with its own "hello" message 884. In an embodiment, the server's "hello" message 884 includes an indication of the publication lists 858 in the category indicated by the client 878. In some embodiments, the indication of the publication lists 858 sent by the server 880 includes metadata 872 for each publication list 858 in the category indicated by the client 878, while in other embodiments, the indication of the publication lists 858 sent by the server 880 includes publication list definitions for the publication lists 858 in the category indicated by the client 878.

[0219] Although Figure 18 884, but in alternative embodiments, the initial exchange of messages may occur over more than two messages. For example, although potentially less efficient, client 878 may send a "hello" message to server 880, in response to which server 880 may confirm its presence with its own "hello" message. Client 878 may respond to the confirmation sent by server 880 by sending a request for posting lists in a particular posting list category. In response to the request, server 880 may send an indication of the posting lists 858 available in the specified posting list category. Of course, other communication arrangements are similarly possible and contemplated.

[0220] In response to an indication from server 880 indicating an available publication list 858 within the publication list category indicated by client 878, client 878 may send a message 886 back to server 880 requesting a specific one of the indicated publication lists. In embodiments, client 878 may include a requested update rate in this message, indicating how frequently client 878 wishes to receive updated values ​​for the parameters of the selected publication list. In some embodiments, the definition of publication list 858 may include a default update rate, and server 880 may publish the parameters of the selected publication list at the default update rate unless client 878 specifies an update rate different from the default update rate. In response to message 886, server 880 may send a message 888 confirming the request for the selected publication list 858 and confirming the valid subscription to the selected publication list. Thereafter, server 880 may publish encrypted data 890 corresponding to the subscribed publication list and transmitted at the agreed-upon update rate to client 878.

[0221] When implemented in software, any of the applications, modules, etc. described herein may be stored in a non-transitory computer-readable memory of any entity, such as a magnetic disk, a laser disk, a solid-state memory device, a molecular memory storage device, or other storage medium, in the RAM or ROM of a computer or processor, etc. Although the example systems disclosed herein are disclosed as including software and / or firmware and other components executed on hardware, it should be noted that such systems are merely illustrative and should not be considered restrictive. For example, it is contemplated that any or all of these hardware, software, and firmware components may be implemented exclusively in hardware, exclusively in software, or in any combination of hardware and software. Therefore, although the example systems described herein are described as being implemented in software executed on a processor of one or more computer devices, it will be readily understood by those of ordinary skill in the art that the examples provided are not the only way to implement such systems.

[0222] Therefore, although the present invention has been described with reference to specific examples, these examples are only intended to illustrate rather than limit the present invention, and it will be obvious to those skilled in the art that changes, additions or deletions may be made to the disclosed embodiments without departing from the spirit and scope of the present invention.

[0223] The specific features, structures and / or characteristics of any specific embodiment can be combined with one and / or more other embodiments in any appropriate manner and / or in any appropriate combination, including using selected features and correspondingly using or not using other features. In addition, many modifications can be made to adapt specific applications, situations and / or materials to the essential scope or spirit of the present invention. It should be understood that other variations and / or modifications of the embodiments of the present invention described and / or shown herein are possible based on the teachings herein and should be considered as part of the spirit or scope of the present invention. Some aspects of the present invention are described herein as exemplary aspects.

Claims

1. A system for managing nodes of a node communication network of a process control or automation system, the system comprising: A network node manager, communicatively connected to the node communication network, the network node manager comprising: a mapping database storing associations of respective tags of a plurality of devices utilized in the process control or automation system with respective endpoint identifications utilized in the nodal communication network, the plurality of devices including one or more highly versatile (HV) field devices having respective one or more physical components that perform respective physical functions to control an industrial process during runtime operation of the process control or automation system; and a status database storing respective statuses of the plurality of devices; and A Domain Name Service (DNS) service is accessible by the network node manager, the DNS service being used to provide a response to a request for an endpoint identification for a particular device among the plurality of devices via the node communication network, the response being generated based on the mapping database and the state database of the network node manager.

2. The system according to claim 1, wherein: The network node manager includes the DNS service.

3. The system according to claim 1, wherein: The DNS service is provided by a DNS server communicatively connected to the node communication network.

4. The system according to claim 1, wherein: The network node manager includes computer-executable instructions stored on one or more memories and executable by one or more processors to cause the network node manager to query the DNS service for any updated information related to the plurality of devices or any additional devices, and to update the contents of the mapping database based on a response of the DNS service to the query.

5. The system according to claim 1, wherein: The respective tags of the plurality of devices are configured by the process control or automation system and are provisioned into respective memories of the plurality of devices prior to respective power-ups of the plurality of devices.

6. The system according to claim 5, wherein: The respective tags of the one or more HV field devices include at least one of respective device tags or respective data tags configured by the process control or automation system.

7. The system of claim 1 , further comprising a Dynamic Host Configuration Protocol (DHCP) service accessible to the network node manager or at least one of the plurality of devices, and wherein The associations of the respective tags of the plurality of devices with the respective endpoint identifications of the plurality of devices are generated by the DHCP service.

8. The system according to claim 7, wherein: The network node manager includes the DHCP service.

9. The system according to claim 7, wherein: The DHCP service is provided by a DHCP server communicatively connected to the node communication network.

10. The system of claim 1, further comprising a security credential database storing security credentials corresponding to the plurality of devices, the security credentials corresponding to the plurality of devices comprising at least one of: one or more keys, one or more certificates, or one or more passwords.

11. The system of claim 10, further comprising a security manager communicatively connected to the network node manager, and wherein: at least one of a network node manager, the HV field device, or another device obtaining a respective at least a portion of the security credentials from the security manager; as well as The security manager manages the security credentials corresponding to the multiple devices, and the management of the security credentials includes at least one of the following: allocating the one or more keys, allocating the one or more passwords, verifying the one or more certificates, or supplying at least some of the security credentials corresponding to the multiple devices to the corresponding devices.

12. The system according to claim 11, wherein Prior to power-up of the HV field device, the respective at least a portion of the security credentials corresponding to the HV field device has been provisioned into the HV field device by the security manager.

13. The system of claim 1, wherein: The DNS service updates the state database of the network node manager based on at least one of: polling of one or more of the multiple devices via the node communication network, or a corresponding state update of each device included in at least one of the multiple devices, the corresponding state update being obtained by the DNS service from each device included in the at least one of the multiple devices.

14. The system according to claim 13, wherein: The DNS service periodically polls each device whose status is stored in the status database.

15. The system of claim 1, wherein: The network node manager is a first network node manager, and the system further comprises a plurality of network node managers communicatively connected to the node communication network, the plurality of network node managers including the first network node manager, and each network node manager included in the plurality of network node managers comprises: a respective communication connection to a respective set of a plurality of mutually exclusive sets of devices, the respective set of the plurality of mutually exclusive sets of devices comprising a respective one or more HV field devices disposed in the process control or automation system; a corresponding mapping database storing associations between corresponding labels of the corresponding sets of the plurality of mutually exclusive sets of devices and corresponding endpoint identifiers utilized in the node communication network; a corresponding state database storing corresponding states of the corresponding set of the plurality of mutually exclusive device sets; and a respective DNS server for providing, via the node communication network, a response to a request for an endpoint identification for a particular device, the particular device being communicatively connected to another network node manager of the plurality of network node managers, the response being generated based on at least one of: a respective mapping database, a respective state database, and a respective communication connection to the another network node manager.

16. The system according to claim 15, wherein: At least one of the plurality of network node managers shares at least a portion of content of its corresponding mapping database with at least one other network node manager, and the response is further generated based on at least a portion of the shared content.

17. The system of claim 1, wherein: The plurality of devices included in the system includes a first device that has been configured with a set of tags corresponding to a set of devices from which the first device is to obtain data associated with controlling the industrial process during runtime operation via the nodal communication network; The tag set is generated based on one or more configurations stored in a configuration database of the process control or automation system; the request for the endpoint identification of the particular device is generated by the first device and includes a tag corresponding to the particular device, the tag corresponding to the particular device being included in the tag set corresponding to the set of devices from which the first device is to obtain the data associated with controlling the industrial process during the runtime operation; as well as The first device obtains the endpoint identification of the specific device from the DNS service from the response of the DNS service, and communicates with the specific device using the obtained endpoint identification.

18. The system according to claim 17, wherein: The particular device transmits at least some of the data associated with controlling the industrial process during the runtime operation to the first device via one or more publications, and the first device is a subscriber to the one or more publications.

19. The system according to claim 17, wherein: The specific device transmits at least some of the data associated with controlling the industrial process during the runtime operation to the first device by using a client-server model, and the first device is a client of the specific device.

20. The system of claim 17, wherein: The first device establishes a communication session using the endpoint identifier of the specific device, and the first device and the specific device communicate through the communication session.

21. The system of claim 20, wherein: one or more security credentials associated with the first device have been provisioned into the first device prior to establishing connection of the first device to the nodal communication network; and The first device also utilizes at least some of the one or more security credentials to establish the communication session with the particular device.

22. The system of claim 17, wherein: The first device is a controller, the particular device is a particular HV field device included in the one or more HV field devices, and the controller and the particular HV field device are included in a process control loop that operates during the runtime operation to control the industrial process.

23. The system of claim 1, wherein: The network node manager receives via the node communication network an identification of a new device and an indication of a new association of corresponding endpoint identifications that have been assigned to the identification of the new device, and adds the new association to the mapping database.

24. The system of claim 23, wherein: The new device provides an indication of the new association to the network node manager.

25. The system of claim 23, wherein: A DHCP server communicatively connected to the node communication network provides an indication of the new association to the network node manager.

26. A highly versatile (HV) field device for a process control or automation system, the HV field device comprising: one or more physical components that perform a physical function to control an industrial process within the process control or automation system; a communication interface to a node communication network; one or more processors; as well as one or more non-transitory memories into which a tag corresponding to the HV field device has been provisioned and stored, the one or more non-transitory memories further storing computer-executable instructions that, when executed by the one or more processors, cause the HV field device to: detecting, when the HV field device is powered on, that the HV field device is connected to the node communication network via the communication interface; transmitting, via the node communication network, a request for an endpoint identification of the HV field device to a Dynamic Host Configuration Protocol (DHCP) server of the node communication network, the request including an indication of the tag corresponding to the HV field device; obtaining, from the DHCP server via the node communication network, an endpoint identifier assigned to the HV field device by the DHCP server; establishing a communication session with another device on the nodal communication network and by using the endpoint identification assigned to the HV field device, the other device being a consumer of data generated by the HV field device, the generated data corresponding to the physical function performed by the HV field device during runtime operation of the process control or automation system; as well as During the runtime operation of the process control or automation system, the data corresponding to the physical functions performed by the one or more physical components of the HV field device is communicated to the other device via the established communication session, thereby controlling the industrial process.

27. The HV field device of claim 26, wherein: Prior to powering up of the HV field device and said detecting of connection of the HV field device to the node communication network, an endpoint identification of the DHCP server has been provisioned and stored in the one or more non-transitory memories; as well as The HV field device transmits the request using the stored endpoint identification of the DHCP server.

28. The HV field device of claim 26, wherein: The DHCP server is a first DHCP server among a plurality of DHCP servers of the node communication network; The computer-executable instructions, when executed by the one or more processors, cause the HV field device to further perform the following operations: broadcasting, via the node communication network, discovery messages corresponding to the plurality of DHCP servers based on the detected connection to the node communication network; as well as receiving, via the node communication network, an offer message generated by the first DHCP server in response to the discovery message; as well as Transmitting the request to the first DHCP server is based on the offer message.

29. The HV field device of claim 26, wherein: The computer-executable instructions, when executed by the one or more processors, cause the HV field device to further provide an indication of the endpoint identifier assigned to the HV field device to a network node manager of the node communication network, and the network node manager stores an association between respective tags corresponding to a plurality of devices communicatively connected to the node communication network and respective endpoint identifiers assigned to the plurality of devices.

30. The HV field device of claim 29, wherein: A Domain Name Service (DNS) server of the node communication network is capable of accessing the stored associations of respective labels corresponding to the plurality of devices and respective endpoint identifications assigned to the plurality of devices; providing, by the DNS server, a response to a request for the respective endpoint identifications of the one or more devices based on the respective states of the one or more devices and the association of the respective tags corresponding to the one or more devices with the respective endpoint identifications assigned to the one or more devices; and The computer-executable instructions of the HV field device, when executed by the one or more processors, cause the HV field device to further perform the following operations: receiving a request for a current status of the HV field device from the DNS server; and A response to the request to the DNS server is transmitted, the response including an indication of the current status of the HV field device.

31. The HV field device of claim 26, wherein: Prior to powering up of the HV field device and said detecting of connection of the HV field device to the node communication network, an endpoint identification of a log server of the node communication network has been provisioned and stored in the one or more non-transitory memories; as well as When executed by the one or more processors, the computer executable instructions cause the HV field device to further send at least one of the following to the endpoint identifier of the log server: an indication that the HV field device has been connected to the nodal communication network, an indication of completed establishment of a communication session with said other device, a respective indication corresponding to each transmission of generated data of said physical function performed by said HV field device, an indication that a communication session has ended; or a respective indication of each of a plurality of other events occurring at the HV field device while the HV field device is connected to the nodal communication network.

32. The HV field device of claim 26, wherein: prior to powering up of the HV field device and said detecting of connection of the HV field device to the node communication network, one or more security credentials associated with the HV field device have been provisioned and stored in the one or more non-transitory memories; as well as The HV field device utilizes at least some of the one or more security credentials to establish the communication session with the other device.

33. The HV field device of claim 32, wherein: The one or more security credentials associated with the HV field device include at least one of: one or more keys, one or more certificates, or one or more passwords.

34. The HV field device of claim 26, wherein: The data corresponding to the physical function described by the HV field device, which is transmitted by the HV field device to the other device, has a structure exposed through a Process Automation Device Information Model (PA-DIM).

35. The HV field device of claim 26, wherein: Transmitting the data corresponding to the physical function of the HV field device to the other device via the established communication session includes publishing the data corresponding to the physical function of the HV field device; and The other device is a subscriber to the data publication.

36. The HV field device of claim 35, wherein: The one or more non-transitory memories of the HV field device store a publication list defining a set of data to be published by the HV field device, the publication list indicating data corresponding to the physical function of the HV field device.

37. The HV field device of claim 36, wherein: The publication list is defined by the subscriber.

38. The HV field device of claim 36, wherein: The release list is defined based on one or more configurations stored in a configuration database of the process control or automation system.

39. The HV field device of claim 26, wherein: The other device is a client of the HV field device; as well as Transmitting data corresponding to the physical function of the HV field device to the other device via the established communication session is in accordance with a client-server model utilized by the other device and the HV field device.

40. The HV field device of claim 26, wherein The tag corresponding to the HV field device is obtained from a configuration database of the process control or automation system and provisioned into the one or more memories of the HV field device prior to power-up of the HV field device.

41. The HV field device of claim 26, wherein: The tag corresponding to the HV field device includes at least one of a device tag or a data tag configured by the process control or automation system.

42. The HV field device of claim 26, wherein: The HV field device and the other device are included in a process control loop, and a configuration of the process control loop is stored in a configuration database of the process control or automation system.

43. A method at a highly versatile (HV) field device of a process control or automation system, the method comprising: detecting, by the HV field device when the HV field device is powered on, that the HV field device is connected to a node communication network via a communication interface of the HV field device, the node communication network having nodes identified by corresponding endpoint identifiers; transmitting, by the HV field device, via the node communication network to a Dynamic Host Configuration Protocol (DHCP) server of the node communication network, a request for an endpoint identification by which the HV field device will be identified within the node communication network, the request including an indication of a tag of the HV field device, the tag identifying the HV field device within the process control automation or automation system; obtaining, by the HV field device, an endpoint identifier assigned to the HV field device from the DHCP server via the node communication network; establishing, by the HV field device, over the nodal communication network and using the endpoint identification assigned to the HV field device, a communication session with another device that is a consumer of data indicative of physical functions performed by one or more physical components of the HV field device during runtime operation of the process control or automation system to control an industrial process; as well as During the runtime operation of the process control or automation system, the data indicative of the physical functions performed by the one or more physical components of the HV field device is transmitted by the HV field device to the other device via the communication session to control the industrial process.

44. The method of claim 43, wherein: The DHCP server is a first DHCP server among multiple DHCP servers; The method further includes, upon detecting connection of the HV field device to the node communication network, broadcasting, by the HV field device via the node communication network, a discovery message corresponding to a plurality of the DHCP servers, and receiving, at the HV field device, a provision message from the first DHCP server in response to the broadcast discovery message; as well as Transmitting the request to the first DHCP server is based on the offer message of the first DHCP server.

45. The method of claim 43, wherein: The endpoint identification of the DHCP server has been provisioned into and stored at the HV field device before powering up the HV field device and detecting that the HV field device is connected to the node communication network; as well as Transmitting the request for identifying the endpoint identification of the HV field device within the nodal communication network is based on the endpoint identification of the DHCP server stored at the HV field device.

46. ​​The method of claim 43, further comprising: providing, by the HV field device, to a network node manager of the node communication network, an indication of an association between the tag of the HV field device and the endpoint identification assigned to the HV field device, the network node manager storing an indication of an association of respective tags of a plurality of devices communicatively connected to the nodal communication network with respective endpoint identifications identifying the plurality of devices within the nodal communication network; as well as At least some of the tags of the plurality of devices are defined by configurations stored in a configuration database of the process control or automation system, and at least some of the identifications of the plurality of devices include identifications of the HV field devices.

47. The method of claim 46, wherein: an indication that a Domain Name Service (DNS) server of the node communication network has access to an association of respective tags of the plurality of devices with respective endpoint identifiers identifying the plurality of devices; providing, by the DNS server, a response to a request for the respective endpoint identifiers of the one or more devices based on the respective states of the one or more devices and the association of the respective tags of the one or more devices with the respective endpoint identifiers corresponding to the one or more devices; as well as The method further comprises: receiving, at the HV field device, from the DNS server, a request for a current status of the HV field device; as well as A response to the request is transmitted by the HV field device to the DNS server, the response including an indication of the current status of the HV field device.

48. The method according to claim 43, in, Prior to powering up the HV field device and detecting that the HV field device is connected to the node communication network, an endpoint identification of a log server of the node communication network has been supplied to the HV field device and stored at the HV field device; and The method further includes sending, by the HV field device, at least one of the following to the endpoint identifier of the log server: an indication that the HV field device has been connected to the nodal communication network, an indication of completed establishment of a communication session with said other device, a respective indication of each transmission of respective data indicative of said physical function during said runtime operation of said process control or automation system, an indication that the communication session has ended, or a respective indication of each of a plurality of other events occurring at the HV field device while the HV field device is connected to the nodal communication network.

49. The method of claim 43, wherein: Prior to power-up of the HV field device, one or more security credentials associated with the HV field device have been provisioned into and stored at the HV field device; The one or more security credentials associated with the HV field device include at least one of: one or more keys, one or more certificates, or one or more passwords; as well as Establishing the communication session with the other field device includes comparing at least some of the one or more security credentials stored at the HV field device to one or more security credentials provided by the other device.

50. The method of claim 43, wherein: transmitting data indicative of the physical functions performed by the one or more physical components of the HV field device to the other device comprises publishing data indicative of the physical functions performed by the one or more physical components of the HV field device; and The other device is a subscriber of the published data.

51. The method of claim 50, wherein: the HV field device storing a publication list defining data sets to be published by the HV field device, the publication list indicating data indicative of the physical functions performed by the one or more physical components of the HV field device; as well as Publishing data indicative of the physical functions performed by the one or more physical components of the HV field device is based on the publication list.

52. The method of claim 51, wherein At least one of the following is satisfied: the publication list is defined by a subscriber, or the publication list is generated based on one or more configurations stored in a configuration database of the process control or automation system.

53. The method of claim 43, wherein: transmitting data indicative of the physical functions performed by the one or more physical components of the HV field device to the other device is based on a client-server model; and The other device is a client of the HV field device.

54. The method of claim 44, wherein: The tag of the HV field device has been provisioned into and stored at the HV field device prior to power-up of the HV field device and is obtained from a configuration stored in a configuration database of the process control or automation system.

55. The method of claim 54, wherein The tag corresponding to the HV field device includes at least one of a device tag or a data tag configured by the process control or automation system.

56. The method of claim 43, wherein Transmitting data indicative of the physical functions performed by the one or more components of the HV field device is in accordance with a data structure exposed via a Process Automation Device Information Model (PA-DIM).

57. The method of claim 43, further comprising synchronizing a clock of the HV field device with corresponding clocks of one or more other nodes of the node communication network.

58. The method of claim 43, wherein Transmitting the request for the endpoint identifier for identifying the HV field device within the node communication network includes transmitting a selection corresponding to the endpoint identifier for identifying the HV field device within the node communication network, the selection being based on a prefix corresponding to the node communication network and advertised at the communication interface of the HV field device.

59. The method according to claim 43 also includes the HV field device obtaining at least one of the following from the DHCP server: an indication of a time server, a domain name, a lease time of the endpoint identifier used to identify the HV field device within the node communication network, a subnet mask, an indication of a gateway, or an indication of a DNS server.

60. The method of claim 43, wherein Transmitting the data by the HV field device to the other device to control the industrial process includes transmitting the data to a controller included in a process control loop defined in a configuration database of the process control or automation system.

Images