Emerson Exchange 365

Here's a suggested process to follow for using EIOC vs VIM2

• IEC-61850 Required? Yes = EIOC
• > 32 device/PLC nodes? Yes = EIOC
• > 6000 Soft IO Tags? Yes = EIOC
• EM's, SFC's or Batch Required? Yes = VIM2
• PLC Migration w/ Heavy Control? Yes = VIM2
• PLC Hardwired IO using Soft IO? Yes = VIM2
• Use EIOC

Hi Neil,

In reply to petroban:

This is a very relevant question. And the landscape is moving.

The EIOC was conceived to offer a natively configured Ethernet integration product with superior performance to the VIM/VIM2. In its v13 initial release, I can only say it was poorly positioned based on its capacity for 256 devices and compared to an SX with VIM solution. It was positioned to integrate any and all devices, including MCC, VFDs, PLC's, IEDs(with IEC61850), and if you managed to have 256 devices on an EIOC, it wasn't too exorbitant. But forcing customers to purchase 256 device capacity priced the node out of reach for most budgets.

In v14, the EIOC is repositioned for subsystem integration and users can purchase the number of devices they plan to connect. So price is less of an issue, and would be less than an SX with VIM.

The EIOC sits as an independent node on the DeltaV network, and counts as an IO Node, like a CIOC or WIOC, of which there is a limit of 300 per system. It does not count as one of the primary 120 nodes, like controllers and Workstations. However, it is not assignable to any controller, like the CIOC or WIOC. The EIOC natively runs the control modules that access the Ethernet signals in the configured logical devices. The EIOC does not support local DeltaV IO. When integrating motors, there may be an emergency stop hardwired to the DCS, or users may prefer to control the motor via hard IO and use Ethernet data for diagnostics and secondary data. In this case the EIOC alone does not work. Also, when motors and VFD's are integrated in the process control functions, interlocks and automated sequences may be sourced in the controller, and it is preferable to connect these devices to their controller via VIM.

In v14.3, DeltaV also released the PK controllers that have an integrated Ethernet port for these devices. It runs the same configuration approach as the EIOC, but does not support the IEC61850 protocol or the OPC UA Client that the EIOC has.

In v14.3, the EIOC was enhanced with the OPC UA protocol and also with the PRP (parallel Redundant protocol) so that it can connect to the IEC61850 network architecture. The PRP can be used with any protocol to create a high availability network with PRP aware switches or RED Boxes. The PK and VIM do not support the PRP, yet.

For me, I position the EIOC for subsystem integration, where the subsystem is performing the control, like a PLC. Or for integrating IEC61850 or OPC UA subsystems. In v14.3, new engineering tools integrate AB PLC data structures that simplify PLC integration. These are only supported on the EIOC. So if there is a significant number of registers coming from PLC's, the EIOC would provide the best solution.

The EIOC can process significantly more data than the VIM as the Ethernet data lands directly in the processor, with no need to move through the DeltaV IO bus used by the VIM. The PK also has better throughput than the VIM for the same reason.

For M-series and S-Series IO, the VIM/VIM2 is required to integrate Ethernet Devices lime MCC's and VFD's to the controller. Adding the VIM2 to the existing controller is much more cost effective than using an EIOC for these devices. But remember that the control modules used for Ethernet IO devices use just as much controller CPU as physical IO. The capacity of an SX controller to handle its normal hard IO is limited, and adding thousands of soft IO to the same controller will impact CPU loading. Integrating a VFD means one module for all the data registers of that device. Integrating a PLC with 20 datasets and up to 2000 signals could add 500 or more control modules. Dedicating an SX controller with VIM for a group of PLC's would work, but I would move to the EIOC for such a situation, and the increased bandwidth.

The PK controller in v14 changes the game, again. Although I still prefer to use an EIOC for subsystem integration, the PK offers the same performance as the EIOC and for applications that require no more than 100 or 300 "Logical Devices", the PK 100 or PK300 would be better value, as long as I don't need IEC61850, OPC UA client or the PLC Integration tools. The limits on SFCs and EMS and functions blocks are not there. PRP is not supported on the PK in v14.

The way I see it, the VIM2 is for the M series and S Series controllers, but can also be added to a PK (if you needed both Modbus TCP and EthernetIP on one controller.) With v14 PK controllers the VIM will mostly not be needed.

The EIOC is only available on v13 or later, with changes in licensing in v14. Both the EIOC and PK use a device license to enable the right number of devices. The PK controllers limit the number of devices possible based on their size: PK100=16 devices, PK300=32 devices, PK750=64 devices, PK1500=128 devices.

If I had my druthers, I would clearly position the EIOC for Subsystems and enhance that product to serve that market. The PK controller would provide optional Ethernet IO integration for MCC's and VFD's for tight integration in the control strategies. The VIM provided these capabilities in pre v13/v14 systems. The VIM also supports a host of other protocols that can be integrated into the PK, M-series and S-series controllers as well. It continues to be developed to serve our installed base of M and S series systems.

2 cents.

Andre Dicaire

In reply to Andre Dicaire:

In my opinion, a very important feature on EOIC not present on VIM is that EOIC allows to define DST's on data exchanged even into bit level, similar to deltav profibus. This is could remove the need to deploy intermediate encode/decode control modules (a.k.a landing modules) when discrete signals are packed into registers. Using this feature possible to use same discrete device classes for conventional and communicated device signals because DST's defined into EOIC may be consumed on function block IO_IN/IO_OUT parameters. Inmmediate benefits are less controller loading and smaller project library size.