Control Systems / Automation & IT

A Strategic Approach for Upgrading Process Control Systems, Part 3

When migrating an existing control system to a different supplier’s platform, it’s important to “look under the covers.” Part 3 in a three-part series.

By Larry O’Brien and Dick Hill, ARC Advisory Group

ARC recommends you treat a major control system upgrade or migration project as you would any strategic business opportunity. By following the process outlined in this three-part series, you will greatly enhance your project’s successful outcome. (read Part 1 and Part 2)

Once your decision criteria are in place, the rationale for evaluating the supplier approaches should be to look at anticipated performance and reliability. Standard products are best, and this is what many migration products have become. They are designed for purpose, tested and warranted, and can be expected to have the right performance and reliability characteristics. You should be cautious of migration solutions that do not use a standard, productized approach.

The same holds true for the tools used by suppliers to automate procedures such as graphics conversion and control-strategy conversion. Many suppliers treat these as standard products within their own organizations. Several suppliers are just developing these tools, which, in some cases, have not yet reached a level of functional reliability or even full functionality. Migration solutions that depend on third-party components to satisfy intermediate needs, but are not tested and warranted as standard products, would not be expected to have the characteristics of standard products.

Another important consideration when taking the phased approach is the need to support common services; the glue that holds a system together through all migration phases. Common system services refer to system health, common time and so on. At different times throughout the migration, components will be removed and replaced. To maintain the integrity of the system, these components need to embrace common system services natively.

For phased replacement, or when integrating foreign equipment, I/O and hardware selection should be based on the breadth and depth of a particular project requirements and the supplier’s ability to address these. For code conversion, proven tools rank high in the list of selection criteria. The ability to convert program code such as sequence logic is next in rank, followed by block code and graphics and the ability to reconfigure legacy structures into S88 standard structures.

Want to achieve greater insights, better decisions and more intelligent  operations overall. Embrace Industry 4.0!  REGISTER NOW

Request for Information Can Help You Decide

While your team is developing and defining the attributes of your new control system, this is an excellent time to develop a request for information (RFI) document that you can send to all prospective suppliers. Of course, it is advisable for you to narrow the list of suppliers down to a reasonable number prior to sending the RFI. The ARC-developed STAR selection tool  can help in these areas.

In the RFI, you want to ask the supplier questions as to how their solution and services can be applied to meet the requirements you have developed. Migration solution supplier decision is not just a technology replacement decision; but an important business decision as well.

System Capability

Some of the RFI questions should be designed to help you understand how the supplier’s new system is built for the purpose you envision. The following are some of the system capability issues you should consider.

Networking and Connectivity

For networking and connectivity, gateways should be kept to a minimum and proprietary protocols should give way to standard and de facto standard protocols in the target or new system. This should be Ethernet-based at the workstation level and above. Field device and instrumentation communication should support what you have installed and plan to have over the roadmap your team has developed. Obviously it is critical for the system to be able to support all standard buses such as Foundation Fieldbus, Profibus and HART. In addition, you should inquire about the supplier’s ability to support wireless protocols such as ISA100.11a and wirelessHART.

Modern control systems also support connectivity and integration with manufacturing operations management/production management-type applications. Those that adhere to ARC’s Collaborative Process Automation System (CPAS) principles will often do a better job of integrating these applications with the control environment. For systems and applications that are not a part of the control system supplier’s products, it is important for the supplier to support connection protocols such as open platform communication.

Industrial Internet of Things and Other Emerging Capabilities

Whether or not you are planning on extended connectivity via the internet, it would be wise to understand what kind of support your short list of control system suppliers either currently offer or plan to offer to support safe and secure internet connectivity. ARC research indicates that by providing remote connectivity to previously stranded industrial assets and supporting advanced analytics capabilities, the emerging Industrial Internet of Things (IIoT) will provide plant personnel and business managers alike with powerful tools to improve both asset availability and business performance. Greater integration will no doubt be one of the justifications for your investment in a new process control system. Your requirements in this area will surely increase as your business challenges and requirements grow, so it’s important to project ahead.

