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

Abstract

A highly versatile process control or plant automation field device is configured with an interface and communication connection structure that enables the field device to operate as a data server that communicates directly or indirectly with and supports a plurality of different applications or clients while simultaneously performing standard process and plant automation control functions. In addition, a variety of different process control and plant automation network architectures, particularly communication architectures, support the versatile field device to enable the versatile field device to communicate with a plurality of different client devices or applications (each associated with a different system) simultaneously using the same or different communication protocols via a common communication network infrastructure.

Description

TECHNICAL FIELD

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

[0002] Distributed process control systems, like those used in chemical, oil, industrial, or other process plants, for manufacturing, refining, converting, generating, or otherwise processing physical materials or products, typically include one or more process controllers communicatively coupled to one or more field devices via physical layer communications blocks or links. The field devices, which can be, for example, valve positioners, switches, and parameter sensors, are located within the process environment and perform physical process control functions such as opening or closing valves, measuring process parameters such as flow, temperature, or pressure, etc. The process controllers, which can be, for example, computers or computer controllers, receive signals from the field devices and use the signals to control the process as a function of time, for example, by sending control signals to change valve position, temperature, etc. in order to control the process. Field devices, such as field devices compatible with the Fieldbus protocol, can also perform control calculations, alarm functions, and other control functions typically implemented in controllers. Process controllers are typically also physically located within the plant environment, receive signals from field devices indicative of process measurements, and / or other information related to the field devices, and execute a control application in order to perform process control decisions based on the information received. The controllers typically communicate with field devices through the use of one or more communication buses or links 105, which can be, for example, wired communication links or wireless communication links, or a combination of both. and Fieldbus field devices. To perform such communication, a control module in the process controller sends control signals to various different input / output (I / O) devices which, in turn, send these control signals to the actual field devices via dedicated communication lines or links (communication physical layer) to control the operation of at least a portion of the process plant or system, e.g., to control at least a portion of one or more industrial processes running or executed within the plant or system. The I / O devices, which are also typically located in the plant environment, typically provide for communication between the process controller(s) and one or more field devices, and implement

[0003] Still further, information from field devices and the process controller is typically made available to one or more other hardware devices, such as operator workstations, personal computers or computing devices, data historians, report generators, centralized databases, or other centralized management computers, typically located in control rooms or other locations away from the harsher field environment of the process plant. Each of these hardware devices is typically connected to the process controller(s) and to each other by way of a data highway or communication network which allows these devices to exchange information for supervision and control of the process, maintenance, and other purposes. The data highway or communication network typically operates in a client-server environment using common communication protocols.

[0004] As described above, a process control system may include multiple field devices that provide a variety of different functional capabilities within the plant, and these field devices are typically communicatively coupled to the process controller using one of the physical layers of various types of specialized physical interfaces or communication interfaces specifically developed for process control. For example, a common process control communication physical interface uses a two-wire interface established in a point-to-point wiring connection arrangement (e.g., only one field device is communicatively coupled to a specific wired interface) or in a multi-drop wiring connection arrangement (e.g., multiple field devices are communicatively coupled to a single wired interface). However, some field devices may connect to the controller using a wireless communication physical layer, which may include wireless gateways and transmitter / receiver devices. Furthermore, field devices are typically configured to communicate with the process controller using one of a variety of highly specialized communication protocols. These communication protocols are typically digital signaling protocols, but may be analog protocols (e.g., 4-20mA protocols) or a combination of digital and analog protocols (e.g., HART protocols). Some of these protocols operate using relatively simple commands and / or communication (e.g., the ON and OFF commands used in the CAN protocol), while others are more complex, requiring more commands and / or more communication information, which may or may not include simple commands. For example, more complex protocols may use, for instance, high-speed addressable remote transducers. Communication protocols are used to transmit analog values, where digital communication is superimposed on the analog values. Other field devices can use fully digital communication, which provides many types of communication (e.g., ...). (Fieldbus communication protocol). Other process control communication protocols include the PROFIBUS communication protocol, although other process control communication protocols have been developed and are in use. Each of these communication protocols requires or needs to be supported by a specific physical layer, which may include two-wire, four-wire, or other physical layers, specific switches, etc. Furthermore, the physical layer can specify maximum or minimum wire length, wire thickness, wire type, termination type, other electrical characteristics, etc. However, it is important that field devices are configured to communicate using a single protocol and have a unified interface for communicating using that communication protocol and the physical layer associated with it.

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

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

[0007] As noted above, each field device is coupled to an I / O device using a specific communication medium or physical layer (e.g., two-wire cable, wireless link, or optical fiber) through a terminal block on the I / O device, and also using one of the above or other specialized process control communication protocols (HART, CAN, WirelessHART, FOUNDATION Fieldbus, PROFIBUS, etc.) that have been developed in the process control industry. Still further, the I / O devices are typically individually connected to the process controller through another bus or wired connection. The use of these different input / output devices means that the physical and logical connections between different field devices must be precisely mapped so that the controller, which is connected to different I / O devices, can keep track of which field devices are connected to which port of each input / output device in order to route signals to that field device through the correct "path." This problem is particularly troublesome in the HART protocol, in which each field device is connected to a different output port of a HART-compliant I / O device. Moreover, communication with the process control field devices must be conducted through defined communication paths, which typically include the field device communicating with a specialized I / O device (typically through a first communication protocol), the I / O device communicating with the process controller (through a second and different communication protocol), and the process controller communicating with a user device or application (e.g., with a process control operator application, process control configuration application, etc. located in a server or other user interface device through yet another different communication protocol). In any case, all communication to and from the field devices is routed or sent through the I / O devices and process controller via specialized communication paths (links). Thus, all data to and from the field devices must be sent through the process controller and one or more I / O devices. In this case, the process controller must initiate and coordinate all messages or communications to and from the field devices via the specified 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 in that all applications seeking to communicate with the field devices must be able to (and authorized to) communicate with the process controller, which then acts as a proxy or server for information from the field devices. Moreover, external applications cannot directly communicate with the field devices.

[0008] While process control field devices typically use proprietary communication hardware and protocols, it is well known to use general purpose IP or other packet-based communication protocols to perform communication between certain other devices within a process plant. For example, it is common to use a packet-based or general purpose IP protocol over an Ethernet bus that communicatively connects one or more distributed process controllers to one or more user interfaces, databases (e.g., a configuration database and a historian database), servers, etc. within a back-end plant environment. In this way, Ethernet (which is a physical layer and part of a data link layer) is an important communication platform for automation systems because it enables flexibility, scalability, and performance in ways that were not previously seen in automation. To help support the adoption of Ethernet in automation, an advanced physical layer (APL) specification is being designed to support the connection of field devices in remote and hazardous locations. APL is followed by the IEEE P802.3cg project, which focuses on the development of enhancements to the existing IEEE 802.3 Ethernet standard (IEEE 802.3) for Ethernet over twisted pair wiring (10BASE-T1L). This development is important because there is a long list of automation protocols that can run on top of the Ethernet physical layer that are developed for various purposes.

[0009] To support this emerging development of Ethernet-based communication in process control, the FieldComm Group has standardized HART-IP as part of HART7 release. While HART-IP was originally designed to allow a host to communicate efficiently with a gateway, it has now emerged as a method for devices to communicate directly with I / O servers and hosts / controllers. HART-IP is now used for monitoring, control, diagnostics, and condition monitoring applications. Because HART-IP already has a complete description of the devices available to it, it is a good protocol for the layer on top of APL. In addition, another protocol that is seeing wide support at the device level is OPC Unified Architecture (OPC UA). While OPC UA does not understand device communication and types natively, there is considerable effort being made in this regard to provide some level of support. While HART-IP and OPC UA can be relatively quickly adopted by the market, they will not be alone in their use. Other protocols such as EthernetIP and PROFINET are already available on Ethernet and will be able to run on APL when it is available. In addition, IT driven protocols such as MQTT and AMQP will emerge as important protocols as the Industrial Internet of Things (IIoT) gains acceptance.

[0010] However, in process plants that have included an installation base that relies heavily on more traditional field devices (e.g., HART or FOUNDATION Fieldbus field devices), it is difficult and not straightforward to support Ethernet or other higher level physical layers, such as those associated with packet-based or generic IP communication protocols, because these various communication protocols would need to be synthesized or merged at some location in the process control network via one or more electronic marshalling cabinets or devices. It is not currently clear how these higher level protocols can be integrated in a typical process plant architecture to operate in a reliable and robust manner.

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

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

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

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

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

[0016] The highly versatile (HV) field devices and network architecture described herein are capable of supporting APL or other Ethernet or general IP-based physical layers and a variety of communication protocols that run on top of them in such a way that the highly versatile field devices are capable of simultaneously acting as servers for multiple different client devices. Moreover, when protocols such as security protocols require additional handshakes, acknowledgements, etc., the highly versatile field devices described herein are capable of nesting protocols within other protocols for use. Moreover, the highly versatile field devices described herein include configuration capabilities that enable easy configuration of process control systems by supporting a variety of I / O types, including packet-based, IP-based, or other high-level protocols such as HART-IP, OPC UA, Ethernet, etc. The highly versatile field devices and associated network architecture described herein support mixed physical layers and multi-protocol support that can be used to enable improved control, while providing direct support for non-control systems, as the highly versatile field devices described herein are capable of supporting request / response, publish / subscribe, event-based communication, reporting communication, and streaming communication, which greatly facilitates support for combinations 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, their capabilities, their diagnostics, and information that can be determined from combinations of these measurements, capabilities, and diagnostics.

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

