A connected product can tell you it broke. The far more valuable capability is telling you it is about to break — recognizing in the data that a bearing, pump, battery, or board is degrading, in time to schedule a repair instead of absorbing a stoppage. For a commercial customer that is the difference between a planned part swap and an idle production line. For you as the manufacturer it is the foundation of a paid service tier and real differentiation. And most of it is not artificial intelligence; it is good sensor selection and disciplined data engineering.
It starts with collecting the right signals
You cannot predict a failure from data you never captured. The question belongs in the requirements document, not in a later software sprint: what signals precede failure in this machine? Common patterns:
- Motors and moving assemblies — a gradual rise in current draw, vibration amplitude, or temperature indicates bearing wear or increasing friction.
- Pumps and compressors — drifting pressure, falling flow rate, or a longer time to reach operating state.
- Batteries — declining usable capacity, rising internal resistance, lengthening charge times.
- Electronics — repeated resets, accumulating communication errors, sensors drifting away from calibration.
- Filters and consumables — pressure differential across the element, or run hours against a known service life.
Sometimes it is worth adding a sensor purely to enable prediction. A current-sense resistor or a small accelerometer can add very little to unit cost while enabling a service contract worth far more. Decide this during hardware definition, using the discipline in how to write a product requirements document, because retrofitting a sensor into a shipped product is not a software change.
Three levels of prediction
- Rules and thresholds. "If temperature exceeds X three times in a day, raise an alert." Simple, transparent, explainable to a customer, and it covers a surprising share of real cases. This is where every program should begin.
- Statistical anomaly detection. The system learns each individual unit's normal behavior and flags deviation from it, without anyone defining a threshold in advance. Catches failure modes you did not anticipate, and handles the fact that two identical machines in different installations have different baselines.
- Machine learning models. With labeled failure history from hundreds of units, you can train a model that estimates probability of failure within a time window. This is the powerful level, and it requires volume plus honest labeling — see AI in hardware products.
The standard mistake is jumping to level three on day one. Without failure history there is nothing to learn from. Start with rules, accumulate labeled events, and upgrade when the data has matured.
Closing the loop from prediction to action
A prediction sitting in a dashboard is worth nothing. The loop has to close:
- Route the alert to whoever can act — the customer, a field technician, or a service desk — with a plain statement of what to check and how urgently.
- Manage at the fleet level. Aggregate view reveals a model or a production lot failing more than the rest, which is a manufacturing fix, not a service fix.
- Show the customer an equipment-health view so the value is visible between service events, not only when something breaks.
- Capture feedback. Was the alert justified? That answer is the raw material for improving accuracy and the labeled data your future model needs.
- Ship improvements to the fleet. Updated thresholds and detection logic reach deployed units through OTA firmware updates.
Common traps
- Collecting everything just in case. High-rate sampling of every channel inflates connectivity and storage cost without improving prediction. Sample at the rate the prediction needs, and aggregate on the device where possible — the economics are laid out in IoT cloud infrastructure cost.
- Alert fatigue. A system that shouts about every minor deviation loses user trust within weeks, after which real alerts get ignored. Tune sensitivity against the actual cost of a false alarm versus a miss.
- A model with no owner. Prediction logic needs ongoing maintenance: usage patterns shift, new hardware revisions ship, suppliers change. Without an assigned owner, accuracy erodes silently.
- Overpromising. "We predict every failure" is a claim nobody can honor. Sell reduced downtime and smarter maintenance, not prophecy — and keep the customer's data governed properly, which is part of IoT security for connected products.
The business model underneath the technology
Predictive maintenance is one of the strongest engines for recurring revenue from a physical product: a premium service tier, a smarter maintenance contract, or an uptime commitment that a commercial customer will pay for because it maps directly to their cost of downtime. That is how a technical feature becomes a subscription worth buying — the structures are compared in hardware as a service. Remember the privacy side as well: usage data from customer sites needs clear consent, security, and a written policy, and this article is engineering guidance rather than legal advice on data handling.
Bottom line
Predictive maintenance is not a research project, it is a ladder: the right sensors chosen during hardware definition, reliable time-series capture, simple rules delivering value from week one, and machine learning once the data justifies it. Planning that ladder up front produces both a more reliable product and a business with recurring revenue. If you are designing a connected product and want prediction built into the architecture rather than bolted on later, describe your product through the contact form, or start with our software development guide.