Distributed control node (DCN) redundancy

Abstract

The invention relates to distributed control node redundancy. Methods, systems, and apparatus for implementing a redundant DCN system over a process automation network. In one aspect, a redundant DCN system includes a primary DCN, a backup DCN, and a keep-alive procedure configured to determine whether the primary DCN becomes unavailable, where in response to the primary DCN being determined to be unavailable, the backup DCN is reassigned as a new primary DCN, and assumes a function previously performed by a previous primary DCN. Each DCN in the redundant DCN system may have a unique virtual IP address or a transfer common virtual IP address. The virtual IP address may affect communications between the DCN and other devices.

Description

Technical Field

[0001] The present invention relates to a distributed control node (DCN) redundancy technology. Background Art

[0002] Process automation facilities can include countless sensors, actuators, and distributed control nodes (DCNs) that collaborate to perform a variety of different tasks, including managing process control loops. Many of these tasks are mission-critical and / or involve processes that are potentially dangerous if not properly controlled. Therefore, the failure of any component could lead to the failure of the larger task, which could be costly at best and catastrophic at worst. Having redundant DCN systems in place allows the facility to continue operating if a primary DCN fails by quickly switching from the failed primary DCN to one or more backup DCNs. Summary of the Invention

[0003] Embodiments for increasing and / or maintaining the availability of a DCN in a process automation network are described herein. More specifically, but not exclusively, embodiments are described herein for determining the availability of a primary DCN based on a keepalive process and reassigning one or more backup DCNs in communication with the primary DCN as new primary DCNs in response to determining that the primary DCN has become unavailable.

[0004] In various embodiments, a redundant distributed control node (DCN) system may include: one or more shared output channels; a dedicated network that is at least logically separate from a process automation network; a primary DCN that subscribes to one or more remote data feeds based on subscription data and drives one or more of the shared output channels based on one or more of the remote data feeds; and one or more backup DCNs communicatively coupled to the primary DCN via the dedicated network. In various embodiments, a virtual IP address used by the redundant DCN system to exchange data on the process automation network is transferable between the primary DCN and one or more of the backup DCNs. In various embodiments, the primary DCN may be configured to send its subscription data to one or more of the backup DCNs via the dedicated network, and the subscription data may be operable to subscribe one or more of the backup DCNs to one or more of the remote data feeds. In various embodiments, a keepalive process may determine whether the primary DCN has become unavailable and trigger the reassignment of one or more of the backup DCNs as the new primary DCN. In various embodiments, the new primary DCN may subscribe to one or more of the remote data feeds based on the subscription data to drive one or more of the shared output channels. In various embodiments, reassigning as the new primary DCN includes transferring the virtual IP address from the primary DCN to the new primary DCN.

[0005] In various embodiments, the keep alive process is hosted on one or more of the backup DCNs. In various embodiments, the keep alive process is hosted on each of the one or more backup DCNs.

[0006] In various embodiments, the keep-alive process is hosted on a processing node separate from the one or more backup DCNs. In various embodiments, the processing node is integrated with the redundant DCN system. In various embodiments, the primary DCN can be configured to periodically send subscription data.

[0007] In various embodiments, the primary DCN may be configured to send subscription data whenever the primary DCN's subscription data is changed. In various embodiments, the primary DCN's subscription data may change in response to the primary DCN subscribing to a new node. In various embodiments, the primary DCN's subscription data may change in response to the primary DCN modifying an existing subscription.

[0008] In various embodiments, the new primary DCN may load subscription data in response to determining that the primary DCN has become unavailable. In various embodiments, in response to loading the subscription data, the new primary DCN may subscribe to one or more of the remote data feeds and drive one or more of the shared output channels based on the one or more of the remote data feeds.

[0009] In various embodiments, after reassigning one or more of the backup DCNs as the new primary DCN, and in response to the primary DCN being made available again, the primary DCN is assigned as another backup DCN among the one or more backup DCNs, while the virtual IP address remains reassigned to the new primary DCN. After reassigning one or more backup DCNs as the new primary DCN, and in response to the primary DCN being made available again, the primary DCN can be assigned as another backup DCN among the one or more backup DCNs, while the virtual IP address remains reassigned to the new primary DCN.

[0010] In various embodiments, the dedicated network can be implemented using one or more of Ethernet, serial, or bus communication technologies. In various embodiments, the primary DCN or the new primary DCN can share a virtual IP address with another DCN. In various embodiments, the keepalive process can determine the status of the primary DCN periodically and / or in response to a triggering event.

[0011] In another aspect, a method may be implemented by one or more processors and may include: identifying one or more shared output channels and a dedicated network, one or more backup DCNs communicatively coupled to a primary DCN via the dedicated network; determining, based on a keepalive process, whether a primary DCN has become unavailable, the primary DCN subscribing to one or more remote data feeds to drive one or more of the shared output channels based on one or more of the remote data feeds, wherein the primary DCN subscribes to the one or more remote data feeds based on subscription data and sends the subscription data to one or more of the backup DCNs via the dedicated network; and, in response to determining that the primary DCN has become unavailable, reassigning one or more of the backup DCNs as a new primary DCN, wherein the reassignment as the new primary DCN includes transferring a virtual IP address of the primary DCN to the new primary DCN, and wherein the new primary DCN subscribes to one or more of the remote data feeds based on the subscription data. In various embodiments, the keepalive process may be hosted on the one or more backup DCNs.

