Managing the DCS upgrade

The right process can take out the guesswork and lead to a successful migration.

By Duane Grob, Optimation February 13, 2014

As distributed control system manufacturers evolved and their products and solutions became less attractive due to their proprietary nature, cost, and most importantly, lack of support and availability, customers began to look for viable replacement strategies. Many “hybrid” DCS platforms and advanced process controllers began to market replacement programs for legacy, monolithic DCS systems in manageable and cost-effective slices.

Today one can choose to replace only the I/O, or only the processors or only the HMI, or combinations of the aforementioned, without full-scale demolition and fabrication of a new system. This may reduce the actual installation timeline and costs of each phase of a DCS upgrade.

Proper planning, definition of project team roles, and testing are vital to take the headache out of a DCS migration project.

Make it more manageable

I/O migrations can be accomplished by providing an upgrade to the I/O structure and devices which would leverage the current I/O termination points, eliminating the need to disturb or rewire the existing field connections. Several manufacturers offer I/O and terminations that are simply a “bolt-on” upgrade and provide backplane or native communications to the original processors. Little or no software changes are needed, and the field wiring and installation requirements are minimal.

Because I/O modules and devices are typically still available from the OEM, and unless there is a shortage or the OEM no longer exists, this upgrade is not critical.

Although replacing the processing units usually is done at the same time as I/O migration, it’s not absolutely necessary. Some manufacturers offer processor upgrades that will still continue to communicate to the original I/O structures, even if those structures are from another manufacturer.

Software services are required for this upgrade, which can vary from automatic control program upgrades (usually requires some manual verification and tweaking) to complete rewrites of the control programs. An experienced systems integrator can determine the proper approach.

A processor upgrade may require an HMI upgrade, as the processor may now have a different communications protocol and naming structure for the tags or control blocks being used at the HMI.

Typical DCS communications are proprietary and serial (such as Modbus), but usually do not cover any recent (past 20 years) protocols like Fieldbus or various Ethernet protocols.

Most plants today are looking for fractional improvements to current systems. From a controls perspective, the DCS does a great job in handling various control loops and other control schemes, but original DCS tools make advanced data mining and manufacturing intelligence unavailable or difficult to obtain and analyze.

The tools best suited for these tasks run on open architectures (like Windows) and require robust connectivity to the SCADA/HMI, I/O services, or databases.

Additional considerations

Most typical DCS installations contain additional controllers, consisting of a variety of PLCs and single loop devices, which currently possess limited or no connectivity to the DCS. This produces an HMI environment that may be blind to some portion of the plant and may require additional HMI products to view those data types.

Some DCS manufacturers no longer exist, or their product line has been discontinued for many years. In these cases, customers have relied on third-party electrical repair houses, surplus and reclaimed electronic stores, or even eBay for replacement parts. Software upgrades are virtually nonexistent and may not be a required purchase, but support of those products is spotty at best.

Most DCS legacy HMI screens are visualized as 2-dimensional vector-based graphics. In today’s world of high definition, realistic animation, and video games, these old HMI systems truly show their age and antiquated level of technology. Although most operators of these systems have grown accustomed to their generally flat colorless interface, far more information can be displayed through new high-definition graphics, increasing operator comprehension without producing information overload.

Establish a plan

As with any of the migration phases, define and develop a true migration plan. Simply developing a request for proposal (RFP) or a cost estimate bid form will not fully identify the scope required, creating the threat of unforeseen costs or risks to both the vendor and system owner.

A common misapplication of the technology is to “copy” or “mimic” the current HMI functionality, without regard to current trends and technology available in most leading HMI/SCADA products. Identifying the requirements as “must haves,” “nice to have,” and “future expectations,” can not only prioritize and define the true scope required for the upgrade, but also lead the owner on a path of discovery as to what his or her current system actually does and what functionality is seldom or never used.

Customers need to document which needs are not currently being met with the existing system’s HMI products. Understand the available new products, their technologies and database structures, to achieve realistic goals and success. Working closely with software product manufacturers and system integrators that have used these products will help define the best methods of development and installation.