[0018] Thus, a highly versatile (HV) field device can be a node of a process control and / or automation network as described herein, which is generally referred to herein as a node communication network. The node communication network generally supports a packet-based, IP-based, or other high-level protocol for communicating information between nodes of the network. A new node, such as a new HV field device, can join the node communication network and be discovered by other nodes, and each node is identified within the node communication network by a unique endpoint identity. As such, in embodiments, a system for managing nodes of a node communication network of a process control or automation system includes a network node manager communicatively connected to the node communication network, and a domain name service (DNS) accessible to the network node manager. The network node manager includes a mapping database that stores associations of respective labels or identifiers of a plurality of devices used in the process control or automation system and respective endpoint identities of the plurality of devices used in the node communication network, where the plurality of devices includes one or more highly versatile (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 to control, for example, an industrial process. The network node manager further includes a state database that stores respective states of the plurality of devices. The DNS of the system provides responses to requests for endpoint identities for particular devices of the plurality of devices via the node communication network, where the responses are generated based on the mapping database and the state database of the network node manager.

[0019] Further, as highly versatile (HV) field devices can join a node communication network and be discovered, in embodiments, a highly versatile field device includes one or more physical components that perform a physical function to control an industrial process within a process control or automation system, a communication interface to the node communication network, one or more processors, and one or more non-transitory memories into which a tag or identifier corresponding to the HV field device has been provisioned and stored. The one or more non-transitory memories additionally store computer-executable instructions that, when executed by the one or more processors, cause the HV field device to perform operations of detecting, upon power-up of the HV field device, that the HV field device is connected to the node communication network via the communication interface; and transmitting, via the node communication network, a request for an endpoint identity for the HV field device to a DHCP server of the node communication network, wherein the request includes an indication of the tag or identifier corresponding to the HV field device. Execution of the computer-executable instructions by the one or more processors causes the HV field device to further perform operations of obtaining, via the node communication network from the DCHP server, an endpoint identity that has been assigned to the HV field device by the DCHP server; and establishing, on the node communication network and by using the endpoint identity assigned to the HV field device, a communication session with another device, wherein the other device is a consumer of data generated by the HV field device and the generated data corresponds to the physical function performed by the HV field device during runtime operation of the process control or automation system. Additionally, execution of the computer-executable instructions further causes the HV field device to perform operations of transmitting, via the established communication session, data corresponding to 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.

[0020] In an embodiment, a method at a highly versatile (HV) field device of a process control or automation system includes detecting, by the HV field device upon power up of the HV field device, that the HV field device is connected to a node communication network via a communication interface of the HV field device, the node communication network having nodes identified within the node communication network by respective endpoint identities. In addition, the method includes transmitting, by the HV field device via the node communication network, a request for an endpoint identity by which the HV field device is to be identified within the node communication network to a DHCP server of the node communication network, wherein the request includes an indication of a tag or identifier of the HV field device and the tag or identifier identifies the HV field device within a process control automation or automation system, and obtaining, by the HV field device via the node communication network from the DCHP server, the endpoint identity that has been assigned to the HV field device. Further, the method includes establishing, by the HV field device on the node communication network and by using the endpoint identity assigned to the HV field device, a communication session with another device that is a consumer of data indicative of a physical function performed by one or more physical components of the HV field device during a runtime operation of the process control or automation system that controls an industrial process. In addition, the method includes transmitting, by the HV field device during the runtime operation of the process control or automation system, data indicative of the physical function performed by the one or more physical components of the HV field device to the another device via the communication session, thereby controlling the industrial process.

[0021] Still further, in a node communication network using highly versatile (HV) field devices, in conjunction with the above-described device discovery method, benefit is derived from a complex network resource management scheme that can be implemented in the node communication network. In an embodiment, a controller controls physical devices in an industrial process or factory automation plant that perform operations on one or more raw materials to transform the one or more raw materials into a product. The HV field devices are coupled to the controller and receive commands from and transmit parameters to the controller. The communication network includes an advanced physical layer (APL) infrastructure - APL cabling, APL power switch(es) that provide connectivity and power via the APL cabling, and APL field switch(es) that receive power from the APL power switch(es) and distribute power and connectivity to the HV field devices - and a network resource management component configured to manage network resources on the communication network to facilitate communication of network traffic on the network, the network traffic including managed network traffic known to the network resource management component and unmanaged network traffic unknown to the network resource management component.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0035] Figure 8 A block diagram of various security features and components implemented in a highly versatile field device is shown. Figure 1

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

[0037] Figure 10 A first example message flow is shown that can occur when initially connecting a highly versatile field device to a node communication network of Figure 9 .

[0038] Figure 11 A second example message flow is shown that can occur when initially connecting a highly versatile field device to a node communication network of Figure 9 .

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

[0040] Figure 13 A block diagram of a node management system for a node communication network that includes multiple network node managers is shown.

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

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

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

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

[0045] Figure 18 A block diagram of an example publish-subscribe communication architecture is shown. Figure 17 ​example communication flow diagram employed by the publish-subscribe communication architecture of the present disclosure. DETAILED DESCRIPTION

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

[0047] In addition, the highly versatile (HV) field device 10 includes a computer processor 14, a computer memory 16, a hardware communication interface 18, an external communication interface 20 (which connects to the physical layer of an external communication network, not shown), and a power supply 22. In general, the hardware communication interface 18 enables communication between the processor 12 (and in particular, one or more applications or routines stored in the memory 16 and executing on the processor 12) and the field device hardware 12 using any desired communication technique or protocol, including any proprietary protocol or technique, any open process control protocol or technique, such as HART, FOUNDATION Fieldbus, CAN, Profibus, etc. The communication interface 18 can be an internal input / output device that multiplexes and / or conditions signals from the hardware device 12 and transduces these signals for reading by or delivery to the processor 14, and vice versa. The communication interface 18 can transduce signals from the processor 14 to be sent in order to control or affect the operation of the hardware 12 in any known or desired manner, and likewise can transduce signals from the hardware 12 to the processor 14 in any known or desired manner. Still further, the processor 14 can execute one or more hardware control applications 30 (which can be stored in the memory 16) to communicate with, control, read signals from, change the settings of, etc. any or all of the field device hardware 12. The hardware control applications 30 can be stored in the ROM or RAM of the memory 16, and / or can be implemented as ASICs, executable applications, or in any other desired manner.

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

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

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

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

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

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

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

[0055] Thus, for example, the application 32 can use a process automation device information model (PA-DIM), which can be accessed by any client application capable of opening a client / server connection with the field device 10 and subscribing to data publications. While the general concept of PA-DIM has been defined by a FieldComm Group (FCG) working group, current device information models do not support control, extensions for condition monitoring, standard publication / subscription lists, and templates for supporting custom publication / subscription lists. In this case, the PA-DIM used in the highly generic field device 10 can be implemented on top of or in addition to existing field device hardware and communication interfaces. Here, the PA-DIM is capable of communicating in a particular protocol, such as OPC UA, which is compatible with IP packet-based communication protocols, and can be used to standardize information available from the field device 10.

[0056] Generally, the highly versatile field device 10 is configured to operate in a field environment at a factory or manufacturing plant. For example, it includes support for high-level protocols running on an open physical layer to perform communication networks between the field device and one or more client devices. These client devices can be associated with any number of different systems, such as control systems, maintenance systems, monitoring systems, etc. Therefore, the client devices can be process controllers (associated with control systems), maintenance applications or servers (associated with equipment or plant maintenance systems), monitoring applications or servers (associated with monitoring systems), and / or other systems.

[0057] In one embodiment, the highly versatile (HV) field device 10 can communicate via an advanced physical layer (APL). For example, Figure 2 An APL-based network 80 is illustrated, in which a highly versatile field device 10 can be used to support multiple client applications and devices. The APL network 80 supports a variety of field devices 82 (any or all of which can be...) Figure 1 The highly general-purpose field devices 10 communicate with any other devices (e.g., controllers, servers, user interface devices, etc.) using packet-based or high-level (e.g., general-purpose 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, CAN, etc.), APL provides sufficient power (in the form of voltage and current) on the two-wire bus to supply power to microprocessors (e.g., those based on general-purpose or higher-level operating systems) within field devices connected to the APL physical layer or bus. Figure 1 The microprocessor 14) is powered. This higher power level is required to enable processors capable of running general-purpose or real-time OSes, as described in the above references. Figure 1The APL, as described. However, the APL does not provide much power (particularly voltage) on the two-wire physical layer to the point that it is dangerous to use in hazardous environments due to the risk of sparking. Thus, the APL has enough power to power process control devices having microprocessors running operating systems such as real-time operating systems, without enough power to cause potential safety issues in the actual process control environment in which the field devices are located. Generally, APL networks provide about 1.4 watts of power to each device (on the spur line) at 14 volts or less, and preferably at 10 volts or less. In addition, APL networks provide a two-wire hardened physical layer or wire by using 14 gauge twisted wire, which makes wiring less susceptible to tampering in the field, and enables more power (current) with lower voltage levels due to reduced resistance. In addition, APL supports IP or packet-based digital communications in the form of traditional Ethernet-based communications, making APL communications easy to use in other types of applications besides control applications, and thus extends the power of traditional Ethernet communications down into process control or factory automation environments or plants, without the drawbacks of the Ethernet physical layer, which typically provides 48 volts on thin or higher gauge single strand wiring.

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

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

[0060] ​Of course, the APL power switch 84 acts as a gateway to the bus 85 and operates to multiplex signals from external sources onto the link 88 using the communication protocol established for the network 80. Likewise, the power switch 84 can operate to decode any messages from the field switches 86 on the link 88 and addressed to destinations outside the network 80 (which can be messages from the field devices 82) and send those messages onto the link 85. Likewise, the APL field switches 86 decode messages on the link 88 and, if addressed to one of the field devices 82 connected to the field switch 86, the field switch 86 places that message on the spur or link 92 for transmission to the field device 82. Likewise, the field switches 86 receive messages from the field devices 82 via the link 92 and place those messages on the link 88 for transmission to another field switch 86 or the power switch 84. Generally, the field devices 82 are all APL compatible field devices in that they use the APL physical layer and the communication protocol supported by the APL physical layer (e.g., the IP communication protocol) to communicate via the links 92 and 88. The field devices 82 can also receive power via the link 92 and that power is provided from the field switches 86 and ultimately from the APL power switch 84 and the power source associated therewith over the bus 88.

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

[0062] As such, Figure 2The network 80 can use any communication protocol supported by APL, such as any protocol supported by an Ethernet connection. These protocols include, but are not limited to, Internet Protocol (IP), packet-based protocols, time-sensitive and non-time-sensitive protocols, etc. 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 general-purpose IP protocols, including protocols that support request / response, publish / subscribe, and event-based communication, as well as data streaming.