Standard Control Programming Languages

In the past, each supplier had its own methods for programming its control devices. This was cumbersome and made common organization impossible. In recent years, the IEC released the 1131-3 standard, which standardizes the programming languages. This keeps the implementation consistent, but still enables existing code to be migrated. Most suppliers have an 1131 implementation, but several have not implemented all the languages, so end users should look closely to ensure their needs are met.

Documentation

All control systems have the ability to self-document. The issue now and into the future, is that any site has a variety of automation, with many different systems from different suppliers. Therefore, if at all possible, the documentation facility should cover all systems. Several suppliers have integrated their systems into InTools from Intergraph. This tool can accommodate all the automation and it or an equivalent product should be part of the criteria.

Configuration Management

All system suppliers provide configuration management for their own systems. However, as with documentation, every site has a variety of systems. Therefore, configuration management is also a site-wide issue and should be a part of the criteria.

Risk Assessment

Any final migration decision needs to include risk assessments of the alternatives before users can make their final decision. Prospective suppliers should be able to help answer some of the questions you have to help you assess the risk of deploying their solution.

How Closely Does the Supplier’s System Map to Your New Requirements?

Ultimately, only you can decide if a supplier’s system will satisfy your needs. Start by creating an inventory of critical application functionality not provided by the proposed supplier and ask the supplier to explain how custom-developed or supplementary third-party applications will work with the new system. While you don’t have to make integrating these applications part of your initial scope of work, you do need to know what it will cost you in the future in terms of time, money, and degree of difficulty. Questions to the suppliers associated with how they would implement these items will help you determine the best fit.

Consider How to Preserve Intellectual Assets and Accrued Knowledge

While system hardware and software will become obsolete and dysfunctional over time, much of the intellectual property (control configurations, information management and historical data, advanced process control and optimization, and so on) embedded in the system represents a valuable corporate asset that should be preserved, if possible. When planning a migration to a new control platform, it’s worth investigating if and how these intellectual assets could be transferred to the new system. Make this part of your RFI to the suppliers under consideration.

How Will the System Equipment Be Transitioned?

At the hardware level, chances are that the considerable amount of wiring used to connect legacy system I/O to field devices is still operational and could continue to function for years to come. Users could save a significant amount of money by retaining this existing field wiring when migrating to a new system. While the existing field wiring won’t support the digital fieldbus communications that would be part of a modern process control system in a greenfield installation, moving to fieldbus is not usually practical in brownfield installations. However, for system migrations, users should consider taking advantage of the bidirectional communications capabilities of existing HART field devices to be able to access device status and diagnostics remotely from the new system, since it’s likely that the existing field wiring can support these communications.

But retaining the existing field wiring can also increase risk. Users should ask their prospective migration supplier how they plan to mitigate the risk while balancing the cost. As previously stated, it is always possible to use the “big bang” technique to totally remove the old hardware (including field wiring) and start with new equipment. However, unless a major shutdown is planned in the near future, this could be time consuming considering all the connection points that would have to be made and verified during the changeover.

If the supplier’s approach is to preserve the field wiring, users need to ask, “How do you do this?” Ultimately, the existing control system will be dismantled. The manner in which this is performed can mitigate risk. For example, if users only have from Friday night to Monday morning to perform the switchover, they want to be sure that, if something goes wrong, they could reestablish their old control system for Monday’s start of production.

How Will Graphic Displays Be Transitioned?

When you add up all the time users have put into engineering and refining their current graphic displays, it becomes obvious that this represents valuable knowledge. However, it’s likely that the graphical display capabilities in the new system can open up a new world of possibilities beyond what was possible on the old system. Simply duplicating the old graphics in the new system may increase the comfort level at a startup on Monday, but users should also consider if and how the new system will enable them to convert the existing graphics to take advantage of the new system’s modern architecture. If this conversion process would require too much time and effort, if may make more sense to develop displays on the new platform from scratch.

