Production Data in Brownfield Environments: Why Machine Connectivity Is Rarely the Real Problem

KNOWLEDGE | Industrial Data

Connecting a machine is rarely particularly difficult.
There is usually some way to get to the data. OPC UA, Modbus, S7, a proprietary interface or, if necessary, an additional gateway.

The more interesting question starts afterwards:

What information do we actually need – and which problem are we trying to solve with it?

Because 5,000 available PLC tags do not create reliable OEE. They do not solve traceability. They do not reduce reporting effort. And they certainly do not automatically help production teams or management make better decisions.

The goal is not to connect machines. The goal is to turn production data into reliable, reusable information.

By Martin Waßmann – IT/OT Experts

The machine is rarely the real problem

In many digitalisation projects, the discussion starts roughly like this:

How do we get the data out of the machine?

That is understandable. But it is often the wrong first question. Because in most cases, there is some way to get the data out.
The more interesting questions are:

• What information do we actually need?
• Which business problem are we trying to solve?
• Where does that information come from today?
• Can we trust it?
• Will the same information be needed for other use cases later?
• And will the whole thing still work with 50, 200 or 500 machines?

Take a simple example:

The company wants to automate OEE. The requirement is not:

We need machine data.

It is something more like:

We need to know when a machine is producing, when it is stopped, how much good product and scrap was produced, and which production order is currently running.

That may sound similar. It is something completely different.

More data does not solve the problem

A common approach is:

Let’s collect all the data first. We can decide what to do with it later.

You can do that. Then you have a lot of data.
Congratulations.

But the amount of data does not automatically answer a single relevant business question.
A PLC can easily contain thousands of variables.
For a specific use case, I may need ten of them.
Or five.
Or I may discover that one of the most important pieces of information does not come from the PLC at all.

The current production order may come from the MES.
The quality status from another system.
The target speed from master data.
The machine state may have to be derived from several signals.

Suddenly, the supposed “machine data problem” is no longer really a machine problem.

It is an information problem.

OEE is a good example

OEE is often used because it looks simple.

Availability.
Performance.
Quality.

Three metrics.

What could possibly go wrong?

Quite a lot.

For a reliable calculation, I may need:

• machine states,
• good count,
• scrap count,
• planned production time,
• target speed or ideal cycle time,
• production order context,
• and possibly downtime reasons.

And that is where the interesting questions start.
What exactly does “machine running” mean?
Does automatic mode already mean production?
What happens if the machine is running but no product is being produced?
Which counter is the leading one?
Is scrap recorded immediately or corrected later?
Which target speed applies to which product?
Where does the production order come from?

At that point it becomes obvious:

Accessing the OPC UA server was probably the easiest part of the entire problem.

From a data point to information

A PLC might provide:

DB17.DBD24 = 126

Technically, that is perfectly fine.
But outside the control system, nobody knows what it means.
An application needs something more like:

Packaging Machine 5 → Speed = 126 units/min

And perhaps additional context:

Site → Line → Machine → Production Order → Speed

Only then does a technical data point become information that can be understood outside the system it originated from.
This translation is often underestimated in industrial projects.
And it is one of the reasons why connecting one machine almost always works – while scaling the same approach becomes expensive later.

A pilot can be successful – and still prove the wrong architecture

One machine.

One gateway.

One OPC UA client.

One dashboard.

A graphic appears.

Pilot successful.

So far, so good.

But that tells me very little about whether the approach is suitable for a rollout.
The second machine has a slightly different data structure.
Machine number five comes from another vendor.

Machine 20 does not support OPC UA.

Machine 35 uses the same IP addressing as machine 12.

By machine 50, we discover that the state model from the pilot does not work for a different type of equipment.

And at some point, somebody realises that every new machine still requires hours or days of manual configuration.

A pilot proves that something works technically.
A rollout proves whether it works economically and operationally.

That is a major difference.

The cost comes from repetition

Manual work is cheap for one machine.
It is not cheap for one hundred.
If every new asset means:

• configuring the connection individually,
• searching for variables manually,
• mapping data points one by one,
• correcting names,
• coordinating firewall rules,
• deploying certificates,
• configuring monitoring,
• writing documentation,
• and adapting application X again,

then I do not have a scalable integration model.
I simply have the same project effort one hundred times.
And that is often where the actual business case for a good production data architecture starts.
Not because the data is suddenly transported in a more modern way.

But because the next use case and the next machine do not have to start from zero again.

The second use case is the real test

Assume I have integrated data from a machine for OEE.
Six months later, traceability is added.
Then energy monitoring.
Later perhaps predictive maintenance or an AI use case.

The important question is:

Can I reuse the information I have already made available?

Or does every use case build its own connection to the machine?
If OEE, reporting, MES, analytics and AI each create their own integration, I may have several working applications.
But I do not have a common data architecture.

That works. Until it does not.

This is exactly where a Unified Namespace can become interesting.

Brownfield does not mean old machines

Brownfield is often translated as “old equipment”. That is too simplistic.
A relatively new machine can be brownfield too.
The more important point is:

I have to work with what is already there.

And what is already there is almost always heterogeneous.

Machine A has OPC UA.

Machine B also has OPC UA – but essentially exposes PLC addresses.

Machine C speaks Modbus.

Machine D has to be integrated via S7 communication.

Machine E already publishes MQTT.

