This is a manufacturing & supply chain problem we approach through our Data to Data service line.
The problem
Every site has data. Historians, PLC tags, SCADA logs, vibration sensors, temperature and flow, sometimes a vendor’s own monitoring box on a critical asset. The data exists and it is being written down.
What the engineering manager cannot do is answer a question across it. Which assets are deteriorating, which sites run the same machine differently, and whether last month’s unplanned stop had a signature that was visible beforehand. Answering any of those means somebody exporting a range from a historian into a spreadsheet, and the answer expires the day it is produced.
The vendor monitoring boxes make it worse rather than better. Each covers one asset class, each has its own interface and its own alarm philosophy, and none of them can compare across sites.
Why it’s hard
Time is unreliable, and everything depends on it. Devices disagree about the clock, gateways buffer and back-fill after a network outage, and historians resample. Condition monitoring is largely about relationships between signals over short windows, and a few seconds of skew between two devices destroys the relationship before any analysis touches it.
Sampling rates are heterogeneous and lossy. One tag at 1 Hz, one at 1 kHz, one written only on change of value beyond a deadband. Aligning them requires choosing an interpolation and aggregation policy, and that choice is a modelling decision that most pipelines make accidentally.
Late data invalidates yesterday’s answer. A gateway that reconnects and back-fills six hours changes the history you already computed features and alerts against. Unless the pipeline can be replayed to a known point in time, you end up with two versions of last Tuesday and no way to say which one an alert was based on.
Failure labels are scarce, which is good news operationally and bad news for modelling. A critical asset that has failed three times in a decade gives a supervised model three positive examples. Any project that opens with “we will train a failure prediction model” needs to answer where the labels come from before anything else.
Normal is not one thing. Product changeovers, seasonal ambient conditions, different operators and different feedstock all move the operating envelope. A static threshold generates alarms on a legitimate state change, and after enough of those the alarm is muted, which is worse than never having built it.
The OT boundary is a real constraint, not a policy preference. Plant networks are segmented, sometimes with unidirectional gateways, and adding a data path out of the control network is a safety and security review rather than a firewall rule.
An early warning is worthless if nothing consumes it. A model that flags a bearing two weeks out only has value if maintenance planning can act on a two-week signal. If the planning cycle cannot, the correct project is a shorter horizon or a different asset.
How we approach it
Land raw, then transform. Telemetry is landed as received, with the source timestamp and the arrival timestamp both preserved, before any resampling. A device sending nonsense on a Friday afternoon should be a diagnosable event, not a mystery in a report.
Stream ingest with a durable log. Kafka as the ingest path, so back-filled and late data are ordinary cases rather than exceptions, and so replay is available when a gateway floods six hours of history at you.
A time-series store chosen for the access pattern. Wide-column stores handle “all signals for this asset over this period” well, which is the query condition monitoring actually asks. We have built and operated this shape on Cassandra and ScyllaDB.
Feature generation with point-in-time discipline. Rolling statistics, residuals against an expected envelope, rate-of-change and cross-signal relationships, computed by an engine that guarantees a feature for a given timestamp uses only data available at that timestamp. Getting this wrong makes every backtest look excellent and every deployment disappointing.
Thresholds and residuals before models. First deployment monitors deviation from an expected operating envelope, conditioned on state — running, idle, changeover. It is explainable to the engineer who has to act, and it establishes the alerting path before anything harder is attempted. Models come after there is a labelled history worth training on, and we say so rather than selling the model first.
Backtest the alerting, not just the model. Before any alert reaches a person, it is replayed against history: how many times would this have fired last year, on what, and would the maintenance team have thanked you. Alarm load is a design parameter.
Self-monitoring, because a silent feed is the common failure. Prometheus and Grafana with staleness and rate-of-change checks on the pipeline itself, plus notifier scripts for proactive alerting. A stopped feed looks perfectly healthy to a liveness check, and a condition-monitoring platform that is not watching its own inputs will report that everything is fine indefinitely.
What we would not do. We would not open with failure prediction. We would not add a data path across the OT boundary without the plant’s own security and safety process. And we would not deploy alerting into a maintenance process that has no capacity to act on it — that produces alarm fatigue and a cancelled project.
What it takes
Tag inventory and asset hierarchy. Which tags exist, which asset each belongs to, and what the engineering units are. This is nearly always the longest phase, and it is plant knowledge rather than data engineering.
Time synchronisation across devices. NTP discipline on gateways and controllers. Without it, cross-signal analysis is not available at any budget.
A recorded maintenance history. Work orders, failures and interventions, with dates that can be joined to telemetry. This is the label set. If it exists only on paper, that is the first project.
An agreed data path out of the control network, signed off by the people accountable for plant safety.
A maintenance planner who will consume the output, and agreement on what horizon their process can act on.
Where this has been done
This is a pattern transfer, and we are stating that plainly: we have not delivered a condition-monitoring system in a manufacturing plant. No client, no reference, no figures. If a vendor tells you otherwise about themselves without naming an asset class, ask which one.
What we have built repeatedly is every component of the pattern, in other domains. A continuously operating ingest service normalising high-volume feeds from inconsistent sources onto one model, on Kafka into a wide-column store. A factor generation engine with enforced point-in-time semantics and its own expression language, so analysts author features without an engineering release, running on compute nodes that scale up for a job and shut down afterwards. A simulation engine that backtests a candidate model against history and A/B compares alternatives before anything goes live. And a production platform we operate with Prometheus, Grafana and custom notifier scripts doing proactive alerting on its own health.
That work was done in racing probability modelling and in a wagering platform we run. The subject matter is different; the engineering is not. What we would be learning on a first manufacturing engagement is the plant domain — asset classes, failure modes, maintenance practice — and we would rather scope that as learning than describe it as experience.