[0012] In another aspect, a redundant DCN system may include: one or more computers including one or more processors, and one or more storage devices storing instructions operable, when executed by the one or more computers, to cause the one or more processors to perform operations comprising: determining whether a primary DCN has become unavailable, the primary DCN currently or previously subscribed to one or more remote data feeds to drive one or more shared output channels based on one or more of the remote data feeds; identifying one or more backup DCNs communicatively coupled to the primary DCN via a dedicated network, the dedicated network being logically separate from a process automation network associated with the redundant DCN system, wherein a virtual IP address used by the redundant DCN system to exchange data on the process automation network is transferable between the primary DCN and one or more of the backup DCNs, and wherein subscription data of the primary DCN is sent to the one or more of the backup DCNs via the dedicated network; and in response to determining that the primary DCN has become unavailable, redesignating one or more of the backup DCNs as new primary DCNs, wherein the redesignation as new primary DCN comprises transferring the virtual IP address of the primary DCN to the new primary DCN.

[0013] In various implementations, the new primary DCN may subscribe to one or more remote data feeds based on the subscription data.

[0014] It should be understood that all combinations of the foregoing concepts and additional concepts described in greater detail herein are contemplated as being part of the subject matter disclosed herein. For example, all combinations of the claimed subject matter appearing at the end of this disclosure are considered to be part of the subject matter disclosed herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 An example environment is schematically depicted in which selected aspects of the present disclosure may be implemented.

[0016] Figure 2 Example environments are schematically depicted in which selected aspects of the present disclosure may be or have been implemented.

[0017] Figure 3 A redundant DCN system is schematically depicted that includes a dedicated network communicatively coupling a primary DCN with one or more backup DCNs, and a keep-alive process for determining if the primary DCN is unavailable.

[0018] Figure 4 Schematically depicts a redundant DCN system after implementing one or more selected aspects of the present disclosure, including reassigning a backup DCN as a new primary DCN, transferring a virtual IP address of the primary DCN to the new primary DCN, subscribing the new primary DCN to a remote data feed, and driving an output channel by the new primary DCN.

[0019] Figure 5 Example methods for carrying out aspects of the present disclosure are schematically depicted.

[0020] Figure 6 An example computer architecture is schematically illustrated upon which selected aspects of the present disclosure may be implemented. DETAILED DESCRIPTION

[0021] Embodiments for increasing and / or maintaining the availability of a DCN in a process automation network are described herein. More specifically, but not exclusively, embodiments are described herein for determining the availability of a primary DCN based on a keepalive process and reassigning one or more backup DCNs in communication with the primary DCN as new primary DCNs in response to determining that the primary DCN has become unavailable.

[0022] A DCN may include one or more input-output (I / O) channels associated with various types of equipment in a process automation facility. Output channels may be associated with output devices such as actuators, valves, and dampers. Input channels may be associated with input devices such as various types of sensors, flow meters, and computing nodes. The DCN may drive the output channels of these output devices based on data received from one or more data sources, such as one or more remote DCNs (or components thereof) to which the DCN subscribes.

[0023] In some embodiments, the DCNs may share an I / O channel, such that each DCN sharing the I / O channel receives or transmits information using the I / O channel. In some embodiments, the DCNs may not share an I / O channel, thereby preventing a DCN not associated with the I / O channel from receiving or transmitting information associated with the I / O channel. In various embodiments, the DCNs may facilitate control of one or more devices (e.g., actuators, valves, dampers, etc.) based on data received from sensors elsewhere in the process automation facility.

[0024] Process automation devices, such as a DCN, can be configured to communicate with other process automation devices using various open (e.g., non-proprietary) and / or standardized communication protocols, which will be described herein as "cross-platform." Cross-platform communication protocols may be governed by various regulations and / or standards, such as the Open Platform Communications (OPC) Unified Architecture (UA). Thus, while in various examples described herein, a DCN is described as hosting one or more "OPC UA clients" and / or one or more "OPC UA servers," this is not meant to be limiting. A DCN may host other types of cross-platform clients and / or cross-platform servers; OPC UA is merely one example.

[0025] In some cases, a DCN may become unavailable. The reasons for a DCN becoming unavailable can vary, but may include failures or malfunctions. The availability of a DCN can have a negative impact on facility operations. For example, OPC UA clients may subscribe to OPC UA servers, and the failure of one or the other may have adverse consequences. When a DCN becomes unavailable, functions performed by other components subscribed to the DCN, such as other DCNs (or OPC UA clients hosted thereon), may be performed incorrectly or based on inaccurate information. For example, suppose a DCN to which another DCN controlling a valve is subscribed is disabled. This could result in the subscribing DCN being unable to properly manage flow through the valve, which could have adverse effects on its own or could further adversely affect larger processes, such as control loops.

