PLC Coding Standards: From Naming to a Reusable Library

1.Why naming conventions alone are not a standard

Almost every team that decides to "standardise" starts with prefixes. bMotorRun, iCounter, rPressure — agreed in an afternoon, written into a one-page document, and then quietly eroded over the next two projects.

The reason it erodes is not laziness. It is that a prefix table answers the smallest question a standard has to answer. It tells you what to call a variable. It says nothing about what a function block must expose, who is allowed to change a library block, or what happens when a project needs a variant of something that already exists.

Those are the questions that decide whether a second engineer can pick up the project — and they are the ones that get skipped because they require decisions, not conventions.

2.The four layers of a workable standard

2.1.Layer 1: Naming that scales

Prefixes for data types are the entry level and worth having. The detailed table lives in the PLC programming best practices article; the part that matters for a standard is what comes after the prefix.

Three rules carry most of the value:

Name by function, not by hardware. bConveyor3Run survives a change of motor supplier. bSEW12345Run does not. The tag outlives the component.

Mirror the plant's own tag system. If the P&ID calls it M-301, the software should carry M301 in the name — not a second, parallel naming universe that only the programmer understands. This single rule saves more time during commissioning than any other.

Encode scope, not location in code. A tag's name should say what it belongs to (Conveyor3_MotorRun), not where it happens to sit (DB12_Bit3). Structure moves; meaning does not.

2.2.Layer 2: The block interface contract

This is where a standard earns its keep. For every reusable function block, decide once and write down:

• What is mandatory on the interface? Most house standards require at minimum an enable, a fault output and a status word. If every block exposes the same shape, higher-level logic can treat them uniformly.
• Who owns the instance data? Instance DBs belong to the calling level, not to the block author.
• What is the block allowed to touch? A reusable block that writes global memory is not reusable — it is a landmine. The rule "a library block reads and writes only through its interface" is the single most valuable line in most standards.
• How are faults reported? Pick one mechanism and apply it everywhere. Many teams use a status word aligned to NAMUR NE 107 so that diagnostics look the same across the whole plant.

(*
  Interface contract for every library block in this standard:
    IN   : bEnable          — no action while FALSE
    IN   : stConfig         — all parameters, no magic numbers inside
    OUT  : bReady, bFault
    OUT  : wStatusNAMUR     — uniform diagnostics across the plant
  The block reads and writes nothing outside this interface.
*)

This is what it looks like in a real project — the group numbers order the blocks by plant section, and the drive block carries exactly the interface specified as a contract above:

2.3.Layer 3: A library, not a folder of copies

The difference between a standard and a habit is whether the blocks live somewhere with a version.

• One source of truth. A library block exists once. Projects reference it; they do not copy it.
• Versioning with release discipline. A library version is released, not edited. If a project needs a change, it either gets a new library version or a project-specific block that is explicitly marked as such.
• A changelog per block. Not a project changelog — per block, because that is the unit that gets reused.
• An explicit exception path. Every standard gets violated eventually. A standard that has no defined way to deviate gets deviated from silently, which is the worst outcome. Write down who approves an exception and where it is recorded.

2.4.Layer 4: Enforcement that does not slow anyone down

A standard nobody checks is a document, not a standard. Three levels of enforcement, in increasing order of effort:

Tooling. TIA Portal v18 and later ships a Code Quality Check that flags naming-convention violations automatically. It will not check your interface contract, but it removes the most tedious part of a review for free.

Review checklist. Five to seven yes/no questions, not a treatise. Does every library block go through its interface only? Does every non-obvious constant have a source? Is the fault mechanism the standard one? A checklist that takes ten minutes gets used; one that takes an hour does not.

Automated structural checks. With TIA Openness, a project can be exported to a text format and checked programmatically — block naming, interface shape, forbidden global access. This is worth building once the library is stable, not before.

3.What a standard should deliberately not do

Over-standardising is a real failure mode, and it is harder to undo than having no standard at all.

• Do not standardise the language per block type. Choose per task — the standard should say how to justify the choice, not dictate it. Which language suits which task is covered in the five IEC 61131-3 languages.
• Do not prescribe internal implementation. The contract is the interface. How a block solves its job internally is the author's business.
• Do not freeze the standard. A standard that has not changed in three years is not stable; it is unused.

4.A note on "Top 20 Secure PLC Coding Practices"

If you have searched for PLC coding standards, you have probably encountered this list. It is worth knowing what it is — and what it is not.

It is a community-driven initiative focused specifically on security hardening of control logic: input validation, plausibility checks, monitoring for unexpected values, restricting what the PLC accepts from outside. Genuinely useful, and increasingly relevant with the EU regulatory direction on machinery and cyber resilience.

But it is a different axis from what this article covers. It answers "how do I make my logic harder to abuse", not "how do I make my project maintainable by the next engineer". A team needs both, and neither replaces the other. Treating the security list as a general coding standard leaves the maintainability questions unanswered.

5.Introducing a standard into an existing plant

The most common reason standards never happen: the existing code base is too large to convert, so nothing starts.

The way that works is to not convert anything:

1. Apply the standard to new blocks only. From today, everything new follows it. Nothing old gets touched.
2. Convert on contact. When a block has to be modified anyway, it gets brought up to standard as part of that work. Over two or three projects this covers the blocks that actually matter — the ones that get touched.
3. Never convert for its own sake. Rewriting a block that has run untouched for eight years introduces risk and buys nothing. The blocks nobody touches are the blocks nobody needs to read.
4. Document the boundary. A one-line note per block stating whether it follows the current standard prevents the next engineer from guessing.

This costs nothing up front and compounds. A full-conversion project, by contrast, tends to stall halfway and leave a code base with two standards instead of one — measurably worse than where it started.

6.Conclusion

• A prefix table is not a standard. The interface contract is where maintainability is decided.
• Name by function and mirror the plant's tag system — the tag outlives the component.
• A library with versions and a changelog turns a habit into a standard.
• Define the exception path, or deviation happens silently.
• Introduce it on new and touched blocks only. Full conversions stall; incremental adoption compounds.

7.Further reading

• PLC Programming: 8 Best Practices for Clean, Maintainable Code – the foundations, including the full prefix table
• PLC Documentation: What Belongs In It and What Matters at Handover – how a standard shows up in the handover
• The 5 PLC Programming Languages of IEC 61131-3 – choosing per task instead of standardising the choice away