Migrating legacy PLC programs to modern PLC hardware

Zero downtime is a requirement for many water/wastewater processes, often necessitating upgrading legacy automation by migrating existing code

By Raju Nair December 12, 2020

Impacted by shrinking municipal budgets, many water/wastewater plants and facilities operate frugally, often running on systems plagued with obsolete hardware and software and patched with years of Band-Aid fixes to remain functional. These patches are not always recorded properly when they are made, and over time, the initially accurate documentation about a facility’s control system can become scarce or unreliable, making it difficult to troubleshoot or upgrade the system when necessary.

A brief history of PLC programming

Looking at the history of programmable logic controllers (PLCs) often used in these facilities, the intent for these devices was to create an industrialized controller to replace electromechanical relay logic (see Figure 1). The world of the electrician/technician was transitioning into the world of the computer programmer. Even as this occurred, electricians maintained a strong influence on PLCs, which were destined to stay in their domain.

Electricians wanted a visual representation of the hardwired logic, and many decisions associated with PLC coding methodologies were impacted by this desire. However, PLC coding means and methods were not standardized among manufacturers, making PLC automation upgrades difficult.

Existing functional code may not be well defined and is never directly portable into new or different systems, which can drive up the risk and cost of migrations. This article examines some ways to migrate legacy PLC programs into more modern platforms.

Challenges of aging systems

PLC coding practices have evolved throughout the years with the development of the IEC 61131 standards for PLC languages. Address-based programming evolved into tag-based programming. Tag-based programming evolved into smarter structures such as user-defined data and program blocks. Newer coding methodologies eased scalability and consistency in coding efforts. Smarter coding practices accounted for handling each instrument or process element uniformly from the standpoint of controls, interlocks and alarms.

Maintaining, let alone specifying, PLC programming standards poses challenges. For many end users, PLCs are mysterious boxes that run so well they may not even have the latest backup programs stored in their possession, or the ability to upload, download or troubleshoot the code.

This means when the need does arise to understand how the automation system functions, technicians must often dive through undocumented program code and out-of-date drawings. In many cases, they must rely on dogeared printouts of the original code, along with dated drawings, to reverse engineer the actual control strategies.

As the system ages, the facility’s system patches may not be enough to maintain a functional process or the fragile status quo any longer. Automation technology continues improving and technical support and aftermarket parts for obsolete hardware and software can come to an end. Facilities need to bring their systems up to speed with the latest technology to avoid problems.

Programming creativity leads to lack of consistency

While many automation industries maintain strict policies around modifying PLC programs, the water/wastewater industry has been less stringent. For example, amusement parks and pharmaceutical companies uphold a strong safety focus with standardized programming practices and extensive change management requirements, including documentation, audits and reports.

In contrast, the water/wastewater industry is more lenient in its programming standards, which has allowed programmers the freedom to develop individualistic styles and programming methods, often lacking consistent methodologies. This freedom has led to a wide variety of differing and even conflicting approaches to PLC program development.

Planning a migration

By extension of this freedom, there are no standard methods or requirements for upgrading water/wastewater systems to new technology. When water/wastewater plant personnel decide to upgrade, they must carefully research and evaluate their existing system assets to understand how their process functions both hydro-mechanically and programmatically before taking actionable steps. This involves reviewing the details of the process itself, the peer-to-peer network relationships associated with data transfer and the process controls and interlocks associated with the equipment (see Figure 2).

There are three main approaches to address legacy PLC control systems:

  1. Keep the legacy system as is without any changes.
  2. Rewrite new code from scratch in the new hardware and software platform.
  3. Migrate existing legacy code into the new hardware and software platform.

First, though not advised, keeping a legacy system as-is may retain a system’s existing functionality, but it leaves the system vulnerable to obsolescence and operational issues. Some users scour eBay and stockpile spare equipment parts as a stopgap measure, but this type of approach can’t work indefinitely.

Second, rewriting new code from scratch provides an opportunity to break away from the old patches and introduce modern coding philosophies. This is a clean slate approach to upgrading a system. However, the cost and risks associated with this approach can be extensive. Crucial existing functionality may not be fully understood, or can be unintentionally altered or even missed, and cutover tends to be a disruptive period.

Third, migrating existing legacy code into new hardware and software preserves a system’s complex control strategies. Maintaining the operational functionality reduces downtime during cutover because more effort can be placed on upgrading the system hardware and software platforms as the existing functional PLC code remains intact. Although new and consistent programming standards can’t be fully applied using this approach, the overall functionality remains as close to original as possible, and the program can be improved to some extent.

Specialized tools ease upgrades

