Highly versatile field devices and communication networks for use in control and automation systems

Abstract

To provide a factory automation system and method that mutually communicate with a plurality of different communication protocols.SOLUTION: A highly versatile process control or a factory automation field device 10 has an interface and a communication connection structure that enables the field device to operate as a data server that communicates with and supports multiple different applications or clients, either directly or indirectly, while simultaneously performing standard process and a factory automation control functions. Moreover, various different process control and factory automation network architectures and, in particular, communication architectures, support the versatile field device to enable the versatile field device to simultaneously communicate with multiple different client devices or applications via a common communication network infrastructure, using the same or different communication protocols.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] This application relates generally to process control and factory automation systems, and more particularly to augmented field devices used in these systems that can simultaneously perform a variety of different functions in different contexts and communicate with different or separate client devices or applications using one or more different communication protocols. [Background technology]

[0002] A distributed process control system, such as those used to manufacture, refine, convert, generate, or produce physical materials or products in chemical, petroleum, industrial, or other process plants, typically includes one or more process controllers communicatively coupled to one or more field devices via a physical layer that may be an analog, digital, or analog / digital bus combination, or may include one or more wireless communication links or networks. Field devices may be, for example, valves, valve positioners, switches, and transmitters (e.g., temperature, pressure, level, and flow sensors) located within the process environment and generally perform physical process control functions, such as opening and closing valves, measuring process and / or environmental parameters, such as flow rate, temperature, or pressure, to control one or more processes running within the process plant or system. Smart field devices, such as field devices conforming to the well-known FOUNDATION® Fieldbus protocol, may also perform control calculations, alarm functions, and other control functions typically implemented within a controller. Process controllers are also typically located within a plant environment and execute control applications that operate different control modules, receive signals indicative of process measurements made by the field devices and / or other information related to the field devices, make process control decisions, e.g., generate process control signals based on the received information, and coordinate among control modules or blocks embodied within the field devices, HART® field devices, WirelessHART® field devices, and FOUNDATION® Fieldbus field devices, etc.To implement this communication, a control module within the process controller sends control signals to various different input / output (I / O) devices, which then transmit these control signals over specialized communication lines or links (communication physical layers) to the actual field devices, thereby controlling the operation of at least a portion of a process plant or system, e.g., controlling at least a portion of one or more industrial processes operating or executing within the plant or system. Additionally, I / O devices, typically located within a plant environment, are generally interposed between the process controller and one or more field devices and enable communication therebetween by converting electrical signals to digital values ​​and vice versa. Different I / O devices are provided to support field devices that use different specialized communication protocols. More specifically, a different I / O device is provided between the process controller and each of the field devices that use a particular communication protocol, such that a first I / O device is used to support HART field devices, a second I / O device is used to support Fieldbus field devices, a third I / O device is used to support Profibus field devices, and so on. As used herein, field devices, controllers, and I / O devices are generally referred to as "process control devices" and are generally located, disposed, or installed in the field environment of a process control system or plant.

[0003] Additionally, information from the field devices and process controllers is typically made available via a data highway or communication network 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 computing devices, typically located in a control room or other location of the plant away from the more hostile field environment, e.g., in the back-end environment of a process plant. Each of these hardware devices is typically centralized throughout the process plant or throughout portions of the process plant. These hardware devices run applications that may enable operators to perform functions related to controlling the process and / or operating the process plant, such as, for example, changing settings in process control routines, modifying the operation of control modules in controllers or field devices, displaying the current state of the process, displaying alarms generated by field devices and controllers, simulating the operation of the process for purposes of training personnel or testing process control software, maintaining and updating configuration databases, etc. The data highways utilized by hardware devices and process controllers may include wired communication paths, wireless communication paths, or a combination of wired and wireless communication paths, and typically use packet-based communication protocols and non-time-sensitive communication protocols such as Ethernet or IP protocols.

[0004] As indicated above, a process control system can include multiple field devices that provide many different functional capabilities within a plant. These field devices are generally communicatively coupled to a process controller using one of a variety of different types of specialized physical interfaces or communication interface physical layers developed specifically for process control. For example, a typical process control communication physical interface uses a two-wire wired interface configured in either a point-to-point wiring arrangement (e.g., only one field device communicatively coupled to a particular wired interface) or a multi-drop wiring arrangement (e.g., multiple field devices communicatively coupled to a wired interface). However, some field devices may connect to a controller using a wireless communication physical layer that may include wireless gateways and transmitter / receiver devices. Furthermore, field devices are typically configured to communicate with the process controller using one of a number of highly specialized communication protocols. These communication protocols are typically digital signaling protocols, but may also be analog protocols (e.g., 4-20mA protocols) or a combination of digital and analog protocols (e.g., the HART protocol). Some of these protocols operate using relatively simple commands and / or communications (e.g., ON and OFF commands as used in the CAN protocol), while other protocols are more complex protocols that require more commands and / or more communication information, which may or may not include simple commands. For example, a more complex protocol may communicate analog values ​​using digital communications superimposed on the analog values, e.g., using the Highway Addressable Remote Transducer (HART®) communication protocol. Other field devices may use fully digital communications (e.g., the FOUNDATION® Fieldbus communication protocol) that offer many types of communications.Other process control communication protocols include the PROFIBUS communication protocol, but other process control communication protocols have also been developed and are in use. Each of these communication protocols requires or must be supported by a particular physical layer, which may include a two-wire, four-wire, etc. physical layer, particular switches, etc. Additionally, the physical layer may specify maximum or minimum wire length, wire thickness, wire type, termination type, other electrical characteristics, etc. Importantly, however, field devices are configured to communicate using a single protocol and have a unified interface that communicates using that communication protocol and the physical layer associated with that protocol.

[0005] As a result of the development of these various field device communication protocols, each of which typically uses different communication wiring (physical layers) and signaling formats, various different field devices (e.g., field devices using different protocols) are communicatively connected to a process controller via different input / output devices (I / O devices), with each different I / O device conforming to a different one of the process control protocols and supporting a particular type of physical layer. That is, a typical plant may have a controller connected to many different I / O devices, such as Fieldbus I / O devices (connected to one or more FOUNDATION Fieldbus field devices via a FOUNDATION Fieldbus-compliant two-wire or four-wire bus), HART I / O devices connected to each of one or more HART-compliant field devices via separate two-wire or four-wire single-drop connections, CAN I / O devices connected to one or more CAN-compliant field devices via CAN-compliant wiring connections, etc.

[0006] Furthermore, coupling the communication ports of field devices to terminal blocks of I / O devices, and ultimately to process controllers within a process plant, is generally a complex process. Field devices must be coupled to I / O cards that convert signals received from the field devices into signals processable by the process controllers and convert signals received from the controllers into signals processable by the field devices. As a result, each channel of each I / O card corresponding to a particular field device must be associated with an appropriate signal type (so that the signals are properly processed by the I / O card), and the I / O cards must ultimately be communicatively coupled to a controller or controllers that receive signals from and / or transmit signals to the field devices coupled to that I / O card.

[0007] As mentioned above, each field device is coupled to an I / O device using a specific communication medium or physical layer (e.g., a two-wire cable, a wireless link, or an optical fiber) via a terminal block on the I / O device, and further coupled using one of these or other specialized process control communication protocols developed in the process control industry (e.g., HART, CAN, WirelessHART, FOUNDATION Fieldbus, PROFIBUS, etc.). Furthermore, the I / O devices are typically individually connected to the process controller via a separate bus or wired connection. The use of these different I / O devices means that the physical and logical connections between different field devices must be precisely mapped so that the controller connected to the different I / O devices can track which field device is connected to which port on each I / O device in order to communicate signals over the correct “path” to that field device. This problem is particularly troublesome with the HART protocol, where each field device is connected to a different output port on a HART-compliant I / O device. Furthermore, communication with process control field devices must occur through defined communication paths that typically include the field device communicating with a dedicated I / O device (typically via a first communication protocol), the I / O device communicating with a process controller (via a second, different communication protocol), and the process controller communicating with a user device or application, such as a process control operator application or process control configuration application, located on a server or other user interface device via yet another, different communication protocol. In either case, all communication to and from the field device is routed or transmitted through a specialized communication path (link) through the I / O device and the process controller. As a result, all data to and from the field device must be transmitted through the process controller and one or more I / O devices.In this case, the process controller must initiate and coordinate all messages or communications to and from the field devices via designated links from the process controller to the I / O devices and from the I / O devices to the field devices. This configuration provides a high degree of security because all applications attempting to communicate with the field devices must be able (and allowed) to communicate with the process controller, which in this case acts as a proxy or server for information from the field devices. Additionally, external applications cannot communicate directly with the field devices.

[0008] While process control field devices typically use specialized communication hardware and protocols, it is common for them to communicate with certain other devices within a process plant using generic IP or other packet-based communication protocols. For example, it is common to use a packet-based or generic IP protocol over an Ethernet bus that communicatively connects one or more distributed process controllers to one or more user interfaces, databases (e.g., configuration databases and historian databases), servers, etc. in the back-end plant environment. Thus, Ethernet, which is both a physical layer and partially a data link layer, is an important communications platform for automation systems because it enables flexibility, scalability, and performance in ways not previously seen in automation. To help support the adoption of Ethernet in automation, the APL (Advanced Physical Layer) specification has been designed to support the connection of field devices in remote and hazardous locations. Behind APL is the IEEE P802.3cg project, which focuses on developing extensions to the existing IEEE 802.3 Ethernet standard (IEEE 802.3) for Ethernet over twisted-pair wiring (10BASE-T1L). This development is significant because there is a long list of automation protocols developed for various purposes that can operate on top of the Ethernet physical layer.

[0009] To support this new development in Ethernet-based communication in process control, the FieldComm Group standardized HART-IP as part of the HART7 release. While HART-IP was initially designed to enable hosts to communicate efficiently with gateways, it has now emerged as a way for devices to communicate directly with I / O servers and hosts / controllers. Today, HART-IP is already being used in monitoring, control, diagnostics, and condition monitoring applications. Because HART-IP already has a complete inventory of devices available for HART-IP, it is an excellent protocol to layer on top of APL. Another widely supported protocol at the device level is OPC Unified Architecture (OPC UA). While OPC UA does not natively understand device communication or types, considerable effort is being made to provide some level of support. While HART-IP and OPC UA are likely to see relatively rapid market adoption, they are not the only ones. Other protocols, such as Ethernet IP and PROFINET, are already available over Ethernet and will be able to operate on top of APL once they become 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, supporting Ethernet or other advanced physical layers, such as those associated with packet-based or general-purpose IP communication protocols, in a process plant that already contains an installed base that relies heavily on more traditional field devices, e.g., HART and FOUNDATION Fieldbus field devices, is challenging and cumbersome because it requires synthesizing or integrating these various communication protocols at some point in the process control network through one or more electronic marshalling cabinets or devices. It is currently unclear how such advanced protocols can be integrated into a typical process plant architecture and reliably operate in a robust manner.

[0011] In addition to control systems, other systems are being developed to support other activities within process plants and factory automation environments. Plant asset management (PAM) or maintenance systems are typically configured to enable maintenance personnel to perform maintenance activities on devices in a plant or factory setting, including not only field devices but also other types of devices. PAMs are used to configure and provision devices, perform diagnostics on deployed devices, monitor device alerts, and perform a large list of many other functions. Additionally, condition monitoring systems are becoming more common and are being deployed at many sites. Condition monitoring systems can perform a wide range of functions, including energy monitoring, equipment and device monitoring, and process monitoring. These condition monitoring systems generally stream data from the plant, perform condition monitoring, and provide recommendations to users, and in some cases to the control system itself. Similarly, data logging systems exist in plant and factory automation settings to collect and log data for later use. For example, energy and monitoring data may be collected in a centralized manner by the data logging system for use in analyzing and establishing an alarm management system, for example, when a water leak is detected or energy is lost due to a leak or break in a pipe. Similarly, smart metering systems are being implemented in many settings to perform continuous or uninterrupted metering. Metering can be a critical process in large, distributed systems such as oil and gas fields, pipelines, chemical storage facilities, and finished goods storage facilities. For example, in chemical storage systems, it is important to have an accurate reading of what materials are present. Smart metering refers to the procedure of installing intelligent meter reading systems, reading these meters either through a controller or independently through a remote monitoring system, and forwarding the readings to a processing location such as an edge gateway or a central data server.Additionally, environmental monitoring must be performed in many settings based on safety concerns, EPA mandates or regulations, etc. For example, many plants have environmental reporting requirements such as reporting NOx, SOx, and other items, and it is critical that the data from these systems be time-stamped, insensitive to daylight saving time adjustments, and secure.

[0012] In either case, these other systems are often 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 plant asset management systems, these systems may communicate with and use some or all of the process control field devices. However, in these examples, applications, servers, or other data collection devices must communicate with the field devices through the process controller using various specialized field device protocols and physical layers installed for the field devices to obtain data from, send messages to, and perform other activities with the field devices. Again, in these cases, the process controller (and typically one or more I / O devices) is involved and is responsible for communicating with the field devices to support these other systems, while the field devices themselves do not have the specific knowledge or capabilities to directly support these other systems. With this approach, the process controller is positioned in the middle of the field devices and is responsible for communicating with the field devices to support other applications or uses beyond process control, such as maintenance activities, continuous monitoring, metering, etc. This additional burden can reduce the efficiency of the process controller or can cause communication with certain field devices to be lost or slowed, as the process controller must prioritize which communications are essential or necessary in any particular situation. Furthermore, this situation makes the field device significantly less efficient at supporting multiple uses. Summary of the Invention

[0013] New high-versatility (HV) process control or factory automation field devices are configured with interfaces and communication connection structures that enable the field devices to communicate with and support, either directly or indirectly, multiple different applications or clients while also operating as data servers that perform standard process and factory automation control functions. Furthermore, a variety of different process control and factory automation network architectures, particularly communication architectures, support the HV field devices, enabling them to simultaneously communicate with multiple different client devices or applications (each associated with a different system) over 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 HV field device, which may use one or more switches to route IP communications from and to the field device to other client devices, such as process or factory automation controllers, condition monitoring systems, plant asset management systems, and data logging systems. In this case, the high-versatility field device may be connected to one or more client devices (e.g., process or factory automation controllers, PAM system devices, data logger systems, etc.) via an APL network (Level 1 network) and through a switch to a second level network using another IP-based packet communication protocol, such as an Ethernet network. These one or more systems (e.g., process controllers in a process control system, PAM servers in a PAM system, data logger databases, condition monitoring applications in a condition monitoring system, etc.) may communicate directly with the high-versatility field device via the second level network, the switch, and the first level network to gain access to the high-versatility field device or obtain data directly from the high-versatility field device.

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

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

[0016] The highly versatile (HV) field devices and network architectures described herein can support APL, or other Ethernet, or generic IP-based physical layers, and various communication protocols operating on top of these physical layers, in a manner that allows the highly versatile field devices to simultaneously act as servers to multiple different client devices. Furthermore, the highly versatile field devices described herein can nest protocols within other protocols for use when protocols, such as safety protocols, require additional handshaking, confirmation, and the like. Furthermore, the highly versatile field devices described herein include configurability that enables 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 mixed physical layers and multiple protocol support that can be used to implement improved control while providing direct support for non-control systems; because the highly versatile field devices described herein can support request / response, publish / subscribe, event-based communication, reporting communication, and streaming communication, they are highly useful in supporting a combination of control and Industrial Internet of Things (IIoT) applications (also generally referred to herein as monitoring systems) that are interested in measurement and actuator data, performance of these applications, diagnostics of these applications, and information that can be determined by the combination of these measurements, performance, and diagnostics.

[0017] Additionally, highly versatile field devices are highly secure because they include many security features that make them more secure in the more open communication environments they are intended to be used in. These security features include, for example, root of trust, secure boot, and endpoint identity features, secure storage, encryption capabilities, secure communications, secure device provisioning, and security auditing capabilities, all of which combine in the field device to provide a high level of security never before offered in a process control field device.

[0018] Thus, a high-versatility (HV) field device may be a node of a process control and / or automation network as described herein, generally referred to herein as a nodal communication network. The nodal communication network typically supports packet-based, IP-based, or other advanced protocols for communicating information between nodes of the network. New nodes, such as new HV field devices, may join the nodal communication network and be discovered by other nodes, with each node being identified within the nodal communication network by a unique endpoint identification. Thus, in one embodiment, a system for managing nodes of a nodal communication network of a process control or automation system includes a network node manager communicatively connected to the nodal 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 between respective tags or identifiers of a plurality of devices utilized in the process control or automation system and respective endpoint identifications of a plurality of devices utilized in the nodal communication network, the plurality of devices including one or more high-versatility (HV) field devices. Each of the one or more HV field devices has one or more respective physical components that perform one or more respective physical functions during runtime operation of the process control or automation system, for example, to control an industrial process. The network node manager further includes a state database that stores the state of each of the plurality of devices. The system's DNS provides responses to requests for endpoint identification information of particular devices of the plurality of devices over the node communication network, the responses being generated based on the network node manager's mapping database and state database.

