Distribution control node (DCN) redundancy

Abstract

To provide a method, a system and a device for implementing a redundant distribution control node (DCN) system through a process automated network.SOLUTION: A redundant DCN system includes a primary DCN, a backup DCN, and a keep alive process for determining whether or not the primary DCN is unavailable, and reassigns the backup DCN as a new primary DCN in response to determination that the primary DCN is unavailable, and has a function previously executed by the previous primary DCN. Each of the DCN in the redundant DCN system may have a unique virtual IP address, or may transfer a common virtual IP address. The virtual IP address may give impact to communication between the DCN and the other device.SELECTED DRAWING: Figure 5

Description

[Technical Field]

[0001] This application relates to distributed control node (DCN) redundancy. [Background technology]

[0002] Process automation facilities may contain countless sensors, actuators, and distributed control nodes (DCNs) that cooperate to perform a variety of different tasks, including managing process control loops. Many of these tasks are mission-critical and / or involve processes that can be dangerous if not properly controlled. Therefore, the failure of any component can result in the failure of a larger task, which can be costly at best and catastrophic at worst. The installation of redundant DCN systems allows the facility to continue operating even if the primary DCN fails by enabling rapid switchover from a failed primary DCN to one or more backup DCNs. Summary of the Invention [Means for solving the problem]

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

[0004] In various implementations, a redundant distributed control node (DCN) system may include one or more shared output channels, a private network that is at least logically separate from the process automation network, a primary DCN for subscribing to one or more remote data feeds based on subscription data and driving 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 private network. In various implementations, a virtual IP address used by the redundant DCN system to exchange data over the process automation network may be transferable between the primary DCN and one or more of the backup DCNs. In various implementations, the primary DCN may be configured to transmit its subscription data to one or more of the backup DCNs via the private 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 implementations, the keep-alive 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 implementations, 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 implementations, the reassignment as the new primary DCN may include transferring a virtual IP address from the primary DCN to the new primary DCN.

[0005] In various implementations, a keep-alive process may be hosted on one or more of the backup DCNs. In various implementations, a keep-alive process may be hosted on each DCN of the one or more backup DCNs.

[0006] In various implementations, the keep-alive process may be hosted on a processing node separate from one or more backup DCNs. In various implementations, the processing node may be integral to a redundant DCN system. In various implementations, the primary DCN may be configured to periodically transmit subscription data.

[0007] In various implementations, the primary DCN may be configured to send subscription data whenever the subscription data of the primary DCN changes. In various implementations, the subscription data of the primary DCN may change in response to the primary DCN subscribing to a new node. In various implementations, the subscription data of the primary DCN may change in response to the primary DCN modifying an existing subscription.

[0008] In various implementations, the new primary DCN may load subscription data in response to determining that the primary DCN has become unavailable. In various implementations, 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 one or more of the remote data feeds.

[0009] In various implementations, following the reassignment of 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 may be assigned as another of the one or more backup DCNs, while the virtual IP address remains reassigned to the new primary DCN.

[0010] In various implementations, the private network may be implemented using one or more of Ethernet, serial, or bus communication technologies. In various implementations, the primary DCN or the new primary DCN may share a virtual IP address with another DCN. In various implementations, a keep-alive process may determine the state 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 a private network through which one or more shared output channels and one or more backup DCNs are communicatively coupled to a primary DCN; determining, based on a keep-alive process, whether a primary DCN that is subscribed 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 has become unavailable, wherein the primary DCN is subscribed 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 private network; and in response to determining that the primary DCN has become unavailable, causing reassignment of one or more of the backup DCNs as new primary DCNs, 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 implementations, the keep-alive process may be hosted on one or more of the backup DCNs.

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

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

[0014] It should be appreciated that all combinations of the above concepts, and additional concepts described in more detail herein, are contemplated as part of the subject matter disclosed herein, e.g., all combinations of claimed subject matter appearing at the end of this disclosure are contemplated as part of the subject matter disclosed herein. [Brief explanation of the drawings]

