Historian data can support an Industrial AI model, but an export of tags and timestamps is rarely a training-ready dataset. Before data moves into an external model-training workflow, a historian engineer needs to establish what each measurement means, when it happened, which asset produced it, and whether the record is reliable enough for the task.
Start with the industrial decision, not the model. A team might want earlier warning of a pump condition or a better way to investigate recurring process deviations. Each goal requires different measurements, context, and evidence. A generic “AI dataset” usually creates more rows, not better training examples.
Start with the industrial decision, not the dataset
Define the asset or process, the decision the model is meant to support, and the time at which a prediction would be useful. Then identify what the model could legitimately know at that time.
For a centrifugal pump, the question might be: “Given the pump’s recent operating signals, should a reliability engineer review it?” That is different from asking a model to declare the cause of a failure. The first question can guide the selection of relevant historian measurements, operating states, alarms, maintenance records, and outcome labels.
This step also limits accidental leakage. A record created after a maintenance decision, for example, should not become an input if it would not have been available when the model is expected to make a prediction.
Check historian data quality before using it for AI
Review tag meaning, engineering unit, expected range, source system, and sampling behavior before treating historian data as model input. A tag named P_102 may be familiar locally but meaningless to a training workflow without asset identity and documentation.
Then separate different data conditions instead of calling them all “missing data”:
- A bad or invalid value may be a measurement-quality issue.
- A blank interval may mean the source was offline, the point was not collected, or the asset was not running.
- A delayed or replayed record may be valid but arrive after its event time.
- A repeated record may be a duplicate, or it may be two legitimate observations with the same value.
Treatment depends on the industrial question. Filling every gap can hide an outage; removing every unusual value can erase the event the model needs to learn from. Keep quality indicators and transformation reasons so the dataset remains reviewable.
Preserve timestamps and operating context
Time-series training depends on what happened when. Where it is available, preserve the source or event time separately from the ingestion time. Ingestion time can help explain delay or replay; it should not silently replace the time at which the process measurement occurred.
Operating context matters just as much. Link measurements to the correct asset, unit, operating mode, production state, and relevant events. A vibration value during startup may differ from one during stable production; a standby-pump pressure reading is not equivalent to one under load.
This is where asset context helps. TDengine’s Industrial Ontology describes a semantic layer for organizing industrial assets, data, and relationships. Whether a team uses that approach or another model, the training dataset needs enough context to explain what each record represents.
Make time-series data training-ready
Prepared historian measurements can become features and labels for an external model-training workflow. Features are the inputs available when a model makes a prediction. Labels are the outcomes the model is intended to learn or estimate.
For the pump example, features might include recent vibration, suction pressure, discharge pressure, flow, run/stop state, and calculated summaries over an agreed time window. An alarm is a label only when it represents the defined target outcome, such as whether a future alarm occurs, rather than duplicating alarm information already available in the features. Engineer-confirmed maintenance findings used as labels must likewise align with the intended prediction window. The label must be reliable enough for the task, and the features must be available before that outcome is known.
The time window, transformations, and label definition are task-specific. Do not assume one resampling interval, missing-value method, or split ratio suits every historian. Validation should keep future information out of model development and compare the model with data that represents the conditions it will face later. Depending on the operating pattern and available history, that may involve chronological holdouts, rolling evaluations, grouped periods, or another justified design. The important boundary is that future events, outcomes, and post-decision records do not leak into earlier examples.
Practical example: preparing pump historian data
Suppose a plant wants an external model to help flag pump conditions for review. The historian engineer begins with a set of pumps of the same type, not every tag in the plant.
They retain vibration, pressure, flow, run/stop state, alarm history, and reviewed maintenance events. They attach equipment identity and units, preserve event time, and flag periods affected by sensor problems, network gaps, or maintenance shutdowns. They then define a feature window that only uses signals available before the intended review point.
The maintenance record is not automatically a perfect label. It may describe a symptom, an inspection result, or an action taken for several reasons. The team should review whether it is specific enough to represent the outcome the model is meant to learn. This makes the model’s training data a traceable engineering artifact rather than a spreadsheet assembled after the fact.
How prepared historian data supports external model workflows
Once a dataset has defined features, labels, timestamps, asset context, and quality boundaries, it may be provided to an external training environment. That environment could train and evaluate a model using the team’s chosen tools and governance process.
The handoff should retain the data dictionary, transformations, time boundaries, quality rules, label definition, and source references. A later model result can then be compared with current historian data and reviewed by the appropriate engineer. Preparing data well does not guarantee a useful model, but it gives the team a clearer basis for testing one.
Where TDengine fits
TDengine’s Industrial AI page describes industrial data, analytics, visualization, and AI-oriented capabilities. Together with asset and relationship context from Industrial Ontology, these documented capabilities can support the data and context side of an Industrial AI workflow.
This article does not claim that TDengine trains or deploys external models. Model selection, training, evaluation, and deployment remain separate steps that require their own tools, validation, and operational approval.
Frequently asked questions
Can a historian export be used directly for model training?
Sometimes, but it should first be checked for meaning, units, timestamps, quality conditions, asset context, and the outcome being modeled. A flat export may be useful for exploration while still being unsuitable for a production-oriented evaluation.
Does more historian data always produce a better model?
No. More data can add value when it is relevant and reliable. It can also add noise, duplicates, unrelated operating states, or misleading records if the task and quality boundaries are unclear.
What should be retained with a trained model?
Retain the data definition, feature and label logic, transformations, quality rules, time boundaries, evaluation evidence, and the sources used to create the dataset. This gives later reviewers a way to understand what the model was tested against.