Examine the current plant network and evaluate it to be sure that it has enough bandwidth to accommodate an upgraded SCADA system. Antiquated or slow hardware should be replaced. Adequate connectivity is required; therefore, additional switches and routers may need to be added as well as upgraded network wiring in the form of copper or fiber, or perhaps wireless. Investigate possible replacement of serial communications with Ethernet where possible.

Throughout the design lifecycle, seek the input of plant operators and other key personnel who will use the system daily. Exposing the operators to new design concepts early on is vital to having them embrace the system in the end. This gives them ample opportunity to work their ideas into the design and will help them to view the HMI as a reliable and user friendly system, rather than being exposed all at once and potentially rejecting the HMI altogether. Change comes hard, but it is much easier if part of the design process is “owned” by the users.

There are many products which can provide the basic HMI requirements for this migration. Advanced applications and connectivity requirements will reduce that number to a more manageable set. Evaluating the features, connectivity, and possible future needs can lower that number of qualified software manufacturers even more. If the customer already has an installed base of SCADA/HMI products, it may wish to include them only as platform vendors for the migration.

Often customers have a short list of system integrators that they work with for their typical plant needs; however, not all system integrators have experience in HMI migration or with advanced levels of integration and communications needed for this type of project. Careful research with the manufacturer would produce a short list of SIs that can actually bring success to this type of project.

Define team roles

Identify the roles filled by the customer’s team and the system integrator’s team in this venture—it’s crucial to project success. The customer needs to be the subject matter expert in its existing system design and operations. It needs to clearly delineate which tasks are owned in-house and which tasks have to be contracted out.

The SI must understand that the full scope of the HMI upgrade may include more than just replacing legacy HMI consoles with new hardware and software. For instance, if there’s a need to upgrade or replace the network infrastructure currently used, the SI must provide those networking services, which typically requires additional resources other than HMI engineering.

The client may also wish to streamline communications and connectivity to other controllers, like PLCs or single loop controllers. This may change the network architecture and introduce the need for a PLC engineer to add functionality to these controllers. Changes in scope may be inevitable, and therefore a change process must be defined to satisfy the final project requirements.

Test for success

Once the new HMI has been partially developed and installed, test it by comparing the currently functioning DCS screens with the newly installed HMI. This ensures the new system operates exactly as the original and also imparts a sense of confidence to the operators, as they can use both systems simultaneously until testing is complete. It makes the transition from old to new much easier.

It is important to observe the I/O response time in the new HMI. Observe the response for items like pushbuttons (discrete points and handshaking) and screen updates (analog value points). How long does it take from the time a button is pushed until its expected action occurs? How close to real time is an analog value updating on the HMI screen? It should meet or exceed the replaced DCS system’s performance. If it doesn’t, steps must be taken to ensure response time is as per user specification.

Factors that affect I/O response time include network speed/availability, server processor loading and memory usage, as well as code module engine speeds and I/O server scan times. All of these items can be adjusted to achieve desirable results.

Once the systems have been running and tested and the end user is confident that operations can be fully switched over to the new HMI, it’s time to begin to take the DCS system offline, area by area. Sufficient time should be given to each portion of the DCS area that is being decommissioned to allow the end user to acclimate to the new HMI and also to revert if necessary.

We recommend at least one DCS operator station remain functional in case of difficulty, until all system owner personnel are trained and comfortable with the level of support they wish to control. Negotiate further support and maintenance between the integrator and the owner.

Considerations for an HMI upgrade

When defining the goals for the new HMI upgrades, consider:

  • Existing data structures in the controllers
  • Existing screens and consolidation, as current technologies allow for far more real estate and resolution for typical screens
  • Other functions performed by the existing HMI components such as: alarming, visual and audible annunciation, and special algorithms
  • Distribution of the visualization as the cost for distribution is far cheaper now than it was in the past—one reason the control room philosophy was used then. Putting the interface where it serves the best needs of the operator can drastically help with the success of the HMI migration.
  • Documentation needs for the design, testing, and training. Since this is a newly designed system, it’s best to accurately define the documents the customer requires as part of the project.