[0015] [Figure 1] FIG. 1 illustrates a schematic diagram of an exemplary environment in which selected aspects of the present disclosure may be implemented. [Figure 2] FIG. 1 illustrates a schematic diagram of an exemplary environment in which selected aspects of the present disclosure may be implemented or may be implemented. [Figure 3] FIG. 1 illustrates a schematic diagram of a redundant DCN system including a private network communicatively coupling a primary DCN with one or more backup DCNs, and a keep-alive process used to determine whether the primary DCN is unavailable. [Figure 4] FIG. 10 is a schematic diagram illustrating a redundant DCN system after one or more selected aspects of the present disclosure have been implemented, including reassigning a backup DCN as a new primary DCN, transferring the virtual IP address of the primary DCN to the new primary DCN, subscribing the new primary DCN to a remote data feed, and driving output channels by the new primary DCN. [Figure 5] FIG. 1 illustrates a schematic diagram of an exemplary method for implementing aspects of the present disclosure. [Figure 6] FIG. 1 illustrates schematically an exemplary computer architecture in which selected aspects of the present disclosure may be implemented. DETAILED DESCRIPTION OF THE INVENTION

[0016] Implementations are described herein for increasing and / or maintaining DCN availability in a process automation network. More particularly, but not exclusively, implementations are described herein for determining the availability of a primary DCN based on a keep-alive process and, in response to determining that the primary DCN has become unavailable, reassigning one or more backup DCNs in communication with the primary DCN as the new primary DCN.

[0017] A DCN may include one or more input / output (I / O) channels associated with various types of equipment in process automation equipment. Output channels may be associated with output devices such as actuators, valves, dampers, etc. Input channels may be associated with input devices such as various types of sensors, flow meters, compute nodes, etc. The DCN may drive output channels that control 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 is subscribed.

[0018] In some implementations, multiple DCNs may share an I / O channel, allowing each DCN that shares the I / O channel to receive or send information using the I / O channel. In some implementations, DCNs may not share an I / O channel, preventing DCNs that are not associated with the I / O channel from receiving or sending information on the I / O channel. In various implementations, a DCN may contribute to the control of one or more pieces of equipment (e.g., actuators, valves, dampers, etc.) based on data received from sensors located anywhere in the process automation facility.

[0019] Process automation equipment such as a DCN can be configured to communicate with other process automation equipment using a variety of open (e.g., non-proprietary) and / or standardized communication protocols, described herein as "cross-platform." Cross-platform communication protocols may be governed by various regulations and / or standards, such as the Open Platform Communication (OPC) Unified Architecture (UA). Accordingly, 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," although this is not intended to be limiting. A DCN may host other types of cross-platform clients and / or servers, with OPC UA being merely one example.

[0020] In some instances, a DCN may become unavailable. The causes of a DCN becoming unavailable can be varied but may include malfunction or failure. The unavailability of a DCN can have adverse effects on facility operations. For example, OPC UA clients may be subscribed to an OPC UA server, and a failure of one or the other can have adverse consequences. When a DCN becomes unavailable, functions performed by other components, such as other DCNs (or OPC UA clients hosted on them), that subscribe to the DCN may not be performed, may be performed improperly, or may be performed based on inaccurate information. For example, assume that a DCN to which another DCN that controls a valve is subscribed is disabled. As a result, the subscribing DCN may be unable to properly manage the flow through the valve, which may be detrimental in itself or may compound to further adversely affect a larger process, such as a control loop.

[0021] In response to the unavailability of a primary DCN, one or more other DCNs in a redundant DCN system may be designated as a “backup” DCN to avoid and / or mitigate adverse effects on system processes. The backup DCN may have similar or identical properties or alternative properties compared to the primary DCN. In some cases, the alternative properties may make the backup DCN less susceptible to unavailability. The backup DCN may be reassigned as a “new primary” DCN in response to determining that the previous primary DCN has become unavailable. Some implementations may include multiple DCNs being designated as backup DCNs, and some implementations may further include a process for running on the backup DCN prior to being reassigned as the new primary DCN. The quantity and quality of DCNs designated as primary or backup DCNs are highly customizable and adaptable to facility requirements.

