Security system for implementing highly versatile field devices and communication networks in control and automation systems

Abstract

A highly versatile process control or factory automation field device is configured with interfaces and communication connection structures as well as security features that enable the field device to operate as a data server that directly or indirectly communicates with and supports multiple different applications or clients while performing standard process and factory automation control functions in a highly secure manner. The security features include a root of trust component, a secure boot component, a secure storage component, a secure communication component, a security audit component, a secure provisioning component, and an endpoint identity component, making the field device communication and operation secure and trustworthy. In addition, various different process control and factory automation network architectures, particularly communication architectures, support the general-purpose field device so that the general-purpose field device can communicate with multiple different client devices or applications (each associated with a different system) via a common communication network infrastructure using the same or different communication protocols in a very secure manner.

Description

Technical Field

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

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

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

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

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

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

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

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

[0009] To support this emerging development of Ethernet-based communication in process control, the FielComm Group has standardized HART-IP as part of the HART7 release. Although HART-IP was initially designed to allow hosts to communicate efficiently with gateways, it has now emerged as a method for devices to communicate directly with I / O servers and hosts / controllers. HART-IP is now used in monitoring, control, diagnostic, and condition monitoring applications. Since HART-IP already has a complete description of the devices available to it, it is a good protocol for the layer above APL. Additionally, another protocol that is seeing widespread support at the device level is OPC Unified Architecture (OPC UA). Although OPC UA itself does not understand device communication and types, significant efforts are being made in this regard to provide some level of support. Although HART-IP and OPC UA may be adopted by the market relatively quickly, they will not be standalone in their use. Other protocols such as EthernetIP and PROFINET are already available on Ethernet and will be able to operate on APL when it is available. Additionally, IT-driven protocols such as MQTT and AMQP will emerge as important protocols as the Industrial Internet of Things (IIoT) gains acceptance.

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

[0011] Furthermore, in addition to control systems, there are other systems that have been developed to support other activities in process plant and manufacturing plant automation environments. Plant Asset Management (PAM) or maintenance systems are typically set up to enable maintenance personnel to perform maintenance activities on equipment in a plant or manufacturing plant setting (such as field devices, but also including other types of equipment). PAM is used to configure and commission equipment, run diagnostics on the equipment once deployed, monitor equipment alarms, and perform a long list of many other functions. Further condition monitoring systems are becoming increasingly common and are being deployed at many sites. Condition monitoring systems can perform various functions, including energy monitoring, equipment and device monitoring, and process monitoring. These condition monitoring systems typically stream data from the plant, perform condition monitoring, and provide feedback recommendations to users and, in some cases, to the control system itself. Similarly, data logging systems exist in plant and manufacturing plant automation settings to collect and record data for later use. For example, energy and monitoring data can be collected by a data logging system in a centralized manner for analysis and to establish an alarm management system, such as if water leakage or energy loss is detected due to a leak or rupture in a pipeline. Similarly, smart metering systems are being implemented in many settings to perform ongoing or continuous metering. Metering can be a critical process in large-scale distributed systems (such as oil and gas fields, pipelines, chemical storage, and finished product storage). For example, in a chemical storage system, it is important to have accurate readings of what materials are present. Smart metering refers to the process of installing smart meter reading systems, reading these meters via a controller or independently via a remote monitoring system, and transmitting the readings to a processing location such as an edge gateway or a central data server. Additionally, environmental monitoring needs to be performed in many settings based on safety considerations, EPA mandates 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 is time-stamped, not affected by daylight saving time adjustments, and secure.

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

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

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

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

[0016] The highly versatile (HV) field devices and network architectures described herein are capable of supporting APL or other Ethernet- or general-IP-based physical layers and various communication protocols operating thereon in a manner that enables the highly versatile field devices to serve as servers for multiple different client devices simultaneously. Additionally, when protocols such as security protocols require additional handshakes, acknowledgments, etc., the highly versatile field devices described herein are capable of nesting protocols within other protocols for use. Further, the highly versatile field devices described herein include configuration capabilities that enable easy configuration of process control systems by supporting multiple I / O types, including packet-based, IP-based, or other advanced protocols such as HART-IP, OPC UA, Ethernet, and other protocols. The highly versatile field devices and associated network architectures described herein support a hybrid physical layer and multi-protocol support, which can be used to achieve improved control while providing direct support for non-control systems, as the highly versatile field devices described herein are capable of supporting request / response, publish / subscribe, event-based communication, report communication, and streaming communication, which greatly aids in supporting the combination of control and industrial Internet of Things (IIoT) applications (also commonly referred to herein as monitoring systems) interested in measurement and actuator data, their capabilities, their diagnostics, and information that can be determined by combinations of these measurements, capabilities, and diagnostics.

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

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

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

[0020] In an embodiment, a method at a highly versatile (HV) field device of a process control or automation system includes: detecting, by the HV field device when the HV field device is powered on, that the HV field device is connected to a node communication network via a communication interface of the HV field device, the node communication network having nodes identified by respective endpoint identifiers within the node communication network. Additionally, the method includes transmitting, by the HV field device via the node communication network, a request for an endpoint identifier to a DHCP server of the node communication network, the HV field device being identified within the node communication network by means of the endpoint identifier, wherein the request includes an indication of a tag or identifier of the HV field device, and the tag or identifier identifies the HV field device within the process control automation or automation system; and obtaining, by the HV field device via the node communication network, the endpoint identifier that has been assigned to the HV field device. Further, the method includes establishing, by the HV field device on the node communication network and by using the endpoint identifier assigned to the HV field device, a communication session with another device, wherein the other device is a consumer of data indicative of a physical function performed by one or more physical components of the HV field device during runtime operation of controlling an industrial process in the process control or automation system. Additionally, the method includes, during runtime operation of the process control or automation system, transmitting, by the HV field device via the communication session, data indicative of a physical function performed by one or more physical components of the HV field device to the other device so as to control the industrial process.

