Leveraging out-of-band communication channels between process automation nodes

Abstract

Implementations are described herein for leveraging "out-of-band" communication channels between nodes of a process automation system. In various implementations, an out-of-band communication channel may be established between two or more process automation nodes of a process automation system. The out-of-band communication channel may be outside of a process automation network in which the two or more process automation nodes are communicatively coupled to other process automation nodes of the process automation system. The two or more process automation nodes may cooperate with one or more of the other process automation nodes to implement an at least partially automated process. One or more characteristics of the process automation system may be monitored and based on the monitoring, traffic may be selectively diverted from the process automation network to the out-of-band communication channel.

Description

[Technical field]

[0001] The present invention relates to leveraging out-of-band communication channels between process automation nodes. [Background technology]

[0002] A process automation system can include one or more process automation networks. A process automation network can be the primary communication channel(s) through which devices, such as distributed control nodes (DCNs), communicate with other nodes of the process automation system, such as other DCNs, sensors, actuators, etc. Process automation networks are typically implemented using a reliable, high-speed, and reasonably large bandwidth communication technology, such as Ethernet. Summary of the Invention [Problem to be solved by the invention]

[0003] Managing a process automation system can pose a variety of technical challenges. As one example, a process automation node, such as a DCN, may malfunction and / or otherwise go offline, in which case the node is unable to perform its role (often defined by one or more functional blocks) in the process automation system. As another example, the process automation network itself may become overloaded and / or congested, and / or portions of the process automation network may fail. As yet another example, data generated by a particular process automation node may be considered more sensitive than data generated by other process automation nodes, and it may be desirable or desired to ensure that such sensitive traffic cannot be easily intercepted, for example, by malicious or other unauthorized parties. As yet another example, data generated or collected by a particular process automation node may be considered to be of higher priority than data generated or collected by other process automation nodes. It may be desirable or desired to ensure that such high priority traffic arrives at its destination accurately and / or in a timely manner.

[0004] Additionally, a process automation network often has many process automation nodes communicatively coupled to the network. A process automation network may also include other networking nodes, such as firewalls to other systems. These myriad nodes are potential targets for malware and attackers. If a process automation network is compromised or infiltrated, recently added devices, such as DCNs, may be particularly vulnerable because such devices may not yet include security mechanisms capable of protecting such devices. Similarly, if a recently added device is compromised and then placed into service, the device may pose a security threat to the entire process automation network. [Means for solving the problem]

[0005] Accordingly, implementations are described herein for utilizing an "out-of-band" communication channel between two or more nodes of a process automation system to address these issues in various ways. More particularly, but not exclusively, techniques are described herein for establishing an out-of-band communication channel between one or more DCNs, outside of a main process automation network of the process automation system. In some implementations, the out-of-band communication channel may be implemented using wired or wireless communication technologies, such as Wi-Fi Direct, Universal Serial Bus (USB), Near Field Communication (NFC), Bluetooth, etc. In some implementations, the out-of-band communication channel may communicatively couple three or more process automation nodes and thus may alternatively be referred to as an out-of-band network. Such out-of-band communication channels may be used for a variety of different purposes, such as provisioning new devices to operate as part of the process automation system, security, load balancing, redundancy, and / or network traffic management.

[0006] With regard to provisioning and security, the out-of-band communication channel may act as a de facto firewall capable of protecting the device to be added on the process automation network from malicious content (e.g., malware, computer viruses). Furthermore, when the out-of-band communication channel is established between the device to be added and an existing member node of the process automation network (e.g., DCN), the out-of-band communication channel may be used to securely authenticate the device to be added while protecting the process automation network from malicious content that may be on the device to be added. For example, by using a secure and / or private out-of-band communication channel, the existing member node may obtain files, programs, and / or data to be loaded on the device to be added and may act as a pass-through for the device to be added. As a result, the device to be added is better prepared to become a secure member of the process automation system that functions as intended. In some implementations, the existing member node may obtain these data from other member(s) of the process automation network. In other implementations, the existing member node may obtain these data from a process automation management system (e.g., a central server).

[0007] For load balancing and / or redundancy, the out-of-band communication channel may be maintained between two or more process automation nodes such that the channel may continue to be used as a private channel for the two or more process automation nodes to exchange data in real time. This may enable any process automation node to take over and / or supplement one or more functions (e.g., function blocks) of the other process automation nodes when the other process automation nodes are unable to perform those functions due to, for example, a power outage, malware, human intervention, losing network connectivity, etc. The decision as to which functions a process automation node should perform when the other process automation nodes are unable can be manually set by a human, selected and / or voted for in real time by other process automation nodes in the process automation network, and / or determined using various artificial intelligence and / or machine learning techniques.

[0008] With respect to network traffic management, in some implementations, traffic can be diverted in real time from the process automation network to an out-of-band communication channel. Traffic may be moved in this manner based on a variety of different factors, including, but not limited to, (i) congestion and / or disruptions detected and / or predicted to occur in the process automation network, (ii) a desire to ensure that certain traffic remains private between nodes coupled to that out-of-band communication channel, and (iii) the relative priority of various traffic, to name a few.

[0009] In some implementations, when a network overload occurs on a process automation network, all or at least some of the devices in the process automation network can throttle their traffic to maintain flow and avoid bottlenecks. For example, each application running on a device, such as a DCN, that publishes data on the process automation network can ascertain the network load at the time of publishing, and based on this network load, the application can reduce or increase the frequency of the application and / or move traffic to an out-of-band communication channel(s) available to the application.

[0010] In some implementations, the out-of-band communication channel may be implemented using multiple channels and / or multiple sub-networks, e.g., one for asset management data (e.g., health data), another for process automation control, and another for time-sensitive networking data exchange.

[0011] In some implementations, a method may be implemented using one or more processors, the method may include establishing an out-of-band communication channel between two or more process automation nodes of a process automation system, where the out-of-band communication channel is outside a process automation network in which the two or more process automation nodes are communicatively coupled to other process automation nodes of the process automation system, and where the two or more process automation nodes cooperate with one or more of the other process automation nodes to implement an at least partially automated process; monitoring one or more characteristics of the process automation system; and based on the monitoring, selectively diverting traffic from the process automation network to the out-of-band communication channel.

[0012] In various implementations, the one or more monitored characteristics of the process automation system include network traffic on a process automation network. In various implementations, the one or more monitored characteristics of the process automation system may include network congestion detected based on network traffic on the process automation network.

[0013] In various implementations, the one or more monitored characteristics of the process automation system may include a degree of privacy assigned to at least some of the network traffic. In various implementations, the selectively diverting may include diverting network traffic assigned a first degree of privacy from the process automation network to an out-of-band communication channel.

