Emerson Exchange 365

John, A lot has changed since version 6 of DeltaV.

First, the limitation on valid remote IO references is with Outputs. An Output channel can only be referenced by local Control modules. Those modules can reference Input IO from another controller. Prior to version 12, if you had a local module and a remote module both referencing the same Input channel, the system calculated a DST license for each module. The intended structure was to have one module (the main control or monitoring module) reference the IO and then all other modules would reference that module with no added licensing. Another thing to understand about referencing IO directly is that the update rate of that IO signal to the remote module will be no faster than 500 ms. So if you are implementing closed loop control with an Output on controller A, and the input on Controller B, you would place the control module in Controller A, reference the input from Controller B, and understand that your closed loop process dynamics will likely have a 0.5 ms delay, in addition to the IO update and module execution rates. The communication update will be by exception and no faster than either of the modules' execution rate.
This has nothing to do with the IO type (local, Remote IO, or CHARMS). The IO is assigned to Controller B and read by controller A. This capability has been possible in DeltaV since at least v3.

As for splitting control across controllers being Taboo, it was, and is really more about exceptions to rules and whether it is appropriate. The recommended method is to install closed loop control IO on the same controller. This is akin to having the FF devices on the same segment so that the AI, PID and AO blocks can execute in order to provide the best control response for fast loops. Remote references would be appropriate for Feed Forward or to integrate interlocks and such. By design, the DeltaV Cascade Control templates allow for the Master or outer loop to be in a different controller than the Slave or inner loop. The inner loop is typically expected to have a time constant at least 4 to 5 times faster than the outer loop. (Otherwise, you can simply use a single PID). If the process time constants are slow (i.e. > 10 seconds), any additional signal dead time from peer to peer communication of IO data would not impact control. But we still prefer to see INputs and Outputs of a loop or a Motor Control function to be on the same controller. Exceptions to the rule are allowed, and supported.

Note that if you really did a poor job of designing the IO assignments to controllers, you would create additional communication load on controllers and would limit the effective control loop response, not to mention maintenance issues with such a confusing implementation.

The Original Remote IO product provided a simplex scanner supporting one 8 wide baseplate. Each card can be independently assigned to a different controller, with the RIU supporting up to 4 controllers. You were able to assign up to 16 remote IO units to a single controller. Along with the 8 local carriers, a controller was able to have 192 IO cards, and with 8, 16 and 32 channel IO cards, the possible address space could exceed 6000 channels. Of course the usable limit is based on the controller's DST max of 750 or 1500 IO.

The reality is that because of the simplex scanner, the RIU found its way to non-critical applications or monitoring only. You can place both Input and Output cards on the RIU, but adoption for close loop control was not high.

WIth the release of electronic Marshalling, the CIOC was designed with full redundancy down to the individual channel to give that required high level of availability, and assignment to controllers was by individual channel. Note that the CIOC also supports a maximum of 4 controllers, and that each IO channel serves one controller. From the controller, that channel can be referenced by multiple controllers as a controller data source.

What about this IO on the PCN Ethernet architecture? Both the RIU and CIOC use the same architecture. Emerson released the Controller firewall to provide isolation and protection to the Ethernet segments with IO nodes. The firewall, in addition to applying rules to filter out invalid protocols, ports and packet structures, it also throttled multi cast and broad cast traffic to prevent a disruptive storm from knocking communications between the IO and the controller. After v11 was released, the DeltaV Smart Switches were equipped with this storm mitigation capability, isolating any broadcast or Multicast storm to be halted at the incoming switch port, preventing denial of service disruptions. The S series controllers and CIOC's were further enhanced with deep packet inspection protection, similar to the rules in the firewall. The RIU's do not have this feature.

So, it is highly recommended to use DeltaV Smart Switches to connect CIOC's to their assigned controllers. This architecture is Achilles certified, without the need for the Firewall. If using RIU's, the firewall would be recommended to mitigate issues with invalid packets, based on the cyber security risk factors. If non Smart Switches are used, the firewall is highly recommended to protect the IO connection from disruptive Ethernet packets from a defective Network card or cyber security malware.

If you are planning to do control over this remote IO, I would recommend the CIOC. You can easily cascade multiple CIOC's back to the controller switch. You get maximum flexibility on IO types, such that you can use 100% of the installed IO capacity. The card based RIU can leave you with unused channels that might not be what you need in the future. (9 AO channels requires 2 cards leaving 7 unused channels).

I look at this way. If I had a "CIOC card" on my controller local IO bus, I would have to install a dedicated network segment to the CIOC's, which would only see that one controller. With the PCN connection, I accomplish this same level to separation using a Smart Switch that connects to the controller and allows the CIOC's to communicate back to this. I call this an IO network with a Controller. The big thing here is to realize that I can add a controller to this IO Network if I find I need more CPU. Since each CIOC can talk to 4 controllers, I know I can expand the control capacity of this IO network without physically modifying any IO connection. I electrically marshal the IO signals to the controller that needs them, leaving an adjacent channel assigned to the original controller. I call this Expandable CPU. Unlike any system that dedicates the IO card and all its channels to a single controller, I can confidently assign my field IO to any channel on any IO card in the network, and once I design and configure the controllers for that IO network, I can assign each channel as needed. This truly allows you to design the IO independently of the controllers.

We are now at version 13.3.1 of DeltaV. We have new Network switches and controllers with new Operating systems and associated cyber security enhancements. Stay tuned for v14 enhancements to DeltaV, and if you go to Exchange this year you'll see more.

Andre Dicaire