[0022] In various implementations, two or more DCNs of a redundant DCN system may be communicatively coupled to one another using a private network. The private network may be logically separate from the larger process automation network but connected to it through one or more entry points. The private network may be implemented using a variety of different communication technologies, such as Ethernet, serial bus, Wi-Fi, Bluetooth, Zigbee or Z-Wave, IP subnets, etc.

[0023] In some implementations, a single virtual IP address may be allocated to and transferable among a group of DCNs that are communicatively coupled via a private network. Further, in some implementations, each DCN may have its own non-virtual (or “traditional,” “normal”) IP address. The virtual IP address may be transferable among multiple DCNs, for example, by mapping (and / or remapping) the virtual IP address to different non-virtual IP addresses of the DCNs. Thus, the virtual IP address can serve as a single entry / exit point to / from a redundant DCN system that includes a primary DCN and one or more backup DCNs that are communicatively coupled via a private network.

[0024] In various implementations, devices such as DCNs may be configured to communicate with a particular virtual IP address. For example, an OPC UA client hosted by a first DCN subscribes to an I / O channel (e.g., a sensor) hosted by a second DCN, and the virtual IP address used by the second DCN may be provided to the OPC UA client hosted by the first DCN. The OPC UA client on the first DCN may then use this virtual IP address to communicate with an OPC UA server hosted by the second DCN, e.g., to retrieve sensor data from the I / O channel of the second DCN. If the second DCN is disabled, the virtual IP address may be transferred to a third “backup” DCN that is on the same private network as the second DCN. The OPC UA client on the first DCN may continue to use the same virtual IP address, except now it communicates with an OPC UA server hosted by the third DCN.

[0025] In some implementations, each primary and backup DCN of a redundant DCN system may be communicatively coupled, directly or indirectly, to a larger process automation network via their conventional / non-virtual IP addresses. A single virtual IP address transferable between DCNs may be used to limit how other nodes in the larger process automation network can communicate with these DCNs, for example, via the single ingress / egress points described above. Additionally or alternatively, in some implementations, the redundant DCN system may include a single network interface connecting the redundant DCN system to the larger process automation network. Within the redundant DCN system, and particularly using a private network logically contained within the redundant DCN system, virtual IP addresses may be transferred between multiple DCNs as needed (e.g., when the primary DCN malfunctions).

[0026] The subscription data may indicate one or more subscriptions of 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 a first DCN by subscribing to one or more remote data feeds used by the primary DCN to perform the functions. Accordingly, output channels driven by the primary DCN may also be shared among a redundant set of DCNs. As previously mentioned, 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.

[0027] A “keep-alive” program may be implemented to determine whether the primary DCN is available or unavailable. The keep-alive program may be configured to periodically, continuously, and / or on demand monitor whether the DCN is unavailable. The keep-alive program may run between one or more of the primary DCN, the backup DCN, or an independent node separate from the primary or backup DCN. For example, a respective instance of the keep-alive program may run on each backup DCN of multiple backup DCNs. In response to an instance in which the keep-alive program determines that the primary DCN is unavailable, the instance of the keep-alive program may reassign the backup DCN as the new primary DCN. The reassignment of the backup DCN as the new primary DCN may be based on one or more of several factors, such as the hardware performance, software capabilities, and availability of the particular DCN.

[0028] Following the reassignment of the backup DCN as the new primary DCN, the new primary DCN may assume the role 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 its 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 did and subscribe to one or more of the same remote data feeds as the old primary DCN did.

[0029] In some cases, the old primary DCN may become available again. The re-available old primary DCN may be reassigned as a backup DCN. Alternatively, the new primary DCN may be returned to backup DCN status, and the original primary DCN may be returned to its previous state. The protocol for the old primary DCN coming back online is customizable and can be adapted to installation requirements.

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

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