[0019] Further, so that a high-versatility (HV) field device can join and be discovered on a nodal communication network, in an embodiment, the high-versatility field device includes one or more physical components that perform a physical function for controlling an industrial process within a process control or automation system, a communication interface to the nodal communication network, one or more processors, and one or more non-transitory memories provisioned with and stored with tags or identifiers corresponding to the HV field device. 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: detect that the HV field device is connected to the nodal communication network via the communication interface when the HV field device is powered on; and send, via the nodal communication network, to a DHCP server of the nodal communication network a request for endpoint identification information of the HV field device, the request including an indication of the tag or identifier corresponding to the HV field device. Execution of the computer-executable instructions by the one or more processors further causes the HV field device to obtain, via the nodal communication network, an endpoint identification assigned to the HV field device by the DCHP server, and establish, via the nodal communication network, a communication session with another device by using the endpoint identification assigned to the HV field device, where the other device is a consumer of data generated by the HV field device, the generated data corresponding to a physical function performed by the HV field device during runtime operation of the process control or automation system. Execution of the computer-executable instructions further causes the HV field device to transmit, via the established communication session, data corresponding to a physical function performed by one or more physical components of the HV field device to the other device during runtime operation of the process control or automation system, thereby controlling an industrial process.

[0020] In one embodiment, a method in a high-versatility (HV) field device of a process control or automation system includes, when the HV field device is powered on, detecting, by the HV field device via a communication interface of the HV field device, that the HV field device is connected to a nodal communication network having nodes identified within the nodal communication network by respective endpoint identification information. The method further includes transmitting, by the HV field device via the nodal communication network to a DHCP server of the nodal communication network, a request for endpoint identification information identifying the HV field device within the nodal communication network, the request including an indication of a tag or identifier of the HV field device, the tag or identifier identifying the HV field device within the process control automation or automation system; and obtaining, by the HV field device from the DHCP server via the nodal communication network, the endpoint identification information assigned to the HV field device. The method further includes establishing a communication session with another device by the HV field device over the node communication network using an endpoint identification assigned to the HV field device, the other device being 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 the process control or automation system for controlling an industrial process. The method further includes transmitting, by the HV field device over the communication session, data indicative of the physical function performed by the one or more physical components of the HV field device to the other device during runtime operation of the process control or automation system, thereby controlling the industrial process.

[0021] Furthermore, the use of high-versatility (HV) field devices in a nodal communication network benefits from sophisticated network resource management schemes that can be implemented in the nodal communication network in combination with the device discovery methods described above. In one embodiment, a controller controls physical devices in an industrial process or factory automation plant that perform operations on one or more raw materials to convert the one or more raw materials into products. The HV field devices are coupled to the controller to receive commands from the controller and send parameters to the controller. A communication network including an advanced physical layer (APL) infrastructure, such as APL wiring, APL power switches that provide connectivity and power via the APL wiring, and APL field switches that receive power from the APL power switches and distribute power and connectivity to the HV field devices, also includes a network resource management component configured to manage network resources on the communication network to facilitate communication over the network of network traffic, including both managed network traffic known to the network resource management component and unmanaged network traffic not known 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 a network resource management component that implements a deterministic management scheme implement a time-sensitive networking (TSN) network management scheme, where both TSN-based devices and non-TSN devices may operate on a communication network. The deterministic network resource management component, in embodiments, allocates network resources to enable transmission of time-critical data with minimal blocking between a source and a destination. In some embodiments, the network resource management component includes one or more outbound ports. Each of the outbound ports includes a plurality of queues, each corresponding to a corresponding class of network traffic. A queue selection unit of each outbound port is configured to receive incoming data and determine which queue the incoming data is placed in, while a transmission selection algorithm is configured to select which data to retrieve from each of the plurality of queues. Each of the queues has an associated gate, and a gate control list determines which of the plurality of gates is open. When a gate is closed, the data is blocked from transmission so that even if a transmission selection algorithm selects data for transmission, data other than the data with the highest assigned priority can be prioritized. The time-aware shaper, in embodiments, controls or synchronizes the gate control list for 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 switch ports by enabling and disabling ports and throttling network traffic through ports, particularly when network traffic is identified by source, destination, and application type. A flexible runtime model is used to allocate network resource usage, and in embodiments, optimizes the allocation of network resources on the network, in part by controlling one or more APL field switches and / or power switches when new devices join the communication network. In embodiments, some percentage of network resources is allocated to unmanaged network traffic, and the network resource management component adjusts the switches when the detected percentage of unmanaged traffic exceeds the allocated percentage.

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

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

[0026] In various embodiments, the public categories include a monitoring and control category and / or a condition monitoring category. In embodiments, the public lists may include a manufacturer-defined public list, a user-defined public list, and / or a custom public list. In embodiments, the method further includes receiving, at the HV field device, a message from a second client device or application indicating a selection of a second public category of the plurality of public categories, and transmitting from the HV field device to the second client device or application, identification information of each of the second plurality of public lists corresponding to the second public category of the plurality of public categories received from the second client device or application. The method further includes receiving, at the HV field device, from the second client device or application, a selection of one of the second plurality of public lists identified by the HV field device, and then transmitting from the HV field device to the second client device or application, a set of parameters associated with the selection of the one of the second plurality of public lists received from the second client device or application. In an embodiment, receiving a selection of one of the plurality of published lists from the first or second device or application further includes receiving an update rate that specifies how often a set of parameters associated with one of the published lists is transmitted from the HV field device to the respective client device or application.

[0027] In various embodiments, an HV field device, or a control or automation system including such an HV field device, may be configured to perform these methods. [Brief explanation of the drawings]

[0028] [Figure 1] 1 is a block diagram of a highly versatile field device as is described herein. [Figure 2]1 depicts an APL network in which highly versatile field devices as described herein may be used. [Figure 3] 1 depicts a first exemplary communication architecture that uses an APL network to support access to a highly versatile field device by multiple client applications / devices. [Figure 4] 10 depicts a second exemplary communication architecture that uses an APL network to support access to a highly versatile field device by multiple client applications / devices. [Figure 5] 10 depicts a third exemplary communication architecture that uses an APL network to support access to a highly versatile field device by multiple client applications / devices. [Figure 6] 10 depicts a fourth exemplary communication architecture that uses an APL network to support access to a highly versatile field device by multiple client applications / devices. [Figure 7] 10 depicts a fifth exemplary communications architecture that uses an APL network to support access to highly versatile field devices by multiple client applications / devices. [Figure 8] 2 depicts a block diagram of various security features and components implemented in the highly versatile field device of FIG. 1; [Figure 9] 10 depicts a block diagram of an exemplary system for managing nodes of a nodal communication network of an industrial process plant or factory automation system, which may include one or more of the highly versatile field devices of FIGS. [Figure 10] 10 depicts a first exemplary message flow that may occur upon initial connection of a highly versatile field device to the nodal communication network of FIG. 9. [Figure 11]10 depicts a second exemplary message flow that may occur upon initial connection of a highly versatile field device to the nodal communication network of FIG. 9. [Figure 12] 10 depicts a block diagram of an example security architecture of a node management system of a node communication network, such as the node communication network depicted in FIG. [Figure 13] 1 depicts a block diagram of a node management system for a node communication network including multiple network node managers. [Figure 14] 1 depicts a block diagram of a network management component that can be configured to manage network traffic in the disclosed communications architecture. [Figure 15] 15 depicts a block diagram of an example outbound port of a network device managed by the network management component of FIG. 14. [Figure 16] 15A-15C are diagrams of two exemplary data flows through a controlled network managed by the network management component of FIG. 14. [Figure 17] 1 depicts a block diagram illustrating various components of a publish-subscribe communication architecture. [Figure 18] 18 depicts an exemplary communication flow diagram employed by the publish-subscribe communication architecture of FIG. 17. DETAILED DESCRIPTION OF THE INVENTION

[0029] Referring now to FIG. 1 , a high-versatility (HV) field device 10 is illustrated generally in block diagram form. In particular, the high-versatility field device 10 includes field device hardware 12, which may be, for example, one or more sensors, actuators, valve seats and valve stems, or any other typical or desired control hardware associated with the operation of the field device. The control hardware 12 may 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 gas or liquid flow control structures, igniters, fans, motors, actuators, pumps, etc. The control hardware 12 may be, for example, a control structure that measures or senses one or more physical phenomena in a plant or factory setting, or that controls or effects one or more physical phenomena in a plant or factory setting, or may be any control hardware associated with any known control field device.

[0030] Additionally, the high-versatility (HV) field device 10 includes a computer processor 14, computer memory 16, a hardware communication interface 18, an external communication interface 20 (connecting to the physical layer of an external communication network, not shown), and a power supply 22. Generally speaking, the hardware communication interface 18 enables communication between the processor 12 (more specifically, one or more applications or routines stored in the memory 16 and executed by the processor 12) and the field device hardware 12 using any desired communication technique or protocol, including proprietary protocols or techniques, or any open process control protocol or technique, such as HART, FOUNDATION Fieldbus, CAN, Profibus, etc. The communication interface 18 may be an internal input / output device that multiplexes and / or conditions signals from the hardware device 12 and converts these signals for reading by or communication to the processor 14, or vice versa. The communication interface 18 may convert signals from the processor 14 sent to control or effect operation of the hardware 12 in any known or desired manner, and similarly, may convert signals from the hardware 12 to the processor 14 in any known or desired manner. Additionally, processor 14 may execute one or more hardware control applications 30 (which may be stored in memory 16) to communicate with, control, read signals from, and change settings on any or all of field device hardware 12. Hardware control applications 30 may be stored in ROM or RAM of memory 16 and / or may be implemented as an ASIC, as an executable application, or in any other desired manner.

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

[0032] Additionally, memory 16 may store one or more communication applications 32 that execute on processor 14 and control communications 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 implement communications using known or standard communication protocols over one or more different communication networks, such as wired networks, wireless networks, etc.

[0033] Importantly, processor 14 of device 10 is powerful enough to have and run an operating system (OS) 34 stored in memory 16 and typically running in real time on processor 14, and applications 30 and 32 run on processor 14 in a structured manner as separate applications that share processor resources. In particular, OS 34 may be a real-time operating system (RTOS), including a general-purpose operating system such as the Linux® operating system, or any of a variety of lightweight operating systems such as the ThreadX operating system. Various different application 32 and processor and communication loading techniques are discussed in more detail below. In any event, the processor 14 may execute any number of different communication applications 32 and / or may enable any communication application 32 to establish multiple different communication threads or proxies (also called communication processes) running simultaneously on the processor 14, which allows the versatile field device 10 to communicate simultaneously (i.e., in an overlapping manner) with different external applications (referred to generally herein as client applications or client devices), which may be within the same or different external devices, hosts, or servers connected to the field device 10 via the communication interface 20. Of course, the communication interface 20 may conform to any desired standard communication protocol or paradigm, such as IP or packet-based protocols such as TCP, UDP, HTTP, HTTPS, TLS, DTLS, etc.

[0034] As will be appreciated, during operation, the OS 34 executing on the processor 14 may set up and manage a communications stack 38, such as a TCP, UDP, or other IP- or package-based stack, to implement external packet-based digital communications via the communications interface 20. Additionally, the OS 34 may set up and manage multiple different communications threads (processes) that may operate simultaneously (and at the same or different speeds) via the communications interface 20 and the underlying communications stack 38. In particular, as illustrated in FIG. 1 , the OS 34 may set up various communications threads 40 that implement the same or different higher lever or more specialized communications protocols, such as the HART-IP protocol, an OPC protocol such as the OPC UA protocol, an email protocol, or any other type of communications protocol used for various purposes by various types of external applications. Thus, during operation, the OS 34 executing on the processor 14 may create, manage, and destroy (decommission) various different communications threads 40 (also referred to as communications processes or sockets), which operate simultaneously to provide communications with different external devices and applications. The various different threads 40 may use the same or different higher level communication protocols to more effectively communicate with different clients (i.e., external devices or applications). In the example illustrated in Figure 1, the OS 34 manages four threads 40, with a first of the threads 40 using HART-IP, which may be used to communicate with a process controller that is performing process control using field devices, a second and third of the threads 40 operating the OPC UA protocol to communicate with a device maintenance system and a data monitoring system, and a fourth of the threads 40 using an email protocol to communicate with an email server to send emails to one or more people.Of course, any number of threads 40 may be created and running simultaneously, and each thread may communicate using one of any number of different communication protocols with a variety of different types of client devices and applications, such as process or automation controllers, maintenance systems, monitoring systems, data collection systems, general-purpose communication systems such as email systems, text systems, internet-based communication systems such as Twitter or Facebook, etc.

[0035] Thus, as will be appreciated, the versatile field device 10 may 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 multiple different applications. Multiple different client systems, such as control systems, maintenance systems, and monitoring systems, may be able to access the same or different field device information (e.g., information from or about the field device hardware device 12) within the device 10. Communication with these various different client systems may use different higher-level communication protocols packetized using the underlying IP communications stack 38 based on the particular needs of the client applications. For example, some protocols, such as HART-IP, are better suited for controlling applications and for controlling communications because HART-IP generally provides faster and more reliable real-time data flow. Other protocols, such as OPC UA, are better suited for monitoring or maintenance applications because the protocol offers more diagnostic functionality without the need for high-speed or real-time communications. Still other protocols may enable device 10 to effectively provide or build web pages for client devices, allowing users to view device information from device 10, send email or text, communicate with external networks or public networks such as the Internet, or provide other device information in other formats useful for different client applications and purposes.Furthermore, the communication system and OS34 of the highly versatile field device 10 may enable communication connections between the field device 10 and external client devices to be established independently of each other, without the other client systems being aware of which other systems are accessing or communicating with the highly versatile field device 10.

[0036] In some cases, the application 30 may access the field device hardware 12 to obtain data from the field device hardware 12 and may store this data in the random access memory 16 of the device 10. The application 32 may enable access to the data in the memory 16 and expose that data to one or more external devices or client applications, depending on the use or functionality of the application 32. In other cases, the application 32 may allow authorized client devices to view and even change configuration data or settings of the field device hardware 12. Typically, a control system may include applications that communicate with authorized controllers to change settings on the field device hardware 12 and change the configuration of the hardware 12. Similarly, applications associated with a PAM system may allow authorized users to view device data and change device configuration settings and run other applications on the device (e.g., calibration applications, test applications, etc.). Other systems, such as monitoring systems, may have more limited access to the device hardware 12 or to device data stored in the memory 16.

[0037] In one exemplary embodiment, applications or modules 32 may be or include device models mapped to specific communication protocols. As an example, applications 32 may use OPC UA communications and APIs and may include device models mapped to OPC UA via profiles. The device models allow applications 32 to be configured to provide specific device data and functionality (according to the device model) accessible to external client devices using a specific communication protocol or paradigm.

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

[0039] Generally speaking, the highly versatile field device 10 is configured to operate in a plant or factory field environment that includes a communications network that supports advanced protocols operating on an open physical layer to facilitate communications between the field device and one or more client devices, which may be devices associated with any number of different systems, such as a control system, a maintenance system, a monitoring system, etc. Accordingly, the client devices may be process controllers (associated with a control system), maintenance applications or servers (associated with a device or plant maintenance system), monitoring applications or servers (associated with a monitoring system), and / or other systems.

[0040] In one embodiment, high-versatility (HV) field devices 10 may communicate via an advanced physical layer (APL). FIG. 2, for example, illustrates an APL-based network 80 in which the high-versatility field device 10 may be used to provide support for multiple client applications and devices. The APL network 80 supports communication between various field devices 82, any or all of which may be the high-versatility field device 10 of FIG. 1, and any other devices (such as controllers, servers, user interface devices, etc.) using packet-based or advanced (e.g., generic IP-based) communication protocols. Importantly, APL provides a two-wire physical communication layer (two-wire bus) that supports both digital communication and power delivery to devices connected to the physical layer. Unlike previous control-specific communication physical layers (e.g., those associated with protocols such as FOUNDATION Fieldbus, HART, Profibus, and CAN), APL provides sufficient power (in the form of voltage and current) over the two-wire bus to power general-purpose or higher-level operating-system-based microprocessors, such as microprocessor 14 of FIG. 1, within field devices connected to the APL physical layer or bus. This higher level of power is necessary to be able to implement a processor with functionality to run a general-purpose or real-time operating system, as described above with respect to FIG. 1. However, APL does not supply so much power (especially voltage) over the two-wire physical layer that it would be dangerous to use in a hazardous environment due to the risk of sparks. Thus, APL has enough power to power process control devices having microprocessors running operating systems, such as real-time operating systems, without having enough power to cause potential safety issues in the actual process control environment where the field devices are located. Generally speaking, an APL network supplies approximately 1.4 watts of power (on the spur lines) to each device at a voltage of 14 volts or less, preferably 10 volts or less.Additionally, the APL network provides a durable physical layer or wiring over two wires by using 14-gauge stranded wire, which makes the wiring less susceptible to braking in the field and allows for more power (current) at lower voltage levels due to reduced resistance. Additionally, APL supports IP-based or packet-based digital communications in the form of traditional Ethernet-based communications, making APL communications more suitable for use in other types of applications beyond control applications and extending the capabilities of traditional Ethernet into process control or factory automation environments or plants, while not having the drawbacks of the Ethernet physical layer (generally delivering 48 volts over thinner or higher gauge, single-stranded wiring).

