PLC Program Standardization: Layers, Naming, Versions

1. What PLC program standardization is: turning personal habit into an engineering asset

PLC program standardization is the act of narrowing how control programs are written, from individual habit into a structure the team can reuse. Two engineers writing the same packaging machine may differ in tag naming, in how sections are divided, and in how alarms are handled. Three years after delivery, when the original developer has left, the person taking over first spends several days reading the logic before daring to change one interlock condition. That is where standardization pays: structure, naming and documentation follow a shared convention, so anyone can walk the same path to the same place.

The boundary needs to be stated clearly. Standardization constrains how the program is organized and what is delivered; it does not constrain the process itself. Recipes, cycle times and motion sequences still follow the customer's process. Reading it as a restriction on coding style is a common misunderstanding: what gets fixed is the skeleton and the interfaces, and the process logic actually becomes easier to change once the layers are clear. IEC 61131-3:2013 already defines program organization units (POUs), function blocks and global variables. The engineering work is to map those concepts onto project folders, section order and naming rules, not to invent a parallel system.

One practical test: hand the program to someone who did not develop it and ask for a single change, such as adding one station. If that person can find the insertion point inside the existing structure without touching the logic of other stations, the program is standardized. If they have to read the whole thing first, standardization stopped at file naming.

2. How to cut the layers: device, unit, process and common

The purpose of layering is to separate logic that changes at different rates. Device-level motion detail changes with mechanical structure, unit-level coordination changes with line layout, process-level recipes change with product, and the common layer of alarms, permissions and communication rarely changes. Mix those four kinds of logic into one block and every change forces you to re-verify everything.

• Device layer: start and stop, interlocks, limit switches and single-machine fault handling. One function block per device, exposing only four interfaces outward: start, stop, reset and status.
• Unit layer: coordination between stations or machines, such as handshakes, cycle synchronisation and buffer decisions. This layer calls device-layer interfaces only and never reads or writes another unit's internal variables.
• Process layer: recipes, parameter sets and process step sequences. Recipe data lives outside the program in a parameter table or database, so changing a recipe does not require a program download.
• Common layer: alarm classes, operator permissions, clock synchronisation, communication mapping and data logging. Shared once across the project instead of rewritten per station.

On the engineering file level, layering becomes a fixed folder structure and section order: each function block starts with an interface description, then the body logic, with exception handling at the end of the section. Once the convention is set, code review gains a shared language: the reviewer first checks whether interfaces cross layers, then whether the logic matches the process.

A caution: more layers is not automatically better. For a project with a single machine type and small batch counts, four layers add maintenance surface. Keeping device and common layers and writing coordination at the call site is more practical there. Layer granularity should follow equipment repetition, not a template.

3. Naming, tag lists and comments: making it readable for the next person

Naming has the highest return on effort in the whole standardization effort. When the same signal is called M100 in one project, Start_OK in another and X12 in a third, maintenance becomes guesswork. A three-part name fixes equipment, function and sequence, so the name itself says which machine it belongs to, what it does and which instance it is.

The tag list ships with the program, not as an afterthought. At minimum it carries address, data type, range and engineering unit, owning function block, initial value and retentive flag. Analogue signals deserve extra care: if the 4–20 mA to engineering range mapping, the filter time and the wire-break threshold are not written down, the next person to tune it will drift it.

How far should comments go? A workable test is to read the comment on its own: without looking at the code, can you say under what condition this block is called and what happens if it fails? If not, the comment is describing an action name rather than a design intent.

4. Version control, backup and handover acceptance

On-site change is the main source of program drift. A dozen revisions a day during commissioning is normal; without a version record, a week later nobody can say which revision runs on the machine and which was experimental. Version control has to answer three questions: which revision is running, what changed in it, and which revision to fall back to.

• Version numbering: a major number for process or structural change, a minor number for parameters and local logic; the version appears both in the first comment block of the program and on the label inside the cabinet, and the two must agree.
• Archiving rhythm: archive daily during commissioning, then on every change once stable; an archive holds the source project, tag list, comment notes and build log, and a missing item breaks the chain for the next person.
• Change record: note who changed what, when, why and with what impact; changes to interlocks and safety-related logic are flagged separately and reviewed.
• Backup and restore: keep one offline-restorable backup at the machine and one historical set on the server; the validity of a backup is proven by a restore drill, not by the file existing.

Safety-related logic carries additional requirements. ISO 13849-1:2023 sets out a design and verification path for safety-related parts of control systems, and a safety function cannot simply live in an ordinary program section distinguished by a comment. EU Machinery Regulation (EU) 2023/1230 applies from 20 January 2027, and software acting as a safety-related part needs a traceable version and verification record. IEC 62443-3-3:2013 requires control over program modification and access: who may download, who may change parameters, and whether changes are logged belong in the delivery scope, not in the optional extras.

Handover acceptance is best done as a checklist, complete only when all five items are present: the source project and a buildable project, the tag list and comments, version and change records, backup files with restore steps, and one on-site restore drill. The drill is the step most often skipped and the one that exposes the most: a backup file that exists but cannot be restored is not uncommon.