Predictive Maintenance for a CNC Production Line

01Executive Summary

Brenta Precision operates 12 CNC machines across two shifts. In the last 12 months the plant recorded 112 unplanned stoppages totalling 616 lost machine-hours, at a fully loaded cost of €228,280 per year. Maintenance is roughly 70% reactive; there is no condition monitoring and no CMMS — work orders live in Excel and on paper.

This report recommends a condition-monitoring and anomaly-detection program, piloted on the 4 machines that account for 41% of downtime hours, before any commitment to full predictive (remaining-useful-life) modelling. The deciding constraint is data: the plant has no sensor history today, so the program is sequenced to build that foundation first and earn its way to prediction.

02Business Challenge Analysis

2.1 Context

Brenta Precision machines safety-relevant components for automotive and hydraulics customers. The fleet: 7 milling centres (3- and 5-axis) and 5 turning centres, running 2 shifts (06:00–22:00), 250 production days per year — a theoretical 48,000 machine-hours annually. The order backlog has held at 6–8 weeks for the past year, so lost machine-hours are lost contribution margin, not just idle time.

2.2 The problem, quantified

Unplanned stoppages in the last 12 months: 112 events, 616 hours (mean time to restore: 5.5 h), equal to 1.3% of fleet hours — concentrated on the oldest machines and on spindle-intensive 5-axis work.

2.3 Failure-mode breakdown

From 1,412 work orders (24 months, Excel; free-text root causes re-coded during this analysis):

2.4 Success criteria

• −40% unplanned downtime hours fleet-wide within 12 months of rollout (616 h → ≤ 370 h); interim gate: −25% on pilot machines by pilot end.
• ≥ 70% of failures on monitored modes flagged ≥ 48 h in advance by month 6 of the pilot.
• ≤ 1 false alert per machine-week by pilot end — alert fatigue is the main adoption killer.
• Payback ≤ 18 months on the full program under conservative assumptions.

03AI Solution Architecture

3.1 Approach: anomaly detection first, prediction second

With no telemetry history, jumping straight to remaining-useful-life (RUL) prediction would mean training models on data that doesn't exist. The architecture is therefore staged:

1. Stage A — Condition monitoring & anomaly detection (this program). Learn each machine's normal behaviour per operation family; alert on deviations. Unsupervised — works from day 90 without failure labels.
2. Stage B — Failure-mode classification (from month ~9). As coded failure events accumulate, map anomaly patterns to specific failure modes.
3. Stage C — RUL prediction (after 9–12+ months of labelled history). Survival models / gradient-boosted regressors per failure mode, only where Stage B shows stable signatures.

3.2 System components

3.3 Deployment model

Recommended: hybrid. Edge preprocessing on-premise (network resilience, no raw data leaves the plant); model training, dashboards and alerting in an EU-region cloud. A fully on-premise variant is feasible but adds ≈ €18,000 in hardware and ongoing ops effort, and slows model iteration — justified only if customer or policy constraints demand it (assessed in Section 8.4).

04Technical Requirements

4.1 Plant infrastructure

• Network drops (PoE) to all 12 machine positions; pilot needs 4 + 1 gateway position per cell.
• Dedicated OT VLAN, segmented from office IT; outbound-only connection from gateway to cloud; VPN for remote support.
• UPS on edge gateways (store-and-forward buffering covers network outages up to 48 h).
• IP67-rated sensors; magnetic mounts where drilling spindle housings is not permitted by the machine vendor's warranty terms — to be confirmed per machine in Phase 0.
• 10% spare sensor stock from day one (sensor failure must not look like machine failure).

4.2 Machine connectivity

4.3 Software & integration

• ERP integration: read-only nightly extract of job schedule (machine, part, operation, planned hours). No write-back in this program.
• CMMS: the plant has none. A lightweight work-order module is included in scope — without digital work orders, the model feedback loop (was the alert right?) cannot close. A full CMMS evaluation is recommended but parallel-tracked, not blocking.
• Identity: dashboard access for ≤ 10 named users; SSO not required in this phase.
• Data retention: raw vibration bursts 90 days; extracted features and events 3 years; all telemetry owned by Brenta Precision (contractually explicit).

05Data Strategy

5.1 What exists today

5.2 The gap, stated plainly

The signal that predictive maintenance actually learns from does not exist yet at Brenta Precision. This is normal for plants at this stage — but it means the first 3 months of the program produce infrastructure and baselines, not predictions. Any vendor promising failure prediction from week one should be asked what data they intend to train on.

5.3 Closing the gap

• Instrument first (weeks 5–12): sensors and gateways on the 4 pilot machines; data quality checks in week 1 of streaming, not month 3.
• Failure-event labelling protocol: 15 controlled failure categories replace free text; the closing technician codes root cause at work-order close; weekly 15-minute review of miscoded events for the first 8 weeks. This single habit determines whether Stage B and C ever become possible.
• Backfill: one structured workshop (maintenance manager + senior techs) re-codes the 24 months of Excel history into the new taxonomy — that produced the Pareto in Section 2.3 and seeds the failure library.
• Baseline windows: known-good operation periods per machine/job family are tagged during weeks 13–16 to train normal-behaviour models.

5.4 Governance

• All telemetry is machine data, owned by Brenta Precision; processor agreements cover the cloud platform.
• No personal data is needed for the models. Operator identity is deliberately excluded from telemetry records (see Section 6.4).
• EU-region hosting; export of raw data outside the EU contractually excluded.

06Organizational Impact & Human Factors

6.1 Who changes how they work

6.2 The decision rule that makes or breaks adoption

6.3 Skills & training

• No data scientist on staff, and none required: the implementation partner operates the models; the plant owns the response process.
• Technicians: 2-day training — vibration analysis basics, dashboard use, root-cause coding discipline.
• Planner and maintenance manager: half-day on the alert-to-intervention workflow and weekly review ritual.

6.4 Adoption risks

• Alert fatigue — the most common failure mode of these systems. Mitigation: conservative thresholds at launch, the ≤ 1 false alert/machine-week KPI, weekly tuning reviews for the first 8 weeks.
• "Black box" skepticism from senior technicians. Mitigation: every alert displays the contributing signals and trend; technician verdicts feed back into thresholds — the system is positioned as a junior assistant that brings evidence, not an oracle.
• Workforce monitoring concerns. The system monitors machines, not people; operator identity is excluded from telemetry by design. In the Italian context, brief the works council under Art. 4, Statuto dei Lavoratori before installation — covered in Section 8.4. Doing this proactively converts a potential objection into demonstrated good faith.

07Implementation Timeline & Investment

7.1 Phased plan — 36 weeks

RUL prediction (Stage C) is deliberately not in this plan: it becomes feasible after 9–12 months of consistently labelled failure history, and committing to it now would be paying for a promise the data cannot yet support.

7.2 Investment

Recurring costs after rollout (cloud, sensor replacement reserve, model maintenance) are estimated at €14,000–18,000/year and are included in the payback sensitivity below.

7.3 Return

Payback ≈ 13 months on the full €95,000 program. If realized benefits land 30% below target — the conservative case — payback extends to ≈ 18 months, still within the success criterion. The €280/machine-hour rate assumes the plant remains capacity-constrained; this assumption is stress-tested in Section 8 (ROI & Business Case).

08Maturity Assessment — Five-Dimension Stress Test

MANOVAT stress-tests the project across five dimensions. Scores reflect the project as scoped today (0–100%); each dimension lists what was found and what raises the score. In the interactive product, each dimension opens a structured challenge session that updates the score and the requirements document as questions get answered.