Brewery sensor and SCADA data for data engineering teams
Brewery plant data is a rich source for analytics, but it was built to run a process, not to feed a data lake. Data engineers who understand where it comes from build pipelines that brewers trust.
Where plant data comes from
In a modern brewery, sensors measure temperature, pressure, flow, level, gravity, dissolved oxygen, conductivity and more. They connect to PLCs (programmable logic controllers), which run valves, pumps and sequences. A SCADA system sits above the PLCs and gives operators screens to watch and control the process. A historian stores time series values for each signal, usually called a tag.
For a data engineer the historian is usually the source. It may be a commercial historian product or a database the SCADA writes to. Access is often through an OPC UA interface, a vendor API or exports. It nearly always goes through the plant's IT and OT security controls.
What the main signals mean
A few tags carry most of the value:
- Fermenter temperature and setpoint. The setpoint is what the brewer asked for. The actual value is what the tank achieved. The gap matters.
- Tank pressure and level. Pressure rises during fermentation in closed tanks. Level shows filling and emptying, which marks the start and end of a batch.
- Gravity or density. Inline or in-tank sensors track sugar falling as yeast works. See digital hydrometers and fermentation sensors.
- Flow and totalisers. Volumes moved between vessels and to packaging.
- Valve and pump states. Binary signals that show which route the beer or cleaning solution took.
Batch context is everything
A temperature series without context is just a line. Brewers think in batches: brew number, beer, tank, start and end time plus phase, such as fermentation, diacetyl rest, crash cooling and storage. The most valuable engineering work is attaching this context to the raw tags.
Some plants follow a batch control model inspired by the ISA-88 standard, with recipes, phases and batch IDs recorded by the control system. Others record batches only in brew logs or an ERP. Either way, the pipeline should join tag data to a batch record so analysts can compare one fermentation with another. Our guide to reading a fermentation curve shows what brewers look for once that join exists.
Sampling, compression and gaps
Historians often store values only when they change by more than a set amount, a technique called deadband or exception-based recording. That saves space but means the data is not evenly spaced. Interpolating blindly can invent values that never existed.
Expect gaps from network outages, PLC restarts and sensor faults. A gravity sensor removed for cleaning will produce a sharp drop or a flat line. A probe recalibration may shift values by a fraction of a degree. Keep raw data, flag quality codes where the historian provides them and document every cleaning rule.
Changes that look like faults but are not
Many sudden changes in brewery data are deliberate. A lager might be held at 10 °C, warmed to around 14 °C for a diacetyl rest, then crash cooled to near 0 °C. Each step changes temperature sharply on purpose. A cleaning cycle sends hot caustic and acid through a tank, so temperature and conductivity spike while the tank holds no beer at all.
Anomaly detection that ignores these phases will flag every normal brew. Learn the process steps for each beer and build them into the logic.
Units, tag names and time
Tag naming in older plants is often cryptic and inconsistent between areas. Build a tag dictionary with the plant team: tag name, description, unit, range, vessel and owner. Check units carefully. Pressure might be in bar or millibar, gravity in °P or specific gravity, volume in litres or hectolitres.
Time zones and clock drift matter too. PLC clocks are not always synchronised with the historian. Daylight saving does not apply in India but may apply to a global data platform. Store timestamps in UTC with the source offset noted.
Security and the plant boundary
Plant networks are operational technology. A careless connection can disrupt production. Most companies insist on read-only access through a demilitarised network zone or replicated historian, never direct writes to control systems. Work with the plant's OT and IT teams on the design. Data engineers who respect that boundary get access faster.
Start small. One fermentation area, a dozen well documented tags and a clean batch join will teach you more about the plant than a full historian copy with no context. Expand once brewers are using the first dashboard and correcting your assumptions.
Common questions
What is the difference between SCADA and a historian?
SCADA lets operators monitor and control the process in real time. A historian stores time series values from the plant so they can be analysed later.
Why does brewery sensor data have gaps?
Network outages, sensor cleaning, calibration and exception-based recording all create gaps or uneven spacing. Pipelines should flag these rather than hide them.
Can data teams write back to brewery control systems?
Usually not. Most plants allow read-only access through a secure zone, because writes to control systems can affect safety and production.