[0014] In various implementations, the one or more monitored characteristics of the process automation system may include a relative priority assigned to at least some of the network traffic. In various implementations, the selectively diverting may include diverting network traffic assigned a first relative priority from the process automation network to an out-of-band communication channel.

[0015] In various implementations, the one or more monitored characteristics of a process automation system may include the ability of a given process automation node of the process automation system to execute a function block.

[0016] In various implementations, the monitoring may be performed by the DCN before the DCN publishes the data to other process automation nodes in the process automation network.

[0017] In various implementations, the method may further include transmitting configuration data from a first process automation node of the two or more process automation nodes to a second process automation node of the two or more process automation nodes via an out-of-band communication channel. The configuration data may include information technology (IT) configuration data usable by the second process automation node to participate in a process automation network and operational technology (OT) configuration data usable by the second process automation node to collaborate with one or more of the other process automation nodes of the process automation system to implement the at least partially automated process.

[0018] In various implementations, the two or more process automation nodes may include at least three process automation nodes, and the out-of-band communication channel may be a network that communicatively couples the at least three process automation nodes and is implemented using a different communication technology than the process automation network.

[0019] In various implementations, the method may further include exchanging device health information between the two or more nodes via the out-of-band communication channel. In various implementations, the method may further include exchanging time-sensitive networking metadata between the two or more nodes via the out-of-band communication channel.

[0020] In another embodiment, the DCN may include a first communication interface and a second interface, and circuitry configured to: join a process automation network communicatively coupling a plurality of process automation nodes of the process automation system using the first communication interface; join an out-of-band communication channel between the DCN and one or more other process automation nodes of the process automation system using the second communication interface; detect the occurrence of an event; and, based on the detection of the occurrence of the event, divert at least some traffic from the DCN to the out-of-band communication channel.

[0021] Moreover, some implementations include one or more processors of one or more computing devices operable to execute instructions stored in associated memory, the instructions configured to cause performance of any of the methods described above. Some implementations also include one or more non-transitory computer-readable storage media that store computer instructions executable by the one or more processors to perform any of the methods described above.

[0022] It should be understood that all combinations of the above concepts, and additional concepts described in more detail herein, are contemplated as being part of the subject matter disclosed herein, for example, all combinations of claimed subject matter appended to the end of this disclosure are contemplated as being part of the subject matter disclosed herein. [Brief description of the drawings]

[0023] [Figure 1] 1 is a schematic diagram illustrating a scenario in which selected aspects of the present disclosure may be implemented, according to an embodiment. [Diagram 2] 1 is a schematic diagram illustrating a scenario in which selected aspects of the present disclosure may be implemented, according to an embodiment. [Diagram 3] 1 is a schematic diagram illustrating a scenario in which selected aspects of the present disclosure may be implemented, according to an embodiment. [Figure 4] 1 is a schematic diagram illustrating a scenario in which selected aspects of the present disclosure may be implemented, according to an embodiment. [Diagram 5] 1 is a schematic diagram illustrating a scenario in which selected aspects of the present disclosure may be implemented, according to an embodiment. [Figure 6] FIG. 1 illustrates an exemplary method for carrying out selected aspects of the present disclosure. [Figure 7] FIG. 1 illustrates another exemplary method for carrying out selected aspects of the present disclosure. [Figure 8]FIG. 1 is a schematic diagram illustrating an example computer architecture in which selected aspects of the present disclosure may be implemented. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0024] As used herein, an "at least partially automated process" includes any process that is implemented in a process automation system by multiple devices collaboratively with little or no human intervention. One common example of an at least partially automated process is a process loop in which one or more actuators are operated automatically (without human intervention) based on the output of one or more sensors. Some at least partially automated processes may be sub-processes of an overall process automation system workflow, such as the single process loop described above. Other at least partially automated processes may include all or a significant portion of the overall process automation system workflow. In some cases, the degree to which a process is automated may exist along a gradient, range, or scale of automation. Processes that are partially automated but still require human intervention may be at or near one end of the scale. Processes that require less human intervention may approach the other end of the scale, representing fully autonomous processes. Process automation may generally be used to automate processes (e.g., chemical processing) in a variety of areas, such as the manufacturing, development, and / or improvement of chemicals, catalysts, machines, and the like.

[0025] As used herein, information technology (IT) configuration data may enable a device, such as a distributed control node (DCN), to network communicate with other nodes on a process automation network. IT configuration data may include networking parameters that may be used to join and / or communicate through a process automation network. These parameters may include, for example, Internet Protocol (IP) addresses, IP subnet masks, routing tables, etc. IT configuration data may also include data associated with the device's hardware or software, such as firmware or operating system (OS) updates, redundancy policies, security policies, etc.

[0026] In contrast, operational technology (OT) configuration data may enable devices such as a DCN to cooperate (e.g., exchange commands and / or sensor data) with one or more actuators or sensors on a process automation network to implement an at least partially automated process. OT configuration data for a DCN may include, among other things, process automation applications to be installed on and / or operated by the DCN, range limits to be imposed on / by the DCN, preferred units of measurement to be used by the DCN, update frequencies to be implemented by the DCN, one or more analog-to-digital conversion parameters to be used by the DCN, information about other nodes (e.g., their roles) in the process automation system, one or more signal conditioning parameters to be used by the DCN, security credentials for operation in the process automation system, error correction parameters (e.g., error correction code techniques) to be used by the DCN, etc.

[0027] 1, an exemplary environment 100 in which various aspects of the present disclosure may be implemented is generally illustrated. A process automation management system 102 is operably coupled to a process automation network 106 at a process automation facility 108. The process automation facility 108 (alternatively referred to herein as a "process automation system 108") may take many forms and may be designed to implement any number of at least partially automated processes. For example, the process automation facility 108 may form all or part of a chemical processing plant, an oil or natural gas refinery, a catalyst plant, a manufacturing facility, etc.

[0028] The process automation network 106 may be implemented using various wired and / or wireless communication technologies, including, but not limited to, cellular networks such as the Institute of Electrical and Electronics Engineers (IEEE) 802.3 standard (Ethernet), IEEE 802.11 (Wi-Fi), 3GPP® Long Term Evolution ("LTE") or other wireless protocols designated as 3G, 4G, 5G, and beyond, and / or other types of communication networks of various types of topologies (e.g., mesh). Process automation is often used in scenarios where the cost of failure tends to be high, both in terms of human safety and financial costs to stakeholders. Thus, in various implementations, the process automation network 106 may be configured with redundancy and / or backups to provide high availability (HA) and / or high quality of service (QoS). Additionally, nodes exchanging data via the process automation network 106 may implement time-sensitive networking (TSN) to facilitate time synchronization and / or real-time control streams.

