SHOP FLOOR
From the machine to data you can work with
The lines run. The numbers sit in the controller, in logs, or nowhere. I pick them up there and make them usable in the day-to-day — for the shift, maintenance and IT.
Who this is for
Plant leads, maintenance, and the people between OT and IT. Not a data-science pitch. The point is a number in the morning meeting that someone trusts.
The path, in plain language
The controller — often Siemens — speaks its own language. In between you need a calm path. Often that is small messages from the machine (MQTT): who reported what, and when. At the end, a table or a screen the shift understands. Not a toolkit museum.
PRACTICE · ANONYMISED
Fault-finding inside the PLC program
- Situation
A Siemens S7 controller reported faults, but the path to the cause ran through the program's STL export — hundreds of networks that only a few people in the company could read.
- Built
The export was parsed into a structured form and analysed by a language model: which blocks intervene where, which conditions hang on the reported fault.
- Result
A detailed fault report in plain language that maintenance and controls engineering could work from together — without anyone stepping through the program network by network.
What you get
You see what the machine is doing without someone walking a USB stick across the hall. Completeness belongs in the work — a pretty chart on missing signals helps no one.
How we start
We clarify which machine, which signal, who needs the number. Then a bounded pilot: one path you can touch. Scale only if that holds.
Questions plant managers ask
Where is the bottleneck of the line?
It only shows once cycle times, stoppages and fault messages per station sit on one timeline. That is what I build first: a path that collects these signals cleanly and completely. The bottleneck then stops being a guess from the morning meeting and becomes a station with a number behind it.
How can I optimise production?
Not with a big programme, but with the question that costs the most right now: changeover times, micro-stops, scrap at one station. Once the data is reliable, measures can be tried and checked on screen the next day. Optimisation becomes a loop, not a project.
Which component causes the most downtime?
That needs fault messages with timestamp, duration and component — from the controller, not from paper. Then it is an analysis: downtime per component, sorted. Often it is not the component with the most messages but the one with the longest.
Do I need a new system for this?
No. The signals come from the existing controller; in between, a small robust path is enough — often MQTT — and at the end an analysis the shift understands. If an MES comes later, this path is the foundation, not a throwaway.