[0021] Further, using a highly versatile (HV) field device in a node communication network, in combination with the above device discovery method, benefits from a complex network resource management scheme that can be implemented in the node communication network. In an embodiment, a controller controls physical devices in an industrial process or a factory automation plant, the physical devices performing operations on one or more raw materials to convert the one or more raw materials into products. The HV field device is coupled to the controller and receives commands from and transmits parameters to the controller. The communication network includes an Advanced Physical Layer (APL) infrastructure—APL cabling, one or more APL power switches that provide connectivity and power via the APL cabling, and one or more APL field switches that receive power from the one or more APL power switches and distribute power and connectivity to the HV field device, and further includes a network resource management component configured to manage network resources on the communication network to facilitate communication of network traffic on the network, the network traffic including managed network traffic known to the network resource management component and unmanaged network traffic unknown to the network resource management component.

[0022] In various embodiments, the network resource management component implements a deterministic management scheme, while in other embodiments, the network resource management component implements a non-deterministic management scheme. Some embodiments of the network resource management component that implement a deterministic management scheme implement a time-sensitive networking (TSN) network management scheme, where both TSN-based devices and non-TSN devices can operate on the communication network. In an embodiment, the deterministic network resource management component allocates network resources such that time-critical data is allowed to be transmitted between a source and a destination with minimal blocking. In some embodiments, the network resource management component includes one or more outbound ports. Each outbound port includes a plurality of queues, and each queue accommodates a corresponding class of network traffic. A queue selection unit for each outbound port is configured to receive input data and determine which queue to place the input data in, 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 opened. If the gate is closed, the transmission of data is blocked even if the transmission selection algorithm has selected the data for transmission, so that priority can be given to data other than the data with the highest assigned priority. In an embodiment, 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 an embodiment, to optimize the allocation of network resources on the network when a new device joins the communication network, partially by controlling one or more APL field switches and / or power switches. In an embodiment, a certain percentage of the network resources is allocated to unmanaged network traffic, and when the percentage of the detected unmanaged traffic exceeds the allocated percentage, the network resource management component adjusts the switch.

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

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

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

[0027] In other embodiments, an HV field device includes a field device hardware component that interacts with a process phenomenon, a communication interface communicatively coupled to one or more external devices via an external communication network, a processor coupled to the field device hardware component and the communication interface, and a computer-readable memory coupled to the processor, wherein the computer-readable memory includes a secure storage for storing boot firmware to be executed when the processor is started. Additionally, the field device includes an operating system stored in the memory and implemented on the processor to perform communication via the communication interface, 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 implement communication via the communication interface. The field device further includes a root of trust component that includes a unique device identity stored in the computer-readable memory, and the field device includes one or more security keys or security certificates stored in the computer-readable memory that can be used to perform secure communication with external devices via the communication interface. Additionally, the processor implements a secure boot procedure that provides protection against tampering of the boot firmware at startup, generates an endpoint identity characteristic that includes a device identifier derived from the unique device identity, and uses an encryption algorithm to encrypt one or more of the data communications performed by the device, the data stored in the device, and the data used as in the device. Similarly, the communication applications use one or more security keys or certificates to perform communication with external devices via the communication interface. The processor can use the unique device identity to authenticate communication between the external device and the field device, and to authenticate the boot activities performed by the processor in the field device.

[0028] In some cases, the boot firmware can be directly stored and executed from a non-writable location in a computer-readable memory. Additionally, the processor can load the boot firmware to be executed by the processor from a protected memory region of the computer-readable memory into a protected memory store reserved for the execution of the boot firmware of the processor. Further, the processor can derive an internal key from a unique device identity, and the processor can perform self-tests and code verification to verify the code identity and establish a set of keys for secure communication with an external device via a communication interface. The processor can execute the boot firmware using a digitally signed binary string or a digitally signed boot file, and can verify the boot file using a digital key verified by a root-of-trust component. The processor can execute the boot firmware using a secure or trusted boot loader or a secure microprocessor and / or using boot file encryption. The processor can use a root-of-trust component to check the validity of the boot firmware, and can perform a secure firmware update by verifying an incoming communication payload before storing or applying the incoming communication payload, which is intended to replace an existing firmware image, to the computer-readable memory. Additionally, if the verification of the new boot image code fails, the processor can perform a secure firmware update by executing a fallback to a known and verified boot firmware image. Further, the processor can perform a secure communication connection to cloud resources by implementing a secure boot process that ensures that the field device authenticates with an external device whenever the field device attempts to connect to the external device using a secure key or certificate.

[0029] In addition, the secure storage device may include off-chip flash memory, and the processor may copy one or more software applications or operating systems into the SRAM or external DDR memory for execution after the processor is booted. Further, the encryption algorithm may include standards-based symmetric cipher suites and / or hash functions and / or random number generators. Further, the processor may store and execute a security audit application that enables monitoring of field devices. The security audit application may perform logging and provide audit log information to an external server. The audit log information may include an event log, and the security audit application may capture system and security events and use an external server such as a Syslog server to transmit the captured events to a host. In some cases, the security audit application may store a local audit log in a computer-readable memory, and the audit log may include one or more of the following: the last time / date the external server was powered on; the last time / date the security credentials were modified; the external server status; a list of 128-entry session digests in a cycle; and timestamps. Further, the security audit application may store a session digest for each communication session with an external device, and the session digest may include one or more of the following: the client identity including the IP address and port number, the connection / disconnection time / date for the client, the start / end configuration change counter, the session status, and a communication counter indicating the number of published, requested, and response PDUs. The security application may perform push audit messaging by pushing messages to an external security information and event management system. Also, to ensure security, the provisioning information may be stored by the device manufacturer in a computer-readable memory, and the provisioning information may include one or more of the following: the device label, a pre-shared security key and / or certificate, the security server hostname and port, the DNS server name, the default port number listened on by the field device, and the static IP address and mask. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

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

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

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

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

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

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

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

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

[0041] Figure 12 Figure 10 shows a block diagram of an example security architecture of a node management system for a node communication network such as the node communication network shown in Figure 9 Figure 7.

[0042] Figure 13 Figure 11 shows a block diagram of a node management system of a node communication network including multiple network node managers.

[0043] Figure 14 Figure 12 shows a block diagram of a network management component configurable to manage network services in the disclosed communication architecture.

[0044] Figure 15 Figure 13 shows Figure 14 a block diagram of an example outbound port of a network device managed by the network management component.

[0045] Figure 16 is through Figure 14Diagram of two example data streams of a controlled network managed by a network management component.

[0046] Figure 17 A block diagram showing various components depicting a publish - subscribe communication architecture.

