Patent Description:
Industrial process control and automation systems are routinely used to automate large and complex industrial processes. These types of systems typically include sensors, actuators, controllers and other intelligent electronic devices for supervisory control and data acquisition. The intelligent electronic devices in such systems are interconnected and communicate through a LAN (local area network) or WAN (Wide Area Network). In such industrial process control and automation systems the architecture may include gateways that are connected to the I/O devices such as for example, sensors and actuators used in the automation system that are not directly connected to the controller. High availability applications operating within a LAN or WAN controlling and supervising the process control and automation system expect networks to have access to all intelligent electronic devices in the network in order to avoid communication disruption. Such as for example, parallel redundancy protocol (PRP) network systems and high-availability seamless redundancy (HSR) network systems.

Process controllers used in industrial process control and automation systems can have their I/O devices separated from the controller by a redundant Ethernet LAN network versus a traditional backplane. PRP network systems use two independent private networks to communicate control signals and data between the controller and I/O devices that may be connected to separate nodes of a network. PRP network systems duplicate the data frames to be transmitted, and add a unique sequence number to the end each of a standard communication data packet and sends both PRP frames through two independent LANs or WANs having a similar network topology. This communication method has an advantage versus a traditional non-PRP redundant network in that if a failure occurs on one LAN, the control to I/O connections can be recovered quickly using the redundant path. The recovery time to switch in the redundant path of a PRP, is for example in the microseconds, versus seconds for traditional non-PRP redundant networks.

A PRP network however could suffer from failure leading to a loss of control in the automation system if the LAN A cable associated with the controller experiences a fault such as for example a broken wire, a faulty connector or a failure in an Ethernet switch attached to the LAN A and the parallel LAN B associated with the I/O device node experiences a similar fault as explained above. In this scenario, there would be no PRP network path from the controller to the I/O devices, leading to a potential interruption of the control of the I/O device and loss of view to the I/O.

It would therefore be advantageous to provide an alternate network path around the failed LAN A and LAN B PRP networks that can route control and I/O traffic between the controller in a control node to its connected devices in an I/O node and continue normal operations until the faults can be diagnosed and repaired.

An example of a currently used system can be found in <CIT>, which discloses a method for protection switching in a shared node where protection resources of a plurality of end-to-end linear protection domain are shared. The shared node receives a first protection switching event message notifying that a protection switching event occurs from a first node of a first end-to-end linear protection domain, and determines whether to prohibit protection switching on a second end-to-end linear protection domain by comparing a priority of the first end-to-end linear protection domain with a priority of the second end-to-end linear protection domain.

This disclosure relates to a method and system for facilitating a parallel redundancy protocol in industrial process control and automation systems.

In a first embodiment an apparatus is disclosed for sending and receiving data on an alternate communication path between a first network node and a second network node. The apparatus includes a first network that connects the first network node to the second network node establishing a first communication path that sends and receives data between the first network node and the second network node. A second network that connects the first network node to the second network node establishing a second communication path that sends and receives data between the first network node and the second network node. A third network is connected to the first node and the second node that forms the alternate network path. The first network, the second network and the third network being disjoint from each other. A diagnostic program causes the alternate network path to send and receive data between the first network node and the second network node when a communication path failure in the first network and the second network is detected.

In a second embodiment, a method for using an alternate communication path to send and receive data between a first network node and a second network node is disclosed, the method includes establishing a first communication path between the first network node and the second network node that sends and receives data between the first network node and second network node. The method further includes establishing a second communication path between the first network node and the second network node that sends and receives data between the first network node and second network node and a third communication path between the first network node and the second network node the third communication path forming the alternate communication path. The first communication path, the second communication path, and the third communication path being disjoint from each other. The method includes testing the first communication path and the second communication path for network failures and causing the alternate communication path to send and receive data between the first network node and second network node when a network failure in the first communication path and the second communication path is detected.

In a third embodiment, a non-transitory computer readable medium containing instructions for sending and receiving data on an alternate communication path connected between a first network node and a second network node is disclosed that when the instructions are executed, cause at least one processing device to send and receive data between the first network node and the second network node using a first communication path between the first network node and the second network node and to send and receive data between the first network node and second network node using a second communication path between the first network node and the second network node. To test using a diagnostic program, the first communication path and the second communication path for network failures and to send and receive data between the first network node and second network node using the alternate communication path when a network failure in the first communication path and the second communication path is detected.

