Control System Migrations

A Practical Project Management Handbook

Daniel Roessler

• Publisher: Momentum Press
• Year: 2013
• ISBN:
  9781606504451
• Topic: Technology & Engineering
• Subtopic: Automation in Engineering
• Index: Technology & Engineering

This new book, by the original developer of the BACnet standards, explains how BACnet's protocols manage all basic building functions in a seamless, integrated way.

BACnet is a data communication protocol for building automation and control systems, developed within ASHRAE in cooperation with ANSI and the ISO. This book explains how BACnet works with all major control systems--including those made by Honeywell, Siemens, and Johnson Controls--to manage everything from heating to ventilation to lighting to fire control and alarm systems.

BACnet is used today throughout the world for commercial and institutional buildings with complex mechanical and electrical systems. Contractors, architects, building systems engineers, and facilities managers must all be cognizant of BACnet and its applications. With a real 'seat at the table, ' you'll find it easier to understand the intent and use of each of the data sharing techniques, controller requirements, and opportunities for interoperability between different manufacturers' controllers and systems.

Highlights include: * A review of the history of BACnet and its essential features, including the object model, data links, network technologies, and BACnet system configurations; * Comprehensive coverage of services including object access, file access, remote device management, and BACnet-2012's new alarm and event capabilities; * Insight into future directions for BACnet, including wireless networking, network security, the use of IPv6, extensions for lifts and escalators, and a new set of BACnet Web Services; * Extensive reference appendices for all objects and services; and * Acronyms and abbreviations

1

---

Migration Project Justification

---

It is a testament to the automation vendors of the 1970s, 1980s, and 1990s that so many legacy control systems from these periods continue to operate industrial facilities today. However, many process control engineers will tell you this is both a blessing and a curse. Because these control systems continue to operate reasonably well, one of the biggest challenges controls engineers face is getting support for control system migrations. Short of failures by the control system that lead to significant downtime, the need for migration projects is often scrutinized and questioned.

When compared with capital expenditures on more tangible and easily understood return-on-investment (ROI) projects, control system migrations are frequently considered lower priorities, which often results in repeated delays to funding them. Understanding the ROI of a project like an equipment debottleneck is straightforward because additional throughput capacity is easily converted to dollars. The ROI on control system migration projects tends to be much less tangible and more difficult to convert to financial benefits that are easily agreed on by key decision-makers.

It is important that someone take ownership of building the case for justifying a control system migration while also establishing realistic expectations within the organization regarding the benefits of replacing the control system with newer technology. This person is often the controls engineer who may or may not be the project manager on the eventual control system migration project. For example, some organizations have a separate project group to manage all capital projects. The project manager, if someone other than the controls engineer, should be identified and involved in the justification process if at all possible. This is the individual who will ultimately be responsible for ensuring that the project delivers on the economics defined in the Authorization for Expenditure (AFE) process.

In this chapter, we examine how to build an effective justification so that your control system migration project will be appealing. We begin by discussing different funding request strategies as well as how to identify and involve key stakeholders that can help support justification efforts. Determining the appropriate timing for your control system migration is also examined. We review how to capture your control system migration project’s ROI and develop supporting business cases and examples. Finally, detailed sections are included, which highlight common areas to consider in your justification process such as parts availability issues and limitations in integrating with third-party systems and applications.

DETERMINING YOUR APPROACH

One of the first steps in the justification process is determining what funding to initially request. There are two options, either request funding for the full project or request funding for a Front End Loading (FEL) study, to better define the scope, schedule, budget, and other project details. Requesting FEL funding is generally a better approach. It requires substantially less initial funds so is often easier to gain approval. Also, a good FEL study details the scope, identifies areas of risk and uncertainty, and generates a tighter estimate with reduced variability. When the subsequent full migration project funding is requested, there is typically much greater certainty in the estimated project cost increasing the confidence of decision-makers and approvers. Even if the migration project is not immediately approved, the FEL documentation is usually largely applicable when the project does move forward requiring minor revisions to account for any updates.

When requesting full funding without having completed a thorough FEL, the budget is much more at risk and typically not more detailed than ±25%. For some organizations, this is an acceptable approach. If this approach is used, be sure to include money for upfront FEL work as part of the overall scope and build this upfront engineering effort into the schedule. This step is crucial to help identify and resolve potential problem areas before project execution begins.

It is essential to include as many key stakeholders as possible in developing the business case for a control system migration project. Identifying parties with a vested interest early in the process and understanding their control system needs not only helps you build a compelling business case but also strengthens support for the project. For instance, visit with the maintenance manager, instrument and electrical (I&E) supervisor, and I&E technicians to understand what challenges they have in maintaining the system. Maybe the team is having trouble with common parts availability on input/output (I/O) cards, controllers, termination panels, or operator consoles? Maybe they have been purchasing updated field instrumentation with expanded diagnostic capability and can’t take full advantage of these newer diagnostics in the older control system? The team will appreciate you seeking their input and will be more supportive of the project if they believe it will help alleviate some of their specific work challenges.