[0041] Although the use of an APL network is described herein as a communications network connected to high-versatility field devices, other communications networks can be used to connect to and power high-versatility field devices. Generally speaking, such networks preferably use 14-gauge (0.06-inch diameter) or smaller (e.g., 12-gauge, 10-gauge, etc.) cable and preferably use stranded cable to provide better power delivery with stronger, more resilient cable. Furthermore, these networks preferably provide power at 14 volts or less, more preferably 10 volts or less, to limit spark generation in hazardous areas. Similarly, these networks should preferably provide at least 200 milliwatts of power, and in some cases may provide up to 2 watts of power to each device. In other embodiments, the network may provide at least 300 milliwatts of power and up to 4 watts of power to devices. More preferably, the network supplies 1-2 watts to the field device at a maximum of 10-14 volts, although lower voltages can be used and the network used to power the field device can supply higher power (wattage) than specified herein.

[0042] In the system of FIG. 2 , network 80 includes an APL power switch 84 connected, for example, via an Ethernet or other bus 85, to a control system (e.g., a process controller) and / or to other applications 90 in a cloud or other network. Cloud applications 90 may be or include any or all of applications from a variety of different systems, such as control applications (controllers) associated with a control system, maintenance applications associated with a maintenance system, and monitoring applications and devices (servers) associated with a monitoring system. By way of example, cloud applications 90 may include simulation applications, control applications, data storage and processing applications, and the like. In any event, APL power switch 84 includes an APL power device that provides power over the APL physical layer, and APL power switch 84 acts as a gateway to APL network 80, particularly to various APL field switches 86 connected to APL power switch 84 via a bus or wire network 88 conforming to the APL physical layer standard. As illustrated with respect to FIG. 2 , bus or network 88 may be a trunk line or a ring topology, as indicated by the dashed portion of bus 88. In any event, the bus 88 is an APL physical layer comprising, for example, a two-wire or four-wire wired network, that provides communication signals as well as power signals from the APL power switches 84 to the APL field switches 86. Additionally, each of the APL field switches 86 has one or any other number of highly versatile field devices 82 connected thereto via an appropriate APL physical layer or link 92. By way of example, the APL link 92 may conform to the APL specification and may be a two-wire or four-wire bus that provides or allows communication and power signals to be transmitted between the APL field switches 86 and the field devices 82.

[0043] Of course, the APL power switch 84 acts as a gateway to the bus 85, operative to multiplex signals from external sources onto the link 88 using the communications protocol established for the network 80. Similarly, the power switch 84 may operate to decode messages from any of the field switches 86 that are on the link 88 and that are destined for destinations outside the network 80 (which may be messages from field devices 82) and transmit these messages onto the link 85. Similarly, the APL field switch 86 decodes messages on the link 88, and if destined for one of the field devices 82 connected to the field switch 86, the field switch 86 places the message on the spur line or link 92 to transmit it to the field device 82. Similarly, the field switch 86 receives messages from the field devices 82 via the link 92 and places those messages on the link 88 for delivery to another field switch 86 or the power switch 84. Generally speaking, field devices 82 are all APL-compliant field devices in that they use the APL physical layer and a communication protocol supported by the APL physical layer (e.g., IP communication protocol) for communication over links 92 and 88. Field devices 82 may also receive power over link 92, which is supplied from field switch 86 and ultimately from APL power switch 84 and its associated power supply over bus 88.

[0044] In one example, the APL (physical layer) in FIG. 2 may be a ruggedized, two-wire, loop-powered Ethernet physical layer using 10BASE-T1L plus extensions for process plant operating conditions and installation in hazardous areas. In this case, the APL power switch 84 provides connectivity between all standard Ethernet networks and field devices and includes a power supply for powering the APL field switch 86 and the field device 82. Typically, the power switch 84 is located in a junction box in a control room or on a skid. Similarly, the APL field switch 86 may be designed for installation and operation in hazardous areas. The field switch 86 is loop-powered by the APL power switch 84 and distributes both communication signals and power to the field device 82 via a spur 92. The Advanced Physical Layer (APL) project was initiated to create a protocol-neutral Ethernet that could solve the problem of finding a protocol for long-reach Ethernet. This physical layer, as described herein, can be used in process automation and process instrumentation, for example, to connect field devices in remote and hazardous locations, and operates as an extension of the Ethernet physical layer, which operates at 10 Mb / s over a pair of cables. Additionally, APL extends 10BASE-T1L for use in hazardous areas, enabling the development of standards associated with typical protection methods, particularly intrinsic safety.

[0045] 2 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, Internet Protocol (IP protocol), packet-based protocols, time-sensitive protocols, and non-time-sensitive protocols. More specifically, these protocols may include HART-IP, OPC UA, and any other desired protocols designed for process control communication. Similarly, these protocols may include protocols not traditionally used in process automation, such as protocols that support request / response, publish / subscribe, and event-based communication, and general-purpose IP protocols including data streaming.

[0046] The use of network 80 illustrates one methodology for implementing the APL physical layer and 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 other devices on networks 85 / 90 of FIG. 2. Of course, in other cases, a process controller may be directly connected to an APL power switch 84 to provide communication with that power switch using the APL physical layer, and thereby implement communication between field device 82 and a controller (e.g., controller 11) using the APL physical layer. Furthermore, a power source may be provided within or associated with APL power switch 84 and may send power to field switch 86 via bus 88, although APL field switch 86 may be separately powered or may include its own power source or source and may provide power to itself, similar to field device 82, via APL spur line 92.

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

[0048] However, it is also possible to integrate the APL physical layer (and the IP communication protocols that use it) into an existing plant or factory network. More specifically, an overall I / O system may be used within a plant or factory field environment to support multiple I / O types while maintaining the plant's more traditional I / O architecture and simultaneously supporting multiple different systems directly from the highly versatile field device. Generally, the highly versatile field device 10 provides or supports a mixed physical layer that can support multiple different communication protocols, including traditional process control protocols and more general or general-purpose IP-based protocols, while also supporting multiple different systems in a direct client / server relationship. This versatility leads to improved control, as well as the combination of control with Industrial Internet of Things (IIoT) applications (typically interested in measurement and actuator data), the performance of these applications, and diagnostics of these applications.

[0049] An example of a more conventional plant and factory automation control architecture incorporating or supporting the high-versatility (HV) field devices 10 described herein is illustrated in FIG. 3. The plant 100 of FIG. 3 includes both process automation (PA) and factory automation (FA) components and control devices connected to one or more process and factory automation controllers via a communication network backbone, such as an Ethernet communication network. More specifically, as illustrated in FIG. 3, the plant 100 includes a factory automation area or section 102 and a process automation area or section 104. The factory automation section 102 is illustrated as including a single APL network 106 having a control topology that reflects how instruments and controls are typically set up in an automation plant. In this case, however, the APL network 106 is used to connect each of the different sets of FA high-versatility (HV) field devices 108 and 110 to a common or shared network backbone 112, which may be, for example, a 100 Megabit (M) or Gigabit Ethernet network. The APL network 106 includes, for example, an APL power switch 114 connected to an APL field switch 116 and a plurality of FA high versatility field devices 110 via a 100M APL network connection 120 , and an APL field switch 116 connected to each of a set of discrete FA high versatility field devices 108 .

[0050] Similarly, the process automation section 104 includes an APL power switch 122 connected to two APL field switches 124A and 124B via, for example, a 10mA APL network connection 126. The APL field switch 124A in FIG. 3 is illustrated as connected via a trunk line to two high-versatility PA field devices 128 and to an adapter device 130 that functions as an input / output device for a conventional field device, in this case a HART 4-20mA field device 132. Similarly, the APL field switch 124B is directly connected to the two high-versatility PA field devices 128 and also to an APL field switch 124C, which is illustrated as connected to two high-versatility (HV) field devices 128. Of course, the high-versatility field devices 108, 110, 128 communicate via their respective APL networks 104 and 106 to devices connected to the network backbone 112 via the APL power switches 114 and 122. In this manner, the high-versatility field devices 108, 110, and 128 can be communicatively connected to one or more controllers 140 on the network backbone 112 via a variety of different APL field switches and APL power switches using physical layers supported by different APLs (or communication networks having different speeds), while implementing control in process and factory settings using conventional control techniques.

[0051] However, as illustrated in FIG. 3 , the network backbone 112 is connected via a switch 142 to an additional network 144 to which other plant or factory applications and assets may be connected. In particular, as illustrated in FIG. 3 , plant asset management devices 145, one or more operator consoles 146, and one or more databases 148, such as control configuration and historian databases, may be connected to the network 144, which in this case may be a Gigabit Ethernet network. The devices 145-148 may communicate to the controller 140 via the network switch 142 and directly to the high-versatility field devices 108, 110, and 128 on the APL networks 104 and 106 via the APL power switches 114 and 122. Additionally, the plant asset management system 145 may include an asset management application 150 that obtains data from (e.g., by subscribing as a client) the various high-versatility field devices 108, 110, and 128. Additionally, other applications 151 and / or 152 and / or devices 154 (e.g., computing devices such as servers or hosts) associated with other systems, such as monitoring systems, data logging systems, etc., can be connected to the network 144 and act as clients to various data available from the high-versatility field devices 108, 110, and 128. Thus, for example, the plant asset management system 145 may execute one or more asset management applications 150 (within the devices 145 or in other devices connected to the networks 144 and 112), which may discover and register any of the high-versatility field devices and obtain data from the high-versatility field devices 108, 110, and 128 as clients (the field devices 108, 110, and 128 act as servers for their internal data and information). Similarly, other applications 151, 152 can discover and register the field devices 108, 110, and 128 and subscribe to data from these field devices.Once the field devices 108, 110, 128 are registered, the plant asset management application 150 or other applications 151, 152 may communicate directly with the field devices 108, 110, 128 via the network 144, the switch 142, and one of the APL power switches 114, 122 and possibly one or more of the field switches 116, 124A-C. This architecture enables the process automation and factory automation controller 140 to control the plant and factory floor using the field devices 108, 110, 128 without having to manage or route communications of other systems, such as a plant asset management system implemented in the device 145. In this case, however, the switch 142 acts as a security switch (e.g., a firewall), allowing authorized applications and users to 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.

[0052] Of course, while the system 100 of Figure 3 illustrates four highly versatile FA field devices 108 and 110 connected via a single APL network 106 and six highly versatile PA field devices 128 connected via a single APL network 104, each of the factory automation and process automation systems may include any number of highly versatile field devices connected to the controller 140 (and network 112) via any number of different APL networks, and each of these APL networks may have any number of field switches associated with it. Furthermore, as illustrated in Figure 3, the APL networks may use different types of communication hardware and communication speeds (physical layers) for each network connection (e.g., depending on the application), and each APL network may include highly versatile field devices connected directly to its power switch or connected to its power switch via one or more field switches.

[0053] In another exemplary architecture, the system of FIG. 3 may be extended to include or provide one or more applications on an additional network, such as a cloud, to gain access to the highly versatile field device 10. For example, FIG. 4 illustrates a system 160 similar to the system 100 of FIG. 3, in which the network 144 is coupled via a firewall device 162 to an additional network 164, which may be a plant or factory business network within a plant or factory. The network 164 may be further connected to a cloud 168 via an edge gateway 166, for example, using the OPC UA protocol and supported physical layers. One or more other applications associated with other systems, such as a monitoring system, a data logging system, etc., may be stored on and executed within a computing device in the cloud 168, and these devices and applications may communicate with the high-versatility (HV) field devices 108, 110, and 128 as clients through the edge gateway 166 (and network 164), through the firewall 162 and network 144, through the switch 142 and network 112, and through one of the APL power switches 114, 122 on 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 high-versatility field devices from applications (client applications) and devices within one or more external networks, i.e., networks external to the plant or factory. As will be understood, the edge topology network of FIG. 4 operates on top of or in parallel with the process and factory automation systems 102, 104. Edge devices or applications 166 and 168 may be used to support plant information integration, including, for example, scheduling, asset monitoring, analysis, simulation, and other functions.

[0054] In yet another example, plant and factory automation network architectures may make highly versatile field devices (also referred to herein as highly connectable field devices) directly available to cloud-based devices or applications. Cloud-based topologies can be used in process plants to operate in parallel with process instrumentation, for example, for energy monitoring, equipment and device monitoring, and condition-based monitoring typically used for process monitoring. Here, monitoring systems stream data from the plant, perform analysis of these data, and provide recommendations back to users, in some cases to the control system itself. A cloud-based topology is illustrated in FIG. 5 , where network architecture 180 includes APL networks 102 and 104 connected via APL power switches 114 and 122 to a cloud network 181 having various client applications 182 therein. Client applications 182 can be applications associated with any of the various systems mentioned above, including process control or factory automation control systems, plant asset management systems, data logging systems, monitoring systems, etc. Additionally, these client applications 182 may communicate with the power switches 114 and 122 of the APL networks 102 and 104 using any desired IP communication protocol, such as, for example, the OPC UA protocol using 100M or Gigabit Ethernet or any other suitable physical layer. Here, the client applications 182 can directly access the 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 for providing support for remote sites in a plant or factory automation setting, allowing control and other access to the versatile field devices via remote or cloud-based connections.

[0055] 6 and 7 illustrate yet another control system architecture including high-versatility (HV) field devices that can be accessed by a variety of client devices or applications. More specifically, the network architectures of FIGS. 6 and 7 are designed to work with traditional networking as well as flattened networking. Generally speaking, traditional networking provides access to devices through controllers and I / O servers, while flattened networking provides direct access to high-versatility field devices.

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

[0057] 7 further illustrates a flattened process control network 250 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 may be, for example, a Gigabit Ethernet network. I / O networks 262B and 262C are illustrated as APL networks with different APL power switches 266A and 266B connected to the Gigabit network 264. APL network 262A may be a high-speed APL network, such as a 100M network, including one or more field switches 268A, which are connected to various highly versatile field devices 270A that support or are used in control in a factory automation environment. In this example, APL network 262B may be a slower APL network, such as a 10M network, including one or more field switches 268B, which are connected to various high-versatility field devices 270B that support or are used in control of a process environment. Additionally, I / O network 262C may include switches connected to I / O devices 280 that support field devices under the control of controller 260, such as traditional field devices like HART, Fieldbus, etc. In this flattened architecture, high-versatility field devices 270, while controlled by controller 260, are connected to and serve data to clients (e.g., client applications) in stations 252, 254, 256, which are connected directly (or through gateway 258) to gigabit network 264, and in cloud network 259.

[0058] In both the traditional network 200 of FIG. 6 and the flattened network 250 of FIG. 7, device tagging must be unique. In both cases, devices include a unique ID, are assigned a unique tag, and support multiple application sessions. However, again, the highly versatile field devices 220, 224, 230, and 270 described herein support both a request model and a publish / subscribe model. To set up a publish / subscribe device, a publisher (highly versatile field device) must be discovered and, once discovered, authenticated for a session. Once a session is established, the highly versatile field device may support both predefined and custom published lists. As described in more detail herein, a client(s) or client application can subscribe to an existing published list or set up a custom published list and then subscribe to the custom published list.

[0059] As will be appreciated, the highly versatile field devices disclosed herein may support many different applications or systems. In particular, highly versatile field devices primarily act and operate as control field devices for performing process or factory automation control activities in response to a process or automation controller. However, highly versatile field devices may also support plant asset management systems (including device configuration). Typically, plant asset management systems are used to configure and provision devices, perform diagnostics on deployed devices, monitor device alerts, and a large list of other functions. Additionally, the highly versatile field devices described herein may support an IIoT platform for continuous condition monitoring. More specifically, condition monitoring systems may be deployed at many sites to perform a wide range of functions, including energy monitoring, equipment and device monitoring, and process monitoring. Such monitoring systems may stream data from the plant, perform condition monitoring, and provide recommendations to users and, in some cases, the control system itself.