[0047] Figure 18 Shown by Figure 17 An example communication flow diagram employed by the publish - subscribe communication architecture of Detailed Description of the Invention

[0048] Now referring to Figure 1 FIG. [Reference number not provided in the original, assuming it's a figure number], 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 seats and stems, or any other typical or desired control hardware associated with the operation of the field device. The control hardware 12 can be any combination of hardware typically associated with any type of control device, such as sensors (e.g., temperature sensors, flow meters, level sensors, pressure sensors, etc.), valves or other flow control structures for gases or liquids, igniters, fans, motors, actuators, pumps, etc. The control hardware 12 can be, for example, a control structure that measures or senses one or more physical phenomena in a plant or manufacturing facility setting, or controls or influences one or more physical phenomena in a plant or manufacturing facility setting, and can be any control hardware associated with any known control field device.

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

[0050] Further still, the power supply 22 is preferably coupled to the communication interface 20, and specifically, to the physical layer of the bus or wired network to which the field device 10 is connected, receives power in the form of current (e.g., DC current) from the physical layer, and converts this current into electrical power signals (typically, one or more voltage signals), which are 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 as described herein to enable the operation of the processor 14. Further still, the power supply 22 can power the memory 16, the interface 18, and one or more field device hardware components 12. If desired, the power supply can include a battery or consist entirely of a battery. If the power supply 22 includes a battery, the battery can be charged by a power signal provided via an external wired communication network. In other cases, 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.

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

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

[0053] As will be appreciated, during operation, the OS 34 executing on the processor 14 may establish and manage a communication stack 38, such as TCP, UDP, or other IP- or packet-based stack, to perform external, packet-based digital communication via the communication interface 20. In addition, the OS 34 may establish and manage multiple different communication threads (processes), which may run simultaneously (and at the same or different speeds) via the communication interface 20 and the underlying communication stack 38. In particular, as Figure 1As shown, the OS 34 can establish various communication threads 40 that implement the same or different higher-level or more specialized communication protocols, such as the HART-IP protocol, the OPC protocol such as the OPC UA protocol, the 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, where the threads 40 run simultaneously to provide communication with different external devices and applications. The various different threads 40 can use the same or different higher-level communication protocols to communicate more effectively with different clients (i.e., external devices or applications). In Figure 1 the example shown, the OS 34 manages four threads 40, where the first of the threads 40 uses HART-IP, which can be used to communicate with a process controller that uses field devices to perform process control, where the second and third of the threads 40 run the OPC UA protocol and communicate with a device maintenance system and a data monitoring system, and where the fourth of the threads 40 uses the email protocol to communicate with an email server to send emails to one or more individuals. 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.

[0054] Thus, as will be appreciated, the highly versatile field device 10 can store and execute different modules, applications, or routines that enable the device 10 to communicate with different client devices and / or applications via the communication interface 20, thereby supporting a variety of different uses and enabling multiple different client systems (such as control systems, maintenance systems, monitoring systems, etc.) to access the same or different field device information within the device 10 (e.g., information from or about the field device hardware device 12). Communication with these various different client systems can use different higher-level communication protocols that, based on the specific needs of the client application, use the underlying IP communication stack 38 to packetize. For example, some protocols such as HART-IP are more suitable for control applications and control communication because HART-IP typically provides faster, more reliable, and real-time data streams. Other protocols such as OPC UA are more suitable for monitoring or maintenance applications because the protocol provides more diagnostic capabilities without the need for fast or real-time communication. Other protocols can enable the device 10 to effectively provide or construct 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. Additionally, 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 each other, and other client systems are unaware of which other systems are accessing or communicating with the highly versatile field device 10.

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

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

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

[0058] Generally, the highly general-purpose field device 10 is configured to operate in a field environment of a factory or manufacturing plant. For example, it includes a communication network that supports high-level protocols operating on an open physical layer to perform communication between the field device and one or more client devices, and the client devices can be devices associated with any number of different systems, such as control systems, maintenance systems, monitoring systems, etc. Thus, the client devices can be process controllers (associated with control systems), maintenance applications or servers (associated with device or factory maintenance systems), monitoring applications or servers (associated with monitoring systems), and / or other systems.

[0059] In one embodiment, the highly general-purpose (HV) field device 10 can communicate via the Advanced Physical Layer (APL). For example, Figure 2 FIG. shows an APL-based network 80, where the highly general-purpose field device 10 can be used to provide support to multiple client applications and devices. The APL network 80 supports various field devices 82 (any one or all of which can be Figure 1Communication using a packet - based or advanced (e.g., IP - based) communication protocol between a highly versatile field device 10) and any other device (e.g., a controller, a server, a user interface device, etc.). Importantly, APL provides a two - wire physical communication layer (two - wire bus) that supports both digital communication and power delivery to the devices connected to the physical layer. Different from previous control - specific communication physical layers (e.g., those associated with protocols such as FOUNDATION Fieldbus, HART, Profibus, CAN, etc.), APL provides sufficient power (in the form of voltage and current) on the two - wire bus to power a microprocessor (e.g., Figure 1 the microprocessor 14) within a field device that is based on a general - purpose or higher - level operating system. This higher power level is needed to enable a processor with functions running a general - purpose or real - time OS, such as those described above with reference to Figure 1 . However, APL does not provide too much power (especially voltage) on the two - wire physical layer, such that using APL in a hazardous environment is dangerous due to the risk of spark generation. Thus, APL has enough power to power a process control device with a microprocessor running an operating system such as a real - time operating system, without having enough power to cause potential safety problems in the actual process control environment where the field device is located. Generally, the APL network provides approximately 1.4 watts of power (on the spur lines) to each device at a voltage of 14 volts or less, preferably 10 volts or less. Additionally, the APL network provides a two - wire reinforced physical layer or wire by using 14 - gauge stranded wire, which makes the wiring less vulnerable to breakage in the field and enables more power (current) at a lower voltage level due to reduced resistance. Furthermore, APL supports IP - or packet - based digital communication in the form of traditional Ethernet - based communication, making APL communication easy to use in other types of applications besides control applications, and thus extending the communication power of traditional Ethernet down to the process control or factory automation environment or factory, without the drawbacks of the Ethernet physical layer (which typically provides 48 volts on thin or higher - gauge single - strand wiring).

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

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

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

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

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

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

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

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

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

[0069] 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 3 The APL field switch 124A of is shown as being connected via a trunk line to two highly versatile PA field devices 128 and an adapter device 130 that is connected to a legacy field device (in this case a HART 4-20mA field device 132) and acts as an input / output device for the legacy field device. Similarly, the APL field switch 124B is shown as being directly connected to two highly versatile PA field devices 128 and is also connected to an APL field switch 124C that in turn is connected to two highly versatile (HV) field devices 128. Of course, the highly versatile field devices 108, 110, 128 communicate via their respective APL networks 104 and 106 with devices connected to the network backbone 112 via the APL power switches 114 and 122. In this way, the highly versatile field devices 108, 110, and 128 can be communicatively connected to one or more controllers 140 on the network backbone 112 via various different APL field switches and APL power switches that use different APL-supported physical layers (or communication networks with different speeds), while performing control in the process and factory settings using traditional control techniques.

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

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

[0072] In another example architecture, Figure 3 the system can be extended to include or provide one or more applications in additional networks, such as in the cloud, to obtain access to the highly versatile field devices 10. For example, Figure 4 shows a system 160 similar to Figure 3 system 100, where network 144 is coupled via a firewall device 162 to an additional network 164 that can be a factory or manufacturing plant commercial network within a factory or manufacturing plant. Network 164 can also be connected to the cloud 168 via an edge gateway 166 using, for example, the OPC UA protocol and a supported physical layer. One or more other applications associated with other systems such as monitoring systems, data recording systems, etc. can be stored and executed in computer devices in the cloud 168, and these devices and applications can communicate with the highly versatile (HV) field devices 108, 110, 128 as clients via the edge gateway 166 (and network 164), via the firewall 162 and network 144, via the switch 142 and network 112, and via one of the APL power switches 114, 122 through one of the APL networks 102 or 104 to which the field devices 108, 110, 128 are connected. This architecture or configuration provides access to the highly versatile field devices from applications (client applications) and devices in one or more external networks (i.e., networks external to the factory or manufacturing plant). As will be understood, Figure 4 the edge topology network runs above or in parallel with the process and factory automation systems 102, 104. The 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.

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

[0074] Figure 6 and Figure 7 show other control system architectures including highly versatile (HV) field devices that can be accessed by various client devices or applications. Specifically, Figure 6 and Figure 7 the network architectures are designed to work with both traditional networking and flattened networking. Generally, traditional networking provides access to devices through controllers and I / O servers, while flattened networking provides direct access to highly versatile field devices.

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

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

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

[0078] As will be understood, the highly versatile field devices disclosed herein can support many different uses or systems. In particular, the highly versatile field devices are first used to control field devices and operate as control field devices to perform process or plant automation control activities in response to a process or automation controller. However, the highly versatile field devices can also support a plant asset management system (including device configuration). Generally, a plant asset management system is used to configure and commission devices, perform diagnostic operations on device operation after the devices are deployed, monitor device alarms, and a long list of many other functions. In addition, the highly versatile field devices described herein can support an IIoT platform for continuous condition monitoring. More particularly, condition monitoring systems can be deployed at many locations to perform various functions, including energy monitoring, device and equipment monitoring, and process monitoring. Such monitoring systems can stream data from the plant, perform condition monitoring, and provide recommendations back to the user and, in some cases, back to the control system itself.

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

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

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

[0082] To provide this support, the communication interfaces of the highly general-purpose field devices described herein include session-oriented capabilities over IP and can support, for example, both UDP and TCP. Most real-time implementations use UDP, which gives the designer a fair amount of control over connection management, timeouts, and other capabilities. As a result, publish messages can be used to send periodic and exception-based data from the field device to subscribing clients such as controllers. The client subscribes to the device to receive the published messages. Once subscribed to the publish list of the field device, the client listens on an IP endpoint, and the field device publishes messages to that endpoint. Therefore, the highly general-purpose field devices and the networks in which these field devices reside must implement strict security.

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

[0084] The highly general-purpose field devices and the networks in which these devices are deployed address these security issues by incorporating security mechanisms into the field devices and the networks, which can include the use of TLS, authentication certificates, and a complete security trust chain. Specifically, Figure 8 is shown a general block diagram of the various security features provided in a highly general-purpose field device 10, for example, Figure 1 and in the network in which these devices reside. Figures 2 - 7 Specifically, as Figure 8 shown, the security features include a root of trust component 302, a secure boot feature 304, an endpoint identity feature 306, secure storage 308, and encryption capabilities 310. Additionally, the security features include secure communication features 312, device provisioning 314, and a security audit function 316.

[0085] In particular, each highly general-purpose field device 10 includes or incorporates a root-of-trust component 302, which forms the basis for device security. Trust in embedded security refers to the expectation that a field device operates as designed. In particular, device software trusts that the hardware operates as it should, applications running on the device trust that the operating system has not corrupted the device configuration, and remote systems communicating with the device trust the identity of the device to which the remote system is connected. The process of establishing this trust is called attestation, and the root of trust 302 of the field device is the point at which attestation and authentication begin. Once established, this root of trust extends through each trust layer and provides the basis for each trust layer. Thus, the root-of-trust component 302 is an important building block in the highly general-purpose field device 10 because the root-of-trust component 302 provides the basis for protecting the device and all communications with the device. The root-of-trust component 302 can be established using any of a variety of methods and can take many forms, but generally the root-of-trust component 302 ensures that the boot code on the field device is the code that the manufacturer intended. This root-of-trust feature 302 protects the boot code in a way that makes it immutable or indestructible by external tampering. In a simple case, the root-of-trust component 302 can be established by storing and / or executing the manufacturer's boot code for the field device 10 in a non-writable location in the memory map of the device processor or directly from that location. Alternatively, the device can include a root-of-trust component 302 that enables updates and patching of the boot code by allowing the boot code to be loaded from a protected memory region into a certain protected memory store reserved for firmware execution. An important aspect of the root-of-trust component is to ensure that the initial code is as expected by the manufacturer before execution, and that this root-of-trust component protects the manufacturer's code (or updated code) from being tampered with by a third party. When the code starts, the root of trust derives its internal key from the provided device identity input, and the device performs a self-test and code verification on itself to verify its identity and establish a basic key for the root of trust to use with other devices in the network.

[0086] In addition, the highly general-purpose field device 10 includes a secure boot feature or process 304. The secure boot process 304 prevents unauthorized code from being executed when the device is powered on and prevents the exposure of embedded boot code and software. The secure boot process can be implemented in many different ways, including using binary strings with digital signatures, using a secure and trusted bootloader, using encrypted boot files, and using a secure microprocessor. Although the secure boot feature 304 can be centered around digitally signed boot files, the boot is not secure unless those signatures are verifiable using some immutable root of trust. Therefore, to verify the boot files, when the device is manufactured or after manufacturing, using a trusted application, the highly general-purpose field device has a digital key installed therein (and established by the root of trust component 302), and this digital key is then used to execute or enable other security features. In addition, the secure boot process protects software on the device, such as proprietary algorithms, and provides trusted remediation measures. That is, the secure boot process 304 provides the ability to securely repair the process control system in the event of device failure or damage, because the repair depends on a secure boot process that has the ability to check the validity of the firmware image that is bootstrapping or using the root of trust component 302. The device secure boot process 304 provides standardization of these checks to ensure that a bad device does not cause damage beyond itself.

[0087] In addition, the device secure boot process 304 provides or enables secure firmware updates. In particular, secure firmware upgrades include verifying the incoming payload intended to replace the existing firmware image, which is critical for maintaining device integrity throughout the system 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, a failure to verify the incoming code results in a secure rollback to a known, verified boot image. In addition, the secure boot process 304 enables a secure connection to cloud resources, because the secure boot process 304 ensures that whenever the device attempts to connect to the cloud by using embedded keys and certificates, the device authenticates to the cloud.

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

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

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

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

[0092] Similarly, the highly general-purpose field device 10 provides or includes secure device provisioning 314 (usually 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 tags, pre-shared keys and / or certificates, system log server hostnames and ports, DNS server names, and optionally the default port number the device listens on, as well as static IP addresses and masks. Devices should be provisioned before they are installed in the factory. This provisioning is commonly referred to as onboarding. In one example, during the provisioning phase, the device should have the following information set by the secure device provisioning process, including (1) the device name and the unit name in which the device will be installed, (2) the pre-shared key or X.509 certificate that will be used to establish a session, (3) the hostname and port used to connect to the system log server, (4) the name of the DNS server, (5) the static IP address and its subnet mask (this is optional), and (6) an optional port number in case the default port number is blocked by a firewall (this is also optional). All this information should be loaded into a secure location in the device. This information will also have to be available to the host that will initiate a session with the device.

[0093] In addition, 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 normal operation. To assist 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 auditing, event logs are used as valuable inputs that can help continuously measure and evaluate risks and mitigate threats. This requires capturing system and security events (which may not be security events), transmitting the events to a host using system logs, and the ability to apply inspection to system events. To implement this functionality, the highly versatile field device 10 supports audit logs and an audit function (system log). In particular, the device (server) can record the following in a local volatile audit log: (1) the last time / date the server was powered on; (2) the last time / date the security credentials were modified; (3) the server status; (4) a list of 128-entry session summaries in a cycle; and (5) a timestamp, such as an 8-byte unsigned integer timestamp. Each session summary record can include: (1) the client identity including the IP address (IPv4, IPv6) and port number; (2) the connection / disconnection time / date of the client; (3) the start / end configuration change counter; (4) the session status; and (5) a communication counter indicating the number of published (burst), request, and response PDUs. In addition, the highly versatile field device 10 can support 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 improving factory security policies and processes to minimize vulnerabilities.

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

[0095] Network Node Management

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

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

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

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

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

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

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

[0103] 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 a device tag, one or more data tags that identify the type of data transmitted and / or received by the device, etc. For example, a device tag can be a first-order device identification or device identifier because the device tag directly identifies the device, while a data tag can be a second-order device identification or device identifier because the data tag indirectly identifies the device via the specific data that the device is to produce or consume. Generally, within one or more configurations of the process control system or automation network, e.g., within one or more configuration databases 420, the tags or identifiers that are identified and / or associated with the devices D1-Dn are defined. One or more configuration databases 420 can be nodes of the node communication network 402, e.g., as Figure 9 shown, or one or more configuration databases 420 can be communicatively coupled to the devices D1-Dn via one or more other types of process control or automation networks ( Figure 9 not shown in the figure), which can include legacy or traditional process control or automation networks. Some identifiers or tags can be supplied to the corresponding devices D1-Dn manually or automatically (e.g., during bench supply and / or commissioning of the devices D1-Dn, or at some other time prior to initial power-up of the devices D1-Dn within the field environment 412a), and / or some identifiers or tags can be downloaded to or otherwise stored in the corresponding devices D1-Dn along with the configuration of the corresponding devices. The corresponding device tags and any corresponding data tags that identify and / or are associated with each device D1-Dn are Figure 9 represented by the circled "tag" symbol in the figure.

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

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

[0106] To this end, the discovered device data store 435 stores an association or mapping between device identifiers (such as the device label of a device and optionally data labels associated with the device) defined in the process control configuration database 420 and the corresponding IP address / endpoint identifier that has been assigned to the device by the DHCP server 430. Thus, the discovered device data store 435 may be interchangeably referred to herein as the "mapping database 435". For illustration, consider an example device D1 that has been provisioned and / or configured with its identifying device label A and two data labels B and C that identify two specific types of data generated by the device D1. The DHCP server 430 assigns the IP address A1B2 to the device D1. Thus, the mapping database 435 (e.g., the discovered device database 435) stores an indication of the association between (1) the device label A and the IP address A1B2, (2) the data label B and the IP address A1B2, and (3) the data label C and the IP address A1B2.

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

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

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

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

[0111] 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 illustrative purposes only and not limiting. Any two or more of these management nodes 430, 432, 435, 438, 440, and 442 can be implemented as an integral node as needed. For example, the network node manager 432 can include the DNS service or server 438, the network node manager 432 can include the DHCP service or server 430, the DNS server 438 can include the mapping database 435, etc. Additionally, although Figure 9 each of the nodes or servers 430, 432, 435, 438, 440, 442 is shown as a corresponding single node, in an embodiment, the system 400 can include multiple of each of the nodes 430, 432, 435, 438, 440, and / or 442. Further still, any one or more of the management nodes 430-442 can be implemented or hosted by any suitable computing system, such as one or more physical and / or virtual servers, one or more databases, etc., at least part of which can be locally or proximally located to the process plant or automation system, and / or at least part of which can be remotely located relative to the process plant or automation system, such as at a server farm, in a cloud computing system, etc.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0131] In any case, when 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 the execution of the process control loop. The controller 580 can use the IP address of the field device (and the field device 552 can use the IP address of the controller) to communicate via the node communication network 402 in any suitable manner (e.g., direct messaging, client / server type communication, request / response, publish / subscribe, etc., as described in other parts of this disclosure) to execute the control loop and / or for other purposes. In an embodiment, the controller 580 and the field device 552 use their respective IP addresses to establish a secure communication session through the network 402, and the controller 580 and the field device 552 transmit data and information via this secure communication session, as indicated by reference numeral 588. For example, the controller 580 and the field device 552 can exchange security credentials (which may have been assigned by the security manager 440 and supplied to each of the devices 580, 552 by the workbench), can verify the certificates using the security manager 440 and / or the network node manager 560, and / or can take other associated actions to protect the communication session. Generally, each of the controller 580 and the field device 552 notifies the system log server 572 of the establishment and termination of the session, as well as other events associated with the communication session ( Figure 11 not shown).

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

[0133] Now returning to Figure 9, as previously discussed, the network node manager 432 can discover devices that have been attached or connected to the node communication network 402, store the device identifier (e.g., a first-level device identifier such as a device label or a second-level device identifier such as a data label) and the IP address of the discovered device in the mapping database / discovered device data store 435, and maintain the updated status and / or condition of the discovered device in the mapping database / discovered device data store 435. For example, in an embodiment where the network node manager 432 and the DHCP server 430 are an integrated node, the network node manager 432 discovers newly connected devices by receiving device queries for the DHCP server 430 for IP addresses. When the network node manager 432 is a different node from the DHCP server 430, the DHCP server 430 can notify the network node manager 432 and / or the DNS server 438 of the newly connected device and its corresponding device identifier / IP address association. When the DHCP server 430 notifies only one of the network node manager 432 or the DNS server 438 of the newly connected device (and its corresponding device identifier / IP address association), the other node can query the notified node (e.g., periodically or otherwise as needed) for any newly added devices and their corresponding IP addresses and device identifiers. Thus, generally speaking, the mapping / discovered device database 435 can store device identifiers and corresponding IP addresses, as well as updated device condition and status information.

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

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

[0136] Of course, the client device and the host device can utilize their respective security credentials or information to establish a communication session via the node communication network 402, such as in Figure 11 the session establishment 588 shown. For example, in addition to providing their respective security credentials to the client device and the host device during bench supply, the security manager 440 can also manage the respective keys and verify certificates after supply, e.g., when the device is connected to the network 402 and / or when the device remains connected to the network 402. If a device fails to successfully authenticate or is successfully verified, the device can be isolated and prevented from communicating with other nodes of the node communication network 402 until the device's security credentials and / or information have been resolved, e.g., manually.

[0137] This security technique advantageously allows for easy replacement of physical devices. For example, a physical replacement device only needs to be bench-supplied with the security credentials that have already been supplied to the device it is replacing. Thus, when a physical replacement device is identified within a process control system by using the device label and security credentials of a previous device, by using the techniques described herein, the physical replacement device will automatically be configured with the same settings as the device it is replacing and can be plug-and-play.

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

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

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

[0141] The provisioning engine 612 operates in conjunction with a workbench provisioning application 618, which can be provided via the user interface of the security manager 605, and / or can otherwise be exposed to or provided at the user interface of other devices (e.g., a handheld computing device or other types of tools) for managing 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 to various user-operated computing devices or tools, and so on. Generally speaking, the workbench provisioning application 615 provides users with access to the security manager 605 for defining, generating, viewing, and managing device security credentials, and / or for performing other tasks related to provisioning security credentials into devices.

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

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

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

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

[0146] At a time different from the provisioning period, such as during the process of connecting to the node communication network 402 and / or when connecting to the node communication network 402, the host device 608 may execute a key request routine 622b, via which the host device 608 requests keys (e.g., private keys, public keys, etc.) from the credential management engine 620 of the security manager 605. For example, the key request routine 622b may be included in the secure communication feature 312. Similarly, the client device 610 may execute a key request routine 625b, via which the client device 610 requests keys (e.g., private keys, public keys, etc.) from the credential management engine 620. Additionally, in order to perform authentication, verification, attestation, and / or other types of certificate evaluations during the process of connecting to the network 402 and when connecting to the network 402, each of the host device 608 and the client device 610 may execute respective credential evaluation routines 622c, 625c, which interface with the credential management engine 620 of the security manager 605 to implement credential evaluation, for example, by accessing the stored credentials 615. For example, when the host device 608 and the client device 610 execute the corresponding join routines 628, 630 to respectively and securely join the node communication network 402 and thereby be able to establish a communication path or even a communication session 632, at least some device security routines or applications 612b, 612c, 620a, 620c may be executed. For example, the host device 608 may utilize any one or more of the security features and / or security protocols (e.g., 306, 310, 312, etc.) discussed with respect to Figure 8 to establish a secure communication session 632.

[0147] Note that inFigure 12 In this case, the applications or routines 622a, 622b, 622c, 628 of the host device 608 are shown as separate and distinct applications or routines. However, this is only for clarity of discussion. In fact, the functions of the host device applications / routines 622a, 622b, 622c, 628 can be implemented using fewer or more separate and distinct applications or routines. Similarly, the functions of the client device applications / routines 625a, 625b, 625c, 630 can be implemented using fewer or more separate and distinct applications or routines, and the various functions provided by the security managers 612, 615, 620 can be implemented using fewer or more separate and distinct engines, applications or routines.

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

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

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

[0151] Network Resource Management

[0152] Although the node communication network 80 in the factory 100 is extremely flexible, partly because it uses an IP-based network, an IP-based network implemented in a process or factory automation control environment needs to consider factors that may be of concern in a typical or traditional process or factory automation control network. For example, the self-routing nature of an IP-based network means that, without proper management, the network will behave differently and / or unpredictably in normal, overloaded, and fault scenarios. As an example, in high-load and competitive scenarios, an IP-based network can drop or delay packets. When packets are delayed or dropped, the performance of monitoring and control applications will be adversely affected by the resulting latency and jitter. Therefore, when performing network design in a process or factory automation control network, it is important to know how applications (e.g., monitoring and control applications, condition monitoring applications, etc.) will be affected under changing network conditions. Specifically, it is important to provide the required quality of service (QoS) to support existing and emerging application requirements, while also supporting a combination of traditional field devices 224, traditional I / O devices 222, and highly versatile field devices 82.

[0153] Equally importantly, an IP-based network can be configured to support various topologies. For example, the node communication network 80 should support traditional factory automation or process automation topologies, such as Figure 3 those shown in, which include highly versatile field devices 82 and traditional field devices 224 coupled to the APL network architecture 892 via adapter devices 130. The communication network 80 should support edge topologies such as Figure 4 those shown in, which operate on top of or in parallel with traditional factory or process automation topologies and support integration of schedule information such as scheduling, asset monitoring, analysis, simulation, and other functions. That is, the communication network 80 should be configurable to facilitate communication between highly versatile field devices 82 and / or traditional field devices 224 (via adapter devices 130) on one hand and various applications including cloud-based client applications 182 on the other hand via one or more edge gateways 166, as described above. Further, the communication network 80 should support cloud topologies such as Figure 5 those shown in, which can operate in parallel with automation instrumentation and can be used, for example, for condition-based monitoring (e.g., energy monitoring, equipment and device monitoring, and process monitoring). In such a system, as described above, the monitoring system can transfer data from the factory 100 to one or more cloud-based applications 182, which perform analysis and transfer data and / or recommendations back to users and / or elements in the process control network 200, such as controllers 140.

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

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

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

[0157] As described above, communication network 80 supports both client / server and publish / subscribe communications, and in addition to facilitating communication between field instruments and applications, it also enables an Internet connection between an Open Platform Communications (OPC) Unified Architecture (UA) server (e.g., a field instrument) and an OPC UA client (e.g., a controller). Each of the field instruments and applications can be a client or a server in various instances. Communication network 80 supports both User Datagram Protocol (UDP) and Transmission Control Protocol (TCP) communication modes. In a client / server communication session, directed communication occurs between a host and a single specific device. The addresses of both the source and destination devices are specific and explicit, and all client / server requests specify the request and response data to be transmitted. Meanwhile, in publish / subscribe communication, new values (e.g., measurement values, status values, etc.) are transmitted from a server (e.g., a device) only when needed. For example, regarding parameters published from highly general field device 82 to controller 140, the parameters can be transmitted as often as needed to allow control actions to correct unmeasured disturbances or respond to setpoint changes.

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

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

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

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

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

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

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

[0165] The network resource management component 800 may be implemented with or without using Time-Sensitive Networking (TSN). Each implementation will be described below.

[0166] TSN-Based Network Management

[0167] The network management requirements based on TSN manage network resources based on TSN (e.g., devices and applications), while allowing non-TSN resources to access the same network. That is, the network management based on TSN facilitates the communication of managed and unmanaged network services. As part of this networking solution, TSN network devices and applications need to know the priorities, and network resources must be allocated in a way that allows time-critical data to be transmitted with minimal blocking when transferring data from a source to a destination.

[0168] The TSN-based network resource management component 800 differentiates the priorities of data transmission according to rules and service types. For example, in some embodiments, priorities are assigned based on the default service types typically associated with a TSN-based network, as shown in Table 1.

[0169] Table 1

[0170] Priority Service Type 0 (Lowest) Background 1 Best Effort 2 Excellent Effort 3 Critical Application 4 Video with less than 100 ms latency and jitter 5 Voice with less than 10 ms latency and jitter 6 Inter - network Control 7 (Highest) Network Control

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

[0172] Table 2

[0173] Priority Service Type 0 (Lowest) Background 1 Best Effort 2 Excellent Effort 3 Device Status and Health Monitoring 4 Low - priority Control (Higher Latency Tolerance) 5 High - priority Control (Lower Latency Tolerance) 6 Inter - network Control 7 (Highest) Network Control

[0174] Referring to Table 2, some of the data used by a factory automation controller or a process controller may be more time-sensitive than other data. Those familiar with such automation processes will understand that this data may be more time-sensitive because the data is part of a frequently executed control loop, or where small changes may 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 prevent or mitigate dangerous situations. Other data used by the controller may be less sensitive to increased latency, such as because it is part of a less frequently executed control loop, or is a process that does not exhibit sudden changes in response to minor disturbances.

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

[0176] Figure 15 An example outbound port 818 is shown. Data enters the outbound port 818 via the input 819 and is placed into one of the multiple queues 822A - 822N by the queue selection unit 820. The queue selection unit 820 can determine which of the queues 822A - 822N to place a particular data based on the priority of the data and / or the type of the data. In an embodiment, each of the queues 822A - 822N can correspond to a specific 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 specific priority, but multiple queues among the queues 822A - 822N can be associated with one of the associated priorities. That is, each priority can be assigned a single queue among the queues 822A - 822N, or can be assigned multiple queues among the queues 822A - 822N. In an embodiment, each of the queues 822A - 822N can have data associated with more than one priority (e.g., if there are fewer queues than priorities or traffic types). In an embodiment, each of the queues 822A - 822N can have data associated with a specific data source, data type, data destination, or data stream associated therewith.

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

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

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

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

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

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

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

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

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

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

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

[0188] Modify the example slightly. If data frames 836 and 838 each have the same priority, or if data frame 836 has a lower priority than data frame 838, network resource management component 800 may still facilitate data frame 836 arriving earlier than data frame 838. For example, if data frame 836 is scheduled network traffic while data frame 838 is unscheduled network traffic. For example, although data frame 836 has a lower priority, it may contain data from highly general field device 104 that controller 140 expects at a specific time. In such a case, network resource management component 800 may configure communication network 80 such that data frame 836 arrives at endpoint system 844 (e.g., controller 140) before higher-priority data frame 838. Network resource management component 800 may configure gate control lists 828 for various outbound ports 818 via time-aware shaper 810 such that a clear data transmission path is created for data frame 836, while one or more transmission gates 826 (e.g., transmission gate 826 corresponding to queue 894B in network switch 846) along the data path of data frame 838 remain closed to block the transmission of data frame 838 until the transmission of data frame 836 is complete.

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

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

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

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

[0193] Non-TSN-based Network Management

[0194] In embodiments where the network resource management component 800 is not based on the Time-Sensitive Networking (TSN) protocol, network services can be managed by controlling the service flows through network switches (e.g., APL power switch 84 and APL field switch 86). The network resource management component 800 in a non-deterministic (i.e., non-TSN-based) system includes a network manager 814. The network manager 814 monitors and adjusts the network service flows among various devices in the network 80, especially in the network switches. Devices and hosts communicate with the network manager 814 to allocate services, for example, by requesting publish-subscribe service flows. The network manager 814 then controls the service flows through the switches by enabling and disabling various ports of the switches and by suppressing the network services passing through the ports. In such embodiments, network services can be identified, for example, by service source (i.e., sender), destination (i.e., receiver), and application type.

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

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

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

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

[0199] Release Kit

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

[0201] As will be understood, 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.) and condition monitoring parameters (e.g., valve stroke, valve drive, valve pressure, cycle count, etc.). Different types of available parameters may be of interest to different applications in the process plant 100. For example, an associated controller 140 may require monitoring and control parameters to implement a control loop for controlling a process, while a plant asset management device 145 may require condition monitoring parameters to monitor the condition of the devices in the process plant 100 and determine when maintenance is required, when a device has failed, when a device has lost calibration, etc.

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

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

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

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

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

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

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

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

