Conveyor Gearmotor Vibration Analytics: Firmware Development Trade-offs
A logistics operator wants vibration-based predictive maintenance on 180 conveyor gearmotors. The development team has an MCU with 256 KB SRAM and 1 MB flash, a 3-axis accelerometer sampled at 3.2 kHz at 16 bits per axis, and an NB-IoT module on a 200 MB per month plan. The product owner has asked for raw waveform upload every 10 minutes so the data science team can iterate on models later. The device must run five years on lithium thionyl chloride cells, fit in a 90 x 60 mm enclosure, and support remote firmware update. A previous prototype streamed raw data and exhausted the monthly data plan in the first week of bench testing. The team has six weeks before a pilot on five motors, and there is no hardware spin budget for a larger MCU.
1. Quantify the raw streaming requirement and decide whether edge feature extraction is justified. Show your arithmetic.
Read the worked answer
Raw rate. 3 axes x 3,200 samples/s x 2 bytes = 19,200 bytes/s, or 153.6 kbit/s.
Per day. 19,200 x 86,400 = 1.66 GB per day per motor.
Per month. 1.66 x 30 = approximately 49.8 GB per motor per month, against a 200 MB plan. That is roughly 250 times over budget for a single device, and there are 180 devices. Even capturing a 1-second burst every 10 minutes instead of continuous streaming gives 19.2 kB x 144 = 2.8 MB per day, still around 83 MB per month per motor, which is 75% of the plan for one motor.
Conclusion. Raw streaming is not viable on this link, this plan or this power budget. Radio energy scales with bytes, and a five-year cell life cannot survive it.
Edge extraction. Compute on-device: an FFT over 1,024 or 2,048 samples yields the fault-relevant features - overall RMS velocity, crest factor, and band energies around shaft, gear-mesh and bearing frequencies, plus 1x and 2x running speed if a tacho is available. A feature packet of about 200 bytes every 10 minutes is roughly 0.86 MB per month per motor, comfortably inside the plan even with 180 devices.
What you give up. You lose the ability to re-analyse historical raw waveforms with a new model. Mitigate by keeping a small reservoir: store raw bursts locally in a ring buffer and upload them only on request or when an anomaly score exceeds a threshold.
2. Design the firmware update mechanism for this device, given 1 MB of flash and no hardware respin. Identify what will not fit and how you resolve it.
Read the worked answer
The arithmetic. Assume an application image of 380 KB, a bootloader of 32 KB and a settings/NVS region of 16 KB. A/B redundancy requires two application slots: 760 + 32 + 16 = 808 KB, leaving about 216 KB. That is less than one application image, so a full-image download cannot be staged in internal flash. This is the constraint that shapes the design.
Options.
- Delta or compressed updates. Ship binary diffs; a typical app change is 10-40 KB. Requires a robust patching step and a verifiable result, and a full-image fallback for recovery.
- External SPI flash. A 4 MB part costs little and adds a staging area, but it needs board changes - not available without a respin, so it is a next-revision item.
- Reduce the A/B requirement. Keep one application slot plus a minimal recovery image, accepting a longer mean time to recover.
For the pilot I would ship delta updates plus a signed full-image fallback into the recovery region.
Safeguards, all mandatory. Sign the image and verify before boot; keep the running slot intact until the new one passes a health check; watchdog plus a boot-counter that reverts after three failed starts; resume block transfers with per-block checksums so a dropped NB-IoT link does not restart a download; stage rollout 1% then 10% then full; and inhibit updates below a signal or power threshold.
3. The pilot is six weeks away and the data science team still wants raw data. Propose a validation and test strategy that de-risks both the feature extraction and the update mechanism.
Read the worked answer
Bench validation with ground truth. Record raw vibration from instrumented motors with a calibrated analyser, including known faults - bearing wear, misalignment, a chipped gear tooth - and healthy baselines at several load points. Run the recorded signals through the on-device feature pipeline in a hardware-in-the-loop rig. Compare extracted features against the analyser's computed values and set tolerance bands; a feature that does not track the reference within a few percent is not fit to report.
Fault injection, not just happy-path testing. Deliberately corrupt an update image and confirm signature rejection; cut power mid-write and confirm rollback; drop 30% of packets and confirm resume; force a low-signal condition and confirm the update is inhibited rather than half-applied. These are the failure modes that produce field truck rolls.
Power and data budget test. Run a device on a bench supply with current logging for 72 hours under the real duty cycle, including retransmissions, and extrapolate. Any deviation from the five-year model gets found here, not in month 18.
Field pilot. Five motors, six weeks, with weekly manual analyser readings as truth. Collect both feature packets and on-demand raw bursts so the data science team can iterate without changing the production path.
Exit criteria for the pilot. Detection of the seeded fault within two reporting cycles, no false alarms on healthy motors, zero failed update recoveries, and measured monthly data per device under 5 MB.