Open topic with navigation
The ODVA EtherNet/IP firmware supports redundant field communications, as of version 1.3.
The Redundant ODVA EtherNet/IP firmware requires two VIM2 and a Virtual IO Module Redundant Link. Each VIM will have its own connection to a shared network. Figure 1 shows a basic redundant VIM network with one redundant field device.
The redundant VIM operates in an active/standby system. The active VIM contains the current input data from the field devices and a copy of the output data from DeltaV. The standby VIM sends a ping to the field devices, to verify that it can connect, should it be required.
Figure 2 shows the flowchart for the VIM. When the VIM boots, the DeltaV controller tells it whether it should be active or standby. The standby VIM starts pinging all the configured field devices and notifying the active of which ones it can connect. The active VIM starts the communications with all the field devices and monitors for errors or timeouts. If either is detected, it checks the last ping report from the standby, to see if it can connect to more field devices.
If the standby can connect to more devices, the active tells the controller that it can no longer connect to the field. The controller then tells the standby to change to active mode, and the active to change to standby mode. The standby receives the Go Active request, but before it can become active, it must wait for the old active to transition to standby mode. Once that is complete, it switches to active and begins communicating with the field devices.
If the standby cannot connect to as many devices as the active, then there is no switchover and the current active continues to communicate with the field devices. This prevents a switchover from degrading the overall availability of the system.
When the standby VIM is transitioning to active, it must first wait for the old active VIM to enter standby mode. Both VIMs cannot be active at the same time. The standby must receive the In Standby notification from the partner. In order to prevent the VIM from waiting forever the standby will timeout and continue to active mode. This situation happens when the partner is not powered or the redundancy link cable is missing.
The firmware emulates redundant DeltaV IO cards, to allow the DeltaV controller to coordinate the redundant operation. DeltaV does not support redundant DeviceNet Interface Cards, so the ODVA EtherNet/IP firmware will only emulate Programmable Serial Interface Cards (PSIC) while in redundant mode.
The firmware will emulate 8 PSIC, 4 on each VIM. One VIM emulates the cards in the odd-numbered slots, while the other VIM emulates the cards in the even-numbered slots. When the VIM switches, all four PSIC it is emulating will switch together.
The VIM that is emulating the odd-numbered IO cards is referred to as VIM A. The VIM that is running the even-numbered IO cards is referred to as VIM B.
Each type of messaging in EtherNet/IP results in slightly different redundancy schemes. Each messaging mode and its impact on redundancy is discussed below.
The field device may be simplex or redundant. The VIM treats simplex and redundant field devices differently. A mix of redundant and simplex field devices is supported on a single VIM.
A simplex device has only one IP address available. If that IP address is not reachable, neither the active or standby VIM will be able to use it. Both the active and the standby VIM will attempt to connect; the active performing normal operations and the standby performing a ping. It is important that the field device support multiple connections for proper operation of the redundant VIM.
A redundant device has two IP addresses. Accessing the device through either address will have the same result. The two IP addresses are expected to both be available at the same time. The VIM A will connect to the primary address and VIM B will connect to the secondary address.
Note: Redundant Field Device with IP Switching should be configured as Simplex.
A third class of device, called redundant with switching IP, has two IP addresses; one of the addresses is primary and the other is backup. The device should always be accessed through the primary. Accessing the device by the backup IP address results in errors. If the media of the network interface with the primary address is lost, the backup network interface assumes the primary address, i.e., the IP address swaps to the operational network interface. In this case, the VIM should treat this device as simplex, configuring only the primary IP address. The backup IP address is not needed. Any switching the device performs becomes invisible to the VIM.