Many major PLC manufacturers offer hardware and software migration tools for facilitating the upgrade from legacy to modern PLC systems. While these may not represent a perfect plug-and-play approach, they go a long way toward minimizing risk, effort and cutover time.

Hardware tools include wiring harnesses, which are installed on top of existing legacy wiring terminals, to provide a mounting interface for newer modern terminals. These modern terminals can be wired to the legacy terminals to tie existing field wiring into the new hardware while keeping the existing field terminations intact (see Figure 3).

A careful design will ensure retrofit work can be performed in the space available. Sometimes more extensive remove-and-replace work is needed, and in these cases the ability to assemble preconfigured hardware fabricated in a shop will speed site installations (see Figure 4).

Software conversion tools take legacy PLC code and upgrade it to a format compatible with modern PLC programming software. These software tools convert most of the program logic, but still require some attention by programming personnel to handle unsupported functions or data types that vary from one generation or model of PLC to the next, such as PLC-sourced peer-to-peer (P2P) messaging.

When upgrading an automation system, it is important for end users to communicate closely with their system integrators, distributors, contractors and equipment manufacturers. Holding workshops among these groups is a prime opportunity for everyone to understand the existing equipment (including equipment lifecycles) and discuss the best methods for upgrading.

Workshops also provide a forum for discussing and tracking project decisions as the control strategies are more fully understood. Having a solid understanding of the existing system facilitates the process of upgrading and minimizes process downtime.

Migration in action

Is there a right or wrong approach to upgrading PLCs between generations? Some would ask, “Why put an old motor into a new car?” Others might say, “Why change something that has been working?” The entire team must focus on achieving the end goal of a functional and maintainable facility, while minimizing the time, cost and risk to get there. The intent is not to advocate one choice over another, but to discuss what is necessary to consider when making the decision.

For many projects, the team finds migrating existing code into a new automation platform to be the best approach. Following are two example projects that were executed by migrating existing functional PLC code into new software and hardware.

Project 1: Rockwell Automation

The situation: A municipal wastewater treatment plant was performing hardware upgrades to their automation system. Their existing system consisted of a Rockwell Automation FactoryTalk View SE supervisory control and data acquisition (SCADA) application that communicated with multiple Allen-Bradley PLC-5 controllers via a ControlLogix gateway.

While the plant was comfortable with the existing SCADA application and PLC programming, they wanted to upgrade their PLC hardware from PLC-5 to ControlLogix. They also wanted to consolidate the programs of the PLC-5s into redundant ControlLogix PLC pairs, and to handle all remote input/output (I/O) (RIO) using Ethernet. Additionally, there were plans to convert the plant network from a proprietary DH+ network to a fiber optic EtherNet/IP network.

After reviewing the end user’s well-documented copies of the existing PLC programs and comparing the current state of the system to the end user’s desired result, Tesco Controls worked with them and developed a plan to upgrade the PLC hardware from PLC-5 to ControlLogix, while maintaining the SCADA application. This was accomplished by converting the PLC-5 program code to be compatible with redundant ControlLogix PLCs and Ethernet RIO, while maintaining the same look and feel of the existing program and updating the PLCs’ network configurations to accommodate the new fiber-optic EtherNet/IP network.

The solution: Tesco Controls leveraged Rockwell Automation’s conversion products and tools to efficiently migrate the existing hardware and software.

To integrate and install new ControlLogix hardware, Tesco Controls used Rockwell’s hardware retrofit kit. This kit allowed the existing PLC-5 terminations to remain in place, and those terminations connect to new ControlLogix I/O modules through a conversion harness (see Figure 5).

Using Rockwell’s software conversion tool, Tesco Controls was able to mimic the PLC-5 coding style in the ControlLogix programming environment. However, to accommodate the newer features of the modern programming software, some revisions were required.

Because I/O cards are handled differently between the two platforms, the scaling for each analog point needed to be individually checked and configured. This is because of the differences in how PLC-5s access analog data compared to ControlLogix systems. PLC-5s use specific block transfer reads and block transfer writes, while ControlLogix PLCs read and write data natively through the program I/O tree. Due to this difference, the program often required additional logic to fully replicate the functions of the original program.

With the upgrade to ControlLogix PLCs, the program logic associated with messaging and peer-to-peer communication needed to be updated to accommodate the modern EtherNet/IP protocol, as PLC-5s natively use the legacy DH+ protocol. To meet the requirements of the EtherNet/IP protocol, each instance of messaging logic needed to be configured individually so the ControlLogix PLCs could communicate with remaining PLC-5s using an EtherNet/IP to DH+ gateway.

