CASE STUDY · INDUSTRY 4.0 / MANUFACTURING SOFTWARE
A predictive maintenance rollout that prevented 3 major line shutdowns.
- 33 likely shutdowns flagged early and handled in planned windows over 6 months
- 40%Unplanned downtime hours down 40%
01 · PROJECT OVERVIEW
The client and the brief.
An anonymised manufacturer. Name withheld under confidentiality.
Sensors, anomaly models and alerts on critical machines.
We chose the machines that hurt most when they stopped. We fitted sensors for vibration, temperature and motor current where the controllers did not already provide the data. We combined that with cycle data from the PLCs. Anomaly models learned what normal looked like for each machine and flagged drift. Alerts went to the maintenance team with the machine, the signal that moved and a suggested check.
- 1Unplanned downtime on production lines.
- 2A few critical machines caused most of the stoppages.
- 3Failures arrived without warning, so spare parts were not on hand and maintenance worked in a rush.
- 4Planned maintenance followed fixed calendar intervals, which meant some parts were changed early and others failed before their turn.
- 5Production planners could not trust the schedule on the affected lines.
02 · WHAT WENT WRONG
What went wrong, and how we fixed it.
Every engagement hits problems. These were the ones that mattered here, and what we changed so they did not come back.
- PROBLEM 01In the first weeks the models raised too many alerts
Normal events such as a changeover, a cold start or a different product caused false alarms, and technicians began to ignore the messages. We added operating context to the models: running state, product code and shift. We also set a rule that an alert needed to persist before it was sent.
- PROBLEM 02Technicians reviewed each week's alerts and marked them useful or not, and we used that to tune
Trust came back once the alert count dropped to a level the team could handle.
- PROBLEM 03A second hurdle came from the sensors themselves
On two machines the vibration readings looked unstable, and the cause was a loose mount that shifted between shifts. The data looked like a developing fault when it was a fitting problem. We added a simple check that compares a sensor against a reference reading at each planned stop, and replaced the mounts with fixed brackets.
- PROBLEM 04After that, readings were steady and alerts on those machines became credible
03 · THE PROCESS
How we ran it.
We held a short weekly call with the maintenance lead and a monthly review with plant management. A maintenance technician was named as the day-to-day contact, and their judgement shaped most alert rules.
- 01Step 1
Weeks 1 to 3: site survey, machine ranking by downtime history, sensor plan and network plan.
- 02Step 2
Weeks 4 to 7: sensors installed in planned windows, data collection running in shadow mode with no alerts.
- 03Step 3
Weeks 8 to 12: models trained on normal running, thresholds tuned with maintenance technicians, alerts switched on for a first group of machines.
- 04Step 4
Months 4 to 6: remaining critical machines added and alert quality reviewed weekly.
04 · RESULTS
What changed.
Measured against the way the work ran before the engagement began.
- NOW 01
Maintenance schedules now use machine condition alongside the calendar.
- NOW 02
Spares for the monitored machines are ordered when an alert shows a developing fault.
- NOW 03
The team reviews alerts and outcomes weekly, and technicians help refine the rules.
- NOW 04
Planners treat the monitored lines as more predictable and schedule around planned windows.
- 3
3 likely shutdowns flagged early and handled in planned windows over 6 months
- 40%
Unplanned downtime hours down 40%
05 · WHAT WE BUILT
How it works.
- Edge gateways on each line read the sensors and the PLCs and forward readings to a central time-series store.
- Connections are outbound only and sit in a separate network zone from the office network.
- Features such as RMS vibration, temperature trend and current signature are computed at the edge and in the store.
- Each machine has its own baseline, because identical models behave differently in practice.
- Alerts carry a severity and need an acknowledgement.
- Every alert and every outcome is logged, so we could measure how often alerts were right.
06 · QUICK ANSWERS
The short version.
- What problem did the client have?
- Unplanned downtime on production lines. A few critical machines caused most of the stoppages. Failures arrived without warning, so spare parts were not on hand and maintenance worked in a rush. Planned maintenance followed fixed calendar intervals, which meant some parts were changed early and others failed before their turn. Production planners could not trust the schedule on the affected lines.
- What did Brandsmashers build?
- Sensors, anomaly models and alerts on critical machines. We chose the machines that hurt most when they stopped. We fitted sensors for vibration, temperature and motor current where the controllers did not already provide the data. We combined that with cycle data from the PLCs. Anomaly models learned what normal looked like for each machine and flagged drift. Alerts went to the maintenance team with the machine, the signal that moved and a suggested check.
- How was the work run?
- We held a short weekly call with the maintenance lead and a monthly review with plant management. A maintenance technician was named as the day-to-day contact, and their judgement shaped most alert rules.
- What were the results?
- 3 likely shutdowns flagged early and handled in planned windows over 6 months; unplanned downtime hours down 40%.
YOUR TURN
Have a similar requirement?
Tell us what is stuck. We will come back with a plan and matched, pre-vetted engineers.
