Strategies and Preparation for a Controls Upgrade
As the central component of an industrial manufacturing process, the control system communicates with all connected equipment and coordinates next steps. As it ages, difficulties and limitations can arise that are best served by upgrading to a newer system. In part one of this series, the reasons to consider a controls upgrade are discussed. This article is part two of the series, and discusses the preparatory knowledge and planning needed to ensure a smooth and seamless upgrade.
By Director of Indiana Operations / Sr. Electrical Engineer John Shipley and Director of Texas Operations Nick Hitchcock
Introduction
Because a control system’s primary function is the coordination of a manufacturing process, a successful upgrade requires prior system knowledge and planning. Communication protocols used by each component must either be directly supported by the new system, or a gateway unit must be sourced. A thorough understanding of the logic executed by the control system ensures that all tasks are identified and accounted for. The software used by the old versus new systems must be considered. A decision may be needed on whether to translate the existing code using a tool, if available, or to rewrite it entirely. Lastly, any security issues introduced by increased connectivity of the newer system must be addressed to ensure cybersecurity.
Planning an Upgrade
The following list outlines the basic knowledge required to prepare for a controls system upgrade. This article discusses the following knowledge areas in further detail:
- Communication protocols
- Design documents
- Sequence of operations
- Software
- OT security
Communication Protocols in Use
Detailed knowledge of the communication protocols used by connected equipment is required as a plan must be in place to ensure a means of connecting every piece of equipment to the new PLC. Sometimes, older equipment may communicate using a protocol no longer supported by newer PLCs. Should that be the case, a gateway unit must be sourced to connect between the PLC and the equipment.
Sourcing a Gateway Card
To find a gateway card, consider the following sources:
An example of a legacy protocol with limited newer PLC support is Remote I/O (RIO). While it’s still possible to obtain gateway cards for these kinds of older protocols, there may or may not be one available that is native to the controls system, opening up other potential compatibility issues.
Access to Design Documents
Having access to existing electrical and mechanical prints greatly facilitates the process of executing a controls system upgrade. The prints show the various connections in the system. While there are several types of prints, some to consider are as follows:
Electrical Schematics
An electrical schematic visually depicts the electrical connections of the entire system, including components and wiring. The panel layout schematic shows how different components within a control panel are connected and arranged. With access to all schematics, verification of all connections in the system can occur and a plan can be made to ensure their continued connectivity to the new PLC.
Equipment Layout Diagram
The equipment layout diagram is a drawing showing the physical layout of each piece of equipment in the system.
Piping and Instrumentation Diagrams (P&IDs)
Used primarily in process industries, the P&IDs depict details related to the pipelines (i.e. piping size, valve types), mechanical equipment (i.e. pumps, tanks), as well as control devices (switches, relays, computer control systems) involved in the process flow.
Safety System Diagram
When a controls system upgrade is undertaken, the new system must be evaluated with a safety risk assessment. The safety system diagram shows the various components within the existing system, allowing the engineer to determine if current safety standards and regulations are met, or if additional safety features will be required as part of the upgrade.
Sequence of Operations
To ensure a seamless transition between control systems, it is necessary to understand the order of operations within the process. Patti Engineering integrators will often take video of the current system. They use the video alongside the source code to match up and verify the observed sequence of operations with those written in the software.
Software Upgrade
It is common for legacy code types to be no longer supported by new control systems. Sometimes, there’s an interest in obtaining access to greater functionality from newer software. A plan must be in place to either translate the legacy code or re-write it entirely.
Code Translation
A code translation tool works by analyzing the original source code for particular software structures and converting them into equivalent structures in the destination language. The process is often imperfect, requiring an engineer to review, edit, and then test the translated code. It is common for vendors to have proprietary translation tools to support the migration of code.
Manual Translation
Occasionally, the existing legacy code is sufficiently robust that a full rewrite is not useful, but a translation tool is not available.
As an interesting example, Patti Engineering recently upgraded a legacy GE Fanuc PLC to a Siemens Simatic S7 1500 for a client. The existing code was written using ladder logic. It presented no operation issues and controlled a simple process. However, as is often the case with older ladder logic, it lacked meaningful symbol names (for registers, variables, functions, etc.) because older programming environments did not support the downloading of human-readable names to the PLC. Without a copy of the original software, the PLC version of the code was a challenge to fully decipher (including unmeaningful address names such as “x19”). Given the circumstances, the decision was made to manually copy the source code (on a near line-by-line basis) from the older application into the new one, adding meaningful symbol names as their function became more known.
Code Rewriting
While the process of fully rewriting software adds more scope to a project, it also offers a unique opportunity to address lingering problems and inefficiencies.
As an example, in a recent controls upgrade project undertaken by Patti Engineering, the customer opted to invest in fully rewriting the software while upgrading from an older Schneider Electric controls system to a newer Siemens PLC. The driving reason to rewrite the code was to eliminate a poorly designed, cumbersome downtime recovery process. This process involved tending all machines regardless of whether or not they had parts in them at downtime, a tedious procedure requiring 15 minutes to complete. Patti Engineering engineers fully rewrote the software to eliminate this unnecessary inefficiency. As a result, the recovery process was simplified, allowing a return to operation directly from the state of operation prior to downtime. The need to tend each machine was eliminated, so downtime recovery was seamless and much faster.
To Translate or Rewrite: That is the Question
The decision about which approach to undertake is application specific, and is also dependent on having:
- Original source code and an evaluation of its current state
- Translation tool between the two languages (may not exist between different brands)
- Documentation describing the current software
- Electrical schematics describing signal connections
- Up-to-date system backups (for source code, recipe values, etc.)
- Documentation describing the sequence of operations
If the software controls a straightforward process and is well documented, the use of a translation tool may be a worthy way to proceed. On the other hand, if the existing source code has already undergone earlier translations, it may not operate as efficiently as it otherwise could. If the brands of the new and legacy PLC are not the same, then a full software rewrite will likely be the only option since translation tools between brands generally don’t exist. Despite adding to the overall scope of the project, a full code rewrite may present an opportunity to incorporate current best practices and obtaining a better overall result.
Black Box Conundrum – No Source Code
Sometimes the original source code is unavailable, hidden for the purpose of protecting the creator’s intellectual property (IP), or occasionally because it contains control properties that are kept out of reach to avoid damaging the system (i.e. control of furnace and other heat-treating systems). Typically, an integrator will leave a customer with full access to the source code so that changes can be made as needed.
Cybersecurity
Due to their lack of connectivity to any broader network, legacy systems are frequently immune to cyber attacks. Their air-gapped nature, while generally limiting, offers them nearly full protection from this ever-increasing risk.
Most newer systems come with the potential for OT (operational technology) network connectivity. This convenience allows them to be remotely accessed, controlled, and firmware updated. It also allows for production process data collection, transfer and analysis: Industry 4.0 capability aimed at process optimization. However, to access these capabilities, the new PLC must be connected to a broader OT network, which must also have access to the outside internet. A thoughtful approach must be in place to ensure reduced vulnerability to the ever-increasing risk of cyber attacks. An OT network employing what’s popularly known as a “zero trust approach” will safeguard the equipment that resides on the system, which is beyond the scope of this blog.
For the reasons discussed in this blog series, a controls upgrade can be a worthwhile investment. With careful research and planning, the pursuit stands a high likelihood of success, breathing new functionality and capability into existing equipment.
Related categories: Blog Control Systems Integration