The figures, discussed below, and the various embodiments used to describe the principles of the present invention in this patent document are by way of illustration only and should not be construed in any way to limit the scope of the invention. Those skilled in the art will understand that the principles of the invention may be implemented in any type of suitably arranged device or system.

<FIG> illustrates a portion of an example industrial process control and automation system <NUM> according to this disclosure. As shown in <FIG>, the system <NUM> includes various components that facilitate production or processing of at least one product or other material. For instance, the system <NUM> can be used to facilitate control or monitoring of components in one or multiple industrial plants. Each plant represents one or more processing facilities (or one or more portions thereof), such as one or more manufacturing facilities for producing at least one product or other material. In general, each plant may implement one or more industrial processes and can individually or collectively be referred to as a process system. A process system generally represents any system or portion thereof configured to process one or more products or other materials or energy in different forms in some manner.

In the example shown in <FIG>, the system <NUM> includes one or more sensors 102a and one or more actuators 102b. The sensors 102a and actuators 102b represent components in a process system that may perform any of a wide variety of functions. For example, the sensors 102a could measure a wide variety of characteristics in the process system, such as temperature, pressure, or flow rate. Also, the actuators 102b could alter a wide variety of characteristics in the process system. Each of the sensors 102a includes any suitable structure for measuring one or more characteristics in a process system. Each of the actuators 102b includes any suitable structure for operating on or affecting one or more conditions in a process system.

At least one input/output (I/O) module <NUM> is coupled to the sensors 102a and actuators 102b. The I/O modules <NUM> facilitate interaction with the sensors 102a, actuators 102b, or other field devices. For example, an I/O module <NUM> could be used to receive one or more analog inputs (AIs), digital inputs (DIs), digital input sequences of events (DISOEs), or pulse accumulator inputs (PIs) or to provide one or more analog outputs (AOs) or digital outputs (DOs). Each I/O module <NUM> includes any suitable structure(s) for receiving one or more input signals from or providing one or more output signals to one or more field devices. Depending on the implementation, the I/O module <NUM> could include fixed number(s) and type(s) of inputs or outputs or reconfigurable inputs or outputs. In the exemplary system of <FIG>, I/O modules <NUM> are connected to gateways <NUM> via a network <NUM>. The gateways <NUM> receive the supervisory control information from remotely located controllers <NUM>. The gateways <NUM> serve as an entry and exit point for a network node. Control information as all data must pass through or communicate with the gateway prior to being routed from the node. For example, control information from controllers <NUM> can be sent to the actuators 102b from controllers <NUM> through one or more gateways <NUM>. Data from the sensors 102a is communicated to one or more controllers <NUM> through one or more gateways <NUM>.

For example, a first set of controllers <NUM> may use measurements from one or more sensors 102a to control the operation of one or more actuators 102b. These controllers <NUM> could interact with the sensors 102a, actuators 102b, and other field devices via the I/O module(s) <NUM>. The controllers <NUM> may be coupled to the I/O module(s) <NUM> via Ethernet, backplane communications, serial communications, or the like. A second set of controllers <NUM> could be used to optimize the control logic or other operations performed by the first set of controllers. A third set of controllers <NUM> could be used to perform additional functions.

The controllers <NUM> can be used in the system <NUM> to perform various functions in order to control one or more industrial processes. For example, a first set of controllers <NUM>, that operate as a first network node may use measurements from one or more sensors 102b sent from gateways <NUM> operating as a second and separated network node to control the operation of one or more actuators 102b. These controllers <NUM> could interact with the sensors 102a, actuators 102b, and other field devices via the gateways <NUM> and I/O module(s) <NUM>. Additionally, controllers <NUM> can also communicate to sensors and actuators (not shown) that can be connected to I/O modules <NUM> in the first network node.

Controllers <NUM> are often arranged hierarchically in a system. For example, different controllers <NUM> could be used to control individual actuators, collections of actuators forming machines, collections of machines forming units, collections of units forming plants, and collections of plants forming an enterprise, either directly connected in their network node or to a different network node via a gateway <NUM>. A particular example of a hierarchical arrangement of controllers <NUM> is defined as the "Purdue" model of process control. The controllers <NUM> in different hierarchical levels can communicate via one or more networks <NUM> and associated switches, firewalls, and other components.

