Keg tracking and line analysis for a brewery group

Situation

A keg line runs kegs through washing, filling and palletising, with robots and a handful of PLCs coordinating it. All of that produced data, and none of it was kept. Two questions had no answer.

Where are the kegs? Kegs are assets that leave the site, come back dirty, and get refilled for years. Knowing how many are in circulation, which came back and which did not, is inventory that walks out of the door.

And why did the line stop? Everyone knew it had stopped. Whether it was a robot fault, a jam, or a changeover, how often, and for how long, was recalled rather than measured.

What I built

A browser where engineers assemble data flows. Rather than commissioning a fixed integration per device, the edge application presents a library of blocks that get wired together on screen: read from a Siemens S7 PLC, a Modbus TCP device or an OPC UA server; decode and reshape the payload; downsample it; then archive it, forward it, or print a label on a Zebra printer. Adding a machine is a configuration change an engineer makes, not a project that waits for me.

Blocks that know the domain sit alongside the generic ones — keg events and keg inventory are first-class, as are robot and HMI blocks, so a new line gets keg counting without anyone writing keg logic again.

Storage that survives the network. The pipeline writes to a time-series service that presents one interface over InfluxDB and TimescaleDB. It runs on site, so a lost uplink stops nothing; readings queue and reconcile when the link returns. Rather than one process doing everything, each data source gets its own supervised worker, so a device that starts misbehaving takes down its own pipeline and nothing else.

Analysis over production periods. The reporting application lets someone choose a period — a shift, a run, a batch — and analyse it. It reconstructs when the line was genuinely producing versus stopped, attributes each stop to the robot alarm or HMI event that caused it, and nests periods inside each other so a shift can be opened up into the runs it contains. Analyses run in the background and are kept, so a number quoted in a meeting can be traced back to the events it came from. Anyone who prefers Grafana gets the same data through a datasource plugin.

Outcome

Keg inventory is counted rather than estimated, and stoppages are discussed from a record instead of from memory.

The split of runtimes is deliberate. The edge software is .NET, where per-device supervision suits hardware that fails independently and constantly. The reporting side is Rails, where the questions change every few weeks and the modelling has to keep up. Working in both meant each end got the tool that fits it.