Coding Guidelines For Qualitative and Standardized PLC Programming

Coding Guidelines For Qualitative and Standardized PLC Programming

Can we bring more discipline to PLC programming in industrial control?

Discussion swirls at every gathering of automation professionals about the new generation of engineers entering (we hope) the industry. One thing for sure, the new generation begins with a much deeper computer science background than any before. Will they want to continue to code programmable logic controllers (PLCs) in the same relay graphical representation as their predecessors? Even the Structured Text language popular in Europe and other places can string together like an old BASIC program.

I am guessing they will bring more discipline to the craft of coding industrial control than ever before. Evidently PLCopen, the organization devoted to developing standards for PLC programming, does also. It has just announced a new set of coding guidelines.

The organization notes in its press release, “Software is becoming increasingly responsible, complex, and demanding. This does not come without its challenges. Due to the greater complexity, programs are more difficult to maintain, more time consuming, and potentially therefore more expensive. This is why quality is taking such an important role these days.”

Continuing, they note, “Unlike in other industries, such as that of embedded software and computer science, there has not previously been a dedicated standard for Programmable Logic Controller (PLC) programs. This has meant that programs were not measured against anything and were often of a poor quality. But that’s where the independent association PLCopen has come in and set the standard with the release of their coding guidelines. These guidelines are a set of good practice programming rules for PLCs, which will help to control and enhance programming methods within industrial automation.”

PLCopen, whose mission is to provide industrial control programming solutions, collaborated with members from a number of companies in different industries to create these coding guidelines. These companies include PLC vendors such as Phoenix Systems, Siemens, and Omron, to software vendors such as Itris Automation and CoDeSys, and educational institutions such as RWTH Aachen. These guidelines were inspired by some pre-existing standards from other domains such as IEC 61131-3, JSF++ coding standard and MISRA-C, and they are the product of three years of work by the working group. PLCopen’s reference standard can be used for testing the quality of all PLC codes, independent of brand and industry.

PLCopen’s coding guidelines are made up of 64 rules, which cover the naming, comments and structure of the code. By following these guidelines, the quality of the code will be improved and there will be greater consistency amongst developers. This will result in greater efficiency, as better readability means a faster debug time, and a program that is easier to maintain. This then results in lower costs as less time is required in order to maintain the program, and the maintenance should be easy enough for both an internal or external programmer as the code will be more straightforward. If the original developer fails to follow certain guidelines when creating a program, this could obstruct other developers and maintenance teams when working with the code during the product lifecycle, thus creating delays and additional costs.

In safety-critical industries, there is the standard IEC 61508 which in 2011 was also extended to PLCS. However, as quality is becoming an ever more important factor across the board, as programs become bigger and more complex, it is generally good practice to follow a set of rules or a standard in all industries. PLCopen’s coding guidelines suggest a standard that can be used across all industries to greatly improve the quality of the code and, as a result, to help companies save time and money. The introduction of such a standard will allow PLC programs to be verified not only from the simple functionality perspective but also from a coding perspective by confirming that good practice programming rules have been followed in their creation. Consistency across PLC programs can only be achieved through the respect of a global corporate or industrial standard, with PLCopen now being the de facto standard in the automation industry.

With quality playing a greater role in industry and with companies always looking for cost saving methods, the answer is to use some sort of standard or set of rules in order to meet these goals. PLCopen have created this standard to improve quality and consistency across PLC programs and so that individual industries and companies don’t have to go to the effort of creating a set of rules themselves. In addition to the internal benefits, this standard will also allow companies to enforce their quality requirements on suppliers, software contractors and system integrators. The only issue for now is that the process for verifying these rules is done manually by most users as they are unaware that some tools are available to do this automatically. But overall, following a standard such as the one proposed by PLCopen, will greatly improve the quality of the program and will save time and money throughout the whole duration of the product lifecycle.

The PLCopen coding guidelines v1.0 are available to download for free from the PLCopen website.

OPC Foundation and OMAC Collaborate For IIoT Machine Communication

OPC Foundation and OMAC Collaborate For IIoT Machine Communication

September 14-15 found me back in Chicago for the International Manufacturing Technology Show (IMTS) and an IIoT conference sponsored by OMG and IIC. I’ll have several reports even though I fly to Sacramento Sunday for the Inductive Automation Ignition Customer Conference. (I’m writing this on Friday, but it may not get posted.)

Thomas BurkeTom Burke, OPC Foundation President and Executive Director, stopped me as I walked the aisle. He talked about the cool things happening with OMAC. I do not know the technical details, but OMAC wishes to specify (not sure of exact technical term) OPC UA into its PackML as its communications protocol.