[0026] To avoid and / or mitigate adverse effects on system processes in response to the unavailability of a primary DCN, one or more other DCNs in a redundant DCN system may be designated as "backup" DCNs. A backup DCN may have similar or identical attributes to the primary DCN, or may have alternative attributes. In some cases, the alternative attributes may make the backup DCN less susceptible to the unavailability. In response to determining that the previous primary DCN has become unavailable, the backup DCN may be redesignated as the "new primary" DCN. Some embodiments may include multiple DCNs designated as backup DCNs, and some embodiments may also include processes running on the backup DCN before being redesignated as the new primary DCN. The number and quality of DCNs designated as primary or backup DCNs is highly customizable and tailored to facility requirements.

[0027] In various embodiments, two or more DCNs of a redundant DCN system can be communicatively coupled to each other using a dedicated network. The dedicated network can be logically separate from, but connected to, a larger process automation network via one or more entry points. The dedicated network can be implemented using a variety of different communication technologies, such as Ethernet, serial bus, Wi-Fi, Bluetooth, Zigbee or Z-Wave, IP subnet, etc.

[0028] In some embodiments, a single virtual IP address can be assigned to a group of DCNs communicatively coupled via a dedicated network and can be transferred between the DCNs. Additionally, in some embodiments, each DCN can have its own non-virtual (or "traditional," "normal") IP address. For example, a virtual IP address can be transferred between multiple DCNs by mapping (and / or remapping) it to a different non-virtual IP address of the DCN. Thus, the virtual IP address can serve as a single entry / exit point to / from a redundant DCN system comprising a primary DCN and one or more backup DCNs communicatively coupled via a dedicated network.

[0029] In various embodiments, devices such as DCNs can be configured to communicate with a specific virtual IP address. For example, when an OPC UA client hosted by a first DCN subscribes to an I / O channel (e.g., a sensor) hosted by a second DCN, the OPC UA client hosted by the first DCN can be provided with a virtual IP address used by the second DCN. The OPC UA client on the first DCN can then use this virtual IP address to communicate with an OPC UA server hosted by the second DCN, for example, to retrieve sensor data from the second DCN's I / O channel. If the second DCN becomes disabled, the virtual IP address can be transferred to a third, "backup" DCN residing on the same private network as the second DCN. OPC UA clients on the first DCN can continue to use the same virtual IP address, except now they are communicating with an OPC UA server hosted by the third DCN.

[0030] In some embodiments, each primary and backup DCN of a redundant DCN system can be communicatively coupled, directly or indirectly, to a larger process automation network via its traditional / non-virtual IP address. A single virtual IP address, transferable between DCNs, can be used to restrict how other nodes of the larger process automation network can communicate with these DCNs, for example, via the single ingress / egress point mentioned previously. Additionally or alternatively, in some embodiments, the redundant DCN system can include a single network interface connecting the redundant DCN system to the larger process automation network. Within the redundant DCN system, and specifically using a dedicated network logically contained within the redundant DCN system, virtual IP addresses can be transferred between multiple DCNs as needed (e.g., in the event of a primary DCN failure).

[0031] Subscription data may indicate one or more subscriptions by a DCN (e.g., by an OPC UA client hosted thereon) to one or more remote data feeds and / or output channels. Subscription data associated with a primary DCN may be shared with a backup DCN. For example, subscription data may be shared to enable a backup DCN to take over one or more functions performed by the primary DCN by subscribing to one or more remote data feeds used by the primary DCN to perform the functions. Thus, output channels driven by the primary DCN may also be shared among DCNs in a redundant set. As previously described, multiple DCNs may be designated as backup DCNs, and data, including subscription data, may be shared differently or identically among each of the multiple backup DCNs.

[0032] A "keep alive" procedure can be implemented to determine whether a primary DCN is available or unavailable. The keep alive procedure can be configured to monitor a DCN for unavailability periodically, continuously, and / or on demand. The keep alive procedure can be executed between one or more of a primary DCN, a backup DCN, or an independent node that is separate from the primary DCN or backup DCN. For example, a corresponding instance of the keep alive procedure can be executed on each of a plurality of backup DCNs. In response to the keep alive procedure determining that a primary DCN is unavailable, the instance of the keep alive procedure can reassign the backup DCN as the new primary DCN. Reassigning a backup DCN as the new primary DCN can be based on one or more of several factors, such as hardware capabilities, software capabilities, and the availability of a particular DCN.

[0033] After the backup DCN is reassigned as the new primary DCN, the new primary DCN can take over the roles previously performed by the previous primary DCN. The new primary DCN can use the subscription data provided by the previous primary DCN to quickly adapt to the updated role. For example, based on the subscription data, the new primary DCN can drive one or more of the same output channels as the old primary DCN and subscribe to one or more of the same remote data feeds as the old primary DCN.

[0034] In some cases, the old primary DCN may become available again. The newly available old primary DCN may be reassigned as a backup DCN. Alternatively, the new primary DCN may be restored back to backup DCN status, and the original primary DCN may be restored to its previous state. The protocol for bringing the old primary DCN back online is customizable and can be adapted to facility requirements.

[0035] Figure 1 An example environment in which selected aspects of the present disclosure may be implemented, according to various embodiments, is schematically depicted. An OPC UA client 64 hosted by a remote DCN 62 may subscribe to information from a DCN 12, or more specifically, to information from an OPC UA server 66 hosted by DCN 12. DCNs 62 and 12 may be communicatively coupled via a larger process automation network 60. DCN 12 may be connected to an I / O module 16 that provides information from a device 20. For illustrative purposes, a device 20 may include a sensor that generates sensor data that DCN 12 retrieves and publishes from the I / O module 16. An OPC UA client 64 may subscribe to this data in order to control another piece of equipment (not shown), such as an actuator, valve, or damper, in a process automation facility.