[0032] As previously mentioned, a single virtual IP address may be allocated to and transferred between the primary DCN 12 and the backup DCN 14. Devices 20 and OPC UA clients 64 may be located outside the private network 10 and may perceive the primary DCN 12 and the backup DCN 14 as a single entity because only one of the primary DCN 12 and the backup DCN 14 uses the virtual IP address at a time. In various implementations, the virtual IP address may be transferred between the primary DCN 12 and the backup DCN 14 such that both the primary DCN 12 and the backup DCN 14 do not share the virtual IP address at the same time. In other words, the virtual IP address transferable between DCNs 12 and 14 may act as the single ingress / egress point previously mentioned.

[0033] 2 schematically illustrates an example environment in which selected aspects of the present disclosure may be implemented or have been implemented. For example, the primary DCN 12 is shown as previously or currently unavailable. As discussed herein, the DCN's unavailability may be due to a variety of causes, including, but not limited to, a failure, malfunction, disconnection, or larger equipment problems.

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

[0035] 3 schematically illustrates an environment in which selected aspects of the present disclosure may be implemented. The environment may include equipment 20 operating as a cross-platform server, a remote DCN 62a, a remote DCN 62, 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 equipment (e.g., sensors, actuators) may also be operatively coupled to the redundant DCN system 100.

[0036] Within redundant DCN system 100, private network 10 may communicatively couple primary DCN 12, backup DCN 14, I / O modules 16, and one or more keep-alive processes 50. As discussed herein, private network 10 may be at least logically separated from process automation network 60. For example, private network 10 may be implemented, for example, as a subnet of or separate from larger process automation network 60. Additionally or alternatively, private network 10 need only carry traffic between DCNs 12 and 14 and keep-alive processes 50 (and I / O modules, if applicable).

[0037] Being "private," the private network 10 allows the DCNs 12, 14 included in the redundant DCN system 100 to readily and privately transfer information such as subscription data 40 and / or virtual IP addresses 42. In many implementations, components outside the private network 10, such as the equipment 20 and the remote DCN 62, are unaware of which DCNs included in the private network 10 are processing and exchanging information. That is, devices outside the redundant DCN system 100 need only seek to exchange information based on a particular IP address, and it is not apparent to them whether that particular IP address is being transferred from the primary DCN 12 to the backup DCN 14.

[0038] Thus, the primary DCN 12 includes a virtual IP address 42. As discussed herein, the remote DCN 62, and more specifically, the OPC UA server 66, may be configured to subscribe directly to data (e.g., sensor readings) to a particular virtual IP address, such as the virtual IP address 42 associated with the first DCN 12. If the keep-alive process 50 determines that the primary DCN 12 has become unavailable, the keep-alive process 50 and / or the backup DCN 14 may ensure that the backup DCN takes over the same virtual IP address 42 previously maintained by the primary DCN 12. The OPC UA server 66 hosted by the remote DCN 62 may then feed the backup DCN 14 the same data (e.g., sensor readings) that the OPC UA server 66 has with the primary DCN 12 via the virtual IP address 42, based on the backup DCN 14 appearing under the same identity purported to be that of the former primary DCN 12.

[0039] The primary DCN 12 and the backup DCN 14 may also include respective instances of cross-platform clients, i.e., OPC UA client 64A and OPC UA client 64B, respectively, and subscription data 40. As indicated by the arrows, subscription data 40 may be exchanged between the primary DCN 12 and the backup DCN 14, such as virtual IP addresses 42. The subscription data 40 may indicate which remote data feeds published by an OPC UA server hosted on a remote DCN to which the DCN (and more specifically, a cross-platform client such as OPC UA client 64 (see FIGS. 1-2)) subscribes. The subscription data 40 may also indicate which devices 20 the DCN “drives” (e.g., provides output to). For example, the subscription data may indicate that OPC UA client 64A is subscribed to a data feed published by an OPC UA server 66 hosted by remote DCN 62. The subscription data 40 may be unique or identical, depending on whether or when it was last shared between the primary DCN 12 and the backup DCN 14. In some implementations, the primary DCN 12 and backup DCN 14 sharing subscription data may make reallocation more efficient (if the backup DCN 14 needs to be reallocated as the new primary DCN).

