The need to update legacy systems becomes more urgent as automation hardware increases in complexity and regulations become stricter and more defined. However, migrations can be costly and time-consuming, so many of us would rather put them off until next year…or maybe the year after that to keep processes up and running. After all, the increased uptime leads to more revenue, right?
Advancements in functionality have made the case for accelerating the migration timeline. On a recent project, there was a need to reset passwords when operators were locked out. Because the passwords were hardcoded, the legacy system required me to remote into the programmable logic controller (PLC) since there was no other way to change them. This practice poses security risks and impacts the regulatory compliance of the system. A modern device could be integrated with the site domain, allowing users to authenticate into the human-machine interface (HMI) using their domain credentials. Password changes would now be governed by company policies, increasing security and inheriting enterprise password requirements. More importantly, HMI actions would now be attributable to individual users, a major regulatory requirement in many industries.
The importance of secure and updated communication protocols is not limited to HMIs. On another project, we were tasked with upgrading a legacy PLC. The only copy of the code was on the live processor, which was equipped with a DH-485 port. Simply connecting to this processor turned out to be comically complicated. First, we tried a DH-485 to serial converter, but we couldn’t find a computer with an old enough operating system (OS) for the driver to work. Then, we tried an adapter that went straight from DH-485 to USB, but after many attempts, we determined the cable was defective. It took multiple trips to the distributor looking for something that would talk to this controller, which was the sole device controlling a critical site utility function.
Eventually, we tracked down a PC-card converter, a special proprietary cable to use with it, and a computer with the exact Windows XP service pack we needed, and straightened out the licensing to use the software and drivers. Finally, we were able to upload the code, though with a significant chunk of our schedule spent just trying to communicate to the PLC.
The point of this is not just to add to the war stories told by others, but to serve as an example of why modernization is important and grows in importance as systems age.
Also, manufacturer support doesn’t last forever. The longer an older device sits in its panel untouched, the less likely help will be available when something goes wrong. And eventually, something will go wrong.
This process doesn’t have to be scary. Carefully considering new power and I/O requirements, hardware sizing, and required testing can help prevent headaches during the migration process. Often, tools within automation software packages carry out most of the code migration for you, and a migration gives you the chance to implement other changes to your code that would be too extensive for a typical downtime period. So consider moving your migration project to the top of your to-do list. It might pay off sooner than you think.
>> Jack Fillenwarth is an automation engineer at Panacea Technologies, a certified member of the Control System Integrators Association (CSIA). For more information about Panacea, visit its profile on the Industrial Automation Exchange.
