Emerson’s Anand Iyer continues his series on the I/O cloud expanding on the I/O bubbles concept.

For the last few decades, we have been focusing on the concept of redundancy specifically at the CPU and card levels. A few critical field devices are redundant in a few cases. Wireless technologies have found limited use but definitely seem to be the future part and parcel of instrument and control systems.

Modern communication systems provide the following new concepts of multicasting and multihoming.

A multicast message is simply a message that is broadcast to a number of recipients. While multihoming is a concept wherein one device connects to many ISP’s i.e. it communicates over several paths. Like say our every day mobile phone, the moment we leave one network, the device scans and provides us with an alternate path. While in mobile phones we may face a detectable disconnect, the same features in a limited environment such as a plant complex could provide us with seamless alternate routes.

In our instrument and controls world, this would multicasting and multihoming could translate to the following:

Plants could have multiple paths that could be used by IO bubbles.

Will governments refund all old speed tickets with interest? Speeding as a solution in the new environment… Going back to our earlier post on intelligent roads and cars etc… What if tomorrow it is found that cars should actually have run at higher speeds to reduce road congestion? Had society as a whole, allowed people who could safely drive at higher speeds, to do so, there may have been lesser congestion and its aftereffects.

Would governments around the world refund those many speeding tickets issued in the past? Probably not. But when such automatic systems are safely established, speeds would automatically go towards the higher end.

As wireless speeds increase and as we start using more advances concepts of multihoming and multicasting, wired networks may start appearing more cumbersome to build, expensive to maintain and less reliable than the wireless networks of tomorrow. Wired networks will not disappear for a long time and suppliers will have to provide some kind of backup to wireless networks till wireless networks get entrenched inside the control system environment.

Will Multicasting, Multihoming and QOS/TOS change (improve) our concepts of reliable availability of data? Looking at the figure above, where a transmitter is wireless and homes to two wireless devices, and is connected to an electronic marshalling-based system (Could as well be fieldbus-based); the transmitter transmits data via three different networks. This could be a transition phase and later there may be only wireless data communication. Most of the time the data could be transmitted and received from the wireless network.

There could also be a hierarchy where the wireless network (HOME-2) could be primary for the transmitters having only wireless communication, Wireless with wired backbone (HOME-1) could be primary for critical transmitters and Wired (electronic marshalling) could be fall back network for critical transmitters.

HOME-2-à Primary for only wireless devices. Secondary for critical devices.
HOME-1 à Primary for critical devices. Secondary for only wireless devices.
Electronic Marshalling à Backup or tertiary network for a kind of end of world scenario.

If the network were an IPV6 clone, then we could be using QOS/TOS fields to define the criticality of the signal. A typical value for the octet of the differentiated services field could be as below.

A typical use of the 8-bit traffic class (IPV6) is to differentiate between the different types of network traffic (something like defining a priority of communication):

Any network device, ISP, router in the control system domain would give priority to communication packets with Fire gas leak priority (bit 7 set) over ESD or other packets. Additional levels could be added like there could be Process control Manual Commands above Process control signals or the process control signals could have more priorities set by the next three bits.

QOS fields for Instrumentation-control systems. Adding more features to IO bubbles, taking reliability to an even higher level. The diffserv (Traffic class etc) octet could provide a differential priority to the Io bubble.

Let us look at one IO bubble from a Fire scanner. This scans the flame in its path and provides a percent output. The IO bubble for this device could in general have the range from 0-10%. Other parameters like health of the transmitter could be a part of the bubble. The priority of normal transmission could be low i.e. it could be under the process control category.

Once the flame is detected and crosses pre-trip limits, then the communication priority could change to Fire-Gas Alerts.

Further, as soon as the trip limit is crossed then the priority could change to Fire gas leak.

The QOS field change adds more features to the IO bubble making it more reliable. Switches-routers will give higher priority to the Fire-Gas Leak ensuring prompt action from other devices. Assuming that the Fire-GAS leak is a hardwired signal, then the shutdowns coming from the ESD or Fire-GAS shutdown systems could have the highest priority.

If we look at the typical communication demands…

1. Process value and units are required on a continuous basis.
2. Trips when activated (TRIP HI HI, LO LO etc.) (It is assumed that all devices hold last state information till there is a change). We can classify them as “On Actuation” signals.
3. Sensor calibration, drift and other asset management and diagnostic information on demand. Could need a stream of data (higher packet size).
4. Process control configuration information on demand (need more data at real time).
5. Manual commands from operators (like valve mode change, manual value entry).
6. Normal control values from different controllers.
7. High priority commands from programs.

The same device could form different bubbles or packets of data that are transmitted over different networks (different homes based on priority, bandwidth required etc.).

A shutdown could be transmitted on all available communication paths.

The table below shows the different communication priorities for different types of signals. The eight bits proposed for the Type of Service (IPV6) could be effectively utilized as below.

