Predictive maintenance with machine learning uses the data equipment already records to forecast when a component will fail, so it is serviced on the evidence rather than on a calendar or after a breakdown. For a UAV fleet that data is the flight log: voltage, current, throttle, inertial and GPS signals. Published cross-industry studies put the savings at 8 to 12 percent over preventive maintenance and up to 40 percent over run-to-failure, and Vozwin's own peer-reviewed research predicts drone battery state of health within 2.26 percent from flight logs alone, with no added sensors. The hard part is rarely the model. It is the data pipeline, the link to maintenance records, and getting the people who sign for the equipment to trust the forecast.
This guide is written for the operations, maintenance and business leaders who decide whether to start a predictive maintenance project and how to run it. It covers where the value comes from, a readiness check you can run on your own data, the build, buy or partner decision, how to scope a pilot, the Canadian funding programs that apply, and the adoption work that decides whether the forecast is ever used. Drone fleets are the worked example throughout. The same logic holds for any fleet of equipment that logs its own operation.
Where the value comes from
Predictive maintenance has been studied across enough industries for long enough that the savings are well documented. The figures below are cross-industry benchmarks, useful for sizing a business case, not a promise for any specific operation:
| Outcome | Published result | Source |
|---|---|---|
| Cost vs. preventive maintenance | 8% to 12% lower | U.S. Department of Energy, O&M Best Practices |
| Cost vs. reactive maintenance | Up to 40% lower | U.S. Department of Energy, O&M Best Practices |
| Breakdowns | Reduced by 70% | Deloitte Analytics Institute |
| Maintenance costs | Reduced by 25% | Deloitte Analytics Institute |
| Productivity | Increased by 25% | Deloitte Analytics Institute |
Cross-industry averages from published studies, cited in full under Sources.
Drone fleets make the case sharper than most. For UAVs, maintenance can represent more than 50 percent of direct operating costs, and published reliability analyses still put the overall failure rate of UAV systems around 25 percent. An unplanned grounding costs more than the repair: a missed inspection window, a crew and a permit to reschedule, and a client who trusts the next date a little less.
Notice where the value actually lands. It is not in the model. It is in decisions that change: fewer parts replaced while they still had life, fewer emergency repairs, maintenance windows planned around demand, and spares ordered against forecast dates instead of a safety stock sized for the worst month. A business case that cannot name the decision it changes is not ready for a pilot.
Four maintenance strategies, and what each asks of your data
Most operations run one of the first three strategies. Each has a different data requirement, and that requirement is what decides how far you are from the fourth:
| Strategy | What triggers work | Data it needs | Where it falls short |
|---|---|---|---|
| Reactive (run-to-failure) | Something breaks | None | Emergency repairs cost more, failures damage surrounding parts, and in-flight failures carry injury and liability exposure. |
| Preventive (calendar or hours) | A cycle count or time interval | Usage counters | Replaces parts regardless of their condition and still misses failures that do not follow the schedule. |
| Condition-based (thresholds) | A monitored parameter crosses a limit | Live readings from dedicated monitoring hardware | No forecast. The warning arrives when the limit is hit, too late to plan around. |
| Predictive (machine learning) | A model forecasts remaining useful life | Operating history plus known outcomes (failures, replacements, capacity checks) tied to each asset | Needs a clean data pipeline and modelling expertise, which is where projects stall without the right partner or product. |
The third column is the one to audit first. Most operations already record the operating history. What they rarely keep is the outcome data that tells a model what degradation looked like.
A readiness check before you spend anything
The same questions a general AI readiness assessment asks apply here, narrowed to one use case. You can answer most of them internally in a week:
- Is the data being recorded? A typical flight controller logs more than 400 parameters on every flight. Most fleets discard nearly all of it. If logs are overwritten on the aircraft, the first project is keeping them.
- Is it tied to the asset? Every log needs to be attached to a tail number, a component and, ideally, a pilot. Logs sitting in a shared folder with no reliable link to the aircraft are raw material, not a dataset.
- Do you have outcomes? A model learns from what happened: a capacity measurement, a replaced motor, a failure. If replacements are recorded but not why, or capacity is never measured, that gap is the first thing to close.
- Is there enough of it? Less than most people expect. Vozwin's battery research reached 2.26 percent accuracy from 631 flights on eight packs. A few hundred well-labelled records beat years of unlabelled ones.
- Can the data leave the site? Many fleets fly for clients whose logs cannot go to a public cloud. That constraint rules options in or out before any vendor conversation starts.
- Who owns the decision? Someone has to be accountable for acting on a forecast, usually the maintenance lead. If nobody is, the pilot will produce a dashboard and nothing else.
Regulated operators often have a head start they do not notice. In Canada, Part IX of the Canadian Aviation Regulations already requires the owner of a remotely piloted aircraft system to keep a record of each flight for 12 months, and of every maintenance action, modification and repair, including who did the work and when, for 24 months. Those records are the outcome data a model needs. The readiness question is whether they are kept in a form a pipeline can read.
Build, buy or partner
Once the data question has an answer, the next decision is who does the work. There are three honest options, and most operations end up combining two of them:
| Option | What you get | What it asks of you | When it is right |
|---|---|---|---|
| Build in-house | Full control of the model, the data and the roadmap | Data scientists, data engineers, infrastructure, and a long runway before the first useful forecast | Predictive maintenance is core to your competitive position and you can hire and keep the team |
| Buy a product | A model already validated on the component type, with the pipeline and evidence built in | Integration with your logs, records and maintenance system, and a vendor you trust with your data | The component is common (batteries, motors) and a product exists that was designed for your equipment class |
| Partner | A team that scopes readiness, builds the pipeline and integration, and runs the pilot with you | Time from your maintenance and operations people, and clear ownership of the result | You lack in-house data expertise, or the product needs integration work your team cannot absorb |
Buying the model and partnering on integration is the common path. Few fleets have a reason to rebuild a validated battery model from scratch.
One warning applies to all three. Generic industrial predictive maintenance models rarely survive contact with drones. UAV batteries and motors come in dozens of configurations, with very little history per type and strict weight limits on any sensor you might add. Whatever you build or buy should have been designed for those constraints, and should prove it on equipment it was not trained on.
Scoping a pilot that proves something
A good pilot is narrow, measured against a baseline, and decided in advance. This sequence works for most fleets:
- Pick one component and one decision. Battery retirement is the usual first choice: the data is already logged, the decision is frequent, and the cost of getting it wrong is easy to count.
- Write down the baseline. How packs are retired today, how many were pulled early or failed late last year, and what each outcome cost. Without a baseline, any result looks like success.
- Collect and condition the logs. Capture flight logs after every flight, tie them to the asset, clean them, and set aside the outcome measurements. This step usually takes longer than the modelling.
- Hold out equipment the model never sees. Accuracy measured on the units the model trained on tells you nothing about the next one. Vozwin's published 2.26 percent figure is on a battery the model had never seen, which is the only kind of number worth comparing.
- Run in shadow mode. Let the forecast run alongside the current schedule without changing any decision, and compare what it would have done with what actually happened.
- Decide on the result you agreed to. Accuracy on held-out equipment, whether the stated confidence matched the outcomes, how many decisions the forecast would have changed, and whether the maintenance lead would have acted on it.
Pilot success is a decision changed, not a dashboard built. If the shadow run shows the forecast would have retired the right packs at the right time, the next step is letting it drive the decision on part of the fleet.
What the research shows is possible with small data
Under the PHUMS project, Vozwin worked with McGill University and Université de Sherbrooke to predict UAV battery state of health from flight data. The team flew 631 experiments on lithium polymer packs of 2,200 mAh and 1,100 mAh, using only the voltage, current and throttle from each discharge cycle: the signals a stock flight controller already records. To work around the small dataset, each flight's time series was converted into an image so a pretrained ResNet-50 vision model could extract features from it, and what the model learned on one pack type was transferred to the other.
The published result is a test error of 2.26 percent on a battery the model had never seen. Continued training on a larger dataset since publication has brought that to 1.57 percent. The companion guide on drone battery state of health walks through the method as a small-data case study, and the peer-reviewed paper is linked under Sources.
Motors are the next component, and the constraint there is weight: dedicated vibration sensors can add as much as a tenth of a small drone's mass. Vozwin's approach predicts motor health from the accelerometers, gyroscopes, barometer and GPS a drone already carries, with camera footage as a second opinion. The lesson for any project is the same: start from the signals you already have before you buy hardware.
Canadian funding that applies
Predictive maintenance projects often involve genuine technical uncertainty, which is what Canada's main innovation programs are built to support. The ones worth checking first:
- SR&ED. The federal Scientific Research and Experimental Development tax incentive refunds a significant share of eligible experimental development spending for Canadian-controlled private corporations. Building a model for a component or equipment class where no proven approach exists can qualify. Integrating an off-the-shelf product usually does not.
- NRC IRAP. The Industrial Research Assistance Program funds part of the salary and contractor costs on eligible innovation projects for small and mid-sized businesses, and assigns an industrial technology advisor to the project.
- Mitacs Accelerate. Co-funds research internships that pair a company with graduate students and faculty at a Canadian university. The battery research in this guide was supported by Mitacs Accelerate, which is how a small team got access to university-grade modelling expertise.
- Provincial programs. Most provinces run their own technology adoption and R&D support that can stack with the federal programs. Check what your province offers before you set the project budget.
Structure the project around the programs before work starts, not after. Eligibility depends on how the work is scoped and documented, and your SR&ED advisor should see the plan first.
Getting the crew to act on the forecast
Most predictive maintenance projects that fail technically are fine. They fail because the person who signs for the aircraft does not trust a number they cannot check. Five design choices decide whether the forecast gets used:
- Evidence with every alert. Each forecast should name the component, the failure mode and the data behind it, so the maintenance lead can verify it before pulling a part. A score with no reason is a threshold alarm with extra steps.
- Calibrated confidence. A forecast should say how sure it is, and that stated confidence should hold up against outcomes. Ask to see the calibration, not just the accuracy headline.
- Physically possible outputs. A battery cannot regain capacity between flights and a motor cannot un-wear. A model with no notion of how components degrade will eventually forecast something impossible, with full confidence, and one of those is enough to lose the crew.
- Actions written into the record. Every decision taken on a forecast should land in the maintenance record the operation already keeps, with the who, the what and the date. If the crew has to keep a second set of books, they will stop keeping one of them.
- A floor that does not move. The forecast sits on top of the manufacturer's maintenance instructions and any regulatory requirements. It tells you which aircraft needs attention first; it does not replace the schedule you are required to follow.
Bring the maintenance lead into the pilot from the first week. The fastest route to adoption is a crew that helped decide what the forecast should show and watched it get the shadow-mode calls right.
Red flags in predictive maintenance offers
- Accuracy reported on the training data. The only number that predicts real-world performance is accuracy on equipment the model never saw. Ask which one you are looking at.
- New sensors required before anything works. Sometimes justified, often not. For drones in particular, added hardware costs weight, flight time and battery life, and the flight controller already logs the signals that matter.
- A score with no explanation. If the output needs a data scientist to interpret, the maintenance lead will not act on it.
- No way to write to your records. A product that cannot export to your logbook or maintenance system creates a parallel record nobody maintains.
- Cloud-only deployment when your data cannot leave the site. Look for edge or air-gapped options running the same model, not a reduced version.
- Plug-and-play promises. The pipeline, the integration and the adoption work are real. A vendor or consultant who says otherwise has not done it.
Where Vozwin AI, Vermilion and Vozwin Aerospace fit
Vozwin funded and owns the battery and motor state-of-health research described above, carried out through its Labs division with McGill University and Université de Sherbrooke and supported by the Mitacs Accelerate program. Vermilion is the production platform built on it: a physics-informed reasoning model, incubated in Vozwin's venture studio and now operating as its own company, production-ready and available for deployment on edge, cloud or air-gapped infrastructure. Vozwin Aerospace works the aircraft side, building UAV platforms that log these signals from the first flight.
Vozwin AI is the part of the group that helps an operation get from interest to a working pilot: the readiness check on your logs and records, the build, buy or partner call, the data pipeline and the integration with your maintenance systems, the pilot design and baseline, and the adoption work with your crew. The same approach applies beyond drones to any equipment that logs its own operation. If you want to know what your data can already predict, that conversation starts with what you record today.