PLC Standards for the New-ish Millennium
The topic of PLC standards for both programming and hardware has been on the mind of the industry nearly since the invention of the PLC. Throughout this time, the industry, as well as the professionals working therein, have experienced great success as well as some setbacks.
The world is also a vastly different place than it was in the 1980s. Back then, we had only recently put away our slide rules, enticed by the lurid glow of the seven segment displays on our digital calculators. We had yet to experience upheavals such as the mass retirement of skilled workers, the Great Resignation, and globalization of the workforce. There have been profound changes in the technology landscape as well. Aside from the magic of air fryers and streaming TV, we’ve got the IIoT, the Cloud, and accelerated development via object-oriented programming.
PLC standards are a lot like playing the guitar or speaking a second language. It’s great to grab your six-string acoustic and play campfire songs, but it requires hours and hours of grueling lessons to get you to the point where that’s a possibility. Similarly, creating a comprehensive set of PLC standards is an undertaking that fewer and fewer companies are equipped to undertake. The Old Guard of PLC Pros has one foot out the door, and the next generation needs to cover a wider array of technologies, which dilutes focus and prevents investment in initiatives with longer term payback.
From an engineering perspective, creation of standards is the fun part. Who doesn’t enjoy a company sponsored lunch while arguing with your colleagues over whether or not to nest your UDTs? Long-term stewardship, including training, enforcement, and continual improvement efforts, can be more of a drain, both literally and figuratively. Certainly, if resources weren’t available to create standards in the first place, there’s unlikely to be enough excess horsepower for the ongoing maintenance efforts.
Further, and separately from workplace changes, one of the arguments in favor of standardization has traditionally been accelerated design and deployment. If we planned to copy/paste our standard logic a thousand times, some up-front design and testing effort would be more than justified, as would the documentation effort to ensure that the standards were implemented properly in various situations. Modern programming tools take off quite a bit of the pressure here. With user-defined function blocks, or add-on instructions, the instantiation process is much faster than copy/paste, and we now retain the link between template and instance, so that all is not lost if we discover a change that needs to be made after roll-out has started. This is undoubtedly a positive development but erodes one of the drivers for implementing standards.
If the industry has a smaller pool of less experienced resources who have less time and less incentive to devote energy to creating and maintaining standards, what is the path forward? There are at least two, and they can work well in conjunction.
Industry supported standardization efforts, such as IEC 61131-3, help define the tools in our toolkit, and simplify the learning curve inherent in switching between hardware brands. This early example has been a real success story – quietly changing the “normal” way we get our jobs done. This value is also seen in ISA 88 for Batch Control and TR88.00 (PackML), among others.
These standards, made available to the industry as a whole, will obviously change the way we approach specific projects and applications, but more importantly over time, change our collective mindset about the way we should go about things. Manufacturers and engineering companies would do well to embrace the standards put forward by industry, and to engage in the ongoing dialogue around these standards.
The other element in finding a good path forward is migrating to more of a lightweight mindset. Standards consisting of a large amount of documentation and ancillary materials are problematic in several ways – initial effort to create, likelihood of becoming outdated due to resistance to modification, barriers to usage due to up-front reading and comprehension. Instead, a cohesive set of sample code that follows a common set of rules presents a much lower cost of entry and usage. When taking this approach, it is important to provide guidance, for example in the form of training, so that the programmers leveraging these lighter standards don’t fall into traps that might be exposed by the more lightweight approach. This combination training and lightweight standards can often be more professionally fulfilling than blindly following standards and could in turn lead to improved retention of resources.
If you find yourself shopping for these standards rather than building them in-house, there are a number of potential resources, including PLC manufacturers, OEMs, and Systems Integrators. The best advice here is to identify a solution that truly fits your business, so that programmers will feel enabled, rather than burdened, by the standards. Maybe this involves an internal search for running applications that are well regarded buy the maintenance and support teams, then reaching out to the supplier. Or possibly you’ll prefer to start the search externally. Either way, it’s important to consider the entire life cycle of the code that will be written. This life cycle includes not only streamlined development and robust code, but simple maintenance and easy future upgrades, along with your own more custom requirements.
As we think about future states, the lightweight approach accepts that there’s unlikely to be a world in which every one of your systems follows the same standards. There’s usually limited value in replacing an application that’s non-standard, unless it’s letting you down in a bigger way. The lightweight approach invites an increased pace refinement over time, which should be viewed as a win-win. Incremental improvements can be leveraged, and the entire process is more organic such that you don’t suddenly wake up one day 10 years in the future with a heavy investment that has become obsolete.