[0060] In other cases, the highly versatile field devices described herein may support data logger systems. As an example, many systems may collect energy and monitoring data in a centralized manner for analysis and establishment of alarm management systems. For example, when a water leak is detected or energy is lost due to a leak or break in a pipe, these systems may 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 may support secure smart metering systems. In particular, metering can be a critical process in large, distributed systems such as oil and gas fields, pipelines, chemical storage facilities, and finished goods storage facilities. For example, in chemical storage systems, it is important to accurately read what materials are present. Smart metering systems typically include intelligent meter reading systems that meter via a controller or independently through a remote monitoring system and forward the readings to a processing location such as an edge gateway or central data server. Furthermore, the highly versatile field devices disclosed herein may support environmental monitoring, such as that mandated by the Environmental Protection Agency (EPA), or monitoring required for other applications. As an example, many plants have environmental reporting requirements, such as reporting of NOx, SOx, and other items. These systems tend to be dedicated systems that perform data collection, calculations, and reporting. It is extremely important that the data from these systems be time-stamped, insensitive to daylight saving time adjustments, and secure. The highly versatile field devices described herein can further provide these additional capabilities to the data provided to client applications.

[0061] Thus, as will be appreciated, the highly versatile field devices and field device network architectures described herein support a wide range of application scenarios. The data required in these scenarios is often different. In contrast to control applications, which require measurement parameters, unit codes, and status information, condition monitoring applications require information about the operation and health of a device. For example, for a valve, control data includes the valve output value (also called the target or valve setpoint) and the actual position of this valve output value, along with the unit code and status information for that valve. Meanwhile, valve condition monitoring data includes the valve setpoint, travel, drive, instrument air, percent travel per reversal, temperature, and other measurements. To make it easier for device manufacturers, these different sets of device parameters for these different applications can be included in pre-built templates for control, condition monitoring, data logging, environmental monitoring, or other functions. Users can also define and download their own templates to highly versatile field devices. Meanwhile, custom templates can be configured on the fly. Client applications can then subscribe to these templates. To streamline plug-and-play operation of highly versatile field devices, these templates can be included as part of the application connection, whereby the field device (server) informs the client what templates the field device has, and the client can subscribe to these templates or define its own custom templates.

[0062] In any case, because highly versatile field devices support IP communications with client devices directly, i.e., without going through a process controller using one or more specialized control protocols and physical layers, highly versatile field devices and the network architectures in which they are deployed require additional security over traditional field devices and networks. As noted above, the highly versatile field devices described herein simultaneously enable IP-based connectivity between these devices (i.e., field instrumentation) and multiple different client data consumers. Thus, highly versatile field devices and supporting networks include field device servers and client applications and devices, where field device servers include field devices such as flow, pressure, temperature, and other sensors, valves, and process analyzers. As noted above, clients include hosts such as PLCs, DCS controllers, plant asset management, and edge gateways, and applications stored and executed on hosts or other computing devices, such as process controller applications, plant asset management applications, environmental monitoring applications, condition monitoring applications, data logging applications, and smart metering applications.

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

[0064] In traditional control systems using traditional field devices, control system cybersecurity and control system design and operation assume that the control instrumentation and instrumentation networks are secure because they are physically separated and protected by the control system network. To support this type of security, control system implementations often include significant use of firewalls, network monitoring, and other defensive mechanisms deployed between layers of the control system. However, in reality, the field devices and field device networks themselves are often unmonitored, making anomaly detection difficult. Furthermore, these traditional control field devices and networks are unprotected, making them targets for attack. This security flaw is further exacerbated when protocols used in control networks are converted to other protocols, such as MODBUS or OPC DA, which lose semantics and context (e.g., unit codes). In these cases, when a client receives a measurement, such as a device measurement converted to an OPC DA value using an OPC DA status, the client is unaware that the value or the value's status has changed. These systems do not provide a standardized way to map the original value, along with the unit code and status of that value, to automation applications and other clients.

[0065] High-versatility field devices and the networks in which they are deployed address these security concerns by incorporating security features into the field devices and networks, which may include the use of TLS, certificates of authentication, and a complete security train of trust. More specifically, FIG. 8 illustrates a general block diagram of various security features provided, for example, in the high-versatility field device 10 of FIG. 1 and the networks in which these devices are deployed, such as those of FIGS. 2-7. In particular, as illustrated in FIG. 8, the security features include a root of trust component 302, a secure boot function 304, an endpoint identity function 306, secure storage 308, and cryptographic capabilities 310. Additionally, the security features include a secure communications function 312, device provisioning 314, and a security audit function 316.

[0066] In particular, each highly versatile field device 10 includes or encompasses a root of trust component 302 that forms the foundation of the device's security. Trust in embedded security refers to the expectation that the field device is operating as designed. Specifically, device software trusts that the hardware is operating as it should, applications run on the device with trust that the operating system has not corrupted the device configuration, and remote systems communicating with the device trust the device identity to which they are connected. The process of establishing this trust is called attestation, and the field device's root of trust 302 is the point where attestation and authentication begin. Once established, this root of trust extends to and provides the foundation for each layer of trust. Thus, the root of trust component 302 is a critical component in highly versatile field devices 10 because it provides the foundation for securing the device and all communications with it. The root of trust component 302 can be established using any of a variety of methods and can take many forms, but generally, the root of trust component 302 ensures that the boot code on the field device is the code intended by the manufacturer. This root of trust function 302 protects the boot code in a manner that makes the root of trust function 302 unalterable or uncorruptible to external tampering. In one simple case, the root of trust component 302 may be established by storing and / or executing the field device 10 manufacturer boot code in or directly from a non-writable location in the device processor's memory map. Alternatively, the device may include a root of trust component 302 that allows the boot code to be updated and patched by allowing the boot code to be loaded from a protected memory area into some type of protected memory store separate from the firmware execution.A key aspect of the Root of Trust component is that it verifies the initial code is what the manufacturer intended before it is executed, and it protects against third-party tampering with the manufacturer code (or updated code). When the code starts, the Root of Trust derives the Root of Trust's internal key from the provided device identity input, and the device performs its own self-tests and code verification to confirm its identity and establish the Root of Trust's base key to be used with other devices in the network.

[0067] Additionally, the high-versatility field device 10 includes a secure boot function or process 304. The secure boot process 304 prevents unauthorized code execution when the device is powered on and prevents the exposure of embedded boot code and software. A secure boot process can be achieved in many different ways, including using digitally signed binaries, a secure and trusted boot loader, boot file encryption, or a security microprocessor. While the secure boot function 304 may be centered around digitally signed boot files, unless those signatures are verifiable using some kind of immutable root of trust, the boot is not secure. Therefore, to validate the boot files, the high-versatility field device is installed with a digital key (and established by the root of trust component 302) either during device manufacture or after manufacture using a trusted application, and this digital key is then used to implement or enable other security functions. Additionally, the secure boot process protects software on the device, such as proprietary algorithms, and provides trusted remediation actions. That is, the secure boot process 304 provides the ability to securely repair the process control system in the event of a device failure or compromise because the repair relies on having a secure boot process that checks the validity of firmware images that boot with or use the root of trust component 302. The device secure boot process 304 provides standardization of these checks to ensure that one bad device does not compromise itself more than it can.

[0068] Additionally, the device's secure boot process 304 provides for or enables secure firmware updates. In particular, secure firmware upgrades involve validating incoming payloads intended to replace existing firmware images, which is critical to maintaining the integrity of the device throughout the system lifecycle. The source of the payload and the payload itself must be verified before being applied, and in a properly implemented secure boot process 304, failure to verify the incoming code results in a secure rollback to a known, verified boot image. Additionally, the secure boot process 304 enables secure connectivity to cloud resources, as the secure boot process 304 ensures that the device is authenticated with the cloud every time the device attempts to connect to the cloud using embedded keys and certificates.

[0069] Similarly, the highly versatile field device 10 provides endpoint identity functionality 306. In particular, endpoint identity is a fundamental component essential to most other security measures. To provide endpoint identity, the highly versatile field device 10 includes a unique device identifier or identity, which is tied to the device's unique device ID.

[0070] Additionally, the highly versatile field device 10 includes secure program storage 308. In particular, the program storage may be implemented in off-chip flash memory, the contents of which are copied to SRAM or external DDR memory and activated when the field device is booted. The hardware root of trust protects the device's unique identity and the keys associated with that identity, thus securing the facilities (communications) derived from these keys. The device includes secure storage 308 for the rest of the chip, acting as an identification or authentication device.

[0071] Additionally, highly versatile field devices use and implement transport protocol (data in motion), in-storage (data at rest), and in-application (data in use) encryption 310. Various types for the encryption services listed below may be used to implement encryption in this manner, although device manufacturers may use others. As an example, highly versatile field devices may use or include standards-based symmetric cipher suites (PSK or PKI), hash functions, and random number generators of appropriate strength, as well as implementations of NIST / FIPS standards-based validated encryption algorithms, allowing for interoperability of encryption keys.

[0072] Additionally, the highly versatile field device 10 provides secure communications 312 by including a secure end-to-end communication protocol stack. The highly versatile field device 10 may provide secure transport using TLS, a hash function (for generating MAC codes) using SHA-2, and encryption using AES-128.

[0073] Similarly, the highly versatile field device 10 provides or includes secure device provisioning 314 (generally performed by the manufacturer in a secure or trusted environment using a secure process), which may include writing specific information to the device, such as a device tag, a pre-shared key and / or certificate, a Syslog server hostname and port, a DNS server name, and optionally, a default port number and static IP address and mask on which the device listens. Devices should be provisioned before they are installed in a plant. This provisioning is often referred to as onboarding. In one example, during the provisioning phase, the device should have the following information configured by the secure device provisioning process: (1) the device name and the unit name where the device is installed, (2) the pre-shared key or X.509 certificate used to establish a session, (3) the hostname and port used to connect to the Syslog server, (4) the name of the DNS server, (5) a static IP address and a submask of the static IP address (optional), and (6) an optional port number if the default is blocked by a firewall (also optional). All of this information should be loaded into a secure location on the device. This information also needs to be made available to hosts that open sessions with the device.

[0074] Additionally, the highly versatile field device 10 includes or supports security audit functionality (e.g., Syslog) 316 that allows the field device 10 to be monitored as part of its normal operation. To aid in this monitoring, the highly versatile field device 10 supports audit logging, including providing audit log information to a Syslog server. In particular, for incident response and auditing, event logs are used as valuable input that can help continuously measure and assess risk and mitigate threats. This requires an application that captures system and security events (which may not be security events), forwards the events to a host using Syslog, and reviews the system events. To implement this functionality, the highly versatile field device 10 supports audit logs and functionality (Syslog). In particular, the device (server) may record the following in a local volatile audit log: (1) the last time and date the server was powered on, (2) the last time and date security credentials were changed, (3) server status, (4) a rotating 128-entry session summary list, and (5) a timestamp, such as an 8-byte unsigned integer timestamp. Each session summary record may include (1) a client identity, including IP address (IPv4, IPv6) and port number, (2) the time / date of connection / disconnection for that client, (3) a start / end configuration change counter, (4) session status, and (5) communication counters indicating the number of publish (burst), request, and response PDUs. Additionally, the highly versatile field device 10 may support Syslog by supporting or providing push audit messages (Syslog messages) that are pushed to a security information and event management system supporting the field device 10. These pushed messages are critical to detecting security attacks and unauthorized operation of the field device 10. Detection enables improvements to plant security policies and procedures to minimize vulnerabilities.

[0075] As an example, the highly versatile field devices 10 and clients connected to these highly versatile field devices 10 may support various communication security protocols, such as TLS versions 1.2 and 1.3 and DTLS versions 1.2 and 1.3. For both TLS and DTLS, a secure handshake is used to establish a secure session. Once established, communications are secured with TLS. Sessions can be established with certificates or with pre-shared keys. The highly versatile field devices may support both PKI and pre-shared keys (PSK). Because OPC UA fully supports certificates, certificates are used when OPC UA is used to communicate with the field devices 10. If the end user decides to use symmetric keys, the system is designed to manage these keys. Additionally, the highly versatile field devices 10 may support different security protocols (PSK and PKI) for different sessions or with different clients.

[0076] Network Node Management 9 is a block diagram of an example system 400 for managing nodes of a nodal communication network 402 of an industrial process plant or factory automation system, where at least one high-versatility (HV) field device 10 is a respective node of the network 402. In an example implementation, the system 400 may be included in or otherwise support any one or more embodiments of the plant and factory automation networking and control architectures depicted in FIGS. 3-7. For example, at least a portion of the nodal communication network 402 may include the conventional process control network 200 of FIG. 6 and / or at least a portion of the nodal communication network may include the flattened process control network 250 of FIG. 7.

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

[0078] Devices D1-Dn may include one or more field devices, each of which performs a respective physical function during runtime operation of the plant or network to thereby control the industrial process. For example, the field devices included in D1-Dn may include sensors, valves, actuators, gauges, other types of measurement devices, etc. In addition to field devices, devices D1-Dn may include other types of devices located 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 devices D1-Dn may be high-versatility (HV) field devices, such as high-versatility field device 10; for example, devices D1-D4 and Dn are illustrated in FIG. 9 as being high-versatility field devices. Some of the devices D1-Dn may be legacy or conventional devices, such as device D5 shown in FIG. 9, and as such may be communicatively connected to the APL component 410 (and thus to the backbone 408 of the node communication network 402) via an adapter 415, where the adapter 415 supports the native I / O of the conventional device D5, thereby enabling the conventional device D5 to communicate over the communication network 402 via the APL component 410.

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

[0080] Generally speaking, during runtime operation of the process plant or automation network, at least some of the devices D1-Dn generate data as they perform their respective functions during runtime control of the industrial process, in a manner as discussed elsewhere herein, and the generated data may include data indicative of and / or associated data for their respective physical functions as they are being performed. In this manner, the devices D1-Dn may be considered to be "data hosts" or "data servers" within the nodal communication network 402, and as such, generate or create data that may be operated on, utilized by, or otherwise consumed by other devices. Other devices and / or systems 418-428 may be consumers of the data generated by the devices D1-Dn, and thus may be considered to be "data clients" of the "data hosts" within the nodal communication network 402, and manipulate, utilize, or consume the data generated / created by the host devices.

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

[0082] Some of the nodes D1-Dn, 418-428 may be both data hosts and data clients simultaneously. For example, the controller 418 may be a data client for data generated by the data host field device D3, and the controller 418 may also be a data host that generates data (e.g., control signals generated by the controller 418 that execute control routines on data generated by the field device D3) that is consumed by another field device Dn, another controller 418, another system 428, etc. Generally, within the node communication network 402, each node D1-Dn, 418-428 of the node communication network 402 (regardless of whether the node is operating as a data host, a data client, or both) is identified via a respective IP address (which in embodiments may be a secure endpoint identity 306, e.g., as discussed above with respect to FIG. 8), which may be assigned to the node by a Dynamic Host Configuration Protocol (DHCP) service (e.g., in a manner as described elsewhere in this disclosure), where the DHCP service may be hosted on a DHCP server 430 of the system 400. 9, the DCHP server 430 is communicatively connected to the node communication network 402, for example, via the backbone 408. In some configurations, the node communication network 402 may include multiple DCHP servers 430 that may operate in a redundant manner (e.g., for backup purposes) or that may service in parallel respective sets of node query requests for IP addresses / endpoint identities utilized within the system 400.

[0083] Within a process control system or automation network, on the other hand, each device D1-Dn is identified by and / or associated with one or more respective logical identifiers or tags, such as a device tag, one or more data tags that identify the type of data the device transmits and / or receives, etc. For example, a device tag may be a primary device identification or identifier because it directly identifies the device, while a data tag may be a secondary device identification or identifier because it indirectly identifies the device via the particular data that the device produces or consumes. Generally speaking, the tags or identifiers identified and / or associated with devices D1-Dn are defined in one or more configurations of the process control system or automation network, such as one or more configuration databases 420. The one or more configuration databases 420 may be nodes of a nodal communication network 402, as illustrated in FIG. 9, for example, or the one or more configuration databases 420 may be communicatively connected to devices D1-Dn via one or more other types of process control or automation networks (not shown in FIG. 9), which may include legacy or conventional process control or automation networks. Some identifiers or tags may be manually or automatically provisioned into each device D1-Dn (e.g., during bench provisioning and / or commissioning of the devices D1-Dn or at some other time prior to initial power-on of the devices D1-Dn in the field environment 412a) and / or some identifiers or tags may be downloaded or otherwise stored into each device D1-Dn along with the configuration of the respective device. Respective device tags and any respective data tags identifying and / or associated with each device D1-Dn are represented in FIG. 9 by circled "tag" symbols.