Each controller <NUM> includes any suitable structure for controlling one or more aspects of an industrial process. At least some of the controllers <NUM> could, for example, represent proportional-integral-derivative (PID) controllers or multivariable controllers, such as Profit Controller or other types of controllers implementing model predictive control (MPC) or other advanced predictive control. As a particular example, each controller <NUM> could represent a computing device running a real-time operating system, a MICROSOFT WINDOWS operating system, or other operating system. Operator access to and interaction with the controllers <NUM> and other components of the system <NUM> can occur via various operator stations <NUM>.

Each operator station <NUM> could be used to provide information to an operator and receive information from an operator. For example, each operator station <NUM> could provide information identifying a current state of an industrial process to an operator, such as values of various process variables and warnings, alarms, or other states associated with the industrial process. Each operator station <NUM> could also receive information affecting how the industrial process is controlled, such as by receiving setpoints for process variables controlled by the controllers <NUM> or other information that alters or affects how the controllers <NUM> control the industrial process. Each operator station <NUM> includes any suitable structure for displaying information to and interacting with an operator.

This represents a brief description of one type of industrial process control and automation system that may be used to manufacture or process one or more materials. Additional details regarding industrial process control and automation systems are well-known in the art and are not needed for an understanding of this disclosure. Also, industrial process control and automation systems are highly configurable and can be configured in any suitable manner according to particular needs.

Although <FIG> illustrates a portion of one example industrial process control and automation system <NUM>, various changes may be made to <FIG>. For example, various components in <FIG> could be combined, further subdivided, rearranged, or omitted and additional components could be added according to particular needs. Also, while <FIG> illustrates one example operational environment in which redundant controllers could be used, this functionality could be used in any other suitable system.

<FIG> illustrates an example control group <NUM> consisting of a controller <NUM> in a first network node communicating to a gateway <NUM> in a second network node along one or more networks <NUM>. For ease of explanation, the control group <NUM> is described as being used in the industrial process control and automation system <NUM> of <FIG>. However, the control group <NUM> could be used in any other suitable system. The example, control group <NUM> operates at Level <NUM> of the Purdue model, and among other things, the example control group <NUM> may use the measurements from the one or more sensors 102a to control the operation of one or more actuators 102b.

As shown in <FIG>, the control group <NUM> includes a controller <NUM> and a gateway <NUM>. The controller <NUM> may represent, or be represented by, various ones of the controllers <NUM> of <FIG>. The gateway <NUM> may represent, or be represented by, various ones of gateways <NUM> of <FIG>. The controllers <NUM> and gateways <NUM> are connected to the one or more networks <NUM>, such as FTE (Fault Tolerant Ethernet), IEC-<NUM>, Ethernet/IP, or MODBUS/TCP networks. Controllers <NUM> could communicate with the sensors and implement control logic for controlling the actuators within their own network node. Controllers <NUM> could also communicate with gateways <NUM> and the sensors 102a and implement control logic for controlling the actuators 102b within the second network node of the gateway <NUM>.

In an embodiment of the present disclosure, a private network facilitates communication between the controllers <NUM> and gateways <NUM>. The private network can transport supervisory control and data between the controllers <NUM> and gateways <NUM>, thereby allowing controllers <NUM> to access and control the sensors and actuators of the second network node.

The private network includes any suitable structure for transporting data between networked devices such as a parallel redundant protocol (PRP) network operating under IEC standard <NUM>-<NUM>. For example, each controller <NUM> could be configured as a node communicating between the gateways <NUM> using two independent PRP networks. Supervisory control and process data can be transmitted and received along the two independent networks between the controllers <NUM> and gateways <NUM>. Each controller <NUM> includes any suitable structure configured to perform control operations in an industrial process control and automation system.

Although <FIG> illustrates an example of a controller group <NUM> having redundant process controllers for industrial control networks, various changes may be made to <FIG>. For example, a controller group <NUM> could include more or fewer controllers. Also, any suitable number and configuration of other network devices could be used to interconnect the controllers in a controller group or a controller node.

<FIG> illustrates a schematic of an example of controller <NUM> of the controller node shown in <FIG>. The controller <NUM> could, for example, represent any of the controllers <NUM> or other control system components used in a redundant configuration in <FIG>. However, the controller <NUM> could represent any other suitable device supporting operation in a redundant manner, regardless of whether the device <NUM> is used for process control and automation.