And for machine F, the vendor tells you that changes to the control system are not supported.

That is not an exception. That is manufacturing.

Standardisation does not mean making every machine identical

This is where the next common idea appears:

Let’s define OPC UA as the standard and require every machine to support it.

You can do that. It just does not help much if 70 percent of the installed base does not meet that standard.
You cannot design brownfield away. That is why I would not try to force technical uniformity below the information layer.

The machine should be integrated using the most sensible interface available.

That may be OPC UA.
It may be Modbus.
It may be something else.

What matters more is what happens afterwards.

The technical integration may remain heterogeneous. The information provided above it should not.

Or, more simply:

Things can be messy underneath. They should not stay messy above.

OPC UA does not automatically solve the data model

OPC UA is a very useful standard.
But the same rule applies here:

OPC UA available does not automatically mean information understood.

I have seen enough OPC UA servers that work perfectly from a technical perspective and still expose little more than PLC variables with cryptic names.

In that case, I have a modern interface.
The information problem remains.
So the question is not only:

Can we access the data?

It is:

Does an application actually understand what that data means afterwards?

Why OPC UA, MQTT and Unified Namespace solve different problems is explained here.

Different machines, different truths

This is where brownfield becomes interesting.

Machine A provides:

State = 2

Machine B:

Operating = TRUE

Machine C:

Auto = 1
Running = 1
Fault = 0

And machine D does not provide a single clear machine state at all.

But the OEE system expects all of them to provide:

• Production
• Stopped
• Fault
• Planned Stop

So somewhere, technical signals have to become business information.

If every application implements that logic independently, you eventually end up with different versions of the truth.
Reporting says 82 percent.
MES says 77 percent.
The production manager’s Excel file says 85 percent.
And then everybody starts debating which number is correct.

The problem is not OEE at that point.

The problem is that nobody clearly defined what the underlying information actually means.

Where should that translation happen?

As close to the source as reasonably possible.

Not necessarily directly inside the PLC.
But before machine-specific details are passed on to five different applications.

Then:

DB17.DBX2.1

or:

Operating = TRUE

or a combination of three signals can always become the same information:

MachineState = Production

For the applications above, the vendor underneath no longer matters.
And that is where scaling starts to become interesting.

The value is in reuse

This is one of the most important points for me.

Information should not be created for only one use case.

Once a reliable machine state exists, it may be reused for:

• OEE,
• production reporting,
• shift reports,
• alerting,
• energy analysis,
• maintenance,
• analytics,
• AI.

That changes the business case.
I am no longer paying for the same integration again for every new use case.
I am building an information foundation that other applications can use.

That is why Industrial Data is not about collecting as much data as possible.

It is about creating information that can actually be used.

And then network, security and operations enter the picture

Of course, the technology still has to work.
Production data does not magically appear on the internet.

Machines sit in OT networks.
There are firewalls in between.
Certificates have to be managed.
IP addresses are sometimes duplicated.
DNS and NTP are not always a given.
Machine vendors need remote access.
And somebody has to notice when a connection fails.

All of that matters.

But it is still a means to an end.

The business goal is not:

We want a beautiful firewall rule.

The goal is more like:

Production information from 300 machines must be available reliably to several applications.

The architecture has to enable that goal – securely and in a way that can actually be operated.

Scaling also means making it operational

A project team can solve many things manually during a pilot.
That stops working with 50, 200 or 500 machines.
At that point, the question is no longer only whether data arrives. It is also:

• How are new machines integrated?
• How are configurations and certificates managed?
• How do we detect missing data or broken connections?
• Who is responsible for operations and changes?
• How do we add another site?

For me, a production data architecture is therefore not scalable simply because it can theoretically connect 500 machines.
It is scalable when machine 501 is no longer a new project.

A working data flow is not yet a working service.

In the end, it starts with a different question

In many projects, the first question is:

How do we get the data out of the machine?

I would start somewhere else:

Which problem are we trying to solve, and which information do we need for it?

Then:

1. Where does that information originate?
2. How must it be described so that other systems understand it?
3. How can it be provided in a reusable and scalable way?
4. And only then: Which technology do we need?

That sounds obvious.
In projects, this order is still reversed surprisingly often.
The discussion starts with the broker, the gateway or OPC UA – and at some point, the business problem is forced to fit the technology that was already chosen.

That is the wrong way round.

Technology should follow the requirement. The requirement should not follow the technology.

Frequently Asked Questions

Is connecting brownfield machines difficult?

Technically, usually not in principle. The bigger challenge is turning different machines and interfaces into consistent, reliable information that can be used by several applications.

Should we collect all available machine data first?

Usually not. The information you need should be derived from concrete use cases and business requirements. More data does not automatically create more value.

Does every machine need OPC UA?

No. OPC UA is often an excellent interface, but brownfield architectures also have to deal with Modbus, S7, proprietary interfaces and other technologies.

Do I need a Unified Namespace for this?

No. A UNS can be a very useful architectural concept, but it is not an end in itself.
Start with the problem. Then define the information you need. And only then choose the architecture.

About the Author

Martin Waßmann is the founder of IT/OT Experts and supports manufacturing companies with digital strategy, IT/OT integration and scalable production data architectures.

His focus includes brownfield integration, Unified Namespace, MQTT, OPC UA and the question of how technical machine data can be turned into production information that actually creates value.

More about Martin Waßmann