[0063] The use of network 80 illustrates an implementation of the APL physical layer and supported communication protocols in a process control system or factory automation environment, for communication between field devices (e.g., field device 82) and other devices (e.g., process controller 11 or...). Figure 2 The method provides communication between the process controller and other devices on network 85 / 90. Alternatively, the process controller may be directly connected to the APL power switch 84 to provide communication with the power switch using the APL physical layer, and thereby use the APL physical layer to perform communication between the field device 82 and the controller (e.g., controller 11). Furthermore, while power may be provided in or associated with the APL power switch 84 and may send power to the field switch 86 via bus 88, the APL field switch 86 may be independently powered, or may include its own power supply or power source and power itself and the field device 82 via APL branch 92.

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

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

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

[0067] 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 10M APL network connection 126. Figure 3APL field switch 124A is shown connected via a trunk to two highly general-purpose PA field devices 128 and adapter device 130, which connects to a legacy field device (in this case, a HART 4-20mA field device 132) and acts as its input / output device. Similarly, APL field switch 124B is shown directly connected to the two highly general-purpose PA field devices 128, and also connected to APL field switch 124C, which in turn connects to two highly general-purpose (HV) field devices 128. Of course, the highly general-purpose field devices 108, 110, and 128 communicate via their respective APL networks 104 and 106 with devices connected to the network backbone 112 via APL power switches 114 and 122. In this way, highly versatile field devices 108, 110, and 128 can communicate with one or more controllers 140 on the network backbone 112 via various APL field switches and APL power switches using different APL-supported physical layers (or communication networks with different speeds), while performing process and plant settings controls using conventional control techniques.

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

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

[0070] In another example architecture, Figure 3 The system can be extended to include or provide one or more applications in other networks, such as the cloud, to gain access to the highly versatile field device 10. For example, Figure 4 It shows something similar to Figure 3 System 100 includes system 160, where network 144 is coupled via firewall device 162 to another network 164, which may be a factory or manufacturing plant's commercial network. Network 164 may also be connected to cloud 168 via edge gateway 166 using, for example, OPC UA protocols and supported physical layers. One or more other applications associated with other systems, such as monitoring systems, data logging systems, etc., may be stored in and executed on computer devices in cloud 168, and these devices and applications may communicate with highly generic (HV) field devices 108, 110, 128 as clients via edge gateway 166 (and network 164), via firewall 162 and network 144, via switch 142 and network 112, and via one of APL power switches 114, 122 through one of APL networks 102 or 104 connected to field devices 108, 110, 128. This architecture or configuration provides access to highly generic field devices from applications (client applications) and devices in one or more external networks (i.e., networks outside the factory or manufacturing plant). As will be understood, Figure 4 The edge topology network operates on or in parallel with process and factory automation systems 102 and 104. Edge devices or applications 166 and 168 can be used, for example, to support factory information integration including scheduling, asset monitoring, analysis, simulation, and other functions.

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

[0072] Figure 6 and Figure 7 Other control system architectures are shown that include highly versatile (HV) field devices that are accessible by various client devices or applications. In particular, Figure 6 and Figure 7 The network architecture of FIG. 18 is designed to work with traditional networking as well as flat networking. Generally, traditional networking provides access to devices through controllers and I / O servers, while flat networking provides direct access to highly versatile field devices.

[0073] For example, Figure 6A process control network 200 is shown having an engineering station 202, an application station 204, an operator station 206, and a gateway 208, which are connected to a controller 210 and I / O devices 212 over a communication network 214, which can be an Ethernet network. The controller 210 is connected to one or more APL networks 216, each having power switches 218 connected to one or more highly capable field devices 220 via zero or one or more field switches (not shown). Additionally, the controller 210 can be connected to legacy process control field devices 224 through standard or traditional I / O devices 222, such as HART, FOUNDATION Fieldbus, WirelessHART, CAN, Profibus, etc. I / O devices. Likewise, the I / O devices 212 can be communicatively connected to one or more APL networks 226, each having power switches 228 connected to one or more highly capable field devices 230 via zero or one or more field switches (not shown). Additionally, remote or cloud-based applications 232 can be connected to the network 214 via the gateway 208 to gain access to the controller 210 and I / O devices 212 to obtain data from the highly capable field devices 220, 230. The I / O devices can be, for example, the I / O devices described in detail in U.S. Patent Application No. 16 / 573,380, 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 hereby expressly incorporated by reference herein.

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

[0075] In Figure 6 the legacy network 200 and Figure 7 the flattened network 250, device tagging must be unique. In both cases, the devices include a unique ID, are assigned a unique tag, and support multiple application sessions. However, even here, the highly generic field devices 220, 224, 230, and 270 described herein support a request and publish / subscribe model. To establish a publish / subscribe device, the publisher (the highly generic field device) must be discovered and, once discovered, authenticated with a session. Once a session is established, the highly generic field device can support pre-defined and custom publish lists. A client or client application can subscribe to an existing publish list or set up a custom publish list and then subscribe to it, as will be explained in more detail herein.

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

[0077] In another case, the highly versatile field devices described herein can support data logger systems. As an example, many systems collect energy and monitoring data in a centralized fashion in order to analyze and establish alarm management systems in the event of, for example, a water leak or loss of energy due to a pipe leak or rupture, and these systems can subscribe or connect to the highly versatile field devices described herein to obtain data for analysis and data logging. Likewise, the highly versatile field devices described herein can support safety smart metering systems. In particular, metering can be a critical process in large scale distributed systems such as oil and gas fields, pipelines, chemical storage, and product storage. For example, in a chemical storage system, it is important to have accurate readings as to what materials are present. Smart metering systems typically include a smart meter reading system, which is metered by a controller or independently by a remote monitoring system, which then transmits the readings to a processing location such as an edge gateway or central data server. In addition, the highly versatile field devices disclosed herein can support environmental monitoring, such as environmental protection agency (EPA) required environmental monitoring or monitoring required in other uses. As an example, many plants have environmental reporting requirements, such as reporting of NOx, SOx, and other items. These systems tend to be specialized systems that perform data collection, calculation, and reporting. It is critical that the data from these systems be time-stamped, not subject to daylight savings time adjustments, and secure. The highly versatile field devices described herein can additionally provide these additional features to the data provided to client applications.

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

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

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

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

[0082] Highly generic field devices and the networks in which they are deployed address these security challenges by incorporating security mechanisms into the field devices and networks. These mechanisms may include the use of TLS, authentication certificates, and a complete chain of secure trust. Specifically, Figure 8 It shows, for example Figure 1 Highly versatile field devices 10 and the locations of these devices Figures 2-7 A general overview of the various security features offered in the network. Specifically, such as... Network node management As shown, the security features include a root trust component 302, a secure boot feature 304, an endpoint identity feature 306, secure storage 308, and encryption capabilities 310. Additionally, the security features include secure communication features 312, device provisioning 314, and security auditing functionality 316.

[0083] In particular, each highly versatile field device 10 includes or comprises a root-of-trust component 302 that forms the basis of device security. Trust in embedded security refers to the expectation that a field device operates as designed. In particular, device software trusts that the hardware operates as it should, applications running on the device trust that the operating system has not compromised the device configuration, and remote systems communicating with the device trust the identity of the device to which the remote system is connected. The process of establishing this trust is known as attestation, and the root-of-trust 302 of a field device is the point at which attestation and authentication begins. This root-of-trust once established extends through and provides the basis for each layer of trust. Thus, the root-of-trust component 302 is an important building block in the highly versatile field device 10 because the root-of-trust component 302 provides the basis for protecting the device and all communications with the device. The root-of-trust component 302 can be established using any of a variety of methods and can take many forms, but generally the root-of-trust component 302 ensures that the boot code on the field device is the code that the manufacturer intended. This root-of-trust feature 302 protects the boot code in a way that makes external tampering with the boot code impossible or unbreakable. In a simple case, the root-of-trust component 302 can be established by storing and / or executing the manufacturer's boot code for the field device 10 in a non-writable location in the memory map of the device processor or directly from that location. Alternatively, the device can include a root-of-trust component 302 that allows the boot code to be updated and patched by allowing the boot code to be loaded from a protected memory area into some protected memory storage set aside for firmware execution. An important aspect of the root-of-trust component is to ensure that the initial code is what the manufacturer intended before it is executed and that the root-of-trust component protects the manufacturer's code (or updated code) from being tampered with by third parties. When the code starts, the root-of-trust derives its internal keys from the provided device identity input and the device performs a self-test and code verification on itself to verify its identity and establish the base keys for the root-of-trust to use with other devices in the network.

[0084] Additionally, the highly versatile field device 10 includes a secure boot feature or process 304. The secure boot process 304 prevents the execution of unauthorized code at device power up and prevents exposure of embedded boot code and software. The secure boot process can be implemented in many different ways, including using digitally signed binary strings, using a secure and trusted bootloader, using boot file encryption, and using a secure microprocessor. While the secure boot feature 304 can be centered around digitally signed boot files, the boot is not secure unless those signatures are verifiable using some sort of unalterable root of trust. Thus, to verify boot files, the highly versatile field device has a digital key installed therein (and established by the root of trust component 302) when the device is manufactured or after manufacture using a trusted application, and the digital key is then used to perform or enable other security features. Moreover, the secure boot process protects software on the device, such as proprietary algorithms, and provides a trusted repair measure. That is, the secure boot process 304 provides the ability to securely repair the process control system in the event of device failure or compromise, as the repair relies on a secure boot process that checks the validity of the firmware image being booted with or using 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 cause damage beyond itself.

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

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

[0087] Further, the highly versatile field device 10 includes secure program storage 308. In particular, the program storage can be implemented in off-chip flash memory, the contents of which are copied into SRAM or external DDR memory to run once the field device is booted. The hardware root of trust protects the unique ID of the device and the keys associated with that ID, and thus the facilities (communications) derived from those keys. The device includes secure storage 308 for the rest of the chip, and serves as a means for identifying or authenticating the device.

[0088] Further, the highly versatile field device uses and implements encryption 310 across transmission protocols (data-in-motion), storage (data-at-rest), and applications (data-in-use). Although various types of encryption services listed below can be used to implement encryption in this manner, other encryption services can be used by the device manufacturer. As one example, the highly versatile field device can use or include standard-based symmetric cipher suites (PSK or PKI), hash functions, and encryption algorithm implementations of appropriate strength with NIST / FIPS standard-based verification, and can implement interoperability of cryptographic keys.

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

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

