For predictive maintenance on production machinery, decide what to instrument from the failure modes you need to catch, and leave the model for later. On a CNC or gantry-mill spindle that means high-bandwidth accelerometers stud-mounted at every bearing housing, slow temperature sensors next to them, acoustic emission where the spindle is critical enough to pay for it, and one time-synchronised historian that stores raw signals against machine state from the first day. We treat sensor type, mounting, cabling and the sampling ceiling as the choices that are costly to change once installed. Thresholds, features and models are cheap to change, so spend the capital on the physical layer now and keep the flexibility in software. Alarm thresholds then come from each machine’s own measured baseline, not from a generic table.

Predictive maintenance sensors per spindle: types, counts and mounting

Per spindle, a workable bill of materials has a triaxial accelerometer (or radial plus axial units) at each bearing housing, an RTD at each housing, the spindle’s own speed and load signals from the controller, and optionally one acoustic emission sensor per critical bearing.

TechnoLynx can turn that outline into a specification you can build. TechnoLynx would start from your spindle speed range, bearing types and the failure modes you care about, and derive the bandwidth those require. From there TechnoLynx would specify mounting positions, channel counts, sample rates and anti-alias filtering, then check on representative spindles that the captured data resolves known or injected bearing fault frequencies before the bill of materials is finalised for the whole line.

ISO 20816, which supersedes ISO 10816 part by part, grades machines on broadband RMS velocity in mm/s measured at bearing housings over 10 to 1000 Hz. Velocity was chosen for general severity because it is broadly flat across the mid-range, while acceleration emphasises the high-frequency content where inner and outer race defects show up. Overall velocity catches unbalance, misalignment and looseness well but is largely insensitive to early bearing faults. iFactory’s bearing condition checklist notes that a bearing can carry a stage 2 inner-race spall showing 10× BPFI amplitude in the envelope spectrum with no change at all in ISO 10816 overall velocity. Keep the velocity channel for severity and protection, and add a bearing channel on top of it.

Spindle sensor specification at a glance

Channel	Sensor	Position	Sampling	What it is for
Bearing vibration	Accelerometer, flat to at least 10 kHz; for spindles above 10,000 RPM, 10–50 mV/g, response to 20 kHz, range ±100 g or more	Each bearing housing; vertical, horizontal and axial directions	25.6 kHz minimum per channel, 24-bit; 25.6–51.2 kHz hardware	Envelope spectrum at BPFO, BPFI, BSF, FTF
Bearing temperature	RTD with ±0.1 °C repeatability (preferred over thermocouples for stability)	Each bearing housing	1 Hz or slower, 16-bit	Trend of 2–5 °C above baseline signalling lubrication breakdown or early spalling
Acoustic emission (optional)	Resonant AE, 30–300 kHz	Critical-path and slow-speed assets	Envelope-detected at 25.6 kHz, or raw above 1 MHz with edge processing	Spall initiation before it reaches the vibration envelope
Machine state	Controller signals: spindle speed and power	Per machine	Recorded with each measurement	Context for every reading

Mounting method critically affects whether the sensor’s high-frequency response reaches the data. Stud mounting gives the widest usable bandwidth, adhesive mounting cuts it to roughly 5 kHz, and a hand-held probe is adequate only below 1 kHz. iFactory’s sensor buyer guide puts the amplitude error of magnet mounts at 10–30% and limits them to temporary surveys. Installation resonances can also mask the high-frequency content a micro-defect produces. Mark the measurement points physically, because trends only mean something when every reading comes from the same location and direction. Axial measurement matters most at thrust bearings, where axial dynamic forces are carried directly.

What sampling rate catches early bearing wear rather than noise?

The sampling rate follows from the bearing defect frequencies at the spindle’s maximum speed, and each spindle needs its own figure. Those frequencies are calculated from bearing geometry and shaft speed. One recommendation is an envelope spectrum of at least 800 lines with a maximum frequency of 10× the highest fault frequency of interest.

