Network resource management in a communication network for a control and automation system

Abstract

A method and related system, including an implementation controller configured to communicate with a plurality of highly general field devices coupled to the controller via a communication network. The method and system also include configuring the network to facilitate communication of traffic over an Advanced Physical Layer (APL) medium. One or more APL power switches are configured to provide connections to other devices and each includes a power source to provide power via the medium. One or more APL field switches, each receiving power from a power switch, are configured to distribute communication signals and power signals to field devices communicatively coupled to the respective field switches. The method also includes configuring a network resource management component to manage network resources to facilitate communication of traffic over the network, the traffic including managed traffic known to the management component and unmanaged traffic unknown to the management component.

Description

Technical Field

[0001] This application generally relates to process control and factory automation systems, and more particularly, to enhanced field devices used in such systems that are capable of performing various different functions simultaneously in different scenarios 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 that are communicatively coupled via a physical layer to one or more field devices. The physical layer can be an analog, digital, or combined analog / digital bus, or can include one or more wireless communication links or networks. Field devices can be, for example, valves, valve positioners, switches, and transmitters (e.g., temperature, pressure, level, and flow rate sensors) that are located within the 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 rate, temperature, or pressure, etc., to control one or more processes being performed within the process plant or system. Intelligent field devices, such as field devices compliant with the well-known Fieldbus protocol, can also perform control calculations, alarm functions, and other control functions typically performed within a controller. Process controllers are also typically physically located within the plant environment, receive signals indicative of process measurements made by the field devices and / or other information related to the field devices, and execute control applications that run, for example, 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 within the field devices, such as and Fieldbus field devices. To perform such communication, the control module in the process controller sends control signals to various different input / output (I / O) devices, and then these input / output devices send these control signals to the actual field devices through dedicated communication lines or links (communication physical layer), thereby controlling the operation of at least a part of the process plant or system. For example, it controls at least a part of one or more industrial processes running or executed within the plant or system. The I / O devices, which are also usually located in the plant environment, are typically arranged between the process controller and one or more field devices, and realize the communication therebetween, for example, by converting electrical signals into digital values and converting digital values into electrical signals. 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 the first I / O device is used to support HART field devices, the second I / O device is used to support Fieldbus field devices, the third I / O device is used to support Profibus field devices, etc. As used herein, field devices, controllers, and I / O devices are generally referred to as "process control devices", and are usually located, arranged, or installed in the field environment of the process control system or plant.