Additional intermediate levels could be defined by some standards committee based on requirements. At present, 255 levels of priorities seem sufficient.

The systems could have predetermined primary and secondary routes based on the type of the bubble. Fire-ESD signals could be sent simultaneously on all networks with highest priority.

Process Control networks could have different networks as their primary and secondary paths.

Asset management remote calibration or configuration could have a different route (could possibly use a hardware cable route).

Further a transmitter could transmit-receive IO bubbles with different priorities.

A gas detector could have the following priorities:

1. A total shutdown signal with highest priority (255).
2. A process control signal with priority 17.
3. An AMS configuration could happen with zero and span gas with priority 25.
4. Remote sensor calibration-trimming could happen with priority 20.

To clarify on a few more points: the priorities are based on the type of IO bubble and not based on the system from where the bubble originates.

A plant with Fire & Gas, ESD and Process control systems could be running continuously at priority 16 and 17.

It would be only during emergencies that the higher priorities would get utilized.

A possible plant network scenario having three network paths is shown below.
Switches and routers for instrumentation and control systems would have these priorities pre-programmed and provide priority based routes. We would probably not be able to use direct of the shelf switches, hubs or routers as we do today. Or maybe suppliers would by then bring some method of doing the priority programming (a process similar to the way we do the smart-switch configuration in DeltaV now).

Redundant communications or multiple active paths. Multicast messages: Most devices would transmit the PV, SP, OUT, Mode as a multicast message. The message would be read simultaneously by Historian, Operator stations, Operator tablets, OPC servers, and so on.

Unicast messages (point to point): Some special requests like configuration of a loop, asset management or some on demand data requests could be unicast messages.

Let us consider a PID loop. The PIC xxyy, is a pressure control loop.

The Pressure Transmitter communicates in the following ways:

1. Unicast pressure PV message to the Valve which hosts the PID loop. (We could also wire the pressure transmitter to the valve locally).
2. Unicast Diagnostic message to the AMS on demand.
3. Unicast Configuration messages to the Engg Station on demand.
4. Unicast Remote Maintenance (from equipment manufacturer for example) messages to the AMS when on remote servicing/calibration mode.

The Pressure Control Valve communicates in the following ways:

1. Unicast message reception from pressure PV.
2. Multicast PV (pressure reading) to all control room equipment and operator tablets.
3. Unicast/multicast message reception from all control room equipment and operator tablets.
4. Unicast message reception from any alternate PV sources. (A second pressure transmitter or other measurements that can be used to control the valve).
5. Unicast Diagnostic message to the AMS on demand.
6. Unicast Configuration messages to the Engg Station on demand.
7. Unicast Remote Maintenance (from equipment manufacturer for example) messages to the AMS when on remote servicing/calibration mode.
8. On actuation messages of alarms.

Looking at the block diagram of the hardware, we can see that there are multiple communication channels/routes in each device. Two possible designs are multiple communication processors, one per network available or one communication processor that can connect to multiple networks simultaneously. Or in other words, the device could also wirelessly communicate over multiple networks.

It is similar to our laptops connecting simultaneously to several wireless networks (at present we communicate to only one network at a time as a standard feature).

Now this brings us to an interesting feature: The devices communicate over multiple paths and maybe multiple methods (wired (copper/fiber optic) Ethernet network cloud, wireless Ethernet control network cloud and so on). Thus, they become more reliable and meet the needs fulfilled by redundancy, but are not like today’s redundant networks. I mean we could call them redundant or maybe we should call them multi-path network cloud to distinguish from the present day redundant networks.

Now once we have a prioritized communication, multiple communication paths, multicast and unicast messages…we come to the next question.

Would Binding IO make any further sense? If I look back in time, every IO in a DCS system has been bound to some processor, CPU, or controller. Except in early days when processor or controller IO was at a premium, some of the IO could be connected to a low level IO device (like a multichannel ADC card on some computer or station).

These IO were available for further processing by any processor or controller. There may have been rigid rules or some limitations in these communications. But removing these earlier limitations of systems from our minds, these could be termed as some of the unbound IO of the early days.

The controller IO were bound to that controller. They were available in a limited way to other controllers.

Once controller IO became more economical, most IO are connected to some processor or controller.

But once again, as we move to IO clouds, the controller has less of a role on very nominal or routine matters like say ranging of an IO, making the IO database available and so on. The controller is used in rare instances, like say we have a 1151 transmitter using 4-20mA, where it may act as a IO bubble forming device (when the transmitter or valve is incapable) or may act to do some equipment module or phase functions that cannot be performed by individual devices.

Controllers may not do PID any more as these and more algorithms of an individual control element (Valve, VFD, damper etc) basis could be done on the individual control element.

Thus, binding the IO to a particular controller would not be necessary. Multicast messages would be received and acted upon by various equipment, each performing its individual role.

Would we see IO shouting “Freedom at last!”?

Share this...

Linkedin

Twitter

Facebook

Email