As shown in <FIG>, the controller <NUM> includes at least one processor <NUM>, at least one storage device <NUM>, at least one communications unit <NUM>, and at least one I/O unit <NUM>. Each processor <NUM> can execute instructions, such as those that may be loaded into a memory <NUM>. Each processor <NUM> denotes any suitable processing device, such as one or more microprocessors, microcontrollers, digital signal processors, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or discrete circuitry.

The memory <NUM> and a persistent storage <NUM> are examples of storage devices <NUM>, which represent any structure(s) capable of storing and facilitating retrieval of information (such as data, program code, and/or other suitable information on a temporary or permanent basis). The memory <NUM> may represent a random access memory or any other suitable volatile or non-volatile storage device(s). The persistent storage <NUM> may contain one or more components or devices supporting longer-term storage of data, such as a read only memory, hard drive, Flash memory, or optical disc.

The communications unit <NUM> supports communications with other systems or devices. For example, the communications unit <NUM> could include at least one network interface card or wireless transceiver facilitating communications over at least one wired or wireless network. As a particular example, the communications unit <NUM> could support communications with one or more sensors 102a or one or more actuators 102b over an I/O network <NUM>. As another particular example, the communications unit <NUM> could support communications with higher-level components over the network <NUM>. The communications unit <NUM> may support communications through any suitable physical or wireless communication link(s).

The I/O unit <NUM> allows for input and output of data. For example, the I/O unit <NUM> may provide a connection for user input through a keyboard, mouse, keypad, touchscreen, or other suitable input device. The I/O unit <NUM> may also send output to a display, printer, or other suitable output device. Note, however, that the use of the I/O unit <NUM> for local I/O may not be needed, such as when the controller <NUM> is accessible locally or remotely over a network connection.

As described in more detail below, the processor <NUM> of the controller <NUM> can be used to execute a diagnostic system that test the operational functionality of the controller <NUM>. The processor <NUM> of the controller <NUM> can also be used to execute an algorithm that supports the transfer of data from the controller <NUM> to a redundant device (such as to an associated redundant process controller <NUM>).

Although <FIG> illustrates one example of a controller <NUM> for implementing the disclosure, various changes may be made to <FIG>. Also, computing devices can come in a wide variety of configurations, and <FIG> does not limit this disclosure to any particular configuration of device.

<FIG> illustrates a private network for transporting data between controllers <NUM> and gateways <NUM> in accordance with an embodiment of present disclosure. A first network NODE <NUM> is formed by controller <NUM>, local I/O module <NUM>, and PRP interface module <NUM>. A second network NODE <NUM> is formed by a gateway <NUM>, I/O module 104b and interface module <NUM>.

The controller <NUM> is connected to and communicates via one or more networks <NUM>, such as network <NUM> shown in <FIG> and associated switches, firewalls, to other components of the industrial process control system <NUM> of <FIG>. The sensors 102a and actuators 102b of this control group are connected to an I/O module 104b via one or more networks <NUM> and to an associated gateway <NUM> as was explained above in <FIG>. The PRP network sends data from the controller <NUM> of NODE <NUM> to the gateway <NUM> and I/O module 104b of NODE <NUM> using two independent LAN networks connected between PRP interface modules <NUM>, <NUM>. For example, PRP interface module <NUM> associated with the network of NODE <NUM> communicates using a first network (hereinafter LAN A) comprised of a first cable A connected between module <NUM> and an Ethernet switch A <NUM> and a second cable A' connected from the Ethernet switch A <NUM> to interface module <NUM>. Interface module <NUM> is further connected to a second network (hereinafter LAN B) via a first cable B to Ethernet switch B <NUM> and second cable B' connected to interface module <NUM>. The PRP interface modules <NUM>, <NUM> through their associated Ethernet switches <NUM>, <NUM> establish two separate private networks, LAN A and LAN B between NODE <NUM> and NODE <NUM>.

As was explained earlier, a PRP network such as the PRP network described above could suffer from failure leading to a loss of control in the automation system if the LAN A cables associated with NODE <NUM> experiences a fault, such as for example a broken wire, a faulty connector or have a failure in the Ethernet switch <NUM> and at the same time, the LAN B cables associated with the NODE <NUM> experiences similar faults as explained above. In this scenario, there would be no PRP network path from the controller <NUM> in NODE <NUM> to the I/O module 104b in NODE <NUM> and vice versa. In order to rectify such a loss in network communications between NODE <NUM> and NODE <NUM> each PRP interface <NUM> and <NUM> also includes a connection to the network <NUM> of the of the industrial process control and automation system.

