January 2019 | Matrix Technologies Incorporated

Converting Old PLC Code: Benefits and Pitfalls

Posted on January 27, 2019June 18, 2020 by Dave Blaida, PE

Converting Old PLC Code: Benefits and Pitfalls

Sounds great, doesn’t it? Buy the new programmable logic controller (PLC) equipment, run the old PLC code through a translator program, and the new system is up and running. Now to give credit where credit is due, very few people would actually believe a control system upgrade would be this easy. What are the pluses and minuses of converting code compared with rewriting it? Why are some systems well suited for this approach and others problematic? This article looks at some of the issues related to converting PLC code and provides some insight into ways to capitalize on this technology without some of the problems that may result.

Why convert compared with rewriting the software? The quickest answer is cost. But is that the correct answer? While it may not take much time to run a translation tool on the old code to create the new, how much extra work is required to get the new program fully operational? Most translation tools will have the disclaimer that they don’t translate 100 percent of the code and have a fairly long list of items that need to be manually handled — and this is if you’re staying with the same manufacturer. If you are switching brands, translation tools may not be available. It is possible to have custom software written to do the conversion, or just do it manually (which may not be practical for a large program) but these alternatives may add significant cost.

How good is your base?

The usefulness of converting an existing program depends on its condition.

Is the source code available in editable form, i.e., the program and programming software exists electronically?
Is the source well documented with rung comments and meaningful symbol names?
Is there a document that explains how the program is organized and how it works, maybe in a technical manual from project commissioning?
How much of the program is still applicable? There may be equipment included in the program that no longer exists, leaving “dead code” for disconnected inputs and outputs. If the code is no longer needed, delete it.
Is the technical staff intimately familiar with the existing logic? If so, it may be easier to maintain translated code than to learn a new program. If not, then it may be better to have a new, well-designed program that’s easier to understand.
Finally, does the existing program operate consistently and problem free for the most part? There could be sensor, actuator or wiring problems that get lumped in with the control system here. In this context, we’re just talking about the logic. Does the program ever “lock up,” requiring a restart? If you translate a bad program, you end up with a bad program translated.

Supporting engineering materials are useful regardless of whether you are converting the program or not but can be invaluable if you decide on a rewrite. This includes a functional specification, process and instrumentation diagrams (P&IDs), state transition diagrams and electrical schematics. Are these materials relatively up-to-date and accurate?

In the worse-case scenario, there is no original source code and no documentation as to how the system was designed. While you may be able to upload the existing code, we would not recommend converting any but the simplest ladder logic programs. We recommend doing an initial engineering phase to fully document the existing system and developing a new program with modern software and programming tools.

After-Conversion Expectations

What do you expect to end up with when the conversion is done? If the converted system just needs to work exactly as it does now, then translation may be a good choice. If your reasons for the new PLC includes making significant operating changes, incorporating new equipment or meeting new regulatory requirements, then it’s probably a better idea to rewrite the program.

Thoughtfully considering the design may also lead to combining smaller systems into one new PLC, or incorporating functions from another device (e.g., a computer) into the more powerful and capable PLCs offered today. This step may also help justify the conversion cost over just replacing an obsolete device.

Issue 1 – Decide how to convert the data structure

Let’s say you have a good base to start with and decide to translate the existing program. One of the first options to consider is do you want to keep the existing data structure or move to the new processor’s structure?

Older central processing units (CPUs) are organized around data types. For example, bits are stored in a bit table, integers are stored with other integers, real numbers with real, timers with timers, etc. For the control of any particular device, say a variable frequency drive (VFD), one might have a few bits, a timer, a couple integers, a real or two, and a counter. These are selected as elements from the various data tables to be used in the logic for the VFD.

New CPUs are object-oriented. Our VFD data is built as a template (i.e., user defined type or UDT), where each item is added to the template with a meaningful name and description. The UDT is replicated for each object of that type. So if there are 20 VFDs, you would have 20 instances of the VFD UDT, each named for the specific drive. And each one would have all the signals included in the UDT for that object (e.g., M101.bRunning). Once the tag is created, the actual memory used is handled behind the scenes by the operating system.

