Case study: PLC data for predictive maintenance

Return on investment

1 hr/dayReturned to engineers, per siteThe daily HMI export is gone, and so is the manufacturer’s API bill.

Every runCaptured automaticallyWhether or not anyone is on site that day, across every machine.

One platform, five jobs

Predictive maintenance, run and alarm analysis, feed optimisation, equipment records and live monitoring, all from the same dataset.

Background

The data existed. Nobody could reach it.

Our client is a biochar project developer running industrial pyrolysis plants, turning oil palm trunk, empty fruit bunches and other biomass into biochar. Every plant was already measuring the things that matter: motor currents, temperatures, feed rates, alarms and trips. Almost none of it reached anyone who could do something with it. There were two ways to get at it. Pay the manufacturer for API access, or send an engineer to the HMI to export it by hand, every day, at every site.

Two engineers in hard hats and hi-vis vests adjusting the chain drive on a pyrolysis unit in the workshop

The challenge

Four problems between the plant and a usable dataset

Getting hold of the data was hard. Trusting it once you had it was harder.

01

A daily manual export

Getting data off the plant meant an engineer standing at the HMI, exporting it by hand, every day. That was about an hour a day. It only covered the sites someone actually visited, and it stopped completely when that person was away.

02

Paying the manufacturer for your own data

The vendor did offer a way in: a paid API. That meant a recurring bill, for every site, to read numbers the client's own plant was already producing.

03

Two makes of controller, naming things differently

The plants run on more than one brand of PLC, a Siemens on one machine and a Unitronics on another, each with its own tag naming. On top of that, the live sensor tags and the equipment parts catalogue were separate systems that did not share identifiers. Nothing matched up on its own, so every reading had to be reconciled by hand before it could be compared across machines.

04

The sensors changed underneath

Partway through, the vendor changed what the sensors measure. One combined current reading per auger drive became two separate sub-motor readings. Four new channels also turned up with the wrong unit recorded against them. The values were right; anything built on the label was not. Mix any of that together and the baseline is wrong before it exists.

Mainspring solution

Everything the plant produces, in one place engineers can use

Direct from the PLCs, no vendor APITwo Raspberry Pis poll Siemens over S7 and Unitronics over Modbus TCP, pushing straight into BioSource. No subscription, no daily export, no gaps when nobody is on site.
Tags mapping every equipmentEvery sensor tag tied to a physical asset and checked against live production data. The labelling bug was caught and fixed, and pre-split readings stay separate from post-split ones.
One database, multiple analyticsMaintenance, run and alarm analysis, feed optimisation, equipment records and live monitoring all query the same store, across sites and machines, with access by role.

See it in actionPick a screen, use the arrows, or tap the cards behind

01Maintenance built from the manuals themselves02Every signal from the plant, on one chart03What each run produced, and how to improve the next04Wear showing up as a trend, not a trip

01 / 04

02 / 04

03 / 04

04 / 04

01

Maintenance built from the manuals themselves

AI reads the sensor and equipment manuals and builds the schedule out of them, instead of someone typing intervals in by hand. Overdue work, jobs due this week and jobs due this month are counted at the top. Every manual stays downloadable so an engineer can check it, and completed work is logged against the asset.

Built from manualsSource downloadableLog kept

biosource.onnu.com/maintenance

Maintenance built from the manuals themselves

Two jobs overdue, five due this week and 76% of planned tasks on schedule, at a glance.

02

Every signal from the plant, on one chart

Temperatures, auger currents and fan speeds come off the controllers on their own and stack onto one chart for any run, with alarms and phases marked against them. Nothing to export, nothing to reconcile. The readings arrive already attached to the equipment they came from.

Stacked signalsAlarm flagsPhase bands

biosource.onnu.com/run-analysis/analytics

Every signal from the plant, on one chart

Six parameters and 58 alarm flags across a twelve-hour run, on one timeline.

03

What each run produced, and how to improve the next

Each run reads in the order material moves through the machine: feedstock, moisture, input, output. Those figures are weighed against feed rate, and the platform suggests settings for the material actually being run, covering feed rate, auger speeds and fan speeds. It shows its reasoning, so an engineer can judge it.

Mass balanceYieldSettings suggested

biosource.onnu.com/run-analysis/performance

What each run produced, and how to improve the next

5,850 kg of oil palm trunk in, 1,579.5 kg of biochar out, in a run of just over 12 hours.

04

Wear showing up as a trend, not a trip

On every run, each motor’s reverses, trips and current draw sit next to its own 90-day average. Anything working harder than it should gets flagged while there is still time to do something about it, which turns wear into a planned job instead of an unplanned stop.

Per motorThis run vs 90 daysWatch flags

biosource.onnu.com/run-analysis/health

Four of twelve motors flagged Watch, sorted worst first so attention goes where it is needed.

The outcome

A plant that reports for itself, and a team that can act on it

Every reading now arrives on its own and lands in one database. The effort that used to go into collecting it goes into using it:

An hour a day back, at every site. The daily HMI export is gone, and so is the manufacturer's API bill. Runs are captured whether or not anyone is on site.

Wear caught while there is still time to act. Motors, augers and rotary valves that start drawing harder than normal show up as a trend, so the work gets scheduled before something stops the line instead of after.

Yield tuned to the feedstock in front of you. Feed rate, auger speeds and fan speeds are matched to the material actually being run. The reasoning is shown, so the engineer still makes the call.

One place for the whole estate. Live runs, alarms, equipment records, maintenance schedules and their completed logs all sit together, across every site and machine, with access set by role.

Work with us