[0029] The process automation management system 102 may include a diversion module 103, a commissioning module 104, and a database 105 that stores information used by the commissioning module 104 to commission new devices to the process automation facility 108. Various aspects of the process automation management system 102, such as the diversion module 103 and / or the commissioning module 104, may be implemented using any combination of hardware and software. In some implementations, the process automation management system 102 may be implemented across multiple computer systems as part of what is often referred to as a "cloud infrastructure" or simply a "cloud". However, this is not required and in FIG. 1, for example, the process automation management system 102 is implemented within the process automation facility 108, such as in a single building or across a single campus of buildings or other industrial infrastructure. In such implementations, the process automation management system 102 may be implemented on one or more local computing systems, such as one or more server computers.

[0030] In addition to the process automation management system 102, various other nodes / devices are operably coupled to the process automation network 106. In FIG. 1, for example, N (a positive integer) DCNs 110-1 through 110-N are operably coupled to the process automation network 106. Each DCN may include circuitry or logic 112, which may take various forms, such as a processor(s) that executes instructions in a memory, a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), etc. Each DCN 110 may have one or more roles to play in the process automation facility 108. A “computational” DCN may, for example, control a process loop (e.g., a chemical process loop) in which various “field” devices (e.g., devices having sensors and / or actuators) cooperate with each other to execute some number of functional control blocks (FBs).

[0031] Each DCN 110 may have various input / output (I / O) hardware components and other hardware components that define at least some of the OT capabilities of that DCN 110 and, more generally, the role of that DCN 110 in the process automation facility 108. OT capabilities can vary significantly by industry. In some cases, OT capabilities include, but are not limited to, the number of I / O channels, the type(s) of available I / O channel(s), nominal range limits, nominal unit(s) of measurement, nominal update frequency, one or more analog-to-digital conversion parameters, one or more signal conditioning parameters, supported open standard protocols such as Open Platform Communications Unified Architecture (OPC UA) and / or Modbus, or any combination thereof.

[0032] 1, a first DCN 110-1 includes a flow transmitter (FT) component 114-1 and an actuator (e.g., a valve) 116-1. A second DCN 110-2 includes an FT component 114-2 and a sensor 118-2 but no actuator. A third DCN 110-3 includes a sensor 118-3 but no actuator.

[0033] The actuators 116 may be any electrical, hydraulic, mechanical, and / or pneumatic components that are controllable to affect some aspect of the process automation workflow occurring in the process automation facility 108. In many cases, the actuators 116 may perform their functions in response to various signals, such as sensor signals, or commands from a computed DCN (which may itself be monitored for sensor signals). Some non-limiting examples of actuators 116 include, but are not limited to, valves, pistons, rotors, switches, heaters, coolers, agitators, syringes, devices that create vacuum, belts, tracks, gears, grippers, motors, relays, servo mechanisms, and the like. The sensor 118 may take a variety of forms, including, but not limited to, pressure sensors, temperature sensors, flow sensors (e.g., FT components 114), various types of proximity sensors, lighting sensors (e.g., photodiodes), pressure wave sensors (e.g., microphones), humidity sensors (e.g., humistors), radiation dosimeters, laser absorption spectrographs (e.g., multi-pass optical cells), and the like.

[0034] Unlike DCNs 110-1 through 110-3, DCN 110-N does not include any inputs / outputs (actuators or sensors). Instead, DCN 110-N may be a “computation-only” DCN whose role is to facilitate collaboration between itself and one or more other DCNs 110 on the process automation network 106 to implement an at least partially automated process. For example, DCN 110-N may control a single process loop (e.g., a chemical process control loop) involving one or more other DCNs 110. In some cases, such a computational DCN 110 may perform a role similar to an autopilot on an airplane, i.e., the computational DCN 110 may receive various signals and control various actuators based on those signals and various criteria and / or thresholds. For example, the computational DCN 110 may monitor various sensors 118 and / or FT components 114 to ascertain data about chemical levels, flow rates (e.g., across valves), tank temperatures, control rates, etc., and may control one or more actuators 116 based on this data and / or comparisons of this data to various criteria and / or thresholds. For example, the computational DCN 110-N may control the actuator 116-1 by sending a corresponding command to the first DCN 110-1, which may optionally conform to a protocol specific to and / or implemented by the first DCN 110-1.

[0035] As previously discussed, managing the process automation system 108 can pose a variety of technical challenges. Nodes, such as DCNs 110-1 through 110-N, can malfunction and / or otherwise go offline. The process automation network 106 itself can become overloaded and / or congested, and / or portions of the process automation network 106 can fail. Data generated by a particular process automation node (e.g., any of DCNs 110-1 through 110-N) may be considered more sensitive and / or of higher priority than data generated by other process automation nodes. Additionally, the often large number of nodes presents a myriad of potential targets for malware and attackers.

[0036] Accordingly, implementations are described herein for utilizing an “out-of-band” communication channel 109 between two or more nodes (e.g., two or more DCNs 110-1 to 110-N) of a process automation system 108 to address these challenges. For example, in various implementations, the out-of-band communication channel 109 may be established between compatible wired or wireless communication interfaces 113 of two or more DCNs, such as between DCNs 110-1 and 110-3 in FIG. 1. The out-of-band communication channel 109 may be external to (e.g., separate, implemented using different communication technologies, etc.) the process automation network 106 of the process automation system 108. Although a single out-of-band communication channel 109 is shown in the figures, this is not intended to be limiting. Any number of out-of-band communication channels may be established between any number of process automation nodes.

[0037] In scenarios where the process automation network 106 is implemented using Ethernet, the connection 107 between the DCN 110 and the process automation network 106 may be a registered jack (RJ) 45 connection in some implementations. In many such cases, the out-of-band communication channel 109 may be implemented using a different communication technology, such as USB, NFC, Bluetooth, etc. However, in other implementations, the out-of-band communication channel 109 may be implemented using the same type of communication technology as the process automation network 106 (e.g., Ethernet), albeit as a separate network / subnet that is sandboxed from the process automation network 106.

[0038] In various implementations, the out-of-band communication channel 109 may communicatively couple the communication interfaces 113 of three or more process automation nodes, as applicable in Figure 1, and thus may alternatively be referred to as an "out-of-band network." The out-of-band communication channel 109 may be used for a variety of different purposes, such as provisioning new devices to operate as part of a process automation system, security, load balancing, redundancy, and / or network traffic management.