[0036] The DCN 12 may be communicatively coupled to other components of the redundant DCN system via a dedicated network 10. The dedicated network 10 may be logically separate from the larger process automation network 60 and may include one or more entry / exit points to the larger process automation network 60. The dedicated network 10 may communicatively couple the primary DCN 12, one or more backup DCNs 14, and the I / O modules 16. The I / O modules 16 may be configured to receive information from and / or provide information to each of the primary DCN 12 and the backup DCN 14.

[0037] As previously discussed, a single virtual IP address can be assigned to and transferred between primary DCN 12 and backup DCN 14. Devices 20 and OPC UA clients 64, which may be located outside of private network 10, can perceive primary DCN 12 and backup DCN 14 as a single entity because only one of primary DCN 12 and backup DCN 14 uses the virtual IP address at a time. In various embodiments, the virtual IP address can be transferred between primary DCN 12 and backup DCN 14 so that both primary DCN 12 and backup DCN 14 do not share the virtual IP address simultaneously. In other words, the virtual IP address, which is transferable between DCNs 12 and 14, can serve as the single entry / exit point mentioned previously.

[0038] Figure 2 Schematically depicts an example environment in which selected aspects of the present disclosure may be implemented. For example, a primary DCN 12 is depicted as previously or currently unavailable. As discussed herein, DCN unavailability may be due to various reasons, including but not limited to failures, malfunctions, disconnections, or larger facility issues.

[0039] In response to primary DCN 12 becoming unavailable, a keepalive process (not shown) may cause backup DCN 14 to take over the functions of primary DCN 12. In other words, the keepalive process may reassign backup DCN 14 as the new primary DCN, for example, by reassigning the virtual IP address previously assigned to primary DCN 12 to backup DCN 14. Based on backup DCN 14 being reassigned as the new primary DCN, I / O modules 16 may forward information associated with devices 20 (e.g., sensor data) to backup DCN 14. Similarly, based on backup DCN 14 being reassigned as the new primary DCN, backup DCN 14 may host OPC UA server 66A and exchange information with OPC UA clients operating on remote DCN 62.

[0040] Figure 3The schematic diagram illustrates an environment in which selected aspects of the present disclosure may be implemented. The environment may include a device 20, a remote DCN 62 operating as a cross-platform server, and an OPC UA server 66. The remote DCN may be connected to a redundant DCN system 100 via one or more process automation networks 60. One or more devices (e.g., sensors, actuators) may also be operably coupled to the redundant DCN system 100.

[0041] Within the redundant DCN system 100, a dedicated network 10 can communicatively couple a primary DCN 12, a backup DCN 14, I / O modules 126, and one or more keepalive processes 50. As discussed herein, the dedicated network 10 can be at least logically separate from the process automation network 60. For example, the dedicated network 10 can be implemented as a subnet of, or separate from, a larger process automation network 60. Additionally or alternatively, the dedicated network 10 can carry only traffic between the DCNs 12 and 14 and the keepalive processes 50 (and I / O modules, if applicable).

[0042] The private network 10 is "private" so that the DCNs 12, 14 included in the redundant DCN system 100 can easily and privately transfer information such as subscription data 40 and / or virtual IP addresses 42. In many embodiments, components external to the private network 10 (such as devices 20 and remote DCN 62) are unaware of which DCN included in the private network 10 is processing and exchanging information. That is, devices external to the redundant DCN system 100 can only seek to exchange information based on a specific IP address, and whether the specific IP address is transferred from the primary DCN 12 to the backup DCN 14 is not exposed to them.

[0043] Thus, primary DCN 12 includes a virtual IP address 42. As discussed herein, remote DCN 62 (and more specifically, OPC UA servers 66) can be configured to direct subscription data (e.g., sensor readings) to a particular virtual IP address, such as virtual IP address 42 associated with primary DCN 12. If keepalive process 50 determines that primary DCN 12 has become unavailable, keepalive process 50 and / or backup DCN 14 can ensure that the backup DCN assumes the same virtual IP address 42 previously held by primary DCN 12. Subsequently, based on backup DCN 14 appearing under the same identity attributed to the former primary DCN 12 at virtual IP address 42, OPC UA servers 66 hosted by remote DCN 62 can feed the same data (e.g., sensor readings) to backup DCN 14 as OPC UA servers 66 did with primary DCN 12.