As shown in <FIG>, the PRP interface module <NUM> associated with NODE <NUM> includes a connection to network <NUM>. Similarly, the PRP interface <NUM> associated with NODE <NUM> includes a similar connection to the network <NUM>. This alternate communication path through network <NUM> can be used to send control signals and data packets between NODE <NUM> and NODE <NUM> when faults in LAN A and LAN B are detected that have cut-off or seriously degraded the PRP network. The alternate communication path can be used to transfer control and data between NODE <NUM> and NODE <NUM> until the PRP network is diagnosed and the faults in the PRP network repaired.

<FIG> illustrates an example of the PRP interfaces modules <NUM>, <NUM> operating under IEC standard <NUM>-<NUM>. Each of the two PRP interface modules <NUM>, <NUM> include a first doubly attached node (DANP1) <NUM> labeled in this disclosure as NODE <NUM>. A second doubly attached node (DANP2) <NUM> is labeled as NODE <NUM>. In this example, NODE <NUM> is associated with controller <NUM> and will be described as the source node and NODE <NUM> is associated with the gateway <NUM> and I/O module 104b and will be described as the destination node.

Each PRP interface module <NUM>, <NUM> includes a processor <NUM>, in the upper layers of the interface modules <NUM>, <NUM> that includes one or more processors or other processing devices that can execute operating system instructions such as the protocol stack <NUM>. The protocol stack <NUM> can be implemented in hypertext transfer protocol (HTTP) and may include a transmission control protocol (TCP) at a transport layer <NUM>, and an IP Internet protocol (IP) at the network layer <NUM>. These IEC protocol layer examples should be considered non-limiting and are merely illustrative of the types of communication protocols which can be implemented by the protocol stack and operated by the processor <NUM> of each PRP interface module <NUM>, <NUM>. A diagnostic layer <NUM> is also included in the upper layers of the interface modules <NUM>, <NUM>. The diagnostic layer <NUM> checks for faults in the cabling, connections, switches, and other physical devices comprising LAN A and LAN B.

Each PRP interface module <NUM>, <NUM> further includes TX/RX circuitry <NUM> which implement the PRP-related functions described herein, as they pertain to the communication stack of the link redundancy entity (LRE) <NUM> of IEC standard <NUM>-<NUM>. As described in IEC <NUM>-<NUM>, to achieve redundancy, PRP-compatible nodes are connected to two independent network LANs having similar topology, (e.g., a first independent network comprised of LAN A and a second independent network comprised of LAN B) through two independent physical ports (port A and port B). The physical ports include circuitry such as transmit (TX) circuitry and receive (RX) circuitry <NUM> for dealing with the physical connectivity of the corresponding NODE <NUM> and NODE <NUM> connections.

Each pair of ports A and B for the same node share the same MAC address and operate in parallel to each other. Each pair of ports A and B are attached to the protocol stack <NUM> of the upper layers of its respective PRP interface module through the LRE <NUM>. The LRE <NUM> ensures that the upper layers are unaware of and unaffected by the redundancy. The LRE <NUM> performs two key tasks related to the PRP-related functions described herein, the LRE <NUM> handles the duplication of PRP frames and manages acceptance of the received packets from LAN A and LAN B.

For example, the upper layers of the protocol stack <NUM> are tasked to attach a MAC header to the data packet and convert the data packet it to an IEEE <NUM> frame, as is done in non-redundant networks. The MAC header includes a source MAC address field, a destination MAC address field, and other fields such as a tag and an Ethernet type/size field for an Ethernet frame. Normally the LRE <NUM> uses the same destination MAC address for the destination within a network. The LRE <NUM> duplicates the data frame received from the upper layers and appends a redundancy check trailer (RCT) to each duplicated data frame. The LRE <NUM> then transfers the data packet frames to the transmitter of port A associated with LAN A and the transmitter of port B associated with LAN B. In the present embodiment the packets from the port A and port B are sent to PRP Interface <NUM> for transmission to the destination NODE <NUM> using both LAN A and LAN B.

