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.


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. Courtesy: CFE MediaOver 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 Engineering, CFE Media, October 2014 cover

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.

<< First < Previous 1 2 Next > Last >>

Les , , 10/09/14 11:35 AM:

The question would be "Does the system really know what the configuration should be?" You are assuming that the system knows this. The device can not make such an assumption because it does not know your system. If your system knows so much perhaps it should do the configuration for the tech.
Anonymous , 10/12/14 06:39 AM:

There is a way to also make discrete devices like on-off valves intelligent, to enable automatic detection, device identification, control strategy binding, device management integration, configuration, checking, and documentation. Since discrete devices make up a considerable portion of I/O in a plant, being able to do this automatically, in my personal opinion, is significant.

I personally agree that many plants end up using just the plain analog signal of field devices. It matches what I often see. I believe it so because the design and installation was done thinking of just plain analog, but the digital HART communication is more demanding than analog 4-20 mA with respect to cable type, shield, grounding, capacitance, length, and separation from power cables etc. As a result, communication errors appear sooner or later, and the communication gets disabled, using just plain analog mode. It can be avoided if you follow the recommendations explained here:

There is not that much difference between HART5 and HART6/HART7 for 4-20 mA devices. The big deal with HART7 in my opinion is WirelessHART. The most useful difference between HART5 and HART6/HART7 devices is that HART5 devices have an 8 character tag and HART6/HART7 devices have a 32 character tag. This means that a tag such as “65-FT-108A” in a HART5 device has to be abbreviated as “65FT108A” - but it can still be done. Note that HART5, HART6, and HART7 devices have the same diagnostics. I often hear HART5 devices have less diagnostics than HART7 devices, but this is not the case. The protocol version does not define the diagnostics. It is the device manufacturer that defines the diagnostics. A HART5 device from one manufacturer may have more diagnostics than a HART7 device from another manufacturer. Indeed there are devices that can be configured to communicate using either HART7 or HART5 (compatible with older systems), and the diagnostic is the same. What limits the diagnostics is the 4 mA loop power, not the protocol version.

Using a digital fieldbus is a way for plants to take the smart concept even further by also putting the same kind of intelligence in their discrete devices like on-off valves. This in my personal opinion is a major technological advance that will drastically simplify projects going forward. This way on-off valves can be just as intelligent and sophisticated as control valves; enabling centralized configuration/setup, easy diagnostics/troubleshooting, as well as access to internal variables etc. Two-wire intelligent on-off valves cost less to implement and provide diagnostics for troubleshooting, and centralized configuration and management from intelligent device management (IDM) software part of the asset management system (AMS) make them too far more flexible.

I personally agree that digital real-time fieldbus communication does not need marshalling cabinets - provided the fieldbus power supply is built into the H1 fieldbus interface card. Fieldbus dramatically reduces the number of cabinets which reduces the size of the field auxiliary rooms (FAR) onshore or overall weight offshore since fieldbus connects many devices on a single pair of wires. Moreover, that single pair of fieldbus wires connects ALL the I/O signals in every device; not just one signal per device. That is, multiple measurements per transmitter, and all the command and feedback signals for valves. Virtual I/O and virtual marshalling are explained in the fieldbus brochure:

The key to configuring large number of devices on a project in bulk is to use device configuration “templates” to build the configuration. The device configuration is downloaded by the control system automatically through the fieldbus network. This eliminates the need to manually keying in the settings line by line through tedious dialogs of handhelds. Configuration download and “templates” for fieldbus devices are explained here:
These templates are also used to verify configuration integrity over time

Fieldbus transmitters for the most part do not need a range to be configured since the signal is transmitted digitally in real-time all the way, it is not converted to analog and then back to digital again.

I personally completely agree that marshalling should be eliminated. As far as termination is concerned it is actually even more extreme. The example makes the assumption a device only has one signal, but in actual fact a device has on average 3 signals corresponding to 3 pairs of wires and 3 I/O channels for each device. Therefore the number of terminations is further reduced by a factor of 3. This makes the case for marshalling elimination even stronger. A simple pressure or temperature transmitter has a single signal, but a control valve has 2-3 signals (setpoint and feedback), an on-off valve has 3 signals (solenoid and limit switches), and electric actuator / motor operated valve has up to 16 I/O if you want to fully benefit from its capabilities. An alternative used by many other companies is using real-time digital fieldbus which only requires a single pair of wires from the field junction box to the device so the reduction in termination, cabling, and I/O can be taken even further by a factor of 3. For instance, 5,000 conventional I/O points becomes 1,700 fieldbus devices. WirelessHART should also be mentioned in this context. Modern plants will have many more sensors “beyond the P&ID”; not for the operators, but for personnel beyond the control room; sensors connected direct to the plant historian to improve reliability, maintenance productivity, energy efficiency, and to reduce HS&E risk. These measurements lend themselves well to WirelessHART, eliminating marshalling.