Proportional-integral-derivative (PID) analog loop control also has differences between the two platforms. One example is how the PID block scales its inputs and outputs. To migrate this aspect of the PLC program, Tesco Controls kept the existing registers and SCADA tags intact to maintain their compatibility with the original logic and SCADA system. However, the PID values were modified as needed to accommodate the ControlLogix PID instruction.

For the SCADA application, Tesco Controls developed its own software tool to automate the tag conversion to expedite the conversion of the existing PLC-5 tags into ControlLogix tags. This custom tool helped eliminate potential transcription errors that could arise from manually converting the tags. This tool was used to convert the tags in a bulk manner for one process area at a time, and each set was uploaded to the existing SCADA system for testing before integration into the live system.

Tesco Controls successfully cut over one PLC per day, with each hardware cutover taking approximately 20 minutes, and with the software cutover and overall testing and verification completed during the remainder of the day.

Tesco Controls performed a relatively seamless hot cutover of the PLCs using good documentation practices, appropriate contingency plans and a thorough understanding of the plant’s operational characteristics and the end user’s goals.

Project 2: Schneider Electric

The situation: The control system for a specific treatment process at this water treatment plant was provided by process an original equipment manufacturer (OEM). This existing SCADA system used Wonderware InTouch and communicated with nine Schneider Electric 984 Compact PLCs over the facility’s Modbus Plus network.

The end user wanted to move to an IP-based fiber-optic network and convert the legacy Compact PLCs to Schneider Electric M580 and M340 PLCs. The goal was to keep the existing SCADA application intact while updating the driver from Modbus Plus to Modbus TCP for use on the new fiber-optic Ethernet network. Additionally, two of the PLCs onsite were near each other so the end user planned to consolidate them into one PLC within the same control panel.

However, the process OEM had stopped supporting and maintaining the process for the end user. So, Tesco Controls was hired to handle the system upgrades. Fortunately, the end user had semi-commented versions of some of the existing PLCs on record, and Tesco Controls was able to verify these programs were equal to the programs currently installed in the field.

The solution: Because of the complexity of the treatment process, Tesco Controls decided to keep the existing logic intact during the cutover to new hardware and software. To facilitate the cutover process, the end user scheduled a lengthy downtime period and a careful demolition and installation plan was established (see Figure 6). Before starting the upgrades, Tesco Controls performed code uploads and data backups of all the PLCs.

The main challenges of this project included:

  • Mapping all peer-to-peer messages between PLCs, as the M580 uses a different messaging block in contemporary Unity software
  • Maintaining setpoints and statistical data when updating each PLC
  • Retaining the functionality of existing operator interface terminals, which could only communicate over the legacy Modbus Plus to the PLCs.

Using the Unity Pro PLC programming software, Tesco Controls was able to convert the 984-ladder logic of the existing Concept and ProWorx PLC applications to accommodate the Unity Pro programming environment. After the conversion was complete, Tesco Controls then reviewed the program and documented the existing registers and register values.

To consolidate the two PLCs in close proximity, Tesco Controls first combined the logic into the single destination PLC. Next, the data addresses used by SCADA were coordinated to ensure they connected with the proper final addresses in the consolidated PLC.

During the process of testing and validating the new system, normal production was bypassed and some permissives needed to be forced or simulated to run certain aspects of the process.

After working collaboratively with the end user, Tesco Controls successfully migrated the control strategies from the existing controllers to the new architecture.

Final thoughts

Preserving archaic automation systems can be painful. On the other hand, performing an automation upgrade by completely revamping all the code and underlying platforms can be risky and expensive, even though it is an opportunity to modernize and standardize PLC coding philosophies.

When old automation systems finally require an upgrade, a balanced approach of migrating legacy industrial automation programs into new platforms can be the preferred solution. This approach provides the best method for preserving existing functionality while minimizing downtime.

However, with legacy program conversions, the output is only as good as the input, and the quality and consistency of the existing code will translate into the new controller. Code conversions without solid documentation may lead to finger pointing situations when anecdotal claims are made such as: “It used to work like this…” without firm proof. Holding workshops and validating existing functionality is key to avoiding these and other issues, and eventually successfully migrating existing code.

Tesco Controls Inc. is a certified member of the Control System Integrators Association (CSIA).

Original content can be found at Control Engineering.

Author Bio: Raju Nair is the PLC applications engineering manager for Tesco Controls. He establishes the technical process requirements for the company’s projects and performance teams and has coordinated multiple complex projects for water/wastewater and renewable energy, including one of the largest EPA clean-ups in the U.S. He possesses a solid understanding of PLC programming best practices and has led the company in the standardization and templatizing of PLC coding.