article_006_tnail

Best practices in control system migration

Jan. 5, 2007
Migration from your old control system to a new one is as an inevitable as death and taxes. But, the key to minimizing the pain is to abide by the control system migration best practices listed here.
By Dan Hebert, PE, Senior Technical Editor

Migration from your old control system to a new one is as inevitable as death and taxes. But unlike dying and paying taxes, you will be better off after a control system migration than before. That’s the good news.

The bad news is that the migration can sometimes be just as painful as paying taxes, if always a little better than death. The key to minimizing the pain is to abide by control system migration best practices. Here, culled from recent interviews with a host of our readers—your peers—is the roadmap for the minimal-pain upgrade.

When to Migrate
The most important control system migration best practice is knowing when to jettison the old in favor of the new. Lack of spare parts for the old control system’s hardware is the leading reason for replacement. In essence, the vendor has made your system obsolete by its decision to discontinue support.

    

WHEN TO MIGRATE

  1. Don’t upgrade until obsolescence threatens
  2. Don’t install soon-to-be obsolete hardware on new processes

“We often replace non-standard proprietary controller for various clients,” reports Bob O’Brien, principal engineer at CSIA member Concept Systems “Such controllers are prone to becoming obsolete, making service very costly and replacement parts hard or impossible to get.”

One end user justified migration based on pending obsolescence. “Our main justification for the migration was concern about the reliability of our Honeywell TDC 2000 system due to its age and spare parts availability,” says Jaime Salom, CSEE and principal instrument engineer at Lyondell Chemical Company (Houston, Texas). “Our data showed some occurring failures that weren’t impacting control, but indicated that reliability in the future might become a problem.”

FIGURE 1: TIME FOR A CHANGE     

Non-standard proprietary controllers such as the one shown at the upper left of the panel are prone to obsolescence, making service very costly and replacement parts hard or impossible to get.
Image courtesy of Concept Systems



 

Even when an old control system remains supportable, there can be good reasons for replacement. “Our migration project was undertaken in conjunction with a plant expansion,” reports an anonymous end user at a Midwestern petrochemical company. “The existing control system is still supported, but we did not want to install obsolete technology on new process units.” 

Obsolescence does not happen on a specific date, but rather is a gradual process that starts with a vendor discontinuing support. Spare parts then become harder to procure and more expensive. At some point, spares become too expensive or too hard to find, obsolescence becomes inevitable and migration must occur.

Once the decision has been made to migrate, the first task is deciding on a partner. Options range from a vendor to a system integrator to an engineering firm. In each case, quality of service should be the deciding factor.

Service is Key
One end user and system integrator after another reiterated the same point: All the major vendors make good hardware and software. No one should make a decision about vendors based on claims about hardward and sofware perforamnce, because all the stuff is pretty good.  

The big differences arise when it comes to service, and you will require lots of service and personal attention from vendors before, during and after a control systems migration. “Our experience with migrations has been mixed,” reports Mark Hall, the IS and applications engineering manager at leading refiner Hess Corporation (New York).

“The technology offerings are all solid and perform reasonably well, but support has been marginal at best. There is a core team of experts at the vendor that are very well-versed on the technology and implementation strategies, but the level of expertise falls off quickly from this point,” concludes Hall.

Another end user voices concerns with vendor service. “Vendor support has a way to go yet. Smaller local service firms offer more bang for the buck than the factory-trained guys with the OEM logo on their hats,” says Patrick Loupin, a technology resources manager at papermaker Boise Cascade (Boise, Idaho).

The contrast between vendors with respect to service is stark, “Exceptional coordination and planning by Yokogawa made for a well-executed migration plan,” claims Jim Peppers, an instrumentation process engineer at the chemical manufacturer Hexcel Corporation (Stamford, Conn.). “As different processes in the plant were starting up, Yokogawa provided application engineering support around the clock,” adds Peppers.

    

How to Pick the Right Partner

  1. Vendor hardware/software is comparable and good, so judge vendors by their service
  2. Find a local system integrator that understands all facets of your project
  3. Don’t count on a vendor to know anything about another vendor’s products

Lyondell was also happy with the migration services it received. “We relied on Honeywell’s experts to get us through a few rough spots, and they did an outstanding job with engineering and technical support,” reports Salom at Lyondell.

Service is a critical factor in a successful migration, and it should be the single most important vendor evaluation item. While vendor service experiences were mixed, end users were much more satisfied with services received from system integrators.

“We developed a partnership with CQS Innovation, a local systems integrator that was the key to our migration project’s success,” reports Robert Burgman, a senior automation engineer at ink manufacturer Sun Chemical (Parsippany, N.J.).

“We avoided the potentially confrontational owner/contractor arrangement, and this was a significant factor in continued support. There’s a lot more to support and continued process optimization than a modem or VPN connection,” he adds.

In an ideal world, your company would partner with a local independent systems integrator with intimate knowledge of your existing control system and extensive knowledge concerning current control system offerings from various vendors. Failing that, you must make sure that your selected migration partner can provide good service.

FIGURE 2: BEFORE AND AFTER

These two photos show how ugly an old system can get and how clean a new system can be. Like an ad for the latest diet fad, it is not hard to guess which are the before and after photos.
Images courtesy of Concept Systems.

Plan, Plan and Plan Some More
As with any large, complex project, planning is key to success. “The most important part of a migration project is the process definition and functional specification documents defined at the beginning of the project,” says Burgman of Sun Chemical.