CPU — Modern Data Logically Organized by Data Object

Translation tools generally don’t have enough smarts to map from data type organization into the object-oriented one. What you’re left with as a result is a whole collection of tags (as named from the previous data element name) to be used to troubleshoot a VFD.

Issue 2 – Are the symbol names useful?

Translation programs may give the user the option of using the symbol name (if it exists) to generate the tag name, or just using the data element name to generate the tag name. If the program is well documented, the symbol names are the best way to go. If there is only a smattering of existing names, or if you generate the program by an upload with no documentation available, then you are stuck with the element names. After translation, you may wish to spend some time documenting the data element names with a useful description in this case.

Issue 3 – Determine how the new program should be structured

Older CPUs have one program, which may include a series of subroutines, jump statements/targets, interrupts and other mechanisms, but at the end of the day only a single program. New CPUs have significant capabilities not only to separate code into modular chunks, but to allow the modules to be called in a variety of ways including sequential, timed, interrupt and on error, along with prioritization between modules. They even allow new language elements to be created for key functions as add-on instructions (AOIs).

Both the data structures and code modules must be manually implemented but add significant value to the long-term support of the control system. Specify that these extra steps are needed when undertaking a code conversion project

Not All-Or-Nothing

Converting the old code doesn’t need to be an all-or-nothing proposition. Some of the old program logic may be quite useful and provide key sequencing, interlock and alarm information that can save time compared with rediscovering these design details. Pick the best useful parts of the old and use them in the new program, while taking advantage of object-based tags and new capabilities.

Fundamental Changes

Even if you run exactly the same code from the old processor in the new one, it may not work exactly the same way. New processors will execute converted code differently because their internal architectures are significantly different. This may result in unexpected results. Here are some things you might see and ideas to mitigate the problems.

New processors are fast. Older PLCs may have code optimized to squeeze every bit of performance from the processor of the day. For example, conditionally scanning blocks of code is a way to reduce scan time, but was often confusing when troubleshooting because it was not obvious some of the code was not being scanned. Consider moving each block to a separate routine or removing the instructions that cause the code to be skipped. Previously skipped code may require some individual edits to make it work properly when it is executing every scan.
Old and new processors handle input/output (IO) updates differently. Old processors had all IO updated at ends of scan. New processors usually update asynchronously to the program scan. If programs include IO mapping routines, this will probably solve the problem; the program logic should not use the actual IO image table as the data may update as the logic is executing.
Old logic may count scans for delay periods or some other scan-based logic. Changing these to timer-based logic should solve the issue.
If changing from one brand to another, logic networks may be executed in a different order (brand M vs. brand A in particular). Often this can be mitigated by breaking down more complex networks into a number of rungs with less complexity.

HMI Considerations

Don’t forget about the human machine interface (HMI) when making control system upgrades. If you plan to reuse the existing HMI, you will most likely need to readdress the tags the HMI is accessing at a minimum.

Some very old systems use HMIs of a style that are actively controlled by the PLC code (think terminals or data displays). There may also be PLC code that reads an active screen number in the HMI and performs logic based upon that screen being displayed. In these cases, a new HMI will be needed and may require new PLC code to support it, plus removal of old code no longer needed.

Inter-processor Communications

If the old system is not connected to any other PLC systems or networks, inter-processor communication is not a concern. However, many installed systems are modified over the years as a data source for reports or provide information upstream or downstream in the process.

If you are lucky, the old program contains a message instruction that includes the source and destination data address, processor, and under what circumstances the message is exchanged. If not, there may be devices that read and even write information from the old PLC without any indication of it in the program. Unless there is some local knowledge or documentation of this, you may not discover it until the data is missing from the report or screen, and may need to add it back. (Use messaging this time.) If the data is used for an alarm or interlock, it may need to be resolved quickly. If possible, test for this case as early as possible by disconnecting or shutting down the old PLC as a test prior to the conversion.

