Your machines have been talking for years

Walk into most plants built or refitted in the last fifteen years and the equipment is already producing data. Cycle counts, machine states, alarm histories, temperatures, energy draw. It goes into a SCADA system or a maintenance package, where it is used to diagnose faults and schedule servicing.

And there it stops. The data that could answer how much can we actually make this week never reaches anybody who has to answer that question.

Why the data does not travel

Different owners. The controls engineer owns the machine data. The planner owns the schedule. They rarely have a reason to talk, and neither is asked to bridge it.

Different vocabularies. The machine knows cycles, states and faults. The planner needs orders, parts and hours. The translation between them exists only in somebody’s head.

Security, correctly. Nobody wants the production network exposed, and IT and OT are separated for good reasons. The usual result is separation implemented as no connection at all, which is safe and useless.

The projects are large. Connecting machine data to business systems is sold as a platform programme with a consultant attached, so plants below a certain size never start.

What is actually available

More than most planners think, and it does not require replacing equipment.

Cycle counts. How many pieces the machine has actually made. Booking data that nobody has to enter, available continuously.

State and stoppage. Running, idle, faulted, changing over. This is where the real capacity question lives, and it is where the difference between the standard time and the achieved time comes from.

Alarm history. Which faults recur, on which machine, at what time of day. Frequently the clearest explanation of why a particular line always misses on Mondays.

Energy. Increasingly instrumented for cost reasons, and a good proxy for whether something is actually running when nobody is looking.

That is enough to answer the planning questions. It is not enough to run the machine, which is fine, because nothing here should be running the machine.

Read-only is the whole design

Reading from equipment is an integration problem. Writing to it is a safety problem, and they should not be discussed as though they are two settings of the same feature.

Anything capable of actuating machinery falls under machinery and functional-safety obligations, with assessment, documentation and change control that a planning system cannot honestly claim. So the boundary is drawn in the architecture rather than in a configuration option: signals come in, nothing goes out, and no update to a business system can ever move an axis.

That constraint also makes the integration far easier to approve. A read-only connection through a one-way path is a conversation an OT engineer can have without a project board.

Where to start

One machine, one signal, one question. Take the line everybody argues about, read its state, and compare the achieved throughput against the standard time being used to schedule it.

That single comparison usually settles an argument that has been running for years, and it is a week of work rather than a programme. Everything else in this direction is easier to justify once somebody has seen that number.