Overnight, the site's MQTT broker restarted. By morning, every Sparkplug B tag on Line 4 still shows its last value from 11 pm — the line view reads green while the machines visibly cycle.
Q1 What failed, and what should have caught it?
A
The machines all stopped at 11 pm and the view is accurate. The machines are visibly cycling. Believing frozen data over the physical plant is the exact failure the stale-tag rule prevents.
B
The subscriptions died with the broker session — birth/death certificates exist to flag exactly this, and stale-tag detection should have tripped. With MQTT you own topic structure and birth/death certificates. A frozen-green line view is a dead feed wearing a healthy face — death certs plus stale-tag checks are the alarm.
C
MQTT can't survive broker restarts — migrate the line to OPC-UA. Session recovery is a configuration job, not a protocol defect. Migrating transports leaves the missing birth/death handling unbuilt.
Covered in Module 01
Downtime events on the capper consistently log four minutes before the andon shows the stop. Downtime attribution keeps blaming the wrong upstream station, and nobody trusts the sequence-of-events view.
Q2 What's the likely defect?
A
Timestamp source — the device clock has drifted from ingest time, and clock skew is destroying downtime attribution. A constant offset between logged events and observed reality is a clock problem. Verify which clock stamps the data and sync it before trusting any event ordering.
B
The andon is slow — trust the tag timestamps and retrain the operators. A four-minute display lag on an andon would be its own outage. The systematic offset points at the tag's clock, and validation means checking it, not explaining it away.
C
The attribution model needs more history to learn the line. No model can attribute correctly on skewed timestamps. Data-path defects come before model fixes — always.
Covered in Module 01
An integrator quotes a custom OPC-UA wrapper around a CNC cell's MTConnect agents, "so everything speaks one protocol into the historian."
Q3 What's the right call?
A
Take MTConnect natively — the cell gives it to you for free, the wrapper adds a failure point, and the connector layer normalizes everything into one tag model anyway. Pick by what the asset actually speaks. Uniformity at the transport layer buys nothing when normalization already happens in the tag model.
B
Reject both and poll the CNCs directly over their controllers' serial ports. Hand-rolled polling discards a working standard. MTConnect already streams samples and events read-only — exactly what the feed needs.
C
Approve it — a single protocol simplifies the architecture. The "simplification" is one more custom component to break at 2 am, sitting in front of a standard that already worked.
Covered in Module 01
Line A reports 86% availability, Line B 79%. You find Line A's model excludes changeovers from planned production time; Line B counts them in. The plant manager wants Line B to "copy Line A's practices."
Q4 What do you tell the plant manager?
A
Line A is genuinely better at changeovers — study their setup discipline. Line A doesn't do better changeovers; it doesn't count them. Copying "practices" from a definition artifact chases a ghost.
B
The 7-point gap is a definition, not a performance difference — align what "planned time" includes before comparing lines. Availability = run time / planned production time. Different denominators make the comparison meaningless; pin the definition first, then compare.
C
Report both lines at the average, ~82%, until the models converge. Averaging two incompatible definitions produces a number that means nothing on either line.
Covered in Module 02
Reviewing a line's loss data, you find 31% of all downtime minutes coded "Other." The AI's ranked actions for that line have gone generic — "investigate recurring stops" — instead of naming causes.
Q5 What's the connection, and the fix?
A
Add 40 hyper-specific codes so nothing ever lands in "Other" again. Over-splitting into codes nobody can tell apart mid-shift produces guessed labels — noise with more decimal places. Short and distinct beats exhaustive.
B
Reason codes are the AI's vocabulary — a catch-all bucket swallows the signal. Rebuild the list against the Six Big Losses, short enough to log honestly. Recommendations can only be as specific as the codes behind them. When a third of the loss is unlabeled, ranking degrades into generalities.
C
The AI needs more data — wait a quarter and revisit. More weeks of "Other" is more of the same nothing. The defect is taxonomy, not sample size.
Covered in Module 02
You spend two weeks lifting the labeler's OEE from 85% to 92%. Line output doesn't move. The capper — the modeled constraint — still runs at 63%.
Q6 Why didn't output move, and what does the hierarchy say to do?
A
Line OEE is governed by the bottleneck — gains at a non-constraint station can't flow through the capper. Act at the constraint the model identifies. That's why you model the hierarchy to the constraint: rollups describe the line, but the bottleneck decides what the line can make.
B
The OEE math is broken — a 7-point station gain must show up somewhere. It shows up as idle margin at the labeler. The math is fine; the constraint is the throughput governor.
C
The labeler gain was too small — push it to 95% and output will follow. A non-constraint station at 92% or 99% feeds the same choked capper. No number at the labeler moves line output.
Covered in Module 02
After cranking the confidence threshold to kill false positives, alert volume drops to near zero — and a bearing failure the model had flagged at lower confidence arrives unannounced, costing a shift.
Q7 What went wrong in the tuning?
A
Confidence became a blunt instrument — raising it trades missed real events for quiet. The durable fix is operator feedback retuning baselines and thresholds, with precision tracked over time. Raising confidence reduces false positives but lets some real events through. The trust loop — labels feeding back into tuning — improves both sides at once.
B
Nothing — near-zero alerts means the model finally matured. Silence bought by threshold isn't accuracy. The flagged-then-suppressed bearing is exactly the cost of confusing quiet with correct.
C
The model should be retrained from scratch on more history. The model flagged the failure — the surfacing policy suppressed it. Retraining doesn't fix a threshold set past the signal.
Covered in Module 03
A vibration tag averages 41 with σ = 3. Someone set its alert threshold at 45 — "a nice round number." It trips 25 times a shift, and maintenance stopped reading the alerts a week ago.
Q8 Diagnose the threshold.
A
The threshold is fine — maintenance needs alert discipline. No crew stays disciplined against 25 false trips a shift. The trip point is statistically guaranteed to cry wolf; fix the math, not the people.
B
Vibration is too noisy to monitor — remove the alert entirely. The tag is monitorable; the trip point is just inside the noise band. μ + 3σ with dwell keeps the signal and drops the noise.
C
45 sits just over one σ from the mean — noise alone crosses it constantly. Set it from process variation, around μ + 3σ = 50, and add a dwell rule. Thresholds set against variation, not round numbers, separate drift from noise. A σ of headroom guarantees alert fatigue on a healthy process.
Covered in Module 03
Two conveyor motor models both show MTBF ≈ 1,500 h. Motor A's Weibull β is 3.1. Motor B's is 0.7, with failures piling up right after rebuilds.
Q9 One maintenance policy or two?
A
One — identical MTBF means the fleets should be treated identically. That's exactly what MTBF can't tell you. One global policy over-maintains one fleet and mis-maintains the other.
B
Two — Motor A earns time- or condition-based replacement late in its interval; Motor B needs its rebuild and install practice fixed. Same MTBF, opposite regimes. MTBF hides the shape. β 3.1 is wear-out, where scheduled work pays; β 0.7 is infant mortality, where every extra touch adds early-life risk.
C
Replace both fleets at 1,200 h to be safe. For Motor B, early replacement re-enters the highest-hazard window more often — the policy manufactures the failures it's meant to prevent.
Covered in Module 04
Six weeks after a new line starts up, failure-mode clustering groups five stoppages into one "misfeed" cluster. The maintenance planner wants a permanent PM task and a fleet-wide bulletin written from it.
Q10 How much weight can this cluster carry?
A
No weight — ignore clustering until a full year of data exists. Hypotheses are useful now. The error is skipping verification, not using the early signal to aim the investigation.
B
Treat it as a hypothesis — five events on a new line is thin labeled history. Investigate the cluster's root cause before institutionalizing anything. Clustering needs enough labeled history to be meaningful. Early clusters point where to look; they don't yet prove what's true.
C
Full weight — five matching signatures is statistical proof of a failure mode. Five points on a six-week-old line can be commissioning noise or one bad batch of material. Point, investigate, verify — then codify.
Covered in Module 04
A year-old CMMS integration maps asset, work-order type, and priority — but never passed the finding ID onto the work order. Now the plant wants to tune auto-create thresholds using "which findings actually paid off." Nobody can produce that list.
Q11 What did the integration design cost them?
A
Nothing serious — finance can match findings to work orders by date and asset. Date-and-asset matching collapses the moment an asset has two findings or a delayed work order. Approximate joins aren't finance-grade.
B
Only reporting polish — the maintenance work still got done. The work got done, but the loop never closed: no verified outcomes, no ledger credits, no data to tune the trigger policy. That cost compounds.
C
Traceability — without the finding ID on the work order and the WO ID back on the finding, outcomes can't reconcile to their triggers, so thresholds can't be tuned on results. The ID link is what turns closed work orders into evidence. Skip it and verification — operational or financial — becomes reconstruction by anecdote.
Covered in Module 05
After a verified availability recovery on the capper, operations wants to book the $48K annualized saving immediately. Finance hasn't reviewed it yet.
Q12 When does the verified-savings ledger credit this?
A
Only when both halves are done — the operational gain is confirmed and finance validates the dollars, all referencing the same finding ID. That two-part rule is what makes the ledger finance-grade rather than a claims list. OEE recovery alone is necessary, not sufficient.
B
Now — the OEE delta is objective, and finance review is a formality. Unvalidated dollars turn the ledger into marketing. The finance sign-off is the difference between a saving and a story.
C
At year end, when the full annualized effect can be observed. The ledger doesn't need a year — it needs the confirmed loss delta plus finance validation. Waiting adds delay, not rigor.
Covered in Module 05