PLC standards for the new-ish millennium

PLC standard insights

• Upheavals such as mass retirements, the great resignation and the globalization of the workforce coupled with strained internal resources have made it more difficult than ever for organizations to develop in-house PLC standards.
• While creating PLC standards is challenging, maintaining them is even more difficult.
• Relying on pre-established industry wide standards such as IEC 61131-3, ISA 88 and TR88.00, and adopting a lightweight mindset can help to ease the process.

---

The topic of programmable logic controller (PLC) standards for both programming and hardware has been on the mind of the industry nearly as long as the PLC itself. Throughout this time, the industry—and the professionals working therein—have experienced both great success and several 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 the globalization of the workforce. There have been profound changes in the technological landscape as well. Aside from the magic of air fryers and streaming TV, we’ve got the Industrial Internet of Things (IIoT), the cloud, and accelerated development via object-oriented programming.

Creating PLC standards

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 ongoing maintenance efforts.

Apart from workplace changes, one of the arguments in favor of standardization has traditionally been that it enables 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.

The pathway forward

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. However, what is more important is that they will change our collective mindset about the way we should go about things over time. 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.

另一个元素,这将有助于打造pathway forward is migrating to a more lightweight mindset. Standards consisting of a large amount of documentation and ancillary materials are problematic in several ways; they require a large amount of initial effort to create; face the likelihood of becoming outdated due to resistance to modification; and create barriers to usage due to struggles with up-front reading and comprehension. Instead, a cohesive sample code that follows a common set of rules can present a much lower cost of entry and usage. When taking this approach, it is important to provide guidance in the form of training so that the programmers leveraging these lighter standards don’t fall into traps that the more lightweight approach might expose them to. This combination of better training and more lightweight standards can often be more professionally fulfilling than blindly following terser and more rigidly developed standards, and could lead to improved retention of resources.

Shopping for standards vs. building them in-house

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 is to identify a solution that truly fits your business, so that programmers will feel enabled, rather than burdened, by the standards. This may involve an internal search for running applications that are well regarded by the maintenance and support teams, and then reaching out to the supplier. You may also 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.

Frank Burger, principal engineer, Avanceon. Edited by David Miller, Content Manager,Control Engineering, CFE Media and Technology,dmiller@cfemedia.com.Avanceonis a Control Engineering content partner.

MORE ANSWERS

Keywords: PLC standards, PLCs

CONSIDER THIS

How can youuse these strategies to develop PLC standards that best suit your organizations needs?

Do you have experience and expertise with the topics mentioned in this content? You should consider contributing to our CFE Media editorial team and getting the recognition you and your company deserve. Clickhereto start this process.