Automating automation: Why do smart devices have to be configured manually?
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.
The DICED process of device configuration
According to Timm Madden, senior instrumentation and control consultant for ExxonMobil Development Company, when using the DICED (look at the initials of the list below) approach, here is what is supposed to happen when a new HART 6 or HART 7 device is connected to a control system using configurable I/O:
Detect — When a new (to the system) HART device is connected to the configurable I/O, the I/O channel detects that current is flowing where current was previously not flowing. That means a new device has been added.
Interrogate — The I/O channel transmits the HART command requesting the device’s tag. The HART-enabled device responds with its tag name. If the new device is not a HART-enabled device, a shut-off valve for example, it will obviously not be able to respond to that initial request. In this case, the DICED process is aborted, but a notification to the user can still be generated reporting that there has been a change in the field wiring, and it is likely that a new DI or DO device has been installed.
Configure — Once the system has detected and determined that there is a new HART-enabled device, the system can configure the device with its engineering range, engineering units, and other configuration information. Our plan is to purchase field devices with only the tag pre-configured and then let the system, which generally has the latest data, configure the field devices accordingly.
Enable — We are assuming that the field devices will have been configured in the system and associated with a particular control strategy. Note that our project execution process going forward assumes that we will complete most of the engineering, configuration, and testing in a virtual environment, but that we will likely not know exactly to which I/O channel each field device is configured. So in this step, the system will know to which I/O channel the new device is connected and now the logical association between the control strategy and field device can be made. Once this happens, the field device and its associated logic are enabled for use.
Document — Assuming all of the above steps are completed successfully, our expectation is that the system will report this success in an event log. Our vision is that we can greatly streamline the field commissioning activities that today require paper loop folders and a lot of field trips.
We also believe that the system can automate some of the testing that today is performed by an engineer or operator sitting at the console in radio contact with a field team. For example, if the detected device is a control valve, we can send an analog output to the valve and read back its position via HART. So we can verify that the valve is working, that it is not sticking, that its failure mode (fail open or closed) is correct, and that it positions correctly over its range.
We have an opinion that all of the circuitry needed to implement DICED is contained in the configurable I/O module. Now it is a question of getting the software implemented to take full advantage of this hardware. Note that DICED requires no changes in the field devices themselves.
Concept vs. reality
The technology necessary to support DICED does not exist yet. But how close are we? ExxonMobil believes that HART 6 and 7 transmitters are ready now and the new I/O systems should be capable of supporting it. In preparation of this article, I put the "How far away are we?" question to four of the major vendors that are producing instrumentation and configurable I/O. None answered.
It is possible that this development has moved farther than we know, or various suppliers are taking a direction somewhat different than DICED suggests but with a similar objective. Time will tell.
Peter Welander is a Control Engineering contributing content specialist.
- New I/O systems make HART devices easier to use, but device configuration remains a largely manual process.
- Users would like to see a mechanism that supports automated device configuration by the control system directly to the device transmitter.
Read related stories more about smart I/O and networks below.
This is the Control Engineering October 2014 cover story for the print and digital edition. See the Control Engineering digital edition archive.