[0091] Further, the highly versatile field device 10 includes or supports a security audit function (e.g., system log) 316 that enables monitoring of the field device 10 as part of regular operations. To assist in such monitoring, the highly versatile field device 10 supports audit logging, including providing audit log information to a system log server. Specifically, for incident response and audit, event logs are used as valuable inputs that can help to continuously measure and assess risk and mitigate threats. This requires capturing system and security events (which can not be security events), communicating events to a host using system logs, and the ability to apply checks to system events. To implement such functionality, the highly versatile field device 10 supports audit logging and audit functions (system log). In particular, the device (server) can record in a local volatile audit log (1) the last time / date the server was powered on; (2) the last time / date a security credential was modified; (3) the server status; (4) a circular 128 entry session digest list; and (5) a timestamp, such as an 8 byte unsigned integer timestamp. Each session digest record can include (1) a client identity including IP address (IPv4, IPv6) and port number, (2) the connect / disconnect time / date for that client, (3) a start / end configuration change counter, (4) a session status, and (5) a communication counter indicating the number of publish (burst), request, and response PDUs. Further, the highly versatile field device 10 can support system logs by supporting or providing push audit messages (system log messages) to a security information and event management system that supports the field device 10. These pushed messages are critical for detecting security attacks and unauthorized manipulation of the field device 10. Detection enables improved factory security policies and processes to minimize vulnerabilities.

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

[0093] Figure 9

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

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

[0096] Devices D1-Dn may include one or more field devices, each performing a corresponding physical function during operation in the plant or network to control an industrial process. For example, field devices included in D1-Dn may include sensors, valves, actuators, meters, and other types of measuring devices. 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 components thereof; safety instrumented system (SIS) components; process control or automation network communication components, such as adapters, routers, gateways, etc.; user interface devices; portable devices; etc. Some of devices D1-Dn may be highly generic (HV) field devices, such as highly generic field device 10. For example, devices D1-D4 and Dn in... Figure 9 The devices shown are highly versatile field devices. Some of the devices D1-Dn can be legacy or traditional devices, such as... Figure 9The device D5 shown is thus communicatively connected to the APL component 410 (and thus to the backbone 408 of the node communication network 402) via adapter 415, wherein adapter 415 supports local I / O of legacy device D5 and thereby enables legacy device D5 to communicate via communication network 402 through APL component 410.

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

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

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