[0040] The keep-alive process 50 may determine whether the primary DCN 12 becomes unavailable. If the primary DCN 12 becomes unavailable, the backup DCN 14 may be reassigned as the new primary DCN. As discussed herein, the keep-alive process 50 may be performed periodically, continuously, upon demand, and / or in response to certain conditions. For example, the keep-alive process 50 may be configured to run daily, continuously, at the request of one or more user accounts, and / or in response to brownouts and power outages.

[0041] While FIG. 3 illustrates the keep-alive process 50 as an independent process connected to other components of the redundant DCN system 100 via the private network 10, some implementations may include the keep-alive process 50 occurring in one or more of the primary DCN 12, the backup DCN 14, an isolated node included in the private network 10, an isolated node included in the process automation network 60, and an isolated node outside the process automation network 60. In some cases, the isolated node is integral to the redundant DCN system. Moreover, in some implementations, multiple instances of the keep-alive process 50 may run serially or in parallel. Furthermore, in some implementations, a single instance of the keep-alive process 50 may run on multiple devices, such as the primary DCN 12 and the backup DCN 14. In implementations in which multiple backup DCNs are implemented, each of the multiple backup DCNs may host an instance of the keep-alive process 50.

[0042] The keep-alive process 50 may communicate continuously or intermittently with one or more of the primary DCN 12 and the backup DCN 14. In some implementations, the keep-alive process 50 communicates with both the primary DCN 12 and the backup DCN 14 to identify the status of each DCN. Thus, while the function of the keep-alive process 50 is to identify the status of the primary DCN 12 (particularly whether the primary DCN 12 is unavailable), the keep-alive process 50 may also determine the status of one or more other DCNs, including the backup DCN 14. By determining the status of both the primary DCN 12 and the backup DCN 14, the keep-alive process 50 may preemptively identify failures in the redundant DCN system. For example, by identifying that the primary DCN 12 is available but the backup DCN 14 is unavailable, the keep-alive process 50 may determine that a different DCN should be reassigned as the backup DCN.

[0043] In some implementations, the keep-alive process 50 may contribute to ranking the backup DCNs. For example, in a redundant DCN system (e.g., 100) including multiple potential backup DCNs, the keep-alive process 50 may contribute to ranking the backup DCN 14 as a first choice for redundancy if the primary DCN 12 is determined to be unavailable, but may rank it as a second or third choice for redundancy (not shown in FIG. 3 ) if the backup DCN 14 is determined to be unavailable. Ranking the backup DCNs for redundancy may be based on hardware, software, network access, previous status as a primary DCN, and / or previous failure rate. Thus, the assignment of the backup DCN 14 as a “primary” backup may change based on numerous dynamic factors.

[0044] 4 schematically illustrates components within the redundant DCN system 100 of FIG. 3 following one or more selected aspects of the present disclosure being implemented. In FIG. 4, the primary DCN 12 is unavailable (indicated by cross-hatching). As discussed herein, DCN unavailability may be caused by automatic, manual, accidental, or intentional factors. Based on the unavailability, the primary DCN 12 may be unable to perform one or more functions.

[0045] 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 when the primary DCN 12 becomes unavailable and reassign the backup DCN 14 as the new primary DCN, with the new primary DCN assuming one or more functions previously performed by the primary DCN 12 following the reassignment. In some instances, the new primary DCN 14 may assume fewer, alternative, or more functions compared to the primary DCN 12. One or more of the new primary DCN 14 and the keep-alive process 50 may contribute to determining which functions the new primary DCN 14 should perform compared to the previous primary DCN 12. As shown in FIG. 4 and discussed herein, the reassignment may include transferring a virtual IP address 42 from the primary DCN 12 to the new primary DCN 14. This transfer may follow a determination by keep-alive process 50 that primary DCN 12 is unavailable. The transfer of virtual IP address 42 need not be implemented directly from DCN 12 to DCN 14, and in fact, the transfer may not be possible if primary DCN 12 fails completely. In some implementations, the transfer of virtual IP address 42 from primary DCN 12 to backup DCN 14 may be implemented, for example, by keep-alive process 50.