[0210]

[0211]

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

[0213]

[0214]

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

[0216]

[0217]

[0218]

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

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

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

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

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

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

Claims

1. A field device, comprising: a field device hardware component that interacts with process phenomena; a communication interface communicatively coupled to one or more external devices via an external communication network; a processor coupled to the field device hardware component and the communication interface; a computer-readable memory coupled to the processor, wherein the computer-readable memory includes a secure storage device that stores boot firmware to be executed when the processor starts up; an operating system stored in the memory and implemented on the processor to perform communication via the communication interface; 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 implement communication via the communication interface; a root of trust component including a unique device identity stored in the computer-readable memory; and one or more security keys or security certificates stored in the computer-readable memory, which can be used to perform secure communication with external devices via the communication interface; wherein the processor implements a secure boot process that provides protection against tampering of the boot firmware at startup, generates an endpoint identity feature including a device identifier derived from the unique device identity, and uses an encryption algorithm to encrypt one or more of the data communications performed by the device, the data stored in the device, and the data used in the device, and wherein the one or more communication applications use the one or more security keys or security certificates to perform communication with external devices via the communication interface.

2. The field device according to claim 1, wherein the processor uses the unique device identity to authenticate communication between the external device and the field device.

3. The field device according to claim 1, wherein the processor uses the unique device identity to authenticate the boot activities performed by the processor in the field device.

