Print this article

Comment

1 June 2006

What's Your Legacy?

By Richard Consoli, Ken Keiser, and Todd Stauffer

Maximize existing asset value and migrate in a stepwise, incremental fashion

Migration is an important topic in today's industrial marketplace as users confront the life cycle management of their installed control systems.

Sixty-five billion dollars of legacy process-control systems have reached the end of their reasonable life cycle. The process automation industry has undergone massive consolidation of both end users and suppliers and has seen significant changes in the life span for distributed control systems (DCS) components spurred by rapidly changing technology.

While the expected life span for input/output (I/O) and wiring is 25 years or more, the life spans for human machine interfaces (HMIs) and workstations are now about five years.

Migration to newer technology presents many challenges to the user and to the supplier.

First, let's assume the decision to migrate from one system to another has already taken place and everyone concerned understands and has researched the advantages of migrating versus not migrating.

Look at the various generic types of products, tools, and services available to help users to extend the life of their existing DCS systems.

• HMI connectivity provides communication channels and HMI elements (such as faceplates) for communication to legacy system controllers via new HMI technology.
• HMI conversion: tool for translating graphics from a legacy HMI to a newer HMI.
• Enhanced batch management provides connectivity for a new Batch Manager to interface directly to an existing controller's phase and recipe sequence logic.
• Engineering library: function blocks, faceplates, and dynamic HMI elements providing equivalent functionality to the existing system, available for use within a new engineering environment.
• Application conversion automatically converts existing process graphics, controller code, or batch recipes to newer systems, allowing reuse of valuable application code.
• Control network gateways allow peer-to-peer communication between legacy controllers and new controllers.
• I/O gateways connect new I/O technology to existing controllers.
• I/O replacement: Install new I/O modules into existing controller I/O slots. Uses older rack with new I/O technologies.
• I/O interfaces enable an existing I/O subsystem (field devices, racks, terminations, and I/O modules) to be controlled by a new controller.
• Field termination assemblies (FTAs) preserve existing wiring by providing a 1:1 replacement of existing terminations and connection to new I/O modules via a new FTA (with same form/fit and function).

Also, we look at the most common scenarios for DCS migration to see how the generic capabilities described above can be employed to help users maximize the value of their existing assets (such as hardware, application engineering, and process know how) and minimize the cost of change, while providing the flexibility to migrate in a stepwise, incremental fashion. We'll profile some common migration scenarios too.

Migration indispensables

A typical DCS can be migrated to a newer system in a stepwise approach. There are certain points in a system where a new piece can fit naturally. The system can upgrade above or below any of these points. For example, the controller, which is located between I/O and the HMI server, can upgrade without touching any of the other pieces of the system.

In any system, there are pieces that have different life cycle curves and life spans. In a system with the various entities like an HMI, controller, and the like, each part has a different life cycle profile. When a new system debuts, each part will eventually have more functions, features, and benefits than the systems previous parts. Refer to this difference as a technology gap.

The technology gap could occur at different times for different pieces of the system. To maximize the life of existing assets, a stepwise or phased approach to migration is necessary where some older assets remain in place at the same time as other assets are swapping out for newer technology.

Further the life span of these asset classes (HMI, controller, I/O, terminations) are different. Of course, the assets' prices differ as well. Some of these values include both hardware and intellectual property, such as the controller or HMI server. Others, such as the HMI client or terminations, are exclusively hardware assets.

There are two options in any migration of a particular asset: Use the same vendor as the existing asset, or use a different vendor. Additionally, there is an option to migrate part of the system or the total system.

In a total migration, the existing assets all go away, and there is no opportunity to maximize the return on any individual asset.

In most cases, however, a stepwise or phased approach is preferable to a total system migration, as each asset becomes obsolete at a different time.

The first focus of executing a phased migration must be the asset with the shortest life span in the system. This asset will become obsolete first and is prone to the first failures. Second, look at the asset with the lower value. This asset tends to be simpler to upgrade and realize a return on that investment. Third, use migration products or tools to maximize the return on existing assets. The migration product or tool itself is the key to a successful project.

Practically, one might look at one's DCS and see the shortest life span is that of the HMI client. The HMI client is typically a PC running a commercial off-the-shelf operating system like Windows XP on an Intel platform. The client PC is also the smallest asset in terms of value compared to the server, and one of the simplest to migrate. The optimal migration solution would be one that has a comparatively low cost and is easiest to implement. For example, the preferred strategy in this case would have the new HMI client automatically gather the information needed from the existing system. No engineering would be required. The migration can happen without user intervention. If the migration included the client and the server, the migration effort may need some human interaction and would be more complex, but not necessarily more difficult to implement.

Cost of migrating

Migration strategies will vary from vendor to vendor. The incumbent vendor may have the best migration product or tool for the migrated asset. Sometimes a different vendor may have the best option. It is the quality of the product or tool that determines if any asset can stay, thereby extending its useful life.

In order to measure the potential returns, one must calculate the total cost of ownership (TCO).

TCO = Procurement + Operating Costs

Whether the migration is implemented with the incumbent DCS vendor's newest offering or a third party DCS vendor's newest offering, comparing the TCO of the migration solutions will be a key factor in selecting a vendor.

The procurement cost component of the TCO is not limited to the cost of the equipment. It also includes the cost of the design, configuration, and startup. The original vendor may not have the migration products or tools necessary to upgrade their older system to a newer system, or the solution may be custom and awkward to use, requiring higher engineering costs to implement than a competing vendor does.

