MWL Automation Note
In the last Automation Note, I argued that working code and maintainable code are not always the same thing.
A machine can run perfectly well while its control program slowly accumulates inconsistent naming, one-off logic, old comments, startup modifications, and those famous “temporary” fixes that somehow earn permanent residency.
One of the best ways to reduce that technical debt is standardization.
But there is an important point I want to add:
Standardization should not start with the PLC program. It should start with the engineering drawings.
For controls engineers and process control engineers, much of our software is ultimately controlling physical equipment. Motors, valves, cylinders, sensors, drives, pressure switches, flowmeters, laser sources, chillers, gas systems, motion axes, and hundreds of other devices already exist in the engineering documentation before we write the first rung of ladder logic or line of structured text.
That documentation should establish the vocabulary of the machine.
One Machine Should Not Have Three Names for the Same Device
Imagine an exhaust fan identified on the electrical drawing as EF-101.
The PLC programmer calls it ExhaustFan_1.
The HMI programmer calls it FumeFan.
The alarm message says Dust Collector Blower Fault.
The maintenance documentation calls it Main Extraction Fan.
Technically, all five descriptions might be correct.
Practically, we have created a translation exercise for the technician standing beside a machine that is not running.
That technician probably does not want a vocabulary lesson at 2:00 a.m.
A better approach is to establish a device identity during engineering and carry that identity through the machine:
Drawings → hardware identification → PLC/DCS → HMI → alarms and diagnostics → historian/event records → maintenance documentation
The syntax may need to change between systems. A CAD package might allow EF-101, while a PLC platform may require EF_101. That is fine.
The important thing is that EF-101 still means EF-101 everywhere.
This idea is consistent with established engineering standards. IEC 81346-1 provides principles for structuring systems and creating unambiguous reference designations, recognizing that a reference designation can serve as a key to finding information about the same object across different documents. The newer IEC 81346-14:2026 extends those concepts specifically to manufacturing and processing systems. IEC 61082-1 addresses the preparation and presentation of electrotechnical documentation, while ANSI/ISA-5.1 provides standardized methods for identifying instrumentation and control functions. [1–4]
None of these standards magically creates a good machine standard. But they reinforce an important engineering principle:
Give an object a meaningful identity and preserve that identity throughout its lifecycle.
The Drawings Become the Foundation
This changes how we think about a controls programming standard.
Instead of the controls engineer receiving drawings and then developing an entirely separate naming system, the drawings become part of the controls standard.
Equipment names, device descriptions, I/O descriptions, instrument identification, and reference designations should be established early enough that they can flow downstream into the software.
If the drawing says Shielding Gas Pressure PT-201, the controls engineer should not have to decide whether the PLC tag will be GasPress1, Pressure_Input_7, or the always-popular Tag_37.
Tag_37 may work perfectly.
Six years later, however, troubleshooting it may require an archaeological permit.
The same principle applies to descriptions. If engineering calls something the Powder Feeder, programming should probably not rename it the Material Delivery Unit unless there is a good reason.
Consistency reduces mental translation.
And mental translation is one of those small things that does not look expensive on a project schedule but becomes very expensive when people troubleshoot equipment for the next fifteen years.
Then Standardize the Software Around the Hardware
Once the machine vocabulary is established, software standardization becomes much more powerful.
Common devices should have common software structures.
A motor should present familiar commands, status, permissives, interlocks, alarms, manual controls, and diagnostic information. A valve should follow a recognizable pattern. Drives, analog instruments, cylinders, process devices, and other recurring equipment should work the same way wherever practical.
The implementation will vary by platform. One PLC may use function blocks, another Add-On Instructions, another functions and structures, and a DCS may use control modules.
The architecture matters less than the principle:
Make the common parts common.
That has been a recurring theme in my thinking about modular PLC programming. Reusable structures reduce duplicate engineering, but their bigger long-term advantage may be familiarity.
When a controls engineer opens an unfamiliar machine, familiar structures provide landmarks.
Standards such as ISA-88 demonstrate the value of common terminology, models, data structures, and modular organization, while OMAC’s PackML work applies similar thinking to machine states and behavior. IEC 61131-3 provides standardized programming-language concepts for programmable controllers. [5–7]
You do not have to implement every one of these standards to benefit from the thinking behind them.
Standardize the Troubleshooting Experience Too
Standardization should continue beyond the code.
If every motor has a standard diagnostic structure, give every motor HMI object a predictable diagnostic view.
If a device cannot start because three permissives are missing, show the technician the three missing permissives.
If an interlock stopped the machine, identify the interlock.
If a sequence is waiting for something, show what it is waiting for.
And alarms deserve the same discipline.
An alarm such as:
ALARM 327 — DEVICE FAULT
is technically an alarm.
It is not particularly helpful.
Something like:
EF-101 Exhaust Fan — VFD Fault — Reset Drive and Verify Ready
has a much better chance of helping somebody solve the problem.
IEC 62682 and ISA-18.2 formalize alarm-management practices around meaningful, manageable alarm systems and their lifecycle. IEC 62682 also explicitly includes alarm and event logs, historians, and performance information within the alarm-system framework. [8]
Again, the practical lesson is consistency.
The device identity that started on the drawing should survive all the way to the alarm history.
Standardization Does Not Mean Making Every Machine Identical
There is a danger here.
A standard can become so rigid that engineers spend more time fighting the standard than engineering the machine.
Laser cutting, welding, cladding, heat treatment, and additive manufacturing systems can have very different process requirements. Motion architectures differ. Laser/process synchronization differs. Safety requirements differ. Sequence logic differs. Process parameter handling can differ dramatically.
Those things should not be forced into identical structures simply because somebody wrote a programming standard five years ago.
Standardize what is genuinely common:
device identification, drawing conventions, tag structures, equipment modules, common states, alarms, diagnostics, HMI navigation, permissive and interlock presentation, revision practices, backups, and documentation.
Then leave room for the application-specific engineering that makes the machine actually work.
Standardization should remove unnecessary engineering work, not prevent necessary engineering work.
Standards Also Need Maintenance
There is one more trap.
A company creates a programming standard.
Everyone celebrates.
The document goes into a folder.
Five years later, the machines have changed, the PLC platform has changed twice, three engineers have added their own improvements, and nobody is completely sure which version is the standard.
Congratulations. We have standardized our inconsistency.
Reusable software libraries, drawing templates, HMI objects, alarm conventions, and device definitions need revision control just like production software.
When a better motor module is developed, decide how it becomes the new standard. Document the change. Test it. Control the revision. Determine whether existing machines should receive the update during future upgrades or whether the change applies only to new projects.
This is where practical standardization and technical-debt management meet.
There Is Also an AI Angle
There is a lot of discussion about AI eventually helping technicians troubleshoot industrial equipment.
Maybe it will.
But an AI system will have the same fundamental problem a human technician has if the machine information is inconsistent.
If the electrical drawing says EF-101, the PLC says ExhaustFan_1, the HMI says Fume Fan, and the alarm historian says Blower 3, software first has to determine whether those are four devices or one.
Consistent device identities, meaningful descriptions, standardized machine states, structured alarms, good event histories, and maintained documentation make machine information more useful today.
They will also make it far more useful to future diagnostic tools.
In other words, preparing machine data for AI may begin with something much less glamorous than artificial intelligence:
good drawings and good tag names.
Make the Common Parts Common
The goal of standardization is not to make every machine identical.
The goal is to create a common engineering language from the drawings through the software and all the way to maintenance.
When the electrical engineer, controls engineer, HMI developer, process engineer, technician, and historian all recognize the same device by the same identity, troubleshooting gets easier.
When common equipment behaves in common ways, programming gets easier.
When alarms and diagnostics follow recognizable patterns, maintenance gets easier.
And when the next engineer opens the project five years from now, they have a much better chance of understanding what we were thinking.
That may be one of the best tests of a good standard.
Standardize the boring parts so engineers can spend their time engineering the interesting parts.
References
- IEC 81346-1:2022, Industrial systems, installations and equipment and industrial products — Structuring principles and reference designations — Part 1: Basic rules. International Electrotechnical Commission.
- IEC 81346-14:2026, Industrial systems, installations and equipment and industrial products — Structuring principles and reference designations — Part 14: Manufacturing and processing systems. International Electrotechnical Commission / International Organization for Standardization.
- IEC 61082-1:2014, Preparation of documents used in electrotechnology — Part 1: Rules. International Electrotechnical Commission.
- ANSI/ISA-5.1-2024, Instrumentation and Control — Symbols and Identification, together with ISA-TR5.1.02-2024, Instrumentation and Control — Identification System Guidelines. International Society of Automation.
- ISA-88.00.01-2010, Batch Control — Part 1: Models and Terminology, and ISA-TR88.00.02-2022, Machine and Unit States: An Implementation Example of ISA-88.00.01. International Society of Automation.
- OMAC, PackML implementation resources and guidance. Organization for Machine Automation and Control.
- IEC 61131-3:2025, Programmable controllers — Part 3: Programming languages. International Electrotechnical Commission.
- IEC 62682:2022, Management of alarm systems for the process industries. International Electrotechnical Commission. ANSI/ISA-18.2-2016 remains the current listed ISA standard in the ISA-18 series.