Turns out this is much more significant than I gleaned from the press release. By the time I waded through the marketing general statements, I gave up on reading the rest. For some reason, marketing and/or PR people seem to want to hit every buzz word in the beginning of a release in order to show relevance or something and then bury the good stuff almost off-hand in the bottom of the text.

This is a significant advance for interoperability. There remains a stance in the industry for point solutions that may be based on open standards, but are explicitly not interoperable—everything is held within the kimono, so to speak. Interoperability benefits an entire industry. The more that end users buy according to interop, the faster the pace of adoption will be.

IIoT and Pack Expo

Look for OPC Foundation (booth N-4702), PLC Open (booth N-4703), and OMAC (booth N-4800) at Pack Expo the first week of November. Be sure to vote first! Personally, I am torn between going to a single-supplier event or this one. Both are too expensive for the lone entrepreneur. I’ll wind up with one, though.

The OPC Foundation provided a couple of bullet points about its news:

  • the results of joined collaboration between OPCF with OMAC about PackML mapping into OPC UA namespace
  • the results of joined collaboration between OPCF and PLCopen about IEC61131-3 PLCopen Client FB to allow initiating an OPC UA connection from inside the controller


Here is the news from OMAC. “The Organization for Machine Automation and Control (OMAC), OPC Foundation, and PLCopen are working together to help advance communications protocols necessary for the Industrial Internet of Things (IIoT) to succeed.

Interoperability among devices and machines that use different protocols is a significant challenge in realizing the full potential offered by the Industrial Internet of Things. By collaborating on companion specifications to the standards and protocols they’ve already developed OMAC, OPC Foundation, and PLCopen can advance the quality and efficiency of data sharing and communication at the machine and production line and up through the enterprise. Collaborative efforts by standards organizations, such as OMAC, OPC Foundation, and PLCopen, align with the Industrial Internet Consortium’s goal to ultimately identify and define building blocks for interoperability that make smart factories and IIoT possible.

“Standards are needed to support communications from machine-to-machine and from the plant floor to interfaces that will allow large scale data analytics and information transfer,” says John Kowal, a member of OMAC’s Board of Directors, co-chair of the Industrial Internet Consortium’s Smart Factory Task Group, and business development director for B&R Industrial Automation Corp. “It just makes sense for these organizations which have individually done so much to advance automated manufacturing to collaborate and avoid redundant developments.”

Here’s how the three automation standards leaders are bringing their efforts together. One of OMAC’s major initiatives has been promotion of the ISA-TR88.00.02 automation standard commonly known as PackML. The second generation was released last year. Manufacturers and machine builders worldwide have implemented ISA-TR88 on various control platforms to increase speed to production, ease packaging line integration and improve reliability. While PackML defines machine modes, states and tag naming conventions, it does not specify a communications protocol.

The OPC Foundation’s Unified Architecture (OPC UA) is an industrial interoperability framework. It delivers information modeling with integrated security, access rights, and all communication layers to provide plug and play machine-to-machine (M2M) communication inside factories. It is scalable across the plant floor and from sensor to IT enterprise and cloud scenarios. OPC and PLCopen recently worked together to define a set of function blocks to map the IEC 61131-3 global standard for industrial controls programming to the OPC UA information communication model. The latest version was released earlier this year. IEC 61131-3 is the only global standard for industrial control programming and is recommended by OMAC in its Packaging Guidelines document.

To take their efforts to the next level, OMAC and the OPC Foundation have established a taskforce to develop a companion specification for ISA-TR88/PackML and OPC UA by the end of 2016. The task force led by Sari Germanos, open automation manager for B&R Industrial Automation, includes members of OMAC and OPC Foundation from around the world. Participation is open to interested members of either organization.

“A standard communication protocol, used consistently across the industry, is vital for realizing the full benefits of automation standards such as ISA-TR88, which then can be a valuable data source for smart factories and the IIoT,” says Dr. Bryan Griffen, OMAC Chairman and Nestlé Group Engineering Manager. “A companion specification between ISA TR88 and OPC UA fills this need and builds on the work completed with PLCopen earlier this year. The opportunities to transform manufacturing as hardware and software solutions are integrated through consistently applied, standardized protocols are extraordinary. We’re pleased to be a part of those efforts worldwide.”

“Today, there is more reason than ever to believe that communications standards will proliferate, as the IIoT drives the need to flatten network communication architectures,” says OPC Foundation Director Thomas Burke. “Along with organizations like OMAC and PLCopen, we’re actively engaged to do just that.”

“By collaborating and ensuring the standards we’ve developed work together we ensure transparent and fully secured communication right out of the box with standardized access between any OPC client and server via a secure channel, independent from network architecture and protocol or machine type and controls,” says PLCopen Managing Director Eelco van der Wal.


Follow this blog

Get a weekly email of all new posts.