Extend DCS Life with In-Place Replacement

Older digital systems, even though fully depreciated, drain the enterprise cash flow because of high operation and maintenance (O&M) costs. Much of the true O&M cost is not reported because it involves removing spares from inventory that were valued at the purchase price, not at today's higher replacement cost.

By Lawrence Ricci, Hathaway Industrial Automation May 1, 1998


Process control and instrumentation

Distributed control systems (DCSs)

Operator interface

Redundant control

Supervisory control and data acquisition (SCADA)

Sidebars: Southern Nevada Water Authority case history

Older digital systems, even though fully depreciated, drain the enterprise cash flow because of high operation and maintenance (O&M) costs. Much of the true O&M cost is not reported because it involves removing spares from inventory that were valued at the purchase price, not at today’s higher replacement cost.

The rapid obsolescence of first-generation DCSs is a new factor in the cost equation of process plants, possibly suggesting premature retirement of plants whose lifetime could be reasonably extended with minimal investment.

Original DCS designs used the manufacturer’s proprietary data communication, bus voltage levels, and components. Circuit cards were often built with vendor-specific integrated circuits, some of which are no longer produced. Manufacturers often made last-time purchases of specialized components to extend the life of the DCS. Some DCS manufacturers have gone out of the business, or have been purchased and relocated, furthur complicating the procurement of spare parts. The result is a high cost of spare parts and difficulty in locating system diagnostic expertise.

Against this background of aging electronics is an acceleration of technology. Now, a $5,000 PC workstation may be capable of replacing a $60,000 DCS workstation which may require several thousand dollars annually for on-going maintenance. Clearly there is a high payback opportunity to replace first generation DCSs with off-the-shelf technology. The challange is to plan and execute the change-over in a cost effective manner.

Replace within budget

Even when the benefits of replacement are recognized, some companies hesitate because of the perceived difficulty of changing from an old system to a new one. These companies assume an extended project is required, including a comprehensive specification, and a full procurement cycle. They are understandably reluctant to undertake a project for a large, integrated hardware/software system with an extended off site acceptance test, and all the other associated activities, such as training.

A well-structured “replace/in place” program can avoid the problems of replacing everything at once. When properly structured, replace/in place can often be funded within the O&M budget.

Structuring a replace/in place program requires starting with a site survey and review of the current system in operation. The basic rule is, if you don’t have to replace something, don’t. Only the obsolete, high maintenance electronics should be removed. Portions of the system which may be reused include termination racks, some or all of the I/O subsystem, and possibly the CRTs.

Terminations, I/O subsystems

Field wiring is expensive, and if old, can be brittle and difficult to re-wire. Cable designs have been stable for many years. New plug-in connections between the old terminations and the new system may be assembled and installed. Sometimes, I/O circuit cards are reusable. Many suppliers of early DCSs brand-labeled the I/O subsystems. These subsystems may still be available from the original equipment manufacturer or secondary suppliers. If this is the case, new controllers can be connected to the existing I/O subsystem with simple plug-in connections and a suitable I/O driver.

The most difficult replace/in place task usually occurs when redundant controllers are running a complex continuous and sequential process. Unless the control is simple, current technology of PLCs is not recommended for these applications. PLC continuous control algorithms can be difficult to implement and integrate into a comprehensive human machine interface (HMI). Features like tracking, bumpless transfer, and override and constraint control are often not supported. Also, PLCs typically do not support the kind of on-line maintenance and powerfail/restart capabilities provided in a DCS. Two alternatives are available.

One is a change-over of only critical loops to the newer generation of integrated, 3 × 6 or DIN-dimensioned microprocessor controllers such as the ABB MOD30ML, Moore Products 353, or Yokogawa YS170. Since these controllers are primarily for backup or supervisory control, they should be selected based on;

Computer interface capabilities;

Communication speed;

Ability to turn around messages; and

Efficiency of data handling.

These controllers can provide excellent backup integrity for control and HMI.

The other approach is to assemble a plug-compatible, redundant PC-based controller sub-system using off-the-shelf components, usually compact enough to mount in the old cabinets.

Replacing consoles is easy

Often, consoles are the only part of the DCS that need to be replaced; and it may be possible to reuse cabinets and CRTs of the old consoles.

Many DCS manufacturer’s provide interfaces to their proprietary data communications. Using these interfaces and a PC, a new HMI can be added, often for a lower cost than one year’s maintenance of the old console. The re- moved parts can be used as spares for remaining consoles.

Changing the communication hardware and underlying protocols can be difficult, especially with remote sites. When multiple devices share the same communication channel, it is very difficult to change them quickly enough to avoid an interruption in operations. This is most prevalent in SCADA systems where many 30 year-old protocols still support SCADA and energy management systems.

The best way to change communications is to replace individual remotes with dual protocol equipment. The new remote subsystems will continue to report to the old SCADA master or DCS console during changeover. When all dual protocol remotes are fully opertional, switchover to the new protocol can be completed. Using both communication protocols provides a fall-back position.

Select software carefully

Few “shrink-wrap” software packages provide the one-to-one redundancy necessary for process control operations. Fewer can handle the more common one-to-many redundancy schemes popular in many first-generation DCSs. Backup controller data update methods, manual and automatic transfer modes, as well as servicing and replacement modes, must be fully understood. It does no good to have a redundant controller installation that must be powered down to replace a failed device.

When selecting a PC package, the user should carefully develop a list of requirements and not just evaluate software features. Some PC software grew up in the environment of one PC, and one PLC for one machine or subprocess. Requirements for control, HMI, and reliability differ in a process plant, where any console is expected to serve any controller or subprocess.

Failure, repair, maintenance

Most DCSs are designed to fail gracefully, and support maintenance and restoration tasks without interrupting operations. Power recovery routines often have special procedures based on the length of the power interruption. Some PC/PLC packages do not support these features.

No matter what the communication protocol the typical DCS assumption was “any value, on any console, at any time,” all with the same integrity and screen refresh rates. PC packages are also networked, but usually differ in network philosophy. Most PC packages “pass on” selected data to a “higher level” device. In some configurations, this could make the higher level device a supervisory PC, which may introduce a single point of failure and could create substantial (10 to 20 sec.) time lags between some PCs on the network.

When planned and executed carefully, replace/in place strategies can extend the lifetime of a plant, while controlling costs and operational impacts.

For more information, visit www.controleng.com/info

Author Information

Lawrence Ricci is director of power automation for Hathaway Industrial Automation in Baltimore, Md.

Southern Nevada Water Authority case history

Southern Nevada Water Authority (SNWA, Las Vegas, Nev.) was facing increasing demands for potable water, with an aging DCS/SCADA system. Anticipating increased water demands through at least the year 2016, a multiyear program was launched to replace the existing system. SNWA retained Westin Engineering (Dallas, Tex.) to develop the project specifications.

The initial system included 32 RTUs with approximately 10,000 I/O points, and 16 workstations. SNWA specified an open architecture using fiber-optic Ethernet networks for in-plant RTUs, and micro-wave communications to remote RTUs. Maintenance costs were taken into consideration by specifying that all nodes be software maintainable from the central location.

Reliability was addressed by requiring redundancy for all critical RTU nodes and new communication paths. “Next heartbeat” switchover requirements were also included in the specification.

SNWA and Westin selected the TIS4000 system from Hathaway Industrial Automation (Baltimore, Md.). SNWA and Westin developed the control strategies and graphics, and the system was staged at Hathaway’s site. The old system was phased out of service and the new system gradually assumed control of the plant where it has been the sole control system since August 1997.

Related Resources