The two PRP frames travel through LAN A and LAN B with different delays and, ideally, both reach the destination node <NUM> and are processed through the PRP interface <NUM> and the port A and port B RX circuitry and the LRE <NUM> of the PRP interface module <NUM>. The LRE <NUM> of NODE <NUM> processes the PRP frame that arrives first and discards the second one (if it arrives). The MAC address of the source, NODE <NUM> in this example, is used to identify the received PRP frame.

The PRP source and destination nodes just explained use the NODE <NUM> PRP interface module <NUM> associated with controller <NUM> as the source node and the NODE <NUM> PRP interface module <NUM> associated with the gateway <NUM> and I/O module 104b as the destination node. The PRP network of the present invention can also operate to provide data to the controller <NUM> from NODE <NUM>. For example, process data from the I/O module 104b provided by sensor 102a and other devices connected to I/O module 104b thereby, operating NODE <NUM> act as the source node and NODE <NUM> as the destination node. For example, the two duplicated PRP frames from the LRE <NUM> of NODE <NUM>, are applied to the port A and port B TX circuitry <NUM> and to PRP interface <NUM> to travel through LAN A and LAN B and be received by the port A and port B respectively, of RX circuitry <NUM> of NODE <NUM> to be processed by LRE <NUM> of NODE <NUM> as explained above.

Each PRP interface module <NUM>, <NUM> includes a diagnostics layer <NUM> in the upper layers of each interface module that routinely performs network integrity checks of LAN A and LAN B when operating. The diagnostics can independently initiate a cutover to send and receive the PRP frames along network (NTW) <NUM> when a failure of LAN A and LAN B is detected. It should be noted that the NTW <NUM> can be one or more separate FTE (Fault Tolerant Ethernet), IEC-<NUM>, Ethernet/IP, or MODBUS/TCP networks or the same network <NUM> shown in <FIG>. The processor <NUM> executing the diagnostics layer <NUM> would periodically interrogate the LAN A and LAN B integrity to detect if a failure has occurred. For example, the processor <NUM> of the NODE <NUM> PRP interface module <NUM> would periodically send a "heart beat" message packet along LAN A to the processor <NUM> of the NODE <NUM> diagnostics layer <NUM>. Similarly, the processor <NUM> of the NODE <NUM> PRP interface module <NUM> would periodically send a "heart beat" message packet along LAN B to the processor <NUM> of the NODE <NUM> diagnostics layer <NUM>. In another example, the diagnostics layer <NUM> of each node could transmit a frame error rate signals on a respective LAN A or LAN B to detect any failures in the LAN A and LAN B networks. Other diagnostic methods known in the industry for testing Ethernet networks for diagnosing communication path integrity could be used to detect failures in LAN A and LAN B.

Upon detection of a failure in both LANs A and B the diagnostics layer <NUM> can command a cutover that uses NTW <NUM> to transfer data packets between NODE <NUM> and NODE <NUM>. For example, in <FIG>, diagnostics layer <NUM> of NODE <NUM>, upon the detection of a failure in LAN A, would send a diagnostic message to the NODE <NUM> NTW interface <NUM> that is transmitted on NTW <NUM>. The diagnostic message is addressed to the network interface <NUM> and diagnostics layer <NUM> of NODE <NUM> informing NODE <NUM> of the failure of the LAN A. If the NODE <NUM> LAN B is operating normally, no action is taken to cutover the LAN A network to use the alternate communication path of the NTW <NUM> network. The diagnostics layer <NUM> of NODE <NUM><NUM> would however also send a fault message to controller <NUM> via the NTW interface <NUM> and NTW <NUM>, notifying the controller <NUM> of the failure of LAN A.

Similarly, diagnostics layer <NUM> of NODE <NUM>, upon the detection of a failure in LAN B, would send a diagnostic message via the NTW interface <NUM> and NTW <NUM> of the NODE <NUM> to the interface <NUM> and diagnostics layer <NUM> of NODE <NUM> informing NODE <NUM> of the failure of the LAN B. If LAN A is operating normally no action is taken to cutover the LAN B network to use NTW <NUM> as an alternate communication path. The diagnostics layer <NUM> of NODE <NUM> would however also send a fault message to controller <NUM> via network interface <NUM> and the NTW <NUM> network.