[0100] Some of the nodes D1-Dn, 418-428 can be both data hosts and data clients. For example, the controller 418 can be a data client of data generated by the data host field device D3, and the controller 418 can also be a data host that generates data (e.g., control signals generated by the controller 418 executing a control routine 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 operates as a data host, a data client, or both) is identified via a respective IP address (which, in embodiments, can be a secure endpoint identity 306, such as discussed above with respect to Figure 9 the secure endpoint identity 306 can be assigned to the node by a dynamic host configuration protocol (DHCP) service (e.g., in the manners described such as in other portions of the present disclosure), where the DHCP service can be hosted on a DCHP server 430 of the system 400. As Figure 9As shown, DCHP server 430 is communicatively connected to node communication network 402, for example, via backbone 408. In some arrangements, node communication network 402 may include multiple DCHP servers 430, which may operate in a redundant manner (e.g., for backup purposes) or serve in parallel a corresponding set of requests for node queries against IP address / endpoint identity used within system 400.

[0101] On the other hand, within a process control system or automation network, each device D1-Dn is identified and / or associated with one or more corresponding logical identifiers or tags, such as device tags, one or more data tags identifying the type of data transmitted and / or received by the device, etc. For example, a device tag can be a first-order device identifier or device identifier because it directly identifies the device, while a data tag can be a second-order device identifier or device identifier because it indirectly identifies the device via specific data that the device is to produce or consume. Generally, in one or more configurations of a process control system or automation network, such as in one or more configuration databases 420, the identified and / or associated tags or identifiers are defined. One or more configuration databases 420 can be nodes of a node communication network 402, for example, such as... Figure 9 As shown, or one or more configuration databases 420 can be accessed via one or more other types of process control or automation networks ( Figure 9 (Not shown) is communicatively connected to devices D1-Dn, and this network may include legacy or traditional process control or automation networks. Some identifiers or tags may be manually or automatically supplied to the respective devices D1-Dn (e.g., during bench supply and / or commissioning of devices D1-Dn, or at some other time before the initial power-on of devices D1-Dn within field environment 412a), and / or some identifiers or tags may be downloaded to or otherwise stored in the respective devices D1-Dn along with the configuration of the respective devices. The corresponding device tag identifying and / or associated with each device D1-Dn and any corresponding data tags are... Figure 9 The symbol in the middle is represented by a circled "label".

[0102] The system 400 for managing nodes (e.g., nodes D1-Dn and 418-428) of the node communication network 402 includes a network node manager 432 communicatively connected to the node communication network 402. The network node manager 432 is aware of (e.g., stores information indicative of) all devices that have connected to the node communication network 402 and have been discovered, e.g., the "nodes" of the node communication network 402. For example, the network node manager 432 can store the identity of discovered devices (e.g., respective IP addresses, endpoint identities or names, and / or respective device identifiers) within a discovered device data store or database 435. In embodiments, at least a portion of the discovered device data store 435 can be integrated with the network node manager 432 (not shown in Figure 9 Figure 9 The network node manager 432 also stores and updates respective states or conditions of discovered devices in the discovered device data store 435. Non-limiting examples of possible device states or conditions include commissioned, active, inactive, offline, failed, booting, diagnostics in progress, limited operation, and / or any other suitable state or condition. Device states or conditions can be updated by the device itself or by other devices. In some embodiments, device states and / or conditions can refer to operational, physical, component, and / or equipment states and / or conditions. In some embodiments, the network node manager 432 also stores respective security credentials of discovered devices and / or associated with discovered devices.

[0103] In addition, the network node manager 432 is communicatively connected to other management nodes of the node communication network 432, such as a DHCP server or service 430, a DNS server or service 438, a security manager 440, and / or a system log server 442, e.g., via the backbone 408. In general, the network node manager 432 performs node management within the node communication network 402, including facilitating discovery of devices by other devices with the aid of the discovered device data store 435, coordinating information flow between the various management nodes 430, 438, 440, 442, and so on.

[0104] ​To this end, the discovered device data store 435 stores associations or mappings between device identifications (e.g., device tags of devices and, optionally, data tags associated with devices) defined in the process control configuration database 420 and respective IP addresses / end point identifications that have been assigned to the devices by the DHCP server 430. Thus, the discovered device data store 435 is interchangeably referred to herein as a "mapping database 435." To illustrate, consider an example device Dl that has been provisioned and / or configured with its identification device tag A and two data tags B and C that identify two particular types of data generated by the device Dl. The DHCP server 430 assigns the IP address AlB2 to the device Dl. Thus, the mapping database 435 (e.g., the discovered device database 435) stores an indication of an association between (1) the device tag A and the IP address AlB2, (2) the data tag B and the IP address AlB2, and (3) the data tag C and the IP address AlB2.

[0105] In assigning IP addresses to devices, the DHCP server 430 and / or the devices themselves can cause the mapping database 435 to be updated accordingly using an indication of an association between device identifiers (e.g., tags) and assigned IP addresses, e.g., by directly updating the mapping database 435, and / or by notifying a domain name service server (438) that updates the mapping database 435 with newly created associations or mappings. Typically, the DNS server 438 manages the mapping database 435 and its contents; however, in other embodiments, the network node manager 432 and / or other management nodes such as the DHCP server 430 can manage the mapping database 435 and its contents. Note that although the mapping database 435 is shown as a separate node of the network 402, in embodiments, the mapping database 435 can be supported and / or integrated into one or more other management nodes, such as the network management node 432 or the DNS server 438. Figure 8 In assigning IP addresses to devices, the DHCP server 430 and / or the devices themselves can cause the mapping database 435 to be updated accordingly using an indication of an association between device identifiers (e.g., tags) and assigned IP addresses, e.g., by directly updating the mapping database 435, and / or by notifying a domain name service server (438) that updates the mapping database 435 with newly created associations or mappings. Typically, the DNS server 438 manages the mapping database 435 and its contents; however, in other embodiments, the network node manager 432 and / or other management nodes such as the DHCP server 430 can manage the mapping database 435 and its contents. Note that although the mapping database 435 is shown as a separate node of the network 402, in embodiments, the mapping database 435 can be supported and / or integrated into one or more other management nodes, such as the network management node 432 or the DNS server 438.

[0106] In practice, the system 400 for managing nodes of the node communication network 402 (e.g., nodes D1-Dn and 418-428) also includes a domain name service (DNS) server 438 communicatively connected to the node communication network 402. The DNS server 438 provides domain name service within the node communication network 402. As such, 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 a configuration identification of the particular device (e.g., a device identification or tag stored in the process control configuration database 420). Upon receiving the request, the DNS server 402 accesses the mapping database 435 to obtain the IP address of the second device and returns it to the first device, e.g., so that the first device can use the IP address of the second device to communicate with the second device. In some embodiments, the DNS server 438 also takes into account the device status indicated in the device status database 435 in its reply. For example, if the second device is not operational, the DNS server 438 can reply with its indication instead of or in addition to the requested IP address of the second device. In some arrangements, the node communication network 402 can include multiple DNS servers 438.

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

[0108] In embodiments, the system 400 for managing nodes of the node communication network 402 (e.g., nodes D1-Dn and 418-428) includes a system log server 442 (also referred to herein as "log server 442") communicatively connected to the node communication network 402. Generally, the system log server 442 is a centralized log server that memorializes or records events with respect to the network 402, such as when devices connect to and disconnect from the node communication network 402, when communication sessions are established and removed, and so on. The devices themselves can notify the log server 442 of the occurrence of various events, for example, each time a device connects to and / or is about to disconnect from the network 402. For example, when the device is a highly versatile field device 10, the device can utilize the security audit function 310 (as discussed above with respect to Figure 9 In some cases, the devices can additionally notify the log server 442 of events related to other devices. The logs stored at the log server 442 can be audited and / or otherwise analyzed for purposes of mitigating security issues.

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

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

[0111] To illustrate, Figure 10 Example message flow 500 is shown when example device 502 is initially connected to node communication network 402. Device 502 can be a highly general-purpose field device, such as device 10, D1-D4, or Dn, or device 502 can be a legacy field device, such as device D5 connected to APL component 410 and network 402 via adapter 415. Therefore, in the case where device 502 is a legacy device, adapter 415 communicates with network 402 on behalf of the legacy device, even though... Figure 9 Adapter 415 is not shown. Generally, message flow 500 can appear... Figure 8 In the embodiment of system 400, or in other systems where nodes of a node communication network are used to manage process control systems or automation networks, reference is also made to... However, for illustrative purposes and not for limitation, the following also refers to... Figure 9 and Figure 9 To describe message flow 500.

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

[0113] Device 502 is physically set and installed at its intended location in the process control plant or automation network, e.g., in its field environment (such as field environment 412a of FIG. 4) and any physical interface to network 402 is physically connected to the device. Subsequently, device 502 is powered on, as represented by reference numeral 505. For example, device 502 can use secure boot feature 304 of FIG. 4 to power on. Figure 8 Figure 10 Upon power on 505, device 502 broadcasts a discovery DHCP message (508) via network 402 to determine or discover any DHCP server that serves node communication network 402 and will be able to assign an IP address or endpoint identifier to device 502, so that device 502 can be identified within network 402 and as a node of network 402. Discovery DHCP message 508 is received by any DHCP service and / or server that serves network 402, such as DHCP server 510 shown in FIG. 4. In an example implementation, DHCP server 510 is an embodiment of DHCP server 430 of FIG. 4.

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

[0115]

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

[0117] In any event, at this point 520 of the message flow 500 (e.g., after the device 502 has received the response 518), the device 502 and the DHCP server 510 are aware of the association between the device's process control / automation network identity (e.g., device tag) and the IP address / endpoint identifier that has been assigned to the device 502. In some implementations, the device 502 and the DHCP server 510 can additionally or alternatively be aware of the respective associations between each of the device's data tags and the IP address assigned to the device 502. As such, the DHCP server 510 and / or the device 502 can update a discovered device / mapping data store or database 522 with the new associations or mappings. In example implementations, the discovered device / mapping data store or database 522 is an embodiment of the discovered device / mapping data store 435. Figure 9

[0118] In the example branch of the message flow 500 represented by reference numeral 525, the DCHP server 510 can communicate 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, and the network node manager and / or DNS server 528 can update 530 the mapping database 522 with an indication of the new association between the device's identity and the IP address assigned to the device 502 (and / or the respective associations between each of the device's data tags and the IP address assigned to the device 502). In example implementations, 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. Figure 10 Additionally or alternatively, the device 502 can communicate an indication of the new association between the device's identity and the IP address assigned to the device 502 (and / or the respective associations between each of the device's data tags and the IP address assigned to the device 502) to the network node manager and / or DNS server 528, as represented by reference numeral 532 in Figure 11 , such that the mapping database 522 is updated accordingly (reference numeral 535). ​

[0119] Importantly, System 400 can provide capabilities for "plug and play" devices, such as... Figure 11 Example message stream 550 is shown. Figure 11 In this context, device 552 (e.g., "device A") physically arrives at a location in the process control plant or automation network. Device 552 will be installed at that location and will operate during operation to control the industrial process. Device 552 can be a highly general-purpose device, such as one of the highly general-purpose field devices 10, D1-D4, and Dn, or device 552 can be a conventional device, such as device D5 to be connected to the node communication network 402 via adapter 415 and APL component 410. Therefore, in the case where device 552 is a conventional device, adapter 415 represents device 552 communicating via the node communication network 402, even when... Figure 9 Adapter 415 is not shown. Generally, message stream 550 can appear in... Figures 8-9 In the embodiment of system 400, or in other systems where nodes of a node communication network are used to manage process control systems or automation networks, reference is also made to... However, for illustrative purposes and not for limitation, the following also refers to... Figure 11 To describe message flow 550.

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

[0121] exist Figure 11In this case, for ease of discussion and not by way of limitation, the embodiment of the system 400 that supports the message flow 550 is arranged such that the network node manager comprises or hosts the DNS service. That is, in this case Figure 11 the network node manager and the DNS service or server are an overall node, e.g., as represented by reference numeral 560. In addition, in this case Figure 9 the DHCP server is a separate node of the node communication network, e.g., as represented by reference numeral 562. In an example implementation, the network node manager / DNS service 560 is an embodiment of the network node manager 432 and the DNS server 438 of the system 400, while the DCHP server 562 is an embodiment of the DHCP server 430 of the system 400. Figure 9 Figure 11

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

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

[0124] Note that although the device 552 is shown as obtaining its assigned IP address by communicating with the network node manager / DNS service 560 in Figure 10 , this is merely one of many possible embodiments. For example, the device 552 can obtain its assigned IP address by utilizing a broadcast discovery DHCP message, e.g., in a manner similar to that performed by the device 502 in the example message flow 500. In another example, the device 552 workbench is provisioned with the IP address of the DHCP server 562, and upon power up 555, the device 552 can directly communicate with the DHCP server 562, thereby requesting and / or obtaining an IP address and associated parameters for the device 552. Of course, other embodiments are possible. Figure 11

[0125] Further reference is made to Figure 11 While the device 552 remains "plugged in" or connected to the node communication network 402, the network node manager / DNS service 560 tracks and updates the status and / or condition of the device 552 within the discovered device or map database (e.g., the discovered device / map database 435, which is shown in Figure 11 as integrated with the network node manager and DNS service 560). In the message flow 550, the network node manager / DNS service 560 polls the device 552 (e.g., periodically, on demand, when triggered, etc.), and receives a current operating status from the device 552 in response to the polling, e.g., as represented by message exchange 578. For example, the network node manager / DNS service 560 can poll each device it is aware of (e.g., via the discovered device or map database) to obtain an update of the device status. Additionally or alternatively, Figure 11 ​(Not shown in the image), device 552 can independently provide its current status and / or condition to network node manager / DNS service 560, for example, periodically and / or when the device's status and / or condition changes (e.g., a fault is detected, device 552 undergoes diagnostics, restart, etc.). Alternatively or alternatively, a third-party device can provide updates on the status and / or condition of device 552 to network node manager / DNS service 560 (also not shown in the image). Figure 11 As shown in the diagram, this includes situations such as when a diagnostic tool takes device 552 offline for diagnostic purposes, or when a security manager (e.g., security manager 440) detects a security anomaly related to device 552 that needs to be mitigated and affects the device's state, etc. In any case, the network node manager / DNS service 560 updates the status and / or condition of device 552 in the discovered device database.

[0126] When device 552 connects to node communication network 402, other devices or nodes in network 402 can discover device 552 and establish communication with it (e.g., the "...ready to use" part of "plug and play"). For illustration, consider an example scenario where device 552 is a field device that generates data during operation of a process control system or automated plant. In this scenario, field device 552 and controller device 580 (e.g., ...) Figure 11The "Device B") is included in a process control loop that operates during run-time of an industrial process plant or automation network to control an industrial process. The configuration of the process control loop, the field devices 552, and the controller 580 are stored in the configuration database 420, and each of the field devices 552 and the controller 580 have been provisioned with its device tag or identification (e.g., as indicated in the configuration database 420) and assigned a unique IP address by the DHCP server 562, respectively. Further, the controller 580 stores (and executes during run-time) one or more control modules or routines that have been configured to operate on data generated by the field devices 552, where such generated data is 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., the hosts). The configuration of the controller 580 and the configuration of the control modules or routines that the controller 580 will execute are defined within the configuration database 420 and downloaded to and / or otherwise provided to the controller 580 for storage and execution during run-time operations. As such, the controller 580 is aware of the device tags and / or data tags associated with the field devices 552 (e.g., as provided in the downloaded configuration); however, the controller 580 does not have a priori knowledge of the IP addresses that have been assigned to the field devices 552 within the node communication network 402.

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

[0128] In embodiments, upon receiving the query 582, the DNS service 560 can authenticate the controller 580 and the field device 552 using their respective security credentials (e.g., keys, certificates, etc.). For example, the DNS service 560 can authenticate the controller 580 and / or the field device 552 by utilizing the corresponding security credentials that have been stored in the discovered device database 435, by querying the security manager 440 to authenticate, validate, verify, etc.

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

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

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

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

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

[0134] Of course, the client devices and host devices can utilize their respective security credentials or information to establish a communication session through the node communication network 402, e.g., in a session establishment 588 as shown. For example, in addition to providing the client devices and host devices with their respective security credentials during bench provisioning, the security manager 440 can also manage the respective keys and verify the certificates after provisioning, e.g., when the devices connect to the network 402 and / or when the devices remain connected to the network 402. If a device fails to successfully validate or be successfully verified, the device can be quarantined and prevented from communicating with other nodes of the node communication network 402 until the security credentials and / or information of the device have been resolved, e.g., manually. Figure 12

[0135] Such security techniques advantageously allow for easy replacement of physical devices. For example, a physical replacement device need only utilize security credentials that have been provisioned into the device it is replacing for bench provisioning. Thus, when the physical replacement device is identified within the process control system by using the device tag and security credentials of the previous device, the physical replacement device will automatically be configured with the same settings as the device it is replacing and can be plug-and-play using the techniques described herein.

[0136] Figure 9 A block diagram illustrating an example security architecture 600 is shown, which illustrates at least some of the security techniques and / or aspects of a system for managing nodes of a node communication network of an industrial process plant or automation system, such as those described elsewhere herein. The security architecture 600 can be used in connection with the system 400 of FIG. 4 or other suitable system. For example, the security architecture 600 can be used to secure the highly versatile field device 10 of FIG. 1, and / or the nodes of the system 400 of FIG. 4. Figure 1 Figure 8 Figure 8 ​​​​The discussion may involve the combination or collaboration of any one or more security features. However, for illustrative purposes and not for limitation, reference may be made while... Figure 9 Safety features and Figure 12 The system 400 is used to describe the architecture 600.

