Automating automation: Why do smart devices have to be configured manually?
While smart instrumentation and field devices have highly sophisticated capabilities, configuration is still a mostly manual process. Users want to know why they still have to perform this action (and many others) the hard way. This is the Control Engineering October 2014 cover story for the print and digital edition.
Over recent years, Control Engineering has discussed developments in smart field devices from time to time. Mostly the discussion has concentrated on capabilities being added to the transmitters, but there have also been considerations of how difficult it can be for that information to get to the control system because older device-level networks can't handle it.
Some of that has to do with the reality of industrial networks in actual manufacturing plants. Most process units that are more than a few years old operate with a mish-mash of automation equipment installed at different times since the plant was first built. When that happens, most systems end up working in a lowest-common-denominator mode where overall performance is not any better than its oldest part. This is often visible in the networks that talk to field devices if they're just plain analog.
Control system vendors have offered more sophisticated capabilities beyond plain analog I/O for quite a while. Native HART-enabled I/O has been around for years, although many companies with older systems have yet to implement it. (Companies that see no reason to improve and are happy with what they have using dumb I/O are not the concern of this discussion.) Most of what has been deployed in the way of HART devices and infrastructure (HART-enabled I/O and multiplexer installations) uses HART 5, which has been around since the early 1990s. More recently, several of the major system vendors have introduced configurable I/O that can be changed via software or a hardware module.
This configurable I/O, at least as it relates to HART devices, provides the most up-to-date mechanism for users to interact with smart devices and realize all the benefits they have to offer. It can interact fully with HART 6 and 7 transmitters as more of those become available, taking advantage of all the latest diagnostic data and bi-directional communication between the control system and device. (Fieldbus users point out that they've had this capability all along, but more on that later.)
Many large-scale process plant owners, such as oil refinery operators, are looking at this as a major technological advance that will drastically simplify projects going forward. Sophisticated HART-enabled devices will have equally sophisticated communication paths that cost less to implement, are easier to troubleshoot, and are far more flexible.
A great step forward, but...
Let's consider today's context. There have been some interesting discussions over the last couple of years where process manufacturers have been more vocal about the state of the automation industry, and what they would like to see from the vendors. Details vary, but there are some common themes:
Automation is infrastructure that supports processes. Consequently, the people designing automation systems have to fulfill the needs of the chemical engineers and other production people that design the process. If one of those elements changes, the automation system has to accommodate that change, which can disrupt all sorts of things and put automation on the critical path for a project. Automation hardware and systems currently available do not always make those late changes easy to accommodate.
Far too much automation equipment has to be designed for a given application and is heavily customized. This makes it expensive, difficult to change, and engineering intensive. There has to be much documentation and testing. Being able to use more standardized off-the-shelf equipment with fewer communication methods and protocols would be a huge help.
The list could go on, but let's stick to things related to instrumentation.
Many users are very enthusiastic about the new configurable I/O systems that are now on the market. They see such systems as evidence that vendors do listen, and want to take advantage of this huge move forward in flexibility. There are two things that users of HART-enabled instrumentation repeatedly mention they want to get rid of: marshalling cabinets and HART multiplexers. Configurable I/O can eliminate both. (Fieldbus users will point out that they don't need that stuff.)
So what's the problem?
All these advances are considered wonderful, and rightfully so. But the problem that refuses to go away is device configuration. The number of parameters that have to be set on a typical smart device has increased significantly over the last few years. Someone who has the job of keying in the settings has to go through line after line after line of questions and answers to get through it all. The exact number varies according to the type of device, but it takes a while. Foundation fieldbus users say configuration using that system can be a little faster, but it shares much the same tedious dialog method.
Some customers work with their suppliers to pre-configure devices. When they come out of the box, they already have range, engineering units, alarms, etc., built into the transmitter so it's plug-and-play. That works provided you have all that information at the time that you need to order the devices, which means pretty early in the process. It also means that the configuration specifics can't change between the time the devices are ordered and commissioned. Those two qualifiers reduce the practicality of this approach.
The question that some users ask is, "Why can't we let the system do the configuration for us? The control system has all the information about what it wants from a given field device. It knows that PT215 is 0-30 psi, should trigger an alarm at 25 psi, etc. All that information is in the system and it's up to date. Why does a technician have to look at that information and key it into the device manually?"
Last month, Timm Madden, senior instrumentation and control consultant for ExxonMobil Development Company, delivered a presentation at Yokogawa's User Group with the title, "It Just Happens." He touched on many ways the company is trying to keep automation off the critical path during refinery projects. The goal is to have automation be invisible. There should be so few problems that it simply seems to appear out of nowhere and does its job from the start.
ExxonMobil has been one of the vocal companies in addressing automation issues, and it has offered some challenges to the vendor community. Some of the points covered in Madden's presentation were technical and others procedural, but he spent a fair amount of time talking about smart device configuration. He described a system that ExxonMobil is working on called "DICED." The section "The DICED process of device configuation" explains this in detail.
Madden made the point that ExxonMobil wants to standardize hardware and do whatever customization that a project needs in software. A field cabinet that is outfitted with configurable I/O should be a stock item deliverable in a very short time, fully tested and ready to go. All the information comes from the control system through the network and there is essentially nothing a technician needs to do beyond connecting the device cables. Everything is pre-tested and the amount of documentation needed is drastically reduced.
He says that such a smart I/O cabinet can be placed in the field with nothing going to it but a fiber optic home-run cable and redundant power. Field devices, which could have had 15 to 25 terminations between a device and the control system under the old marshalling cabinet wiring scheme, now have five: two at the device and three in the cabinet. ExxonMobil has not embraced fieldbus networking and prefers HART devices. Madden's contention is that using this approach with a smart I/O cabinet in the field makes it impossible to determine which technique, HART or fieldbus, is in use. The system architecture and resulting functionality is basically the same.