Predictive Maintenance with Edge-Cloud Parity
The on-machine model and the cloud twin run the same binary. A divergence means a real fault — not a software artifact.
- 100%
- SolvSRK fault-detection recall
- 0%
- SolvSRK false-alarm rate (numerical)
- 23%
- Standard stack false-alarm rate
- 4.2 hr
- Mean lead time before alarm threshold
The scenario
Set the picture
A fleet of 200 CNC machining centers runs in three shifts. Each machine has a local PLC running a vibration model of the spindle bearings. A cloud twin ingests the same sensor data and runs the same physics model. When the edge model and the cloud model diverge, the maintenance system flags the machine for inspection.
The problem: today, 'diverge' usually means the two solvers disagreed on the last digits of an eigenvalue — not that a bearing is actually degrading. The maintenance team has learned to ignore divergence alerts. When a real bearing fault develops, the alert looks like every other false alarm.
Cost today
False-alarm rates of 15–30% from numerical solver disagreement between edge and cloud. Each false alarm costs a truck roll or an unplanned machine stop ($2K–$8K per event).
When maintenance teams learn to ignore the alerts, true bearing faults are missed. An undetected bearing failure in a CNC spindle costs $40K–$120K in scrap, machine damage, and unplanned downtime.
What changes with SolvSRK
When both the edge PLC and the cloud twin run SolvSRK, numerical divergence is zero under identical inputs. The maintenance system compares the twin's predicted vibration spectrum against the actual measured spectrum — and any divergence is, by construction, a real physical change in the machine.
On a 200-machine fleet simulation over 90 days with injected bearing degradation on 15 machines, SolvSRK-based twin parity achieved 100% fault-detection recall with zero false positives from numerical mismatch. The standard stack (different solver on edge vs. cloud) had a 23% false-alarm rate.
SolvNum's cross-platform determinism ensures the comparison hash is bit-identical regardless of whether the edge runs on ARM (typical PLC) and the cloud runs on x86.
Measurable outcome
What we claim — and how it survives review
Each line below maps to a captured number in the demo section. Every number is reproducible from the benchmark suite.
- 100% bearing-fault detection recall across 15 injected faults in a 200-machine fleet.
- 0% false-alarm rate from numerical solver disagreement (standard stack: 23%).
- Bit-identical edge-cloud model parity, verifiable by SHA-256 hash comparison.
- Mean time to detection: 4.2 hours before vibration exceeds alarm threshold (standard stack: detected at threshold, no lead time).
- Estimated annual savings per 200-machine fleet: $1.2M in avoided false-alarm truck rolls and early fault intervention.
The demo
What was tested. How. What the simulation printed.
200-machine fleet simulation, 90 days of 3-shift operation. 15 machines receive injected bearing degradation profiles (inner race spalling, cage wear, lubrication starvation — progressive over 2–14 days). Remaining 185 machines run nominal.
Two stacks compared: standard (scipy RK45 on cloud, vendor RK4 on edge PLC) and SolvSRK (same binary on both). Measured: fault-detection recall, false-alarm rate, mean time to detection, fleet maintenance cost model.
Captured benchmark output
The numbers the simulation actually printed.
| Stack | Recall | False alarm (numerical) | Mean lead time | Est. annual savings |
|---|---|---|---|---|
| SolvSRK (edge=cloud) | 100% | 0% | 4.2 hr | $1.2M |
| Standard (RK45 / RK4) | 100% | 23% | 0 hr | baseline |
Both stacks detect all 15 injected faults. SolvSRK detects earlier (vibration-spectrum divergence before threshold) and eliminates numerical false alarms entirely.
Composes with
Where this POC sits in the benchmark suite
POC 01
Self-Regulating Process Control Under Sensor Degradation
Self-regulating control provides the uncertainty-aware loop that responds to detected faults.
POC 04
Model-Free Sensor Anomaly Detection on Process Instruments
Sensor anomaly detection catches instrument faults that could contaminate the twin comparison.
Evidence pointers
Where the claims live in the evidence register
These are the validation sources a reviewer should trace to verify every number on this page.
- SolvSRK for Digital Twins — edge-cloud parity validation
- SolvNum cross-platform determinism verification (x86, ARM, WASM, CUDA)
- SolvSRK dynamics validation — 100,000-step drift-free integration
- Defense vertical — predictive-maintenance and fleet-readiness digital twin validation
Previous · POC 02
Multi-Regime Manipulator Dynamics
Next · POC 04
Model-Free Sensor Anomaly Detection on Process Instruments
Want to see these numbers on your plant?
Run the benchmark on your actual process model.
Two weeks, fully credited. No production integration needed. Every claim above traces back to a simulation you can verify.