Giving a milling plant eyes on its own process

Our client is a large-scale European flour milling and food processing group — a continuous, document-heavy, time-sensitive production operation running multiple milling tracks and lines. Its machines already think for themselves: PLCs and industrial sensors run the local loops. But the data they produce was trapped at the edge — logged on paper, relayed verbally, and reassembled in Excel after the shift ended. Graffino architected the missing layer: an on-premise, real-time process observability system built on top of the existing automation hardware, designed to wrap around how the plant actually works.

PLC-levelcapture
Telemetry read at the source, not retyped
100%on-premise
Decoupled from corporate IT & live production
Semi-autoby design
Software that wraps around human interventions

A continuous process where pressure makes the decisions

The process at the center of the engagement is a multi-stage, starch-based mixture preparation line. Starch and water are dosed and combined in a secondary mixing unit, then blended in a closed tank. Steam heats the mixture while operators watch the parameters climb toward a target temperature. When the threshold is reached, a pump transfers the batch to a second, open tank — and there, pressure is the decision-maker: it determines exactly when the transfer pump shuts off.

Weighing and dosing run on a separate electronic dosing system in manual and automatic modes. The physical stages, as the plant runs them:

Stage 1 Dosing & mixing Starch + water combined, blended in the closed tank
Stage 2 · watched Steam heating Operators monitor until the target temperature is reached
Stage 3 · critical Pumping & transfer Pressure in the open tank decides when the pump stops
In parallel Tank refill The closed tank should refill during transfer — currently untracked

Machines that act in milliseconds, reported on by hand after the shift

The structural problem sat at the intersection of the physical factory floor and digital visibility:

  • Low operational visibility. Siloed production pipelines with no real-time, plant-level telemetry — teams guessed line statuses or chased down individual operators.
  • The parallel-processing gap. Refilling the first tank while the second receives the batch is what maximizes output — and that critical parallel stage wasn't digitally tracked at all.
  • Reporting latency. Downtime logs, runtime trends and mechanical anomalies lived in human memory, hand-entered notes and scattered Excel files — visible only long after a shift ended.
  • A safety-critical blind spot. The transfer pipe between the tanks occasionally clogs and must be cleared manually — a bottleneck and a worker-safety hazard. The pressure variations that precede a clog are exactly the data nobody was capturing.
  • Corporate systems that don't reach the floor. The group's ERP and WMS handle payroll and high-level logistics, but they don't talk to the machines — leaving telemetry trapped at the edge.

One more constraint shaped everything: a previous attempt at a fully automated, hands-off mixing cycle had already failed in this plant. Raw materials are physically unpredictable; the process needs human judgment at specific points. Whatever got built had to respect that.

Full automation already failed here once. The system has to wrap around real-world human interventions — not pretend they don't exist.

The design constraint that shaped the architecture

Wrap the hardware. Don't rip anything out.

The mandate was pragmatic: a localized, on-premise monitoring and observability layer on top of the automation hardware the plant already trusts. Three principles ran through the architecture:

  • Read, don't interfere. The system listens to the existing PLCs and sensors over standard industrial protocols. PLC logic stays untouched; live production rhythms carry zero integration risk.
  • Standalone by design. Local collection servers and a local-network database — completely decoupled from corporate IT, so the monitoring layer can't disrupt manufacturing workflows or the group's ERP infrastructure.
  • Semi-automatic, honestly. Operators intervene because the physics demands it. The software's job is to capture, timestamp and contextualize those interventions — turning them into data instead of treating them as exceptions.

An on-premise telemetry pipeline, from sensor to dashboard

01

Local data-collection servers

On-premise servers reading asynchronous telemetry directly from the edge PLCs and embedded sensors over standard industrial protocols.

02

Normalization pipeline

Ingestion scripts that parse continuous raw event streams, apply runtime/downtime logic rules, map anomalies and reconcile conflicting versions of data truth.

03

Time-series storage schema

Hardware events translated into structured SQL blocks — a local-network PostgreSQL store holding high-resolution temperature and pressure profiles over time.

04

Web-based SCADA dashboards

