A predictive maintenance program is built on instruments: vibration probes on the bearings, thermal surveys of the panels, motor current signatures, oil samples sent to the lab, and a schedule for everything the instruments do not cover. It is very good at what those instruments measure, and it is blind to whatever they were not placed to see. The cameras a plant already runs watch many of the same machines, and they see the visible half of a failure: the leak spreading under a pump, a fire, product building up on a frame, a guard left open, a scene that has changed when it should not have.
Cameras also keep the minutes before a failure, so the technician can see what happened before walking over, and a plant's recorded repairs hold what the last technician did about it. This guide defines the maintenance strategies in plain terms, says honestly what sensors and cameras each see, and shows how the visual record, the recorded repair and a cited answer can join a maintenance program without displacing any of it. A reader should be able to decide where cameras earn a place in their own program by the end, whether or not they ever use VIDIZMO.
Reactive, preventive, condition-based and predictive maintenance
Maintenance strategies differ in what triggers the work, and each one is the right choice for some assets and an expensive mistake for others. Reactive maintenance, also called run to failure, waits for the machine to break and then fixes it. It costs nothing to plan and a great deal when the failure stops a line, so it suits cheap, redundant or non-critical assets such as a spare fan or a light fitting.
Preventive maintenance does the work on a schedule, by calendar time, run hours or cycle count, whether or not the machine needs it. It is simple to plan and audit, and it wastes effort on parts replaced while still healthy, while still missing failures that arrive between intervals. Condition-based maintenance does the work when a measured condition crosses a limit, such as vibration above a threshold, which spends effort only where it is needed but depends entirely on measuring the right condition.
Predictive maintenance goes a step further, combining condition monitoring with a prediction of when the failure will happen, so the work can be planned into the next scheduled stop rather than done as an emergency. Reliability engineers describe this with the P-F interval, the time between the point P where a developing failure can first be detected and the point F where the machine actually fails. A program's value comes from detecting failures early in that interval, and from having a plan to act before F.
| Strategy |
What triggers the work |
Strength |
Weakness |
Right for |
| Reactive |
The failure |
No planning cost |
Unplanned stops, collateral damage |
Cheap, redundant, non-critical assets |
| Preventive |
Calendar, hours or cycles |
Simple to plan and audit |
Replaces healthy parts, misses failures between intervals |
Assets with wear tied to use, regulated inspections |
| Condition-based |
A measured limit crossed |
Work only where needed |
Only as good as what is measured |
Assets with a measurable failure signal |
| Predictive |
A forecast of when failure will occur |
Work planned into scheduled stops |
Instrumentation, data and analysis cost |
Critical assets where a stop is expensive |
What sensors see and what they miss
Sensor-based predictive maintenance is good at the internal failures behind many of the most expensive breakdowns, and nothing in this guide argues otherwise. Vibration analysis finds bearing wear, imbalance and misalignment long before they can be seen or heard. Thermography finds hot connections in panels and failing insulation, motor current analysis finds rotor and load problems, oil analysis finds wear metals and contamination, and ultrasound finds leaks in compressed air and early bearing faults.
Each of those measurements reports only what its sensor was placed to measure, at the point where it was mounted. A vibration probe on a pump bearing says nothing about the seal that has started to weep onto the floor, the guard someone left open after a jam, or the carton wedged against a conveyor frame that is about to trip a motor. Those are visible failures, or visible precursors to failures, and they are common on a plant floor, because a great deal of downtime starts with something a person walking past would have noticed.
The cost of the failures that get through is large enough to justify looking at every source of early warning. Siemens' True Cost of Downtime research, as reported by the Institute for Supply Management, put unscheduled downtime at roughly 11 percent of annual revenues across the world's 500 largest companies, around $1.4 trillion a year. Those are headline figures for headline companies, and the mechanism they describe applies at every scale, since a stop that nobody saw coming costs far more than one planned into the schedule.
What cameras see before a failure
Cameras see a different set of early warnings from sensors, and most of them are things a maintenance technician would recognize on a walk-round. Leaks and pooling under pumps, valves and hydraulic units, drips from overhead lines, fire, product or debris building up on a machine, a guard or panel door left open, steam where there should be none, and a scene that has simply changed are all visible, and many of them are visible well before the failure they lead to.
The most useful method for these warnings needs no list of faults and no training data, because each camera learns what its own scene normally looks like. In AI Live Insight, a fixed camera spends a learning period sampling its normal view, from 15 minutes to 30 days with a week by default, and then flags any region inside its drawn zones that stays different from everything it learned. A pool spreading under a pump is flagged because it was not there while the camera was learning, without anyone having labeled a single leak. Each event arrives with a box around the region, a snapshot, a severity and a confidence, and when more than a third of the frame changes at once, because the camera was knocked or covered, the camera raises one tamper event instead of a burst of alerts.
That method's limits decide where it fits, and they should be stated plainly. It says that something changed, not what the change is, so a person still decides whether the region is a leak, a dropped rag or a pallet left for collection. It works on fixed cameras, and the learning period has to span the machine's normal variation, so a press area that looks different during changeovers needs a learning period that includes several changeovers, and a camera that is moved or re-aimed must relearn its view.
Fire is the other visible warning that ships as standard, because fire is a detection class on live feeds and a detection raises an alert. A fire starting in a dust extraction unit or a motor housing is a maintenance event as well as a safety one, and in an area with no flame or heat sensor the camera may be the first instrument to see it.
For situations nobody listed in advance, written questions are a further option. Frames cached from the live pipeline can be analyzed by a multimodal model against a question someone wrote, such as whether product is accumulating at a transfer point, which our article on anomaly detection without a preset list covers in detail. That analysis is an add-on that needs both AI Live Insight and AI Intelligence Hub, it runs after capture rather than in real time, each run consumes model usage, and its answers carry no accuracy figure, so the question should be kept in the record beside the finding.
Gauge reading, visible wear and misalignment come up in almost every maintenance conversation about cameras, and they are a different kind of work. A detection type for a specific gauge face or a specific wear pattern can be trained for the plant on its own footage, as part of an engagement scoped for that asset, and it then behaves like any other class, with its own confidence threshold and severity per camera. It is not a catalog feature that arrives switched on, and a plant should plan for the footage collection and labeling it needs.
The table below sorts the common visible warnings by the method that suits each, which is the first planning question for any camera added to a predictive maintenance program.
| Visible warning |
What it often signals |
Method that suits it |
| Leak, pooling or drip under a pump, valve or hydraulic unit |
Seal, hose or fitting failure |
Learned-normal anomaly detection on a fixed camera |
| Product or debris building up on a frame or transfer |
Coming jam, motor overload, fire risk in dusty areas |
Learned-normal anomaly detection, or a written question for a specific transfer |
| Fire in a motor housing, extraction unit or panel area |
Electrical fault, friction, ignited dust |
Fire detection on the live feed |
| Guard or panel door left open |
Unsafe restart, contamination, a repair left unfinished |
Learned-normal anomaly detection, or a trained class for that guard |
| Gauge reading out of range, visible wear or misalignment |
Process drift, mechanical wear |
A detection type trained for that asset in an engagement |
| Camera knocked, covered or refocused |
Loss of the view itself |
Camera tamper event |
These visible warnings are where most plants start, and it is worth seeing how other operations use them before choosing anything. Explore how organizations handle unplanned downtime on the cameras they already own.
The clip behind a failure
A large share of the time after a stop goes into finding out what happened, and footage of the minutes before it is often the quickest way to shorten that. Every camera AI Live Insight reads is recorded continuously for a retention window configured in days, 30 by default, so the minutes before a stop exist whether or not any rule fired at the time. Every alert carries a snapshot of the moment it started, and where recording is set up for the camera, a clip cut from that recording, including the seconds before the trigger, filed in the library by camera and time.
The practical effect is that a technician can watch what happened before walking over, and arrive with the right tools and the right question. A conveyor that stopped because a carton jammed at a transfer looks very different on video from one that stopped because a motor failed, and the difference decides whether the first person on the scene is an operator with a hook or an electrician. Our article on downtime cause analysis covers how stops are detected and evidenced, and our article on correlating a line stop with what the cameras saw covers conditions evaluated over recorded events across several cameras.
Joining sensor alarms to footage
A sensor alarm without footage and footage without an alarm each leave the technician guessing. The vibration system says the pump is in alarm but not whether there is water on the floor around it, while the camera shows the pool but not whether the bearing is also failing. Joining the two gives the technician the alarm, the reading and the view of the asset in one place, which is what lets a planner decide between an immediate stop and the next scheduled window.
That join is possible today, with tailoring, and it should be scoped as an engagement rather than expected as a shipped feature. The design that works is simple to describe: the condition-monitoring system calls a workflow over HTTP with the asset and the time of the alarm, the workflow finds the clip from the cameras that cover that asset around that time, and it raises a work order with the alarm details and the clip link attached. AI Intelligence Hub workflows can be called over HTTP by an external system and can call other systems' APIs in turn, which is what makes the design buildable without new product code.
Each plant still has to build several pieces, and listing them early keeps the engagement honest. The plant needs an up-to-date map of which cameras cover which assets, a condition-monitoring system able to make an outbound call when an alarm fires, a connector authored against the maintenance system's Application Programming Interface (API), and clocks on both sides kept in agreement so that the alarm time and the footage time line up.
Work orders that carry the evidence
The work order is where visual evidence pays for itself, because it is what the technician actually opens. An alert, or a monitor firing when a condition holds over recorded events, can reach the Computerized Maintenance Management System (CMMS) by webhook or through a connector authored against its API, carrying the detection type, camera, time, severity and the link to the clip. The maintenance system then creates the work order under its own rules, priorities and assignments, because it remains the authority on maintenance work.
Our article on connecting video AI to MES, SCADA and your maintenance system covers the mechanics, including how a new system is reached by authoring rather than custom code and how the integration engine is hardened for an Operational Technology (OT) security review. The boundary that matters most is the same in every case: events flow out to plant systems as information, and nothing writes to a control system.
The knowledge half: recorded repairs and cited answers
The other half of a maintenance program lives in people's heads, and much of it can be recorded. The repair the senior technician did on the filler last spring, filmed from their point of view and transcribed, is exactly what the night-shift technician needs when the same fault appears at 3 a.m. Speech in a recording is transcribed with every word aligned to the timeline, so a search for the fault name plays from the moment it was mentioned, and long repair recordings can be divided into chapters by step.
Manuals, wiring diagrams and schematics belong in the same library, where the text on a scanned page is searchable and a result opens at the page. AI Intelligence Hub can then answer a technician's question from that material, combining the recorded repair, the manual and past notes, and citing each source as a card the technician opens to check the method. An assistant can be scoped to one asset class or one line, so it answers from the right machine's material, and it answers only from what the asking technician is permitted to see.
The language models behind those answers can run on the plant's own servers, which matters when repair recordings show proprietary equipment and processes. Our guide to knowledge transfer in manufacturing covers how a plant builds that library in the first place, from choosing whose repairs to record first to keeping recordings current.
Where cameras are the wrong tool
Cameras add little to the prediction of internal failures, and a plant should be clear about that before it spends any of its predictive maintenance budget on them. Bearing wear, lubrication breakdown, electrical insulation failure, gearbox damage and anything inside an enclosed machine are invisible to a lens until the failure is well advanced, and the sensor program remains the right instrument for them. Remaining useful life estimates, vibration and thermal trend analysis, and decisions about maintenance intervals are the condition-monitoring program's work.
Cameras also need a view, and some plants do not have one where it matters. Machines inside enclosures, assets in areas no camera covers, and lines that are reconfigured so often that camera positions never settle will all get little from a learned-normal method. A plant whose critical failure modes are mostly internal will therefore get little from cameras for prediction, while still getting the clip that shows what happened when a stop does occur, which on its own often justifies the cameras that are already there.
Starting small
A plant gets the most from a first project by choosing one asset class with a visible failure mode and a camera already watching it. Hydraulic units that leak, conveyors that jam at a known transfer, and dust extraction where buildup and fire are the risks are all good candidates, because the warning is visible and the cost of missing it is known.
The learning period should span the asset's normal operation, including changeovers, cleaning and the quiet hours, and a week is a sensible starting point for most areas. The first weeks of alerts should then be reviewed with the people who maintain the machine, because they will recognize at once which flags are real warnings and which are ordinary activity, and their judgment is what tunes the zones, sensitivity and severity. Our article on alert fatigue and tuning confidence and severity covers that tuning in more depth.
The work order loop should be built before anything more ambitious, because an alert that lands in an inbox nobody owns is soon ignored. Once flagged events reach the maintenance system with a clip attached and technicians use them, the plant has the base on which sensor joins, recorded repairs and an assistant can be added one at a time.
Judging the first project needs measures the maintenance team already trusts, rather than a vendor's promise of reduced downtime. The useful ones are simple to count, such as how many visible warnings were flagged before they became a stop, how long it took from an alert to a work order, what share of work orders arrived with a clip, and how long technicians say diagnosis took with the clip compared with without it. Those numbers, gathered over a quarter on one asset class, are what a predictive maintenance budget holder will want to see before extending cameras to the next one.
How VIDIZMO helps
The approach in this guide combines three products, each doing the part it was built for. VIDIZMO AI Live Insight watches the cameras a plant already owns, learns each camera's normal scene, detects fire, keeps continuous recording and cuts a clip around each event it is set to record, and its live analysis runs on the plant's own servers near the cameras, because streaming every feed off site adds latency and bandwidth cost that real-time alerting cannot carry. Monitors evaluate conditions over the recorded events, and alerts and firings reach the maintenance system by webhook.
AI Intelligence Hub runs the written questions put to footage, the workflows that join an alarm or an alert to a work order, and the assistant that answers from recorded repairs and manuals with citations. VIDIZMO Nexus holds the repair library, with transcripts, on-screen and document text search and chapters, under the same permissions as everything else. We built them as separate products because plenty of plants start with the cameras alone and add the rest when the work order loop is working.
Predictive maintenance is one part of a wider picture, and the other guides in this series cover the ground around it. AI video analytics for manufacturing covers cameras as an operations instrument, AI for workplace safety in manufacturing covers fire, open guards and the safety program that shares the same cameras, and quality control in manufacturing covers the defects that start as equipment condition. If you want to see the visible warnings, the clip and the cited answer working on your own equipment, request a demo.