Testing Converted Software

Once the new PLC program is ready, it should be tested thoroughly before being placed into operation. The testing may use simulation software or actually run in a “shadow” mode prior to being allowed to control. In shadow mode, the inputs are run to both systems in parallel and only one set of outputs is allowed to control (generally the old system). If the new system is using the same IO, transfer the IO image to execute the new logic. Software is configured to detect any differences between the two sets of outputs, and then differences are logged to a file or database. The shadowing is complete when all of the differences can be resolved.

Depending on how much code is converted and how much technical information is available on the old system, testing can be tricky. If you don’t know exactly how the system should work, how do you evaluate if it’s in fact working properly? Having the engineering basis for how the system operates is another benefit of a rewrite.

Conclusion

Converting old code to run in a new process can be an effective, fast and low-cost way to get new controls in and working. It can also result in software that never quite works right and is very difficult to understand, troubleshoot and change when needed. This article outlines some of the issues often encountered in control system upgrades and provides considerations so that you can end up with a properly working program that is maintainable into the future. If you need help deciding the best way to implement your new PLC, give Matrix Technologies a call.

Matrix Technologies is one of the largest independent process design, industrial automation engineering, and manufacturing operations management companies in North America. To learn more about our industrial automation capabilities and manufacturing process control solutions, contact Dave Blaida, PE, CEO & President.

© Matrix Technologies, Inc.

Oil Refinery Upgrades Control System Involving More than 3,000 Instruments

Posted on January 10, 2019December 12, 2022 by Scott Byrne, PE

Oil Refinery Upgrades Control System Involving More than 3,000 Instruments

An oil refinery client needed a control system upgrade to correct performance and maintenance issues. As part of this, the move to an instrument fieldbus technology was made to take advantage of the monitoring and troubleshooting features it could provide. This resulted in the need to replace more than 3,000 existing electrical and controls instruments with a fieldbus networked infrastructure. The sheer size of the installation and the need for hot cutover of the new equipment required extensive field work, planning, testing and coordination among several parties.

Matrix Technologies consultants worked with the refinery staff to perform a definition phase study for the project. A detailed field inventory of the existing control devices was used to prepare instrument location plans and replacement scope per device. This information was then used to prepare a preliminary Fieldbus infrastructure design and an installation cost estimate suitable for project funding.

As part of the implementation, each device was revisited and documented. A custom tool for field documentation was developed by Matrix using hardened iPad tablet devices. The devices communicated directly to the project design team via existing cellular networks. This allowed real time communication between the teams in the field doing documentation and the design teams in Matrix’s offices.

Field data was entered directly from the field into the project design data base using this tool. Pictures of each device were taken using the iPad, and the field team had access to the client’s drawing vault in real time. This increased the rate of device field documentation by 50 to 80 percent compared to traditional paper-and-pencil techniques. A structured query language (SQL) database was developed, which ultimately contained 160,000 pieces of instrument data.

Fieldbus segment design took into consideration plant reliability concerns and device geographic proximity. The custom SQL database was integrated with Smart Plant Instrumentation (SPI) software package to prepare electronic specification sheets for all of the new control devices. Matrix prepared the control system infrastructure design and the contractor installation packages. Matrix field oil and gas engineering consultants were available to answer questions from the onsite installation contractors. The entire re-instrumentation was executed using hot cutovers.

Over the implementation phase of the project, 3,500 new fieldbus devices were specified and installed. The detailed design was broken down into 450 fieldbus segments (75 miles of FFB cable). Installation packages containing a total of 3,000 drawings were prepared and issued. As-recorded drawings were prepared based on contractor markups and, when necessary, confirmed in the field by Matrix team members.

The end result was an extremely successful control system upgrade, which, according to the client, was one of the best the refinery had ever executed.

Matrix Technologies is one of the largest independent process design, industrial automation engineering, and manufacturing operations management companies in North America. To learn more about our control system upgrades or oil refinery capabilities and manufacturing process control solutions, contact Scott Byrne, PE, Associate Director, Process & Electrical Design Department.