[0044] The primary DCN 12 and the backup DCN 14 may also include respective instances of a cross-platform client, an OPC UA client 64A and an OPC UA client 64B, and subscription data 40. As indicated by the arrows, subscription data 40, such as virtual IP addresses 42, may be exchanged between the primary DCN 12 and the backup DCN 14. The subscription data 40 may indicate a DCN (and more specifically, an OPC UA client 64 (see Figure 1-2 Subscription data 40 indicates which remote data feeds published by an OPC UA server hosted on a remote DCN (e.g., a cross-platform client) the DCN subscribes to. Subscription data 40 may also indicate which device 20 the DCN "drives" (e.g., provides output to which device). For example, subscription data may indicate that OPC UA client 64A subscribes to data feeds published by OPC UA server 66 hosted by remote DCN 62. Subscription data 40 may be unique or identical, depending on whether or when it was last shared between primary DCN 12 and backup DCN 14. In some embodiments, sharing subscription data between primary DCN 12 and backup DCN 14 can make reassignment more efficient (should backup DCN 14 be reassigned as the new primary DCN).

[0045] Keepalive process 50 can determine whether primary DCN 12 becomes unavailable. If primary DCN 12 becomes unavailable, backup DCN 14 can be reassigned as the new primary DCN. As discussed herein, keepalive process 50 can be executed periodically, continuously, on demand, and / or in response to certain conditions. For example, keepalive process 50 can be configured to execute daily, continuously, on demand for one or more user accounts, and / or in response to temporary power outages and blackouts.

[0046] Although Figure 3 Keepalive process 50 is depicted as a standalone process connected to other components of redundant DCN system 100 via dedicated network 10. However, some embodiments may include keepalive process 50 occurring on one or more of primary DCN 12, backup DCN 14, a separate node included in dedicated network 10, a separate node included in process automation network 60, or a separate node external to process automation network 60. In some cases, the separate node is integrated with the redundant DCN system. Furthermore, in some embodiments, multiple instances of keepalive process 50 may run sequentially or concurrently. Furthermore, in some embodiments, a single instance of keepalive process 50 may run on multiple devices, such as primary DCN 12 and backup DCN 14. In embodiments implementing multiple backup DCNs, each of the multiple backup DCNs may host an instance of keepalive process 50.

[0047] Keepalive process 50 can communicate continuously or intermittently with one or more of primary DCN 12 and backup DCN 14. In some embodiments, keepalive process 50 communicates with both primary DCN 12 and backup DCN 14 to identify the status of each DCN. Thus, while the function of keepalive process 50 is to identify the status of primary DCN 12 (particularly, whether primary DCN 12 is unavailable), keepalive process 50 can also determine the status of one or more other DCNs, including backup DCN 14. By determining the status of both primary DCN 12 and backup DCN 14, keepalive process 50 can proactively identify failures within the redundant DCN system. For example, by identifying that primary DCN 12 is available but backup DCN 14 is unavailable, keepalive process 50 can determine that a different DCN should be redesignated as the backup DCN.

[0048] In some embodiments, the keep alive process 50 may assist in ranking backup DCNs. For example, in a redundant DCN system including multiple potential backup DCNs (e.g., 100), the keep alive process 50 may assist in ranking backup DCN 14 as the first choice for redundancy should primary DCN 12 be determined to be unavailable, but may prioritize the second or third choices ( Figure 3 The backup DCNs 14 are ranked for redundancy (not shown). Ranking the backup DCNs for redundancy can be based on hardware, software, network access, previous status as a primary DCN, and / or previous failure rates. Thus, the designation of a backup DCN 14 as a "primary" backup can change based on a number of dynamic factors.

[0049] Figure 4 Schematically depicts a process after implementing one or more selected aspects of the present disclosure. Figure 3 Components within the redundant DCN system 100. Figure 4 In the example embodiment, the primary DCN 12 becomes unavailable (indicated by cross-hatching). As discussed herein, DCN unavailability may be caused automatically, manually, coincidentally, or intentionally. The primary DCN 12 may be unable to perform one or more functions based on the unavailability.

[0050] To prevent and / or mitigate the impact on process automation due to the unavailability of the primary DCN 12, the keep-alive process 50 is configured to detect that the primary DCN 12 has become unavailable and reassign the backup DCN 14 as the new primary DCN, which will take over one or more functions previously performed by the primary DCN 12 after the reassignment. In some cases, the new primary DCN 14 may take over fewer, alternative, or more functions relative to the primary DCN 12. The new primary DCN 14 and one or more of the keep-alive processes 50 may help determine which functions the new primary DCN 14 will perform compared to the previous primary DCN 12. As described in Figure 4 As indicated in and discussed herein, reassignment may include the transfer of the virtual IP address 42 from the primary DCN 12 to the new primary DCN 14. This transfer may occur after the keepalive process 50 determines that the primary DCN 12 is unavailable. The transfer of the virtual IP address 42 need not be accomplished directly from the DCN 12 to the DCN 14—indeed, this may not be possible if the primary DCN 12 fails completely. In some embodiments, the transfer of the virtual IP address 42 from the primary DCN 12 to the backup DCN 14 may be accomplished, for example, by the keepalive process 50.

[0051] The reassignment may enable the OPC UA client 64B hosted by the new primary DCN 14 to immediately retrieve information from remote data feeds to which the OPC UA client 64B has subscribed, such as feeds published by the OPC UA server 66 hosted by the remote DCN 62. Based on this retrieved data, the OPC UA client 64B may output information (e.g., sensor readings, actuation instructions, etc.) to the device 20.

[0052] After the backup DCN 14 is reassigned as the new primary DCN, the remote DCN 62, I / O modules 16, and / or devices 20 may cease exchanging information with the previous primary DCN 12. Instead, the remote DCN 62 and devices 20 may exchange information with the new primary DCN 14. The remote DCN 62 can effect this transition without any additional configuration by continuing to send data it publishes to the same virtual IP address 42, which now directs data to the new primary DCN 14 instead of the previous primary DCN 12. The I / O modules 16 can similarly effect this transition, for example, by directing all traffic to the same virtual IP address 42. Additionally or alternatively, the I / O modules 16 can effect this transition in other ways, for example, by rerouting communication channels from the previous primary DCN 12 to the new primary DCN 14.

[0053] In some embodiments, a DCN is configured to send subscription data 40 to one or more other DCNs whenever subscription data 40 is updated. Proactively distributing subscription data 40 updates to one or more other DCNs ensures that if the primary DCN 12 becomes unavailable, each DCN in the redundant set has current subscription data 40 to operate with. This enables the reassigned DCN to quickly take over functions previously performed by another DCN. For example, the subscription data 40 of the backup DCN 14 can be updated based on the primary DCN 12 subscribing to or unsubscribing from a new data feed published by a new or existing OPC UA server 66, or modifying an existing subscription.

[0054] After backup DCN 14 is assigned the role of the new primary DCN and driver of devices 20 based on one or more remote data feeds published by OPC UA server 66 hosted by remote DCN 62, the former primary DCN 12 may become available again. Upon becoming available again, the former primary DCN 12 may be reassigned as the primary DCN again, and the new primary DCN 14 may be reassigned as the backup DCN again. Alternatively, upon becoming available again, the former primary DCN 12 may be reassigned as the backup DCN, while the new primary DCN 14 remains unchanged.

[0055] Figure 5 Included is a flowchart illustrating an example method 500 for performing various aspects of the present disclosure. For convenience, the operations of the flowchart are described with reference to a system performing the operations. The system may include various components of various computer systems. Furthermore, while the operations of method 500 are shown in a particular order, this is not meant to be limiting. One or more operations may be reordered, omitted, and / or added. The methods, systems, and apparatus disclosed herein, including but not limited to method 500, may be implemented using one or more processors.

[0056] At block 502, the system identifies one or more shared output channels and a dedicated network that are at least logically separate from a process automation network. These components may be part of a redundant DCN system (e.g., 100). While the dedicated network may be included in the process automation network, it may be logically isolated, for example, as indicated by its "dedicated" status. In some embodiments, the dedicated network may be external to the process automation network and may include one or more entry / exit points for communicating with the external process automation network. The one or more shared output channels may or may not be separate from the process automation network.

[0057] At block 504, the system subscribes the primary DCN of the private network and associated with the virtual IP address to one or more remote data feeds. This can include, for example, a cross-platform client (e.g., OPC UA client 64) hosted by the primary DCN subscribing to one or more data feeds published by a remote cross-platform server (e.g., OPC UA server 66). In some embodiments, the system can subscribe the primary DCN to one or more data feeds based on new or existing subscription data. As disclosed herein, designating a DCN as the primary DCN can be based on a variety of factors of the DCN, including hardware, software, location, accessibility, reliability, and configuration. A private network can communicatively couple multiple DCNs, with the primary DCN being only one DCN. For example, as discussed herein, a private network can host one or more backup DCNs. As previously explained, at various points in time, such as periodically and / or in response to the primary DCN 12 updating its subscription data, the primary DCN 12 can provide (e.g., clone) its latest subscription data to the backup DCN 14 so that the backup DCN 14 can quickly take over if a need arises. In various embodiments, although the primary DCN and backup DCN may share the same subscription data, only the primary DCN may receive information from a remote data feed if the remote data feed is configured to provide information to a virtual IP address currently assigned to the primary DCN.

[0058] Return to Figure 5 At block 506, the system determines whether the primary DCN has become unavailable. A DCN may become unavailable for a variety of reasons, including failure, destruction, and disconnection. As disclosed herein, a keepalive process (e.g., 50) may be performed by one or more DCNs on a dedicated network and / or by separate nodes within or outside the network. That is, the keepalive process may run simultaneously across multiple devices, may run on a single device, or may be partially run by multiple devices. The keepalive process may, for example, prevent and / or mitigate the effects of a DCN becoming unavailable by determining that the DCN is available. Thus, in some embodiments, the keepalive process may determine that the primary DCN is available and / or that one or more backup DCNs are available when the primary DCN becomes unavailable. As discussed herein, the keepalive process may be performed continuously, periodically, on demand, or in response to certain events, for example.

[0059] In response to determining that the primary DCN has become unavailable, at block 508, the system reassigns one or more of the backup DCNs on the private network as the new primary DCN using the virtual IP address. Reassigning one or more backup DCNs as the new primary DCN can enable the backup DCNs (which previously received the latest subscription data from the primary DCN) to perform one or more functions of the primary DCN. This can be beneficial, for example, when the primary DCN contributes to a critical process, and without the primary DCN's contribution, the process could fail or be performed incorrectly or inefficiently. Thus, having a redundant set of DCNs in place when the primary DCN becomes unavailable can significantly benefit the process by creating a failover to ensure productivity, efficiency, and procedural correctness.

[0060] In some embodiments, multiple backup DCNs can be reassigned as primary DCNs via virtual IP addresses and / or virtual machines. For example, a backup DCN can include a DCN currently implementing other processes, such that only a subset of its overall processing capacity is available to assume the functions of the unavailable primary DCN. Thus, the backup DCN's processing capacity can be partitioned and / or reserved for backup purposes, while the remaining processing capacity of the backup DCN can be dedicated to one or more other functions. This allows a backup DCN, which itself is unable to fully assume the functions of the now-unavailable primary DCN, to collaborate with one or more other DCNs and use the combined processing capacity to fully assume the functions of the now-unavailable primary DCN. Virtual IP addresses and virtual machines can be implemented in association with these partitions to represent I / O channels associated with the partitions as coming from a "single" new primary DCN. As discussed, devices can be configured to receive I / O only from identified devices, and by masking the backup DCN partitions under a common virtual IP address, the functions previously performed by the primary DCN can be effectively assumed by multiple backup DCNs, appearing as a single, identified DCN.

[0061] At block 510, the system determines, in response to the reassignment, that the new primary DCN subscribes to one or more remote data feeds based on subscription data. In some embodiments, the new primary DCN subscribes to one or more of the remote data feeds to drive one or more shared output channels. As discussed herein, subscription data can be transferred between DCNs prior to failure of one or more of those DCNs. This shared subscription data can be used to determine which remote data the backup DCN subscribes to and / or which output channels the backup DCN drives. As also discussed herein, the keepalive process can determine not only whether a DCN is unavailable but also whether it is available. In some embodiments, determining whether the new primary DCN is available can include determining whether the DCN subscribes to one or more of the remote data feeds to drive one or more of the shared output channels. This can ensure that functions previously performed by the primary DCN are being performed by the new primary DCN.

[0062] Figure 6 6 is a block diagram of an example computing device 610, which can optionally be used to perform one or more aspects of the techniques described herein. Computing device 610 typically includes at least one processor 614 that communicates with a number of peripheral devices via a bus subsystem 612. These peripheral devices may include a storage subsystem 624 (including, for example, a memory subsystem 625 and a file storage subsystem 626), a user interface output device 620, a user interface input device 622, and a network interface subsystem 616. Input and output devices allow a user to interact with computing device 610. Network interface subsystem 616 provides an interface to an external network and connects to corresponding interface devices in other computing devices.

[0063] The user interface input devices 622 may include a keyboard, a pointing device such as a mouse, trackball, touchpad, or graphics tablet, a scanner, a touch screen incorporated into a display, an audio input device such as a voice recognition system, a microphone, and / or other types of input devices. In general, the use of the term "input device" is intended to include all possible types of devices and ways of entering information into the computing device 610 or onto a communication network.

[0064] User interface output devices 620 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 cathode ray tube (CRT), a flat-panel device such as a liquid crystal display (LCD), a projection device, or some other mechanism for creating a visible image. The display subsystem may also provide a non-visual display, such as via an audio output device. In general, the use of the term "output device" is intended to include all possible types of devices and ways of outputting information from computing device 610 to a user or another machine or computing device.

[0065] The storage subsystem 624 stores programming and data structures that provide the functionality of some or all of the modules described herein. For example, the storage subsystem 624 may include a Figure 5 Selected aspects of the method and methods for implementing Figures 1 to 4 Various aspects described in.

[0066] These software modules are typically executed by processor 614 alone or in combination with other processors. The memory 625 used in storage subsystem 624 may include multiple memories, including a main random access memory (RAM) 630 for storing instructions and data during program execution and a read-only memory (ROM) 632 in which fixed instructions are stored. The file storage subsystem 626 may provide persistent storage for program and data files and may include a hard drive, a floppy disk drive and associated removable media, a CD-ROM drive, an optical drive, or a removable media cartridge. Modules that implement the functionality of certain embodiments may be stored by file storage subsystem 626 in storage subsystem 624 or in another machine accessible by processor(s) 614.

[0067] The bus subsystem 612 provides a mechanism for the various components and subsystems of the computing device 610 to communicate with each other as intended. Although the bus subsystem 612 is shown schematically as a single bus, alternative implementations of the bus subsystem may use multiple busses.

[0068] The computing device 610 can be of various types, including a workstation, server, computing cluster, blade server, server farm, or any other data processing system or computing device. Due to the ever-changing nature of computers and networks, Figure 6 The description of computing device 610 depicted in FIG is intended only as a specific example for purposes of illustrating some embodiments. Figure 6 Many other configurations of computing device 610 are possible with more or fewer components than those depicted.

[0069] Although several embodiments have been described and illustrated herein, a variety of other devices and / or structures may be utilized to perform the functions and / or obtain the results and / or one or more advantages described herein, and each of such variations and / or modifications is considered to be within the scope of the embodiments described herein. More generally, all parameters, dimensions, materials, and configurations described herein are meant to be exemplary, and the actual parameters, dimensions, materials, and / or configurations will depend on the specific application or applications in which the teachings are used. Those skilled in the art will recognize or be able to determine many equivalents to the specific embodiments described herein using no more than routine experimentation. Therefore, it should be understood that the foregoing embodiments are presented by way of example only, and within the scope of the appended claims and their equivalents, the embodiments may be implemented in a manner other than as specifically described and claimed. Embodiments of the present disclosure are directed to each individual feature, system, article, material, kit, and / or method described herein. In addition, 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 they are not mutually inconsistent.

Claims

1. A redundant distributed control node (DCN) system, comprising: one or more shared output channels; a dedicated network that is at least logically separated from the process automation network; a master DCN that subscribes to one or more remote data feeds based on subscription data and drives one or more of the shared output channels based on one or more of the remote data feeds; as well as one or more backup DCNs, the backup DCNs being communicatively coupled to the primary DCN via the dedicated network, wherein a virtual IP address used by the redundant DCN system to exchange data on the process automation network is transferable between one or more of the primary DCN and the backup DCN, and wherein the primary DCN sends the subscription data of the primary DCN to one or more of the backup DCNs via the dedicated network, wherein the subscription data is operable to subscribe one or more of the backup DCNs to one or more of the remote data feeds; and a keep-alive process for determining whether the primary DCN has become unavailable and, in response to determining that the primary DCN has become unavailable, triggering reassignment of one or more of the backup DCNs as new primary DCNs, wherein the new primary DCN subscribes to one or more of the remote data feeds based on the subscription data to drive one or more of the shared output channels, and The reassigning as the new primary DCN includes: transferring the virtual IP address from the primary DCN to the new primary DCN.

2. The redundant DCN system according to claim 1, wherein: The keep-alive process is hosted on one or more of the backup DCNs.

3. The redundant DCN system according to claim 1, wherein: The keep-alive process is hosted on each of the one or more backup DCNs.

4. The redundant DCN system according to claim 1, wherein: The keep-alive process is hosted on a processing node separate from the one or more backup DCNs.

5. The redundant DCN system according to claim 4, wherein: The processing node is integrated into the redundant DCN system.

6. The redundant DCN system according to claim 1, wherein: The primary DCN is configured to periodically send the subscription data.

7. The redundant DCN system according to claim 1, wherein: The primary DCN is configured to send the subscription data whenever the subscription data of the primary DCN is changed.

8. The redundant DCN system according to claim 7, wherein: The subscription data of the primary DCN is changed in response to the primary DCN subscribing to a new node.

9. The redundant DCN system according to claim 7, wherein: The subscription data of the primary DCN is changed in response to the primary DCN modifying an existing subscription.

10. The redundant DCN system according to claim 1, wherein: The new primary DCN loads the subscription data in response to determining that the primary DCN has become unavailable.

11. The redundant DCN system according to claim 10, wherein: In response to loading the subscription data, the new primary DCN subscribes to one or more of the remote data feeds and drives one or more of the shared output channels based on the one or more of the remote data feeds.

12. The redundant DCN system according to claim 1, wherein: After reassigning one or more of the backup DCNs as the new primary DCN, and in response to making the primary DCN available again, the primary DCN is assigned as another backup DCN of the one or more backup DCNs, while the virtual IP address remains reassigned to the new primary DCN.

13. The redundant DCN system according to claim 1, wherein: The dedicated network is implemented using one or more of Ethernet, serial or bus communication technologies.

14. The redundant DCN system according to claim 1, wherein: The primary DCN or the new primary DCN shares the virtual IP address with another DCN.

15. The redundant DCN system according to claim 1, wherein: The keep-alive process periodically determines the status of the primary DCN.

16. The redundant DCN system according to claim 1, wherein: The keep-alive process determines the status of the primary DCN in response to a triggering event.

17. A method implemented by one or more processors, the method comprising: identifying one or more shared output channels and a dedicated network through which one or more backup DCNs are communicatively coupled to the primary DCN; determining, based on a keep-alive procedure, whether the primary DCN has become unavailable, the primary DCN subscribing to one or more remote data feeds to drive one or more of the shared output channels based on one or more of the remote data feeds, wherein the primary DCN subscribes to the one or more remote data feeds based on subscription data, and sends the subscription data to one or more of the backup DCNs via the dedicated network; and In response to determining that the primary DCN has become unavailable, redesignating one or more of the backup DCNs as new primary DCNs, wherein redesignating as the new primary DCN comprises transferring a virtual IP address of the primary DCN to the new primary DCN, and wherein the new primary DCN subscribes to one or more of the remote data feeds based on the subscription data.

18. The method according to claim 17, wherein: The keep-alive process is hosted on one or more of the backup DCNs.

19. A redundant distributed control node (DCN) system comprising: One or more computers comprising one or more processors and one or more storage devices storing instructions, the instructions being operable, when executed by the one or more computers, to cause the one or more processors to perform operations comprising: determining whether a primary DCN has become unavailable, the primary DCN currently or previously subscribed to one or more remote data feeds to drive one or more shared output channels based on one or more of the remote data feeds; identifying one or more backup DCNs communicatively coupled to the primary DCN via a dedicated network, the dedicated network being logically separate from a process automation network associated with the redundant DCN system, wherein a virtual IP address used by the redundant DCN system to exchange data on the process automation network is transferable between the primary DCN and one or more of the backup DCNs, and wherein subscription data of the primary DCN is sent to one or more of the backup DCNs via the dedicated network; and In response to determining that the primary DCN has become unavailable, redesignating one or more of the backup DCNs as new primary DCNs, wherein redesignating as the new primary DCN comprises transferring the virtual IP address from the primary DCN to the new primary DCN.

20. The redundant distributed control node (DCN) system according to claim 19, wherein: The new primary DCN subscribes to one or more of the remote data feeds based on the subscription data.

Images