[0137] like Figure 9 As shown, architecture 600 includes a security manager 605, which can communicate with host device 608 and client device 610 for security purposes. In the example implementation, security manager 605 is... Figure 12 In an embodiment of security manager 440, 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. Figure 11 In the example shown, client device 610 is a consumer of data generated or produced by host device 608 during the operation of devices 608 and 610 in an industrial process plant or automation network. For example, host device 608 could be... Figure 11 The field device 552, and the client device 610 can be... Figure 12 The controller is 580.

[0138] Safety manager 605 includes supply engine 612, which generates or otherwise determines appropriate safety credentials for such devices during workbench supply of equipment to be connected to node communication network 402 in an industrial process plant or automation system, such as when such equipment has not yet been powered on for operation within the industrial process plant or automation system, and when such equipment is not connected to network 402. Supply engine 612 records or stores the credentials for supplying these devices in credential data storage 615. Typically, workbench supply is performed when such equipment is in the field of the process plant or automation system; however, workbench supply can be performed at any time before such equipment is powered on for connection to node communication network 402, such as when such equipment is in a manufacturing plant, at an assembly point, etc.

[0139] The provisioning engine 612 operates in conjunction with a workbench provisioning application 618, which can be provided via a user interface of the security manager 605 and / or can be otherwise exposed to or provided at a user interface of other devices (e.g., handheld computing devices or other types of tools) used to manage provisioning. For example, the security manager 605 can download an instance of the workbench provisioning application 618 to various user-operated computing devices or tools, the security manager 605 can host the workbench provisioning as a service accessible by various user-operated computing devices or tools, and so on. Generally, the workbench provisioning application 615 provides user access to the security manager 605 for defining, generating, viewing, and managing device security credentials and / or for performing other tasks related to provisioning security credentials into devices.

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

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

[0142] The host device 608 stores one or more routines or applications 622 on one or more of its memories that, when executed by one or more processors of the host device 608, enable the host device 608 to communicate with the security manager 605. Likewise, the client device 610 stores one or more routines or applications 625 on one or more of its memories that, when executed by one or more processors of the client device 610, enable the client device 610 to communicate with the security manager 605. For example, the host device 608 can include a provisioning routine 622a that obtains a device identification of the host device 608 (e.g., a device tag of the host device 608, any associated data tags, and so on) and associated security credentials of the host device 608 from the provisioning engine 612, e.g., during workbench provisioning of the host device 608. The information obtained by the provisioning routine 622a is stored in one or more memories of the host device 608 (e.g., in a secure memory of the host device 608) and is used by the host device 608 to communicate with the security manager 605, e.g., to request security credentials, to provide security credentials, and so on. Figure 8The host device 608 can include a provisioning routine 622a that obtains a device identification (e.g., a device tag, any associated data tag, etc.) of the host device 608 and / or associated security credentials of the host device 608, for example, during commissioning of the host device 608. The information obtained by the provisioning routine 622a is stored in one or more memories (not shown) of the host device 608. In example implementations in which the host device 608 is a highly versatile field device, such as the highly versatile field device 10, for example, the provisioning routine 622a can include the device provisioning functionality 314, and the obtained device identification and / or security credentials can be stored in the secure program memory 308.

[0143] Similarly, the client device 610 can include a provisioning routine 625a that obtains a device identification (e.g., a device tag, any associated data tag, etc.) of the client device 610 and associated security credentials of the client device 610, for example, during commissioning of the client device 610. Additionally, the provisioning routine 625a of the client device 610 can also obtain respective device identifications (e.g., device tags, associated data tags, etc.) of any host devices (including the host device 608) that generate runtime data that the client device 610 consumes and operates on during runtime. The information obtained by the provisioning routine 420a is stored in one or more memories (not shown) of the client device 610.

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

[0145] Note that, in the example implementation of the host device 608 as a highly versatile field device, such as the highly versatile field device 10, the host device 608 can include the device provisioning functionality 314 and the secure communication feature 312, and the obtained device identification and / or security credentials can be stored in the secure program memory 308.​Figure 13 In particular embodiments, the applications or routines 622a, 622b, 622c, 628 of the host device 608 are shown as separate and distinct applications or routines, however, this is for clarity of discussion only. In practice, the functionality of the host device applications / routines 622a, 622b, 622c, 628 can be implemented using fewer or a greater number of separate and distinct applications or routines. Similarly, the functionality of the client device applications / routines 625a, 625b, 625c, 630 can be implemented using fewer or a greater number of separate and distinct applications or routines, and the various functionality provided by the security managers 612, 615, 620 can be implemented using fewer or a greater number of separate and distinct engines, applications, or routines.

[0146] Turning now to Figure 13 In some embodiments, the network of nodes 402 can include a plurality of network node managers 432, at least some of which can be redundant and serve as backup network node managers, and / or at least some of which can be distributed in nature. For example, Figure 9 An arrangement of an example system 650 for managing nodes of a network of nodes of an industrial process control or automation system is shown, where the system 650 includes a plurality of distributed network node managers 652, 655, 658. The system 650 can be an embodiment of the system 400, and for clarity of illustration, is discussed herein concurrently with reference to Figure 13 However, it will be appreciated that other systems for managing nodes of a network of nodes of an industrial process control or automation system can readily incorporate a plurality of redundant and / or distributed network node managers 652-658 using the principles and techniques described herein.

[0147] As Network resource managementAs shown, each network node manager 652-658 is communicatively connected to other types of management nodes of the system 650, such as one or more DHCP servers 662, one or more DNS servers 665, one or more security managers 668, one or more log servers 670, etc., via the backbone of the node communication network 660. Moreover, each network node manager 652-658 respectively 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 way, each network node manager 652-658 manages, e.g., via its respective mapping database, the device tag, IP address or endpoint identification, status, and optionally security information of each host device included in its respective set of host devices 672, 675, 678. In this way, a query received at a first network node manager for an endpoint identification of a device not managed by the first network node manager can be routed via the node communication network 600 to another network node manager that manages the device. In some embodiments, one or more of the network node managers 652-658 can share (and update) at least a portion of its respective mapping database with at least one other of the node managers 652-658, such that at least one other of the node managers can service queries for non-managed devices without having to dialog with the managing network node manager.

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

[0149] Figure 3

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

[0151] It is also important that an IP-based network can be configured to support a variety of topologies. For example, the node communication network 80 should support traditional plant automation or process automation topologies, such as those shown in Figure 4 , which include highly versatile field devices 82 and traditional field devices 224 coupled to the APL network architecture 892 through adapter devices 130. The communication network 80 should support edge topologies, such as those shown in Figure 5 , which run on top of or in parallel with traditional plant or process automation topologies and support the integration of planning information such as scheduling, asset monitoring, analytics, simulation, and other functions. That is, the communication network 80 should be configurable to facilitate communication between, on the one hand, highly versatile field devices 82 and / or traditional field devices 224 (via 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. Still further, the communication network 80 should support cloud topologies, such as those shown in Figure 6 , which can run in parallel with automation instrumentation and can be used, for example, for condition-based monitoring (e.g., energy monitoring, device and equipment monitoring, and process monitoring). In such a system, as described above, the monitoring system can communicate data from the plant 100 to one or more cloud-based applications 182, which perform analytics and communicate data and / or recommendations back to users and / or elements in the process control network 200, such as controllers 140.

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

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

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

[0155] ​As also noted above, the communication network 80 supports both client / server and publish / subscribe communications, and in addition to facilitating communication between field instruments and applications, implements Internet connectivity between Open Platform Communications (OPC) Unified Architecture (UA) servers (e.g., field instruments) and OPC UA clients (e.g., controllers), each of which in various instances can be a client or a server. The communication network 80 supports both User Datagram Protocol (UDP) and Transmission Control (TCP) communication modes. In client / server communication sessions, directed communication occurs between a host and a single specific device. The addresses of both the source and destination devices are specific and explicit, and all client / server requests specify the request and response data to be transferred. At the same time, in publish / subscribe communications, new values (e.g., measurement values, condition values, etc.) are transferred from servers (e.g., devices) only when needed. For example, with respect to a parameter published from a highly generic field device 82 to a controller 140, the parameter can be frequently transferred as needed to allow control actions to correct for unmeasured disturbances or responses to setpoint changes.

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

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

[0158] An industrial IoT (Internet of Things) platform can also benefit from the implementation of a communication network 80 as described herein. An industrial IoT platform for continuous condition monitoring can be deployed to monitor various parameters within a process plant 100. Such a system can monitor functions such as energy consumption, equipment and device functionality / performance, and process performance. Such a system typically operates using various parameters collected from a large number of devices in the overall process plant 100 as input. In a traditional system, the industrial IoT platform performing continuous monitoring receives data indirectly from field devices via controllers 140 and / or one or more other devices such as operator stations 206 or plant asset management devices 145. However, in the system described herein, these industrial IoT platforms can receive data directly from devices as data sources without needing to relay the data through intermediate devices either by direct request or by programming the intermediate devices using publish / subscribe (i.e., by subscribing to the data).

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

[0160] As will be appreciated, implementing traditional monitoring and control data as well as other non-traditional data such as described in the use cases above on the same network can result in problems such as latency and dropped packets that do not exist in the case of traditional control networks that only transfer data between individual devices and controllers and on which such data is scheduled, specifically requested by a controller, or otherwise strictly controlled for transmission in order to ensure that high-priority, latency-sensitive data is received at the controller from the devices (or at the devices from the controller) in a timely manner. One challenge is to accommodate both scheduled network traffic (e.g., monitoring and control data transferred between field devices and controllers) and non-scheduled traffic (e.g., condition monitoring and other data transferred between devices and applications) on the same network.

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

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

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

[0164] TSN-based network management

[0165] TSN-based network management requires management of 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 communication of both managed and unmanaged network traffic. As part of this networking scheme, TSN network devices and applications need to be aware of priorities, and network resources must be allocated in a manner that allows time-critical data to be transmitted with minimal blocking when transmitting data from a source to a destination.

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

[0167] Table 1

[0168]

[0169]

[0170] However, when implemented in a factory automation or process control plant, such as the factory 100, priorities need not be assigned based on the same types of traffic that can exist in an average network. Rather, by way of example and not limitation, priorities can be assigned based on specific types of network traffic that can exist in a factory automation or process control environment. Table 2 is an example list of traffic types and priorities, although it can be appreciated that the traffic types associated with each priority can be assigned according to the needs of the system operator.

[0171] Table 2

[0172] Traffic type 0 (lowest) Background Best effort 1 Excellent effort 2 Device condition and health monitoring 3 Low priority control (higher delay tolerance) 4 High priority control (lower delay tolerance) 5 Inter-network control 6 7 (highest) Network control Figure 15

[0173] Referring to Table 2, some data used by a factory automation controller or process controller can be more time sensitive than other data. Those familiar with such automation processes will appreciate that such data can be more time sensitive because the data is part of a control loop that is executed frequently, or where small changes can have a disproportionately large impact very quickly, or because the data is part of a safety system that must respond quickly to events in order to, for example, prevent or mitigate a dangerous situation. Other data used by the controller can be less sensitive to increased latency, for example, because it is part of a control loop that is executed less frequently, or is of a process that exhibits sudden changes relative to not responding to small disturbances.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0187] With slight modification of this example, the network resource management component 800 can still facilitate the data frame 836 to arrive earlier than the data frame 838 if the data frames 836 and 838 each have the same priority, or if the data frame 836 has a lower priority than the data frame 838, for example, if the data frame 836 is scheduled network traffic and the data frame 838 is unscheduled network traffic. For example, the data frame 836, although having a lower priority, can contain data from a highly generic field device 104 that is desired by the controller 140 at a particular time. In this case, the network resource management component 800 can configure the communication network 80 such that the data frame 836 arrives at the endpoint system 844 (e.g., the controller 140) before the higher priority data frame 838. The network resource management component 800 can configure the gate control lists 828 of the various egress ports 818 via the time-aware shaper 810 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 the queue 894B in the network switch 846) remain closed to block transmission of the data frame 838 until the transmission of the data frame 836 is complete.

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

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

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

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

