Historian data (and ML)

Every ML ambition in a plant runs through one unglamorous asset: the historian. OSIsoft PI, Wonderware, GE Proficy, or a homegrown SQL store — it holds years of the exact data models need, and it's already there. Plants that start ML from the historian get first results in days; plants that start by building a data lake often get their first results in the following fiscal year.

What models need from it

Three things, in order of pain. Resolution: historians compress (deadband, swinging-door); aggressive compression can erase the very transients a model needs. Check actual stored resolution against what the failure modes require. Tag semantics: models don't care that a tag is called TT4711, but engineers acting on attributions do — a tag-mapping pass is part of every serious deployment. Context: product codes, lot IDs, shift and changeover markers turn anonymous time-series into regime-aware training data; without them models confuse a product change with a process drift.

Practical sequence

Connect the historian read-only, backfill 6–24 months, map the tags that matter, add context feeds (MES/ERP product and lot data), and let the platform train. Vendors differ enormously in how much of this they automate — it's a better demo question than anything about algorithms.

FAQ

How much historian data do ML platforms need?

Enough normal production to cover real operating regimes — commonly 6–24 months backfill. More products and seasonality push toward the high end; a stable mono-product line can start lower.

Do we need to clean the data first?

Not exhaustively — modern platforms tolerate gaps and noise. Fix what changes conclusions: stored resolution, tag mapping for the variables that matter, and regime context (product/lot/shift). A perfection-first cleansing project is where momentum goes to die.