[0039] In some implementations, the diversion module 103 may be configured to control and / or influence how the out-of-band communication channel 109 is utilized to address one or more of the various challenges discussed above. For example, in some implementations, the diversion module 103 may be configured to cause one or more process automation nodes, such as one or more of the DCNs 110-1 through 110-N, to establish an out-of-band communication channel 109 between themselves and / or to divert traffic to the out-of-band communication channel 109. Additionally, the diversion module 103 may monitor various characteristic(s) of the process automation facility 108 and, based on the monitored characteristic(s), may selectively divert traffic from the process automation network 106 to the out-of-band communication channel 109, or cause other process automation nodes to so selectively divert traffic.

[0040] In various implementations, all or part of the functionality attributed herein to the diversion module 103 may additionally or alternatively be performed in any process automation node, such as any of the DCNs 110-1 through 110-N. For example, an individual DCN 110 may monitor one or more characteristics of the process automation system 108 immediately prior to publishing data to the process automation network 106, such that an individual DCN 110 can selectively divert some or all traffic to an out-of-band communication channel 109, for example.

[0041] In various implementations, the diversion module 103 and / or other components may selectively divert network traffic to the out-of-band communication channel 109 based on detected or predicted network congestion and / or interruptions. For example, when the diversion module 103 detects or predicts a threshold level of network congestion and / or interruption, it may trigger the diversion module 103 to reactively or preemptively issue a command(s) to one or more of the DCNs 110-1 through 110-3 to divert some or all of those DCNs' exposed network traffic to the out-of-band communication channel 109. Network congestion and / or disruptions, whether detected / predicted by the diversion module 103 or by other process automation nodes (e.g., any of DCNs 110-1 to 110-3), can be detected or predicted in a variety of ways, such as the percentage of total bandwidth used, the number or percentage of packets dropped, detected latency meeting or exceeding some time threshold, detection of time-sensitive networking errors, etc.

[0042] In some implementations, network congestion may be predicted in the future based on detection of other conditions occurring historically prior to network congestion. These conditions may include, for example, time periods (e.g., peak times of operation), certain sensor condition(s) being satisfied, certain processes being implemented, and so on. These predictions may be rule-based or machine learning based. For example, inputs processed using such machine learning models may include discretized conditions. Outputs generated based on such models may include, for example, indicators of network congestion probability. Such machine learning models may take various forms, such as support vector machines, random forests, neural networks, and so on. In some implementations, time-series machine learning models, such as recurrent neural networks (RNNs), long short-term memory (LSTM) networks, gated recurrent unit (GRU) networks, and so on, may be trained on historical data, including data leading to instances of network congestion. Once trained, the time series model may be iteratively applied to time series data sampled from the process automation system 108, such as a time sequence of data snapshots of various sensor values. At each iteration, the output may include some indication of the network congestion probability.

[0043] As an example, if there is no network congestion, the diversion module 103 may not divert any traffic to the out-of-band communication channel 109. However, if there is network congestion, the diversion module 103 may issue commands to one or more of the DCNs 110-1 through 110-3 to divert at least some of those DCNs' traffic, particularly traffic destined for another one of the DCNs 110-1 through 110-3, to the out-of-band communication channel 109. In some implementations, the diversion module 103 or another component may identify a particular location of a network traffic bottleneck on the process automation network 106 (e.g., in terms of network topology and / or physical location). Based on that location, the diversion module 103 may instruct the DCNs 110 that are closest to the bottleneck and that have an out-of-band communication channel 109 available to them to divert traffic from the process automation network 106, thereby alleviating the bottleneck.

[0044] In addition to or instead of network congestion, in some implementations, the diversion module 103 may take into account a desired level(s) of privacy and / or relative priority of data exchanged over the process automation network 106 when selectively diverting traffic to the out-of-band communication channel 109. For example, the diversion module 103 may selectively divert highly sensitive network traffic, proprietary network traffic, and / or high / low priority network traffic over the out-of-band communication channel 109, sometimes in response to network congestion and sometimes independent of network congestion. In some implementations, network packets forming the network traffic may be assigned a priority and / or degree of privacy, e.g., by the diversion module 103 and / or the DCN 110 that generated those packets. Explicit designation of these priority and / or privacy assignments may be included, e.g., in the packet headers and / or payloads of those packets.

[0045] Alternatively, in some implementations, the priority and / or degree of privacy may be contextually assigned or inferred, for example, based on the state of all or part(s) of the process automation system 108 and / or the state of individual sensor signals. As an example, a packet carrying a measured sensor reading above or below a critical threshold may be automatically tagged as high priority, e.g., by the diversion module 103 or DCN that generated the packet, and may be diverted to an out-of-band communication channel 109 accordingly. As another example, assume that a particular sub-process implemented in the process automation system 108 includes proprietary and / or confidential aspects. While the sub-process is active, network traffic generated by the DCN(s) involved in the sub-process may be designated as private and / or confidential, such that the traffic may be diverted to one or more available out-of-band communication channels to avoid interception from the process automation network 106. In contrast, when a sub-process is inactive, traffic generated by those same DCN(s) may instead be transmitted over the process automation network 106 .

[0046] In some implementations, the priority and / or degree of privacy may be determined based on one or more policies or rules implemented by the diversion module 103 and / or one or more individual DCNs 110. As an example, the second DCN 110-2 may provide the first DCN 110-1 with a first sensor reading from the FT component 114-2 at various times that is not critical or time sensitive. At various other times, the second DCN 110-2 may provide the first DCN 110-1 with a second sensor reading from the sensor 118-2 that is different from the first sensor reading and is critical for the process control loop and / or time sensitive. In this scenario, the second DCN 110-2 may transmit the first sensor reading to the first DCN 110-1 via the process automation network 106, for example, regardless of whether network congestion exists. However, if network congestion is detected on the process automation network 106, the second DCN 110-2 may instead divert the second sensor readings to the first DCN 110-1 via the out-of-band communication channel 109.

[0047] In some implementations, the capabilities and / or availability of individual process automation nodes, such as DCNs 110-1 to 110-3, may be taken into consideration when selectively diverting traffic to / from the out-of-band communication channel 109, e.g., by the diverter module 103 and / or other process automation nodes. For example, multiple similar or identical DCNs 110 may be communicatively coupled (e.g., daisy-chained) to one another via out-of-band communication channels, but only one of the multiple DCNs may be communicatively coupled directly to the process automation network 106. The other DCNs may act as backups for redundancy purposes, such that if a sensor 118 or actuator 116 of the one DCN fails, or if a functional block of the one DCN fails, one or more of the other DCNs may take over. Assuming the one DCN is still able to communicate over the process automation network 106, this avoids the need to reassign the IP address of the one DCN to another DCN. In other words, from the perspective of other nodes in the process automation facility 108, there is no change in the network whatsoever.