However, if both diagnostics layers <NUM> report a fault or failure of each LAN A and LAN B than a cutover procedure is instituted in each node to use the NTW <NUM> as an alternate communication path to send PRP control and data between NODE <NUM> and NODE <NUM>. With renewed reference to <FIG>, upon the detection of a failure of the LAN A and LAN B networks each processor <NUM> of each PRP interface module <NUM>, <NUM> would send a signal to its respective PRP interface <NUM> to cut over and use the alternate network route to send and receive PRP frames between NODES <NUM> and NODES <NUM>. For example, PRP interface module <NUM> acting as the source would have the diagnostics layer <NUM> instruct the PRP interface <NUM> to stop sending and receiving network traffic through the PRP interface <NUM> and establish a direct communication path along connection <NUM> to NTW interface <NUM> and begin sending and receiving network traffic from the NTW interface <NUM> of NODE <NUM>. Similarly, the PRP interface module <NUM> acting as the destination would have the diagnostics layer <NUM> instruct the PRP interface <NUM> to begin sending and receiving network traffic from the NTW interface <NUM> of NODE <NUM>.

The NTW interface <NUM> of NODE <NUM> would transmit the PRP frames received from TX A circuitry <NUM>, through NTW interface <NUM> and NTW <NUM> to the NTW interface <NUM> of NODE <NUM>. The NTW interface <NUM> would transmit the received PRP frames to the NODE <NUM> interface <NUM> from the NTW interface <NUM> via connection <NUM> and the RX A circuitry <NUM> to be processed by LRE <NUM>. PRP frames from NODE <NUM> when acting as the source would be sent similarly along NTW <NUM> from the NODE <NUM> NTW interface <NUM> to PRP interface <NUM> RX A circuitry <NUM> to be processed by the LRE <NUM> of NODE <NUM>.

For the ease of explanation , the present disclosure has been explained as the alternate network path having only one NTW <NUM> path. However, most modern Ethernet networks used in plants operate using a fault tolerant system includes a second redundant network NTW <NUM> path to carry duplicate traffic (not shown). The present disclosure can be used to simultaneously carry duplicate PRP frames from a node acting as the source to the node acting as the destination using the port B channel TX/RX circuitry <NUM> along the second redundant network of NTW <NUM> path, in the same manner as explained above for the port A channel.

The diagnostics layers <NUM> of each PRP interface modules <NUM>, <NUM> would continue to test each LAN A and B for recovery of the PRP network. The diagnostics layer <NUM>, as explained earlier, would continue to send fault messages to the controller <NUM> of the status of each LAN A and LAN B via NTW <NUM>.

<FIG> illustrates an example architecture for providing service analytics and reporting faults of the PRP network according to the present disclosure. For ease of explanation, the architecture <NUM> may be described as being implemented within the controller <NUM> of <FIG>. The controller <NUM> is implemented using the device <NUM> of <FIG>. However, the architecture <NUM> shown in <FIG> can be used with any suitable device and in any suitable system.

In this example, the architecture <NUM> includes a processor <NUM> that executes one or more control algorithms <NUM>, stored in a control database <NUM> representing memory locations in main writable memory of a persistent storage <NUM>, or other storage device <NUM>. Each control algorithm <NUM> can be used to control one or more aspects of at least one industrial process. One operation of at least one of the control algorithms <NUM> is to track and send data to I/O modules <NUM> and sensors 102a and actuators 102b and other devices, associated with the controller <NUM>. NTW <NUM> represents an Ethernet network, such as for example network <NUM> shown in <FIG>. The NTW <NUM> connects to controller <NUM> through the communication unit <NUM>, that can be represented by the communication unit <NUM> of controller <NUM> described in <FIG>.

The processor <NUM> also includes and executes a failure detection diagnostic algorithm <NUM>. Processor <NUM> and the failure detection diagnostics <NUM> would receive the fault messages transmitted from interface modules <NUM> and <NUM> along NTW <NUM>. The processor <NUM> is further connected to an enabled services manager <NUM>. Fault messages and any diagnostic data received with the fault messages are processed by the failure detection diagnostics <NUM> and sent to and reviewed by the enabled services manager <NUM>. The enabled services manager <NUM> would log the fault discovered in the PRP network as a diagnostic event and prioritize the detected faults based on a critical status.