Can the New Control System Accommodate Advanced Applications?

Most control systems, even those in the “$65 billion of outdated systems” category, have some advanced applications attached to the fundamental control function. Some of these functions are in the form of additional layers of control and some in the form of history gathering software. End users must first assess how important these applications are to the operation of their process units. Determine which ones need to immediately link to the new control platform and which ones can wait. Users should ask the proposed migration supplier how the integration would be performed, now or at some point in the future.

Can You Eliminate Custom Integration?

Since gateways and custom integration make it difficult and more costly to implement and support advanced strategies, users should investigate how their prospective migration supplier integrates to or embeds third-party systems and applications and verify that the applications embedded in the new system actually represent an improvement over those in the existing system.

What Training Does the Supplier Suggest?

Whichever process control system users choose, some training will be required. Users need to determine what formal training is available from the supplier for maintenance staffs, control engineers and application specialists. Also, consider how open the system is for training purposes. Today’s process control systems have a lot of embedded commercial-off-the-shelf IT. Users should ask their migration supplier to what extent they could take advantage of third-party training resources.

What Is Your Path Forward – 10 Years and Beyond?

The supplier’s plans for maintaining the competitive qualities of their systems over time may become important to users in the future.

For example, what is the supplier’s lifecycle support strategy for the new control system? The support policy after withdrawal from sale should be less of an issue with modern systems than with those of the past, since modern systems largely separate applications from hardware. Users should ask their prospective migration supplier for a roadmap that extends 10 years out. This roadmap should clearly indicate how the supplier in-tends to preserve the users’ investments, not just in hardware, but also in the functions users implement today and over the next 10 years.

Can You Provide Successful Migration Project References?

Process automation system suppliers clearly understand the importance of their installed base. All major process control system suppliers focus on retaining their installed base by making sure that they have a path forward from their legacy system to their latest process control technologies. Some have a bigger challenge than others in this respect due to multiple system offerings, largely a result of industry consolidation. Ultimately, all suppliers want to get to an automation platform that is both scalable and “future proof.”

However, the point at which existing users begin to consider migrating to a new platform also represents a point of vulnerability for suppliers. Even if the user is generally satisfied with their existing system supplier, it is likely that they will at least explore migration options from competing suppliers.

From the user’s perspective, when considering migrating an existing control system to a different supplier’s platform, it’s important to “look under the covers.” Users should ask the new prospective supplier for specific references from other users who have performed similar migrations and diligently follow up on these by discussing the implementations with those references. Be sure to ask what they liked and what they didn’t, and learn about potential pitfalls that could be avoided with their own implementation.

And, for that matter, it certainly couldn’t hurt to ask for references from other users, even when considering migrating from one system to another within the same supplier’s lineup.

This is the third in a three-part series on optimizing process control system migration projects. For more information, readers can visit www.arcweb.com.


LObrienLarry O'Brien is vice president of Process Automation at ARC Advisory Group. He has 22 years of experience working in the automation and consulting business with 18 years at ARC Advisory Group. Larry has helped author numerous reports at ARC, including the Collaborative Process Automation System 2.0, Distributed Control System Market Size and Forecast, Control System Migration Survival Manual, and Automation Supplier Provided Services Market Size and Forecast. Larry also served three years as global marketing manager at the Fieldbus Foundation.

 

DHillDick Hill is vice president and general manager of Manufacturing Advisory Services at ARC Advisory Group. He is part of the management team at ARC responsible for developing the strategic direction for ARC products, services, and geographical expansion. Dick has over 35 years of experience in the areas of manufacturing and automation. As a process engineer, he gained experience in oil refinery operations and applications of advanced process control. Later, he expanded this knowledge of manufacturing solutions applied to other process industries. Dick is a graduate of Lowell Technological Institute with a BS in Chemical Engineering. He has completed post graduate courses in network technologies and relational database structures at Northeastern University.