[0046] The reallocation may cause or enable the OPC UA client 64B hosted by the new primary DCN 14 to immediately retrieve information from a remote data feed to which the OPC UA client 64B is subscribed, such as a feed published by an 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 commands, etc.) to the equipment 20.

[0047] Following the reassignment of the backup DCN 14 as the new primary DCN, the remote DCN 62, the I / O modules 16, and / or the equipment 20 may cease exchanging information with the previous primary DCN 12. Instead, the remote DCN 62 and the equipment 20 may exchange information with the new primary DCN 14. The remote DCN 62 may affect this transition without any extra configuration by continuing to send data that it exposes to the same virtual IP address 42, which now directs the data to the new primary DCN 14 rather than the previous primary DCN 12. The I / O modules 16 may similarly affect this transition, for example, by directing all traffic to the same virtual IP address 42. Additionally or alternatively, the I / O modules 16 may affect this transition in other ways, for example, by rerouting communication channels from the previous primary DCN 12 to the new primary DCN 14.

[0048] In some implementations, a DCN is configured to transmit subscription data 40 to one or more other DCNs whenever the subscription data 40 is updated. Proactively distributing updates to the subscription data 40 to one or more other DCNs ensures that each DCN in the redundant set has current subscription data 40 to operate with if the primary DCN 12 becomes unavailable. This allows a reallocated DCN to quickly assume functions previously performed by another DCN. For example, the subscription data 40 of the backup DCN 14 may be updated based on the primary DCN 12 subscribing to or unsubscribing from new data feeds published by new or existing OPC UA servers 66, or modifying existing subscriptions.

[0049] Following the backup DCN 14 being assigned the role of the new primary DCN and driving equipment 20 based on one or more remote data feeds published by the OPC UA server 66 hosted by the remote DCN 62, the previous primary DCN 12 may once again become available. Once again available, the previous primary DCN 12 may once again be reassigned as the primary DCN, and the new primary DCN 14 may once again be reassigned as the backup DCN. Alternatively, once again available, the previous primary DCN 12 may once again be reassigned as the backup DCN, and the new primary DCN 14 remains the same.

[0050] 5 includes a flowchart illustrating an exemplary method 500 for implementing aspects of the present disclosure. For convenience, the operations of the flowchart are described with reference to a system that performs the operations. This system may include various components of various computer systems. Moreover, while the operations of method 500 are shown in a particular order, this is not intended to be limiting. One or more operations may be reordered, omitted, and / or added. The methods, systems, and apparatuses disclosed herein, including but not limited to method 500, may be implemented using one or more processors.

[0051] In block 502, the system identifies one or more shared output channels and a private network that is at least logically separated from the process automation network. These components may be part of a redundant DCN system (e.g., 100). The private network may be included in the process automation network but may be logically isolated, for example, as indicated by its "private" status. In some implementations, the private network may be outside the process automation network and may include one or more entry / exit points for communicating with the outside process automation network. The one or more shared output channels may or may not be separated from the process automation network.

[0052] 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 may 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 implementations, the system may subscribe the primary DCN to one or more data feeds based on new or existing subscription data. As disclosed herein, the assignment of a DCN as the primary DCN may be based on numerous factors, including the DCN's hardware, software, location, accessibility, reliability, and configuration. A private network may communicatively couple multiple DCNs, only one of which is the primary DCN. For example, the private network may host one or more backup DCNs, as discussed herein. As mentioned above, at various times, such as periodically and / or in response to the primary DCN 12 updating its subscription data, the primary DCN 12 may provide (e.g., clone) its most recent subscription data to the backup DCN 14, allowing the backup DCN 14 to quickly take over if the need arises. In various implementations, the primary DCN and backup DCN may share the same subscription data, but only the primary DCN may receive information from a remote data feed if that remote data feed is configured to provide information to a virtual IP address currently assigned to the primary DCN.

