PLC Code - Good vs Bad
There are differing schools of thought when it comes to programming PLC’s as to what is the ‘best’ way to achieve a successful outcome from the control system side of things. On the surface PLC programming is not too difficult, add a few rungs or lines of code and presto, the system works, however what happens if a system expansion is required or changes are needed to be implemented by someone other than the original writer of the code? Not all PLC code is created equal, so how can you differentiate good code from bad?
PLC coding that is not correctly implemented can result, at best, in system inefficiencies and minor disruptions to processes or plant operation, requiring at the very least ongoing attention to rectify these issues. This can be frustrating, time consuming and costly for ongoing call-outs.
At worst, poor PLC coding practices can result in extended major infrastructure shutdowns which could easily impact the safety of not only workers on or near the site, but cause wide ranging, costly and potentially life-threatening issues to the wider population such as water contamination, loss of power, toxic pollution and loss of security to name a few.
There will also be extensive ongoing costs associated with the management, containment and rectification of the disrupted infrastructure or process plant.
PLC code differences
What are the differences between good and bad PLC code? Good coding, first and foremost, adheres to a specific set of standards and guidelines that outlines what is required and how the code needs to be implemented. One of these standards is IEC 61131-3, which provides guidance on the different programming languages including syntax, layout and formatting.
Having thorough documentation processes including development of a Functional Design Specification (FDS) is paramount to programming a reliable and safe PLC system. The FDS will provide guidance on what the system parameters are and how the PLC is going to function with all the interrelated system components. A lack of design brief or documented procedures opens up one of the first points of failure when considering PLC software development.
Good coding also comes from experience working with a wide range of PLC projects. All PLC manufacturers have their own way of implementing code into their systems, so having a thorough understanding of the coding standards, instruction set and the differences between manufacturers assists with becoming proficient and avoiding time consuming errors.
Another important aspect often overlooked is commenting. All PLC code should be well commented, this provides guidance for how the system is implemented and assists with troubleshooting during the testing phase along with ease of undertaking future modifications.
Good code includes well-structured blocks, timers and loops that are implemented to provide the best balance of process functionality and efficiency. Are start and run permissives clearly identified? Are all the communication tags clearly grouped for efficient transfer? How about memory map layout, is it clearly defined and laid out using structures or similar object orientated design? How about alarms and event data, are these allowed for and cleanly separated from functional code?
Examples of bad coding includes poor or non-existent commenting, lack of documentation such as a detailed functional specification, duplicate functions within the program, using unnecessary loops, mixing alarms into control blocks, inconsistent tag naming, direct addressing of physical I/O in function blocks, code blocks scattering memory allocations, multiple communications blocks reading or writing to multiple memory areas, using old school working registers when modern PLC’s rarely run out of memory, the list goes on.
Product and service quality
Given a majority of PLC systems are essentially critical by nature, how does the end user know they’re getting a quality product and service that won’t compromise reliability or safety of the process or plant? The short answer is, unless they are an experienced programmer themselves they don’t.
Typically, it’s not until the system is implemented or functional testing is undertaken that the shortcomings of the PLC code development becomes apparent. By this time, it’s usually too late to make any significant changes, and attempting to rectify a complex system that has poor PLC coding or implementation practices will ensure ongoing delays and additional project costs, regardless of what the project contractual agreements were outlined prior to the engagements.
Geoff Bladon, Business Development Director at Automation IT, has been involved with control system engineering for over 20 years and in this time he has seen all manner of PLC code, good and bad. He has worked as an expert witness for the Supreme Courts of both Queensland and Victoria in this capacity so we were interested to hear his thoughts.
“A lot of end users assume all PLC code and specifically software developers are the same. You don’t hire an electrician to fix your plumbing, so why do people think you should hire an electrician to design and program your control system? I guess from the end users point of view they in most cases don’t understand the software aspects in detail and once running, the software isn’t physically seen so all is good, right?
“Most PLC systems are complex and I’ve seen far too many examples of poorly written code with little or no documentation on how the system is supposed to perform. This is not to say I haven’t seen bad code from some engineers either, but those guys should know better having formal training in design and programming with continued professional development requirements placed upon them.
“This opens the end client up to major risk when the system does not perform as expected or contain intermittent issues due to poor coding practices. What a lot of end users don’t actually realise is that in Queensland, PLC programing is classified as an engineering service under the professional engineering act and it’s illegal for non-registered engineers to perform this service unless directly supervised by an Registered Professional Engineer of Queensland (RPEQ).”
Documentation is an often overlooked part of the process, especially when small projects are involved, Geoff Bladon outlines some important aspects.
“For small projects, people assume that it should only take a ‘day or two’ to program the PLC and implement on site. In order to achieve a successful outcome, the system process needs to be understood and documented. Proportionately, the documentation costs for small projects can appear high, however these costs should be considered as adding value rather than being a burden. Well documented systems mean everything can be traced and modifications easily implemented in future.
“I’ve seen many small projects taken on by others that become expensive very quickly, in some cases costing many times the original estimate as the whole of cost for the project was not considered at the beginning. Changes end up taking much longer than they should as a quality base just isn’t there.
“The only way to ensure a particular control system, small or large, is designed, developed and commissioned correctly is by engaging companies who have suitably qualified engineers with extensive experience developing software code for a wide range of PLC and SCADA systems.
“These companies should have the necessary quality assurance certifications to ensure the project is undertaken and completed following fully documented procedures. Process plants are complex and expensive to build, upgrade and manage, so the emphasis should be on engaging experienced companies who provide a quality product or service and seek successful outcomes.”
Automation IT are a low risk specialist PLC and SCADA engineering company that strives to provide the end client with a fully documented and quality coded product, designed to maximise plant efficiencies and operation.