[0192] Non-TSN-based network management

[0193] In embodiments where the network resource management component 800 is not based on time sensitive networking (TSN) protocols, network traffic can be managed by controlling traffic flows 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 adjusts network traffic flows between various devices in the network 80, particularly in the network switches. Devices and hosts communicate with the network manager 814 in order to allocate traffic, for example, by requesting publish-subscribe traffic flows. The network manager 814 then controls traffic through the switches by enabling and disabling various ports of the switches and by throttling network traffic through the ports. In such embodiments, network traffic can be identified, for example, by traffic source (i.e., sender), destination (i.e., receiver), and application type.

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

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

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

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

[0198] Figure 17

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

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

[0201] To this end, devices (and possibly applications) operating on the communication network 80 can have a predefined list of parameters and other data available for subscription. Figure 17 An example server 848 (e.g., a highly versatile field device 82, an application, a controller 140, etc.) and an example application 874 (e.g., another highly versatile field device 82, a controller 140, or another application) are shown. While the server is shown as a highly versatile field device, and thus various elements are shown that can not be present in a controller (e.g., a sensor) or an application (e.g., a sensor, a communication circuit, etc.), the application is shown as a separate entity from the server, and thus various elements are shown that can not be present in a highly versatile field device or a controller. Figure 17 The server is shown as a highly versatile field device, and thus various elements are shown that can not be present in a controller (e.g., a sensor) or an application (e.g., a sensor, a communication circuit, etc.), but the application is shown as a separate entity from the server, and thus various elements are shown that can not be present in a highly versatile field device or a controller. Figure 17 The general concept illustrated in the middle illustrates a set of publish lists 858 stored in the server 848. In particular, turning to the left side of the middle, the server 848 is shown as having a set of publish lists 858, each of which is associated with a different application 874. Each of the publish lists 858 is shown as having a list of parameters that the server 848 can publish to the associated application 874. The right side of the middle shows the same set of publish lists 858, but in this case, the server 848 is shown as having a set of subscribe lists 860, each of which is associated with a different application 874. Each of the subscribe lists 860 is shown as having a list of parameters that the server 848 can subscribe to from the associated application 874. Figure 18The server 848 (e.g., a highly general field device 82) includes one or more sensors 851 (e.g., temperature sensors, position sensors, pressure sensors, flow sensors, etc.). The sensors 851 send data to a processor 852, which can monitor data from the sensors, store data from the sensors, execute process control modules to implement a portion of a control strategy, and / or communicate data to one or more other devices (e.g., controllers) or applications. The server 848 includes communication circuitry 854 to facilitate communication with various devices and applications via the communication network 80. The server 848 also includes a memory device 850, which can include a parameter store 856 for storing various parameters of the server 848 (e.g., data from sensors, publish subscriptions, etc.). The server 848 also includes in the memory 850 various publish lists 858, at least some of which are predefined and determined by the device or application manufacturer.

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

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

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

[0205] Still further, the server 848 can store one or more custom publication lists 864 in the memory 850. The custom publication lists 864 can be defined, for example, for a particular device or application or group of devices or applications in the plant 100. For example, in most cases, the controllers 140 can subscribe to a manufacturer-defined publication list 860 or a user-defined publication list 862 for a particular type of device (e.g., a particular valve type) in the associated process control network 200, but can require (or not require) one or more particular parameters for a group of devices (e.g., the same particular valve type) for the process control network 200. Accordingly, a custom publication list 864 can be defined for the group of devices. Similar to the manufacturer-defined publication lists 860 and the user-defined publication lists 862, the custom publication lists 864 can include zero, one or more monitoring and control publication lists 868, condition monitoring publication lists 870, and publication lists for applications other than monitoring and control or condition monitoring.

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

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

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

[0209]

[0210]

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

[0212]

[0213]

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

[0215]

[0216]

[0217]

[0218] When a client 874 wants to subscribe to a server 848, during the initial handshake between the client 874 and the server 848, the client discovers and selects a particular one of the available publication lists 858 for the server. Figure 18An example communication flow diagram 876 showing initial handshake interactions 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 embodiments, the initial "hello message" includes an indication of the list of categories of publications (e.g., monitoring and control, condition monitoring, etc.) that the client 878 wishes to monitor. In response to the initial "hello" message 882, the server 880 responds with its own "hello" message 884. In embodiments, the server's "hello" message 884 includes an indication of the list of publications 858 in the categories indicated by the client 878. In some embodiments, the indication of the list of publications 858 sent by the server 880 includes the metadata 872 for each of the list of publications 858 in the categories indicated by the client 878, while in other embodiments, the indication of the list of publications 858 sent by the server 880 includes the publication list definitions for the list of publications 858 in the categories indicated by the client 878.

[0219] While shown in ​ as occurring over two messages 882 and 884, in alternative embodiments, the initial exchange of messages can occur over more than two messages. For example, while less efficient, the client 878 can send a "hello" message to the server 880, in response to which the server 880 can acknowledge its presence with its own "hello" message. The client 878 can respond to the acknowledgment sent by the server 880 by sending a request for publications in a particular list of publication categories. In response to the request, the server 880 can send an indication of the list of publications 858 available in the specified list of publication categories. Of course, other communication arrangements are similarly possible and conceivable.

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

[0221] When implemented in software, any of the applications, modules, etc. described herein can be stored in any non-transitory computer-readable medium, such as a magnetic disk, laser disk, solid-state memory device, molecular memory storage device, or other storage medium, and processed by a computer or processor. While the example systems disclosed herein are disclosed as including software and / or firmware executed on hardware, it is noted that such systems are merely illustrative and not limiting all examples encompassed by this disclosure. For example, it is contemplated that any or all of these hardware, software, and firmware components can be implemented or provided in a combination of hardware and software, or entirely in hardware, entirely in software, or entirely in firmware. Thus, although the example systems described herein are described as being implemented or provided in software, it is noted that the examples provided are merely illustrative and not limiting.

[0222] Thus, although the application has been described with reference to specific examples, it will be apparent to those skilled in the art that many modifications can be made within the spirit and scope of the application, and it is intended to claim all such modifications as fall within the scope of the application. It will be appreciated by persons skilled in the art that numerous variations and / or modifications can be made to the embodiments described herein. It is to be understood that any such variations and / or modifications do not depart from the spirit or scope of the present application.

[0223] The particular features, structures, and / or characteristics described can be combined in any suitable manner in one or more embodiments, including to form alternative embodiments, including structure and / or functionally equivalent structures and / or functions. Moreover, while particular embodiments are described, combinations of these embodiments can be explicitly contemplated. Additionally, features described herein can be implemented in hardware, software, firmware or a combination thereof, and can be implemented as a computer program product comprising a computer usable medium having stored computer program code means thereon. The particular features, structures, and / or characteristics described can be combined in any suitable manner in one or more embodiments, including to form alternative embodiments, including structure and / or functionally equivalent structures and / or functions. Moreover, while particular embodiments are described, combinations of these embodiments can be explicitly contemplated. Additionally, features described herein can be implemented in hardware, software, firmware or a combination thereof, and can be implemented as a computer program product comprising a computer usable medium having stored computer program code means thereon.

Claims

1. A control system, comprising: A first communication network, set up in a process or plant environment, is configured to support packet-addressable messages; Multiple field devices are coupled to the first communication network, wherein at least one of the multiple field devices includes: Field device hardware components that interact with process variables in a process or plant to perform physical functions in the process or plant environment; The processor is coupled to the field device hardware components and the first communication interface; A computer-readable storage device coupled to the processor; An operating system, stored in the memory and implemented on the processor, performs communication via the first communication interface; and One or more communication applications are stored in the memory and executed on the processor and managed by the operating system, wherein the one or more communication applications use addressed digital messages to implement communication on the first communication network; The second communication network is configured to support packet-addressable messages; An interface device is coupled between the first communication network and the second communication network to transmit addressing messages between the first communication network and the second communication network; A plant or process controller, coupled to the second communication network, is configured to communicate with at least one of the field devices via packet-addressed messages through the second communication network, the interface device, and the first communication network; and A second computer device, coupled to the second communication network, is configured to communicate with at least one of the field devices via packet-addressed messages, independently of the plant or process controller, through the second communication network, the interface device, and the first communication network.