Worked example (assumptions stated). A 2025 spindle study ran its test bearing at 12,000 RPM, where BPFI was 1197 Hz, and sampled at 51.2 kHz. Ten times that BPFI gives an envelope band to about 12 kHz (1197 × 10). The envelope itself is demodulated from a high-frequency carrier, typically 5–20 kHz. Capturing a 20 kHz carrier needs a sample rate above 40 kHz by the Nyquist criterion. That makes 51.2 kHz, the rate the study used, a sensible target here; a 25.6 kHz minimum would not capture a 20 kHz carrier. Defect frequencies scale with shaft speed, so if the same bearing runs at 24,000 RPM, BPFI doubles to roughly 2394 Hz and every figure above moves with it. The same study notes that at around 80,000 RPM a single outer-race defect can produce impact rates above 20 kHz, with harmonics in the ultrasonic range.

iFactory’s sensor buyer guide states that most DCS systems sample at 1–10 Hz, which is enough for temperature and overall trends but not for envelope analysis.

Can acoustic emission replace the accelerometers, or is it redundant?

Acoustic emission is added to the accelerometers, not used in place of them. It detects spall initiation earlier than the vibration envelope does. A study of slow-speed crane bearings, cited in a review of acoustic emission for bearing monitoring, found that AE sensors detected defects before they appeared in the vibration acceleration range. iFactory’s sensor buyer guide puts AE sensors at roughly 20 kHz to 1 MHz, above the conventional accelerometer range, and says below about 300 RPM AE is often the only practical method. The accelerometer is still what supplies the envelope spectrum and the defect-frequency diagnosis.

AE earns its place on critical assets, and it costs data volume. The same guide puts broadband AE at 10–50 MB per second per channel at 1 MHz and says envelope detection at the sensor cuts the pipeline bandwidth by 40–60×. It also claims 14–28 days of lead time from a correctly specified accelerometer with envelope analysis on motors, pumps and fans at 900–3,600 RPM, and recommends AE where detection margin is critical. For a gantry-mill spindle whose failure stops a line, we would fit AE on the spindle bearings and leave it off the auxiliary drives.

Two caveats belong in the specification. Exact counts and positions depend on the housing design and on how accessible it is. Calibration also drifts: an uncalibrated accelerometer can drift 5–15% or more in sensitivity, and 12 months is the usual calibration interval. Whether sensors and mounts survive the environment for the life of the programme is its own validation problem, covered in our piece on choosing, mounting and proving the field reliability of a sensor suite.

What is the simplest historian to stand up from day one?

The simplest backbone that will still serve failure modelling later has three parts: a time-series store, an edge gateway per machine group that timestamps at acquisition and buffers through network loss, and machine-state tags written into the same store as the sensor channels.

TechnoLynx’s AI engineering for manufacturing team can design and deploy that backbone. TechnoLynx would identify which signals need capture and at what rates across your CNC machines and gearboxes, choose the historian, and decide where edge buffering or light pre-processing is justified and where raw signals can stream centrally. Then TechnoLynx would wire sensor timestamps to machine-state tags, replace separate vendor apps with one ingestion and dashboard layer, and validate data completeness and time alignment on every asset before production.

A historian is software that records and retrieves sensor data from equipment. In one documented deployment, a Raspberry Pi collected 100 Hz data from a PLC into a local Apache IoTDB instance, which synchronised its files to the cloud every 10 seconds. IoTDB’s format is built to save disk space: it encodes timestamps by second-order difference and compresses values with schemes such as Gorilla and RLE. In this design the historian only captures and retains data. It models nothing, and the analytics that consume the data are a separate decision.

Edge pre-processing or raw streaming to the central store?

Streaming every high-rate channel raw to the cloud is cost-prohibitive at scale. iFactory’s edge-computing guide estimates that one machine producing 10 kHz vibration data generates over 800 MB per hour, and that edge platforms filter 90–99% of it before transmission. Filtering everything has a cost too. Keeping only an RMS value per minute leaves nothing to look at when someone asks what the spectrum looked like the hour before a failure.

