When plants start talking about AI adoption, the conversation usually begins with models — which algorithm, which vendor, which accuracy figure. But the point where projects actually stall is almost always earlier than that: there is no data to train on.
Why manufacturing AI PoCs keep failing
Stories from plants that have run a PoC sound remarkably alike. They hired consultants and picked a model, but when it was time to hand over data:
- Sensor data was locked inside PLCs and individual machines — there was no way to get it out
- What existed was a few weeks of snapshots — no history long enough to capture seasonality or equipment degradation
- Time series existed, but without context — which machine, which lot, which conditions
- Gaps from server swaps and network outages were left as-is
Swapping models doesn't change the outcome. The bottleneck in manufacturing AI is not the algorithm — it's the data.
Models became a commodity. Your data didn't.
Over the past few years, anomaly-detection and forecasting models have effectively become commodities. Papers, open source, commercial services — they're everywhere. Anything every factory can buy is not a competitive edge.
Your plant's data, on the other hand, is something only you can have. The vibration signature of this line, the degradation curve of this machine, the seasonality of this process — that is the real asset of manufacturing AI, and the only moat that deepens over time.
Good training data has three properties:
- Continuity — unbroken time series. Too many gaps and baseline learning collapses.
- Context — which asset and process each tag belongs to (asset hierarchy), and what was happening at the time (alarms, work orders, lots).
- Quality — synchronized clocks, consistent units, deduplication. Fixing these later costs many times more.
So what should you collect?
You don't need a grand program. The priorities are clear:
- Sensor time series: core tags like temperature, pressure, vibration, current. One-second resolution covers most analytics.
- Alarms and events: what fired when, and how it was handled. This is what puts labels on otherwise unlabeled time series.
- Production context: work orders, lots, items. You should be able to answer "what were the production conditions in this window?"
- Asset hierarchy: an ISA-95 view of plant → line → equipment → tag. Ten thousand tags become navigable data once the hierarchy exists.
What a collection layer must provide
- Standards-based acquisition — OPC-UA, Modbus, SECS/GEM and other standards keep the system alive when equipment changes.
- Edge collection that survives outages — networks will go down. Without local buffering and automatic retransmission on recovery, continuity is lost.
- A purpose-built time-series store — stuffing per-second tags into a relational database won't survive a year. You need a store with compression and retention policies.
- A catalog — data has to be findable by anyone before an AI team can start working.
A realistic roadmap — six months is enough
- Month 1: pick one critical line and start collecting its key tags. One line, not the whole plant.
- Months 2–6: accumulate time series while connecting alarms, work orders and lots. Use this period to fix quality issues — gaps, units, clocks.
- After month 6: start with anomaly detection on the accumulated history. Because the baseline data is already there, the AI project becomes a model-validation project instead of a data-hunting one.
Closing
AI is a function that only runs on data. The data you start collecting today decides the outcome of your AI project six months from now. Put differently: if you don't start collecting now, you'll be having the same conversation in six months.
PlantPulse was built for this "before AI" stage: 42 industrial protocol drivers for acquisition, edge store-and-forward for continuity, and a time-series store with a data catalog for context — all on-premises. Once the data is ready, AI follows.