Getting to interoperable automation and controls
Just because an automation product complies with certain standards doesn’t mean it will be interoperable. Even interoperability is slippery. Should a product interoperate with other products within the company, with all products in that company’s partner list, with all other products that follow a particular version of a standard, or with all products that follow that standard? Or (and I believe this is what end users really expected by now), when you plug in products, they just work. And if they don’t self-configure, they should indicate what needs doing.
Original equipment manufacturers and automation suppliers may say end users won’t pay for that level of functionality, or that even if customers mention standards in specifications (and some inexplicably do not), interoperability really isn’t required. Or OEMs may say they cannot offer best-in-class products inside machines or within processing lines if they’re held to that level of functionality.
Old way: We brought IO to field junction boxes, made a home run to marshalling cabinets, and wired to IO or controller cabinets in a customized way. Engineering was sequential. We were in constant rework. Sometimes at the factory acceptance test (FAT), we saw that we didn’t have a complete design and needed rework at great cost in time and dollars. Everything was custom; nothing was standard. Everything depended on data from all disciplines. It was sequential. There were many terminations and a lot of copper. Changes required pulling extra cable. Sound familiar?Challenge "The way it has always been done," internally and externally, advised Sandy Vasser, facilities electrical and instrumentation manager at ExxonMobil Development. He is changing expectations, eliminating rework, and partnering with suppliers for greater efficiencies in 100 ongoing projects in upstream oil and gas. At the ARC Forum in February, Vasser explained the old way and new way.
New way: A standard, smart junction box has one set of terminations. There are no more complex loops. A data highway goes to controllers. The marshalling cabinet is eliminated. There is no need to do a hardware FAT ever again. Field terminations are cut 60%-70%. It’s almost installation-proof. Software is validated separately, commissioning is streamlined, and documentation is integrated. The projects use smart IO blocks and virtualization for hardware and software. And capabilities for auto detect, integrated configure, enable, and document (DICED) are under development.
Standards are used for human machine interface and wireless, and IEC 61850 provides for standard communication networks and systems in substations.* Hardware is standard and virtualized for engineering, and software is proven before deployed. Several hundred thousand terminations are eliminated. There are fewer loop drawings, less engineering, and control and safety interconnections will self-correct. ABB, Emerson Process Management, GE Intelligent Platforms, Honeywell Process Solutions, Rockwell Automation, Schneider Electric, Siemens, and Yokogawa are among vendors working on extending these capabilities for ExxonMobil.
Do you have to be the largest non-governmental oil and gas producer to get this kind of treatment? Think again. As you use these vendors, and others, be disciplined and demand the same. See the online box for more.
– Mark T. Hoske, content manager, CFE Media, Control Engineering, email@example.com.
– * Note from Control Engineering Engineering and IT Insight columnist, Dennis Brandl, said on March 18: A better model is the IEC 61158-2, Digital data communications for measurement and control – Fieldbus for use in industrial control systems – Part 2: Physical layer specification and service definition, Type 5 (HSE). This is closer to the industrial use than the referenced IEC 61850. In fact a lot of people are now looking at 61158-2 as a distributed control backbone.
– See 12 tips from Vasser, in the first item linked below, and other advice below that.