2. The control system according to claim 1, wherein, The interface device is a network switch.

3. The control system according to claim 1, wherein, The interface device includes a power source that applies a power signal to the first communication network, and wherein the at least one field device in the field devices includes a power source that uses the power signal to power the processor of the at least one field device in the field devices.

4. The control system according to claim 3, wherein, The second communication network supplies power to the interface device at a higher level than the power applied by the interface device on the first communication network.

5. The control system according to claim 4, wherein, The second communication network provides the same type of protocol message sending and receiving as the first communication network.

6. The control system according to claim 1, wherein, The second communication network provides power to the interface device, and the interface device supplies power to the first communication network with a lower power signal than the second communication network.

7. The control system according to claim 1, wherein, The second communication network implements a different physical layer than the first communication network.

8. The control system according to claim 1, wherein, The first communication network is a two-wire communication network that provides both power and communication via a pair of wires.

9. The control system according to claim 1, wherein, The first communication network includes an Advanced Physical Layer (APL) network.

10. The control system according to claim 1, wherein, The second communication network includes Ethernet.

11. The control system according to claim 1, wherein, The second computer device enables equipment maintenance applications.

12. The control system according to claim 1, wherein, The second computer device implements data recording applications.

13. The control system according to claim 1, wherein, The second computer device enables environmental monitoring applications.

14. The control system according to claim 1, wherein, The second computer device enables data analysis applications.

15. The control system according to claim 1, wherein, The second computer device implements email applications.

16. The control system according to claim 1, wherein, The operating system of at least one of the field devices implements a lower-level Internet Protocol stack to create and process messages on the first communication network, and implements a higher-level protocol stack for each of a plurality of communication processes, and uses different communication processes among the plurality of communication processes to create messages for the plant or process controller and the second computer device.

17. The control system according to claim 16, wherein, The operating system implements a first higher-level protocol stack associated with a first communication protocol for the first communication process in the communication process, and implements a second higher-level protocol stack associated with a second communication protocol for the second communication process in the communication process.

18. The control system according to claim 17, wherein, The first communication protocol and the second communication protocol are different communication protocols.

19. The control system according to claim 18, wherein, The first communication protocol is a process control communication protocol, and the second communication protocol is a general communication protocol.

20. The control system according to claim 1, wherein, The one or more communication applications communicate with the plant or process controller and the second computer device by sending and receiving publish / subscribe messages through the communication network.

21. The control system according to claim 1, wherein, The one or more communication applications use different communication processes running simultaneously in the field device to communicate with the plant or process controller and the second computer device.

22. The control system according to claim 1, wherein, Both the plant or process controller and the second computer device are directly coupled to the second communication network.

23. The control system of claim 1 further includes a third communication network coupled to the second communication network via a firewall or gateway device.

24. The control system according to claim 23, wherein, The second computer device is directly coupled to the third communication network, and is also coupled to the second communication network via the firewall or gateway device.

25. The control system according to claim 24, wherein, The third communication network is a public communication network.

26. The control system according to claim 24, wherein, The third communication network includes Internet-based communication networks.

27. The control system according to claim 1, wherein, The second communication network includes an Internet-based communication network.

28. A method for performing control and communication in a process or plant environment, comprising: Configure the first communication network in the process or plant environment to support packet-addressed messages; A plurality of field devices are connected to a first communication network, wherein at least one of the plurality of field devices includes field device hardware components that interact with physical phenomena in the process or plant environment to perform physical functions in the process or plant environment, a processor coupled to the field device hardware components and the first communication network, a computer-readable storage coupled to the processor, and an operating system stored in the storage and implemented on the processor to perform communication via the first communication network. A second communication network configured to support packet-based addressing messages is coupled to the first communication network via an interface device, the interface device being configured to transmit addressing messages between the first communication network and the second communication network; Configure a plant or process controller coupled to the second communication network to communicate with at least one of the field devices via packetized addressing messages through the second communication network, the interface device, and the first communication network; Configure a second computer device coupled to the second communication network to communicate with at least one of the field devices via packet-addressed messages, independently of the plant or process controller, through the second communication network, the interface device, and the first communication network; and Using one or more communication applications stored in the memory of the at least one field device in the field device, executed on the processor of the at least one field device in the field device, and managed by the operating system of the at least one field device in the field device, to communicate with the process or plant controller and the second computer device via separate packetized addressing messages on the first communication network and the second communication network.

29. The method of claim 28, further comprising: A single basic-level messaging protocol is used on both the first and second communication networks.

30. The method according to claim 29, wherein, The underlying protocol is the Internet Protocol.

31. The method of claim 28, further comprising: The interface device is used to provide power signals to the plurality of field devices via the first communication network.

32. The method of claim 31, further comprising: The power signal is provided through the second communication network, wherein the power signal provided through the first communication network is less than the power signal provided through the second communication network.

33. The method of claim 28, further comprising: The second communication network uses a different physical layer than the one used in the first communication network.

34. The method according to claim 28, wherein, Configuring the first communication network includes using a two-wire communication network that provides both power and communication via a pair of wires.

35. The method of claim 28, further comprising: A device maintenance application is implemented at the second computer device to communicate with at least one of the field devices.

36. The method of claim 28, further comprising: A data logging application is implemented at the second computer device to communicate with at least one of the field devices.

37. The method of claim 28, further comprising: An environmental monitoring application is implemented at the second computer device to communicate with at least one of the field devices.

38. The method of claim 28, further comprising: A data analytics application is implemented at the second computer device to communicate with at least one of the field devices.

39. The method of claim 28, further comprising: A lower-level Internet Protocol stack is implemented at at least one field device in the field devices to send and receive messages via the first communication network, and a first higher-level protocol stack is implemented on top of the lower-level Internet Protocol stack to perform communication with the process or plant controller, and a second higher-level protocol stack is implemented on top of the lower-level Internet Protocol stack to perform communication with the second computer device.

40. The method according to claim 39, wherein, Implementing the first higher-level protocol stack and the second higher-level protocol stack includes using different higher-level communication protocols for the first higher-level protocol stack and the second higher-level protocol stack.

41. The method according to claim 40, wherein, The first communication protocol in the higher-level communication protocol is a process control communication protocol, and the second communication protocol in the higher-level communication protocol is a general communication protocol.

42. The method according to claim 39, wherein, Implementing the first higher-level protocol stack and the second higher-level protocol stack includes using the same higher-level communication protocol for both the first higher-level protocol stack and the second higher-level protocol stack.

43. The method according to claim 28, wherein, Communicating on the first and second communication networks using one or more communication applications stored in the memory of at least one of the field devices includes: communicating with the process or plant controller and the second computer device using publish / subscribe messaging on the first and second communication networks.

44. The method according to claim 28, wherein, Communication on the first communication network and the second communication network using one or more communication applications stored in the memory of at least one field device in the field device includes: using different communication processes running simultaneously in the at least one field device in the field device.

45. The method of claim 28, comprising: The process or plant controller and the second computer device are directly coupled to the second communication network.

46. ​​The method of claim 28, comprising: The process or plant controller is directly coupled to the second communication network, the third communication network is coupled to the second communication network via a firewall or gateway device, and the second computer device is directly coupled to the third communication network.

47. The method according to claim 46, wherein, Coupled to the third communication network, the second communication network includes: coupling a public communication network as the third communication network.

48. The method according to claim 47, wherein, The third communication network includes a cloud-based communication network.

49. The method according to claim 28, wherein, The second communication network includes a cloud-based communication network.

50. A process control or factory automation system, comprising: One or more device networks, each device network including; The field device communication network bus is configured to support packet-addressable messages; One or more field devices are coupled to the field device communication network bus, each field device including: Field device hardware components that interact with process variables in a process or plant environment to perform physical functions in the process or plant environment; The processor is coupled to the field device hardware components and the field device communication network bus; A computer-readable storage device coupled to the processor; An operating system, stored in the memory and implemented on the processor, performs communication via the field device communication network bus; and One or more communication applications, stored in the memory and executed on the processor and managed by the operating system, wherein the one or more communication applications communicate via the field device communication network bus using addressed digital messages; and An interface device, coupled to the field device communication network bus; The second communication network bus is configured to support packetized addressing messages for the interface devices of each device network in the device network. A plant or process controller, coupled to the second communication network bus, is configured to communicate with at least one of the field devices via packet-addressed messages through the field device communication network bus, the interface device, and the second communication network bus to perform control within the plant or process environment; and A second computer device, coupled to the second communication network bus, is configured to communicate independently of the plant or process controller via packetized addressing messages through the field device communication network bus, the interface device, and the second communication network bus, to perform auxiliary activities regarding data from the at least one field device. In this context, the interface device of each device network in the device network transmits addressing messages between the associated field device communication network bus and the second communication network bus.

51. The process control or factory automation system according to claim 50, wherein, The interface device provides power signals on the field device communication network bus.

52. The process control or factory automation system according to claim 50, wherein, The interface device is a power switch.

53. The process control or factory automation system according to claim 52, wherein, One of the one or more device networks includes one or more field switches coupled to the field device communication network bus, and one of the field devices in the one or more device networks is coupled to the field device communication network bus via the field switch.

54. The process control or factory automation system according to claim 52, wherein, One of the one or more field devices is directly coupled to the field device communication network bus.

55. The process control or factory automation system according to claim 50, wherein, The second communication network bus is Ethernet.

56. The process control or factory automation system according to claim 50, wherein, The second communication network bus includes a network bus, which includes a physical layer different from the physical layer used by the field device communication network bus.

57. The process control or factory automation system according to claim 56, wherein, The second communication network bus uses the same communication protocol as the field device communication network bus.

58. The process control or factory automation system according to claim 50, wherein, One of the field devices communicates with the process or plant controller using a first higher-level communication protocol, and communicates with the second computer device using a different higher-level communication protocol.

59. The process control or factory automation system according to claim 50, wherein, One of the field devices communicates with the process or plant controller using a first communication process and with the second computer device using a second communication process, wherein the one of the field devices simultaneously implements both the first communication process and the second communication process.

60. The process control or factory automation system according to claim 59, wherein, One of the field devices uses publish / subscribe communication to communicate with the process or plant controller and also with the second computer device.

Images