[0048] 2 illustrates an example of a typical operation of the process automation facility 108. In this example, the sensor 118-3 of the third DCN 110-3 generates sensor data that is used by the first DCN 110-1 to control the actuator 116-1, for example, alone or in conjunction with other data such as flow rate provided by the FT component 114-1. The third DCN 110-3 may relay this sensor data from the sensor 118-3 to the first DCN 110-1, as indicated by the white arrow shown at 236. In some implementations, as part of relaying this sensor data, the third DCN 110-3 may process the sensor data in various ways, such as formatting the sensor data into a format compatible with and / or accepted or understood by the first DCN 110-1.

[0049] As indicated by the shaded arrow 238, in some cases, this relayed sensor data may also be intercepted from the process automation network 106 by the second DCN 110-2 (and potentially other nodes of the process automation facility 108). Some of the sensor data generated by the sensor 118-3 may be considered sensitive, private, and / or proprietary. Furthermore, the entity controlling the process automation facility 108 may have a higher level of trust in the manufacturer of the third DCN 110-3 than in the manufacturer of the second DCN 110-2. Under such circumstances, there may be some concern that the second DCN 110-2 may have some network connection (e.g., a backdoor) to one or more entities outside the process automation facility 108, and thus there may be some risk that the second DCN 110-2 may expose this intercepted sensor data to unauthorized parties. An out-of-band communication channel 109 may be used to avoid the DCN 110-2, thereby preventing such sensor data from being intercepted by the second DCN 110-2.

[0050] Individual components of the process automation system 108, such as any of the DCNs 110-1 to 110-N, may be assigned a degree of trust in a variety of ways. In some implementations, the degree of trust of a device may correspond to a degree of trust associated with (e.g., assigned to) an entity that forms part of the supply chain for that device, such as a manufacturer or distributor. Additionally or alternatively, a degree of trust may be assigned to a device, such as the DCN 110, based on the state or configuration of the device itself. If a device's software (e.g., security software such as antivirus, function blocks, etc.) is not up to date, the device may be considered less trustworthy than other devices that are up to date. The device's network settings and / or location on the network may also be considered in determining the device's degree of trust. Devices behind a firewall may be assigned a greater degree of trust than other devices that are not protected.

[0051] For example, in response to detecting a packet(s) flagged with a high degree of privacy, the diversion module 103 may instruct the third DCN 110-3 to disable and / or disconnect portions of the out-of-band communication channel 109 between the DCN 110-2 and the DCN 110-3 while leaving the second DCN 110-2 connected to the process automation network 106. This may enable the diversion module 103 and / or the third DCN 110-3 to address the risk of eavesdropping by diverting sensor data generated by the sensor 118-3 from the process automation network 106 to the out-of-band communication channel 109.

[0052] FIG. 3 illustrates an exemplary scenario in which a disruption 340 occurs on the process automation network 106. Other components and the overall scenario in FIG. 3 are the same as those illustrated in FIG. 1-FIG. 2. The disruption 340 may be network congestion that causes some packets to be dropped and / or prevents some packets from being delivered in a timely manner. Alternatively, the disruption 340 may be a break (e.g., a tangled or cut section) in the process automation network 106 between the first DCN 110-1 and the third DCN 110-3. Whatever the case may be, the disruption 340 may be detected, for example, by either the DCNs 110-1 / 110-3 and / or the diversion module 103 and may trigger a diversion such that traffic addressed to the first DCN 110-1 by the third DCN 110-3 is routed through the out-of-band communication channel 109, as indicated by the bottom shaded arrow.

[0053] In some implementations, not only is traffic addressed by the first DCN 110-1 by the third DCN 110-3 diverted in this manner, but any traffic that cannot reach its destination (or at least cannot reach its destination in a timely manner) due to the interruption 340 may be diverted through DCNs 110-1 / 110-3, at least until the interruption 340 is remedied. For example, the diverting module 103 may detect the interruption 340 and instruct all or some of the DCNs 110-2 through 110-N that traffic addressed to the first DCN 110-1 should be rerouted to an IP address of the third DCN 110-3 so that the third DCN 110-3 can relay that information to the first DCN 110-1 via the out-of-band communication channel 109. Additionally, although not shown in FIG. 3, a second DCN 110-2 is also coupled to the out-of-band communications channel 109 and may therefore additionally or alternatively be used to divert traffic to / from the first DCN 110-1, assuming the second DCN 110-2 has a sufficient level of trust.

[0054] 4 illustrates an exemplary scenario in which the sensor 118-3 of the third DCN 110-3 fails, as shown by shading. However, the third DCN 110-3 is otherwise operational. As previously described, the first DCN 110-1 operates the actuator 116-1 based at least in part on the sensor data generated by the sensor 118-3. As a result, the first DCN 110-1 may not be able to properly operate the actuator 116-1 without somehow addressing the loss of the sensor 118-3.

[0055] However, similar or even identical sensors may be available in association with another DCN. For example, the sensor 118-2 of the second DCN 110-2 may be similar or even identical to the sensor 118-3 of the third DCN 110-3. In such a scenario, assuming the sensor 118-2 is not overly burdened, the second DCN 110-2 may divert "proxy" sensor data generated by the sensor 118-2 to the third DCN 110-3 via an out-of-band communication channel 109, as shown by the bottom shaded arrow in FIG. 4. The third DCN 110-3 may then relay this proxy sensor data to the first DCN 110-1 through the process automation network 106, as shown by arrow 236, similar to FIG. 2. This avoids having to reconfigure process automation network 106 parameters such as individual IP addresses, routing tables, domain name server (DNS) tables, etc.

[0056] In some cases, from the perspective of the first DCN 110-1, there may be no change in the data it receives, and the first DCN 110-1 may continue to operate as normal. However, the second DCN 110-2 may be configured to publish the sensor data generated by the sensor 118-2 in a different format than that used by the third DCN 110-3 to publish the sensor data generated by the sensor 118-3. In some such implementations, the diversion module 103 may instruct the second DCN 110-2 to publish the substitute sensor data in a particular format, even going so far as to provision, if necessary, for OT configuration data to be installed on the second DCN 110-2 to enable such formatting. Alternatively, the diversion module 103 may instruct the first DCN 110-1 to accept the proxy sensor data in a format natively exposed by the second DCN 110-2 or to convert the exposed proxy sensor data to the first DCN 110-1's proprietary format. As yet another alternative, another DCN, such as a computation DCN 110-N, may act as a gateway capable of converting between these various sensor data formats. In such cases, the out-of-band communication channel 109 may be extended, for example, from the second DCN 110-2 and / or the first DCN 110-1 to the DCN 110-N to facilitate such conversion.