4. The field device according to claim 1, wherein the boot firmware is directly stored and executed from a non-writable location in the computer-readable memory.

5. The field device according to claim 1, wherein the processor loads the boot firmware to be executed by the processor from a protected memory area of the computer-readable memory into a protected memory storage reserved for the execution of the boot firmware by the processor.

6. The field device according to claim 1, wherein the processor derives an internal key from the unique device identity, and the processor performs self-tests and code verification to verify the code identity and establish a key set for performing secure communication with external devices via the communication interface.

7. The field device according to claim 1, wherein the processor uses a digitally signed binary string or a digitally signed boot file to execute the boot firmware, and uses a digital key verified by the root of trust component to verify the boot file.

8. The field device according to claim 1, wherein The processor executes the boot firmware using a secure or trusted boot loader or a secure microprocessor.

9. The field device according to claim 1, wherein, the processor executes the boot firmware using boot file encryption.

10. The field device according to claim 1, wherein, the processor uses the root of trust component to check the validity of the boot firmware.

11. The field device according to claim 1, wherein, the processor performs a secure firmware update by verifying the incoming communication payload before storing or applying the incoming communication payload, which is intended to replace the existing firmware image, to the computer-readable memory.

12. The field device according to claim 1, wherein, if the verification of the new boot image code fails, the processor performs a secure firmware update by executing a fallback to a known and verified boot firmware image.