Operations, maintenance, and engineering are the common organizations represented in the utilization and care of most control systems. While not as obvious, there are other groups to include as well. Information Technology (IT) is often involved in getting data out of the control system for other applications. Increasingly, the separation of company IT and control system networks are blurred. While most controls engineers will argue that the process control network (PCN) is a separate entity, at the very least, critical information is transferred across networks daily to support business applications. Talking with the owners and users of various business applications that utilize control system data is also important. They may have difficulty getting the information they need from the control system, may need different formatting or granularity, or have other challenges that can also contribute to the business justification for migrating the control system.

Another factor in the justification process is identifying the proper timing to propose the migration. The timing of when a control system migration should occur is not an exact science. Control system viability is based on balancing a combination of factors such as reliability, total cost of ownership, and system performance to meet defined business objectives. Whenever a given element is out of balance, it can signal that it is time to evaluate whether a migration might be necessary.

Obviously, there are numerous factors in the migration timing consideration process. Each company must make the decision based on the available capital and relative prioritization with other projects. Some companies will take a pro-active approach and continually evaluate the long-term viability of their control systems. Other companies hold on to their existing control systems well past the optimal point and are hesitant to migrate until a specific issue, such as security vulnerability, system failures, etc. forces them to take action. It is important that the decision to migrate your control system is an educated one that is based on a full understanding of not only the financial ROI of a migration project but also those benefits that may be difficult to quantify. Every company should have a control system lifecycle plan that is reviewed and updated at a regular frequency, which will help them evaluate the lifecycle status of their system.

DEFINING ROI

So how do you calculate ROI for a migration project? There is no universally agreed upon answer. Companies use a variety of ways to calculate ROI, rate-of-return analysis, and other financial metrics to determine whether a proposed project meets defined payback thresholds. I won’t tackle ROI calculation methodology details other than to note that it is seldom a single factor that should be used to justify a control system migration project. Instead a combination of additive factors is generally used to build a strong ROI case. There are of course projects that are approved based on factors other than ROI, such as safety and maintenance reliability projects. In these situations, many of the justification cases outlined below will still apply.

For many industrial facilities today, control system migrations are part of a larger vision. For instance, facility siting frequently identifies problematic control room locations. As a result, companies are building new control rooms in alternate locations within the facility and using this opportunity to upgrade their control system. Many companies have also reduced staffing and subsequently consolidate control rooms as part of streamlined operations. In these cases, control rooms are often re-designed and control systems are updated as part of the consolidation process as well.

When there are larger projects, such as these driving control system replacements or modernizations, it can reduce the challenges of the justification process but comes with other pitfalls. In these situations, the control system migration is not the focal point of the project and the scope as well as the budget can get minimized to balance other parts of the project. If scope or budget reductions to the control system migration occur and are substantial they can impact the long-term benefits of the migration. It is also not uncommon to see critical control related design strategies or control system selections being made for financial rather than technical reasons with prioritization given to how it impacts the overall project rather than what is ideal for long-term operations.

What are some effective justifications for standalone control system migration projects? The answer is complex because it is largely dependent on a given facilities specific situation. Some common considerations that contribute to control system migration project justifications are identified in Table 1.1 below.

Table 1.1. Common control system migration project ROI considerations

Issue	Result	ROI Considerations
• System failures	• Decreased reliability • Increased downtime	• Lost production • Unplanned outages • Product schedule and shipment disruptions
• Parts availability or obsolescence issues	• Extended outages (often unplanned) • Lost system functionality • Increased maintenance requirements	• Increased maintenance costs • Lost production • Impact to production quality
• Difficulty integrating with newer applications and systems	• Can’t realize full potential of new applications • Key data not easily available to decision-makers	• Less optimized operational performance • Slower business decisions • Higher costs associated with project implementations and ongoing support
• Reduced availability of support services	• Difficulty troubleshooting maintenance issues • Extended schedules for projects requiring engineering	• Increased maintenance costs • Increased engineering costs • Delays in realizing benefits of projects involving control system configuration
• Operational inefficiency	• Inability to take advantage of current best practices • Operator mistakes contributing to product quality issues and downtime	• Reduced product quality • Increased downtime • Operator stress

As you begin to put together your justification, consider how many of the considerations in Table 1.1 are applicable to your control system migration project. The ROI for your specific project will be unique and may include numerous other issues related to your particular migration. We examine these common issues that drive control system migration projects in more detail throughout the remaining sections of this chapter.

SYSTEM FAILURES

The most straightforward justification for a control system migration is when the system is failing. When your plant shuts down multiple times in a year...