[0084] The system 400 for managing nodes of the node communication network 402 (e.g., nodes D1-Dn and 418-428) includes a network node manager 432 communicatively connected to the node communication network 402. The network node manager 432 has knowledge of (e.g., stores information indicative of) all devices that have connected to the node communication network 402 and that have been discovered, e.g., as “nodes” of the node communication network 402. For example, the network node manager 432 may store the identities of the discovered devices (e.g., their respective IP addresses, endpoint identities, or names, and / or their respective device identification information) 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 integral with the network node manager 432 (not shown in FIG. 9 ) and / or at least a portion of the discovered device data store 435 may be implemented as individual nodes of the node communication network 402, as shown in FIG. 9 . Network node manager 432 further stores and updates the state or status of each discovered device in discovered device data store 435. Non-limiting examples of possible device states or statuses include commissioned, active, inactive, offline, faulty, booting, in diagnostics, limited operation, and / or other suitable states or statuses. Device states or statuses may be updated by the device itself or by other devices. In some embodiments, device states and / or statuses may refer to operational, physical, component, and / or equipment states and / or statuses. In some embodiments, network node manager 432 also stores each security credential of and / or associated with a discovered device.

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

[0086] To this end, the discovered device data store 435 stores associations or mappings between device identification information (e.g., a device's device tag and, optionally, data tags associated with the device) as defined in the process control configuration database 420 and respective IP addresses / endpoint identities assigned to the devices by the DHCP server 430. As such, the discovered device data store 435 is interchangeably referred to herein as the “mapping database 435.” To illustrate, consider an exemplary device D1 that has been provisioned and / or configured with a device identification tag A and two data tags B and C that identify two particular types of data generated by the device D1. The DHCP server 430 assigns the device D1 an IP address A1B2. Thus, the mapping database 435 (e.g., the discovered device database 435) stores representations of the associations between (1) the device tag A and the IP address A1B2, (2) the data tag B and the IP address A1B2, and (3) the data tag C and the IP address A1B2.

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

[0088] In practice, 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. In this manner, the DNS server 438 receives a request or query from a first device for an assigned IP address of a second device, where the second device is identified in the request or query by the specific device's configured identification information (e.g., a device identification information 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 and return the IP address of the second device to the first device, for example, so that the first device can communicate with the second device using the IP address of the second device. In some embodiments, the DNS server 438 also takes into account the state of the device as indicated in the device state database 435 in the DNS server 438's response. For example, if the second device is down, the DNS server 438 may respond with an indication of this in addition to or instead of the requested IP address of the second device. In some configurations, the node communication network 402 may include multiple DNS servers 438.

[0089] 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 coupled to the node communication network 402. Generally speaking, 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 and 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, the security manager 440 may verify certificates and / or other types of security credentials when requested, etc. Additionally, the security manager 440 may include an interface that may cause various security credentials to be provisioned or otherwise stored in the devices (e.g., before the devices undergo bench provisioning and are powered on in the field environment 412a). Additionally or alternatively, security manager 440 may provide various security credentials to devices when their respective IP addresses are assigned (e.g., by DHCP server 430). Security manager 440 may include a user interface that may allow a user to manually enter security credentials and / or may include a communication interface that may allow tools or other computing devices to provide and / or obtain security credentials for the devices. Additional details regarding security credentials are provided elsewhere in this disclosure.

[0090] In an embodiment, the system 400 for managing nodes (e.g., nodes D1-Dn and 418-428) of the node communication network 402 includes a system log server 442 (also referred to herein as “log server 442”) communicatively connected to the node communication network 402. Generally speaking, the system log server 442 is a centralized log server that logs or records events related to the network 402, such as when devices connect to and disconnect from the node communication network 402, and when communication sessions are established and torn down. The devices themselves may notify the log server 442 of the occurrence of various events, such as each time the device connects to and / or attempts to disconnect from the network 402. For example, if the device is a high-versatility field device 10, the device may utilize the security audit function 310 (as discussed above with respect to FIG. 8 ) to communicate connection, disconnection, and other types of information with the system log server 442. In some cases, the device may further notify the log server 442 of events related to other devices. Logs stored on log server 442 may be audited and / or otherwise analyzed for the purpose of mitigating security issues.

[0091] 9 illustrates DHCP server 430, network node manager 432, DNS server 438, security manager 440, log server 442, and mapping database 435 (e.g., “management” nodes of network 402) as being separate and distinct nodes of node communication network 402, it should be noted that this is for ease of explanation only and is non-limiting. Any two or more of these management nodes 430, 432, 435, 438, 440, and 442 may be implemented as an integrated node, if desired. For example, network node manager 432 may include DNS service or server 438; network node manager 432 may include DHCP service or server 430; DNS server 438 may include mapping database 435; etc. 9 illustrates each of the nodes or servers 430, 432, 435, 438, 440, 442 as a respective single node, in embodiments, the system 400 may include multiple nodes of each of the nodes 430, 432, 435, 438, 440, and / or 442. Furthermore, any one or more of the management nodes 430-442 may be implemented by or hosted by any suitable computing system, such as one or more physical and / or virtual servers, one or more data banks, etc., and at least a portion of these management nodes may be located locally or proximately with respect to the process plant or automation system, and / or at least a portion of these management nodes may be located remotely with respect to the process plant or automation system, e.g., in a server farm, a cloud computing system, etc.

[0092] Generally speaking, the management nodes or components 430, 432, 435, 438, 440, 442 of the 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, the system 400 may provide device discovery, device state tracking, device security, and other types of device management.

[0093] For illustrative purposes, FIG. 10 depicts an exemplary message flow 500 that occurs upon initial connection of an exemplary device 502 to a node communication network 402. The device 502 may be a highly versatile field device, such as, for example, device D1, D1-D4, or Dn, or the device 502 may be a legacy field device, such as device D5, connected to the APL component 410 and network 402 via an adapter 415. Thus, in situations where the device 502 is a legacy device, the adapter 415 communicates with the network 402 on behalf of the legacy device, even though the adapter 415 is not depicted in FIG. 10. Generally speaking, the message flow 500 may occur in the embodiment of the system 400 of FIG. 9 or in other systems for managing nodes in a node communication network of a process control system or automation network. However, for ease of explanation, and not for purposes of limitation, the message flow 500 is described below with simultaneous reference to FIGS. 8 and 9.

[0094] In the example message flow 500, the device 502 is provisioned with its own identity prior to powering up 505 and connecting to the communications network 402. That is, the device's unique identification information (e.g., a device tag), and optionally any data tags corresponding to data that the device will transmit and / or receive during runtime operation, may be provisioned or otherwise stored in the memory of the device 502, for example, either manually by an operator and / or by using a provisioning, commissioning, or other suitable tool, such as a security manager 440 or 605. The above process of storing identity and other information in the device 502 while the device 502 is not yet powered up for runtime operation and while the device 502 is not yet connected to the network 402 is referred to herein as “bench provisioning” and is described in more detail elsewhere in this disclosure. In any event, as previously discussed, the device's unique identification (e.g., device tag) and any data tags associated with the device 502 are typically defined in one or more configurations stored in the process control system or automation network's configuration database 420; in this manner, the device 502 is provisioned with a logical identifier (e.g., corresponding device tag) that allows the device 502 to be recognized by the process control system or automation network, and optionally, any corresponding data tags that are further recognized by the process control system or automation network.

[0095] The device 502 is physically located and installed in its intended location of the process control plant or automation network, for example, a field environment of the process control plant or automation network (such as field environment 412a in FIG. 9), and any physical interface to the network 402 is physically connected to this field environment. The device 502 is then powered on, as represented by reference numeral 505. For example, the device 502 may be powered on using the secure boot function 304 in FIG. 8.

[0096] Upon powering on 505, the device 502 broadcasts a discover DHCP message (508) over the network 402 to determine or discover any DHCP servers that serve the node communication network 402 and that may be able to assign the device 502 an IP address or endpoint identifier so that the device 502 may be identified within the network 402 as a node of the network 402. The discover DHCP message 508 is received by any DHCP services and / or servers serving the network 402, such as the DHCP server 510 shown in Figure 10. In one exemplary implementation, the DHCP server 510 is an embodiment of the DHCP server 430 of Figure 9.

[0097] In the example message flow 500, the DHCP server 510 responds to the discover DHCP message 508 with a DHCP offer 512 that identifies the DHCP server 510 therein and includes IP addressing information for the device 502. For example, the offer 512 may 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 corresponding network parameters and other information associated with the IP address assigned to the device 502 (e.g., the endpoint identity 306). The DHCP server 510 responds 518 with the requested information, thus providing the device 502 with not only the IP address assigned to the device 502 (e.g., the endpoint identity 306), but also other parameters such as a netmask, gateway, router, and / or other network configuration parameters. In some embodiments, the assigned IP address is valid for only a finite time (eg, a lease), and the DHCP server 510 indicates the duration of the lease to the device 502 in the response 518 .

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

[0099] In any event, at this point 520 in the message flow 500 (e.g., after the response 518 is received by the device 502), both the device 502 and the DHCP server 510 have knowledge of the association between the device's process control / automation network identification information (e.g., device tag) and the IP address / endpoint identifier assigned to the device 502. In some implementations, the device 502 and the DHCP server 510 may additionally or alternatively have knowledge of the respective associations between each of the device's data tags and the IP address assigned to the device 502. In this manner, the DHCP server 510 and / or the device 502 may update the discovered device / mapping data store or database 522 with the new associations or mappings. In one example implementation, the discovered device / mapping data store or database 522 is an embodiment of the discovered device / mapping data store 435 of FIG. 9.

[0100] In the exemplary branch of message flow 500 represented by reference numeral 525, the DCHP server 510 may send an indication of the new association or mapping between the device 502 and its assigned IP address to a network node manager and / or DNS server 528, which may update 530 the mapping database 522 with an indication of the new association between the device's identification information and the IP address assigned to the device 502 (and / or of the respective associations between each of the device's data tags and the IP address assigned to the device 502). In one exemplary implementation, the network node manager and / or DNS server 528 is an embodiment of at least one of the network node manager 432 or the DNS server 438 of FIG. 9. Additionally or alternatively, device 502 may send an indication of the new association between the device's identification information and the IP address assigned to device 502 (and / or the respective association between each of the device's data tags and the IP address assigned to device 502) to the network node manager and / or DNS server 528, as represented in FIG. 10 by reference numeral 532, thereby causing mapping database 522 to be updated accordingly (reference numeral 535).

[0101] Significantly, the system 400 may provide the capability for “plug-and-play” devices, as illustrated by the example message flow 550 of FIG. 11 . In FIG. 11 , a device 552 (e.g., “device A”) physically arrives at a site of a process control plant or automation network where the device 552 is installed and operates to control an industrial process during runtime. The device 552 may be a highly versatile device, such as one of the highly versatile field devices 10, D1-D4, and Dn, or the device 552 may be a legacy device, such as device D5, which connects to the node communication network 402 via an adapter 415 and an APL component 410. Thus, for situations where the device 552 is a legacy device, the adapter 415 communicates on behalf of the device 552 via the node communication network 402, even though the adapter 415 is not shown in FIG. 11 . Generally speaking, message flow 550 may occur in the embodiment of system 400 of Figure 9, or in other systems for managing nodes in a node communication network of a process control system or automation network. However, for ease of explanation, and not by way of limitation, message flow 550 is described below with simultaneous reference to Figures 8-9.

[0102] Prior to powering up 555 the device 552 on-site for runtime operation, the device 552 may be provisioned (e.g., bench-provisioned) with a device tag and, optionally, with information such as a corresponding data tag, one or more security credentials (e.g., keys, certificates, passwords, etc.), the IP addresses of the DHCP server 430, the DNS server 438, and / or the network node manager 432, the IP address of the system log server 442, the IP address of the security manager 440, and / or other information. For example, an operator or user may communicatively and temporarily connect a not-yet-connected device 552 to the security manager 440 or 605, to a provisioning or commissioning tool (not shown), or to another suitable device or tool that provisions or otherwise stores such information in the memory of the device 552, thereby bench-provisioning the device 552. In embodiments in which security credentials are bench-provisioned to the device 552, the security manager 440 typically assigns one or more security credentials to the device 552. In embodiments where the device 552 is a highly versatile field device 10, the device 552 may utilize on-board device provisioning functionality 314 to obtain identification information and security credentials from the security manager 440 and store the obtained information in on-board secure storage 308 for use by functions such as root of trust 302, secure boot 304, cryptographic performance 310, secure communications 312, and security audit 316, for example.

[0103] 11, for ease of discussion, but not by way of limitation, an embodiment of system 400 supporting message flow 550 is arranged such that the network node manager includes or hosts a DNS service. That is, in FIG. 11, the network node manager and DNS service or server are integrated nodes, as represented, for example, by reference numeral 560. Further, in FIG. 11, the DHCP server is a separate node in the node communication network, as represented, for example, by reference numeral 562. In one exemplary implementation, network node manager / DNS service 560 is an embodiment of network node manager 432 and DNS server 438 of FIG. 9, and DHCP server 562 is an embodiment of DHCP server 430 of FIG. 9.

[0104] When device 552 powers up 555 (e.g., by utilizing secure boot functionality 304), device 552 sends a request 558 to integrated network node manager / DNS service 560 for an IP address or endpoint identity that will identify device 552 within node communication network 402. For example, device 552 may send request 558 to network node manager / DNS service 560 using the network node manager / DNS service's 560 IP address that was bench-provisioned for device 552. Upon receiving device request 558, network node manager / DNS service 560 interfaces with DHCP server 562 (e.g., via message exchange 565) to obtain an IP address for device 552 (e.g., obtain device's endpoint identity 306), and network node manager / DNS service 560 returns the device's assigned IP address / endpoint identity (and optionally other information as previously discussed) to device 552 in response 568. The device 552 may store its assigned IP address / endpoint identity and other information, for example, in the secure storage 308 of the device 552. At this point 570 in the message flow 550, the device 552 is recognized or identified within the process control system or automation network by its configured device identification or tag and is recognized or identified within the node communication network 402 by its assigned IP address / endpoint identity. The association between the device's configured identification or tag and the device's IP address / endpoint identity is stored in a mapping database or discovered device data store, such as the mapping database 435, which is accessible to at least the network node manager / DNS service 560, as previously discussed.Additionally, the network node manager / DNS service 560 updates the state of the device 552 in the mapping database or discovered devices data store to "connected," "active," "available," or some suitable equivalent state that indicates that the device 552 is active and available for use. In the exemplary implementation illustrated in FIG. 11, the discovered devices / mapping database is integrated with the network node manager / DNS server 560.

[0105] Thus, at this point 570 in message flow 550, device 552 is "plugged in" to node communication network 402. That is, device 552 is connected to node communication network 402 and is available to communicate with other nodes in network 402. Once connection 570 is complete, device 552 notifies system log server 572 that device 552 has connected to network 402 (e.g., as represented by reference numeral 575), and system log server 572 logs the connection event. In one example, system log server 572 is an embodiment of system log server 442, and device 552 utilizes security audit function 316 to provide an indication of the connection event to log server 442.

[0106] 11, device 552 is shown as obtaining its assigned IP address by communicating with network node manager / DNS service 560, it should be noted that this is but one of many possible embodiments. For example, device 552 may obtain its assigned IP address by utilizing a broadcast discover DHCP message, e.g., in a manner similar to that performed by device 502 in example message flow 500 of FIG. 10. In another example, device 552 may be bench-provisioned with an IP address from DHCP server 562, and upon power-on 555, device 552 may communicate directly with DHCP server 562 to thereby request and / or obtain its IP address and associated parameters. Of course, other embodiments are possible.

[0107] 11 , while device 552 remains “plugged in” or connected to node communication network 402, network node manager / DNS service 560 tracks and updates the state and / or status of device 552 in a discovered device or mapping database (e.g., discovered device / mapping database 435, which, as previously discussed, is illustrated in FIG. 11 as being integrated with network node manager and DNS service 560). In message flow 550, network node manager / DNS service 560 polls device 552 (e.g., periodically, on-demand, when triggered, etc.) and receives current operational state from device 552 in response to the poll, as represented by message exchange 578, for example. For example, network node manager / DNS service 560 may poll each device in network node manager / DNS service 560 (e.g., via a discovered device or mapping database) for which it has knowledge of updates to the device's state. Additionally or alternatively (not illustrated in FIG. 11 ), device 552 may autonomously provide its current state and / or status to network node manager / DNS service 560, for example, either periodically and / or when the device's state and / or status changes (e.g., a fault is discovered, device 552 undergoes diagnostics, reboots, etc.). Still additionally or alternatively, a third-party device may provide updates to network node manager / DNS service 560 on the state and / or status of device 552 (also not illustrated in FIG. 11 ), such as when a diagnostic tool examines device 552 offline for diagnostic purposes, when a security manager (e.g., security manager 440) discovers a security anomaly associated with device 552 that needs to be mitigated and affects the device's state, etc. In either case, network node manager / DNS service 560 updates the state and / or status of device 552 in its discovered device database.

