Modular I/O is more popular in Europe and in non-process/continuous operations, well-suited to concentrations of I/O situated in reasonable proximity and preferably in unclassified areas. There are intrinsically safe (IS) remote I/O products available, but IS represents about 10–20% of the total process I/O market. As process I/O is only a fraction of the overall I/O market, this is definitely a niche application.
There are a number of reasons that modular I/O is not very prevalent in North America. The two primary roadblocks are field power and standard backhaul protocol.
Remote I/O systems require power for the unit itself and to drive the inputs and outputs. Unfortunately, at least in North America, once you get outside the control room, reliable power is not so common. This is because the lighting panels are used for everything ac and could be isolated for some form of maintenance, or at least the single bus isolated and then the associated devices are automatically off, with potentially adverse consequences. For those simpler remote I/O devices for which the module itself is loop-powered by Power over Ethernet (PoE), for example, there is still not sufficient power to drive the loops. A typical analog loop requires about 13 mA just to power the instrument, never mind taking into account other losses. Hopefully, the forthcoming flood of wireless access points will help drive the development of reliable field power supplies.
The backhaul protocol is critical to the adoption of open modular I/O because it connects remote modules to central controllers. Without protocols to make these connections, there always will be limited interoperability between the field and controllers. Granted, in most cases a facility typically will not have more than two or three different suppliers for any one product in a single facility or at least a single site, so by judicious selection this challenge can at least be managed and hopefully all the suppliers will support a common protocol such as Profibus, EtherCat or other protocol that is relatively easy to configure.
Configuration is important and always should be a consideration when selecting the remote I/O device. A common protocol is great, but if it requires that you map every parameter from the device to every data point/tag in the control system, then not only is this a lot of effort but it’s also prone to error, even if only a keying error. More complex protocols can do much of this mapping for you via enhancements such as device descriptions that uniformly define the parameters in the devices. Unfortunately, there is still work required to get the diagnostic data in smart devices fully defined, so that, just like process variables, fault conditions can be transferred automatically to the appropriate asset management software with minimal effort.
Fortunately, the ISA100.15 backhaul specifications are being developed as a joint effort between ISA and the Fieldbus Foundation, so odds are good that the resulting protocol will be very close to the HSE wired protocol. Combining this with the pending release of FF Certified HSE Remote I/O products in 2011 increases the odds of having a protocol that is not only easily configurable thanks to EDDL and the forthcoming FDI standards, but also interoperable between hosts and I/O suppliers, courtesy of interoperability testing by both organizations.
The next step on modular I/O will be the incorporation of gateways in the field devices, so you can capture simple signals and also the richer information available from a range of digital protocols such as HART or DeviceNet into a higher-level, faster protocol such as Profinet or HSE.
Despite the above, one thing that might drive the adoption of modular/distributed I/O in the process industries in North America is the continuing trend to use modular construction of facilities — thus making it sensible to pre-wire the instruments to a single point to which a single cable can be connected, and make it possible to fully function test the skid before it leaves the factory/assembly yard.
What are your thoughts on modular I/O? If you have additional reasons or rebuttals regarding the subject, let me know and we will continue this discussion in another column next year.