We would split the difference: continuous features and trends computed at the edge, plus periodic raw waveform snapshots kept centrally. The storage arithmetic supports that split. One worked demonstration recorded one second every ten minutes at 20 kHz, which came to about 4 GB per sensor-year, or a little over a terabyte a year for 300 sensors. The edge layer should also buffer locally through outages and sync once connectivity returns. Whether wireless links on a noisy factory floor deliver gap-free data is a reliability question in its own right, and it needs its own proof of continuous coverage.

One store, not five vendor apps or a spreadsheet

Put every machine into one shared historian from the start. Per-machine vendor apps each hold a partial view, and joining them later means reconciling different clocks, tag names and retention policies. A spreadsheet cannot hold waveform data, so starting there postpones the real system and leaves a gap in the history it was meant to collect. Migration between historians is a paid project of its own. One integrator says most of its migrations finish within two weeks of kick-off, longer beyond a few years of data or a few hundred thousand tags.

How do we tie sensor timestamps to spindle load, RPM and tool changes?

Set timestamps as close to acquisition as possible, in UTC, with a clock accuracy chosen from the fastest relevant process change. ICS Schneider’s planning sequence for industrial measurement data includes these steps:

1. Decide the maximum time error the later analysis can tolerate. If a process is evaluated every ten seconds, microsecond synchronisation adds nothing.
2. Choose NTP or PTP from that figure. NTP is generally sufficient for historian trends and normal alarms, while correlating machine events to a few milliseconds means validating NTP or considering PTP, and sub-millisecond multi-channel work usually needs PTP with hardware support.
3. Generate the authoritative timestamp as close to acquisition as possible, and record whether it is a measurement, polling, gateway or server time.
4. Store in UTC and convert to local time only for display, which avoids duplicated or missing ranges at daylight-saving changes.
5. Keep the original measurement time on buffered values, and monitor and log synchronisation status so that unsynchronised periods are visible.

Polled brownfield interfaces such as Modbus RTU need extra care. When a gateway reads sensors one after another and stamps them all with one time, it creates a simultaneity that never existed, and a better clock does not fix that. For machine state, ISO 17359 lists speed and power during the measurement among the fields worth recording alongside each reading. Write the controller’s spindle speed, load and tool-change events into the historian as tags on the same time base. That lets a later model separate running from idle, the way one commercial kit uses only data from running assets to build baselines and trigger alarms. Once data is landing, the next question is whether it is fit for modelling, which our guide to auditing and harmonising sensor histories covers.

How do we build a healthy baseline with no sensor history?

You build it by measuring the machine itself once it is known to be in good condition, after wear-in, separately for each operating state, under documented conditions. ISO 17359 defines baseline data as measurements taken when operation is known to be acceptable and stable, and notes that machines with several operating states may need a baseline for each. For in-service machines with no records, the accepted approach is to take readings during known stable operation, ideally after scheduled maintenance, and to record speed, load and temperature with them. New and overhauled equipment needs time for wear-in first, because measured values commonly change over the first days or weeks.

Baseline procedure for a new line

1. Confirm the machine is in known-good condition, shortly after commissioning or overhaul.
2. Fix and mark the measurement points and directions.
3. Let the wear-in period pass before you capture data.
4. Capture each operating state (speed bands, load levels) separately, and compare later readings at the same location, orientation and operating conditions.
5. Repeat on different days. iFactory’s bearing condition checklist, citing ISO 13373-1, asks for three envelope measurements and three concurrent housing temperatures on different days at the same operating condition.
6. Record machine and measurement metadata, including date, time and time zone, location, units and qualifier.
7. Keep absolute ISO limits active while the baseline builds, as Amazon Monitron does by raising only ISO-model alarms during its learning period.
8. Rebaseline after replacement, repair or heavy maintenance.

How long must the commissioning run be?

