Comment

1 December 2005

Migration path

Systems often age, but some assets have a longer life span.

By Ken Keiser and Todd R. Stauffer

The word has come down. The decision to migrate from one system to another has occurred, and a team of automation professionals researched and understand the advantages of migrating versus not migrating.

Migration is a huge issue throughout the industry these days as users confront the true life cycle of their installed control systems. Around $65 billion of legacy process control systems have reached the end of their reasonable life cycle, according to one survey. The automation industry has undergone massive consolidation of 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 span of human machine interfaces (HMIs) and workstations is now five years. Migration to newer technology presents challenges to the user and to the supplier.

Part of the effort at extending the life of existing DCS systems, include:

• HMI Connectivity—providing 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—providing 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—to automatically convert existing process graphics, controller code, or batch recipes to newer systems, allowing reuse of valuable application code.
• Control Network Gateways—for allowing peer-to-peer communication between legacy controllers and new controllers.
• I/O Gateways—connects new I/O technology to existing controllers.
• I/O Replacement—installs new I/O modules into existing controller I/O slots. Uses older rack with new I/O technologies.
• I/O Interfaces—enables an existing I/O subsystem (field devices, racks, terminations, and I/O modules) 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).

At the end of the day, you want to look at common scenarios for DCS migration to see how the capabilities described above can help users maximize the value of their existing assets, and minimize the cost of change, while providing the flexibility to migrate in a stepwise, incremental fashion.

Back to basics

A typical DCS can migrate to a newer system in a stepwise approach. There are certain points in a system where a new piece can fit naturally. A user can upgrade the system above or below any of these points.

A user can upgrade the controller located between P2 and P3 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. Each part has a different life cycle profile. When a new system hits the market, each part will eventually have more functions, features, and benefits than the previous system's parts. 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 stay in place at the same time as the user replaces other assets with newer technology.

A user needs to understand the life span of assets, and, in addition, 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 go away, and there is no need to maximize the return on any individual asset.

A typical system (X) with various parts, such as HMI, controller, I/O and terminations. The difference between the X system and the Y system in the HMI area shows the technology gap.

In most cases, a stepwise or phased approach is preferable to a total system migration, as each asset will most likely become obsolete within a different timeframe.

The first focus of executing a phased migration must be the asset with the shortest life span in the system. This is the asset that 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.

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. The preferred strategy in this case would have the new HMI client automatically gather the information needed from the existing system. No engineering required. The migration occurs 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.

Migration tools

The quality of the tool will determine if a user can retain any asset, thereby extending its useful life.

In order to measure the potential returns, the user will need to determine the total cost of ownership (TCO = Procurement Costs + Operating Costs).

Whether the migration occurs with the incumbent supplier or a third party's offering, comparing the TCO of the migration solutions will be a key factor.

The procurement cost component of the TCO does not end with the cost of the equipment. It also includes the cost of the design, configuration, and startup. The original vendor may not have the migration 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.

Standard tools can be less costly to procure and use than custom solutions or manual data manipulation. Also, engineering costs are lower when you use standard products. 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, you can cut operating costs on the migration methods and 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 solutions include migration tools. You can define products as those software or hardware items available to the end user and included in the vendor's catalog. They see use on an ongoing basis to aid in the migration. A product gets full support from the vendor's help desk and technical support.

A migration tool is a software or hardware device that helps in the migration effort and sees use once. Often, a vendor doing the migration uses it internally and is not usually available to the end user.

Tools of the trade

The following are standard migration solutions, their features and benefits, and typical scenarios where they see use:

1: HMI connectivity—provides a method where a new HMI can communicate with the existing controllers on a continuous basis. Existing intellectual assets copy from the existing HMI and then they go into the new HMI. This connectivity will include the ability to emulate older HMI elements (such as faceplates) so an operator would feel comfortable using the new HMI. As a continuously running application, if there is a change in the controller, this will implement a change at the HMI automatically. The older HMI may or may not need to go and a user can use it, if need be, at the same time as the newer system giving continuity to the operators during a transition phase.

2: HMI conversion tool—moves the graphics and other configuration from the old HMI to the new HMI. Historical data from the existing HMI can also move to the new HMI's historian. This tool, used only once, will move data and assist in the HMI migration. The assumption of using this tool is the old graphics and configuration are worth moving.

3: Enhanced batch management—similar to HMI connectivity, 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 S88 structures, this transfers the configuration from that system to the newer system, preserving the batch intellectual property of the plant. The key point is you can save the intellectual investment (S88 structures), while at the same time, a state of the art batch management system can view and manipulate the older structure.

4: Engineering 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.

5: Controller application conversion—converts existing process configuration, 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 you find a method to access this data, it can be an easy procedure to move the data from one controller to another.

6: Controller network gateway—provides peer-to-peer communication between legacy controllers and new controllers. This 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 gone to the scrap yard.

7: I/O Gateway—allows new I/O modules to connect to legacy controllers. In cases were the legacy system has the ability to connect to Fieldbus technology, this tool allows for new I/O module installation as local or remote I/O modules. The gateway usually comes from the incumbent vendor and the incumbent controller remains to control the process.

8: I/O replacement—allows the user to retain the termination and existing I/O rack. 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 new vendor takes responsibility for the old rack where they mount the new module.

9: I/O interface—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 comes out, but you can potentially save the intellectual investment of the controller by using other migration solutions. This tool saves considerable rewiring costs.

10: Field termination assemblies (FTAs)—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 you don't need additional cabinet space) and uses the existing connectors of the field wiring so you don't need to rewire, which will save labor costs.

Each component of a system has different life spans and life cycle profiles. Each part can migrate 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.

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

Behind the byline

Ken Keiser is a migration marketing specialist and Todd R. Stauffer is manager of product marketing at Siemens AG, Spring House, Penn.