[0108] While the device 552 is connected to the node communication network 402, other devices or nodes of the network 402 may discover the device 552 and establish communications with it (e.g., the "... and play" portion of "plug and play"). To illustrate, consider an exemplary scenario in which the device 552 is a field device that generates data as the device 552 operates during runtime of a process control system or automation plant. In this scenario, the field device 552 and a controller device 580 (e.g., "Device B" in FIG. 11 ) are included in a process control loop that operates during runtime of the industrial process plant or automation network to control the industrial process. The configuration of the process control loop, the field device 552, and the controller 580 is stored in the configuration database 420, and each of the field devices 552 and the controller 580 has been provisioned with its respective device tag or identification information (e.g., as shown in the configuration database 420) and assigned a unique IP address by the DHCP server 562. Additionally, the controller 580 stores (and executes during runtime) one or more control modules or routines configured to manipulate data generated by the field devices 552, such generated data being referenced by the device tag of the field device or by one or more respective data tags associated with the field devices 552. That is, the controller 580 is configured to be a consumer (e.g., a client) of runtime data generated by the field devices 552 (e.g., a host). The configuration of the controller 580 and of the control modules or routines that the controller 580 will execute is defined in the configuration database 420 and downloaded and / or otherwise provided to the controller 580 for storage and execution during runtime operation.In this manner, the controller 580 has knowledge of the device tag and / or data tag associated with the field device 552 (e.g., as provided in a downloaded configuration), but the controller 580 does not have a priori knowledge of the IP address assigned to the field device 552 within the node communication network 402.

[0109] 11 , the controller 580 (e.g., via a DNS client running on the controller 580) queries the DNS service or server 560 for the IP address of the field device 552 (represented by reference numeral 582), for example, by utilizing the IP address of the DNS server 560 bench-provisioned in the controller 580 and providing the DNS server 560 with the device tag and / or data tag of the field device 552 known to the controller 580. Upon receiving the query 582, the DNS service 560 accesses a mapping database / discovered device data store to find the IP address assigned to the field device 552. The DNS service 560 responds 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, the DNS service 560 may return the IP address of the field device 552 only when the field device 552 is active, the DNS service 560 may return both the IP address of the field device 552 and an indication of the field device's current state (e.g., active, temporarily down, etc.), the DNS service 560 may return an indication that the field device 552 has been disconnected from the network 402, etc.

[0110] In an embodiment, upon receiving the query 582, the DNS service 560 may authenticate the controller 580 and the field device 552 using the respective security credentials (e.g., keys, certificates, etc.) of the controller 580 and the field device 552. For example, the DNS service 560 may authenticate the controller 580 and / or the field device 552 by querying the security manager 440 to authenticate, verify, confirm, etc. by utilizing the respective security credentials stored in the discovered device database 435.

[0111] In any event, upon receiving response 585 from DNS service 560, controller 580 has discovered the field device 552 with which it will communicate during execution of the process control loop. Using the field device's IP address (and field device 552 using the controller's IP address), controller 580 may communicate in any suitable manner (e.g., direct messaging, client / server type communication, request / response, publish / subscribe, etc., as described elsewhere in this disclosure) over node communication network 402 to execute the control loop and / or for other purposes. In an embodiment, controller 580 and field device 552 utilize their respective IP addresses to establish a secure communication session over network 402, as represented by reference numeral 588, allowing controller 580 and field device 552 to communicate data and information. For example, the controller 580 and the field device 552 may exchange security credentials (which may be assigned by the security manager 440 and bench-provisioned to each of the devices 580, 552), may verify certificates with the security manager 440 and / or the network node manager 560, and / or may take other associated actions to secure the communication session. Typically, the controller 580 and each of the field devices 552 notifies the system log server 572 of the establishment and teardown of the session, as well as other events associated with the communication session (not shown in FIG. 11 ).

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

[0113] 9, as previously discussed, network node manager 432 may discover devices attached to or connected to node communication network 402, store device identification information (e.g., primary device identification information such as a device tag, or secondary device identification information such as a data tag) and IP addresses of discovered devices in mapping database / discovered device data store 435, and maintain updated states and / or statuses of discovered devices in mapping database / discovered device data store 435. For example, in embodiments where network node manager 432 and DHCP server 430 are an integrated node, network node manager 432 discovers newly connected devices by receiving device queries of DHCP server 430 for IP addresses. When network node manager 432 is a different node from DHCP server 430, DHCP server 430 may notify network node manager 432 and / or DNS server 438 of newly connected devices and their respective device identification / IP address associations. When DHCP server 430 notifies only one of network node manager 432 or DNS server 438 of newly connected devices (and their respective device identification / IP address associations), the other node may query (e.g., periodically or otherwise as needed) the notified node for the newly added devices and their respective IP addresses and device identifications. Thus, generally speaking, mapping / discovered device database 435 may store device identifications and corresponding IP addresses, as well as updated device status and state information.

[0114] In an embodiment, 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 security manager 440 and may have been stored in discovered device database 435 directly by security manager 440 (e.g., via bench provisioning). Additionally or alternatively, at least some of the security credentials may be provided to network node manager 432 during device discovery by security manager 440 and / or by the device itself for storage in discovered device database 435. For example, with reference to FIG. 11 , device 552 may provide its bench-provisioned security credentials or information (e.g., keys, certificates, passwords, etc.) to network node manager 560 along with a request for network node manager 560's IP address 558.