Key Concepts of Machine Safety Verification and Validation

Posted on January 2, 2019June 18, 2020 by Carl Bohman, PE

Safety First

At Matrix Technologies, safety is one of our core values. In fact, we have a program called “Believe in Zero,” which means we strive every day to not have a reportable OSHA incident. We provide all necessary protections for our employees, and we put their safety first.

Our concern about safety extends to our customers as well. How do we strive to ensure our customers’ safety? We work hard to guarantee all industrial safety systems we engineer are up to relevant safety standards and pass the key tests of verification and validation.

Starting with Standards of Safety

Every industrial worker’s workplace should be, as OSHA puts it, “free from recognized hazards that are causing, or are likely to cause, death or serious physical harm.” In some cases, safety systems are designed and installed to lower the probability or frequency of hazards to achieve the level of safety that is required. In these cases, a safety device or safety system should work as it was intended (e.g. stop the machine, slow down operation, move to a safe position, etc).

While designing systems for industrial applications, we conduct a risk assessment: we identify potential hazards, analyze who can be injured and how, and develop safety measures to mitigate the risk. These safety measures might include devices and systems such as estop push buttons, safety switches, safety contactors, and more. To ensure these devices and systems will react as intended, our engineers put them through the processes of verification and validation.

Verification and Validation: Ensuring Safety through Two Distinct Processes

Verification is the process of comparing a safety circuit design and its components to the appropriate safety standards to determine if they meet or exceed the safety level determined by the risk assessment. After the safety circuit is designed and before it is installed, our Matrix engineers use SISTEMA, a widely-known software tool, to accomplish a safety system verification for the control standard of EN ISO 13849-1. The software allows our engineers to model the structure of the safety devices in the system and input the relevant parameters to determine the achieved Performance Level (PL) of the safety system.

Validation is the process of checking the possible fault conditions of the safety system after it is installed to make sure it functions to the safety level required by the risk assessment. This process may involve lifting wires, shorting contacts, removing power, etc., to simulate the possible fault conditions.

The best way to visualize the difference between these two processes is to look at the two simple houses below. Knowledge of the appropriate standards is required to verify the design and build both of the houses. However, only after the houses are built and installed can we validate that only the house on the right was installed properly.

Similarly, safety systems can function in unexpected ways after installation and should be validated before production begins. A simple example would be a safety area scanner used to detect the presence of a person roughly 10 feet from an automatic saw blade used to cut tree logs. In theory, if a person were to walk near the saw, the safety area scanner would detect the person and cut power to the motor of the saw; however, two major problems can occur that may not have been caught during the design and verification steps:

First, dust will be created from cutting the logs, which can inhibit the scanner’s ability to detect a person.
Second, the saw blade would be considered a high inertial load, which means the saw blade will continue to spin on its own even after power is removed from the motor. This freewheel spin can continue for several minutes depending on how fast it was running and the friction of the system before the blade eventually comes to a stop.

The Solution

When problems like these come to light during the safety system validation, it is necessary to find good solutions. For the scenario above, one possible solution could be to install a locking gate sensor with a zero-speed switch on the shaft of the saw blade in lieu of the area scanner. The zero-speed switch would detect the rotation of the saw blade and would only unlock the gate allowing access to the saw when it was no longer rotating. This system would take into account the environmental conditions and the high inertial load of the saw and would pass both the safety system verification and validation after it was installed.

When designing and installing a safety system, performing both a safety system verification and a safety system validation are critical steps in the machine safety lifecycle to ensure that the safety devices work as intended. Skipping these steps could leave fault conditions unprotected, leading to possible harm in the workplace.

Matrix Technologies is one of the largest independent process design, industrial automation, engineering, and manufacturing operations management companies in North America. To learn more about our safety verification and validation services, contact Carl Bohman, PE, FS Senior Project Engineer (TUV Rheinland).