[0057] When multiple candidate process automation nodes can take over the role performed by the disabled process automation node, various techniques may be used to select which candidate process automation node will take over. In some implementations, the available bandwidth of one or more out-of-band communication channels may be analyzed to select the best candidate stand-in process automation node. For example, a particular process automation node may be connected to two different candidate stand-in process automation nodes via two different out-of-band communication channels. Either of the two candidate stand-in process automation nodes may be suitable to take over the responsibilities of another node that has malfunctioned. If one of the out-of-band communication channels has more available bandwidth compared to the other, the corresponding candidate stand-in process automation node may be selected as the stand-in.

[0058] Additionally or alternatively, in some implementations, the process automation nodes may vote for candidates, for example, with each node voting based on its own self-interest (e.g., continuing to receive sensor data in a timely manner). For example, when a process automation node needs a stand-in, each remaining process automation node may vote for the candidate stand-in process automation node(s) that are least likely to adversely affect the voting process automation node's own performance. As a result, the candidate stand-in node that receives the most votes may be the node that is most likely to be able to take over the functions of the node to be replaced without degrading the performance of the process automation system as a whole. Additionally or alternatively, the voting process automation nodes may vote for the candidate stand-in process automation node that has demonstrated the best, most timely, and / or most consistent performance from their own perspective and / or based on objective metrics, the idea being that the node that receives the most votes can be most relied upon as best suited to take over the responsibilities of the other node.

[0059] In some implementations, artificial intelligence and / or machine learning may be used to select from a number of candidate process automation nodes. For example, for each process automation node, a feature vector or feature embedding may be generated that includes various features of the respective node. These feature vectors may then be analyzed for similarity to the disabled process automation node, for example, using techniques such as cosine similarity or dot product, to determine which node is best suited to take over. As another example, different permutations of the process automation facility 108 that would exist if different candidate process automation nodes were to take over the functionality of the disabled node may be generated and represented as candidate state feature vectors. For example, the candidate state feature vector that is most similar to the configuration of the process automation facility 108 prior to the node being disabled or to known functional permutations of a similar process automation facility may be selected.

[0060] 5 illustrates the same scenario as in FIG. 4, where the sensor 118-3 has failed. In this example, the third DCN 110-3 itself may or may not have failed. In any case, as is the case in FIG. 4, instead of diverting the substitute sensor data from the second DCN 110-2 to the third DCN 110-3 via the out-of-band communication channel 109, and then from the third DCN 110-3 back to the first DCN 110-1 via the process automation network 106, the second DCN 110-2 may simply transmit the substitute sensor data directly to the first DCN 110-1 via the out-of-band communication channel 109, as indicated by the bottom shaded arrow. In some such implementations, the diversion module 103 and / or the second DCN 110-2 may first inform the first DCN 110-1 that the substitute sensor data will arrive via the out-of-band communication channel 109 rather than via the process automation network 106.

[0061] 6 is a flowchart illustrating an example method 600 for implementing selected aspects of the disclosure, according to implementations disclosed herein. For convenience, the operations of the flowchart are described with reference to a system that performs those operations. The system may include various components of various computer systems, such as the diversion module 103 and / or other devices, such as any of the DCNs 110-1 to 110-N. Additionally, although the operations of the method 600 are shown in a particular order, this is not intended to be limiting. One or more operations may be reordered, omitted, or added.

[0062] In block 602, the system may establish an out-of-band communication channel (e.g., 109) between two or more process automation nodes (e.g., two or more of DCNs 110-1 to 110-N) of a process automation system (e.g., 108). As previously discussed, the out-of-band communication channel may be external to and / or distinct or separate from a process automation network (e.g., 106) in which the two or more process automation nodes are communicatively coupled to other process automation nodes of the process automation system. The two or more process automation nodes coupled via the out-of-band communication channel 109 may cooperate with one or more of the other process automation nodes to implement an at least partially automated process.

[0063] In some implementations, when one or more of the two or more process automation nodes are being added to the process automation system (e.g., as a stand-in, addition, upgrade, etc.), a first of the two or more process automation nodes may send configuration data to a second of the two or more process automation nodes over an out-of-band communication channel in block 604. In various implementations, the configuration data may include information technology (IT) configuration data usable by the second process automation node to join the process automation network and OT configuration data usable by the second process automation node to collaborate with one or more of the other process automation nodes of the process automation system to implement an at least partially automated process. In various implementations, the IT configuration data and / or the OT configuration data over the out-of-band communication channel 109, rather than via the process automation network 106, can at least partially and / or temporarily protect both the process automation node being added and other existing member nodes from malicious software such as viruses, Trojan horses, etc., at least until appropriate security measures can be implemented.

[0064] At block 606, the system may monitor one or more characteristics of the process automation system, e.g., by the diversion module 103 and / or the individual DCNs 110. As previously described, these characteristics may include, but are not limited to, network traffic, availability and / or validity of function block(s) implemented by the process automation node(s) of the process automation system, etc. With respect to network traffic, the characteristics may include, but are not limited to, a degree of network congestion and / or interruption (e.g., percentage of bandwidth used, percentage of packets dropped / delayed, etc.), a degree(s) of privacy or sensitive nature attributable to at least some of the network traffic, relative priority among packets of the network traffic, etc. Based on the monitoring, at block 608, the system may selectively divert traffic from the process automation network to an out-of-band communication channel, e.g., by the diversion module 103 sending a command and / or by the individual nodes taking an action.

[0065] In optional block 610, the system may exchange device health information between two or more of its nodes via an out-of-band communication channel, for example, by the individual DCNs 110. For example, the third DCN 110-3 may periodically provide the first DCN 110-1 with health data, such as a heartbeat, or the status of a sensor 118-3 (on which the first DCN 110-1 relies for operation of the actuator 116-1). If the first DCN 110-1 does not receive this health data, or if the health data indicates that the sensor 118-3 has failed, the first DCN 110-1 can respond appropriately, for example, by notifying the bypass module 103, requesting substitute sensor data from the second DCN 110-2, etc. Exchanging device health information via an out-of-band communication channel 109 rather than via the process automation network 106 can avoid burdening the process automation network 106 with this additional device health traffic that may not be useful outside of the two or more nodes that exchange it.

