Managing the DCS upgrade


Establish a plan

System integrators also need to know the capabilities of both the hardware and soft-ware ends of the system in order to deliver the most effective upgrade. Courtesy: OptimationAs 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.

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

click me