Problem Statement: A Cyber-Physical Early-Warning Platform
Frames predictive maintenance as four coupled planes: ingestion, detection, action, and learning.
Problem statement
Design a predictive maintenance platform for industrial machinery: factories, compressors, pumps, turbines, vehicles, and elevators. Sensors stream temperature, vibration, pressure, current draw, and usage counters. The system ingests that telemetry, applies rule thresholds and ML models to detect degradation early, predicts remaining useful life (RUL), and notifies reliability engineers so they open work orders before a failure stops production.
The business case is asymmetric. An unplanned outage on a paper-mill line costs $10K-$100K per hour; a bearing replaced on schedule costs a few hundred dollars plus planned downtime. Therefore the system is judged by two numbers: how many failures it predicted with enough lead time (recall at 7-30 days horizon) and how many false alarms it created (precision, because alert fatigue kills adoption).
Why this problem is distinctive
A web backend retries a failed request. A missed bearing failure destroys a machine. The design therefore separates mission success from detection correctness. Detection is a continuous, windowed computation over ordered per-machine streams. Action is a durable workflow: alert, acknowledgement, work order, parts, execution, feedback. Learning closes the loop: technician outcomes become labels that retrain models.
Public evidence shows the category operates at real scale. Komatsu has tracked more than 500,000 machines through KOMTRAX since 2001. Caterpillar reports more than 1.5 million connected assets. TK Elevator (ThyssenKrupp) connected more than 240,000 elevators to Azure IoT Hub and reported up to 50% downtime reduction. Rolls-Royce monitors more than 4,500 Trent engines and has publicly stated a single engine can produce up to 1TB of raw data per second in test conditions. These are company-reported figures, not our design targets.
The four architectural planes
- Ingestion plane: edge gateways, MQTT, schema validation, ordering, store-and-forward.
- Detection plane: streaming features, rule engine, ML anomaly and RUL scoring.
- Action plane: alert deduplication, prioritization, work orders, technician mobile flow, CMMS integration.
- Learning plane: historical lake, feature store, label collection, training, champion/challenger rollout.
A strong answer keeps these planes separate. Ingestion may lag without corrupting work orders. A model may be retrained without touching the rule path. A work order may be executed while dashboards are stale. The planes communicate through typed events, never shared mutable state.
Key Highlights
- •The product is measured by recall at 7-30 day lead time and by precision, because alert fatigue destroys adoption.
- •Public fleets prove scale: Komatsu 500K+ machines, Caterpillar 1.5M+ connected assets, TK Elevator 240K connected elevators.
- •Four planes: ingestion, detection, action, learning - coupled by typed events, not shared state.
- •High-rate vibration (10-25kHz) is processed at the edge; the cloud receives feature packets, not raw waveforms.
- •Technician work-order closures are the label source; the action plane feeds the learning plane.
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "I will separate detection correctness from workflow durability; they fail differently and recover differently."
- "Before choosing databases, let me define what ingestion, detection, action, and learning each own."