13. The field device according to claim 1, wherein, the processor performs a secure communication connection to cloud resources by implementing a secure boot process that ensures that the field device authenticates with the external device whenever the field device attempts to connect to the external device using the security key or security certificate.

14. The field device according to claim 1, wherein, the secure storage device includes off-chip flash memory, and wherein the processor copies one or more software applications or the operating system to the SRAM or external DDR memory for execution after the processor is booted.

15. The field device according to claim 1, wherein, the encryption algorithm includes a standards-based symmetric cipher suite, or a hash function, or a random number generator.

16. The field device according to claim 1, wherein, the processor stores and executes a security audit application that enables monitoring of the field device.

17. The field device according to claim 16, wherein, the security audit application performs logging and provides audit log information to an external server.

18. The field device according to claim 17, wherein, the audit log information includes an event log.

19. The field device according to claim 17, wherein, the security audit application captures system and security events and uses the external server to transmit the captured events to a host.

20. The field device according to claim 17, wherein, the security audit application stores local audit logs in the computer-readable memory, wherein the audit logs include one or more of the following: the last time / date the external server was powered on; the last time / date the security credentials were modified; the external server status; a cyclic 128-entry session digest list; and a timestamp.

21. The field device according to claim 17, wherein, the security audit application stores a session digest for each communication session with an external device.

22. The field device according to claim 21, wherein, Each session summary includes one or more of the following: client identity including IP address and port number, connection / disconnection time / date for the client, start / end configuration change counter, session status, and communication counters indicating the number of published PDUs, requested PDUs, and response PDUs.

23. The field device according to claim 17, wherein, the security audit application performs push audit message transceiver by pushing messages to an external security information and event management system.

24. The field device according to claim 1, further comprising supply information stored by the device manufacturer in the computer-readable memory.

25. The field device according to claim 24, wherein, the supply information includes one or more of the following: device label, pre-shared security key and / or certificate, security server hostname and port, DNS server name, default port number listened by the field device, and static IP address and mask.

Images