A lightweight React/Next.js interface delivering real-time plant-level rollups, scannable line dashboards and historical diagnostic timelines.

05

Batch & lot consistency tracking

Running outputs and batch lot consistency made visible per line — replacing guessing and operator-chasing with status timelines.

06

Downtime & anomaly timelines

Runtime trends, stoppages and mechanical anomalies logged automatically at the source — visible during the shift, not reconstructed after it.

07

Clog-precursor pressure monitoring

High-stakes tracking of the pressure variations that precede a transfer-pipe clog — the data foundation for warnings before a hazard, not after.

08

Parallel-stage observability

Digital tracking for the refill-during-transfer stage that maximizes output — the critical parallel process that previously ran unmonitored.

The signal path, from factory floor to screen

Existing Physical production lines Starch mixing · steam heating · the clog-prone transfer pipe
live temperature & pressure signals
Existing Edge PLCs & hardware sensors Local machinery loops — untouched by the new layer
standard industrial protocols
Graffino layer Local-network data-collection servers On-premise, decoupled from corporate IT
raw event streams
Graffino layer Normalization scripts Runtime/downtime rules · anomaly mapping · one version of truth
Graffino layer SQL time-series database PostgreSQL on the local network · high-resolution T & P profiles
queried in real time
Graffino layer Web SCADA / manufacturing dashboards Real-time output · downtime logs · safety alerts · historical diagnostics

What the layer changes on the floor

AreaTodayWith the observability layer
Data capturePaper logs, verbal handoffs, hand-compiled ExcelAutomatic, source-level capture from the PLCs
Line statusGuessed, or chased down operator by operatorReal-time plant-level rollups and status timelines
Downtime & anomaliesVisible long after the shift endsLogged and visible as they happen
The parallel refill stageUntracked entirelyMonitored — the output-maximizing stage gets data
Pipe clogsDiscovered when the line stops; cleared by handPressure precursors tracked, warnings before the hazard
HistoryScattered notes and memoryA normalized time-series archive for optimization and audits
Corporate ITDisconnected from the floorStill disconnected — by design, zero production risk

The disciplined road from seeing to optimizing

This is an architecture engagement — the value is the path it opens. The design follows the classic industrial maturity pattern, deliberately starting where every credible plant-modernization effort starts: by seeing clearly.

Phase 1 Monitoring & observability Source-level capture, real-time dashboards, the time-series archive.
Phase 2 Alerts & safety Warning boundaries on temperature and pressure — including clog precursors.
Phase 3 Optimization & automation Process tuning grounded in evidence, where the physics allows it.

Each phase earns the next. No optimization without alerts; no alerts without trustworthy data.

Manual dependencies

Designed out

Paper logging, verbal handoffs and human-compiled spreadsheets replaced by automatic, source-level capture.

Observability

Line-level, live

Factory managers and operators see running outputs, lot consistency and line errors as they happen.

Historical record

Time-series, normalized

Temperature and pressure profiles archived for process optimization and auditing.

Worker safety

Precursors visible

The pressure patterns that precede a clog become trackable — the foundation for pre-hazard warnings.

Production risk

Zero added

Standalone and on-premise — no dependency on, or risk to, live manufacturing or the corporate ERP.

The pattern

Wrap, don't rip

Observability unlocked on top of existing PLCs and ERPs — no costly, disruptive replacement of anything that already works.

Most factories don't need new machines. They need to see the ones they have.

Industrial environments are full of capable hardware whose data never leaves the floor. The instinct to fix that with a full automation program — or a rip-and-replace ERP project — is exactly what this architecture argues against. A monitoring layer that reads what already exists, respects human interventions, and stays off the corporate network delivers the foundation first, at a fraction of the risk.

The pattern travels. Any manufacturer running PLC-controlled lines with paper logs and end-of-shift spreadsheets — milling, food processing, chemicals, packaging — has a version of the same gap between what its machines know and what its people can see. The same architecture closes it.

Let's build your observability layer, by Graffino.

We design real-time monitoring layers on top of existing PLC infrastructure — connecting disconnected line data into central web dashboards without interrupting active production rhythms.

Talk to Graffino
←  All case studies