Dataset and labelling plan

1. Capture normal data across speed, load and warm-up states
2. Create held-out normal sessions from a different time
3. Collect supervised fault examples only when safe
4. Record sensor orientation, mounting and sample rate
5. Exclude startup transients or label them as a separate state

Training and validation pipeline

1. Check time waveform, saturation and spectral stability
2. Create frequency-domain or learned features
3. Train normal-vs-anomalous scoring model
4. Set threshold using held-out normal and safe fault data
5. Quantise and test score distribution again
6. Document false-positive and missed-fault cases

Model deployment procedure

1. Use deterministic sampling with overrun detection
2. Verify sensor range and anti-alias assumptions
3. Deploy model and threshold as separately versioned values
4. Measure inference under Wi-Fi and peak task load
5. Latch repeated anomalies but allow safe reset policy
6. Export score, operating state and diagnostic context

Memory and performance targets

Deployment checkpoints

collect_window(samples);
if (!sensor_ok || sample_overrun) { state = SENSOR_FAULT; return; }
features = vibration_features(samples);
score = invoke_anomaly_model(features);
state = score > threshold ? SUSPECT : NORMAL;
if (repeated_suspect()) request_inspection();

Troubleshooting

Safety, privacy and model limits

• Use guards, current limiting and safe simulated faults; never create a dangerous mechanical failure.
• An anomaly is a request for inspection, not proof of a specific defect.
• Store only required operational data and define retention.
• A changed machine, mounting or speed range may invalidate the baseline.

Interview and viva questions

1. Why is normal-only training insufficient without held-out abnormal evaluation?
2. How is a threshold selected?
3. Why must mounting be controlled?
4. What is the difference between sensor fault and machine anomaly?
5. How would you monitor model drift?

Lesson notes

Responsible TinyML workflow

Keep raw data, preprocessing, model version, compiler options and measured device results together. A desktop accuracy score does not prove embedded performance. Validate representative unseen samples on the actual target and define an explicit fallback for low confidence or out-of-distribution input.

Deployment evidence

Record the dataset split, confusion matrix, exported model hash, firmware build, board revision, peak memory, average and worst-case latency, power conditions and failures. Never treat an educational classifier as a safety-certified decision system.