Mini Manufacturing Digital Twin — Runtime Process Monitoring
I built this for ES 51 (Computer-Aided Machine Design), the course I teach at Harvard SEAS, where students machine their own parts on the lathe and mill. It is the machining-lab monitor: it represents a physical cut as a live data stream, compares that stream against an expected process model, detects anomalies, and turns them into auditable operator recommendations, so students can see the cut as data, not just chips. It is the back half of a design → build → monitor digital thread; its companion, the Additive Build Advisor, is the front half and hands its release record off to this twin.
The dashboard below is driven by the twin’s actual simulator, detector, and recommender. Spindle load, vibration, and temperature stream in against their expected models, detected anomaly windows are shaded, a smoothed health score tracks process state, and a human-in-the-loop recommendation updates as evidence accrues.
Why I built it, and where it fits
When my students finish a part, they take it to the CNC to machine the features that printing could not hold as-built. I wanted them to see that step the way a good operator sees it, as a loop run in the head and made explicit: start with the physical process, stream the machine data, compare measured behavior against what you expect, detect deviations, and recommend action only when the evidence is strong enough to justify it. That is the whole point of the project. The dashboard is just where the loop becomes visible.
The two halves share a hand-off. The Additive Build Advisor releases a part with an explicit block (machine id, part id, expected operation, and the signals to watch), and that becomes this twin’s as-built monitoring context. The front half decides how to make it; the back half watches it being made. Same verify-before-act discipline at both ends.
How it works
A CNC process simulator generates repeatable machine telemetry for an adaptive milling operation on machine SEAS-CNC-01, cycling through warmup, roughing, finishing, and inspection phases. Each event is wrapped in an MQTT-style topic envelope (factory/SEAS-CNC-01/process), so the data carries the shape an industrial streaming architecture expects, without requiring a broker. From there, a lightweight digital-twin state holds the current process model, the actual measurements, a health score, and the anomaly evidence; the detector reads that state, and the recommender turns it into a decision. The whole thing is zero-install: Python standard library only, python3 app.py, open the browser.
The detector and the recommender
I kept the detector transparent on purpose, using explicit rules rather than a black box, so a student can read exactly why it fired. It works on residuals (actual load and temperature minus the expected model), rolling z-scores, phase-specific vibration limits and feed-rate windows, a tool-wear threshold, and missing-telemetry checks. Together those catch the five failure modes the simulator injects: chatter, tool wear, thermal drift, feed mismatch, and sensor dropout.
The recommender then converts that evidence into a graded decision (proceed, watch, human review, schedule intervention, or do-not-proceed) rather than a blunt stop. The judgment is in the gating. Chatter asks for human review of fixturing before anyone touches a parameter; tool wear schedules an intervention at the next safe stop instead of halting mid-cut. And the case I most wanted students to see: on a sensor dropout, the twin explicitly refuses to recommend a parameter change rather than acting on incomplete data. When the data is missing, the model should not confidently push a physical action. That is the verify-before-act rule, and it is the same gate the advisor uses before release.
Honest scope
This is a prototype, not a production twin. The telemetry is simulated and is not yet wired to a live machine or a real broker; the value is in the architecture and the decision logic, not a claim of readiness. A production version would connect to MQTT, MTConnect, or OPC UA for real machine data, persist time-series, and validate the detectors against labeled fault data. I would rather state that plainly than overclaim it.
Code
The full project, technical report, and smoke test are on GitHub.