A technical resource by Fault Ledger — Dual-Mode Bearing Sensors — Predictive Maintenance + Forensic Evidence

Tag: edge AI

  • Dual-Mode Bearing Sensors: Why Predictive Maintenance and Forensic Evidence Need Different Architectures

    The bearing condition monitoring market has traditionally offered two distinct product categories: predictive maintenance sensors that trend vibration data over time, and forensic recording systems that capture high-fidelity evidence at the moment of failure. These two functions serve fundamentally different purposes, require different data architectures, and until recently, demanded separate hardware. This article examines why these architectures differ, what each one optimizes for, and how a single sensor platform can serve both roles through over-the-air firmware switching.

    The Predictive Maintenance Architecture

    Predictive maintenance (PdM) sensors are designed around one question: is this bearing degrading, and when should we intervene? This drives every architectural decision — from sampling strategy to data bandwidth to alert logic.

    Data Characteristics

    A PdM sensor captures vibration data at regular intervals — typically every few minutes to every few hours, depending on the criticality of the asset. Each measurement window might last 1–5 seconds at a moderate sampling rate (e.g., 6.4 kHz to 25.6 kHz). From each window, the system extracts summary statistics and spectral features:

    • Time-domain metrics: RMS velocity, peak acceleration, crest factor, kurtosis
    • Frequency-domain features: FFT spectrum, bearing defect frequencies (BPFO, BPFI, BSF, FTF), harmonic amplitudes
    • Derived indicators: Health scores, trend slopes, threshold exceedances

    The raw waveform is typically discarded after feature extraction. What gets stored and transmitted is a compact feature vector — perhaps 50–200 bytes per measurement — rather than the full time-series data, which could be 50–500 KB per capture window.

    Bandwidth and Storage Optimization

    This compression is essential. A wireless, battery-powered sensor cannot transmit hundreds of kilobytes every few minutes without exhausting its battery in days. The PdM architecture therefore optimizes for data efficiency: extract the diagnostic features on-device, discard the raw data, and transmit only what’s needed for trending and alerting.

    For a sensor sampling at 25.6 kHz for 2 seconds every 15 minutes, the raw data rate is approximately 3.4 MB/hour. After on-device FFT and feature extraction, this reduces to perhaps 800 bytes/hour — a compression ratio exceeding 4,000:1. This is what makes multi-year battery life possible on wireless PdM sensors.

    The AI Edge Processing Layer

    Modern PdM architectures increasingly process data at the edge — on the gateway rather than in the cloud. An edge AI system can run anomaly detection models, bearing defect classifiers, and health scoring algorithms locally, without requiring internet connectivity. This approach offers several advantages:

    • Latency: Anomalies are detected in seconds, not minutes (no round-trip to a cloud server)
    • Bandwidth: Only alerts and summary data leave the facility, reducing cellular/satellite costs
    • Availability: The system continues to function when internet connectivity is lost — critical for marine, mining, and remote installations
    • Data sovereignty: Sensitive vibration data (which can reveal production rates, equipment utilization, and process parameters) stays on-premises

    Edge AI models trained on bearing defect spectral signatures can classify the type and severity of developing faults — distinguishing an outer race defect from an inner race defect, for example — and assign a health score that maintenance teams can act on. This moves the intelligence from the cloud to the point of measurement.

    The Forensic Evidence Architecture

    A forensic recording system asks a fundamentally different question: when this bearing fails catastrophically, what physical evidence will survive? This inverts nearly every design priority of the PdM architecture.

    Data Characteristics

    Where PdM discards raw waveforms, forensic capture preserves them. The entire value of forensic evidence lies in the raw, high-frequency vibration data from the moments surrounding a failure event. Summary statistics and trend data are irrelevant — what matters is the unprocessed physics.

    A forensic capture system maintains a continuous rolling buffer of high-frequency data. When a terminal event is detected (shock threshold, spectral discontinuity, thermal excursion, acoustic transient), the system freezes the pre-event buffer and continues capturing post-event data for a fixed window. The complete evidence package might contain:

    • Pre-event waveform: 5–30 seconds of high-frequency acceleration data (e.g., 51.2 kHz, 3-axis) — the bearing’s vibration signature immediately before failure
    • Post-event waveform: 5–30 seconds of data capturing the failure itself and its immediate aftermath
    • Metadata: Timestamp, sensor ID, trigger conditions, temperature, battery voltage

    A typical forensic evidence package might be 2–10 MB of raw data — orders of magnitude larger than a PdM feature vector, but captured only once per failure event rather than continuously.

    Integrity and Chain of Custody

    The second critical difference is data integrity. PdM data needs to be accurate for diagnostic purposes, but it doesn’t need to be legally defensible. Forensic evidence does. The data must be:

    • Tamper-evident: Cryptographically sealed on-device at the moment of capture. Any alteration attempt must be detectable and must invalidate the record.
    • Chain-of-custody auditable: Full metadata documenting who captured the data, when, on what equipment, under what conditions, and who has had access to it since.
    • Multi-party neutral: No single party — equipment operator, OEM, insurer, or sensor vendor — should be able to unilaterally access, suppress, or alter the evidence. This is typically achieved through multi-party key control, where decryption requires keys held by multiple independent parties.

    These integrity requirements add architectural complexity that is unnecessary (and wasteful) in a pure PdM system. But for warranty disputes, insurance claims, and litigation, they transform raw vibration data into evidence.

    Why Both Architectures Matter

    The predictive and forensic architectures serve different stakeholders at different times in an asset’s lifecycle:

    • Predictive maintenance serves the maintenance team before failure — enabling planned interventions, parts ordering, and scheduled downtime
    • Forensic evidence serves the legal, insurance, and procurement teams after failure — establishing what happened, when, and what the physical signature looked like

    Consider a concrete scenario: a large gearbox bearing in a paper mill fails after 14 months of operation on a bearing rated for 50,000 hours. The bearing manufacturer claims the failure was caused by improper installation or contamination. The plant claims the bearing was defective.

    If the plant had PdM sensors, they might have trend data showing the bearing’s vibration levels increased over the final weeks — but the trending data was processed, averaged, and compressed. The raw waveform from the moment of failure was never captured.

    If the plant had forensic sensors, they’d have the high-frequency vibration signature from the seconds before and after failure — raw data that a bearing failure analyst could examine to distinguish between fatigue spalling (suggesting a manufacturing defect), brinelling (suggesting improper installation), or contamination wear patterns. And that data would be cryptographically sealed and chain-of-custody documented, making it admissible in a dispute proceeding.

    If the plant had a dual-mode sensor, they’d have both: months of PdM trend data documenting the progression of the fault, plus forensic evidence from the failure event itself.

    The Dual-Mode Approach: One Platform, Two Firmware Modes

    The hardware requirements for PdM and forensic capture overlap significantly. Both need:

    • A high-frequency accelerometer (MEMS or piezoelectric)
    • An on-device processor capable of FFT analysis and event detection
    • Flash memory for buffering and storage
    • Wireless connectivity (BLE, LoRa, or LTE)
    • Battery power and rugged enclosure

    The differentiation is almost entirely in firmware — the software that controls sampling strategy, data processing, storage policy, and transmission logic. This means a single hardware platform can run either mode, selected by firmware configuration.

    Over-the-air (OTA) firmware updates make this practical. A facility can deploy sensors in PdM mode for ongoing monitoring, then switch individual sensors to forensic mode when:

    • A bearing enters a warranty-critical period
    • A dispute is anticipated or underway
    • An asset has a history of unexplained failures
    • Insurance or regulatory compliance requires forensic-grade documentation

    The switch happens remotely — no physical access, no hardware replacement, no truck roll. The same sensor that was trending vibration data yesterday is now capturing forensic evidence today.

    Mixed-Mode Deployments

    In practice, most facilities benefit from running a mixed fleet. Critical assets with high failure consequences or active warranty disputes get forensic-mode sensors. The remaining assets run PdM-mode sensors for day-to-day monitoring. As conditions change — a new warranty claim, an insurance audit, a pattern of unexplained failures — individual sensors can be switched without disrupting the rest of the deployment.

    This flexibility turns the sensor from a single-purpose instrument into an adaptable platform that evolves with the facility’s needs. The hardware investment is made once; the monitoring strategy adapts over the air.

    Practical Considerations

    Battery Life Trade-offs

    PdM mode is inherently more battery-efficient than forensic mode. PdM sensors sample briefly at intervals and transmit compact feature vectors. Forensic sensors must maintain a continuous buffer — which means the accelerometer runs continuously at high frequency, consuming more power.

    In practice, this means a sensor in PdM mode might achieve 3–5 years of battery life, while the same sensor in forensic mode might achieve 1–2 years. This is a meaningful trade-off, but it’s managed at the deployment level: forensic mode is reserved for assets where the value of evidence justifies the shorter battery life.

    Gateway Requirements

    A dual-mode deployment benefits from an intelligent gateway. For PdM-mode sensors, the gateway runs AI-based anomaly detection and defect classification locally. For forensic-mode sensors, the gateway manages evidence retrieval and secure storage. Both modes benefit from edge processing that reduces cloud dependency and maintains functionality during connectivity outages.

    When to Use Which Mode

    Scenario Recommended Mode Rationale
    Routine monitoring of non-critical assets Predictive Maximize battery life, minimize data costs
    Critical assets with high failure consequences Forensic Evidence preservation justifies power cost
    Active warranty dispute on specific equipment Forensic Tamper-evident evidence for the dispute
    New bearing installation with warranty coverage Forensic Protect warranty claim rights from day one
    General fleet monitoring across a facility Mixed PdM for most, forensic for high-value/disputed
    Compliance-driven monitoring (insurance, regulatory) Forensic Chain-of-custody documentation required

    Conclusion

    Predictive maintenance and forensic evidence capture are not competing approaches — they’re complementary functions that serve different stakeholders at different points in an asset’s lifecycle. The convergence of both into a single hardware platform, switchable over the air, eliminates the false choice between monitoring and evidence. You deploy once and adapt the mission as needs change.

    For facilities that face both operational reliability challenges and post-failure disputes, a dual-mode sensor platform offers something that neither pure PdM nor pure forensic systems can: continuous visibility before failure and defensible evidence after it.

    For more on the technical architecture behind forensic bearing evidence capture, see our article on why tamper-evident data changes everything in multi-party disputes. For an example of a dual-mode platform in practice, see Fault Ledger.

  • Edge AI for Bearing Condition Monitoring: Why Local Processing Beats Cloud-Only Architectures

    The default architecture for IoT bearing monitoring has been cloud-centric: sensors capture vibration data, transmit it to a cloud platform, and algorithms running on remote servers perform analysis, anomaly detection, and alerting. This approach works — until it doesn’t. Latency, bandwidth costs, connectivity failures, and data sovereignty concerns are driving a shift toward edge AI, where anomaly detection and bearing defect classification run locally on the gateway rather than in the cloud. This article examines the architectural trade-offs and explains when edge processing is the right choice for bearing condition monitoring.

    The Cloud-Centric Model and Its Limitations

    In a typical cloud-based bearing monitoring architecture, sensors capture vibration data and transmit it wirelessly to a gateway. The gateway forwards the data (often via cellular or satellite) to a cloud platform — AWS IoT Core, Azure IoT Hub, or a vendor-specific SaaS platform. Cloud servers run the analytics: FFT computation, bearing defect frequency identification, anomaly detection models, and health scoring. Results are pushed back to dashboards and alerting systems.

    This model has clear advantages: elastic compute resources, centralized model management, easy software updates, and the ability to aggregate data across many sites for fleet-level analytics. But it has equally clear failure modes.

    Latency

    The round-trip time from sensor to cloud to alert can range from seconds to minutes, depending on connectivity, queue depths, and processing load. For most bearing monitoring applications, this latency is acceptable — bearing degradation unfolds over days or weeks, not seconds. But for applications where rapid response matters (e.g., automatic shutdowns, safety interlocks, or real-time operator alerts during commissioning), cloud latency introduces unacceptable delay.

    Bandwidth and Cost

    Transmitting raw or semi-processed vibration data over cellular networks is expensive. A single sensor capturing 2-second windows at 25.6 kHz every 15 minutes generates approximately 3.4 MB/hour of raw data. For a facility with 50 sensors, that’s 170 MB/hour or roughly 4 GB/day. At typical industrial IoT cellular rates of $1–5/GB, the data transmission cost alone can exceed $120–600/month — often more than the hardware amortization cost.

    Edge processing reduces this dramatically. If anomaly detection and feature extraction happen on the gateway, only compact summary data and alerts need to traverse the cellular link. The same 50-sensor deployment might transmit 50–200 KB/hour instead of 170 MB/hour — a reduction of 99.9%, bringing monthly data costs below $5.

    Connectivity Dependency

    Cloud-dependent systems fail when connectivity fails. This is not a theoretical concern — it’s a daily reality in many industrial environments:

    • Marine vessels lose cellular connectivity when more than 20–50 km offshore. Satellite links (Iridium, Starlink) provide intermittent, expensive, and bandwidth-limited alternatives.
    • Mining operations in remote locations may have unreliable cellular coverage or operate in radio-quiet zones.
    • Railway rolling stock passes through tunnels, rural dead zones, and areas with congested networks.
    • Industrial facilities in developing regions may have unstable internet infrastructure.

    An edge AI system continues to monitor, detect anomalies, and generate alerts regardless of connectivity status. Data synchronizes to the cloud when connectivity is available, but the monitoring function is never interrupted.

    Data Sovereignty and Security

    Vibration data from industrial equipment is more sensitive than many organizations realize. High-resolution vibration signatures can reveal:

    • Production rates and machine utilization
    • Process parameters and operating conditions
    • Equipment age and condition (competitive intelligence)
    • Maintenance practices and compliance status

    For defense contractors, energy infrastructure, pharmaceutical manufacturing, and other regulated or sensitive industries, transmitting this data to third-party cloud platforms raises legitimate security and compliance concerns. Edge processing keeps the raw data on-premises, transmitting only aggregated metrics and alerts.

    What Edge AI Actually Does for Bearing Monitoring

    The term “edge AI” covers a spectrum of capabilities. For bearing condition monitoring, the relevant functions include:

    1. Anomaly Detection

    The most fundamental edge AI function is answering the question: is this vibration pattern normal or abnormal? Anomaly detection models learn the baseline vibration signature of each monitored bearing during a training period, then flag statistical deviations from that baseline.

    Common approaches include:

    • Statistical methods: Z-score monitoring of RMS, peak, and crest factor values against historical distributions
    • Autoencoder neural networks: Trained on normal vibration patterns, these models produce high reconstruction error when presented with anomalous data
    • Isolation forests: Ensemble methods that efficiently identify outliers in multi-dimensional feature spaces

    These models are lightweight enough to run on gateway-class hardware (ARM Cortex-A processors, 1–4 GB RAM) with inference times measured in milliseconds.

    2. Bearing Defect Classification

    Beyond detecting that something is wrong, edge AI can classify what is wrong. Bearing defects produce characteristic frequency signatures:

    • BPFO (Ball Pass Frequency Outer Race): Outer race defect — typically the most common bearing failure mode
    • BPFI (Ball Pass Frequency Inner Race): Inner race defect
    • BSF (Ball Spin Frequency): Rolling element defect
    • FTF (Fundamental Train Frequency): Cage defect

    A classification model trained on labeled spectral data can identify which defect type is developing and estimate its severity — enabling maintenance teams to prioritize interventions and order the correct replacement parts before the failure occurs.

    3. Health Scoring

    Edge AI can compute a composite health score for each bearing, integrating multiple indicators (RMS trend, spectral energy in defect frequency bands, temperature, crest factor trend) into a single 0–100 score. This abstraction makes the data accessible to operators and maintenance planners who may not be vibration analysis specialists.

    Health score algorithms can be as simple as weighted threshold models or as sophisticated as gradient-boosted regression models trained on historical failure data. The key is that the computation happens locally, and the score is available immediately — no cloud round-trip required.

    4. Adaptive Sampling

    An underappreciated edge AI function is adaptive sampling — dynamically adjusting the sensor’s measurement frequency based on detected conditions. When a bearing is healthy, the sensor can sample infrequently (every 30–60 minutes) to conserve battery. When the anomaly detection model detects a developing fault, it signals the sensor to increase sampling frequency (every 1–5 minutes) for higher temporal resolution during the critical degradation period.

    This feedback loop between edge intelligence and sensor behavior is only possible when the AI runs locally. A cloud-based system introduces too much latency to make real-time sampling decisions.

    Edge vs. Cloud vs. Hybrid: Architecture Comparison

    Criterion Cloud-Only Edge-Only Hybrid (Edge + Cloud)
    Alert latency Seconds to minutes Milliseconds Milliseconds (edge) + enriched alerts (cloud)
    Connectivity required Always Never For sync only — monitoring continues offline
    Data transmission cost High ($100+/mo for 50 sensors) Near zero Low ($5–20/mo for 50 sensors)
    Model update complexity Simple (server-side deploy) Moderate (OTA gateway update) Both available
    Fleet-level analytics Native Not available Available when synced
    Data sovereignty Data leaves premises Data stays on-premises Raw data stays; summaries sync
    Hardware requirements Minimal gateway Capable gateway (ARM + RAM) Capable gateway

    For most industrial bearing monitoring deployments, the hybrid architecture offers the best balance. Edge AI handles real-time monitoring, anomaly detection, and alerting. Cloud services provide fleet-level analytics, long-term trend storage, model training on aggregated data, and remote management. The edge functions independently when connectivity is unavailable; the cloud enriches the analysis when connectivity is present.

    Gateway Hardware for Edge AI

    Running AI models at the edge requires more capable gateway hardware than a simple data forwarder. Typical requirements include:

    • Processor: ARM Cortex-A53/A72 or equivalent (e.g., Raspberry Pi Compute Module, NVIDIA Jetson Nano, NXP i.MX8)
    • RAM: 1–4 GB for model inference and data buffering
    • Storage: 16–64 GB for local data retention and model storage
    • Connectivity: BLE and/or LoRa radio for sensor communication; Ethernet, Wi-Fi, or cellular for cloud sync
    • Power: 5–15W continuous — typically mains-powered, though battery-backed options exist for remote sites

    The inference workload for bearing condition monitoring is modest by modern AI standards. A classification model running on a Cortex-A53 can process FFT features from 50+ sensors in under a second. This is not large language models or computer vision — it’s compact, specialized signal processing models operating on structured numerical data.

    When Edge AI Matters Most

    Edge AI is not universally necessary for every bearing monitoring deployment. It provides the greatest value in environments where:

    • Connectivity is unreliable or expensive: Marine, mining, railway, remote energy sites
    • Latency matters: Safety-critical equipment, commissioning checks, operator-attended machinery
    • Data sovereignty is required: Defense, regulated industries, competitive environments
    • Large sensor deployments need cost control: 20+ sensors where cellular data costs compound quickly
    • Operational continuity is critical: Facilities that cannot tolerate monitoring gaps during internet outages

    For a small deployment of 3–5 sensors in a well-connected facility, cloud-only processing may be perfectly adequate. For a marine vessel with 30 sensors and intermittent satellite connectivity, edge AI is not optional — it’s the only architecture that works reliably.

    Conclusion

    The shift toward edge AI in bearing condition monitoring is not a technology trend for its own sake — it’s a practical response to the real-world constraints of industrial IoT deployments. Connectivity is not guaranteed. Bandwidth is not free. Latency matters for some applications. Data sovereignty matters for some industries.

    Edge AI moves the intelligence to where the data is generated, enabling real-time anomaly detection, bearing defect classification, and health scoring without cloud dependency. When paired with cloud synchronization for fleet analytics and model updates, it provides the best of both worlds: autonomous local monitoring with centralized fleet intelligence.

    For a comparison of the wireless protocols that connect edge sensors to gateways, see our technical article on BLE vs LoRa vs LTE for bearing monitoring. Fault Ledger is one platform that implements on-gateway edge AI for bearing condition monitoring.

IoT Bearings — Technical Resources for Bearing Condition Monitoring