---
title: "Three plants, one operations view | B&C Associates"
description: "Machine data across three plants lived in three incompatible systems and a shift supervisor notebook. We put one number in front of the plant manager and made the reason for every stop a tap on a tablet."
language: "en"
canonical: "https://bcass.net/work/plant-telemetry"
---

# Three plants, one operations view

_Metal forming · 3 plants · 41 machines_

Machine data lived in three incompatible systems and a shift supervisor notebook. We put one number in front of the plant manager, and made the reason for every stop a tap on a tablet.

## The situation

A pressed metal parts manufacturer with plants in Italy and Romania. Each plant reported output weekly in a spreadsheet, compiled by hand on Monday morning from paper shift logs. The question "which machine cost us the most last month" took two days to answer, and the answer was an opinion.

The machines came from four vendors across three decades. The newest lines ran Siemens S7-1500 controllers. The older ones ran S7-300. Two lines had no controller network at all. One press had a single useful output: a dry contact on the cycle counter.

## What made it hard

- No new PLC programming. The machine builder warranty forbids it on two of the lines, and nobody was willing to test that clause.
- The plant network is not routable to the internet, by policy, and that policy was not up for discussion.
- The operators would not accept anything that added more than about ten seconds to handling a stop. Anything slower gets ignored, and ignored data is worse than no data.
- A site losing its internet connection for a day had to cost nothing. Not a gap in the history, not a lost shift.

## How we built it

1. **Read one machine** (Weeks 1 to 2)
   We connected to a single S7-1500 over OPC UA, read only, and proved the cycle signal matched what an operator counted by hand across a full shift. Until that matched there was no point building anything on top of it.
   You get: A signed off signal map for one machine, and a written list of what could not be read at all.

2. **The edge gateway** (Weeks 3 to 6)
   One small industrial PC per plant. OPC UA where the controller offered it, Modbus TCP for the two older lines, and a 24V digital input card for the press with the dry contact. The gateway buffers locally and forwards when the link is up.
   You get: Three gateways installed, 41 machines reporting, and a fourteen day local buffer at each site.

3. **Downtime reasons** (Weeks 7 to 9)
   A tablet at each line. When a stop passes ninety seconds the screen asks why, with eight buttons the plant chose itself and a free text field almost nobody uses. The plant chose the eight, we did not.
   You get: Reason capture live on every line, with a median of six seconds to answer.

4. **The number** (Weeks 10 to 12)
   Availability, performance and quality per machine, per shift, per order. A time series database behind a live view for the plant floor, and an automated weekly PDF for head office, because the PDF is what the board actually reads.
   You get: One dashboard, one weekly report, and the Monday morning spreadsheet retired.

5. **Handover** (Weeks 13 to 14)
   The client maintenance team owns this now. We wrote the runbook against the failures we had already seen, not the ones we imagined.
   You get: Runbook, a restorable gateway image, and two hours of training for the people who keep it running.

## What it runs on

Nothing exotic. Every part of this can be maintained by the client own maintenance team, which was a requirement rather than a preference.

- OPC UA and Modbus TCP, read only, no controller changes
- A Node.js gateway on Debian, one per plant
- MQTT over TLS from plant to platform, store and forward
- TimescaleDB on PostgreSQL for the machine history
- Grafana for the live plant view, a scheduled PDF for head office
- One Android tablet per line, kiosk locked to a single page

## What changed

- **2 days → 4 seconds** — to answer which machine cost the most
- **41** — machines reporting, across 4 vendors and 3 decades
- **6 s** — median time for an operator to log a stop reason
- **+6.2 pts** — OEE on the two worst lines, first quarter after go live

The first month produced no improvement at all, and that was expected. The data confirmed what the plant already suspected about two lines and contradicted them about a third.

The argument that had run for a year about whether the 1996 press was the bottleneck ended in a week. It was not. A die change on the newest line was, and it had been invisible because it happened between shifts.

The improvement came from the fourth month onward, once the plant had reorganised around what the data said rather than around what everybody had assumed.

## Is your plant data in a spreadsheet?

Most are. Tell us which machines you have and what you can already read from them, and we will tell you honestly whether this is a two week problem or a two quarter one.

[Start a conversation](/contact)