[0115] Network node manager 432 may utilize device credentials and / or security information stored in discovered device database 435 to manage device security for individual devices and among multiple devices. For example, network node manager 432 may verify or validate the device credentials of a host device attempting to connect to node communication network L15, network node manager 432 may verify or validate the device credentials of a client device (e.g., in conjunction with querying the client device for the host device's IP address, e.g., pursuant to reference numeral 582), network node manager 432 may verify or validate device credentials in conjunction with polling the device for its status (e.g., reference numeral 578 in FIG. 11 ), etc. Additionally or alternatively, network node manager 432 may rely on security manager 440 to verify and / or validate device credentials and security information, for example, by asking security manager 440 to perform verification, validation, and other security tasks.

[0116] Of course, the client device and the host device may utilize the client device's and host device's respective security credentials or information to establish a communication session over the node communication network 402, such as in session establishment 588 shown in Figure 11. In addition to providing the client device and host device with their respective security credentials during, for example, bench provisioning, the security manager 440 may also manage their respective keys and verify certificates after provisioning, for example, when the device connects to the network 402 and / or while the device remains connected to the network 402. If a device fails to successfully verify or be successfully authenticated, the device may be quarantined and prevented from communicating with other nodes on the node communication network 402 until the device's security credentials and / or information are resolved, for example, manually.

[0117] Such security techniques advantageously allow for easy replacement of physical devices. For example, a physical replacement device need only be bench-provisioned with the security credentials provisioned on the device it is replacing. Thus, once a physical replacement device is identified within the process control system using the device tag and security credentials of the previous device, using the techniques described herein, the physical replacement device can be automatically configured with the same settings as the device it is replacing and can be plugged and played.

[0118] 12 depicts a block diagram of an example security architecture 600 illustrating at least some of the security techniques and / or aspects of a system for managing nodes of a node communication network of an industrial process plant or automation system, such as those security techniques and / or aspects described elsewhere herein. Security architecture 600 may be utilized with devices and / or nodes of system 400 of FIG. 9 or other suitable systems. For example, security architecture 600 may be utilized to secure high-versatility field device 10 of FIG. 1 and / or in conjunction with or in concert with any one or more of the security features discussed above with respect to FIG. 8. However, for ease of explanation, and not for purposes of limitation, architecture 600 will be described with simultaneous reference to the security features of FIG. 8 and system 400 of FIG. 9.

[0119] 12 , architecture 600 includes a security manager 605 that can communicate with a host device 608 and a client device 610 for security purposes. In one exemplary implementation, security manager 605 is an embodiment of security manager 440 of FIG. 9 , host device 608 is an embodiment of one of devices or systems 10, D1-Dn, 418, 422, 425, 428, and client device 610 is an embodiment of another of devices or systems 10, D1-Dn, 418, 422, 425, 428. In the example illustrated in FIG. 12 , client device 610 is a consumer of data generated or created by host device 608 while devices 608, 610 are operating during runtime operation of an industrial process plant or automation network. For example, host device 608 may be field device 552 of FIG. 11 , and client device 610 may be controller 580 of FIG. 11 .

[0120] The security manager 605 includes a provisioning engine 612 that generates or otherwise determines security credentials for each of the devices of the industrial process plant or automation system that will connect to the node communications network 402 during bench provisioning of such devices, e.g., when such devices have not yet been powered up for runtime operation within the industrial process plant or automation system, and while such devices are not yet connected to the network 402. The provisioning engine 612 records or stores the provisioned credentials of such devices in a credential data store 615. Typically, bench provisioning occurs when such devices are located on-site in the process plant or automation system, although bench provisioning may occur at any time prior to powering up such devices for the purpose of connecting to the node communications network 402, such as when such devices are located in a manufacturing plant, a staging site, etc.

[0121] The provisioning engine 612 works in conjunction with a bench provisioning application 618, which may be provided through a user interface of the security manager 605 and / or may be otherwise exposed or provided to the user interface of other devices (e.g., handheld computing devices or other types of tools) utilized to manage provisioning. For example, the security manager 605 may download instances of the bench provisioning application 618 to various user-operated computing devices or tools, the security manager 605 may host bench provisioning as a service accessible to various user-operated computing devices or tools, etc. Generally speaking, the bench provisioning application 615 provides user access to the security manager 605 to define, generate, view, and manage device security credentials and / or perform other tasks related to provisioning security credentials to devices.

[0122] Security manager 605 further includes a credential management engine 620 that typically manages security credentials for devices while they attempt to connect to network 402 and during runtime operation of the industrial process plant or automation system. For example, credential management engine 620 may authenticate or validate various devices, provide keys to various requesting devices, validate certificates, etc. In this manner, credential management engine 620 may access credential data store 615. Typically, although not necessarily, credential management engine 620 operates automatically, e.g., without user input.

[0123] In one embodiment, the provisioning engine 612, the bench provisioning application 618, and the credential management engine 620 each include a respective set of computer-executable instructions stored in one or more memories of the security manager 605 and executable by one or more processors of the security manager 605 to perform the respective tasks and / or functions of the security manager 605.

[0124] The host device 608 stores, in one or more of its memories, one or more routines or applications 622 that, when executed by one or more processors of the host device 608, enable the host device 608 to communicate with the security manager 605. Similarly, the client device 610 stores, in one or more of its memories, one or more routines or applications 625 that, when executed by one or more processors of the client device 610, enable the client device 610 to communicate with the security manager 605. For example, the host device 608 may include a provisioning routine 622a that obtains, from the provisioning engine 612, device identification information (e.g., the host device's 608's device tag, any associated data tags, etc.) and associated security credentials for the host device 608, such as during bench provisioning of the host device 608. The information obtained by the provisioning routine 622a is stored in one or more memories (not shown in FIG. 12 ) of the host device 608. In an exemplary implementation in which the host device 608 is a highly versatile field device such as the highly versatile field device 10, the provisioning routine 622a may include the device provisioning functionality 314, and the obtained device identification information and / or security credentials may be stored, for example, in the secure program storage 308.

[0125] Similarly, the client device 610 may include a provisioning routine 625a that obtains device identification information (e.g., device tag of the client device 610, any associated data tags, etc.) and associated security credentials of the client device 610, for example, during bench provisioning of the client device 610. Additionally, the provisioning routine 625a of the client device 610 may also obtain device identification information (e.g., device tag, associated data tags, etc.) of each of any host devices that produce runtime data that the client device 610 consumes and manipulates during runtime, including the host device 608. The information obtained by the provisioning routine 620a is stored in one or more memories (not shown) of the client device 610.

[0126] At times other than during provisioning, for example, during the process of connecting to the node communication network 402 and / or while connected to the node communication network 402, the host device 608 may execute a routine 622b that causes the host device 608 to request a key (e.g., a private key, a public key, etc.) from the credential management engine 620 of the security manager 605. For example, the key request routine 622b may be included in the secure communication function 312. Similarly, the client device 610 may execute a key request routine 625b that causes the client device 610 to request a key (e.g., a private key, a public key, etc.) from the credential management engine 620. Additionally, during the process of connecting to the network 402, and while connected to the network 402, for authentication, verification, validation, and / or other types of credential evaluation, each of the host device 608 and the client device 610 may interface with the credential management engine 620 of the security manager 605 and execute respective credential evaluation routines 622c, 625c to accomplish the same, e.g., by accessing stored credentials 615. For example, at least some device security routines or applications 612b, 612c, 620a, 620c may be executed when the host device 608 and the client device 610 execute their respective joining routines 628, 630 to securely join the node communication network 402, respectively, thereby enabling the establishment of a communication path or even a communication session 632. 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 FIG. 8 to establish the secure communication session 632.

[0127] 12, the host device 608 applications or routines 622a, 622b, 622c, 628 are illustrated as separate and distinct applications or routines, but this is for clarity of discussion only. In fact, the functionality of the host device applications / routines 622a, 622b, 622c, 628 may be implemented using fewer or more separate and distinct applications or routines. Similarly, the functionality of the client device applications / routines 625a, 625b, 625c, 630 may be implemented using fewer or more separate and distinct applications or routines, and the various functionalities provided by the security managers 612, 615, 620 may be implemented using fewer or more separate and distinct engines, applications, or routines.

[0128] 13 , in some embodiments, the node communication network 402 may include multiple network node managers 432, at least some of which may be redundant and function as backup network node managers, and / or at least some of which may be distributed in nature. For example, FIG. 13 illustrates the configuration of an exemplary system 650 for managing nodes of a node communication network of an industrial process control or automation system, where the system 650 includes multiple distributed network node managers 652, 655, 658. The system 650 may be one embodiment of the system 400 and is discussed herein with simultaneous reference to FIG. 9 for clarity of explanation. However, it should be understood that other systems for managing nodes of a node communication network of an industrial process control or automation system may readily incorporate multiple redundant and / or distributed network node managers 652-658 using the principles and techniques described herein.

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

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

[0131] Network Resource Management Although the node communication network 80 of the plant 100 is highly flexible, in part because the node communication network 80 uses an IP-based network, implementing an IP-based network in a process or factory automation control environment requires consideration of factors that may be of concern in typical or traditional process or factory automation control networks. For example, the self-routing nature of IP-based networks means that without proper management, the network will behave differently and / or unpredictably under normal, overload, and failure scenarios. As an example, under high load and contention scenarios, IP-based networks may drop or delay packets. When packets are delayed or dropped, the performance of monitoring and control applications will be adversely affected by the resulting delay and jitter. Therefore, when implementing network designs 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 various network conditions. Specifically, it is important to provide the quality of service (QoS) necessary to support both existing and new application requirements while also supporting a combination of traditional field devices 224, traditional I / O devices 222, and highly versatile field devices 82.

[0132] It is also important that an IP-based network be configurable to support various topologies. For example, the node communication network 80 should support a traditional factory automation or process automation topology, such as that depicted in FIG. 3 , including both high-versatility field devices 82 and traditional field devices 224 coupled to the APL network architecture 892 by adapter devices 130. The communication network 80 should support an edge topology, such as that depicted in FIG. 4 , that operates on top of or in parallel with the traditional factory or process automation topology, supporting planning information integration such as scheduling, asset monitoring, analysis, simulation, and other functions. That is, the communication network 80 should be configurable to facilitate communication between, on the one hand, the high-versatility field devices 82 and / or traditional field devices 224 (via the adapter devices 130) and, on the other hand, various applications, including cloud-based client applications 182, via one or more edge gateways 166, as described above. Additionally, the communications network 80 should support a cloud topology that can operate in parallel with automation instrumentation, such as that depicted in Figure 5, and that can be used, for example, for condition-based monitoring (e.g., energy monitoring, equipment and device monitoring, and process monitoring). In such a system, as described above, the monitoring system may send data from the plant 100 to one or more cloud-based applications 182, which perform analysis and transmit data and / or recommendations back to users and / or elements of the process control network 200, such as the controller 140.

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

[0134] Whether implemented in a traditional or flat networking environment, the communications network 80 must be configured to take into account time sensitivity because some data flowing from the high-versatility field devices 82 and the traditional field devices 224 to the various applications and devices of the process control network 200 is more time-sensitive than other data. For example, some control modules (i.e., control routines or portions of control routines) operating in the controller 140 may require certain data much more frequently than other control modules and / or more frequently than condition monitoring applications that are not performing real-time control of the process. Therefore, it is important that the communications network 80 prioritizes time-critical and time-sensitive data over delay-insensitive data while supporting the transmission of various data types to and from the various devices and applications.

[0135] As described above with reference to Figures 3-7, communication network 80 is implemented as an IP-based network using APL network architecture 892, which includes APL power switches 84 and APL field switches 86 coupled by an APL bus 88 (e.g., Ethernet) to each other and to various high-versatility field devices 82, adapter device 130, controller 140, workstations 206, 145, 202, 204, edge gateway 166, and / or cloud 168 (e.g., via firewall device 162). APL power switches 84 and APL field switches 86 facilitate communication of data to and from field devices 82 and 224 and to and from various applications. In some embodiments, APL power and field switches 84 and 86 may cooperate with various other switches (e.g., the L2 switches depicted in Figure 3) to facilitate communication of data from a source to a destination.

[0136] Also, as described above, in addition to facilitating communication between field instrumentation and applications, the communication network 80 supports both client / server and publish / subscribe communications, enabling internet connectivity between Open Platform Communication (OPC) Unified Architecture (UA) servers (e.g., field instrumentation) and OPC UA clients (e.g., controllers), each of which may be clients or servers in various instances. The communication network 80 supports both User Datagram Protocol (UDP) and Transmission Control Protocol (TCP) communication modes. In a client / server communication session, directed communication occurs between a host and a single, specific device. The addresses of the source and destination devices are unique and unambiguous, and every client / server request specifies both the request data and the response data to be communicated. In contrast, in publish / subscribe communications, new values ​​(e.g., measurements, status values, etc.) are sent from a server (e.g., a device) only as frequently as needed. For example, with respect to parameters exposed from a highly versatile field device 82 to the controller 140, the parameters may be transmitted as frequently as necessary to allow control action to correct for unmeasured disturbances or responses to set point changes.

[0137] The communications network 80 is configured to support a variety of use cases in cooperation with the high-versatility field devices 82. Of course, the primary use case is the control use case, enabling the high-versatility field devices 82 and the legacy field devices 224 to communicate with the controller 140 (in the latter case via the adapter device 130) and / or with the operator station 206 to facilitate control of the process plant 100. While in traditional process plant communication networks, the field devices communicate only with their respective controllers, and the operator station both receives necessary parameter data from the controller and transmits new setpoint data to the field devices via the controller, the communications network 80 may be configured to facilitate communication directly between the operator station 206 and the high-versatility field devices 82 and the legacy field devices 224. Specifically, the communications network 80 is configurable to allow a particular field device to simultaneously expose parameter data to multiple consumers of that data. Thus, a valve, for example, may expose parameter data to both the controller 140 and the operator station 206, which can conserve bandwidth by eliminating repeated transmissions of data. That is, a single transmission can communicate data to both the controller 140 and the operator station 206 without requiring a second transmission of data from the controller 140 to the operator station 206, as is typical in conventional control networks.

[0138] The communications network 80 can also improve plant asset management (PAM), including device configuration. PAM systems are used to configure and provision devices, perform diagnostics on deployed devices, monitor device alerts, and for other functions. For example, the PAM system may receive condition monitoring data from field devices 82 and / or 224 to determine when a device is malfunctioning, needs calibration, etc.

[0139] Industrial Internet of Things (IoT) platforms can also benefit from implementations of the communications network 80 as described herein. Industrial IoT platforms for continuous condition monitoring may be deployed to monitor a wide range of parameters within the process plant 100. Such systems may monitor functions such as energy consumption, equipment and device functionality / performance, and process performance, among other items. Such systems typically operate using various parameters collected from an array of devices throughout the process plant 100 as inputs. In conventional systems, Industrial IoT platforms that perform continuous monitoring receive data indirectly from field devices through the controller 140 and / or one or more other devices, such as the operator station 206 and plant asset management devices 145. However, in the systems described herein, these Industrial IoT platforms may receive data directly from the devices that are the source of the data, either by direct request or using publish / subscribe (i.e., by subscribing to the data), without requiring programming of intermediate devices to relay the data.

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

[0141] As will be appreciated, implementing both traditional monitoring and control data and other non-traditional data, such as those described in the use cases above, on the same network can introduce problems such as latency and dropped packets that are not present in traditional control networks that communicate data only between individual devices and a controller, whereas transmission of such data is scheduled, specifically requested by the controller, or otherwise tightly controlled to be prioritized so that latency-sensitive data is received in a timely manner from the device to the controller (or from the controller to the device). One challenge is accommodating both scheduled network traffic (e.g., monitoring and control data sent between field devices and controllers) and unscheduled traffic (e.g., condition monitoring and other data sent between and among devices and applications) on the same network.

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

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

[0144] The network resource management component 800 may be implemented either with or without time-sensitive networking (TSN), each of which is described below.

[0145] TSN-based network management TSN-based network management involves managing TSN-based network resources (e.g., devices and applications) while allowing non-TSN resources to access the same network. That is, TSN-based network management facilitates the communication of both managed and unmanaged network traffic. As part of this networking scheme, TSN network devices and applications must be priority-aware, and network resources must be allocated in a manner that allows time-critical data to be transmitted with minimal blocking as the data travels from source to destination.

[0146] The TSN-based network resource management component 800 prioritizes data transmission according to rules and traffic types. For example, in some implementations, priorities are assigned based on default traffic types generally associated with TSN-based networks, as shown in Table 1. [Table 1]

[0147] However, when implemented in a factory automation or process control plant (e.g., plant 100), priorities need not be assigned based on the same types of traffic that may be present on an average network. Instead, by way of example, and not limitation, priorities may be assigned based on the particular types of network traffic that may be present in a factory automation or process control environment. Table 2 is an exemplary list of traffic types and priorities, although it can be appreciated that the traffic types associated with each of the priorities may be assigned according to the needs of the system operator. [Table 2]

[0148] Referring to Table 2, some data used by a factory automation controller or process controller may be more time-sensitive than other data. As those familiar with such automation processes will understand, such data may be more time-sensitive because it is part of a frequently executed control loop, or where small changes can have an outsized impact very quickly, or because the data is part of a safety system that must respond quickly to an event, for example, to prevent or mitigate a dangerous situation. Other data used by the controller may be somewhat less sensitive to increased delays, for example, because it is part of a control loop that runs less frequently, or with respect to a process that does not exhibit sudden changes in response to small disturbances.

[0149] In any event, various types of data within plant 100 may be assigned different priority levels within the TSN-based networking scheme implemented by network resource management component 800. Prioritization of data according to the network scheme is performed at outbound ports 818 of TSN-based devices, such as high-versatility field device 82, adapter device 130, APL power switch 84, and APL field switch 86. Of course, any TSN-based device that transmits data may have a corresponding outbound port 818.

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

[0151] In any event, each of the queues 822A-822N has an associated transmission selection algorithm 824A-824N that operates to select which data to retrieve from the corresponding queue 822A-822N. A plurality of gates 826A-826N, each associated with a corresponding one of the queues 822A-822N, determines whether the data selected by the respective transmission selection algorithm 824A-824N can be transmitted. An open one of the gates 826A-826N allows the data selected by the respective transmission selection algorithm 824A-824N to be transmitted from the respective one of the queues 822A-822N, while a closed one of the various gates 826A-826N prevents the data from being transmitted. A gate control list 828 determines which of the plurality of gates 826A-826N are open at any given time. The transmission selection unit 830 selects which data provided and / or available from the open gates 826A-826N is transmitted from the data output 832 by selecting the highest available priority frame for transmission. As a result of this arrangement, even though the transmission selection algorithms 824A-824N determine the order in which data is transmitted from their respective queues 824A-824N, the gates 826A-826N may effectively block transmission in favor of data other than the data with the highest assigned priority. Thus, the gates 826A-826N are important for properly handling traffic to result in the proper transmission of time-sensitive scheduled traffic. As described, each of the gates 826A-826N can be either open or closed. Multiple gates of the gates 826A-826N may be open (or closed) at any given time.

[0152] Of course, controlling gates 826A-826N to ensure highly predictable delivery of data in a real-time system while accounting for delays and jitter during transmission through the various switches between devices requires knowledge of the network topology, knowledge of the devices and applications that send and receive 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.

[0153] To this end, network resource management component 800 may include a routing information component 802 that determines and / or stores information regarding network topology and the routing of data from one point to any other point within the network. For example, routing information component 802 may store data indicating that a particular network switch (e.g., one of APL field switches 86) is connected to a particular upstream device (e.g., a particular APL power switch 84) and downstream device (e.g., high-versatility field device 82). By having “knowledge” of the network topology, routing information component 802 enables network resource management component 818 to estimate network delays between any two devices and / or applications sending traffic over the network and to predictably schedule periodic traffic.

[0154] The key to mapping the network topology is understanding what devices exist on the communications network 80. The device registration component 804 may implement this functionality, as described above with respect to device discovery. By implementing the device registration component 804, all discovered devices are recognized by the network resource management component 800, and may also implement a DHCP server and / or DNS server for registering devices.

[0155] Network resource management component 800 may have routines or data for obtaining and / or storing network scheduling information 806, which may be received from or programmed by various of controller 140 and / or workstations regarding timing requirements for various data transmitted over communications network 80. In embodiments, a portion of network scheduling information 806 is obtained directly from a configuration file that programs controller 140 (e.g., from control loop timing requirements specified in the configuration file). In embodiments, a portion of network scheduling information 806 is determined according to publish-subscribe requests established between particular devices, as described herein. That is, as each publishing device (e.g., high-versatility field device 82) establishes a subscription with another device or application, each publishing device may update network scheduling information 806 so that network resource management component 800 can allocate network resources appropriately.

[0156] Network resource allocation information 808 may store various data associated with the allocation of network resources, including associations between types of data and assigned priority levels, as well as information such as specific time slots reserved for particular data priorities, specific scheduled data transmissions, and may include bandwidth allocations for unscheduled traffic (e.g., request-response traffic).

[0157] The time-aware shaper 810 may utilize the network resource allocation information 808, the routing information 802, and the network scheduling information 806 to configure and synchronize the gate control list 828 to meet the real-time requirements of the communication network 80 and the various devices and applications on the communication network 80. In the plant 100, control data is often transmitted on a recurring time schedule, so it is possible to have knowledge of when a particular transmission will occur. However, as should be understood, prioritizing data does not, in itself, ensure that the data can be transmitted at the appropriate time, because other, lower priority data may already be transmitting over the communication network 80 when the scheduled data is ready for transmission. If the lower priority transmission already in progress is large, it will necessarily have to finish before the other can be transmitted, thereby delaying the scheduled data.

[0158] Here, the gate control list 828 is depicted in the image. Each gate control list 828 establishes or results in a repeating pattern of open and closed gates at its associated outbound port 818. By synchronizing the gate control list 828 for each outbound port 818 and programming them accordingly, a clear transmission path for scheduled data may be created at the appropriate time. That is, each of the outbound ports 818 must have a synchronized clock so that each gate 826A-826N of the outbound port 818 can be opened and / or closed at precisely the correct time to facilitate ultra-low latency data transmission. In an embodiment, the TSN-based network resource management component 800 synchronizes the clocks associated with the various outbound ports 818 using the Precision Time Protocol (PTP). The time-aware shaper 810 may manage the gate control list 828A-828N to precisely time the opening and closing of gates 826A-826N at each of the outbound ports 818, taking into account network topology, routing information for each scheduled transmission, delays incurred as data traverses various switches, network scheduling information, and network resource allocation information, so that the appropriate gates of gates 826A-826N are opened and closed at exactly the correct times and intervals.

[0159] 16 is a diagram of an example data flow 834 illustrating this concept. In the example data flow 834, two different endpoint systems 840 and 842 transmit respective data frames 836 and 838 to a third endpoint system 844 via a network switch 846. Each of the endpoint systems 840, 842, and 844 may be a device or application within the plant 100. By way of example, and without limitation, the endpoint systems 840 and 842 may each be a highly versatile field device 82 transmitting parameter data to the endpoint system 844, which may be a controller 140. In another example, the endpoint systems 840 and 842 may each be a highly versatile field device 82 transmitting health status data to the endpoint system 844, which may be a plant asset management device 145 running an asset management system (AMS). In general, each of endpoint systems 840, 842, 844 may be any device communicating over node communication network 80, and may include devices where data frames 836 and 838 are scheduled or unscheduled traffic transmitted according to a publish-subscribe protocol, a request-response protocol, or based on some other criteria.

[0160] In exemplary data flow 834, two data frames 836 and 838 are transmitted simultaneously from respective endpoint systems 840 and 842 to endpoint system 844. Between respective 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 is depicted in exemplary data flow 834 as an outbound port 818 with its respective corresponding element. Of course, it should be understood that the devices and systems described herein, including high-versatility field device 82, APL power switch 84, APL field switch 86, and other devices, may each have multiple outbound ports 818. Returning to FIG. 16 , when both data frames 836 and 838 arrive at network switch 846, both data frames 836 and 838 are put into corresponding queues 894A and 894B of network switch 846, where they are considered to have arrived simultaneously. When data frames 836 and 838 are transmitted from network switch 846, data frame 836 will be transmitted before data frame 838 because data frame 836 has a higher priority than data frame 838.

[0161] 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 their respective priority levels or respective data types. Queue selection unit 820 places data from each data frame 836 and 838 into respective queues 894A and 894B. Transmit selection algorithm 824 may select data from each of data frames 836 and 838 for transmission, and assuming both transmit gates 826 of respective queues 894A and 894B are open, transmit selection routine 830 may select the highest priority data for transmission, i.e., data from data frame 836, before selecting data from data frame 838 for transmission.

[0162] Modifying this 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, network resource management component 800 may nevertheless facilitate data frame 836 arriving earlier than data frame 838, e.g., if data frame 836 is scheduled network traffic while data frame 838 is unscheduled network traffic. For example, data frame 836 may contain data from a high-versatility field device 104 that is low priority but expected at a particular time by controller 140. In this case, network resource management component 800 may configure communication network 80 such that data frame 836 arrives at endpoint system 844 (e.g., controller 140) before the higher priority data frame 838. The network resource management component 800 may configure, via the time-aware shaper 810, the gate control list 828 for the various outbound ports 818 such that a clear data transmission path is created for the data frame 836, while one or more of the transmission gates 826 along the data path of the data frame 838 (e.g., the transmission gate 826 corresponding to queue 894B of the network switch 846) remains closed to block transmission of the data frame 838 until transmission of the data frame 836 is complete.

[0163] As will be appreciated, a network configuration component (NCC) 816 of the network resource management component 800 may discover devices (e.g., in cooperation with the device registration component 804) and determine the topology of the communication network 80. The NCC 816 may be centralized or distributed. In either case, the NCC may receive a request to discover the physical topology of the communication network 80 (or a portion of the communication network 80) and, in response, may 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 may cooperate with the device registration component 804 to determine the connectivity of each new device that registers via the device registration component 804, thereby determining the topology of the network 80.

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

[0165] The user configuration component (UCC) 812 may be responsible for managing various end stations (e.g., high-versatility field devices 82, adapter devices 130, workstations and applications, etc.). The UCC 812 requests scheduled flows of network traffic by making requests to the NCC 816. The requests provide specific requirements for those scheduled flows of network traffic by specifying the endpoint devices (sender and receiver) for each flow and specific timing requirements (e.g., how often the flow occurs, the size of the data payload, the extent to which the data payload is time-sensitive, the order of the sequence, etc.).

[0166] The NCC 816 may communicate with the UCC 812 to receive communication requirements for the various traffic flows that will be present on the network 80, determine routes for each traffic flow, and schedule the transmission of each traffic flow. Scheduling the transmission of each traffic flow may include using the time-aware shaper 810 to create and manage gate control lists 828 for each of the switches and routers controlled by the NCC 816. The NCC 816 then communicates the necessary scheduling data to each of the switches and routers that it controls.

[0167] Non-TSN-based network management In embodiments in which the network resource management component 800 is not based on a time-sensitive networking (TSN) protocol, it may manage network traffic by controlling traffic flow through network switches (e.g., APL power switches 84 and APL field switches 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 coordinates network traffic flow between various devices in the network 80, particularly within the network switches. Devices and hosts communicate with the network manager 814 to allocate traffic, for example, by requesting publish-subscribe traffic flows. The network manager 814 would then control traffic through the switch by enabling and disabling various ports of the switch and throttling network traffic through the ports. In such embodiments, network traffic may be identified, for example, by the traffic's source (i.e., sender), destination (i.e., receiver), and application type.

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

[0169] At some point after each of the devices joins the network 80, the various devices may request the network manager 814 to negotiate bandwidth. For example, the devices may negotiate with the network manager 814 about publish-subscribe bandwidth between particular devices (e.g., between one of the high-versatility field devices 82 and the controller 140, or between one of the high-versatility field devices 82, the controller 140, and the operator station 206). If the network manager 814 approves the request, the devices may begin publishing data to hosts subscribed to the data.

[0170] Network manager 814 may allocate a certain portion or percentage of bandwidth on 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. Network manager 814 may monitor traffic flow through network 80 and adjust switches when the percentage of unmanaged traffic exceeds the allocated amount.

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

[0172] Public Suite In part, because the node communication network 80 supports both publish-subscribe and request-response traffic between any devices on the communication network 80, and in part, because each of the high-versatility field devices 82 and adapter devices 130 may publish data from and subscribe to data from multiple devices, the high-versatility field devices 82 and node communication network 80 support a wide range of use cases, including monitoring and control, plant asset management, condition monitoring, data logging, secure plant metering, environmental monitoring, etc., as described above. Also, as described above, any particular high-versatility field device 82 or adapter device 130 may connect to multiple application types. For example, one of the high-versatility field devices 82 may support secure connections for monitoring and control and condition monitoring, while the connections may be completely separate and support different workloads with separate applications each subscribing to different data sets available from the high-versatility field device 82, and therefore the published lists of parameters sent from the high-versatility field device 82 to each respective application will be different. As a result of these new capabilities in devices and applications, simplifying the publish-subscribe initiation protocol becomes desirable.

[0173] As will be appreciated, each device or application may have various parameters or other data available for exposure to other devices or applications on the communications network 80. As an example, a valve may have both monitoring and control parameters (e.g., current set point, valve temperature, etc.) and condition monitoring parameters (e.g., valve travel, valve actuation, valve pressure, cycle count, etc.). Different types of available parameters may be of interest to different applications within the process plant 100. For example, monitoring and control parameters may be required by an associated controller 140 to implement a control loop that controls a process, while condition monitoring parameters may be required by the plant asset management device 145 to monitor the condition of devices within the process plant 100 and determine when maintenance is needed, when a device is about to fail, when a device is out of calibration, etc.

[0174] To that end, devices (and possibly applications) operating on the communications network 80 may have predefined lists of parameters and other data available for subscription. FIG. 17 illustrates an exemplary server 848 (e.g., a high-versatility field device 82, an application, a controller 140, etc.) and an exemplary application 874 (e.g., another high-versatility field device 82, a controller 140, or another application). While FIG. 17 illustrates the server as a high-versatility field device and, as a result, depicts various elements that may not be present in the controller (e.g., a sensor) or in the application (e.g., a sensor, communication circuitry, etc.), the general concept illustrated in FIG. 17 relates to a set of published lists 858 stored on the server 848. Specifically, turning to FIG. 17, the server 848 (e.g., a high-versatility field device 82) includes one or more sensors 851 (e.g., a temperature sensor, a position sensor, a pressure sensor, a flow sensor, etc.). The sensors 851 monitor data from the sensors, store the data from the sensors, and transmit the data to a processor 852, which may execute process control modules to implement portions of a control strategy and / or transmit the data to one or more other devices (e.g., controllers) or applications. The server 848 includes communications circuitry 854 for facilitating communication with various devices and applications over the communications network 80. The server 848 also includes a memory device 850, which may include parameter storage 856 for storing various parameters of the server 848 (e.g., data from sensors, published subscriptions, etc.). The server 848 also includes various published lists 858 within the memory 850, at least some of which are predefined and determined by the device or application manufacturer.

[0175] Thus, the memory 850 of the server 848 includes one or more manufacturer-defined public lists 860. Each of the manufacturer-defined public lists 860 may include parameters typically transmitted from the server 848 for a particular application. For example, a first one of the manufacturer-defined public lists 860 may include device parameters related to controlling a process. If the server 848 is a valve, the manufacturer-defined public list 860 may be a monitoring and control public list 868 and may include valve setpoint, valve temperature, and upstream and downstream flow rates and / or pressures. If the server 848 is a level transmitter, the monitoring and control public list 868 may include levels. Meanwhile, a second one of the manufacturer-defined public lists 860 may be a condition monitoring public 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 public list 870 may include parameters such as valve travel, valve actuation, valve pressure, and cycle count.

[0176] Server 848 includes at least one predefined public list 858 defined by the manufacturer as a manufacturer-defined public list 860. In embodiments, manufacturer-defined public list 860 includes multiple public lists. In embodiments, at least one of manufacturer-defined public lists 860 is a monitor and control public list 868. In embodiments, at least one of manufacturer-defined public lists 860 is a status monitoring public list 870. In embodiments, manufacturer-defined public lists include both a monitor and control public list 868 and a status monitoring public list 870, and may indeed include multiple monitor and control public lists 868 and / or multiple status monitoring public lists 870. In some embodiments, manufacturer-defined public list 860 may also include one or more public lists defined for applications other than monitor and control or status monitoring.

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

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

[0179] In an embodiment, each of the public lists 858 includes associated public list metadata 872. The public 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 public list category (e.g., control, status monitoring, etc.), a public list name (e.g., "MfgControlList"), and a list of parameters included in the public list. In such an embodiment, the metadata 872 may be transmitted by the server 848 to clients 874 that request to subscribe to data from the server 848, as described in more detail below.

[0180] As described throughout, the client 874 may be a high-versatility field device 82, an adapter device 130, or an application on the communication network 80 that subscribes to a published data source. For example, the client 874 may be the controller 862, another high-versatility field device 82 or an adapter device 130, an application 874A on the operator station 206, an application 874B on the application station 204, an application 874C on the engineering station 202, a cloud-based application 874D, an application that accesses the communication network 80 via the edge gateway 166, etc.

[0181] Each of the public lists 858 may be defined to have information about the device type, manufacturer, and device revision, device address, tag, public list category, public list name, information about the version, and information about the parameters that are part of the public list. For example, the public data of a typical monitoring and control public list 868 may look like this: [ { “ExpandedDeviceTypeCode”:4875, “ExpandedDeviceTypeString”:”DVC6000 HW2”, “ManufacturerCode”:19, “ManufacturerString”:”Fisher Controls”, “DeviceRevision”:2, “publishedData”:[ { “deviceAddr”:”0x0000000020”, “deviceTag”:”FC-101”, “publishCategory”:”Control”, “publishList”:”MfgsControlList”, “version”:”1”, “response”:”Success”, “fieldDeviceStatus”:0, “parameters”:[ { “deviceVariableCode”:”PV”, “deviceVariableClassification”:0, “valueType”:”float”, “value”:7.05, “status”:”Good-NotLimited”, “units”:”“, “timestamp”:”2020-05-01T14:33:02” }, { “deviceVariableCode”:”SV”, “deviceVariableClassification”:0, “valueType”:”float”, “value”:24.25601, “status”:”Good-NotLimited”, “units”:”“, “timestamp”:”2020-05-01T14:33:02” } ] } ] } ] Meanwhile, the public data of a typical status monitoring public list 870 may be as follows: [ { “ExpandedDeviceTypeCode”:4875, “ExpandedDeviceTypeString”:”DVC6000 HW2”, “ManufacturerCode”:19, “ManufacturerString”:”Fisher Controls”, “DeviceRevision”:2, “publishedData”:[ { “deviceAddr”:”0x0000000020”, “deviceTag”:”FC-101”, “publishCategory”:”ConditionMonitoring”, “publishList”:”MfgsConditionMonitoringList”, “version”:”1”, “response”:”Success”, “fieldDeviceStatus”:0, “parameters”:[ { “deviceVariableCode”:”Travel”, “deviceVariableClassification”:0, “valueType”:”float”, “value”:50.1464844, “status”:”Good-NotLimited”, “units”:”“, “timestamp”:”2020-05-01T14:33:02” }, { “deviceVariableCode”:”Drive”, “deviceVariableClassification”:0, “valueType”:”float”, “value”:75.31738, “status”:”Good-NotLimited”, “units”:”“, “timestamp”:”2020-05-01T14:33:02” }, { “deviceVariableCode”:”PressureA”, “deviceVariableClassification”:0, “valueType”:”float”, “value”:21.03125, “status”:”Good-NotLimited”, “units”:”“, “timestamp”:”2020-05-01T14:33:02” }, { “deviceVariableCode”:”PressureB”, “deviceVariableClassification”:0, “valueType”:”float”, “value”:-0.097656, “status”:”Good-NotLimited”, “units”:”“, “timestamp”:”2020-05-01T14:33:02” }, { “deviceVariableCode”:”CycleCount”, “deviceVariableClassification”:0, “valueType”:”float”, “value”:3439080.0, “status”:”Good-NotLimited”, “units”:”“, “timestamp”:”2020-05-01T14:33:02” } ] } ] } ]

[0182] The public list 858 may be defined in a similar manner, including information about the device, information about the type of public list, and various parameters of the public list 858. Public lists may be defined individually or by group. The following example shows how the two public list outputs above may be defined by group. [ { “ExpandedDeviceTypeCode”:4875, “ExpandedDeviceTypeString”:”DVC6000 HW2”, “ManufacturerCode”:19, “ManufacturerString”:”Fisher Controls”, “DeviceRevision”:2, “publishLists”:[ { “publishCategory”:”Control”, “publishList”:”MfgsControlList”, “version”:”1”, “parameters”:[ { “deviceVariableCode”:”PV”, “deviceVariableClassification”:0, “valueType”:”float”, “value”:0.0, “status”:”“, “units”:”“, “timestamp”:”“ }, { “deviceVariableCode”:”SV”, “deviceVariableClassification”:0, “valueType”:”float”, “value”:0.0, “status”:”“, “units”:”“, “timestamp”:”“ } ] }, { “publishCategory”:”ConditionMonitoring”, “publishList”:”MfgsConditionMonitoringList”, “version”:”1”, “parameters”:[ { “deviceVariableCode”:”Travel”, “deviceVariableClassification”:0, “valueType”:”float”, “value”:0.0, “status”:”“, “units”:”“, “timestamp”:”“ }, { “deviceVariableCode”:”Drive”, “deviceVariableClassification”:0, “valueType”:”float”, “value”:0.0, “status”:”“, “units”:”“, “timestamp”:”2020-05-01T14:33:02” }, { “deviceVariableCode”:”PressureA”, “deviceVariableClassification”:0, “valueType”:”float”, “value”:0.0, “status”:”“, “units”:”“, “timestamp”:”“ }, { “deviceVariableCode”:”CycleCount”, “deviceVariableClassification”:0, “valueType”:”float”, “value”:0.0, “status”:”“, “units”:”“, “timestamp”:”“ } ] } ] } ]

[0183] When a client 874 wishes to subscribe to a server 848, the client discovers and selects a particular publication list from among the available publication lists 858 for the server during the initial handshake between the client 874 and the server 848. FIG. 18 depicts an example communication flow diagram 876 of the initial handshake interaction between a client 878 and a server 880. The client 878 initiates a publish-subscribe session by sending an initial "hello" message 882 to the server 880. In an embodiment, the initial "hello" message includes an indication of the publication list category (e.g., monitoring and control, status monitoring, etc.). In response to the initial "hello" message 882, the server 880 replies with its own "hello" message 884. In an embodiment, the server's "hello" message 884 includes an indication of the publication list 858 within the category indicated by the client 878. In some embodiments, the representation of the public lists 858 transmitted by the server 880 includes metadata 872 for each of the public lists 858 in the category indicated by the client 878, while in other embodiments, the representation of the public lists 858 transmitted by the server 880 includes public list definitions for the public lists 858 in the category indicated by the client 878.

[0184] 18 as occurring over two messages 882 and 884, the initial exchange of messages may occur over three or more messages in alternative embodiments. For example, although perhaps less efficiently, client 878 could send a "hello" message to server 880, and in response, server 880 could confirm the presence of client 878 with its own "hello" message. Client 878 could respond to the acknowledgment sent by server 880 by sending a request for publication lists in a particular publication list category. In response to that request, server 880 could send an indication of the publication lists 858 that are available in the specified publication list category. Of course, other communication configurations are possible and contemplated as well.

[0185] In response to an indication from the server 880 of available public lists 858 within a public list category indicated by the client 878, the client 878 may send a message 886 back to the server 880 requesting a specific one of the indicated public lists. In embodiments, the client 878 may include in the message a requested update rate indicating how often the client 878 would like to receive updated values ​​of the parameters of the selected public list. In some embodiments, the definition of the public list 858 may include a default update rate, and the server 880 may publish the parameters of the selected public 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 may send a message 888 acknowledging the request for the selected public list 858 and confirming an active subscription to the selected public list. The server 880 may then publish encrypted data 890 to the client 878, the data corresponding to the subscribed public list and transmitted at the agreed-upon update rate.

[0186] If implemented in software, any of the applications, modules, etc. described herein may be stored in any tangible, non-transitory computer-readable memory, such as a magnetic disk, laser disk, solid-state storage device, molecular memory storage device, or other storage medium, RAM, or ROM of a computer or processor. It should be noted that while the exemplary systems disclosed herein are disclosed as including software and / or firmware running on hardware, among other components, such systems are merely exemplary and should not be considered limiting. For example, it is contemplated that any or all of these hardware, software, and firmware components may be embodied exclusively in hardware, exclusively in software, or in any combination of hardware and software. Thus, while the exemplary systems described herein are described as implemented in software running on processors of one or more computing devices, those skilled in the art will readily appreciate that the provided examples are not the only way to implement such systems.

[0187] Thus, while the present invention has been described with reference to specific examples, it will be apparent to those skilled in the art that these examples are illustrative only and are not intended to be limitations of the invention, and that modifications, additions, or deletions may be made to the disclosed embodiments without departing from the spirit and scope of the invention.

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

Claims

1. A field device used in a manufacturing or industrial process to implement control actions used to control the manufacturing or industrial process pursuant to instructions of a process controller responsible for implementing the manufacturing or industrial process, comprising: a field device hardware component that interacts with a process phenomenon in the manufacturing or industrial process; a communication interface communicatively coupled to one or more external devices via an external communication network; a processor coupled to the field device hardware components and to the communication interface; a computer-readable memory coupled to the processor; an operating system stored in memory and implemented on said processor for implementing communications over said communications interface; a field device including one or more communication applications stored in the memory, executed on the processor, and managed by the operating system, the one or more communication applications implementing communication via the communication interface with a plurality of different external devices via a plurality of different communication processes, one of the plurality of different external devices being the process controller that controls the manufacturing or industrial process using the field device, and another of the external devices being an external device that does not control the manufacturing or industrial process with an external device other than the process controller.

2. 2. The field device of claim 1, wherein the operating system implements an Internet Protocol communication stack that packetizes messages to be sent via the communication interface and processes packetized messages received via the communication interface.

3. The field device of claim 2 , wherein the operating system implements a TCP communications stack.

4. 4. The field device of claim 2, wherein the operating system implements a UDP communication stack.

5. 5. The field device of claim 2, wherein the operating system implements a higher level protocol stack for each of the communication processes.

6. 6. The field device of claim 5, wherein the operating system implements a first higher level protocol stack of a first multilevel protocol stack associated with a first communication protocol for a first communication process of the communication processes, and a second higher level protocol stack of a second multilevel protocol stack associated with a second communication protocol for a second communication process of the communication processes.

7. The field device of claim 6 , wherein the first and second communication protocols are different communication protocols.

8. 8. The field device according to claim 6, wherein the first communication protocol is an OPC UA protocol or a HART-IP protocol.

9. 9. The field device according to claim 6, wherein the first communication protocol is a process control communication protocol, and the second communication protocol is a general-purpose communication protocol.

10. The field device of claim 1 further comprising a power supply.

11. The field device of claim 10 , wherein the power supply is coupled to the external communication network to receive power from the external communication network and to provide power to the processor.

12. The field device of claim 10 or claim 11, wherein the power source comprises a battery.

13. 13. The field device of claim 1, wherein the communication interface is adapted to be coupled to a wired external communication network.

14. The field device of claim 1 , wherein the communication interface is a wireless communication interface adapted to be coupled to a wireless external communication network.

15. The field device of claim 1 , wherein the field device hardware components include sensors that measure physical phenomena.

16. The field device of claim 1 , wherein the field device hardware component comprises an actuator.

17. The field device of claim 1 , wherein the field device hardware component comprises a valve.

18. The field device of claim 1 , wherein the one or more communication applications implement communication with the plurality of different external devices using addressed messages.

Images