Anyone can drive down a wide-open, well maintained road on a lovely day. But it requires a higher level of skill to avoid disaster when there is traffic, construction and bad weather. Similarly, good engineering for automation projects requires us to think beyond the normal everyday conditions and make sure we are designing to protect against the unexpected. Many designs appear to work well under typical conditions, but may not respond as desired during situations out past the “edge” of normality such as wiring faults, power failures, mechanical breakdowns, and bad inputs.
Today’s automation engineer must be familiar with electrical design, instrument selection, control hardware performance, process functionality, and software development concepts. This post is aimed at practical automation engineering considerations that should be addressed for typical projects. It does not attempt to address more specialized topics such as safety integrity level (SIL) design, hazard and operability studies (HAZOP), cybersecurity, redundancy, and the like.
Instead, let’s focus on good design practices at the field device, control platform, and programming levels. A term applicable to multilayered approaches is “defense in depth.” This means that while any one layer of protection may not succeed, taken as a whole the designer has made the best available choice at each layer. In this way, if an unusual or even unexpected “boundary condition” occurs in the operation, the system is positioned to respond in the best possible way to protect people and property.
Configuring devices as fail-safe
Beginning at the field device layer, the primary consideration is configuring devices as “fail-safe”. Simple mechanical discrete devices, like pressure and flow switches, offer normally open (N.O.) and normally closed (N.C.) contacts which should always be selected such that a “on/closed/1” result indicates that the process condition is “OK”, while an “off/open/0” result indicates “bad.”
The reason is that if a device is not configured fail-safe in this way, then a loose field wire will fail to transmit a “bad” condition to the control system. The contact selection is based on the process situation. If a pump must be interlocked off upon high downstream pressure, then choose a N.C. contact that opens upon high pressure. If the same pump must be interlocked off upon failure of seal water flow, then choose a N.O. contact that closes upon good flow. In each case, a loose wire will trigger the fault response.
Smarter powered field devices can offer more advanced options, such as normally open held closed (N.O.H.C.) contacts. These contacts will close if the device is powered and the process condition is “OK”, and will open otherwise. The device is effectively encoding two pieces of information in series; the process condition and the device health. Similarly, many 4-20mA transmitters can be configured to fail high or low.
If such a transmitter indicates a vessel temperature and the sensing element fails, then usually the transmitter should be configured to “fail high” to a >20mA signal so the control system responds as if the process is far too hot (which would trigger disabling the heating source). However, if such a transmitter indicates equipment oil pressure and there is an internal sensor failure, then the device should be configured to “fail low” to a <4mA signal so the control system reacts to a perceived loss of oil pressure.
Achieving the safest possible state
Controlled devices like valves, variable frequency drives (VFDs), and packaged equipment have some additional considerations, since they are performing real-world actions that can affect processes and personnel. These devices must be provided with hardware (such as spring returns for valves) and be configured as needed (such as setting a VFD to turn off the motor if there is a communication failure) so that the device goes to the safest possible state upon failure of signal or motive power. Of course, any interlocks to controlled devices must be wired fail-safe also. Whenever a smart device offers a diagnostic signal that can indicate trouble or failure, it should be monitored by the supervisory control system to alarm operators and take action as appropriate.
Why wouldn’t a designer take measures to make a system more fail-safe? Perhaps customer requirements or project specifications were not explicit on the subject. Of course, good design entails some more effort, and could increase the cost or complexity to a project. Sometimes adding alarm monitoring points could introduce nuisance alarms that must be handled. Other times, if all of the controls and sensing devices are physically safeguarded within a factory piece of equipment (such as switchgear) with no field wiring, then common practice might ignore fail-safe wiring in favor of simplicity.
Ensuring that the proper field devices and connections are in place is just the first step. My next post will move up the automation food chain to look at best practices for the control platform level.