The sources below give different figures for the commissioning run. Banner’s vibration kit builds its baseline from the first 300 running samples, about 24 hours. Amazon Monitron takes 14 to 21 days depending on duty cycle. Amazon Lookout for Equipment requires at least 14 days and asks for data covering every normal operating mode. Research on wind turbines shows what goes wrong when the window is too short: normal-behaviour models trained on scarce or unrepresentative data give unreliable fault detection. Our reading is that the run is long enough when it has covered every spindle speed band, load level and thermal state the line actually uses, after wear-in, and that 14 days is a floor for learned models, not a target.

Fleet-based monitoring uses comparable in-service machines as the reference, treating deviation from them as a fault signal. Treat it as provisional: in a wind-turbine study, a model trained on one machine was generally not usable on another with different characteristics. Replace the borrowed reference with the new line’s own data once you have it.

Alarm thresholds, lead time and the failures already in your log

Set alarms from the machine’s own baseline. Size the inspection or sampling interval from the P-F interval of the failure mode. Then test the whole arrangement against the failures you have already had.

Baseline-relative alarm and trip limits

ISO 20816-3 sets the ALARM limit at the machine’s own steady baseline plus 25% of the upper limit of Zone B, and normally no higher than 1.25 times that limit. For a Group 2 motor on a rigid base, Zone B ends at 2.8 mm/s, so the step is 0.7 mm/s: a baseline of 1.2 mm/s gives an alarm at 1.9 mm/s, and no alarm should sit above 3.5 mm/s. TRIP limits protect mechanical integrity and do not follow the baseline. The standard recommends keeping them no higher than 1.25 times the upper limit of Zone C, which is 5.6 mm/s for Group 2 rigid. Revise the alarm whenever the baseline changes, for example after an overhaul. Separately, any step change up or down of more than 25% of the B/C boundary counts as significant even inside Zone B, which is 0.7 mm/s for Group 2 rigid.

ISO 17359 practice as one source describes it uses multiples instead: alert at 150–175% of baseline, danger at 250–300%. Pick one per asset class and document it, because mixing them on one machine makes alarm history impossible to compare. Machine group and support type also matter: getting them right is the most common source of misapplied vibration alarms.

These ISO limits are set on broadband RMS velocity. The bearing channel is compared against its own baseline values. In iFactory’s bearing condition checklist, defect-frequency harmonics in the envelope spectrum at 2–5× baseline mark stage 2 wear, and housing temperature 2–5 °C above baseline marks caution, rising to alarm at 5–10 °C.

Which conditions raise a work order and which only get logged?

In ISO 20816 terms, Zone C is a planning trigger and not an emergency, while Zone D means stop or accept accelerated damage. The ISO 17359 alert level triggers a work order and more frequent monitoring, not shutdown. Require persistence before raising a ticket, so a single spike does not create one. Banner’s kit, for example, separates acute alerts (five consecutive samples over threshold) from chronic alerts (a 100-point moving average crossing it). Readings that cross a threshold once and then return can be logged for review.

How much warning before a seizure can we realistically expect?

Lead time is the P-F interval, the time between the first detectable sign of failure and functional failure, and it depends on the detection technology. In one bearing example, unusual vibration was detectable at about six months, airborne ultrasound at three months and heat at one month before failure. A reliability reference gives indicative ranges of 1–9 months for vibration analysis, 3–6 months for ultrasound and 1–4 weeks for thermography. For high-speed spindles specifically, the 2025 study reports that its method detected 150 µm defects with 72+ hours of additional warning. Ranges like these are averages, not promises for your bearings.

Inspect at less than half the P-F interval, so a defect that appears just after one inspection is still caught before failure. If parts lead time or repair complexity is long, subtract the mean time to repair from the P-F interval when setting the task interval. Continuous monitoring does not lengthen the P-F interval. It removes the gap between inspections, which matters most for failure modes measured in weeks.

Would this sensor suite have caught the failures already in our maintenance log?