[0053] Returning to FIG. 5 , in block 506, the system determines whether the primary DCN has become unavailable. A DCN may become unavailable for numerous reasons, including malfunction, disruption, and disconnection. As disclosed herein, the keep-alive process (e.g., 50) may be performed by one or more DCNs on the private network and / or by separate nodes within or outside the network. That is, the keep-alive process may run in parallel across multiple devices, may run on a single device, or may be partially run by multiple devices. The keep-alive process may prevent and / or mitigate the impact of a DCN becoming unavailable, for example, by determining that the DCN is available. Thus, in some implementations, the keep-alive process may determine that the primary DCN is available and / or that one or more backup DCNs are available if the primary DCN becomes unavailable. As discussed herein, the keep-alive process may run, for example, continuously, periodically, on demand, or in response to some event.

[0054] In response to determining that the primary DCN has become unavailable, in block 508, the system reassigns one or more of the backup DCNs on the private network as the new primary DCN using a virtual IP address. Reassigning one or more backup DCNs as the new primary DCN may enable the backup DCNs, which have previously received the most recent subscription data from the primary DCN, to perform one or more functions of the primary DCN. This may be beneficial, for example, when the primary DCN contributes to a critical process that, without the primary DCN's contribution, may fail or be performed improperly or inefficiently. Therefore, having a redundant set of DCNs in place in the event that the primary DCN becomes unavailable may significantly benefit the process by creating a fail-safe that ensures productivity, efficiency, and procedural correctness.

[0055] In some implementations, multiple backup DCNs may be reassigned as the primary DCN using virtual IP addresses and / or virtual machines. For example, a backup DCN may 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. Accordingly, the processing capacity of the backup DCN may be partitioned and / or reserved for backup purposes, and the remaining processing capacity of the backup DCN may be dedicated to one or more other functions. This allows a backup DCN that cannot fully assume the functions of the now-unavailable primary DCN alone to cooperate with one or more other DCNs and use its combined processing power to fully assume the functions of the now-unavailable primary DCN. Virtual IP addresses and virtual machines may be implemented in association with these partitions to represent the I / O channels associated with these partitions as being from a “single” new primary DCN. As discussed, devices may be configured to receive I / O only from identified devices, and by masking backup DCN partitions under a common virtual IP address, functions previously performed by a primary DCN may be efficiently carried out by multiple backup DCNs that appear as a single identified DCN.

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

[0057] 6 is a block diagram of an exemplary computing device 610 that may optionally be used to implement one or more aspects of the techniques described herein. The computing device 610 typically includes at least one processor 614 that communicates with several peripheral devices via a bus subsystem 612. These peripheral devices may include, for example, a storage subsystem 624 including 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. The input and output devices enable user interaction with the computing device 610. The network interface subsystem 616 provides an interface to external networks and is coupled to corresponding interface devices in other computing devices.

[0058] The user interface input devices 622 may include a keyboard, a pointing device such as a mouse, a trackball, a touchpad, or a graphics tablet, a scanner, a touchscreen 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 of inputting information into the computing device 610 or into a communications network.

[0059] The 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 producing 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 of outputting information from the computing device 610 to a user or to another machine or computing device.

[0060] Storage subsystem 624 stores programming and data structures that provide the functionality of some or all of the modules described herein. For example, storage subsystem 624 may include logic for performing selected aspects of the method illustrated in Figure 5, as well as for implementing various aspects illustrated in Figures 1-4.

[0061] These software modules are generally executed by the processor 614 alone or in combination with other processors. The memory 625 used in the storage subsystem 624 may include several 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 of program 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 in the storage subsystem 624 by the file storage subsystem 626 or on other machines accessible by the processor 614.

[0062] The bus subsystem 612 provides a mechanism for allowing 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 buses.

[0063] The computing device 610 may 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 610 shown in Figure 6 is intended only as a specific example for purposes of illustrating some implementations. Many other configurations of the computing device 610 are possible, having more or fewer components than the computing device shown in Figure 6.

[0064] While 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 used, 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 for 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. Accordingly, it should be understood that the above-described implementations are presented by way of example only, and that, within the scope of the appended claims and their equivalents, implementations may be practiced otherwise 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 also included within the scope of the present disclosure, unless such features, systems, articles, materials, kits, and / or methods are mutually inconsistent. [Explanation of symbols]