Prioritizing the detected faults can include organizing the collected faults so that the most important (e.g., urgent) faults can be addressed the earliest. For example, a failure detected on only LAN A or only on LAN B would still allow the message traffic to be sent between NODE <NUM> and NODE <NUM>. This would be registered as a non-urgent low priority fault. However, a complete failure of both LAN A and LAN B would be prioritized as urgent or a high priority failure. The fault messages sent by NODE <NUM> and NODE <NUM> may also include diagnostic data that can include abnormal parameters. The diagnostic data that contain abnormal parameters that are severely outside (e.g., exceedingly under or over) the threshold limitation value, can be listed first to establish an order. The detected faults reported to be present can also be validated so as to ensure their existence. Validating the diagnostic data of a detected fault can include comparing the collected diagnostic data to past data, the parameter settings, and functionality of the PRP network connections.

Minor events would be logged-in to an event journal and to on-line diagnostic summary and reported, by the enabled services manager <NUM> by sending a diagnostic message along NTW <NUM> using communication unit <NUM> to alert a user. Alerting the user can include alerting (e.g., notifying) the user via dashboard, mobile, user interface, or a report. For example, the alert messages can be provided (e.g., displayed and/or presented) to a remote operator (e.g., expert, user technician) at an associated operator station <NUM> connected to network <NUM>. Once alerted, a technician would repair the fault in the PRP network. However, embodiments of the present disclosure are not so limited. For example, diagnostic messages can be provided to any person and/or entity responsible for diagnosing, fixing, and/or resolving abnormalities associated with the automation system, and/or any person and/or entity responsible for diagnosing and/or improving field automation system operations.

In some embodiments, the diagnostic messages reported by the enabled services manager <NUM> can include parameters (e.g., field parameters) and diagnostic data associated with the control system <NUM> associated with the PRP network connecting NODE <NUM> and NODE <NUM>. The field parameters can include information associated with the control system <NUM>, such as system configurations. The collected diagnostic data can include information relating to the set of parameters. For urgent faults, such as for example, the detection that no PRP network exists between NODE <NUM> and NODE <NUM> the enabled services manager <NUM> would send diagnostic messages to an operator station <NUM> that the alternate network path between NODE <NUM> and NODE <NUM> has been activated and that the immediate repair of the PRP network must be conducted.

When the PRP network is repaired, each PRP interface module <NUM>, <NUM> generates and sends a message to the diagnostics layer <NUM> of each PRP interface module <NUM>, <NUM> that the LAN A and LAN B has returned to normal operation. The processor <NUM> instructs PRP interface <NUM> to return to normal operation, routing message traffic through PRP interface <NUM> and LAN A and LAN B. A normal operation message is also sent to controller <NUM>, notifying the controller <NUM> that normal operation of the LAN A and LAN B has resumed. Manager <NUM> then generates and logs an event to indicate the PRP network between NODE <NUM> and NODE <NUM> has returned to normal and sends a message to the user of the normal condition of the PRP network.

In some embodiments, various functions described in this patent document are implemented or supported by a computer program that is formed from computer readable program code and that is embodied in a computer readable medium.

It may be advantageous to set forth definitions of certain words and phrases used throughout this patent document. The terms "application" and "program" refer to one or more computer programs, software components, sets of instructions, procedures, functions, objects, classes, instances, related data, or a portion thereof adapted for implementation in a suitable computer code (including source code, object code, or executable code). The term "communicate," as well as derivatives thereof, encompasses both direct and indirect communication. The phrase "associated with," as well as derivatives thereof, may mean to include, be included within, interconnect with, contain, be contained within, connect to or with, couple to or with, be communicable with, cooperate with, interleave, juxtapose, be proximate to, be bound to or with, have, have a property of, have a relationship to or with, or the like.

The description in the present application should not be read as implying that any particular element, step, or function is an essential or critical element that must be included in the claim scope. The scope of patented subject matter is defined only by the allowed claims.

Claim 1:
An apparatus for sending and receiving data on an alternate communication path between a first network node and a second network node; the apparatus comprising:
a first network (LAN A) connecting the first network node to the second network node, the first network establishing a first communication path that sends and receives data between the first network node and second network node;
a second network (LAN B) connecting the second network node to the first network node, the second network establishing a second communication path that sends and receives data between the first network node and second network node; characterized by
a third network (<NUM>) connected to the first network node and the second network node the third network forming the alternate network path, the first network, the second network and the third network being disjoint from each other; and
a diagnostic program (<NUM>) that causes the alternate network path to send and receive data between the first network node and the second network node when a communication path failure in the first network (LAN A) and the second network (LAN B) is detected.