What follows is our approach, not a standard method. For each logged failure, write down the failure mode, the date, and whether any data from the weeks before it exists. Check that the proposed channel set would have seen that mode at all, and estimate from its P-F interval when it would have fired. Once raw waveforms are being stored, you can run today’s detector over earlier data and see when it would have fired. With features alone that test is impossible. The thresholds then get tuned in both directions: set too high, they let silent failures through; set too low, they cause constant false alarms that erode trust in scheduling. ISO 17359 expects alarm criteria to be optimised iteratively. With only a few failures in the log, the evidence is thin, and the honest output is a judgement about each failure mode, not an accuracy figure.

Can we build on signals already in the historian, or do we need new instrumentation?

Existing tags can support feature engineering only if they cover the failure-relevant locations at a sufficient sampling rate and hold enough history spanning real degradation. Add instrumentation only where a specific failure mode cannot be seen in the current tags.

TechnoLynx can run that assessment. TechnoLynx would catalogue the available tags against the target failure modes and identify coverage gaps, choose spectral and statistical features and the channel mapping, build the feature extraction pipeline for the edge or historian-side compute where it will run, and validate the features against labelled wear and failure events before they go into service.

4–20 mA vibration transmitters that report only overall velocity can stay in place for protection alarms, with higher-bandwidth sensors added on the critical assets, and correctly specified accelerometers already fitted can be retained. ISO 17359 practice is to choose techniques from failure-mode analysis, not from whatever hardware is installed. One example given is gearboxes, where oil analysis catches some failures months before vibration would.

For features, time-domain RMS, spectral entropy and phase-space measures have all been used for bearing degradation, and adding complementary features improved the degradation models in one small-data study. Kurtosis tends to rise with spall impacts before RMS moves much. We judge a history by how many degradation-to-failure cycles it contains, not by how many months it covers. In wind-turbine monitoring, data has been found to go stale after maintenance, part replacements or ageing, when earlier records stop representing future operation. If bandwidth forces you to cut channels, cut only where another channel or a lower-fidelity proxy still detects that failure mode. Otherwise you lose early warning for faults the training history has not yet seen.

Which sensor choices to lock in now, and which to keep flexible

Lock in what is physically fixed: stud-mounting pads at every bearing housing, cable routes, accelerometers with bandwidth headroom above your top spindle speed, DAQ channel count and maximum sample rate, and the time-synchronisation scheme. Keep flexible everything that lives in software: features, thresholds, model choice, snapshot cadence and retention. We would fit a spare mounting point and a spare DAQ channel at installation rather than retrofit them later. A threshold you set too conservatively costs nothing to change.

Sizing the sensor spend to each spindle’s criticality

That depends on what an unplanned failure of the asset costs, which is why ISO 17359 programmes score every machine for criticality and let that score drive monitoring frequency and technique selection. For high-speed machining, the 2025 spindle study cites reports that bearing failures can account for 40–70% of unscheduled stoppages in machining centres. Work it out per asset from your own downtime cost and failure history.

A documented baseline makes later additions an evidence question

Write down the baseline as you capture it, so that any later sensor or model change can be judged against evidence. ISO 17359 lists minimum records for each machine (identifier, type, rated speed and power, drive configuration, support and coupling) and for each measurement (date, time and time zone, location and orientation, value, units and qualifier). It also suggests recording transducer type, attachment method, processing settings and calibration dates. Any hardware change then needs a defined requalification step, so that a new sensor or firmware revision cannot silently shift the baseline the alarms depend on.

We treat the mounting and bandwidth you put on each bearing housing this year as the decision hardest to undo. Everything else on this page can be revised as failures, and the data from before them, build up.

FAQ

Is vibration measured in mm/s?

For severity assessment, yes. ISO 10816 and ISO 20816 use broadband RMS velocity in mm/s over 10–1000 Hz for most machines, and permit displacement for machines below 10 Hz fundamental frequency. Bearing diagnostics rely on envelope spectrum analysis instead.

How is predictive maintenance different from preventive maintenance?

Preventive maintenance services equipment on a fixed schedule, while predictive maintenance acts on measured condition, intervening when monitoring detects that a failure has begun.