[0066] In optional block 612, the system may exchange time-sensitive networking metadata between the two or more nodes over an out-of-band communication channel, for example, by the individual DCNs 110. In many scenarios in which process automation is deployed, such as oil / chemical refining or oil / chemical processing, time may be of the essence. Thus, the nodes may exchange time-sensitive networking metadata that allows the nodes to synchronize their exchange of data in time, even though the underlying process automation network 106 is implemented using an asynchronous communication technology, such as Ethernet. Exchanging time-sensitive networking metadata over an out-of-band communication channel 109 rather than over the process automation network 106 can avoid burdening the process automation network 106 with this additional traffic that may not be useful outside of the two or more nodes exchanging it.

[0067] 7 is a flow chart illustrating an example method 700 in which a DCN (e.g., any of 110-1 through 110-N) performs selected aspects of the disclosure, according to implementations disclosed herein. Although the operations of method 700 are shown in a particular order, this is not intended to be limiting. One or more operations may be reordered, omitted, or added.

[0068] At block 702, a DCN (e.g., any of 110-1 through 110-N in FIGS. 1-5) may join a process automation network using a first communication interface (e.g., 107). The process automation network may communicatively couple multiple process automation nodes of a process automation system. At block 704, the DCN may join an out-of-band communication channel (e.g., 109) between the DCN and one or more other process automation nodes of the process automation system using a second communication interface (e.g., 113).

[0069] At block 706, the DCN may detect the occurrence of an event that triggers diverting traffic from the process automation network to an out-of-band communication channel. For example, the DCN may monitor characteristics of the process automation system, such as network traffic (e.g., network congestion and / or network availability, sensitive packets and / or prioritized packets), the ability of the nodes to perform their respective roles, etc. An event may be detected, for example, if network congestion reaches some threshold, if a portion of the process automation network becomes unavailable, if the sensitive nature or priority of network traffic increases or decreases, or if one or more process automation nodes are no longer able to perform their node roles. Based on the detected event, at block 708, the DCN may divert at least some traffic from the DCN to an out-of-band communication channel.

[0070] 8 is a block diagram of an exemplary computing device 810 that may optionally be utilized to perform one or more aspects of the techniques described herein. The computing device 810 typically includes at least one processor 814 that communicates with a number of peripheral devices via a bus subsystem 812. These peripheral devices may include, for example, a storage subsystem 824 including a memory subsystem 825 and a file storage subsystem 826, a user interface output device 820, a user interface input device 822, and a network interface subsystem 816. The input and output devices enable user interaction with the computing device 810. The network interface subsystem 816 provides an interface to external networks and is coupled to corresponding interface devices in other computing devices.

[0071] The user interface input devices 822 may include a keyboard, a mouse, a trackball, a pointing device such as a touchpad, or a graphics tablet, a scanner, a touch screen integrated into a display, a voice recognition system, an audio input device such as a microphone, and / or other types of input devices. In general, use of the term "input device" is intended to include all possible types of devices and methods for inputting information into the computing device 810 or into a communications network.

[0072] The user interface output devices 820 may include a display subsystem, a printer, a fax machine, or a non-visual display such as an audio output device. The display subsystem may include a flat panel device such as a cathode ray tube (CRT), a liquid crystal display (LCD), a projection device, or some other mechanism for generating a visible image. The display subsystem may also provide a non-visual display, such as via an audio output device. In general, use of the term "output device" is intended to include all possible types of devices and methods for outputting information from the computing device 810 to a user or to another machine or computing device.

[0073] Storage subsystem 824 stores programming and data structures that provide the functionality of some or all of the modules described herein. For example, storage subsystem 824 may include logic to perform selected aspects of the methods of Figures 6-7 as well as to implement the various components shown in Figures 1-5.

[0074] These software modules are generally executed by the processor 814 alone or in combination with other processors. The memory 825 used in the storage subsystem 824 can include several memories, including a main random access memory (RAM) 830 for storing instructions and data during program execution, and a read-only memory (ROM) 832 in which fixed instructions are stored. The file storage subsystem 826 can provide persistent storage for program files and data files, and may include a hard disk drive, a floppy disk drive with associated removable media, a CD-ROM drive, an optical drive, or a removable media cartridge. Modules implementing the functionality of some implementations may be stored by the file storage subsystem 826 in the storage subsystem 824 or in other machines accessible by the processor(s) 814.

[0075] The bus subsystem 812 provides a mechanism for allowing the various components and subsystems of the computing device 810 to communicate with each other as intended. Although the bus subsystem 812 is illustrated generally as a single bus, alternative implementations of the bus subsystem may use multiple buses.

[0076] The computing device 810 can be of various types, including a workstation, a server, a computing cluster, a blade server, a server farm, or any other data processing system or computing device. Due to the ever-changing nature of computers and networks, the description of the computing device 810 shown in Figure 8 is intended only as a specific example intended to illustrate some implementations. Many other configurations of the computing device 810 are possible, having more or fewer components than the computing device shown in Figure 8.

[0077] Although several implementations have been described and illustrated herein, various other means and / or structures for performing the functions and / or obtaining the results and / or one or more of the advantages described herein may be utilized, and each such variation and / or modification is considered to be within the scope of the implementations described herein. More generally, all parameters, dimensions, materials, and configurations described herein are intended to be exemplary, and the actual parameters, dimensions, materials, and / or configurations will depend on the particular application or applications in which the teachings are used. Those skilled in the art will recognize or be able to ascertain, using no more than routine experimentation, many equivalents to the specific implementations described herein. Thus, the implementations described above are presented by way of example only, and it should be understood that within the scope of the appended claims and their equivalents, implementations may be implemented in a manner other than as specifically described and claimed. Implementations of the present disclosure are directed to each individual feature, system, article, material, kit, and / or method described herein. Furthermore, any combination of two or more such features, systems, articles, materials, kits, and / or methods is included within the scope of the present disclosure, if such features, systems, articles, materials, kits, and / or methods are not mutually inconsistent. [Explanation of symbols]

[0078] 100 Environment 102 Process Automation Management System 103 Diversion Module 104 Commission Module 105 Database 106 Process Automation Network 107 Connection 108 Process Automation Facility 109 Out-of-band communication channels 110-1, 110-2, 110-3, 110-N Distributed Control Node 112-1, 112-2, 112-3, 112-N Logic 113-1, 113-2, 113-3, 113-N Communication Interface 114-1, 114-2 Float transmitter components 116-1 Actuator 118, 118-2, 118-3 Sensor 810 Computing Devices 812 Bus Subsystem 814 processor(s) 816 Network Interface 820 User Interface Output Device 822 User Interface Input Devices 824 Memory Subsystem 825 Memory Subsystem 826 File Storage Subsystem 830 Random Access Memory 832 Read-Only Memory

