Decades of custom work created a naming crisis in production automation

Every time a new machine, line, or system was added to a facility without a consistent naming convention or equipment model, the facility accumulated what might be called structural debt. Not technical debt in the software sense, but something more physical: a plant where a temperature reading in one area is named entirely differently from an equivalent reading three hundred metres away, and where nobody at the site can explain why.

This pattern appears consistently when automation engineers attempt to prepare a facility for data-driven work.

In the best cases, it means an expensive mapping exercise. In the worst cases, it means sending engineers to walk the production floor line by line, matching readings to physical equipment by process of elimination.

As Lars Linnet, Product Director at Au2mate, describes it:

“Just the step of doing that work of mapping out your data can just be so time-consuming, and therefore, so expensive that the whole business model can actually fall apart.”

The optimisation project stalls not because the tools were wrong, but because the foundation was never built.

Data standards exist precisely to prevent kaos

ISA-88, the batch process standard that defines a common language for equipment hierarchy and process structure, was developed specifically to solve this problem. It gives facilities, suppliers, and system integrators a shared model for how a production site is described: from the site level down through areas, process cells, units, and individual equipment modules.

When that model is applied consistently, a facility gains something that sounds mundane but is genuinely valuable: every data point has a known address:

A tank temperature in the cheese production area has a name that reflects where it sits in the physical hierarchy, and that name is consistent whether it was installed five years ago or five months ago.

This is what makes AI-driven optimisation feasible. Not the algorithm, and not the sensor density. The address book.

The argument that standards are a compliance burden gets the situation precisely backwards. Compliance is the floor. A consistent equipment model and naming convention is the infrastructure that makes every future investment in data, automation, or optimisation worth making.

The counter-argument: we are already running

The objection most frequently raised is a quite reasonable one. A facility that is already producing has no obvious stopping point at which to retrofit a structural model. Bringing in engineers to re-map and re-label a running plant is expensive, disruptive, and hard to justify on a quarterly basis.

This is fair, and it is not an argument for bulldozing everything and starting again. Linnet is explicit about this: “If you have a working plant, there is no benefit of just redoing everything just for tidying up.”

But the objection does not apply to projects that have not started yet. Every new line, every new supplier engagement, every MES upgrade is a decision point. The question is whether the structural model gets built in from the beginning, or whether it gets deferred again, adding to the debt that will eventually make the next optimisation project just as expensive as this one.

To get startet, you want to look at the problem from a pragmatic point of view. Begin with the next project and insist on the model. Build it into the user requirements so that every supplier who comes to the table is working from the same language. Over time, the facility becomes readable.

What is actually at stake

The decimal optimisation argument is often made in dairy: even a 0.05% improvement in raw milk yield, across the volumes a mid-sized dairy processes, translates into tens of thousands of euros annually. And these numbers are real. The question is whether the infrastructure exists to identify and act on those improvements.

Without a consistent structural model, a facility is running blind. The data exists. The sensors are there. The readings are being logged somewhere. But the facility cannot act on them at scale because it cannot reliably interpret them.

The production managers and engineering teams who treat standards as the foundation of their data strategy, rather than a documentation task to be completed after the fact, are the ones who will be positioned to act when the tools catch up. The ones who defer will find that the mapping project they avoided five years ago is now larger, more expensive, and more urgent than it ever needed to be.

The data problem is not a data problem. It is a decision that has been postponed, one project at a time, for years. The good news is that the next project is another opportunity to start building the foundation that makes everything else possible.