Another end user seconds Burgman’s comments. “Everything takes longer than expected when detailed planning is not completed prior to beginning the project,” according to Dave Goodman, project manager at Cambrex Pharma (East Rutherford, N.J.). “Do the homework, plan the change, identify the critical timeline, have the daily meeting, involve those that will be affected by the change, identify all the resources and have additional resources from system integrators to vendor staff ready if needed. You must have a contingency plan. Remember, people do not remember when things go right; they remember the pain when things go wrong,” adds Goodman.

    

How to Plan the Migration
  1. Plan up front
    to avoid problems later
  2. Involve operators,
    IT and maintenance early
  3. Budget for contingencies
  4. Budget for full-time
    project management

Salom of Lyondell emphasizes that contingencies must be built into the schedule to doeal with unforeseen circumstances. “It’s easy to be overly confident that everything will go as planned, but it usually doesn’t. We had a tight schedule with no float, and a big chunk of this upgrade happened during Hurricanes Katrina and Rita. It became very difficult to find and keep construction people because many had to help restart other facilities.”

How to Migrate
Perhaps the leading best practice cited was reuse of existing field wiring to the greatest extent possible. System integrator FeedForward always tries to minimize or eliminate re-termination of field I/O. This cuts project costs by reducing field labor and required electrical design drawings. “We find that most vendors offer connection to legacy I/O structures, and some vendors offer cable connection to other vendors’ legacy equipment,” reports Phil Murray, principal at FeedForward.

Tokyo-based Konica Minolta migrated from an old to a new Yokogawa control system and reports that Yokogawa designed new I/O cards that were compatible with the old signal conditioning cards. “It was not necessary to rewire the I/O. We just had to disconnect the cables and plug into the new I/O. This was a huge downtime saver,” reports Wayne Yancey, system engineer at Konica Minolta.

Another important best practice is to not be a guinea pig with brand new software, even a revision. “Simple upgrades within a platform are generally easy to perform, provided you aren’t one of the early adopters,” says Hunter Vegas, PE, an engineer at CSIA member and system integrator Avid Solutions. “For instance, going from DeltaV 6.0 to 7.0 wasn’t a big deal AFTER Emerson worked the bugs out of the conversion prgrams and figured out the procdedure. We often counsel our clients to let other people suffer through that initial learning process before upgrading,” adds Vegas.

    

How to Execute the Migration

  1. Reuse existing field wiring and I/O to the greatest extent possible
  2. Don’t be the guinea pig with brand new software, even a revision
  3. Rewrite the application software for the best possible new control system
  4. Use utilities that convert software from older to newer control systems with care
  5. Migrate in phases
  6. Simulate to reduce downtime

Of course, someone has to be first to adopt new software, and it may be you. A fair trade-off would be to get the vendor to provide free on-site support in consideration for use of your process automation system as a beta site. The key is to do your homework going in, so that you know if the new software is proven and stable.

Stable and bug-free vendor software is crucial, and so is the application software that will control and monitor the system. Making the right decision with respect to your application software is vital.

Reuse Your Existing Software?
Your existing control system has been controlling your processes for years, maybe decades. There are many lines of code, multiple HMI screens and a plethora of miscellaneous software programs. Some of the vendors claim to have conversion programs that will automatically convert existing software to run on your new system. But is this a good idea?

“I definitely owe the job’s success to the decision to throw out all of the old code and start from scratch with a competent integrator that had a broad background of S88 batch experience with both PLC/HMI and hybrid DCS platforms,” says Burgman of Sun Chemical.

“I could have had all of the control-module and equipment-mode code imported into the new system, and at first glance this seemed like an excellent way to save on programming costs. But this would have meant importing all the old mistakes, band-aid work-arounds and abandoned code of the old system. We also would have not been able to use current practice programming techniques with features like libraries for S88-phase and equipment-module logic,” concludes Burgman.

A system integrator had success using a third-party utility to convert code. “On a job for International Paper/Cantonment, the existing Allen-Bradley PLC3 had thousands of lines of code,” says Murray of FeedForward. “Instead of interpreting and manually recoding, we used software from Javelin Technologies to automatically convert the PLC3 code to ControlLogix. We tested representative points and found the conversion to be accurate.”

Migrate in Phases
Breaking a large migration project into smaller and more manageable phases reduces risk and downtime. “Our migration had to be completed with minimum downtime, so we used the phased replacement approach. The first phase targeted the operator stations, the second phase replaced the controllers and I/O, and the third phase was a combination of the first two phases in a different process area,” reports Yancey of Konica Minolta.

A system integrator relates its approach to phased migration. “For a large-scale retrofit, it’s best to use a phased approach,” claims Jim Zelazny, automation systems manager at systems integrator Integrated Mill Systems. “Phased migration eliminates risk by narrowing the focus incrementally while providing a fall-back to the old system. This approach requires communication with the existing system for interim phase-in, physical coexistence with the old equipment to avoid burning bridges, and the ability to switch quickly and easily between old and new signals for testing/tuning purposes. We leveraged the high bandwidth of GE Fanuc’s Control Memory Xchange to bridge to the old system. This and innovative techniques to quickly switch hard-wired signals, made it possible to successfully migrate without interrupting production,” concludes Zelazny.

Phased migration does have its drawbacks. “We did our Yokogawa migration in three phases and stretched it over a four-year period,” says Peppers of Hexcel. “After completing the detailed scope for the final phase, a cost comparison study was made. The three-part plan was great for lowering the annual capital required and the magnitude of the tasks, but I would have preferred one all-inclusive project plan. The three phases turned out to be three individual projects for Hexcel. Because of the extended time frame involved and other things, such as administrative/startup costs, scope increases, inflation, taxes, labor and loss of single-project efficiencies, a significant overall cost increase was realized.”

Phased migration will cost more and take more time, but it is a lower-risk approach with less downtime. Further risk and downtime reduction can be achieved by simulating the new system prior to installation.