Claims

1. 1. A method implemented using one or more processors, comprising: establishing an out-of-band communication channel between two or more process automation nodes of a process automation system, the out-of-band communication channel being external to a process automation network in which the two or more process automation nodes are communicatively coupled to other process automation nodes of the process automation system, the two or more process automation nodes cooperating with one or more of the other process automation nodes to execute an at least partially automated process; monitoring one or more characteristics of the process automation system; selectively diverting traffic from the process automation network to the out-of-band communication channel based on the monitoring; transmitting configuration data from a first process automation node of the two or more process automation nodes to a second process automation node of the two or more process automation nodes via the out-of-band communication channel; said configuration data comprising: information technology (IT) configuration data usable by the second process automation node to participate in the process automation network; and operational technology (OT) configuration data usable by the second process automation node to execute the at least partially automated process in cooperation with the one or more of the other process automation nodes of the process automation system; and A method comprising:

2. The method of claim 1 , wherein the one or more characteristics monitored of the process automation system include network traffic in the process automation network.

3. The method of claim 2 , wherein the one or more characteristics monitored of the process automation system include network congestion detected based on the network traffic in the process automation network.

4. A method implemented using one or more processors, comprising: establishing an out-of-band communication channel between two or more process automation nodes of a process automation system, the out-of-band communication channel being external to a process automation network in which the two or more process automation nodes are communicatively coupled to other process automation nodes of the process automation system, the two or more process automation nodes cooperating with one or more of the other process automation nodes to execute an at least partially automated process; monitoring one or more characteristics of the process automation system; selectively diverting traffic from the process automation network to the out-of-band communication channel based on the monitoring; Including, the one or more monitored characteristics of the process automation system include network traffic in the process automation network; the one or more monitored characteristics of the process automation system include a degree of privacy assigned to at least some of the network traffic, and the selectively diverting step includes diverting network traffic assigned a first degree of privacy from the process automation network to the out-of-band communication channel.

5. 5. The method of claim 2, wherein the one or more monitored characteristics of the process automation system include a relative priority assigned to at least some of the network traffic, and wherein the selectively diverting step includes diverting network traffic assigned a first relative priority from the process automation network to the out-of-band communication channel.

6. 6. The method of claim 1, wherein the one or more characteristics of the process automation system that are monitored include an ability of a given process automation node of the process automation system to execute a function block.

7. 7. The method of claim 1, wherein the monitoring step is performed by a distributed control node (DCN) prior to the DCN publishing the data to other process automation nodes of the process automation network.

8. 8. The method of claim 1, wherein the two or more process automation nodes include at least three process automation nodes, and the out-of-band communication channel includes a network communicatively coupling the at least three process automation nodes and implemented using a different communication technology than the process automation network.

9. The method of claim 1 , further comprising exchanging device health information between the two or more nodes via the out-of-band communication channel.

10. The method of claim 1 , further comprising exchanging time-sensitive networking metadata between the two or more nodes via the out-of-band communication channel.

11. A distributed control node (DCN), a first communication interface and a second communication interface; Circuit and the circuit comprising: participating in a process automation network using the first communications interface, communicatively coupling a plurality of process automation nodes of a process automation system; participating in an out-of-band communication channel between the DCN and one or more other process automation nodes of the process automation system using the second communication interface; Detects the occurrence of an event, based on said detection of said occurrence of said event, diverting at least some traffic from said DCN to said out-of-band communication channel; configured to transmit configuration data from a first process automation node of the plurality of process automation nodes to a second process automation node of the plurality of process automation nodes via the out-of-band communication channel, the configuration data comprising: information technology (IT) configuration data usable by the second process automation node to participate in the process automation network; and operational technology (OT) configuration data usable by the second process automation node to execute the at least partially automated process in cooperation with the one or more other process automation nodes of the process automation system; and Including, DCN.

12. The DCN of claim 11 , wherein the circuitry is further configured to monitor one or more characteristics of the process automation system for the occurrence of the event.

13. The DCN of claim 12 , wherein the one or more characteristics of the process automation system that are monitored include network traffic in the process automation network.

14. The DCN of claim 13 , wherein the event comprises network congestion in the process automation network.

15. A distributed control node (DCN), comprising: a first communication interface and a second communication interface; Circuit and the circuit comprising: participating in a process automation network using the first communications interface, communicatively coupling a plurality of process automation nodes of a process automation system; participating in an out-of-band communication channel between the DCN and one or more other process automation nodes of the process automation system using the second communication interface; Detects the occurrence of an event, configured to divert at least some traffic from the DCN to the out-of-band communication channel based on the detection of the occurrence of the event; the circuitry is further configured to monitor one or more characteristics of the process automation system for the occurrence of the event; the one or more monitored characteristics of the process automation system include network traffic in the process automation network; A DCN, wherein one or more of the characteristics include a degree of privacy assigned to at least some of the network traffic.

16. 16. The DCN of claim 13, wherein one or more of the characteristics includes a relative priority assigned to at least some of the network traffic.

17. 17. The DCN of claim 12, wherein the circuitry is further configured to monitor the one or more characteristics of the process automation system each time the DCN publishes data to the process automation network.

18. At least one non-transitory computer-readable medium containing instructions, The instructions, in response to execution of the instructions by one or more processors of a distributed control node (DCN), cause the one or more processors to: participating in a process automation network communicatively coupling a plurality of process automation nodes of the process automation system; establishing an out-of-band communication channel between the DCN and one or more other process automation nodes of the process automation system; monitoring the process automation system for the occurrence of an event; diverting at least some traffic from the DCN to the out-of-band communication channel in response to detecting the event; transmitting configuration data from a first process automation node of the plurality of process automation nodes to a second process automation node of the plurality of process automation nodes via the out-of-band communication channel, the configuration data comprising: information technology (IT) configuration data usable by the second process automation node to participate in the process automation network; and operational technology (OT) configuration data usable by the second process automation node to execute the at least partially automated process in cooperation with the one or more other process automation nodes of the process automation system; and At least one non-transitory computer readable medium comprising:

19. 20. The at least one non-transitory computer-readable medium of claim 18, further comprising instructions for exchanging device health information or time-sensitive networking metadata between the DCN and one or more of the other process automation nodes of the process automation system.

Images