Standard products or tools can be less costly to procure and use than custom solutions or manual data manipulation. Engineering costs are also lower when standard products are used. In addition, the vendor with standard products can also re-use these at other sites and even on other vendor's equipment within the plant.

In addition to procurement and engineering costs, operating costs can be less depending on the migration methods and product or tools the vendor uses. If a migration product includes the ability to put faceplates on the new system that have the same look and feel of the incumbent system's faceplates, the operators will be more likely to adopt the new system quickly and with less of a learning curve.

When using a standard migration product (as opposed to a custom solution), there will be better support from the vendor, more knowledgeable troubleshooting help from technical support, better documentation, more robust testing before it is released, larger user base for feedback, and a more knowledgeable field service group. These benefits result in a lower TCO of the migration effort.

Migration tools and scenarios

Migration solutions include migration products and tools. Products are software or hardware items available to the end user and are included in the vendor's

catalog. They serve on an ongoing basis to aid in the migration. A product gets full support from the vendor's help desk as well as technical support.

A migration tool is a software or hardware device that helps in the migration effort but works only once. The vendor doing the migration often uses it internally and is not usually available to the end user.

Here are standard migration solutions, their features and benefits, and typical scenarios where they are used.

• HMI connectivity product: This product provides a method where a new HMI can communicate with the existing controllers on a continuous basis. Existing intellectual assets (software configuration like graphics, faceplates, trend configuration) copy from the older existing HMI and implemented in the new HMI. This product includes the ability to emulate older HMI elements (such as faceplates) so an operator feels comfortable using the new HMI. As a continuously running application, if there is a change in the controller, this product will implement this change at the HMI automatically. The older HMI may or may not need to uninstall and can work simultaneously with the new system giving continuity to the operators during a transition phase.
• HMI conversion tool: This tool moves the graphics and other configuration from the old HMI to the new HMI. Historical data from the existing HMI can also copy to the new HMI's historian. This tool moves data and assists in the HMI migration, and that ends its service. The assumption of using this tool is the old graphics and configuration are worth moving.
• Enhanced batch management: This product is similar to the HMI connectivity product, with the exception that it provides connectivity for a new Batch Manager to interface directly to an existing controller's phase and recipe sequence logic. Assuming the existing system has ISA-88 structures, this product transfers the configuration from that system to the newer system, preserving the batch intellectual property of the plant. The key point of this product is the intellectual investment (ISA-88 structures) can endure, while at the same time, a state of the art batch management system can work to view and manipulate the older structure.
• Engineering library: The library resides in the engineering tool of the new controller and includes function blocks, structured text, and other control languages that emulate the languages of the existing controller library. Since the new library uses similar function blocks as the old library, an engineer can use these familiar blocks in the new controller without the need for new training. The engineer has the option to recreate the old control scheme or utilize the newer technology of the new controller and create a new control scheme using familiar function blocks.
• Controller application conversion: This tool converts existing process configuration (the function blocks as well as the links between them, and other IEC 1131 languages), allowing reuse of valuable application code. This one tool will preserve the years of intellectual investment made by plant personnel to improve the DCS. While each controller is proprietary to each vendor, the basic organization of the data in most vendors' controllers is very similar. Once a method surfaces to access this data, it can be an easy procedure to move the data from one controller to another.
• Controller network gateway: This provides peer-to-peer communication between legacy controllers and new controllers. It allows the existing system to be online at the same time as the new system for a phased, stepwise approach to the migration process. The older controllers may be viable for years after the original HMI that connected to them has moved on.
• I/O gateway: The gateway or specialized I/O module allows new I/O modules to be connected to legacy controllers. In cases where the legacy system has the ability to connect to Fieldbus technology, this tool allows for new I/O modules to be installed either as local or remote I/O modules. The incumbent vendor usually provides the gateway, and the incumbent controller remains to control the process.
• I/O replacement: This product allows for the termination and existing I/O rack to remain. The replacement I/O is part of the new vendor's offering so field signals bypass the incumbent's controller and move directly to the new vendor's controller. The incumbent's controller goes away. The new vendor takes responsibility for the old rack in which the new module is mounted.
• I/O interface: This product enables the new controller to use an existing I/O subsystem (field devices, racks, terminations, and I/O modules). The existing I/O stays in place, and the new controller interfaces with the old I/O. The old controller goes away, but the intellectual investment in the controller can potentially stay by using other migration solutions. This tool saves considerable rewiring costs.
• Field termination assemblies (FTAs): This hardware solution preserves existing wiring by providing a 1:1 replacement of existing terminations and connection to new I/O modules via a new FTA (with same form/fit and function). This product is, ideally, the same size as the original terminations (so additional cabinet space is not required) and uses the existing connectors of the field wiring so no rewiring is necessary, saving considerable labor costs.

Therefore, while each component of a system has different life spans and life cycle profiles, each part can be migrated separately or with another at the same time or in a phased approach.

The quality of the migration solution determines how much of the existing assets can be saved and is the key to successfully maximizing the return on existing assets.

There is an advantage to using a vendor with standard off-the-shelf migration products rather than using a vendor (incumbent or not) that uses custom applications, which tend to raise the total cost of ownership.

By minimizing TCO, a user can migrate to newer technology and at the same time maximize returns on the existing assets.

ABOUT THE AUTHORS

Richard Consoli has an electrical engineering degree and is the president of Innovative Controls a systems integration company in Tennessee. His e-mail is rconsoli@innovativecontrols.com. Ken Keiser and Todd Stauffer work for Siemens AG in Pennsylvania as migration specialist and manager. Their e-mails are ken.keiser@siemens.com and todd.stauffer@siemens.com.