I also agree with the need to reduce hardware customization. There is only one type of FOUNDATION fieldbus interface card. The same card is used for input and output devices, continuous and discrete signals, so the cabinets are standardized. The fieldbus architecture is different in that the interface card is located indoors, not in the junction box in the field, as the real-time digital communication goes all the way to the sensors and actuator, from the very first meter, completely eliminating hardwired 4-20 mA and on-off signals.

I personally totally agree with the smart device commissioning concept. It can also be applied to discrete devices like on-off valves provided intelligent on-off valves are used and communication is in place. Intelligent two-wire on-off valves are available with fieldbus since a few years ago. That is, intelligent on-off devices enable the same smart commissioning: automatic detection and identification, automatic binding to the control strategy and integration with the intelligent device management software, as well as automatic configuration download, loop checking, and lastly generation of documentation.
Richard , MA, United States, 10/16/14 03:52 PM:

For new plants, Foundation Fieldbus H1 instruments with Foundation Fieldbus HSE Linking Devices and a network can solve most problems. There is no marshaling, that is done in the field with a Linking Device. The DCS interface is just Ethernet - but except for ABB and Yokogawa, all other DCS suppliers do not support HSE, and it's HSE that enables the cost reduction in cabling and elimination of marshaling. ABB and Yokogawa have yet to figure this out and are not marketing their systems in such a way that Timm Madden would recognize these benefits. All other DCS suppliers just give lip-service to their Foundation Fieldbus support.

For older systems with aging and obsolete DCSs, it's even worse. Usually, they have thousands of perfectly good HART instruments in the field, and no way to communicate with their digital data content except with a handheld terminal or an investment in slow HART multiplexers, just like we used to do with ancient pneumatic multiplexers of ages past. Of course, they could also use either ISA100 or WirelessHART wireless networks, but that is even further removed from established configurations for control. For these older plants with wired HART, another solution is necessary to avoid the cost of new marshaling racks and I/O boards just to switch to a new DCS.

Timm is right - there must be a better way, and today's DCS offerings are better than yesteryear, but are still incomplete.
albert , TX, United States, 11/16/14 08:15 PM:

Very good article
Anonymous , 11/24/14 10:48 AM:

The article is very interesting ans useful.
The Engineers' Choice Awards highlight some of the best new control, instrumentation and automation products as chosen by...
The System Integrator Giants program lists the top 100 system integrators among companies listed in CFE Media's Global System Integrator Database.
Each year, a panel of Control Engineering and Plant Engineering editors and industry expert judges select the System Integrator of the Year Award winners in three categories.
This eGuide illustrates solutions, applications and benefits of machine vision systems.
Learn how to increase device reliability in harsh environments and decrease unplanned system downtime.
This eGuide contains a series of articles and videos that considers theoretical and practical; immediate needs and a look into the future.
Controller programming; Safety networks; Enclosure design; Power quality; Safety integrity levels; Increasing process efficiency
Additive manufacturing benefits; HMI and sensor tips; System integrator advice; Innovations from the industry
Robotic safety, collaboration, standards; DCS migration tips; IT/OT convergence; 2017 Control Engineering Salary and Career Survey
Featured articles highlight technologies that enable the Industrial Internet of Things, IIoT-related products and strategies to get data more easily to the user.
This article collection contains several articles on how automation and controls are helping human-machine interface (HMI) hardware and software advance.
This digital report will explore several aspects of how IIoT will transform manufacturing in the coming years.

Find and connect with the most suitable service provider for your unique application. Start searching the Global System Integrator Database Now!

Infrastructure for natural gas expansion; Artificial lift methods; Disruptive technology and fugitive gas emissions
Mobility as the means to offshore innovation; Preventing another Deepwater Horizon; ROVs as subsea robots; SCADA and the radio spectrum
Future of oil and gas projects; Reservoir models; The importance of SCADA to oil and gas
Automation Engineer; Wood Group
System Integrator; Cross Integrated Systems Group
Jose S. Vasquez, Jr.
Fire & Life Safety Engineer; Technip USA Inc.
This course focuses on climate analysis, appropriateness of cooling system selection, and combining cooling systems.
This course will help identify and reveal electrical hazards and identify the solutions to implementing and maintaining a safe work environment.
This course explains how maintaining power and communication systems through emergency power-generation systems is critical.
click me