[0003] Furthermore, information from field devices and process controllers is generally 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 controller via a data highway or communication network. These devices are usually placed in the control room or other locations 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 generally centralized across the entire process plant or a part of the process plant. These hardware devices run applications that can, for example, enable an operator to perform functions related to controlling the process and / or operating the process plant, such as changing the settings of process control routines, modifying the operation of control modules within the controller 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 the configuration database, etc. The data highway used by the hardware devices and the process controller can include wired communication paths, wireless communication paths, or a combination of wired and wireless communication paths, and generally uses 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 factory, and these field devices are typically communicatively coupled to a process controller using one of various different types 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 particular 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 can connect to the controller using a wireless communication physical layer, which can include a wireless gateway and transmitter / receiver devices. Further, field devices are typically configured to communicate with a process controller using one of various different highly specialized communication protocols. These communication protocols are typically digital signal protocols, but can 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., ON commands 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, a more complex protocol can use, for example, a high-speed addressable remote transducer communication protocol to transmit analog values, where digital communication is superimposed on the analog values. Other field devices can use fully digital communication that provides many types of communication (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 also being used. Each of these communication protocols requires or needs to be supported by a specific physical layer, which can include physical layers such as two-wire, four-wire, etc., specific switches, etc. In addition, the physical layer can specify maximum or minimum line lengths, line thicknesses, line types, terminal types, other electrical characteristics, and so on. However, importantly, the field devices are configured to communicate using a single protocol and have a unified interface for communicating using that communication protocol and the physical layer associated with that protocol.

[0005] Due to the development of these various different field device communication protocols, each of which typically uses a different communication line (physical layer) and signaling format, the various different field devices (e.g., field devices using different protocols) communicate through different input / output devices (I / O devices) to a process controller, and each different I / O device conforms to a different protocol in the process control protocol and supports a specific type of physical layer. That is, a typical plant can have a controller coupled to multiple different I / O devices, the I / O devices including Fieldbus I / O devices (which are in turn coupled to one or more FOUNDATION Fieldbus field devices via a two-wire or four-wire bus conforming to FOUNDATION Fieldbus), HART I / O devices coupled to each of one or more HART-compliant field devices via a separate two-wire or four-wire single-branch connection, CAN I / O devices coupled to one or more CAN-compliant field devices via a CAN-compliant wiring connection, and so on.

[0006] In addition, coupling the communication port of a field device to a terminal block of an I / O device and ultimately to a process controller in a process plant is typically a complex process. The field device must be coupled to an I / O card that converts the signals received from the field device into signals that can be processed by the process controller and converts the signals received from the controller into signals that can be processed by the field device. Thus, each channel of each I / O card corresponding to a specific field device must be associated with an appropriate signal type (so that the signals can be properly processed by the I / O card), and the I / O card must be communicatively coupled to a controller or multiple controllers that will ultimately receive signals from and / or send signals to the field device coupled to that I / O card.

[0007] As described above, each field device uses a specific communication medium or physical layer (e.g., two-wire cable, wireless link, or fiber optic) 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 dedicated process control communication protocols (HART, CAN, WirelessHART, FOUNDATION Fieldbus, PROFIBUS, etc.) developed in the process control industry. Further, the I / O device is typically separately connected to the process controller via another bus or wired connection. Using these different input / output devices means that the physical and logical connections between different field devices must be precisely mapped so that the controller connected to different I / O devices can keep track of which field devices are connected to which ports of each input / output device in order to route signals to that field device via the correct "path". In the HART protocol, this problem is particularly troublesome, in which each field device is connected to a different output port of the HART-compliant I / O device. Additionally, communication with process control field devices must occur via a defined communication path, which typically includes the field device communicating with a dedicated I / O device (usually via a first communication protocol), the I / O device communicating with the process controller (via a second and different communication protocol), and the process controller communicating with a user device or application (e.g., via yet another different communication protocol, with a process control operator application, a process control configuration application, etc. located in a server or other user interface device). In any case, all communication to and from the field device is routed or sent via the I / O device and the process controller via a dedicated communication path (link). Thus, all data to and from the field device must be sent through the process controller and one or more I / O devices. In this scenario, the process controller must initiate and coordinate all messages or communication to and from the field device via the 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 level of security because all applications seeking to communicate with the field device must be able to (and be authorized to) communicate with the process controller, which then acts as a proxy or server for information from the field device. Additionally, external applications cannot communicate directly with the field device.

[0008] While process control field devices typically use dedicated communication hardware and protocols, it is well known that general-purpose IP or other packet-based communication protocols are used to perform communication between certain other devices within a process plant. For example, packet-based or general-purpose IP protocols are typically used over an Ethernet bus that communicatively couples one or more distributed process controllers to one or more user interfaces, databases (e.g., configuration databases and history databases), servers, etc. within a backend plant environment. As such, Ethernet, which is the physical layer and part of the data link layer, is an important communication platform for automation systems because Ethernet enables flexibility, scalability, and performance in ways not previously seen in automation. To help support the adoption of Ethernet in automation, an 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 run on top of the Ethernet physical layer.

[0009] To support this emerging development of Ethernet-based communication in process control, the FielComm Group has standardized HART-IP as part of the HART7 release. 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 now used in monitoring, control, diagnostic, and condition monitoring applications. Since HART-IP already has a complete description of the devices available to it, it is a good protocol for the layer above APL. Additionally, another protocol that is seeing widespread support at the device level is OPC Unified Architecture (OPC UA). Although OPC UA itself does not understand device communication and types, significant efforts are being made in this regard to provide some level of support. Although HART-IP and OPC UA may be relatively quickly adopted by the market, they will not be alone in their use. Other protocols such as EthernetIP and PROFINET are already available over Ethernet and will be able to run on APL when it becomes available. Additionally, 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 have an installed base that heavily relies 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 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 marshalling cabinets or devices. It is not yet clear how these advanced protocols can be integrated into a typical process plant architecture to operate in a reliable and robust manner.

[0011] Furthermore, in addition to control systems, there are other systems that have been developed to support other activities in process plant and manufacturing plant automation environments. Plant Asset Management (PAM) or maintenance systems are typically set up so that maintenance personnel can perform maintenance activities on equipment in a plant or manufacturing plant setting (such as field devices, but also including other types of equipment). PAM is used to configure and commission equipment, run diagnostics on the equipment once it is deployed, monitor equipment alarms, and perform a long list of many other functions. Further condition monitoring systems are becoming increasingly common and are being deployed at many sites. Condition monitoring systems can perform various 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 returned recommendations to users and, in some cases, to the control system itself. Similarly, data logging systems exist in plant and manufacturing plant automation settings to collect and record data for later use. For example, energy and monitoring data can be collected by the data logging system in a centralized manner for analysis and to establish an alarm management system, such as if water leakage or energy loss is detected due to a leak or rupture in a pipeline. Similarly, smart metering systems are being implemented in many settings to perform on-going 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 of what materials are present. Smart metering refers to the process of installing smart meter reading systems, reading these meters either through a controller or independently through a remote monitoring system, 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 orders or rules, 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 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 some or all of the process control field devices and use some or all of these process control field devices. However, in these cases, the application, server, or other data collection device must communicate with the field devices via the process controller using the various dedicated field device protocols and physical layers installed for the field devices in order to obtain data from the field devices, send messages to the field devices, and perform other activities regarding the field devices. Similarly, in these cases, the process controller (and typically, one or more I / O devices) participates in and is responsible for performing the communication with the field devices to support these other systems, and the field devices themselves do not have specific knowledge or capabilities to directly support these other systems. This technology places the process controller in the middle of the communication with the field devices and is responsible for performing the communication with the field devices to support other applications or uses in addition to process control, such as maintenance activities, continuous monitoring, metering, etc. This additional load may make the process controller less effective, or may result in lost or slow communication with a particular field device because the process controller needs to prioritize the communication that is necessary or required in any given situation. Additionally, 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 communicates directly or indirectly with multiple different applications or clients and supports multiple different applications or clients while simultaneously performing standard process and factory automation control functions. Additionally, various different process control and factory automation network architectures, particularly communication architectures, support the general-purpose field device to enable the general-purpose field device to communicate with multiple different client devices or applications (each associated with a different system) simultaneously via a common communication network infrastructure using the same or different communication protocols. In one case, the communication architecture uses an IP-based communication protocol and infrastructure directly connected to the highly versatile field device, and the communication architecture can use one or more switches to route IP communications to / from the field device to other client devices such as process or factory automation controllers, condition monitoring systems, factory asset management systems, data recording systems, etc. In this case, the highly versatile field device can be connected via an APL network (first-level network) through a switch to one or more client devices (e.g., process or factory automation controllers, PAM system devices, data recorder systems, etc.), and then to a second-level network using another IP-based packet communication protocol, such as Ethernet. These one or more systems (e.g., the process controller of a process control system, the PAM server of a PAM system, the data recorder database, the condition monitoring application 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 obtain access to the highly versatile field device or directly retrieve data from the highly versatile field device.

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

[0015] In yet another scenario, cloud-based applications and devices (clients) can be directly connected to a first-level network via a first-level network switch (such as an APL power switch) to provide support for applications at a remote site. Such 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 recording systems, condition monitoring systems, etc. In another scenario, highly versatile field devices can be installed in a more traditional process control architecture that includes traditional or legacy field devices connected to an APL network or other IP-based communication network set up in a factory. In yet another scenario, highly versatile field devices can be connected to a flattened 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 recording systems, condition monitoring systems) are connected.

[0016] The highly versatile (HV) field devices and network architectures described herein are capable of supporting APL or other Ethernet- or general-IP-based physical layers and various communication protocols operating thereon in such a way that the highly versatile field devices can simultaneously act as servers for multiple different client devices. Additionally, when protocols such as security protocols require additional handshakes, acknowledgments, etc., the highly versatile field devices described herein are capable of nesting protocols within other protocols for use. Further, 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 advanced protocols such as HART-IP, OPC UA, Ethernet, and other protocols. The highly versatile field devices and associated network architectures described herein support a hybrid physical layer and multi-protocol support, which can be used to achieve improved control while providing direct support for non-control systems, as the highly versatile 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 combinations of control and industrial Internet of Things (IIoT) applications (also commonly referred to herein as monitoring systems) interested in measurement and actuator data, their capabilities, their diagnostics, and information determinable by combinations of these measurements, capabilities, and diagnostics.

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

[0018] Thus, a highly versatile (HV) field device can be a node of a process control and / or automation network as described herein, which network is generally referred to herein as a node communication network. The node communication network generally supports packet-based, IP-based, or other advanced protocols for communicating information between the 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 within the node communication network by a unique endpoint identifier. Thus, in an embodiment, a system for managing the 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 associations of corresponding tags or identifiers of multiple devices used in the process control or automation system with corresponding endpoint identifiers of the multiple devices used in the node communication network, where the multiple devices include one or more highly versatile (HV) field devices. Each of the one or more HV field devices has a corresponding one or more physical components that perform one or more corresponding physical functions during runtime operation of the process control or automation system to control, for example, an industrial process. The network node manager also includes a status database that stores the corresponding statuses of the multiple devices. The DNS of the system provides a response to a request for an endpoint identifier of a particular device among the multiple devices via the node communication network, where the response is generated based on the mapping database and the status database of the network node manager.

[0019] In addition, since highly versatile (HV) field devices can be added to a node communication network and discovered, in an embodiment, a 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, and a label or identifier corresponding to the HV field device has been supplied and stored in the one or more non-transitory memories. 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: when the HV field device is powered on, detect that the HV field device is connected to the node communication network via the communication interface; and transmit, via the node communication network, a request for an endpoint identifier for the HV field device to a DHCP server of the node communication network, wherein the request includes an indication of the label or identifier corresponding to the HV field device. Execution of the computer-executable instructions by the one or more processors causes the HV field device to further perform the following operations: obtain, via the node communication network, an endpoint identifier that has been assigned to the HV field device by the DCHP server; and establish a communication session with another device on the node communication network and by 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 the physical functions performed by the HV field device during runtime operations of the process control or automation system. Additionally, execution of the computer-executable instructions further causes the HV field device to perform the following operation: during runtime operations of the process control or automation system, transmit data corresponding to the physical functions performed by one or more physical components of the HV field device to the other device via the established communication session, thereby controlling the 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 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 respective endpoint identifiers within the node communication network. Additionally, 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, the HV field device being identified 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 via the node communication network, the endpoint identifier that has been assigned to the HV field device from the DCHP server. Further, the method includes establishing, by the HV field device on the node communication network and by using the endpoint identifier assigned to the HV field device, a communication session with another device, wherein the other device is a consumer of data indicative of a physical function performed by one or more physical components of the HV field device during runtime operation of controlling an industrial process in the process control or automation system. Additionally, the method includes transmitting, during runtime operation of the process control or automation system, data indicative of a physical function performed by one or more physical components of the HV field device to the other device via the communication session to control the industrial process.

[0021] Furthermore, using a highly versatile (HV) field device in a node communication network, in combination with the above-described device discovery method, benefits from a complex network resource management scheme that can be implemented in the node communication network. In an embodiment, a controller controls physical devices in an industrial process or a factory automation plant, the physical devices performing 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 and transmits parameters to the controller. The communication network includes an Advanced Physical Layer (APL) infrastructure - APL cabling, one or more APL power switches that provide connectivity and power via the APL cabling, and one or more APL field switches that receive power from the one or more APL power switches and distribute power and connectivity to the HV field device, and also includes a network resource management component 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 devices and non-TSN devices can operate on the communication network. In an embodiment, the deterministic network resource management component allocates network resources such that time-critical data is allowed to be transmitted between a source and a destination with minimal blocking. In some embodiments, the network resource management component includes one or more outbound ports. Each outbound port includes a plurality of queues, and each queue accommodates a corresponding class of network traffic. The queue selection unit for each outbound port is configured to receive input data and determine which queue to place the input data in, while the transmission selection algorithm is configured to select which data to take from each of the plurality of queues. Each queue has an associated gate, and the gate control list determines which of the plurality of gates is opened. If the gate is closed, the transmission of the data is blocked even if the transmission selection algorithm has selected the data for transmission, so that priority can be given to data other than the data with the highest assigned priority. In an embodiment, the time-aware shaper controls or synchronizes the gate control list of each outbound port to create a clear communication channel for ultra-low latency data transmission.

[0023] In embodiments implementing a non-deterministic network resource management component, the network resource management component includes an interface that controls network traffic through a switch port by enabling and disabling ports and throttling the network through the ports, especially when the network traffic is identified by a source, a destination, and an application type. A flexible runtime model is used to allocate network resource usage, and in an embodiment, when a new device joins the communication network, the network resource management component optimizes the allocation of network resources on the network, partly by controlling one or more APL field switches and / or power switches. In an embodiment, a certain percentage of the network resources is allocated to unmanaged network traffic, and when the detected percentage of unmanaged traffic exceeds the allocated percentage, the network resource management component adjusts the switch.

[0024] In an embodiment, a method of managing network resources in an industrial process control or factory automation system includes implementing a controller in the system that controls physical devices. The controller is configured to perform operations on one or more raw materials to convert the materials into products and 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 further includes using one or more APL power switches to configure the communication network to facilitate communication of network traffic over an APL medium, each APL power switch being configured to provide connections to other devices and each APL power switch including a power source to provide power via the APL medium. Additionally, 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 being configured to distribute both communication signals and power signals to HV field devices communicatively coupled to the respective APL field switch via the APL medium. The method further 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 it.

[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 of establishing communication between an application and an HV field device and between HV field devices. In an embodiment, a method includes receiving, at an HV field device, a message from a first client device or application indicating a selection of a first publication category from a plurality of publication categories, the first publication category corresponding to a type of information desired by the client device. The HV field device transmits to the first client device or application an identification of each publication list of a plurality of publication lists corresponding to the first category of the plurality of publication categories. 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 the first list of the plurality of publication lists identified by the HV field device from the first client device or application, and thereafter transmits the set of parameters associated with the first publication list of 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 an embodiment, the publication list may include a manufacturer-defined publication list, a user-defined publication list, and / or a customized publication list. In an embodiment, 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 among 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 among the plurality of publication categories received from the second client device or application. The method further includes receiving, at the HV field device, a selection of one of the publication lists in 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 set of parameters associated with the selection of one of the publication lists in the second plurality of publication lists received from the second client device or application. In an embodiment, receiving a selection of one of the publication lists from the first or second device or application further includes receiving an update rate that specifies the frequency at which a set of parameters associated with one of the publication lists will be transmitted from the HV field device to the corresponding client device or application.

[0027] In various embodiments, the 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-purpose field device as described herein.

[0029] Figure 2 illustrates an APL network in which a highly general-purpose field device as described herein may be used.

[0030] Figure 3 illustrates a first example communication architecture that uses an APL network to support access to a highly general-purpose field device by multiple client applications / devices.

[0031] Figure 4 illustrates a second example communication architecture that uses an APL network to support access to a highly general-purpose field device by multiple client applications / devices.

[0032] Figure 5 illustrates a third example communication architecture that uses an APL network to support access to a highly general-purpose field device by multiple client applications / devices.

[0033] Figure 6 illustrates a fourth example communication architecture that uses an APL network to support access to a highly general-purpose field device by multiple client applications / devices.

[0034] Figure 7 Shows a fifth example communication architecture that uses an APL network to support access by multiple client applications / devices to highly general-purpose field devices.

[0035] Figure 8 Shows Figure 1 a block diagram of various security features and components implemented in a highly general-purpose field device.

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

[0037] Figure 10 Shows a first example message flow that may occur when initially connecting a highly general-purpose field device to Figure 9 a node communication network.

[0038] Figure 11 Shows a second example message flow that may occur when initially connecting a highly general-purpose field device to Figure 9 a node communication network.

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

[0040] Figure 13 Shows a block diagram of a node management system of a node communication network including multiple network node managers.

[0041] Figure 14 Shows a block diagram of a network management component configurable to manage network traffic in the disclosed communication architecture.

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

[0043] Figure 16 is a diagram of two example data streams of a controlled network managed by a network management component of Figure 14 above.

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

[0045] Figure 18 Shows Figure 17An example communication flowchart adopted by the publish-subscribe communication architecture. Detailed implementation

[0046] Now refer to Figure 1 which generally shows a highly versatile (HV) field device 10 in block diagram form. In particular, the highly versatile field device 10 includes field device hardware 12, which can be, for example, one or more sensors, actuators, valve seats and 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, 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 plant or manufacturing facility setting, or controls or affects one or more physical phenomena in a plant or manufacturing facility 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, a 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, 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 the processor 14 or for transmission to the processor 14, and vice versa. The communication interface 18 can convert signals to be sent from the processor 14 so as 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. Further, the processor 14 can execute one or more hardware control applications 30 (which can 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 can be stored in the ROM or RAM of the memory 16, and / or can be implemented as an ASIC, an executable application, or in any other desired manner.

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

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

[0050] Importantly, the processor 14 of the device 10 is powerful enough to have 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 as separate applications sharing processor resources in a structured manner. 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 various lightweight operating systems such as the ThreadX operating system. The various different applications 32 and processors 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 are simultaneously executed in the processor 14, which enables the general-purpose field device 10 to communicate simultaneously (i.e., in an overlapping manner) with different external applications (commonly 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 can conform to any desired standard communication protocol or paradigm, such as IP or packet-based protocols such as TCP, UDP, HTTP, HTTPS, TLS, DTLS, etc.

[0051] As will be understood, during operation, the OS 34 executed on the processor 14 can establish and manage a communication stack 38, such as TCP, UDP, or other IP or packet-based stacks, to perform external, packet-based digital communication via the communication interface 20. Additionally, the OS 34 can establish and manage multiple different communication threads (processes) that can 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 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, OPC protocols such as the OPC UA protocol, email protocols, 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 referred to as 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 communicate more effectively with different clients (i.e., external devices or applications). In Figure 1In the example shown, the OS 34 manages four threads 40, where the 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, where the 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 where the fourth of the threads 40 uses an email protocol to communicate with an email server to send emails to one or more persons. 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 various different kinds 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 so on.

[0052] Accordingly, 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). Communication with these various different client systems can use different higher-level communication protocols that, based on the specific needs of the client application, use the underlying IP communication stack 38 to packetize. For example, some protocols such as HART-IP are more suitable for control applications and control communication because HART-IP typically provides faster, more reliable, and real-time data streams. Other protocols such as OPC UA are more suitable for monitoring or maintenance applications because the protocol provides more diagnostic capabilities without the need for fast or real-time communication. Other protocols can enable the device 10 to effectively provide or construct a web page for the client device to enable a user to browse device information from the device 10, send emails or texts, communicate with an external network or a public network such as the Internet, or provide other device information in other formats for different client applications and purposes. In addition, the communication system and the OS 34 of the highly versatile field device 10 can enable communication connections between the field device 10 and external client devices to be established independently of each other, without other client systems knowing which other systems are accessing or communicating with the highly versatile field device 10.

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

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

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

[0056] Generally, the highly versatile field device 10 is configured to operate in a plant or factory floor environment. For example, it includes a communication network that supports high-level protocols running over an open physical layer to perform communication between the field device and one or more client devices, which can be devices associated with any number of different systems, such as control systems, maintenance systems, monitoring systems, etc. Thus, the client device can 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 the Advanced Physical Layer (APL). For example, Figure 2 An APL-based network 80 is shown, where the highly versatile field device 10 can be used to provide support to multiple client applications and devices. The APL network 80 supports communication between various field devices 82 (any one or all of which can be Figure 1 the highly versatile field device 10) and any other device (e.g., a controller, a server, a user interface device, etc.) using packet-based or high-level (e.g., general-purpose IP-based) communication protocols. Importantly, the 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. Different from previous control-specific communication physical layers (e.g., those associated with protocols such as FOUNDATION Fieldbus, HART, Profibus, CAN, etc.), the APL provides sufficient power (in the form of voltage and current) on the two-wire bus to power a microprocessor (e.g., Figure 1 the microprocessor 14) based on a general-purpose or higher-level operating system within the field device connected to the APL physical layer or bus. This higher power level is required to enable a processor with functions running a general-purpose or real-time OS, such as those referred to above Figure 1As described. However, APL does not provide much power (especially voltage) on the two-wire physical layer, such that it is dangerous to use the APL in a hazardous environment due to the risk of spark generation. Thus, APL has sufficient power to power a process control device with a microprocessor running an operating system such as a real-time operating system, without sufficient power to cause potential safety problems in the actual process control environment where the field device is located. Generally speaking, the APL network provides approximately 1.4 watts of power (on the spur line) to each device at a voltage of 14 volts or less, preferably at 10 volts or less. Additionally, the APL network provides a two-wire reinforced physical layer or wire by using 14-gauge stranded wire, which makes the wiring less susceptible to breakage in the field and enables more power (current) with a lower voltage level due to reduced resistance. Further, APL supports IP- or packet-based digital communication in the form of traditional Ethernet-based communication, making APL communication easy to use in other types of applications in addition to control applications, and thus extending the communication power of traditional Ethernet down to the process control or factory automation environment or factory, without the disadvantages of the Ethernet physical layer (which typically provides 48 volts on thin or higher-gauge single-strand wiring).

[0058] While using an APL network is described herein as a communication network for connecting to highly versatile field devices, other communication networks can also be used to connect to and power highly versatile field devices. Generally speaking, such networks preferably use a 14-gauge (.06-inch diameter) or lower (e.g., 12-gauge, 10-gauge, etc.) cable, and also preferably use a stranded cable to provide better power delivery with a stronger and more resilient cable. Further still, these networks preferably provide 14 volts or less and more preferably 10 volts or less of power to limit the occurrence of sparks in hazardous areas. Similarly, these networks should preferably provide at least 200 milliwatts of power, and in some cases can provide up to 2 watts of power to each device. In other embodiments, the network can provide at least 300 milliwatts of power to the device and can provide up to 4 watts of power. More preferably, the network provides between 1 and 2 watts of power to the field device at a voltage between 10 and 14 volts maximum, although lower voltages can be used, and the network used to power the field device can provide more power (watts) than the power specified herein.

[0059] In Figure 2In the system, network 80 includes an APL power switch 84, which is connected to a control system (such as a process controller) and / or other applications 90 within the cloud or other network via, for example, Ethernet or other bus 85. The cloud application 90 can be or can include any one or all of various different system applications, such as a control application (controller) associated with the control system, a maintenance application associated with the maintenance system, a monitoring application and device (server) associated with the monitoring system, etc. As an example, the cloud application 90 can include an analog application, a control application, a data storage and processing application, etc. In any case, the APL power switch 84 includes an APL power device that provides power through the 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 connected to the APL power switch 84 via a bus or wired network 88 that complies with the APL physical layer standard. As Figure 2 shown, the bus or network 88 can be a trunk line or can be a ring connection, as shown by the dashed portion of the bus 88. In any case, the bus 88 is the APL physical layer, including, for example, a two-wire or four-wire wired network that provides communication signals as well as power signals from the APL power switch 84 to the APL field switch 86. In addition, each APL field switch 86 has one or any other number of highly versatile field devices 82 connected to it 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 device 82.

[0060] Of course, the APL power switch 84 acts as a gateway to the bus 85 and operates to multiplex signals from an external source onto the link 88 using the communication protocol established for the network 80. Similarly, the power switch 84 can operate to decode messages from any field switch 86 on the link 88 and addressed to a destination external to the network 80 (which can be a message from a field device 82), and send those messages onto the link 85. Similarly, the APL field switch 86 decodes messages on the link 88, and if the message is addressed to one of the field devices 82 connected to the field switch 86, the field switch 86 places the message on a spur 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 those 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 as 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 can also receive power via the link 92, and that power is provided from the field switch 86 and ultimately from the APL power switch 84 and the power associated therewith via 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 within the operating conditions and hazardous areas of a process plant. In this case, the APL power switch 84 provides the connection between all standard Ethernet networks and field devices and includes power to supply power to the APL field switch 86 and the field devices 82. Typically, the power switch 84 will be located in a control room or in a junction box on a skid. 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 the spur 92. An Advanced Physical Layer (APL) project was initiated to create a protocol-neutral Ethernet that can address the issues of finding a long-distance Ethernet protocol. As described herein, this physical layer can be used in process automation and process instrumentation devices 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. In addition, APL extends 10BASE-T1L for use in hazardous areas, which enables the development of standards related to typical protection methods, especially intrinsic safety.

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

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

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

[0065] However, it is also possible to integrate the APL physical layer (and the IP communication protocol using that layer) within an existing network of factories or manufacturing plants. Specifically, the entire I / O system can be used in the field environment of a factory or manufacturing plant to support multiple I / O types while maintaining the more traditional I / O architecture of the factory and, at the same time, directly supporting multiple different systems from highly versatile field devices. Typically, the highly versatile field device 10 provides or supports a hybrid physical layer that can support multiple different communication protocols, including traditional process control protocols and more commonly used or general-purpose 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 An example of a more traditional factory and manufacturing plant automation control architecture incorporating or supporting the highly versatile (HV) field device 10 described herein is shown. Figure 3 The factory 100 includes process automation (PA) and factory automation (FA) components as well as control devices that are connected to one or more process and factory automation controllers via a communication network backbone such as an Ethernet communication network. Specifically, as Figure 3 shown, the factory 100 includes a factory automation area or section 102 and a process automation area or section 104. The factory 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 factory. 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 that is connected to an APL field switch 116 and multiple FA highly versatile field devices 110 via, for example, a 100M APL network connection 120, and includes an APL field switch 116 that is connected to each of a set of discrete FA highly versatile field devices 108.

[0067] Similarly, the process automation section 104 includes an APL power switch 122 that is 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-20 mA field device 132) and acts as an input / output device for the legacy field device. Similarly, the APL field switch 124B is shown directly connected to two highly versatile PA field devices 128 and is also connected to an APL field switch 124C, which in turn is 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, the highly versatile field devices 108, 110, and 128 can be communicatively connected to one or more controllers 140 on the network backbone 112 via various different APL field switches and APL power switches that use different APL-supported physical layers (or communication networks with different speeds), while performing control in the process and plant settings using traditional control techniques.

[0068] However, as Figure 3 shown, the network backbone 112 is connected via a switch 142 to an additional network 144 to which other factory or manufacturing plant applications and assets can be connected. In particular, as Figure 3As shown, a plant asset management device 145, one or more operator consoles 146, and one or more databases 148 (such as a control configuration and history database) can be connected to a network 144, which in this case can be a gigabit Ethernet network. Devices 145 - 148 can communicate with a controller 140 via a network switch 142 and directly communicate with highly versatile field devices 108, 110, and 128 on APL networks 104 and 106 via APL power switches 114 and 122. Additionally, the plant asset management system 145 can include an asset management application 150 that obtains data from various highly versatile field devices 108, 110, and 128 (e.g., by subscribing as a client). Further, other applications 151 / 152 and / or devices 154 (such as computer devices like servers or hosts) associated with other systems (such as monitoring systems, data recording systems, etc.) can be connected to the network 144 and act as clients for various data obtainable 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 (either in device 145 or in other devices connected to networks 144 and 112) that can discover any of the field devices in the highly versatile field devices 108, 110, and 128 and register with them to obtain data from them as a client (the field devices 108, 110, and 128 operate as servers for their internal data and information). Similarly, other applications 151, 152 can discover the field devices 108, 110, and 128 and register with them and subscribe to data from them. Once registered with the field devices 108, 110, 128, the plant asset management application 150 or other applications 151, 152 can communicate directly with the field devices 108, 110, 128 via the network 144, 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 plant automation controller 140 to use the field devices 108, 110, 128 to control the plant and manufacturing plant site without having to manage the communication for other systems such as the plant asset management system implemented in device 145 or act as a conduit for the communication for other systems. However, in this case, the switch 142 acts as a security switch (e.g., a firewall) such 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 3System 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. However, each of the factory automation and process automation systems can include any number of highly versatile field devices connected to a controller 140 (and network 112) via any number of different APL networks, where each APL network can have any number of field switches associated therewith. Additionally, as Figure 3 shown, the APL network can use different types of communication hardware and communication speeds (physical layer) for each network connection (e.g., depending on the use), and each APL network can include highly versatile field devices directly connected to its power switch or connected to its power switch via one or more field switches.

[0070] In another example architecture, Figure 3 the system can be extended to include or provide one or more applications in additional networks, such as in the cloud, to obtain access to the highly versatile field devices 10. For example, Figure 4 shows a system 160 similar to Figure 3 system 100, where network 144 is coupled via a firewall device 162 to an additional network 164 that can be a factory or plant business network within a factory or manufacturing plant. Network 164 can also be connected to the cloud 168 via an edge gateway 166 using, for example, the OPC UA protocol and a supported physical layer. One or more other applications associated with other systems such as monitoring systems, data recording systems, etc. can be stored and executed in computer devices in the cloud 168, and these devices and applications can communicate with the highly versatile (HV) field devices 108, 110, 128 acting 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 the 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 above 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, a factory and manufacturing plant automation network architecture can make highly versatile field devices (also referred to herein as highly connectable field devices) directly available to cloud-based devices or applications. A cloud-based topology can be used in a process factory 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 systems stream data from the factory, perform their analysis, and provide recommendations back to the user and, in some cases, back to the control system itself. Figure 5 A cloud-based topology is shown in which the network architecture 180 includes APL networks 102 and 104 connected to a cloud network 181 having various client applications 182 therein via APL power switches 114 and 122. The client applications 182 can be applications associated with any of the various systems described above, including process control or factory automation control systems, factory asset management systems, data recording systems, monitoring systems, etc. Additionally, these client applications 182 can communicate with the power switches 114 and 122 of the 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, the client applications 182 can directly access the highly versatile field devices 108, 110, and 128 of the APL networks 102 and 104 via the APL power switches 114, 122. This type of architecture is useful in providing support for remote sites in a factory or manufacturing plant automation setting to enable control and other access to highly versatile field devices via remote or cloud-based connections.

[0072] Figure 6 and Figure 7 show other control system architectures including highly versatile (HV) field devices that can be accessed by various client devices or applications. Specifically, Figure 6 and Figure 7 the network architectures are designed to work with both traditional networking and flat networking. Generally, traditional networking provides access to devices via 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 that can be Ethernet. The controller 210 is connected to one or more APL networks 216, each APL network 216 having 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 traditional process control field devices 224 via standard or legacy I / O devices 222, such as HART, FOUNDATION Fieldbus, WirelessHART, CAN, Profibus, and other I / O devices. Similarly, the I / O devices 212 can be communicatively connected to one or more APL networks 226, each APL network 226 having 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 be connected to the network 214 via the gateway 208 to obtain 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, the I / O devices described in detail in U.S. Patent Application No. 16 / 573,380, entitled "Integration of Multiple Communication Physical Layers and Protocols in a Process Control Input / Output Device," filed on September 17, 2019, the entire disclosure of which is hereby expressly incorporated herein by reference.

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

[0075] In Figure 6 the traditional network 200 and Figure 7 in the flattened network 250, device tagging must be unique. In both cases, the devices include unique IDs, are assigned unique tags, and support multiple application sessions. However, even here, the highly versatile field devices 220, 224, 230, and 270 described herein also support request and publish / subscribe models. To establish a publish / subscribe device, the publisher (highly versatile field device) must be discovered and, once discovered, a session is utilized for authentication. Once the session is established, the highly versatile 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 first used to 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 a plant asset management system (including the configuration of the devices). Generally, the plant asset management system is used to configure and commission the devices, perform diagnostic operations on the devices after they are deployed, monitor device alarms, and a long list of many other functions. In addition, the highly versatile field devices described herein can support an IIoT platform for continuous condition monitoring. More particularly, condition monitoring systems can be deployed at many locations to perform various functions, including energy monitoring, device and equipment monitoring, and process monitoring. Such monitoring systems can stream data from the plant, 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 a data logger system. As an example, many systems collect energy and monitoring data in a centralized manner in order to analyze and establish an alarm management system, for example, in the event of water leakage or energy loss 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 a secure smart metering system. 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 an accurate reading of what materials are present. A smart metering system typically includes a smart meter reading system that is metered by a controller or independently by a remote monitoring system, and then the readings are transmitted 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 the environmental monitoring required by the Environmental Protection Agency (EPA) or the monitoring required for other uses. As an example, many factories have environmental reporting requirements, such as reporting of NOx, SOx, and other items. These systems tend to be dedicated systems that perform data collection, calculation, and reporting. Critically, the data from these systems is time-stamped, not affected by daylight saving time adjustments, and is secure. The highly versatile field devices described herein can additionally provide these additional features to the data provided to the client application.

[0078] Thus, as will be understood, the highly general-purpose field devices and field device network architectures described herein support a wide range of application scenarios. The data required in these scenarios is typically different. State monitoring applications require information about the operation and health of the device, as compared to control applications that require measured parameters, unit codes, and status information. 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 their unit codes and status information. On the other hand, valve condition monitoring data includes valve setpoints, travel, drive, instrument air, percentage of travel per reversal, temperature, and other measurements. To make it easier for device manufacturers, these different sets of device parameters for these different uses can be included in pre-built templates for control, condition monitoring, data logging, environmental monitoring, or other functions. Users may also define their own templates and download them to the highly general-purpose field devices. On the other hand, custom templates can be created on the fly. The client application can then subscribe to these templates. To streamline the plug-and-play operation of the highly general-purpose field devices, these templates can be included as part of the application connection, such that the field device (server) tells the client what templates it has, and the client can subscribe to them or define its own custom templates.

[0079] In any case, because the highly general-purpose field devices directly support IP communication with the customer devices, i.e., without going through a process controller that uses one or more proprietary control protocols and physical layers, the highly general-purpose field devices and the network architectures in which they are located require additional security over traditional field devices and networks. As described above, the highly general-purpose field devices described herein are capable of implementing IP-based connections simultaneously between these devices (i.e., field instruments) and multiple different client data consumers. Thus, the highly general-purpose field devices and the supporting network include a field device server and client applications and devices, where the field device server includes field devices such as sensors for 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, as well as applications stored on 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 interfaces of the highly general-purpose field devices described herein include session-oriented capabilities over IP and can support, for example, both UDP and TCP. Most real-time implementations use UDP, which gives the designer a fair amount of control over connection management, timeouts, and other capabilities. As a result, publish messages can be used to send periodic and exception-based data from the field device to subscribing clients such as controllers. The client subscribes to the device to receive the published messages. Once subscribed to the publish list of the field device, the client listens on an IP endpoint, and the field device publishes messages to that endpoint. Therefore, the highly general-purpose field devices and the networks in which these field devices reside must implement strict security.

[0081] In traditional control systems using traditional field devices, control system network security and control system design and operation assume that control instrumentation and instrumentation 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 the use of firewalls, network monitoring, and other defense mechanisms located between the layers of the control system quite extensively. However, in practice, the field devices and the field device network itself are usually not monitored, making it difficult to perform anomaly detection. 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 translated into other protocols such as MODBUS and OPC DA, where semantics and context are lost (e.g., unit codes). In these cases, when the client receives a measurement value, such as a device measurement value that is converted to an OPC DA value using the OPC DA status, the client will not know that the value or the status of the value has been changed. These systems do not provide a standardized way to map the raw value along with its unit code and status to automation applications and other clients.

[0082] The highly general-purpose field devices and the networks in which these devices 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 security trust chain. Specifically, Figure 8 is shown a general block diagram of the various security features provided in a highly general-purpose field device 10, for example, Figure 1 and in the network in which these devices reside. Figures 2 - 7 Specifically, as Figure 8 shown, the security features include a root of trust component 302, a secure boot feature 304, an endpoint identity feature 306, secure storage 308, and encryption capabilities 310. Additionally, the security features include secure communication features 312, device provisioning 314, and a security audit function 316.

[0083] In particular, each highly general-purpose field device 10 includes or incorporates a root-of-trust component 302, which forms the basis for device security. Trust in embedded security refers to the expectation that a field device operates as designed. In particular, device software trusts that the hardware operates as it should, applications running on the device trust that the operating system has not corrupted the device configuration, and remote systems communicating with the device trust the identity of the device to which the remote system is connected. The process of establishing this trust is called attestation, and the root of trust 302 for the field device is the point at which attestation and authentication begin. Once established, this root of trust extends through each trust layer and provides a basis for each trust layer. Thus, the root-of-trust component 302 is an important building block in the highly general-purpose field device 10 because the root-of-trust component 302 provides the basis for protecting the device and all communications with the device. The root-of-trust component 302 can be established using any of a variety of methods and can take many forms, but generally the root-of-trust component 302 ensures that the boot code on the field device is the code that the manufacturer intended. This root-of-trust feature 302 protects the boot code in a manner that makes it immutable or indestructible from 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 memory map of the device processor or directly from that location. Alternatively, the device can include a root-of-trust component 302 that enables updates and patching of the boot code by allowing the boot code to be loaded from a protected memory region into a certain protected memory store reserved for firmware execution. An important aspect of the root-of-trust component is to ensure that the initial code is as expected by the manufacturer before execution, and that this root-of-trust component protects the manufacturer's code (or updated code) from being tampered with by a third party. When the code starts, the root of trust derives its internal key from the provided device identity input, and the device performs a self-test and code verification on itself to verify its identity and establish a basic key 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 unauthorized code from being executed 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 bootloader, using encrypted boot files, and using a secure microprocessor. Although the secure boot feature 304 can be centered around digitally signed boot files, the boot is not secure unless those signatures are verifiable using some immutable root of trust. Therefore, to verify the boot files, when the device is manufactured or after manufacturing, using a trusted application, the highly versatile field device has a digital key installed therein (and established by the root of trust component 302), 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 recovery measures. That is, the secure boot process 304 provides the ability to securely repair the process control system in the event of device failure or damage, because the repair relies on a secure boot process that checks the validity of the firmware image that is booting 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 does not cause damage beyond itself.

[0085] In addition, the device secure boot process 304 provides or enables secure firmware updates. In particular, secure firmware upgrades include verifying the incoming payload intended to replace the existing firmware image, which is critical for maintaining device integrity throughout the system life cycle. The source of the payload and the payload itself must be verified before being applied, and with a properly implemented secure boot process 304, a failure to verify the incoming code results in a secure rollback to a known and verified boot image. In addition, the secure boot process 304 enables a secure connection to cloud resources, because the secure boot process 304 ensures that whenever the device attempts to connect to the cloud by using embedded keys and certificates, the device authenticates to the cloud.

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

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

[0088] In addition, the highly versatile field device uses and implements encryption 310 across the transport protocol (data in motion), storage (data at rest), and application (data in use). Although the various types of encryption services listed below can be used to implement encryption in this way, device manufacturers can use other encryption services. As an example, the highly versatile field device can use or include standard-based symmetric cipher suites (PSK or PKI), hash functions, and random number generators of appropriate strength and encryption algorithm implementations verified based on NIST / FIPS standards, and can achieve interoperability of cryptographic keys.

[0089] Furthermore, the highly versatile field device 10 provides secure communication 312 by including a secure end-to-end communication protocol stack. The highly versatile field device 10 can use TLS for secure transmission, use SHA-2 (a hash function for generating MAC codes) for the hash function, and can use AES-128 for encryption.

[0090] Similarly, the highly versatile field device 10 provides or includes secure device provisioning 314 (usually performed by the manufacturer in a secure or trusted environment using a secure process), which can include writing certain information to the device, such as device tags, pre-shared keys and / or certificates, system log server hostnames and ports, DNS server names, and optionally the default port number the device listens on and the static IP address and mask. The devices should be provisioned before they are installed in the factory. This provisioning is commonly 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 unit name 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 hostname and port used to connect to the system log server, (4) the name of the DNS server, (5) the static IP address and its subnet mask (this is optional), and (6) an optional port number in case the default port number is blocked by a firewall (this is also optional). All this information should be loaded into a secure location in the device. This information will also have to be available to the host that will initiate 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, which enables the monitoring of the field device 10 as part of normal operations. To assist with this 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 inputs, which can help continuously measure and evaluate risks and mitigate threats. This requires capturing system and security events (which may not be security events), transmitting the events to a host using the system log, and applying the ability to examine system events. To implement this functionality, the highly versatile field device 10 supports audit logging 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 circular list of 128 entry session summaries; and (5) a timestamp, such as an 8-byte unsigned integer timestamp. Each session summary record can include: (1) the client identity including the IP address (IPv4, IPv6) and port number; (2) the connection / disconnection time / date of the client; (3) the start / end configuration change counter; (4) the session status; and (5) a communication counter indicating the number of published (burst), request, and response PDUs. In addition, the highly versatile field device 10 can support the system log by supporting or providing push audit messages (system log messages) to a security information and event management system that supports the field device 10. These pushed messages are critical for detecting security attacks and unauthorized manipulation of the field device 10. Detection enables the improvement of plant security policies and procedures to minimize vulnerabilities.

[0092] As an example, the highly versatile field device 10 and 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, communication is protected using TLS. A session can be established using a certificate or a pre-shared key. The highly versatile field device 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 an 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 9FIG. 400 is a block diagram of an example system 400 for a node of a node communication network 402 that manages an industrial process plant or a manufacturing plant automation system, where at least one highly versatile (HV) field device 10 is a corresponding node of the network 402. In an example implementation, the system 400 may be included in or otherwise support embodiments of any one or more of the plant and manufacturing plant automation networking and control architectures shown in Figures 3 - 7 or otherwise support these embodiments. For example, at least a portion of the node communication network 402 may include Figure 6 a traditional process control network 200 of Figure 7 and / or at least a portion of the node communication network may include

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

[0096] Devices D1-Dn may include one or more field devices, each of which performs a corresponding physical function during the runtime operation of the 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 measurement devices, etc. In addition to field devices, devices D1-Dn may include other types of devices disposed within the field environment 412a of the process plant or automation network, such as controllers; I / O devices, systems, and / or their components; 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 the devices D1-Dn may be highly versatile (HV) field devices, such as the highly versatile field device 10. For example, devices D1-D4 and Dn are shown as highly versatile field devices in Figure 9 Some of the devices D1-Dn may be legacy or traditional devices, such as Figure 9The device D5 shown in

[0097] and can thus be communicatively coupled 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 thus enables the legacy device D5 to communicate via the communication network 402 through the APL component 410. Figure 9 shown) or communicatively coupled to the backbone 408 via respective APL components and / or APL networks ( Figure 9 not shown in Figure 9 ). These other nodes 418, 420, 422, 425 are typically (but not necessarily) located in the back-end environment of the process plant or automation network (and / or away from the process plant or automation network), as indicated by reference numeral 412b, and are shielded from or protected from the harsher field environment 412a of the process plant or automation network. As Figure 9 shown, one or more controllers 418, configuration databases or servers 420, and edge gateways 422 of the process plant or automation network can be directly coupled to the backbone 408 and / or otherwise communicatively coupled to the backbone 408 without using any APL components 410. For example, such components 418, 420, 422 can be communicatively coupled to the backbone 408 via a second-level network (e.g., a tier 2 network). Other systems 425, 428 associated with the process plant or automation network can also be communicatively coupled to the backbone 408 of the node communication network 402, for example, via a second-level network, a third-level network (e.g., a tier 3 network), and / or a higher-level network (e.g., a plant asset management system 425, a diagnostic system, an analysis system, a data recording system, a condition monitoring system, and / or other types of systems 428). For example, at least some of the other systems 425, 428 can reside in a cloud computing system. In general, the nodes 418-428 located in the back-end environment 412b are considered to be nodes of the node communication network 402, regardless of whether the nodes 418-428 utilize any APL components and / or networks to communicatively couple to the backbone 408.

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

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

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

[0101] On the other hand, within a process control system or automation network, each device D1 - Dn is identified and / or associated with one or more corresponding logical identifiers or tags, such as device tags, 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 the specific data that the device is to produce or consume. Generally, within one or more configurations of a process control system or automation network, e.g., within one or more configuration databases 420, the tags or identifiers that are identified and / or associated with the devices D1 - Dn are defined. One or more configuration databases 420 can be nodes of the node communication network 402, e.g., as Figure 9 shown, or one or more configuration databases 420 can be communicatively coupled to the devices D1 - Dn via one or more other types of process control or automation networks ( Figure 9 not shown in the figure), which can include legacy or traditional process control or automation networks. Some identifiers or tags can be supplied manually or automatically into the corresponding devices D1 - Dn (e.g., during bench supply 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 can be downloaded or otherwise stored in the corresponding devices D1 - Dn along with the configuration of the corresponding devices. The corresponding device tags and any corresponding data tags that identify and / or are associated with each device D1 - Dn are represented by the circled "tag" symbol in Figure 9 the figure.

[0102] A 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 communicatively connected to the node communication network 402. The network node manager 432 knows (e.g., stores information indicating it) all devices that have been connected to and discovered by the node communication network 402, such as the "nodes" of the node communication network 402. For example, the network node manager 432 may store the identities of the discovered devices (e.g., corresponding IP addresses, endpoint identities or names, and / or corresponding device identifiers) in a discovered device data store or database 435. In an embodiment, at least a portion of the discovered device data store 435 may be integrated with the network node manager 432 ( Figure 9 not shown), 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 shown. The network node manager 432 also stores and updates the corresponding status or condition of the discovered devices in the discovered device data store 435. Non-limiting examples of possible device statuses or conditions include debugged, active, inactive, offline, faulty, booting, undergoing diagnosis, restricted operation, and / or any other suitable status or condition. The device status or condition may be updated by the device itself or by other devices. In some embodiments, the device status and / or condition may 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 devices and / or associated with the discovered devices.

[0103] Additionally, the network node manager 432 is communicatively connected to other management nodes of the node communication network 432, such as a DHCP server or service 430, a DNS server or service 438, a security manager 440, and / or a system log server 442, via, for example, a backbone 408. Generally, 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 various management nodes 430, 438, 440, 442, and so on.

[0104] To this end, the discovered device data store 435 stores an association or mapping between device identifiers (such as the device label of a device and optionally data labels associated with the device) defined in the process control configuration database 420 and the corresponding IP address / endpoint identifier that has been assigned to the device by the DHCP server 430. Thus, the discovered device data store 435 may be 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 label A and two data labels 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 the associations between (1) the device label A and the IP address A1B2, (2) the data label B and the IP address A1B2, and (3) the data label C and the IP address A1B2.

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

[0106] In fact, the system 400 for managing nodes (e.g., nodes D1-Dn and 418-428) of the node communication network 402 further 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 for the assigned IP address of a second device from a first device, where the second device is identified in the request or query by a configuration 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., such that the first device can use the IP address of the second device to communicate with the second device. In some embodiments, the DNS server 438 also takes into account the device status indicated in the device status database 435 in its response. For example, if the second device is inoperable, the DNS server 438 may reply with an indication thereof 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] The system 400 for managing nodes (e.g., nodes D1-Dn and 418-428) of the node communication network 402 may include a security manager 440 communicatively connected to the node communication network 402. Generally, the security manager 440 of the node communication network 402 may provide and manage security credentials for various devices and nodes of the network 402. That is, the security manager 440 may automate certificate management as well as credential provisioning and management. For example, the security manager 440 may assign one or more keys and / or one or more passwords to each device, and the security manager 440 may verify certificates and / or other types of security credentials upon request, etc. Additionally, the security manager 440 may include an interface via which various security credentials may be provisioned or otherwise stored into the devices (e.g., before the devices are powered on in the field environment 412a via a workbench). Additionally or alternatively, the security manager 440 may provide various security credentials to a device when assigning the corresponding IP address (e.g., by the DHCP server 430) to the device. 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 tools or other computing devices may provide and / or obtain security credentials of the devices. Additional details regarding security credentials are described in other parts of 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") communicatively coupled to the node communication network 402. Generally speaking, the system log server 442 is a centralized log server that records or logs events regarding 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 a device connects to the network 402 and / or is about to disconnect from the network 402. For example, when the device is the highly versatile field device 10, the device can utilize the security audit function 310 (as discussed above with respect to Figure 8 to communicate connection, disconnection, and other types of information with the system log server 442. In some cases, the device can additionally notify the log server 442 of events related to other devices. For purposes of mitigating security concerns, the logs stored at the log server 442 can be audited and / or otherwise analyzed.

[0109] Note that although Figure 9 the DHCP server 430, network node manager 432, DNS server 438, security manager 440, log server 442, and mapping database 435 (e.g., the "management" nodes of network 402) are shown as separate and distinct nodes of the node communication network 402, this is for illustrative purposes only and not limiting. Any two or more of these management nodes 430, 432, 435, 438, 440, and 442 can be implemented as an integral node as needed. For example, the network node manager 432 can include the DNS service or server 438, the network node manager 432 can include the DHCP service or server 430, the DNS server 438 can include the mapping database 435, etc. Additionally, although Figure 9 each of the nodes or servers 430, 432, 435, 438, 440, 442 is shown as a corresponding single node, in an embodiment, the system 400 can include multiple of each of the nodes 430, 432, 435, 438, 440, and / or 442. Further still, any one or more of the management nodes 430-442 can be implemented or hosted by any suitable computing system, such as one or more physical and / or virtual servers, one or more databases, etc., which can be at least partially local or proximate to the process plant or automation system, and / or which can be at least partially remote from the process plant or automation system, such as at a server farm, in a cloud computing system, etc.

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

[0111] For illustration, Figure 10 an example message flow 500 that occurs when an example device 502 is initially connected to the node communication network 402 is shown. Device 502 can be a highly versatile field device, such as devices 10, D1 - D4, or Dn, or device 502 can be a legacy field device, such as device D5 that is connected to the APL component 410 and network 402 via an adapter 415. Thus, for the case where device 502 is a legacy device, adapter 415 represents the legacy device communicating with network 402, even though Figure 10 adapter 415 is not shown in Figure 9 the embodiments of system 400. Generally, message flow 500 can occur in Figure 8 and Figure 9 the embodiments of system 400, or can occur in other systems for nodes of a node communication network that manages a process control system or an automation network. However, for purposes of illustration and not limitation, message flow 500 is described below with reference to both

[0112] In example message flow 500, prior to power - on 505 and connection to the node communication network 402, the device 502 has been supplied with its own identity. That is, the unique identifier of the device (e.g., device tag) and optionally any data tags corresponding to the data that the device is to send and / or receive during runtime operation can have been supplied, for example, manually by an operator and / or by using a provisioning, commissioning, or other suitable tool such as security manager 440 or 605, or otherwise stored into the memory of device 502. The process of storing the identity and other information into the device when device 502 has not been powered on for runtime operation and when device 502 is not connected to network 402 is referred to herein as "bench - provisioning" and is described in more detail in other parts of the present disclosure. In any case, as previously discussed, the unique identifier of the device (e.g., device tag) and any data tags associated with device 502 have typically been defined in one or more configurations stored in the configuration database 420 of the process control system or automation network, and thus, device 502 is supplied with a logical identifier (e.g., the corresponding device tag) by which device 502 is known to the process control system or automation network, and optionally supplied with any corresponding data tags that are also known to the process control system or automation network.

[0113] The device 502 is physically set up and installed at its intended location in a process control plant or automation network, such as in its field environment (such as Figure 9 the field environment 412a), and any physical interface to the network 402 is physically connected to the device. Subsequently, the device 502 is powered on, as indicated by reference numeral 505. For example, the device 502 can use Figure 8 the secure boot feature 304 to power on.

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

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

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

[0117] In any case, 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 process control / automation network identity of the device (e.g., the device label) and the IP address / endpoint identifier that has been assigned to the device 502. In some implementations, the device 502 and the DHCP server 510 may additionally or alternatively know the corresponding association between each of the data labels of the device 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 implementation, the discovered device / mapping data store or database 522 is Figure 9 an embodiment of the discovered device / mapping data store 435.

[0118] In an example branch of the message flow 500 denoted by reference numeral 525, the DCHP server 510 can convey an indication of the 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 can update 530 the mapping database 522 with an indication of the new association between the identity of the device and the IP address assigned to the device 502 (and / or the corresponding association between each of the data labels of the device and the IP address assigned to the device 502). In an example implementation, the network node manager and / or DNS server 528 is Figure 9 an embodiment of at least one of the network node manager 432 or DNS server 438. Additionally or alternatively, the device 502 can convey an indication of the new association between the identity of the device and the IP address assigned to the device 502 (and / or the corresponding association between each of the data labels of the device and the IP address assigned to the device 502) to the network node manager and / or DNS server 528, as Figure 10 denoted by reference numeral 532, such that the mapping database 522 is updated accordingly (reference numeral 535).

[0119] Importantly, system 400 can provide capabilities for "plug and play" devices, such as Figure 11 shown in example message flow 550. In Figure 11 , a device 552 (e.g., "Device A") physically arrives at a location in a process control plant or automation network where the device 552 is to be installed and operates during runtime to control an industrial process. Device 552 can be a highly versatile device, such as one of the highly versatile field devices 10, D1 - D4, and Dn, or device 552 can be a legacy device, such as device D5 to be connected to the node communication network 402 via adapter 415 and APL component 410. Thus, for the case where device 552 is a legacy device, adapter 415 represents device 552 communicating via node communication network 402, even though Figure 11 adapter 415 is not shown in Figure 9 . Generally, message flow 550 can occur in an embodiment of system 400 of Figures 8 - 9 or can occur in other systems for nodes of a node communication network that manages a process control system or automation network. However, for purposes of illustration and not limitation, message flow 550 is described below with simultaneous reference to Figures 8 - 9 .

[0120] Before powering on 555 device 552 in the field for runtime operation, a device tag can be supplied to device 552 (e.g., bench supply), and optionally information such as corresponding data tags, one or more security credentials (e.g., keys, certificates, passwords, etc.), the respective IP addresses of DHCP server 430, DNS server 438, and / or network node manager 432, the IP address of system log server 442, the IP address of security manager 440, and / or other information. For example, an operator or user can communicatively and temporarily connect the otherwise unconnected device 552 to 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 supplied or otherwise stored in the memory of device 552, thereby bench supplying device 552. In an embodiment where security credentials are bench supplied to device 552, typically security manager 440 assigns one or more security credentials to device 552. In an embodiment where device 552 is a highly versatile field device 10, device 552 can utilize the on - board device provisioning feature 314 to obtain identification and security credentials from security manager 440, and the obtained information can be stored in the on - board security storage device 308 for use by features such as trust root 302, secure boot 304, encryption capabilities 310, secure communication 312, secure audit 316, etc.

[0121] In Figure 11For purposes of discussion and not limitation, an embodiment of system 400 that supports message flow 550 is arranged such that the network node manager includes or hosts a DNS service. That is, in Figure 11 the network node manager and the DNS service or server are an integral node, such as represented by reference numeral 560. Additionally, in Figure 11 the DHCP server is a separate node of the node communication network, such as represented by reference numeral 562. In an example embodiment, the network node manager / DNS service 560 is Figure 9 an embodiment of network node manager 432 and DNS server 438, and the DCHP server 562 is Figure 9 an embodiment of DHCP server 430.

[0122] When device 552 is powered on 555 (e.g., by utilizing secure boot feature 304), device 552 sends a request 558 to the integral network node manager / DNS service 560 for an IP address or endpoint identity via which device 552 will be identified within node communication network 402. For example, device 552 may utilize the IP address of the network node manager / DNS service 560 supplied to device 552 by the workbench to send 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 the DHCP server 562 (e.g., via message exchange 565) to obtain an IP address for 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 device 552 in response 568. For example, device 552 may store its assigned IP address / endpoint identity and other information in secure storage 308 at device 552. At this point 570 in message flow 550, device 552 is known or identified by its configured device identification or label within the process control system or automation network and by its assigned IP address / endpoint identity within node communication network 402. The association between the device's configured identification or label and the device's IP address / endpoint identity is stored in a mapping database or discovered device data store, such as mapping database 435, which, as previously described, is at least accessible by the network node manager / DNS service 560. Additionally, the network node manager / DNS service 560 updates the status of device 552 in the mapping database or discovered device data store to "connected", "active", "available", or some appropriate equivalent status indicating that device 552 is active and operational. In Figure 11In the illustrated example embodiment, the discovered device / mapping database is integrated with the network node manager / DNS server 560.

[0123] Accordingly, at this point 570 in the message flow 550, the device 552 has been "inserted" into the node communication network 402. That is, the device 552 is connected to the node communication network 402 and is available for communication with other nodes of the network 402. After the connection 570 is completed, the device 552 notifies the system log server 572 that the device 552 has been connected to the network 402 (e.g., as indicated by reference numeral 575), and the system log server 572 records the connection event. In the example, the system log server 572 is an embodiment of the system log 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 in Figure 11 the device 552 is shown as obtaining its assigned IP address by communicating with the network node manager / DNS service 560, this is only one of many possible embodiments. For example, the device 552 can obtain its assigned IP address by utilizing a broadcast discovery DHCP message, e.g., in a manner similar to that performed by the device 502 in the example message flow 500 of Figure 10 . In another example, the IP address of the DHCP server 562 is supplied to the device 552 workbench, and upon power-up 555, the device 552 can communicate directly with the DHCP server 562 to request and / or obtain the IP address and associated parameters of the device 552. Of course, other embodiments are possible.

[0125] Further referring to Figure 11 , when the device 552 remains "inserted" or connected to the node communication network 402, the network node manager / DNS service 560 tracks and updates the status and / or condition of the device 552 within the discovered device or mapping database (e.g., the discovered device / mapping database 435, as previously described, which is shown as integrated with the network node manager and DNS service 560 in Figure 11 ). In the 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 operating status from the device 552 in response to the poll, e.g., as indicated by the message exchange 578. For example, the network node manager / DNS service 560 can poll each device it knows (e.g., via the discovered device or mapping database) to obtain an update of the device status. Additionally or alternatively ( Figure 11(not shown), device 552 may itself provide its current state and / or condition to the network node manager / DNS service 560, e.g., periodically and / or when the state and / or condition of the device changes (e.g., a fault is detected, device 552 undergoes diagnostics, reboot, etc.). Additionally or alternatively, a third-party device may provide an update to the network node manager / DNS service 560 regarding the state and / or condition of device 552 (also not shown in Figure 11 ), such as when a diagnostic tool takes device 552 offline for diagnostic purposes, when a security manager (e.g., security manager 440) detects a security anomaly related to device 552 that needs to be mitigated and affects the state of the device, etc. In any case, the network node manager / DNS service 560 updates the state and / or condition of device 552 in the discovered device database.

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

[0127] Accordingly, to establish communication with the field device 552 via the node communication network 402, the controller 580 discovers the field device 552 via the node communication network 402. Specifically, as Figure 11As shown, the controller 580 (e.g., via a DNS client executed in the controller 580) queries the DNS service or server 560 for the IP address of the field device 552 (as indicated by reference numeral 582), e.g., by utilizing the IP address of the DNS server 560 that has been supplied to the controller 580 workbench and providing the device label and / or data label of the field device 552 known to the controller 580 to the DNS server 560. Upon receiving the query 582, the DNS service 560 accesses the 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 inoperable, 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 utilizing the corresponding security credentials that have been stored in the discovered device database 435, by querying the security manager 440 for authentication, verification, validation, etc.

[0129] In any case, when the controller 580 receives 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 the 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 in other parts of the present 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, via which the controller 580 and the field device 552 transmit data and information, as indicated by reference numeral 588. For example, the controller 580 and the field device 552 can exchange security credentials (which may have been assigned by the security manager 440 and supplied by the workbench to each of the devices 580, 552), can verify the certificates using the security manager 440 and / or the network node manager 560, and / or can take other associated actions to secure the communication session. Generally, each of the controller 580 and the field device 552 notifies the system log server 572 of the establishment and removal 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 the controller and the host device 552 (e.g., device A) as the field device, and they are both included in the same process control loop, this is for illustrative purposes only. In fact, any type of client device connected to the node communication network 402 can use a similar method (e.g., message exchanges 582, 585) to discover one or more host devices that produce data to be consumed by the client device.

[0131] Now returning to Figure 9, as previously discussed, the network node manager 432 can discover devices that have been attached or connected to the node communication network 402, store the device identifier (e.g., a first-level device identifier such as a device label or a second-level device identifier such as a data label) and the IP address of the discovered device in the mapping database / discovered device data store 435, and maintain the updated status and / or condition of the discovered device in the mapping database / discovered device data store 435. For example, in an embodiment where the network node manager 432 and the DHCP server 430 are an integrated node, the network node manager 432 discovers newly connected devices by receiving the device's query of the DHCP server 430 for an IP address. When the network node manager 432 is a different node from the DHCP server 430, the DHCP server 430 can notify the network node manager 432 and / or the DNS server 438 of the newly connected device and its corresponding device identifier / IP address association. When the DHCP server 430 notifies only one of the network node manager 432 or the DNS server 438 of the newly connected device (and its corresponding device identifier / 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 identifiers. Thus, generally speaking, the mapping / discovered device database 435 can store device identifiers and corresponding IP addresses, as well as updated device condition and status 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 directly stored in the discovered device database 435 by the security manager 440 (e.g., via workbench provisioning). Additionally or alternatively, at least some of the security credentials can be provided to the network node manager 432 by the security manager 440 and / or by the device itself during device discovery for storage in the discovered device database 435. For example, referring to Figure 11 , the device 552 can provide its workbench-provisioned security credentials or information (e.g., keys, certificates, passwords, etc.) along with a request for its IP address 558 to the network node manager 560.

[0133] The network node manager 432 can utilize device credentials and / or security information stored in the discovered device database 435 to manage device security among individual devices and multiple devices. For example, the network node manager 432 can verify or authenticate the device credentials of a host device attempting to connect to the node communication network L15. The network node manager 432 can verify or authenticate the device credentials of a client device (such as in connection with a query by the client device for the IP address of the host device, e.g., as denoted by reference numeral 582). The network node manager 432 can verify or authenticate device credentials in conjunction with polling the status of a device (e.g., Figure 11 denoted by reference numeral 578), and so on. Additionally or alternatively, the network node manager 432 can rely on the security manager 440 to verify and / or authenticate device credentials and security information, such as by requesting that the security manager 440 perform verification, authentication, and other security tasks.

[0134] Of course, the client device and the host device can utilize their respective security credentials or information to establish a communication session via the node communication network 402, such as in Figure 11 the session establishment 588 shown. For example, in addition to providing their respective security credentials to the client device and the host device during bench supply, the security manager 440 can also manage the respective keys and verify certificates after supply, e.g., when the device connects to the network 402 and / or when the device remains connected to the network 402. If a device fails to successfully authenticate or is successfully verified, the device can be isolated and prevented 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 only needs to be bench-supplied with the security credentials that have already been supplied to the device it is replacing. Thus, when a physical replacement device is identified within the process control system by using the device label and security credentials of the previous device, by 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.

[0136] Figure 12 A block diagram of an example security architecture 600 is shown, which illustrates at least some of the security techniques and / or aspects for managing the security of nodes of a node communication network of an industrial process plant or an automation system, such as those security techniques and / or aspects described in other parts of this document. The security architecture 600 can be used for Figure 9 the devices and / or nodes of the system 400 or other suitable systems. For example, the security architecture 600 can be used to protect Figure 1 the highly versatile field device 10, and / or in connection with the above regarding Figure 8combine or cooperate with any one or more of the security features discussed. However, for purposes of illustration and not limitation, the architecture 600 will be described with reference to the security features of Figure 8 and the Figure 9 system 400.

[0137] As Figure 12 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 implementation, the security manager 605 is an embodiment of the security manager 440 of Figure 9 , 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 one of the devices or systems 10, D1-Dn, 418, 422, 425, 428. In the example shown in Figure 12 , the client device 610 is a consumer of data generated or produced by the host device 608 during the runtime operation of the devices 608, 610 in an industrial process plant or automation network. For example, the host device 608 can be the Figure 11 field device 552, and the client device 610 can be the Figure 11 controller 580.

[0138] The security manager 605 includes a provisioning engine 612 that generates or otherwise determines the corresponding security credentials for devices to be connected to the node communication network 402 in an industrial process plant or automation system during the bench provisioning of the devices, e.g., when such devices have not 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. The provisioning engine 612 records or stores the provisioned credentials for these devices in the credential data store 615. Generally, bench provisioning is performed when such devices are located at the site of the process plant or automation system; however, bench provisioning can be performed at any time before powering on such devices for connection to the node communication network 402, such as when such devices are located in a manufacturing plant, at a staging location, etc.

[0139] The provisioning engine 612 operates in conjunction with a workbench provisioning application 618, which may be provided via the user interface of the security manager 605 and / or may otherwise be exposed to or provided at the user interface of other devices (e.g., a handheld computing device or other type of tool) for managing provisioning. For example, the security manager 605 may download an instance of the workbench provisioning application 618 to various user-operated computing devices or tools, the security manager 605 may host the workbench provisioning as a service accessible to various user-operated computing devices or tools, and so on. Generally speaking, 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 into a device.

[0140] The security manager 605 also includes a credential management engine 620, which generally manages the security credentials of devices when the devices attempt to connect to the network 402, connect to each other, and during the runtime operation of an industrial process plant or automation system. For example, the credential management engine 620 may authenticate or verify various devices, provide keys to various requesting devices, verify certificates, etc. Thus, the credential management engine 620 has access to the credential data store 615. Generally, but not necessarily, the credential management engine 620 operates automatically, e.g., without 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 their 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, which, 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, which, 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, which, for example, obtains the device identifier (e.g., the device label of the host device 608, any associated data labels, etc.) of the host device 608 and the associated security credentials of the host device 608 from the provisioning engine 612 during the workbench 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 12(not shown). In an example implementation 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 identifier and / or security credentials may be stored in the secure program memory 308.

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

[0144] At a time different from the provisioning period, for example, during the process of connecting to the node communication network 402 and / or when connecting to the node communication network 402, the host device 608 may execute a key request routine 622b, via which the host device 608 requests keys (e.g., private keys, public keys, etc.) from the credential management engine 620 of the security manager 605. For example, the key request routine 622b may be included in the secure communication feature 312. Similarly, the client device 610 may execute a key request routine 625b, via which the client device 610 requests keys (e.g., private keys, public keys, etc.) from the credential management engine 620. In addition, in order to perform authentication, verification, confirmation, and / or other types of certificate evaluations during the process of connecting to the network 402 and when connecting to the network 402, each of the host device 608 and the client device 610 may execute respective credential evaluation routines 622c, 625c, which interface with the credential management engine 620 of the security manager 605 to implement credential evaluation, for example, by accessing the stored credentials 615. For example, when the host device 608 and the client device 610 execute the corresponding 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 of the device security routines or applications 612b, 612c, 620a, 620c may be executed. For example, the host device 608 may utilize any one or more of the security features and / or security protocols (e.g., 306, 310, 312, etc.) discussed with respect to Figure 8 to establish a secure communication session 632.

[0145] Note that inFigure 12 In this case, 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 reality, the functions of the host device applications / routines 622a, 622b, 622c, 628 can be implemented using fewer or more separate and distinct applications or routines. Similarly, the functions of the client device applications / routines 625a, 625b, 625c, 630 can be implemented using fewer or more separate and distinct applications or routines, and the various functions provided by the security managers 612, 615, 620 can be implemented using fewer or more separate and distinct engines, applications, or routines.

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

[0147] As Figure 13As shown, each network node manager 652-658 is communicatively connected via the backbone of the node communication network 660 to other types of management nodes of the system 650, 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, where the different sets of host devices 672, 675, 678 are mutually exclusive sets. In this way, each network node manager 652-658 manages, for example via its corresponding mapping database, the device label, IP address or endpoint identifier, status, and optionally security information of each host device included in its corresponding set of host devices 672, 675, 678. In this way, a query for the endpoint identifier of a device not managed by the first network node manager received at the first network node manager can be routed via the node communication network 600 to another network node manager that manages the device. In some embodiments, one or more of the network node managers 652-658 may share (and update) at least a portion of its corresponding mapping database with at least one other node manager among the node managers 652-658, such that at least one other node manager among the node managers can serve queries for non-managed devices without having to talk to the managing network node manager.

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

[0149] Network Resource Management

[0150] Although the node communication network 80 in factory 100 is extremely flexible, partly because it uses an IP-based network, an IP-based network implemented in a process or factory automation control environment needs to consider 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 will behave differently and / or unpredictably in normal, overloaded, and fault scenarios. As an example, in high-load and competitive scenarios, an IP-based network can drop or delay packets. When packets are delayed or dropped, the performance of monitoring and control applications will be adversely affected by the resulting latency and jitter. Therefore, when performing network design in a process or factory automation control network, it is important to know 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] Equally important, an IP-based network can be configured to support various topologies. For example, the node communication network 80 should support traditional factory automation or process automation topologies, such as Figure 3 those shown in, which include highly versatile field devices 82 and traditional field devices 224 coupled to the APL network architecture 892 via adapter devices 130. The communication network 80 should support edge topologies, such as Figure 4 those shown in, which operate on top of or in parallel with traditional factory or process automation topologies and support integration of schedule information 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 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 topologies, such as Figure 5 those shown in, which can operate in parallel with automation instrumentation and can be used, for example, for condition-based monitoring (e.g., energy monitoring, device and equipment monitoring, and process monitoring). In such a system, as described above, the monitoring system can transfer data from factory 100 to one or more cloud-based applications 182, which perform analysis and transfer data and / or recommendations back to users and / or elements in the process control network 200, such as controller 140.

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

[0153] Whether implemented in a traditional networking environment or in a flattened networking environment, since some data flowing from highly general-purpose field device 82 and traditional field device 224 to various applications and devices in process control network 200 is more time-sensitive than other data, 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 in controller 140 may require certain data more frequently than other control modules and / or may require certain data more frequently than condition monitoring applications that do not perform real-time control of processes. Therefore, it is important that communication network 80 prioritize time-critical and time-sensitive data over data that is less sensitive to latency while supporting the transmission of various data types to and from various devices and applications.

[0154] As referenced above Figures 3 - 7 described, communication network 80 is implemented as an IP-based network that uses an APL network architecture 892 including an APL power switch 84 and an APL field switch 86 that are coupled to each other via an APL bus 88 (e.g., Ethernet) and (e.g., via firewall device 162) to various highly general-purpose field devices 82, adapter devices 130, controllers 140, workstations 206, 145, 202, 204, edge gateway 166, and / or cloud 168. APL power switch 84 and APL field switch 86 facilitate the communication of data to and from field devices 82 and 224 and to and from various applications. In some embodiments, APL power switch 84 and field switch 86 may cooperate with various other switches (e.g., Figure 3 the L2 switch shown in) to facilitate the communication of data from source to destination.

[0155] Similarly as described above, the communication network 80 supports both client / server and publish / subscribe communications and, in addition to facilitating communication between field instruments and applications, enables an Internet connection between an Open Platform Communications (OPC) Unified Architecture (UA) server (e.g., a field instrument) and an OPC UA client (e.g., a controller). Each of the field instruments and applications can be a client or a server in various instances. The communication network 80 supports both User Datagram Protocol (UDP) and Transmission Control (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 explicit, and all client / server requests specify the request and response data to be transmitted. At the same time, in publish / subscribe communication, new values (e.g., measurement values, condition values, etc.) are transmitted from a server (e.g., a device) only when needed. For example, with respect to a parameter published from a highly versatile field device 82 to a controller 140, the parameter can be transmitted as often as needed to allow control actions to correct for unmeasured disturbances or in response to setpoint changes.

[0156] The communication network 80 is configured to cooperate with the highly versatile field device 82 to support various use cases. Of course, the primary use case is control, allowing the highly versatile field device 82 and the traditional field device 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 the control of the process plant 100. While in a traditional process plant communication network, a field device only communicates with a corresponding controller and the operator station receives the necessary parameter data from the controller and sends new setpoint data to the field device through the controller, the communication network 80 can be configured to facilitate direct communication between the operator station 206 and the highly versatile field device 82 and the traditional field device 224. Specifically, the communication network 80 can be configured to allow a specific field device to publish parameter data to multiple consumers of that data simultaneously. Thus, a valve can, for example, publish parameter data to both the controller 140 and the operator station 206, which can save bandwidth by eliminating duplicate transmission of data. That is, a single transmission can deliver the 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 in a traditional control network.

[0157] The communication network 80 can also improve plant asset management (PAM), including the configuration of devices. A PAM system is used to configure and commission devices, run diagnostics on the devices once deployed, monitor device alarms, and other functions. For example, a PAM system can receive condition monitoring data from the field devices 82 and / or 224 to determine when a device has failed, needs calibration, etc.

[0158] Industrial IoT (Internet of Things) platforms can also benefit from the implementation of the communication network 80 as described herein. An industrial IoT platform for continuous status monitoring can be deployed to monitor various parameters within a process plant 100. Such a system can monitor functions such as energy consumption, device and equipment 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 inputs. In traditional 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 systems described herein, these industrial IoT platforms can receive data directly from the devices that are the data sources, without the need to program intermediate devices to relay the data via direct requests or using publish / subscribe (i.e., by subscribing to the data).

[0159] Other processes can be similarly facilitated by the communication network 80 described herein. For example, data logging can be achieved by streamlining the collection of energy and monitoring data, metering can be achieved by streamlining the collection of data from a smart meter reading system and transmitting the data to a processing application via, for example, an edge gateway 166 and / or the cloud 168, and environmental monitoring can be achieved 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 as well as other non-traditional data such as those described above in usage on the same network can result in problems such as latency and dropped packets, which do not exist in the case of traditional control networks that only transfer data between individual devices and controllers and on which such data transfer is scheduled, specifically requested by the controller, or otherwise tightly controlled to ensure timely receipt of high-priority, latency-sensitive data at the controller (or from the controller at the device). One challenge is to accommodate scheduled network traffic (e.g., monitoring and control data transferred between field devices and controllers) and unscheduled traffic (e.g., condition monitoring and other data transferred between devices and applications) on the same network.

[0161] To address and / or prevent such problems, the communication network 80 includes a network resource management component 800. Refer to Figure 14, Generally, the network resource management component 800 interacts with various physical network devices (e.g., with the APL power switch 84 and the APL field switch 86) via a physical network (e.g., the APL bus 88) to manage network resources (e.g., bandwidth and scheduling), thereby facilitating the communication of managed network services (network services known to the network resource management component 800, such as scheduled network services) and unmanaged network services (network services not known to the network resource management component 800, such as unscheduled request - response network services). In various embodiments, the network resource management component 800 can be centralized in a specific device, such as the APL power switch 84, or can be distributed among various APL power switches 84 and APL field switches 86, the controller 140, etc. throughout the communication network 80. That is, the network resource management component 800 can be a logical component embodied in a specific physical component or distributed among 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 a switch, or implemented 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 services, the network resource management component 800 facilitates communication in various modes between various devices and applications while ensuring that scheduled and / or high - priority network services reach their destinations without undue or unacceptable delays. This includes at least: network services between a highly general - purpose field device 82 and another highly general - purpose field device 82; network services between a highly general - purpose field device 82 and the controller 140; network services between a highly general - purpose field device 82 and multiple other highly general - purpose field devices 82; network services between a highly general - purpose field device 82 and an application running on a workstation (on the process control network 80, via the edge gateway 166, the cloud - based application 182); network services between a highly general - purpose field device 82 and multiple applications running on a workstation.

[0163] The network resource management component 800 can be implemented to use Time - Sensitive Networking (TSN) or not use TSN. Each implementation will be described below.

[0164] TSN - based Network Management

[0165] Based on the network management requirements of TSN, network resources based on TSN (e.g., devices and applications) are managed while allowing non-TSN resources to access the same network. That is, the network management based on TSN facilitates the communication of managed and unmanaged network services. As part of this networking solution, TSN network devices and applications need to know 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 a source to a destination.

[0166] The TSN-based network resource management component 800 differentiates the priority of data transmission according to rules and service types. For example, in some embodiments, priorities are assigned based on the default service 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 factory (e.g., Factory 100), priorities do not need to be assigned based on the same types of services that may exist in an average network. Instead, by way of example and not limitation, priorities can be assigned based on the specific types of network services that may exist in a factory automation or process control environment. Table 2 is an example list of service types and priorities, although it can be appreciated that the service types associated with each priority can be assigned according to the needs of the system operator.

[0171] Table 2

[0172] Priority Service Type 0 (Lowest) Background 1 Best Effort 2 Extraordinary Effort 3 Equipment Condition and Health Monitoring 4 Low - Priority Control (Higher Latency Tolerance) 5 High - Priority Control (Lower Latency Tolerance) 6 Inter - network Control 7 (Highest) Network Control

[0173] Referring to Table 2, some of the data used by a factory automation controller or a process controller 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 may very quickly have an excessive impact, or because the data is part of a safety system that must respond quickly to events to, for example, prevent or mitigate a dangerous situation. Other data used by the controller may be less sensitive to increased latency, such as because it is part of a less frequently executed control loop, or is a process that does not exhibit sudden changes in response to minor disturbances.

[0174] In any case, various types of data within the factory 100 can be assigned different priorities within the TSN-based networking solution implemented by the network resource management component 800. The differentiation of data priorities according to the network solution is performed at the egress port 818 of the TSN-based device, such as the highly versatile field device 82, the adapter device 130, the APL power switch 84, the APL field switch 86, etc. Of course, each TSN-based device that sends data can have a corresponding egress port 818.

[0175] Figure 15 An example egress port 818 is shown. Data enters the egress port 818 via the input 819 and is placed into one of the multiple queues 822A - 822N by the queue selection unit 820. The queue selection unit 820 can determine which of the queues 822A - 822N to place a particular piece of data into based on the priority of the data and / or the type of the data. In an embodiment, each of the queues 822A - 822N can correspond to a particular priority, and each priority can be associated with one of the queues 822A - 822N. In other embodiments, each of the queues 822A - 822N can correspond to a particular priority, but multiple of the queues 822A - 822N can be associated with one of the associated priorities. That is, each priority can be assigned a single queue among the queues 822A - 822N, or can be assigned multiple of the queues 822A - 822N. In an embodiment, each of the queues 822A - 822N can have data associated with more than one priority (e.g., if there are fewer queues than priorities or traffic types). In an embodiment, each of the queues 822A - 822N can have data associated with a particular data source, data type, data destination, or data stream 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 take out from the corresponding queue 822A - 822N. A plurality of gates 826A - 826N, each associated with a corresponding one of queues 822A to 822N, determine whether the data selected by the corresponding transmission selection algorithm 824A - 824N can be transmitted. An open one of gates 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 preventing data transmission when each of gates 826A - 826N is closed. A gate control list 828 determines which one of the plurality of gates 826A - 826N is open at any given time. The transmission selection unit 830 selects which data to transmit from data output 832 by selecting the highest - priority available frame for transmission, provided and / or available from the open gates 826A - 826N. As a result, in this arrangement, even though the transmission selection algorithms 824A - 824N determine in what order data will be transmitted from the corresponding queues 824A - 824N, the gates 826A - 826N can block the transmission to effectively give priority to data other than the data with the highest assigned priority. Thus, the gates 826A - 826N are important in properly handling traffic to achieve proper transmission of time - sensitive scheduled traffic. As described, each of gates 826A - 826N can be open or closed. A plurality of the gates 826A - 826N can be open (or closed) at any given moment.

[0177] Of course, controlling the gates 826A - 826N to ensure highly predictable transmission of data in a real - time system, while taking into account latency 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 can 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 can 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 through the network and can predictably schedule recurring traffic.

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

[0180] The network resource management component 800 may have routines or data for obtaining and / or storing network scheduling information 806, and the information can be received from or programmed by the controller 140 and / or each workstation, and regarding the timing requirements of various data to be transmitted through the communication network 80. In an embodiment, some of the network scheduling information 806 is directly obtained from a configuration file that programs the controller 140 (e.g., from the control loop timing requirements specified in the configuration file). In an embodiment, as described herein, some of the network scheduling information 806 is determined according to the publish-subscribe requests established between specific devices. That is, when each publishing device (e.g., the highly general field device 82) establishes a subscription with another device or application, it can 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 can store various data associated with the allocation of network resources, and can include information such as the association between data types and the assigned priorities, as well as specific time slots reserved for specific data priorities, specific scheduled data transmissions, etc., and includes bandwidth allocation for unscheduled traffic (e.g., request-response traffic).

[0182] The time-aware shaper 810 can use the network resource allocation information 808, the routing information 802, and the network scheduling information 806 to set and synchronize the gate control list 828 to meet the real-time requirements of the communication network 80 and various devices and applications thereon. Since in the factory 100, control data is often transmitted on a repeating schedule, it is possible to know when a specific transmission occurs. However, it should be understood that the prioritization of data itself does not guarantee that the data can be transmitted at the correct time, because when the scheduled data is ready for transmission, other lower-priority data may have already been transmitted through the communication network 80. If a larger lower-priority transmission is already in progress, it must be completed before any other data can be transmitted, thus delaying the scheduled data.

[0183] This is the reason why the gate control list 828 is involved. Each gate control list 828 establishes or implements a repeating pattern of opening and closing the 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 correct time for 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 the respective outbound ports 818. Considering the network topology, the routing information of each scheduled transmission, the latency generated when the data passes through various switches, the network scheduling information, and the network resource allocation information, the time-aware shaper 810 can manage the gate control lists 828A - 828N to precisely time the opening and closing of the gates 826A - 826N in each outbound port 818, so that the appropriate gates among the gates 826A - 826N are opened and closed at the exact correct time and intervals.

[0184] Figure 16 FIG. is a diagram showing an example data flow 834 of this concept. In the example data flow 834, two different endpoint systems 840 and 842 send respective data frames 836 and 838 to a third endpoint system 844 through a network switch 846. Each of the endpoint systems 840, 842, 844 can be a device or an application in the factory 100. By way of example and not limitation, the endpoint systems 840 and 842 can each be highly versatile field devices 82 that send parameter data to the endpoint system 844, which can be a controller 140. In another example, the endpoint systems 840 and 842 can be highly versatile field devices 82 that send health status data to the endpoint system 844, and the endpoint system 844 can be a factory asset management device 145 on which an Asset Management System (AMS) is executed. Generally, 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 their data frames 836 and 838 are scheduled traffic or unscheduled traffic, and are transmitted according to a publish-subscribe protocol, a request-response protocol, or based on some other standard.

[0185] In example data stream 834, two data frames 836 and 838 are simultaneously transmitted from their respective endpoint systems 840 and 842 to endpoint system 844. Between the corresponding endpoint systems 840 and 842 and endpoint system 844, each data frame passes through network switch 846. Each of endpoint systems 840, 842, 844, and network switch 846 in example data stream 834 is shown as having an outbound port 818 with its corresponding elements. Of course, it should be understood that the devices and systems described herein, including highly general-purpose field devices 82, APL power switches 84, APL field switches 86, and other devices, may each have multiple outbound ports 818. Returning to Figure 16 , when both data frames 836 and 838 arrive at network switch 846, both data frames 836 and 838 are placed into respective queues 894A and 894B of network switch 846 that are considered to have arrived simultaneously. When transmitting data frames 836 and 838 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 of each or the data type of each. Queue selection unit 820 places the 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 of data frames 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 for transmission from data frame 838.

[0187] Modify the example slightly. 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 can still facilitate data frame 836 arriving earlier than data frame 838. For example, if data frame 836 is scheduled network traffic and data frame 838 is unscheduled network traffic. For example, although data frame 836 has a lower priority, it may contain data from the highly versatile field device 104 that the controller 140 expects at a specific time. In this case, the network resource management component 800 can configure the communication network 80 such 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 list 828 of various outbound ports 818 via the time-aware shaper 810 such that a clear data transmission path is created for data frame 836, while one or more transmission gates 826 (e.g., the transmission gate 826 corresponding to queue 894B in the network switch 846) along the data path of data frame 838 remain closed to block the transmission of data frame 838 until the transmission of data frame 836 is complete.

[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 that device is connected to the network 80. Alternatively, or in addition, the NCC 816 can cooperate with the device registration component 804 to determine the connections of each new device registered via the device registration component 804, thereby determining the topology of the network 80.

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

[0190] The User Configuration Component (UCC) 812 can be responsible for managing various endpoint stations (e.g., highly versatile field devices 82, adapter devices 130, workstations, and applications, etc.). The UCC 812 requests the scheduling flow of network services by sending requests to the NCC 816. These requests provide specific requirements for those scheduled network service flows by specifying the endpoint devices (sender and receiver) of each flow and specific timing requirements (e.g., the frequency at which the flow occurs, the size of the data payload, and the time sensitivity of the data payload, sequence order, etc.).

[0191] The NCC 816 can communicate with the UCC 812 to receive the communication requirements of various service flows that will appear on the network 80, determine the route of each service flow, and schedule the transmission of each service flow. The scheduling of the transmission of each service 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 embodiments where the network resource management component 800 is not based on the Time-Sensitive Networking (TSN) protocol, network services can be managed by controlling the service flows through network switches (e.g., APL power switch 84 and 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 service flows among various devices in the network 80, particularly in the network switches. Devices and hosts communicate with the network manager 814 to allocate services, for example, by requesting publish-subscribe service flows. The network manager 814 then controls the service flows through the switches by enabling and disabling various ports of the switches and by suppressing the network services passing through the ports. In such embodiments, network services can be identified, for example, by the service 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 can be stored as routing information 802 and device registration information 804, for example, to allocate network resource usage. The network resource allocation can be stored in network resource allocation information 808, for example. The network manager 814 can cooperate with the device registration 804 such that when a device joins the network 80, the network manager 814 is part of the joining process and such that the network manager 814 uses its flexible runtime model 815 of the network 80 and algorithms to optimize the traffic flow through the network. Once network resources have been allocated (and information about the allocation is stored in network resource allocation information 808, for example), the network manager 814 can use this information to manage the switches.

[0195] At some time after each device has joined the network 80, various devices request to negotiate bandwidth with the network manager 814. For example, a device can negotiate the publish-subscribe bandwidth between specific devices (e.g., between one of the highly general field devices 82 and the controller 140, or between one of the highly general field devices 82 and the controller 140 and the operator station 206) with the network manager 814. If the network manager 814 approves the request, the device can start publishing data to the hosts subscribing to the data.

[0196] The network manager 814 can allocate a specific portion or percentage of the bandwidth on the network 80 for unmanaged traffic, such as network traffic from unscheduled communications (e.g., ad hoc request-response communications), which is considered "best effort" traffic. The network manager 814 can monitor the traffic flow through the network 80 and can adjust the 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 managing unmanaged network traffic on the network 80 and supports publish-subscribe in both directions on the network (i.e., from field devices to the controller / application and from the controller / application to the field devices). As described above, security and plug-and-play operations can be supported similarly. Peer-to-peer network traffic can also be supported. The network resource management component 800 also facilitates devices that are both data publishers and data subscribers in the same device.

[0198] Release Kit

[0199] Partly because the node communication network 80 supports publish-subscribe and request-response services between any devices on the communication network 80, and partly because each of the highly general-purpose field devices 82 and adapter devices 130 can publish data to and subscribe data from multiple devices, the highly general-purpose field devices 82 and the node communication network 80 support a wide range of usage scenarios, including monitoring and control, plant asset management, condition monitoring, data logging, secure plant metering, environmental monitoring, etc. as described above. Also as described above, any particular highly general-purpose field device 82 or adapter device 130 can be connected to more than one type of application. For example, one of the highly general-purpose field devices 82 can support secure connections for monitoring and control as well as condition monitoring, and the connections can be completely separate and support different workloads, where the separate applications each subscribe to different data sets available from the highly general-purpose field device 82, and thus the list of published parameters sent from the highly general-purpose field device 82 to each corresponding application will be different. Due to these new capabilities in the devices and applications, it becomes desirable to simplify the publish-subscribe initiation protocol.

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

[0201] To this end, devices (and possibly applications) operating on the communication network 80 can have a predefined list of parameters and other data available for subscription. Figure 17 An exemplary server 848 (e.g., a highly general-purpose field device 82, an application, a controller 140, etc.) and an exemplary application 874 (e.g., another highly general-purpose field device 82, a controller 140, or another application) are shown. Although Figure 17 the server is illustrated as a highly general-purpose field device and thus shows various elements that may not be present in a controller (e.g., a sensor) or an application (e.g., a sensor, a communication circuit, etc.), Figure 17 the general concept illustrated involves a collection of publish lists 858 stored in the server 848. Specifically, turning to Figure 17, the server 848 (e.g., the highly versatile field device 82) includes one or more sensors 851 (e.g., temperature sensors, position sensors, pressure sensors, flow sensors, etc.). The sensors 851 send data to the processor 852, which can monitor data from the sensors, store data from the sensors, execute process control modules to implement a part of the control strategy, and / or transmit data to one or more other devices (e.g., controllers) 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 publish lists 858 in the memory 850, at least some of which are predefined and determined by the device or application manufacturer.

[0202] Thus, the memory 850 of the server 848 includes one or more manufacturer-defined publish lists 860. Each manufacturer-defined publish list 860 may include parameters that are typically transmitted from the server 848 for a specific application. For example, the first of the manufacturer-defined publish lists 860 may include device parameters related to process control. If the server 848 is a valve, the manufacturer-defined publish list 860 may be a monitoring and control publish list 868 and may include valve set points, valve temperature, and upstream and downstream flow rates and / or pressures. If the server 848 is a level transmitter, the monitoring and control publish list 868 may include the level. Meanwhile, the second of the manufacturer-defined publish lists 860 may be a condition monitoring publish list 870 that includes device parameters related to monitoring the condition of the device itself. For example, if the server 848 is a valve, the manufacturer-defined condition monitoring publish list 870 may include parameters such as valve stroke, valve drive, valve pressure, cycle count, etc.

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

[0204] The server 848 can also store one or more user-defined publication lists 862 in the memory 850. The user-defined publication lists 862 can be defined, for example, by a particular plant operator operating, for example, a single plant 100 or multiple plants 100, and can be defined for use at a single plant 100 or across multiple plants 100. Similar to the manufacturer-defined publication lists 860, the user-defined publication lists 862 can 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.

[0205] Further, the server 848 can store one or more customized publication lists 864 in the memory 850. The customized publication lists 864 can be defined, for example, for a particular device or application in the plant 100 or a particular group of devices or applications. For example, in most cases, the controller 140 can subscribe to the manufacturer-defined publication list 860 or the user-defined publication list 862 for a particular type of device (e.g., a particular valve type) in 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 particular valve type) in the process control network 200. Thus, a customized publication list 864 can be defined for this group of devices. Similar to the manufacturer-defined publication lists 860 and the user-defined publication lists 862, the customized publication lists 864 can 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 that requests to subscribe to data from the server 848, as described in more detail below.

[0207] As described throughout, the client 874 can be a highly versatile field device 82, an adapter device 130, or an application subscribing to a data source published on the communication network 80. For example, the client 874 can be an application 874A on a controller 862, another highly versatile field device 82 or adapter device 130, an application 874B on an operator station 206, 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 so on.

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

[0209]

[0210]

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

[0212]

[0213]

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

[0215]

[0216]

[0217]

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

[0219] Although shown in Figure 18 as occurring over two messages 882 and 884, in alternative embodiments, the initial exchange of messages can occur over more than two messages. For example, although it may be less efficient, the client 878 can send a "greeting" message to the server 880, in response to which the server 880 can confirm its presence with its own "greeting" message. The client 878 can respond to the confirmation sent by the server 880 by sending a request for a publish list in a specific publish list category. In response to this request, the server 880 can send an indication of the publish list 858 available in the specified publish list category. Of course, other communication arrangements are similarly possible and conceivable.

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

[0221] When implemented in software, any of the applications, modules, etc. described herein can be stored in any entity's non-transitory computer-readable memory, such as on a disk, a laser disk, a solid-state memory device, a molecular memory storage device, or other storage media, 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 that execute 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 one or all of these hardware, software, and firmware components can be implemented specifically in hardware, specifically in software, or in any combination of hardware and software. Thus, although the example systems described herein are described as being implemented in software that executes on the processors of one or more computer devices, those of ordinary skill in the art will readily understand that the examples provided are not the only way to implement such systems.

[0222] Accordingly, while the invention has been described with reference to specific examples, these examples are only illustrative and not restrictive of the invention, and it will be apparent to those of ordinary skill in the art that changes, additions, or deletions can be made to the disclosed embodiments without departing from the spirit and scope of the invention.

[0223] The specific features, structures, and / or characteristics of any particular embodiment can be combined with one and / or more other embodiments in any suitable manner and / or in any suitable combination, including using the selected features with or without the other features accordingly. Additionally, many modifications can be made to adapt a particular application, situation, and / or material to the essential scope or spirit of the invention. It should be understood that other variations and / or modifications of the embodiments of the invention described and / or illustrated herein are possible in accordance with the teachings herein and should be considered to be part of the spirit or scope of the invention. Certain aspects of the invention are described herein as exemplary aspects.

Claims

1. An industrial process control or factory automation system, comprising: a controller for controlling physical devices in an industrial process or a factory automation plant, the controller performing operations on one or more raw materials to transform the one or more raw materials into a product; a plurality of highly versatile (HV) field devices communicatively coupled to the controller, the plurality of HV field devices receiving commands from the controller and transmitting parameter values to the controller; a communication network, comprising: advanced physical layer (APL) cabling configured to provide loop-powered connections; one or more APL power switches, each configured to provide connections to other devices and each including a power source to provide power via the APL cabling; one or more APL field switches, each receiving power from one of the one or more APL power switches via the APL cabling and each configured to distribute both communication signals and power signals to HV field devices communicatively coupled to the respective APL field switch via the APL cabling while meeting intrinsic safety requirements; and a network resource management component configured to manage network resources on the communication network to facilitate communication of network traffic on the communication 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.

2. The industrial process control or factory automation system according to claim 1, wherein, the network traffic includes communication with at least one HV field device communicating with multiple applications.

3. The industrial process control or factory automation system according to claim 1, wherein, the network traffic includes communication between at least one HV field device communicating with at least one other HV field device.

4. The industrial process control or factory automation system according to claim 1, wherein, the network traffic includes traffic from at least one HV field device that publishes data to a publishing HV field device or an application.

5. The industrial process control or factory automation system according to claim 1, wherein, the network traffic includes traffic from at least one HV field device that subscribes to data from a subscribing HV field device or an application.

6. The industrial process control or factory automation system according to claim 1, wherein, the controller is a process controller in a process plant, and wherein the HV field device is a process control field device.

7. The industrial process control or factory automation system according to claim 1, wherein, the controller is a factory automation controller in a factory, and wherein the HV field device is a robotic factory automation device.

8. The industrial process control or factory automation system according to claim 1, wherein, the communication network provides communication between the controller and the HV field devices.

9. The industrial process control or factory automation system according to claim 1, wherein, The communication network provides communication between the HV field device and one or more applications via an edge gateway.

10. The industrial process control or factory automation system according to claim 1, wherein, the communication network provides communication between the HV field device and one or more cloud-based applications.

11. The industrial process control or factory automation system according to claim 1, wherein, the network resource management component includes a deterministic network manager.

12. The industrial process control or factory automation system according to claim 11, wherein, the deterministic network manager implements a time-sensitive networking (TSN) network management scheme.

13. The industrial process control or factory automation system according to claim 12, wherein, both TSN-based devices and non-TSN devices exist on the communication network.

14. The industrial process control or factory automation system according to claim 11, wherein, the network resource management component includes an outbound port, and the outbound port includes: a plurality of queues, each queue in the plurality of queues accommodating a corresponding category of network traffic; a queue selection unit configured to receive input data and determine in which queue of the plurality of queues the input data is to be placed; a transmission selection algorithm configured to select which data to take out from each queue of the plurality of queues; a plurality of gates, each gate associated with a corresponding one of the plurality of queues; and a gate control list configured to determine which one of the plurality of gates is to be opened, wherein if a gate is closed, data transmission is blocked even if the transmission selection algorithm has selected data for transmission, such that priority can be given to data other than data with the highest assigned priority.

15. The industrial process control or factory automation system according to claim 14, further comprising a time-aware shaper configured to synchronize the gate control lists of each of the plurality of outbound ports, such that a clear communication channel is created for ultra-low latency data transmission.

16. The industrial process control or factory automation system according to claim 12, further comprising a centralized network configuration representing applications utilizing the communication network to configure network resources.

17. The industrial process control or factory automation system according to claim 16, further comprising a centralized user configuration that discovers and configures application resources and communicates with the centralized network configuration on behalf of the device on which the application resides to configure TSN features.

18. The industrial process control or factory automation system according to claim 1, wherein, the network resource management component includes an interface that controls network traffic through a switch port by enabling and disabling ports and suppressing the network passing through the ports.

19. The industrial process control or factory automation system according to claim 18, further comprising a flexible runtime model for allocating network resource usage.

20. The industrial process control or factory automation system according to claim 19, wherein, The network resource management component uses the flexible runtime model to optimize the allocation of network resources on the communication network when a new device joins the communication network, and controls the one or more APL field switches and the one or more APL power switches in the communication network according to the allocation of the network resources.

21. The industrial process control or factory automation system according to claim 18, wherein, the network resource management component allocates a percentage of network services for unmanaged network services, and wherein when the detected percentage of unmanaged network services exceeds the allocated percentage of unmanaged network services, the network resource management component adjusts the one or more APL field switches and the one or more APL power switches.

22. The industrial process control or factory automation system according to claim 1, wherein, the network resource management component supports publish / subscribe in both directions on the communication network.

23. The industrial process control or factory automation system according to claim 1, wherein, the communication network supports peer-to-peer network services.

24. A method of managing network resources in an industrial process control or factory automation system, the method comprises: implementing a controller in the industrial process control or factory automation system to control physical devices, the controller being configured to perform operations on one or more raw materials to transform the one or more raw materials into products, and further being configured to communicate with a plurality of highly versatile (HV) field devices via a communication network, the plurality of HV field devices being communicatively coupled to the controller to receive commands from the controller and transmit parameter values to the controller; using one or more APL power switches to configure the communication network to facilitate communication of network services over an advanced physical layer (APL) medium, each of the one or more APL power switches being configured to provide a connection to other devices and each including a power source to provide power via the APL medium, and further using one or more APL field switches, each of the one or more APL field switches receiving power from one of the one or more APL power switches via the APL medium and each being configured to distribute both communication signals and power signals to HV field devices communicatively coupled to the respective APL field switch via the APL medium while meeting intrinsic safety requirements; configuring a network resource management component to manage network resources on the communication network to facilitate communication of network services on the communication network, the network services including managed network services known to the network resource management component and unmanaged network services unknown to the network resource management component.

25. The method according to claim 24, wherein, configuring the communication network to facilitate communication of network services includes: configuring the communication network to facilitate communication with at least one HV field device that communicates with a plurality of applications.

26. The method according to claim 25, Wherein, the network service includes communication between at least one HV field device that communicates with at least one other HV field device.

27. The method according to claim 25, wherein, the network service includes services from at least one HV field device that publishes HV field device or application subscription data.

28. The method according to claim 25, wherein, the network service includes services from at least one HV field device that publishes data to a subscribing HV field device or application.

29. The method according to claim 24, wherein, the controller is a process controller in a process plant, and wherein the HV field device is a process control field device.

30. The method according to claim 24, wherein, the controller is a factory automation controller in a factory, and wherein the HV field device is a robotic factory automation device.

31. The method according to claim 24, wherein, the communication network provides communication between the HV field device and one or more applications through an edge gateway.

32. The method according to claim 24, wherein, the communication network provides communication between the HV field device and one or more cloud-based applications.

33. The method according to claim 24, wherein, configuring a network resource management component to manage network resources includes implementing a deterministic network manager.

34. The method according to claim 33, wherein, the deterministic network manager implements a time-sensitive networking (TSN) network management scheme.

35. The method according to claim 33, configuring the network resource management component to allocate network resources such that time-critical data is allowed to be transferred between a source and a destination with minimal blocking.

36. The method according to claim 33, further comprising: configuring a time-aware shaper to synchronize the gate control lists in each of a plurality of output ports such that an unobstructed communication channel is created for ultra-low latency data transmission.

Images