[0065] 10 Private Networks 12 DCN, primary DCN 14 Backup DCN, DCN, new primary DCN 16 I / O modules 20 equipment 40 Subscription Data 42 virtual IP addresses 50 keep-alive processes 60 Process Automation Network 62 Remote DCN, DCN 64 OPC UA clients 64A OPC UA Client 64B OPC UA Client 66 OPC UA Server 66A OPC UA Server 100 Redundant DCN System 610 Computing Devices 612 Bus Subsystem 614 processor 616 Network Interface Subsystem 620 User Interface Output Device 622 User Interface Input Devices 624 Memory Subsystem 625 Memory Subsystem, Memory 626 File Storage Subsystem 630 Random Access Memory (RAM) 632 Read-Only Memory (ROM)

Claims

1. 1. A redundant distributed control node (DCN) system, comprising: one or more shared output channels; a private network that is at least logically separated from the process automation network; a primary DCN for subscribing to one or more remote data feeds based on subscription data and for driving one or more of the shared output channels based on one or more of the remote data feeds; one or more backup DCNs communicatively coupled to the primary DCN via the private network; a virtual IP address used by the redundant DCN system to exchange data over the process automation network is transferable between the primary DCN and one or more of the backup DCNs; one or more backup DCNs, the primary DCN for transmitting the subscription data of the primary DCN to one or more of the backup DCNs over the private network, the subscription data operable to subscribe the one or more of the backup DCNs to one or more of the remote data feeds; 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 a reassignment of one or more of the backup DCNs as a new primary DCN; the new primary DCN subscribes to one or more of the remote data feeds to drive one or more of the shared output channels based on the subscription data; the reassignment as a new primary DCN includes a keep-alive process that transfers the virtual IP address from the primary DCN to the new primary DCN; A redundant distributed control node (DCN) system comprising:

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

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

4. The redundant DCN system of 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 of claim 4 , wherein the processing node is integral with the redundant DCN system.

6. The redundant DCN system of claim 1 , wherein the primary DCN is configured to periodically transmit the subscription data.

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

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

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

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

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

12. 2. The redundant DCN system of claim 1, wherein following reassignment of 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 of the one or more backup DCNs, while the virtual IP address remains reassigned to the new primary DCN.

13. The redundant DCN system of claim 1 , wherein the private 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 of claim 1 , wherein the keep-alive process periodically determines the status of the primary DCN.

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

17. 1. A method implemented by one or more processors, comprising: identifying a private network through which one or more shared output channels and one or more backup DCNs are communicatively coupled to the primary DCN; determining, based on a keep-alive process, whether the primary DCN subscribed to one or more remote data feeds has become unavailable to drive one or more of the shared output channels based on one or more of the remote data feeds; the primary DCN subscribes to the one or more remote data feeds based on subscription data, and transmits the subscription data to one or more of the backup DCNs via the private network; in response to determining that the primary DCN has become unavailable, causing a reassignment of one or more of the backup DCNs as new primary DCNs, the reassignment including transferring a virtual IP address of the primary DCN to the new primary DCN, the new primary DCN subscribing to one or more of the remote data feeds based on the subscription data; A method comprising:

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

19. 1. 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 operable, when executed by the one or more computers, to cause the one or more processors to perform operations, the operations comprising: determining whether a primary DCN currently subscribed to or previously subscribed to one or more remote data feeds has become unavailable for driving 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 private network logically separated from a process automation network associated with the redundant DCN system; a virtual IP address used by the redundant DCN system to exchange data over the process automation network is transferable between the primary DCN and one or more of the backup DCNs; Identifying the primary DCN's subscription data, which is transmitted to one or more of the backup DCNs via the private network; in response to determining that the primary DCN has become unavailable, reassigning one or more of the backup DCNs as new primary DCNs, the reassigning as new primary DCNs including transferring the virtual IP address from the primary DCN to the new primary DCN; A redundant distributed control node (DCN) system, including:

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

Images