TinyML Condition Monitoring for Legacy Industrial Machines

TinyML can support offline condition monitoring of legacy machines by connecting suitable sensors to a microcontroller that processes signals and runs a compact model locally. A successful pilot must prove that the signal reveals a useful maintenance condition, that alerts survive loss of connectivity and that staff can act on them. Anomaly detection alone does not establish failure prediction.

Observable faults and sensor placement

Start with a failure that matters to the production schedule and has an observable precursor. A bearing problem, belt-tension change and overheating motor may require different sensors, sampling and validation. TinyML describes machine learning on a small embedded device; it does not make every fault detectable or supply the evidence connecting an unusual signal with an approaching failure. The maintenance team should define what decision an alert would change and how much warning is useful before selecting the model or board.

A practical research example is Fraunhofer IPMS’s 2024 conveyor demonstrator, which combines several sensing modes and local analysis for belt-tension and jam detection. It shows a way to integrate sensing and edge processing around specified conditions. A demonstration on a small conveyor does not establish an acceptable false-alarm rate for an entire factory. Its useful lesson is the close connection between the physical fault, sensor arrangement and interpretation of the signal.

External sensors can make a retrofit possible when an older controller exposes little data, but mounting is part of the measurement. An accelerometer fixed to a flexible cover may record something different from one securely mounted near the bearing housing. Acoustic monitoring can pick up neighbouring machines; current measurements can change with legitimate load variation. Establish that the sensor, mounting and acquisition chain capture the frequency range and amplitude of interest. A model cannot recover a fault signature that inadequate sampling or filtering has removed.

TinyML resources and offline operation

The embedded implementation must fit the complete workload. Google’s LiteRT for Microcontrollers documentation describes inference on devices with very limited memory and without an operating system. That capability still leaves the engineer to budget sensor buffers, preprocessing, model memory, logging and execution time. Quantisation can reduce model size, but the deployed version needs its own validation. Battery life also depends on sampling, radios and wake cycles, so a low inference power figure is insufficient to size the maintenance interval.

Some platforms support learning locally as well as inference. STMicroelectronics’ FP-AI-NANOEDG1 firmware describes data collection, learning and detection on a sensor node, with a standalone operating mode. This is enabling software for development, not a diagnosis of the site’s machines. Define where initial model generation, configuration, updates and support occur. Then disconnect the external connection during acceptance testing and verify sensing, decisions, timekeeping, alert delivery and recovery. Local inference is only one part of an offline service.

Normal variation, false alarms and maintenance action

The baseline must cover normal variation before unusual behaviour becomes meaningful. Collect representative loads, speeds, products, start-ups and ambient conditions; record maintenance and process changes alongside the signals. Validate on separate operating periods rather than randomly splitting overlapping windows from the same recording. A model trained on one normal speed may flag another healthy speed as a fault. Begin with advisory alerts and investigation: an anomaly score is not automatically a remaining-life estimate or a qualified machine-protection function.

Measure the burden on maintenance staff as well as detection. Report unnecessary investigations per machine-month, confirmed findings, missed observable events and available warning time. For an illustrative fleet of 50 machines, one false alert per machine each week creates 50 investigations every week. Even quick checks can consume more time than a small team has available. Threshold changes should be assessed against missed detections, rather than optimised solely to make the dashboard quiet. A short trial with no real failures can establish operational usability, but gives limited evidence of failure prediction.

Every alert needs an owner, a way to record the inspection and a route into the maintenance schedule or local management system. The node also becomes an asset: budget replacement batteries, mounting checks, firmware support and recalibration after machine changes. Preserve the model version and configuration associated with each finding so results remain interpretable. Scale beyond the pilot when the evidence shows useful, timely decisions at a manageable investigation cost and the factory can maintain the sensing system throughout its intended service life.